Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3973

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

Pages: 61
Experimental
Errata
Updated by:  87369436
Part 3 of 3 – Pages 38 to 61
First   Prev   None

Top   ToC   RFC3973 - Page 38   prevText

4.7. PIM Packet Formats

All PIM-DM packets use the same format as PIM-SM packets. In the event of a discrepancy, PIM-SM [4] should be considered the definitive specification. All PIM control messages have IP protocol number 103. All PIM-DM messages MUST be sent with a TTL of 1. All PIM-DM messages except Graft and Graft Ack messages MUST be sent to the ALL-PIM-ROUTERS group. Graft messages SHOULD be unicast to the RPF'(S). Graft Ack messages MUST be unicast to the sender of the Graft. The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM- ROUTERS group is 'ff02::d'.

4.7.1. PIM Header

All PIM control messages have the following header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Ver PIM version number is 2.
Top   ToC   RFC3973 - Page 39
   Type
     Types for specific PIM messages.  Available types are as follows:
     0 = Hello
     1 = Register (PIM-SM only)
     2 = Register Stop (PIM-SM only)
     3 = Join/Prune
     4 = Bootstrap (PIM-SM only)
     5 = Assert
     6 = Graft
     7 = Graft Ack
     8 = Candidate RP Advertisement (PIM-SM only)
     9 = State Refresh

   Reserved
     Set to zero on transmission.  Ignored upon receipt.

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

     For IPv6, the checksum also includes the IPv6 "pseudo-header", as
     specified in RFC 2460, Section 8.1 [5].

4.7.2. Encoded Unicast Address

An Encoded Unicast Address has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... Addr Family The PIM Address Family of the 'Unicast Address' field of this address. Values 0 - 127 are as assigned by the IANA for Internet Address Families in [9]. Values 128 - 250 are reserved to be assigned by the IANA for PIM specific Address Families. Values 251 - 255 are designated for private use. As there is no assignment authority for this space; collisions should be expected. Encoding Type The type of encoding used with a specific Address Family. The value '0' is reserved for this field and represents the native encoding of the Address Family.
Top   ToC   RFC3973 - Page 40
   Unicast Address
     The unicast address as represented by the given Address Family and
     Encoding Type.

4.7.3. Encoded Group Address

An Encoded Group address has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Multicast Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... Addr Family As described above. Encoding Type As described above. B Indicates that the group range should use Bidirectional PIM [16]. Transmitted as zero; ignored upon receipt. Reserved Transmitted as zero. Ignored upon receipt. Z Indicates that the group range is an admin scope zone. This is used in the Bootstrap Router Mechanism [18] only. For all other purposes, this bit is set to zero and ignored on receipt. Mask Len The mask length field is 8 bits. The value is the number of contiguous left justified one bits used as a mask, which, combined with the address, describes a range of addresses. It is less than or equal to the address length in bits for the given Address Family and Encoding Type. If the message is sent for a single address then the mask length MUST equal the address length. PIM-DM routers MUST only send for a single address. Group Multicast Address The address of the multicast group.
Top   ToC   RFC3973 - Page 41

4.7.4. Encoded Source Address

An Encoded Source address has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... Addr Family As described above. Encoding Type As described above. Rsrvd Reserved. Transmitted as zero. Ignored upon receipt. S The Sparse Bit. Set to 0 for PIM-DM. Ignored upon receipt. W The Wild Card Bit. Set to 0 for PIM-DM. Ignored upon receipt. R The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon receipt. Mask Len As described above. PIM-DM routers MUST only send for a single source address. Source Address The source address.
Top   ToC   RFC3973 - Page 42

4.7.5. Hello Message Format

The PIM Hello message, as defined by PIM-SM [4], has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Value | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Value | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Ver, Type, Reserved, Checksum Described above. Option Type The type of option given in the Option Value field. Available types are as follows: 0 Reserved 1 Hello Hold Time 2 LAN Prune Delay 3 - 16 Reserved 17 To be assigned by IANA 18 Deprecated and SHOULD NOT be used 19 DR Priority (PIM-SM Only) 20 Generation ID 21 State Refresh Capable 22 Bidir Capable 23 - 65000 To be assigned by IANA 65001 - 65535 Reserved for Private Use [9] Unknown options SHOULD be ignored.
Top   ToC   RFC3973 - Page 43
4.7.5.1. Hello Hold Time Option
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hold Time is the number of seconds a receiver MUST keep the neighbor reachable. If the Hold Time is set to '0xffff', the receiver of this message never times out the neighbor. This may be used with dial- on-demand links to avoid keeping the link up with periodic Hello messages. Furthermore, if the Holdtime is set to '0', the information is timed out immediately. The Hello Hold Time option MUST be used by PIM-DM routers.
4.7.5.2. LAN Prune Delay Option
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| LAN Prune Delay | Override Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LAN_Prune_Delay option is used to tune the prune propagation delay on multi-access LANs. The T bit is used by PIM-SM and SHOULD be set to 0 by PIM-DM routers and ignored upon receipt. The LAN Delay and Override Interval fields are time intervals in units of milliseconds and are used to tune the value of the J/P Override Interval and its derived timer values. Section 4.3.5 describes how these values affect the behavior of a router. The LAN Prune Delay SHOULD be used by PIM-DM routers.
Top   ToC   RFC3973 - Page 44
4.7.5.3. Generation ID Option
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 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. The Generation ID option MAY be used by PIM-DM routers.
4.7.5.4. State Refresh Capable Option
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 = 21 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version = 1 | Interval | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Interval field is the router's configured State Refresh Interval in seconds. The Reserved field is set to zero and ignored upon receipt. The State Refresh Capable option MUST be used by State Refresh capable PIM-DM routers.
Top   ToC   RFC3973 - Page 45

4.7.6. Join/Prune Message Format

PIM Join/Prune messages, as defined in PIM-SM [4], have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Neighbor Address (Encoded Unicast Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Num Groups | Hold Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address 1 (Encoded Group Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 1 (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address n (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address m (Encoded Group Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC3973 - Page 46
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Joined Source Address n (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Pruned Source Address 1 (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Pruned Source Address n (Encoded Source Format)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Ver, Type, Reserved, Checksum
     Described above.

   Upstream Neighbor Address
     The address of the upstream neighbor.  The format for this address
     is given in the Encoded Unicast address in Section 4.7.2.  PIM-DM
     routers MUST set this field to the RPF next hop.

   Reserved
     Transmitted as zero.  Ignored upon receipt.

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

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

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

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

   Number of Pruned Sources
     Number of Prune source addresses listed for a given group.
Top   ToC   RFC3973 - Page 47
   Join Source Address 1..n
     This list contains the sources from which the sending router wishes
     to continue to receive multicast messages for the given group on
     this interface.  The addresses use the Encoded Source address
     format given in Section 4.7.4.

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

4.7.7. Assert Message Format

PIM Assert Messages, as defined in PIM-SM [4], have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address (Encoded Group Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address (Encoded Unicast Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Metric Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Ver, Type, Reserved, Checksum Described above. Multicast Group Address The multicast group address in the Encoded Multicast address format given in Section 4.7.3. Source Address The source address in the Encoded Unicast address format given in Section 4.7.2. R The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon receipt.
Top   ToC   RFC3973 - Page 48
   Metric Preference
     The preference value assigned to the unicast routing protocol that
     provided the route to the source.

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

4.7.8. Graft Message Format

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

4.7.9. Graft Ack Message Format

PIM Graft Ack messages are identical in format to the received Graft message, except that the Type field is set to 7. The Upstream Neighbor Address field SHOULD be set to the sender of the Graft message and SHOULD be ignored upon receipt.

4.7.10. State Refresh Message Format

PIM State Refresh Messages have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address (Encoded Group Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address (Encoded Unicast Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address (Encoded Unicast Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Metric Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Masklen | TTL |P|N|O|Reserved | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Ver, Type, Reserved, Checksum Described above.
Top   ToC   RFC3973 - Page 49
   Multicast Group Address
     The multicast group address in the Encoded Multicast address format
     given in Section 4.7.3.

   Source Address
     The address of the data source in the Encoded Unicast address
     format given in Section 4.7.2.

   Originator Address
     The address of the first hop router in the Encoded Unicast address
     format given in Section 4.7.2.

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

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

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

   Masklen
     The length of the address mask of the unicast route to the source.

   TTL
     Time To Live of the State Refresh message.  Decremented each time
     the message is forwarded.  Note that this is different from the IP
     Header TTL, which is always set to 1.

   P
     Prune indicator flag.  This MUST be set to 1 if the State Refresh
     is to be sent on a Pruned interface.  Otherwise, it MUST be set to
     0.

   N
     Prune Now flag.  This SHOULD be set to 1 by the State Refresh
     originator on every third State Refresh message and SHOULD be
     ignored upon receipt.  This is for compatibility with earlier
     versions of state refresh.

   O
     Assert Override flag.  This SHOULD be set to 1 by upstream routers
     on a LAN if the Assert Timer (AT(S,G)) is not running and SHOULD be
     ignored upon receipt.  This is for compatibility with earlier
     versions of state refresh.
Top   ToC   RFC3973 - Page 50
   Reserved
     Set to zero and ignored upon receipt.

   Interval
     Set by the originating router to the interval (in seconds) between
     consecutive State Refresh messages for this (S,G) pair.

4.8. PIM-DM Timers

PIM-DM maintains the following timers. All timers are countdown timers -- they are set to a value and count down to zero, at which point they typically trigger an action. Of course they can just as easily be implemented as count-up timers, where the absolute expiry time is stored and compared against a real-time clock, but the language in this specification assumes that they count downward towards zero. Global Timers Hello Timer: HT Per interface (I): Per neighbor (N): Neighbor Liveness Timer: NLT(N,I) Per (S,G) Pair: (S,G) Assert Timer: AT(S,G,I) (S,G) Prune Timer: PT(S,G,I) (S,G) PrunePending Timer: PPT(S,G,I) Per (S,G) Pair: (S,G) Graft Retry Timer: GRT(S,G) (S,G) Upstream Override Timer: OT(S,G) (S,G) Prune Limit Timer: PLT(S,G) (S,G) Source Active Timer: SAT(S,G) (S,G) State Refresh Timer: SRT(S,G)
Top   ToC   RFC3973 - Page 51
   When timer values are started or restarted, they are set to default
   values.  The following tables summarize those default values.

Timer Name: Hello Timer (HT)
+----------------------+--------+--------------------------------------+
| Value Name           | Value  | Explanation                          |
+----------------------+--------+--------------------------------------+
|Hello_Period          | 30 sec | Periodic interval for hello messages |
+----------------------+--------+--------------------------------------+
|Triggered_Hello_Delay | 5 sec  | Random interval for initial Hello    |
|                      |        | message on bootup or triggered Hello |
|                      |        | message to a rebooting neighbor      |
+----------------------+--------+--------------------------------------+

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

Timer Name: Neighbor Liveness Timer (NLT(N,I))
+-------------------+-----------------+--------------------------------+
| Value Name        | Value           | Explanation                    |
+-------------------+-----------------+--------------------------------+
| Hello Holdtime    | From message    | Hold Time from Hello Message   |
+-------------------+-----------------+--------------------------------+

Timer Name: PrunePending Timer (PPT(S,G,I))
+-----------------------+---------------+------------------------------+
| Value Name            | Value         | Explanation                  |
+-----------------------+---------------+------------------------------+
| J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to  |
|                       |               | allow other routers on the   |
|                       |               | LAN to send a Join           |
+-----------------------+---------------+------------------------------+

   The J/P_Override_Interval is the sum of the interface's
   Override_Interval (OI(I)) and Propagation_Delay (PD(I)).  If all
   routers on a LAN are using the LAN Prune Delay option, both
   parameters MUST be set to the largest value on the LAN.  Otherwise,
   the Override_Interval (OI(I)) MUST be set to 2.5 seconds, and the
   Propagation_Delay (PD(I)) MUST be set to 0.5 seconds.
Top   ToC   RFC3973 - Page 52
Timer Name: Prune Timer (PT(S,G,I))
+----------------+----------------+------------------------------------+
| Value Name     | Value          | Explanation                        |
+----------------+----------------+------------------------------------+
| Prune Holdtime | From message   | Hold Time read from Prune Message  |
+----------------+----------------+------------------------------------+

Timer Name: Assert Timer (AT(S,G,I))
+--------------------------+---------+---------------------------------+
| Value Name               | Value   | Explanation                     |
+--------------------------+---------+---------------------------------+
| Assert Time              | 180 sec | Period after last assert before |
|                          |         | assert state is timed out       |
+--------------------------+---------+---------------------------------+

   Note that, for historical reasons, the Assert message lacks a
   Holdtime field.  Thus, changing the Assert Time from the default
   value is not recommended.  If all members of a LAN are state refresh
   enabled, the Assert Time will be three times the received
   RefreshInterval(S,G).

Timer Name: Graft Retry Timer (GRT(S,G))
+--------------------+-------+-----------------------------------------+
| Value Name         | Value | Explanation                             |
+--------------------+-------+-----------------------------------------+
| Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck |
|                    |       | message, the time before retransmission |
|                    |       | of a Graft message                      |
+--------------------+-------+-----------------------------------------+

Timer Name: Upstream Override Timer (OT(S,G))
+------------+----------------+----------------------------------------+
| Value Name | Value          | Explanation                            |
+------------+----------------+----------------------------------------|
| t_override | rand(0, OI(I)) | Randomized delay to prevent response   |
|            |                | implosion when sending a join message  |
|            |                | to override someone else's prune       |
+------------+----------------+----------------------------------------+

   t_override is a random value between 0 and the interface's
   Override_Interval (OI(I)).  If all routers on a LAN are using the LAN
   Prune Delay option, the Override_Interval (OI(I)) MUST be set to the
   largest value on the LAN.  Otherwise, the Override_Interval (OI(I))
   MUST be set to 2.5 seconds.
Top   ToC   RFC3973 - Page 53
Timer Name: Prune Limit Timer (PLT(S,G))
+------------+--------------------+------------------------------------+
| Value Name | Value              | Explanation                        |
+------------+--------------------+------------------------------------|
| t_limit    | Default: 210 secs  | Used to prevent Prune storms on a  |
|            |                    | LAN                                |
+------------+--------------------+------------------------------------+

Timer Name: Source Active Timer (SAT(S,G))
+----------------+-------------------+---------------------------------+
| Value Name     | Value             | Explanation                     |
+----------------+-------------------+---------------------------------+
| SourceLifetime | Default: 210 secs | Period of time after receiving  |
|                |                   | a multicast message a directly  |
|                |                   | attached router will continue   |
|                |                   | to send State Refresh messages  |
+----------------+-------------------+---------------------------------+

Timer Name: State Refresh Timer (SRT(S,G))
+-----------------+------------------+---------------------------------+
| Value Name      | Value            | Explanation                     |
+-----------------+------------------+---------------------------------+
| RefreshInterval | Default: 60 secs | Interval between successive     |
|                 |                  | state refresh messages          |
+-----------------+------------------+---------------------------------+

5. Protocol Interaction Considerations

PIM-DM is designed to be independent of underlying unicast routing protocols and will interact only to the extent needed to perform RPF checks. It is generally assumed that multicast area and autonomous system boundaries will correspond to the same boundaries for unicast routing, though a deployment that does not follow this assumption is not precluded by this specification. In general, PIM-DM interactions with other multicast routing protocols should be in compliance with RFC 2715 [7]. Other specific interactions are noted below.

5.1. PIM-SM Interactions

PIM-DM is not intended to interact directly with PIM-SM, even though they share a common packet format. It is particularly important to note that a router cannot differentiate between a PIM-DM neighbor and a PIM-SM neighbor based on Hello messages.
Top   ToC   RFC3973 - Page 54
   In the event that a PIM-DM router becomes a neighbor of a PIM-SM
   router, the two will effectively form a simplex link, with the PIM-DM
   router sending all multicast messages to the PIM-SM router while the
   PIM-SM router sends no multicast messages to the PIM-DM router.

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

5.2. IGMP Interactions

PIM-DM will forward received multicast data packets to neighboring host group members in all cases except when the PIM-DM router is in an Assert Loser state on that interface. Note that a PIM Prune message is not permitted to prevent the delivery of messages to a network with group members. A PIM-DM Router MAY use the DR Priority option described in PIM-SM [14] to elect an IGMP v1 querier.

5.3. Source Specific Multicast (SSM) Interactions

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

5.4. Multicast Group Scope Boundary Interactions

Although multicast group scope boundaries are generally identical to routing area boundaries, it is conceivable that a routing area might be partitioned for a particular multicast group. PIM-DM routers MUST NOT send any messages concerning a particular group across that group's scope boundary.

6. IANA Considerations

6.1. PIM Address Family

The PIM Address Family field was chosen to be 8 bits as a tradeoff between packet format and use of the IANA assigned numbers. When the PIM packet format was designed, only 15 values were assigned for Address Families, and large numbers of new Address Families were not envisioned; 8 bits seemed large enough. However, the IANA assigns Address Families in a 16 bit value. Therefore, the PIM Address Family is allocated as follows:
Top   ToC   RFC3973 - Page 55
   Values 0 - 127 are designated to have the same meaning as IANA
   assigned Address Family Numbers [9].

   Values 128 - 250 are designated to be assigned by the IANA based on
   IESG approval, as defined in [8].

   Values 251 - 255 are designated for Private Use, as defined in [8].

6.2. PIM Hello Options

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

7. Security Considerations

The IPsec authentication header [10] MAY be used to provide data integrity protection and groupwise data origin authentication of PIM protocol messages. Authentication of PIM messages can protect against unwanted behaviors caused by unauthorized or altered PIM messages. In any case, a PIM router SHOULD NOT accept and process PIM messages from neighbors unless a valid Hello message has been received from that neighbor. Note that PIM-DM has no rendezvous point, and therefore no single point of failure that may be vulnerable. Because PIM-DM uses unicast routes provided by an unknown routing protocol, it may suffer collateral effects if the unicast routing protocol is attacked.

7.1. Attacks Based on Forged Messages

The extent of possible damage depends on the type of counterfeit messages accepted. We next consider the impact of possible forgeries. A forged PIM-DM message is link local and can only reach a LAN if it was sent by a local host or if it was allowed onto the LAN by a compromised or non-compliant router. 1. A forged Hello message can cause multicast traffic to be delivered to links where there are no legitimate requestors, potentially wasting bandwidth on that link. On a multi-access LAN, the effects are limited without the capability to forge a Join message, as other routers will Prune the link if the traffic is not desired. 2. A forged Join/Prune message can cause multicast traffic to be delivered to links where there are no legitimate requestors, potentially wasting bandwidth on that link. A forged Prune
Top   ToC   RFC3973 - Page 56
      message on a multi-access LAN is generally not a significant
      attack in PIM, because any legitimately joined router on the LAN
      would override the Prune with a Join before the upstream router
      stops forwarding data to the LAN.

   3. A forged Graft message can cause multicast traffic to be delivered
      to links where there are no legitimate requestors, potentially
      wasting bandwidth on that link.  In principle, Graft messages
      could be sent multiple hops because they are unicast to the
      upstream router.  This should not be a problem, as the remote
      forger should have no way to get a Hello message to the target of
      the attack.  Without a valid Hello message, the receiving router
      SHOULD NOT accept the Graft.

   4. A forged GraftAck message has no impact, as it will be ignored
      unless the router has recently sent a Graft to its upstream
      router.

   5. By forging an Assert message on a multi-access LAN, an attacker
      could cause the legitimate forwarder to stop forwarding traffic to
      the LAN.  Such a forgery would prevent any hosts downstream of
      that LAN from receiving traffic.

   6. A forged State Refresh message on a multi-access LAN would have
      the same impact as a forged Assert message, having the same
      general functions.  In addition, forged State Refresh messages
      would be propagated downstream and might be used in a denial of
      service attack.  Therefore, a PIM-DM router SHOULD rate limit
      State Refresh messages propagated.

7.2. Non-cryptographic Authentication Mechanisms

A PIM-DM router SHOULD provide an option to limit the set of neighbors from which it will accept PIM-DM messages. Either static configuration of IP addresses or an IPSec security association may be used. All options that restrict the range of addresses from which packets are accepted MUST default to allowing all packets. Furthermore, a PIM router SHOULD NOT accept protocol messages from a router from which it has not yet received a valid Hello message.

7.3. Authentication Using IPsec

The IPSec [10] transport mode using the Authentication Header (AH) is the recommended method to prevent the above attacks in PIM. The specific AH authentication algorithm and parameters, including the choice of authentication algorithm and the choice of key, are configured by the network administrator. The Encapsulating Security
Top   ToC   RFC3973 - Page 57
   Payload (ESP) MAY also be used to provide both encryption and
   authentication of PIM protocol messages.  When IPsec authentication
   is used, a PIM router SHOULD reject (drop without processing) any
   unauthorized PIM protocol messages.

   To use IPSec, the administrator of a PIM network configures each PIM
   router with one or more Security Associations and associated Security
   Parameters Indices that are used by senders to authenticate PIM
   protocol messages and are used by receivers to authenticate received
   PIM protocol messages.  This document does not describe protocols for
   establishing Security Associations.  It assumes that manual
   configuration of Security Associations is performed, but it does not
   preclude the use of some future negotiation protocol such as GDOI
   [17] to establish Security Associations.

   The network administrator defines a Security Association (SA) and
   Security Parameters Index (SPI) to be used to authenticate all PIM-DM
   protocol messages from each router on each link in a PIM-DM domain.

   In order to avoid the problem of allocating individual keys for each
   neighbor on a link to each individual router, it is acceptable to
   establish only one authentication key for all PIM-DM routers on a
   link.  This will not specifically authenticate the individual router
   sending the message, but will ensure that the sender is a PIM-DM
   router on that link.  If this method is used, the receiver of the
   message MUST ignore the received sequence number, thus disabling
   anti-replay mechanisms.  The effects of disabling anti-replay
   mechanisms are essentially the same as the effects of forged
   messages, described in Section 7.1, with the additional protection
   that the forger can only reuse legitimate messages.

   The Security Policy Database at a PIM-DM router should be configured
   to ensure that all incoming and outgoing PIM-DM packets use the SA
   associated with the interface to which the packet is sent.  Note
   that, according to [10], there is nominally a different Security
   Association Database (SAD) for each router interface.  Thus, the
   selected Security Association for an inbound PIM-DM packet can vary
   depending on the interface on which the packet arrived.  This fact
   allows the network administrator to use different authentication
   methods for each link, even though the destination address is the
   same for most PIM-DM packets, regardless of interface.
Top   ToC   RFC3973 - Page 58

7.4. Denial of Service Attacks

There are a number of possible denial of service attacks against PIM that can be caused by generating false PIM protocol messages or even by generating false data traffic. Authenticating PIM protocol traffic prevents some, but not all, of these attacks. The possible attacks include the following: * Sending packets to many different group addresses quickly can amount to a denial of service attack in and of itself. These messages will initially be flooded throughout the network before they are pruned back. The maintenance of state machines and State Refresh messages will be a continual drain on network resources. * Forged State Refresh messages sent quickly could be propagated by downstream routers, creating a potential denial of service attack. Therefore, a PIM-DM router SHOULD limit the rate of State Refresh messages propagated.

8. Acknowledgments

The major features of PIM-DM were originally designed by Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy, David Meyer, and Liming Wei. Additional features for state refresh were designed by Dino Farinacci, Isidor Kouvelas, and Kurt Windisch. This revision was undertaken to incorporate some of the lessons learned during the evolution of the PIM-SM specification and early deployments of PIM-DM. Thanks the PIM Working Group for their comments.

9. References

9.1. Normative References

[1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
Top   ToC   RFC3973 - Page 59
   [4]  Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
        Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei,
        "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
        Specification", RFC 2362, June 1998.

   [5]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [6]  Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
        Discovery (MLD) for IPv6", RFC 2710, October 1999.

   [7]  Thaler, D., "Interoperability Rules for Multicast Routing
        Protocols", RFC 2715, October 1999.

   [8]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [9]  IANA, "Address Family Numbers", linked from
        http://www.iana.org/numbers.html.

   [10] Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

9.2. Informative References

[12] Deering, S.E., "Multicast Routing in a Datagram Internetwork", Ph.D. Thesis, Electrical Engineering Dept., Stanford University, December 1991. [13] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. [14] Fenner, W., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Work in Progress. [15] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress. [16] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi- directional Protocol Independent Multicast", Work in Progress. [17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
Top   ToC   RFC3973 - Page 60
   [18] Fenner, W., Handley, M., Kermode, R., and D. Thaler, "Bootstrap
        Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress.

Authors' Addresses

Andrew Adams NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738 EMail: ala@nexthop.com Jonathan Nicholas ITT Industries Aerospace/Communications Division 100 Kingsland Rd Clifton, NJ 07014 EMail: jonathan.nicholas@itt.com William Siadak NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738 EMail: wfs@nexthop.com
Top   ToC   RFC3973 - Page 61
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.