NOVEL ALGORITHMS FOR IP FAST REROUTE (DRAFT)

More documents

Recommendations

Info

21 IntroductionIP has come a long way to become a cost-eective bearing platform for commercialservices, providing scalable QoS, point-and-click management, secure VPN services,unpaired scalability, etc. The importance of improving IP in these ways stems fromthe numerous new applications with special needs for transporting trac types IPwas never designed for. Nowadays, Internet has to transport a high amount of realtime trac, such as IPTV, VoIP or trac of on-line gaming. Although several shortcomingswere vanished, an important piece of the puzzle still lags behind: a native IPresilience technique is needed, which is able to provide fast reroute upon failure rises.These days the resilience of IP networks lays on some outdated resilience methodslike plain Open Shortest Path First (OSPF) or Intermediate System to IntermediateSystem (IS-IS), width failure recovery time in the order of seconds. In contrast, currentrequirements usually forces operators to apply MultiProtocol Label Switching(MPLS) or other protocols below the IP layer in order to keep recovery time under50ms, indispensable to reach ve nines availability. The Internet Engineering TaskForce, therefore, has spearheaded the standardization of a fast, intra-domain, full-IPresilience mechanism. This eort gave rise to the IP Fast ReRoute (IPFRR) framework,which, as of this writing, is on its way to become an Internet RFC [Shand08].IPFRR is an eective reformulation of MPLS Fast Reroute on the context of IP.As the ones used in MPLS networks, these techniques decrease convergence time byusing Local and Proactive recovery. Here, Local means that only routers neighborthe failed resource change their state and it is not needed to inform other partsof the network for recovery. In this way saving the time of communication is possible.Moreover, Proactive means that routers prepare for the failure long before it occursin reality. Naturally, since preparing for unlimited number of failures in arbitrarynetworks is impossible, these techniques prepare only for single failures, which is definitelythe most common case. Then, while the failure is being handled by an IPFRRmethod, the network remains still operable giving the chance of reconguration andpreparing to another fast recovery.One may observe that local rerouting in IP networks is not trivial. Since forwardingdecision in IP bases exclusively on the destination address of the package, simplyforwarding to a node, which does not know about the change of topology commonlycauses loop. Thus, IPFRR algorithms need to mark packages on detour, either implicitlyor explicitly. Implicit marking is realizable by the incoming interfaces; if notonly the destination address but also the incoming interface is taken into considerationduring the forwarding decision, IP fast reroute becomes possible [Nel06]. Forexplicit marking, it is usually proposed to reserve some bits [Cicic07], or to create anIP-in-IP tunnel with a header containing a special destination address [Bry08].Although it is easy to see that the way of marking packets is extremely important
for Local rerouting, current solutions in the literature have focused too exclusivelyon this problem and have settled for some variations of shortest path as Proactivedetour computation. As shell be revealed below, sometimes giving up shortest pathscan carry signicant advantages.2 Research Objectives3 Methodology4 New Results4.1 Handling Multiple Failures with Interface-based IP FastReRouteIn this part I deal with the problem of interface-base IP fast reroute, techniquesusing interface-based forwarding. In contrast to traditional IP forwarding, whichselects the next hop based on the destination address of the packet, interface-basedforwarding takes into consideration both the destination address and the incominginterface. Since forwarding decision in modern routers is made by the linecards ofthe interfaces, it is very easy to realize this type of forwarding; if dierent forwardingtables are downloaded to these linecards, the next hop depends on the incominginterface as well. Using this extra information providing IP fast reroute becomespossible without new hardware. The rst interface-based IP fast reroute algorithmis the Failure Insensitive Routing (FIR [Nel06]), which can always avoid single linkfailures (if a path between the source and the destination still exists). Although theauthors presented two algorithms, the computed routes are the same, so I refer tothese as FIR in the sequel.THESIS 1: [C2][C3] I have shown that detours computed by FIR are not necessarilyloop-free. I proposed a new loop-free interface-based IP fast reroute method in orderto avoid this shortcoming.Forming loops in networks should always be avoided, since they may have devastatingeects. In a loop the number of packets can become very high, in this way theprobability of packet loss is increased as well and even those parts of the network canbecome unavailable, which were not eected by the original failure.The main reason of forming loops stems from the way of selecting default paths.If in the intact network shortest paths are used for default forwarding, it can not beguaranteed that detours are loop-free.THESIS 1.1: There does not exist an interface-based IP fast reroute technique that3
Page 4 and 5: 4Figure 1: Loop in a network with i
Page 6 and 7: 6Figure 3: A pair of node-redundant
Page 8 and 9: 8almost fullling DAG properties. Mo
Page 10 and 11: 10Algorithm 2 Finding the edges (h
Page 13 and 14: THESIS 3.4: I dened heuristics to c
Page 15 and 16: IP Fast ReRoute.Computing the next
Page 17: 17Publication of new results[J] Jou

NOVEL ALGORITHMS FOR IP FAST REROUTE (DRAFT)

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?