190 likes | 396 Views
IP fast reroute s olutions and challenges. Amund Kvalbein. Outline. Motivation for fast IP recovery What do we want? Current solutions What are the challenges?. Do we need proactive IP recovery?. Yes: Strict delay/availability requirements dictate a proactive solution
E N D
IP fast reroutesolutions and challenges Amund Kvalbein
Outline • Motivation for fast IP recovery • What do we want? • Current solutions • What are the challenges?
Do we need proactive IP recovery? • Yes: • Strict delay/availability requirements dictate a proactive solution • The costs of a re-convergence are too great for transient failures • No: • Re-convergence is fast enough (sub-second) • If you want FRR, use MPLS
What do we want? Functional: • Protect both link and node failures • 100% coverage (?) • Easy support for multicast traffic • LANs, ECMP, asymmetric weights, SRLG, MPLS • Protect multihomed prefixes if reachable Operational: • Smooth network dynamics / plug-and-play • Easy integration in current routing • Nice distribution of recovered traffic
Selected IPFRR mechanisms • Interface specific routing (USC) • Not-via (Cisco) • Multiple Routing Configurations (Simula) • (IP Redundant Trees (Simula)) All give protection against both link and node failures
Interface specific routing (FIR/FIFR) • Infer failures from packet flight • Interface specific FIB • Repair to egress
FIR/FIFR strengths • No tunnelling, packet marking or other special treatment of repaired traffic • Repair paths almost shortest path • Easy support for MHP
FIR/FIFR weaknesses • Not always 100% coverage • No strategy for last-hop link failures • Issue with looping when there are more than one failure • Not easy support for multicast traffic • Little flexibility to control recovered traffic • Difficulties with SRLGs
Not-via • Connectionless version of MPLS-FRR • Create special not-via addresses • Routing to these addresses is restricted • Avoid the failed component • 2|E| addresses needed • Repair to next-next hop
Not-via strengths • 100% coverage • Easy support for multicast traffic • Due to repair to next-next hop • Easy support for SRLGs • …
Not-via weaknesses • Relies on tunnelling • Heavy processing • MTU issues • Suboptimal backup path lengths • Due to repair to next-next hop
Multiple Routing Configurations • Relies on multiple logical topologies • Builds backup configurations so that all components are protected • Recovered traffic is routed in the backup configurations • Repairs to the egress node
MRC strengths • 100% coverage • Better control over recovery paths • Recovered traffic routed independently • Easy support for SRLGs
MRC weaknesses • Needs a topology identifier • Packet marking, or • Tunnelling • Multicast not trivially solved • Number of topologies not bounded
IP redundant trees • New method developed at Simula by combining RT and MRC • Fixed number of backup ”topologies” (two trees) • Trees are calculated per destination
Key design difference • Where is recovered traffic sent • Next-next hop (Not-via) • Egress router (FIR & MRC) • This has consequences for • MC support • Traffic Engineering
Combining MRC and Not-via • If tunnelling is used in MRC, then MRC can be seen as a generalized version of not-via • Freedom to repair to egress or next-next hop • Not-via: exclude heavily loaded links
Main challenges • How to handle network dynamics • MC support • More elegant support for MHP • Effects of FRR on traffic (TCP etc) • Practical issues • FIB organisation • Traffic differentiation
Intra-domain and other network environments Mike (Scribe) Tarik Audun Srihari Inter-domain Georgios (Scribe) Rudiger Amund Pierre Framework & Metrics James (Scribe) Michael Josh Stein Marian Groups