tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7761

 
 
 

Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)

Part 6 of 7, p. 98 to 122
Prev RFC Part       Next RFC Part

 


prevText      Top      ToC       Page 98 
4.7.  PIM Bootstrap and RP Discovery

   For correct operation, every PIM router within a PIM domain must be
   able to map a particular multicast group address to the same RP.  If
   this is not the case, then black holes may appear, where some
   receivers in the domain cannot receive some groups.  A domain in this
   context is a contiguous set of routers that all implement PIM and are
   configured to operate within a common boundary.

   A notable exception to this is where a PIM domain is broken up into
   multiple administrative scope regions; these are regions where a
   border has been configured so that a range of multicast groups will
   not be forwarded across that border.  For more information on
   Administratively Scoped IP Multicast, see RFC 2365.  The modified
   criteria for admin-scoped regions are that the region is convex with
   respect to forwarding based on the MRIB, and that all PIM routers
   within the scope region map scoped groups to the same RP within that
   region.

   This specification does not mandate the use of a single mechanism to
   provide routers with the information to perform the group-to-RP
   mapping.  Currently, four mechanisms are possible, and all four have
   associated problems:

   Static Configuration
         A PIM router MUST support the static configuration of group-to-
         RP mappings.  Such a mechanism is not robust to failures but
         does at least provide a basic interoperability mechanism.

   Embedded-RP
         Embedded-RP defines an address allocation policy in which the
         address of the Rendezvous Point (RP) is encoded in an IPv6
         multicast group address [16].

Top      Up      ToC       Page 99 
   Cisco's Auto-RP
         Auto-RP uses a PIM Dense-Mode (PIM-DM) multicast group to
         announce group-to-RP mappings from a central location.  This
         mechanism is not useful if PIM Dense Mode is not being run in
         parallel with PIM Sparse Mode; it was only intended for use
         with PIM Sparse Mode Version 1.  No standard specification
         currently exists.

   Bootstrap Router (BSR)
         RFC 2362 specifies a bootstrap mechanism based on the automatic
         election of a BSR.  Any router in the domain that is configured
         to be a possible RP reports its candidacy to the BSR, and then
         a domain-wide flooding mechanism distributes the BSR's chosen
         set of RPs throughout the domain.  As specified in RFC 2362,
         the BSR mechanism is flawed in its handling of admin-scoped
         regions that are smaller than a PIM domain, but the mechanism
         does work for global-scoped groups.

   As far as PIM-SM is concerned, the only important requirement is that
   all routers in the domain (or admin scope zone for scoped regions)
   receive the same set of group-range-to-RP mappings.  This may be
   achieved through the use of any of these mechanisms, or through
   alternative mechanisms not currently specified.

   It must be operationally ensured that any RP address configured,
   learned, or advertised is reachable from all routers in the PIM
   domain.

4.7.1.  Group-to-RP Mapping

   Using one of the mechanisms described above, a PIM router receives
   one or more possible group-range-to-RP mappings.  Each mapping
   specifies a range of multicast groups (expressed as a group and mask)
   and the RP to which such groups should be mapped.  Each mapping may
   also have an associated priority.  It is possible to receive multiple
   mappings, all of which might match the same multicast group; this is
   the common case with the BSR mechanism.  The algorithm for performing
   the group-to-RP mapping is as follows:

   1.  Perform longest match on group range to obtain a list of RPs.

   2.  From this list of matching RPs, find the ones with highest
       priority.

       Eliminate any RPs from the list that have lower priorities.

Top      Up      ToC       Page 100 
   3.  If only one RP remains in the list, use that RP.

   4.  If multiple RPs are in the list, use the PIM hash function to
       choose one.

   Thus, if two or more group-range-to-RP mappings cover a particular
   group, the one with the longest mask is the mapping to use.  If the
   mappings have the same mask length, then the one with the highest
   priority is chosen.  If there is more than one matching entry with
   the same longest mask and the priorities are identical, then a hash
   function (see Section 4.7.2) is applied to choose the RP.

   This algorithm is invoked by a DR when it needs to determine an RP
   for a given group, e.g., upon reception of a packet or IGMP/MLD
   membership indication for a group for which the DR does not know
   the RP.

   Furthermore, the mapping function is invoked by all routers upon
   receiving a (*,G) Join/Prune message.

   Note that if the set of possible group-range-to-RP mappings changes,
   each router will need to check whether any existing groups are
   affected.  This may, for example, cause a DR or acting DR to re-join
   a group, or cause it to restart register encapsulation to the new RP.

      Implementation note: The bootstrap mechanism described in RFC 2362
      omitted step 1 above.  However, of the implementations we are
      aware of, approximately half performed step 1 anyway.  Note that
      implementations of BSR that omit step 1 will not correctly
      interoperate with implementations of this specification when used
      with the BSR mechanism described in [11].

4.7.2.  Hash Function

   The hash function is used by all routers within a domain, to map a
   group to one of the RPs from the matching set of group-range-to-RP
   mappings (this set of mappings all have the same longest mask length
   and same highest priority).  The algorithm takes as input the group
   address, and the addresses of the candidate RPs from the mappings,
   and gives as output one RP address to be used.

Top      Up      ToC       Page 101 
   The protocol requires that all routers hash to the same RP within a
   domain (except for transients).  The following hash function must be
   used in each router:

   1.  For RP addresses in the matching group-range-to-RP mappings,
       compute a value:

   Value(G,M,C(i))=
   (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31

       where C(i) is the RP address and M is a hash-mask.  If BSR is
       being used, the hash-mask is given in the Bootstrap messages.  If
       BSR is not being used, the alternative mechanism that supplies
       the group-range-to-RP mappings may supply the value, or else it
       defaults to a mask with the most significant 30 bits being one
       for IPv4 and the most significant 126 bits being one for IPv6.
       The hash-mask allows a small number of consecutive groups
       (e.g., 4) to always hash to the same RP.  For instance,
       hierarchically encoded data can be sent on consecutive group
       addresses to get the same delay and fate-sharing characteristics.

       For address families other than IPv4, a 32-bit digest to be used
       as C(i) and G must first be derived from the actual RP or group
       address.  Such a digest method must be used consistently
       throughout the PIM domain.  For IPv6 addresses, it is RECOMMENDED
       to use the equivalent IPv4 address for an IPv4-compatible
       address, and the exclusive-or of each 32-bit segment of the
       address for all other IPv6 addresses.  For example, the digest of
       the IPv6 address 3ffe:b00:c18:1::10 would be computed as
       0x3ffe0b00 ^ 0x0c180001 ^ 0x00000000 ^ 0x00000010,
       where the '^' symbol represents the exclusive-or operation.

   2.  The candidate RP with the highest resulting hash value is then
       the RP chosen by this hash function.  If more than one RP has the
       same highest hash value, the RP with the highest IP address is
       chosen.

4.8.  Source-Specific Multicast

   The Source-Specific Multicast (SSM) service model [6] can be
   implemented with a strict subset of the PIM-SM protocol mechanisms.
   Both regular IP Multicast and SSM semantics can coexist on a single
   router, and both can be implemented using the PIM-SM protocol.  A
   range of multicast addresses, currently 232.0.0.0/8 in IPv4 and
   ff3x::/32 for IPv6, is reserved for SSM, and the choice of semantics
   is determined by the multicast group address in both data packets and
   PIM messages.

Top      Up      ToC       Page 102 
4.8.1.  Protocol Modifications for SSM Destination Addresses

   The following rules override the normal PIM-SM behavior for a
   multicast address G in the SSM range:

   o  A router MUST NOT send a (*,G) Join/Prune message for any reason.

   o  A router MUST NOT send an (S,G,rpt) Join/Prune message for any
      reason.

   o  A router MUST NOT send a Register message for any packet that is
      destined to an SSM address.

   o  A router MUST NOT forward packets based on (*,G) or (S,G,rpt)
      state.  The (*,G)- and (S,G,rpt)-related state summarization
      macros are NULL for any SSM address, for the purposes of packet
      forwarding.

   o  A router acting as an RP MUST NOT forward any Register-
      encapsulated packet that has an SSM destination address and SHOULD
      respond with a Register-Stop message to such a Register message.

   o  A router MAY optimize out the creation and maintenance of
      (S,G,rpt) and (*,G) state for SSM destination addresses -- this
      state is not needed for SSM packets.

   The last three rules are present to deal with SSM-unaware "legacy"
   routers that may be sending (*,G) and (S,G,rpt) Join/Prunes, or
   Register messages for SSM destination addresses.  Note that this
   specification does not attempt to aid an SSM-unaware "legacy" router
   with SSM operations.

4.8.2.  PIM-SSM-Only Routers

   An implementer may choose to implement only the subset of PIM
   Sparse Mode that provides SSM forwarding semantics.

   A PIM-SSM-only router MUST implement the following portions of this
   specification:

   o  Upstream (S,G) state machine (Section 4.5.5)

   o  Downstream (S,G) state machine (Section 4.5.2)

   o  (S,G) Assert state machine (Section 4.6.1)

Top      Up      ToC       Page 103 
   o  Hello messages, neighbor discovery, and DR election (Section 4.3)

   o  Packet forwarding rules (Section 4.2)

   A PIM-SSM-only router does not need to implement the following
   protocol elements:

   o  Register state machine (Section 4.4)

   o  (*,G) and (S,G,rpt) downstream state machines (Sections 4.5.1 and
      4.5.3)

   o  (*,G) and (S,G,rpt) upstream state machines (Sections 4.5.4,
      4.5.6, and 4.5.7)

   o  (*,G) Assert state machine (Section 4.6.2)

   o  Bootstrap RP election (Section 4.7)

   o  Keepalive Timer

   o  SPTbit (Section 4.2.2)

   The Keepalive Timer should be treated as always running, and the
   SPTbit should be treated as always being set for an SSM address.
   Additionally, the packet forwarding rules of Section 4.2 can be
   simplified in a PIM-SSM-only router:

     oiflist = NULL

     if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
         oiflist = inherited_olist(S,G)
     } else if( iif is in inherited_olist(S,G) ) {
         send Assert(S,G) on iif
     }

     oiflist = oiflist (-) iif
     forward packet on all interfaces in oiflist

   This is nothing more than the reduction of the normal PIM-SM
   forwarding rule, with all (S,G,rpt) and (*,G) clauses replaced
   with NULL.

Top      Up      ToC       Page 104 
4.9.  PIM Packet Formats

   This section describes the details of the packet formats for PIM
   control messages.

   All PIM control messages have IP protocol number 103.

   PIM messages are either unicast (e.g., Registers and Register-Stop)
   or multicast with TTL 1 to the 'ALL-PIM-ROUTERS' group (e.g.,
   Join/Prune, Asserts).  The source address used for unicast messages
   is a domain-wide reachable address; the source address used for
   multicast messages is the link-local address of the interface on
   which the message is being sent.

   The IPv4 'ALL-PIM-ROUTERS' group is '224.0.0.13'.  The IPv6
   'ALL-PIM-ROUTERS' group is 'ff02::d'.

   The PIM header common to all PIM messages is:

    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.  PIM Types are:

   Message Type                          Destination
   ---------------------------------------------------------------------
   0 = Hello                             Multicast to ALL-PIM-ROUTERS
   1 = Register                          Unicast to RP
   2 = Register-Stop                     Unicast to source of Register
                                            packet
   3 = Join/Prune                        Multicast to ALL-PIM-ROUTERS
   4 = Bootstrap                         Multicast to ALL-PIM-ROUTERS
   5 = Assert                            Multicast to ALL-PIM-ROUTERS
   6 = Graft (used in PIM-DM only)       Unicast to RPF'(S)
   7 = Graft-Ack (used in PIM-DM only)   Unicast to source of Graft
                                            packet
   8 = Candidate-RP-Advertisement        Unicast to Domain's BSR

Top      Up      ToC       Page 105 
   Reserved
         Set to zero on transmission.  Ignored upon receipt.

   Checksum
         The checksum is a standard IP checksum, i.e., the 16-bit one's
         complement of the one's complement sum of the entire PIM
         message, excluding the "Multicast data packet" section of the
         Register message.  For computing the checksum, the checksum
         field is zeroed.  If the packet's length is not an integral
         number of 16-bit words, the packet is padded with a trailing
         byte of zero before performing the checksum.

         For IPv6, the checksum also includes the IPv6 "pseudo-header",
         as specified in RFC 2460, Section 8.1 [5].  This
         "pseudo-header" is prepended to the PIM header for the purposes
         of calculating the checksum.  The "Upper-Layer Packet Length"
         in the pseudo-header is set to the length of the PIM message,
         except in Register messages where it is set to the length of
         the PIM register header (8).  The Next Header value used in the
         pseudo-header is 103.

   If a message is received with an unrecognized PIM Ver or Type field,
   or if a message's destination does not correspond to the table above,
   the message MUST be discarded, and an error message SHOULD be logged
   to the administrator in a rate-limited manner.

4.9.1.  Encoded Source and Group Address Formats

   Encoded Unicast Address

   An encoded unicast address takes 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 0-127 are as assigned by the IANA for Internet Address
         Families in [7].  Values 128-250 are reserved to be assigned by
         the IANA for PIM-specific Address Families.  Values 251 through
         255 are designated for Private Use.  As there is no assignment
         authority for this space, collisions should be expected.

Top      Up      ToC       Page 106 
   Encoding Type
         The type of encoding used within 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.

   Encoded Group Address

   Encoded group addresses take 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 |B| Reserved  |Z|  Mask Len     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Group multicast Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   Addr Family
         Described above.

   Encoding Type
         Described above.

   [B]idirectional PIM
         Indicates that the group range uses Bidirectional PIM [13].
         For PIM-SM as defined in this specification, this bit MUST be
         zero.

   Reserved
         Transmitted as zero.  Ignored upon receipt.

   Admin Scope [Z]one
         Indicates that the group range is an admin scope zone.  This is
         used in the Bootstrap Router mechanism [11] only.  For all
         other purposes, this bit is set to zero and ignored on receipt.

Top      Up      ToC       Page 107 
   Mask Len
         The Mask length field is 8 bits.  The value is the number of
         contiguous one bits that are left-justified and used as a mask;
         when combined with the group address, it describes a range of
         groups.  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 group, then the Mask length must equal the
         address length in bits for the given Address Family and
         Encoding Type (e.g., 32 for IPv4 native encoding, 128 for IPv6
         native encoding).

   Group multicast Address
         Contains the group address.

   Encoded Source Address

   An encoded source address takes 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
         Described above.

   Encoding Type
         Described above.

   Reserved
         Transmitted as zero, ignored on receipt.

   S     The Sparse bit is a 1-bit value, set to 1 for PIM-SM.  It is
         used for PIM Version 1 compatibility.

   W     The WC (or WildCard) bit is a 1-bit value for use with PIM
         Join/Prune messages (see Section 4.9.5.1).

   R     The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use
         with PIM Join/Prune messages (see Section 4.9.5.1).  If the
         WC bit is 1, the RPT bit MUST be 1.

Top      Up      ToC       Page 108 
   Mask Len
         The mask length field is 8 bits.  The value is the number of
         contiguous one bits that are left-justified and used as a mask;
         when combined with the source address, it describes a source
         subnet.  The mask length MUST be equal to the mask length in
         bits for the given Address Family and Encoding Type (32 for
         IPv4 native and 128 for IPv6 native).  A router SHOULD ignore
         any messages received with any other mask length.

   Source Address
         The source address.

4.9.2.  Hello Message Format

   A Hello message is sent periodically by routers on all interfaces.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          OptionType           |         OptionLength          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          OptionValue                          |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          OptionType           |         OptionLength          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          OptionValue                          |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Version, Type, Reserved, Checksum
         Described in Section 4.9.

   OptionType
         The type of the option given in the following OptionValue
         field.

   OptionLength
         The length of the OptionValue field in bytes.

   OptionValue
         A variable-length field, carrying the value of the option.

Top      Up      ToC       Page 109 
   The Option fields may contain the following values:

   o  OptionType 1: Holdtime

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 1             |         Length = 2            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Holdtime             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Holdtime is the amount of time a receiver must keep the neighbor
      reachable, in seconds.  If the Holdtime is set to '0xffff', the
      receiver of this message never times out the neighbor.  This may
      be used with dial-on-demand links, to avoid keeping the link up
      with periodic Hello messages.

      An implementation MAY provide a configuration mechanism to reject
      a Hello message with holdtime 0xffff, and/or provide a mechanism
      to remove a neighbor.

      Hello messages with a Holdtime value set to '0' are also sent by a
      router on an interface about to go down or changing IP address
      (see Section 4.3.1).  These are effectively goodbye messages, and
      the receiving routers SHOULD immediately time out the neighbor
      information for the sender.

   o  OptionType 2: LAN Prune Delay

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 2             |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|      Propagation_Delay      |      Override_Interval        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The LAN Prune Delay option is used to tune the prune propagation
      delay on multi-access LANs.  The T bit specifies the ability of
      the sending router to disable Join suppression.  Propagation_Delay
      and Override_Interval are time intervals in units of milliseconds.
      A router originating a LAN Prune Delay option on interface I sets
      the Propagation_Delay field to the configured value of
      Propagation_Delay(I) and the value of the Override_Interval field
      to the value of Override_Interval(I).  On a receiving router, the
      values of the fields are used to tune the value of the
      Effective_Override_Interval(I) and its derived timer values.

Top      Up      ToC       Page 110 
      Section 4.3.3 describes how these values affect the behavior of a
      router.

   o  OptionTypes 3 through 16: Reserved; to be defined in future
      versions of this document.

   o  OptionType 18: Deprecated and should not be used.

   o  OptionType 19: DR Priority

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 19            |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         DR Priority                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      DR Priority is a 32-bit unsigned number and should be considered
      in the DR election as described in Section 4.3.2.

   o  OptionType 20: Generation ID

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 20            |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Generation ID                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Generation ID is a random 32-bit 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.

Top      Up      ToC       Page 111 
   o  OptionType 24: Address List

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 24            |      Length = <Variable>      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Secondary Address 1 (Encoded-Unicast format)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Secondary Address N (Encoded-Unicast format)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The contents of the Address List Hello option are described in
      Section 4.3.4.  All addresses within a single Address List must
      belong to the same address family.

   OptionTypes 17 through 65000 are assigned by the IANA.
   OptionTypes 65001 through 65535 are reserved for Private Use,
   as defined in [9].

   Unknown options MUST be ignored and MUST NOT prevent a neighbor
   relationship from being formed.  The Holdtime option MUST be
   implemented; the DR Priority and Generation ID options SHOULD be
   implemented.  The Address List option MUST be implemented for IPv6.

4.9.3.  Register Message Format

   A Register message is sent by the DR to the RP when a multicast
   packet needs to be transmitted on the RP-tree.  The IP source address
   is set to the address of the DR, the destination address to the RP's
   address.  The IP TTL of the PIM packet is the system's normal
   unicast TTL.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |B|N|                       Reserved2                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                     Multicast data packet                     .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 112 
   PIM Version, Type, Reserved, Checksum
         Described in Section 4.9.  Note that in order to reduce
         encapsulation overhead, the checksum for Registers is done only
         on the first 8 bytes of the packet, including the PIM header
         and the next 4 bytes, excluding the data packet portion.  For
         interoperability reasons, a message carrying a checksum
         calculated over the entire PIM Register message should also be
         accepted.  When calculating the checksum, the IPv6
         pseudo-header "Upper-Layer Packet Length" is set to 8.

   B     The Border bit.  This specification deprecates the Border bit.
         A router MUST set the B bit to 0 on transmission and MUST
         ignore this bit on reception.

   N     The Null-Register bit.  Set to 1 by a DR that is probing the RP
         before expiring its local Register-Suppression Timer.  Set to 0
         otherwise.

   Reserved2
         Transmitted as zero, ignored on receipt.

   Multicast data packet
         The original packet sent by the source.  This packet must be of
         the same address family as the encapsulating PIM packet, e.g.,
         an IPv6 data packet must be encapsulated in an IPv6 PIM packet.
         Note that the TTL of the original packet is decremented before
         encapsulation, just like any other packet that is forwarded.
         In addition, the RP decrements the TTL after decapsulating,
         before forwarding the packet down the shared tree.

         For (S,G) Null-Registers, the Multicast data packet portion
         contains a dummy IP header with S as the source address
         and G as the destination address.  When generating an IPv4
         Null-Register message, the fields in the dummy IPv4 header
         SHOULD be filled in according to the following table.  Other
         IPv4 header fields may contain any value that is valid for
         that field.

         Field                  Value
         ---------------------------------------
         IP Version             4
         Header Length          5
         Checksum               Header checksum
         Fragmentation offset   0
         More Fragments         0
         Total Length           20
         IP Protocol            103 (PIM)

Top      Up      ToC       Page 113 
         On receipt of an (S,G) Null-Register, if the Header Checksum
         field is non-zero, the recipient SHOULD check the checksum and
         discard Null-Registers that have a bad checksum.  The recipient
         SHOULD NOT check the value of any individual fields; a correct
         IP header checksum is sufficient.  If the Header Checksum field
         is zero, the recipient MUST NOT check the checksum.

         With IPv6, an implementation generates a dummy IP header
         followed by a dummy PIM header with values according to the
         following table in addition to the source and group.  Other
         IPv6 header fields may contain any value that is valid for that
         field.

         Header Field   Value
         --------------------------------------
         IP Version     6
         Next Header    103 (PIM)
         Length         4
         PIM Version    0
         PIM Type       0
         PIM Reserved   0
         PIM Checksum   PIM checksum, including
                        IPv6 "pseudo-header";
                        see Section 4.9

         On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM
         header is present, the recipient SHOULD check the checksum and
         discard Null-Registers that have a bad checksum.

4.9.4.  Register-Stop Message Format

   A Register-Stop is unicast from the RP to the sender of the Register
   message.  The IP source address is the address to which the register
   was addressed.  The IP destination address is the source address of
   the register message.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Group Address (Encoded-Group format)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Address (Encoded-Unicast format)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 114 
   PIM Version, Type, Reserved, Checksum
         Described in Section 4.9.

   Group Address
         The group address from the multicast data packet in the
         Register.  The format for this address is described in
         Section 4.9.1.  Note that for Register-Stops the Mask Len field
         contains the full address length * 8 (e.g., 32 for IPv4 native
         encoding), if the message is sent for a single group.

   Source Address
         The host address of the source from the multicast data packet
         in the register.  The format for this address is given in the
         encoded unicast address in Section 4.9.1.  A special wildcard
         value consisting of an address field of all zeros can be used
         to indicate any source.

4.9.5.  Join/Prune Message Format

   A Join/Prune message is sent by routers towards upstream sources and
   RPs.  Joins are sent to build shared trees (RP trees) or source trees
   (SPT).  Prunes are sent to prune source trees when members leave
   groups as well as sources that do not use the shared tree.

Top      Up      ToC       Page 115 
    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    |          Holdtime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         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)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Joined Source Address n (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Pruned Source Address 1 (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Pruned Source Address n (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 116 
   PIM Version, Type, Reserved, Checksum
         Described in Section 4.9.

   Unicast Upstream Neighbor Address
         The primary address of the upstream neighbor that is the target
         of the message.  The format for this address is given in the
         encoded unicast address in Section 4.9.1.

   Reserved
         Transmitted as zero, ignored on receipt.

   Holdtime
         The amount of time a receiver MUST keep the Join/Prune state
         alive, in seconds.  If the Holdtime is set to '0xffff', the
         receiver of this message SHOULD hold the state until canceled
         by the appropriate canceling Join/Prune message, or timed out
         according to local policy.  This may be used with dial-on-
         demand links, to avoid keeping the link up with periodic
         Join/Prune messages.

         Note that the HoldTime MUST be larger than the
         J/P_Override_Interval(I).

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

   Multicast group address
         For format description, see Section 4.9.1.

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

   Joined Source Address 1 .. n
         This list contains the sources for a given group that the
         sending router will forward multicast datagrams from if
         received on the interface on which the Join/Prune message
         is sent.

         See Section 4.9.1 for the format description for the
         encoded source address.

   Number of Pruned Sources
         Number of pruned source addresses listed for a group.

Top      Up      ToC       Page 117 
   Pruned Source Address 1 .. n
         This list contains the sources for a given group that the
         sending router does not want to forward multicast datagrams
         from when received on the interface on which the Join/Prune
         message is sent.

   Within one PIM Join/Prune message, all the Multicast Group addresses,
   Joined Source addresses, and Pruned Source addresses MUST be of the
   same address family.  It is NOT PERMITTED to mix IPv4 and IPv6
   addresses within the same message.  In addition, the address family
   of the fields in the message SHOULD be the same as the IP source and
   destination addresses of the packet.  This permits maximum
   implementation flexibility for dual-stack IPv4/IPv6 routers.  If a
   router receives a message with mixed family addresses, it SHOULD only
   process the addresses that are of the same family as the unicast
   upstream neighbor address.

4.9.5.1.  Group Set Source List Rules

   As described above, Join/Prune messages are composed of one or more
   group sets.  Each set contains two source lists: the Joined Sources
   and the Pruned Sources.  This section describes the different types
   of group sets and source list entries that can exist in a Join/Prune
   message.

   There is one valid group set type:

   Group-Specific Set
         A Group-Specific Set is represented by a valid IP multicast
         address in the group address field and the full length of the
         IP address in the mask length field of the Multicast Group
         Address.  Each Join/Prune message SHOULD NOT contain more than
         one group-specific set for the same IP multicast address.  Each
         group-specific set may contain (*,G), (S,G,rpt), and (S,G)
         source list entries in the Joined or Pruned lists.

      (*,G)
            The (*,G) source list entry is used in Join/Prune messages
            sent towards the RP for the specified group.  It expresses
            interest (or lack thereof) in receiving traffic sent to the
            group through the RP shared tree.  There MUST only be one
            such entry in both the Joined and Pruned lists of a group-
            specific set.

            (*,G) source list entries have the Source-Address set to the
            address of the RP for group G, the Source-Address Mask-Len
            set to the full length of the IP address, and both the WC
            and RPT bits of the encoded-source-address set.

Top      Up      ToC       Page 118 
      (S,G,rpt)
            The (S,G,rpt) source list entry is used in Join/Prune
            messages sent towards the RP for the specified group.  It
            expresses interest (or lack thereof) in receiving traffic
            through the shared tree sent by the specified source to this
            group.  For each source address, the entry MUST exist in
            only one of the Joined and Pruned source lists of a group-
            specific set, but not both.

            (S,G,rpt) source list entries have the Source-Address set to
            the address of the source S, the Source-Address Mask-Len set
            to the full length of the IP address, and the WC bit cleared
            and the RPT bit set in the encoded source address.

      (S,G)
            The (S,G) source list entry is used in Join/Prune messages
            sent towards the specified source.  It expresses interest
            (or lack thereof) in receiving traffic through the shortest
            path tree sent by the source to the specified group.  For
            each source address, the entry MUST exist in only one of the
            Joined and Pruned source lists of a group-specific set, but
            not both.

            (S,G) source list entries have the Source-Address set to the
            address of the source S, the Source-Address Mask-Len set to
            the full length of the IP address, and both the WC and RPT
            bits of the encoded source address cleared.

   The rules described above are sufficient to prevent invalid
   combinations of source list entries in group-specific sets.  There
   are, however, a number of combinations that have a valid
   interpretation but that are not generated by the protocol as
   described in this specification:

   o  Combining a (*,G) Join and an (S,G,rpt) Join entry in the same
      message is redundant, as the (*,G) entry covers the information
      provided by the (S,G,rpt) entry.

   o  The same applies for a (*,G) Prune and an (S,G,rpt) Prune.

   o  The combination of a (*,G) Prune and an (S,G,rpt) Join is also not
      generated.  (S,G,rpt) Joins are only sent when the router is
      receiving all traffic for a group on the shared tree and it wishes
      to indicate a change for the particular source.  As a (*,G) prune
      indicates that the router no longer wishes to receive shared tree
      traffic, the (S,G,rpt) Join would be meaningless.

Top      Up      ToC       Page 119 
   o  As Join/Prune messages are targeted to a single PIM neighbor,
      including both an (S,G) Join and an (S,G,rpt) Prune in the same
      message is usually redundant.  The (S,G) Join informs the neighbor
      that the sender wishes to receive the particular source on the
      shortest path tree.  It is therefore unnecessary for the router to
      say that it no longer wishes to receive it on the shared tree.
      However, there is a valid interpretation for this combination of
      entries.  A downstream router may have to instruct its upstream
      only to start forwarding a specific source once it has started
      receiving the source on the shortest-path tree.

   o  The combination of an (S,G) Prune and an (S,G,rpt) Join could
      possibly be used by a router to switch from receiving a particular
      source on the shortest-path tree back to receiving it on the
      shared tree (provided that the RPF neighbor for the shortest-path
      and shared trees is common).  However, Sparse-Mode PIM does not
      provide a mechanism for explicitly switching back to the shared
      tree.

   The rules are summarized in the table below.

   +----------++------+-------+-----------+-----------+-------+-------+
   |          ||Join  | Prune | Join      | Prune     | Join  | Prune |
   |          ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Join      ||-     | no    | ?         | yes       | yes   | yes   |
   |(*,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Prune     ||no    | -     | ?         | ?         | yes   | yes   |
   |(*,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Join      ||?     | ?     | -         | no        | yes   | ?     |
   |(S,G,rpt) ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Prune     ||yes   | ?     | no        | -         | yes   | ?     |
   |(S,G,rpt) ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Join      ||yes   | yes   | yes       | yes       | -     | no    |
   |(S,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Prune     ||yes   | yes   | ?         | ?         | no    | -     |
   |(S,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+

Top      Up      ToC       Page 120 
   yes   Allowed and expected.

   no    Combination is not allowed by the protocol and MUST NOT be
         generated by a router.  A router MAY accept these messages, but
         the result is undefined.  An error message MAY be logged to the
         administrator in a rate-limited manner.

   ?     Combination not expected by the protocol, but well defined.  A
         router MAY accept it but SHOULD NOT generate it.

   The order of source list entries in a group set source list is not
   important, except where limited by the packet format itself.

4.9.5.2.  Group Set Fragmentation

   When building a Join/Prune for a particular neighbor, a router should
   try to include in the message as much of the information it needs to
   convey to the neighbor as possible.  This implies adding one group
   set for each multicast group that has information pending
   transmission and within each set including all relevant source list
   entries.

   On a router with a large amount of multicast state, the number of
   entries that must be included may result in packets that are larger
   than the maximum IP packet size.  In most such cases, the information
   may be split into multiple messages.

   There is an exception with group sets that contain a (*,G) Joined
   source list entry.  The group set expresses the router's interest in
   receiving all traffic for the specified group on the shared tree, and
   it MUST include an (S,G,rpt) Pruned source list entry for every
   source that the router does not wish to receive.  This list of
   (S,G,rpt) Pruned source list entries MUST NOT be split in multiple
   messages.

   If only N (S,G,rpt) Prune entries fit into a maximum-sized Join/Prune
   message, but the router has more than N (S,G,rpt) Prunes to add, then
   the router MUST choose to include the first N (numerically smallest
   in network byte order) IP addresses, and the rest are ignored (not
   included).

Top      Up      ToC       Page 121 
4.9.6.  Assert Message Format

   The Assert message is used to resolve forwarder conflicts between
   routers on a link.  It is sent when a router receives a multicast
   data packet on an interface on which the router would normally have
   forwarded that packet.  Assert messages may also be sent in response
   to an Assert message from another router.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Group Address (Encoded-Group format)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Address (Encoded-Unicast format)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                      Metric Preference                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Version, Type, Reserved, Checksum
         Described in Section 4.9.

   Group Address
         The group address for which the router wishes to resolve the
         forwarding conflict.  This is an encoded group address, as
         specified in Section 4.9.1.

   Source Address
         Source address for which the router wishes to resolve the
         forwarding conflict.  The source address MAY be set to zero for
         (*,G) asserts (see below).  The format for this address is
         given in the encoded unicast address in Section 4.9.1.

   R     RPTbit is a 1-bit value.  The RPTbit is set to 1 for
         Assert(*,G) messages and 0 for Assert(S,G) messages.

   Metric Preference
         Preference value assigned to the unicast routing protocol that
         provided the route to the multicast source or Rendezvous Point.

   Metric
         The unicast routing table metric associated with the route used
         to reach the multicast source or Rendezvous Point.  The metric
         is in units applicable to the unicast routing protocol used.

Top      Up      ToC       Page 122 
   Assert messages can be sent to resolve a forwarding conflict for all
   traffic to a given group or for a specific source and group.

   Assert(S,G)
         Source-specific asserts are sent by routers forwarding a
         specific source on the shortest-path tree (SPTbit is TRUE).
         (S,G) Asserts have the Group-Address field set to the group G
         and the Source-Address field set to the source S.  The RPTbit
         is set to 0, the Metric-Preference is set to MRIB.pref(S), and
         the Metric is set to MRIB.metric(S).

   Assert(*,G)
         Group-specific asserts are sent by routers forwarding data for
         the group and source(s) under contention on the shared tree.
         (*,G) asserts have the Group-Address field set to the group G.
         For data-triggered Asserts, the Source-Address field MAY be set
         to the IP source address of the data packet that triggered the
         Assert and is set to zero otherwise.  The RPTbit is set to 1,
         the Metric-Preference is set to MRIB.pref(RP(G)), and the
         Metric is set to MRIB.metric(RP(G)).



(page 122 continued on part 7)

Next RFC Part