SDN融合5G和时延敏感网络(TSN)

一．场景与需求
超可靠低时延（URLLC）是5G的三大应用场景之一，比如在工业4.0中，工业企业应用上云，工厂车间的物理网络系统（CPS）传出的时延敏感流量（比如报警信息、控制命令）需要经过5G接入、5G前传网、5G核心网到达云数据中心，通过IT和OT融合赋能工业互联网，实现智能化、自动化、柔性化的智能制造。同时，该场景也同样适用于远程控制、远程驾驶、远程医疗、VR游戏等业务应用，不同的业务可以通过网络切片的方式进行硬管道隔离。

在组网设备上，5G前传网主要由TSN交换机组成，而核心网内既有TSN交换机又有SDN交换机，如何通过统一的控制平面对全网进行管控，并保证超可靠低时延的特性，就成了现在亟需解决的问题，从而也产生了SDN融合5G和TSN的技术需求。下面就分别对SDN架构和TSN控制平面进行介绍和分析。

二．SDN与TSN
SDN架构：

经典的SDN架构如下图所示，有数据面、控制面、管理面这三大平面和南向接口、北向接口这两大接口。SDN首先将数据面和控制面进行分离，然后通过南向接口接入数据面，获得网络全局视图，从而实现集中式管控，最后基于抽象的网络功能实现网络可编程。

TSN控制平面架构：

TSN的802.1Qcc协议讨论了TSN控制平面的架构，有全分布式、分布式用户管理和集中式网络控制、全集中式三种方案，如下图所示，当前主要采用第3种全集中式的架构，CUC是中心化用户配置，相当于编排器，负责采集终端业务的带宽时延抖动等网络服务质量需求，并将其转换后通过北向接口发给CNC，CNC是中心化网络控制，相当于控制器，包含计算拓扑路径等网络功能、并通过南向接口下发更新门控列表等配置信息给TSN交换机。

由于802.1Qcc只提供了方案模型，但没有提供具体的实现方式，所以采用何种规范的南向接口协议，将哪些TSN的协议和网络功能抽象到控制平面，实现怎样的可编程TSN应用，是TSSDN需要考虑的核心内容。

三．TSSDN两种实现方式
目前有“TSSDN网关”和“TSSDN统一”两种实现方式，网关是指通过协议转换将TSN和SDN域进行互连互通，统一是指直接在一台设备上同时实现TSN协议和SDN功能。很显然，网关的实现会更快更容易一些，实现了网关的基础上才能更好的实现统一。

TSSDN网关：
在TSSDN网关模型中，TSN和SDN使用通用的网络抽象层（比如MAC学习、拓扑发现、路径计算），但使用各自的控制平面、数据平面和安全策略。

首先，SDN域并不支持TSN相关的时延抖动保障技术，以使用OpenFlow为南向接口为例，则只能用OpenFLow现有的Queuing队列进行简单的流量调度，以及使用Meter计量表进行速率限制来尽量保障TSN域传来业务的QoS。

其次，由于各自所使用的协议和接口不同，网关还需要涉及到协议数据单元（PDU，Protocol Data Unit）的转换，即重写传入数据包的包头字段，比如修改VLAN中的PCP（Priority Code Point）字段实现域间的优先级映射，再比如进行NAT网络地址转换等。

此外，还需要考虑安全功能，比如接入控制、身份验证、授权和加密等。工厂企业对数据有很高的安全要求，企业应用上云后，为保证数据不被劫持、泄露、篡改、损毁，需要各种网络安全策略以及故障冗余等保护措施。不同的安全策略需要在TSSDN网关中得到统一的转译和有效的实施。

TSSDN统一：

在TSSDN同一模型中，TSN和SDN不仅使用相同的网络抽象层（路径管理、拓扑管理、策略管理），还使用统一的控制平面和数据平面，即北向接口REST API要支持SRP流预留协议来实现OPC UA的发布-订阅模式，控制器要新添CUC、CNC等网络功能组件，要能通过OpenFlow、Netconf等接口对TSN交换机下发流表和配置。具体的Yang模型定义可参考TSN工作组的的如下标准草案：

802.1Qcp（Bridges and Bridged Networks Amendment: YANG Data Model）.
802.1Qcw（YANG Data Models for Scheduled Traffic, Frame Preemption, and Per-Stream Filtering and Policing）.
802.1Qcx（YANG Data Model for Connectivity Fault Management）.

四．TSSDN三大实现步骤
按照SDN的三平面两接口架构，由于TSN的数据面已经基本完善，目前已有可商用的TSN交换机，同时北向接口API可任意选用，TSSDN还剩南向接口、控制面、编排面需要讨论和实现。TSSDN实现的三大步骤为：实现适配的南向接口，实现TSN控制功能，实现可编程TSN应用。

实现适配的南向接口

南向接口可以采用OpenFlow和Netconf，OpenFLow保持协议不变，完成流表下发等功能，对于TSN相关协议的配置和更新，可采用Netconf对接口（需要修改很多的匹配字段）后进行下发。Netconf协议（RFC 6241）规定了网络设备中的Netconf Server和控制器中的Netconf Client组件，在Server端，配置被存储在配置数据库中，客户端可以通过RPC（Remote Procedure Call）的方式进行get-config和edit-config这样的操作。比如可以通过edit-config对SRP流预留资源进行实时建立和释放，以及对门控列表进行修改。

实现TSN控制功能

接下来是本文的重头戏，贴一张图片总结一下TSN中最主要的几个协议和功能。简单的说，有了这四个协议：①先进行全网设备时钟同步，②然后对流进行端到端的带宽分配和资源预留，③再对入端口流量进行过滤，④对出端口流量进行门控队列调度整形，就基本能保证时延敏感流的确定性时延和抖动需求。将这四个功能移到控制面，也是目前大家讨论得比较多的点。

考虑具体的协议实现，我画了一张TSN交换机内部的流量处理流程视图，包含从入端口过滤，查找转发，到出端口队列门控整形、帧抢占、物理层传输的一系列过程的处理（有点小复杂，感兴趣的可以点开放大看一下）。

当然，我不可能拿这么复杂一张图来讲，所以请看精简版的下图：黑色区域代表SDN的功能组件，红色区域代表新增的TSN功能组件，TSN在结合SDN时要验证满足以下两个基本要求：

1.SDN的数控分离开销不能影响TSN协议的实现效果。比如，若将时钟同步功能移至控制面，则有可能因为连接控制面的较大时间开销导致时钟同步出错；再比如流预留功能，每一跳的talker advertise预留信息都要上报至控制器，控制器确认后再下发给交换机，也会带来额外的处理时延开销。

2.配置的更新和下发要保证实时性和一致性。比如，门控列表的下发，如果一台交换机的门控列表进行了更新，而下一跳更新不及时或者未能成功更新（不一致），就会导致流量无法在正确的时隙被传输，所以一般会检验所有的设备配置都成功后，才会给终端发送“确认可以发包”的消息。

实现可编程TSN应用

可编程TSN应用目前还很少，TSN大多还处在硬件demo或协议仿真阶段。预计未来随着远程医疗、远程教育、全息视频、VR游戏等终端实时应用和业务的丰富，TSN网络功能应用也将如黄河之水天上来一般，奔涌而出。

当前尽力而为的网络拥堵时就如同下班晚高峰路上的汽车，滴滴复滴滴，而TSN就是交通里的地铁和高铁，嘀嗒就抵达。未来，SDN融合5G和TSN，在家办公不必再为视频会议卡顿而捶胸，在家上课不必再为答题交互延迟而跺脚，远程医疗准确高效还免去了排队挂号取单子的繁琐，玩游戏更是流畅到人人都是“头号玩家”。

最后，熟悉OMNeT++仿真的朋友，可以下载INet实时以太网仿真框架和SDN4CoRE框架，进行TSN协议的仿真学习，传送门：https://github.com/CoRE-RG/.

原文链接：https://www.sdnlab.com/24142.html