Video Transport over IP Core Studio Fixed Secondary IP/MPLS Distribution Core Core IP/MPLS Core Home...

Video Transport pover IP

Marko Vukadinović, [email protected]

© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 1

Video Transport over IP

Market Overview

2

© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Video Service ProvidersTaxonomy & CharacteristicsTaxonomy & Characteristics

VideoStream

BandwidthStudio to Studio; BroadcasterStudio to Studio; Broadcaster

to Broadcaster

Uncompressed, Lossless

Very High bit-rate stream: SD (270Mbps), HD (1.5-3Gbps)

Content owner to provider

Compressed

Low/moderate bit-rate stream

Provider to subscriber i.e. Cable TV & IPTV

P-to-P and P2MP(unicast and multicast)

P2MP MPLS technology

e.g. Broadcasters, Studios

Low/moderate bit rate stream ~ same as secondary dist

P-to-P and P2MP(unicast and multicast)

MPLS & IP technology

Compressed

Low bit-rate stream: SD (3-4Mbps mpeg2, 2-3Mbps mpeg4), HD (16-20Mbps

mpeg2, 8-10Mpbs mpeg4)e.g. Contribution providers,

US national cable backbonesP-to-P for VOD (unicast) & P2MP for IPTV (multicast)

MPLS & IP technology

e.g. Service ProvidersContributionContributionContributionContributionPrimaryPrimary

DistributionDistribution SecondarySecondaryDistributionDistribution

3


# of end points

Video Service ProvidersMapping to Broadcast IndustryMapping to Broadcast Industry

PrimaryPrimaryContributionContribution• Increasing demand for localised content

• Service Control & Broadcast Quality gaining prominence

StudioStudio

FinalStudio

DistributionDistribution

Common core networkrequirements & designs

Quality gaining prominence• Increasing scale to end-customer

IP/MPLS

IP/MPLSCore Mobile

Studio Fixed

SecondarySecondaryDistributionDistributionIP/MPLS

Core

IP/MPLSCore

IP/MPLSCore Home

Network

FixedStudio

DCM

IP/MPLSCore

AccessN t k

VODcontent

distributingto scale

DCM

DCM

NetworkSuper

Head End(x2)

4


VOD

Head End(x10s)

Homex millions

VSO(x100s)

VOD VODDCM / VQE

Local Content Insertion

National Content Insertion

International & National

Content Insertion

SuperHead End

(x2)

Video Transport:Primary Technology challengesPrimary Technology challenges

1. Basic transportH hif h k IP MPLS i VPN?How to shift the packets … IP or MPLS, native or VPN?Type of provider impacts transport requirements

2. How to meet SLAs for video?2. How to meet SLAs for video?Main problem is management of loss due to reconvergence eventsNumber of potential deployment models and technology approachesPotential for lossless transport services

3. How to manage and monitor the service?The ability to verify that the IP network is delivering the required SLAs for ideo and to identif problem areas is ke to accelerating IPTVvideo, and to identify problem areas is key to accelerating IPTV

deployments

5



Transport and Edge design options

6


50,000 Feet ArchitectureIPTV and Multicast

IPTV “Services Plane” IP multicastIPTV Services Plane

IP multicastsource IP multicast

receiver

Service gatewayReceive/process/send

Eg: Ad-Splicer, Dserver, Transrater,…

ng ling

ng

Sign

ali

Sign

a l

Sign

ali

Service Interface

The network Multicast trafficMulticast traffic

7


“Network Plane”

50,000 Feet ArchitectureGoals

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

Routers switches optical gear NMSRouters, switches, optical gear, NMS, …

IPTV = encoders, groomers, splicers, VoD server, STB, …Often operated by different entity/group than network

2. IP multicast2. IP multicastAllow 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 )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.

3. Service Interface3. Service InterfaceHow network & service operator infrastructure interacts with each other

SLA of IP multicast traffic sent/received, Signaling used

8


Transport Architecture Elements

• C(ustomer)-tree building protocolsIPTV: IGMPv3 / PIM-SSM

P( id ) t (PMSI) b ildi t l• P(rovider)-tree (PMSI) building protocolsNative: 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 protocolsOptional PIM or BGP (extensions)Not needed: native IPv4/IPv6, ‘direct-MDT’ mLDP, static mapping

PE2C t tC t t

ReceiverReceiver

PE1 P1

PE2 CE2P2Tailend LSRs =

Downstream PEsCE2

Content Content SourceSource

9


P4 PE3 CE3Upstream PE =Headend LSR ReceiverReceiver

Combinations with L3 on PECurrent Widely Deployed

1. “Native IP multicast” (IPv4/IPv6)IPv4/IPv6 PIM-SSM in core

User side = core tree: No PE-PE signaling required.

“RPF-Vector” for “BGP free core”

2. “MVPN”(-GRE)Carries traffic across RFC2547 compatible L3 VPN.

With aggregationWith aggregation

IPv4 PIM-SSM/SM/Bidir in core (IPv4)

RFC2547 BGP ; GRE encap/decap on PE

PE-PE signaling required I-PMSI = Default-MDT ; SI-PMSI = Data-MDT

BGP extensions for InterAS and SSM support

10


pp

Transport architectureOverviewOverview

1.Common current deployments: Native PIM-SSM or MVPN

2.Emerging / Future alternatives:Support for MPLS multicast (LSM)( )

P2MP / MP2MP label switched delivery trees

mLDP (P2MP, MP2MP), RSVP-TE P2MP

Put traffic into a VPN contextAs a method of service isolation / multiplexing

L2 vs L3 on PE nodesL2 vs. L3 on PE nodesTo “integrate” better into an L2 service model

Redefine PE-PE signaling for MVPN

11


Redefine PE PE signaling for MVPN

MPLS traffic forwarding

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

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

IPv4IPv6

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

PE-2 CE-2

ReceiverReceiverIPv4IPv6 L100

MC Pkt L20

MC Pkt

MC Pkt

ContentContent

PE-1 P-4CE-1MPLS Core

“Pop”MC Pkt


PE-3

IPv4IP 6

“Push”L30

“Swap”

MC Pkt MC Pkt

12


CE-3

ReceiverReceiver

IPv6“Swap”

Note: Deployment timelines are dependent on the platform

mLDP signalingwith native and Direct-MDT

Note: Deployment timelines are dependent on the platformwith native and Direct MDT

PIM-V4 JOIN: VRF IPTVSource= 10 10 10 1mLDP Label Mapping:

FEC S G RD R t Source 10.10.10.1Group = 232.0.0.1

FEC = S+ G+RD+ RootLabel=(20)

mLDP Label Mapping:FEC = S+G +RD+RootPIM-V4 Join: VRF IPTV

PE-2

CE-2

ReceiverReceiver

IPv4Label=(100)Source= 10.10.10.1Group = 232.0.0.1

VRFIPTV

ContentContent

PE-1

PE 2

P-4CE-1MPLS Core

IPv4

PIM-V4 JOIN: VRF IPTVSource= 10 10 10 1

VRFIPTVContent Content

SourceSourcePE-3

IPv4

Source= 10.10.10.1Group = 232.0.0.1

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

P2MP LSP“Root” VRF

IPTV

IPTV

13

© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID © 2006 Cisco Systems, Inc. All rights reserved.

CE-3

[email protected]

ReceiverReceiver

IPTV

FEC: Forwarding Equivalence Class

RSVP-TE P2MP signalingwith static native IPv4 to customer

Note: Deployment timelines are dependent on the platformwith static native IPv4 to customer

Static IGMP/PIM joinSource= 10.10.10.1

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

PATH P4, PE2

Static IGMP/PIM join

Group = 232.0.0.1On interface to CE

ERO2: P-4, PE-3

PATH P4, PE3

PATH P4, PE2

RESV Label = 20

PE-2

CE-2

ReceiverReceiverIPv4

IPv4

Source= 10.10.10.1Group = 232.0.0.1On TE tunnel interface

ContentContent

PE-1

PE 2

P-4CE-1

MPLSCore

IPv4


PE-3

IPv4

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

RESV Label = 30

RESV Label = 100

RESV Label = 100

PATH P4, PE2

14


CE-3

ReceiverReceiverP2MP LSPHeadend

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

PIM/mLDP benefits over RSVP-TE P2MPExamples

1.Cost of trees (Signalling / Hardware State)

Examples

SrcH d d

N = # tailend LSR (#PE)Bidir-PIM/mLDP MP2MP: ~1PIM/mLDP P2MP: ~1

HeadendLSR

RSVP-TE P2MP: ~NFull mesh of RSVP-TE P2MP LSP: ~(N*N)Summary: No scaling impact of N for PIM/mLDPy g p

2.Locality:Affects convergence/reoptimization speed:PIM/ LDP F il i k ff l iPIM/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.R

15


Join/leave of members affect only routers up to first router on the tree in mLDP/PIM. Will affect headend and all midpoints in RSVP-TE P2MP.

Rcv

RcvRcv

RSVP-TE P2MP benefits over PIM/mLDPExamples1.Sub 50 msec protection ?

Also feasible for PIM/mLDP

Examples

Src

H d d2.Load-split traffic across alternative

paths (ECMP or not)PIM/ LDP t f ll h t t th “d ”

HeadendLSR

PIM/mLDP tree follows shortest path, “dense” receiver population == dense use of links

RSVP-TE P2MP ERO trees (RED/PINK) under control of headend LSR.

CSPF load split based on available bandwidth.“Steiner tree” CSPF modifications possible

3.Block (stop) trees on redundancy lossAssume high-prio and low-prio trees.With full redundancy, enough bandwidth to carry R

16


With full redundancy, enough bandwidth to carry all trees (with load-splitting)

On link-loss, reconverge high-prio, block low-prio

Rcv

RcvRcv

Other SignalingUnicast / RPF reachability for PIM/mLDPUnicast / RPF reachability for PIM/mLDP

• Native IPv4/IPv6, no RPF-vector:P/PE node: BGP (SAFI2) IPv4/IPv6 + IGP IPv4 (/IPv6) for upstream PEP/PE node: BGP (SAFI2) IPv4/IPv6 + IGP IPv4 (/IPv6) for upstream PE

• Native IPv4/IPv6 with RPF-vector, mLDPPE/P node: IGP IPv4 (/IPv6) for upstream PEP node: BGP (SAFI2) IPv4/IPv6( )

• L3VPN, MVPN-GRE/mLDP:P/PE node: IGP IPv4 route for upstream PEPE node: BGP VPNv4/VPNv6 routes (RFC2547)

InterAS MVPN: BGP ‘Connector-attribute’ (not shown)

BGP: S -> PE1IGP: PE1 -> P1

VPNv4/VPNv6 BGP“native” BGP

PE1 P1 PE2 RcvrSrc(S)

Native PIM-join: (S,G)RPF PE1

PIM-join (S,G)

17


RPFv: PE1MVPN PIM-join: (PE1,G’) – Default/Data MDT

End-to-end protocol viewDSL, L3 aggregation, gg g

Same choices for all access technologies Different by access technology

STBHomeEg:DSLAMPE-AGG

Core Distribution/ regional

Aggregation Home NetAccessExternalNetwork

Eg: Dis. STBGatewayDSLAMContentprovider

Video encoder/multiplexer

Edge Rtr

First hoprouter Content injection:

External, national, regional, local

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

IGMP:L3 Transport Options in clouds:

Native: PIM-SSM or MVPN/SSMOpt

18


IGMPv3proxy routing

IGMPv3snooping

IGMP:{Limits}

{Static-fwd}PIM-SSMPIM-SSM

Native: PIM-SSM or MVPN/SSMMPLS: LSM / mLDP RSVP-TE

Opt.Source

RedundancyIGMPv3

SSMPIM-SSM

End-to-end protocol viewDSL, L2 aggregation, gg g

Same choices for all access technologies Different by access technology

STBHomeEg:DSLAMPE-AGG

Core / Distribution Aggregation Home NetAccessExternal

NetworkEg: STBGatewayDSLAM

Contentprovider

Video encoder/multiplexer

L2

PIM-SSM

First hoprouter Content injection:

External, national, regional, local

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

Headend

IGMP:TransportO tiOpt

19


IGMPv3proxy routing

IGMPv3snooping

IGMP:{Limits}

{Static-fwd}PIM-SSM

OptionsOpt.Source

RedundancyIGMPv3

SSMIGMPv3

snoopingIGMPv3

snooping

IGMP Snooping vs. PIM Routing?

IGMP Snooping is TV Stream unawareIGMP Snooping is TV Stream unaware• is Multicast Address Learning to constraint flooding in LAN• relies of Multicast Router/Querrier to find the source• no source state, no monitoring, limited scalability

IP Multicast Routing is TV Stream aware• information on sources, incoming (iif) and outgoing (oif) interfaces• information on actives sources in kbps and pps

Switch# show ip igmp snooping groupsVlan Group Type Version Port List

p pp

-------------------------------------------------------------1 224.1.4.4 igmp Fa1/0/111 224.1.4.5 igmp Fa1/0/112 224.0.1.40 igmp v2 Fa1/0/15

GROUP

OUTGOINGPORT

20


g p

IGMP Snooping vs. PIM Routing?L3 Multicast provides excellent monitoring

Router# show ip mrouteIP Multicast Routing Table

GROUPSOURCE HOW LONG...(2.2.2.2, 233.6.6.6), 00:01:20/00:02:59, flags:sCTI

Incoming interface: GigabitEthernet3/3, RPF nbr 0.0.0.0Outgoing interface list:

GROUPSOURCE HOW LONG

INCOMING PORTSGigabitEthernet3/1, Forward/Sparse-Dense, 00:00:36/00:02:35TenGigabitEthernet4/1, Forward/Sparse-Dense, 00:00:36/00:02:35

Router# show ip mroute activeHOW LONGOUTGOING PORTS

pActive IP Multicast Sources - sending >= 4 kbps

Group: 224.2.127.254, (sdr.cisco.com)Source: 146 137 28 69 (mbone ipd anl gov)Source: 146.137.28.69 (mbone.ipd.anl.gov)

Rate: 301 pps/3543 kbps(1sec), 3654 kbps(last 1 secs), 3245 kbps(life avg)

Group: 233.6.6.6, ?Source: 2 2 2 2 (?) HOW MUCH STABILITY

21


Source: 2.2.2.2 (?)Rate: 389 pps/3933 kbps(1sec), 3833 kbps(last 20 secs),

3677 kbps(life avg)

O UC S

Layer 3 Multicast – is simple

QAM

Link Failure

Node Failure

Anycast Concept• native 1:1 stream protection• simple fast and automatic

22


EncodersDCMTV Headend

simple, fast and automatic• exists in L3 MC only• no RPF check in L2 MC

Layer 2 Multicast – is complicated

QAM

Link Failure

PIMAssert

Missing

X

MissingHellos

23



Layer 2 Multicast – chained VPLS?

VPLS

Node Failure QAMQAMVPLS

Li k

VPLSVPLS

VPLSVPLS

Link Failure

No HelloAssert

VPLS VPLSSourceFailure

X

24


EncodersDCMTV Headend Discontiguous Subnets!!!

Layer 3 Multicast – IETF PIM SSMNode Failure

QAMQAMA/ IP Routingg• connection-less convergence• works automatically• possible using simple IP Routing

Link Failure

B/ MPLS FRR• connection-oriented • manual pre-provisioning• possible using Routed Pseudowire

SourceFailure

p g

25



MPLS FRR for IPmc – Routed PW

QAMQAM

Li k

IPmc routing in AToM PW in TE tunnel• Cisco 7600 (SIP, ES20)• FRR for AToM

Hop-by-hopLink Failure Future Approaches

• IPFRR (dynamic, connectionless)• P2MP TE using RSVP (static)• LSM using mLDP (dynamic)

Hop-by-hopL3-terminated

AToM Pseudowires

• LSM using mLDP (dynamic)

26



(Aggregation) networksWhy L3 and not L2 (‘snooping’)Why L3 and not L2 ( snooping )

1.Better/easier path engineering / load sharing (IGP vs. STP)

2.P2P links inhibit PIM asserts / duplicates / reordering

3.L2 forwarding prone to address aliasing / unnecessary forwarding

Real SSM in IGMP snooping requires per IP (S G) forwardingReal SSM in IGMP snooping requires per IP (S,G) forwarding

4.L2: No hop-by-hop problem isolation

5.Snooping is not a verifiable / specified / standard protocol5.Snooping is not a verifiable / specified / standard protocol

long history of device incompatibilities

6.More predictable convergence / redundancy

7.Easier management (no standardized snooping MIBs exist)

8.Application optimized tree building policies and traffic constraining:

27


SSM (IPTV) , potentially SM, Bidir (for other services)

Static vs. Dynamic Trees

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

Source(1)(2)(3)

DSL link can only carry required program!

static forwarding into DSLAM

Fear of join latency ree

eeFear of join latency

History (ATM-DSLAM)

2.“Switched Digital Video” ic (P

IM) t

r

c (P

IM) t

re

PIM

join

s

gAllow oversubscription of PE-AGG/DSLAM link

3 “Real Multicast”

PE-AGGStat

Stat

icP

3. Real Multicastdynamic tree building full path

HomeGateway

DSLAM

join

s

join

s

P jo

ins

28


IGM

P

IGM

P

IGM

P


Resiliency options

29


Video SLA Requirements1. Throughput

Addressed through capacity planning and QOS (i.e. Diffserv)2 Delay/Jitter2. Delay/Jitter

Delay variation absorbed by jitter buffer at STBDesire to minimise jitter buffer to improve responsivity (reduce channel change

time)Controlled with QOS (i.e. Diffserv) – core contribution to delay variation is

insignificant compared to other factorsDiffserv is mature technology and premium transport service is known to offer ~

<1msec jitter end-to-end

3. Loss – controlling loss in the main challenge4. Service Availability

The proportion of time for which the specified throughput is available within the bounds of the defined delay and loss - a compound of the other networksbounds of the defined delay and loss - a compound of the other networks and network availability

30


MPEG – Impact of Packet Loss

1200

800

1000

rmen

t (m

s) SD-low -w orst

SD-low -best

SD-high-w orst

400

600

Dur

atio

n of

impa

ir SD-high-best

HD-low -w orst

HD-low -best

HD-high-w orst

HD-high-best

0

200

0 100 200 300 400 500

D ti f k t l ( )

D

• Increasing the GOP size, e.g. with MPEG-4, will result in a corresponding increase in the worst-caseDuration of packet loss (ms)

1. Jason Greengrass, John Evans and Ali C. Begen, "Not all packets are equal, part I: streaming video coding and SLA requirements," IEEE Internet Comput., vol. 13/1, pp. 70-75, Jan./Feb. 2009

increase in the worst case impairment duration

31


2. Jason Greengrass, John Evans and Ali C. Begen, "Not all packets are equal, part II: the impact of network packet loss on video quality," IEEE Internet Comput., vol. 13/2, pp. 74-82, Mar./Apr. 2009

Video SLA Requirements:Managing Lossg g

1. A number of technological approaches to achieve required SLA

Network approaches to reduce loss:d xity

Range of viable engineering options may vary by type of video distribution, Network approaches to reduce loss:

fast convergence, fast rerouteApplication approaches to recover from loss experiences: FEC, Temporal Redundancy, Spatial RedundancyN t k h f i i

Cos

t and

Com

plex

N b f ibl

service or content

Network approaches for engineering spatial redundancy

2. Number of network deployment models to support each approach

3 Application level approaches may

Number of possible approaches, or combinations of approaches.

3. Application level approaches may also impose requirements on the network

4. Different combinations of models and approaches have different pros / d t l itLoss / cons and cost vs. complexity trade-offs

Loss(Impairments/Time)

Re-engineeringRequired

entia

l Ove

r-En

gine

erin

g Viable-Engineering

32


Pote E

How to compare different approaches

1. Can compare different approaches in terms of:

1. An idealised solution …

Lossless or lossyIs lossless in the failure of all SHE and core network element failures

Bandwidth usage in network working and failure cases

Requires that only the basic MPEG stream be provisioned on working case and failure case paths

Delay impact on transported stream

p

Adds negligible overall delay to the transported stream

Cost and complexity of design and deployment and application infrastructure

Does not significantly increase core network complexity with respect to design, deployment and operations

33


Platform support

and operations

Is supported across all current platforms

Network-level technologies for reducing packet loss after link and node failures

1. Fast IP routing protocol convergenceImplementation and protocol optimisations that can deliver sub second

convergence times for unicast (OSPF ISIS BGP) and multicastconvergence times for unicast (OSPF, ISIS, BGP) and multicast (PIM)

Applies for both IP and MPLSSimplest approach to design deploy and operate

2. Multicast-only Fast Reroute (MoFRR)Simple enhancement to PIM processing provides the capability to

instantiate resilient multicast trees can be used for fasterinstantiate resilient multicast trees – can be used for faster convergence

Misnomer – no relation to MPLS TE FRR; can apply to IP and MPLS

3. MPLS Traffic Engineering (TE) Fast Reroute (FRR)Enables pre-calculated back up TE tunnels to be used to protect

against link and node failures for rerouting in sub 100ms [RFC4090]

34


[RFC4090]Requires MPLS TE is deployed – additional complexityMay require that additional bandwidth is provisioned

Fast Convergence

PrimaryStreamStream

R t d

VideoSource

VideoReceivers

CoreDistribution

(DCM)

EdgeDistribution

(DCM)

Rerouted PrimaryStream

1. Implementation and protocol optimisations that can deliver sub second convergence times for unicast (OSPF, ISIS, BGP) and multicast (PIM)

2. Network IP routing protocol reconverges on core network failure (link or node); loss of connectivity is experienced before the video stream connectivity is restoredrestored

3. Fast Convergence

Lowest bandwidth requirements in working and failure case

L t l ti t d l it

35


Lowest solution cost and complexity! Requires fast converging network to minimize visible impact of loss

Is not hitless – will result in a visible artifact to the end users

IPoDWDM Proactive Protection1 IP / ti l i t ti bl th bilit t id tif d d d li k1. IP / optical integration enables the capability to identify degraded link

using optical data (per-FEC BER) and start protection (i.e. by signaling to the IGP) before traffic starts failing, achieving hitless protection in many cases

Working path

Switchover lost data

Protectedpath Working path Protect path

SR port on router

WDM port on routerB

ER

LOF

BER

Near-hitless switch

T its

FEC limit

its

FEC limit

FEC

Trans-ponder

Optical impairments

Cor

rect

ed b

Optical impairmentsC

orre

cted

b

ProtectiontriggerFEC

36


Optical impairments Optical impairments

WDM WDM

Today’s protection Proactive protection

MPLS TE Fast Reroute

PrimaryStreamStream

R t d

VideoSource

VideoReceivers

CoreDistribution

(DCM)

EdgeDistribution

(DCM)

Rerouted PrimaryStream

1. Enables pre-calculated back up TE tunnels to be used to protect against link failures for rerouting in sub 100ms [RFC4090]

2. Network reconverges / reroutes on core network failure (link or node); loss of connectivity is experienced before the video stream connectivity is restoredconnectivity is experienced before the video stream connectivity is restored

3. Fast Reroute! Requires additional cost and complexity of deploying MPLS TE! May require that additional bandwidth is provisioned to cover failure cases

37


y q p

Is not hitless – will result in a visible artifact to the end users

MPLS TE FRR Bandwidth Inefficiency= working case mcast tree= failed link or node= FRR backup paths

Node FailureLink Failure

1. To protect failure of the orange link, the blue link needs to be provisioned for two times the normal multicast load

1. To protect failure of the orange node, the blue link needs to be provisioned for three times the normal multicast load

38


multicast load normal multicast load2. NSF / SSO is a better approach

Multicast only Fast Reroute (MoFRR)1. MoFRR = Multicast only Fast Reroute

Misnomer – no relation to MPLS TE FRR

2. MoFRR provides the capability to instantiate2. MoFRR provides the capability to instantiate resilient multicast trees for the same content

If receive IGMP or PIM join on downlink and have multiple paths to source send joins on two pathsLeverage IGP Link-State database and knowledge of how networks are designed to ensure streamsof how networks are designed to ensure streams are path diverseFeed connected receivers from only one of the two received streamsMonitor the health of the primary stream and upon f il th dfailure, use the secondary

3. A simple approach from a design and deployment and operations perspective

4. Can be used for both lossy and lossless approaches and be implemented in the

= Receiver

= IGMP Joinapproaches and be implemented in the network or on the video end system

5. MPLS TE and MTR are options in topologies that do not support MoFRR

IGMP Join

= PIM Join

= Source

39


Application-level approaches for recovering from packet lossp

1. Forward Error Correction (FEC)FEC adds redundancy to the transmitted data to allow the y

receiver to detect and correct errors (within some bound) without the need to resend any data

2. Temporal Redundancy (TR)With temporal redundancy the transmitted stream is broken into

blocks, each block is then sent twice, separated in timep

3. Spatial Redundancy (a.k.a. live / live)T t t di th b t th dTwo streams are sent over diverse paths between the sender

and receiver

40


Spatial (Path) Diversity(a.k.a “live / live”)( )

PrimaryStreamStream

VideoSource

VideoReceivers

CoreDistribution

(DCM)

EdgeDistribution

(DCM)PrimaryStream

1. Two streams are sent over diverse network paths between the sender and receiver

2. Spatial diversity p ySupports hitless recovery from loss due to core network failures with packet by packet stream merge functions (e.g. DCM)Lower overall bandwidth consumed in failure case compared to FEC

41


Introduces no delay if the paths have equal propagation delays

! May require network-level techniques to ensure spatial diversity: MoFRR, MPLS TE, MTR – required techniques depend upon topology

Network-level technologies for engineering redundant paths to support spatial redundancy

1. Multicast-only Fast Reroute (MoFRR)Simple enhancement to PIM processing provides the capability to

instantiate resilient multicast trees that can be used for live / liveSimple approach from a design and deployment and operations perspective

2. MPLS TERequires MPLS TE – additional cost and complexityPossible option in topologies that do not support MoFRR

3 Multi-topology routing (MTR)3. Multi topology routing (MTR)Requires MTR – additional cost and complexityPossible option in topologies that do not support MoFRR

42


Dual plane networks

1.Constructed by taking two symmetric cores and interconnecting them

R lt t l i ECMP b t t l th di itResults not only in ECMP, but natural path diversity

2.Immediately usable for MoFRR, live-live services3.Option to engineer multiple topologies (MT-IGP, RSVP-TE)p g p p g ( , )

Orange: full network, Plane A (green), Plane B (red)

Standard customerCE site A

Standard customerCE site B

MoFRR customerCE site A

MoFRR customerCE site B

MoFRR MoFRR

43


Live-live customerCE site B

Live-live customerCE site A

Source RedundancyAnycast/Prioritycast policies Src BSrc A

• Policiessecondaryprimary10.2.3.4/3110.2.3.4/3110.2.3.4/3210.2.3.4/32

Anycast: clients connect to the closest instance of redundant IP address

P i it tPrioritycast: clients connect to the highest-priority instance of the redundant IP address

1.Also used in other placesEg: PIM-SM, Bidir-PIM RP redundancy, DNS

2.Policy simply determined by routing announcement and routing configannouncement and routing config

Anycast well understood

Prioritycast: engineer metrics of announcements

44


or use different prefix length. Rcvr 2Rcvr 1Example: prioritycast withPrefixlength annuncement


Video Monitoring

45


Video Transport Monitoring

1. Need techniques to isolate where and what video packets are being dropped in the network

2. Multi-pronged approachActive video transport monitoring: IPTV SLA

Passive per flow video transport monitoring: Vidmon

Video quality monitoring: Trap and clone

Overarching video service management solution: VAMS

46


Passive per flow video transport monitoring: Vidmon

MDI

1. Embedded router technique (MDI) to isolate where and what video packets are being dropped in the network on a per-flow basisbasis

2. Discriminates between problems at the source boundary, at the edge boundary, within the network

3. Complements IPSLA functionality

4. Focuses on loss monitoring

5. Scales to 100’s of flows

6. Leverages MDI, a well-known industry metric: RFC4445

47


Passive per flow video transport monitoring: Vidmon – Example #1

MDI

pAccess Service and ReceiversMDI

MDI(CTV)0:0

MDI(CTV)0:0

Access Service

MDI

MDI

VideoSource MDI(CTV)

0:0

MDI(CTV)0 0

MDI(CTV)0:0MDI (CiscoTV, CRS1) = DF: MLR

• Delay Factor (DF): a measurement at

MDI (CiscoTV, CRS1) = DF: MLR

• Delay Factor (DF): a measurement at

and Receivers

Access Service

MDI

MDI

0:0

MDI(CTV)-50:0.1

y ( )router CRS1 of the accumulated jitter for flow “CiscoTV”

• Media Loss Rate (MLR): a measurement at router CRS1 of the accumulated loss for flow “CiscoTV”

y ( )router CRS1 of the accumulated jitter for flow “CiscoTV”

• Media Loss Rate (MLR): a measurement at router CRS1 of the accumulated loss for flow “CiscoTV”

and ReceiversMDI

1. Passive per flow monitoring complements IPSLA by detecting an individual per-flow issues at identified core routers

2. Pervasive router support and deployment allows for troubleshooting the

48


pp p y groot cause location

3. Significantly reduced CAPEX and OPEX compared to external probes

Video quality monitoring: Trap and clone #1Access Service and Receivers

VideoS

Access Service and Receivers

T&C

Source

Access Service and ReceiversT&C

1. Embedded router technique to intercept 1. Embedded router technique to intercept

Video Codec Aware 3rd Party Analyzer

3rd

q pand dispatch a copy of the intercepted flow towards a codec-aware 3rd-party analyzer in the NOC

2. Provides low-level codec-aware

q pand dispatch a copy of the intercepted flow towards a codec-aware 3rd-party analyzer in the NOC

2. Provides low-level codec-aware

49


Network Operations Centreanalysis of the flow

3. OPEX and CAPEX efficient technique for fine-grained video-aware analysis

analysis of the flow

3. OPEX and CAPEX efficient technique for fine-grained video-aware analysis

Video Assurance Management Solution (VAMS)Video Transport Assurance – Backbone, Regional, Agg/Div, Access

Presentation

VAMS

Cisco Video Assurance Management Solution (VAMS) delivers realtime centralized video assurance in the core, distribution, and aggregation networks for broadcast id t t

Cisco Video Assurance Management Solution (VAMS) delivers real-time centralized video assurance in the core, distribution, and aggregation networks for broadcast id t t

Aggregation & Correlation

ANA

VNE Servers

GatewayCisco MulticastManager

MySQL Traps

VAMS video transport.

Dynamic visualization of Video

video transport.

Features• Dynamic visualization of Video

Metrics C stom Se ice Vie s

Data Sources

Collection Polling/Traps

CommandsPolling/Traps

• Custom Service Views • Root-cause Analysis • Integration with other OSS/BSS

solutions • Proactive Video Transport

Monitoring

CRS 1 4500 7600

Linksys/SA HomeRouter

CRS 1

IP NG Network

Monitoring • Data collection from probes • Multicast data collection

Benefits• Reduces Mean Time to Repair CRS-1

Router 76004500 or 7600

Series SA QAM7600CRS-1Router

CRS-1Router

IP/MPLS IP/MPLSIP/MPLS

• Reduces Mean Time to Repair (MTTR)

• Enhanced Video Quality of Experience

• Proactive Video Transport Monitoring

50

© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_IDBackbone Network

CRS-1Router

CRS-1Router

Regional Network

7600 7600

Aggr / Div Network

4500 or 7600Series

7600 or CRS

Access/Hub

SA STB orDVR

Home

DSLAMMonitoring

• Increased Operational Efficiency


Summary

51


Transit technologies for IPTVSummary / recommendationsSummary / recommendations1.Native PIM-SSM + RPF-Vector

Most simple, most widely deployed, resilient solution.Most simple, most widely deployed, resilient solution.

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

3.mLDPRecommended Evolution for MPLS networks for all IP multicast transit:Recommended Evolution for MPLS networks for all IP multicast transit:

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

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

52


eg: IPTV contribution networks.

ResilienceSummaryy

1.Determine what resilience you need for IPTV and other servicesExpectations are shifting with more experience of operatorsp g p p

2.Multicast Fast Convergence only end-to-end ubiquitous layer 3 resilience. Well optimized, but architecturally limited

Subsec3.Sub 50 msec link protection alone (DPT rings, protected

pseudowires) is not a full L3 solution4.Optimizations at L3:

RSVP-TE P2MP: FRRPIM/mLDP: Make-before-break, Full (IP)-FRR, MoFRR, Live-Live

5 Applications:5.Applications:Do not only ask what the network can do for you, …but ask what you can do for the network

FEC, ARQ, live-live (QoS marking, pacing, …)

53


Cisco Networkers 25-28. januar 2010.BarselonaR i t jtRegistrujte se

54


Video Transport over IP Core Studio Fixed Secondary IP/MPLS Distribution Core Core IP/MPLS Core Home...

Documents

Transcript of Video Transport over IP Core Studio Fixed Secondary IP/MPLS Distribution Core Core IP/MPLS Core Home...