1.1. 设计原则 (Design Principles)

RPL 的设计目标是满足 [RFC5867], [RFC5826], [RFC5673] 和 [RFC5548] 中明确提出的需求.

一个网络可以同时运行多个 RPL 实例. 每个实例可以服务于不同的约束或性能标准, 这些约束或标准甚至可能彼此冲突. 本文档定义单个实例的运行方式.

为了适用于广泛的 LLN 应用领域, RPL 将分组处理和转发与路由优化目标分离. 这类目标的示例包括最小化能耗, 最小化时延, 或满足特定约束. 本文档描述 RPL 的运行模式. 其他配套文档规定路由目标函数 (Objective Functions). 为了支持特定 LLN 应用, RPL 实现将包含该应用所需的目标函数.

RPL 的运行需要双向链路. 在某些 LLN 场景中, 这些链路可能表现出非对称属性. 路由器在被用作父节点之前, 必须验证其可达性. RPL 期望在父节点选择阶段触发外部机制, 以验证链路属性和邻居可达性. 邻居不可达检测 (Neighbor Unreachability Detection, NUD) 就是这样一种机制, 也可以使用其他替代机制, 包括双向转发检测 (Bidirectional Forwarding Detection, BFD) [RFC5881], 以及来自较低层的提示, 例如通过 [RFC5184] 这类第 2 层 (Layer 2, L2) 触发器提供的提示. 一般而言, 更倾向于使用对流量有响应的检测机制, 以最大限度降低监测未使用链路的成本.

RPL 还期望存在一种外部机制, 用于在数据分组中访问并传输某些控制信息, 这些信息称为 "RPL 分组信息 (RPL Packet Information)". RPL 分组信息在第 11.2 节中定义, 它支持将数据分组与某个 RPL 实例关联起来, 并验证 RPL 路由状态. RPL 选项 [RFC6553] 就是这类机制的一个示例. 除严格源路由的情况外, 所有分组都需要该机制. 严格源路由即第 9 节进一步说明的非存储模式 (Non-Storing mode) 下向下 (Downward) 传送的分组, 其固有特性可防止无休止的环路, 并减少对 RPL 分组信息的需求. 未来的配套规范可能会提出在 IPv6 分组中携带 RPL 分组信息的其他方式, 并可能扩展 RPL 分组信息以支持更多特性.

RPL 提供了一种机制, 用于在动态形成的网络拓扑上分发信息. 这种分发使节点只需最少配置, 从而允许节点大体上自主运行. 如第 8.3 节所述, 该机制使用 Trickle [RFC6206] 来优化分发过程.

在某些应用中, RPL 会组建由拥有独立前缀的路由器构成的拓扑. 这些前缀是否可以聚合取决于路由器的来源. 路由器拥有的前缀会被通告为链路内 (on-link).

RPL 还引入了一种能力, 可以将一个子网与公共前缀绑定在一起, 并在该子网内进行路由. 某个源可以注入关于该子网的信息, 供 RPL 分发, 且该源是该子网的权威来源. 由于许多 LLN 链路具有非传递属性, RPL 在子网上分发的公共前缀不得被通告为链路内.

具体而言, RPL 可以分发 IPv6 邻居发现 (IPv6 Neighbor Discovery, ND) 信息, 例如 [RFC4861] 前缀信息选项 (Prefix Information Option, PIO) 和 [RFC4191] 路由信息选项 (Route Information Option, RIO). 由 RPL 分发的 ND 信息会保留其原有的路由器到主机语义, 并针对路由器到路由器场景作有限扩展. 不过, 这不应与路由通告混淆, 也绝不能被直接重新分发到另一个路由协议中. RPL 节点通常同时具备主机和路由器行为. 作为主机时, 它会按照 [RFC4191], [RFC4861], [RFC4862] 和 [RFC6275] 的规定处理这些选项. 作为路由器时, RPL 节点可以按照特定链路的需要通告这些选项中的信息, 例如在 ND 路由器通告 (Router Advertisement, RA) 消息中通告, 但具体操作超出本文档范围.

本规范的一组配套文档将以适用性声明 (applicability statements) 的形式提供进一步指导, 规定适用于楼宇自动化, 家庭自动化, 工业和城市应用场景的一组运行点.