diff options
Diffstat (limited to 'doc/rfc/rfc8736.txt')
| -rw-r--r-- | doc/rfc/rfc8736.txt | 333 |
1 files changed, 333 insertions, 0 deletions
diff --git a/doc/rfc/rfc8736.txt b/doc/rfc/rfc8736.txt new file mode 100644 index 0000000..0ea2897 --- /dev/null +++ b/doc/rfc/rfc8736.txt @@ -0,0 +1,333 @@ + + + + +Internet Engineering Task Force (IETF) S. Venaas +Request for Comments: 8736 Cisco Systems, Inc. +Obsoletes: 6166 A. Retana +Updates: 3973, 5015, 5059, 6754, 7761, Futurewei Technologies, Inc. + 8364 February 2020 +Category: Standards Track +ISSN: 2070-1721 + + + PIM Message Type Space Extension and Reserved Bits + +Abstract + + The 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 three new + message types. For each of the new types, four of the previously + reserved bits are used to form an extended type range. + + This document updates RFCs 7761 and 3973 by defining the use of the + currently Reserved field in the PIM common header. This document + further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, + and 8364, by specifying the use of the currently reserved bits for + each PIM message. + + This document obsoletes RFC 6166. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8736. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions Used in This Document + 3. PIM Header Common Format + 4. Flag Bit Definitions + 4.1. Flag Bits for Type 4 (Bootstrap) + 4.2. Flag Bits for Type 10 (DF Election) + 4.3. Flag Bits for Type 12 (PFM) + 4.4. Flag Bits for Types 13, 14, and 15 (Type Space Extension) + 5. PIM Type Space Extension + 6. Security Considerations + 7. IANA Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Authors' Addresses + +1. Introduction + + The PIM version 2 messages share a common message header format + defined in the PIM Sparse Mode specification [RFC7761]. The common + header definition contains eight reserved bits. While all message + types use this common header, 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 [RFC7761] 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 per-message-type usage. + + 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], + [RFC5059], [RFC6754], and [RFC8364], by specifying the use of the + currently reserved bits for each PIM message. + + The currently defined PIM message types are in the range from 0 to + 15. That type space is almost exhausted. Message type 15 was + reserved by [RFC6166] for type space extension. In Section 5, this + document specifies the use of the Flag Bits for message types 13, 14, + and 15 in order to extend the PIM type space. This document + obsoletes [RFC6166]. + +2. Conventions Used in This Document + + 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 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. PIM Header Common Format + + The common PIM header is defined in Section 4.9 of [RFC7761]. 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. + + 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 | Flag Bits | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: New Common Header + + The Flag Bits field is defined in Section 4. All other fields remain + unchanged. + +4. Flag Bit Definitions + + Unless otherwise specified, all the flag bits for each PIM type are + Reserved [RFC8126]. 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. + + 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. + + 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 |7 6 5 4 3 2 1 0| Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Flag Bits + +4.1. Flag Bits for Type 4 (Bootstrap) + + PIM message type 4 (Bootstrap) [RFC5059] defines flag bit 7 as No- + Forward. The usage of the bit is defined in that document. The + remaining flag bits are reserved. + +4.2. Flag Bits for Type 10 (DF Election) + + PIM message type 10 (DF Election) [RFC5015] specifies that the four + most significant flag bits (bits 4-7) are to be used as a subtype. + The usage of those bits is defined in that document. The remaining + flag bits are reserved. + +4.3. Flag Bits for Type 12 (PFM) + + PIM message type 12 (PIM Flooding Mechanism) [RFC8364] defines flag + bit 7 as No-Forward. The usage of the bit is defined in that + document. The remaining flag bits are reserved. + +4.4. Flag Bits for Types 13, 14, and 15 (Type Space Extension) + + These types and the corresponding flag bits are defined in Section 5. + +5. PIM Type Space Extension + + This document defines types 13, 14, and 15, such that each of these + types has 16 subtypes, providing a total of 48 subtypes available for + future PIM extensions. This is achieved by defining a new Subtype + field (see Figure 3) using the four most significant flag bits (bits + 4-7). The notation type.subtype is used to reference these new + extended types. The remaining four flag bits (bits 0-3) are reserved + to be used by each extended type (abbreviated as FB below). + + 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 |Subtype| FB | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Subtypes + +6. Security Considerations + + 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 [RFC7761] and + [RFC3973]. + +7. IANA Considerations + + This document updates the "PIM Message Types" registry to indicate + which flag bits are defined for use by each of the PIM message types. + The registry now references this document. The registration policy + remains IETF Review [RFC8126]. Assignments into this registry MUST + define any non-default usage (see Section 4) of the flag bits in + addition to the type. + + The updated "PIM Message Types" registry is shown below. + + +------------+---------------+---------------+--------------------+ + | Type | Name | Flag Bits | Reference | + +============+===============+===============+====================+ + | 0 | Hello | 0-7: Reserved | [RFC3973][RFC7761] | + +------------+---------------+---------------+--------------------+ + | 1 | Register | 0-7: Reserved | [RFC7761] | + +------------+---------------+---------------+--------------------+ + | 2 | Register Stop | 0-7: Reserved | [RFC7761] | + +------------+---------------+---------------+--------------------+ + | 3 | Join/Prune | 0-7: Reserved | [RFC3973][RFC7761] | + +------------+---------------+---------------+--------------------+ + | 4 | Bootstrap | 0-6: Reserved | [RFC5059][RFC7761] | + | | +---------------+--------------------+ + | | | 7: No-Forward | [RFC5059] | + +------------+---------------+---------------+--------------------+ + | 5 | Assert | 0-7: Reserved | [RFC3973][RFC7761] | + +------------+---------------+---------------+--------------------+ + | 6 | Graft | 0-7: Reserved | [RFC3973] | + +------------+---------------+---------------+--------------------+ + | 7 | Graft-Ack | 0-7: Reserved | [RFC3973] | + +------------+---------------+---------------+--------------------+ + | 8 | Candidate RP | 0-7: Reserved | [RFC7761] | + | | Advertisement | | | + +------------+---------------+---------------+--------------------+ + | 9 | State Refresh | 0-7: Reserved | [RFC3973] | + +------------+---------------+---------------+--------------------+ + | 10 | DF Election | 0-3: Reserved | [RFC5015] | + | | +---------------+--------------------+ + | | | 4-7: Subtype | [RFC5015] | + +------------+---------------+---------------+--------------------+ + | 11 | ECMP Redirect | 0-7: Reserved | [RFC6754] | + +------------+---------------+---------------+--------------------+ + | 12 | PIM Flooding | 0-6: Reserved | [RFC8364] | + | | Mechanism +---------------+--------------------+ + | | | 7: No-Forward | [RFC8364] | + +------------+---------------+---------------+--------------------+ + | 13.0-15.15 | Unassigned | 0-3: | RFC 8736 | + | | | Unassigned | | + +------------+---------------+---------------+--------------------+ + + Table 1: Updated PIM Message Types Registry + + The unassigned types above, as explained in Section 5, use the + extended type notation of type.subtype. Each extended type only has + 4 flag bits available. New extended message types should be assigned + consecutively, starting with 13.0, then 13.1, etc. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., + Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent + Multicast - Sparse Mode (PIM-SM): Protocol Specification + (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March + 2016, <https://www.rfc-editor.org/info/rfc7761>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +8.2. Informative References + + [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol + Independent Multicast - Dense Mode (PIM-DM): Protocol + Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, + January 2005, <https://www.rfc-editor.org/info/rfc3973>. + + [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, + "Bidirectional Protocol Independent Multicast (BIDIR- + PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, + <https://www.rfc-editor.org/info/rfc5015>. + + [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, + "Bootstrap Router (BSR) Mechanism for Protocol Independent + Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January + 2008, <https://www.rfc-editor.org/info/rfc5059>. + + [RFC6166] Venaas, S., "A Registry for PIM Message Types", RFC 6166, + DOI 10.17487/RFC6166, April 2011, + <https://www.rfc-editor.org/info/rfc6166>. + + [RFC6754] Cai, Y., Wei, L., Ou, H., Arya, V., and S. Jethwani, + "Protocol Independent Multicast Equal-Cost Multipath + (ECMP) Redirect", RFC 6754, DOI 10.17487/RFC6754, October + 2012, <https://www.rfc-editor.org/info/rfc6754>. + + [RFC8364] Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM + Flooding Mechanism (PFM) and Source Discovery (SD)", + RFC 8364, DOI 10.17487/RFC8364, March 2018, + <https://www.rfc-editor.org/info/rfc8364>. + +Authors' Addresses + + Stig Venaas + Cisco Systems, Inc. + Tasman Drive + San Jose, CA 95134 + United States of America + + Email: stig@cisco.com + + + Alvaro Retana + Futurewei Technologies, Inc. + 2330 Central Expressway + Santa Clara, CA 95050 + United States of America + + Email: alvaro.retana@futurewei.com |