3. 上下文和目标 (Context and Goal)
本节说明 RPL DAO Projection 与由根发起的路由状态 (root-initiated routing state) 的上下文和目标, 包括 P-DAO, P-DAO-ACK, P-DAO-REQ, PDR-ACK, VIO, SIO, RPI, SRH, Storing 与 Non-Storing P-Routes, Tracks, IANA 注册以及规范性行为.
3.1. RPL 适用性 (RPL Applicability)
RPL 针对电力稀缺, 带宽受限且传输不可靠的场景进行了优化. 这与当前 RPL 通常使用的 IoT LLN 用例相符, 也与网络中节点之间存在高相对移动性的场景相符, 也称为 swarming, 例如具有相似整体运动的一组可变车辆或无人机编队. 相比之下, 本规范仅适用于编队具有相对稳定拓扑的情况, 在这种拓扑中, segment 可以在一定生命周期内被赋予可靠性和可用性. 参见 [RAW-ARCH].
为实现这一目标, RPL 的主要设计目标是最小化控制平面活动, 即路由协议交换相对于数据流量的比例, 并减少每个节点中维护的状态量. RPL 不需要收敛, 并且在大多数时间为大多数节点提供连通性.
RPL 可以形成多个称为 Instance 的拓扑. 可以创建 Instance, 以通过 Objective Function 强制实施各种优化, 或通过不同的 Root 节点到达外部. Objective Function 的概念允许根据用例调整路由协议活动, 例如 LLN 链路的类型, 速度和质量.
RPL Instance 并行运行, 彼此互不感知. 不过, 可以定义一种模型: 如果在数据包当前转发所在的 Instance A 中找不到路由, 则路由器可以查找 Instance B 中的路由表, 即 RIB, 并在其中找到路由时沿 Instance B 转发. 为避免环路, 这必须以这样的方式发生: 各 Instance 自身形成一个通向最后备用 Instance 的有向无环图 (Directed Acyclic Graph, DAG). 如果认为 Instance A 比 Instance B "更高", 则最后备用 Instance 是"最低"的 Instance. 本规范使用下层 Track 作为"较低"的 Instance, 主 Instance 则是所有 Instance 中"最高"的.
RPL Root 负责选择用于将来自骨干网的数据包转发进 RPL 域的 RPL Instance, 并负责在数据包中设置相关的 RPL 信息. 每个 Instance 在参与节点中创建自己的路由表, 即 RIB, 并且与该 Instance 关联的 RIB 必须在 RPL 域中端到端使用. 为此, RPL 在 Hop-by-Hop 扩展头中使用 Instance ID 标记数据包. 6TiSCH 利用 RPL 执行其分布式路由操作.
为减少路由交换, RPL 利用各向异性的距离向量 (Distance Vector) 方法. 该方法不需要全局拓扑知识, 只优化到 RPL Root 和来自 RPL Root 的路由, 因而允许 P2P 路径被拉长. 虽然 RPL 主动安装路由, 但它只以惰性方式维护路由, 即响应实际流量或作为缓慢的后台活动.
当流量主要发往或来自某个中心节点时, 这种方式简单而高效, 例如路由器与软件定义网络 (Software-Defined Networking, SDN) 基础设施控制器之间的控制流量, 或自治控制平面 (Autonomic Control Plane, ACP) 的控制流量.
但是, P2P 路由中的路径拉长会引入额外延迟和丢包机会, 因而对可靠性和时延都有负面作用. 因此, [RPL] 不适合 RAW 用例文档 [RFC9450] 中列出的用例. 这些用例要求高可用性和高可靠性, 因而同时需要短路径和多样化路径.
3.2. 多拓扑路由和环路避免 (Multi-Topology Routing and Loop Avoidance)
RPL 首先在每个节点中形成一条指向 Root 的默认路由, 这些路由共同汇聚为一个向上的 DAG. 然后, RPL 在相反方向上构造到作为 Target 通告的目的地的路由, 沿同一个 DODAG 向下. 为此, 一个 RPL Instance 可以以 RPL Storing 或 Non-Storing MOP 运行. 指向 Root 的默认路由会被积极维护, 并且可以在数据包前进过程中改变而不导致环路, 因此数据包仍会到达 Root.
在 Non-Storing Mode 中, 每个节点直接向 Root 通告自身为 Target, 并指示可用于到达自身的 parent. Root 递归地在内存中构建并维护整个 DODAG 的映像, 并利用该抽象为沿 DODAG 向下到达目的地的数据包计算源路由路径. 当节点改变其连接到 DODAG 的一个或多个 attachment point 时, 它只需要沿默认路由向 Root 发送一个单播数据包来更新 Root, 到该节点的连通性即可立即恢复. 对于互联网连通性占主导的用例, 或 Root 控制节点中网络活动的用例, 此模式更优, 本规范即属于这种情况.
在 Storing Mode 中, 路由信息向上渗透, 每个节点维护沿 DODAG 向下通向其后代 subDAG 的路由. 维护是惰性的, 要么在收到流量时反应式触发, 要么作为缓慢的后台过程运行. 数据包经由共同 parent 流动, 与 Non-Storing MOP 相比, 路由拉长程度降低, 从而提供更好的 P2P 连通性. 但是, 新路由传播到 Root 需要更长时间, 因为距离向量协议需要逐跳运行, 并且在节点移动后, 从 Internet 到该节点的连通性恢复更慢.
无论哪种方式, RPL 路由都是由 Target 节点以分布式方式注入的. 为补充 RPL 并消除路由拉长, 本规范引入一种混合模式, 它结合 Storing 和 Non-Storing 操作, 构建路由并将其投射到应安装这些路由的节点上. 本规范使用术语 "P-Route" 指代这些路由.
在本规范最简单的模式中, 可以部署 Storing Mode P-Routes, 以补全主 DODAG 中 loose SRH 所描述跳点之间的路径. 在这种情况下, 所有路由, 包括源路由和 P-Routes, 都属于与主 Instance 关联的路由信息库 (Routing Information Base, RIB). 本规范将 Storing Mode P-Routes 称为 segment.
也可以投射一组 P-Routes, 以形成主 Instance 的点线式下层网络, 并为应用程序提供流量工程 (Traffic-Engineered) 路径. 在这种情况下, P-Routes 以 Non-Storing Mode 安装, 这一组 P-Routes 称为 Track. Track 与其自己的 RPL Instance 关联, 并且与任何 RPL Instance 一样, 也与其自己的 RIB 关联. 因此, 每个 Track 都在 RPL 域中定义一个路由拓扑. 与主 DODAG 类似, 可以部署与 Track Instance 关联的 segment, 使用表示为 Storing Mode P-Routes 的 segment, 在 loose source routing 跳点之间建立完整路径.
除非应用严格规则, 否则多拓扑域中的路由可能导致环路. 本规范定义两个严格顺序, 以确保在 RPL 域中使用 P-Routes 时避免环路: 一个顺序位于转发方法之间, 另一个顺序位于作为路由拓扑的 RPL Instance 之间.
第一个顺序是严格且完整的, 它与转发方法有关, 更具体地说, 与下一跳计算所使用信息的来源有关. 可能的转发方法为: 1. 转发到直接下一跳, 2. 经由共同邻居转发到间接邻居, 3. 沿 segment 转发, 4. 沿嵌套 Track 转发. 这些方法按上述列表严格排序. 更多内容参见第 6.7 节. 一种转发方法可以利用任何较低顺序的方法, 但绝不能利用较高顺序的方法. 例如, 当沿 segment 转发数据包时, 路由器可以使用直接或间接邻居, 但不能使用 Track. 较低顺序的方法具有严格优先级, 因此路由器总是优先选择直接邻居而非间接邻居, 也总是优先选择当前 RPL Instance 内的 segment 而非另一个 Track.
第二个顺序是严格且部分的, 适用于 RPL Instance 之间. 它允许 RPL 节点检测 PCE 安装的状态中的错误, 例如不同步之后的错误. 该顺序必须由 RPL 域管理员定义, 并定义一个以下层 RPL Instance 为节点且以主 Instance 为 Root 的 DODAG. RPL Instance 之间的关系可以表示为一个 Instance DODAG, 其中主 Instance 是 Root. 规则是: 当且仅当另一个 RPL Instance 是图中该 Instance 的后代时, 一个 RPL Instance 才可以将另一个 RPL Instance 用作下层网络. 对嵌套 Track 支持此方法是 OPTIONAL, 在 Track Instance 与主 Instance 之间支持此方法是 REQUIRED. 这可以通过网络管理或本规范的未来扩展来完成. 当未提供下层 Instance 的 DODAG 时, RPL 节点默认认为所有 Track Instance 都是主 Instance 的子节点, 并且不会尝试验证嵌套 Track 的顺序, 而是隐式信任 PCE. 因此, 沿主 Instance 转发的数据包可以封装到任何 Track 中, 但已经沿某个 Track 转发的数据包 MUST NOT 再沿主 Instance 的默认路由转发.
3.3. 需求 (Requirements)
3.3.1. 松散源路由 (Loose Source Routing)
在高度受限的 LLN 中运行的 RPL 实现通常使用 Non-Storing MOP, 如图 2 所示. 在该模式中, RPL 节点使用从该节点直接单播到 Root 的目标通告对象 (Destination Advertisement Object, DAO), 向 Root 指示 parent-child 关系. Root 通常通过递归拼接这些信息, 构建沿 DODAG 向下到达目的地的源路由路径.
+-----+
| | Border Router
| | (RPL Root)
+-----+ ^ | |
| | DAO | ACK |
o o o o | | | Strict
o o o o o o o o o | | | Source
o o o o o o o o o o | | | Route
o o o o o o o o o | | |
o o o o o o o o | v v
o o o o
LLN
Figure 2: RPL Non-Storing Mode of Operation
基于 Non-Storing DAO 消息中表达的 parent-children 关系, Root 拥有关于整个网络的拓扑信息, 但这些信息仅限于以 Root 为目的地的 DODAG 结构. 域内生成的数据包总会到达 Root. 如果目的地也在该 DODAG 中, Root 随后可以应用源路由信息到达目的地. 类似地, 对于预期位于 RPL 域中的目的地, 从域外进入的数据包也会到达 Root. 这使得 Root 附近的无线带宽成为发往该域或在该域内传输的所有传输的限制因素, 并且 Root 成为到其域内节点的所有连通性的单点故障.
RPL Root 必须为所有下行数据包添加 Source Routing Header. 随着网络增长, Source Routing Header 的大小会随网络深度增加. 在某些用例中, RPL 网络会沿照明街道等物理结构形成长线. 限制数据包大小有利于能量预算, 既直接减少当前传输的能耗, 也间接降低帧丢失和重试所消耗的能量, 例如第 2 层单跳 ARQ 或上层端到端重试. 使用更小的数据包也会降低数据包分片的可能性. 分片对 LLN 操作非常有害, 尤其是在片段被转发但未被恢复时. 更多细节可比较 [RFC8930] 与 [RFC8931].
少量目标明确的路由状态可使源路由操作成为 loose 而非 strict, 并减少数据包中的路由信息开销. 因为每个节点存储路由状态的能力有限, 哪条路由安装在哪里只能通过系统全局知识进行优化. Root 或关联的 PCE 可能通过本规范范围之外的方式拥有这些知识.
在 Non-Storing Mode 中, Root 位于所有数据包路径上, 因而可以确定其 RPL 域内每个源和目的地的 P2P 数据包数量, 产生的时延, 以及为到达 Root 再向下返回而消耗的能量和带宽, 包括封装较大数据包时可能产生的分片. 对于选定的 P2P 源和目的地, 启用不经过 Root 的更短路径可能改善时延, 降低受限资源消耗, 释放 Root 附近瓶颈处的带宽, 提高交付率, 并降低这些 P2P 流的时延. 通过降低 Root 负载, 这将为所有流带来全局收益.
为限制深层网络中对 RPL Source Route Header 的需求, 一种可能方式是在路径下游选定的 RPL 路由器中存储与主 DODAG 关联的路由状态. Root 可以从其 RPL Source Route Header 中省略已安装在网络中的路由器序列, 因而该 Source Route Header 变为 loose, 与 [RPL] 中 strict 的情况相对.
3.3.2. 前向路由 (Forward Routes)
[RPL] 优化从 Root 出发的 P2MP 路由, 指向 Root 的 MP2P 路由, 以及当 Root 同时充当边界路由器时从 RPL 域外到域内或从域内到域外的路由. 所有路由都沿 RPL DODAG 以 North-South, 即 up/down, 方式安装. RPL 网络中的 Peer-to-Peer 前向路由通常会经历拉长的路径而非直接的优化路径, 因为两个节点之间的路由总是经由共同 parent, 如图 3 所示:
------+---------
| Internet
+-----+
| | Border Router
| | (RPL Root)
+-----+
X
^ v o o
^ o o v o o o o o
^ o o o v o o o o o
^ o o v o o o o o
S o o o D o o o
o o o o
LLN
Figure 3: Routing Stretch Between S and D via Common Parent X
Along North-South Paths
如 [RFC9008] 所述, 拉长程度取决于 MOP:
-
在 Non-Storing Mode 中, DODAG 内路由的所有数据包都会一路上行到 DODAG 的 Root. 如果目的地位于同一 DODAG 中, Root 必须封装数据包以放置 RH, 其中包含沿 DODAG 向下到目的地的 strict source route 信息. 即使目的地相对靠近源且 Root 相对较远, 也会如此.
-
在 Storing Mode 中, 除非目的地是源的 child, 否则数据包同样会沿默认路由上行 DODAG. 如果目的地位于同一 DODAG 中, 数据包最终会到达拥有到该目的地路由的共同 parent. 在最坏情况下, 该共同 parent 也可能是 Root. 从该共同 parent 开始, 数据包将沿 DODAG 向下走一条按用于构建 DODAG 的 Objective Function 优化的路径.
事实证明, 当 RPL 路由相对于最短路径存在拉长, 或者新路由按不同目标进行工程化时, 启用直接 P2P 路由通常有益. 这一点在 Non-Storing Mode 中比在 Storing Mode 中更关键, 因为其路由拉长更大. 因此, IETF 早期引入了工作成果 "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks" [RFC6997], 该文档规定了一种建立优化 P2P 路由的分布式方法. 本规范提出一种基于集中式路由计算的替代方案.
+-----+
| | Border Router
| | (RPL Root)
+-----+
|
o o o o
o o o o o o o o o
o o o o o o o o o o
o o o o o o o o o
S>>A>>>B>>C>>>D o o o
o o o o
LLN
Figure 4: More Direct Forward Route Between S and D
需求是在 RPL 路由器中安装额外路由, 以减少某些 P2P 路由的拉长程度, 并将特性维持在给定服务级别目标 (Service Level Objective, SLO) 内, 例如时延和/或可靠性方面.
3.4. 关于 Track (On Tracks)
3.4.1. 使用 RPL 构建 Track (Building Tracks with RPL)
Track 概念在 6TiSCH 架构 [RFC9030] 中引入, 表示一组潜在 protection path, 这些路径沿途利用冗余转发解决方案. 它可以是 DODAG, 也可以是更复杂且仅部分无环的结构, 例如按数据包无环.
在本规范中, Track 被塑造为 DODAG, 沿有向边前进会到达 Track ingress. Storing Mode P-DAO 消息沿边的方向传播, 为反向流动的流量设置路由, 即朝向一个或多个 Track egress 的流量. 如果只有一个 Track egress, 则 Track 是可逆的, 可以通过反转每条边的方向形成另一个 DODAG. 位于 Track 中多个 segment 入口的节点可以使用这些 segment 中的一个或多个在 Track 内转发数据包.
RPL Track 是按 ingress 到 egress 顺序排列的一组或多组并行 loose source-routed 节点序列, 每个序列形成一个 protection path. Track 中的节点可以直接连接, 可以经由现有 Track 到达, 如第 3.5.2.3 节所示, 也可以通过其他节点的 strict segment 连接, 如第 3.5.1.3 节所示. Protection path 以 RPL Non-Storing Mode 表达, 并需要封装以添加 RPL Source Route Header, 而 segment 以 RPL Storing Mode 表达.
一条 path 只在 ingress 与 egress 之间提供一条路径. 它恰好包含一个 protection path. 独立 segment 隐式定义一条从其 ingress 到 egress 的 path.
Complex Track 形成一个图, 该图提供一组潜在路径, 以便为数据包提供冗余. 这可以是一组在某些点并行或交织的 protection path, 也可以是更通用的 DODAG.
3.4.2. Track 和 RPL Instance (Tracks and RPL Instances)
[RPL] 第 5.1 节描述了 RPL Instance 及其编码. 最多可以有 128 个 Global RPL Instance, 每个可有一个或多个 DODAG. 也可以有 64 个 Local RPL Instance, 其命名空间由 DODAGID 索引, 其中 DODAGID 是 DODAG Root 的唯一本地地址 (Unique Local Address, ULA) 或全局单播地址 (Global Unicast Address, GUA). 如图 5 所示, bit 0, 即最高有效位, 被设置为 1 以表示 Local RPLInstanceID. 扩展地, 本规范将 RPLInstanceID 的值表示为 128 到 191 之间的单个整数, 该整数同时表示最右侧比特中的 0..63 Local RPLInstanceID 和已置位的 bit 0.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+
| |
\ \
\ Bit 1 is set to 0 in TrackIDs
Bit 0 set to 1 signals a Local RPLInstanceID
Figure 5: Local RPLInstanceID Encoding
Track 通常形成主 Instance 的 underlay, 并与一个 Local RPL Instance 关联, 该 Instance 的 RPLInstanceID 被用作 TrackID. 当数据包被放置到 Track 上时, 它会以 IP-in-IP 方式封装, 并带有一个包含 RPL Packet Information (RPI) 的 RPL Option, 用于指示 RPLInstanceID. 封装源 IP 地址和 RPI Instance 分别设置为 Track ingress IP 地址和 Local RPLInstanceID. 更多内容参见第 6.3 节.
Track 通常跨多个 protection path 提供服务保护. 作为 Track 的退化形式, 由单个 protection path 构成的 path, 即不提供保护的 path, 可用作 segment 的替代方案, 用于沿 RPL Instance 转发. 在这种情况下, 数据包不沿 Instance 的原生路由前进, 而是被封装, 以在被封装的 Source Routing Header 中指示 loose hop 之间更具体的 source-routed path.
如果被封装的数据包遵循 Global Instance, 则 protection path 也可以是该 Global Instance 的一部分, 例如主 DODAG 的 Global Instance. 这只能用于 Global Instance, 因为在 protection path 上封装数据包的 ingress 节点不是该 Instance 的 Root, 因而被封装数据包的源地址无法用于沿途确定 Track.
3.5. 路径信令 (Path Signaling)
本规范支持沿 protection path 或 segment 设置 P-Route. P-Route 由主 DODAG 的 Root 使用扩展 RPL DAO 消息进行安装和维护, 该消息称为 P-DAO. Track 由一个或多个 P-Route 的组合构成. 为阐明可用于安装 P-Route 的技术, 本节使用图 6 所示路径的简单情况. 因此, 目标是为发往 E 的邻居 F 和 G 的数据包, 沿 A, B, C, D 和 E 构建一条从节点 A 到 E 的路径, 而不是经由 Root:
/===> F
A ===> B ===> C ===> D===> E <
\===> G
Figure 6: Reference Track
用于 Track 的 P-DAO 消息在 RPLInstanceID 字段中指示 TrackID. 对于 Local RPL Instance, Track ingress 的地址被用作沿 Track 封装数据包的源地址. Track 在 P-DAO Base Object 的 DODAGID 字段中指示. 参见图 8.
本规范引入 Via Information Option (VIO), 用于在 P-DAO 消息中指示 protection path 或 segment 中的一系列跳点, 可用于 Storing Mode (SM-VIO) 或 Non-Storing Mode (NSM-VIO). 一个 P-DAO 消息包含一个 VIO, 该 VIO 与一个或多个 RPL Target Option 关联, 后者指示可沿 Track 到达的目的 IPv6 地址. 更多内容参见第 5.3 节.
在更深入讨论 Track 和 segment 信令及操作之前, 本节通过一个简单示例的若干变体说明 route projection 如何工作. 这个简单示例展示 host route 的情况, 但 RPL Target 也可以是 prefix.
按约定, 本文使用 ==> 表示 strict hop, 使用 --> 表示 loose hop. 本文使用 "-to-" 表示逗号分隔的 Target, 例如 C==>D==>E-to-F 表示 F 是 segment C==>D==>E 的 Target. 在下面的示例中, A 是 Track ingress, E 是 Track egress. C 是 stitching point. F 和 G 是 Track 的"外部" Target, 并且可从 A 经由 Track A, 即 ingress, 到 E, 即 egress 和 Non-Storing Mode 中的隐式 Target, 再到 F 和 G, 即显式 Target, 到达.
一般而言, 期望结果如下:
- Target 为 E, F 和 G.
- P-DAO 1 指示 C==>D==>E.
- P-DAO 2 指示 A==>B==>C.
- P-DAO 3 指示 F 和 G 经由 A-->E Track.
如果 P-DAO 1 和 P-DAO 2 将 F 和 G 指示为 Target, 则可以省略 P-DAO 3.
Loose hop 序列以 Non-Storing Mode 表达. 因此, P-DAO 3 包含 NSM-VIO. 在本规范中:
- ingress 用作源地址的 DODAGID 在 DAO Base Object 中指示, 参见图 8.
- VIO 中的 via list 被编码为 SRH-6LoRH, 参见图 16, 并以 loose hop 序列中 ingress 节点之后的第一跳节点地址开始.
- via list 以 egress 节点地址结束.
Note 1: Non-Storing Mode P-Route 的 egress 隐式为 Target. 它不会列在 RPL Target Option 中, 但仍按列入处理. 唯一例外是 egress 是 VIO 中列出的唯一地址时, 因为这会表示经由其自身, 没有意义.
Note 2: 按设计, Non-Storing Mode 中 VIO 的节点列表正是封装 SRH 中出现的列表. 因此, 在下面详述的情况中, 如果 P-DAO 的 Mode 为 Non-Storing, 则 VIO 行也可理解为指示 SRH.
3.5.1. 使用 Storing Mode Segment (Using Storing Mode Segments)
A==>B==>C 和 C==>D==>E 是同一 Track 的 segment. 注意, Storing Mode 信令要求 segment 中严格连续, 因为 P-DAO 像传统 DAO 一样逐跳传递, 沿其所指示数据路径的反向前进. Strict routing 的一个好处是可避免 Track 内环路.
3.5.1.1. 拼接 Segment (Stitched Segments)
在这种表述中:
- P-DAO 1 指示 C==>D==>E-to-F,G.
- P-DAO 2 指示 A==>B==>C-to-F,G.
Storing Mode P-DAO 1 被发送到 E, 成功确认后, Storing Mode P-DAO 2 被发送到 C, 如下所示:
+====================+==============+==============+
| Field | P-DAO 1 to E | P-DAO 2 to C |
+====================+==============+==============+
| Mode | Storing | Storing |
+====================+--------------+--------------+
| Track ingress | A | A |
+====================+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) |
+====================+--------------+--------------+
| SegmentID | 1 | 2 |
+====================+--------------+--------------+
| VIO | C, D, E | A, B, C |
+====================+--------------+--------------+
| Targets | F, G | F, G |
+====================+--------------+--------------+
Table 1: P-DAO Messages
因此, RIB 设置如下:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 1 | E | (A, 129) |
+------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+
Table 2: RIB Settings
Note: 本文档各表中使用 " 符号表示与上一行相同的值.
源自 A 并发往 F 或 G 的数据包不需要封装, 因为 RPI 可以放置在原生 header chain 中. 对于 A 路由的数据包, A 必须封装以添加指示 TrackID 的 RPI. 沿 Track 转发的数据包的外层头部具有如下设置:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | A | F or G | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Inner | Any but A | F or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 3: Packet Header Settings
例如, 假设 A 有一个发往 F 的数据包. 使用表 2 中的 RIB:
- 来自 P-DAO 2: A 转发到 B, B 转发到 C.
- 来自 P-DAO 1: C 转发到 D, D 转发到 E.
- 来自 Neighbor Cache Entry: E 将数据包交付给 F.
3.5.1.2. 外部路由 (External Routes)
在此示例中, 如 [RFC9008] 第 4.1.1 节所讨论, 本文将 F 和 G 视为 Track 这个 DODAG 外部的目的地. 随后应用该情况下的封装指令, 更多内容参见第 6.7 节.
在这种表述中, 本文显式设置 protection path. 这会在中间跳点创建较少路由状态, 代价是需要更大的数据包以容纳 source routing:
- P-DAO 1 指示 C==>D==>E-to-E.
- P-DAO 2 指示 A==>B==>C-to-E.
- P-DAO 3 指示 F 和 G 经由 A-->E-to-F,G Track.
Storing Mode P-DAO 1 和 2 以及 Non-Storing Mode P-DAO 3 分别被发送到 E, C 和 A, 如下所示:
+====================+==============+==============+==============+
| | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Storing | Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | A | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 2 | 3 |
+====================+--------------+--------------+--------------+
| VIO | C, D, E | A, B, C | E |
+====================+--------------+--------------+--------------+
| Targets | E | E | F, G |
+====================+--------------+--------------+--------------+
Table 4: P-DAO Messages
注意, 上表中的 E 在 Storing Mode 中不是隐式 Target, 因此必须在 P-DAO 1 和 2 的 RPL Target Option (RTO) 中添加 E. 对 P-DAO 3 而言, E 也不是隐式 Target, 因为 E 是 VIO 中的唯一条目.
因此, RIB 设置如下:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 3 | E | (A, 129) |
+------+-------------+---------+-------------+----------+
Table 5: RIB Settings
从 A 到 E 的数据包不需要封装. 在下表中, 这就是为什么只有当 IPv6 源地址 X 不同于 A 时, E 才可能显示为 IPv6 目的地址. 反之, 当 IPv6 目的地址为 F 或 G 时始终执行封装. 其他目的地址不匹配此 P-Route, 因而不受封装影响.
沿 Track 转发的数据包的外层头部具有如下设置:
+========+=====================+==========================+=========+
| Header | IPv6 Source | IPv6 Destination Address | TrackID |
| | Address | | in RPI |
+========+=====================+==========================+=========+
| Outer | A | E | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Inner | X | Either F or G. If X!=A, | N/A |
| | | E is also permitted. | |
+--------+---------------------+--------------------------+---------+
Table 6: Packet Header Settings
例如, 假设 A 有一个发往 F 的数据包. 使用表 5 中的 RIB:
- 来自 P-DAO 3: A 封装数据包, 并沿 P-DAO 3 指示的 Track 发送, 使用上面的外层头部. 此时数据包目的地为 E.
- 来自 P-DAO 2: A 转发到 B, B 转发到 C.
- 来自 P-DAO 1: C 转发到 D, D 转发到 E. E 解封装数据包.
- 来自 Neighbor Cache Entry: E 将数据包交付给 F 或 G.
3.5.1.3. Segment Routing
在这种表述中, protection path 被用来组合 segment 并形成图. 数据包从一个 segment 到下一个 segment 进行 source routing, 以适配路径:
- P-DAO 1 指示 C==>D==>E-to-E.
- P-DAO 2 指示 A==>B-to-B,C.
- P-DAO 3 指示 F 和 G 经由 A-->C-->E-to-(E),F,G Track.
Storing Mode P-DAO 1 和 2 以及 Non-Storing Mode P-DAO 3 分别被发送到 E, B 和 A, 如下所示:
+====================+==============+==============+==============+
| | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Storing | Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | A | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 2 | 3 |
+====================+--------------+--------------+--------------+
| VIO | C, D, E | A, B | C, E |
+====================+--------------+--------------+--------------+
| Targets | E | B, C | F, G |
+====================+--------------+--------------+--------------+
Table 7: P-DAO Messages
注意, 上表中的 segment 可以像 P-DAO 1 示例那样终止于 loose hop, 也可以像 P-DAO 2 那样终止于前一跳. 对由 loose protection path 连接的任何 segment, 两种方法都可行. P-DAO 1 会生成更多信令, 因为 D 本可作为 segment egress, 但此处 E 是 segment egress. 其好处是可以验证 D 与 E 之间的连通性仍然存在.
因此, RIB 设置如下:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| D | E | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| C | D | P-DAO 1 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D | (A, 129) |
+------+-------------+---------+-------------+----------+
| B | C | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| A | B | P-DAO 2 | Neighbor | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | C | P-DAO 2 | B | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 3 | C, E | (A, 129) |
+------+-------------+---------+-------------+----------+
Table 8: RIB Settings
从 A 发起到 E 的数据包不需要封装, 但会携带经由 C 的 SRH. 沿 Track 转发的数据包的外层头部具有如下设置:
+========+=====================+==========================+=========+
| Header | IPv6 Source | IPv6 Destination Address | TrackID |
| | Address | | in RPI |
+========+=====================+==========================+=========+
| Outer | A | C until C then E | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Inner | X | Either F or G. If X!=A, | N/A |
| | | E is also permitted. | |
+--------+---------------------+--------------------------+---------+
Table 9: Packet Header Settings
例如, 假设 A 有一个发往 F 的数据包. 使用表 8 中的 RIB:
- 来自 P-DAO 3: A 将数据包封装到 P-DAO 3 指示的 Track 中, 使用上面的外层头部. 此时 IPv6 头部中的目的地为 C, 并且 SRH 指示最终目的地为 E.
- 来自 P-DAO 2: A 转发到 B, B 转发到 C.
- 来自 P-DAO 3: C 处理 SRH, 并将 IPv6 头部中的目的地设置为 E.
- 来自 P-DAO 1: C 转发到 D, D 转发到 E. E 解封装数据包.
- 来自 Neighbor Cache Entry: E 将数据包交付给 F 或 G.
3.5.2. 使用 Non-Storing Mode 连接 Track (Using Non-Storing Mode Joining Tracks)
在这种表述中:
- P-DAO 1 指示 C==>D==>E-to-(E),F,G.
- P-DAO 2 指示 A==>B==>C-to-(C),E,F,G.
A==>B==>C 和 C==>D==>E 是以 Non-Storing Mode P-DAO 表达的 Track.
3.5.2.1. 拼接 Track (Stitched Tracks)
Non-Storing Mode P-DAO 1 和 2 分别被发送到 C 和 A, 如下所示:
+====================+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A |
+====================+==============+==============+
| Mode | Non-Storing | Non-Storing |
+====================+--------------+--------------+
| Track ingress | C | A |
+====================+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 131) |
+====================+--------------+--------------+
| SegmentID | 1 | 1 |
+====================+--------------+--------------+
| VIO | D, E | B, C |
+====================+--------------+--------------+
| Targets | F, G | E, F, G |
+====================+--------------+--------------+
Table 10: P-DAO Messages
因此, RIB 设置如下, 其中使用 "ND" 表示该地址通过 IPv6 Neighbor Discovery [RFC4861] [RFC8505] 或等价方法发现:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | C, E, F, G | P-DAO 2 | B, C | (A, 131) |
+------+-------------+---------+-------------+----------+
Table 11: RIB Settings
从 A 发起到 E, F 和 G 的数据包可以带着 RPI 和 SRH 生成, 且无需封装. 或者, A 可以生成到 target 的原生数据包, 然后用 RPI 和 SRH 对其封装, 其中 SRH 指示通向 E 的 source-routed path, 就像它对来自另一个节点且由它路由的数据包所做的那样. 这实际上与 Non-Storing Mode RPL 网络中 Root 生成的数据包情况相同, 参见 [RFC9008] 第 8.1.3 节. 后一种方式通常更优, 因为它形成单一代码路径. 当目的地为 F 或 G 时, 它也不需要理解和处理 RPI 或 SRH. 无论哪种方式, 发往 E, F 或 G 的数据包都携带经由 B 和 C 的 SRH. 当它们到达 C 时, C 需要再次封装以添加经由 D 和 E 的 SRH. 沿 C 与 E 之间 Track 转发的数据包的封装头部具有如下设置:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | C | D until D then E | (C, |
| | | | 131) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 12: Packet Header Settings Between C and E
例如, 假设 A 有一个发往 F 的数据包. 使用表 11 中的 RIB:
- 来自 P-DAO 2: A 将目的地为 F 的数据包封装进 P-DAO 2 指示的 Track. 外层头部以 A 为源, B 为目的地, SRH 指示 C 为下一个 loose hop, RPI 指示来自 A 命名空间的 TrackID 131, 该 TrackID 与来自 C 命名空间的 TrackID 131 不同.
- 来自 SRH: B 转发的数据包以 A 为源, C 为目的地, SRH 已被消耗, RPI 指示来自 A 命名空间的 TrackID 131. C 解封装.
- 来自 P-DAO 1: C 将目的地为 F 的数据包封装进 P-DAO 1 指示的 Track. 外层头部以 C 为源, D 为目的地, SRH 指示 E 为下一个 loose hop, RPI 指示来自 C 命名空间的 TrackID 131. E 解封装.
3.5.2.2. 外部路由 (External Routes)
在这种表述中:
- P-DAO 1 指示 C==>D==>E-to-(E).
- P-DAO 2 指示 A==>B==>C-to-(C),E.
- P-DAO 3 指示 F 和 G 经由 A-->E-to-F,G Track.
Non-Storing Mode P-DAO 1 被发送到 C, Non-Storing Mode P-DAO 2 和 3 被发送到 A, 如下所示:
+====================+==============+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Non-Storing | Non-Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | C | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 1 | 1 |
+====================+--------------+--------------+--------------+
| VIO | D, E | B, C | E |
+====================+--------------+--------------+--------------+
| Targets | | E | F, G |
+====================+--------------+--------------+--------------+
Table 13: P-DAO Messages
注意, 上表中的 E 是 P-DAO 1 中的隐式 Target, C 是 P-DAO 2 中的隐式 Target. 作为 Non-Storing Mode egress 节点地址, 它们不会列在各自的 RTO 中.
因此, RIB 设置如下:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | C, E | P-DAO 2 | B, C | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | F, G | P-DAO 3 | E | (A, 141) |
+------+-------------+---------+-------------+----------+
Table 14: RIB Settings
沿 C 与 E 之间 Track 转发的数据包的封装头部具有如下设置:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | C | D until D then E | (C, |
| | | | 131) |
+--------+---------------------+--------------------------+---------+
| Middle | A | E | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 15: Packet Header Settings
例如, 假设 A 有一个发往 F 的数据包. 使用表 14 中的 RIB:
- 来自 P-DAO 3: A 将目的地为 F 的数据包封装进 P-DAO 3 指示的 Track. 外层头部以 A 为源, E 为目的地, RPI 指示来自 A 命名空间的 TrackID 141. 这会与以下过程递归.
- 来自 P-DAO 2: A 将目的地为 E 的数据包封装进 P-DAO 2 指示的 Track. 外层头部以 A 为源, B 为目的地, SRH 指示 C 为下一个 loose hop, RPI 指示来自 A 命名空间的 TrackID 129.
- 来自 SRH: B 转发的数据包以 A 为源, C 为目的地, SRH 已被消耗, RPI 指示来自 A 命名空间的 TrackID 129. C 解封装.
- 来自 P-DAO 1: C 将目的地为 E 的数据包封装进 P-DAO 1 指示的 Track. 外层头部以 C 为源, D 为目的地, SRH 指示 E 为下一个 loose hop, RPI 指示来自 C 命名空间的 TrackID 131. E 解封装.
3.5.2.3. Segment Routing
在这种表述中:
- P-DAO 1 指示 C==>D==>E-to-(E).
- P-DAO 2 指示 A==>B-to-C.
- P-DAO 3 指示 F 和 G 经由 A-->C-->E-to-(E),F,G Track.
Non-Storing Mode P-DAO 1 被发送到 C, Non-Storing Mode P-DAO 2 和 3 被发送到 A, 如下所示:
+====================+==============+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
+====================+==============+==============+==============+
| Mode | Non-Storing | Non-Storing | Non-Storing |
+====================+--------------+--------------+--------------+
| Track ingress | C | A | A |
+====================+--------------+--------------+--------------+
| (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) |
+====================+--------------+--------------+--------------+
| SegmentID | 1 | 1 | 1 |
+====================+--------------+--------------+--------------+
| VIO | D, E | B | C, E |
+====================+--------------+--------------+--------------+
| Targets | | C | F, G |
+====================+--------------+--------------+--------------+
Table 16: P-DAO Messages
因此, RIB 设置如下:
+======+=============+=========+=============+==========+
| Node | Destination | Origin | Next Hop(s) | TrackID |
+======+=============+=========+=============+==========+
| E | F, G | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| D | E | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| C | D | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | E | P-DAO 1 | D, E | (C, 131) |
+------+-------------+---------+-------------+----------+
| B | C | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| A | B | ND | Neighbor | Any |
+------+-------------+---------+-------------+----------+
| " | B, C | P-DAO 2 | C | (A, 129) |
+------+-------------+---------+-------------+----------+
| " | E, F, G | P-DAO 3 | C, E | (A, 141) |
+------+-------------+---------+-------------+----------+
Table 17: RIB Settings
沿 A 与 B 之间 Track 转发的数据包的封装头部具有如下设置:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | A | B until D then E | (A, |
| | | | 129) |
+--------+---------------------+--------------------------+---------+
| Middle | A | C | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 18: Packet Header Settings
沿 B 与 C 之间 Track 转发的数据包的封装头部具有如下设置:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | A | C | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 19: Packet Header Settings
沿 C 与 E 之间 Track 转发的数据包的封装头部具有如下设置:
+========+=====================+==========================+=========+
| Header | IPv6 Source Address | IPv6 Destination | TrackID |
| | | Address | in RPI |
+========+=====================+==========================+=========+
| Outer | C | D until D then E | (C, |
| | | | 131) |
+--------+---------------------+--------------------------+---------+
| Middle | A | E | (A, |
| | | | 141) |
+--------+---------------------+--------------------------+---------+
| Inner | X | E, F, or G | N/A |
+--------+---------------------+--------------------------+---------+
Table 20: Packet Header Settings
例如, 假设 A 有一个发往 F 的数据包. 使用表 18:
- 来自 P-DAO 3: A 将目的地为 F 的数据包封装进 P-DAO 3 指示的 Track. 外层头部以 A 为源, C 为目的地, SRH 指示 E 为下一个 loose hop, RPI 指示来自 A 命名空间的 TrackID 141. 这会与以下过程递归.
- 来自 P-DAO 2: A 将目的地为 C 的数据包封装进 P-DAO 2 指示的 Track. 外层头部以 A 为源, B 为目的地, RPI 指示来自 A 命名空间的 TrackID 129. B 解封装, 并基于 sibling connected route 转发到 C.
- 来自 SRH: C 消耗 SRH, 并使目的地成为 E.
- 来自 P-DAO 1: C 将目的地为 E 的数据包封装进 P-DAO 1 指示的 Track. 外层头部以 C 为源, D 为目的地, SRH 指示 E 为下一个 loose hop, RPI 指示来自 C 命名空间的 TrackID 131. E 解封装.
3.6. Complex Track (Complex Tracks)
为提高 P2P 传输可靠性, 本规范支持在相同 ingress 和 egress 节点之间构建一组 protection path, 并在同一 TrackID 内组合它们, 如图 7 所示. Protection path 可以在 loose hop 的边缘交织, 也可以保持并行.
连接 protection path 中 loose hop 的 segment 使用与 protection path 相同的 TrackID 安装. 但是, 每个单独的 protection path 和 segment 都有自己的 P-RouteID, 以便单独管理. 同一 Track 的两个 protection path 可以在某个共同节点交叉, 该共同节点是每个 protection path 的某个 segment 的成员, 也可以由额外 segment 连接. 因而, 数据包的最终路径可能是这两个, 以及可能更多, protection path 交织的结果. 在这种情况下, 共同节点在其与 Track 关联的 RIB 中有多个下一跳, 但数据包中没有特定信号指示正在跟随哪个 segment. 会选择一个能够到达 loose hop 的下一跳.
< Controller Plane Functions >
Southbound API
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
+----------+
| RPL Root |
+----------+
( main DODAG )
( all around )
<- Protection path 1 via B, E ->
<--- Segment 1 A,B ---> <------- Segment 2 C,D,E ------->
FWD -- Relay -- FWD -- FWD Target 1
/-- Node -- Node -- Node -- Node \ /
--/ (A) (B) \ (C) (D) \ /
Track \ Track
Ingress Segment 5 Egress -- Target
(I) \ -- (E) 2
\ \ / \
\ FWD -- FWD -- Relay -- FWD --/ \
Node -- Node -- Node -- Node Target 3
(F) (G) (H) (J)
<------ Segment 3 F,G,H ------> <---- Segment 4 J,E ---->
<- Protection path 2 via H, E ->
<--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ---->
<- Protection path 3 via B, H, E ->
)
(
( )
Figure 7: Segments and Tracks
注意, 虽然本规范支持在 protection path 内构建 segment, 例如上面的 segment 2, 它位于 protection path 1 内, 也支持构建 protection path 之间的 segment, 即 North-South segment, 例如上面的 segment 5, 它连接 protection path 1 和 2, 但本规范并不向 ingress 指示哪些 protection path 之间的 segment 可用. 因此, North-South segment 及其关联路径冗余功能的使用目前受限. 目前唯一可行的方式是定义重叠的 protection path, 如图 7 所示. 其中 protection path 3 到节点 B 为止与 protection path 1 一致, 从节点 H 开始与 protection path 2 一致, 并将 segment 5 抽象为 forward segment.
3.7. 范围和预期 (Scope and Expectations)
3.7.1. 外部依赖 (External Dependencies)
本规范预期主 DODAG 以 RPL Non-Storing Mode 运行, 以维持与 Root 的交换. 基于其对 parent-child 关系的全面了解, Root 可以形成整个 DODAG 拓扑的抽象视图. 本文档增加了节点通告额外 sibling 信息的能力, 以补充 Root 的拓扑感知并传递给 PCE, 使 PCE 能够构建更多和/或更好的穿越这些 sibling 的路径.
P-Route 需要资源, 例如路由器中的路由表空间和链路上的带宽. 安装在每个节点中的状态量必须经过计算, 以适应节点内存. 被改路由的流量量也必须适应传输链路能力. 用于获知节点能力以及设备和网络中可用资源的方法不在本文档范围内. 捕获并报告 LLN 链路容量和可靠性统计信息的方法也不在范围内. 这些信息可以通过网络管理功能或其他形式的遥测获取, 例如 Operations, Administration, and Maintenance (OAM).
3.7.2. 与其他 IETF 规范的关系 (Relationship to Other IETF Specifications)
3.7.2.1. 扩展 6TiSCH (Extending 6TiSCH)
6TiSCH 架构 [RFC9030] 利用一种与 DetNet 架构 [RFC8655] 类似的集中式模型. 在该模型中, 设备资源和能力暴露给外部控制器, 外部控制器根据自身 Objective Function 向网络安装路由状态, 这些 Objective Function 位于该外部实体中.
3.7.2.2. 映射到 DetNet (Mapping to DetNet)
DetNet 转发节点只理解沿 segment 的简单 1-to-1 转发子层传输操作, 而更复杂的 relay 节点还可以提供服务子层功能, 例如 Replication and Elimination.
DetNet 与本规范之间的一种可能映射是: 将 relay 节点指示为 protection path 的跳点, 并将 forwarding 节点指示为连接这些 relay 节点的 segment 中的跳点, 如图 7 所示.
3.7.2.3. 利用 PCE (Leveraging PCE)
在 DetNet 和 6TiSCH 中, 控制器中负责计算路由的组件是 PCE. 如 [RFC4655] 所述, PCE 根据其自身 Objective Function 计算路由, 并且通常使用 PCE Communication Protocol (PCEP) [RFC5440] 控制路由. 虽然本规范预期存在 PCE, 并且 PCEP 可能实际用于 Root 与 PCE 之间, 但 PCE 与 Root 之间的控制协议不在范围内.
本规范还预期存在一个拥有完整网络视图的单一 PCE. 为大型网络分发 PCE 功能不在范围内. 本规范使用 RPL Root 作为 PCE 的代理. PCE 可以与 Root 共置, 也可以位于外部 Controller 中. 在后一种情况下, Root 与 PCE 之间的协议不在范围内, 并映射到 DODAG 内部的 RPL. Root 与外部 PCE 之间一种可能的控制协议是: Root 将其在 RPL DAO 中收到的信息传输给 PCE, 包括所有详细描述 parent/child 和 sibling 信息的 SIO.
用于计算路径的算法, PCE 使用的协议, 以及计算涉及的 metric 和链路统计信息也不在范围内. PCE 路由计算的有效性取决于从 RPL 网络报告的 metric 质量. 使用哪些 metric 以及如何报告它们不在范围内, 但预期这些 metric 主要具有长期统计性质, 并提供相对较长时期内链路吞吐量, 时延, 稳定性和可用性的可见性.
3.7.2.4. 为 RAW 提供支持 (Providing for RAW)
RAW 架构 [RAW-ARCH] 中的 recovery graph 可以由前向 East-West 方向 segment 和 North-South 双向 segment 组成, 以便使用 PREOF 选择用于给定数据报的 protection path, 从而启用额外路径多样性. 这在流的可靠性和可用性要求与节约能量和频谱的需求之间提供动态平衡. 本规范通过设置 Track 为 RAW 做准备, 但它只形成 DODAG. 这些 DODAG 由聚合的端到端 loose source-routed protection path 组成, 通过 strict routed segment 连接, 且全部面向前向.
RAW 架构定义了 PCE 的数据平面扩展, 称为本地修复点 (Point of Local Repair, PLR), 它会调整 Track 内路径冗余的使用方式, 以应对导致数据包丢失的多种原因. PLR 控制 Track 内数据包的转发操作. 本规范可以使用 PLR, 但不强制使用 PLR, 也不提供用于选择哪些数据包通过 Track 内哪条路径路由的策略. 换言之, 本规范不规定 PLR 如何使用 Track 内的路径冗余. 默认情况下, 可用冗余的使用仅限于简单负载均衡, 并且所有 segment 都只是前向单向的.
Track 可以被设置为降低 Root 周围的负载, 或使紧急流量更直接地流动. 本规范不提供用于决定哪些流通过哪个 Track 路由的策略. 在 Non-Storing Mode RPL Instance 中, 主 DODAG 经由 Root 提供默认路由, 而 Track 提供到 Track Target 的更具体路由.