Network Working Group                                     Dino FarinacciInternet Draft                                          Procket NetworksExpiration Date: May, 2001                               Isidor Kouvelas                                                           cisco Systems                                                           Kurt Windisch                                                           cisco Systems                                                       November 22, 2000                        State Refresh in PIM-DM                    <draft-ietf-pim-refresh-02.txt>Status of this Memo   This document is an Internet-Draft and is in full conformance with   all provisions of Section 10 of RFC2026.   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF), its areas, and its working groups. Note that other   groups may also distribute working documents as Internet-Drafts.   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time. It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as "work in progress."   The list of current Internet-Drafts can be accessed at   http://www.ietf.org/ietf/1id-abstracts.txt   The list of Internet-Draft Shadow Directories can be accessed at   http://www.ietf.org/shadow.html.1. Introduction   This proposal extends the PIM-DM [1] protocol specification by intro-   ducing the PIM State-Refresh control message.   When an (S,G) entry is created in a router for a directly connected   source, if the interface directly connected to the source is the   incoming interface for the entry, a new timer is started: the State-   Refresh-Timer [SRT(S,G)]. The State-Refresh-Timer controls periodic   transmission of the PIM State-Refresh message, which is propagated   hop-by-hop down the (S,G) RPF tree. When received by a router on the   RPF interface, the State-Refresh message causes existing prune state   to be refreshed.Farinacci, Kouvelas, Windisch                                   [Page 1]Internet Draft            PIM-DM State Refresh             November 2000   Addition of this heartbeat message solves many of the current prob-   lems with PIM-DM. It prevents the periodic timeout of prune state in   routers, greatly reducing the re-flooding of multicast traffic down   the pruned branches that expire periodically. It also causes topology   changes to be realised quicker than the traditional 3 minute timeout.2. Sending State-Refresh   For a given (S,G) tree, State-Refresh messages will be originated by   all routers that use an interface directly connected to the source as   the RPF interface for the source. Upon expiry of their (S,G) State-   Refresh-Timer the PIM State-Refresh message will be sent on all PIM-   DM interfaces with active PIM neighbors, except the interface con-   necting the source.   In addition, when the SRT(S,G) expires, the following timers are   refreshed:  SRT(S,G) is restarted with it's default value [Refresh-   Interval], and all (S,G) pruned interface timers are refreshed.   The first-hop router will no longer originate state refresh messages   when the (S,G) entry times out. The (S,G) entry timer for the first-   hop router is updated only by the receipt of data and not upon expiry   of the SRT(S,G) timer.   All other routers will forward state refresh messages only when   receiving one from a neighbor, as described below.   State-Refresh messages are multicast using address 224.0.0.13 (ALL-   PIM ROUTERS group) with protocol number equal to PIMv2 and a TTL of   1. The IP source address is set to the outgoing interface address and   is rewritten hop-by-hop when forwarding.   The State-Refresh message contains the source and group the message   is referring to, the originator address (for debugging purposes),   routing information required by the LAN assert mechanism, a TTL value   for scope control (different from header TTL), the state-refresh ori-   gination interval and a number of flags described below. The routing   information, TTL and flags can be rewritten hop-by-hop.   The TTL value in the message is initialised by the originating router   and can be either the result of local configuration, or the value of   the largest TTL observed in data packets from the source so far. The   TTL value will be decremented by downstream routers forwarding the   State-Refresh message.  Routers will only forward the State-Refresh   message if the value of the TTL in the message is greater than 0 and   larger than the configured local threshold.  This will prevent   State-Refresh messages from reaching areas of the network where data   packets have not already created (S,G) state.Farinacci, Kouvelas, Windisch                                   [Page 2]Internet Draft            PIM-DM State Refresh             November 2000   The flags in the message consist of the Prune-Indicator, Prune-Now   and Assert-Override flags.  The Prune-Indicator flag is cleared when   the message is transmitted on an outgoing interface in forwarding   state and set when the message is transmitted on a pruned interface.   This mechanism is required to recover from situations where loss of   consecutive refresh messages has caused an inconsistency in prune   state on a branch of the (S,G) tree.  The Prune-Now flag is required   to provide a mechanism for rate-limiting control traffic on multi-   access LANs. The Assert-Override flag is used to recover from assert   winner failures.3. Receiving State-Refresh   PIM State-Refresh messages are RPF flooded down the (S,G) tree using   the data source address included in the message to determine the RPF   neighbor. When a PIM State-Refresh message is received for a given   (S,G), the following steps are taken:   o Whenever a (S,G) State-Refresh message is received on the interface     for RPF(S) by a router with no existing (S,G) entry, an (S,G) entry     should be created. If the Prune-Indicator flag in the message indi-     cates a forwarding branch, then all non-iif interfaces with PIM     neighbors are set to forwarding state in the new entry. Otherwise,     the new entry is created with prune state on all non-iif inter-     faces.   o If the (S,G) State-Refresh message was received on an interface     other than RPF(S) by a router with no existing (S,G) entry, then     the message is ignored.   o If the State-Refresh message was received on a (S,G) non-iif inter-     face then the message is ignored. If the receiving interface     corresponds to a LAN the message may still be processed according     to the modified PIM Assert rules described in section 4.   o If the State-Refresh was received on the (S,G) incoming interface     from a PIM router other than the upstream neighbor (i.e, RPF neigh-     bor or Assert winner), then the State-Refresh message is ignored.     However, the message is still processed according to the modified     PIM Assert rules described in section 4.   o If the State-Refresh was received on the (S,G) incoming interface     from the upstream neighbor (i.e, RPF neighbor or Assert winner),     then all (S,G) pruned interface timers are refreshed.  Further, if     (S,G) is a negative cache entry, then the entry timer is also     refreshed to its default value.   o If the State-Refresh was received on the (S,G) incoming interfaceFarinacci, Kouvelas, Windisch                                   [Page 3]Internet Draft            PIM-DM State Refresh             November 2000     from the upstream neighbor (i.e, RPF neighbor or Assert winner) and     the Prune-Indicator flag in the message is set, indicating that it     was forwarded down a pruned branch, but the local (S,G) entry is     not a negative cache entry, then the Prune-Indicator flag in the     message is cleared and a Join is sent upstream.  To avoid duplicate     Join generation from different downstream routers responding to a     State-Refresh message, sending the Join is delayed by a random     interval smaller than 3 seconds and a scheduled Join is canceled if     one is received from another router on the LAN.   o If the State-Refresh was received on the (S,G) incoming interface     from the upstream neighbor (i.e, RPF neighbor or Assert winner) and     the Prune-Indicator flag in the message is not set, indicating that     it was forwarded down a forwarding branch, but the local (S,G)     entry is a negative cache entry, then the Prune-Indicator flag in     the message is set and a Prune is sent upstream.  To avoid dupli-     cate Prune generation from different downstream routers responding     to a State-Refresh message, sending the Prune is delayed by a ran-     dom interval smaller than 3 seconds and a scheduled Prune is can-     celed if one is received from another router on the LAN.     In a scenario where there are multiple downstream routers, some     with forwarding and some with negative cache entries, the routers     with the negative caches will generate a prune on each State-     Refresh message and the routers with the forwarding entries will     have to Join override. To reduce the amount of control traffic     created by such behavior, it is mandatory for a negative cache     router to respond with a Prune to a State-Refresh message with a     clear Prune-Indicator if the Prune-Now flag is set in the State-     Refresh message.  This flag will be set by the State-Refresh origi-     nator in one out of 3 messages transmitted. Downstream routers may     also respond with a Prune to State-Refresh messages with the     Prune-Now flag cleared.   o If the State-Refresh was received on the (S,G) incoming interface     from the upstream neighbor (i.e, RPF neighbor or Assert winner),     then the Refresh message is retransmitted on all PIM interfaces     other than the (S,G) incoming interface, provided that the TTL in     the message is greater than 0 and larger than the configured thres-     hold for the interface and that the interface does not have multi-     cast boundary addresses configured for the group specified in the     message. The IP header specifies the outgoing interface address as     the source and the Refresh Packet is rewritten with the local     router's preference, metric and mask for reaching S. If the (S,G)     entry has prune state for the interface on which the refresh mes-     sage is being sent, the Prune-Indicator flag in the message is set     to indicate a pruned branch. The TTL in the forwarded message is     one less than that of the received message.Farinacci, Kouvelas, Windisch                                   [Page 4]Internet Draft            PIM-DM State Refresh             November 20004. State-Refresh processing on LANs   On multi-access LANs, State-Refresh messages double as Asserts. Pos-   sible forwarders and downstream routers use the routing metric infor-   mation in the State-Refresh messages to decide who is the assert   winner. In most ways the processing of such messages is identical to   the assert processing rules described in [1].   The assert rules described in [1] rely on the periodic timeout of   prune state in routers to recover from situations where the assert   winner on a LAN goes away. When operating under State-Refresh this no   longer happens. In particular on a leaf LAN with multiple forwarders   there are no downstream routers to timeout and join towards the new   forwarder if the assert winner dies.  Possible remaining forwarders   that keep receiving State-Refresh messages will refresh their outgo-   ing interface prune timers and will not time out and start forward-   ing.   To recover from this scenario, the assert processing needs to be   slightly modified when operating under State-Refresh. Assert losers   need to remember the last time they have heard a State-Refresh from a   router on the LAN that has a better routing metric to the source. If   a period of three times the [Refresh-Interval] elapses with no such   report, then the Assert-Override flag will be set in the next for-   warded State-Refresh message.  If there are directly connected   members reported by IGMP, the interface to the LAN will transition   into forwarding state. The value of the Refresh-Interval used for   timing out the winner, is extracted from the forwarded message (see   section 5).   Downstream routers on a LAN that receive a State-Refresh message with   the Assert-Override flag set, will discard the stored routing metric   values for the assert winner and use the State-Refresh sender as   their new RPF neighbor.5. State-Refresh Message Packet Format   This section described the details of the packet format for the PIM   DM State-Refresh Message. As with all PIM control messages, the   State-Refresh message uses protocol number 103. It is multicast hop-   by-hop to the `ALL-PIM-ROUTERS' group `224.0.0.13'.Farinacci, Kouvelas, Windisch                                   [Page 5]Internet Draft            PIM-DM State Refresh             November 2000