This document discusses network services in carrier networks. It begins with an agenda for a 168 slide, 40 minute presentation on multiservice IP next-generation networks (NGN). It then discusses concepts like quality of service (QoS), multicasting, and TCP performance in the context of modern networking technologies like HTTP/2, over-the-top services, and 100 gigabit Ethernet. The rest of the document provides details on implementing QoS, guidelines for QoS for video, the history and uses of multicasting, and fundamentals of multicast addressing.
PLNOG16: Obsługa 100M pps na platformie PC, Przemysław Frasunek, Paweł Mała...PROIDEA
Modern CPUs have many cores and advanced instruction sets like AVX that allow performing multiple operations simultaneously. To handle 100 million packets per second, a platform needs network interfaces with speeds of at least 10 Gbps and a PCIe bus and memory fast enough to keep up. The Linux networking stack is not optimized for these speeds, so achieving line rate requires implementing the network processing in userspace using techniques like DPDK that avoid kernel overhead.
PLNOG16: Data center interconnect dla opornych, Krzysztof MazepaPROIDEA
This document discusses data center interconnect (DCI) solutions for extending layer 2 domains across multiple sites. It introduces Overlay Transport Virtualization (OTV) as an IP-based solution that uses "MAC in IP" techniques to extend layer 2 connectivity over any transport network while containing failures and preserving resiliency. OTV uses control-plane learning and IS-IS routing to advertise MAC reachability between sites and elect a single edge device per VLAN to forward traffic. This allows OTV to provide layer 2 extensions across metro or global distances while isolating spanning tree domains and preventing unknown unicast flooding beyond site boundaries.
PLNOG16: Jak zbudować Punkt Wymiany Ruchu używając urządzeń Junipera, Aleksan...PROIDEA
Orange Polska operates an extensive telecommunications network in Poland and provides voice, data and roaming services. It established an Internet Exchange Point (IXP) called TPIX to provide low-cost peering and interconnectivity for its customers and other carriers, as high peering costs were exceeding IP transit prices. TPIX has grown over time to support more ports and higher speeds, providing not just peering but also services like IPTV and private interconnects through a single access port. Juniper networks partnered with Orange Polska to provide switching equipment to build out TPIX's infrastructure and support its growth.
PLNOG16: Netflix Open Connect is the Netflix proprietary CDN, Nina BargisenPROIDEA
This document discusses Netflix's Open Connect content delivery network (CDN). It provides an overview of Netflix globally and its Open Connect program which allows ISPs to host Netflix content locally using Open Connect appliances provided by Netflix. The appliances store Netflix's content and use adaptive bitrate streaming to provide optimal video quality based on available bandwidth. The document outlines Netflix's peering and hardware requirements for ISPs to participate in Open Connect and benefit their users with faster access to Netflix content.
This document discusses Mellanox's Efficient Virtual Network (EVN) solution for service providers. It begins with an overview of Mellanox's end-to-end interconnect solutions and portfolio. It then discusses how the cloud-native NFV architecture requires an efficient virtual network. The EVN is introduced as the foundation for efficient telco cloud infrastructure. The document provides details on how SR-IOV and DPDK can be used together with Mellanox NICs to achieve near line-rate performance without CPU overhead. It also discusses how overlay networks can be accelerated using overlay network accelerators in NICs. Benchmark results show the EVN approach achieving higher performance and lower CPU utilization compared to alternative solutions.
If the number of spine switches were to be merely doubled, the effect of a single switch failure is halved. With 8 spine switches, the effect of a single switch failure only causes a 12% reduction in available bandwidth. So, in modern data centers, people build networks with anywhere from 4 to 32 spine switches. With a leaf-spine network, every server on the network is exactly the same distance away from all other servers – three port hops, to be precise. The benefit of this architecture is that you can just add more spines and leaves as you expand the cluster and you don't have to do any recabling. Intuition Systems will also get more predictable latency between the nodes.
As a trend, disaggregation seems to be most useful for very large companies like Facebook and Google, or cloud providers. The technology does not necessarily have significant implications for small or medium sized businesses. Historically, however, technology has a way of trickling down from the pioneering phases of existing only within large companies with tremendous resources, to becoming more standardized across the board.
This document discusses use cases and requirements for different cloud customer segments using Contrail. It describes Contrail's ability to enable IT as a service, enterprise migration to the cloud with legacy interconnects, public cloud services, and IoT/M2M use cases. It provides an overview of how Contrail works including its components, scale out architecture, and interaction with OpenStack. It also summarizes Contrail's features such as routing, security, analytics, and gateway services.
NFV SDN Summit March 2014 D3 03 bruno_rijsman NFV with OpenContrailozkan01
This document discusses network function virtualization (NFV) using OpenContrail. It provides the following key points:
1) OpenContrail allows for network virtualization, tenant and application policies, service chaining, and rich analytics.
2) It enables the virtualization of network functions and dynamic service chaining through SDN.
3) OpenContrail provides logical abstraction of networks and policies from the physical implementation through its transformation engine and SDN compiler approach.
PLNOG16: Obsługa 100M pps na platformie PC, Przemysław Frasunek, Paweł Mała...PROIDEA
Modern CPUs have many cores and advanced instruction sets like AVX that allow performing multiple operations simultaneously. To handle 100 million packets per second, a platform needs network interfaces with speeds of at least 10 Gbps and a PCIe bus and memory fast enough to keep up. The Linux networking stack is not optimized for these speeds, so achieving line rate requires implementing the network processing in userspace using techniques like DPDK that avoid kernel overhead.
PLNOG16: Data center interconnect dla opornych, Krzysztof MazepaPROIDEA
This document discusses data center interconnect (DCI) solutions for extending layer 2 domains across multiple sites. It introduces Overlay Transport Virtualization (OTV) as an IP-based solution that uses "MAC in IP" techniques to extend layer 2 connectivity over any transport network while containing failures and preserving resiliency. OTV uses control-plane learning and IS-IS routing to advertise MAC reachability between sites and elect a single edge device per VLAN to forward traffic. This allows OTV to provide layer 2 extensions across metro or global distances while isolating spanning tree domains and preventing unknown unicast flooding beyond site boundaries.
PLNOG16: Jak zbudować Punkt Wymiany Ruchu używając urządzeń Junipera, Aleksan...PROIDEA
Orange Polska operates an extensive telecommunications network in Poland and provides voice, data and roaming services. It established an Internet Exchange Point (IXP) called TPIX to provide low-cost peering and interconnectivity for its customers and other carriers, as high peering costs were exceeding IP transit prices. TPIX has grown over time to support more ports and higher speeds, providing not just peering but also services like IPTV and private interconnects through a single access port. Juniper networks partnered with Orange Polska to provide switching equipment to build out TPIX's infrastructure and support its growth.
PLNOG16: Netflix Open Connect is the Netflix proprietary CDN, Nina BargisenPROIDEA
This document discusses Netflix's Open Connect content delivery network (CDN). It provides an overview of Netflix globally and its Open Connect program which allows ISPs to host Netflix content locally using Open Connect appliances provided by Netflix. The appliances store Netflix's content and use adaptive bitrate streaming to provide optimal video quality based on available bandwidth. The document outlines Netflix's peering and hardware requirements for ISPs to participate in Open Connect and benefit their users with faster access to Netflix content.
This document discusses Mellanox's Efficient Virtual Network (EVN) solution for service providers. It begins with an overview of Mellanox's end-to-end interconnect solutions and portfolio. It then discusses how the cloud-native NFV architecture requires an efficient virtual network. The EVN is introduced as the foundation for efficient telco cloud infrastructure. The document provides details on how SR-IOV and DPDK can be used together with Mellanox NICs to achieve near line-rate performance without CPU overhead. It also discusses how overlay networks can be accelerated using overlay network accelerators in NICs. Benchmark results show the EVN approach achieving higher performance and lower CPU utilization compared to alternative solutions.
If the number of spine switches were to be merely doubled, the effect of a single switch failure is halved. With 8 spine switches, the effect of a single switch failure only causes a 12% reduction in available bandwidth. So, in modern data centers, people build networks with anywhere from 4 to 32 spine switches. With a leaf-spine network, every server on the network is exactly the same distance away from all other servers – three port hops, to be precise. The benefit of this architecture is that you can just add more spines and leaves as you expand the cluster and you don't have to do any recabling. Intuition Systems will also get more predictable latency between the nodes.
As a trend, disaggregation seems to be most useful for very large companies like Facebook and Google, or cloud providers. The technology does not necessarily have significant implications for small or medium sized businesses. Historically, however, technology has a way of trickling down from the pioneering phases of existing only within large companies with tremendous resources, to becoming more standardized across the board.
This document discusses use cases and requirements for different cloud customer segments using Contrail. It describes Contrail's ability to enable IT as a service, enterprise migration to the cloud with legacy interconnects, public cloud services, and IoT/M2M use cases. It provides an overview of how Contrail works including its components, scale out architecture, and interaction with OpenStack. It also summarizes Contrail's features such as routing, security, analytics, and gateway services.
NFV SDN Summit March 2014 D3 03 bruno_rijsman NFV with OpenContrailozkan01
This document discusses network function virtualization (NFV) using OpenContrail. It provides the following key points:
1) OpenContrail allows for network virtualization, tenant and application policies, service chaining, and rich analytics.
2) It enables the virtualization of network functions and dynamic service chaining through SDN.
3) OpenContrail provides logical abstraction of networks and policies from the physical implementation through its transformation engine and SDN compiler approach.
PLNOG16: Public IX is the tip of the Internet Iceberg. The 9:1 PNI rule, Mart...PROIDEA
The document discusses key considerations for peering planning and implementation. It recommends having a blend of transit, public peering, and private peering according to traffic volumes. Specifically, it suggests planning for 20%+ annual traffic growth, including peering as part of the IP traffic growth strategy, understanding the benefits of campus peering over distributed peering models, and expecting private peering traffic to outgrow public peering traffic over the long run. The document uses Equinix as an example, highlighting their large ecosystem of networks that can help lower IP transit costs and support robust public and private peering options.
This document provides an overview and configuration instructions for deploying Carrier Ethernet services on the Cisco ASR 9000 router. It begins with an introduction to Carrier Ethernet and the Cisco ASR 9000 platform. It then covers the configuration of Ethernet flow points (EFPs) to classify and rewrite VLAN tags. The document details various Ethernet service types including point-to-point local connect and VPWS services, as well as multipoint bridging and VPLS services. It concludes with sections on operations, administration, and maintenance (OAM) and best practices.
Cloud Network Virtualization with Juniper Contrailbuildacloud
Description: Contrail Technology will be discussed covering architecture, capabilities and use cases. It will be followed by a demonstration on current Contrail implementation on CloudStack/Openstack.
Parantap works as a Sr. Director of Solutions Engineering for Contrail Product within Juniper. Before Juniper, Parantap led the network architecture team for Microsoft Online Services (Windows Azure, MS Bing). Prior to Microsoft, Parantap worked as a core engineering manager for UUNet Technologies building Internet backbones.
Automate programmable fabric in seconds with an open standards based solutionTony Antony
Discover how how the standards-based Cisco Programmable Fabric with open APIs enables the Cisco Virtual Topology System (VTS) to automate overlay network provisioning with a highly scalable solution that truly integrates physical and virtual networks.
Learn how the Cisco VTS dramatically simplifies operations, reducing provisioning time from weeks to mere seconds. Find out how this open standards-based BGP EVPN control plane increases VXLAN scalability, extending workload placement and mobility range.
The document discusses traffic engineering for content delivery networks (CDNs). It describes how CDNs like Akamai use DNS-based mapping to direct users to the optimal edge server based on their location. This allows Akamai to serve over 30 terabits per second of traffic daily to over 2 trillion requests from its global network of over 189,000 servers. However, because CDNs operate as independent clusters without a private backbone, standard BGP techniques often do not work as expected to influence traffic patterns. The document provides examples of how traffic from ISPs may shift locations within 24 hours as the CDN mapping system reacts to routing changes. Effective traffic engineering requires coordination between the CDN and ISPs.
The European Advanced Networking Test Center (EANTC) conducted an evaluation of the performance and functionality of the ADVA FSP 150 ProVMe and confirmed its unique capabilities. The independent tests found that the ADVA Optical Networking edge NFV device succeeded in minimizing latency and that its hardware-assisted support functions, such as synchronization and service assurance, can be activated without requiring compute resources. This removes negative impact on revenue-generating VNFs and enhances performance.
PLNOG16: Kreowanie usług przez operatorów – SP IWAN, Krzysztof KonkowskiPROIDEA
The document discusses an SP-IWAN (Service Provider Intelligent WAN) architecture that can be offered by network operators. It proposes separating the transport and service layers, using DMVPN as an overlay and allowing applications to flow freely between MPLS and internet links using PfR. It also discusses using virtual network functions and orchestration to automate service provisioning and deliver application-aware services like monitoring, optimization and security. The architecture is meant to help operators deliver new cloud services, optimize application performance across networks and generate new revenue streams.
Virtualization Forum 2015, Praha, 7.10.2015
sál Juniper Networks
Jestliže SlideShare nezobrazí prezentaci korektně, můžete si ji stáhnout ve formátu .ppsx nebo .pdf.
The document discusses network function virtualization (NFV) in telecommunications networks. It provides an overview of NFV goals such as agility, scalability, and the ability to add new services through service chaining. It then discusses specific NFV use cases like virtual customer premises equipment (vCPE), virtual branch offices, virtual routing engines, and virtual route reflectors. It also covers Juniper's virtualized MX (VMX) product for NFV, including its performance, scaling capabilities, and deployment models.
OpenContrail Presentation at Openstack Days Tokyo Japan Feb 13 2014ozkan01
The document discusses network challenges and solutions for virtualized environments like OpenStack. It covers issues with traditional network approaches and limitations around scalability, programmability and multi-tenancy support. It then introduces Contrail as a network virtualization solution to address these issues by providing an L2/L3 overlay, network services insertion and centralized management of physical and virtual network functions.
This document discusses I/O virtualization using InfiniBand and 40 Gigabit Ethernet. It covers technologies like RDMA, VPI, IPoIB, iSER and SRP that improve performance, CPU utilization, bandwidth and latency. Mellanox provides software solutions for RDMA storage and networking that integrate with VMware vSphere. Performance results show significant improvements in VM migration times, IOPS and bandwidth when using Mellanox's 40GbE adapters compared to 10GbE.
1. The document discusses the evolution of data center network architectures from traditional multi-tier designs to modern spine-leaf fabrics.
2. Modern fabrics use a collapsed core design with high-performance spine switches directly connected to top-of-rack leaf switches to reduce latency and simplify network operations.
3. Open source initiatives like Open Compute Project aim to standardize and disaggregate hardware to lower costs and increase innovation in data center networks.
The document discusses VXLAN BGP EVPN based multi-pod, multi-fabric, and multi-site network architectures. It provides an overview of the evolution from single-pod/fabric deployments to more complex multi-site designs. Key concepts covered include hierarchical overlay domains, isolated underlay domains, and border gateways used to interconnect sites while maintaining underlay isolation.
This lab guide provides instructions for completing several labs that demonstrate an Intelligent WAN (IWAN) solution. The labs utilize a virtual lab environment containing routers, servers, and PCs in a data center and branch office. Students will navigate the lab topology, generate application traffic, and configure Cisco Prime Infrastructure and other components. The objective is to understand the IWAN architecture and how it optimizes application performance over the WAN.
Places in the network (featuring policy)Jeff Green
Networks of the Future will be about a great user experience, devices and things…
In an industry that’s already defined, Extreme Network’s recent announcement of The Automated Campus is a significant advance in networking. For the first time, all the essential technologies, products, procedures and support are gathered together and integrated. All too often, the piecemeal/piecewise growth strategy, typically applied in network evolutions, results in too many tools, procedures, and techniques. The patchwork quilt approach precludes fast responsiveness, optimal operations staff productivity, and sacrifices the accuracy and efficiency required to keep end-users productive as well.
The most important opportunity to improve efficiency for governments today is in boosting both the productivity of end-users and network operators. The automated campus must address the productivity of network planners and network operations managers and staff. The often-significant number of elements required in an installation can demand significant staff time and can, consequentially, have an adverse impact on operating expenses (OpEx). While It is possible to build traditional networks that, when running correctly and optimally get the job done, they often embody such high operating expenses that cost becomes the overriding factor controlling the evolution of the campus network. The Automated Campus will allow XYZ Account to address all these issues and concerns. A key goal must be for XYZ Account to reduce the number of “moving parts” required to build and operate any campus and introduce a level of simplicity and automation that will address your future.
Extreme’s strategy for Campus Automation begins with re-thinking the way networks are designed, deployed and managed. Extreme’s Fabric-based networks enable faster configuration and troubleshooting; As a result, there is less opportunity for misconfiguration. Several automation solutions designed to enhance security often force network managers to accept complexity and degraded resilience to secure the network to meet local policies. Should a breach occur, containment to that segment protects even more sensitive parts of the network, resulting in a true dead-end for the hacker. With Extreme’s Automated Campus services can easily be defined and provisioned on-the-fly without disruption. Network operators specify what services are allowed or prohibited across the network.
9.) audio video ethernet (avb cobra net dante)Jeff Green
Replacing a crossbar switch with ‘virtual’ IP packet switching - The ability to expand video-over-IP systems ‘one piece at a time’ and the decentralized nature of the matrix makes the technology very compelling for any size or scope of AV project.. AV-over-IP is the transport of AV signals over a standard Ethernet network, including…
HD Video (e.g. HDMI, DVI)
Audio
Control Signals (e.g. IR)
Peripheral Signals (e.g. USB)
Does Dante require special switches? No. We strongly recommend that Gigabit switches be used due to the clear advantages in performance and scalability.
Does Dante require a dedicated network infrastructure? No, a dedicated network infrastructure is not required. Dante-enabled devices can happily coexist with other equipment making use of the network, such as general purpose PCs sending and receiving email and other data.
Does Dante require any special network infrastructure? No, special network infrastructure is not required. Since Dante is based upon universally accepted networking standards, Dante-enabled devices can be connected using inexpensive off-the-shelf Ethernet switches and cabling.
What features are important when purchasing a switch? Dante makes use of standard Voice over IP (VoIP) Quality of Service (QoS) switch features, to prioritize clock sync and audio traffic over other network traffic. VoIP QoS features are available in a variety of inexpensive and enterprise Ethernet switches. Any switches with the following features should be appropriate for use with Dante:
Gigabit ports for inter-switch connections
Quality of Service (QoS) with 4 queues
Diffserv (DSCP) QoS, with strict priority
Totally new to AV over IT? This may help. If you have worked with any of the popular protocols, your time is better spent in other sessions. AV over IT methods vary in application of OSI model. Audio Networking - One RJ45 and CAT5 cable for dozens of signal paths. Switches can provide hardware time stamping which allows synchronization, offsets, and corrections. All covered in IEEE 1588.
Ethernet Timing & Priority Standards - All audio over Ethernet protocols require Priority, Sequence, & Sync
Differentiated Services / Quality of Service (DiffServ, QoS)
Priority by data type (Clock Sync and Audio Packets over Email)
Traffic prioritized based upon tags in IP Header (Layer 3)
Priority number assigned by manage switch to each packet
Real-time Transport Protocol (RTP)
Keeps data sequenced in the right order
Time stamp on UDP header
Works with RTCP (Real Time Control Protocol) for QoS and Sync
Variation: RTSP (Real Time Streaming Protocol) works on TCP and not UDP
Does not reserve resources or provide for quality of service
Precision Timing Protocol (PTP)
IEEE 1588
Sub-microsecond accuracy to synchronize subnets
Layer 2 - Switches provide hardware-based time stamping
Hartmut Schroeder, Consultant Systems Engineer, Juniper Networks
Virtualization Forum 2014, Prague, 22.10.2014
Jestliže SlideShare nezobrazí prezentaci korektně, můžete si ji stáhnout ve formátu .ppsx nebo .pdf (kliknutím na tlačitko v dolní liště snímků).
PLNOG16: Coping with Growing Demands – Developing the Network to New Bandwidt...PROIDEA
This document discusses the growing demands on data center networks and the transition to higher bandwidth technologies like 25GbE, 50GbE and 100GbE. It covers drivers of higher bandwidth demand like increased virtual machine density and higher resolution video formats. It then discusses technology solutions for higher bandwidth including new silicon, port architectures, transceiver standards and cable types. Examples of network architectures using these technologies are presented.
This hands on workshop for OpenContrail will be led by Sreelakshmi Sarva & Aniket Daptari.
This is a labs session so we will have hard RSVP limits. Please RSVP only if you are confident that you will be able to attend.
About Sreelakshmi Sarva
Sree is currently working as part of solution engineering team at Juniper’s Contrail team. She is responsible for delivering & managing SDN solutions & partnerships relating to Contrail. She has been with Juniper for the last 13 years working on various Routing, Switching, Network programmability & virtualization platforms. Prior to Juniper, She worked at Nortel networks in the Systems Engineering group. Sree received her Masters in Computer Science from University of Texas at Dallas and Bachelor’s in Computer Science from India.
About Aniket Daptari
Aniket is currently working as part of Juniper Networks' Contrail Cloud Solutions team. He is responsible for delivering SDN solutions and technology partnerships related to Contrail. He has been with Juniper for the last 3 years working on various Network programmability & virtualization platforms. Prior to Juniper, he worked at Cisco Systems in the Internet Systems Business Unit (Catalyst 6500). Aniket received his Masters in Computer Science from University of Southern California and a graduate certificate in Management Science and Engineering from Stanford University.
Course Abstract
This session will be the first of a series of OpenContrail hands-on tutorials for developers who want to get deep into OpenContrail code.
This “Basic OpenContrail Programming” Hands-on Session will focus on making developers proficient in writing and contributing code for our OpenContrail Project.
Session will cover the following areas
1) Contrail Overview
· Use Cases
· Architecture recap
2) Contrail Hands on
· Demo + Hands on - Configuration , VN, VM, Network Policies etc
· DevStack introduction
PLNOG16: Public IX is the tip of the Internet Iceberg. The 9:1 PNI rule, Mart...PROIDEA
The document discusses key considerations for peering planning and implementation. It recommends having a blend of transit, public peering, and private peering according to traffic volumes. Specifically, it suggests planning for 20%+ annual traffic growth, including peering as part of the IP traffic growth strategy, understanding the benefits of campus peering over distributed peering models, and expecting private peering traffic to outgrow public peering traffic over the long run. The document uses Equinix as an example, highlighting their large ecosystem of networks that can help lower IP transit costs and support robust public and private peering options.
This document provides an overview and configuration instructions for deploying Carrier Ethernet services on the Cisco ASR 9000 router. It begins with an introduction to Carrier Ethernet and the Cisco ASR 9000 platform. It then covers the configuration of Ethernet flow points (EFPs) to classify and rewrite VLAN tags. The document details various Ethernet service types including point-to-point local connect and VPWS services, as well as multipoint bridging and VPLS services. It concludes with sections on operations, administration, and maintenance (OAM) and best practices.
Cloud Network Virtualization with Juniper Contrailbuildacloud
Description: Contrail Technology will be discussed covering architecture, capabilities and use cases. It will be followed by a demonstration on current Contrail implementation on CloudStack/Openstack.
Parantap works as a Sr. Director of Solutions Engineering for Contrail Product within Juniper. Before Juniper, Parantap led the network architecture team for Microsoft Online Services (Windows Azure, MS Bing). Prior to Microsoft, Parantap worked as a core engineering manager for UUNet Technologies building Internet backbones.
Automate programmable fabric in seconds with an open standards based solutionTony Antony
Discover how how the standards-based Cisco Programmable Fabric with open APIs enables the Cisco Virtual Topology System (VTS) to automate overlay network provisioning with a highly scalable solution that truly integrates physical and virtual networks.
Learn how the Cisco VTS dramatically simplifies operations, reducing provisioning time from weeks to mere seconds. Find out how this open standards-based BGP EVPN control plane increases VXLAN scalability, extending workload placement and mobility range.
The document discusses traffic engineering for content delivery networks (CDNs). It describes how CDNs like Akamai use DNS-based mapping to direct users to the optimal edge server based on their location. This allows Akamai to serve over 30 terabits per second of traffic daily to over 2 trillion requests from its global network of over 189,000 servers. However, because CDNs operate as independent clusters without a private backbone, standard BGP techniques often do not work as expected to influence traffic patterns. The document provides examples of how traffic from ISPs may shift locations within 24 hours as the CDN mapping system reacts to routing changes. Effective traffic engineering requires coordination between the CDN and ISPs.
The European Advanced Networking Test Center (EANTC) conducted an evaluation of the performance and functionality of the ADVA FSP 150 ProVMe and confirmed its unique capabilities. The independent tests found that the ADVA Optical Networking edge NFV device succeeded in minimizing latency and that its hardware-assisted support functions, such as synchronization and service assurance, can be activated without requiring compute resources. This removes negative impact on revenue-generating VNFs and enhances performance.
PLNOG16: Kreowanie usług przez operatorów – SP IWAN, Krzysztof KonkowskiPROIDEA
The document discusses an SP-IWAN (Service Provider Intelligent WAN) architecture that can be offered by network operators. It proposes separating the transport and service layers, using DMVPN as an overlay and allowing applications to flow freely between MPLS and internet links using PfR. It also discusses using virtual network functions and orchestration to automate service provisioning and deliver application-aware services like monitoring, optimization and security. The architecture is meant to help operators deliver new cloud services, optimize application performance across networks and generate new revenue streams.
Virtualization Forum 2015, Praha, 7.10.2015
sál Juniper Networks
Jestliže SlideShare nezobrazí prezentaci korektně, můžete si ji stáhnout ve formátu .ppsx nebo .pdf.
The document discusses network function virtualization (NFV) in telecommunications networks. It provides an overview of NFV goals such as agility, scalability, and the ability to add new services through service chaining. It then discusses specific NFV use cases like virtual customer premises equipment (vCPE), virtual branch offices, virtual routing engines, and virtual route reflectors. It also covers Juniper's virtualized MX (VMX) product for NFV, including its performance, scaling capabilities, and deployment models.
OpenContrail Presentation at Openstack Days Tokyo Japan Feb 13 2014ozkan01
The document discusses network challenges and solutions for virtualized environments like OpenStack. It covers issues with traditional network approaches and limitations around scalability, programmability and multi-tenancy support. It then introduces Contrail as a network virtualization solution to address these issues by providing an L2/L3 overlay, network services insertion and centralized management of physical and virtual network functions.
This document discusses I/O virtualization using InfiniBand and 40 Gigabit Ethernet. It covers technologies like RDMA, VPI, IPoIB, iSER and SRP that improve performance, CPU utilization, bandwidth and latency. Mellanox provides software solutions for RDMA storage and networking that integrate with VMware vSphere. Performance results show significant improvements in VM migration times, IOPS and bandwidth when using Mellanox's 40GbE adapters compared to 10GbE.
1. The document discusses the evolution of data center network architectures from traditional multi-tier designs to modern spine-leaf fabrics.
2. Modern fabrics use a collapsed core design with high-performance spine switches directly connected to top-of-rack leaf switches to reduce latency and simplify network operations.
3. Open source initiatives like Open Compute Project aim to standardize and disaggregate hardware to lower costs and increase innovation in data center networks.
The document discusses VXLAN BGP EVPN based multi-pod, multi-fabric, and multi-site network architectures. It provides an overview of the evolution from single-pod/fabric deployments to more complex multi-site designs. Key concepts covered include hierarchical overlay domains, isolated underlay domains, and border gateways used to interconnect sites while maintaining underlay isolation.
This lab guide provides instructions for completing several labs that demonstrate an Intelligent WAN (IWAN) solution. The labs utilize a virtual lab environment containing routers, servers, and PCs in a data center and branch office. Students will navigate the lab topology, generate application traffic, and configure Cisco Prime Infrastructure and other components. The objective is to understand the IWAN architecture and how it optimizes application performance over the WAN.
Places in the network (featuring policy)Jeff Green
Networks of the Future will be about a great user experience, devices and things…
In an industry that’s already defined, Extreme Network’s recent announcement of The Automated Campus is a significant advance in networking. For the first time, all the essential technologies, products, procedures and support are gathered together and integrated. All too often, the piecemeal/piecewise growth strategy, typically applied in network evolutions, results in too many tools, procedures, and techniques. The patchwork quilt approach precludes fast responsiveness, optimal operations staff productivity, and sacrifices the accuracy and efficiency required to keep end-users productive as well.
The most important opportunity to improve efficiency for governments today is in boosting both the productivity of end-users and network operators. The automated campus must address the productivity of network planners and network operations managers and staff. The often-significant number of elements required in an installation can demand significant staff time and can, consequentially, have an adverse impact on operating expenses (OpEx). While It is possible to build traditional networks that, when running correctly and optimally get the job done, they often embody such high operating expenses that cost becomes the overriding factor controlling the evolution of the campus network. The Automated Campus will allow XYZ Account to address all these issues and concerns. A key goal must be for XYZ Account to reduce the number of “moving parts” required to build and operate any campus and introduce a level of simplicity and automation that will address your future.
Extreme’s strategy for Campus Automation begins with re-thinking the way networks are designed, deployed and managed. Extreme’s Fabric-based networks enable faster configuration and troubleshooting; As a result, there is less opportunity for misconfiguration. Several automation solutions designed to enhance security often force network managers to accept complexity and degraded resilience to secure the network to meet local policies. Should a breach occur, containment to that segment protects even more sensitive parts of the network, resulting in a true dead-end for the hacker. With Extreme’s Automated Campus services can easily be defined and provisioned on-the-fly without disruption. Network operators specify what services are allowed or prohibited across the network.
9.) audio video ethernet (avb cobra net dante)Jeff Green
Replacing a crossbar switch with ‘virtual’ IP packet switching - The ability to expand video-over-IP systems ‘one piece at a time’ and the decentralized nature of the matrix makes the technology very compelling for any size or scope of AV project.. AV-over-IP is the transport of AV signals over a standard Ethernet network, including…
HD Video (e.g. HDMI, DVI)
Audio
Control Signals (e.g. IR)
Peripheral Signals (e.g. USB)
Does Dante require special switches? No. We strongly recommend that Gigabit switches be used due to the clear advantages in performance and scalability.
Does Dante require a dedicated network infrastructure? No, a dedicated network infrastructure is not required. Dante-enabled devices can happily coexist with other equipment making use of the network, such as general purpose PCs sending and receiving email and other data.
Does Dante require any special network infrastructure? No, special network infrastructure is not required. Since Dante is based upon universally accepted networking standards, Dante-enabled devices can be connected using inexpensive off-the-shelf Ethernet switches and cabling.
What features are important when purchasing a switch? Dante makes use of standard Voice over IP (VoIP) Quality of Service (QoS) switch features, to prioritize clock sync and audio traffic over other network traffic. VoIP QoS features are available in a variety of inexpensive and enterprise Ethernet switches. Any switches with the following features should be appropriate for use with Dante:
Gigabit ports for inter-switch connections
Quality of Service (QoS) with 4 queues
Diffserv (DSCP) QoS, with strict priority
Totally new to AV over IT? This may help. If you have worked with any of the popular protocols, your time is better spent in other sessions. AV over IT methods vary in application of OSI model. Audio Networking - One RJ45 and CAT5 cable for dozens of signal paths. Switches can provide hardware time stamping which allows synchronization, offsets, and corrections. All covered in IEEE 1588.
Ethernet Timing & Priority Standards - All audio over Ethernet protocols require Priority, Sequence, & Sync
Differentiated Services / Quality of Service (DiffServ, QoS)
Priority by data type (Clock Sync and Audio Packets over Email)
Traffic prioritized based upon tags in IP Header (Layer 3)
Priority number assigned by manage switch to each packet
Real-time Transport Protocol (RTP)
Keeps data sequenced in the right order
Time stamp on UDP header
Works with RTCP (Real Time Control Protocol) for QoS and Sync
Variation: RTSP (Real Time Streaming Protocol) works on TCP and not UDP
Does not reserve resources or provide for quality of service
Precision Timing Protocol (PTP)
IEEE 1588
Sub-microsecond accuracy to synchronize subnets
Layer 2 - Switches provide hardware-based time stamping
Hartmut Schroeder, Consultant Systems Engineer, Juniper Networks
Virtualization Forum 2014, Prague, 22.10.2014
Jestliže SlideShare nezobrazí prezentaci korektně, můžete si ji stáhnout ve formátu .ppsx nebo .pdf (kliknutím na tlačitko v dolní liště snímků).
PLNOG16: Coping with Growing Demands – Developing the Network to New Bandwidt...PROIDEA
This document discusses the growing demands on data center networks and the transition to higher bandwidth technologies like 25GbE, 50GbE and 100GbE. It covers drivers of higher bandwidth demand like increased virtual machine density and higher resolution video formats. It then discusses technology solutions for higher bandwidth including new silicon, port architectures, transceiver standards and cable types. Examples of network architectures using these technologies are presented.
This hands on workshop for OpenContrail will be led by Sreelakshmi Sarva & Aniket Daptari.
This is a labs session so we will have hard RSVP limits. Please RSVP only if you are confident that you will be able to attend.
About Sreelakshmi Sarva
Sree is currently working as part of solution engineering team at Juniper’s Contrail team. She is responsible for delivering & managing SDN solutions & partnerships relating to Contrail. She has been with Juniper for the last 13 years working on various Routing, Switching, Network programmability & virtualization platforms. Prior to Juniper, She worked at Nortel networks in the Systems Engineering group. Sree received her Masters in Computer Science from University of Texas at Dallas and Bachelor’s in Computer Science from India.
About Aniket Daptari
Aniket is currently working as part of Juniper Networks' Contrail Cloud Solutions team. He is responsible for delivering SDN solutions and technology partnerships related to Contrail. He has been with Juniper for the last 3 years working on various Network programmability & virtualization platforms. Prior to Juniper, he worked at Cisco Systems in the Internet Systems Business Unit (Catalyst 6500). Aniket received his Masters in Computer Science from University of Southern California and a graduate certificate in Management Science and Engineering from Stanford University.
Course Abstract
This session will be the first of a series of OpenContrail hands-on tutorials for developers who want to get deep into OpenContrail code.
This “Basic OpenContrail Programming” Hands-on Session will focus on making developers proficient in writing and contributing code for our OpenContrail Project.
Session will cover the following areas
1) Contrail Overview
· Use Cases
· Architecture recap
2) Contrail Hands on
· Demo + Hands on - Configuration , VN, VM, Network Policies etc
· DevStack introduction
PLNOG 17 - Rafał Wiosna - Euro 2016 -- case study (prawdopodobnie) największy...PROIDEA
Podczas prezentacji opowiem o tym, jak Telewizja Polska SA przygotowywała się do przeprowadzenia transmisji internetowej z 11 meczów Euro 2016, jakie porażki i sukcesy zostały odniesione oraz przybliżę technologię wykorzystywaną do masowych transmisji internetowych dla setek tysięcy widzów. Postawię też odważną tezę, że TVP, pod względem dystrybucji sygnału wideo w internecie, biorąc pod uwagę liczbę na terytorium RP, jest "większe" niż Akamai -- i postaram się to udowodnić z wykorzystaniem przeźroczy, plansz i materiałów źródłowych.
PLNOG 17 - Łukasz Dorosz - Architektura Hybrydowa, jak połączyć własne data c...PROIDEA
Architektura hybrydowa, to najczęściej przyjmowany model w dużych firmach. Bez względu na charakter rozwiązania opartego o chmurę publiczną oraz własne data center, bardzo ważną kwestią pozostaje spięcie ze sobą tych dwóch środowisk. Podczas mojej prezentacji pokaże Wam różne modele architektury hybrydowej. Na przykładzie AWS, przyjrzymy się dokładniej jak wygląda konfiguracja oraz czym charakteryzują się usługi VPN i Direct Connect.
PLNOG15 :DDOS Attacks & Collateral Damage. Can we avoid it? Asraf AliMarta Pacyga
This document discusses DDoS attacks, including the types of attacks, their impact on victims, and best practices for network operators. It covers TCP exhaustion attacks, volumetric attacks, reflective amplification attacks that exploit protocols like DNS and NTP, and application layer attacks. These attacks can directly impact content providers and indirectly impact service providers and cloud providers. The document recommends network operators deploy anti-spoofing, scan for and mitigate abusable services, and utilize carrier DDoS protection services to help prevent collateral damage from attacks.
Zack Sosnovich built birdhouses to place in the courtyard of a nursing home where his great-grandmother used to live, in order to bring joy to residents. He learned woodworking skills like cutting, sanding, and assembly from his grandfather while making the birdhouses. The birdhouses were painted and personalized with plaques honoring his great-grandmother before being installed. Zack enjoyed the project both for benefiting others and gaining new skills.
32 Ways a Digital Marketing Consultant Can Help Grow Your BusinessBarry Feldman
How can a digital marketing consultant help your business? In this resource we'll count the ways. 24 additional marketing resources are bundled for free.
LTE and DPI technologies are essential for managing mobile broadband networks due to increasing bandwidth demands outpacing supply growth. DPI allows for prioritization of real-time traffic like voice and video, security measures, and new revenue opportunities through traffic analysis and service differentiation. It provides a "smart pipe" for optimized network efficiency and subscriber services. Rapid adoption of smartphones, internet video, and mobile applications is driving network traffic growth that LTE and DPI solutions can help address.
This document discusses quality of service (QoS) techniques for prioritizing different types of network traffic such as voice over IP. It describes several QoS mechanisms including weighted fair queuing, priority queuing, class-based weighted fair queuing, IP precedence, policy routing, and resource reservation protocol. These mechanisms allow administrators to classify and manage network traffic to ensure sufficient bandwidth and latency for applications like VoIP that have sensitive network requirements.
Software Defined Network (SDN) using ASR9000 :: BRKSPG-2722 | San Diego 2015Bruno Teixeira
The document discusses deploying SDN on the Cisco ASR 9000 platform. It provides an overview of SDN drivers, concepts and definitions. It then describes how the ASR 9000 supports SDN through capabilities like BGP-LS, stateful PCEP, OpenFlow, NETCONF/YANG. The rest of the document discusses these protocols and technologies in more detail and provides examples and configurations for SDN on the ASR 9000.
Juniper Networks provides a data center solution consisting of Juniper switches, security devices, and Contrail SDN software. The solution addresses challenges of scale and automation needed to build future-proof clouds and data centers. Key aspects of the solution include Juniper's portfolio of data center switches like the QFX10000 line, partnerships with other vendors, and proven reference designs. Juniper helps customers address these challenges and create valuable cloud services.
Learn more about how today's service provider's networks are built to deliver yesterday's services and how the Next generation service require a new approach with our Evolved Programmable Network's offerings will enable business transformation for new service deliveries.
IoT Field Area Network Solutions & Integration of IPv6 Standards by Patrick G...gogo6
gogo6 IPv6 Video Series. Event, presentation and speaker details below:
EVENT
gogoNET LIVE! 4: IPv6 & The Internet of Things. http://gogonetlive.com
November 12 – 14, 201, Silicon Valley, California
Agenda: http://gogonetlive.com/gogonetlive4-agenda.asp
PRESENTATION
IoT Field Area Network Solutions & Integration of IPv6 Standards
Abstract: http://www.gogo6.com/profiles/blogs/my-presentation-at-gogolive-integration-of-ipv4-and-non-ip
Presentation video: http://www.gogo6.com/video/iot-field-area-network-solutions-integration-of-ipv6-standards-by
Interview video: http://www.gogo6.com/video/interview-with-carsten-bormann-at-gogonet-live-4-ipv6-iot-confere
SPEAKER
Patrick Grossetete - Technical Marketing Engineer (IoT), Cisco
Bio/Profile: http://www.gogo6.com/profile/PatrickGrossetete
MORE
Learn more about IPv6 on the gogoNET social network and our online training courses
http://www.gogo6.com/main
Get free IPv6 connectivity with Freenet6
http://www.gogo6.com/Freenet6
Subscribe to the gogo6 IPv6 Channel on YouTube
http://www.youtube.com/subscription_center?add_user=gogo6videos
Follow gogo6 on Twitter
http://twitter.com/gogo6inc
Like gogo6 on Facebook
http://www.facebook.com/pages/IPv6-products-community-and-services-gogo6/161626696777
Squire Technologies: Signal Transfer Point Presentation.
The SVI_STP provides a comprehensive future proof STP supporting legacy SS7 TDM, Next Generation IP SIGTRAN and IMS / LTE / 4G support. A mature, proven, carrier grade technology packed with feature rich capabilities derived from a decade of global deployments.
This document summarizes Cisco's UCS and usNIC technologies for high performance computing. It discusses how UCS provides record-setting servers with large memory capacities, low latency Ethernet networking, and centralized management. It then describes how usNIC allows direct userspace access to network interface cards for ultra-low latency by bypassing the operating system. Benchmarks show usNIC achieving sub-microsecond application to application latency.
SDN programming and operations requires continuous monitoring of network and application state as well as consistent configuration and update of (forwarding) policies across heterogeneous devices. This is resulting in significant challenges.
Multiple open protocols such as OpenFlow, OF-CONFIG, OnePK , etc. are being adopted by different vendors causing an integration problem for developers.
Internet of Things applications are pushing the size and volume of data handled by SDN systems demanding more efficient and scalable protocols for information distribution and coordination of SDN devices.
This presentation will describe these and other SDN challenges and ways in which various open protocols, such as DDS, XMPP, AMQP, are being used to address them.
This document discusses IP interfaces for video production and summarizes the benefits of IP-based systems compared to SDI. It provides examples of IP-enabled video switchers and control systems from Sony and Grass Valley. The rest of the document discusses standards organizations and specifications that enable IP interoperability such as SMPTE ST 2110, AES67, and AIMS. It also summarizes IP routing and processing platforms like Grass Valley's GV Node and control systems like Lawo's VSM.
This document discusses quality of service (QoS) requirements for voice over IP (VoIP) and how QoS can be implemented in packet switched networks to address issues like jitter, latency, bandwidth congestion, and packet loss that can negatively impact call quality. It explains that QoS aims to guarantee a certain level of performance for applications like VoIP through techniques like traffic classification, marking, and queuing. The document also provides recommendations for applying QoS on the network edge, core, and internet exchange points to help improve end-to-end call quality.
5 maximazing networkcapacity_v4-jorge_alvaradoSSPI Brasil
This document discusses how to maximize network capacity through bandwidth optimization and data compression techniques. It provides an agenda that covers defining wireless link optimization, maximizing network capacity for internet access, VPN networks, UDP traffic, corporate applications, and cellular backhaul. Specific scenarios and case studies are presented where XipLink's optimization solutions have reduced bandwidth usage by 18-60% for various application types including internet, VPNs, VoIP, video surveillance, and file transfers. The solutions provide a typical return on investment of less than 4 months.
Building DataCenter networks with VXLAN BGP-EVPNCisco Canada
The session specifically covers the requirements and approaches for deploying the Underlay, Overlay as well as the inter-Fabric connectivity of Data Center Networks or Fabrics. Within the VXLAN BGP-EVPN based Overlay, we focus on the insights like forwarding and control plane functions which are critical to the simplicity operation of the architecture in achieving scale, small failure domains and consistent configuration. To complete the overlay view on VXLAN BGP-EVPN, we are going to the insides of BGP and its EVPN address-familiy and extend to about how multiple DC Fabric can be interconnected within, either as stretched Fabrics or with true DCI. The session concludes with a brief overview of manageability functions, network orchestration capabilities and multi-tenancy details. This Advanced session is intended for network, design and operation engineers from Enterprises to Service Providers.
Sigtran and SS7 over IP technologies allow the transport of SS7 signaling over an IP network. Sigtran defines protocols like SCTP and M3UA that encapsulate SS7 and ensure reliable delivery over IP. A phased deployment strategy migrates SS7 links onto IP in stages to test performance before full conversion. Testing focuses on priority, failure handling, latency, and interoperability to ensure equivalent functionality over IP.
Sigtran and SS7oIP technologies allow the transport of SS7 signaling over IP networks. Sigtran defines protocols like SCTP and M3UA that encapsulate SS7 messages for transport over IP. A phased deployment strategy migrates SS7 links onto SS7oIP devices to realize cost savings. Initial deployments place half the links in a city or STP over IP. Full deployment moves all A, B, and C links to IP. Testing validates capabilities like priority, rerouting, and interoperability before full migration.
The document discusses the open virtualized RAN (vRAN) ecosystem. It provides an overview of the ecosystem and its goals of accelerating adoption of open vRAN solutions. It describes traditional and evolving RAN architectures including centralized and virtualized RAN. It demonstrates early multi-vendor pre-5G and 5G SA proof of concept solutions using the open vRAN architecture. The demos show how the architecture enables new services through network slicing and edge computing. Finally, it discusses how the open vRAN ecosystem is accelerating the transition to software-defined mobile networks.
BGP started in 1989 to connect autonomous systems in a stable, efficient manner. This document outlines advancements in BGP infrastructure, VPN enhancements, and high availability features. Infrastructure enhancements improve areas like keepalive processing and update generation. VPN enhancements support technologies like iBGP between PE and CE routers, multicast VPNs, and EVPN. High availability features include graceful shutdown, fast convergence using PIC, and non-stop routing.
This document discusses VSAT, VoIP, and shared internet access. It provides details on VSAT specifications and applications including receive-only and transmit/receive uses. VoIP technologies like softphones, gateways, and codecs are explained. The concept of a shared access network is introduced where a satellite bandwidth is shared between multiple users like a neighborhood network to reduce costs. Wireless options for sharing a high-speed 11Mbps connection are also described.
Similar to PLNOG16: Usługi w sieciach operatorskich, Marcin Aronowski (20)
Discover the benefits of outsourcing SEO to Indiadavidjhones387
"Discover the benefits of outsourcing SEO to India! From cost-effective services and expert professionals to round-the-clock work advantages, learn how your business can achieve digital success with Indian SEO solutions.
Ready to Unlock the Power of Blockchain!Toptal Tech
Imagine a world where data flows freely, yet remains secure. A world where trust is built into the fabric of every transaction. This is the promise of blockchain, a revolutionary technology poised to reshape our digital landscape.
Toptal Tech is at the forefront of this innovation, connecting you with the brightest minds in blockchain development. Together, we can unlock the potential of this transformative technology, building a future of transparency, security, and endless possibilities.
HijackLoader Evolution: Interactive Process HollowingDonato Onofri
CrowdStrike researchers have identified a HijackLoader (aka IDAT Loader) sample that employs sophisticated evasion techniques to enhance the complexity of the threat. HijackLoader, an increasingly popular tool among adversaries for deploying additional payloads and tooling, continues to evolve as its developers experiment and enhance its capabilities.
In their analysis of a recent HijackLoader sample, CrowdStrike researchers discovered new techniques designed to increase the defense evasion capabilities of the loader. The malware developer used a standard process hollowing technique coupled with an additional trigger that was activated by the parent process writing to a pipe. This new approach, called "Interactive Process Hollowing", has the potential to make defense evasion stealthier.
2. 2
PLAN NA DZISIAJ
168 slajdóww 40 minut (aż 14,3 sek na slajd ;) )
Dyskusja zamiast prezentacji
Dużo informacji ”na później”
3. 3
Czy w dobie “net neutrality”, wszechobecnych
HTTP2,OTT i sieci 100GE jest sens bawić się w
QoS,multicasty i temu podobne fanaberie? ;)
4. MULTISERVICE IP NGN
4
Peering
IPSNG
Residential Subscribers
Encoder
Terrestrial
Encoder
Ground Station Encoder
Ground Station
Encoder
Studio / OB
SNG
Peering
DistributionContribution
PE
Uplink
Post
Production
CDN
Fixed location
6. QOS GOLDEN RULES
Start with the goal in mind
There is no substitute for sufficient
bandwidth
Queuing and Scheduling can protect
voice and video from data
Only Call Admission Control can protect
voice from voice and video from video
Don’t mix UDP and TCP in the same
class
10. TCP LOSS
TCP design balance
Don’t over-run the receiver/network
Use available bandwidth
TCP will adjust to the correct rate
based on delay and drops
TCP drops packets!
12. TCP LOSS
There are 2 types of TCP loss
Detected by timeout (red area)
Detected by duplicate ACK (green
area)
13. UDP
UDP does not adjust to loss or delay
UDP is generally only used for real-time trafficwhere
drops are preferred to delays
DNS
Voice
Video (VC and live broadcasts)
Financial applications (ticker)
Video games
Multicast (non-real time)
Content distribution
§ IPSec NAT-T
Does not count
Treat like TCP?
16. GENERAL QOS GUIDELINES
DiffServ QoS model
Works on aggregate traffic classes rather than individual flows
Highly scalable
Best effort traffic can reuse non-utilized bandwidth
Real-time traffic classes with preferential treatment (Voice, Video, bi-dirTP)
Strict Priority when noVoice services are provided otherwise non-strict Priority
AF class withVoice when single PQ
Real-time traffic policed at ingress to avoid misconfiguration issues
Data services run as Best Effort traffic
Business traffic uses in-profile/out-profileQoS approach
17. QOS CHEAT SHEET Do not mixUDP &TCP traffic in the same class
Do not mixVoice & Video traffic in the same class
Per-subscriber SLA for Voice and Data applications
Per-subscriber SLA not applicable toVideo/IPTV
Over-the-top (Internet)Video traffic to be treated as default traffic
With dual Dual Priority queue
Use priority level 1 forVoice traffic
Use priority level 2is forVideo traffic
With Single Priority queue
Use priority queue for Voice traffic
Use AF queue with minimum bandwidth guarantee for video
18. 1
8
Queues Distribution
(A+B+C+D=100)
PQ
A% of Link BW
Class1 - Video
B% of Link BW
(tail-drop)
Class2 - Business
Critical
C% of Link BW
(WRED-DSCP/EXP)
Class3/ Default
D% of Link BW
Multi-Play Application Traffic
DSCP /
EXP
Broadcast Video AF41 / 4*
VoD AF42 / 1
Streaming TV AF43 / 1
Ad Traffic AF31 / 2
Content Distribution (Music, Video) AF11 / 0
VoIP Bearer EF / 5
Videoconferencing (Video/Audio Bearer) CS5 / 5
VoIP Signaling (incl. video conferencing) CS3 / 3
Prioritized Data Services (inc. Commercial
Services) AF21 / 2
Residential Data Services CS0 / 0
Gaming CS 0 / 0
Other Data CS0 / 0
Network Control - Routing CS6 / 6
Service Provisioning, Control & Mgmt. CS2 / 2
Network Management CS2 / 2
19. QOS GUIDELINESFORVIDEO
NetworkSLAs
Delay:May affect Contribution
Jitter: Bounded by receiver buffer size (IP-STBs up to 200 ms, DCM
up to 100 ms)
Packet-loss:Criticalfor compressed services. IPTV packet lossrate <
10-6 (onenoticeableartifact per hour of streaming @ 4 Mbps). No
packet lossfor Contribution services
Real-timeVideoTraffic
Not oversubscribed
Not congested
Video on Demand
Can be oversubscribed withCAC
Less priority than BroadcastVideo
20. RSVP
RSVP implementation could be
modified to address the problem for
private WANs
Requires routers to initiate
reservations
RSVP agent
RSVP and IOS
RSVP proxy
21. RSVP
RSVP AND QOS IN CISCO IOS ROUTERS
Scheduling + Policing
Call AdmissionControl
? YES
NO
RSVP
RSVP signaling
LLQ/CBWFQ
IntServ
model
Data
Control Plane
Data Plane
RSVP
IntServ/
DiffServ
model
Scheduling + Policing
Call AdmissionControl
? YES
NO
Data
Control Plane
Data Plane
RSVP signaling
22. RSVP
INTSERV/DIFFSERV—IOS MODEL INTERFACE QUEUING
“Usable”Bandwidth(75%)Reserved
TotalLinkBandwidth
0%
25%
50%
75%
100%
Priority
(33% max)
BWAssignedtoLLQClasses
iprsvp
bandwidth
RSVP flows admitted/
rejected based on ‘ip rsvp
bandwidth’ only
RSVP flows assigned to
priority queue based on
LLQ classes
(typically, DSCP)
BW reserved for LLQ/
CBWFQ classes based on
policy maps and service
policy
Packets assigned to LLQ
classes/queues based on
class maps (typically,
DSCP)
Provision priority
queue to match RSVP
bandwidth + L2
overhead
23. RSVP
INTSERV/DIFFSERV CISCO IOS MODEL: NOTES
LLQ/CBWFQ classes can be configured as usual
and bandwidth allocated to them on the interface
No bandwidth is reserved with ip rsvp bandwidth
Reservations accepted/rejected based
exclusively on value configured in ip rsvp
bandwidth
RSVP traffic assigned to queues based on LLQ
rules (RSVP is not involved in classification)
If non-RSVP real-time applications are present,
provision the PQ accordingly and ensure they
use a CAC mechanism to avoid oversubscription
ip rsvp resource-provider none
ip rsvp data-packet classification none
To enable this
model in IOS:
26. A BRIEF HISTORY OF MULTICAST
Steven Deering, 1985, Stanford University
Yeah, he was way ahead of his time and too clever for all of us.
A solution for layer2 applications in the growing layer3 campus
network
-Think overlay broadcast domain
Broadcast Domain
- all members receive
- all members can source
- members dynamically come and go
26
27. A BRIEF HISTORY OF MULTICAST
RFC966 - 1985
Multi-destination delivery is useful to several
applications, including:
- distributed, replicated databases [6,9].
- conferencing [11].
- distributed parallel computation, including
distributed gaming [2].
All inherently many-to-many applications
No mention of one-to-many services such as Video/IPTV
27
28. A BRIEF HISTORY OF MULTICAST
Overlay Broadcast Domain Requirements
- Tree building and maintenance
- Network-based source discovery
- Source route information
- Overlay mechanism – tunneling
The first solution had it all
Distance Vector Multicast Routing Protocol
DVMRP, RFC1075 – 1988 28
29. A BRIEF HISTORY OF MULTICAST
PIM – Protocol Independent Multicast
“Independent” of which unicast routing protocol you run
It does require that you’re running one. J
Uses local routing table to determine route to sources
Router-to-router protocol to build and maintain distribution trees
Source discovery handled one of two ways:
1) Flood-and-prune PIM-DM, Dense Mode
2) Explicit Join w/ Rendezvous Point (RP) PIM-SM,
Sparse Mode - The Current Standard
29
30. A BRIEF HISTORY OF MULTICAST
PIM-SM – Protocol Independent Multicast Sparse Mode
-Tree building and maintenance
- Network-based source discovery
- Source route information
- Overlay mechanism – tunneling
Long, Sordid IETF history
RFC4601 – 2006 (original draft was rewritten from
scratch)
Primary challenges to the final specificationwere in addressing Network-based
source discovery.
30
31. A BRIEF HISTORY OF MULTICAST
Today’s dominant applications are primarily one-to-many
IPTV, Contribution video over IP, etc.
Sources are well known
SSM – Source Specific Multicast
RFC3569, RFC4608 – 2003
-Tree building and maintenance
- Network-based source discovery
- Source route information
- Overlay mechanism – tunneling
Very simple and the preferred solution for one-to-many applications 31
32. MULTICAST USES
§ Any applications with multiple receivers
‒ One-to-many or many-to-many
§ Live video distribution
§ Collaborative groupware
§ Periodic data delivery—“push” technology
‒ Stock quotes, sports scores, magazines, newspapers, adverts
§ Server/Website replication
§ Reducing network/resource overhead
‒ More than multiple point-to-point flows
§ Resource discovery
§ Distributed interactive simulation (DIS)
‒ War games
‒ Virtual reality
32
33. MULTICAST CONSIDERATIONS
Multicast Is UDP-Based
Best effort delivery: Drops are to be expected; multicast applications should not expect
reliable delivery of data and should be designed accordingly; reliable multicast is still an
area for much research; expect to see more developments in this area; PGM, FEC,QoS
No congestion avoidance: Lack ofTCP windowing and “slow-start”mechanisms can
result in network congestion; if possible, multicast applications should attempt to detect
and avoid congestion conditions
Duplicates: Some multicast protocol mechanisms (e.g., asserts,registers, and SPT
transitions)result in the occasional generation of duplicate packets; multicast
applications shouldbe designed to expect occasional duplicate packets
Out of order delivery:Some protocol mechanisms may also result in out of order
delivery of packets
33
36. UNICASTVS. MULTICASTADDRESSING
src addr:
10.1.1.1
src addr:
10.1.1.1
How do we
address one
packet to
different
destinations?
12.1.1.1
11.1.1.1
13.1.1.1
..replicated at
each node along
the tree.
A unique packet
addressed to each
destination.
37. MULTICAST ADDRESSING
IPv4 Header
Options Padding
Time to Live Protocol Header Checksum
Identification Flags Fragment Offset
Version IHL Type of Service Total Length
Source Address
Destination AddressDestination
Source
224.0.0.0 - 239.255.255.255 (Class D) MulticastGroup Address Range
Destination
1.0.0.0 - 223.255.255.255 (Class A, B, C)
Source Always the unique unicast origin address of
the packet – same as unicast
37
38. MULTICAST ADDRESSING
Multicast Group addressesare NOT in the unicast route table.
A separate route table ismaintained for active multicast treesin the
network.
Multicast state entriesare initiated by receiverssignaling their request to
join a group.
Sources do not need to join,they just send.
Multicast routing protocolsbuild and maintainthe trees,hop-by-hop,based
on receiver membership and source reach ability.
Source reach ability isderived from the unicast route table.
Multicast relieson a dependable unicast infrastructure.
Class D Group addresses – 224/4
38
39. MULTICAST STATEClass D Group addresses – 224/4
barn#show ip mroute 232.1.1.109
(207.109.83.5, 232.1.1.109), 3w1d/00:02:40, flags: s
Incoming interface: Ethernet 0/0, RPF nbr 207.109.83.33
Outgoing interface list:
Ethernet 1/0, Forward/Sparse, 3w1d/00:02:40
Ethernet 2/0, Forward/Sparse, 2w0d/00:02:33
barn#show ip route 232.1.1.109
% Network not in table
barn#
Multicast route entries are in (S,G) form.
Incoming interface points upstream
toward the root of the tree.
Outgoing interface list is where receivers
have joined downstream and where packets
will be replicated and forwarded downstream.
Multicast Group addresses
are NEVER in the unicast
route table.
39
40. MULTICAST ADDRESSING—224/4§ Reserved link-local addresses
224.0.0.0–224.0.0.255
Transmitted with TTL = 1
Examples
224.0.0.1 All systems on this subnet
224.0.0.2 All routers on this subnet
224.0.0.5 OSPF routers
224.0.0.13 PIMv2 routers
224.0.0.22 IGMPv3
§ Other reserved addresses
224.0.1.0–224.0.1.255
Not local in scope (transmitted with TTL > 1)
Examples
224.0.1.1 NTP (Network Time Protocol)
224.0.1.32 Mtrace routers
224.0.1.78 Tibco Multicast1 40
41. MULTICAST ADDRESSING—224/4
§ Administratively scoped addresses
‒ 239.0.0.0–239.255.255.255
‒ Private address space
Similar to RFC1918 unicast addresses
Not used for global Internet traffic—scoped traffic
§ GLOP (honest, it’s not an acronym)
‒ 233.0.0.0–233.255.255.255
‒ Provides /24 group prefix per ASN
§ SSM (Source Specific Multicast) range
‒ 232.0.0.0–232.255.255.255
‒ Primarily targeted for Internet-style broadcast 41
42. MULTICAST ADDRESSING
32 Bits
28 Bits
25 Bits 23 Bits
48 Bits
01-00-5e-7f-00-01
1110
5 Bits
Lost
IP Multicast MAC Address Mapping
239.255.0.1
44. HOW ARE MULTICASTADDRESSES
ASSIGNED?§ Static global group address assignment (GLOP)
‒ Temporary method to meet immediate needs
‒ Group range: 233.0.0.0–233.255.255.255
Your AS number is inserted in middle two octets
Remaining low-order octet used for group assignment
‒ Defined in RFC 2770, updated in RFC 3180
“GLOPAddressing in 233/8”
‒ SSM does not require group address “ownership”
§ Manual address allocation by the admin
‒ Is still the most common practice
44
45. HOST-ROUTER SIGNALING:
INTERNET GROUP MANAGEMENT
PROTOCOL (IGMP)
§ How hosts tell routers about group membership
§ Routers solicit group membership from directly connected hosts
§ RFC 1112 specifies version 1 of IGMP
‒ Supported on Windows 95
§ RFC 2236 specifies version 2 of IGMP
‒ Supported on latest service pack for Windows and most
UNIX systems
§ RFC 3376 specifies version 3 of IGMP
‒ Supported in Window XP and various UNIX systems 45
47. HOST-ROUTER SIGNALING: IGMP
§ Router sends periodic queries to 224.0.0.1 Query
§ One member per group per subnet reports
224.1.1.1
Report
§ Other members suppress reports
224.1.1.1
Suppressed
X
224.1.1.1
Suppressed
X
Maintaining a Group
H3H2H1
48. HOST-ROUTER SIGNALING: IGMP
§ Host sends leave message to 224.0.0.2
H1
Leave to
224.0.0.2
224.1.1.1
#1
§ Router sends group-specific query to 224.1.1.1
Group Specific
Query to 224.1.1.1
#2
§ No IGMP report is received within ~ 3 seconds
§ Group 224.1.1.1 times out
H2
Leaving a Group (IGMPv2)
H3H3
49. HOST-ROUTER SIGNALING: IGMPV3
§ Adds include/exclude source lists
§ Enables hosts to listen only to a specified subset of the hosts
sending to the group
§ Requires new ‘IPMulticastListen’ API
§ New IGMPv3 stack required in the OS
§ Apps must be rewritten to use IGMPv3 include/ exclude features
RFC 3376 – enables SSM
50. HOST-ROUTER SIGNALING: IGMPV3
§ 224.0.0.22 (IGMPv3 routers)
‒ All IGMPv3 hosts send reports to this address
Instead of the target group address as in IGMPv1/v2
‒ All IGMPv3 routers listen to this address
‒ Hosts do not listen or respond to this address
§ No report suppression
‒ All hosts on wire respond to queries
Host’s complete IGMP state sent in single response
‒ Response interval may be tuned over broad range
Useful when large numbersof hostsreside on subnet
New Membership Report Address
51. IGMPV3—JOINING A GROUP
§ Joining member sends IGMPv3 report
to 224.0.0.22 immediately upon joining
H2
1.1.1.1
H1 H3
1.1.1.10 1.1.1.11 1.1.1.12
rtr-a
Group: 224.1.1.1
Include: (empty)
v3 Report
(224.0.0.22)
52. IGMPV3—JOINING SPECIFIC SOURCE(S)
§ IGMPv3 report contains desired
source(s) in the include list
H2
1.1.1.1
H1 H3
1.1.1.10 1.1.1.11 1.1.1.12
rtr-a
Group: 232.1.1.1
Include: 10.0.0.1
v3 Report
(224.0.0.22)
§ Only “Included” source(s) are joined
53. IGMPV3—MAINTAINING STATE
Query1.1.1.1
§ Router sends periodic queries
§ All IGMPv3 members respond
§ Reports contain multiple group state records
v3 Report
(224.0.0.22)
v3 Report
(224.0.0.22)
v3 Report
(224.0.0.22)
H2
1.1.1.10 1.1.1.11 1.1.1.12
H1 H3
54. MULTICAST L3 FORWARDING
§ Unicast routing is concerned about where the packet
is going
§ Multicast routing is concerned about where the packet came from
‒ Initially
Multicast Routing is Backwards from Unicast Routing
55. UNICASTVS. MULTICAST FORWARDING
§ Destination IP address directly indicates where to forward packet
§ Forwarding is hop-by-hop
‒ Unicast routing table determines interface and next-hop router to forward
packet
Unicast Forwarding
56. UNICASTVS. MULTICAST FORWARDING
§ Destination IP address (group) doesn’t directly indicate where to forward
packet
§ Forwarding is Outgoing Interface List dependent (OIF)
‒ Receivers must first be “connected” to the tree before traffic begins to flow
Connection messages (PIM joins) follow unicast routing
table toward multicast source
Build multicast distribution trees that determine where
to forward packets
Distribution trees rebuilt dynamically in case of network topology changes
Each router in the path maintains an OIF list per tree state
Multicast Forwarding
57. REVERSE PATH FORWARDING (RPF)
§ The multicast packet’s source address is checked against the unicast routing
table
§ This determines the interface and upstream router in the direction of the
source to which PIM joins are sent
§ This interface becomes the “Incoming” or RPF interface
‒ A router forwards a multicast datagram only if received on the RPF interface
The RPF Calculation
58. REVERSE PATH FORWARDING (RPF)
R1
C
D
10.1.1.1
E1
E2
Unicast Route Table
Network Interface
10.1.0.0/24 E0
Join
Join
A
E0
E
RPF Calculation
§ Based on source address
§ Best path to source found in unicast
route table
§ Determines where to send join
§ Joins continue towards source
to build multicast tree
§ Multicast data flows down tree
SRC
B
59. REVERSE PATH FORWARDING (RPF)
R1
C
D
A
R2
10.1.1.1
E1E0
E2
E
Join
Join
SRC
RPF Calculation
§ Based on source address
§ Best path to source found in unicast
route table
§ Determines where to send join
§ Joins continue towards source
to build multicast tree
§ Multicast data flows down tree
B
60. REVERSE PATH FORWARDING (RPF)
R1
B C
D E
A
10.1.1.1
E1E0
E2Unicast Route Table
Network Intfc Nxt-Hop
10.1.0.0/24 E0 1.1.1.1
10.1.0.0/24 E1 1.1.2.1
1.1.2.11.1.1.1 Join
F
RPF Calculation
§ What if we have equal-cost paths?
‒ We can’t use both
§ Tie-breaker
‒ Use highest next-hop IP address
SRC
64. MULTICAST DISTRIBUTIONTREES
Receiver 1
B
E
A F
Source 1 Notation: (*, G)
* = All Sources
G = Group
C
Receiver 2
Source 2
(RP) PIM Rendezvous Point
Shared Tree
Source Tree
D (RP)
Shared Distribution Tree
65. MULTICAST DISTRIBUTIONTREES
§ Source or shortest path trees
‒ Uses more memory O (S x G) but you get optimal paths from source to all
receivers; minimizes delay
§ Shared trees
‒ Uses less memory O(G) but you may get suboptimal paths
from source to all receivers; may introduce extra delay
Characteristics of Distribution Trees
66. MULTICAST TREE CREATION
§ PIM join/prune control messages
‒ Used to create/remove distribution trees
§ Shortest path trees
‒ PIM control messages are sent toward the source
§ Shared trees
‒ PIM control messages are sent toward RP
68. MAJOR DEPLOYED PIMVARIANTS
§ PIM-SM
‒ ASM
Any Source Multicast/RP/SPT/shared tree
‒ SSM
Source Specific Multicast, no RP, SPT only
‒ BiDir
Bidirectional PIM, no SPT, shared tree only
71. PIM-SM SENDER REGISTRATION
Receiver
RP
Source
Shared Tree
Source Tree RP Sends a Register-Stop Back
to the First-Hop Router to Stop
the Register Process(S, G) Register-Stop (unicast)
Traffic Flow
(S, G) Register (unicast)
(S, G) Traffic Begins Arriving at
the RP via the Source Tree
73. PIM-SM SPT SWITCHOVER
Receiver
RP
(S, G) Join
Source
Source Tree
Shared Tree
Last-Hop Router Joins the
Source Tree
Additional (S, G) State Is
Created Along New Part of the
Source Tree
Traffic Flow
74. PIM-SM SPT SWITCHOVER
Receiver
RP
Source
Source Tree
Shared Tree
(S, G)RP-bit Prune
Traffic Begins Flowing
Down the New Branch of
the Source Tree
Additional (S, G) State Is Created
Along the Shared Tree to Prune Off
(S, G) Traffic
Traffic Flow
78. PIM-SM—EVALUATION
§ Effective for sparse or “dense” distribution of multicast receivers
§ Advantages
‒ Traffic only sent down “joined” branches
‒ Can switch to optimal source-trees for high traffic sources dynamically
(sounds clever but it actuallyswitches for all sources by default)
‒ Unicast routing protocol-independent
‒ Basis for interdomain, multicast routing
When used with MBGP, MSDP and/or SSM
79. SOURCE SPECIFIC MULTICAST - SSM
§ Assume a one-to-many multicast model
‒ Example: video/audio broadcasts, stock market data
§ Why does ASM need a shared tree?
‒ So that hosts and last-hop routers can learn who the active source is for the source
discovery
§ What if this was already known?
‒ Hosts could use IGMPv3 to signal exactly which (S, G) SPT to join
‒ The shared tree and RP wouldn’t be necessary
‒ Different sources could share the same group address and not interfere with each
other
§ Result: Source Specific Multicast (SSM)
§ RFC 3569: An Overview of Source Specific Multicast (SSM)
82. SSM—EVALUATION
§ Ideal for applications with one source sending to many receivers
§ Uses a simplified subset of the PIM-SM protocol
Simpler network operation
§ Solves multicast address allocation problems
Flows differentiated by both source and group
• Not just by group
Content providers can use same group ranges
• Since each (S,G) flow is unique
§ More secure
No “Bogus” source traffic
• Can’t consume network bandwidth
• Not received by host application
83. MANY-TO-MANY STATE PROBLEM
§ Creates huge amounts of (S,G) state
‒ State maintenance workloads skyrocket
High OIL fan-out makes the problem worse
‒ Router performance begins to suffer
§ Using shared trees only
‒ Provides some (S, G) state reduction
Results in (S, G) state only along SPT to RP
Frequently still too much (S, G) state
Need a solution that only uses (*, G) state
86. BIDIR PIM—EVALUATION
§ Ideal for many to many applications
§ Drastically reduces network mroute state
‒ Eliminates all (S,G) state in the network
SPTs between sourcesto RP eliminated
Source trafficflows both up and down shared tree
‒ Allows many-to-many applications to scale
Permits virtuallyan unlimited number of sources
88. PIM-SM ASM RP REQUIREMENTS
§ Group to RP mapping
‒ Consistent in all routers within the PIM domain
§ RP redundancy requirements
‒ Eliminate any single point of failure
89. HOW DOESTHE NETWORK LEARN RP
ADDRESS?
§ Static configuration
‒ Manually on every router in the PIM domain
§ AutoRP
‒ Originally a Cisco® solution
‒ Facilitated PIM-SM early transition
§ BSR
‒ draft-ietf-pim-sm-bsr
90. STATIC RPS
§ Hard-configured RP address
‒ When used, must be configured on every router
‒ All routers must have the same RP address
‒ RP failover not possible
Exception: if anycast RPs are used
§ Command
‒ ip pim rp-address <address> [group-list <acl>]
[override]
‒ Optional group list specifies group range
Default: range = 224.0.0.0/4 (includes auto-RP groups!)
‒ Override keyword “overrides” auto-RP information
Default: auto-RP learned info takes precedence
91. AUTO-RP—FROM 10,000 FEET
Announce Announce
AnnounceAnnounce
Announce Announce
AnnounceAnnounce
RP-Announcements Multicast to the
Cisco Announce (224.0.1.39) Group
A
C D
C-RP
1.1.1.1
C-RP
2.2.2.2
B
MA MA
92. AUTO-RP—FROM 10,000 FEET
C D
C-RP
1.1.1.1
C-RP
2.2.2.2
RP-Discoveries Multicast to the
Cisco Discovery (224.0.1.40) Group
MA MA
A B
98. L2 MULTICAST FRAME SWITCHING
Problem:Layer 2 Floodingof Multicast Frames
PIM
TypicalL2 switchestreat multicast traffic
as unknown or broadcast andmust
“flood” the frame to every port
Static entries can sometimes be set to
specify whichports should receive which
group(s) of multicast traffic
Dynamic configuration of these entries
would cut down on user administration
Multicast M
98
99. L2 MULTICAST FRAME SWITCHINGIGMPv1–v2Snooping
IGMP
IGMP
Switches become “IGMP”-aware
IGMP packets intercepted by the NMP
or by special hardware ASICs
Requires special hardware to maintain throughput
Switch must examine contents of IGMP messages to determine which ports want what traffic
IGMP membership reports
IGMP leave messages
Impact on low-end, Layer 2 switches
Must process all Layer 2 multicast packets
Admin load increases with multicast traffic load
Generally results in switch meltdown
PIM
99
100. L2 MULTICAST FRAME SWITCHING
Impact of IGMPv3on IGMPSnooping
IGMPv3 reports sent to separate group (224.0.0.22)
Switches listen to just this group
OnlyIGMP traffic—nodata traffic
Substantiallyreduces loadon switchCPU
Permits low-end switchesto implement IGMPv3 snooping
No report suppressionin IGMPv3
Enables individualmember tracking
IGMPv3 supports source-specificincludes/excludes
100
101. SUMMARY—FRAME SWITCHES
Switches with Layer 3-aware hardware/ASICs
High-throughput performancemaintained
Increasescost of switches
Switches without Layer 3-aware hardware/ASICs
Suffer serious performancedegradationor
even meltdown!
Shouldn’t be a problemwhen IGMPv3 is implemented
101
IGMP Snooping
103. MBGPOVERVIEW
MBGP: MultiprotocolBGP
Defined in RFC 2858 (extensionstoBGP)
Can carry different typesof routes
Unicast
Multicast
Both routes carried in same BGP session
Does not propagatemulticast state info
That’s PIM’s job
Same pathselection andvalidation rules
AS-Path,LocalPref, MED…
103
104. MBGPOVERVIEW
§ Separate BGP tables maintained
‒ Unicast prefixes for unicast forwarding
‒ Unicast prefixes for multicast RPF checking
§ AFI = 1, Sub-AFI = 1
‒ Contains unicast prefixes for unicast forwarding
‒ Populated with BGP unicast NLRI
§ AFI = 1, Sub-AFI = 2
‒ Contains unicast prefixes for RPF checking
‒ Populated with BGP multicast NLRI
105. MBGPOVERVIEW
MBGPAllows Divergent Paths and Policies
Same IP address holdsdual significance
Unicast routing information
Multicast RPF information
For same IPv4 addresstwo different NLRI with
different next-hops
Can therefore support both congruentand
incongruenttopologies
105
107. MSDP – MULTICASTSOURCE DISCOVERY PROTOCOL
§ RFC 3618
§ ASM only
‒ RPs knows about all sources in their domain
Sources cause a “PIM Register” to the RP
Tell RPs in other domains of it’s sources
Via MSDP SA (Source Active) messages
‒ RPs know about receivers in a domain
Receivers cause a “(*, G) Join” to the RP
RP can join the source tree in the peer domain
Via normal PIM (S, G) joins
‒ MSDP required for interdomain ASM source discovery
109. MSDPOVERVIEWMSDP Example
Domain C
Domain B
Domain D
Domain E
SA
SA
SA SA
SA
SA
Source Active
Messages
SA
Domain A
SA Message
192.1.1.1,224.2.2.2
SA Message
192.1.1.1,224.2.2.2
MSDP Peers
Register
192.1.1.1,224.2.2.2
RP
RP
RP
RP
RP
Receiver
Source
109
114. MSDPWRT SSM—UNNECESSARY
Domain C
Domain B
Domain D
Domain E
Domain A
ASM MSDP Peers
(Irrelevant to SSM)
Source in 232/8
Receiver Learns
S and G Out of
Band, i.e.,
Webpage
RP
RP
RP
RP
RP
Receiver
Source
Multicast Traffic
114
115. MSDPWRT SSM—UNNECESSARY
Domain C
Domain B
Domain D
Domain E
Domain A
ASM MSDP Peers
(Irrelevant to SSM)
Source in 232/8
Data flows natively
along the interdomain
source tree
RP
RP
RP
RP
RP
Receiver
Source
Multicast Traffic
115
116. ANYCAST RP—OVERVIEW
§ Redundant RP technique for ASM which uses MSDP
for RP synchronization
§ Uses single defined RP address
Two or more routers have same RP address
RP address defined as a loopback interface
Loopback address advertised as a host route
Senders and receivers join/register with closest RP
Closest RP determined from the unicast routing table
Because RP is statically defined
§ MSDP session(s) run between all RPs
Informs RPs of sources in other parts of network
RPs join SPT to active sources as necessary
119. INTERNET IP MULTICAST
§ We can build multicast distribution trees.
‒ PIM
§ We can RPF on interdomain sources
‒ MBGP
§ We no longer need (or want) network-based source discovery
‒ SSM
§ So interdomain IP Multicast is in every home, right?
121. IPV4VS. IPV6 MULTICAST
IP Service IPv4 Solution IPv6 Solution
Address Range 32-Bit, Class D 128-Bit(112-Bit Group)
Routing
Protocol-Independent
All IGPs and GBP4+
Protocol-Independent
All IGPs and BGP4+
with v6 Mcast SAFI
Forwarding
PIM-DM, PIM-SM:
ASM, SSM, BiDir
PIM-SM: ASM, SSM, BiDir
Group Management IGMPv1, v2, v3 MLDv1, v2
Domain Control Boundary/Border Scope Identifier
Interdomain Source Discovery
MSDP Across IndependentPIM
Domains
Single RP Within Globally Shared
Domains
122. IPV6 MULTICASTADDRESSES (RFC 3513)
1111 1111
128 Bits
8 Bits 8 Bits
FF
Flags
Scope Flags =
T or Lifetime, 0 if Permanent, 1 if Temporary
P Proposed for Unicast-Based Assignments
Others Are Undefined and Must Be Zero
TP
FF
8
Flags
4
0Scope
4
Interface-ID
Scope =
1 = interface-local 2 =
link 4 =
admin-local
5 = site
8 = organization
E = global
125. IPV6 ROUTING FOR MULTICAST
§ RPF-based on reachability to v6 source same as
with v4 multicast
§ RPF still protocol-independent
‒ Static routes, mroutes
‒ Unicast RIB: BGP, ISIS, OSPF, EIGRP, RIP, etc.
‒ Multiprotocol BGP (mBGP)
Support for v6 mcast subaddress family
127. RP MAPPING MECHANISMS FOR IPV6
§ Static RP assignment
§ BSR
§ Auto-RP—no current plans
§ Embedded RP
128. EMBEDDED RPADDRESSING—RFC3956
§ Proposed new multicast address type
Uses unicast-based multicast addresses (RFC 3306)
§ RP address is embedded in multicast address
§ Flag bits = 0RPT
R = 1, P = 1, T = 1 à Embedded RP address
§ Network-Prefix::RPadr = RP address
§ For each unicast prefix you own, you now also own:
16 RPs for each of the 16 multicast scopes (256 total) with 2^32 multicast groups assigned to
each RP (2^40 total)
FF
8
Flags
4
Network-Prefix
64
Scope
4
Rsvd
4
RPadr
4
Group-ID
32
Plen
8
129. EMBEDDED RPADDRESSING—
EXAMPLE
MulticastAddress with Embedded RPAddress
FF76:0130:1234:5678:9abc::4321
1234:5678:9abc::1
Resulting RP Address
FF
8
Flags
4
Network-Prefix
64
Scope
4
Rsvd
4
RPadr
4
Group-ID
32
Plen
8
129
130. MULTICAST LISTENER DISCOVER—MLD
§ MLD is equivalent to IGMP in IPv4
§ MLD messages are transported over ICMPv6
§ Version number confusion
‒ MLDv1 corresponds to IGMPv2
RFC 2710
‒ MLDv2 corresponds to IGMPv3, needed for SSM
RFC 3810
§ MLD snooping
‒ draft-ietf-magma-snoop-12.txt
131. NOWYOU KNOW…
§ Why multicast?
§ Multicast fundamentals
§ PIM protocols
§ RP choices
§ Multicast at Layer 2
§ Interdomain IP multicast
§ IPv6 Multicast bits
133. MULTICAST VPN SOLUTIONS
1
3
Four major components
A.Encapsulation
IP
MPLS
B.P-coreTree-building method
PIM
RSVP TE
mLDP
C. Auto-Discovery MVPN member PE
BGP
D. PE-PE C-mroute Exchange
PIM
BGP
MPLS
(LSM)
mVPN
mLDP
p-to-mp TE
PIM
BGP
A B D
• Multicast VPN’s are built on a tunnel infrastructure through the
provider core
• These are Multipoint Tunnels
• Multicast route signalling is using the Tunnel or an out of band
signalling protocol, like BGP or PIM over TCP
C
137. MULTICASTTREETYPES AND BUILDINGOPTIONS
1
3
P-Tree types
• Point-to-Multi Point(P2MP)
• Multi Point-to-Multi Point (MP2MP)
P-Tree building protocols
• PIM
• RSVP-TE
In contrast to PIM, leaves are specified at root, i.e. head-end driven
MPLS Encapsulation required
Extensions defined to build P2MP trees
Only option that supports constraint-based routing
• MLDP
Receiver-driven (like PIM)
MPLS encapsulation required
Extensions to LDP to support both MP2MP and P2MP LSPs
138. P2MPTUNNEL SETUP
MLDP
Each leaf node initiates P2MP LSPsetup by sending mLDPLabel Mapping message towards theroot, using unicast
routing
Label Mapping message carries theidentity ofthe LSP, encoded as P2MPFEC
Each intermediate node along thepath from a leaf to theroot propagates
mLDPLabel Mapping towards theroot, using unicast routing
Service Edge Distribution/
Access
CoreSource Receivers
R1 (CE)
R6 (CE)
R7 (CE)R5 (PE)
R4 (PE)
R3 (P)
R2 (PE)
Label mapping P2MP:
(FEC: 200, Root: R2,
Label: L5)
Label mapping P2MP:
(FEC: 200, Root: R2,
Label: L1)
Label mapping P2MP:
(FEC: 200, Root: R2,
Label: L7)
139. MLDPRSVP-TE
LSM SIGNALING
P2MP TREE
The egress (leaf) receives a PIM Join.
The Leafs sends a BGPA-D leaf to notify the ingress
PE
The ingress sends RSVP-TE Path messages to the
leaves
The leaves respond with RSVP-TE Resv messages
The core router received 6 updates.
The egress (leaf) receives a PIM Join.
The leaf sends a MLDP label mapping to the ingress
PE.
The core router received 3 update messages
140. CONTROL PLANE SCALE COMPARISON
Similarities
• Both are based on existing MPLS technology (LDP or RSVP TE)
• Both require changes to support Multicast
• Both support FRR
Differences
• RSVP-TE
Support bandwidth reservation
No MP2MP support
Periodic refreshof states
• MLDP
Support MP2MP LSPs
TCP based protocol - no periodic refreshof states
Less signaling and state to support an LSP, more scalable.
142. AUTO DISCOVERY
Auto discoveryis a processof discoveringwhichPEs support
whichVPNs
Auto discoverymechanismisindependentof core tree building
and customer mcast routes exchangemethods
Candidate protocolsare PIM and BGP
If PIM is alsothe P-Tree buildingprotocol, it makessense to use it
also for auto discovery(as PIM is leaf driven)
BGP alsoeffective for auto discovery
144. MULTICAST SIGNALING
EXCHANGINGCUSTOMER MULTICAST ROUTES
Mechanics used for customer mcast route exchange is independent of core
tree building and auto discovery methods
In draft-ietf-l3vpn-2547bis-mcast-10two optionsare specified:
Option 1: Per-mVPN PIM peering among the PEs
This is deployed today (draft-ietf-l3vpn-2547bis-mcast-10,
a.k.a draft-rosen)
Option 2: BGP
Analogousto RFC4364 exchangeofVPN-IPv4routes, but
with new MVPNAFI/SAFI
145. MVPN
OTHER FACTORSTO WATCH
Aggregation
Aggregate traffic into a single tunnel:less state in P-routers
Build individual treesfor each multicast group:optimal forwarding
Compromise:amount ofP-router state vs. optimal forwarding
Migration from existingGREMVPNs
Encapsulation:GRE-> MPLS
P-Tree building protocol:PIM-> RSVP-TEor mLDP
Change in tree building protocol and encapsulation method doesnot
require a change in method used today to exchange c-mcast routes (which
is PIM)
PE routers still need to run PIM – even when P routers become PIM-free
147. COMPONENTS OF DELAY IN IP / MPLS NETWORKS
The dominant causesofdelay in IP / MPLS networksare:
Propagation delay
Arising from speed-of-light delayson wide area links;~5msper 1000km for
optical fibre
Queuing delays– in switches and routers
Other componentsofdelay are negligible for linksof1Gbpsand over
Serialization delay:~10µsfor 1500byte packet at 1Gbps
Switching delay:typically~10µsper hop
Since propagationdelaysare a fixed property ofthe topology,delay and jitter
are Minimized when queuing delaysare Minimized
Queuing delaysdepend upon the traffic profile
148. 100%
0%
micro-bursts
failure & growth
measured traffic
24 hours
IP / MPLS TRAFFICCHARACTERISATION
1
4
Network traffic measurementsare
normally long term,i.e.in the order of
minutes
Implicitly the measured rate isan
average of the measurement
interval
In the short term, i.e. milliseconds,
however, microburstscause queueing,
impacting the delay,jitter and loss
What’s the relationshipbetween the
measured load and the short term
microbursts?
How much bandwidth needsto be
provisioned,relative to the measured
load,to achieve a particular SLA target?
150. 1 hop
Avg: 0.23 ms
P99.9: 2.02 ms
2 hops
Avg: 0.46 ms
P99.9: 2.68 ms
MULTI-HOP QUEUING
[TELKAMP]
Multi-hop delay is not additive (1Gbps)
151. QUEUING DELAY SUMMARY
QueuingSimulation:
– Gigabit Ethernet (backbone)link
Overprovisioning percentage in the order of 10% is required to bound delay/jitter
to less than 1 ms
– Lower speeds (<1G)
Overprovisioningfactorissignificant
– Higher speeds (2.5G/10G)
Overprovisioning factor becomes very small
P99.9multi-hop delay/jitter is not additive
http://www.denog.de/meetings/denog1/pdf/013-Telkamp-How_Full_is_Full.pdf
153. PACKET LOSS ISA MAJOR PROBLEM FORVIDEO
Video is very sensitive to packet drops.
The lossof an I-Frame resultsin the loss of the
reference frame from which subsequent P and B
frames depend.
It is thisdependency that causescumulative picture
degradation (“melt-down”) until the arrival of the
next valid I-Frame
1
5
§ With a 50ms outage, probability of an I-frame loss is 34%
§ Resulting visual impairment will be at min ~500-600ms (GOP size)
§ End user QoE for a 50ms optimized network is sameas a 500ms
optimized network!
§ BUT cost/complexity of a 50ms optimized network is much higher
Details of analysis can be found in “Not All Packets Are Equal: The Impact of Network Packet
Loss on Video Transport” , IEEE Internet Computing, Vol. 13, March/April 2009
Slice error
Pixelisation
Ghosting
154. MPEG : IMPACT OF PACKET LOSS
1
5
§ Single Packet loss can cause artifacts for the whole GOPperiod – 500ms (I frame pkt loss)
§ [GREENGRASS]: Jason Greengrass,John Evans, Ali C. Begen, “Not All Packets Are Equal: The Impact of Network PacketLoss on Video
Transport” – IEEE Internet Computing, Nov 08
§ http://www.employees.org/~jevans/videopaper/videopaper.html
0
200
400
600
800
1000
1200
0 100 200 300 400 500
Duration of packet loss (ms)
Durationofimpairment(ms)
SD-low -w orst
SD-low -best
SD-high-w orst
SD-high-best
HD-low -w orst
HD-low -best
HD-high-w orst
HD-high-best
155. NETWORKTECHNIQUES FOR
MANAGING LOSS Fast IP routing protocolconvergence
Implementation and protocol optimisations, availableon all Cisco routingplatforms
Delivers sub second convergencetimes for unicast and multicast
Multicast-only Fast Reroute (MoFRR)
Enablecreation of resilient multicast trees
Efficient approach to achieving sub 50msec convergencetimes
Can be applied to topologiesthat can support multiplediversemulticast trees
MPLS Traffic Engineering (TE) Fast Reroute (FRR)
Enables pre-calculated backup Traffic Engineerd tunnels
Used to protect against linkand nodefailuresfor rerouting in sub-100ms[RFC4090]
Requiresadditional complexity ofMPLS-TE and additional provisioned bandwidth
IPoDWDM Proactive Protection
Report Optical layer failureto IP layer to speed up routing convergenceevents
Reduces convergencetime to sub 20ms
Requiresrouter integrated optical transpondersasoffered in Cisco IPoDWDM solutions
1
5
156. FAST IGP CONVERGENCE
Network converges(reroutes) based on globalupdates(old IGP
convergenceor now localvia LFA) on a core networkfailure (link
or node)
Fast Convergence(FC)
ü Lowest bandwidth requirements in working and failure cases
ü Lowest solution cost and complexity
! Requires fast converging network to Minimisevisible impact of loss
O Is NOT hitless – ~200ms Loss of connectivity before connectivity is restored (~ less than 50ms with Loop Free Alternate Fast Reroute.
Configuration is done once, globally, per system: one command line!)
Video
Source
Core
Router
Core
Router
Edge
Distribution
Core
Router
Primary Stream
Edge
Distribution
Core
Router
Reconverged
Stream
O
157. LOCAL FASTCONVERGENCE– MOFRR
Edge router chooses best content based on local information.
Multicast only Fast Reroute (MoFRR)
ü Low bandwidth requirementsin working and failurecases(for IPTV networks)
ü Lowest solution cost and complexity
! RequiresMoFRR counter modecapability at edgeand only benefitsmulticast
O Is NOT hitless(@ present)– ~35ms Loss of connectivitybeforeflow is restored
Video
Source
Core
Router
Core
Router
Edge
Distribution
Core
Router
O
Edge
Distribution
Core
Router
158. MULTICASTONLY FAST REROUTE
MOFRR
Localenhancement to PIM
Egress onlyfeature
No changes needed in therest ofthe network
Phased approach
Control,Data plane and RTPout-of-seq triggers
Vidmonmetrics
Not hitlesstoday
~35loss of connectivitybefore flow is restored
Topologydependent
Requires ECMP paths
1
5
= IGMP Join
= PIM Join
= Mcast Tr
IP/MPLS
Core Network
Source
e1 e2
10.1.1.1
Receiver
X
MoFRR Recv
159. MULTICAST (SSM) FAST
CONVERGENCE (ASR9K)
Tested with 2500 IGP prefixes and 250k BGP routes, IOS XR 3.9.1
Tests show for SecDistribution
MoFRR delivers consistent sub 50ms
Convergence @ no operational cost
160. TI-MOFRR
OVERCOMING THE ECMP LIMITATION
• Simple deployable solution
• 100% Path Diversity (i.e.TE-like ERO)
• Works in any ECMP or Non-ECMP topologiessuch as mesh, ring,
hub-spoke,star, etc. …
• Consistent and predictable: sub 50 msec solution
• No loopsor micro-loopsin the Network
• Foundation to lossless stream-merge
161. EXPLICIT PATHVECTORTLV
Bringing Path-Diversity to Multicast
It’s like RSVP-TEERO
It allowsexplicit-routing ofPIMJoins or MLDP Joins
No loopsor microloops
Explicit PathVectorTLV Encoding:
(Example)
Multicast Source IP: S = 10.0.0.1
R1: 11.0.0.1
R2: 12.0.0.1
R3: 13.0.0.1
R4: 14.0.0.1
1
6
S
IP:10.0.0.1
R1
R2R3R4
R5R6
Rx
IGMP Join
PIM Join
PIM Join
162. TI-MOFRR
CREATION OF PRIMARY/BACKUPTREE USING 2 MROUTES
IGMP Join
(S1,G)
PIM Join
(S1,G)
PIM Join
(S2,G)
TI-MoFRR
Leaf Multicast Router
TI-MoFRR Egress Multicast Router:
1. Explicit Path Vector TLV used for PIM-Tree explicit routing
2. Original (S1,G) PIM Join forwarded towards S1 source to build Primary tree
3. Cloned (S2,G) PIM Join used to build backup PIM tree
163. TI-MOFRR NATIVE MULTICAST
SOLUTION
SINGLED/DUALHOMED SOURCE
(S1,G)
(S1,G)
(S2,G)
(S1,G)
(S1,G)
PE1
PE3
PE4
Ingress TI-MoFRR Functions:
1. Clone (S1,G)
2. Re-write S1 to S2 => (S2,G)
Egress TI-MoFRR Functions:
1. Perform MoFRR
2. Specify S1/S2 prefixes in MoFRR
3. Re-write S2 to S1 => (S1,G)
Ingress
Demarcation
Egress
Demarcation
Any Transport
Between PEs
Protection
Domain
PE2
(S2,G)
164. VIDMON
QUALITYTRIGGERED TI-MOFRR RESILIENCY SOLUTION
(S1,G)
Primary
(S1,G)
Backup
(S2,G)
TI-MoFRR
Egress Multicast Router
VidmonVidmon
MDI(0:0:12)MDI(24:34:223)
Vidmon and TI-MoFRR Integration Solution Details:
1. Vidmon monitors MPEG MDI quality of Primary and Backup TI-MoFRR flow
2. Vidmon result at end of Monitoring Interval:
• Primary MDI is Poor with impairment
• Backup MDI is Good without impairment
3. Vidmon instructs TI-MoFRR switchover from Primary to Backup
165. LOCAL FAST CONVERGENCE
P2MP FAST REROUTE
Network reconverges (reroutes) based on local information (LOS) on a core link failure
Fast Reroute (FRR)
ü Lowest bandwidth requirements inworking and failure cases
! Medium solution cost and complexity
! Requires fast converging network to Minimise visible impact of loss
O Is NOT hitless – ~50ms Loss of connectivity before connectivity is restored
Video
Source
Core
Router
Core
Router
Edge
Distribution
Core
Router
Primary Stream
Edge
Distribution
Core
Router
FRR Stream
O
Core
Router
167. IPODWDM PROACTIVE
PROTECTION
IP / optical integration enablesthe
capability to identifydegraded link using
optical data (pre-FECBER) and start
protection (i.e.by signaling to the IGP)
before traffic starts failing,achieving
hitless protection in many cases Trans-
ponder
SR
port
on
router
WDM
port
on
router
Optical impairments
Correctedbits
FEC limit
Working
path
Switchover
lost data
Protected
path
BER
LOF
Optical impairments
Correctedbits
FEC limit
Protection
trigger
Working path Protect path
BER
Near-
hitless
switch
WDM WDM
FEC
FEC
Proactive protection
Router Has NoVisibility intoOptical
Transport Network
Pre-FEC FRR Fault
Packet Loss (ms)
Highest Lowest Average
No Optical-switch 11.47 11.54 11.37
No Noise-injection 7404.00 1193.00 4305.00
No Fibre-pull 28.81 18.52 21.86
No PMD-injection 129.62 122.51 125.90
Yes Optical-switch 11.50 11.18 11.37
Yes Noise-injection 0.02 0.00 0.00
Yes Fibre-pull 11.05 0.00 3.23
Yes PMD-injection 0.08 0.00 0.02