一.场景与需求 超可靠低时延(URLLC)是5G的三大应用场景之一,比如在工业4.0中,工业企业应用上云,工厂车间的物理网络系统(CPS)传出的时延敏感流量(比如报警信息、控制命令)需要经过5G接入、5G前传网、5G核心网到达云数据中心,通过IT和OT融合赋能工业互联网,实现智能化、自动化、柔性化的智能制造。同时,该场景也同样适用于远程控制、远程驾驶、远程医疗、VR游戏等业务应用,不同的业务可以通过网络切片的方式进行硬管道隔离。 在组网设备上,5G前传网主要由TSN交换机组成,而核心网内既有TSN交换机又有SDN交换机,如何通过统一的控制平面对全网进行管控,并保证超可靠低时延的特性,就成了现在亟需解决的问题,从而也产生了SDN融合5G和TSN的技术需求。下面就分别对SDN架构和TSN控制平面进行先容和分析。 二.SDN与TSNSDN架构: 经典的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,在家办公不必再为视频会议卡顿而捶胸,在家上课不必再为答题交互延迟而跺脚,远程医疗准确高效还免去了排队挂号取单子的繁琐,玩游戏更是流畅到人人都是“头号玩家”。
|