IETF San Francisco
Multicast-only Fast ReRoute
(MoFRR)
Dino Farinacci
Apoorva Karan
Clarence Filsfils
March, 2009
Agenda
•
•
•
•
•
•
•
Problem Statement
Solution Statement
Two-Plane Network Design
Generalization to Non-ECMP
Ring Topology
Failure Detection
IPR Disclosure
MoFRR
IETF San Francisco
03/2009 - 2
Problem Statement
• Multicast streams need resiliency for network outages
– Need fast switchover times with near 0 packet loss
– 50 ms, 100s ms, definitely < 1 second
• Switchover time frame requirement ranges
– 500ms to 1000ms - unicast routing with FC satisfies
– 100ms to 500ms - unicast routing with FC satisfies
• Reality - what is really needed
– 50ms to 100ms - problem space for MoFRR
• Perception - what they think they need
• Fact - Losing an I-frame with 50ms rerouting has same visual
impact as with 400ms rerouting
MoFRR
IETF San Francisco
03/2009 - 3
Solution Statement
• For really fast switchover
– Cannot use messaging - takes too long
– Cannot repair when failure occurs - takes too
long
– Can’t depend on unicast routing convergence
• Times are around 500 - 1000 ms
• We want 50 - 100 ms times
– Need to be relatively low cost
– Incremental deployment desirable
MoFRR
IETF San Francisco
03/2009 - 4
Solution Statement
• MoFRR - Advantages
– Does not require specialization of core for an
application
– Depends solely on PIM - does not wait for
unicast routing protocol convergence
– An alternative to source redundancy, but
• Don’t have to provision sources
• Don’t have to sync data streams
• No duplicate data to multicast receivers
– Upstream routers do not require MoFRR
• Simple
• Incremental deployment
MoFRR
IETF San Francisco
03/2009 - 5
Solution Statement
• MoFRR - Disadvantages
– Not meant to be a generic solution for all
topologies. Rather, a simple solution that applies to
a frequent network design
– Depends on ECMP
• Could work with Non-ECMP
• Extensions for Ring Topologies
– Redundant data in some parts of the network
• As membership becomes dense, this is less of a problem
MoFRR
IETF San Francisco
03/2009 - 6
ECMP Example
S
not wasted bandwidth
A
alt data path
R
B
data path
alt
path
join
path
7) If upstream of D there are
receivers, bandwidth is only
wasted from that point to D
wasted bandwidth
data path
redundant path
rpf path (RPF join)
alt join (sent on non-rpf)
link down or RPF-failed packet drop
MoFRR
D
C
8) When C fails or DC link fails, D makes
local decision to accept packets from B
9) Eventually unicast routing says B is new
RPF path
R
1) D has ECMP path {BA, CA} to S
2) D sends join on RPF path through C
3) D can send alternate-join on BA path
4) A has 2 oifs leading to a single receiver
5) When RPF path is up, duplicates come to D
6) But D RPF fails on packets from B
IETF San Francisco
03/2009 - 7
Two-Plane Network Design
• Many SP networks apply the Two-Plane Design
– two symmetric backbone planes (green and red)
– interconnected by grey links with large metrics to ensure
that a flow entering the red plane goes all the way to its
exit via the red plane
IPTV source
– pop’s are dual-homed to each plane
– important content (IPTV source)
is dual-homed to both planes
MoFRR
IETF San Francisco
Pop2
PopN
03/2009 - 8
Two-Plane Network Design
• An IPTV SSM Tree for a premium channel is densely covering
the two-plane design
• Dense trees : key to analysis. For IPTV, we assume there are
many receivers
• From a capacity planning viewpoint, all Green and
Red routers
IPTV source
in a PoP are or must be assumed to be connected to the tree
MoFRR
IETF San Francisco
Pop2
PopN
03/2009 - 9
MoFRR Applied to Two-Plane
Network Design
• MoFRR only needs to be deployed on PE’s (!)
• Does not create any additional capacity demand (!)
• Disjointness does not need to be created by
explicit routing techniques. This is a native
IPTV source
property of the design (!)
Pop1
MoFRR
IETF San Francisco
PopN
03/2009 - 10
MoFRR Generalization to
Non-ECMP
• Re-use IP-FRR intelligence to choose
a loop-free alternative
• Sends an additional PIM join to any
IGP neighbor who is strictly closer to
the source than you because you’re
sure that router will never send a join
to you
– If multiple candidates, leverage LSDB
to choose the most disjoint candidate
MoFRR
IETF San Francisco
03/2009 - 11
Ring Topology Extensions
• On rings, most nodes have 2 non-ECMP paths
and no loop free alternative
• The shortest path is via the RPF interface and
the other path is via the alternate interface
• To support MoFRR, the two ring interfaces
(primary and alternate ring interface) need to
be configured on the router
• Special routing and forwarding rules have to be
defined
• These extensions will be documented in future
versions of the draft
MoFRR
IETF San Francisco
03/2009 - 12
MoFRR and Generic Topology
• In topologies considered so far, there are
alternate paths to the source
• If the topology does not support natural
disjoint paths, then extra cost and
complexity need to be incurred (MT, RSVP)
to create these disjoint paths.
• The switch-over (<50msec) or zero-loss
techniques would likely be leveraged
MoFRR
IETF San Francisco
03/2009 - 13
Failure Detection
•
•
•
•
Direct link failures are detected fast
Neighbor failures can be detected fast
Upstream router or link failures take time
We need one solution to detect all cases
MoFRR
IETF San Francisco
03/2009 - 14
Failure Detection Algorithm
• Monitor data flow on RPF path
–
–
–
–
Constant-bit-rate apps have excepted packet arrival time
Use counters to see if packets have been received
Polling interval is loss budget
If counter doesn’t increment within interval, there is an
upstream failure
• Switch to alt-interface
– If false positive, doesn’t matter if you are getting the
data, don’t have to switch back
– Unicast routing will tell you later if path failed
MoFRR
IETF San Francisco
03/2009 - 15
Failure Detection Algorithm
• 50 ms MoFRR
– IPTV Inter-packet Gap is 0(1msec).
– Monitor SSM (S, G) counter and if no packet
received within 50msec switch onto the backup
branch
– Local detection with end-to-end protection!
• MoFRR Zero-Loss
– IPTV flows to use RTP
– MoFRR PE device to repair any loss thanks to
RTP sequence match on the disjoint branch
MoFRR
IETF San Francisco
03/2009 - 16
Failure Detection Algorithm
• MoFRR based on RIB trigger
– Upon failure along the primary path, IGP
converges and the best path to the
source is modified.
– This triggers the use of the alreadyestablished MoFRR backup branch.
– Gain over FC: no time incurred due to
the building of the new branch
– Target: sub200msec
MoFRR
IETF San Francisco
03/2009 - 17
MoFRR and MPLS Transport
• MoFRR is as applicable to MLDP as to
PIM
MoFRR
IETF San Francisco
03/2009 - 18
IPR Disclosure
• MoFRR Patent Application
– Filed April 26, 2007
• MoFRR extensions for Ring Topologies
– Filed February 12, 2008
MoFRR
IETF San Francisco
03/2009 - 19