UC Expo 2010 - Best Practices: Deploying Microsfot OCS on Brocade Network Infrastructure

1,299 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,299
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Packet loss - Several factors make packet loss requirements somewhat variable. Even with the same average packet loss, the way the packets are lost influences the impact on Voice Quality:There are two types of packet loss: random packet loss over time (where single packets might be dropped every so often during the call) and “bursty” packet loss (where several, contiguous packets can be lost in a short time window). Losing ten contiguous packets is worse than losing ten packets evenly spaced over an hour time span.Packet loss may be also be more noticeable for larger voice payloads (i.e. packets representing a longer time sample) than for smaller ones, because more voice is lost in a larger payload.Packet loss may be more tolerable for one codec over another, because some codecs have some loss concealment capabilities.Packet loss requirements are tighter for tones (other than DTMF) than for voice. The ear is less able to detect packet loss during speech (variable-pitch), than during a tone (consistent pitch).Even small amounts of packet loss can greatly affect traditional TTY devices’ ability to work properly as well as transmission of faxes using the usual fax protocol T.30 over IP networks; standards such as T.38 have been developed to reduce the impact of network impairments on the reliability of faxing over IP, but in practice they are not always supported, or the IP network may not be detected.
  • Processing delay includes the time required collecting a frame of voice samples before processing by the speech encoder can occur, the actual process of encoding, encrypting if appropriate, packetizing for transmission, and the corresponding reverse process on the receiving end, including the jitter buffer used to compensate for varying packet arriving delay on the receiving end. The complete end-to-end processing delay is often in the 60 ms to 120 ms range when all of the contributing factors are taken into account. The processing delay is essentially within a fixed range determined by the vendor’s technology and implementation choices. Encoding and decoding might be repeated several times however if there is any inline transcoding from one codec to another, for example for some hand-off between networks, in which case accumulated processing delay can become disruptive.Serialization delay is a fixed delay required to clock a voice or data frame onto a network interface, placing the bits onto the wire for transmission. The delay will vary based on the clocking speed of the interface. A lower speed circuit (such as a modem interface or smaller transmission circuit) will have a higher serialization delay than a higher speed circuit. It can be quite significant on low-speed links and occurs on every single link of a multi-hop network.Network delay is mostly caused by inspecting, queuing and buffering of packets, which can occur at traffic shaping buffers (such as “leaky bucket” buffers) sometimes encountered at various network ingress points, or at various router hops encountered by the packet along the way. Network delay on the internet generally averages less than 40 ms when there is no major congestion. Modernization of routers has contributed to reducing this delay over time.Propagation delay is the distance traveled by the packet divided by the speed of signal propagation (i.e. speed of light). Propagation delay on transcontinental routes is relatively small – typically less than 40 ms – but propagation delay across complex intercontinental paths can be much larger. This is especially true when satellite circuits are involved or on very long routes such as Australia to South-Africa via Europe, for example, which might incur up to 500 ms of one way propagation delay. Propagation delay can only be optimized by designing the shortest possible path links.
  • For microsoftocs known clients use active directory group policy, otherwise ensure demarkation point set to untrusted on the ports
  • Processing delay includes the time required collecting a frame of voice samples before processing by the speech encoder can occur, the actual process of encoding, encrypting if appropriate, packetizing for transmission, and the corresponding reverse process on the receiving end, including the jitter buffer used to compensate for varying packet arriving delay on the receiving end. The complete end-to-end processing delay is often in the 60 ms to 120 ms range when all of the contributing factors are taken into account. The processing delay is essentially within a fixed range determined by the vendor’s technology and implementation choices. Encoding and decoding might be repeated several times however if there is any inline transcoding from one codec to another, for example for some hand-off between networks, in which case accumulated processing delay can become disruptive.Serialization delay is a fixed delay required to clock a voice or data frame onto a network interface, placing the bits onto the wire for transmission. The delay will vary based on the clocking speed of the interface. A lower speed circuit (such as a modem interface or smaller transmission circuit) will have a higher serialization delay than a higher speed circuit. It can be quite significant on low-speed links and occurs on every single link of a multi-hop network.Network delay is mostly caused by inspecting, queuing and buffering of packets, which can occur at traffic shaping buffers (such as “leaky bucket” buffers) sometimes encountered at various network ingress points, or at various router hops encountered by the packet along the way. Network delay on the internet generally averages less than 40 ms when there is no major congestion. Modernization of routers has contributed to reducing this delay over time.Propagation delay is the distance traveled by the packet divided by the speed of signal propagation (i.e. speed of light). Propagation delay on transcontinental routes is relatively small – typically less than 40 ms – but propagation delay across complex intercontinental paths can be much larger. This is especially true when satellite circuits are involved or on very long routes such as Australia to South-Africa via Europe, for example, which might incur up to 500 ms of one way propagation delay. Propagation delay can only be optimized by designing the shortest possible path links.
  • UC Expo 2010 - Best Practices: Deploying Microsfot OCS on Brocade Network Infrastructure

    1. 1. Infrastructure & Delivery Management Theatre<br />Deploying Microsoft OCS on Brocade Networksa best practice Guide <br />Harry PettyDirector, Product Marketing<br />UC EXPO<br />March 11, 2010<br />© 2010 Brocade Communications Systems, Inc.<br />
    2. 2. Legal Disclaimer<br />All or some of the products detailed in this presentation may still be under development and certain specifications, including but not limited to, release dates, prices, and product features, may change. The products may not function as intended and a production version of the products may never be released. Even if a production version is released, it may be materially different from the pre-release version discussed in this presentation. <br />NOTHING IN THIS PRESENTATION SHALL BE DEEMED TO CREATE A WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, INCLUDING BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT OF THIRD-PARTY RIGHTS WITH RESPECT TO ANY PRODUCTS AND SERVICES REFERENCED HEREIN. <br />Brocade, the B-wing symbol, BigIron, DCX, Fabric OS, FastIron, File Lifecycle Manager, IronPoint, IronShield, IronView, IronWare, JetCore, MyView, NetIron, SecureIron, ServerIron, StorageX, and TurboIron are registered trademarks, and DCFM and SAN Health are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. All other brands, products, or service names are or may be trademarks or service marks of, and are used to identify, products or services of their respective owners.<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />March 11, 2010<br />2<br />
    3. 3. Abstract<br />Is your Network Infrastructure Ready for Voice and UC Services?<br />While typical enterprise networks have sufficient bandwidth to accommodate VoIP services, voice and video calls demand low latency with high Quality of Service (QoS)<br />Additionally, there are other aspects of the network infrastructure that need to be considered in the process of planning for a successful VoIP or UC deployment<br />This session will explore the challenges of deploying voice and UC services in legacy enterprise networks and how to UC-enable your network infrastructure<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />March 11, 2010<br />3<br />
    4. 4. Agenda<br /><ul><li>Unified Communications Challenges
    5. 5. Office Communications Server Deployment Models
    6. 6. Designing OCS Network Infrastructure
    7. 7. Layer 2-3 Network Infrastructure
    8. 8. Layer 4-7 Application Delivery
    9. 9. The Best Practice for the Best ROI</li></ul>Is your Network Infrastructure Ready for Voice and UC Services?<br />4<br />March 11, 2010<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />
    10. 10. Unified Communications Challenges<br />Packet Loss<br />Packet loss occurs when packets fail to reach their destination, and is expressed as the percentage of packets lost en-route across the network<br />IP backbones and LANs are designed to prevent packet losses greater than 0.5%, whereas Internet routing can result in losses exceeding 10%<br />WiFi-connected devices can experience packet loss in excess of 15%<br />Jitter<br />Expressed in milliseconds, jitter is a measure of the time variability in the arrival of successive packets<br />Jitter can result from packets taking different routes, or from congestion on certain routes causing packets to get delayed in queues<br />Microsoft OCS 2007 R2 offers ‘time-warping’ jitter buffer control<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />March 11, 2010<br />5<br />
    11. 11. Unified Communications Challenges<br />Delay/Latency<br />Delay is the measure of the time required for the packets of a voice signal to traverse the network<br />The four types of delay include processing, serialization, network, and propagation<br />Propagation delay can be adversely impacted by increased distance and connection type (e.g. satellite), but can be improved by selecting the shortest path<br />150 milliseconds of total one-way delay is the upper limit for the best voice quality, and any delay exceeding this will lead to echo and talk-over effects<br />Bandwidth<br />The measure of bandwidth of an end-to-end network path that is actually available at a given point in time to applications or network flows<br />Not having enough bandwidth on uplinks or the WAN<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />March 11, 2010<br />6<br />
    12. 12. Enterprise Deployment Models<br />Internet<br />Firewall<br />Standard Deployment<br />OCS 2007 R2 Standard Edition is deployed with the Frontend Server, Backend Database, A/V Conferencing Server, Web Conferencing Server, and Web Components Server installed on a single physical computer<br />Recommended for small to medium size companies<br />Can support up to 5000 users per server<br />Add more servers as demand increases<br />DMZ<br />OCS Edge<br />OCS Edge<br />OCS Antivirus<br />OCS Antivirus<br />OCS Edge<br />OCS Antivirus<br />Firewall<br />Data<br />Center<br />Campus<br />LAN<br />Aggregation/ Core <br />NetIron MLX<br />Access -<br />FastIron CX-PoE+<br />Access – FCX<br />SQL Server<br />OCS Frontend, AV, Monitoring, Web Conferencing <br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />March 11, 2010<br />7<br />
    13. 13. Large EnterpriseDeployment Models<br />Internet<br />Expanded Deployment<br />OCS 2007 R2 Enterprise Edition in the consolidated configuration, one or more Enterprise Edition servers are deployed, each running the Frontend Server, A/V Conferencing Server, Web Conferencing Server, and Web Components Server<br />Recommended for most organizations<br />Provides high performance and high availability with easy scalability<br />A hardware load balancer is required when two or more Enterprise Edition servers make up a pool<br />Firewall<br />Access – FastIron CX<br />DMZ<br />OCS Edge<br />OCS Edge<br />OCS Antivirus<br />OCS Antivirus<br />Firewall<br />Core - NetIron MLX<br />Internal Network<br />Aggregation – FastIron SX<br />Load Balance – ServerIron ADX<br />OCS Frontend, AV, Monitoring, Web Conferencing <br />SQL Server<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />March 11, 2010<br />8<br />
    14. 14. Data Center Layer 2-3 OCS Network Design<br />CampusLAN<br />Multi-tier<br />Depending on size of network, use three-tier architecture<br />Redundancy<br />Provide redundancy at all levels<br />Link Aggregation Groups<br />Provide at least 10GbE dynamic LAGs between each layer<br />Monitor LAGs and WAN link to see if congestion is occurring<br />NetIron MLX<br />Core<br />FastIron SX<br />Aggregation<br />ServerIron ADX<br />OCS Servers<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />March 11, 2010<br />9<br />
    15. 15. Data Center Layer 4-7 OCS Network Design<br />High Availability<br />ServerIron ADX switch pairs in front of Enterprise Edition pools of OCS Directors, Frontend and Edge servers maximize application uptime and server farm utilization<br />Security<br />Shield applications from malicious attack without performance degradation<br />Scalability<br />ADX receives all client requests, performing health checks to identify outages and direct client connections to the most available resource, while servers are added or subtracted from the network in real time<br />ServerIron ADX HA Pair<br />server virtual EDVIP 10.5.57.90<br />server virtual DIRVIP 10.5.57.90<br />server virtual FEVIP 10.10.57.13<br />OCS 2007 R2<br />Edge Servers<br />server real ED1 10.5.57.11<br />server real ED2 10.5.57.12<br />OCS 2007 R2<br />Directors<br />server real DIR1 10.10.57.8<br />server real DIR2 10.10.57.9 <br />OCS 2007 R2<br />Frontend Servers<br />server real FE1 10.10.57.11<br />server real FE2 10.10.57.12 <br />Ports Load Balanced<br />server port 5060 tcp<br />server port 5061 tcp<br />server port 5063tcp<br />server port 135 tcp<br />server port 80 tcp<br />server port 443 tcp<br />server port 444 tcp<br />server port 5069 tcp<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />March 11, 2010<br />10<br />
    16. 16. Best Practice—Layer 2-3 <br />Deploy Rapid Spanning Tree to speed up convergence time<br />Configure ports that are connected to other switches as point-to-point and all other ports as edge devices<br />Leverage VRRP-e<br />Increases availability of default gateways servicing the clients<br />Internet<br />VRID1<br />Router1 = Master<br />Interface IP = 192.53.5.2<br />VIP = 192.53.5.1<br />Priority = 110<br />VRID1<br />Router1 = Master<br />Interface IP = 192.53.5.3<br />VIP = 192.53.5.1<br />Priority = 100<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />March 11, 2010<br />11<br />
    17. 17. Best Practice—Layer 2-3<br />Use Quality of Service (QoS) throughout<br />Assign higher priority to voice than video traffic<br />Apply QoS on all switches so that QoS is maintained on each hop<br />Helps reduce jitter on voice and video traffic<br />Assign DSCP values within Active Directory Group Policy so that all clients apply the same level of QoS<br />Use Link Aggregation Groups (LAG)<br />Both sides of a LAG automatically negotiate and configure themselves<br />Load balances traffic across dynamic LAGs<br />Use QoS and dynamic LAGs throughout the network<br />12<br />March 11, 2010<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />
    18. 18. Best Practice—Layer 2-3 <br />Service quality: <br />Provision network capacity for the demanding voice/video applications<br />Monitor service quality through S-Flow monitoring tools<br />Power delivery:<br />All phones are PoE powered<br />Access layer switches can deliver max PoE power on all ports<br />March 11, 2010<br />© 2010 Brocade Communications Systems, Inc. <br /><ul><li>Auto-configuration:
    19. 19. Device configured automatically: LLDP-MED based phone configuration
    20. 20. Phones auto discover voice VLAN
    21. 21. Availability:
    22. 22. Redundant components across the board power supplies, management modules, fabric modules …
    23. 23. Redundant network topology</li></li></ul><li>Best Practice—Layer 4-7<br />Always use ADX HA pairs to eliminate a single point of failure<br />Active Hot Standby: One ADX active, the other is standby with shared MAC address<br />Active-Standby VIP – both ADXs can receive traffic buy only one VIP is acting in standby<br />Active-Active: Both ADXs are active allowing for oversubscription<br />Use Global Server Load Balancing in multi OCS R2 Server farms to distribute services transparently across multiple sites<br />Use one-arm, or DSR mode, which is less network-intrusive<br />UC Expo | Deploying Microsoft OCS on Brocade Networks<br />March 11, 2010<br />14<br />
    24. 24. Branch / Remote Sites<br />Internet<br />New York<br />Brocade MLX<br />OSPF 11<br />Brocade FCX<br />OSPF 20 - 50ms Latency<br />Corporate Site<br />San Francisco<br />Brocade SX<br />Austin<br />SQL, Exchange, and SharePoint Clusters<br />Brocade ADX<br />OSPF 30 - 25ms Latency<br />Brocade FCX<br />Brocade <br />FC SAN<br /> OCS R2 <br />Monitoring<br />Seattle<br />OCS R2 Edge Server<br />DMZ<br />OSPF 40 - 5ms Latency<br />Brocade FCX<br />OCS R2 Director<br />OCS R2 Front End<br />Fabrikam Sports<br />Network Topology<br />March 11, 2010<br />UC Expo | Scaling and Securing Your Microsoft OCS Investment<br />15<br />
    25. 25. Best Practice for the Best ROI<br /><ul><li>For Campus LAN,
    26. 26. Use high performance edge, use QoS, monitor sFlow
    27. 27. Push L3 to the edge, use RST for L2
    28. 28. For Data Center LAN,
    29. 29. Design topology and network elements for reliability
    30. 30. Use flat L2 for servers, RST for L2 access
    31. 31. For Application Delivery
    32. 32. Design for app availability and reliability </li></li></ul><li>THANK YOU<br />For more information, please visit www.brocade.com<br />

    ×