跳到主要内容

3. DetNet 控制平面架构 (DetNet Control Plane Architecture)

如简介所述, DetNet Control Plane 负责 flow 的实例化和维护, flow 相关信息 (例如 MPLS 标签) 的分配和分发, 以及用于支持这些功能的主动带内或带外信息分发.

以下各节定义三类 DetNet Control Plane 架构: 1) 使用动态信令协议的完全分布式控制平面, 2) 完全集中式的 SDN-like 控制平面, 以及 3) 同时包含分布式协议和集中式控制的混合控制平面. 本文档描述每类架构中网络实体之间的各种信息交换, 以及对应的优点和缺点.

以下各节中的示例说明了可在每类架构中使用的可能机制. 这些示例并非穷尽性列举, 也不排除使用其他可能机制来替代示例中的机制.

3.1. 分布式控制平面和信令协议 (Distributed Control Plane and Signaling Protocols)​

在完全分布式配置模型中, User-Network Interface (UNI) 信息通过 DetNet UNI 协议从用户侧传输到网络侧. 随后, UNI 和网络配置信息通过分布式控制平面信令协议在网络中传播. 当终端系统具备 DetNet 能力时, 此类 DetNet UNI 协议并非必需.

以一个 RSVP-TE [RFC3209] MPLS 网络为例, 其中终端系统不属于 DetNet 域:

  1. 网络节点通过 IGP 收集网络节点的拓扑信息和 DetNet 能力.

  2. 入口边缘节点从 UNI 接收 flow 建立请求, 并计算一条或多条有效路径.

  3. 入口节点通过 RSVP-TE 发送带有显式路由的 PATH 消息. 出口边缘节点收到 PATH 消息后, 发送带有已分发标签和资源预留请求的 RESV 消息.

在此示例中, IGP 和 RSVP-TE 都可能需要针对 DetNet 进行扩展.

3.2. 完全集中式控制平面 (Fully Centralized Control Plane)​

在完全集中式配置模型中 (例如使用 SDN 控制器), flow 和 UNI 信息都可以通过 API 或北向接口, 从集中式用户控制器或其他应用程序传输到集中式控制器. DetNet flows 的网络节点配置由控制器使用某种协议完成, 例如 NETCONF [RFC6241], YANG [RFC6020] [RFC7950], DetNet YANG [RFC9633], 或基于 PCE 的中心控制器 (PCE-based central controller, PCE-CC) [RFC8283].

以下情况可作为示例:

  1. 集中式控制器通过 NETCONF/YANG 收集网络节点的拓扑信息和 DetNet 能力.

  2. 控制器从 UNI 接收 flow 建立请求, 并计算穿越网络的一条或多条有效路径.

  3. 控制器选择最优路径, 并通过 PCE-CC 配置该路径沿线设备, 以传输 DetNet flow.

上述示例中的协议可能需要针对 DetNet 进行扩展.

3.3. 混合控制平面 (部分集中式且部分分布式) (Hybrid Control Plane (Partly Centralized and Partly Distributed))​

在混合模型中, 控制器和控制平面协议协同工作以提供 DetNet 服务, 并且存在多种可能组合.

在以下情况中, RSVP-TE 和控制器一起使用:

  1. 控制器通过 IGP 和/或 Border Gateway Protocol - Link State (BGP-LS) [RFC9552] 收集网络节点的拓扑信息和 DetNet 能力.

  2. 控制器通过 API 接收 flow 建立请求, 并计算穿越网络的一条或多条有效路径.

  3. 根据计算结果, 控制器将 flow 路径信息分发给入口边缘节点, 并使用必要的 DetNet 信息配置路径沿线网络节点 (例如用于 replication/duplicate elimination).

  4. 入口边缘节点使用 RSVP-TE 发送带有显式路由的 PATH 消息. 出口边缘节点收到 PATH 消息后, 发送带有已分发标签和资源预留请求的 RESV 消息.

混合控制平面还可以包含许多其他变体. 每种可能情况下协议所需的 DetNet 扩展属于未来工作.

最后于 更新