RFC 8736: PIM Message Type Space Extension and Reserved Bits

RFC 8736	PIM Type Extension and Reserved Bits	February 2020
Venaas & Retana	Standards Track	[Page]

摘要

PIM 版本 2 消息共享通用的消息标头格式。公共标头定义包含八个保留位。本文档指定了各个消息类型如何使用这些位，并创建一个包含每个消息类型用法的注册表。本文档还通过定义三种新的消息类型来扩展 PIM 类型空间。对于每种新类型，之前保留的四个位用于形成扩展类型范围。¶

本文档通过定义 PIM 公共标头中当前保留字段的使用来更新 RFC 7761 和 3973。本文档通过指定每个 PIM 消息当前保留位的使用，进一步更新了 RFC 7761 和 3973，以及 RFC 5015、5059、6754 和 8364。¶

本文档废弃了 RFC 6166。¶

本备忘录的状态

这是一份互联网标准跟踪文档。¶

本文档是互联网工程任务组 (IETF) 的产品。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准发布。有关互联网标准的更多信息，请参阅 RFC 7841 第 2 节。¶

有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8736。¶

版权声明

本文档受本文档发布之日生效的 BCP 78 和 IETF Trust 与 IETF 文件相关的法律规定 (https://trustee.ietf.org/license-info) 的约束。请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。从本文档中提取的代码组件必须包括信托法律条款第 4.e 节中所述的简化 BSD 许可文本，并且在提供时不提供简化 BSD 许可中所述的保证。¶

1. 简介

PIM 版本 2 消息共享 PIM 稀疏模式规范 [RFC7761] 中定义的通用消息头格式。公共标头定义包含八个保留位。虽然所有消息类型都使用此通用标头，但没有文档正式指定每个消息类型要使用这些位。¶

本文档将公共 PIM 标头 [RFC7761] 中指定为“保留”的位称为“PIM 消息类型标志位”，或者简称为“标志位”，并且它指定它们将在每个消息类型的基础上单独使用。它创建一个包含每个消息类型使用情况的注册表。¶

本文档通过定义 PIM 中当前保留字段的使用来更新 [RFC7761] 和 [RFC3973]公共标头。本文档进一步更新了 [RFC7761] 和 [RFC3973]，以及 [RFC5015 ]、[RFC5059]、[RFC6754] 和 [RFC83641>]0>，通过指定每个 PIM 消息当前保留位的使用。¶2>

当前定义的 PIM 消息类型范围为 0 到 15。那种类型的空间几乎耗尽了。消息类型 15 被 [RFC6166] 保留用于类型空间扩展。在第5节中，本文档指定了消息类型13、14和15的标志位的使用，以扩展PIM类型空间。本文档废弃了 [RFC6166]。¶

3. PIM 标头通用格式

通用 PIM 标头在 [RFC7761] 的 Section 4.9 中定义。本文档更新了保留字段的定义，并将该字段称为“PIM 消息类型标志位”，或者简称为“标志位”。新的通用标头格式如下。¶

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 1:新通用标头

标志位字段在第 4 节中定义。所有其他字段保持不变。¶

4. 标志位定义

除非另有说明，每种 PIM 类型的所有标志位均保留[RFC8126]。它们在传输时必须设置为零，并且在接收时必须被忽略。新 PIM 类型的规范必须指示是否应以不同方式处理这些位。¶

定义标志位时，采用明确定义的方式来引用特定位会很有帮助。标志位的最高有效位（紧跟在类型字段之后的位）被称为位 7。最低有效位（校验和字段前面的位）称为位 0。如下图所示。¶

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图2:标志位

4.1. 类型 4（引导程序）的标志位

PIM 消息类型 4（引导）[RFC5059] 将标志位 7 定义为不转发。该文件中定义了该位的用法。其余标志位保留。¶

4.2. 类型 10 的标志位（DF 选择）

PIM 消息类型 10（DF 选择）[RFC5015] 指定四个最高有效标志位（位 4-7）将用作子类型。该文档中定义了这些位的用法。其余标志位保留。¶

4.3. 类型 12 (PFM) 的标志位

PIM 消息类型 12（PIM 泛洪机制）[RFC8364] 将标志位 7 定义为不转发。该文件中定义了该位的用法。其余标志位保留。¶

4.4. 类型 13、14 和 15 的标志位（类型空间扩展）

这些类型和相应的标志位在第 5 节中定义。¶

5. PIM类型空间扩展

本文档定义了类型 13、14 和 15，其中每种类型都有 16 个子类型，总共为未来的 PIM 扩展提供了 48 个可用的子类型。这是通过使用四个最高有效标志位（位 4-7）定义新的子类型字段（参见图 3）来实现的。符号 type.subtype 用于引用这些新的扩展类型。其余四个标志位（位 0-3）保留供每个扩展类型（下面缩写为 FB）使用。¶

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 3:子类型

7. IANA 注意事项

本文档更新了“PIM 消息类型”注册表，以指示定义了哪些标志位供每种 PIM 消息类型使用。注册表现在引用该文档。注册政策仍然是 IETF 审核[RFC8126]。除了类型之外，对该注册表的分配必须定义标志位的任何非默认用法（请参阅第 4 节)。¶

更新后的“PIM 消息类型”注册表如下所示。¶

Table 1: Updated PIM Message Types Registry
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]
4	Bootstrap	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 Advertisement	0-7: Reserved	[RFC7761]
9	State Refresh	0-7: Reserved	[RFC3973]
10	DF Election	0-3: Reserved	[RFC5015]
10	DF Election	4-7: Subtype	[RFC5015]
11	ECMP Redirect	0-7: Reserved	[RFC6754]
12	PIM Flooding Mechanism	0-6: Reserved	[RFC8364]
12	PIM Flooding Mechanism	7: No-Forward	[RFC8364]
13.0-15.15	Unassigned	0-3: Unassigned	RFC 8736

上面的未分配类型，如第 5 节中所述，使用 type.subtype 的扩展类型表示法。每个扩展类型只有 4 个可用标志位。新的扩展消息类型应连续分配，从 13.0 开始，然后是 13.1，依此类推。¶

8. 参考文献

8.1. 规范性参考文献

[RFC2119]: 布拉德纳，S.、“RFC 中用于指示需求级别的关键字”、BCP 14、RFC 2119、DOI 10.17487/RFC2119 t3>、1997 年 3 月、<https://www.rfc-editor.org/info/rfc2119>。
[RFC7761]: 芬纳，B.，汉德利，M.，霍尔布鲁克，H.，库维拉斯，I.，帕里克，R., 张, Z.、郑丽、“协议独立组播 - 稀疏模式（PIM-SM）：协议规范（修订版）”、STD 83、 RFC 7761、DOI 10.17487/RFC7761、2016 年 3 月、<https://www.rfc-editor.org /info/rfc7761>。
[RFC8126]: 科顿，M.，莱巴，B. 和 T. Narten、“在 RFC 中编写 IANA 注意事项部分的指南”、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017 年 6 月、<https://www.rfc-editor.org/info/rfc8126 >。
[RFC8174]: 莱巴，B.、“RFC 2119 关键字中大写与小写的歧义”、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017 年 5 月、<https://www.rfc-editor.org/info/rfc8174>。

8.2. 信息参考

[RFC3973]: 亚当斯，A.，尼古拉斯，J. 和 W. Siadak、“协议独立组播 - 密集模式 (PIM-DM)：协议规范（修订版）”、RFC 3973、 DOI 10.17487/RFC3973,2005 年 1 月,<https://www.rfc-editor.org/info/rfc3973>.
[RFC5015]: 汉德利，M.，库维拉斯，I.，斯派克曼，T. 和 L. Vicisano、“双向协议独立组播 (BIDIR-PIM)”、RFC 5015、DOI 10.17487/RFC5015、2007 年 10 月、<https://www.rfc-editor.org/info/rfc5015>。
[RFC5059]: 巴斯卡，N.，加尔，A.，林加德，J. 和 S. Venaas、“协议独立组播 (PIM) 的引导路由器 (BSR) 机制”、RFC 5059、DOI 10.17487/RFC5059,2008 年 1 月,<https://www.rfc-editor.org/info/rfc5059>。
[RFC6166]: 韦纳斯，S.、“PIM 消息类型注册表”、RFC 6166、DOI 10.17487/RFC6166、2011 年 4 月、<https://www.rfc-editor.org/info/rfc6166>。
[RFC6754]: 蔡，Y., 魏 L., 欧 H.，艾莉亚，V. 和 S. Jethwani、“协议独立组播等价多路径 (ECMP) 重定向”、RFC 6754、DOI 10.17487/ RFC6754,2012 年 10 月,<https://www.rfc-editor.org/info/rfc6754>。
[RFC8364]: 维南兹，IJ.，维纳斯，S.，布里格，M. 和 A. Jonasson、“PIM 泛洪机制 (PFM) 和源发现 (SD)”、RFC 8364、DOI 10.17487 /RFC8364,2018 年 3 月,<https://www.rfc-editor.org/info/rfc8364>。

RFC 8736

PIM 消息类型空间扩展和保留位

摘要