Transport Architectures Using Ip Multicast Technology For1615

Transport architectures using IP Multicast technology for IPTV Services
Stefan Kollar
Consulting System Engineer, CCIE #10668 skollar@cisco.com
Presentation_ID
2009 Cisco Systems, Inc. All rights reserved.
Cisco Confidential
Agenda
1. 2. 3. 4. 5. 6. Introduction Architectural overview IP multicast primer (SSM) Transit Transport Design options Wholesale / content distribution Resiliency
Source redundancy, protected pseudowires,
fast convergence, FRR, live-live, MoFRR
7.
Path selection
ECMP, multi topologies, RSVP-TE P2MP
2
Presentation_ID 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
Introduction
IPTV and IP Multicast
3
Broadcast IPTV = IP Multicast

1. however transport network transits packets ..
Native IP multicast, MPLS, L2, optical
2. IP multicast sources:
Encoder, Transrater, Groomer, Ad-Splicer,
3. IP multicast receivers:
Transcoder, Groomer, Ad-Splicer, eQAM, STB
4. IP == IPv6 (Japan) or IPv4 (RotW rest of the world)

No address exhaustion issue (SSM) No/slow move to IPv6 for IPTV in RotW
4
Deployment Strategy
Overview, Recommendation
1. Network
Add 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
2. IPTV services
Start with traditional broadcast TV Investigate extending IPTV and add other (IP multicast) services
More RoI on network layer investment
5
Architectural Overview
6
50,000 Feet Architecture

IPTV and Multicast
IPTV Services Plane
IP multicast source
IP multicast Service gateway IP multicast receiver
Receive/process/send Eg: Ad-Splicer, Dserver, Transrater,
Service Interface
Multicast traffic
The network
Signaling
Signaling
Multicast traffic
Network Plane
7
Signaling
50,000 Feet Architecture

Goals
1. Separate network and services plane
Network = shared infrastructure for all services
Routers, switches, optical gear, 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, 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
IP Multicast Primer
9
Protocols and Services

and IP Multicast 1. multicast / multipoint protocols
Between routers, switches, .. Only of interest to network operator PIM-SM, MSDP, (M)BGP, AutoRP, BSR, mLDP, RSVP-TE, ), IGPs (OSPF, ISIS),
2. multicast services
How 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!
10
IP Multicast Services
1. ASM: Any Source Multicast (1990, rfc1112)
The traditional IP multicast service (collaborative) Sources send packets to multicast groups Receivers join to (G) groups, receive from any source
2. SSM Source Specific Multicast (~2000, rfc4607/4604)

The multicast variant for IPTV (or other content distribution) Unchanged: Sources send packets to multicast groups Receivers 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
11
IP Multicast Services
1. ASM
Issues with ASM Resolved with SSM

DoS attacks by unwanted sources Address allocation (IPv4 only, not IPv6)
2. Standard protocol suite PIM-SM/MSDP/Anycast-RP

Complexity of protocol operations required
PIM-SM (RPT+SPT+Switchover), RP redundancy, announce, location MSDP (RPF), BGP congruency, Interactions with MPLS cores, bandwidth reservation, protection
Scalability, Speed of protocol operations (convergence)

RPT + SPT operations needed
12
Model / Protocols for SSM

1. IETF standardized:
Receiver host to router (eg: IP-STB, eQAM)
IGMPv3(IPv4) / MLDv2(IPv6) with (S,G) signaling
MUST be supported in host stack and host middleware (app)
Between routers
PIM-SSM == subset of PIM-SM for SSM (nothing new!)
IGMPv3 proxy routing / (snooping) on HAG, L2 access Simple point to multipoint tree building == (S,G) SPTs only
2.
Not IETF standardized

Anycast source redundancy
L3: Signaling of Anycast/Prioritycast source addresses
Transition support
SSM-mapping, (URD, IGMPv3lite)
13
End-to-End Protocol View

Example: L3 Aggregation
Same choices for all access technologies Different by access technology
External Network
Eg: Content provider
Video encoder/ multiplexer First hop router
Core
Distribution / regional
Dis. Edge Rtr
Aggregation
PE-AGG
Access
BB type specific
Home Net
Home Gateway STB
?
Content injection: External, national, regional, local PIM-SSM (S,G) joins IGMPv3 (S,G) membership
Headend
Opt. Source Redundancy
Presentation_ID
L3 Transport Options in clouds:

Native: PIM-SSM or MVPN/SSM MPLS: LSM / mLDP RSVP-TE
PIM-SSM PIM-SSM
Cisco Confidential
IGMP: {Limits} {Static-fwd} PIM-SSM
IGMPv3 IGMPv3 IGMPv3 snooping proxy routing SSM

14
Transit Transport
Design Options
15
Transport Architecture
Overview 1. Common deployments: Native PIM-SSM or MVPN
Native, GRE IP Multicast
2. Concentrate on futures / components

Support for MPLS multicast (LSM)
Build 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
Using L2 vs. L3 on PE nodes

To integrate better into an L2 service model
Redefine PE-PE signaling for MVPN

16
Overview
Elements of Transport Architecture for Tree Building
1. 2. 3. 4. 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 Receiver
Content Source
P2
PE2
CE2
Tailend LSRs =
CE2
PE1
P1 P4
Cisco Confidential
Downstream PEs
Upstream PE = Headend LSR

Presentation_ID
PE3
CE3
Receiver
17
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
18
MPLS Traffic Forwarding

1. 2. 3. Same forwarding (HW requirements) with mLDP / RSVP-TE Initial: Single label tree for both non -aggregated & aggregated No PHP: receive PE can identify tree
Put packet after pop into correct VRF for IP multicast lookup
IPv4 IPv6
MC Pkt L20
PE-2
CE-2
MC Pkt
Receiver
IPv4 IPv6
PE-1
MC Pkt
L100
CE-1 MC Pkt
P-4
Pop
MPLS Core
MC Pkt L30
Content Source
Push Swap
MC Pkt PE-3
IPv4 IPv6
CE-3
Receiver
19
mLDP + PE Mapping Options

(Candidate Futures)
1. mLDP native multicast for 4PE (unicast)
mLDP P2MP trees build pretty much like PIM-SSM trees No additional PE-PE signaling required
Just standard IPv4 BGP on PE (for IPv4 and IPv6 user side!)
2. mLDP Direct-MDT in VPN context

Exactly like mLDP native! just rfc2547 VPNv4 BGP AF
No MVPN or similar signaling required
3. mLDP MVPN
Exactly like MVPN signaling Just replaces PIM-SSM+GRE with mLDP MP2MP mLDP replaces Bidir-PIM (MP2MP) Default-MDT
20
mLDP Signaling
With Native and Direct-MDT
mLDP Label Mapping: FEC = S+ G+RD+ Root Label=(20)
PIM-V4 Join: VRF IPTV Source= 10.10.10.1 Group = 232.0.0.1 PIM-V4 JOIN: VRF IPTV Source= 10.10.10.1 Group = 232.0.0.1
mLDP Label Mapping: FEC = S+G +RD+Root Label=(100)
IPv4 CE-2
VRF IPTV Receiver
IPv4
CE-1 PE-1 P-4
PE-2
Content Source
VRF IPTV
MPLS Core
PIM-V4 JOIN: VRF IPTV

Source= 10.10.10.1 Group = 232.0.0.1
P2MP LSP Root
mLDP Label Mapping: FEC= S + G + RD + Root Label=(30)
PE-3
VRF IPv4 IPTV

CE-3
FEC: Forwarding Equivalency Class

Receiver
21
mLDP Signaling
Summary
1. Best of PIM + MPLS
Receiver side originated explicit joins scalable trees PIM-SSM = mLDP P2MP, Bidir-PIM ~= mLDP MP2MP RPF-vector implicit (mLDP root)
2.
Best of LDP
Neighbor discovery, graceful restart, share unicast TCP session No interaction with unicast label assignment (ships in the night)
3. 4.
Variable length FEC

Allows overlay signaling tree 1:1 tree building for ANY (vpn, v6,..) tree
All PIM complexity avoided

No direct source/receiver support (DR) (just PE to PE)
No PIM-SM (need to emulate), No Bidir-PIM DF process
No hop-by-hop RP config (AutoRP, BSR, static) needed) No asserts, other data-triggered events
22
RSVP-TE P2MP Signaling

With Static Native IPv4 to Customer
TE tunnel config: ERO1: P-4, PE-2 ERO2: P-4, PE-3
PATH P4, PE2 RESV Label = 20
Static IGMP/PIM join
PATH P4, PE2
Static IGMP/PIM join Source= 10.10.10.1 Group = 232.0.0.1 On interface to CE
PATH P4, PE3

CE-2
Source= 10.10.10.1 Group = 232.0.0.1 On TE tunnel interface
IPv4
MPLS Core
PE-1 P-4 PE-2
Receiver
IPv4
CE-1
Content Source
RESV Label = 100 RESV Label = 100 PATH P4, PE3

RESV Label = 30
Static IGMP/PIM join
PE-3
Source= 10.10.10.1 Group = 232.0.0.1 On interface to CE
IPv4
CE-3
P2MP LSP Headend

Presentation_ID 2009 Cisco Systems, Inc. All rights reserved.
Label merge ! Assign same upstream label For all branches of a tree
Cisco Confidential
Receiver
23
P2MP RSVP-TE
Summary
1. RSVP-TE P2P LSP
Path explicitly (hop-by-hop) built by headend LSR towards tailend LSR RSVP PATH messages answered by RESV message
2.
P2MP RSVP-TE LSP

A P2MP LSP is built by building a P2P LSP for every tailend of P2MP LSP
Midpoint LSR performs label merge during RESVP:

Use same upstream label for all branches
3.
Almost all details shared with RSVP-TE P2P

All RSVP parameters (for bandwidth reservation) ERO or CSPF, affinities link protection Node protection more difficult
not currently supported
24
Combinations with L3 on PE
With RSVP-TE P2MP (Possible Futures)
1. RSVP-TE P2MP static / native
Core trees statically provisioned on Headend-PE:
Set of tailend-PE
All IP multicast traffic that need to be passed into the tree.
2. RSVP-TE P2MP static in L3VPN context

TBD: Possible, some more per-VRF/VPN config
3. RSVP-TE P2MP dynamic

TBD: MVPN or new PE-PE signaling (work in IETF, vendors) Required / beneficial ?
Reason for RSVP-TE often explicit path definition Not as easy predictable dynamic as static
25
PIM/mLDP Benefits Over RSVP-TE P2MP

Examples (Not Complete)
1. Cost of trees (in node/network)
N = # tailend LSR (#PE) PIM/mLDP P2MP: ~1, RSVP-TE P2MP: ~N Full mesh of RSVP-TE P2MP LSP: ~(N * N) Bidir-PIM/mLDP MP2MP: ~1 Summary: No scaling impact of N for PIM/mLDP Src
Headend LSR
2.
Locality:
Affects convergence/reoptimization speed: 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 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
Rcv
Rcv
26
RSVP-TE P2MP Benefits Over PIM/mLDP

Examples
1. 2. Sub 50 msec protection ?
Also feasible for PIM/mLDP! Src
Headend LSR
Load-split traffic across alternative paths (ECMP or not)

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.
Rcv
Rcv
Rcv
27
Virtualization Considerations
Internet/Walled-Garden or L3VPN ?
1. L3VPN (MVPN) developed as multicast component of (unicast/RFC2547) L3VPN
Primarily for Enterprise VPN services
Usable for IPTV as well (with MVPN-GRE or MVPN-mLDP)
2.
Why ?
Core - operator policy for all services (VPN, IPTV, Internet, ) Edge - wholesale considerations (VPN per wholesaler)
Service separation considerations (service per VPN)
3.
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
28
L2VPN Considerations
1. 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!
2. No (dynamic) P/PE L2 solution with P2MP trees

VPLS: full-mesh/hub&spoke P2P pseudowire only
Non P/PE models available: single-hop protected pseudowires.
3. Recommended directions:
Most simple: one mLDP MP2MP LSP per L2VPN (broadcast) Not to use IGMP/PIM snooping on L2VPN-PE!
Unless customer is provider (eg: broadband edge design)
29
Transit Technologies for IPTV

Summary / Recommendations
1. 2. Native PIM-SSM + RPF-Vector
Most simple, most widely deployed, resilient solution.
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
Strength in TE elements (ERO/CSPF + protection) Recommended for limited scale, explicit engineered designs, eg: IPTV contribution networks.
30
Resiliency
31
Source Redundancy
With SSM
1. Receivers explicitly join to (S,G) Group AND Source 2. What to do if source fails ? 3. Initially ok: join to two sources (S1,G), (S2,G)
Supported by transition solutions like SSM mapping
Double state in network (convergence speed)
Makes operations more difficult

(CAC, RSVP, management, acces control, )
4. Best: use same source-IP address

Known as Anycast, better: Redundant IP address Redundant IP address should be additional/secondary address
Primary address of router always has to be unique
32
Source Redundancy
With SSM
1. L2: Redundant sources in same L2 LAN
No interaction with network required Application must ensure only one source active at any time. Recommended/good for collocated sources.
L2 source redundancy
Src1 Src2
R1
R3 can RPF to either R1 or R2 and receive traffic from either source
RPF
R2
2.
L3: Redundant sources in different LANs

Source to announce redundant IP address for PIMSSM (eg: R3) to know where to RPF/join the traffic. Both sources may send simultaneously ! But announce address only when sending ! RIPv2 most simple announcement protocol NOT RIPv2 between routers! Add BFD srce<->network for efficient fast failover
R3
L3 source redundancy
Src1 Src2
R1
Announce Redundant IP address When source Is sending
RPF
R2
R3
33
Presentation_ID
Cisco Confidential
Source Redundancy
L2/L3 Issue
1. When not use L2 Src redundancy on WAN
Consider Src1/Src2 in different WAN locations with L3 network. Can create L2 connectivity between them.
Eg: EoMPLS R1 <-> R2
L2 source redundancy Across WAN

Location 1 Location 2
Src1
Src2
Does this help to avoid redundant IP source address signaling ? Yes, but R1
EoMPLS
R2
2.
Problem:
L2 and L3 topologies overlap
traffic may flow multiple times over same physical link. Traffic
L3 RPF can not know which edge router (R1, R2) on LAN is closest router toward active source
That is exactly what the announcement of the redundant IP source address would provide !
RPF
R3
L3 core/ distribution network

34
Presentation_ID
Cisco Confidential
Source Redundancy
Anycast/Prioritycast Policies 1. Policies
Anycast: clients connect to the closest
instance of redundant IP address
Src A Src B primary secondary 10.2.3.4/32 10.2.3.4/31
Prioritycast: clients connect to the highestpriority instance of the redundant IP address
2. Also used in other places

Eg: PIM-SM, Bidir-PIM RP redundancy, DNS
3. 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
35
Example: prioritycast with Prefixlength annuncement
Source Redundancy
Explicit Signaling Benefits 1. Subsecond failover possible 2. Represent program channel as single (S,G)
SSM: single tree, no signaling, ASM: no RPT/SPT
3. Move instances freely around the network

Most simply within IGP area Careful across national network (BGP)
4. No vendor proprietary source sync proto required 5. Per program, not only per-source-device failover
Use different source address per program
36
Protected Pseudowires
Classic pseudowire 1. R1/R2 provide pseudowire for R3/R4 accepting/delivering packets from/to physical interface. R1 R3 Pseudowire over LDP MPLS R2 R4
Protected pseudowire 1. Provide sub 50msec link protection for packets of pseudowire (or any other MPLS packets) by configuring RSVP-TE LSP with FRR backup tunnel R1 R3
RSVP-TE (P2P) Tunnels with FRR
R2 Pseudowire over LDP MPLS
R4
Terminated(Routed) pseudowire 1. R1/R2 terminate pseudowire on internal port instead of physical interface. Can bridge (VLAN) or route from/to
2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
RSVP-TE (P2P) Tunnels with FRR
R1 Terminated pseudowire over LDP MPLS
R2
37
Presentation_ID
Sub 50 msec Link Protection

With Protected Pseudowires
Core R6 Distr-Edge routers R4
Access
R5
R1
R2 Access
R3 Access
Access
1. 2.
Consider aggregation network (R-R6). L2 (bridged) or L3 (routed) Configure L2 or L3 multicast to not use physical links between R1-R6, but terminated pseudowires (one-hop). Sub 50 link protection against link failures in ring!
Problem: as long as outage persists, traffic will flow duplicate on links
38
2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
3.
Presentation_ID
Multicast Fast Convergence (FC)

1. FC (unicast and multicast) heavily optimized in IOS/IOS-XR
Limitations in basic principle of tree building:
2. IP multicast
All failures / recoveries / topology changes corrected by re-converging the trees. Same interruption for all causes !!! Re-convergence time is sum of:
Failure detection time (only for failure cases) Unicast routing re-convergence time ~ #Multicast-trees PIM re-convergence time
Possible
~ minimum of 400 msec initial ~ 500 ... 4000 trees convergence/sec (perf)
3. Same targets with mLDP !

39
(classic) Fast Reroute (FRR)

RSVP-TE (P2P, P2MP), IP-FRR (PIM, mLDP)
1. Principles
Local reaction to failure (no signaling) == 50 msec Send traffic on pre-established (Link, Node) backup path (tunnel)
Only in failure case, only necessary on unexpected failures !
Make before break reconvergence / reoptimization

Backup tunnel almost never ideal path Less able not sustain another error while using tunnel !
2. 3.
RSVP-TE P2MP: All included (ietf) !

Not covered: Headend redundancy !
Native IP multicast, mLDP

Optional, not part of protocols themselves Unicast IP-FRR principles already in IETF.
To be leveraged by multicast IP-FRR (for backup tunnels)
40
(classic) FRR
mLDP Link Protection
Rcvr1 L7 R1 L3
R2 L1 s0
R3 L5
S(ource)
php L4 L1 L1
L1: IIF = s0 L2 L1 R5
R4
1. 2.
L5 L1
L3 L1
R6
RSVP-TE P2P backup tunnel or IPFRR / LDP backup tunnel Simple:

When R3 sees link to R going down it takes mLDP packet as it would send it to R2 and sends it into the backup tunnel PHP in R1 will cause backup tunnel labels to be removed
R2 will receive same packet as from s0, just from different interface
Same forwarding !
41
Presentation_ID
Cisco Confidential
(classical) FRR Node Protection

With p2p Backup Tunnels
1. If router with fan-out of N fails, N-times as much backup bandwidth as otherwise is needed.
Provisioning issue depending on topology !
2. Some ideas to use multipoint backup to resolve this, but
3. Recommendation?: Rely on Node HA instead!!

Rcvr1 S(ource)
R1 Rcvr2
R2
R3
R4
R5
R6
42
cFRR
PIM/mLDP Make Before Break
1. S(ource) 2. 3. Cost: 10 Cost: 12 4. Receive RPF change from unicast Send joins to A Wait for right time to go to 4.
Until upstream is forwarding traffic
Change RPF to A
Send prunes to B
5.
Should only do Make-before-Break when old path (B) is known to still forward traffic after 1.
Path via B failed but protected Path to A better, recovered Not: path via B fails, unprotected
Make before Break could cause more interruption than Break before Make !
R(eceiver)
43
Live-Live with Path Diversity

Principles
1. Guarantee:
Transfer two copies of stream path separated - No single failure in network impacts both copies
Best: Two network - traditional finance deployment
Source Or stream
Src
Cheaper: Shared network

Natural diversity Forced diversity (various solutions)
splicer
Protection Domain
2.
Splice and Join at EDGE of network

In actual source/receivers In network devices (dedicated or in router) No need for time-critical operations in core
Naturally or forced disjoint
3.
Live-live service:
receive/deliver two copies, splice/join on customer side. Limited to customers whose app/equip. can support this
4.
Zero-Loss service (using live-live):

Join based on sequence numbers. Protects also against BER on both paths !!!
Receiver Or stream
joiner
Rcv
44
Presentation_ID
Cisco Confidential
Basic MoFRR
ECMP, IGP Upstream
1. Join within network device (router) by switching which received copy to forward.
Switch is not zero loss but (close to) 50msec
Src RH
Protection Domain
2.
R1 MoFRR operations
Expect two RPF paths (from IGP/BGP)
ECMP
Join to both RPF interfaces

Forward traffic from one of them.
Naturally disjoint
RU1 RU2
If used path is lost, switch to second
3.
Various extensions considered

Switchover based on traffic loss Full zero-loss (sequence number based join) Support for more topologies:
U-turn via LFA
R1a
R1 Rcv
R1b
45
U-turn attachment
Path Separation in Rings

Rcvr Rcvr
eQAM
eQAM
Redundant Encoder/Multiplexer
Rcvr Rcvr
Small metric
Infinite/large metric Small metric
Infinite/large metric
1. Can provide live-live guarantee in rings ! Cost saving!

Used in eg: MSO / digital cable
2. Various techniques to create two counterclockwise traffic flows

3. Candidate: Two IGP topologies with asymmetric link costs
46
Application Side Resiliency

1. FEC Forward error correction
Compensate for statistical packet loss Use existing FEC eg: for MPEG transport to overcome BER errors. Potentially applicable to sub 50 msec correction.
2. ARQ - Retransmissions
Done eg: with Cisco VQE unicast retransmissions
Candidate large bursts of retransmissions
Multicast retransmissions would help improve
3. Live-live exception
4. FEC/ARQ introduce delay !
47
RSVP-TE P2P
Workarounds
1. Without improvements (classical FRR or other), IP multicast can not benefit from RSVP-TE P2P tunnels
P2P tunnels break multicast without workarounds:
2. Classic: Auto-tunnel (one-hop) / strategic

TE routes calculated independent of IGP -> IGP still has native route. mpls traffic-eng multicast-intact Changes multicast RPF: If RPF is tunnel, retrieve original IGP route to source from multicast RIB.
3. MPLS TE forwarding adjacency (12.0(15)S, )

tunnel mpls traffic-eng forwarding-adjacency IGP considers TE tunnel as normal interfaces. No guarantee that native paths are calculated.
48
IP Multicast (PIM/mLDP) ECMP

(Equal Cost Multipath) 1. Pseudo-random selection of RPF
if Unicast routing has more than one available path.
2. Polarizing == predictable
(consistent across network), IOS only
ip multicast multipath s-g-hash basic
3. Non-polarizing
IOS and XR (XR default & only option, no config) ip multicast multipath s-g-hash next-hop-based
4. IOS default: no ECMP use highest IP address neighbor
49
IP Multicast (and mLDP) ECMP

Non-Polarizing Means Non-Predictable
1. Polarization:
All routers along network path choose same relative interface for a multicast tree.
2.
Predictability:
With algorithm known, group addresses G of (S,G) can be assigned by operator such that traffic is well split across multiple hops (link bundles)
Workaround, not recommended for highly utilized links (> 85% ?)
Polarizing Bad: Good:
Non-polarizing Good
Bad ?
Link Overload?
4 2
5
Never Used
6 3
4 2
6 3 1
1
50
Multicast and IPTV

Summary
1. 2. Design IP multicast WITH SSM as generic infrastructure service for IPTV and beyond Select transport design
Native IP multicast or mLDP (MPLS core) for most networks to the future
RSVP-TE P2MP for eg: contribution network
3. 4.
Determine appropriate resilience support Path selection

ECMP and multicast or multiple topologies
51
52

Transport Architectures Using Ip Multicast Technology For1615

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Transport Architectures Using Ip Multicast Technology For1615

Hochgeladen von

Copyright:

Verfügbare Formate

Transport architectures using IP Multicast technology for IPTV Services

2009 Cisco Systems, Inc. All rights reserved.

Broadcast IPTV = IP Multicast

4. IP == IPv6 (Japan) or IPv4 (RotW rest of the world)

Solution should minimize involvement in provisioning of individual applications/services

50,000 Feet Architecture

IP multicast Service gateway IP multicast receiver

Receive/process/send Eg: Ad-Splicer, Dserver, Transrater,

50,000 Feet Architecture

IPTV = encoders, groomers, splicers, VoD server, STB,

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

SLA of IP multicast traffic sent/received, Signaling used

Protocols and Services

2. SSM Source Specific Multicast (~2000, rfc4607/4604)

Issues with ASM Resolved with SSM

2. Standard protocol suite PIM-SM/MSDP/Anycast-RP

Scalability, Speed of protocol operations (convergence)

Model / Protocols for SSM

Not IETF standardized

End-to-End Protocol View

L3 Transport Options in clouds:

IGMP: {Limits} {Static-fwd} PIM-SSM

IGMPv3 IGMPv3 IGMPv3 snooping proxy routing SSM

2009 Cisco Systems, Inc. All rights reserved.

2. Concentrate on futures / components

Put traffic into a VPN context

Using L2 vs. L3 on PE nodes

Redefine PE-PE signaling for MVPN

P(rovider)-tree (PMSI) building protocols

PE mapping: C-tree(s) to P-tree

PE-PE (overlay) tree signaling protocols

Upstream PE = Headend LSR

BGP extensions for InterAS and SSM support

MPLS Traffic Forwarding

mLDP + PE Mapping Options

2. mLDP Direct-MDT in VPN context

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

PIM-V4 JOIN: VRF IPTV

P2MP LSP Root

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

VRF IPv4 IPTV

FEC: Forwarding Equivalency Class

Variable length FEC

All PIM complexity avoided

RSVP-TE P2MP Signaling

PATH P4, PE2

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

PATH P4, PE3

Source= 10.10.10.1 Group = 232.0.0.1 On TE tunnel interface

RESV Label = 100 RESV Label = 100 PATH P4, PE3

Static IGMP/PIM join

Source= 10.10.10.1 Group = 232.0.0.1 On interface to CE

P2MP LSP Headend

P2MP RSVP-TE LSP

Midpoint LSR performs label merge during RESVP:

Almost all details shared with RSVP-TE P2P

All IP multicast traffic that need to be passed into the tree.

2. RSVP-TE P2MP static in L3VPN context

3. RSVP-TE P2MP dynamic

PIM/mLDP Benefits Over RSVP-TE P2MP

RSVP-TE P2MP Benefits Over PIM/mLDP

Load-split traffic across alternative paths (ECMP or not)

Use only when needed !

2. No (dynamic) P/PE L2 solution with P2MP trees