planning guide for deploying microsoft office communications
TRANSCRIPT
1
Planning Guide for Deploying Microsoft Office Communications Server 2007 R2 in a Juniper Distributed Enterprise
Created for: Microsoft Network Optimization program
June 2010
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408.745.2000
1.888 JUNIPER
www.juniper.net
2
Table of Contents
LIST OF FIGURES ........................................................................................................................................................... 4
LIST OF TABLES............................................................................................................................................................. 5
OVERVIEW ................................................................................................................................................................... 6 START HERE: PLAN YOUR JUNIPER/MICROSOFT OCS NETWORK IN THREE STEPS ................................................................................
INTRODUCTION............................................................................................................................................................ 7 SCOPE .................................................................................................................................................................................. 8 TARGET AUDIENCE.................................................................................................................................................................. 8
INTRODUCING MICROSOFT OFFICE COMMUNICATIONS SERVER 2007 R2 ..................................................................... 9 MICROSOFT OCS 2007 R2 VERSIONS ....................................................................................................................................... 9 Microsoft OCS 2007 R2 Standard Edition ....................................................................................................................... 9 Microsoft OCS 2007 R2 Enterprise Edition.................................................................................................................... 10
MICROSOFT OCS 2007 R2 DEPLOYMENT SCENARIOS ................................................................................................................ 12 MICROSOFT OCS 2007 R2 REQUIREMENTS ............................................................................................................................. 12 MEDIATION SERVER .............................................................................................................................................................. 13 MEDIA GATEWAY INTEGRATION.............................................................................................................................................. 13
OCS 2007 R2 IN A JUNIPER NETWORKS DISTRIBUTED ENTERPRISE ............................................................................. 14 WHAT DOES JUNIPER OFFER?................................................................................................................................................. 14 JUNIPER DISTRIBUTED ENTERPRISE COMPONENTS ...................................................................................................................... 15 EX Series Ethernet Switches .......................................................................................................................................... 16 M/MX Series with IMSG................................................................................................................................................ 17 SRX Series Services Gateways for the Branch ............................................................................................................... 17 Additional Components ................................................................................................................................................ 18
STEP 1: DESIGN THE NETWORK ARCHITECTURE .......................................................................................................... 20 DATA CENTER ARCHITECTURE CONSIDERATIONS ........................................................................................................................ 20 CAMPUS AND OFFICE CONSIDERATIONS.................................................................................................................................... 21 Layer 3 Recommendations ........................................................................................................................................... 21 LAN Considerations....................................................................................................................................................... 22 Wireless LAN Considerations ........................................................................................................................................ 22 WAN Considerations..................................................................................................................................................... 23 LAN and WAN Connectivity Recommendations............................................................................................................ 23
WAN CONNECTIVITY CONSIDERATIONS: OPTIMIZE MEDIA ROUTING ............................................................................................ 24 Select the Appropriate High‐Level Topology................................................................................................................. 24 SIP Trunking Topologies................................................................................................................................................ 26
STEP 2: DESIGN THE QOS CONFIGURATION ................................................................................................................ 29 Packet Flow in a QoS‐Enabled Router........................................................................................................................... 30 Juniper QoS Recommendations .................................................................................................................................... 31
STEP 3: ANALYZE DELAY AND JITTER........................................................................................................................... 33 Delay Considerations .................................................................................................................................................... 33 Jitter Considerations ..................................................................................................................................................... 34
3
Encoding Delay ............................................................................................................................................................. 35 Audio Bandwidth Considerations.................................................................................................................................. 35 Video Bandwidth Considerations.................................................................................................................................. 38 Audio and Video Recommendations............................................................................................................................. 39
SAMPLE DEPLOYMENT OF MICROSOFT OCS 2007 R2 WITHIN THE JUNIPER DISTRIBUTED ENTERPRISE ....................... 40 Small Office/Home Office ............................................................................................................................................. 41 Remote Offices ............................................................................................................................................................. 43 Medium‐to‐Large Branch Offices.................................................................................................................................. 45 Campus/Headquarters ................................................................................................................................................. 47 Data Center................................................................................................................................................................... 50
ANALYZING END‐TO‐END DELAYS............................................................................................................................................ 53
SUMMARY ................................................................................................................................................................. 56
LINKS FOR FURTHER INFORMATION ........................................................................................................................... 57
ABOUT JUNIPER NETWORKS ...................................................................................................................................... 58
APPENDIX: PUBLIC AND PRIVATE WAN LATENCY........................................................................................................ 59 AT&T................................................................................................................................................................................. 59 VERIZON BUSINESS ............................................................................................................................................................... 60 Private IP Service (MPLS) .............................................................................................................................................. 60 Internet Service............................................................................................................................................................. 60
QWEST ............................................................................................................................................................................... 62
4
List of Figures Figure 1. Standard Microsoft OCS 2007 R2 deployment........................................................................................................................... 9
Figure 2. Microsoft OCS 2007 R2 expanded deployment. ...................................................................................................................... 10
Figure 3. Microsoft OCS reference architecture. .................................................................................................................................... 11
Figure 4. Basic Media Gateway. .............................................................................................................................................................. 13
Figure 5. Juniper Distributed Enterprise components. ........................................................................................................................... 16
Figure 6. Juniper "data center fabric." .................................................................................................................................................... 21
Figure 7. Hub‐and‐spoke model. ............................................................................................................................................................. 24
Figure 8. Mesh design. ............................................................................................................................................................................ 25
Figure 9. Distributed SIP Trunking with STEP. ......................................................................................................................................... 27
Figure 10. Regional SIP Trunking with STEP and IMSG............................................................................................................................ 28
Figure 11. VoIP requirements. ................................................................................................................................................................ 29
Figure 12. QoS processing model............................................................................................................................................................ 30
Figure 13. EX Series CoS model for classification, queuing, and scheduling. .......................................................................................... 31
Figure 14. End‐to‐end delay. ................................................................................................................................................................... 33
Figure 15. Juniper Networks product portfolio for the distributed enterprise....................................................................................... 40
Figure 16. SOHO reference architecture. ................................................................................................................................................ 41
Figure 17. Remote office reference architecture.................................................................................................................................... 43
Figure 18. Typical architecture for a medium‐to‐large branch office. .................................................................................................... 45
Figure 19. Campus/headquarters reference architecture. ..................................................................................................................... 48
Figure 20. Data center reference architecture........................................................................................................................................ 51
Figure 21. End‐to‐end delay. ................................................................................................................................................................... 53
Figure 22. Delay reference architecture. ................................................................................................................................................ 54
5
List of Tables Table 1. Juniper Solution Components that Enable Microsoft UC. ......................................................................................................... 19
Table 2. DiffServ Recommendations. ...................................................................................................................................................... 32
Table 3. Types of Delays and Definitions. ............................................................................................................................................... 34
Table 4. Latency for RTAudio. ................................................................................................................................................................. 35
Table 5. RTAudio Information. ................................................................................................................................................................ 36
Table 6. Audio Capacity Planning. ........................................................................................................................................................... 36
Table 7. Voice Bandwidth with Layer 2 Header. ..................................................................................................................................... 37
Table 8. Voice Bandwidth with Layer 2 Header and IPsec. ..................................................................................................................... 38
Table 9. WAN Bandwidth Sample Planning for SOHO with T1 Interface. ............................................................................................... 42
Table 10. SRX Delays for SOHO. .............................................................................................................................................................. 42
Table 11. WAN Bandwidth Sample Planning for Remote Office with T1 Interface................................................................................. 44
Table 12. EX and SRX Delay for a Remote Office..................................................................................................................................... 44
Table 13. WAN Bandwidth Sample Planning for Medium‐to‐Large Branch Offices................................................................................ 46
Table 14. WAN Bandwidth Sample Planning for Medium‐to‐Large with Private WAN. ......................................................................... 46
Table 15. EX and SRX Delay for a Medium‐to‐Large Branch Office. ........................................................................................................ 47
Table 16. WAN Bandwidth Sample Planning for Campus/Headquarters with 8xDS3 Interface. ............................................................ 49
Table 18. WAN Bandwidth Sample Planning for Campus/Headquarters with Private WAN Interface................................................... 49
Table 19. EX and SRX Delay for the Campus/Headquarters.................................................................................................................... 50
Table 19. Branches and Campus/Headquarters Supported per Data Center with Different WAN Bandwidths..................................... 52
Table 20 Worst Delay from Different Distributed Enterprise Networks ................................................................................................. 55
Table 21 Worst/Best Delays from Different Branch Types ..................................................................................................................... 55
Table 22 Delays if All Connections are Terminated and WAN Queuing at Datacenter........................................................................... 56
6
Overview This planning guide presents the Quality of Service (QoS) and connectivity considerations that are important for a successful
implementation of Microsoft Office Communications Server (OCS) 2007 R2 in a Juniper Distributed Enterprise network. The guide describes how to determine the bandwidth requirements for the five key architectures that make up Juniper’s distributed
enterprise: small office/home office (SOHO), remote office, medium‐to‐large branch office, campus/headquarters, and the data center.
When you are planning a Microsoft OCS 2007 R2 implementation in a Juniper distributed enterprise, start by learning about the components.
• For a brief introduction to Microsoft OCS 2007, including a description of versions, deployment scenarios, and a summary of requirements, see Introduction to Microsoft Office Communications Server 2007 R2.
• For a description of a Juniper Distributed Enterprise and its components, including the SRX Series Services Gateway and the EX Series Ethernet Switches, see OCS 2007 R2 in a Juniper Networks Distributed Enterprise and Juniper Distributed
Enterprise Components. A table in this section shows the Juniper solution components that enable an OCS implementation.
Note that security is also a consideration. However, this document focuses on QoS only; security considerations are covered in other
documents.
Start Here: Plan Your Juniper/Microsoft OCS Network in Three Steps To plan your Microsoft OCS 2007 R2 implementation in a Juniper Distributed Network, you need to take a few basic steps. These steps include (but are not limited to) the following:
1. Step 1: Design the Network Architecture: engineer your network topology to optimize the media path. To ensure efficient network operation, you must seek the shortest media path by minimizing the number of hops (or links)
used in order to minimize delay. You should therefore design the most appropriate high‐level topology—mesh or hub‐and‐spoke, as well as consider the point of connection to remote telecommuters and SIP trunks—so that you have as much
direct traffic as possible. See Step 1: Design the Network Architecture.
2. Step 2: Design the QoS Configuration: plan forwarding queues.
Once your architecture design is stable, plan the use of forwarding queues throughout the network, including priority and bandwidth allocation. See Step 2: Design the QoS Configuration. Also see Packet Flow in a QoS Router and Juniper QoS
Recommendations.
3. Step 3: Analyze Delay and Jitter: verify that the expected delays for your implementation are acceptable.
For a discussion of calculating end‐to‐end delays in a Juniper Distributed Network with Microsoft OCS 2007 R2 under best‐case and worst‐case conditions, see Step 3: Analyze Delay and Jitter. Based on your calculation results, repeat steps 1 and 2
above to reach acceptable delay estimates.
7
Introduction The promise of reduced costs combined with enhanced productivity and mobility has led many companies to adopt unified
communications (UC) solutions—solutions that combine the entire set of available information applications under the single, broad umbrella of communications. This evolution started with voice/video, instant messaging (IM), and e‐mail, and is moving forward to
encompass corporate applications with real‐time communications—even corporate systems that include Customer Relationship Management (CRM) and Enterprise Resource Planning (ERP).
UC integrates both real‐time and non real‐time communications with business processes and requirements that are based on presence capabilities and presents a consistent unified user experience across multiple devices and media types. UC is not a single
product, but rather a solution composed of a variety of communication tools and components that let people connect, communicate, and collaborate seamlessly to improve business agility and results. These results include better user and group
productivity, dynamic collaboration and simplified business processes, with the goal of increasing revenues, decreasing costs and improving customer service.
Microsoft approaches UC from the enterprise application side with Microsoft Office Communications Server (OCS) 2007 R2, a client‐
server product that uses the Session Initiation Protocol (SIP) to facilitate real‐time communications between users. OCS 2007 R2 provides the infrastructure for:
• Enterprise instant messaging • Presence
• File transfer • Peer‐to‐peer and multi‐party voice and video calling
• Ad hoc and structured conferences (audio, video and Web) • Public switched telephone network (PSTN) connectivity
These features are available within an organization, between organizations, and with external users on the public Internet or on standard phones (PSTN as well as SIP trunking).
Implementing a comprehensive UC solution with OCS 2007 R2 requires more than OCS server and OCS clients. Successful UC
implementations need scalable, converged solutions that provide security, connectivity, and performance to ensure the reliability of data, voice, and video communications—all while securing the network and protecting corporate assets. As a Microsoft OCS implementation grows and evolves, it can benefit from a single high‐performance network infrastructure that can deliver high‐
quality voice and data services without latency, jitter, and packet loss, which can cripple real‐time voice and video communications. Juniper Distributed Enterprise networks deliver the solution.
Juniper Networks® Distributed Enterprise solutions are comprehensive, high‐performance networking solutions that include switching, routing, security, network management, and WAN optimization—all with a lower total cost of ownership (TCO) than other
solutions. The solutions accomplish this by providing consistent IT networking services for connectivity, security, and manageability for anyone, anytime, anywhere in the distributed enterprise.
Deploying Microsoft OCS on a single, converged network requires careful consideration. UC implementations require high and consistent bandwidth to maintain performance. While latency, jitter, and packet loss rarely have an impact on the quality of data
communications, they can have a crippling effect on voice and video communications. UC solutions have real‐time requirements and high availability (HA) connectivity expectations. These applications are particularly vulnerable to performance degradation and
8
failures in network links or devices. And because users expect their voice and video communications to be private, solutions must
meet the highest standards for security. High‐performance routing, switching, and security must move the packets through the network with appropriate Quality of Service (QoS), ensuring that security appliances, switches, routers, gateways, and other
components do not affect the Quality of Experience (QoE) for the user.
This planning guide discusses the QoS and connectivity considerations that are important for a successful OCS 2007 R2 implementation in a Juniper Distributed Enterprise network. It provides bandwidth guidelines and recommendations for the five key
architectures that make up Juniper’s distributed enterprise: • Small office/home office (SOHO)
• Remote office • Medium‐to‐large branch office
• Campus/headquarters • The data center
Scope This paper presents guidelines to help ensure sufficient bandwidth when implementing Microsoft OCS 2007 R2 in a Juniper
Networks distributed enterprise that includes SOHOs, remote offices, medium‐to‐large branch offices, campus/headquarters, and a data center. This document focuses on QoS and connectivity issues; security issues are addressed in separate documentation.
Target Audience This guide is intended for the following network personnel:
• Network architects • Network designers
• Network administrators
9
Introducing Microsoft Office Communications Server 2007 R2 Microsoft’s UC solutions use the power of software to streamline communications. Microsoft OCS 2007, the cornerstone of
Microsoft’s UC solution, is the platform for presence, instant messaging, conferencing, and enterprise voice for businesses around the world. Microsoft OCS 2007 R2 adds chat rooms as well as additional IM, conferencing, and telephony functionality, such as
interactive voice response (IVR) and conferencing auto‐attendant. User interfaces include Microsoft Office Communicator, a unified communications client, as well as Office Communicator Web Access, Office Communicator Mobile, Office Communications Server
Attendant, and RoundTable.
Microsoft OCS 2007 R2 Versions Office Communications Server 2007 R2 comes in different versions—the Standard Edition and the Enterprise Edition. The Standard
Edition includes all of the components on a single server, while the Enterprise Edition is deployed on multiple servers, allowing a customer to scale when demands increase.
Microsoft OCS 2007 R2 Standard Edition Office Communications Server 2007 R2 Standard Edition is deployed with the Front End Server, Microsoft SQL Server, A/V Conferencing Server, Web Conferencing Server, and Web Components Server installed on a single physical computer. (See Figure 1.)
Figure 1. Standard Microsoft OCS 2007 R2 deployment.
10
Office Communications Server 2007 R2 Standard Edition is recommended for small to mid‐sized organizations, such as branch and
pilot deployments, which do not have high availability and performance requirements. All components in this topology are located on one server. This configuration is bundled with Microsoft SQL Server Express 2005 SP2 or SP3. The configuration shown in Figure 1
can support up to 5,000 users per server.
Microsoft OCS 2007 R2 Enterprise Edition Enterprise Edition is recommended for most organizations. There are two possible topologies: expanded and consolidated. Enterprise Edition servers run the Front End Server, A/V Conferencing Server, Web Conferencing Server, and Web Components
Server. Each of these components can be installed on one server or on separate servers to balance the load.
Expanded Topology
An expanded topology lets you place higher‐demand services, such as conferencing, onto dedicated servers, which allows a pool to service a larger number of clients than is possible using a consolidated topology (up to 125,000 users). However, an expanded
topology tends to be more tedious and expensive to deploy; it is no longer a recommended scenario and requires command‐line installation and configuration in OCS 2007 R2. An expanded deployment is shown in Figure 2.
Figure 2. Microsoft OCS 2007 R2 expanded deployment.
Consolidated Topology
The recommended topology for Microsoft OCS 2007 R2 is a consolidated configuration with Enterprise Edition in which all server
roles in a pool are on a single computer. This topology reduces both deployment and operational overhead, which in turn reduces
11
cost of ownership. Scalability (up to 100,000 users) is achieved by adding computers to the pool or perimeter network and load
balancing them. The topology uses a consolidated edge server, a monitoring server (CDR and QoE), and a dedicated archiving server.
The following considerations apply to the Enterprise Edition consolidated configuration:
• A single Enterprise Edition server can be configured as an enterprise pool. • A hardware load balancer is required when two or more Enterprise Edition servers are configured as a pool.
• The back‐end database must be deployed on a separate server.
Figure 3 shows a consolidated topology that illustrates the server roles and components.
Figure 3. Microsoft OCS reference architecture.
12
Microsoft OCS 2007 R2 Deployment Scenarios Microsoft UC leverages standards and published interfaces to integrate with existing telephony and application infrastructure
investments. The result is a flexible integration of telephony with other business communications tools. Microsoft OCS 2007 R2 supports several deployment scenarios that address different customer deployment strategies and timelines, as well as customers’
existing telephony investment mix. • Microsoft OCS 2007 R2 Co‐Existence
In this deployment scenario, a PBX coexists with OCS 2007 R2 and Office Communicator to provide a flexible and powerful combination of traditional telephony and unified communications. If your PBX infrastructure does not natively support this
scenario, you can use a Microsoft‐certified IP‐PSTN media gateway to provide integration between OCS 2007 R2 and the PBX.
• Microsoft OCS 2007 R2 Stand‐Alone
You can exclusively use OCS 2007 R2 and associated elements for the voice communications needs of your enterprise, eliminating the PBX phone altogether. OCS 2007 R2 stand‐alone is distinct from OCS 2007 R2 co‐existence in that the
enterprise dial plan is partitioned between OCS 2007 R2 users and PBX users. This means that you can have either a PBX phone or an Office Communicator endpoint, but not both.
• Remote Call Control In this scenario, you can issue commands from Office Communicator 1.0 to the PBX for your telephone extension (for
example, click to call or accept a call). Office Communicator 1.0 merely sends commands to the PBX to carry out actions on the calls routed to your extension. The integration uses the CSTA over SIP standard TR/87 protocol, and commonly requires
a third‐party CSTA server. The advantage of CSTA as an integration mechanism is that most PBX types and models support this technology, thereby enabling a powerful addition to user functionality without having to affect the PBX installation or
configuration. With more recent versions of PBXs or the appropriate third‐party integration, the OCS 2007 and OCS 2007 R2 support this scenario and can continue to work alongside the co‐existence scenario.
Microsoft OCS 2007 R2 Requirements
There are many requirements to consider when planning a Microsoft OCS 2007 R2 deployment, including the following. (Consult the
Microsoft OCS 2007 R2 documentation for a complete list of requirements.) • Active Directory Domain Services Requirements
OCS relies on Active Directory Domain Services (AD DS) to store global settings and groups that are necessary for deployment and management. The first step in deploying OCS 2007 R2 is to prepare AD DS by extending the schema and
then creating and configuring objects. The schema extensions add the Active Directory classes and attributes that OCS requires.
• Network Infrastructure Requirement The network adapter card of each server in the OCS topology must support at least 1 Gigabit per second (Gbps). In general,
you should connect all server roles within the OCS topology using a low latency and high bandwidth local area network (LAN). The size of the LAN is dependent on the size of the topology (described later in this document):
o In Standard Edition topologies, servers should be in a network that supports 1 Gbps Ethernet or equivalent. o In Enterprise pool topologies, most servers should be in a network that supports more than 1 Gbps, especially
when supporting audio/video conferencing and application sharing.
• Network Audio/Video Requirements If you plan to deploy an A/V edge server, a publicly routable IP address is required on its external interface. If you anticipate
13
a high volume of audio/video traffic or experience packet loss after you deploy, you should optimize the network interface
card to accommodate the A/V traffic.
Mediation Server Client access to OCS 2007 R2 is provided through either Microsoft Office Communicator 2007 or the Live Meeting client installed on
a PC. OCS 2007 R2 also includes the Mediation Server, which provides a “front end” element to: • Enable intermediate signaling and call flows through a back‐to‐back‐user‐agent (B2BUA), including adding or removing
elements of a SIP transaction that were not supported by most telephony elements.
• Transcode real time protocol (RTP) media flows from traditional codecs, such as G.711, to the Microsoft advanced audio codec, Real‐time Audio (RTAudio).
• Act as an interactive connectivity establishment (ICE) client to enable PSTN‐originated media flows to traverse intervening network address translations (NATs) and firewalls.
• Enroll in the management, monitoring and provisioning scheme (leveraging Microsoft management technologies such as WMI, MMC, AD DS, and System Center) to extend management functions to the PSTN and PBX.
• Provide intermediation for a pool of media gateways.
• Interoperate with PSTN Service Provider network elements.
• Provide branch office survivability functions.
• Provide legacy telephone device interoperability.
Media Gateway Integration Media gateways play a vital role in unified communications. Bridging users from the OCS 2007 R2 and PSTN worlds together when a
SIP‐enabled PBX is not present requires a media gateway, as illustrated in Figure 4.
Figure 4. Basic media gateway.
14
OCS 2007 R2 in a Juniper Networks Distributed Enterprise Today’s enterprise footprints are distributed far beyond the corporate headquarters to globally distributed locations that encompass
several branch locations, numerous remote offices, and even home offices and mobile workers. Furthermore, enterprises are more “fluid” than ever. An employee may work at the main campus one day and from a remote location the next. This means all work
centers are now business‐critical and require consistent, secure, high‐performance IT networking systems.
The key to successful OCS deployment for these distributed enterprises is to have a network infrastructure that provides fast and
consistent application performance, high availability, reliability, and security. When designing the network, it is critical for the network architect to have a clear understanding of the codecs used, of the network requirements (in terms of latency, jitter, and
packet loss), and of the new security vulnerabilities that are continually being introduced. It is also important to assign appropriate QoS to the network traffic so that downstream network devices can expedite time‐sensitive packets to ensure a satisfactory user
experience.
Juniper Networks Distributed Enterprise solutions enable OCS 2007 R2 to provide service “without boundaries” by delivering consistent connectivity, security, and management services across all workforce centers, regardless of size or location. In addition,
Juniper’s distributed enterprise systems maintain a focus on reducing the overall total cost of ownership (TCO) of the networks.
What Does Juniper Offer? Juniper solutions offer IP switching, routing, security, wide area network (WAN) application acceleration, and Integrated
Convergence Services (ICS) for the UC/VoIP solutions that power and protect the network as well as the Microsoft applications and services that run on it. As a Microsoft Certified Partner, Juniper works closely with Microsoft to create a responsive and trusted
environment for accelerating the deployment of Microsoft OCS over a single converged network.
The Juniper/Microsoft collaboration helps customers meet their single‐network needs by providing: • Comprehensive QoS functionality to classify, prioritize, and schedule voice and video traffic in a way that ensures the end
user’s communications quality.
• Voice‐enabled architecture and link fragmentation and interleaving (LFI) to provide low latency and jitter in support of clear voice communications.
• Application‐specific integrated circuit (ASIC)‐based processing to accelerate the performance of processor‐intensive functions in routing, switching, and security appliances.
• Modular Juniper Networks JUNOS® software to reduce integration costs and increase network efficiency.
• Compressed Real Time Protocol (cRTP), which compresses packet headers to increase network efficiency.
• Internet protocol security (IPsec) VPN technology to support low‐latency, encrypted voice traffic for large‐scale WAN deployments.
• Power over Ethernet (PoE) for standard, managed, and undisrupted power for VoIP phones.
• Link Layer Discovery Protocol (LLDP) and LLDP‐Media Endpoint Discovery (LLDP‐MED) for VoIP capabilities, power management, and network inventory of VoIP devices.
• Dynamic Host Configuration Protocol (DHCP) services and DHCP relay for Layer 3 addressing of VoIP phones and desktops that share a connection to the same access port.
• Peering with PSTN, PBX, and SIP Trunking services with the use of Juniper SRX ICS (SIP Media GW), SRX STEP (SIP Trunking Edge Point), M/MX IMSG (Integrated Multiservice GWs), and SRX/ SSG ALGs.
15
JUNOS is the common language running across every router, switch, and security device that makes up a Juniper solution. JUNOS is
an open, adaptive, and customizable application development platform. JUNOS software offers standard‐based IETF DiffServ, which interoperates well with the Microsoft UC system.
The JUNOS operating system supports application layer gateways (ALGs) for SIP and other protocols that are prevalent in UC deployments. The ALG dynamically opens and closes firewall ports to allow incoming and outgoing calls to transit the network. A
complementary solution aimed at carrier peering scenarios and based on SIP back‐to‐back‐user‐agent (B2BUA) functionality uses integrated multi‐service gateways (IMSG) implemented over M/MX Series routers and SIP trunking edge point (STEP), a function
embedded within the media gateway (MGW) in SRX Series for the Branch; both STEP and IMSG incorporate SIP signatures that support intrusion prevention systems (IPS). For more detail, see M/MX Series with IMSG.
The Juniper Networks security solution works in a NAT environment that uses private IP addresses, which can complicate the process of receiving calls. Juniper offers plug‐and‐play functionality in NAT environments for Microsoft UC―customers can choose a
strict NAT scheme for tight security environments or a full‐cone NAT scheme. In either case, Microsoft OCS Interactive Connectivity Establishment (ICE) can be used for NAT traversal, but with different media routing patterns. ICE makes use of existing protocols,
such as Simple Traversal of UDP through NAT (STUN), Traversal Using Relay NAT (TURN), and Real Specific IP (RSIP), and works through the mutual cooperation of both endpoints in a SIP dialog. For more detail, see Step 1: Design the Network Architecture .
Juniper Distributed Enterprise Components The Juniper Distributed Enterprise core solution components include service gateways (the SRX Series Services Gateways), switches (the EX Series Ethernet switches), routers (including the M/MX Series routers with IMSG), as well as additional components to
address security, switching, and other functionality. Note that all products are based on JUNOS and share the same IPS service. Figure 5 illustrates some features of these components.
16
Figure 5. Juniper Distributed Enterprise components.
EX Series Ethernet Switches Juniper EX Series Ethernet Switches (EX2200, EX3200, EX4200, EX4500, and EX8200) deliver carrier‐class reliability, security risk
management, network virtualization, application control, and reduced total cost of ownership (TCO) because of the scalable, pay‐as‐you‐go architecture.
The EX Series switches feature Juniper Networks Virtual Chassis technology, which enables multiple switches to be interconnected and operate as a single system. For example, up to 10 EX4200 switches can be interconnected over a 128 Gigabit‐per‐second (Gbps)
backplane, creating a single virtual switch supporting up to 480 10/100/1000BASE‐T ports and up to 40 GbE or 20 10 GbE uplink ports.
The EX Series switches also support generic routing encapsulation (GRE) tunneling. This technology allows mirrored traffic to be sent from remote locations to monitoring devices in the network operations center for centralized troubleshooting and analysis. It also
supports the construction of segregated overlay networks without the challenges associated with Spanning Tree Protocol (STP).
Each of the EX Series switches delivers wire‐speed performance on all ports for any packet size. For instance, the EX8200 modular
switches deliver up to 128 wire‐speed 10 Gigabit Ethernet ports per chassis with nearly 2 billion packets per second throughput. The
17
EX Series switches support eight QoS queues per port, ensuring proper prioritization of control plane, voice, video, and multiple
levels of data traffic—with room to converge other networks, such as when adding automation and video security systems.
Additional features that are VoIP or UC specific include:
• Support for LLDP and LLDP‐ME, which enables the switches to automatically discover Ethernet‐enabled devices, determine their power requirements, and assign virtual LAN (VLAN) parameters.
• Class 3 PoE with 15.4 W on some or all ports to VoIP phones, closed‐circuit security cameras, wireless access points, and other IP‐enabled devices.
• 802.1X with VoIP VLAN support, which provides 802.1X (port‐level) access control as well as Layer 2‐4 policy enforcement based on user identity (such as those contained in Microsoft Active Directory), locations, and/or device.
M/MX Series with IMSG Juniper M Series Multiservice Edge Routers (M7i, M10i, M120, and M320) have a wide array of WAN interfaces typically deployed in
head office locations that require high‐performance packet processing, such as Internet gateways, WAN aggregation devices, data center routers, or backbone routers.
The Juniper MX Series 3D Universal Edge Routers (MX80, MX240, MX480, and MX960), are optimized for Ethernet and provide high‐performance and high port‐density routing and switching in both campus core and aggregation, in data center core and aggregation,
and WAN edge.
The M and MX Series offer IMSGs with session border control (SBC) in the core, as well as IPS, GW, IPsec, and video QoS monitoring.
For the data center or large campus with many endpoints, IMSG provides large‐scale peering between the enterprise and the carrier or service provider. The Juniper IMSG package is similar to STEP, but can do much more, including the following:
• Routing SIP properly.
• Managing trunks and multiple carriers.
• Controlling bandwidth between the enterprise and the service provider.
• Providing security to prevent outside attacks.
SRX Series Services Gateways for the Branch Juniper Networks SRX Series Services Gateways provide the essential capabilities necessary to connect, secure, and manage enterprise and service provider networks, from the smallest sites to the largest headquarters and data centers. When they
consolidate switching, routing, and security services in a single device, organizations can economically deliver new applications and services, secure connectivity, and ensure quality end‐user experiences.
The SRX series is offered in versions for the branch (SRX100, SRX 210, SRX240, and SRX650), and for the data center (SRX3400, SRX3600, SRX5600, and SRX5800).
SRX Series Services Gateways for the Branch
The SRX Series Services Gateways for the Branch (SRX100, SRX 210, SRX240, and SRX650) combine JUNOS routing, switching and
security with integrated convergence services (ICS) security within a single device.
Features of the SRX Series Gateways for the Branch include:
• OCS 2007 R2‐compatible Direct SIP Media Gateway Branch SRX Series Media Gateways integrate with OCS, Standalone or Enterprise Edition. This allows customers to adopt
and deploy UC at branch locations on a Juniper converged network.
18
• Onboard PSTN Interfaces
These interfaces integrate branch telco lines and analog phones with OCS call routing.
o FXS ports enable existing analog phones, faxes, or PBX systems for OCS across distributed enterprise locations.
o FX0 ports allow for local PSTN call routing, local access number preservation and direct E911 calling from the branch.
• Onboard PoE This feature directly powers IP phones or other devices through the Ethernet cable—up to 15.4W per port using 802.3af
standards. This capability eliminates the need to purchase and deploy a separate PoE switch for smaller branch locations where four or fewer PoE ports are required.
• STEP—onboard SIP trunking STEP is a function embedded within MGW in Branch SRX (no additional license needed). It optimizes media routing to SIP
trunking services to assure the highest quality service and security. It also reduces cost and adds survivability and flexibility. This gateway for SIP/RTP traffic going to/from local SIP trunks is responsible for security, topology hiding, QoS, and more.
• SIP Survivable Call Server (SCS) SCS provides local call handling and call routing for branch analog and IP phones (standard SIP phones) when the
centralized SIP call server (or peer call server) that provides them under normal conditions is unreachable. Supported features include class of restriction for stations, auto‐attendant, call transfer, voicemail forwarding, three‐way calls, and
more.
SRX Series Services Gateways for the Data Center
Based on the Dynamic Services Architecture, the SRX Series Services Gateways for the Data Center (SRX3400, SRX3600, SRX5600, and SRX 5800) provide performance, scalability, and security. The SRX Series is designed to meet the network and security
requirements for data center consolidation, rapid services deployment, and aggregation of security services such as IPsec tunnels. With the SRX Series Services Gateways, security services such as firewall, application‐level gateway (ALG), intrusion prevention
system (IPS), and IPsec can be applied to all traffic going to/from MGW and the SIP trunk edge point in the branches.
Additional Components Additional Juniper solution components include the following.
• For application acceleration:
o WX/WXC Series Application Acceleration Platforms: Deliver fast and consistent application response across the WAN to help ensure uncompromised access to mission‐critical applications and services.
• For network management:
o Network and Security Manager (NSM): Provides a single pane of management for the entire network infrastructure, including routing, switching, and security devices.
o STRM Series Security Threat Response Managers: Collect events and alerts from different Juniper and third‐party products and aggregate them to deliver an enterprise‐wide threat management view.
• For the network operating system:
o Junos Software: Integrates routing, switching, and security services, and offers the power of one operating system to reduce complexity, achieve operational excellence, and deliver dynamic services with lower TCO.
• For security:
19
o SA Series SSL VPN Appliances: Feature best‐in‐class performance, scalability, and redundancy for organizations requiring high‐volume secure access and authorization.
o Unified Access Control (UAC) Appliances: The IC4500 and IC6500 Unified Access Control Appliances are next‐generation hardened, centralized policy management servers that deliver superior scalability, performance, and cryptographic operations for large, multinational organizations and government agencies.
• For services:
o J‐Care Technical Services: J‐Care Technical Services ensure rapid response from Juniper engineers and offer hardware replacement options so you can choose the timing and resources that are right for your network.
• For routing:
o MX Series Ethernet Services Routers: Provide Ethernet switching capabilities coupled with the carrier‐class routing features customers expect from Juniper.
Table 1 lists the specific Juniper solution components for the distributed enterprise.
Table 1. Juniper Solution Components that Enable Microsoft UC.
Enterprise Location Routing Switching Security/VPN Access Control
WAN Optimization
Policy Management
Integrated Convergence Services
Data center
MX960 MX480 MX240 M320 M120 M10i
EX820 EX4200 EX3200
ISG2000 ISG1000 NetScreen‐5400 NetScreen‐5200 IDP8200
SA6500 IC6000 IC4000
WXC Stack WXC3400 WXC2600 WXC590 WXC500 WXC250
IC6000 IC4000
SRX 3000 SRX Series Services Gateways for the Data Center (SRX3400, SRX3600, SRX5600, and SRX 5800)
Campus/Headquarters
M10i M71
EX8200 EX4200 EX3200
ISG2000 ISG1000 NetScreen‐5400 NetScreen‐5200 IDP8200
SA6500 SA4500 IC6000 IC4000
WXC3400 WXC2600 WXC590 WXC5000
IC6000 IC4000
SRX 650 SRX Series Services Gateways for the Data Center (SRX3400, SRX3600, SRX5600, and SRX 5800)
Medium‐to‐Large branches
SRX240 SRX650
EX220 EX3200
SRX240 SRX650
SA2500 SA700 IC4000
WXC2600 WXC250
Provided from a central location
SRX240 SRX650
Small office/Home office
SRX210 SRX100 SRX210
SRX100 SRX210
SRX210 WXC250 Provided from a central location
SRX210
20
Step 1: Design the Network Architecture Quality of Service (QoS) refers to the standards‐based capability of a network to provide better service to selected network traffic.
Considering QoS means that the bandwidth, error rates, and latency are monitored, sampled, and optimized so you can deliver data efficiently by reducing the impact of delay during peak times when networks are approaching full capacity. It also means that
network devices are properly configured to respect QoS priority assigned to data packets. QoS does not mean adding capacity; it means managing data traffic better so that top priority traffic is not queued behind lower priority traffic. QoS helps manage the use
of bandwidth by applying a set of tools, such as a priority scheme, so that certain packets (such as mission‐critical or voice and video packets) are forwarded first.
End‐to‐end QoS is critical for Microsoft OCS and UC applications. These are real‐time applications that are extremely sensitive to latency, jitter, and packet loss. Failure to implement QoS opens the possibility of contention, or interference from other applications
on the network. Simply adding bandwidth does not solve the problem. Even a network with large bandwidth capacity can have poor VoIP call quality due to network contention.
Some of the most common challenges associated with deploying UC include: application performance, lack of network infrastructure, insufficient expertise, and lack of bandwidth. Knowing the amount of bandwidth required for voice and video
applications helps to determine the amount of WAN/LAN bandwidth needed throughout the distributed enterprise. (Layer 2 headers and IPsec headers should be included in the calculation because they can easily double the amount of bandwidth required.)
When planning an OCS implementation, it is also important to consider the possible congestion points. Although several places on the network typically experience congestion, the access level and WAN edge experience the most. This is mainly due to bandwidth
mismatch and over‐subscription. The only way to guarantee service is to enable queuing and policing at any node that has the potential for congestion. In general, to deploy OCS successfully, WAN links must provide policy and compression, and must prioritize
voice and video traffic as VoIP moves onto and throughout the WAN; WAN queuing introduces significant delay in VoIP traffic.
Data Center Architecture Considerations The data center stores the majority of servers and call controllers and is the termination point for the aggregated WAN and LAN links from the campus/headquarters and from the branches.
Frequently, a three‐layer hierarchical model is used for the network design of a data center; this model permits traffic aggregation and filtering at three successive routing or switching levels, each of which has a specific role:
• The core layer provides optimal transport between sites. • The distribution layer connects network services to the access layer and implements policies regarding security, traffic
loading, and routing. • The access layer consists of the routers at the edge of the campus networks in a WAN design. In a campus network, the
access layer provides switches or hubs for end‐user access.
Typically, a data center has a large number of ports that need to be aggregated, and the three switching layers for aggregating all of
the ports are oversubscribed. This leads to delays and inefficiency.
The Juniper solution uses High‐End SRX Series Services Gateways (SRX3400, SRX3600, SRX5600, and SRX 5800) and EX Series
switches to simplify the network. The solution collapses the core and distribution layer in the data center into a single layer using the Virtual Chassis technology built into the EX switches. This “data center fabric” decreases latency and increases availability.
21
Note that this solution can also apply to a large campus.
Figure 6. Juniper "data center fabric."
Campus and Office Considerations For the campus and office (which may be a small office/home office, remote office, or medium‐to‐large branch office), considerations center on Layer 3, LAN, Wireless LAN (WLAN), and WAN.
Layer 3 Recommendations For Layer 3, you should plan for the use of VLANs—groups of devices configured to communicate as if they were attached to the
same broadcast domain regardless of their physical location. A VLAN has the same attributes as a physical LAN, but it lets end stations be grouped together even if they are not located on the same network switch. This capability lets you reconfigure the
network through software instead of by physically relocating devices and reconnecting cable to different ports. VLANs provide the segmentation services traditionally provided by routers in LAN configurations. VLANs also address issues such as scalability, security,
and network management. Routers in VLAN topologies provide broadcast filtering, security, address summarization, and traffic flow management.
Juniper recommends keeping the voice and data traffic in separate VLANs. This can be done by either configuring the port as a trunk
port or using the VoIP VLAN command feature, which allows both tagged packets and untagged packets on an access port. Packets that are tagged are assigned to the voice VLAN, while untagged packets are assigned to the data VLAN.
Once an IP phone has been placed on the network, the branch network infrastructure, services gateway, or switch should be able to auto‐sense it by using the LLDP‐MED protocol. (LLDP and LLDP‐MED are IEEE 802.1AB and IEEE 801.1AB‐extensions that allow
network devices to advertise and receive their identity and capabilities on a LAN segment.)
22
LLDP‐MED offers the following capabilities:
• Network policy discovery LLDP‐MED lets endpoints and switches advertise their VLAN IDs (for example, VoIP‐VLAN), Layer 2 class of server (CoS), and
differentiated services code point (DSCP).
• PoE management
LLDP‐MED lets endpoint devices advertise their actual PoE levels. This helps power sourcing equipment such as switches to allocate and manage their power budget.
• Inventory management discovery LLDP‐MED lets switches store endpoint device information such as vendor, model firmware, and serial numbers. This
information is accessible from neighboring network devices and provides a means for reporting inventories.
IP phones and desktops require an IP address for communication with call servers. DHCP services are either provided locally by EX
Series switches or DHCP relay can be used to forward DHCP discovery messages to DHCP servers. Since Layer 3 termination is usually at the aggregation or core layer for a two‐tier model, DHCP relay is configured at the core switch. In addition, to enable high
availability, Virtual Router Redundancy Protocol (VRRP) is implemented at the core switch to provide failover.
LAN Considerations An enterprise branch office LAN infrastructure typically comprises one or two layers depending on its size.
• Small offices or retail stores These normally need five to 50 Ethernet ports, partial or full PoE, and typically use the integrated switching functionality of
the branch services gateway device.
• Medium branch offices of 50 to 100 Ethernet ports
These typically use a fixed configuration switch for interconnecting more devices such as laptops, desktops, phones, printers, access points, and security cameras.
• Larger branch office sites, supporting from 100 to 500 end users These typically have an access layer with multiple access switches in one or many wiring closets. The access layer in the
branch LAN hierarchical topology has a specific function. It serves as the periphery of the LAN network and provides interfaces to personal computers, printers, IP phones, and wireless access points deployed within the branch office.
When planning the office LAN deployment, you should consider the following: • The capacity requirements of the LAN
This dictates the speed and number of ports required for connecting all machines at a branch to the LAN.
• Logical segmentation and how many logically separate networks should share the same LAN
• Application‐specific requirements, such as redundancy of LAN switching
• PoE capabilities of the LAN devices
• QoS marking at the source
• Support for 802.1X
• Available security features such as access control lists (ACLs)
Wireless LAN Considerations Wireless access can be found in each type of office. When designing a wireless network, a primary concern is often security. WLAN‐
enabled branch products should offer enhanced security functionality for WLAN and should support multiple service set identifiers (SSIDs) per device. By using multiple SSIDs, different security functionality can be used on different wireless networks, providing the
23
best in both security and ease‐of‐use capabilities. Network architects tend to select the tighter security functionality with WiFi
Protected Access (WPA) encryption and 802.1X authentication to provide a truly secure WLAN for the office. Additionally where needed, architects can grant open access to a wireless network with limited risk by employing the user‐identity‐based access control
Layer 3 and/or Layer 2 security policies to allow different levels of user access for different functional groups (for example, Finance, Human Resources, or engineering departments).
For more information about WLAN, see the Juniper Research report, Broadband Wireless LAN. Also, see information about the AX411 WLAN access point at AX Series in the Juniper product documentation.
WAN Considerations It is important to consider the competing demands of cost containment and increased network traffic. Since WAN costs typically account for the IT department’s highest expenditure after headcount, most enterprises do not have the luxury of simply adding
more WAN capacity to their networks. A SOHO or branch office typically uses one or a combination of the following three WAN connection types:
• Private Management of Point‐to‐Point circuits Typically these circuits will provide Layer 2 (L2) connectivity between two locations. A branch office is more likely to use this
connection type, typically referred to as L2VPN or private circuits, where locations are permanent and the importance of data communications is high.
• Provider Provisioned VPN (PPVPN) With PPVPN, the enterprise receives a full mesh of connectivity between multiple nodes. Normally referred to as MPLS
L2/L3 VPN, this connectivity is typically managed by the service provider, and the provider manages routing, or metro Ethernet switching if it’s L2, to form a full meshed topology.
• The Internet This is usually a connection between sites over the Internet, wired or wireless, with IPsec tunneling to secure the internal
traffic.
A WAN optimization and application acceleration platform must have specific attributes in order to overcome the bandwidth,
latency, congestion, and manageability issues that impede application performance over the WAN. It must also support QoS and bandwidth optimization features that are critical to deployment of real‐time applications like voice and video.
For information about Juniper WAN acceleration (WX/WXC platforms), see WXC Series in the Juniper product documentation.
LAN and WAN Connectivity Recommendations In general, connectivity means providing connections for the LAN, wireless LAN (WLAN), and WAN. The medium‐to‐large branch
office will generally have to deploy Multiple Protocol Label Switching (MPLS) layer 2 or layer 3 connectivity as well; this is typically deployed transparently by a service provider, offering a reliable VPN service to the enterprise. MPLS networks and network traffic
engineering capabilities are typically deployed to configure Label Switch Paths (LSPs) with Resource Reservation Protocol (RSVP) or Label Distribution Protocol (LDP). This is especially critical with voice and video deployments, because QoS can mitigate latency and
jitter issues by sending traffic along preferred paths or by enabling fast reroute to anticipate performance problems or failures.
You should provide seamless LAN and WLAN connectivity and ensure service availability for the office. Recommendations for office
LAN and WAN connectivity include: • Flexible connectivity
You should ensure flexible connectivity to the WAN and Internet—such as Metro WAN as primary and Internet (third‐generation wireless or ISDN) as backup—that supports a variety of interfaces (third‐generation wireless, xDSL, cable, T1/E1,
DS3, and other) that scale from Kbps speeds to Gbps speeds.
24
• Split tunneling
You should allow for split tunneling so that Internet traffic goes straight to the Internet while data center traffic is tunneled.
• Sufficient bandwidth
You should ensure that sufficient bandwidth is allocated for critical applications, especially with server centralization where most or all applications are accessed from remote data centers.
• Granular QoS You should support granular QoS so that traffic can be prioritized as real time, business critical, or best effort so that new
applications like VoIP and video can be rolled out without requiring any (or little) change to the branch office infrastructure.
• PoE
You should support PoE in order to deploy devices like IP phones, cameras, and similar devices.
WAN Connectivity Considerations: Optimize Media Routing To ensure efficient network operation, you must optimize the number of hops (or links) used to minimize delay. Wherever possible, you should explore ways to allow direct media routes.
Select the Appropriate High‐Level Topology There are several ways to optimize media routing by selecting an appropriate high‐level topology. You can use mesh‐structured
MPLS. Alternately, you can use Internet‐carried Real‐time Transport Protocol (RTP) with split VPN tunnels; this allows voice and video traffic to route directly to telecommuters or to other branches if all of the end points register externally and are using full‐cone
NAT.
Hub‐and‐Spoke Model
Because of the cost, scalability, and manageability constraints, traditional private WAN designs usually use a hub‐and‐spoke model,
implementing either a centralized hub design or a more efficient regional hub design. Under hub‐and‐spoke designs, QoS is primarily administered by the hub router, or WAN aggregator, by the enterprise customer. As long as the service provider meets the
contracted service levels, the packets received at remote branches reflect the scheduling policies of the WAN aggregator. The WAN aggregator controls not only the campus‐to‐branch traffic, but also the branch‐to‐branch traffic, which is homed through the hub.
(See Figure 7.)
Figure 7. Hub‐and‐spoke model.
25
Mesh Model With a mesh design, the hub router administers QoS for the campus‐to‐branch traffic, but does not fully control the QoS for branch‐
to‐branch traffic. Enterprises and service providers must jointly administer QoS over MPLS VPNs. Routers must have queuing policies, and will also typically enforce SLAs using policies on ingress. (See Figure 8.)
Figure 8. Mesh design.
Telecommuter Support As telecommuting becomes a more popular option, you must consider how to optimize routing of telecommuters’ calls. Customer networks (including hotels, conference centers, and so on) are generally built on private address space schemes. This means that the
telecommuter is usually behind some type of NAT. The enterprise (the HQ and branches) are on a single address space and are also behind NAT. Juniper offers plug‐and‐play functionality for Microsoft UC in NAT environments; ICE can be used for NAT traversal, but
with different media routing patterns depending on whether symmetric NAT or full cone NAT is used. ICE uses existing protocols―such as STUN and TURN―and works through a SIP dialogue at the endpoints (the telecommuter and the enterprise HQ
or the branch).
Two types of firewalls are generally used and impact the way telecommuters interact with the branch. They are: • Symmetric firewall
Also called a strict firewall, the symmetric firewall provides the best level of security. This type of firewall allows communication initiated only by an end point in the protected zone to a host in the outside public zone. Responses from
the outside zone, verified to be from the very same IP and port targeted from inside, will be permitted, but any other traffic attempting to enter is blocked. The symmetric firewall is the most common firewall used in enterprise environments.
• Full‐cone NAT
Full‐cone NAT allows for higher traffic capacity, is usually less expensive, and is mainly used to support NAT with a very limited level of protection. Once an internal end point opens a communication session and opens a pin hole to the outside,
any publicly located host can send traffic to the internal end point through the same pin hole. Many home, hotel, and hot spot devices use full‐cone NAT scheme.
When the endpoints signal each other, private IP information is sent to the STUN server during the SIP signaling set up (the
information is embedded in the SIP message). The STUN server gathers the information about the endpoints and sends the information back―information about what kind of NAT is being used and information about the pinhole. Through the STUN server,
26
the endpoints negotiate and find a common denominator so that the media transfer or call can be completed. If the endpoints find
that they are behind the same NAT or they find that at least one endpoint is behind full‐cone NAT, communication can begin. If both endpoints are behind symmetric NAT, or a symmetric firewall, they must use a TURN server to relay the information between them.
In some enterprises, all traffic must be routed through the HQ for security reasons―this means that if a telecommuter wants to connect to a branch, traffic must go to the HQ first, and then from there to the branch. This is a very secure solution, but is
inefficient traffic engineering. Expensive WAN bandwidth may be wasted on unimportant calls or media transfers that must be routed through the HQ.
The Juniper network management solution allows the HQ security policies to be propagated to multiple devices at the branches instead of having all security on one device in the HQ. With security policing at the branches, you can offload some of the Internet
traffic to the branches and allow direct branch‐to‐branch communication while continuing to maintain security.
To provide these mesh qualities for telecommuters and allow direct branch‐to‐branch communication, you have two options. With
the first option, you can create split‐tunnel Internet traffic for external communication and allow full‐cone NAT for all of the branches. This provides excellent QoS but is not the most secure option. A second option is to allow split‐tunnel Internet traffic (one
tunnel to the HQ and one for Internet access) and keep using symmetric NAT for the branches, with full‐cone NAT for telecommuters (most residential NAT devices are full‐cone NAT). This option works well if you have a large number of telecommuters and less
branch‐to‐branch traffic.
SIP Trunking Topologies SIP trunking services are emerging as an alternative to legacy systems, providing flexibility and many feature and cost advantages.
While designing an architecture for a single site with SIP trunking to the carrier is relatively simple, a multi‐site architecture is much more complex. Many currently used topologies are based on routing through the HQ to the carrier. This uses more bandwidth, costs
more, and reduces QoS.
Juniper has created a scalable method to utilize SIP trunking directly from the branch using STEP, a function embedded within MGW
in the branch SRX. SIP trunking from the branch reduces the number of FXOs (ports used by analog phone lines) and primary rate ISDN (PRI) lines, and works in most disaster scenarios because it uses the SIP carrier’s local point of reference.
Figure 9 shows fully distributed SIP trunking, with SIP and media trunking to the carrier running directly from the branch, TDM/analog backup, and multiple SIP trunks for redundancy. STEP validates and polices every call, and negotiates so that calls get a
guaranteed portion of high‐priority bandwidth with no inter‐call QoS impact. The MGW integration adds the failover and slipover mechanisms to ensure a predictable, high QoE for the user.
27
Figure 9. Distributed SIP Trunking with STEP.
Another alternative is useful with large deployments built on regional hub‐and‐spoke topologies, reducing the number of trunks negotiated with the carrier. STEP is used to control media up to regional hubs, assuring quality delivery, and IMSG controls the
connection to the carrier.
Figure 10 shows a regional SIP trunking model in which STEP provides traffic control for the branch edge WAN connections and regional SBCs aggregate multiple branches (multiple trunks), carrying traffic over to SIP trunk providers. The SBC services are
provided by Juniper’s IMSG package implemented over M/MX routers. STEP in the branch replaces the need for additional branch‐level SBC functionality. IPS implemented in the branch SRX gateway is identical to IPS in the M/MX routers. Media can be routing
through regional SBCs, OR routed directly to carrier POP, with signaling aggregated through regional SBCs.
You can also use IMSG for aggregating SIP trunks, with the media still flowing directly from the branch to the carrier’s closest PSTN
termination point, which leverages the best of both solutions.
28
Figure 10. Regional SIP Trunking with STEP and IMSG.
29
Step 2: Design the QoS Configuration To truly assure application connectivity with a good user experience over large networks, QoS is a key requirement. You will need to calculate the number and define the types of queues your implementation will use, and you will need to determine how much
bandwidth to assign to each queue.
Defining a QoS strategy requires mainly two elements:
• Classifying the network and application traffic according to levels of sensitivity and criticality For example, a business application that manages purchase orders needs to deliver better performance to users than
simple Internet access. VoIP traffic is another example, as it needs higher priority than business applications because it has less tolerance for delay, jitter, and packet loss.
• Enforcing the strategy at the network choke points The reason that choke points like routers and firewalls are specifically called out is that typically LANs do not suffer from
congestion. It is mainly when the LAN is connected to the WAN that prioritization is necessary. To enforce a successful QoS strategy, enterprises should try to limit policing to only critical elements and choose suitable systems for classification and
for policing. For example, in the medium‐to‐large branch offices, the local switch does the classification and the services gateway or secure router does the enforcement. To achieve this strategy, the branch office network equipment should be
able to carry QoS marking through the VPN tunnels and apply the policy across the entire deployment.
Figure 11 shows the recommended threshold for delivering high‐quality IP voice communications.
Figure 11. VoIP requirements.
30
Packet Flow in a QoS‐Enabled Router Understanding how QoS works in an appliance can help when planning your OCS 2007 R2 deployment. Modular software
architectures are key in the sorting and scheduling of traffic, ensuring that the most important applications take priority with networking resources. Figure 12 shows the general flow of a packet as it passes through class of service (CoS) in a QoS‐implemented
router.
Figure 12. QoS processing model.
The ingress and egress process, as illustrated in the figure, includes the following: • Behavior aggregate (BA) classifier
Classifies traffic based on marked CoS (IP precedence, DSCP, IEEE‐802.1, or MPLS EXP) and assigns the packet to a forwarding class. Usually implemented at the core router/switches.
• Multi‐field classifier Classifies traffic based on multiple fields in a packet’s header (Layer 2 or Layer 3) and assigns the packet to a forwarding
class.
• Policer
Enforces traffic flow on ingress or egress. The policer can drop or re‐mark packets.
• Queuing and Shaping
Manages all attributes of queuing, such as transmission rate, buffer depth, priority, and Random Early Detection (RED) profile.
• Packet dropping
Manages the drop profile to avoid TCP synchronization and protect high‐priority traffic from being dropped.
• Rewrite marker
Rewrites CoS fields (IP precedence, DSP, IEEE‐802.1, or MPLS EXP) with a new value.
31
Juniper QoS Recommendations Juniper recommends using JUNOS QoS to implement classification as close to the OCS implementation as possible. For certain VoIP
phones, especially with LLDP‐MED‐enabled phones, CoS is already marked with the correct value and the BA can be used to classify and set traffic to the correct forwarding class. However, in the case of other IP phones, multi‐field classifier can be used. Multi‐field
classifier is configured in the firewall and has more options to classify traffic.
EX Series Ethernet Switches offer eight egress queues per port and up to 16 supporting forwarding classes. Juniper recommends
configuring the following forwarding classes:
• Network control
• Voice
• Video
• Business applications
• Best‐effort
These forwarding classes should be mapped to queues 7, 5, 4, 2 and 0, respectively. Queues can be allocated and configured for either strict priority or shaped deficit weighted round‐robin (SDWRR). Figure 13 shows the EX Series CoS model for classification,
queuing, and scheduling.
Figure 13. EX Series CoS model for classification, queuing, and scheduling.
32
Forwarding class is assigned with packet loss priority (PLP) and DiffServ code points, which are used for queuing and BA in the core router. For the following UC applications, Juniper recommends the following classifiers and PLP (also known as drop precedence).
Packet loss priority sets the packet drop precedence value (low or high) to help prevent queue congestion. Packets with a low PLP have higher buffer thresholds than packets with a high PLP. By default, the high threshold is 100 percent of the buffer. Table 2 shows
the recommendation for DiffServ and PLP for voice, video, and other network traffic.
Table 2. DiffServ Recommendations.
Applications DiffServ PLP
Network Control CS6 Low
Voice EF Low
Video
CS4 AF41 AF42 AF43
Low
High
Bandwidth Application
AF21 AF22 AF23
Low High
Best Effort Remaining Code
Points Low
33
Step 3: Analyze Delay and Jitter Next, you need to analyze delay and jitter in your planned implementation, and verify that the expected delays for your implementation are acceptable.
Delay Considerations Unlike many data applications, voice cannot tolerate high levels of latency or delay. Toll‐quality voice requires that sounds travel from the speaker’s lips to the receiver’s ear in 100 ms or less. Delays exceeding 150 ms can start to irritate callers and cause
conversation overrun. When delays approach 500 ms, voice communication becomes impossible without reverting to the half‐duplex practice of saying “over” to signal the end of a transmission.
In addition to the latency physically present on the WAN link, there are many sources of delay including codec processing, queuing, serialization, propagation and jitter buffer delay. As an example, Figure 14 shows an end‐to‐end delay from campus to branch office,
illustrating some of the sources that cause delay.
Figure 14. End‐to‐end delay.
34
Table 3 lists and defines the different types of delays.
Table 3. Types of Delays and Definitions.
Types of Delays Definition
Encoding Delay Related to collecting analog voice samples and algorithmic calculations of the codec (Coder‐Decoder) to digitize analog voice samples. Different codecs will have different encoding delays. For RTAudio at 16 KHz or 8 KHz, the total one‐way codec delay is less than 25 ms. G.711 µ‐law has approximately a 1 ms delay.
LAN Serialization and Queuing Delay Related to putting a voice or data frame onto the LAN network interface (queuing delay is configured for the LAN). This delay is related to the clock rate on the LAN interface and is generally negligible.
IPsec Encryption Delay Related to processing delay in encryption voice packets. This delay is related to the type of encryption mechanism used and depends on the use of software or hardware encryption.
WAN Serialization Delay Related to putting voice or data frame onto the WAN network interface. This delay is related to the clock rate on the WAN interface.
WAN Queuing Delay Related to queue size that is reserved for queuing voice packets. The WAN is usually oversubscribed and queuing occurs often. In addition, a speed mismatch between the LAN and the WAN also causes congestion (and therefore queuing).
Propagation and Network Delay Related to the time it takes to travel from point A to point B in the network. In addition, network switching delay occurs between and within carriers. The general rule of thumb indicates about 1 ms delay for every 100 miles traveled.
Jitter Buffer Delay Related to de‐jitter buffer delay, which is used to smooth out jitter in voice. Jitter buffer delay is variable and ranges from 20 to 50 ms.
Additional Packet Inspection Delay IDP or some voice inspection techniques add delay since they inspect voice packets before passing them on.
Jitter Considerations Jitter, defined as the statistical variance of the RTP data packet inter‐arrival time, is a common problem with connectionless
networks or packet networks. The recommendation is less than 20 ms of jitter to maintain high‐quality voice. Note that with RTAudio, jitter is measured in timestamp units; for example, if you transmit audio sampled at the usual 8000 Hz, the timestamp unit
is 1/8000 of a second.
The receiver needs to compensate for variable packet arrival by using a jitter buffer, which holds packets and plays them out at a
constant rate. The recommendation is to use less than 100 ms of buffer because the buffer can increase the overall delay of one‐way audio, impacting voice quality.
35
Encoding Delay Every speech codec introduces a delay in the transmission. This latency varies with the codec used. For RTAudio wide band and narrow band, the delay (in ms) is shown in Table 4.
Table 4. Latency for RTAudio.
Latency in [ms]
RTAudio WB RTAudio NB G.711
Encoder Latency 13 10 0
ARM (TJ) 7 3 0 Encoder Complexity
PC (1GHz) 2 1 0
Latency in [ms]
RTAudio WB RTAudio NB G.711
Decoder Latency 3 0 0
ARM (TJ) 1 0 0 Decoder Complexity
PC (1GHz) 0.3 0 0
Audio Bandwidth Considerations
An uncompressed voice call across a traditional analog network requires only 64 Kbps of bandwidth, and about 60 percent of that
bandwidth is wasted on silence. On IP networks, the voice sample packets include a header that adds bandwidth. The sample rate requires different amounts of bandwidth for different codecs.
Microsoft OCS uses RTAudio, an adaptive wide‐band speech codec designed for two‐way VoIP applications as well as games, audio conferencing, and wireless applications. Because RTAudio is a variable‐rate codec, it can adjust the data rate based on the underlying network conditions. With variable‐rate codecs, more bandwidth is used to achieve better quality. In conditions of network congestion, the codec may throttle back the sending rate to use less bandwidth. Bandwidth usage for RTAudio varies
from 45 to 74 Kbps.
The RTAudio encoder is capable of encoding single‐channel (mono), 16‐bit per sample audio signals. The encoder can be configured
to operate either in the narrow band mode (8 KHz sampling rate) or the wide band mode (16 KHz sampling rate). The RTAudio decoder has a built‐in jitter‐control module as well as an error concealment module. Table 5 summarizes information about
RTAudio, and shows other codec information for comparison. (Note that the sample interval is the sample interval at which the codec operates, or the duration of a signal frame that is processed and converted to a packet payload.)
36
Table 5. RTAudio Information.
* This is on a wideband MOS scale
Table 6 provides capacity planning information.
Table 6. Audio Capacity Planning.
Media Codec Average Bandwidth
(Kbps) Estimated Activity
(%) Maximum
Bandwidth (Kbps)
Wide Band Audio RTAudio 34.8 61 57
Wide Band Audio Siren 22.2 43 51.6
Narrow Band Audio RTAudio 25.9 65 39.8
Note that for the values in the tables:
• Bandwidth numbers quoted for media streams include all overhead for framing, encryption, and IP routing information in addition to actual encoded media.
• Average codec bandwidth values are based on measurements and derived from the maximum theoretical bandwidth based on typical activity level values. Audio activity levels take voice activity in the stream into account.
• Activity levels for RTAudio narrow band are slightly higher to allow for less optimal voice activity detection in PSTN Gateways for OCS VoIP‐to‐PSTN calls. This number should be increased by another 15 percent if no voice activity detection
is enabled on the deployed PSTN Gateway.
Codec and Bit Rate (Kbps) Codec Sample Size (Bytes)
Codec Sample Interval (ms)
Mean Opinion Score (MOS)
RTAudio Narrow Band (28 Kbps)
40 Bytes 20 ms 3.9
RTAudio Wide Band (45 Kbps)
75 Bytes 20 ms 4.1*
G.711 (64 Kbps) 80 Bytes 10 ms 4.3
G.729 (8 Kbps) 10 Bytes 10 ms 3.9
G.723.1 (6.3 Kbps) 24 Bytes 30 ms 3.9
G.723.1 (5.3 Kbps) 20 Bytes 30 ms 3.8
G.726 (32 Kbps) 20 Bytes 5 ms 3.9
G.726 (24 Kbps) 15 Bytes 5 ms 3.8
G.728 (16 Kbps) 10 Bytes 5 ms 3.6
37
Layer 2 Overhead
A more accurate method for provisioning VoIP considers the Layer 2 overhead, which includes preambles, headers, flags, CRCs, and ATM cell padding. The amount of overhead per VoIP call depends on the Layer 2 media used:
• 802.1Q Ethernet (or VLAN tagging) adds up to 38 bytes of Layer 2 overhead (when preambles are included).
• Point‐to‐Point Protocol (PPP) adds 12 bytes of Layer 2 overhead.
• Multilink PPP (MLP) adds 13 bytes of Layer 2 overhead.
• Frame Relay adds 4 bytes of Layer 2 overhead; Frame Relay with FRF.12 adds 8 bytes.
• ATM adds varying amounts of overhead, depending on the cell padding requirements. The example below shows padding of approximately 65 bytes for two cells.
Table 7 lists bandwidth‐provisioning guidelines for voice that include Layer 2 overhead. Table 8 lists bandwidth‐provisioning
guidelines for voice that include Layer 2 overhead and IPsec. Information for other codecs has been added for comparison.
Table 7. Voice Bandwidth with Layer 2 Header.
Bandwidth Consumption
802.1Q Ethernet (LAN Switch)
802.3 Trunk with VLAN Tagging
PPP MLP Frame Relay with FRF.12
RTAudio Narrow Band
59 Kbps 61 Kbps 60 Kbps 60 Kbps 43 Kbps
RTAudio Wide Band
76 Kbps 78 Kbps 77 Kbps 77 Kbps 64 Kbps
G.711 at 50 pps 95 Kbps 97 Kbps 96 Kbps 96 Kbps 83 Kbps
G.711 at 33 pps 63 Kbps 64 Kbps 63 Kbps 64 Kbps 55 Kbps
G.729A at 50 pps 39 Kbps 41 Kbps 40 Kbps 40 Kbps 27 Kbps
G.729A at 33 pps 26 Kbps 27 Kbps 26 Kbps 27 Kbps 20 Kbps
38
Table 8. Voice Bandwidth with Layer 2 Header and IPsec.
Bandwidth Consumption
802.1Q Ethernet (LAN Switch)
802.3 Trunk with VLAN Tagging
PPP MLP Frame Relay with FRF.12
RTAudio Narrow Band
70 Kbps 71 Kbps 59 Kbps 60 Kbps 62 Kbps
RTAudio Wide Band
90 Kbps 92 Kbps 80 Kbps 81 Kbps 79 Kbps
G.711 at 50 pps 109 Kbps 111 Kbps 99 Kbps 100 Kbps 98 Kbps
G.711 at 33 pps 72 Kbps 73 Kbps 65 Kbps 66 Kbps 64 Kbps
G.729A at 50 pps 54 Kbps 55 Kbps 43 Kbps 44 Kbps 42 Kbps
G.729A at 33 pps 35 Kbps 36 Kbps 29 Kbps 30 Kbps 27 Kbps
Video Bandwidth Considerations Many video codecs can be used to process video signals and transmit them over IP networks. In order for different video products to work with each other, many video codecs use common, standard video compression formats.
RTVideo is Microsoft's default video codec for OCS 2007 R2 and the Microsoft Office Communicator 2007 client. It is a Microsoft proprietary implementation of the VC‐1 codec for real‐time transmission. Microsoft extensions to VC‐1 are based on cached frame
and SP‐frame. RTVideo also includes system‐level enhancements for recovery of packet loss on IP networks and forward error correction (FEC). (See Table 9.)
Table 9. Video capacity values.
Resolution Framerate W13 W12
CIF 15 250 Kbps 350 Kbps
VGA 24 600 Kbps ‐
HD 24 1.5 Mbps ‐
Pano 15 350 Kbps 350 Kbps
39
Audio and Video Recommendations Microsoft recommends provisioning your network links to support throughput of 45 Kbps per audio stream and 300 Kbps per video stream during peak usage periods. Note that a bi‐directional audio or video session consists of two streams.
To cope with unexpected spikes in traffic above the recommended level and increased usage over time, OCS media endpoints can adapt to varying network conditions and support loads of three times the throughput for audio and video while still retaining
acceptable quality. However, do not assume that this adaptability will support an under‐provisioned network because this will reduce the ability of the OCS media endpoints to dynamically deal with varying network conditions, such as temporary high packet
loss.
For network links where provisioning is extremely costly and difficult, you may have to consider provisioning for a lower volume of
traffic and letting the elasticity of the OCS media endpoints absorb the difference between that traffic volume and the peak traffic level, at the cost of some reduction in the voice quality, but also of a decrease in the headroom otherwise available to absorb
sudden peaks in traffic.
Note that you should provision your network to ensure a maximum end‐to‐end delay of 150 ms under peak load. Delay is the one
network impairment that OCS media components cannot reduce, and it is important to find and eliminate the weak points.
40
Sample Deployment of Microsoft OCS 2007 R2 within the Juniper Distributed Enterprise While a UC deployment including OCS 2007 improves business communications and enhances productivity, it can overwhelm networks, affect applications, and require new policies and planning. The key to successfully implementing an OCS‐based solution in
a Juniper Distributed Enterprise is to recognize the challenges early on and anticipate the types of pitfalls that might lie ahead. With proper planning, many of these pitfalls can be avoided.
Figure 15 shows Microsoft OCS 2007 R2 in a distributed enterprise network consisting of a data center, a campus or headquarters, a
branch office, a remote user, and a SOHO office. OCS 2007 R2 is deployed centrally, with call servers and unified messaging (UM) servers located in a data center. Major VoIP devices typically reside in a campus and/or headquarters with high bandwidth
connections to the data center through a core connection or a private WAN. The branch office is connected to the core using a private WAN or Internet. The majority of remote users connect to the data center through the Internet.
Each part of the distributed enterprise has a different topology with different WAN interfaces that require conscientious planning to support the number and types of different users while still ensuring high quality service. The “spokes” of the distributed enterprise—
the branch offices, SOHOs, and remote users—also need to be able to connect to each other directly in a “mesh” network. This minimizes the number of hops required, and optimizes bandwidth use.
The following sections show the numbers of users and the expected delay, and the requirements and delays for each part of the Juniper Distributed Enterprise network. (Note that all calculations take into account Layer 2 headers for different WAN interfaces.)
Figure 15. Juniper Networks product portfolio for the distributed enterprise.
41
In the distributed enterprise, communication can flow between the branch and the campus/headquarters, between branches, and
from a branch to a service provider through SIP trunking, a service offered by an Internet Telephony Service Provider (ITSP). This service permits businesses that have a PBX installed to use VoIP also outside the enterprise network by using the same connection
as the Internet connection.
The ability to connect to SIP trunks directly from the branch is natively integrated into the SRX Series’ SIP MGW with its SIP trunk
edge point. Its SIP trunk IP‐IP media gateway enables a highly secure and robust SIP trunk connection point to create the most reliable SIP‐based solution, with optimized QoS and traffic engineering, running the shortest path from the branch to the carrier
point of presence (POP).
Unlike traditional SIP architectures where traffic is backhauled to headquarters, the local SIP trunk serves as a natural circuit switch
trunk replacement (available in most survivability conditions), thereby allowing elimination of TDM/analog lines. This approach brings tremendous cost savings with dynamic pricing schemes available from SIP trunking carriers. Once a SIP trunk has been
configured in the system, it can be used seamlessly in conjunction with or instead of any other TDM trunk based on the dial plan.
The end‐to‐end delays for the entire distributed enterprise are shown for several scenarios: best case (where there is no congestion
at either endpoint), worst case, and branch‐to‐branch, when a call does not go through the headquarters.
Small Office/Home Office The small office/home office (SOHO) profile typically consists of a single integrated security and routing device to address a relatively
small number of devices that are connected. WAN connectivity to the data center is implemented with single or dual WAN connections including third‐generation (3G) wireless. The SOHO typically supports a full set of security/VPN features with standard
LAN/WAN connectivity support. The SOHO profile consists of a single‐box infrastructure to provide employee access. Most micro or small branch offices use the switching capabilities of the integrated security and routing device, also known as service gateway
equipment.
Figure 16 shows a typical SOHO architecture. It consists of a branch SRX Series Services Gateway, and has an external connection
leading to the managed services connection provided by service providers or the Internet.
Figure 16. SOHO reference architecture.
The SOHO configuration uses the branch SRX Series as the branch security/routing/switching device. The branch SRX Series offers
higher levels of protection since it provides additional security functions—for example, integrated unified threat management (UTM) capabilities for firewalls, such as antivirus, anti‐spam, Web filtering, and intrusion detection and prevention (IDP).
42
LAN connectivity in the SOHO is provided through the integrated switching function on SRX Series Services Gateways for the branch.
These services gateway devices offer complete cost‐efficient Layer 2 and Layer 3 switching capabilities, 10/100/1000BASE‐T copper port connectivity with either full or partial PoE, and the comprehensive JUNOS routing feature set.
Typically, device or link redundancy is not required for the SOHO, while a backup 3G wireless or commodity Internet connectivity can easily be implemented on the branch SRX Series, if desired. The SOHO can have a maximum of five users. Table 9 shows that the
maximum numbers of concurrent calls that can be supported for 100 percent T1 bandwidth (with the RTAudio codec) is 39. If 15 percent of the bandwidth is reserved for voice, then five concurrent voice calls are supported.
Table 9. WAN Bandwidth Sample Planning for SOHO with T1 Interface.
Description Value
WAN bandwidth 1.544 Mbps
WAN encapsulation Frame Relay + IPsec
Codec RTAudio
Max calls supported on WAN (100 percent voice) 39 calls
Max calls supported on WAN (15 percent voice) 5 calls
The main delay comes from the WAN side of the SRX because IP Phones connect directly to switch ports on the SRX router. Table 10
lists the delays.
Table 10. SRX Delays for SOHO.
Description Delay (ms)
Encoding delay for RTAudio 20 ms
WAN SRX delay, serialization .5 ms
WAN SRX delay, queuing for 5 concurrent calls with T1 link 10.1 ms
IPsec encryption delay Approx. 1 ms
Total worst case delay (encoding + WAN) 32 ms
Total best case delay with no queuing 22 ms
43
Remote Offices The remote office branch configuration adds a few more resources to the SOHO profile. These include high availability and an additional security zone that is used for guest access. It includes two security devices, with one device connecting to a private link
(L2VPN) and the other connecting to the Internet. Device redundancy is achieved through the use of bridge groups with floating default routes. LAN redundancy is implemented with a Juniper Networks EX2200 Ethernet Switch or Juniper Networks EX3200
Ethernet Switch connected to the edge devices in full mesh to provide high availability.
Figure 17 shows a typical architecture for a remote office.
Figure 17. Remote office reference architecture.
The remote office profile configured with SRX Series and EX Series devices provides the same UTM features, firewall, antivirus, Web filtering, and IDP as the SOHO profile. In the Remote Office profile, wide area communications are accomplished with either T1/E1 or
broadband connectivity for high‐speed performance, with the security of link‐level redundancy to ensure edge reliability using a high availability configuration.
LAN connectivity in the Remote Office profile is implemented with a single fixed configuration EX2200 or EX3200 Ethernet switch. These devices offer complete cost efficient Layer 2 and Layer 3 switching capabilities, 10/100/1000BASE‐T copper port connectivity
with either full or partial PoE, and the full JUNOS feature set. The remote office can have a maximum of 50 users.
Table 11 shows that the maximum numbers of concurrent calls that can be supported for 100 percent T1 bandwidth (with the
RTAudio codec) is 39. If 33 percent of the bandwidth is reserved for voice, then 13 concurrent voice calls are supported.
44
Table 11. WAN Bandwidth Sample Planning for Remote Office with T1 Interface.
Description Value
WAN bandwidth 1.544 Mbps
WAN encapsulation Frame Relay + IPsec
Codec RTAudio
Max calls supported on WAN (100 percent voice) 39 calls
Max calls supported on WAN (33 percent voice) 13 calls
The EX Series access switch and the WAN SRX router generate delay. Table 12 lists the delays.
Table 12. EX and SRX Delay for a Remote Office.
Description Delay (ms)
Encoding delay for RTAudio 20 ms
EX LAN serialization + queuing delay Approx. 0.5 ms
WAN SRX delay, serialization 0.5 ms
WAN SRX delay, queuing for 13 concurrent calls with T1 link
14.2 ms
IPsec encryption delay Approx. 1 ms
Total worst case delay (LAN + WAN) 36.2 ms
Total best case delay with no queuing 22 ms
45
Medium‐to‐Large Branch Offices A branch location is defined as any strategic location that is logically and/or geographically separate from campus or headquarters facilities. Today, branch locations significantly contribute to the bottom line and are central to many organizations’ success. Figure
18 shows a typical architecture for a medium‐to‐large branch office. This branch profile consists of two services gateways and up to ten Ethernet switches in a Virtual Chassis configuration, interconnected to form an active/active redundant topology. WAN
connections to the data centers can use both Internet and private WAN connectivity.
Figure 18. Typical architecture for a medium‐to‐large branch office.
Because the key requirements of this type of branch office are high availability, high speed/high performance, services‐ready, VoIP,
and WAN optimization, Juniper recommends using: • A pair of standard Juniper Networks J Series Services Routers
• A pair of SRX Series gateways deployed in a high availability configuration
• A single EX Series Virtual Chassis Ethernet switch connected to the gateways in a full mesh configuration
These switches offer complete cost‐efficient Layer 2 and Layer 3 switching capabilities, 10/100/1000BASE‐T copper/fiber port connectivity (24‐ or 48‐port) with either full or partial PoE, along with redundant fans and power supplies.
The alternate configuration for this profile replaces the SRX Series with the J Series routers configured for high availability. The same segmentation and zones are also used in this configuration as those for the SRX Series device. The medium‐to‐large branch offices
can have a maximum of 1000 users.
Table 13 shows that the maximum numbers of concurrent calls that can be supported for 100 percent T1 bandwidth (with the RTAudio codec) is 312. If 33 percent of the bandwidth is reserved for voice, then 104 concurrent voice calls are supported.
46
Table 13. WAN Bandwidth Sample Planning for a Medium‐to‐Large Branch Offices.
Description Value
WAN bandwidth (4 x T1) 4 x 1.544 Mbps
WAN encapsulation Frame Relay + IPsec
Codec RTAudio
Max calls supported on WAN (100 percent voice) 312 calls
Max calls supported on WAN (33 percent voice) 104 calls
In addition, there is a connection to the private WAN that can have 100 Mb WAN interfaces. Table 14 shows that the maximum number of concurrent calls that can be supported for 100 percent private WAN Fast Ethernet is 2202. If 33 percent of the bandwidth
is reserved for voice, then 726 concurrent voice calls are supported.
Table 14. WAN Bandwidth Sample Planning for a Medium‐to‐Large Branch Office with a Private WAN.
Description Value
WAN bandwidth (2 x Fast Ethernet) 2 x 100 Mbps
WAN encapsulation IPsec or MPLS
Codec RTAudio
Max calls supported on WAN (100 percent voice) 2202 calls
Max calls supported on WAN (33 percent voice) 726 calls
The EX Series and the WAN SRX router generate delay. Table 15 lists the delays.
47
Table 15. EX and SRX Delay for a Medium‐to‐Large Branch Office.
Description Delay (ms)
Encoding delay for RTAudio 20 ms
EX LAN serialization + queuing delay Approx. .5 ms
WAN SRX delay, serialization .5 ms
WAN SRX delay, queuing for 104 concurrent calls with T1 link
61 ms
WAN SRX delay, queuing for 104 concurrent calls with 4 x T1 link
15.3 ms (61 ms divided by 4)
IPsec encryption delay Approx. 1 ms
Total worst case delay (LAN + WAN) 37.3 ms
Total best case delay with no queuing 22 ms
Campus/Headquarters The term campus refers to a main enterprise location consisting of one or more buildings in close proximity to one another at the same locale. A campus is typically the corporate headquarters or a major site. Examples include a multi‐floored office building
housing an enterprise, a corporation with several buildings in an office park complex, and the sprawling facilities that constitute a university. All buildings and floors are connected to shared resources and services in a data center, which may or may not be part of
the campus, via a campus LAN or WAN connection. The campus/headquarters is where the majority of users access the network.
48
Figure 19 shows a typical architecture for a campus or headquarters.
Figure 19. Campus/headquarters reference architecture.
LAN Considerations
An enterprise campus LAN architecture may span up to three functional layers, from desktop devices connected to wiring closet
switches at the access layer, to the core layer at the center of a large campus LAN. The hierarchical topology segments the network into physical building blocks, which simplifies operation and increases availability. Each layer within the hierarchical infrastructure
has a specific role. • The access layer provides an access control boundary and delivers network connectivity to end devices (client machines,
printers, IP telephony, and cameras) in a campus.
• The aggregation layer aggregates connections and traffic flows from multiple access‐layer switches, providing a core
enforcement perimeter as it delivers traffic to core‐layer switches.
• The core layer provides secure connectivity between aggregation‐layer switches and the routers connecting to the WAN
and the Internet, which enable business‐to‐business collaboration.
WAN Considerations
A WAN edge routing platform must offer sufficient high‐speed Ethernet ports to provide connectivity between the WAN and core or
aggregation layer. It also must provide high‐performance throughput to the Internet and WAN.
All WAN edge devices must provide a full complement of high availability services to maintain critical WAN connectivity. The
hardware must be robust and offer redundant power supplies and cooling fans. Devices should be paired in active/active routing states for optimal high availability using dynamic routing protocols with minimal convergence times. Also, an alternate connection to
the Internet or WAN must be maintained.
Secure and optimized voice services should be provided at the WAN edge to enable effective communications across the LAN and
WAN. Either an integrated or standalone VoIP gateway may be implemented.
49
Note that adding more bandwidth does not automatically deliver LAN‐like performance across the WAN. Acceleration services are
needed to optimize performance of centralized applications across the WAN at all times, even when bandwidth is constrained.
WAN optimization products seek to accelerate a broad range of applications accessed by distributed enterprise users through
eliminating redundant transmissions, staging data in local caches, compressing and prioritizing data, and streamlining chatty protocols like the Common Internet File System (CIFS).
The campus network allows a maximum of 5000 users. The general WAN bandwidth of a typical campus/headquarters includes at least 8xDS3 and 4x100Mbits interfaces.
Campus/Headquarters Planning
Table 16 shows that the maximum numbers of concurrent calls that can be supported for 100 percent T1 bandwidth (with the
RTAudio codec) is 3965. If 33 percent of the bandwidth is reserved for voice, then 1309 concurrent voice calls are supported.
Table 16. WAN Bandwidth Sample Planning for Campus/Headquarters with 8xDS3 Interface.
Description Value
WAN bandwidth (8 x DS3) 8 x 45 Mbps
WAN encapsulation IPsec
Codec RTAudio
Max calls supported on WAN (100 percent voice) 3965 calls
Max calls supported on WAN (33 percent voice) 1309 calls
In addition, there is a connection to the private WAN that can have 100 Mb WAN interfaces. Table 18 shows that the maximum numbers of concurrent calls that can be supported for 100 percent private WAN Fast Ethernet is 4406. If 33 percent of the
bandwidth is reserved for voice, then 1454 concurrent voice calls are supported.
Table 17. WAN Bandwidth Sample Planning for Campus/Headquarters with Private WAN Interface.
Description Value
WAN bandwidth (4 x Fast Ethernet) 4x 100 Mbps
WAN encapsulation IPsec or MPLS
Codec RTAudio
Max calls supported on WAN (100 percent voice) 4406 calls
Max calls supported on WAN (33 percent voice) 1454 calls
50
Table 18. EX and SRX Delay for Campus/Headquarters.
Description Delay (ms)
Encoding delay for RTAudio 20 ms
EX 4200 to EX8200, LAN serialization + G.711 Approx. 1.5 ms
EX8200 to SRX5600, LAN queuing for 1309 calls with 100 Mb link
20.1 ms (maximum)
SRX5600 to WAN edge (M/MX series), LAN queuing for 1309 calls
20.1 ms (maximum)
WAN serialization 1 ms
WAN SRX delay, queuing for 1309 concurrent calls with 1‐DS3 link
44.6 ms (maximum)
WAN SRX delay, queuing for 1309 concurrent calls with 8‐ DS3 links
5.6 ms (44.6 ms divided by 8)
IPsec encryption delay Approx. 1 ms
Total worst case delay (LAN + WAN) 48.3 ms
Total best case delay with no queuing 4.5 ms (G.711)
Data Center The data center stores the majority of servers and call controllers. Aggregated WAN/LAN links from the campus/headquarters and
from the branches are terminated at the data center. Proper planning is required to ensure that traffic is not congested and that it is classified and serviced correctly.
The internal data center comprises one or more server network(s) or data center LANs. The data center LAN hosts a large population of servers that require high‐speed and highly available network connectivity. In addition, there can be multiple LAN segments and
networks deployed that differ in security and capacity levels and other services offered. Typically, connections of 1 Gbps and higher (while 10 Gbps are becoming the standard) will be available in the data center network, providing at least 1 Gbps to the server and
preferably 10 Gbps at network choke points.
Data center connectivity requires a minimum of 10 Gbps WAN interfaces. Juniper recommends 40 Gbps interfaces (and will soon
recommend 100 Gbps Ethernet interfaces).
51
Figure 20 shows a typical architecture for a data center.
Figure 20. Data center reference architecture.
52
Table 19 shows the number of branches and headquarters that can be aggregated to a Juniper Networks data center with the different WAN bandwidth interfaces.
Table 19. Branches and Campus/Headquarters Supported per Data Center with Different WAN Bandwidths.
Location Mbps Support for 10 Gbps WAN Interfaces Data Center
Support for 40 Gbps WAN Interfaces Data Center
SOHO with T1 interfaces 1.544 1000 sites
5000 users
5000
50,000 users
Remote office with T1 interfaces 1.544 1000 sites
50,000 users
1000
50,000 users
Medium branches with 4 x T1 interfaces 6.176 50 sites
10,000 users
500
100,000 users
Large branches with 2 x T1 and private WAN (2 x 100 Mbps)
203.088 10 sites
20,000 users
50
100,000 users
Campus/HQ with 4 x DS3 interfaces 180 5 sites
20,000 users
25
100,000 users
Campus/HQ with 8 x DS3 interfaces 360 5 sites
25,000 users
15
125,000 users
Total aggregated bandwidth (Gbps) 9.355
130,000 users
50 percent active at peak hour
Queuing delay worst: 25.78 ms
38.406
525,000 users
50 percent active at peak hour
Queuing delay worst: 26.03 ms
53
Analyzing End‐to‐End Delays When planning for delay, it is necessary to consider the entire path, from one end to other. Many factors must be taken into account from the branch to the termination point at the data center or with a SIP trunk provider. For example, Figure 21 shows an end‐to‐
end delay from campus to branch office and also illustrates several sources that cause delay.
Figure 21. End‐to‐end delay.
54
Figure 22 shows the reference architecture that was used to calculate the various delays in the different parts of a distributed
enterprise network.
For the calculations, the public WAN connection uses IPsec and the private WAN connection uses MPLS. All connections are
terminated in the data center. The campus/headquarters is not included for simplicity; it uses the same connection as the branch office, which connects to both the public WAN and the private WAN. If the campus/headquarters is co‐located with the data center,
they share the core layer connection and additional delay is minimal.
Figure 22. Delay reference architecture.
55
The following tables summarize the end‐to‐end delays under different sets of assumptions. Note that “WAN” indicates delay
introduced by WAN: a typical rule of thumb is 1 ms for every 100 miles. (NA indicates cases where there is no direct traffic possible due to the IPsec topology.)
Table 20 shows the various combinations of delay from the four different distributed enterprise network branches, assuming RTP flows directly between the sites and congestion occurs at both ends.
Table 20 Worst Delay from Different Distributed Enterprise Networks
Location Delay/Worst Delay (ms) SOHO
(32 ms)
Remote Office
(36 ms)
Medium/Large Branches
(37 ms)
Campus/HQ
(48 ms)
SOHO (32 ms) 64 + WAN* 68 + WAN* 69 + WAN* 80 + WAN
Remote office (36 ms) 68 + WAN* 72 + WAN* 73 + WAN* 84 + WAN
Medium/large branches (37 ms) 69+ WAN* 73 + WAN* 74 + WAN 85 + WAN
Campus/HQ (48 ms) 80 + WAN 84 + WAN 85 + WAN 96 + WAN
* Assumes direct IPsec connection site to site, or through group VPN.
Table 21 shows the end‐to‐end delays with direct RTP flow between branches when only one end is congested. Table 21 Worst/Best Delays from Different Branch Types
Location Delay Worst/Best Delay (ms)
SOHO
(22 ms)
Remote Office
(22 ms)
Medium/Large Branches
(22 ms)
Campus/HQ
(4.5 ms)
SOHO (32 ms) 54 + WAN* 54 + WAN* 54 + WAN* 36.5 + WAN
Remote office (36 ms) 58 + WAN* 58 + WAN* 58 + WAN* 40.5 + WAN
Medium/large branches (37 ms) 59 + WAN* 59 + WAN* 59 + WAN 41.5 + WAN
Campus/HQ (48 ms) 70 + WAN 70 + WAN 70 + WAN 52.5 + WAN
* Assumes direct IPsec connection site to site, or through group VPN.
56
Table 22 lists the delays when RTP flows through the data center and IP sec/ MPLS are terminated and rerouted to other sites. In this table, it is assumed that only one end is congested. Table 22 Delays if All Connections are Terminated and WAN Queuing at Datacenter.
Location Delay Worst/Best Delay (ms)
SOHO
(22 ms)
Remote Office
(22 ms)
Medium/Large Branches
(22 ms)
Campus/HQ
(4.5 ms)
SOHO (32 ms) 80 + 2xWAN 80 + 2xWAN 80 + 2xWAN 62.5 + WAN
Remote office (36 ms) 84 + 2xWAN 84 + 2xWAN 84 + 2xWAN 66.5 + WAN
Medium/large branches (37 ms) 85 + 2xWAN 85 + 2xWAN 85 + WAN 67.5 + WAN
Campus/HQ (48 ms) 96 + WAN 96 + WAN 96 + WAN 78.5 + WAN
Note, for reference, that some typical delays posted by carriers are in the range of: • 30‐50 ms within the US or within Europe
• Up to around 100 ms across the Atlantic as well as within APAC. • Up to 150 ms across the Pacific.
• Higher than 150 ms in specific routes (up to 300 ms in some cases)
Summary Microsoft OCS 2007 R2 can be used in a Juniper Networks Distributed Enterprise, providing software‐powered communications that
is streamlined, interconnected, and extensible. This planning guide discusses the QoS and connectivity considerations that are important when implementing Microsoft OCS 2007 R2 in a distributed enterprise that includes SOHOs, remote offices, medium‐to‐
large branch offices, campus/headquarters, and a data center.
The guide helps network architects determine bandwidth requirements and delays for the number and types of interfaces they plan
to use when following the three basic design steps: 1. Design the network architecture.
You need to engineer your network topology to optimize the media path. Select the most appropriate high‐level topology—mesh or hub‐and‐spoke—so that you have as much direct traffic as possible to minimize delay.
2. Design the QoS configuration. You need to plan the forwarding queues. Calculate the number and define the types of queues your implementation will
use, and determine how much bandwidth to assign to each queue.
3. Analyze delay and jitter.
You need to verify that the expected delays for your implementation are acceptable. If the expected delays are not acceptable, review your topology choice and queuing policy again, and modify accordingly.
57
Links for Further Information The following links provide information about Microsoft OCS.
• Office Communications Server 2007 R2 Technical Reference Guide provides detailed technical reference information for administrators who are deploying, have deployed, or are administering Microsoft OCS 2007 R2.
• Office Communications Server 2007 R2 Technical Overview provides a technical overview of many OCS features, with an emphasis on features introduced in Microsoft OCS 2007 R2.
• The Microsoft TechNet portal for Office Communications Server includes a wealth of resources for OCS, as well as technical forums where you can ask specific questions.
• The capacity planning requirements for OCS 2007 R2 are described in the TechNet article Capacity Planning.
• For more information about RTAudio, see the Overview of the Microsoft RTAudio Speech Codec.
• For the internal hardware and software requirements for OCS 2007 R2, see Internal Office Communications Server Component Requirements.
• For a PDF of a PowerPoint deck, see Architecture, Implementing, and Migrating to Office Communications Server 2007 R2.
• For a map of available documentation for Microsoft OCS 2007 R2, see the Microsoft Office Communications Server 2007 R2 Documentation Roadmap.
• For a discussion of QoE in Microsoft implementations, see Quality of Experience: A strategic competitive advantage of Microsoft Unified Communications.
The following links provide information about Juniper Networks.
• For information about the Juniper Distributed Enterprise, see The New Network Has Distributed Enterprise Solutions.
• For the press release, see Juniper Networks Introduces Distributed Enterprise Solutions with New SRX Services Gateways and EX Series Ethernet Switches.
• For a solution brochure, see Distributed Enterprise Solutions. Also see Distributed Enterprise Solutions for the Branch and Distributed Enterprise Solutions for the Campus.
• For a discussion of Juniper Networks’ approach to the branch offices, see Branch Office Reference Architecture.
• For a discussion of Juniper Networks’ approach to the campus, see Campus Networks Reference Architecture. See also the Campus LAN Reference Architecture.
• For a discussion of Juniper Networks’ approach to the data center, see Enterprise Data Center Network Reference Architecture.
• For a solution brief about Juniper Networks and Microsoft UC, see Juniper Networks Solution for Microsoft Unified Communications.
• For a brochure about JUNOS, see Juniper Networks JUNOS Software.
• For a Microsoft and Juniper Networks solution brief, see Juniper Networks and Microsoft Enable High‐Performance Businesses Through the Intelligent Coupling of Networking and Software.
58
About Juniper Networks Juniper Networks, Inc. is the leader in high‐performance networking. Juniper offers a high‐performance network infrastructure that
creates a responsive and trusted environment for accelerating the deployment of services and applications over a single network. This fuels high‐performance businesses. Additional information can be found at www.juniper.net.
Copyright ©2010 Juniper Networks, Inc. All rights reserved. Juniper Networks and the Juniper Networks logo are registered trademarks of Juniper Networks, Inc. in the United States and other countries. JUNOS 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.
59
Appendix: Public and Private WAN Latency
This section provides public data from a variety of Internet/WAN providers as to typical latency over long‐haul WAN networks.
AT&T http://ipnetwork.bgtmo.ip.att.net/pws/network_delay.html
Sampling of latency figures ‐ June 25, 2010. Note that these figures frequently change.
60
Verizon Business
Private IP Service (MPLS) http://www.verizonbusiness.com/about/network/latency/#pip
Internet Service Verizon Business Service Level Agreements (SLAs) guarantee
Monthly latency figures of: • 45 ms or less for regional round trips within North America • 30 ms or less for regional round trips within Europe • 90 ms or less for transatlantic round trips between London and New York
61
62
Qwest http://209.3.158.116/statqwest/perfRptIndex.jsp