PIM reserved
bits and type space extensionCisco Systems, Inc.Tasman DriveSan JoseCA 95134USAstig@cisco.comHuawei R&D USA2330 Central ExpresswaySanta ClaraCA 95050USAalvaro.retana@huawei.com
Routing
MulticastThe currently defined PIM version 2 messages share a common message
header format. The common header definition contains eight reserved
bits. This document specifies how these bits may be used by individual
message types, and creates a registry containing the per message type
usage. This document also extends the PIM type space by defining a new
message type where four of the flag bits are used as an extended type
range.This document Updates RFC7761 and RFC3973 by defining the use of the
currently Reserved field in the PIM common header. This document further
updates RFC7761 and RFC3973, along with RFC5015, RFC6754 and
I-D.ietf-pim-source-discovery-bsr, by specifying the use of the
currently Reserved bits for each PIM message.The currently defined PIM version 2 messages share a common message
header format defined in the PIM Sparse Mode
and Dense Mode specifications. The common
header definition contains eight reserved bits. The message types
defined in these documents all use this common header. However, several
messages already make use of one or more bits, including the Bootstrap
, DF-Election , and PIM
Flooding Mechanism (PFM) messages. There is no
document formally specifying that these bits are to be used per message
type.This document refers to the bits specified as Reserved in the common
PIM header as PIM
message type flag bits, or simply flag bits, and it specifies that they
are to be separately used on a per message type basis. It creates a
registry containing the the per message type usage. For a particular
message type, the usage of the flag bits can be defined in the document
defining the message type, or a new document that updates that
document.The PIM message types as defined in the PIM Sparse Mode and Dense Mode
specifications are in the range from 0 to 15. That type space is almost
exhausted. Message type 15 was reserved by for
type space extension. In , this document specifies
the use of the flag bits for Type 15 in order to extend the PIM type
space. The registration procedure for the extended type space is the
same as for the existing type space, and the existing PIM message type
registry is updated to include the extended type space.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when,
and only when, they appear in all capitals, as shown here. The common PIM header is defined in section 4.9 of and section 4.7.1 of . This
document updates the definition of the Reserved field and refers to that
field as PIM message type flag bits, or simply flag bits. The new common
header format is as below. The Flags Bits field is defined in . All
other fields remain unchanged.Unless otherwise specified, all the flag bits for each PIM type are
Reserved . They MUST be set to zero on
transmission, and they MUST be ignored upon receipt. The specification
of a new PIM type, MUST indicate whether the bits should be treated
differently. Currently for the message types 0 (Hello), 1 (Register), 2
(Register Stop), 3 (Join/Prune), 5 (Assert), 6 (Graft), 7 (Graft-Ack), 8
(Candidate RP Advertisement), 9 (State Refresh) and 11 (ECMP Redirect),
all flag bits are Reserved.When defining flag bits it is helpful to have a well defined way of
referring to a particular bit. The most significant of the flag bits,
the bit immediately following the type field is referred to as bit 7.
The least significant, the bit right in front of the checksum field is
referred to as bit 0. This is shown in the diagram below.PIM message type 4 (Bootstrap) defines
flag bit 7 as No-Forward. The usage of the bit is defined in that
document. The remaining flag bits are Reserved.PIM message type 10 (DF Election)
specifies that the four most significant flag bits (bits 4-7) are to
be used as a sub-type. The remaining flag bits are currently
Reserved.PIM message type 12 (PFM) defines flag bit 7 as
No-Forward. The usage of the bit is defined in that document. The
remaining flag bits are Reserved.This type and the flag bit usage is defined in .The type space defined by the existing PIM specifications is almost
exhausted. This document defines type 15 (Type Space Extension) allowing
for 16 additional types by using the four most significant flag bits
(bits 4-7) as a new field to store the extended type. These types are
referred to as types 15.0 to 15.15 where the last number denotes the
value stored in the new field. The remaining four flag bits (bits 0-3)
are Reserved to be used by each extended type. The specification of a
new PIM extended type MUST indicate whether the bits should be treated
differently. The common header for types 15.0 to 15.15 is shown in the
diagram below. The extended type field "Rsvd" denotes the value after
the dot.This document clarifies the use of the flag bits in the common PIM
header and it extends the PIM type space. As such, there is no impact on
security or changes to the considerations in
and .This document updates the PIM Message Types registry and also creates
a PIM Message Type Flag Bits registry that shows which flag bits are
defined for use by each of the PIM message types.The following changes should be made to the existing PIM Message
Types registry. For types 4 (Bootstrap) and 8 (Candidate RP
Advertisement) a reference to RFC5059 should be added. For type 15
(Reserved), the name should be changed to "Type Space Extension", and
reference this document. In addition, there should be one new row at the
bottom where it should say "15.0-15.15 Unassigned".A new registry called "PIM Message Type Flag Bits" should be created
in the pim-paremeters section with registration procedure "IETF Review"
as defined in with this document as a
reference. The initial content of the registry should be as below.