Video Over IP

Video Transport
p
over IP
Marko Vukadinović, mvukadin@cisco.com
Presentation_ID © 2008 Cisco Systems, Inc. All rights reserved. Cisco Confidential 1
Video Transport over IP
Market Overview
2
Presentation_ID © 2008 Cisco Systems, Inc. All rights reserved. Cisco Confidential
Video Service Providers
Taxonomy & Characteristics
Video
Stream
Bandwidth
Studio to Studio; Broadcaster
to Broadcaster
Uncompressed, Lossless Content owner to provider
Very High bit-rate stream: SD Compressed Provider to subscriber i.e.
(270Mbps), HD (1.5-3Gbps) Cable TV & IPTV
Low/moderate bit-rate
bit rate stream
P-to-P and P2MP ~ same as secondary dist Compressed
(unicast and multicast) Low bit-rate stream: SD (3-
P-to-P and P2MP
P2MP MPLS technology (unicast and multicast) 4Mbps mpeg2, 2-3Mbps
mpeg4), HD (16-20Mbps
e.g. Broadcasters, Studios MPLS & IP technology mpeg2, 8-10Mpbs mpeg4)
e.g. Contribution providers, P-to-P for VOD (unicast) &
US national cable backbones P2MP for IPTV (multicast)
MPLS & IP technology
e.g. Service Providers
Contribution
Primary
Distribution Secondary
Distribution
# of end points
3
Video Service Providers
Mapping to Broadcast Industry
• Increasing demand for
localised content
Contribution • Service Control & Broadcast
Primary Quality gaining prominence
Distribution • Increasing scale to end-
Studio
Studio
customer
Final Common core network
Studio
requirements & designs
IP/MPLS
Core
Secondary
IP/MPLS
IP/MPLS Distribution
Mobile Core
Core
Studio
Fixed
Studio
IP/MPLS
IP/MPLS
Core Home
Core Network
Access
DCM
N t
Network
k
Super VOD
Head End content
(x2) distributing
to scale
DCM
VOD VOD VOD
International DCM / VQE
National Super
& National Local
Content Head End Content Head End VSO Home
Content
Insertion (x2) Insertion (x10s) (x100s) x millions
Insertion 4
Video Transport:
Primary Technology challenges
1. Basic transport
H
How to shift
hif the
h packets
k … IP or MPLS
MPLS, native
i or VPN?
Type of provider impacts transport requirements
2. How to meet SLAs for video?

Main problem is management of loss due to reconvergence events
Number of potential deployment models and technology approaches
Potential 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
video,
ideo and to identify
identif problem areas is key
ke to accelerating IPTV
deployments
5
Transport and Edge design

options
6
50,000 Feet Architecture
IPTV and Multicast
IPTV “Services
Services Plane”
Plane IP multicast
Service gateway
IP multicast Receive/process/send
source Eg: Ad-Splicer, Dserver, Transrater,… IP multicast
receiver
Signalling
Signaling
Signaling
Service Interface
Multicast traffic Multicast traffic

The network
“Network Plane”
7
50,000 Feet Architecture
Goals
1. Separate “network” and “services” plane
Network = shared infrastructure for all services
Routers switches
Routers, switches, optical gear
gear, NMS
NMS, …
IPTV = encoders, groomers, splicers, VoD server, STB, …
Often operated by different entity/group than network
2. IP 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
(IPTV, MVPN
MVPN, …))
Different transport options for different services possible
Enable network operator not to provision/worry about individual programming.
3. Service Interface
How 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 protocols

IPTV: IGMPv3 / PIM-SSM
• P(rovider)-tree
P( id ) t (PMSI) b
building
ildi protocols
t l
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
Receiver
C t t
Content
Source P2 PE2 CE2
Tailend LSRs =
CE2 PE1 P1 Downstream PEs
Upstream PE = P4 PE3 CE3

Headend LSR Receiver 9
Combinations with L3 on PE
Current 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 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
pp
10
Transport architecture
Overview
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 context
As a method of service isolation / multiplexing
L2 vs.
vs L3 on PE nodes
To “integrate” better into an L2 service model
Redefine PE-PE
PE PE signaling for MVPN
11
MPLS traffic forwarding
1. Same forwarding (HW requirements) with mLDP / RSVP-TE

2. Initial: “Single label tree” for both non-aggregated & aggregated
3. No PHP: receive PE can identify tree
Put packet after pop into correct VRF for IP multicast lookup IPv4
IPv6
PE-2 CE-2
MC Pkt L20
MC Pkt Receiver
IPv4
MC Pkt L100
IPv6
“Pop”
PE-1 P-4
CE-1 MC Pkt
MPLS Core
Content
Source MC Pkt L30
MC Pkt
“Push” PE-3
IPv4
“Swap” IP 6
IPv6
CE-3
Note: Deployment timelines are dependent on the platform Receiver
12
mLDP signaling Note: Deployment timelines are
with native and Direct
Direct-MDT
MDT dependent on the platform
PIM-V4 JOIN: VRF IPTV

mLDP Label Mapping:
FEC = S+
S G+RD+
G RD R
Roott Source= 10.10.10.1
Source 10 10 10 1
Label=(20) Group = 232.0.0.1
mLDP Label Mapping:

PIM-V4 Join: VRF IPTV FEC = S+G +RD+Root
Source= 10.10.10.1 Label=(100) IPv4 CE-2
Group = 232.0.0.1 Receiver
VRF
IPTV
PE-2
PE 2
IPv4
PE-1 P-4
CE-1
VRF MPLS Core PIM-V4 JOIN: VRF IPTV
Content IPTV Source= 10.10.10.1
10 10 10 1
Source Group = 232.0.0.1
P2MP LSP mLDP Label Mapping: PE-3

FEC= S + G + RD + Root
“Root” Label=(30) VRF IPv4
IPTV
CE-3
FEC: Forwarding Equivalence Class Receiver
13
dalin@cicso.com
Presentation_ID © 2006
© 2008 Cisco Systems, Cisco
Inc. Systems,
All rights Inc. All rights
reserved. Ciscoreserved.
Confidential
RSVP-TE P2MP signaling Note: Deployment timelines are
with static native IPv4 to customer dependent on the platform
TE tunnel config: Static IGMP/PIM join

ERO1: P-4, PE-2 Source= 10.10.10.1
ERO2: P-4, PE-3 PATH P4, PE2 Group = 232.0.0.1
PATH P4, PE2 On interface to CE
RESV Label = 20
Static IGMP/PIM join PATH P4, PE3
Source= 10.10.10.1
CE-2
Group = 232.0.0.1
On TE tunnel interface IPv4 Receiver
IPv4 PE-2
PE 2
MPLS
Core
PE-1 P-4
CE-1
Content
Source RESV Label = 100 Static IGMP/PIM join
Source= 10.10.10.1
RESV Label = 100 PATH P4, PE2 PE-3 Group = 232.0.0.1
On interface to CE
RESV Label = 30 IPv4
P2MP LSP Label merge ! CE-3

Headend Assign same upstream label Receiver
For all branches of a tree 14
PIM/mLDP benefits over RSVP-TE P2MP
Examples
1.Cost of trees (Signalling / Hardware
State) Src
Headend
H d d
N = # tailend LSR (#PE) LSR
Bidir-PIM/mLDP MP2MP: ~1
PIM/mLDP P2MP: ~1
RSVP-TE P2MP: ~N
Full mesh of RSVP-TE P2MP LSP: ~(N*N)
y No scaling
Summary: g impact
p of N for PIM/mLDP
2.Locality:
Affects convergence/reoptimization speed:
PIM/mLDP:
PIM/ LDP F Failure
il iin network
k affects
ff only
l router iin
region (eg: in pink region).
RSVP: impact headend and all affected midpoint and
tailends for RSVP-TE reoptimization.
R
Rcv
Join/leave of members affect only routers up to first
router on the tree in mLDP/PIM. Will affect headend Rcv
and all midpoints in RSVP-TE P2MP. Rcv 15
RSVP-TE P2MP benefits over PIM/mLDP
Examples
1.Sub 50 msec protection ? Src
Also feasible for PIM/mLDP
Headend
H d d
2.Load-split traffic across alternative LSR
paths (ECMP or not)
PIM/mLDP
PIM/ LDP tree
t follows
f ll shortest
h t t path,
th “dense”
“d ”
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 loss

Assume high-prio and low-prio trees.
With full redundancy, enough bandwidth to carry
R
Rcv
all trees (with load-splitting)
Rcv
On link-loss, reconverge high-prio, block low-prio Rcv 16
Other Signaling
Unicast / RPF reachability for PIM/mLDP
• Native IPv4/IPv6, no RPF-vector:

P/PE node: BGP (SAFI2) IPv4/IPv6 + IGP IPv4 (/IPv6) for upstream PE
• Native IPv4/IPv6 with RPF-vector, mLDP
PE/P node: IGP IPv4 (/IPv6) for upstream PE
P node: BGP (SAFI2)
( ) IPv4/IPv6
• L3VPN, MVPN-GRE/mLDP:
P/PE node: IGP IPv4 route for upstream PE
PE node: BGP VPNv4/VPNv6 routes (RFC2547)
InterAS MVPN: BGP ‘Connector-attribute’ (not shown)
VPNv4/VPNv6 BGP BGP: S -> PE1
“native” BGP IGP: PE1 -> P1
Src(S) PE1 P1 PE2 Rcvr

Native PIM-join: PIM-join
(S,G) (S,G)
RPF PE1
RPFv:
MVPN PIM-join:
(PE1,G’) – Default/Data MDT
17
End-to-end protocol view
DSL,, L3 aggregation
gg g
Same choices for all access technologies Different by access technology
External Core Distribution Aggregation Access Home Net

Network / regional Eg:
Eg: Dis. PE-AGG Home
DSLAM STB
Content Edge Rtr Gateway
provider
Video encoder/
multiplexer
First hop
router
Content injection:
External, national, regional, local
PIM-SSM (S,G) joins IGMPv3 (S,G) membership

Headend
L3 Transport Options in clouds:

Opt.
Opt Native: PIM-SSM or MVPN/SSM IGMP:
MPLS: LSM / mLDP RSVP-TE {Limits} IGMPv3 IGMPv3 IGMPv3
Source
{Static-fwd} snooping proxy routing SSM
Redundancy
PIM-SSM PIM-SSM PIM-SSM
18
End-to-end protocol view
DSL,, L2 aggregation
gg g
Same choices for all access technologies Different by access technology
External Core / Access Home Net

Distribution Aggregation
Network Eg:
Eg: PE-AGG Home
DSLAM STB
Content Gateway
provider
Video encoder/ L2
multiplexer
First hop
router
Content injection:
External, national, regional, local
PIM SSM
PIM-SSM
(S,G) joins IGMPv3 (S,G) membership
Headend
Transport
Opt.
Opt O ti
Options IGMP:
{Limits} IGMPv3 IGMPv3 IGMPv3 IGMPv3 IGMPv3
Source
{Static-fwd} snooping snooping snooping proxy routing SSM
Redundancy
PIM-SSM
19
IGMP Snooping vs. PIM Routing?
IGMP 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
p and pps
• information on actives sources in kbps pp
Switch# show ip igmp snooping groups

Vlan Group Type Version Port List
-------------------------------------------------------------
OUTGOING
1 224.1.4.4 igmp PORT Fa1/0/11
1 GROUP 224.1.4.5 igmp Fa1/0/11
2 224.0.1.40 g p
igmp v2 Fa1/0/15
20
IGMP Snooping vs. PIM Routing?
L3 Multicast provides excellent monitoring
Router# show ip mroute

IP Multicast Routing Table
SOURCE
... GROUP 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.0
Outgoing interface list: INCOMING PORTS
GigabitEthernet3/1, Forward/Sparse-Dense, 00:00:36/00:02:35
TenGigabitEthernet4/1, Forward/Sparse-Dense, 00:00:36/00:02:35
OUTGOING PORTS HOW LONG
Router# show ip
p mroute active
Active IP Multicast Sources - sending >= 4 kbps
Group: 224.2.127.254, (sdr.cisco.com)

Source: 146.137.28.69
146 137 28 69 (mbone.ipd.anl.gov)
(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
2.2.2.2 O MUCH
UC STABILITY
S
Rate: 389 pps/3933 kbps(1sec), 3833 kbps(last 20 secs),
3677 kbps(life avg)
21
Layer 3 Multicast – is simple
QAM
Link
Failure
Node
Failure
Anycast Concept
• native 1:1 stream protection
• simple,
simple fast and automatic
Encoders
• exists in L3 MC only
TV Headend
DCM • no RPF check in L2 MC
22
Layer 2 Multicast – is complicated
QAM
Link
Failure
PIM
Assert
Missing
Hellos
X
Encoders
DCM
TV Headend 23
Layer 2 Multicast – chained VPLS?
Node
Failure
QAM QAM
VPLS
VPLS VPLS
Link
Li k
Failure
Assert
VPLS
No Hello VPLS
Source VPLS VPLS

Failure
Encoders
TV Headend
DCM Discontiguous Subnets!!! 24
Layer 3 Multicast – IETF PIM SSM
Node
Failure
QAM QAM
A/ IP Routing
g
• connection-less convergence
• works automatically
• possible using simple IP Routing
Link B/ MPLS FRR
Failure • connection-oriented
• manual pre-provisioning
•ppossible using
g Routed Pseudowire
Source
Failure
Encoders
DCM
TV Headend 25
MPLS FRR for IPmc – Routed PW
QAM QAM
IPmc routing in AToM PW in TE tunnel

• Cisco 7600 (SIP, ES20)
• FRR for AToM
Link
Li k Hop-by-hop
Failure L3-terminated Future Approaches
AToM • IPFRR (dynamic, connectionless)
Pseudowires • P2MP TE using RSVP (static)
• LSM using mLDP (dynamic)
Encoders
DCM
TV Headend 26
(Aggregation) networks
Why L3 and not L2 ((‘snooping’)
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
(S,G)
G) forwarding
4. L2: No hop-by-hop problem isolation
5. 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:
SSM (IPTV) , potentially SM, Bidir (for other services)
27
Static vs. Dynamic Trees
1. “Broadcast Video” Source
Dynamic IGMP forward up to DSLAM (3) (2) (1)
DSL link can only carry required program!
static forwarding into DSLAM
Static (PIM) trree

ee
c (PIM) tre
Fear of join latency
PIM joins
History (ATM-DSLAM)
2. “Switched Digital
g Video”
Static
P
Allow oversubscription of PE-
PE-AGG
AGG/DSLAM link
3 “Real
3. Real Multicast
Multicast” DSLAM
dynamic tree building full path
P joins
IGMP joins
IGMP joins
Home
Gateway
IGMP
28
Resiliency options
29
Video SLA Requirements
1. Throughput
Addressed through capacity planning and QOS (i.e. Diffserv)
2
2. Delay/Jitter
Delay variation absorbed by jitter buffer at STB
Desire 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 factors
Diffserv is mature technology and premium transport service is known to offer ~
<1msec jitter end-to-end
3. Loss – controlling loss in the main challenge
4. 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 networks
and network availability
30
MPEG – Impact of Packet Loss
1200
1000
Duration of impairrment (ms)
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
D
200
• Increasing the GOP size,

0 e.g. with MPEG-4, will
0 100 200 300 400 500 result in a corresponding
D
Duration
ti off packet
k t lloss (m
( s)) increase in the worst
worst-case
case
impairment duration
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
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
31
Video SLA Requirements:
Managing
g g Loss
Range of viable 1. A number of technological
engineering options approaches to achieve required
may vary by type of SLA
xity
video distribution,
Cost and
d
Complex
service or content Network approaches to reduce loss:

fast convergence, fast reroute
Application approaches to recover from
loss experiences: FEC, Temporal
Redundancy, Spatial Redundancy
Number
N b off possible
ibl Network
N t k approaches
h ffor engineering
i i
approaches, or spatial redundancy
combinations of
approaches. 2. Number of network deployment
models to support each approach
3
3. Application level approaches may
also impose requirements on the
network
4. Different combinations of models
and approaches have different pros
Loss / cons andd costt vs. complexity
l it
(Impairments/Time)
Re-engineering trade-offs
Engineering
Viable-
ential Over-
Engineering Required
Pote
E
32
How to compare different approaches
1. Can compare different 1. An idealised solution …
approaches in terms of:
Is lossless in the failure of all
Lossless or lossy SHE and core network
element failures
Requires that only the basic
Bandwidth usage in network MPEG stream be provisioned
working and failure cases on working case and failure
case p
paths
Delay impact on transported Adds negligible overall delay to
stream the transported stream
Cost and complexity of design Does not significantly increase

and deployment and core network complexity with
application infrastructure respect to design, deployment
and operations
Platform support Is supported across all current
platforms 33
Network-level technologies for reducing
packet loss after link and node failures
1. Fast IP routing protocol convergence
Implementation and protocol optimisations that can deliver sub second
convergence times for unicast (OSPF
(OSPF, ISIS
ISIS, BGP) and multicast
(PIM)
Applies for both IP and MPLS
Simplest 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 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]
Requires MPLS TE is deployed – additional complexity
May require that additional bandwidth is provisioned 34
Fast Convergence
Primary
Stream
Video Video
Source Receivers
Rerouted
R t d
Core Primary Edge
Distribution Stream Distribution
(DCM) (DCM)
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
restored
3. Fast Convergence
3 Lowest bandwidth requirements in working and failure case
3 Lowest
L t solution
l ti costt and
d complexity
l it
! Requires fast converging network to minimize visible impact of loss
Presentation_ID
8 Is not hitless – will result in a visible artifact to the end users
© 2008 Cisco Systems, Inc. All rights reserved. Cisco Confidential
35
IPoDWDM Proactive Protection
1
1. IP / optical
ti l integration
i t ti enables
bl theth capability
bilit tto id
identify
tif ddegraded
d d lilink
k
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 Switchover Protected

Working path Protect path
path lost data path
LOF Near-hitless
SR switch
port on WDM
BER
BER
router port on
router
FEC
FEC limit FEC limit

Corrected bits
Corrected bits
T
Trans-
ponder
FEC Protection
trigger
Optical impairments Optical impairments
WDM WDM
Today’s protection Proactive protection

36
MPLS TE Fast Reroute
Primary
Stream
Video Video
Source Receivers
Rerouted
R t d
Core Primary Edge
Distribution Stream Distribution
(DCM) (DCM)
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 restored
3. Fast Reroute
! Requires additional cost and complexity of deploying MPLS TE
! Mayy require
q that additional bandwidth is p
provisioned to cover failure cases
8 Is not hitless – will result in a visible artifact to the end users
37
MPLS TE FRR Bandwidth Inefficiency
= working case mcast tree
= failed link or node
= FRR backup paths
Link Failure Node Failure
1. To protect failure of the orange link, 1. To protect failure of the orange

the blue link needs to be node, the blue link needs to be
provisioned for two times the normal provisioned for three times the
multicast load normal multicast load
2. NSF / SSO is a better approach
38
Multicast only Fast Reroute (MoFRR)
1. MoFRR = Multicast only Fast Reroute
Misnomer – no relation to MPLS TE FRR
2. 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 paths
Leverage IGP Link-State database and knowledge
of how networks are designed to ensure streams
are path diverse
Feed connected receivers from only one of the two
received streams
Monitor the health of the primary stream and upon
f il
failure, use th
the secondary
d
3. A simple approach from a design and
deployment and operations perspective
= Receiver
4. Can be used for both lossy and lossless = IGMP Join
approaches and be implemented in the
network or on the video end system = PIM Join
= Source
5. MPLS TE and MTR are options in topologies
that do not support MoFRR
39
Application-level approaches for recovering
from p
packet loss
1. Forward Error Correction (FEC)
FEC adds redundancy y to the transmitted data to allow the
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
p in time
3. Spatial Redundancy (a.k.a. live / live)

Two streams
T t are sentt over diverse
di paths
th between
b t the
th sender
d
and receiver
40
Spatial (Path) Diversity
((a.k.a “live / live”))
Primary
Stream
Video Video
Source Receivers
Core Edge
Distribution
Distribution Primary (DCM)
(DCM) Stream
1. Two streams are sent over diverse network paths between the sender and
receiver
2. Spatial
p diversity
y
3 Supports hitless recovery from loss due to core network failures with packet
by packet stream merge functions (e.g. DCM)
3 Lower overall bandwidth consumed in failure case compared to FEC
3 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 41
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 / live
Simple approach from a design and deployment and operations perspective
2. MPLS TE
Requires MPLS TE – additional cost and complexity
Possible option in topologies that do not support MoFRR
3 Multi
3. Multi-topology
topology routing (MTR)
Requires MTR – additional cost and complexity
Possible option in topologies that do not support MoFRR
42
Dual plane networks
1. Constructed by taking two symmetric cores and

interconnecting them
R
Results
lt nott only
l iin ECMP
ECMP, b
butt natural
t l path
th di
diversity
it
2. Immediately usable for MoFRR, live-live services
3. Option
p to engineer
g multiple
p topologies
p g (MT-IGP,
( , RSVP-TE))
Orange: full network, Plane A (green), Plane B (red)
Standard customer
Standard customer CE site B
CE site A
MoFRR customer
MoFRR customer CE site B
CE site A
MoFRR MoFRR
Live-live customer Live-live customer

CE site A CE site B
43
Source Redundancy
Anycast/Prioritycast policies
Src A Src B
primary secondary
10.2.3.4/32 10.2.3.4/31
• Policies
Anycast: clients connect to the closest
instance of redundant IP address
P i it
Prioritycast
t: clients connect to the highest-
priority instance of the redundant IP address
1. Also used in other places
Eg: PIM-SM, Bidir-PIM RP redundancy, DNS
2. Policy simply determined by routing
announcement and routing config
Anycast well understood
Prioritycast: engineer metrics of announcements
or use different prefix length. Rcvr 1 Rcvr 2
Example: prioritycast with
44
Prefixlength 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 approach
Active 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: MDI
Vidmon
1. Embedded router technique (MDI) to isolate where and what
video packets are being dropped in the network on a per-flow
basis
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: MDI
Vidmon – Example
p #1
Access Service
MDI and Receivers
MDI
MDI(CTV)
0:0
MDI(CTV)
MDI 0:0
Access Service
Video MDI and Receivers
MDI(CTV)
Source 0:0
MDI MDI(CTV)
MDI (CiscoTV, CRS1) = DF: MLR 0:0
• Delayy Factor (DF):
( ) a measurement at MDI(CTV) Access Service
router CRS1 of the accumulated jitter for 00
0:0 MDI
flow “CiscoTV”
and Receivers
• Media Loss Rate (MLR): a measurement
at router CRS1 of the accumulated loss for MDI(CTV)
flow “CiscoTV” -50:0.1
1. Passive per flow monitoring complements IPSLA by detecting an

individual per-flow issues at identified core routers
2. pp and deployment
Pervasive router support p y allows for troubleshooting
g the
root cause location
3. Significantly reduced CAPEX and OPEX compared to external probes
48
Video quality monitoring: Trap and clone #1
Access Service
and Receivers
T&C
Access Service
Video and Receivers
S
Source
Access Service
T&C
and Receivers
1. Embedded router technique

q to interceptp
and dispatch a copy of the intercepted
flow towards a codec-aware 3rd-party
analyzer in the NOC
3rd Video Codec Aware
3rd Party Analyzer 2. Provides low-level codec-aware
analysis of the flow
Network Operations Centre
3. OPEX and CAPEX efficient technique

for fine-grained video-aware analysis 49
Video Assurance Management Solution (VAMS)
Cisco Video Assurance Management
Video Transport Assurance – Backbone,
SolutionRegional, Agg/Div,
(VAMS) delivers Access
real
real-
time centralized video assurance in
Presentation the core, distribution, and
aggregation networks for broadcast
VAMS video
id transport.
t t
Aggregation & Gateway
Correlation
Cisco Multicast
Manager
ANA
Features
MySQL Traps • Dynamic visualization
VNE Servers
of Video
Metrics
Collection • C stom Service
Custom Se ice Views Vie s
Polling/Traps
Polling/Traps
• Root-cause Analysis
• Integration
Commands
with other OSS/BSS
solutions
Data Sources
• Proactive Video Transport
Monitoring
• Data collection from probes Linksys/SA
IP NG Network • Multicast data collectionHome
Router
Benefits
CRS 1
CRS-1 CRS-1 CRS 1
CRS-1 •
4500 or Reduces
7600 Mean Time to Repair
7600 SA QAM
Router Router Router 7600 (MTTR)
Series
• Enhanced Video Quality of
IP/MPLS IP/MPLS IP/MPLS
Experience
• Proactive Video Transport
Monitoring
CRS-1 CRS-1 7600 7600 7600 or •4500 orIncreased
7600 Operational Efficiency
DSLAM
Router Router CRS Series SA STB or
DVR
50
© 2008 Cisco Systems, Inc. Regional
Backbone Network
Presentation_ID Network
All rights reserved. Cisco Confidential Aggr / Div Network Access/Hub Home
Summary
51
Transit technologies for IPTV
Summary / recommendations
1.Native PIM-SSM + RPF-Vector
Most simple, most widely deployed, resilient solution.
2.MVPN-GRE
Also many years deployed (Cisco/rosen specification).
Recommended for IPTV when VRF-isolation necessary !
3.mLDP
Recommended Evolution for MPLS networks for all IP multicast transit:
‘Native’ (m4PE/m6PE)
‘Direct-MDT/MVPN-mLDP’ (IPv4/IPv6)
4 RSVP TE P2MP
4.RSVP-TE
Strength in TE elements (ERO/CSPF + protection)
Recommended for limited scale, explicit engineered designs,
eg: IPTV contribution networks
networks.
52
Resilience
Summary y
1. Determine what resilience you need for IPTV and other services
Expectations
p are shifting
g with more experience
p of operators
p
2. Multicast Fast Convergence only end-to-end ubiquitous layer 3
resilience. Well optimized, but architecturally limited
Subsec
3. Sub 50 msec link protection alone (DPT rings, protected
pseudowires) is not a full L3 solution
4. Optimizations at L3:
RSVP-TE P2MP: FRR
PIM/mLDP: Make-before-break, Full (IP)-FRR, MoFRR, Live-Live
5 Applications:
5.
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.
Barselona
R i t jt se
Registrujte
54

Video Over IP

Uploaded by

Copyright:

Available Formats

You might also like

Video Over IP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Video Over IP

Uploaded by

Copyright:

Available Formats

Video Transport

Marko Vukadinović, mvukadin@cisco.com

2. How to meet SLAs for video?

3. How to manage and monitor the service?

Transport and Edge design

Multicast traffic Multicast traffic

• C(ustomer)-tree building protocols

Upstream PE = P4 PE3 CE3

1. “Native IP multicast” (IPv4/IPv6)

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

PIM-V4 JOIN: VRF IPTV

mLDP Label Mapping:

P2MP LSP mLDP Label Mapping: PE-3

TE tunnel config: Static IGMP/PIM join

P2MP LSP Label merge ! CE-3

3.Block (stop) trees on redundancy loss

• Native IPv4/IPv6, no RPF-vector:

Src(S) PE1 P1 PE2 Rcvr

External Core Distribution Aggregation Access Home Net

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

L3 Transport Options in clouds:

External Core / Access Home Net

IGMP Snooping is TV Stream unaware

Switch# show ip igmp snooping groups

Router# show ip mroute

Group: 224.2.127.254, (sdr.cisco.com)

Source VPLS VPLS

IPmc routing in AToM PW in TE tunnel

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

Static (PIM) trree

800 SD-low -best

• Increasing the GOP size,

service or content Network approaches to reduce loss:

Cost and complexity of design Does not significantly increase

2. Multicast-only Fast Reroute (MoFRR)

3. MPLS Traffic Engineering (TE) Fast Reroute (FRR)

1. Implementation and protocol optimisations that can deliver sub second

Working Switchover Protected

FEC limit FEC limit

Optical impairments Optical impairments

Today’s protection Proactive protection

1. Enables pre-calculated back up TE tunnels to be used to protect against link

Link Failure Node Failure

1. To protect failure of the orange link, 1. To protect failure of the orange

2. Temporal Redundancy (TR)

3. Spatial Redundancy (a.k.a. live / live)

1. Multicast-only Fast Reroute (MoFRR)

1. Constructed by taking two symmetric cores and

Live-live customer Live-live customer

1. Passive per flow monitoring complements IPSLA by detecting an

1. Embedded router technique

3. OPEX and CAPEX efficient technique

You might also like