draft-ietf-pim-refresh-02.txt

BCAST Implementation for NS2

Network Working Group                                     Dino Farinacci
Internet Draft                                          Procket Networks
Expiration 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 interface



Farinacci, 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 2000


4. 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