IP Multicast Fault Recovery in PIM over OSPF

Transcription

1 1 IP Mlticast Falt Recovery in PIM over OSPF Abstract Relatively little attention has been given to nderstanding the falt recovery characteristics and performance tning of native IP mlticast networks. This paper focses on the interaction of the component protocols to nderstand their behavior in network failre and recovery scenarios. We consider a mlticast environment based on the Protocol Independent Mlticast (PIM) roting protocol, the Internet Grop Management Protocol (IGMP) and the Open Shortest Path First (OSPF) protocol. Analytical models are presented to describe the interplay of all of these protocols in varios mlticast channel recovery scenarios. Qantitative reslts for the recovery time of IP mlticast channels are given as references for network configrations, and protocol development. Simlation models are developed sing the OPNET simlation tool to measre the falt recovery time and the associated protocol control overhead, and stdy the inflence of important protocol parameters. A testbed with five Cisco roters is configred with PIM, OSPF, and IGMP to measre the mlticast channel failre and recovery times for a variety of different link and roter failres. In general, the failre recovery is fond to be light-weight in terms of control overhead and recovery time. Failre recovery time in a WAN is fond to be dominated by the nicast protocol recovery process. Failre recovery in a LAN is more complex, and strongly inflenced by protocol interactions and implementation specifics. Sggestions for improvement of the failre recovery time via protocol enhancements, parameter tning, and network configration are provided. I. INTRODUCTION Many IP mlticast applications, for example, near real-time dissemination of financial information, reqire high availability. This problem has not received mch attention so far. One exception is STRESS [1], a tool that atomates the formal evalation of PIM sparse-mode protocol robstness. However, STRESS does not inclde timers, and does not consider the interaction between nicast and mlticast protocols. Mlticast grop membership management, nicast roting protocols, and mlticast roting protocols are all reqired to enable end-to-end mlticast capabilities. In this paper, we investigate a complete mlticast roting architectre consisting of IGMP [6] for mlticast grop membership management in a LAN, OSPF [4] for nicast roting, and PIM sparse-mode [8] and PIM dense-mode [7] for mlticast roting. OSPF is chosen becase of its rapid falt recovery properties, widespread se, and its spport of parametrically tning of falt recovery time, as compared with RIP which has long, non-tnable fail-over periods. The two variants of PIM are becoming the dominant mlticast roting protocols. Other mlticast protocols, sch as DVMRP or CBT resemble dense and sparse mode, respectively, and we ths expect that many of or reslts apply to these and similar protocols as well. End-to-end mlticast channel falt recover is a fnction of the interplay of all of these protocols and is ths the focs of this paper. We investigate how qickly the mlticast channel recovers when links and roters fail in a mlticast network. We define a mlticast channel as the state established in roters and hosts that allows a single sender to commnicate with a grop of receivers. We consider single link and roter falts inside the network, bt we assme that sending and receiving hosts, their LANs are reliable. Since falt recovery associated with rendezvos point (RP) failres in PIM SM have been stdied extensively [8], this paper focses on other mechanisms (roter, link, LAN, WAN fail-over) that are not sfficiently addressed and are less well nderstood by the commnity. The key aims of this stdy are: develop a detailed nderstanding of the protocol interactions and seqence of events nder different failre scenarios; provide qantitative insight into the effect of protocol parameters on recovery time and overhead; develop general sggestions for parametric tning of protocols and enhancements to protocol specifications and implementation. To achieve these objectives, we combine reslts from analytical analysis, simlations and testbed measrements. In the analysis, we present the interactions of the protocols (PIM, OSPF, IGMP) with end-to-end mlticast channel recovery nder varios network failre scenarios. We also develop some qantitative reslts that can be sed as references for network configrations and protocol development. In addition, the analysis serves as a basis for or providing recommendations on the protocol enhancement. Simlation models for IGMP, PIM DM and spport tools were constrcted sing the OPNET [11] simlation platform. The simlation is sed to measre the control costs of the trio of protocols dring steady state and failre recovery scenarios, for varios random topologies and with varios parametric tnings. Frthermore, the simlation is sed to validate the failre recovery reslts derived from the analytical models. The experimental reslts were spplemented by stdying the operation and failre recovery of the protocols on a testbed of five Cisco roters arranged in a simple topology. This enabled a basic demonstration of failre recovery on WAN and LAN, and also allowed s to identify some implementation-related isses that affect failre recovery. The paper is organized as follows. Section II reviews IGMP, OSPF and PIM. Section III describes the topologies and configrations we sed, as well as the chain of events cased by link or roter failres. We also present several analytical mlticast recovery models. Section IV and V present the simlation and testbed reslts, respectively. II. OVERVIEW OF PROTOCOLS The establishment of end-to-end mlticast commnication channels reqires several protocols to work in concert. To establish a mlticast channel over a native mlticast enabled WAN, a sender application needs only to send UDP packets onto the LAN sing a class D IP address (grop address) in the destination field of the IP header. Mlticast grop information on a LAN is sally maintained by the IGMP protocol. The mlticast enabled roters in the network are responsible for constrcting the mlticast channel, and extending it to the interested receivers; in or case, this is done sing PIM DM or PIM SM. The mlticast protocol constrcts the mlticast delivery tree sing the metrics and topology information maintained by the nicast roting protocol; in or case, OSPF. Below, we briefly review these protocols. A. IGMP IP Mlticast delivery is selective; only those hosts that have expressed interest in joining the grop will become attached to the channel. The IGMP protocol manages the grop interests between hosts and their first hop roters. One mlticast roter on each LAN serves as a Qerier for soliciting the grop membership information by periodicallysendinga General Qery message at the Qery

2 Interval (defalt 125 s) to all hosts on the LAN. In response, a host sends a Host Membership Report message to the grop address for each grop to which it desires to belong, within a bonded random interval Qery Response Interval (defalt 10 s). When a Qerier receives sch a Host Membership Report, it adds the grop being reported to its membership list for the LAN. B. OSPF OSPF is a link state nicast roting protocol that dynamically detects topology changes and calclates new loop-free rotes after a period of convergence. Each roter in the network maintains a replicated database. Roters execte Dijkstra s algorithm on their database to calclate a shortest-path rote to a given destination sbnet. Roters flood database information periodically or when network element failres occr. OSPF is rn within an atonomos system (AS) maintained by a single administration. An AS can be frther divided into OSPF areas. Within each area, roters maintain identical topology databases. Each area reqires Area Border Roters (ABR) at their periphery. An ABR is connected to mltiple areas and has a copy of the topological database for each area. The ABR is responsible for the propagation of inter-area roting information into the areas to which they are connected. Finally, totally stbby areas are sed to redce the storage reqirements of roters within those areas for a system in which a lot of inter-as rotes are defined. Topological information is not permitted to be flooded to totally stbby area roters. OSPF tilizes several timers that affect its rate of convergence in the event of network element failres. OSPF neighbors send Hello messages to each other in every HelloInterval (defalt 10s) and will time ot the neighbor if no Hello message is received within the RoterDeadInterval. The recommended ratio of the Roter- DeadInterval to HelloInterval is three to one. Both the intervals mst be the same for neighboring roters. In the Cisco roter OSPF implementation, two timers are sed to control how soon Dijkstra s algorithm is exected to pdate the roting database. The Shortest Path First(SPF) Delay timer is the timer between when OSPF receives a topology change and when it starts a shortest path calclation, after reception of an Link State Advertisement (LSA). The SPF Holding time is the interval between two consective SPF calclations, representing the minimm interval in which back-toback Dijkstra calclations can occr. C. PIM PIM operates in either Sparse Mode (SM) or Dense Mode (DM). PIM DM is a broadcast-and-prne protocol and is best sited for networks densely poplated by receivers and with plentifl bandwidth. Each roter copies incoming packets to all its interfaces except the one on which the data arrived. When the mlticast channel reaches a leaf roter 1, the grop information maintained by the roter is examined and either the mlticast data is forwarded onto the LAN or the roter prnes back the channel. The prne state has an associated timer; the broadcast-and-prne process repeats pon its expiration. If a new member wants to join a grop, the directly connected roter will send a Graft towards the sorce. PIM SM is a mlticast roting protocol that dynamically bilds and maintains mlticast trees. PIM SM is optimized for environments where grop members are sparsely distribted across a wide area. Unlike PIM DM, which has a broadcast-and-prne phase, a 1 A network on a roter interface is deemed a leaf if there is no PIM neighbor on that network. Designated Roter (DR) 2 sends periodic Join/Prne messages towards the Rendezvos Point (RP) 3.AJoin/Prne message is also sent when a new mlticast entry is created. If the data rate of the tree reaches a predefined threshold, roters with local members individally migrate from the grop s shared tree to a shortest path tree (SPT) rooted at the sender s roter. When two or more roters are forwarders for a mlti-access network LAN, an Assert process is sed to elect the roter with best metric to the sorce (DM or SM SPT) or to the RP (SM) as forwarder. All other roters remove their oifs towards the LAN. Several PIM timers provide falt recovery tning capabilities. Each PIM roter periodically send Hello to each other every Hello- Period (defalt 30 s) and a neighbor is timed ot if Hello messages are not received from the neighbor within Hello-Holdtime (defalt 105 s). If a DR goes down, a new DR is elected. PIM (DM and SM) also has several timers that control the maintenance of state in the roters. A timer for each otgoing interface (oif) is sed to time ot that oif. In DM, it is reset whenever a data packet is forwarded or a Graft message is received. In SM it is reset when a Join/Prne message is received. Both of the timers will be reset to Prne- Holdtime. A timer for each rote entry is sed to time ot that entry and is reset to Data-Timeot (defalt 180 s) when receiving data packets (DM or SM SPT) and is reset to the maximm prne timer among all its otgoing interfaces once all interfaces in the oif list are prned. An Assert-timer is also sed for an entry to time ot received Asserts after Assert-Timeot (defalt 180 s). III. NETWORK FAILURE SCENARIOS When network element failre occrs in a network, IGMP, OSPF, and PIM asynchronosly interact to recover a mlticast channel. The analysis of PIM SM is restricted to shared trees (not shortest path trees) and ths does not address failre dring the migration period of shared tree to shortest path tree. PIM SM and DM recover from network element failres in a similar manner. However, for recovering the part of the mlticast channel pstream of a roter, a roter rnning PIM SM will send a Join message to its Reverse Path Forwarding (RPF) 4 roter, while a roter rnning PIM DM will send a Graft message. From herein, PIM is sed to refer to both the DM and SM cases, nless otherwise specified. In this section, the analytical models for the varios failover scenarios are shown. For convenience, parameters sed in the analysis are defined in table I. In general the total mlticast channel recovery time for a affected roter can be written as: T r = + H ospf p + T spf + T Dijkstra + T pim + Tp pim (1) The major portion of T r is contribted by T ospf, T spf,and T pim, all of which have a granlarity in seconds. In contrast, Tp ospf, Tp pim,andt Dijkstra are typically in milliseconds, and are ths not considered frther in the model. Single-falt network failres can be classified into for categories: link failre in the WAN, roter failre in the WAN, link 2 The DR is responsible for sending Join/Prne and Register messages toward the RP. When more than one roter is connected to a LAN, the highest IP addressed roter becomes the DR 3 An RP is a roter that acts as the root of the shared tree, and to where all joins and prnes are directed 4 For a shared tree, the RPF interface provides the best reverse metric to the RP. For a shortest path tree, the RPF interface provides the best reverse metric to the sorce 2

3 T r T cd fd hi rdi p H ospf T spf T Dijkstra T pim pli T pim T pim hhi T pim nfd T pim p T pim a T igmp qi T igmp qri Mlticast channel failre recovery time. The carrier delay time OSPF failre detection time. OSPF topology pdating time OSPF HelloInterval OSPF RoterDeadInterval Propagation delay of an OSPF control message on a point to point serial link Nmber of hops from the roter adjacent to the network failre SPF exection delay time after topology pdating Dijkstra exection time on the roter The interval for PIM to poll the nicast roting table The time for PIM to detect topology change PIM hello holding time for detecting neighbor failre PIM neighbor failre detection time Propagation delay for a PIM Join/Graft message to recover the mlticast channel PIM Assert-Time. IGMP Qery Interval IGMP Qery Response Interval TABLE I PARAMETERS USED IN THE ANALYSIS failre to the client site LAN, and roter failre on the client site LAN. A. Protocol Interaction in WAN The network recovery in WAN rests solely on the interactions between OSPF and PIM 5. In general, an OSPF implementation shold feed otage information received from the data-link and physical layers into its interface state machine (Section 9.3 of RFC 2328, event InterfaceDown) and from there into the neighbor state machine. Most roters are able to notice within a small nmber of seconds that their link is down, and then they shold commnicate this information via an pdated roter-lsa to the rest of the OSPF roters. The speed of the recovery depends on the vendor implementations and the carrier-delay parameters set p for detecting an otage. Depending on type of otage, circit, and the switch vendor, an NBMA network over ATM or FR may not give the otage indication. Even when the lower levels know that the neighbor has gone away, many networking stacks don t pass this information p to the roting protocols. In these cases, the Roter- DeadInterval of OSPF can be sed as a last resort to detect a link failre. As soon as each roter receives the new roter-lsa, it recalclates its shortest path throgh Dijkstra s algorithm. PIM can learn the topology change from OSPF directly throgh a notify message (if an implementation spports it) or indirectly by periodically polling the OSPF roting table (this fnction is implemented in the crrent Cisco roters). PIM needs to determine its RPF for each sorce in the sorce-grop pair (S, G) or RP. If a new RPF has been discovered, PIM sends a Join/Graft message on the new RPF interface to form a new mlticast channel. As specified in the PIM SM specification, the roter may also send a Prne message ot the old inpt interface (iif), if the link is operational, to remove this part of the tree. However, a race condition 5 IGMP version 1 and 2 do not play a role in WAN mlticast recovery. Comparatively, the IGMP version 3 proposal is carried beyond the leaf roter into the WAN and will likely play a role in channel recovery. Rote A Roter 2 Roter 1 RP Link 1 Rote B Roter 4 Roter3 Fig. 1. WAN failre scenario Rote C may exist in this case, depending on the delay of establishing the new branch of the mlticast tree. If the delay is big, removing the old iif may lead to packet loss, since the new mlticast channel has not been established. To avoid nnecessary packet losses dring the transition phase, the athors sggest keeping both the old iif and corresponding pstream oifs fnctional, by allowing for two iifs dring network topology change period, at the cost of slightly increase of the overhead de to the temporary dplicate packet transmissions, dring the transition period. To avoid extra overhead, a Prne can be sent ot the old iif as soon as new data packets have arrived from the new iif, instead of waiting for the time ot of the pstream oifs. In the following sections, representative WAN link and roter failre scenarios are detailed. A.1 Link Failre in the WAN Consider the link failre scenario shown in Fig. 1. Originally, a mlticast channel exists over Rote A. If Link 1 fails, Roter 1 and Roter 2 both immediately detect the failre since the link is directly attached to each roter (not attached over a NBMA network). Each roter will pdate the link-state database by re-originating its roter-lsa to annonce the topology change, sending it to Roter 3 and Roter 4. The new best metric rote from Roter 2 to the RP or sender is now via Roter 3. PIM on Roter 2 then sends a Join/Graft to its new RPF Roter 3 to recover the failre. The mlticast channel is rebilt to Rote B in Fig. 1. While the above processing is occrring in Roter 2 and 3, Roter 4 will have received LSAs from Roter 2 and 3 separately. Detecting its new RPF via Roter 3, PIM on Roter 4 triggers a Join/Graft to Roter 3. As sggested earlier, to avoid potential packet loss de to a race condition, Roter 4 may not send a Prne right away to Roter 2. The mlticast channel will migrate to Rote C eventally after interfaces associated with the sboptimal path Rote B time ot or are prned. In general, the mlticast channel recovery time in WAN is dependent on the carrier-delay time reqired to learn abot a link otage from a lower layer, or on the OSPF RoterDeadInterval if link failre can not be detected earlier at lower layers. Every OSPF Hello message resets the OSPF Inactivity Timer, with a link failre occrring (on average) at the mid-point of the hello interval. Hence the average OSPF failre detection time is: fd = min{ rdi 0.5 hi,t cd } (2) The worst-case time for OSPF to detect a failre is:,w fd = min{ rdi,t cd } (3) After detecting the topology change, OSPF starts a shortest path calclation after SPF Delay time. We can then represent the average OSPF topology database pdating time as: = fd + T spf (4) The worst case OSPF topology database pdating time is: 3

4 T ospf,w =,w + T fd spf (5) If PIM is notified of the nicast table change by OSPF, mlticast channel recovery can be initiated immediately after OSPF pdates the topology. If instead, PIM polls the nicast table to learn of changes, an additional delay of 0.5 T pim pli is incrred on average. In general, we represent the average time for PIM to detect the topology change as T pim, and corresponding worst-case time as T pim,w. The mlticast channel recovery time can now be written as: T r = + T pim (6) The worst-case mlticast channel recovery time can be represented as: T w r =,w + T pim,w (7) A.2 Roter Failre in the WAN Roter failre in the WAN is similar to mltiple simltaneos link failres. Assme a mlticast channel is instantiated via Rote A, as shown in Fig. 1. If Roter 2 fails, Roter 4 immediately detects its interface to Roter 2 is torn down. Roter 4 pdates its OSPF database, exectes the Dijkstra s algorithm to pdate its network topology, and floods an OSPF LSA. When PIM on Roter 4 finds that its best reverse path metric to the RP or sender is now via Roter 3, it sends a Join to Roter 3 to recover the mlticast channel via Rote C. Roter 1 takes no proactive action dring the recovery. The channel recovery is triggered by those roters frther downstream from the failed roter. B. Protocol Interaction on a LAN Mlticast channel recovery in LAN is more complicated than that in WAN. In addition to the interaction of OSPF and PIM protocols as presented in Section III-A, IGMP plays a role in LAN mlticast channel recovery. The OSPF failre detection time on LAN may depend more critically on the RoterDeadInterval. When roters are on an Ethernet, for example, the fact that roter X s cable has fallen ot will not lead the other roters on the Ethernet to destroy their adjacencies with Roter X ntil OSPF RoterDeadInterval has expired. However, as long as they can receive Roter X s new roter-lsa (that is, as long as the Ethernet is not a single point of failre), the other roters on the Ethernet will pdate their roting tables well before the adjacency is destroyed. On the LAN, PIM roters can act in two important roles: Designated Roter (DR) and last-hop roter. A DR in PIM SM is responsible for initially drawing-down the mlticast channel to the LAN (Section II-C). The last-hop roter is the last roter to receive mlticast data packets before they are delivered to directly-connected member hosts. The DR is normally the last hop roter. However, a roter on the LAN that is not the DR bt has a lower metric rote to the data sorce or to the grop s RP may take over the role of the last-hop roter. When the DR receives an IGMP Membership Report, it adds the receiving interface to its oif list. It may also send Join messages to its RPF roter (if the existing entry had no active oifs). If the DR is not the last-hop roter, this may trigger a new Assert process. In or case, PIM DM does not need a DR, althogh it was reqired on a LAN rnning IGMP v1. Its mlticast channel formation and failre recovery are therefore a little different from PIM SM. a) last-hop Rote A Roter 1 Roter 2 Host DR Rote B b) last-hop Rote A Roter 1 Roter 2 DR Rote B Roter 3 Host Roter 4 Fig. 2. LAN failre scenario, DR and last-hop roter are different roters B.1 LAN Failre Recovery - PIM-SM 1. Scenario 1: last-hop roter and DR are separate roters (Fig. 2). Since the DR is not the last hop roter, it does not have an oif towards the LAN. In this case, when the link immediately pstream or downstream of the DR fails, the mlticast channel for LAN stays alive in either case since the failre point is not on the mlticast path. For completeness, we present the transient behavior in either case. (a) The DR s pstream link fails. The DR will detect the otage right away if the failed link is a serial link, or at most wait for RoterDeadInterval if the lower layer cannot convey the otage information to OSPF. When DR has active oifs in addition to the one towards the LAN, it may send Join to the new RPF immediately after the failre is detected. However a mlticast branch that goes throgh the DR towards the LAN can be recovered only when the IGMP Membership Report reactivates the prned oif after the nicast channel recovery. The average time for the DR to recover its mlticast branch is: T r = + T pim +0.5 (T igmp qi qri ) (8) The worst mlticast channel recovery time is: T w r =,w + T pim,w qi qri (9) (b) The link between the DR and the LAN fails. On average, the time to detect a neighboring roter failre (DR failre) is abot T pim nfd = T pim hhi 0.5 T pim hi. After the failre detection, the roter on the LAN with the next highest Ethernet interface IP address becomes the DR. Sbseqently, the DR mst acqire the IGMP grop membership information, and this contribtes a term (as in the previos case) of 0.5 (T igmp qi qri ). The average recovery time is therefore given by: T r = T pim igmp nfd +0.5 (Tqi qri ) (10) The worst case recovery time is: Tr w = T pim hhi qi qri (11) (c) The pstream link of last-hop roter fails. If there is an alternative link, the last-hop roter will Join to the new RPF pon detecting the change in the nicast table. In this case, the average and worst case recovery time will be the same as in eqation 6 and 7 If, as a reslt, the affected roter no longer remains the last hop roter, the Assert process will lead to a new last-hop roter being elected and a new optimal mlticast channel established. If there is no alternative link from last-hop roter towards the RP or sender, the mlticast channel is recovered throgh the DR by sendinga Join message when a new IGMP Host Membership Report is received from a host on the LAN. The recovery time in this case is as given by: 4

5 a) DR last-hop Rote A Roter 1 Roter 2 Host Rote B b) DR last-hop Rote A Roter 1 Roter 2 Rote B Roter 3 Host Roter 4 Fig. 3. LAN failre scenario, DR and last-hop roter are the same roter T r =0.5 (T igmp qi The worst case recovery time is: T w r = T igmp qi qri ) (12) qri (13) (d) The link between the last-hop roter and the LAN fails. The DR may be informed of the topology change throgh a roter-lsa qickly. However, if no roters exist downstream of the crrent last-hop roter, the DR will not reactivate the mlticast channel ntil it receives the new IGMP Membership Report. The average recovery time will be the same as eqation 12 and 13. If the DR regards the affected last-hop roter as RPF roter, it needs to detect the failre and graft to the new RPF. The average and worst case recovery time for the mlticast channel are therefore as in eqation 8 and 9. If there are roters downstream of the affected last-hop roter (Fig. 2 b), they will detect the topology change throgh OSPF roter-lsas. The roters previosly considering the affected last-hop roter as the RPF roter will send Join to the new RPF once a new RPF is detected. The mlticast channel recovery time in this case depends critically on the topology change detection time and on average is as eqation 6. The downstream roters with a different RPF neighbor (according to the original nicast table) from the last-hop roter may need to wait for the Assert-Timer to expire before they can send Join to the new RPF roter. So the mlticast channel recovery time will depend on both the Assert-timer vale and the IGMP Qery Interval in this case, whichever comes first. The average recovery time is: T r =0.5 min{t igmp qi The worst case recovery time is: T w r igmp = min{tqi qri,ta pim } (14) qri,ta pim } (15) 2. Scenario 2: last-hop roter and DR are the same roter. The LAN consists of two roters, with one roter acting as both the last-hop roter and the DR (Fig 3). (a) The link pstream of the DR fails. Regardless of roters downstream of the DR, the DR will recover the mlticast channel immediately after it determines the new RPF roter, since it has active mlticast entries. The average recovery time is as in eqation 6. (b) The link between the DR and the LAN fails. If there are no roters downstream of the DR, the mlticast channel will not recover ntil a new DR is elected and a host membership report is received by the new DR. The mlticast channel recovery time is the same as eqation 10 and 11. If downstream roters exist, the mlticast channel can be recovered and switched to the new RPF roter of the downstream roters in the same time as eqation 6, on average. B.2 LAN Failre Recovery - PIM DM Since PIM DM does not have a DR, some failre scenarios for PIM SM do not apply. For the mlticast channel to recover, the LAN mst have more than one roter towards the sorce (Fig. 2), and the Assert process is sed to select the forwarder (or last-hop roter) for the LAN (Roter 1). We refer to the roter that loses the Assert as Roter-Other (Roter 2). 1. Roter-Other s pstream link fails. If Roter-Other has an active entry (on-tree oifs other than the one towards LAN), it sends a Graft to its new RPF pon failre detection. Otherwise, Roter-Other will pll down the mlticast channel towards LAN again if it receives a new IGMP report. The average recovery time is T r = max{ + T pim, 0.5 (T igmp qi qri )}. (16) Note that the recovery time is different from eqation 8, since in PIM DM, the RPF neighbor will acknowledge the Graft by sending GraftAck. If failre is detected after arrival of a new IGMP report, the Graft message will be lost and the sender will periodically (defalt 3 s) retransmit the Graft message, ntil a new RPF is fond. On the other hand, if a IGMP report arrives first, the reslting active entry allows the mlticast channel to be recovered immediately after the new RPF is detected. In addition, PIM DM can recover from data packet flooding when the Roter-Other s prned interface towards LAN times ot before a new IGMP report is received. When no mlticast entry exists in Roter-Other, a new entry will be created when a data packet arrives and the channel throgh Roter-Other can recover qickly. 2. The pstream link of last-hop roter fails. The mlticast channel will either recover qickly as in eqation 6 and 7 if there is an alternative link towards the sorce, or recover throgh Roter-Other in a time given by eqation 12 and The downstream link of last-hop roter fails. The recovery scenario is similar to the corresponding case in PIM SM. In addition to the failre scenarios presented above, a failre of the IGMP Qerier will increase the next IGMP grop membership report interval. As long as this does not happen in coincidence with the failre of other components that are more critical to a mlticast channel, it is not a concern. Roter failres in the LAN is similar to the downstream link failre cases. From the presentation above, we can see that depending on the failre scenario, the mlticast channel recovery for a LAN may critically depend on several parameters, the most important of which are OSPF RoterDeadInterval,PIM Hello-Holdtime, Assert-Time as well as IGMP Qery Interval. C. Totally Stbby Area Considerations In additional to protocol behavior, the network configration can also inflence the failre recovery. For example, if OSPF totally stbby areas are configred in the network, the final migrated mlticast channel may not necessarily have the best metrics to the sorce or RP. Frthermore, the mlticast channel might not be recovered at all in some totally stbby area configrations. Consider the hypothetical network in Fig. 4. Originally, the mlticast channel traverses Rote A: Roter 1 Roter 2 Roter 4 Roter 6. If WAN Link 1 fails, for example, Roter 2 sends 5

6 Link 1 Roter1 OSPF Area 0 Roter 2 Link 2 Rote B Roter 3 Link 3 Rote A Roter 4 Link4 Roter 5 Roter 6 Rote C OSPF Area 1 Total Stbby Fig. 4. OSPF Stbby area failre recovery a Join/Graft to Roter 3 to rebild the mlticast channel via Rote B. The mlticast channel will not migrate to Rote C even thogh Rote C may have better metrics than Rote B. Since OSPF Area 1 is configred as totally stbby, OSPF LSAs are not flooded into Area 1 by either OSPF Area Border Roters (ABR) Roter 4 or Roter 5. Now consider the case Link 3 and Link 4 do not exist. If Link 2 fails, Roter 4 learns of the failre bt it cannot recover the mlticast channel since it only has Roter 6 as its neighbor in Area 1. Roter 6 has a potential rote to the RP or sender via Rote C bt has no reachability knowledge concerning other OSPF areas via Roter 5. Ths, Roter 6 does not migrate the channel to its other pstream link. The network failre, in this scenario, cases the mlticast channel to Roter 6 to be nrecoverable sing PIM SM. In PIM DM, the next rebroadcast period will case the channel to be re-established via Rote C. If the network is redesigned to add Link 3 or Link 4, Roter 4 cold then bild the mlticast channel via Roter 3 or Roter 5. When sing OSPF totally stbby areas, the OSPF area border roters shold always have an alternative pstream link within the OSPF Area to the RP or sender, to provide for mlticast channel recovery. If Roter 4 were to fail, instead of a backbone link, as described above, then Roter 6 wold send a Join/Graft on its other pstream link to Roter 5 (new RPF) to recover the channel. The recovery occrs becase Roter 4 is co-located with Roter 6 in the same OSPF area. IV. SIMULATION AND RESULTS ANALYSIS Simlation models for an IP mlticast system have been developed for the investigation of end-to-end mlticast failre recovery behavior and performance by sing OPNET [14]. The models inclde IGMP, PIM DM, modifications to the IP forwarding engine, a random topology generator ported from the TIERS topology generator [10], a mlticast sender and receiver application model, a link falt injector, as well as several probes to acqire simlation statistics. More detailed descriptions of the design and implementation of these models can be fond in [14]. In addition to the stdy of end-to-end mlticast failre recovery time, we also calclate the traffic control loads generated by the different protocols nder normal network conditions and in network failre recovery scenarios. A. Simlation Parameters and Design Decisions We simlated each combination of network topology, and protocol parameters. The parameters that were varied in or simlation are as follows: 1. Network topology. In order to be able to generalize the reslts, mltiple random topologies were created and sed in or experiments. In the majority of the simlations (nless otherwise specified), three random topologies, each consist- Fig. 5. OSPF load change with the variation of Hello interval ing of 36 nodes, were sed. In each topology, the defalt redndancy factor was 4, and the percentage of receivers was set to 80% for the (single) grop. For any particlar topology, depending on the experiment, we varied the nmber of roters in the network, the redndancy factor (2, 3, 4), and the percentage of receivers relative to the total nmber of nodes in a network. 2. OSPF parameters. In order to stdy the failre recovery time, the OSPF Hello and Dead timers are tned. The RoterDead- Interval is set to three times the HelloInterval in all the simlations. In addition, the SPF calclation time was redced from its defalt vale of 10 seconds to 1 second. 3. PIM parameters. In the PIM implementations of some of the roter vendors, sch as Cisco, the nicast roting table is polled periodically to allow PIM to detect the network topology changes. To minimize the inflence of the polling interval on the simlation failre recovery and focs on the protocol interactions themselves, the polling interval was set to a small vale (0.2 s). 4. Application layer parameters. To stdy the end-to-end mlticast channel failre recovery behavior, the end to end recovery time is measred. The arrival traffic was generated sing a CBR model. Using this model, receivers detect when they have become disconnected from the mlticast channel if they fail to receive the next expected packet. The data rate is set to a low vale (two per second) to redce the simlation time de to the handling of large nmber of events, while keeping the mlticast channel alive. As a reslt, there is no packet loss de to bffer overflow in the simlation environment. B. The Control Load of OSPF and PIM From the analysis reslts in Section III, we have seen that the failre recovery time is closely related to the OSPF Hello interval. We first stdy the change in OSPF control load de to the variation of OSPF Hello interval. Sbseqently, we discss the effects of the network redndancy factor and the receiver poplation on the PIM DM control load. B.1 OSPF Control Load verss OSPF Hello Interval The OSPF HelloInterval wasvariedfrom5sto15sin1ssteps, and correspondingly the RoterDeadInterval was varied from 15 s to 45 s, in 3 s steps. The effect on the OSPF control load was stdied for 3 random 36-node network topologies with redndancy factor 4. Intitively, the OSPF control load will decrease as the OSPF hello interval increases. The reslts in Fig. 5 show that this is tre for a hello interval of less than 9 s, with the load varying almost inversely with the HelloInterval. When the hello interval is greater than 9 s, the overhead de to variations in the hello interval appear to be negligible. This is becase the average OSPF control load 6

7 a) b) Fig. 6. PIM DM load change with the variation of network redndancy factor a) and receiver percentage b) a) b) Fig. 7. a) Variation of mlticast channel recovery time with the OSPF Hello interval (PIM polling interval set to 0.2 s) b) Variation of mlticast channel recovery time with the PIM polling interval per link is no longer dominated by the overhead of hello messages when the hello interval is large. Over the entire range, the load is not strongly affected by the network topology. Overall, the average OSPF control overhead in a link is very small (less than 250 bps in all cases). B.2 PIM DM Control Load verss Network Topology In the first simlation, the PIM control load was measred on three different 36-node networks, with redndancy factors 2, 3, a) b) and 4 respectively. Fig. 6 a) shows that the total PIM control Fig. 8. a) Variation of OSPF topology pdation time with the OSPF Hello interval. b) The time between topology pdation by OSPF and mlticast channel overhead is directly proportional to the network redndancy factor. This can be nderstood as follows. PIM DM control load is recovery sing PIM, as a fnction of the OSPF Hello interval dominatedby the periodicalhello and Prnemessages. The Hello load will not be inflenced by the network topology. The Prne will increase as the network redndancy factor increases, since the data packets are flooded across more links and trigger more PIM Prnes. In the second simlation, the PIM control load was measred on a single 36-node network, while varying the nmber of receivers Falts were injected singly at randomly selected links, and also at randomly (niformly) distribted times. As mentioned in the Section IV-A, packet loss in the simlated network only happens if there is a network failre. Accordingly, a failre is detected for a grop if a receiver in the grop detects a missed packet. The recovery on this network. Fig. 6 b) shows that when the percentage of time for an individal receiver is defined as the time interval the receivers (relative to the nmber of nodes) increases, the PIM DM control load actally decreases. This is becase as the receiver poplation increases, the nmber of links branches on the mlticast tree increases, and fewer Prnes will be sent ot. This indicates that PIM DM efficiency increases in a network densely poplated with receivers, which is the primary design goal of PIM DM. C. Single Mlticast Channel Recovery Time As discssed in Section III-A, the recovery time from a link or roter failre in a WAN is strongly dependent on the speed with which lower layers of the protocol stack in neighboring roters learn of the otage and how qickly they inform the OSPF protocol. Accordingly, the vendor implementation dependent carrier delay parameters have a strong inflence. In case the OSPF roters are not able to learn of the otage throgh the lower layers, the expiry of the OSPF Inactivity Timer is sed as a last resort. However, in or simlations, since the OSPF implementation in OPNET does not send the link layer failre information to the network layer, failre can be detected only when the OSPF Inactivity Timer expires. Hence, we only stdy the inflence of the RoterDeadInterval interval (or eqivalently, the proportional Hello Timer interval) on the failre recovery time. In fact, as will be seen later in Section V, the experiments sing the Cisco testbed show that a data link layer otage can provide mch qicker failre recovery time in the WAN, depending on the setting of the carrier detection parameter vale. As before, failres were simlated on a randomly generated 36 node network of redndancy factor 4, identified in the graphs. between the packets received immediately before and immediately after the missing packet(s). Each data point in Fig. 7 and 8 is the failre recovery time averaged over all receivers for a particlar falt, and also averaged over approximately 100 single falts at random links. Fig. 7 a) shows that the failre recovery time increases with the OSPF Hello interval and does not depend on the network topology. The comparison between Fig. 7 a) and Fig. 8 a) shows that the failre recovery time is dominated by the OSPF recovery time. This is approximately 2.5 times the OSPF Hello interval as predicted by the analysis (eqation 2). Since triggered Graft/Join is sed to recover a mlticast channel, PIM does not have a major contribtion to the failre recovery time. After a nicast roting table is pdated by OSPF, PIM takes at most a polling interval (which is set to 0.2 second for the experiments of Fig. 7 a) and 8 a)) to find ot the topology change, and triggers the Join/Graft to a new RPF roter, ths migrating to the new mlticast channel. However, the recovery time after topology pdation, shown in Fig. 8 b), is larger than the expected PIM recovery time. This is becase it takes abot extra SPF Delay (= 1 s) for OSPF to start a new topology calclation after the topology pdation. The end-to-end packet loss detection method (with data packets interval 2 s) also contribtes to the apparent PIM recovery time, and also makes it somewhat random. As expected, the component of the recovery time after topology pdation does not change with OSPF Hello interval. The failre recovery time does not change very mch with the network topology either, since the propagation delay of the control messages is 7

8 Ethernet 1 Sender Host Roter 3 Link 2 Link 1 Roter 1 Link 4 Link 3 Roter 2 Link 5 Roter 5 Roter 4 a) b) Ethernet 2 Receiver Host Fig. 9. OSPF load change (a) and PIM DM load change (b) dring failre recovery, beginning at t=500 seconds Fig. 10. Testbed topology negligible (of the order of micro-seconds) as compared to the delay de to the protocol (tens of seconds). Therefore, to redce the mlticast channel recovery time, the OSPF hello interval and SPF calclation interval shold be set as small as possible. The average overhead de to polling of nicast table is approximately half of the polling interval. Fig. 7 b) shows the variation of the PIM recovery time with the polling interval, with the OSPF Hello interval set at 7 seconds. As expected, there is a linearly increase in this component of the recovery time with the polling interval. To allow a fast recovery, the polling interval shold be set as small as possible. The recovery time is nearly the same for all the network topologies shown. D. Network Load Change dring Failre Recovery Dring failre recovery, the nmber of control messages increases - this incldes PIM join, prne messages and OSPF link state pdate messages. In this section, we compare the average link control load dring failre recovery with the control load dring steady state. Network topologies were generated as in the previos section. The OSPF Hello Interval was set to a defalt vale of 10 seconds, and the PIM nicast roting table polling interval is set to 0.2 second. At simlation time 500 seconds, a falt was injected. Figre 9 a) shows that at the beginning of the simlation, the OSPF control load is higher than the load in steady state. This is de to the flooding of LSAs by all nodes in the network. As OSPF reaches steady state, the control load becomes smaller bt increases periodically every 10 seconds and 30 mintes. The small load shown in the lighter area every 10 s is de the periodical OSPF Hello load. LSAs are flooded periodically every 30 mintes. At time 500 s, when the falt is injected, the load increases de to the flooding of pdated LSA as a reslt of a topology change. However, the increase in the control load is minimal, compared to the increase de to the half-horly flooding of LSA s. Similar to the OSPF case, Figre 9 b) over the same time period shows that the PIM DM control load is higher dring the establishment of the PIM neighbor relationships between PIM enabled roters. The load shown consists mainly of PIM Hello, Graft and Prne messages. In steady state, PIM hello messages are sent periodically every 30 seconds and prne messages every 180 seconds. Dring the failre event at 500 seconds, the PIM control load, nlike that of OSPF, does not increase, bt remains flat. This is becase the PIM channel recovery is highly localized and the extent of localization depends on the network topology and redndancy factor. If short, alternative paths exist, the mlticast channel can be recovered with minimal additional PIM control loading. V. EXPERIMENTAL RESULTS Experiments are exected to verify the behavior of the component protocols nder the LAN and WAN failre scenarios described in Section III. Measrements of the mlticast channel recovery times are provided, given a set of tightly tned parameters. A. Testbed Set-p A testbed was constrcted as shown in Fig. 10. Roters 1, 2, and 3 were CISCO 4700 roters and roters 4 and 5 were CISCO 2503 roters. The roters implemented OSPF as the nicast roting protocol, and PIM DM and SM and IGMP protocols. The hosts ran Microsoft Windows NT 4.0. The link speeds were T1 on Link 1, 2, and 3, and 64 Kb/s on Links 4 and 5. B. Test Procedre Since the stdy was focsed on the interaction amongst the component protocols dring fail recovery, only a single sender and single receiver were reqired for the testing. In all the test cases, a mlticast tree was first established from sender to receiver. To simlate a link failre, a selected link on the mlticast tree was manally open-circited. To simlate a roter failre, the selected roter was manally powered off. The sender application generated mlticast data at the rate of 1 KB/s. The receiver logged the received mlticast packets into a file, allowing the detection of missing packets and packets received ot of seqence. The overall failre recovery process was monitored sing several mechanisms. Roter debg messages were monitored and logged via telnet sessions into the respective roters. The roter debg messages contained a time stamp, which was synchronized among all the roters in the network sing the Network Time Protocol [12]. The debg messages provided casal ordering of roting protocol operations. For W&G LAN and WAN network analyzers [13] were sed to analyze data traffic and IGMP, OSPF, and PIM control messages on the mlticast channels. The analyzers operate with a synchronos clock, and ths packet delays cold be measred accrately within 10 5 seconds. C. Parametric Tning In the Cisco roter implementation, several protocol parameters can be tned for the prpose of failre recovery. The IGMP parameters that may be tned inclde the Qery Interval, theqery Response Interval and the Other Qerier Present Interval. By redcing these parameter intervals, new grop information may be discovered more rapidly by the roter, and qerier failre can be detected faster. They are set to defalt vale 125 s, 10 s, and 255 s respectively. In most implementations, inclding the one by Cisco, the other non-qerier roters on a LAN shadow the IGMP database maintained at the roter acting as the qerier. When the 8

9 qerier fails, a new qerier roter is elected and the transition occrs rapidly since IGMP information is already on-hand. The OSPF HelloInterval and RoterDeadInterval were set to one and three seconds, respectively, and the carrier delay time was set to two seconds. The SPF delay time and holding time were set to zero and ten seconds, respectively. This meant that the network failre cold be detected within three seconds in the worst case, and the SPF calclation wold be immediately processed after the detection. The PIM Hello message interval was tned to two seconds, so that roters on a LAN wold detect the DR failre on average in approximately five seconds (2.5 times PIM hello interval), as in eqation 6. PIM SM sends periodic Join/Prne messages to its pstream roters to keep the mlticast channel alive (soft state). The defalt period is 60 seconds. As explained in section III, the PIM polling interval determines how often PIM polls the nicast roting table, and therefore dictates how qickly it initiates recovery of the mlticast channel pon detecting a change. In the implementation of PIM sed on the testbed, the PIM polling interval was not tnable and was fixed at five seconds. D. Reslts Tables II and III smmarize the experimental reslts. The total recovery time consists of three components. The OSPF recovery time was measred as the time from when the network element failre occrred to when the affected roter received the corresponding LSA. The PIM recovery time was measred as the time from when the affected roter received the corresponding LSA till the time a PIM Join/Graft message was sent. The Join Latency was the time taken by the affected roter to process a received Join/Graft message and forward it to an pstream roter, pls the transmission time of the Join/Graft message itself. The first set of tests was condcted with OSPF configred as a totally stbby area at the client site. The OSPF areas are configred in Figre 10 sch that: Link 1, 2, and 3 are in Area 0, and Link 4, 5 and Ethernet 2 are in totally stbby Area 1. The individal protocol component recover times nder the varios mlticast channel failre scenarios are shown in Table II. The initial rote of the mlticast channel, prior to the failre, the corresponding failre event, and sbseqent component recovery times are listed from the perspective of the identified roter. Table III shows the measred reslts where Links 4, 5 and Ethernet 2 are in non-stbby Area 1. In the first failre event (Link 1 failre) nder this configration, the mlticast channel recovery occrs in two steps. In Step 1, Roter 2 recovers from the Link 1 failre by constrcting the mlticast tree throgh Roter 1 to Roter 3. When Roter 4 determines that the better metric to the RP or sorce is throgh Roter 5 (Roter 3 Roter 1 Roter 5), the Step 2 migration takes place at Roter 4. In both the OSPF totally stbby area and non-stbby area cases, the average and worst case fail-over time, as given by eqations 6 and 7 for failre of link 1, link 5, Roter 2 respectively, is measred to be approximately 5 and 8 seconds, respectively, pls a few hndred additional milliseconds. It is noted that when Roter 4 (acting as both the DR and last-hop roter) fails, the mlticast channel can be recovered in abot five seconds after the DR failre is detected. This is mch shorter than the 65 seconds predicted by eqation 10, which is based on the protocol that the DR needs to wait either for the IGMP report to reactivate its oif towards LAN or for the periodic flooding of data packets in PIM DM (whichever happens first) before it can reactivate its oif towards the LAN. The rapid recovery of the mlticast channel occrs in the Cisco implementation becase all roters on the LAN cache the mlticast grop membership information, and the mlticast channel is recovered as soon as the new DR is elected. However, when the last hop roter and DR are not co-located and the last hop roter (Roter 5) fails, the DR does need to wait either for the IGMP report (SM) or for the periodic flooding of data (DM), as will be observed from the following experiments. In the case of the Roter 5 failre, the reslts are related to the PIM protocol specifications and the specifics of the vendor s PIM protocol implementation. For PIM SM, recovery reqires approximately 60 seconds. The DR did not prne its interface towards the LAN in Cisco s implementation and the mlticast channel recovered when the periodical Join was sent pstream by the DR (every 60 seconds). Rather than waiting for the next periodic Join interval, the roter implementation cold be changed to immediately send a Join pstream, once the DR detects failre of the last-hop roter. PIM DM reqires 1.5 and 3 mintes in the average and worst cases. PIM DM recovers when the data is rebroadcast at every 3 mintes interval as expected in Section III-B.2. Similar to the PIM SM case, some improvement in the protocol specifications can lead to mch faster failre recovery process as explored in Section VI. VI. DISCUSSION In this section, we present some general insights and design gidelines on the basis of or analysis, simlations, and experiments, and nderstanding of the protocol behavior in the varios failre scenarios. A. General observations 1. In general, mlticast channel recovery time is dominated by the time reqired to re-constrct the nicast roting table. Althogh the test-bed reslts show a sbstantial recovery time attribted to PIM, in most cases this was de to large polling interval with which PIM looked p the nicast roting table. Trigger based active joining of mlticast trees (as sed in PIM) allows the mlticast channel to be recovered qickly thereafter. 2. The simlation reslts for control overhead and recovery time yielded similar reslts for all randomly generated topologies with the same nmber of nodes and the same redndancy. This indicates that or reslts are generally representative for networks of a given size and complexity. 3. Protocol control loads: The PIM DM control load increases proportionally with the redndancy factor and decreases inversely with the percentage of receivers. The OSPF load increases proportionally as OSPF Hello interval decreases and is acceptable in the simlated parameters range (10 s - 5 s). In general, the defalt assignment of protocol timers appears to be conservative, and the tightening of these parameters for speeding p the failre recovery does not lead to excessive overhead. If possible, the nicast roting parameters shold be tned to allow rapid detection of topology changes and prompt pdating of the roting table. Neither PIM nor OSPF has high control traffic dring failre recovery, and the combined overhead for each link is always less than 1 kbps in all simlation cases. B. Effect of Network Configration on Falt Recovery Network configration can potentially inflence the failre recovery. 9