1 / 32

Enabling Ultra Low Latency Applications Over Ethernet

Enabling Ultra Low Latency Applications Over Ethernet. Grant Kirkwood Chief Technology Officer Mzima Networks. Services are fast becoming packet-based. Residential. Digital broadcast IPTV, VoIP Internet video gaming. Circuit-switched voice and broadcast video. Enterprise.

ros
Download Presentation

Enabling Ultra Low Latency Applications Over Ethernet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Enabling Ultra Low Latency Applications Over Ethernet Grant Kirkwood Chief Technology Officer Mzima Networks

  2. Services are fast becoming packet-based Residential Digital broadcast IPTV, VoIP Internet video gaming Circuit-switched voice and broadcast video Enterprise Ethernet Services Virtual circuits IP PBX VoIP Dedicated connections T1/T3, FR, ATM Digital PBX Wireless Data optimized Video enabled 3G/4G/WiMax Voice optimized 2G network

  3. Services are stream-based, not packet-based Digital broadcast IPTV, VoIP Internet video gaming Ethernet Services Virtual circuits IP PBX VoIP Data optimized Video enabled 3G/4G/WiMax

  4. Services are stream-based, not packet-based Voice, video and other services – streams of data Internet Protocol (IP) relies on small packets, not streams of data Digital broadcast IPTV, VoIP Internet video gaming Ethernet Services Virtual circuits IP PBX VoIP Data optimized Video enabled 3G/4G/WiMax

  5. IP Networks designed to carry“best effort” traffic Email, web browsing, “instant” messaging….Applications are not time-sensitive. Networks designed to carry packet-based data are now being askedto carry streaming data

  6. Perceived value has shifted from service provider to application provider Enterprise Consumer • Penetration of Ethernet, fiber, collaboration, and interactive video • Increased workforce mobility requiring seamless access • Maturing virtualization, cloud-based applications & telepresence • Maturity of multiservice offerings • Increased mobile data penetration and improved ease of use • Growing adoption of online video and Web 2.0 applications

  7. New applications created daily Applications become more and more sensitive to network conditions QoS policies are being created to support these technologies An increasing number of QoS policies are creating challenges for service providers

  8. Traffic keeps growing … But revenue growth is slowing ** * 41% Broadband Consumer Enterprise Wireless 134 Tbps 30% Wireline 33 Tbps 20% 66 Tbps 10 Tbps 13% 13% 101 Tbps 10% 7% 56 Tbps 4% 3% -1% -3% -5% 2007 2011 2004 2006 2008 2010 * Source: McKinsey & Company ** Sources: Yankee Group and Pyramid Research Service provider realities

  9. How do we deliver real-time services with carrier-grade QoS?

  10. QoS Model

  11. Ethernet Performance Metrics • Packet Loss • Latency • Jitter

  12. Ethernet Performance Metrics Jitter Packet Loss Latency

  13. Ethernet Performance Metrics Jitter Packet Loss Latency

  14. Ethernet Performance Metrics Different applications are sensitive to different performance metrics

  15. Class/Quality of Service QoS/CoS

  16. QoS Model

  17. QoS Model Methods to separatetraffic into different “buckets”or QoS policies

  18. QoS Model “FIFO” is not intelligent orderingOrder by priority

  19. QoS Model Non-stream services Drop packets for applications not sensitive to packet loss

  20. QoS Model Size throughput to availability Limit/buffer traffic that won’t be impacted by policing

  21. QoS Model

  22. QoS Model

  23. Policing vs Classifying • Bandwidth policing is “dumb” • Metering drops packets without discretion • Congestion causes buffering (on routers) • Buffering causes latency • Each application sensitive to specific metrics • Key is accurate classification

  24. End to end QoS Classification/Policing Schedule Transmit VoIP Gold Gold VoIP Silver Silver Gold VoIP Silver Best Effort

  25. End to end QoS • End-to-end QoS requires a technology that exists end-to-end • Difficult to achieve in multi-vendor, multi-carrier or multi-technology networks • New technologies are being developed to address this limitation

  26. Mzima Case Study • Problem: provide true Carrier Ethernet • Differentiate product from other carriers • Provide End-to-End QoS • Carry carrier-grade Services • Application-level granularity of QoS profiles • Meet requirements of true Carrier Ethernet

  27. Mzima Case Study

  28. Mzima Case Study • VLAN bridging or tunneling • Layer 2 MPLS • Layer 3 MPLS • PBB-TE

  29. PBB-TE • Provider Backbone Bridge – Traffic Engineering • End-to-End QoS • Stringent performance metrics • First Carrier Ethernet protocol not integrated into a layer 3 protocol (MPLS)

  30. PBB-TE Tunnel Performance Management Y.1731 Performance Management PRIMARY PBB-TE BCBs PBB-TE BEB PBB-TE BEB BACKUP • PBB-TE with Y.1731 Performance Management • Performance Management between Tunnel Endpoints • Provides Service Independent Tunnel Monitoring • Enhanced Scalability as 1,000’s of services may traverse the tunnel without the need to monitor every service • Leverages 802.1ag frames for reduced overhead • Multiple packets sent at 100ms interval to perform the test • Frame Delay / Frame Delay Variation / Loss Measurement • 2-way Delay Roundtrip Measurement • 1-way Delay Measurement (requires common time base) • Single Ended Frame-Loss (MEP to MEP)

  31. Management Plane: Y.1731 Round trip delay/jitter and single ended frame loss (MEP to MEP) • Non-Service Affecting • Utilizes IEEE 802.1ag format frames for test packets • Unicast messages to a specific MEP • Multiple packets sent at 100ms interval to perform the test • Delay, Jitter, and Frame Loss measurements • Test results remain until the next test is run or until reboot of switch • MIPs do not participate in delay/jitter/frame loss measurements MEP 12 MIP 802.1ag CCMs MEP 10 MEP 11 MIP MIP

  32. Thank You

More Related