RFC 7761
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
Pages: 137
Internet Standard: 83
→ Errata
Obsoletes: 4601
Updated by: 8736 9436
Internet Standard: 83
→ Errata
Obsoletes: 4601
Updated by: 8736 9436
Part 6 of 7 – Pages 98 to 122
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].
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.
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.
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.
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)
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.
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
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.
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.
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.
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.
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.
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.
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 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
(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.
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) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
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).
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.
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)