4. 扩展和修订现有 RFC (Extending and Amending Existing RFCs)
本节说明哪些变更是对现有规范的扩展, 哪些变更是对现有规范的修订. 预期对现有规范的扩展不会导致旧版 6LR 上的现有代码出错, 因为这些扩展只会被忽略. 扩展需要新代码. 这些 6LR 无法在新机制中工作, 也可能使 P-DAO 无法安装. 对现有规范的修订是指需要对现有代码进行语义变更的情况, 并且可能需要新的单元测试来确认旧版操作会继续不受影响.
4.1. 扩展 RFC 6550 (Extending RFC 6550)
本规范扩展 RPL [RPL], 使 Root 能够在以 Non-Storing Mode 运行的主 DODAG 内安装前向路由. Root 向 Track 入口发送 P-DAO 消息 (见第 4.1.1 节). P-DAO 消息包含新的 VIO, 该 VIO 分别安装严格或松散的跳序列, 用于形成 Track 段或保护路径.
Projected DAO Request (P-DAO-REQ) 是第 5.1 节详细说明的新消息. 根据 [RPL] 第 6 节, 如果节点收到该消息但不理解这个新代码, 则丢弃该消息. 当 Root 发起与某节点的通信, 而此前未曾与该节点通信, 且尚未确定该节点实现本规范 (例如通过 capabilities 等手段) 时, Root 应当 (SHOULD) 请求 Projected DAO Request Acknowledgment (PDR-ACK).
P-DAO-REQ 消息使 Track 入口能够向 Root 请求 Track. 生成的 Track 也是一个 DODAG, 其中 Track 入口是 Root, owner 是作为 DODAGID 的地址, 并对选择 TrackID 的关联命名空间具有权威性. 在本规范语境中, 已安装路由表现为到 Track Targets 的更具体路由, Track 入口使用正常的最长匹配 IP 转发, 通过 Track 将数据包转发到 Targets.
为确保 P-DAO-REQ 和 P-DAO 消息在大多数时候都能流动, 推荐 (RECOMMENDED) 参与 Track 的节点在主 DODAG 中维护多个 parent, 将它们全部通告给 Root, 并轮流使用它们重试类似数据包. 还推荐 (RECOMMENDED) Root 使用多样化的源路由路径, 向 Track 中的节点重试类似消息.
4.1.1. Projected DAO
[RPL] 第 6 节引入 RPL Control Message Options (CMO), 包括可放置在 DAO 等 RPL 消息中的 RPL Target Option (RTO) 和 Transit Information Option (TIO). DAO 消息向一个或多个 RTO 中指示的 Target 通告路由信息, 并在 TIO 中提供且只提供一个 via-node, 该 via-node 是到达 targets 的隧道端点.
本文档修订 DAO 的规范, 创建 P-DAO 消息. 这个经修订的 DAO 使用新的 "Projected DAO" (P) 标志表示. 见图 8.
P-DAO 是一种特殊 DAO 消息, 由 Root 生成, 用于在其 DODAG 中安装由多跳组成的 P-Route. 这提供了一种基于 RPL 的方法, 可按 6TiSCH 架构 [RFC9030] 的预期, 将 Tracks 安装为多个 P-Route 的集合.
Root 必须使用其作为主 DODAG 的 DODAGID 的地址作为 P-DAO 消息源地址. 接收方禁止接受并非由其 DODAG 的 Root 发送的 P-DAO 消息, 且必须静默忽略此类消息.
P 标志编码在 DAO Base Object 的 Flags 字段的 bit 2 位置. Root 必须在 P-DAO 消息中将其设置为 1. 否则, 它必须设置为 0. 在旧版实现中, 如 [RPL] 第 20.11 节和第 6.4 节分别规定, 它设置为 0.
P-DAO 是控制平面信令的一部分, 不应被高流量阻塞. 预期 P-DAO 消息以高 QoS 级别发送, 高于数据流量, 通常使用 Network Control 优先级.
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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|D|P| Flags | Reserved | DAOSequence |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| DODAGID field is set to the |
+ IPv6 address of the Track ingress +
| used to source encapsulated packets |
+ +
| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+
Figure 8: Projected DAO Base Object
新字段:
TrackID: 作为 Track 的 DODAG 的 Local 或 Global RPLInstanceID (更多内容见第 6.3 节).
P: 1-bit 标志.
P 标志由 Root 设置为 1, 用于表示 P-DAO. 否则, 它设置为 0.
D 标志设置为 1 表示存在 DODAGID 字段. 当且仅当 Projected DAO Acknowledgment (P-DAO-ACK) 消息的目标地址设置为作为 DODAGID 的 IPv6 地址时, 它可以设置为 0. 否则它必须设置为 1, 这意味着 DODAGID 字段随后必须存在.
在 RPL Non-Storing Mode 中, TIO 和 RTO 在 DAO 消息中组合使用, 用于通知 DODAG Root 关于 DODAG 中所有 edge 的信息, 这些 edge 由有向 parent-child 关系形成. DAO 消息向 Root 表示可使用给定 parent 到达给定 child. P-DAO 消息将 DAO 泛化, 向 Track 入口表示一个 Track 可用于到达 Track 出口的 children 和 siblings, 其中发送方是该 Track 的 Root. 在两种情况下, option 都可以因子化, 且可以存在多个 RTO, 分别用于表示可通过 parent 或 Track 到达的一组 children.
4.1.2. Projected DAO Acknowledgment
本文档还修订 DAO-ACK 消息. 新的 P 标志表示 projected 形式.
因此, P-DAO-ACK 消息格式如图 9 所示:
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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |D|P| Reserved | DAOSequence | Status |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| DODAGID field is set to the |
+ IPv6 address of the Track ingress +
| used to source encapsulated packets |
+ +
| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+
Figure 9: P-DAO-ACK Base Object
新字段:
TrackID: 作为 Track 的 DODAG 的 Local 或 Global RPLInstanceID (更多内容见第 6.3 节).
P: 1-bit 标志.
P 标志由 Root 设置为 1, 用于表示 P-DAO. 否则, 它设置为 0.
D 标志设置为 1 表示存在 DODAGID 字段. 当且仅当 P-DAO-ACK 消息的源地址设置为作为 DODAGID 的 IPv6 地址时, 它可以设置为 0. 否则它必须设置为 1, 这意味着 DODAGID 字段随后必须存在.
4.1.3. Via Information Option
本文档扩展 CMO, 创建称为 Via Information Option (VIO) 的新对象. VIO 是 TIO 的多跳替代形式 (更多内容见第 5.3 节). 一种 VIO 是有状态的 Storing Mode VIO (SM-VIO). SM-VIO 安装称为 Track segment 的严格逐跳 P-Route. 另一种是 Non-Storing Mode VIO (NSM-VIO). NSM-VIO 在 Track 入口安装称为 protection path 的松散源路由 P-Route, Track 入口使用该状态以新的 Routing Header (RH) 将 IP-in-IP 数据包封装到 Track 出口 (更多内容见第 6.7 节).
P-DAO 包含一个或多个 RTO, 用于指示可通过 P-Route 到达的 Target (目的地), 后跟正好一个 VIO, 用于表示应遵循的节点序列 (更多内容见第 6 节). P-Route 有两种操作模式: Storing Mode 和 Non-Storing Mode (分别见第 6.4.2 节和第 6.4.3 节).
4.1.4. Sibling Information Option
本规范扩展 CMO, 创建 Sibling Information Option (SIO). RPL-Aware Node (RAN) 使用 SIO 将其候选邻居中的一个选择集作为 siblings 通告给 Root (更多内容见第 5.4 节). SIO 放置在直接发送到主 Root 的 DAO 消息中, 包括 multicast DAO (见 [RPL] 第 9.10 节).
本规范修订 [RPL] 第 9.10 节列出的 multicast DAO 操作规则 1 和 2, 如下:
OLD:
| 1. A node MAY multicast a DAO message to the link-local scope
| all-RPL-nodes multicast address.
|
| 2. A multicast DAO message MUST be used only to advertise
| information about the node itself, i.e., prefixes directly
| connected to or owned by the node, such as a multicast group
| that the node is subscribed to or a global address owned by
| the node
NEW:
| 1. A multicast DAO message MUST be used only to advertise
| information about the node (using the Target Option) and
| direct Link Neighbors such as learned by Neighbor Discovery
| (using the SIO).
|
| 2. The multicast DAO may be used to enable direct and indirect
| (via a common neighbor) P2P communication without needing the
| DODAG to relay the packets. The multicast DAO exposes the
| sender's addresses as Targets in RTOs and the sender's
| neighbors addresses as siblings in SIOs; this tells the
| sender's neighbors that the sender is willing to act as a
| relay between those of its neighbors that are too far apart.
4.1.5. P-DAO Request
RPL Control Messages 集合被扩展为包括 P-DAO-REQ 和 PDR-ACK. 这两个新的 RPL Control Messages 使 RAN 能够请求在自身 (作为 Track ingress Node) 与 Track egress 之间建立 Track. 该节点通过向 Root 发送新的 P-DAO-REQ 消息来提出请求. Root 使用新的 PDR-ACK 消息向请求方 RAN 确认. 更多内容见第 5.1 节.
4.1.6. 修订 RPI (Amending the RPI)
在 RPL Local Instance 内发送数据包, 需要在外层 IPv6 头部链中存在 [RPL] 第 11.2 节所述的抽象 RPI (见 [RFC9008]). RPI 携带一个 Local RPLInstanceID, 该 ID 与 IPv6 头部中的源地址或目标地址关联, 指示数据包所遵循的 RPL Instance.
本规范修订 [RPL], 创建一个新标志, 用于表示数据包何时沿 P-Route 转发.
Projected-Route P: 1-bit 标志. 当数据包通过 Track 发送时, 该标志在封装中添加的 RPI 中设置为 1. 当数据包沿主 DODAG 转发 (作为 Track), 包括当数据包遵循连接主 DODAG 松散跳的段时, 该标志设置为 0. 该标志在转发途中不可变.
P 标志在原生格式中的编码见第 4.2 节, 压缩格式见第 4.3 节.
4.1.7. RPL DODAG Configuration Option 中的额外标志 (Additional Flag in the RPL DODAG Configuration Option)
DODAG Configuration option 定义于 [RPL] 第 6.7.6 节. 其用途扩展为通过 DODAG 分发影响 DODAG 构建和维护的配置信息, 以及 DODAG 上 RPL 的操作参数. 该 option 最初设计时预留了四个 bit 位置作为未来使用的 Flags.
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 = 0x04 |Opt Length = 14|D| | | |A| ... |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|4 bits |
Figure 10: DODAG Configuration Option (Partial View)
本规范修订 [RPL], 定义新的 "Projected Routes Support" (D) 标志. D 标志编码在 DODAG Configuration option 中保留 Flags 的 bit 0 位置 (即最高有效位). 在旧版实现中, 如 [RPL] 第 20.14 节和第 6.7.6 节分别规定, 它设置为 0.
D 标志设置为 1 表示本规范已在网络中启用, 且 Root 在收到 P-DAO-REQ 消息后会在可行时安装所请求的 Tracks.
[RFC9008] 第 4.1.2 节修订 [RPL], 指出 Flags 的定义只适用于 MOP 值从零 (0) 到六 (6). 对于 MOP 值 7, 实现必须认为 Root 接受 P-DAO-REQ 消息并将安装 P-Routes.
RPL DODAG Configuration option 通常放置在 DIO 消息中. DIO 消息沿 DODAG 向下传播, 用于形成并随后维护其结构. DODAG Configuration option 从 parent 到 child 原样复制.
[RPL] 说明:
| Nodes other than the DODAG root MUST NOT modify this information
| when propagating the DODAG Configuration option.
因此, 旧版 parent 会按 Root 设置的方式传播 D 标志, 并且当 D 标志设置为 1 时, 它会透明地泛洪到 DODAG 中的所有节点.
4.2. 扩展 RFC 6553 (Extending RFC 6553)
"The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams" [RFC6553] 描述了 RPL Option, 供 RPL 路由器在数据包中包含 [RPL] 第 11.2 节所述的抽象 RPI.
RPL Option 通常被称为 RPI, 尽管 RPI 实际上是在 RPL Option 中传输的抽象信息. [RFC9008] 将 Option Type 从 0x63 更新为 0x23.
本规范扩展 RPL Option, 按如下方式编码 P 标志:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Amended RPL Option Format
Option Type: 0x23 或 0x63. 见 [RFC9008].
Opt Data Len: 见 [RFC6553].
O, R 和 F 标志: 见 [RFC6553]. 如果 P 标志已设置, 发送方必须将这些标志设置为 0, 接收方必须忽略这些标志.
Projected-Route P: 第 4.1.6 节定义的 1-bit 标志.
RPLInstanceID: 见 [RFC6553]. 如果 P 标志已设置, 则指示 TrackID, 如第 4.1.1 节所讨论.
SenderRank: 见 [RFC6553]. 如果 P 标志已设置, 发送方必须将该字段设置为 0, 接收方必须忽略该字段.
4.3. 扩展 RFC 8138 (Extending RFC 8138)
6LoWPAN Routing Header 规范 [RFC8138] 引入一种新的 6LoWPAN [RFC6282] dispatch type, 用于 6LoWPAN route-over 拓扑, 其最初覆盖 RPL 数据包压缩的需求.
[RFC8138] 第 4 节以两种形式给出 6LoRH 的通用格式: Elective 和 Critical. 当路由器不理解 Elective 形式时, 可以忽略并跳过它. 当路由器无法处理 Critical 形式时, 会导致数据包被丢弃. 6LoRH 中的 E 标志指示其形式. 为了跳过 Elective 6LoRH, 其格式强制使用固定的大小表达式, 而 Critical 6LoRH 的大小可以用可变形式表示, 以支持额外优化.
当使用 [RFC8138] 所述压缩时, 设置 Track 的主 DODAG 的 Root 也代表 Track 入口构造压缩 Routing Header (SRH-6LoRH), 这避免了在受限代码中优化 SRH-6LoRH 编码的复杂性. 在这种情况下, SRH-6LoRH 在 NSM-VIO 中表示, 并以可由 Track 入口原样放入数据包封装的方式表达.
[RFC8138] 第 6.3 节给出了 type 5 的 6LoWPAN RH (RPI-6LoRH) 格式, 它压缩正常 RPL 操作的 RPI. RPI-6LoRH 的格式不适合 P-Routes, 因为不使用 O, R 和 F 标志, 且 Rank 未知并被忽略.
本规范扩展 [RFC8138], 引入新的 6LoRH, 即 P-RPI-6LoRH, 它可用于 Elective 或 Critical 6LoRH 形式. 分别见表 22 和表 23. 新 6LoRH 必须用作 Critical 6LoRH, 除非存在 SRH-6LoRH 且由其控制路由决策, 在这种情况下可以 (MAY) 使用 Elective 形式.
P-RPI-6LoRH 旨在沿 RPL P-Routes 压缩 RPI. 其格式如下:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|E| Length | 6LoRH Type | RPLInstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: P-RPI-6LoRH Format
6LoRH Type: IANA 已为 Elective 和 Critical 两种形式定义值 8.
Elective E: 见 [RFC8138]. E 标志设置为 1 表示 Elective 6LoRH, 即转发时可以忽略它.
RPLInstanceID: 在本规范语境中, RPLInstanceID 字段表示 TrackID. 见第 3.4 节和第 6.3 节.
第 6.8 节详细说明 Track 入口如何利用 P-RPI-6LoRH 头部作为数据包封装的一部分, 将数据包放入 Track.