tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2117

 
 
 

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

Part 3 of 3, p. 42 to 66
Prev RFC Part

 


prevText      Top       Page 42 
3.9 Summary of flags used

   Following is a summary of all the flags used in our scheme.

Bit           |  Used in    |  Definition

Authoritative | C-RP-Adv    | Group-prefix information should not be
                              over-ridden by BSR
Border        | Register    | Register for external sources is coming
                              from PIM multicast border router
Null          | Register    | Register sent as Probe of RP, the
                              encapsulated IP data packet should not
                              be forwarded
RPT           | Route entry | Entry represents state on the RP-tree
RPT           | Join/Prune  | Join is associated with the shared tree
                              and therefore the Join/Prune message is
                              propagated along the RP-tree (source
                              encoded is an RP address)
RPT           | Assert      | The data packet was routed down the shared
                              tree; thus, the path indicated corresponds
                              to the RP tree
SPT           | (S,G) entry | Packets have arrived on the iif towards S,
                              and the iif is different from the (*,G)
                              iif
WC            |Join         | The receiver expects to receive packets
                              from all sources via this (shared tree)
                              path. Thus, the Join/Prune applies to a
                              (*,G) entry
WC            | Route entry | Wildcard entry; if there is no more
                              specific match for a particular source,
                              packets will be forwarded according to
                              this entry


3.10 Security

   All PIM control messages may use IPSec [6] to address security
   concerns.

4 Packet Formats

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

   All PIM control messages have protocol number 103.

Top       Page 43 
   Basically, PIM messages are either unicast (e.g.  Registers and
   Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' group
   `224.0.0.13' (e.g. Join/Prune, Asserts, etc.).

    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  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   PIM Ver
         PIM Version number is 2.

   Type  Types for specific PIM messages.  PIM Types are:

      0 = Hello
      1 = Register
      2 = Register-Stop
      3 = Join/Prune
      4 = Bootstrap
      5 = Assert
      6 = Graft (used in PIM-DM only)
      7 = Graft-Ack (used in PIM-DM only)
      8 = Candidate-RP-Advertisement

   Addr length
         Address length in bytes.  Throughout this section this
         would indicate the number of bytes in the Address field of
         an address, including unicast and group addresses.

   Checksum
         The checksum is the 16-bit one's complement of  the  one's
         complement  sum  of  the entire PIM message, (excluding the
         data portion in the Register message).  For  computing  the
         checksum, the checksum field is zeroed.

4.1 Encoded Source and Group Address formats

   1    Unicast address: Only the address is included.  The length
        of the unicast address in bytes is specified in the `Addr
        length' field in the header.

   2    Encoded-Group-Address: Takes the following format:

Top       Page 44 
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Reserved  |  Mask Len     | Group multicast Address ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...Group multicast Address ...|
   +-+-+-+-+-+-+-+-+-+-+~+~+~+~+~+~+


        Reserved
              Transmitted as zero. Ignored upon receipt.

        Mask Length
              The Mask length is 8 bits. The value is the number of
              contiguous bits left justified used as a mask which
              describes the address. It is less than or equal to
              Addr length * 8. If the message is sent for a single
              group then the Mask length must equal Addr length * 8
              (i.e. 32 for IPv4 and 128 for IPv6).

        Group multicast Address
              contains the group address, and has number of bytes
              equal to that specified in the Addr length field.

   3    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rsrvd   |S|W|R|  Mask Len     | Source Address ...            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ...  Source Address          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+-+


        Reserved
              Transmitted as zero, ignored on receipt.

        S,W,R See Section 4.5 for details.

Top       Page 45 
        Mask Length
              Mask length is 8 bits. The value is the number of
              contiguous bits left justified used as a mask which
              describes the address. The mask length must be less
              than or equal to Addr Length * 8. If the message is
              sent for a single source then the Mask length must
              equal Addr length * 8.  In version 2 of PIM, it is
              strongly recommended that this field be set to 32 for
              IPv4.

        Source Address
              The address length is indicated from the Addr length
              field at the beginning of the header. For IPv4, the
              address length is 4 octets.

4.2 Hello Message

   It 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  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OptionType              |         OptionLength          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          OptionValue                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+
   |                               .                               |
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OptionType              |         OptionLength          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          OptionValue                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+


   PIM Version, Type, Addr length, Checksum
         Described above.

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

   OptionLength
         The length of the OptionValue field in bytes.

Top       Page 46 
   OptionValue
         A variable length field, carrying the value of the option.

   The Option fields may contain the following values:

   *    OptionType = 1; OptionLength = 2; OptionValue = Holdtime;
        where 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 ISDN lines, to avoid
        keeping the link up with periodic Hello messages.
        Furthermore, if the Holdtime is set to `0', the information
        is timed out immediately.

   *    OptionType 2 to 16: reserved

   *    The rest of the OptionTypes are defined in another
        document.

   In general, options may be ignored; but a router must not ignore the
   'Holdtime' OptionType.

4.3 Register Message

   A Register message is sent by the DR or a PMBR to the RP when a
   multicast packet needs to be transmitted on the RP-tree. Source IP
   address is set to the address of the DR, destination IP address is to
   the RP's address.


   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  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |B|N|                       Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Multicast data packet                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   PIM Version, Type, Addr length, Checksum
        Described above.  {Note that the checksum for Registers
        is done only on the PIM header, excluding the data packet
        portion.}

Top       Page 47 
   B     The Border bit. If the router is a DR for a source that it
         is directly connected to, it sets the B bit to 0. If the
         router is a PMBR for a source in a directly connected
         cloud, it sets the B bit to 1.

   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.

   Multicast data packet
         The original packet sent by the source.

   For (S,G) null Registers, the Multicast data packet portion contains
   only a dummy IP header with S as the source address, G as the
   destination address, and a data length of zero.

4.4 Register-Stop Message

   A Register-Stop is unicast from the RP  to  the  sender  of  the
   Register  message. Source IP address is the address to which the
   register was addressed. Destination IP  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  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Encoded-Group Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Unicast-Source Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   PIM Version, Type, Addr length, Checksum
         Described above.

   Encoded-Group Address
         Format described above. Note that for Register-Stops the
         Mask Len field contains Addr length * 8 (32 for IPv4), if
         the message is sent for a single group.

   Unicast-Source Address
         IP host address of source from multicast data packet in
         register. The length of this field in bytes is specified in
         the Addr length field. A special wild card value (0.0.0.0),
         can be used to indicate any source.

Top       Page 48 
4.5 Join/Prune Message

   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       Page 49 
    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  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Unicast-Upstream Neighbor Address                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reserved     | Num groups    |          Holdtime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Encoded-Multicast Group Address-1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Joined  Sources   |   Number of Pruned Sources    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Joined Source Address-1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Joined Source Address-n                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Pruned Source Address-1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Pruned Source Address-n                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           .                                   |
   |                           .                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Encoded-Multicast Group Address-n              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Joined  Sources   |   Number of Pruned Sources    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Joined Source Address-1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Joined Source Address-n                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Pruned Source Address-1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Encoded-Pruned Source Address-n                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top       Page 50 
   PIM Version, Type, Addr length, Checksum
         Described above.

   Upstream Neighbor Address
         The IP address of the RPF or upstream neighbor.

   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 never times out the
         oif. This may be used with ISDN lines, to avoid keeping the
         link up with periodical Join/Prune messages.  Furthermore,
         if the Holdtime is set to `0', the information is timed out
         immediately.

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

   Encoded-Multicast group address
         For format description see Section
         4.1. A wild card group in the (*,*,RP) join is represented
         by a 224.0.0.0 in the group address field and `4' in the
         mask length field. A (*,*,RP) join also has the WC-bit and
         the RPT-bit set.

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

   Join Source Address-1 .. n
         This list contains the sources that the sending router
         will forward multicast datagrams for if received on the
         interface this message is sent on.

         See format section 4.1. The fields explanation for the
         Encoded-Source-Address format follows:


        Reserved
              Described above.

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

Top       Page 51 
        W     The WC bit is a 1 bit value. If 1, the join or prune
              applies to the (*,G) or (*,*,RP) entry. If 0, the join
              or prune applies to the (S,G) entry where S is Source
              Address.  Joins and prunes sent towards the RP must
              have this bit set.

        R     The RPT-bit is a 1 bit value. If 1, the information
              about (S,G) is sent towards the RP.  If 0, the
              information must be sent toward S, where S is the
              Source Address.

        Mask Length, Source Address
              Described above.


        Represented in the form of < WC-bit >< RPT-bit > < Mask length
        ><Source address>:

        A source address could be a host IP address :

         < 0 >< 0 >< 32 >< 192.1.1.17 >

        A source address could be the RP's IP address :

         < 1 >< 1 >< 32 >< 131.108.13.111 >

        A source address could be a subnet address to prune from the
        RP-tree :

         < 0 >< 1 >< 28 >< 192.1.1.16 >

        A source address could be a general aggregate :

         < 0 >< 0 >< 16 >< 192.1.0.0 >

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

   Prune Source Address-1 .. n
         This list contains the sources that the sending router
         does not want to forward multicast datagrams for when
         received on the interface this message is sent on.  If the
         Join/Prune message boundary exceeds the maximum packet
         size, then the join and prune lists for the same group must
         be included in the same packet.

Top       Page 52 
4.6 Bootstrap Message

   The Bootstrap messages are multicast to `ALL-PIM-ROUTERS' group, out
   all interfaces having PIM neighbors (excluding the one over which the
   message was received).  Bootstrap messages are sent with TTL value of
   1. Bootstrap messages originate at the BSR, and are forwarded by
   intermediate routers.

   Bootstrap message is divided up into `semantic fragments', if the
   original message exceeds the maximum packet size boundaries.

   The semantics of a single `fragment' is given below:

Top       Page 53 
   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  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Fragment Tag          | Hash Mask len | BSR-priority  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-BSR-Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Encoded-Group Address-1               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RP-Count-1    | Frag RP-Cnt-1 |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-RP-Address-1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RP1-Holdtime         |           Unicast- . . .      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | . . . RP-Address-2            |       RP2-Holdtime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-RP-Address-m                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RPm-Holdtime         |            Encoded- . . .     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | . . . Group Address-2         . . .                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Encoded-Group Address-n               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RP-Count-m    | Frag RP-Cnt-m |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-RP-Address-1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RP1-Holdtime         |           Unicast- . . .      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | . . . RP-Address-2            |       RP2-Holdtime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-RP-Address-m                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RPm-Holdtime         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top       Page 54 
   PIM Version, Type, Addr length, Checksum
         Described above.

   Fragment Tag
        A randomly generated number, acts to distinguish the
        fragments belonging to different Bootstrap messages;
        fragments belonging to same Bootstrap message carry the
        same `Fragment Tag'.

   Hash Mask len
        The length (in bits) of the mask to use in the hash
        function.  For IPv4 we recommend a value of 30. For IPv6 we
        recommend a value of 126.

   BSR-priority
        Contains the BSR priority value of the included BSR.  This
        field is considered as a high order byte when comparing BSR
        addresses.

   Unicast-BSR-Address
        The IP address of the bootstrap router for the domain. The
        length of this field in bytes is specified in Addr length.

   Encoded-Group Address-1..n
        The group prefix (address and mask) with which the
        Candidate RPs are associated. Format previously described.

   RP-Count-1..n
        The number of Candidate RP addresses included in the whole
        Bootstrap message for the corresponding group prefix. A
        router does not replace its old RP-Set for a given group
        prefix until/unless it receives `RP-Count' addresses for
        that prefix; the addresses could be carried over several
        fragments.  If only part of the RP-Set for a given group
        prefix was received, the router discards it, without
        updating that specific group prefix's RP-Set.

   Frag RP-Cnt-1..m
        The number of Candidate RP addresses included in this
        fragment of the Bootstrap message, for the corresponding
        group prefix. The `Frag RP-Cnt' field facilitates parsing
        of the RP-Set for a given group prefix, when carried over
        more than one fragment.

   Unicast-RP-address-1..m
        The address of the Candidate RPs, for the corresponding
        group prefix.  The length of this field in bytes is
        specified in Addr length.

Top       Page 55 
   RP1..m-Holdtime
        The Holdtime for the corresponding RP. This field is copied
        from the `Holdtime' field of the associated RP stored at
        the BSR.

4.7 Assert Message

   The Assert message is sent when a multicast data packet is received
   on an outgoing interface corresponding to the (S,G) or (*,G)
   associated with the source.


    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  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encoded-Group Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Unicast-Source Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                        Metric Preference                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Metric                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   PIM Version, Type, Addr length, Checksum
         Described above.

   Encoded-Group Address
         The group address to which the data packet was addressed,
         and which triggered the Assert.  Format previously
         described.

   Unicast-Source Address
         Source IP address from IP multicast datagram that
         triggered the Assert packet to be sent. The length of this
         field in bytes is specified in Addr length.

   R     RPT-bit is a 1 bit value. If the IP multicast datagram
         that triggered the Assert packet is routed down the RP
         tree, then the RPT-bit is 1; if the IP multicast datagram
         is routed down the SPT, it is 0.

   Metric Preference
         Preference value assigned to the unicast routing protocol
         that provided the route to Host address.

Top       Page 56 
   Metric The unicast routing table metric. The metric is in units
         applicable to the unicast routing protocol used.

4.8 Graft Message

   Used in dense-mode. Refer to PIM dense mode specification.

4.9 Graft-Ack Message

   Used in dense-mode. Refer to PIM dense mode specification.

4.10 Candidate-RP-Advertisement

   Candidate-RP-Advertisements are periodically unicast from the C-RPs
   to the BSR.


    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  | Addr length   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix-Cnt    |A| Reserved    |             Holdtime          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast-RP-Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Encoded-Group Address-1               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Encoded-Group Address-n               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   PIM Version, Type, Addr length, Checksum
         Described above.

   Prefix-Cnt
         The number of encoded group addresses included in the
         message; indicating the group prefixes for which the C-RP
         is advertising. A Prefix-Cnt of `0' implies a prefix of
         224.0.0.0 with mask length of 4; i.e. all multicast groups.
         If the C-RP is not configured with Group-prefix
         information, the C-RP puts a default value of `0' in this
         field.

Top       Page 57 
   A     The Authoritative bit. This bit indicates that the BSR
         should not override the group-prefix information indicated
         in the C-RP Advertisement. In most cases C-RPs set this bit
         to 0.

   Holdtime
         The amount of time the advertisement is valid. This field
         allows advertisements to be aged out.

   Unicast-RP-Address
         The address of the interface to advertise as a Candidate
         RP.  The length of this field in bytes is specified in Addr
         length.

   Encoded-Group Address-1..n
         The group prefixes for which the C-RP is advertising.
         Format previously described.

5 Acknowledgments

   Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul Francis,
   Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia
   Zhang and Girish Chandranmenon provided detailed comments on previous
   drafts. The authors of CBT [7] and membership of the IDMR WG provided
   many of the motivating ideas for this work and useful feedback on
   design details.

   This work was supported by the National Science Foundation, ARPA,
   cisco Systems and Sun Microsystems.

Top       Page 58 
6 Appendices

6.1 Appendix I: Major Changes and Updates to the Spec

   This appendix populates the major changes in the specification
   document as compared to `draft-ietf-idmr-pim-spec-01.ps,txt'.

   * Major Changes

   List of changes since March '96 IETF:

   (*,*,RP) Joins state and data forwarding check; replaces (*,G-
   Prefix) Joins state for interoperability. (*,G) negative cache
   introduced for the (*,*,RP) state supporting mechanisms.

   Semantic fragmentation for the Bootstrap message.

   Refinement of Assert details.

   Addition and refinement of Join/Prune suppression and Register
   suppression (introduction of null Registers).

   Editorial changes and clarifications to the timers section.

   Addition of Appendix II (BSR Election and RP-Set Distribution), and
   Appendix III (Glossary of Terms).

   Addition of table of contents.

   List of changes incurred since version 1 of the spec.:

   Proposal and refinement of bootstrap router (BSR) election mechanisms

   Introduction of hash functions for Group to RP mapping

   New RP-liveness indication mechanisms based upon the the Bootstrap
   Router (BSR) and the Bootstrap messages.

   Removal of reachability messages, RP reports and multiple RPs per
   group.


   * Packet Format Changes

   Packet Format incurred updates to accommodate different address
   lengths, and address aggregation.

Top       Page 59 
   1    The `Addr length' field was added to the PIM fixed header
        to specify the address length in bytes of the underlying
        protocol, see section 4.

   2    The Encoded source and group address formats were
        introduced, with the use of a `Mask length' field to allow
        aggregation, section 4.1.

   3    Packet formats are no longer IGMP messages; rather PIM
        messages.


   PIM message types and formats were also modified:

   [Note: most changes were made to the May 95 version, unless otherwise
   specified].

   1    Obsolete messages:

        Register-Ack [Feb. 96]

        Poll and Poll Response [Feb. 96]

        RP-Reachability [Feb. 96]

        RPlist-Mapping [Feb. 96]


   2    New messages:

        Candidate-RP-Advertisement [change made in October 95]
        RP-Set [Feb. 96]


   3    Modified messages:

        Join/Prune [Feb. 96]
        Register [Feb. 96]
        Register-Stop [Feb.  96]
        Hello (addition of OptionTypes) [Aug 96]


   4    Renamed messages:

        Query messages are renamed as Hello messages [Aug. 96]
        RP-Set messages are renamed as Bootstrap messages [Aug. 96]

Top       Page 60 
6.2 Appendix II: BSR Election and RP-Set Distribution

   For simplicity, the Bootstrap message is used in both the BSR election
   and the RP-Set distribution.

   The above two mechanisms; the BSR election, and the RP-Set
   distribution; are realized through the following state machine,
   illustrated in figure 4:

      [Figures are present only in the postscript version]
      Fig.  4 State Diagram for the BSR election and RP-Set
      distribution mechanisms

   The protocol transitions for a C-BSR are given in state diagram (a).
   For routers not configured as C-BSRs, the protocol transitions are
   given in state diagram (b).

   Each PIM router keeps a Bootstrap-timer, initialized to
   [Bootstrap-Timeout], in addition to a local BSR field `LclBSR'
   (initialized to a local address if C-BSR, or to 0 otherwise), and a
   local RP-Set `LclRP-Set' (initially empty).  The two main stimuli to
   the state machine are the timer events, and receiving an Bootstrap
   message:

   * Initial States and Timer Events


   1    If the router is a C-BSR:

        1    The router operates initially in the `CandBSR' state, where
             it does not originate any Bootstrap messages.

        2    If the Bootstrap-timer expires, and the current state is
             `CandBSR', the router originates an Bootstrap message -
             carrying the local RP-Set, and its own BSR priority and
             address-, restarts the Bootstrap-timer at [Bootstrap-
             Period] seconds and transits into the `ElectedBSR' state.

        3    If the Bootstrap-timer expires, and the current state is
             `ElectedBSR', the router originates an Bootstrap message,
             and restarts the RP-Set timer at [Bootstrap-Period].  No
             state transition is incurred.

             This way, the elected BSR originates periodic Bootstrap
             messages every [Bootstrap-Period].

Top       Page 61 
   2    If a router is not a C-BSR:

        1    The router operates initially in the 'AxptAny' state.  In
             such state, a router accepts the first Bootstrap message
             from the RPF neighbor toward the included BSR. The Reverse
             Path Forwarding (RPF) neighbor in this case is the next hop
             router en route to the included BSR.

        2    If the Bootstrap-timer expires, and the current state is
             `AxptPref', -where the router accepts only preferred.
             Bootstrap messages from the RPF neighbor toward the
             included BSR-, the router transits into the `AxptAny'
             state (preferred Bootstrap messages are those that carry
             BSR-priority and address higher than, or equal to,
             `LclBSR').

             In this case, if an elected BSR becomes unreachable, the
             routers start accepting Bootstrap messages from another C-
             BSR after the Bootstrap-timer expires.  All PIM routers
             within a domain converge on the preferred (with highest
             priority and address) reachable C-BSR.


   * Receiving Bootstrap Message

   To avoid loops, an RPF check is performed on the included BSR address.
   Upon receiving an Bootstrap message from the RPF neighbor toward the
   included BSR, the following actions are taken:

   1    If the router is not a C-BSR:

        1    If the current state is 'AxptAny', the router accepts the
             Bootstrap message, and transits into the 'AxptPref' state.

        2    If the current state is 'AxptPref', and the Bootstrap
             message is preferred, the message is accepted. No state
             transition is incurred.

   2    If the router is a C-BSR, and the Bootstrap message is
        preferred, the message is accepted. Further, if this happens
        when the current state is

   When an Bootstrap message is accepted, the router restarts the
   Bootstrap-timer at [Bootstrap-Timeout], stores the received BSR
   priority and address in `LclBSR', and the received RP-Set in
   `LclRP-Set', and forwards the Bootstrap message out all interfaces
   except the receiving interface.

Top       Page 62 
   If an Bootstrap message is rejected, no state transitions are
   triggered.

6.3 Appendix III: Glossary of Terms

   Following is an alphabetized list of terms and definitions used
   throughout this specification.


   *    {Bootstrap router (BSR)}. A BSR is a dynamically elected router
        within a PIM domain. It is responsible for constructing the RP-
        Set and originating Bootstrap messages.

   *    {Candidate-BSR (C-BSR)}. A C-BSR is a router configured to
        participate in the BSR election and act as BSRs if elected.

   *    {Candidate RP (C-RP)}. A C-RP is a router configured to send
        periodic Candidate-RP-Advertisement messages to the BSR, and act
        as an RP when it receives Join/Prune or Register messages for
        the advertised group prefix.

   *    {Designated Router (DR)}.  The DR sets up multicast route
        entries and sends corresponding Join/Prune and Register messages
        on behalf of directly-connected receivers and sources,
        respectively.  The DR may or may not be the same router as the
        IGMP Querier. The DR may or may not be the long-term, last-hop
        router for the group; a router on the LAN that has a lower
        metric route to the data source, or to the group's RP, may take
        over the role of sending Join/Prune messages.

   *    {Incoming interface (iif)}. The iif of a multicast route entry
        indicates the interface from which multicast data packets are
        accepted for forwarding. The iif is initialized when the entry
        is created.

   *    {Join list}. The Join list is one of two lists of addresses that
        is included in a Join/Prune message; each address refers to a
        source or RP.  It indicates those sources or RPs to which
        downstream receiver(s) wish to join.

   *    {Last-hop router}. The last-hop router is the last router to
        receive multicast data packets before they are delivered to
        directly-connected member hosts. In general the last-hop router
        is the DR for the LAN.  However, under various conditions
        described in this document a parallel router connected to the
        same LAN may take over as the last-hop router in place of the
        DR.

Top       Page 63 
   *    {Outgoing interface (oif) list}. Each multicast route entry has
        an oif list containing the outgoing interfaces to which
        multicast packets should be forwarded.

   *    {Prune List}. The Prune list is the second list of addresses
        that is included in a Join/Prune message. It indicates those
        sources or RPs from which downstream receiver(s) wish to prune.

   *    {PIM Multicast Border Router (PMBR)}. A PMBR connects a PIM
        domain to other multicast routing domain(s).

   *    {Rendezvous Point (RP)}. Each multicast group has a shared-tree
        via which receivers hear of new sources and new receivers hear
        of all sources. The RP is the root of this per-group shared
        tree, called the RP-Tree.

   *    {RP-Set}. The RP-Set is a set of RP addresses constructed by
        the BSR based on Candidate-RP advertisements received. The RP-
        Set information is distributed to all PIM routers in the BSR's
        PIM domain.

   *    {Reverse Path Forwarding (RPF)}. RPF is used to select the
        appropriate incoming interface for a multicast route entry . The
        RPF neighbor for an IP address X is the the next-hop router used
        to forward packets toward X. The RPF interface is the interface
        to that RPF neighbor. In the common case this is the next hop
        used by the unicast routing protocol for sending unicast packets
        toward X. For example, in cases where unicast and multicast
        routes are not congruent, it can be different.

   *    {Route entry.} A multicast route entry is state maintained in a
        router along the distribution tree and is created, and updated
        based on incoming control messages.  The route entry may be
        different from the forwarding entry; the latter is used to
        forward data packets in real time. Typically a forwarding entry
        is not created until data packets arrive, the forwarding entry's
        iif and oif list are copied from the route entry, and the
        forwarding entry may be flushed and recreated at will.

   *    {Shortest path tree (SPT)}.  The SPT is the multicast
        distribution tree created by the merger of all of the shortest
        paths that connect receivers to the source (as determined by
        unicast routing).

   *    {Sparse Mode (SM)}. SM is one mode of operation of a multicast
        protocol.  PIM SM uses explicit Join/Prune messages and
        Rendezvous points in place of Dense Mode PIM's and DVMRP's
        broadcast and prune mechanism.

Top       Page 64 
   *    {Wildcard (WC) multicast route entry}. Wildcard multicast route
        entries are those entries that may be used to forward packets
        for any source sending to the specified group. Wildcard bots in
        the join list of a Join/Prune message represent either a (*,G)
        or (*,*,RP) join; in the prune list they represent a (*,G)
        prune.

   *    {(S,G) route entry}. (S,G) is a source-specific route entry. It
        may be created in response to data packets, Join/Prune messages,
        or Asserts. The (S,G) state in routers creates a source-rooted,
        shortest path (or reverse shortest path) distribution tree.
        (S,G)RPT bit entries are source-specific entries on the shared
        RP-Tree; these entries are used to prune particular sources off
        of the shared tree.

   *    {(*,G) route entry}. Group members join the shared RP-Tree for
        a particular group. This tree is represented by (*,G) multicast
        route entries along the shortest path branches between the RP
        and the group members.

   *    {(*,*,RP) route entry}. (*,*,RP) refers to any source and any
        multicast group that maps to the RP included in the entry. The
        routers along the shortest path branches between a domain's
        RP(s) and its PMBRs keep (*,*,RP) state and use it to determine
        how to deliver packets toward the PMBRs if data packets arrive
        for which there is not a longer match. The wildcard group in the
        (*,*,RP) route entry is represented by a group address of
        224.0.0.0 and a mask length of 4 bits.


   References

 1.  Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei,
     P.Sharma, and A.Helmy.  Protocol independent multicast (pim) :
     Motivation and architecture. Work in Progress.


 2.  Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, and L.Wei.
     The pim architecture for wide-area multicast routing.
     ACM Transactions on Networks, April 1996.


 3.  Estrin, D., D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and
     A.Helmy.  Protocol independent multicast-dense mode (pim-dm) :
     Protocol specification.  Work in Progress.


 4.  Deering, S. Host extensions for ip multicasting, Aug 1989. RFC1112.

Top       Page 65 
 5.  Fenner, W. Internet group management protocol, version 2.
     Work in Progress.


 6.  Atkinson, R. Security architecture for the internet protocol,
     August 1995. RFC-1825.


 7.  Ballardie, A.J., P.F. Francis, and J.Crowcroft. Core based trees.
     In Proceedings of the ACM SIGCOMM, San Francisco, 1993.


   Addresses of Authors:

   Deborah Estrin
   Computer Science Dept/ISI
   University of Southern Calif.
   Los Angeles, CA 90089 
   estrin@usc.edu

   Dino Farinacci
   Cisco Systems Inc.
   170 West Tasman Drive,
   San Jose, CA 95134
   dino@cisco.com

   Ahmed Helmy
   Computer Science Dept.
   University of Southern Calif.
   Los Angeles, CA 90089
   ahelmy@catarina.usc.edu

   David Thaler
   EECS Department
   University of Michigan
   Ann Arbor, MI 48109
   thalerd@eecs.umich.edu

   Stephen Deering
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304
   deering@parc.xerox.com

Top       Page 66 
   Mark Handley
   Department of Computer Science
   University College London
   Gower Street
   London, WC1E 6BT
   UK
   m.handley@cs.ucl.ac.uk

   Van Jacobson
   Lawrence Berkeley Laboratory
   1 Cyclotron Road
   Berkeley, CA 94720
   van@ee.lbl.gov

   Ching-gung  Liu
   Computer Science Dept.
   University of Southern Calif.
   Los Angeles, CA 90089
   charley@catarina.usc.edu

   Puneet Sharma
   Computer Science Dept.
   University of Southern Calif.
   Los Angeles, CA 90089
   puneet@catarina.usc.edu

   Liming Wei
   Cisco Systems Inc.
   170 West Tasman Drive,
   San Jose, CA 95134
   lwei@cisco.com