Video Transport Architectures

Thomas Kernen, IJsbrand Wijnands BRKSPV-2919 Agenda

• Introduction • Solution Space • Video Transport Use Cases • QoS • IP/MPLS Video Transport • IP Multicast Transport Options • Problem Space & Requirements • Label Switched Multicast • Minimizing Failure/Recovery Loss • Bounded Delay & Jitter • Auto Multicast Tunneling • Video & Packet Loss • Bit Index Edge Replication • Zero Loss Options • Video Monitoring Broadcast Media Content Delivery High level view

Acquisition Production Distribution Consumer Experience

• Video Contribution • Studio-to-Studio Primary • Primary Distribution Distribution • Owner to Distributor

• Secondary Distribution Secondary • IPTV, Cable, Mobile, DVB-T Distribution • SP CDN/Internet Streaming

• Enterprise Video • Multicast VPNs

• In all cases, point-to-point AND multipoint services over Private OR SP infrastructure are required

Studio and Remote Primary Secondary Consumer Contribution Post Production Distribution Distribution Experience Production

Studio to Studio Owner to Provider Provider to Subscriber Uncompressed/Lossless compression Compressed (High quality) Compressed - SD: 270 Mbps (SMPTE ST 259) P-to-P  P-to-MP - SD: 2 – 6 Mbps - HD: 1.5 – 3 Gbps (SMPTE ST 292, ST 372, ST 424) P-to-MP for DTT/DVB-T - HD: 6 – 16 Mbps - UHD: 12 Gbps (SMPTE ST 2082) P-to-P for VoD P-to-P, MP-to-P, P-to-MP P-to-MP for IPTV “Dial up” approach (ATM SVC very common) May be wholesaled

Stricter Requirements, Higher per-flow bandwidth

• TDM based networks provide uniform services IP/MPLS • Circuit-oriented with Circuit-based protection Si

• No bandwidth sharing Transport

• ATM/DTM networks provide specialized services • Granular bandwidth with switching capabilities Video : A new layer for each service • Specific overlays per service

• IP/MPLS networks are multi-service • Flexible bandwidth re-utilization

• Co-existence of strict and loose SLA applications IP/MPLS • Future proof

Video: Just a new service

Performance Impact Goal Solution Technology of Delay Service SLAs Resiliency Path Diversity Traffic Guaranteed bandwidth Engineering

Transport SLAs Delay Planning y Loss FRR x% 100% Average Link Simplicity KISS IP Utilisation Manageability Video Monitoring VidMon Contribution Flexibility MultiService QoS Distribution

Scalability & File Transfer Unified CP for Multicast LSM Multipoint

• Packetization/Encapsulation • Uncompressed A/V, MPEG-2 TS and MXF wrappers

• Adaptation/Profiling • RTP: Sequencing and Timestamp

• Transport • UDP: Multiplexing and Checksum

• Network • IP: QoS, Multi-service

• Traffic Engineering • MPLS: Path selection, Admission control, Bandwidth Reservation

BRKSPV-2919 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 11 Video Transport: Quality of Service Contribution • Required to enable multiple services Distribution • Elastic and inelastic (sensitive to loss and delay) File Transfer

• Differentiated services (per traffic aggregate) • Marking, Conditioning, Queuing, … (the IP QoS toolkit) • Handling a variety of traffic classes in a single network

• Integrated services (per flow) • Allowing for service oversubscription • Video CAC (Call Admission Control)

• Delay and Jitter requirements for Video transport are satisfied by modern routing equipment

• P2P, P2MP and MP2MP services IP/MPLS • Unicast and Multicast models • IP and MPLS • Single, multi-topology • (m)VPNs

• Automatic (shortest path) or Explicit path setup • Admission Control and Bandwidth Reservation • MPLS-TE with RSVP based label distribution

• Resiliency: from sub 50 msec restoration to lossless • IP FRR • MPLS FRR for link and node protection

• The dominant causes of delay in IP / MPLS networks are: • Propagation delay • Arising from speed-of-light delays on wide area links; ~5ms per 1000km for optical fibre • Queuing delays – in switches and routers

• Other components of delay are negligible for links of 1Gbps and over • Serialization delay: ~10µs for 1500 byte packet at 1Gbps, 1µs for 10 Gbps, 0.1µs for 100Gbps link • Switching delay: typically 1µs per hop (with modern fabric)

• Propagation delays are a fixed property of the topology • Delay and jitter are minimized when queuing delays are minimized

• Queuing delays depend upon the traffic profile

• Network traffic measurements are 100% normally long term, i.e. in the order of minutes failure & growth • Implicitly the measured rate is an average of the measurement interval micro-bursts • In the short term, i.e. milliseconds, however, microbursts cause queueing, impacting the delay, jitter and loss

• What’s the relationship between the measured load and the short term measured traffic microbursts? 0%

24 hours

1 hop 2 hops

Avg: 0.23 ms Avg: 0.46 ms P99.9: 2.02 ms P99.9: 2.68 ms

Classification Queuing and Post-Queuing and Marking (Selective) Dropping Operations

1200

1000 SD-low -w orst

800 SD-low -best SD-high-w orst SD-high-best 600 HD-low -w orst HD-low -best 400 HD-high-w orst HD-high-best

Durationof impairment (ms) 200

0 0 100 200 300 400 500 Duration of packet loss (ms)

. Single Packet loss can cause artifacts for the whole GOP period – 500ms (I frame pkt loss)

. [GREENGRASS]: Jason Greengrass, John Evans, Ali C. Begen, “Not All Packets Are Equal: The Impact of Network Packet Loss on Video Transport” – IEEE Internet Computing, Nov 08

• ABR normally HTTP(s) (unicast), not RTP • Payload are segments of MPEG/H26x media • ABR can be very bursty • Sequence of segment@max-speed, idle, segment@max-speed, idle,.. • Competing ABR flows can cause mutual congestion collapse • Network QoS and ABR “self-friendliness” required

• Some Limited standards for ABR over IP multicast • 3G, upcoming in cable (OC-SP-MS-EMCI-I01-150528) • Still transporting a segment that needs to arrive without loss • ABR sender need to use FEC instead of TCP retransmissions.

• Congestion / oversubscription • Elasticity of the traffic • Inelastic – classic broadcast • Partial elastic – ABR • Elastic – “TCP like” – sender bitrate adaptation (uncommon in broadcast video)

• BER – Bit Error Rate Loss • Link quality

• Failure/Recovery • Link, Interface, Linecard, Node, Power,..

• Elastic links • DSL retraining • WiFi, Mobile, Powerline

• DiffServ QoS model • Works on aggregate traffic classes rather than individual flows • Highly scalable (any number of eg: video channels – just < ~ 20 classes of QoS). • Best effort traffic can reuse non-utilized bandwidth

• Real-time traffic classes with preferential treatment (Voice, Video) • Strict Priority when no Voice services are provided otherwise non-strict Priority • AF class with Voice 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-profile QoS approach

• Do not mix UDP & TCP traffic in the same class • Do not mix Voice & Video traffic in the same class • Per-subscriber SLA for Voice and Data applications • Per-subscriber SLA not applicable to Video/IPTV • Over-the-top (Internet) Video traffic to be treated as default traffic • With Dual Priority queue • Use priority level 1 for Voice traffic • Use priority level 2 is for Video traffic • With Single Priority queue • Use priority queue for Voice traffic • Use AF queue with minimum bandwidth guarantee for video

PQ high Multi-Play Application Traffic DSCP / EXP priority A% of Link BW Broadcast Video AF41 / 4* VoD AF42 / 1 Streaming TV AF43 / 1 Class1 - Video Ad Traffic AF31 / 2 B% of Link BW

Content Distribution (Music, Video) AF11 / 0 (tail-drop) Little/no

VoIP Bearer EF / 5 oversubscription Videoconferencing (Video/Audio Bearer) CS5 / 5

VoIP Signaling (incl. video conferencing) CS3 / 3 Class2 - Business Prioritized Data Services (inc. Commercial AF21 / 2 Critical Services) C% of Link BW Residential Data Services CS0 / 0 (WRED-DSCP/EXP) Litmited

Gaming CS 0 / 0 oversubscription Other Data CS0 / 0 Class3/ Default Network Control - Routing CS6 / 6 D% of Link BW Service Provisioning, Control & Mgmt. CS2 / 2 same priority Network Management CS2 / 2

• Network SLAs • Delay: May affect Contribution • Jitter: Bounded by receiver buffer size (IP-STBs up to 200 ms, DCM up to 100 ms) • Packet-loss: Critical for compressed services. IPTV packet loss rate < 10-6 (one noticeable artifact per hour of streaming @ 4 Mbps). No packet loss for Contribution services

• Real-time Video Traffic • Not oversubscribed • Not congested

• Video on Demand • Can be oversubscribed with CAC • More and more replaced with adaptive video (lower quality during busy hour) • Less priority than Broadcast Video

• For non-multicast traffic and point to point feeds: • Native IP or MPLS, L3VPN, E-Line, P2P TE, etc

• For multicast, multipoint topologies: • LSM (Label Switched Multicast) • P2MP TE global • PW over P2MP TE • mLDP • IP IP mVPN • Native (PIM SSM) Multicast • mVPN P2MP TE MPLS (LSM) MLDP mVPN

• Diverse applications for Multicast with different requirements means diversity of solutions: • Contribution • Dynamic circuit setup with bandwidth guarantees • Distribution (e.g. IPTV, Cable CHE to RHE) • IP Multicast distribution from centralized servers • Managed Enterprise Services, Video Wholesale • Multicast VPN • No single, one-size-fits-all, Multicast design model • Varying requirements, even for the same application • Depends on factors like rate of joins, topology • IP Multicast is an important service • Purely L2 solutions have limited value

Contribution Distribution Managed Enterprise mVPN PIM mode SSM only SSM only SM and SSM #S(ources) per G(roup) 1 or 2 1 or 2 1 or 2 #(S, G) #(S, G) < 1000 #(S, G) < 1000 100s (S, G) per VPN; 100s of (multicast source states) VPNs < 100 (cable)

Receivers per G(roup) <10 Millions 100s of sites; potentially Hundreds (cable) 1000s MDT dynamism 100s of new trees per day; trees Static trees MDT is dynamic; joins and static once established leaves may impact core mVPN requirement No Yes Yes Offload routing Yes No No Path separation Yes Yes Yes Admission control Yes No No FRR or equivalent Yes Yes Yes

Characteristic Plain IP Multicast p2mp MPLS TE mLDP

Convergence < ~500ms ~50ms < ~500ms (< 50ms with MoFRR path separation) (~50ms with p2p MPLS LP) Offload routing    (IGP metric based traffic engineering) (IGP metric based traffic engineering)

Path separation  (MoFRR)   (MoFRR) Admission control and bw reservation  (RSVP)   Scalable mp2mp    Initiator Receiver Source Receiver Application Ideal for single-source multicasts with Ideal for single-source multicasts Ideal for dynamic, receiver-driven many leafs with few leafs multicasts with many leafs

Insertion Secondary Distribution Contribution Enterprise VPN

BRKSPV-2919 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 33 LSM - Label Switched Multicast Multicast VPN solutions • Multicast VPN’s are built on a tunnel infrastructure through the provider core • Four major components • These are Multipoint Tunnels • Encapsulation • IP/GRE • Multicast route signalling is using the Tunnel or an out of band signalling protocol, like • MPLS BGP or PIM over TCP • P-core Tree-building method • PIM • RSVP TE • mLDP

• Auto-Discovery MVPN member PE PIM IP/ PIM • PIM BGP GRE • BGP p-to-mp TE MPLS BGP • PIM PE-PE C-mcast route Exchange (LSM) mLDP • PIM • BGP A B C D

B. P-Tree Building A. Encapsulation

C. Auto-discovery D. C-mcast route exchange

BRKSPV-2919 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 36 VPN (“Customer”) IP Multicast packet Encapsulation S(ource) address G (roup) address • There are 2 tunnel encapsulation options: IP/GRE encap

S (ingres PE source address)

G (P-tree group) • IP (GRE) Ethernet IP/IPv6-etype

• First implementation choice Unicast source MAC

• Driven by desire to support unmodified core network: Multicast destination MAC No support for MPLS label switching – but IP multicast • Historically still widely deployed VPN (“Customer”) IP Multicast packet • MPLS S(ource) address • Now preferred choice when customer is using unicast MPLS G (roup) address • Leverage same forwarding plane as unicast 1 MPLS label from mLDP/RSVP “FEC” • Used in all new deployments (since ca. 2012/2013) (tree identifier)

Ethernet MPLS-etype

Unicast source MAC

Unicast/Mcast destination MAC

B. P-Tree Building A. Encapsulation

C. Auto-discovery D. C-mcast route exchange

BRKSPV-2919 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 38 Multicast Tree types and building options PE • P-Tree types • Point-to-Multi Point (P2MP) – “any to any” • Multi Point-to-Multi Point (MP2MP) – “source specific”

• P-Tree building protocols P • IP/GRE encapsulation • PIM PE • LSM – MPLS encapsulation • RSVP-TE • In contrast to PIM/mLDP, leaves are specified at root PE i.e. head-end driven • Supports P2MP trees PIM / mLDP / RSVP-TE • Only option that supports constraint-based routing for hop by hop tree building • mLDP • Receiver-driven (like PIM) • Extensions to LDP • Support both MP2MP and P2MP LSPs

Source Service Edge Core Distribution/ Receivers Label mapping P2MP: Access (FEC: 200, Root: R2, Label mapping P2MP: Label: L1) (FEC: 200, Root: R2, Label: L5)

R4 (PE) R6 (CE)

R3 (P) R1 (CE) R2 (PE)

Label mapping P2MP: R5 (PE) R7 (CE) (FEC: 200, Root: R2, Label: L7)

Leaf nodes initiate P2MP LSP setup • Send mLDP Label Mapping message towards the root, relying on unicast routing • Label Mapping message carries the identity of the LSP, encoded as P2MP FEC Intermediate node along the path to root propagate mLDP label mapping messages

BRKSPV-2919 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 40 MPLS Traffic Engineering Source Service Edge Core Distribution/ Receivers RSVP Messages Access PATH ERO: R2-R3-R4 • HE router originates RSVP R4 (PE) R6 (CE) PATH messages

R3 (P) • Non-aggregated option R1 (CE) R2 (PE)

• One PATH per destination PATH ERO: R2-R3-R5 R5 (PE) R7 (CE) • Each destination responds

with RESV message and Label Source Service Edge sharing Core Distribution/ Receivers label mapping Access RESV Label: 44 RESV • Branch nodes merge labels Label: 33 R4 (PE) R6 (CE) • HE receives messages R3 (P) from all destinations R1 (CE) R2 (PE)

RESV Label: 33 R5 (PE) R7 (CE) RESV Label: 55

• Similarities • Both are based on existing MPLS technology (LDP or RSVP TE)

• Both require changes to support Multicast mLDP can build • Both support FRR the largest trees

• Differences RSVP-T P2MP • RSVP-TE Can build trees with • Support bandwidth reservation complex/alternative paths • No MP2MP support • Periodic refresh of states • MLDP • Support MP2MP LSPs • TCP based protocol - no periodic refresh of states • Less signaling and state to support an LSP, more scalable.

(Banyan) (Sequioa)

• PIM/mLDP scales to larger trees Headend • N = # tailend LSR = #PE • PIM/mLDP P2MP: ~1, RSVP-TE P2MP: ~N LSR • Full mesh of RSVP-TE P2MP LSP: ~(N * N) • Bidir-PIM/mLDP MP2MP: ~1 • Summary: No scaling impact of N for PIM/mLDP • Failure/recovery: • Faster convergence/reoptimization in PIM/mLDP • PIM/mLDP: Failure in network affects only router in region (eg: in pink region). • RSVP: impact headend and all affected midpoint and tailends for RSVP-TE reoptimization. • Join/leave Rcv • Also end-to-end impact in TE Rcv Rcv

BRKSPV-2919 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 43 RSVP-TE P2MP benefits over PIM/mLDP Src • Sub 50 msec protection? Headend • Also feasible for PIM/mLDP! LSR • Load-split traffic across alternative paths • Example: No link fast enough for three flows • RSVP “CSPF” (Constrained Shorted Path First) automatically calculates load – split • Guaranteed PIM/mLDP multi-hop load splitting almost impossibe with ECMP, impossible with non-ECMP alternative paths • Block (stop) trees on redundancy loss • Consider mix of high-prio and low-prio trees. • With full redundancy, enough bandwidth to carry all trees (with load-splitting) Rcv Rcv • On link-loss, reconverge high-prio, block low-prio Rcv

B. P-Tree Building A. Encapsulation

C. Auto-discovery D. C-mcast route exchange

• Auto discovery mechanism is independent of core tree building and customer mcast routes exchange VPN3 VPN1 BGP Route methods reflector PE for BGP • Candidate protocols are PIM and BGP

• If PIM is also the P-Tree building protocol, it makes sense to use it also for auto discovery (as PIM is leaf PE VPN1 driven) VPN2

• BGP also effective for auto discovery

B. P-Tree Building A. Encapsulation

C. Auto-discovery D. C-mcast route exchange

BRKSPV-2919 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 47 Multicast Signaling CE PIM VPN2 (S,G) Exchanging Customer multicast routes join • Mechanics used for customer multicast route exchange PE is independent of core tree building and auto discovery PIM/BGP methods (S,G, “VPN2”) join • In RFC6513 (“draft”-rosen) two options are specified: (S,G,”VPN”) to P-tree mapping • Option 1: Per-mVPN PIM peering among the PEs PE • This is deployed since 2003

PE • Option 2: BGP • Analogous to RFC4364 exchange of VPN-IPv4 routes, PIM (S,G) VPN2 but with new MVPN AFI/SAFI join • In recent deployments (since about 2013) CE Receiver

• Aggregation • Aggregate traffic into a single tunnel: less state in P-routers • Build individual trees for each multicast group: optimal forwarding, diagnostics • Configurable compromise: amount of P-router state vs. optimal forwarding

• Migration from existing GRE MVPNs • Encapsulation: GRE -> MPLS • P-Tree building protocol: PIM -> RSVP-TE or mLDP

• Change in tree building protocol and encapsulation method does not 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 • Not true anymore with CE-PE BGP signaling being introduced as an option

• Redundant components with fast recovery software • Interface Linecard / Chassis redundancy – (with redundant attached links) • Expensive. Does not protect against BER (Bit Error Rate) loss on links

• Network reconvergence (L2 / L3) • Unicast / Multicast “fast re-routing” • Multicast naturally more difficult than unicast: need to rebuild trees (not only routing tables) • Subsecond. Depends on number of routes and (multicast) number of multicast trees) • Unicast re-route optimizations: LFA • RSVP-TE backup tunnels (unicast and with mLDP/RSVP-TE p2mp) • Build p2p backup tunnel for failing links/nodes. Sub 50 msec protection.

• Live-Live = “path protection”

• IPoDWDM Proactive Protection • Discover failing links proactively by measuring FEC failure rate

Core Router Edge Core Video Distribution Core Source Router Router

Core Fast Convergence (FC) = Network reroutes: Router IGP convergence (optimized code) and/or LFA (Loop Free Alternative – local calculation) For link or node failure/recovery in core network.  Lowest bandwidth requirements in working and failure cases  Lowest solution cost and complexity ! Requires fast converging network to Minimise visible impact of loss  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!)

BRKSPV-2919 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 52 Fast IGP Convergence Edge Distribution  Core Router Edge Core Video Distribution Core Reconverged Source Router Router Stream

Tests show for Sec Distribution MoFRR delivers consistent sub 50ms Convergence @ no operational cost

• Tested with 2500 IGP prefixes and 250k BGP routes, IOS XR 3.9.1

. Least expensive topology for live-live services (minimum redundancy) . All links and nodes are shared for both copies, but can maintain Live-live guarantee . No single network (link/node) failure affects both copies to any receiver . Network wide: link/nodes can be shared by both copies (colors). . Traffic for both colors needs to flow in opposite directions then.

When topologies become more complex. Maintaining live-live guarantee is more difficult Merge/Rcv1

Spliter Merge/Rcv2

Redundant Encoder

• ECMP – best design for live live services – common in europe • Hypercube / leaf & spine, …

• Support three classes of services • Standard-customer – across full topology • Single stream resilience – attach via Split/Merge into both topology parts • Live-Live – attach via separate links into both topology parts. Standard customer Standard customer CE site B CE site A CE CE

Single stream Split/ Single-stream live-live resilent Merge live-live resiientl. customer customer CE site A Split/ CE site B Merge

Live-live customer Live-live customer CE site B CE site A Zero-Loss PE PE P BRKSPV-2919 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 56 Engineered dual-plane networks what if your network looks like this ?

. If Network has dual routers per site and enough links between sites: . Network can be made dual-plane. May need link rehoming . Plan (on whiteboard) . Color links/nodes: red, green, excess: black . BUILD CONTIGUOUS RED, GREEN TOPO ACROSS ALL SITES

. If Network has dual routers per site and enough links between sites:

. Network can be made dual-plane. May need link rehoming Links requiring . Plan (on whiteboard) rehoming . Color links/nodes: red, green, excess: black . BUILD CONTIGUOUS RED, GREEN TOPO ACROSS ALL SITES

. Reparent links as necessary

. Leaf sites need one red and one green link

. Deploy One IGP topology solution: make black links very expensive in multicast IGP. Three topology solution easier. All links (red, green, black) into base topology, red/green into additional IGP topologies.

1 ( )

CR 2

Transponder Integrated into Routers/Switches

End-to-End Proactive G.709/FEC Service Protection

CRS-1

• IPoDWDM reduces CAPEX Router/S MSTP witch • Less components, shelves, processor cards • IPoDWDM reduces OPEX • Less shelves, less rack space, less power, simplifies troubleshooting • Green – reduction in power/G by a factor of 2.5 • 100G same power and footprint as 40Gig • IPoDWDM enhances Resiliency • Less Opto Electronic Components, enhanced fault recovery features

Working Switchover Protected Working path Protect path path lost data path

IP / optical integration enables the WDM LOF SR port Near-hitless capability to identify degraded link port switch on using optical data (pre-FEC BER) and on router

start protection (i.e. by signaling to the router BER IGP) before traffic starts failing, BER FEC achieving hitless protection in many FEC limit FEC limit cases Trans- ponder

FEC Protection

Router Has No Visibility into trigger Corrected bits Corrected Optical Transport Network bits Corrected Optical impairments Optical impairments WDM WDM Proactive protection 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

• How do I get IP multicast across Internet ? • No IP multicast in Internet. • GRE traditional solution, but • User are not network operators: Can not configure GRE tunnels • Users are not PC administrators. Could not even get GRE tunnel software to work even if they would find it. • How do I get IP multicast across Campus without IP multicast • WAN connection too slow for unicast copies to every receiver in campus • How to get IP multicast through home NATs ? • GRE does not make it well through NATs • How to get IP multicast across WLAN • Most hotspot/home WLAN can not intelligently do IP multicast • 802.11 standard has transparent packet retransmission for unicast. Not for multicast • 802.11 multicast inefficient: Sending with highest power. Can not use beamforming.

• AMT-Relay: Sender-side AMT tunnel interface AMT Tunnel • Multipoint – one tunnel for all receivers multicast • AMT Gateway: Receiver side AMT tunnel interface capable • AMT tunnels are UDP – get through NATs. • UDP encapsulated IGMP joins Gateway -> Relay Non • Some more signaling to support anycast relays etc.. Non multicast • UDP encapsulated multicast traffic Relay -> Gateway multicast

• Cisco CRS supports AMT relay HAG NAT • Cisco CSR1kv and ASR1000 support relay & gateway

• Open Source Libraries available for AMT gateway • To directly integrate into Applications.

• Service provider need to simplify networks for better scale, reliability, OPEX • “Segment Routing” (SR) is next-generation after RSVP-TE / IGP-engineering ?! • BIER – “Bit Indexed Explicit Replication” is to PIM/mLDP what SR is in unicast.

• Manage unicast routing: • Millions of routes in Internet. But can can get rid of them via LDP/BGP, SR, LISP,…

• Manage multicast routing: • One multicast tree (S,G) tree per Video program • Aggregation in MVPN possible but with a lot signaling complexity (Rosen, BGP,…) • Need different trees in core for different set of receivers (egres-PE) and ingres-PE (headends).

• How about no multicast trees in transit nodes at all ??? • Tree state is bad because it depend on what applications are running (sender/receivers) • Just routes for multicast traffic independent of what traffic flows (like unicast)

Packet forwarding (high level) B/32 Ingres-PE sends multicast packet with BIER header LSA BIER including bitstring. 1 - A/32 Domain Each egres-PE is one Bit. LSA 2 – B/32 LSA 5 – E/32 Control plane LSA E/32 LSA Assign a unique Bit Position from a BitString to 3 – C/32 each BFER in the BIER domain. 4 – D/32

C/32 Each BFER floods their Bit Position to BFR-prefix D/32 mapping using the IGP (OSPF, ISIS) BitMask Nbr 5 4 3 2 1 Build BitMask forwarding table in ever P router. 00001 F Direct Nbr -> egres-PE bits 00100 B BitString 01000 C 10000 D

Forwarding rulesNbr for BIER on everyNbr router Nbr 0111 B &0111 0011 C &0011 0001 D &0001 AND AND AND D • For every direct Nbr, compare0100 (AND)E &0100 bitstring 0010 F &0010 0001 0001 in 0111Nbr forwarding entry0111 with Bits in packet0011 header A B C 0100 • Bits in Nbr Bitstring indicate egres PE (called BFER) reachable via this Nbr. • If common bits. Forward. F • For forwarded copy to Nbr, reset all bits in packet E header that are not in the Nbr Bitstring 0010 0010 0100 • Avoid duplicates Nbr 0011 C AND B

Nbr Nbr Nbr 0111 B &0111 0011 C &0011 0001 D &0001 AND AND AND D 0100 E &0100 0010 F &0010 0001 0001 0111 0111 0011 A B C 0100

F E 0010 0010 Nbr 0100 0011 C AND B

• No multicast trees in network core.

• Forwards with MPLS or IP encapsulation.

• No need for LDP/RSVP-TE/mLDP/PIM. • Just IGP extensions to create routing entries for Bits in bitstrings

• Packet bitstrings in actual products most likely 256 bits • Automatic Ingres replication when network has more egres PE. • Reduces traffic load to 1/256 = 0.3% - good enough

• Roadmap of products -> ask PMs, planned for 2018.

• IETF working group (BIER)

• Cheers!

Primary Stream FEC Stream Core Edge Distribution Distribution Video Video Receivers Source Rerouted Primary Stream

• Application / middleware function

• FEC adds redundancy to the transmitted data to Allows the receiver to detect and correct errors (within some bound) without the need to resend any data  Enables hitless recovery from network interruption  No requirement for network path diversity – works for all topologies  Requires fast converging network to minimise FEC overhead 50 msec easy. 2 sec expensive/difficult  Higher overall bandwidth consumed in failure case compared to live / live  Incurs in delay – longer outages require larger overhead or larger block sizes (more delay)

• Dual transmission of same traffic via diverse paths • Network designs supporting this often called “Live-live” • Many options: 2 separate networks, RSVP-TE/P2MP for MPLS

• “Merging techniques” • In video equipment: SMPTE ST 2022-7 - hitless

MERGE

Studio Studio

Video Head-End Core/Distribution Edge Access VQE-S VQE-C HGW STB DSLAM

Encoders DCM VQE-C HGW STB DSLAM • RTP support at head-end VQE-S - Real-Time Encoders or Cisco DCM (Digital Content Manager) – RTP encapsulation • VQE-Client embedded in Set-Top Box join different channels - Primary function: facilitate error repair - Unicast - Generate per-channel, per-client, transport quality reports (loss, delay, jitter) • VQE-Server at network edge joins multicast channels - Primary function: Caches channel content and respond to VQE Service requests (RET, RCC) from Clients - Collect per-channel real-time reception quality reports (loss, delay, jitter,...)

BRKSPV-2919 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 77 Summary Transport service requirements and solutions Studio and Remote Primary Secondary Consumer Contribution Post Production Distribution Distribution Experience Production

Professional Contribution Professional Media Multiservice “IP-NGN” networks Home networks Media Network Networks Networks IP, PIM, QoS RSVP-TE IP, PIM, QoS IP, PIM, MPLS, mLDP, QoS IP, QoS SDN, App Traffic-Eng, SLA, SDN, App integration MVPN, Simplicity Scale Simplicity, Scale integration CAC SMPTE 2022-7 SMPTE 2022-7 SMPTE 2022-7 FEC Non-blocking fabric BIER Non-blocking fabric BIER AMT AMT Video Monitoring Video Monitoring Video Monitoring Video Monitoring Video Monitoring VQE

• BRKIPM-2239 • Multicast and Segment Routing

• BRKSPV-2160 • Content Delivery Networks (CDN): Caching Principles, Architecture, and Resource Optimization

• BRKSPV-2999 • ABR - Adaptive streaming and your network; a match made in heaven?

• BRKSPV-1222 • IP Fabric Architectures for Video Production and Broadcast workflows

• BRKSPV-3112 • The transformation of media & broadcast video production to a Professional Media Network

• Please complete your Online Session Evaluations after each session • Complete 4 Session Evaluations & the Overall Conference Evaluation (available from Thursday) to receive your Cisco Live T-shirt • All surveys can be completed via the Cisco Live Mobile App or the Don’t forget: Cisco Live sessions will be available Communication Stations for viewing on-demand after the event at CiscoLive.com/Online

• Demos in the Cisco campus

• Walk-in Self-Paced Labs

• Lunch & Learn

• Meet the Engineer 1:1 meetings

• Related sessions