IETF San Francisco Multicast-only Fast ReRoute (MoFRR) Dino Farinacci Apoorva Karan Clarence Filsfils March, 2009

IETF San FranciscoIETF San Francisco

Multicast-only Fast ReRouteMulticast-only Fast ReRoute

(MoFRR)(MoFRR)

Dino FarinacciApoorva KaranClarence Filsfils

March, 2009

MoFRRMoFRR IETF San FranciscoIETF San Francisco 03/2009 - 03/2009 - 22

AgendaAgenda

• Problem Statement• Solution Statement• Two-Plane Network Design• Generalization to Non-ECMP• Ring Topology • Failure Detection• IPR Disclosure


Problem StatementProblem 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


Solution StatementSolution 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


Solution StatementSolution 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


Solution StatementSolution 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


ECMP ExampleECMP ExampleS

R

AA

BB CC

DD

join path

data path

alt path

alt data path

wasted bandwidth

wasted bandwidth

R

not

1) D has ECMP path {BA, CA} to S2) D sends join on RPF path through C3) D can send alternate-join on BA path4) A has 2 oifs leading to a single receiver5) When RPF path is up, duplicates come to D6) But D RPF fails on packets from B

7) If upstream of D there are receivers, bandwidth is only wasted from that point to D 8) When C fails or DC link fails, D makes

local decision to accept packets from B9) Eventually unicast routing says B is new RPF path

rpf path (RPF join)

alt join (sent on non-rpf)

redundant path

link down or RPF-failed packet drop

data path


Two-Plane Network DesignTwo-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

– pop’s are dual-homed to each plane– important content (IPTV source)

is dual-homed to both planes

IPTV source

Pop2PopN


Two-Plane Network DesignTwo-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 in a PoP are or must be assumed to be connected to the tree

IPTV source

Pop2PopN


MoFRR Applied to Two-Plane MoFRR Applied to Two-Plane Network DesignNetwork 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 property of the design (!)

Pop1

IPTV source

PopN


MoFRR Generalization to MoFRR Generalization to Non-ECMP 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


Ring Topology ExtensionsRing 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 and Generic MoFRR and Generic TopologyTopology

• 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


Failure DetectionFailure 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


Failure Detection Failure Detection AlgorithmAlgorithm

• 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



• 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 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 already-established MoFRR backup branch.

– Gain over FC: no time incurred due to the building of the new branch

– Target: sub200msec


MoFRR and MPLS MoFRR and MPLS TransportTransport

• MoFRR is as applicable to MLDP as to PIM


IPR DisclosureIPR Disclosure

• MoFRR Patent Application– Filed April 26, 2007

• MoFRR extensions for Ring Topologies– Filed February 12, 2008

Documents

IETF San Francisco Multicast-only Fast ReRoute (MoFRR) Dino Farinacci Apoorva Karan Clarence Filsfils March, 2009