Multicast in IP Fast Reroute Jozef Papan, Pavel Segec, Peter Paluch * Faculty of Management Science and Informatics, University of Zilina, Univerzitna 8215/1, 010 26 Zilina, e-mail: {jozef.papan, pavel.segec, peter.paluch}@fri.uniza.sk Abstract — Over the last few years, Internet Protocol (IP) networks have made significant progress, allowing to provide voice over IP (VoIP) and other real-time services. The quality of provided real-time services depends on quality parameters of the network (QoS). One of the leading QoS parameters is the survivability of network itself. The survivability parameter reflects on how fast the network will recover after the failure of a link or a node. One of mechanisms which significantly improves the survivability of network is the IP Fast Reroute (IP FRR) mechanism. Currently, there are many of IPFRR methods mainly developed by IETF. In this paper we present and analyze few of existing IP FRR proposals. Finally we introduce a new method utilizing the multicast technology improving recovery time after a link or a node failure. Keywords—IP Fast Reroute; IP FRR; multicast; PIM-SM I. INTRODUCTION The primary reason why IP FRR mechanisms are very important is that after a node or a link failure the convergence time (defined as the maximum time between the occurrence of the failure and the moment of establishing a replacement path on a network node) in large networks is not fast enough. The disruption of network paths and reconvergence may take from hundreds of milliseconds up to tens of seconds. Overall time depends on the size of network and on the type of routing protocol used in the network. The main goal of IP FRR mechanisms is to achieve very fast network recovery time. These mechanisms can provide up to 50 ms network recovery time after node or link failure [1][2]. To achieve such a very fast recovery time we need to quickly detect the failure of a link or the unavailability of a next node. There are several methods of detecting a link failure – detecting a loss of carrier signal, loss of link pulses, loss of bit/symbol/frame/multiframe synchronization, increase in bit error ratio or number of FEC corrections, loss of keepalive/heartbeat messages, etc. Many of these mechanisms, however, depend on the capabilities of the chosen physical and data link layer technology, and cannot be arbitrarily added. Therefore, software-based Layer 2 or Layer 3 signalling is often used. As an example, the Bidirectional Forwarding Detection (BFD) protocol [3] defines a method to detect faults in the bidirectional path between two systems. BFD is a simple Hello protocol which allows pair of systems transmits BFD packets periodically over the path to validate the link or the system availability. After the failure detection, IP FRR mechanism will instruct the data plane of a router to use an alternate pre-computed route to bypass the failed link or node (see Fig. 1) [4]. The new alternate route can not traverse through the failed link. The router may have more than one pre-computed routes. The idea of pre-computed routes is common for all IP FRR mechanisms and it is the key factor to achieve rapid restoration of networks. Fig. 1. IP Fast Reroute. The route installed by the IP FRR mechanism to protect the IP traffic is used only for a time till the process of routing protocol convergence is running in the background. After the convergence is complete, the routing protocol takes the control of local routing again. The link protected against a failure is called the protected link. Individual IP FRR mechanisms are designed for specific network topologies. An important aspect of IP FRR mechanisms is the way they are computing the backup routes. Each router on the network makes its decisions based on its own internal rules. A router that received a packet from an alternative backup route may determine failure by implicit or explicit way. Implicitly means, when the router begins receiving packets over an unusual physical interface. Explicitly means, when the source router will change specific bites inside of the IP packet header, and another receiving router makes specific reaction based on it. Various IP FRR mechanisms have a different percentage of repair coverage. Repair coverage of IP FRR mechanism is dependent on the repair strategy and highly dependent on the specific topology and metrics. If a strategy of IP FRR mechanism will permit the repair of all single link or node failures within the network topology, it can be defined as 100% repair coverage [4]. Unfortunately there is no exact method for measuring IPFRR repair coverage. Present methods of measuring repair