Subject: draft-ietf-pim-dm-new-v2-04.txt

From: Andrew Adams <[email-masked]>
Date: Fri, 20 Jul 2001 12:45:12 -0400

Hello all.  At the Minneapolist IETF a several of us volunteered
to revive and revise the pim-dm draft.  Please find attached an ascii
version of the revised draft.  A postscript version containing
state machine diagrams and tables can be found at

http://www.nexthop.com/standards/drafts/draft-ietf-pim-dm-new-v2-04.ps

We're working to get it posted on the pim working group
web page as well.

Much of the work on this revision was to give the pim-dm specification 
the same look, feel and state-machine orientation as the 
pim-sm specification.

It was stated at the Minneapolis IETF that for pim-dm to be
the most useful, the specification should incorporate the 
state-refresh work. This draft doesn't yet incorporate that work.

One change from the most recent pim-dm draft 
(draft-ietf-pim-v2-dm-03.txt, June 7, 1999) is that packets 
from sources for which a route isn't known are silently discarded, 
rather than trigger an Assert.

There are several open issues.

1. Should all upstream routers process Prunes, Joins and Grafts?
   Pros:
     No need to track upstream Asserts or calculate RPF'(S).
     When topology changes, only need action when RPF_Interface(S)
changes.
   Cons:
     Extra processing and memory required.
     Not consistent with PIM-SM.
 
2. Should Assert processing depend on Prune status?
   Pros:
     Consistent with PIM-SM.
     Less processing required.
   Cons:
     Graft actions more complicated.
     More frequent Assert Negotiation.

3. There are places where one can argue that a state machine SHOULD
   transition rather than MUST transition.  Using SHOULD results
   some conditional state transitions, making the state machine
   more complicated.  Should conditional transitions be allowed?

4. Should (*,G) Prunes be allowed?
   It is possible that a router (probably on a stub) might
   decide it has no downstream members of group G and would want to send
a
   (*,G) Prune.  Should such behavior be allowed?

5. And regarding the PIM MIB...
   It would seem that perhaps objects are needed for the following.

      Hello Holdtime
      J/P Override Interval
      Graft Retry Period

Thanks,

-Andy (and Jon and Bill)

Internet Engineering Task Force	                                  PIM WG
INTERNET DRAFT	                      Andrew Adams (NextHop Technolgies)
draft-ietf-pim-dm-new-v2-04.txt	            Jonathan Nicholas (ITT A/CD)
	                           William Siadak (NextHop Technologies)
                                                           July 16, 2001

         Protocol Independent Multicast - Dense Mode (PIM-DM)
                   Protocol Specification (Revised)

Status of this Document

This document is an Internet Draft and is in full conformance with all 
provisions of Section 10 of RFC 2026.

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/lid-abstracts.txt.

The list of Internet Draft Shadow Directories can be accessed at 
http://www.ietf.org/shadow.html.

This document is a product of the IETF PIM WG.  Comments should be 
addressed to the authors, or the WG's mailing list at 
[email-masked].

                            Abstract

This document specifies Protocol Independent Multicast - Dense Mode 
(PIM-DM).  PIM-DM is a multicast routing protocol that uses the 
underlying unicast routing information base to flood multicast 
datagrams to all multicast routers.  Prune messages are used to prevent 
future messages from propagating to routers with no group membership 
information.

Adams, Nicholas, Siadak                                         [Page 1]

                           Table of Contents
1.     Introduction	                                               3
2.     Terminology	                                               3
3.     Definitions	                                               3
4.     Pseudocode Notation	                                       4
5.     PIM-DM Protocol Overview	                                       4
6.     Protocol Specification	                                       5
6.1.   PIM Protocol State	                                       5
6.1.1. General Purpose State	                                       5
6.1.2. (S,G) State	                                               5
6.1.3  State Summarization Macros                                      6
6.2.   Data Packet Forwarding Rules	                               7
6.3.   Hello Messages	                                               8
6.3.1. Sending Hello Messages	                                       8
6.3.2. Receiving Hello Messages	                                       8
6.3.3. Hello Message Hold Time	                                       8
6.4.   PIM-DM Prune, Join and Graft Messages	                       9
6.4.1. UpstreamPrune, Join and Graft Messages	                       9
6.4.2. Downstream Prune, Join and Graft Messages	              13
6.5.   PIM Assert Messages	                                      15
6.5.1. (S,G) Assert Message State Machine	                      15
6.5.2. Assert Metrics	                                              19
6.5.3. AssertCancel Messages	                                      20
6.5.4. Assert State Macros	                                      20
6.5.5. Rationale for Assert Rules	                              21
6.6.   PIM Packet Formats	                                      21
6.6.1. PIM Header	                                              21
6.6.2. Encoded Unicast Address	                                      22
6.6.3. Encoded Group Address	                                      22
6.6.4. Encoded Source Address	                                      23
6.6.5. Hello Message Format	                                      24
6.6.6. Join/Prune Message Format	                              25
6.6.7. Assert Message Format	                                      27
6.6.8. Graft Message Format	                                      27
6.6.9. Graft Ack Message Format	                                      27
6.7.   PIM-DM Timers	                                              28
6.7.1. Timer Values	                                              28
7.     Protocol Interaction Considerations	                      29
7.1.   PIM-SM Interactions	                                      29
7.2.   IGMP Interactions	                                      30
7.3.   Source Specific Multicast (SSM) Interactions	              30
8.     IANA Considerations	                                      30
8.1.   PIM Address Family	                                      30
8.2.   PIM Hello Options	                                      30
9.     Security Considerations	                                      30
10.    Authors' Addresses	                                      31
11.    Acknowledgments	                                              31
12.    References	                                              31

Adams, Nicholas, Siadak                                         [Page 2]

1. Introduction

This specification defines a multicast routing algorithm for multicast 
groups that are densely distributed across a network.  This protocol 
does not have a topology discovery mechanism often used by a unicast 
routing protocol.  It employs the same packet formats sparse mode PIM 
(PIM-SM) uses.  This protocol is called PIM - Dense Mode.  The 
foundation of this design was largely built on Deering's early work on 
IP multicast routing [1].

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be 
interpreted as described in RFC 2119 and indicate requirement levels 
for compliant PIM-DM implementations.

3. Definitions

Multicast Routing Information Base (MRIB)
    This is the multicast topology table, which is typically derived 
    from the unicast routing table, or routing protocols such as MBGP 
    that carry multicast-specific topology information.  PIM-DM uses 
    the MRIB to make decisions regarding RPF interfaces.

Tree Information Base (TIB)
    This is the collection of state maintained by a PIM router and 
    created by receiving PIM Join/Prune messages, PIM Assert 
    messages, and IGMP information from local hosts.  It essentially 
    stores the state of all multicast distribution trees at that 
    router.

Reverse Path Forwarding (RPF)
    RPF is a multicast forwarding mode where a data packet is 
    accepted for forwarding if it is received on an interface used to 
    reach the source in unicast.

Upstream Interface
    Interface towards the source of the datagram.  Also known as the 
    RPF Interface.

Downstream Interface
    All interfaces that are not upstream interfaces, including the 
    router itself.

(S,G) Pair
    Source S and destination group G associated with an IP packet.

Adams, Nicholas, Siadak                                         [Page 3]

4. Pseudocode Notation

We use set notation in several places in this specification.
    A (+) B is the union of two sets A and B.
    A (-) B are the elements of set A that are not in set B.
    NULL is the empty set or list.

Note that (+) and (-) operators are NOT commutative, and must be 
conducted in the order specified.

In addition we use C-like syntax:
    =   denotes assignment of a variable.
    ==  denotes a comparison for equality.
    !=  denotes a comparison for inequality.
    Braces { and } are used for grouping.

5. PIM-DM Protocol Overview

This section provides an overview of PIM-DM behavior.  It is intended 
as an introduction to how PIM-DM works, and is NOT definitive.  For the 
definitive specification, see Section 6. Protocol Specification.
PIM-DM assumes that when a source starts sending, all downstream 
systems want to receive multicast datagrams.  Initially, multicast 
datagrams are flooded to all areas of the network.  PIM-DM uses RPF to 
prevent looping of multicast datagrams while flooding.  If some areas 
of the network do not have group members, PIM-DM will prune off the 
forwarding branch by instantiating prune state.

Prune state has a finite lifetime.  When that lifetime expires, data 
will again be forwarded down the previously pruned branch.
Prune state is associated with an (S,G) pair.  When a new member for a 
group G appears in a pruned area, a router can "graft" toward the 
source S for the group, thereby turning the pruned branch back into a 
forwarding branch.

The broadcast of datagrams followed by pruning of unwanted branches is 
often referred to as a flood and prune cycle and is typical of dense 
mode protocols.

Compared with multicast routing protocols with built in topology 
discovery mechanisms (e.g. DVMRP) PIM-DM has a simplified design and is 
not hard-wired into a specific topology discovery protocol.  However, 
such a simplification does incur more overhead by causing flooding and 
pruning to occur on some links that could be avoided if sufficient 
topology information were available, i.e. to decide whether an 
interface leads to any downstream members of a particular group. 
Additional overhead is chosen in favor of the simplification and 
flexibility gained by not depending on a specific topology discovery 
protocol.

PIM-DM differs from PIM-SM in two essential ways: 1) There are no 
periodic joins transmitted, only explicitly triggered prunes and 
grafts.  2) There is no Rendezvous Point (RP).  This is particularly 
important in networks that cannot tolerate a single point of failure.  
(An RP is the root of a shared multicast distribution tree. For more 
details see [3]).

Adams, Nicholas, Siadak                                         [Page 4]

6. Protocol Specification

The specification of PIM-DM is broken into several parts:
    Section 6.1 details the protocol state stored.
    Section 6.2 specifies the data packet forwarding rules.
    Section 6.3 specifies generation and processing of Hello messages.
    Section 6.4 specifies the Join, Prune and Graft generation and 
                processing rules.
    Section 6.5 specifies the Assert generation and processing rules.
    Section 6.6 gives details on PIM-DM Packet Formats
    Section 6.7 summarizes PIM-DM timers and their defaults

6.1. PIM Protocol State

This section specifies all the protocol states that a PIM-DM 
implementation should maintain in order to function correctly.  We term 
this state the Tree Information Base or TIB, as it holds the state of 
all the multicast distribution trees at this router.  In this 
specification, we define PIM-DM mechanisms in terms of the TIB.  
However, only a very simple implementation would actually implement 
packet forwarding operations in terms of this state.  Most 
implementations will use this state to build a multicast forwarding 
table, which would then be updated when the relevant state in the TIB 
changes.

Although we specify precisely the state to be kept, this does not mean 
that an implementation of PIM-DM needs to hold the state in this form. 
This is actually an abstract state definition, which is needed in order 
to specify the router's behavior.  A PIM-DM implementation is free to 
hold whatever internal state it requires, and will still be conformant 
with this specification so long as it results in the same externally 
visible protocol behavior as an abstract router that holds the 
following state.

6.1.1. General Purpose State

A router stores the following non-group-specific state:
    For each interface:
        Neighbor State:
            For each neighbor:
                Information from neighbor's Hello
                Neighbor's Gen ID.
                Neighbor liveness timer (NLT)

6.1.2. (S,G) State

For every source/group pair (S,G), a router stores the following state:
    (S,G) state:
        For each interface:
            Local Membership:
                State: One of {"NoInfo", "Include"}
            PIM (S,G) Prune State:
                State: One of {"NoInfo" (NI), "Pruned" (P), 
                               "PrunePending" (PP)}
                Prune Pending Timer (PPT)
                Prune Timer (PT)

Adams, Nicholas, Siadak                                         [Page 5]

            (S,G) Assert Winner State:
                State: One of {"NoInfo" (NI), "I lost Assert" (L), 
                               "I won Assert" (W)}
                Assert Timer (AT)
                Assert winner's IP Address
                Assert winner's Assert Metric
        Upstream interface-specific:
            Graft/Prune State:
                State: One of {"Forwarding" (F), "Pruned" (P), 
                               "AckPending" (AP)} 
                GraftRetry Timer (GRT)
                Override Timer (OT)

6.1.3. State Summarization Macros

Using the state defined above, the following "macros" are defined and 
will be used in the descriptions of the state machines and pseudocode 
in the following sections.

The most important macros are those defining the outgoing interface 
list (or "olist") for the relevant state.

immediate_olist(S,G) = pim_nbrs - prunes(S,G) + 
                         (pim_include(*,G) - pim_exclude(S,G)) +
                         pim_include(S,G) - lost_assert(S,G)
olist(S,G) = immediate_olist(S,G) - RPF_interface(S)

The macros pim_include(*,G) and pim_include(S,G) indicate the 
interfaces to which traffic might be forwarded or not forwarded because 
of hosts that are local members on those interfaces.
 
pim_include(*,G) = {all interfaces I such that:
                    local_receiver_include(*,G,I)}
pim_include(S,G) = {all interfaces I such that:
                    local_receiver_include(S,G,I)}
pim_exclude(S,G) = {all interfaces I such that:
                    local_receiver_exclude(S,G,I) }

The macro RPF_interface(S) returns the RPF interface for source, S.  
That is to say, it returns the interface used to reach S as indicated 
by the MRIB.

The macro local_receiver_include(S,G,I) is true if the IGMP module or 
other local membership mechanism has determined that there are local 
members on interface I that desire to receive traffic sent specifically 
by S to G.  The macro local_receiver_include(*,G,I) is true if the IGMP 
module or other local membership mechanism has determined that there 
are local members on interface I that desire to receive all traffic 
sent to G.  Note that this determination is expected to account for 
membership joins initiated on or by the router. The macro 
local_receiver_exclude(S,G,I) is true if local_receiver_include(*,G,I) 
is true but none of the local members desire to receive traffic from S.
The set pim_nbrs is the set of all interfaces on which the router has 
at least one active PIM neighbor.

Adams, Nicholas, Siadak                                         [Page 6]

The set prunes(S,G) is the set of all interfaces on which the router 
has received Prune(S,G) messages:
prunes(S,G) = {all interfaces I such that DownstreamPState(S,G,I) 
               is in Pruned state}

The set lost_assert(S,G) is the set of all interfaces on which the 
router has lost an (S,G) Assert.  
lost_assert(S,G) = {all interfaces I such that 
                    lost_assert(S,G,I) == TRUE }

The following pseudocode macro definitions are also used in many places 
in the specification.  Basically RPF' is the RPF neighbor towards a 
source unless a PIM-DM Assert has overridden the normal choice of 
neighbor.

neighbor RPF'(S,G) {
  if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) {
    return AssertWinner(S, G, RPF_interface(S) )
  } else {
    return MRIB.next_hop( S )
  }
}

The macro I_Am_Assert_loser(S, G, I) is true if the Assert state 
machine (in 6.5. PIM Assert Messages) for (S,G) on interface I is in 
the "I am Assert Loser" state.

6.2. Data Packet Forwarding Rules

The PIM-DM packet forwarding rules are defined below in pseudocode.

  iif is the incoming interface of the packet.
  S is the source address of the packet.
  G is the destination address of the packet (group address).
  RPF_interface(S) is the interface the MRIB indicates would be used 
    to route packets to S.

First, an RPF check MUST be performed to determine whether the packet 
should be accepted based on TIB state and the interface on which that 
the packet arrived.  Packets that fail the RPF check MUST NOT be 
forwarded and the router will conduct an assert process for the (S,G) 
pair specified in the packet.  Packets for which a route to the source 
cannot be found MUST be discarded. 

If the RPF check has been passed, an outgoing interface list is 
constructed for the packet.  If this list is not empty, then the packet 
MUST be forwarded to all listed interfaces.  If the list is empty, then 
the router will conduct a prune process for the (S,G) pair specified in 
the packet.

Adams, Nicholas, Siadak                                         [Page 7]

On receipt on a data packet from S addressed to G on interface iif:

if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned ) {
  oiflist = immediate_olist(S,G)
}

oiflist = oiflist (-) iif

forward packet on all interfaces in oiflist

This pseudocode employs the following  "macro" definition:
UpstreamPState(S,G) is the state of the Upstream(S,G) state machine in 
section 6.4.1. Upstream Prune, Join and Graft Messages.

6.3. Hello Messages

This section describes the generation and processing of Hello messages.

6.3.1. Sending Hello Messages

PIM-DM uses Hello messages to detect other PIM routers.  Hello messages 
are sent periodically on each PIM enabled interface.  Hello messages 
are multicast to address 224.0.0.13 (the ALL PIM ROUTERS group).  When 
PIM is enabled on an interface or a router first starts, the Hello 
Timer (HT) MUST be set to a random value between 0 and Hello_Period.  
This prevents synchronization of Hello messages if multiple routers are 
powered on simultaneously.  

After the initial Hello message, a Hello message MUST be sent every 
Hello_Period.  A single Hello timer MAY be used to trigger sending 
Hello messages on all active interfaces.  The Hello Timer SHOULD NOT be 
reset except when it expires.

6.3.2. Receiving Hello Messages

When a Hello message is received, the receiving router SHALL record the 
receiving interface and the sender.  This information is retained for a 
number of seconds in the Hold Time field of the Hello Message.  If a 
new Hello message is received from a particular neighbor N, the 
Neighbor Liveness Timer (NLT(N,I)) MUST be reset to the new value.  

6.3.3. Hello Message Hold Time

The Hold Time in the Hello Message should be set to a value that can 
reasonably be expected to keep the Hello active until a new Hello 
message is received.  On most links, this will be 3.5 times the value 
of Hello_Period.

If the Hold Time is set to '0xffff', the receiving router MUST NOT time 
out that Hello message.  This feature might be used for on-demand links 
to avoid keeping the link up with periodic Hello messages.

If a Hold Time of '0' is received, the corresponding neighbor state is 
expired immediately. When an interface goes down or changes IP address, 
a Hello message with a zero Hold Time SHOULD be sent immediately (with 
the old IP address if the IP address is changed) to cause any PIM 
neighbors to remove the old information immediately.

Adams, Nicholas, Siadak                                         [Page 8]

6.4. PIM-DM Prune, Join and Graft Messages

This section describes the generation and processing of PIM-DM Join, 
Prune and Graft messages.  Prune messages are sent towards an upstream 
neighbor for S to indicate that traffic from S addressed to group G is 
not desired.  In the case of two downstream routers A and B, where A 
wishes to continue receiving data and B does not, A will send a Join in 
response to B’s Prune to override the Prune.  This is the only 
situation in PIM-DM in which a Join message is used.

Finally, a Graft message is used to re-join a previously pruned branch 
to the delivery tree.

6.4.1. Upstream Prune, Join and Graft Messages

The Upstream(S,G) state machine for sending Prune, Graft and Join 
messages is given below.  There are three states.

    Forwarding (F)
        This is the starting state of the Upsteam(S,G) state machine.  
        The state machine is in this state if it just started or if 
        oiflist(S,G) != NULL.

    Pruned(P)
        The set, olist(S,G), is empty   The router will not forward data 
        from S addressed to group G.

    AckPending(AP)
        The router was in the Pruned(P) state but a transition has 
        occurred in the Downstream(S,G) state machine for one of this 
        (S,G) entry’s outgoing interfaces indicating that traffic from S 
        addressed to G should again be forwarded.  A Graft message has 
        been sent to RPF’(S) but a Graft Ack message has not yet been 
        received.

In addition there are three state-machine-specific timers:

    GraftRetry Timer (GRT(S,G))
        This timer is set when a Graft is sent upstream.  If a 
        corresponding GraftAck is not received before the timer expires, 
        then another Graft is sent and the GraftRetry Timer is reset.  
        The timer is stopped when a Graft Ack message is received. This 
        timer is normally set to Graft_Retry_Period (see 6.7.1).

    Override Timer (OT(S,G))
        This timer is set when a Prune(S,G) is received on the upstream 
        interface where olist(S,G) != NULL.  When the timer expires, a 
        Join(S,G) message is sent on the upstream interface. This timer 
        is normally set to t_override (see 6.7.1).

    Prune Limit Timer (PLT(S,G))
        This timer is used to rate-limit Prunes on a LAN.  It is only 
        used when the Upstream(S,G) state machine is in the Pruned state. 
        A Prune cannot be sent if this timer is running. This timer is 
        normally set to t_limit (see 6.7.1)

Adams, Nicholas, Siadak                                         [Page 9]

[For State Machine Figure refer to Postscript Version]

                          Figure 1

In tabular form, the state machine is defined as follows.

[For State Machine Table refer to Postscript Version]

The transition event "Rcv GraftAck(S,G)" implies receiving a Graft Ack 
message targeted to this router’s address on the incoming interface for 
the (S,G) entry.  If the destination address is not correct, the state 
transitions in this state machine must not occur.

Transitions from the Forwarding (F) State
    When the Upstream(S,G) state machine is in the Forwarding (F) state, 
    the following events may trigger a transition:

    Data Packet arrives on RPF_Interface(S) and olist(S,G) == NULL
        The Upstream(S,G) state machine MUST transition to the Pruned 
        (P) state, send a Prune(S,G) to RPF’(S) and set PLT(S,G) to 
        t_limit seconds.

    olist(S,G) -> NULL
        The Upstream(S,G) state machine SHOULD transition to the Pruned 
        (P) state, send a Prune(S,G) to RPF’(S) and set PLT(S,G) to 
        t_limit seconds.

    See Prune(S,G) to RPF’(S)
        This event is only relevant if RPF_interface(S) is a shared 
        medium.  

        This router sees another router on RPF_interface(S) send a 
        Prune(S,G) to RPF’(S,G).  As this router is in Forwarding state, 
        it must override the Prune after a short random interval.  If 
        OT(S,G) is not running, the router MUST set OT(S,G) to 
        t_override seconds.

        The Upstream(S,G) state machine remains in Forwarding (F) state.  
        If the OT(S,G) is set to expire in more than t_override seconds,
        reset it to t_override seconds.

    See Join(S,G) to RPF’(S)
        This event is only relevant if RPF_interface(S) is a shared 
        medium.  This router sees another router on RPF_interface(S) 
        send a Join(S,G) to RPF’(S,G). If the OT(S,G) is running, then 
        it means that the router had scheduled a Join to override a 
        previously received Prune.  Another router has responded more 
        quickly with a Join and so the local router SHOULD cancel its 
        OT(S,G), if it is running.  The Upstream(S,G) state machine 
        remains in the Forwarding (F) state.

    OT(S,G) Expires
        The OverrideTimer (OT(S,G)) expires.  The router MUST send a 
        Join(S,G) to RPF’(S) to override a previously detected prune.
        The Upstream(S,G) state machine remains in the Forwarding (F) 
        state.

Adams, Nicholas, Siadak                                        [Page 10]

    RPF’(S) Changes AND olist(S,G) is non-null
        Unicast routing or Assert state causes RPF’(S) to change, 
        including changes to RPF_Interface(S).

        The Upstream(S,G) state machine SHOULD transition to the 
        AckPending (AP) state, a Graft unicast to the new RPF’(S)and 
        the GraftRetry Timer (GRT(S,G)) set to Graft_Retry_Period.

Transitions from the Pruned (P) State
    When the Upstream(S,G) state machine is in the Pruned (P) state, the 
    following events may trigger a transition:

    olist(S,G)->non-null
        The set of interfaces defined by the olist(S,G) macro becomes 
        non-empty indicating traffic from S addressed to group G must be 
        forwarded.

        The Upstream(S,G) state machine MUST transition to the 
        AckPending (AP) state and unicasts a Graft message to RPF’(S).  
        The Graft Retry Timer (GRT(S,G)) MUST be set to 
        Graft_Retry_Period.

    See Prune(S,G) to RPF’(S)
        A Prune(S,G) is seen on RPF_interface(S).

        The Upstream(S,G) state machine stays in the Pruned (P) state.  
        The router MAY reset its PLT(S,G) to the value in the Holdtime 
        field of the received message if greater than the current value 
        of the PLT(S,G).

    RPF’(S) Changes AND olist(S,G) -> non-null
        Unicast routing or Assert state causes RPF’(S) to change, 
        including changes to RPF_Interface(S).

        The Upstream(S,G) state machine SHOULD transition to the 
        AckPending (AP) state.  A Prune is multicast to the old RPF’(S) 
        and a Graft is unicast to the new RPF’(S).  The GraftRetry Timer
        (GRT(S,G)) is set to Graft_Retry_Period.

    PLT(S,G) Timer Expires
        The router MUST transition to the Forwarding (F) state.

Transitions from the AckPending (AP) State
    When the Upstream(S,G) state machine is in the AckPending (AP) 
    state, the following events may trigger a transition:

    GRT(S,G) Expires
        The GraftRetry Timer (GRT(S,G)) expires for this (S,G) entry.
        The Upstream(S,G) state machine stays in the AckPending (AP) 
        state. Another Graft message for (S,G) SHOULD be unicasted to 
        RPF’(S) and the GraftRetry Timer (GRT(S,G)) reset to 
        Graft_Retry_Period.

Adams, Nicholas, Siadak                                        [Page 11]

    RPF(S)’ Changes and olist(S,G) does not become NULL
        Unicast routing or Assert state causes RPF’(S) to change, 
        including changes to RPF_Interface(S).

        The Upstream(S,G) state machine SHOULD stay in the AckPending 
        (AP) state, A Graft  unicast to the new RPF’(S) and the 
        GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period.

    See GraftAck(S,G) from RPF’(S)
        A GraftAck is received from  RPF’(S).
        The GraftRetry Timer MUST be cancelled and the Upstream(S,G) 
        state machine MUST transition to the Forwarding(F) state.

    olist(S,G) -> NULL
        The set of interfaces defined by the olist(S,G) macro becomes 
        null indicating traffic from S addressed to group G should no 
        longer be forwarded.

        The Upstream(S,G) state machine MUST transition to the Pruned 
        (P) state.  A Prune(S,G) MUST be multicast to the 
        RPF_interface(S) with RPF’(S) named in the upstream neighbor 
        field.  The GraftRetry Timer (GRT(S,G)) MUST be cancelled.

    See Prune(S,G) to RPF’(S,G)
        This event is only relevant if RPF_interface(S) is a shared 
        medium.  This router sees another router on RPF_interface(S) 
        send a Prune(S,G) to RPF’(S,G).  As this router is in AckPending
        (AP) state, it must override the Prune after a short random 
        interval. If OT(S,G) is not running, the router MUST set OT(S,G)
        to t_override seconds.

        The Upstream(S,G) state machine remains in AckPending (AP) state.  
        If the OT(S,G) is set to expire in more than t_override seconds, 
        reset it to t_override seconds.

    See Join(S,G) to RPF’(S,G)
        This event is only relevant if RPF_interface(S) is a shared 
        medium.  This router sees another router on RPF_interface(S) 
        send a Join(S,G) to RPF’(S,G). If the OT(S,G) is running, then 
        it means that the router had scheduled a Join to override a 
        previously received Prune.  Another router has responded more 
        quickly with a Join and so the local router SHOULD cancel its 
        OT(S,G), if it is running.

        The Upstream(S,G) state machine remains in the AckPending (AP) 
        state.

    OT(S,G) Expires
        The OverrideTimer (OT(S,G)) expires. The router MUST send a 
        Join(S,G) to RPF’(S).

        The Upstream(S,G) state machine remains in the AckPending (AP) 
        state.

Adams, Nicholas, Siadak                                        [Page 12]

6.4.2. Downstream Prune, Join and Graft Messages

The Prune(S,G) Downstream state machine for receiving Prune, Join and 
Graft messages on interface I is given below.  This state machine will 
always be in the NoInfo state on the upstream interface.  It contains 
three states.

    NoInfo(NI)
        The interface has no (S,G) Prune state and neither the Prune 
        timer (PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is 
        running.

    PrunePending(PP)
        The router has received a Prune(S,G) on this interface from a 
        downstream neighbor and is waiting to see whether the prune will 
        be overridden by another downstream router.  For forwarding 
        purposes, the PrunePending state functions exactly like the 
        NotPruned state.

    Pruned(P)
        The router has received a Prune(S,G) on this interface from a 
        downstream neighbor and the Prune was not overridden.  Data from 
        S addressed to group G is no longer being forwarded on this 
        interface.

In addition there are two timers:

    PrunePending Timer (PPT(S,G,I))
        This timer is set when a valid Prune(S,G) is received.  Expiry 
        of the PrunePending Timer (PPT(S,G,I)) causes the interface to 
        transition to the Pruned state.

    Prune Timer (PT(S,G,I))
        This timer is set when the PrunePending Timer (PT(S,G,I)) 
        expires.  Expiry of the Prune Timer (PT(S,G,I)) causes the 
        interface to transition to the NotPruned (NP) state, thereby 
        allowing data from S addressed to group G to be forwarded on the 
        interface.

[See Postscript Version for Figure]
 
Figure 1: Prune(S,G) Downstream State Machine

In tabular form, the state machine is:

[See Postscript Version for Table]

The transition events "Rcv Graft(S,G)", "Rcv Prune(S,G)" and "Rcv 
Join(S,G)" denote receiving a Graft, Prune or Join message in which 
this router’s address on I is contained in the message’s upstream 
neighbor field.  If the upstream neighbor field does not match this 
router’s address on I, then these state transitions in this state 
machine must not occur.

Transitions from the NoInfo State
When the Prune(S,G) Downstream state machine is in the NoInfo (NI) 
state, the following events may trigger a transition:

Adams, Nicholas, Siadak                                        [Page 13]

    Receive Prune(S,G)
        A Prune(S,G) is received on interface I 

        The Prune(S,G) Downstream state machine on interface I MUST 
        transition to the PrunePending (PP) state.  The PrunePending 
        Timer (PPT(S,G,I)) MUST be set to J/P_Override_Interval if the 
        router has more than one neighbor on I.  If the router has only 
        one neighbor on interface I, then it SHOULD set the PPT(S,G,I) 
        to zero, effectively transitioning immediately to the Pruned (P) 
        state.

    Receive Graft(S,G)
        A Graft(S,G) is received on the interface I with the upstream 
        neighbor field set to the router’s address on I.

        The Prune(S,G) Downstream state machine on interface I stays in 
        the NotPruned (NP) state.  A GraftAck(S,G) MUST be unicasted to 
        the originator of the Graft(S,G) message.

    Transitions from the PrunePending (PP) State
        When the Prune(S,G) downstream state machine is in the 
        PrunePending (PP) state, the following events may trigger a 
        transition.

    Receive Graft(S,G)
        A Graft(S,G) is received on interface I 

        The Prune(S,G) Downstream state machine on interface I MUST 
        transition to the NoInfo (NI) state.  If the upstream neighbor 
        field of the Graft message is set to the router’s address on I, 
        the router MUST unicast a Graft Ack message to the Graft 
        originator.  The PrunePending Timer (PPT(S,G,I)) is cancelled.

    Receive Join(S,G)
        A Join(S,G) is received on interface I

        The Prune(S,G) Downstream state machine on interface I MUST 
        transition to the NoInfo (NI) state.  The PrunePending Timer 
        (PPT(S,G,I)) is cancelled.

    PPT(S,G,I) Expires
        The PrunePending Timer (PPT(S,G,I)) expires indicating that no 
        neighbors have overridden the previous Prune(S,G) message.

        The Prune(S,G) Downstream state machine on interface I MUST 
        transition to the Pruned (P) state.  The Prune Timer (PT(S,G,I))
        is started and MUST be initialized to the received 
        Prune_Hold_Time minus J/P_Override_Interval.  A PruneEcho(S,G) 
        MUST be sent on I.

        A PruneEcho(S,G) is simply a Prune(S,G) message multicast by the 
        upstream router to  a LAN with itself as the Upstream Neighbor.  
        Its purpose is to add additional reliability so that if a Join 
        that should have overridden the Prune  is lost locally on the 
        LAN, then the PruneEcho(S,G) may be received and trigger a new 
        Join message .  A PruneEcho(S,G) need not be sent on a point-to-
        point interface.

Adams, Nicholas, Siadak                                        [Page 14]

    RPF_Interface(S) becomes interface I
        The upstream interface for S has changed.

        The Prune(S,G) Downstream state machine on interface I MUST 
        transition to the NoInfo (NI) state.  The PrunePending Timer 
        (PPT(S,G,I)) MUST be cancelled.

Transitions from the Prune (P) State
When the Prune(S,G) Downstream state machine is in the Pruned (P) 
state, the following events may trigger a transition.

    Receive Graft(S,G)
        A Graft(S,G) is received on interface I 

        The Prune(S,G) Downstream state machine on interface I MUST 
        transition to the NoInfo (NI) state.  If the Upstream Neighbor 
        is set to the router’s address on I, the router MUST send a 
        Graft Ack back to the Graft’s source. The Prune Timer 
        (PT(S,G,I)) is cancelled. The router SHOULD evaluate any 
        possible transitions in the Upstream(S,G) state machine.

    Receive Join(S,G)
        A Join(S,G) is received on the interface I 

        The Prune(S,G) downstream state machine on interface I MUST 
        transition to the NoInfo (NI) state.  The Prune Timer 
        (PT(S,G,I)) is cancelled.  The router SHOULD evaluate any 
        possible transitions in the Upstream(S,G) state machine.

    Receive Prune(S,G)
        A Prune(S,G) is received on the interface I 

        The Prune(S,G) Downstream state machine on interface I remains 
        in the Pruned (P) state.  The Prune Timer (PT(S,G,I)) SHOULD be 
        reset to the holdtime contained in the Prune(S,G) message.

    PT(S,G,I) Expires
        The Prune Timer (PT(S,G,I)) expires indicating that it is again 
        time to flood data from S addressed to group G onto interface I.

        The Prune(S,G) Downstream state machine on interface I MUST 
        transition to the NoInfo (NI) state.  The router SHOULD evaluate 
        any possible transitions in the Upstream(S,G) state machine.

    RPF_Interface(S) becomes interface I
        The upstream interface for S has changed.

        The Prune(S,G) Downstream state machine on interface I MUST 
        transition to the NoInfo (NI) state.  The PrunePending Timer 
        (PT(S,G,I)) MUST be cancelled.

6.5. PIM Assert Messages

6.5.1. (S,G) Assert Message State Machine

The (S,G) Assert state machine for interface I is shown in Figure 3. 

Adams, Nicholas, Siadak                                        [Page 15]

There are three states:

    NoInfo (NI)
        This router has no (S,G) Assert state on interface I.

    I am Assert Winner (W)
        This router has won an (S,G) Assert on interface I.  It is now 
        responsible for forwarding traffic from S destined for G via 
        interface I.

    I am Assert Loser (L)
        This router has lost an (S,G) Assert on interface I.  It must 
        not forward packets from S destined for G onto interface I.  

In addition there is also an Assert Timer (AT(S,G,I)) that is used to 
time out Assert state on the Assert losers and to resend Assert 
messages on the Assert winner.

[See Postscript Version for Figure] 

Figure 3: Per-interface (S,G) Assert state machine

In tabular form the state machine is defined as follows.

[See Postscript Version for Table]

Note that for reasons of compactness, "AssTrDes(S,G,I)" is used in the 
state machine table to refer to AssertTrackingDesired(S,G,I).

Terminology:
    A "preferred assert" is one with a better metric than the current 
    winner.

    An "inferior assert" is one with a worse metric than 
    my_assert_metric(S,G,I).

The state machine uses the following macros:

CouldAssert(S,G,I) = (RPF_interface(S) != I AND 
                      (I in immediate_olist(S,G) + lost_assert(S,G)))

AssertTrackingDesired(S,G,I) = ((I in immediate_olist(S,G) + 
                                 lost_assert(S,G)) OR 
                                (RPF_interface(S)==I AND 
                                 UpstreamPState(S,G) != P))

AssertTrackingDesired(S,G,I) is true on any interface in which an (S,G) 
assert might affect our behavior.

The first line accounts for (S,G) join information received on I that 
might cause the router to be interested in Asserts on I.

The last line accounts for the fact that a router must keep track of 
Assert information on upstream interfaces in order to send Grafts and 
Prunes to the proper neighbor.

Adams, Nicholas, Siadak                                        [Page 16]

Transitions from NoInfo State
When in NoInfo state, the following events may trigger transitions:

    Receive Inferior Assert AND CouldAssert(S,G,I)==TRUE
        An Assert is received for (S,G) that is inferior to our own 
        assert metric. The Assert state machine MUST transition to the 
        "I am Assert Winner" state, and perform actions A1 (below).

    An (S,G) data packet arrives on downstream interface I
        An (S,G) data packet arrived on a downstream interface which is 
        contained in immediate_olist(S,G).  It is optimistically assumed 
        that this router will be the Assert winner for this (S,G).  The 
        Assert state machine MUST transition to the "I am Assert Winner" 
        state and perform actions A1 (below), thereby initiating the 
        Assert negotiation for (S,G).

    Receive Preferred Assert AND AssertTrackingDesired(S,G,I)==TRUE
        This router is interested in (S,G) Asserts on interface I either 
        because I is a downstream interface for which there exists (S,G) 
        forwarding state, or because I is the upstream interface for S 
        and there exists (S,G) forwarding state.  The received Assert 
        has a better metric than this router’s and therefore the Assert 
        state machine MUST transition to the "I am Assert Loser" state 
        and perform actions A2(below).  The router MUST also multicast a 
        Prune(S,G) to the Assert winner.

Transitions from Winner State
When in "I am Assert Winner" state, the following events trigger 
transitions:

    AT(S,G,I) Expires
        The (S,G) Assert Timer (AT(S,G,I)) expires.  Since the Assert 
        state machine is currently in the Winner state, then there must 
        still exist (S,G) forwarding state that is actively being kept 
        alive.  An (S,G) Assert SHOULD be resent and the Assert Timer 
        (AT(S,G,I)) restarted (Action A3 below).  Note that the Assert 
        winner's timer is engineered to expire shortly before timers on 
        Assert losers. This prevents unnecessary Assert negotiation and 
        periodic flooding of duplicate packets. 

    Receive Inferior Assert
        An (S,G) Assert is received containing a metric for S that is 
        worse metric than this router’s metric for S.  Whoever sent the 
        Assert is in error, and so an (S,G) Assert MUST be resent and 
        the Assert Timer (AT(S,G,I)) restarted.(Action A3 below).

    Receive Preferred Assert
        An (S,G) Assert is received that has a better metric than this 
        router’s metric for S.  The Assert state machine MUST transition 
        to "I am Assert Loser" state and perform actions A2 (below). The 
        router MUST also multicast a Prune(S,G) to the Assert winner.

Adams, Nicholas, Siadak                                        [Page 17]

    CouldAssert(S,G,I) -> FALSE
        This router’s (S,G) forwarding state or RPF interface changed so 
        as to make CouldAssert(S,G,I) become false.  This router can no 
        longer perform the actions of the Assert winner, and so the 
        Assert state machine MUST transition to NoInfo state and perform 
        actions A4 (below).  This includes sending a "Cancelling Assert" 
        with an infinite metric.

Transitions from Loser State
When in "I am Assert Loser" state, the following transitions can occur:

    Receive Preferred Assert
        An Assert is received that is better than or equal to that of 
        the current Assert winner.  The Assert state machine remains in 
        Loser (L) state and SHOULD perform actions A2 below. The router 
        MUST also multicast a Prune(S,G) to the Assert winner.

    RPF interface changed away from interface I
        Interface I used to be the RPF interface for S, and now it is 
        not.  The Assert state machine MUST transition to NoInfo (NI) 
        state and perform action A5 (below).

    Receive Inferior Assert from Current Winner
        An Assert is received from the current Assert winner that is 
        worse than this router’s metric for S (typically the winner's 
        metric became worse).  The Assert state machine MUST transition 
        to NoInfo (NI) state and perform action A5 (below). Usually this 
        router will eventually re-assert and win when data packets from 
        S have started flowing again.

    AT(S,G,I) Expires
        The (S,G) Assert Timer (AT(S,G,I)) expires.  The Assert state 
        machine MUST transition to NoInfo (NI) state and performs action 
        A5 (below).

    AssertTrackingDesired(S,G,I)->FALSE
        AssertTrackingDesired(S,G,I) becomes FALSE.  This router’s 
        forwarding state has changed so that (S,G) Asserts on interface 
        I are no longer of interest to it.  The Assert state machine 
        transitions to the NoInfo (NI) state and performs action A5 
        (below).

    My metric becomes better than the assert winner's metric
        my_assert_metric(S,G,I) has changed so that now this router’s 
        Assert metric for (S,G) is better than the metric it has stored 
        for current Assert winner.  This might happen when the 
        underlying routing metric changes, or when CouldAssert(S,G,I) 
        becomes true. 

        The Assert state machine MUST transition to NoInfo (NI) state 
        and perform action A5 (below).

    Current Assert Winner’s NeighborLiveness Timer Expires
        The current Assert winner’s NeighborLiveness Timer (NLT(N,I)) 
        has expired.  The Assert state machine MUST transition to the NoInfo 
        (NI) state and performs action A5 (below).

Adams, Nicholas, Siadak                                        [Page 18]

    Receive Graft(S,G)
        A Graft(S,G) message was received on interface I with its IP 
        destination set to the router’s address on I.  The Assert state 
        machine transitions to the NoInfo (NI) state and performs action 
        A5 (below).

    Receive Prune(S,G) 
        A Prune(S,G) message was received on interface I with its IP 
        destination set to the router’s address on I.  The Assert state 
        machine transitions to the NoInfo (NI) state and performs action 
        A5 (below).

(S,G) Assert State-machine Actions

    A1:	Send Assert(S,G)
        Set timer to (Assert_Time - Assert_Override_Interval)
        Store self as AssertWinner

    A2:	Store new Assert winner
        Set timer to Assert_Time

    A3:	Send Assert(S,G)
        Set timer to (Assert_Time - Assert_Override_Interval)

    A4:	Send AssertCancel(S,G)
        Delete assert info

    A5:	Delete Assert info

6.5.2. Assert Metrics

Assert metrics are defined as:

struct assert_metric {
  metric_preference;
  route_metric;
  ip_address;
};

When comparing assert_metrics, the metric_preference and route_metric 
field are compared in order, where the first lower value wins.  If all 
fields are equal, the IP address of the router that sourced the Assert 
message is used as a tie-breaker, with the highest IP address winning.
An Assert metric for (S,G) to include in (or compare against) an Assert 
message sent on interface I should be computed using the following 
pseudocode:

assert_metric
my_assert_metric(S,G,I) {
  if (CouldAssert(S,G,I) == TRUE) {
    return spt_assert_metric(S,G,I)
  else {
    return infinite_assert_metric()
  }
}

Adams, Nicholas, Siadak                                        [Page 19]

spt_assert_metric(S,I) gives the Assert metric we use if we're sending 
an Assert based on active (S,G) forwarding state:

assert_metric
spt_assert_metric(S,I) {
  return {0,MRIB.pref(S),MRIB.metric(S),my_ip_address(I)}
}

MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing 
metrics associated with the route to a particular (unicast) destination 
X, as determined by the MRIB.  my_ip_address(I) is simply the router's 
IP address that is associated with the local interface I.

infinite_assert_metric() gives the Assert metric we need to send an 
Assert but doesn’t match (S,G) forwarding state:

assert_metric
infinite_assert_metric() {
  return {1,infinity,infinity,infinity}
}

6.5.3. AssertCancel Messages

An AssertCancel(S,G) message is simply an Assert message for (S,G) with 
infinite metric.  The Assert winner sends such a message when it 
deletes the forwarding state that triggered the original Assert 
exchange.  Other routers will see this metric, causing those with 
forwarding state to send their own Asserts and re-establish an Assert 
winner.

AssertCancel messages are simply an optimization.  The original Assert 
timeout mechanism will allow a subnet to eventually become consistent; 
the AssertCancel mechanism simply causes faster convergence.  No 
special processing is required for an AssertCancel message, since it is 
simply an Assert message from the current winner.

6.5.4. Assert State Macros 

The macro lost_assert(S,G,I), is used in the olist computations of 
section 6.1.3. State Summarization Macros, and is defined as follows.

bool lost_assert(S,G,I) {
  if (RPF_interface(S) == I) {
    return FALSE
  } else {
    return (AssertWinner(S,G,I) != me  AND
            (AssertWinnerMetric(S,G,I) is better than 
             spt_assert_metric(S,G,I))
  }
}

AssertWinner(S,G,I) defaults to Null and AssertWinnerMetric(S,G,I) 
defaults to Infinity when in the NoInfo state.

Adams, Nicholas, Siadak                                        [Page 20]

6.5.5. Rationale for Assert Rules 

The following is a summary of the rules for generating and processing 
Assert messages.  It is not intended to be definitive (the state 
machines and pseudocode provide the definitive behavior).  Instead it 
provides some rationale for the behavior.

1.  The Assert winner for (S,G) must act as the local forwarder for 
    (S,G) on behalf all downstream members.
2.  PIM messages are directed towards to the RPF' neighbor and not to 
    the regular RPF neighbor.
3.  An Assert loser that receives a Graft(S,G) directed to it cancels 
    the (S,G) assert timer.
4.  An assert winner for (S,G) sends a canceling assert when it is about 
    to stop forwarding on an (S,G) entry. Example : if a router is being 
    taken down, then a canceling assert is sent.
5.  [Optionally] re-assert before timing out.
    This prevents periodic duplicates.

6.6. PIM Packet Formats

All PIM-DM packets use the same format as PIM-SM packets.  All PIM 
control messages have IP protocol number 103.  All PIM-DM messages MUST 
be sent with a TTL of 1.  All PIM-DM messages except Graft Ack messages 
MUST be sent to the ALL-PIM-ROUTERS group (224.0.0.13).  Graft Ack 
messages are unicast to the sender of the Graft.

6.6.1. PIM Header

All PIM control messages have the following header:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |   Reserved    |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Ver
PIM version number is 2.

Type
Types for specific PIM messages.  Available types are:
0 = Hello
1 = Register (PIM-SM only)
2 = Register Stop (PIM-SM only)
3 = Join/Prune
4 = Bootstrap (PIM-SM only)
5 = Assert
6 = Graft
7 = Graft Ack
8 = Candidate RP Advertisement (PIM-SM only)

Reserved
Set to zero on transmission.  Ignored upon receipt.

Adams, Nicholas, Siadak                                        [Page 21]

Checksum
The checksum is standard IP checksum, i.e. the 16 bit one's 
complement of the one's complement sum of the entire PIM message.  
For computing checksum, the checksum field is zeroed.

6.6.2. Encoded Unicast Address

An Encoded Unicast Address has the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Family  | Encoding Type |     Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

Addr Family
The PIM Address Family of the 'Unicast Address' field of this 
address.

Values of 0-127 are as assigned by the IANA for Internet Address 
Families in [6].  Values 128-250 are reserved to be assigned by the 
IANA for PIM specific Address Families.  Values 251-255 are 
designated for private use.  As there is no assignment authority for 
this space, collisions should be expected.

Encoding Type
The type of encoding used with a specific Address Family.  The value 
'0' is reserved for this field, and represents the native encoding 
of the Address Family

Unicast Address
The unicast address as represented by the given Address Family and 
Encoding Type.

6.6.3. Encoded Group Address

An Encoded Group address has the following format:
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Family  | Encoding Type |   Reserved    |  Mask Len     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Group Multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

Addr Family
As described above.

Encoding Type
As described above.

Reserved
Transmitted as zero.  Ignored upon receipt.

Adams, Nicholas, Siadak                                        [Page 22]

Mask Len
The mask length field is 8 bits.  The value is the number of 
contiguous on bits left justified used as a mask, which combined 
with the address, describes a range of addresses.  It is less 
than or equal to the address length in bits for the given Address 
Family and Encoding Type.  If the message is sent for a single 
address then the mask length MUST equal the address length.  PIM-
DM routers MUST only send for a single address.

Group Multicast Address
The address of the multicast group.

6.6.4. Encoded Source Address

An Encoded Source address has the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Family  | Encoding Type |  Rsrvd  |S|W|R|  Mask Len     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Source Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

Addr Family
As described above.

Encoding Type
As described above.

Rsrvd
Reserved.  Transmitted as zero.  Ignored upon receipt.

S
The Sparse Bit.  Set to 0 for PIM-DM.  Ignored upon receipt.

W
The Wild Card Bit.  Set to 0 for PIM-DM.  Ignored upon receipt.

R
The Rendezvous Point Tree bit.  Set to 0 for PIM-DM.  Ignored  upon 
receipt.

Mask Len
As described above.  PIM-DM routers MUST only send for a single 
source address.

Source Address
The source address.

Adams, Nicholas, Siadak                                        [Page 23]

6.6.5. Hello Message Format
The PIM Hello message has the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |   Reserved    |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Option Type          |         Option Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Option Value                          |
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Option Type          |         Option Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Option Value                          |
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Ver, Type, Reserved, Checksum
Described above.

Option Type
The type of option given in the Option Value field.  Available types 
are:
0	Reserved
1	Hello Hold Time
2-16	Reserved
17	To be assigned by IANA
18	Deprecated and SHOULD NOT be used
19	DR Priority
20	Generation ID
21-65000	To be assigned by IANA
65001-65535	Reserved for Private Use [7]

The Hello Hold Time option MUST be used by PIM-DM routers.  DR Priority 
option SHOULD be used by PIM-DM routers.  Generation ID MAY be used by 
PIM-DM routers.  Unknown options SHOULD be ignored.

Option Length
The length of the Option Value field in bytes.  The following values 
are used with the given option:
Hello Hold Time 2
DR Priority     4
Generation ID   4

Option Value
A variable length field, carrying the value of the option.  A 
description of the assigned options follows.

Adams, Nicholas, Siadak                                        [Page 24]

Hello Hold Time
Hold Time is the number of seconds a receiver MUST keep the neighbor 
reachable.  If the Hold Time is set to '0xffff', the receiver of this 
message never times out the neighbor.

DR Priority
DR Priority is an unsigned integer and is used in the DR election 
process described in section 4.1.4. See [3] for a complete description 
of DR priority.

Generation ID
Generation ID is a random value for the interface on which the Hello 
message is sent.  The Generation ID is regenerated whenever PIM 
forwarding is started or restarted on the interface.

6.6.6. Join/Prune Message Format

PIM Join/Prune messages have the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |   Reserved    |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Upstream Neighbor Address (Encoded Unicast Format)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Reserved    |  Num Groups   |          Hold Time            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Multicast Group Address 1 (Encoded Group Format)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Number of Joined Sources    |   Number of Pruned Sources    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Joined Source Address 1 (Encoded Source Format)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Joined Source Address n (Encoded Source Format)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Pruned Source Address 1 (Encoded Source Format)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Pruned Source Address n (Encoded Source Format)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Multicast Group Address m (Encoded Group Format)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Number of Joined Sources    |   Number of Pruned Sources    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Joined Source Address 1 (Encoded Source Format)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Adams, Nicholas, Siadak                                        [Page 25]

|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Joined Source Address n (Encoded Source Format)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Pruned Source Address 1 (Encoded Source Format)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Pruned Source Address n (Encoded Source Format)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Ver, Type, Reserved, Checksum
Described above.

Upstream Neighbor Address
The address of the upstream neighbor.  The format for this address is 
given in the Encoded Unicast address in section 4.7.2.  PIM-DM routers 
MUST set this field to the RPF next hop and SHOULD ignore it upon 
reception.

Reserved
Transmitted as zero.  Ignored upon receipt.

Hold Time
The number of seconds a receiving PIM-DM router MUST keep a Prune state 
alive, unless removed by a Join or Graft message. If the Hold Time is 
'0xffff', the receiver MUST NOT remove the Prune state, unless a 
corresponding Join or Graft message is received.  The Hold Time is 
ignored in Join messages.

Number of Groups
Number of multicast group sets contained in the message.

Multicast Group Address
The multicast group address in the Encoded Multicast address format 
given in section 4.7.3.

Number of Joined Sources
Number of Join source addresses listed for a given group.

Number of Pruned Sources
Number of Prune source addresses listed for a given group.

Join Source Address 1..n
This list contains the sources from which the sending router wishes to 
continue to receive multicast messages for the given group on this 
interface.  The addresses use the Encoded Source address format given 
in section 4.7.4.

Prune Source Address 1..n
This list contains the sources from which the sending router does not 
wish to receive multicast messages for the given group on this 
interface.  The addresses use the Encoded Source address format given 
in section 4.7.4.

Adams, Nicholas, Siadak                                        [Page 26]

6.6.7. Assert Message Format

PIM Assert Messages have the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |   Reserved    |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Multicast Group Address (Encoded Group Format)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Source Address (Encoded Unicast Format)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|                     Metric Preference                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Metric                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PIM Ver, Type, Reserved, Checksum
Described above.

Multicast Group Address
The multicast group address in the Encoded Multicast address format 
given in section 4.7.3.

Source Address
The source address in the Encoded Source address format given in 
section 4.7.4.

R
The Rendezvous Point Tree bit.  Set to 0 for PIM-DM.  Ignored upon 
receipt.

Metric Preference
The preference value assigned to the unicast routing protocol that 
provided the route to the source.

Metric
The cost metric of the unicast route to the source.  The metric is in 
units applicable to the unicast routing protocol used.

6.6.8. Graft Message Format

PIM Graft messages use the same format as Join/Prune messages except 
the Type field is set to 6.  The source address MUST be in the Join 
section of the message.  The Hold Time field SHOULD be zero and SHOULD 
be ignored when a Graft is received.

6.6.9. Graft Ack Message Format

PIM Graft Ack messages are identical to the received Graft message 
except the Type field is set to 7.

Adams, Nicholas, Siadak                                        [Page 27]

6.7. PIM-DM Timers

PIM-DM maintains the following timers.  All timers are countdown timers 
- they are set to a value and count down to zero, at which point they 
typically trigger an action.  Of course they can just as easily be 
implemented as count-up timers, where the absolute expiry time is 
stored and compared against a real-time clock, but the language in this 
specification assumes that they count downwards towards zero.

Global Timers
    Hello Timer: HT
    Per interface (I):
    Per neighbor (N):
        Neighbor Liveness Timer: NLT(N,I)
    Per (S,G) Pair:
        (S,G) Assert Timer: AT(S,G,I)
        (S,G) Prune Timer: PT(S,G,I)
        (S,G) PrunePending Timer: PPT(S,G,I)
    Per (S,G) Pair:
        (S,G) Graft Retry Timer: GT(S,G)
        (S,G) Upstream Override Timer: OT(S,G)
        (S,G) PruneLimit Timer: PLT(S,G)

6.7.1. Timer Values

When timer values are started or restarted, they are set to default 
values.  This section summarizes those default values.

Hello Timer (HT)    
    Hello_Period - 30 sec
    Triggered_Hello_Delay - 5 sec

    Hello message are sent on every active interface once every 
    Hello_Period seconds.  At system power-up, the timer is initialized 
    to rand(0,Triggered_Hello_Delay) to prevent synchronization.  When a 
    new or rebooting neighbor is detected, a responding Hello is sent 
    within rand(0,Triggered_Hello_Delay).  Hello_Period corresponds to 
    the PIM MIB object pimInterfaceHelloInterval.

Neighbor Liveness Timer: NLT(N,I)
    Hello_Holdtime - From Message

    Hold Time read from Hello message.

PrunePending Timer (PPT(S,G,I))
    J/P_Override_Interval - 3 secs

    Short period after a join or prune to allow other routers on the LAN
    to override the join or prune.

Assert Timer (AT(S,G,I))
    Assert_Override_Interval - 3 secs

    Short interval before an Assert times out where the Assert winner 
    resends an Assert message.

Adams, Nicholas, Siadak                                        [Page 28]

    Assert_Time - 180 secs

    Period after last Assert before Assert state is timed out.

    Note that for historical reasons, the Assert message lacks a 
    Holdtime field.  Thus changing the Assert Time from the default 
    value is not recommended.

Prune Timer (PT(S,G,I))
    Prune_Time - From message

    Prune Hold Time read from J/P message.

    Prune Hold Time corresponds to PIM MIB object 
    pimInterfaceJoinPruneInterval

Graft Retry Timer (GRT(S,G))
    Graft_Retry_Period - 3 sec

    In the absence of receipt of a Graft Ack message, the interval 
    between subsequent transmission of Graft messages.

Upstream Override Timer (OT(S,G))
    t_override - rand(0, 0.9 * J/P_Override_Interval)

    Randomized delay to prevent response implosion when sending a join 
    message to override another router’s prune message.

Prune Limit Timer (PLT(S,G))
    t_limit - Equal to the Holdtime of the Prune message

    Used to prevent Prune storms on a LAN.

7. Protocol Interaction Considerations

PIM-DM is designed to be independent of underlying unicast routing 
protocols and will interact only to the extent needed to perform RPF 
checks.  It is generally assumed that multicast area and autonomous 
system boundaries will correspond to the same boundaries for unicast 
routing, though a deployment which does not follow this assumption is 
not precluded by this specification.

In general, PIM-DM interactions with other multicast routing protocols 
should be in compliance with RFC 2715 [13].  Other specific 
interactions are noted below.

7.1. PIM-SM Interactions

PIM-DM is not intended to interact directly with PIM-SM, even though 
they share a common packet format.  It is particularly important to 
note that a router cannot differentiate between a PIM-DM neighbor and a 
PIM-SM neighbor based on Hello messages.

In the event that a PIM-DM router becomes a neighbor of a PIM-SM router 
they will effectively form a simplex link with the PIM-DM router 
sending all multicast messages to the PIM-SM router while the PIM-SM 
router sends no multicast messages to the PIM-DM router.

Adams, Nicholas, Siadak                                        [Page 29]

The common packet format permits a hybrid PIM-SM/DM implementation that 
would use PIM-SM when a rendezvous point is known and PIM-DM when one 
is not.  Such an implementation is outside the scope of this document.

7.2. IGMP Interactions

PIM-DM will forward received multicast data packets to neighboring host 
group members in all cases except when the PIM-DM router is in an 
Assert Loser state on that interface.  Note that a PIM Prune message is 
not permitted to prevent the delivery of messages to a network with 
group members.

7.3. Source Specific Multicast (SSM) Interactions

PIM-DM makes no special considerations for SSM [11].  All Prunes and 
Grafts within the protocol are for a specific source, so no additional 
checks need be made.

8. IANA Considerations

8.1. PIM Address Family

The PIM Address Family field was chosen to be 8 bits as a tradeoff 
between packet format and use of the IANA assigned numbers.  When the 
PIM packet format was designed, only 15 values were assigned for 
Address Families and large numbers of new Address Families were not 
envisioned, 8 bits seemed large enough.  However, the IANA assigns 
Address Families in a 16 bit value.  Therefore, the PIM Address Family 
is allocated as follows:

Values 0 through 127 are designated to have the same meaning as IANA 
assigned Address Family Numbers [6].

Values 128 through 250 are designated to be assigned by the IANA based 
upon IESG approval as defined in [7].

Values 251 through 255 are designated for Private Use, as defined in 
[7].

8.2. PIM Hello Options

Values 17 through 65000 are to be assigned by the IANA.  Since the 
space is large, they may be assigned as First Come First Served as 
defined in [7].  Such assignments are valid for one year, and may be 
renewed.  Permanent assignments require a specification as defined in 
[7].

9. Security Considerations

All PIM control messages MAY use IPsec [8] to address security 
concerns.  The authentication methods are addressed in a companion 
document [9].  Keys may be distributed as described in [10].

Adams, Nicholas, Siadak                                        [Page 30]

We should note that PIM-DM has no rendezvous point, and therefore no 
single point of failure that may be vulnerable.  However, since PIM-DM 
assumes that multicast messages are desired throughout the network, it 
may be particularly vulnerable to denial of service attacks.
It is further worth noting that because PIM-DM uses unicast routes 
provided by an unknown routing protocol, it may suffer collateral 
effects if the unicast routing protocol is attacked.

10. Authors' Addresses

Andrew Adams
NextHop Technologies
825 Victors Way, Suite 100
Ann Arbor, MI 48108-2738
[email-masked]

Jonathan Nicholas
ITT Aerospace/Communications Division
100 Kingsland Rd
Clifton, NJ  07014
[email-masked]

William Siadak
NextHop Technologies
825 Victors Way, Suite 100
Ann Arbor, MI 48108-2738
[email-masked]

11. Acknowledgments

The major features of PIM-DM were originally designed by Stephen 
Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy, 
David Meyer, and Liming Wei.  This revision was undertaken to 
incorporate some of the lessons learned during the evolution of the 
PIM-SM specification.

Thanks the PIM Working Group for their comments.

12. References

[1]     S.E. Deering,  "Multicast Routing in a Datagram Internetwork",  
        Ph.D. Thesis, Electrical Engineering Dept., Stanford University, 
        December 1991.
[2]	D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast 
        Routing Protocol", November 1988, RFC 1075
[3]	W. Fenner,  M. Handley, H.Holbrook, I. Kouvelas, "Protocol 
        Independent Multicast - Sparse Mode (PIM-SM)", 
        draft-ietf-pim-sm-v2-new-02.txt, work in progress.
[4]	S.E. Deering, "Host Extensions for IP Multicasting", August 1989, 
        RFC 1112.
[5]	W.Fenner, "Internet Group Management Protocol, Version 2", 
        November 1997, RFC 2236.
[6]	IANA, "Address Family Numbers", linked from 
        http://www.iana.org/numbers.html.
[7]	T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 
        Considerations Section in RFCs", RFC 2434.

Adams, Nicholas, Siadak                                        [Page 31]

[8]	S. Kent, R. Atkinson, "Security Architecture for the Internet 
        Protocol", RFC 2401.
[9]	L. Wei, "Authenticating PIM Version 2 Messages", draft-ietf-pim-
        v2-auth-01.txt, work in progress.
[10]	T. Hardjono, B. Cain, "Simple Key Management Protocol for PIM", 
        draft-ietf-pim-simplekmp-01.txt, work in progress.
[11]	H.Holbrook, B. Cain, "Source Specific Multicast for IP", draft-
        holbrook-ssm-00.txt, work in progress.
[12]	B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, 
        "Internet Group Management Protocol, Version 3", 
        draft-ietf-idmr-igmp-v3-07.txt, work in progress.
[13]	D. Thaler, "Interoperability Rules for Multicast Routing 
        Protocols", October 1999, RFC 2715
[14]	K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol 
        Independent Multicast MIB for IPv4", October 2000, RFC 2934

Adams, Nicholas, Siadak                                        [Page 32]

---

From: John Zwiebel <[email-masked]>
Date: Fri, 20 Jul 2001 11:50:23 -0700

Andrew Adams wrote:

This looks nice.  Unlike most folks, I do believe that
a requirement for dense-mode will develop.  I look forward
to going over your spec in more detail.

A couple of immediate observations...

One of the issues I don't see addressed though is the TTL problem
for expanding ring searches.  There is a problem in cisco's
where if a packet is received with a TTL of 1 and its
destination address isn't the router, that packet will have the TTL
decremented and thrown away.  This causes assert problems and 
duplicate traffic on the lan.  I'll grant you that this could
be considered a cisco specific problem, but I wouldn't be 
surprised to find it in other routers also.  I don't have
a "good" solution for the problem, but you may want to address it.

> state-refresh work. This draft doesn't yet incorporate that work.

FWIW: without state-refresh there's no need to look further into
this spec.  There are way too many protocol problems with the
periodic flooding of data to refresh state, resulting in long
blackholes of data and/or flooding of excessive data on to a lan.

Perhaps you intend to make the document "most useful" at sometime,
but, seriously, without state refresh dense-mode shouldn't be deployed.
(the only exception is in the case of a network that has a member on
every subnet, ie auto-rp, and this is a poor exception.)

>      More frequent Assert Negotiation.

Do state-refresh and the frequent assert problem goes away.

I've been working on PIM since Dino first coded it.  Dense-mode
without state-refresh is a non-starter.  

While I'm "on a role" (ie bitching), I'd also like to encourage
this group to require the source to ask for permission to send
to the network.  Every IETF the same discussion comes up about
how difficult it is to implement a protocol that allows the
source to just dump traffic on to the network and then expect the
routers to handle it.  I keep saying "CTS/RTS".  Then I'm told
the host vendors will take too long to incorporate such a change in
their OS so "its too hard".  Now 5 years later we still have the 
same stupid problem with customer's demanding that multicast
be more stable and that no data be lost.  That's impossible 
as long as the source can just dump traffic on to the net.

Of course, I can be accused of "just bitching", after all, if 
I thought it was so important, I'd write a draft myself.  :-)

---

From: John Zwiebel <[email-masked]>
Date: Fri, 20 Jul 2001 11:50:23 -0700

Andrew Adams wrote:

---

From: Beau Williamson <[email-masked]>
Date: Tue, 31 Jul 2001 08:49:41 -0500

>as long as the source can just dump traffic on to the net.

I agree with John on this although I don't think it has anything to do with PIM.  I'd like to see new MAGMA WG tackle this along with other issues of admission control of both receivers and senders.

Beau Williamson

---

From: Bryan Mclaughlin <[email-masked]>
Date: Tue, 31 Jul 2001 17:31:34 +0100

This issue is addressed by Multicast Source Notification of Interest 
Protocol (MSNIP)  for SM protocols,  isn't it ? What would need to be added 
to make it work for DM?

Bryan

At 08:49 31/07/2001 -0500, Beau Williamson wrote:
>I agree with John on this although I don't think it has anything to do 
>with PIM.  I'd like to see new MAGMA WG tackle this along with other 
>issues of admission control of both receivers and senders.
>
>Beau Williamson

---

From: John Zwiebel <[email-masked]>
Date: Tue, 31 Jul 2001 11:26:15 -0700

> Protocol (MSNIP)  for SM protocols,  isn't it ? What would need to be added

MSNIP does not do admission control.  It "kind of" does it, but
there's nothing that prevents a source from dumping mpackets on to the
LAN.
And MSNIP does not specifically address what a router should do if
it sees packets from a source that hasn't registered via MSNIP.
(one could make the leap that in such a case the router could just
bit bucket the data stream)

The host (source) is still "in charge" and the network has to muddle
through the best it can.  If a host is sending and there is no MSNIP
available, there's nothing to stop it.

The RTS/CTS process I'd like to see would make the network more 
"superior" to the host and is quite a bit more complicated than what
MSNIP is trying to provide.

I guess this sentence from the MSNIP draft makes my point:

     Hosts that wish to be managed by MSNIP periodically transmit an
     Interest Solicitation message. This message is multicast with a
group
     destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) and is
     transmitted every [Interest Solicitation Interval] seconds.  

  -- MSNIP is IGMPv3 only
  -- Hosts can arbitrarily decide to not be managed by MSNIP
  -- MSNIP does not describe how to signal the "network" that the
	source is about to send.

This shouldn't be taken as a condemnation of MSNIP.  Its quite 
possible my imagination just isn't strong enough to grasp the
capabilities.  And what I think is needed may be way too complicated
and contrary to the "spirit of the internet".

---

From: Hugh Holbrook <[email-masked]>
Date: Tue, 31 Jul 2001 15:58:41 -0700 (PDT)

Yes, your observations/interpretations of MSNIP are right on, John.

The information provided by MSNIP to the host is advisory and there is
no intent (at least on my part) to insist that all sources use MSNIP,
or to prevent sources from sending if they haven't received an MSNIP
Receiver Interest notification.  It is the routing protocol in use
determines what a router will do when it sees traffic even when MSNIP
is in use.  MSNIP does not impact the router's forwarding logic.

MSNIP is pretty much SSM-only.  (I'm pretty sure it would actually
work fine with MOSPF, too.)  Actually, MSNIP "works" with SM and DM
(as in, it doesn't break anything) -- it just doesn't add any value.

Adding support for DM or SM would require extending the Group Map
packet to include a "default" forwarding mode (forward/don't forward)
and would require adding some sort of "Receiver Prune" from the router
to the sender.  The thing that is probably the most exciting is that
when there are multiple routers on the LAN, they would all need to
agree that none of them have any downstream neighbors before sending a
"Receiver Prune" to the source.  This would need quite a bit of
mechanism in the protocol.  Another alternative might be to mandate
some kind of multicast router discovery in the host and merge prunes.
But this would always occur *after* the sender had sent traffic.  We
didn't sense much interest in MSNIP for DM/SM, and we deemed that the
possible benefit doesn't merit the added complexity.  I'd be
interested to hear arguments if anyone thinks this is compelling.

And no, we didn't consider a "Dear Router, I'm about to blast you with
traffic on group G" message at all.  As you suggest, it seems kind of
hard to imagine something like this that doesn't violate the
connectionless nature of IP.

-Hugh

> Date: Tue, 31 Jul 2001 11:26:15 -0700
> From: John Zwiebel <[email-masked]>
> 
> Bryan Mclaughlin wrote:
> >