Transport architectures using IP Multicast …palo/Rozne/cisco-expo-2009...Presentation_ID © 2009...
Transcript of Transport architectures using IP Multicast …palo/Rozne/cisco-expo-2009...Presentation_ID © 2009...
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 1
Transport architectures using
IP Multicast technology for IPTV
Services
Stefan Kollar Consulting System Engineer, CCIE #10668 [email protected]
2
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Agenda
1. Introduction
2. Architectural overview
3. IP multicast primer (SSM)
4. Transit Transport Design options
5. Wholesale / content distribution
6. Resiliency
Source redundancy, protected pseudowires,
fast convergence, FRR, live-live, MoFRR
7. Path selection
ECMP, multi topologies, RSVP-TE P2MP
3
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Introduction
IPTV and IP Multicast
4
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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
5
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Deployment StrategyOverview, 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
6
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Architectural Overview
7
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
50,000 Feet ArchitectureIPTV and Multicast
“Network Plane”
IPTV “Services Plane”
IP multicast
source IP multicast
receiver
IP multicast
Service gatewayReceive/process/send
Eg: Ad-Splicer, Dserver, Transrater,…
The network
Sig
na
lin
g
Sig
na
lin
g
Sig
na
lin
g
Service Interface
Multicast trafficMulticast traffic
8
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
50,000 Feet ArchitectureGoals
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
9
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
IP Multicast Primer
10
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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!
11
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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
12
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
IP Multicast ServicesIssues with ASM – Resolved with SSM
1. ASM
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
13
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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)
14
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
End-to-End Protocol ViewExample: L3 Aggregation
PIM-SSM (S,G) joins IGMPv3 (S,G) membership
STBHome
Gateway
BB typespecific
PE-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
?
15
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Transit Transport
Design Options
16
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Transport ArchitectureOverview
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
17
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
OverviewElements of Transport Architecture for Tree Building
1. C(ustomer)-tree building protocols
IPTV: IGMPv3 / PIM-SSM
2. P(rovider)-tree (PMSI) building protocols
Native: PIM-SSM/SM/Bidir, MPLS: mLDP, RSVP-TE
3. PE mapping: C-tree(s) to P-tree
1:1/N:1 (aggregation) ; „native‟/VPN (L2, L3) ; static/dynamic
4. 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 Source
Receiver
Receiver
18
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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 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
19
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Content Source
PE-1
PE-2
PE-3
P-4CE-1
CE-2
CE-3
MPLS Core
Receiver
Receiver
IPv4IPv6
IPv4IPv6
IPv4IPv6
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
L100
“Push”
MC Pkt L20
L30
“Swap”
“Pop”
MC Pkt
MC Pkt
MC Pkt
MC Pkt
MC Pkt
20
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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
21
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
mLDP SignalingWith Native and Direct-MDT
Content Source
PE-1
PE-2
PE-3
P-4CE-1
CE-2
CE-3
MPLS Core
Receiver
Receiver
IPv4
IPv4
IPv4
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+ RootLabel=(20)
mLDP Label Mapping:FEC = S+G +RD+RootLabel=(100)
PIM-V4 Join: VRF IPTV
Source= 10.10.10.1
Group = 232.0.0.1
mLDP Label Mapping:FEC= S + G + RD + RootLabel=(30)
P2MP LSP“Root”
VRF
IPTV
VRF
IPTV
VRF
IPTV
FEC: Forwarding Equivalency Class
22
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
mLDP SignalingSummary
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. Variable length FEC
Allows overlay signaling tree 1:1 tree building for ANY (vpn, v6,..) tree
4. 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
23
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
RSVP-TE P2MP SignalingWith Static Native IPv4 to Customer
Content Source
PE-1
PE-2
PE-3
P-4CE-1
CE-2
CE-3
MPLSCore
Receiver
Receiver
IPv4
IPv4
IPv4
PATH P4, PE2
P2MP LSPHeadend
Static IGMP/PIM join
Source= 10.10.10.1
Group = 232.0.0.1
On interface to CE
Static IGMP/PIM join
Source= 10.10.10.1
Group = 232.0.0.1
On TE tunnel interface
Static IGMP/PIM join
Source= 10.10.10.1
Group = 232.0.0.1
On interface to CE
TE tunnel config:
ERO1: P-4, PE-2
ERO2: P-4, PE-3
PATH P4, PE3
PATH P4, PE2
RESV Label = 20
RESV Label = 30
RESV Label = 100
RESV Label = 100
Label merge !
Assign same upstream label
For all branches of a tree
PATH P4, PE3
24
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
P2MP RSVP-TESummary
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
25
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Combinations with L3 on PEWith 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
26
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
PIM/mLDP Benefits Over RSVP-TE P2MPExamples (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
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.
Src
Rcv
Rcv
Rcv
HeadendLSR
27
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
RSVP-TE P2MP Benefits Over PIM/mLDPExamples
1. Sub 50 msec protection ?
Also feasible for PIM/mLDP!
2. 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.
Src
Rcv
Rcv
Rcv
HeadendLSR
28
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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
29
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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)
30
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Transit Technologies for IPTVSummary / 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
Strength in TE elements (ERO/CSPF + protection)
Recommended for limited scale, explicit engineered designs,
eg: IPTV contribution networks.
31
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Resiliency
32
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Source RedundancyWith 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
33
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Source RedundancyWith 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.
2. L3: Redundant sources in different LANs
Source to announce redundant IP address for PIM-SSM (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
Src1 Src2
Src1 Src2
R3
L2 source redundancy
L3 source redundancy
…
Announce
RedundantIP addressWhen source
Is sending
RPF
R3
RPF
R3 can RPF
to either R1
or R2 and
receive traffic
from either source
R1 R2
R2R1
34
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Source RedundancyL2/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
Does this help to avoid redundant IP source address signaling ?
Yes, … but …
2. Problem:
L2 and L3 topologies overlap
traffic may flow multiple times over same physical link.
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 !
Src1 Src2
L2 source redundancy
Across WAN
R3RPF
R1 R2
Location 1 Location 2
L3 core/
distribution
network
EoMPLS
Traffic
35
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Source RedundancyAnycast/Prioritycast Policies
1. Policies
Anycast:clients connect to the closest instance of redundant IP address
Prioritycast:clients connect to the highest-priority 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.
Src B
secondary
Rcvr 2Rcvr 1
Src A
primary
10.2.3.4/31
Example: prioritycast with
Prefixlength annuncement
10.2.3.4/32
36
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Source RedundancyExplicit 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
37
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Terminatedpseudowire
over LDP MPLS
Protected Pseudowires
Classic pseudowire
1. R1/R2 provide pseudowirefor R3/R4
accepting/delivering packets from/to physical interface.
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
Terminated(Routed) pseudowire
1. R1/R2 terminate pseudowire on internal port instead of physical
interface. Can bridge (VLAN) or route from/to port.
R3R4
R1 R2
R2R1
R3
R4R1 R2
Pseudowireover LDP MPLS
Pseudowireover LDP MPLS
RSVP-TE (P2P) Tunnels with FRR
RSVP-TE (P2P) Tunnels with FRR
38
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Sub 50 msec Link ProtectionWith Protected Pseudowires
1. Consider aggregation network (R-R6). L2 (bridged) or L3 (routed)
2. 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!
3. Problem: as long as outage persists, traffic will flow duplicate on links
R1
Access
Core
Distr-Edge routers
R2 R3
R4
R5R6
Access
AccessAccess
39
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_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 !
40
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
(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. RSVP-TE P2MP: All included (ietf) !
Not covered: Headend redundancy !
3. 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)
41
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
(classic) FRRmLDP Link Protection
1. RSVP-TE P2P backup tunnel or IPFRR / LDP backup tunnel
2. 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 !
S(ource)Rcvr1R1 R2 R3
R4
R5
R6
s0
L1: IIF = s0
L2
L3
L4
php
L5L3L7 L1
L1
L1
L1 L1
L5 L1
42
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
(classical) FRR Node ProtectionWith 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!!
S(ource)Rcvr1
R1 R2 R3
R4 R5 R6
Rcvr2
43
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
cFRRPIM/mLDP Make Before Break
1. Receive RPF change from unicast
2. Send joins to A
3. Wait for right time to go to 4.
Until upstream is forwarding traffic
4. Change RPF to A
5. Send prunes to B
Should only do Make-before-Break when oldpath (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 !
A B
S(ource)
Cost: 10
C
Cost: 12
R(eceiver)
44
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Live-Live with Path DiversityPrinciples
1. Guarantee:
Transfer two copies of stream path separated - No single failure in network impacts both copies
Best: Two network - traditional finance deployment
Cheaper: Shared network
Natural diversity
Forced diversity (various solutions)
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
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 !!!
Src…
Naturallyor
forceddisjoint
…Rcv
Pro
tectio
n D
om
ain
SourceOr
stream
splicer
ReceiverOr
stream
joiner
45
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Basic MoFRRECMP, IGP Upstream
1. Join within network device (router) by switching which received copy to forward.
Switch is not zero loss – but (close to) 50msec
2. R1 MoFRR operations
Expect two RPF paths (from IGP/BGP)
ECMP
Join to both RPF interfaces
Forward traffic from one of them.
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
Src
R1
RU1 RU2
Naturallydisjoint
Rcv
RH
Pro
tectio
n D
om
ain
R1a R1b
U-turn attachment
46
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Path Separation in Rings
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
RedundantEncoder/Multiplexer
RcvrRcvr
Rcvr
Rcvr Small metric
Infinite/largemetric Infinite/large
metricSmall metric
eQAM
eQAM
47
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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 !
48
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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.
49
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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
50
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
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% ?)
1
32
4 5 6 7
Polarizing
Bad ?Good:Bad:
NeverUsed
1
32
4 5 6 7
Non-polarizing
GoodLink
Overload?
51
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID
Multicast and IPTVSummary
1. Design IP multicast WITH SSM as generic infrastructure service – for IPTV and beyond
2. Select transport design
Native IP multicast or mLDP (MPLS core) for most networks to the future
RSVP-TE P2MP for eg: contribution network
3. Determine appropriate resilience support
4. Path selection
ECMP and multicast or multiple topologies
52
© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID