IP Multicast and IPTV Customer Day IP Multicast Summit 06 ... · MC Pkt L20 L30 “Swap” “Pop” Same forwarding (HW requirements) with mLDP / RSVP-TE Initial: “Single label

© 2007 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialSession IDPresentation_ID 1

IP Multicast and IPTV

Customer DayIP Multicast Summit

06/13/2008

Toerless Eckert

Technical Leader

[email protected]


Content

Cut down version of Multicast IPTV Networkers 2008 (Orlando) Breakout Session (in two weeks)

Session BRKVVT-2102

Will provide full presentation


Cisco ‘IPTV’ Solutions

Wide range of IPTV related solutions in various stages of customer facing documentation

Basic IPTV for Wireline and Cablehttp://www.cisco.com/en/US/products/ps6902/prod_release_notes_list.html

VAMS WhiteTip(CIC, Tivoli, Netcool, ANA + CMM)http://www.cisco.com/en/US/products/ps9518/index.html


AgendaIntroduction

Architectural overview

IP multicast primer (SSM)

Transit Transport Design options

Resiliency

Broadband Edge

Admission control

Channel changing


IntroductionIPTV and

IP multicast


…however transport network transits packets ..“Native IP multicast”, MPLS, L2, optical

IP multicast sources:Encoder, Transrater, Groomer, Ad-Splicer, …

IP multicast receivers:Transcoder, Groomer, Ad-Splicer, eQAM, STB

IP == IPv6 (Japan) or IPv4 (RotW rest of the world)No address exhaustion issue (SSM)No/slow move to IPv6 for IPTV in RotW

Broadcast IPTV = IP multicast


Deployment strategyOverview, Recommendation

NetworkAdd IP multicast service to your network (for any application)

Choose transport methods based on SLA and operational requirements/preferences

Native IP multicast, MPLS, L2, mix

Solution should minimize involvement in provisioning of individual applications/services

IPTV servicesStart with traditional broadcast TV

Investigate extending IPTV and add other (IP multicast) services

More RoI on network layer investment


Additional service/application opportunitiesAcross common SSM IP multicast service

No need to change the IP multicast functionality in the networkMay want improvements on optional elements (RSVP, …)

Extending IPTV broadcast serviceDynamic redundancy (regional to national) Variety of reach of transmission (src->rcvr)

Groomer/Transraters, Ad-SplicersIPTV broadcast vs. Switched Digital Video, oversubscriptionWholesale, dynamic, international channels

Other servicesCommercial (MVPN)Content pre-provisioning to VoD server, STBMulticast in Internet Service (eg: To PC)Voice conferencing, gaming, surveillance, …


Architectural Overview


50,000 feet architectureIPTV and multicast

“Network Plane”

IPTV “Services Plane”

IP multicastsource IP multicast

receiver

IP multicastService gateway

Receive/process/sendEg: Ad-Splicer, Dserver, Transrater,…

The network

Sign

alin

g

Sign

alin

g

Sign

alin

g

Service Interface

Multicast trafficMulticast traffic


50,000 feet architectureGoals

Separate “network” and “services” planeNetwork = shared infrastructure for all services

Routers, switches, optical gear, NMS, …IPTV = encoders, groomers, splicers, VoD server, STB, …

Often operated by different entity/group than networkIP multicast

Allow to attach service plane devices (sourcing, receiving) anywhere – global, national, regional, local. Start/stop sending traffic dynamically, best utilize bandwidth only when needed.

One network technology usable for all services (IPTV, MVPN, …)Different transport options for different services possible

Enable network operator not to provision/worry about individual programming.

Service InterfaceHow network & service operator infrastructure interacts with each otherSLA of IP multicast traffic sent/received, Signaling used


IP multicast primer (SSM)… as required for IPTV…


Protocols and Services…and IP multicast

multicast / multipoint protocolsBetween routers, switches, ..

“Only of interest to network operator”

PIM-SM, MSDP, (M)BGP, AutoRP, BSR, mLDP, RSVP-TE, …), IGPs(OSPF, ISIS), …

multicast servicesHow end-devices can use IP multicast

“Of interest to network and service operator”

ASM, SSM (and protocols “IGMP/MLD”)

Service operator just need to add SLA requirements!


IP multicast services

ASM: “Any Source Multicast” (1990, rfc1112)

The “traditional IP multicast service” (collaborative)Sources send packets to multicast groupsReceivers join to (G) groups, receive from any source

SSM “Source Specific Multicast” (~2000, rfc4607/4604)The multicast variant for IPTV (or other “content distribution”)Unchanged: Sources send packets to multicast groupsReceivers subscribe (S,G) channels,receive only traffic from S sent to G Primarily introduced (by IETF) for IPTV type services

Because of limitations of standard (protocol) model for ASM


IP multicast servicesIssues with ASM – resolved with SSM

ASMDoS attacks by unwanted sources

Address allocation (IPv4 only, not IPv6)

Standard protocol suiteComplexity of protocol operations required

PIM-SM (RPT+SPT+Switchover), RP redundancy, announce, location

MSDP (RPF), BGP congruency,

Interactions with MPLS cores, bandwdith reservation, protection

Scalability, Speed of protocol operations (convergence)RPT + SPT operations needed


End-to-end protocol viewHistoric development

STBHomeGatewayDSLAMPE-AGG

Aggregation Home NetAccessNationalcontent

Regional/ localcontent

Old designs: Use non-IP satellite distribution, inject regional / locally“National IP network can not transport video (cost, function)”

Current designs: use regional/local injection only for regional/local contentThe national core IP network can transport video optimallyMay also want to feed local/region back across core (national redist)

ReceiverDisk in every Agg. region


End-to-end protocol viewexample: L3 aggregation

PIM-SSM (S,G) joins IGMPv3 (S,G) membership

STBHomeGateway

BB typespecificPE-AGG

Core Distribution/ regional

Aggregation Home NetAccessExternalNetwork

Eg:Contentprovider

Headend

Video encoder/multiplexer

First hoprouter

IGMPv3proxy routing

IGMPv3snooping

IGMP:{Limits}

{Static-fwd}PIM-SSMPIM-SSM

L3 Transport Options in clouds:Native: PIM-SSM or MVPN/SSM

MPLS: LSM / mLDP RSVP-TEOpt.

SourceRedundancy

Content injection:External, national, regional, local

Dis.Edge Rtr

IGMPv3SSM

PIM-SSM

Same choices for all access technologies Different by access technology

?


Transit Transport design options


Transit technologies for IPTVSummary / recommendations

Native PIM-SSM + RPF-VectorMost simple, most widely deployed, resilient solution.

MVPN-GREAlso many years deployed (Cisco/rosen specification). Recommended for IPTV when VRF-isolation necessary !

mLDPRecommended Evolution for MPLS networks for all IP multicast transit:

‘Native’ (m4PE/m6PE) ‘Direct-MDTMVPN-mLDP’ (IPv4/IPv6)

RSVP-TE P2MPStrength in TE elements (ERO/CSPF + protection)Recommended for limited scale, explicit engineered designs, eg: IPTV contribution networks.


OverviewElements of transport architecture for tree building• C(ustomer)-tree building protocols

IPTV: IGMPv3 / PIM-SSM• P(rovider)-tree (PMSI) building protocols

Native: PIM-SSM/SM/Bidir, MPLS: mLDP, RSVP-TE• PE mapping: C-tree(s) to P-tree

1:1/N:1 (aggregation) ; ‘native’/VPN (L2, L3) ; static/dynamic• PE-PE (“overlay”) tree signaling protocols

Optional PIM or BGP (extensions)Not needed: native IPv4/IPv6, ‘direct-MDT’ mLDP, static mapping

PE1 P1

PE2 CE2P2

P4 PE3 CE3Upstream PE =Headend LSR

Tailend LSRs =Downstream PEsCE2

Content Content SourceSource

ReceiverReceiver

ReceiverReceiver



PE-1

PE-2

PE-3

P-4CE-1

CE-2

CE-3

MPLS Core

ReceiverReceiver

ReceiverReceiver

IPv4IPv6

IPv4IPv6

IPv4IPv6

MPLS traffic forwarding

L100

“Push”

MC Pkt L20

L30

“Swap”

“Pop”

Same forwarding (HW requirements) with mLDP / RSVP-TE

Initial: “Single label tree” for both non-aggregated & aggregated

No PHP: receive PE can identify treePut packet after pop into correct VRF for IP multicast lookup

MC Pkt

MC Pkt

MC Pkt

MC Pkt

MC Pkt

© 2007 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialSession IDPresentation_ID 22© 2006 Cisco Systems, Inc. All rights reserved.


PE-1

PE-2

PE-3

P-4CE-1

CE-2

CE-3

MPLS Core

[email protected]

ReceiverReceiver

ReceiverReceiver

IPv4

mLDP signalingwith native and Direct-MDT

IPv4

IPv4

PIM-V4 JOIN: VRF IPTVSource= 10.10.10.1Group = 232.0.0.1




mLDP Label Mapping:FEC = S+ G+RD+ RootLabel=(20)

mLDP Label Mapping:FEC = S+ G+RD+ RootLabel=(20)

mLDP Label Mapping:FEC = S+G +RD+RootLabel=(100)

mLDP Label Mapping:FEC = S+G +RD+RootLabel=(100)

PIM-V4 Join: VRF IPTVSource= 10.10.10.1Group = 232.0.0.1

PIM-V4 Join: VRF IPTVSource= 10.10.10.1Group = 232.0.0.1

mLDP Label Mapping:FEC= S + G + RD + RootLabel=(30)

mLDP Label Mapping:FEC= S + G + RD + RootLabel=(30)

P2MP LSP“Root”

VRFIPTV

VRFIPTV

VRFIPTV

FEC: Forwarding Equivalency Class



PE-1

PE-2

PE-3

P-4CE-1

CE-2

CE-3

MPLSCore

ReceiverReceiver

ReceiverReceiver

IPv4

RSVP-TE P2MP signalingwith static native IPv4 to customer

IPv4

IPv4

PATH P4, PE2PATH P4, PE2

P2MP LSPHeadend

Static IGMP/PIM joinSource= 10.10.10.1Group = 232.0.0.1On interface to CE


Static IGMP/PIM joinSource= 10.10.10.1Group = 232.0.0.1On TE tunnel interface

Static IGMP/PIM joinSource= 10.10.10.1Group = 232.0.0.1On TE tunnel interface



TE tunnel config:ERO1: P-4, PE-2ERO2: P-4, PE-3

TE tunnel config:ERO1: P-4, PE-2ERO2: P-4, PE-3



RESV Label = 20RESV Label = 20




Label merge !Assign same upstream labelFor all branches of a tree

Label merge !Assign same upstream labelFor all branches of a tree



Virtualization considerations“Internet/Walled-garden” or L3VPN ?

L3VPN (MVPN) developed as multicast component of (unicast/RFC2547) L3VPN

Primarily for “Enterprise VPN” servicesUsable for IPTV as well (with MVPN-GRE or MVPN-mLDP)

Why ?Core - operator policy for all services (VPN, IPTV, Internet, …)Edge - wholesale considerations (VPN per wholesaler)

Service separation considerations (service per VPN)

Use only when needed !Native IP multicast with PIM-SSM or mLDP most simple! L3VPN adds complexity, convergence, reliability considerations.No need for L3VPN for access control policy reasons!

All possible with native IP SSM access control


L2VPN considerations

L2 preferred by non-IP ‘communities’IP address transparency (unicast only issue)

PE “invisible” = customer free to choose protocols independent of provider

Not true if PE uses PIM/IGMP snooping!

No (dynamic) P/PE L2 solution with P2MP treesVPLS: full-mesh/hub&spoke P2P pseudowire only

Non P/PE models available: single-hop protected pseudowires.

Recommended directions:TBD: Define how to use mLDP for L2VPN (VPLS)

Most simple: one mLDP MP2MP LSP per L2VPN (broadcast)

Recommend not to use IGMP/PIM snooping on L2VPN-PE!

Unless customer is provider (eg: broadband edge design)


Broadband edge IP multicast


End-to-end protocol viewDSL, L3 aggregation

PIM-SSM (S,G) joins IGMPv3 (S,G) membership

STBHomeGateway

Eg:DSLAMPE-AGG



Eg:Contentprovider

Headend


First hoprouter

IGMPv3proxy routing

IGMPv3snooping

IGMP:{Limits}


L3 Transport Options in clouds:Native: PIM-SSM or MVPN/SSM


SourceRedundancy


Dis.Edge Rtr

IGMPv3SSM

PIM-SSM



End-to-end protocol viewDSL, L2 aggregation

PIM-SSM(S,G) joins IGMPv3 (S,G) membership

STBHomeGateway

Eg:DSLAMPE-AGG

Core / Distribution Aggregation Home NetAccessExternal

NetworkEg:

Contentprovider

Headend


First hoprouter

IGMPv3proxy routing

IGMPv3snooping

IGMP:{Limits}

{Static-fwd}PIM-SSM

TransportOptionsOpt.

SourceRedundancy


IGMPv3SSM


L2

IGMPv3snooping

IGMPv3snooping


End-to-end protocol viewdigital cable (non DOCSIS)

PIM-SSM (S,G) joinsIGMPv3 (S,G) membership

CableSTB

Eg:DSLAMPE-AGG



Eg:Contentprovider

Headend


First hoprouter

IGMP:{Limits}


L3 Transport options in clouds:Native: PIM-SSM or MVPN/SSM


SourceRedundancy


Dis.Edge Rtr

IGMPv3SSM

PIM-SSM


eQAM HFC


Aggregation

End-to-end protocol viewDOCSIS 3.0 cable

PIM-SSM (S,G) joinsIGMPv3 (S,G) membership

IP/CableSTB

Eg:DSLAMPE-AGG


Home NetAccessExternalNetwork

Eg:Contentprovider

Headend


First hoprouter

IGMP:{Limits}

{Static-fwd}DOCIS CLIPIM-SSMPIM-SSM

L3 Transport options in clouds:Native: PIM-SSM or MVPN/SSM


SourceRedundancy


Dis.Edge Rtr

IGMPv3SSM

PIM-SSM


HFCCMTS

CM/(eRouter)

DOCSIS 3.0MulticastSignalingDSID/DSx


Auto Multicast Tunneling (AMT)Tunnel through non-multicast enabled network segment

Draft in IETF ; Primarily for SSMGRE or UDP encapRelay uses well known ‘anycast’ address

Difference to IPsec, L2TPv3, MobileIP, …Simple and targeted to problemConsideration for NAT (UDP)Ease implemented in applications (PC/STB) (UDP)

Variety of target deployment casesRelay in HAG – provide native multicast in homeGateway in core-SP – non-multicast Access-SPAccess-SP to Home - non-multicast DSLIn-Home only – eg: multicast WLAN issues

Nonmulticast

multicastcapable

AMT GatewayAMT Gateway

AMT RelayAMT Relay

AMT TunnelAMT Tunnel

Nonmulticast

HAGNAT


ResiliencyMoFRR/Live-Live


live-live with path diversityprinciplesGuarantee:

Transfer two copies of stream path separated - No single failure in network impacts both copies

Best: Two networktraditional finance deployment

Cheaper: Shared networkNatural diversity (ECMP, …) [MoFRR ECMP]Forced diversity (various solutions)

Splice and Join at EDGE of network (or segment)In actual source/receiversIn network devices (dedicated or in router)No need for time-critical operations in core

Live-live service:receive/deliver two copies, splice/join on customer side. Limited to customers whose app/equip. can support this

MoFRR/Zero-loss service:Splice/join within service – applicable to all customers.

Src…

Naturallyor

forceddisjoint

…Rcv

Protection D

omain

SourceOr

streamsplicer

ReceiverOr

streamjoiner


Basic MoFRRECMP, IGP upstreamJoin within network device (router) by switching which received copy to forward.

Switch is not zero loss – but (close to) 50msec

R1 MoFRR operationsExpect two RPF paths (from IGP/BGP)

ECMP Join to both RPF interfacesForward traffic from one of them.If used path is lost, switch to second

Various extensions consideredSwitchover based on traffic lossFull zero-loss (sequence number based join)Support for more topologies:

U-turn via LFA

Src

R1

RU1 RU2

Naturallydisjoint

Rcv

RH

Protection D

omain

R1a R1bU-turn attachment


Application side resiliency

FEC – Forward error correctionCompensate for statistical packet loss

Use existing FEC eg: for MPEG transport to overcome BER errors. Potentially applicable to sub 50 msec correction.

ARQ - RetransmissionsDone eg: with Cisco VQE – unicast retransmissions

Candidate large bursts of retransmissions

Multicast retransmissions would help improve

FEC/ARQ introduce delay !


Failure impact upon viewer experience

Very hard to measure and quantifyIf I frames or frame-information is lost, impact will be for a whole GOP

GOP can be 500 msec (MPEG2) ... 10 sec (WM9)

Viewing impact beyond single GOP possible!Encoding and intelligence of decoder to “hide” loss impact quality as wellIPTV STB typically larger playout buffer than traditional non-IP STBs:

Loss can cause catch-up: no black picture, but just a jump in the motion.

What “viewing” loss is acceptable ?Measured in #phone calls from complaining customers !?Standard: 1 artefact in two hours.


Admission control


Static vs. dynamic trees

1. “Broadcast Video”Dynamic IGMP forward up to DSLAM

DSL link can only carry required program!

static forwarding into DSLAM

Fear of join latency

History (ATM-DSLAM)

2. “Switched Digital Video”Allow oversubscription of PE-

AGG/DSLAM link

3. “Real Multicast”dynamic tree building full path

Source

HomeGateway

DSLAM

PE-AGGStat

ic (P

IM) t

ree

(1)

Stat

ic (P

IM) t

ree

(2)

IGM

P jo

ins

PIM

join

s

(3)

IGM

P jo

ins

IGM

P jo

ins


Switched Digital VideoWhy oversubscription of access links makes sense

Switched Digital VideoConsider 500…1000 users on DSLAMConsider 300 available TV programsMonitor customer behavior – what is being watched ?

Example (derived from actual MSO measurements)Some 50 TV programs almost always watched (big channels)Out of remaining 220 TV programs never than ¼ watched Never need more bandwidth than ~ 125 channels!

Dynamic joining towards core ?Todays offered content << #users aggregated -> worst case traffic will always flow.More a provisioning issue – and when content expands well beyond current cable-TV models


Admission control

Congestion must be avoidedInelastic: TV traffic can not throttle upon congestion

One flow too many disturbs all flows

Need to do per TV-flow admission control

Router-linksRouter local CLI solution

Strategic solution: RSVP

Already used for unicast VoD

Can only share bandwidth between unicast and multicast with RSVP

Broadband access (DSL link, Cable)Issues with L2 equipment (eg: DSLAM)


3. Fair sharing of bandwidth1GE

Multicast Call Admission Control

1GE

1GE

250-500 usersper DLAM

DSLAM

DSLAM

DSLAM

Cat7600

Example CAC use:

4. 250 Mbps for each CP250 Mbps Internet/etc

1. Three CPs

10GE

10GE

10GE

ContentProvider 1

ContentProvider 2

ContentProvider 3

ContentProviders

ServiceProvider

PayingCustomers

2. Different BW:

- MPEG2 SDTV: 4 Mbps - MPEG2 HDTV: 18 Mbps - MPEG4 SDTV: 1.6 Mbps - MPEG4 HDTV: 6 Mbps

MPEG4 SDTV

MPEG2 SDTVMPEG4 SDTV

MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

MPEG4 SDTV


MPEG2 HDTV

CP-1 (250Mbps)

CP-2 (250Mbps)

CP-3 (250Mbps)

Voice/Int/V

oD (250Mbps)

5. Simply add global costs

PE


Channel changing


Join Latency

Static forwarding (to PE-AGG, or DSLAM) To avoid join latencySometimes other reasons too (policy, …)

Bogus ?Hop-by-hop Join latency (PIM/IGMP) very low, eg: individual < 100 msec …Joins stop at first router/switch in tree that already forwards treeProbability for joins to go beyond PE-AGG very low !

If you zap to a channel and it takes ¼ sec more: You are the first guy watching this channel in a vicinity of eg: 50,000 people. Are you sure you want to watch this lame program ?

ImportantTotal channel zapping performance of system – Primetime TV full hour or (often synchronized) commercial breaks.Join latency during bursts might be worse than on average. (DSLAM performance)


Channel ChangingGOP size and channel changing

GOP size of N seconds causes channel change latency

USER OUTAGE EXPERIENCE>= N secondsCan not start decoding before next I-frame

GOP sizes > 0.5 sec required ?

Codec dependencies:How much bandwidth is saved in different codecs by

raising GOP size but keep the quality.


Video Quality Experience

Three functions (currently): Video Quality monitoring, FEC/ARQ support for DSL links, Fast Channel changeUses standards RTP/RTCP, FEC extensions.Fast channel channel by RTCP “retransmission” triggered resend of missing GOP packets from VQE (cached on VQE).

STBHomeGatewayDSLAM

PE-AGG

Core Distributionregional

Aggregation Home NetAccess

ASERVER VQE

multicast

Unicast/(multicast)

control

VQE Clientlibrary


Summary


Multicast and IPTVSummary

Design IP multicast WITH SSM as generic infrastructure service –for IPTV and beyondSelect transport design

Native IP multicast or mLDP (MPLS core) for most networksRSVP-TE P2MP for eg: contribution network

Understand your L2 broadband edge specificsIGMPv3 snooping and SSM + lots of options

Determine appropriate resilience supportPath selection

ECMP and multicast or multiple topologiesAdmission control

Router local and broadband specificChannel changing

GOP size, total performance


Q and A


IP Multicast and IPTV Customer Day IP Multicast Summit 06 ... · MC Pkt L20 L30 “Swap” “Pop” Same forwarding (HW requirements) with mLDP / RSVP-TE Initial: “Single label

Documents