IP网络控制器架构与关键技术
2020-11-06卢泉梁筱斌尹远阳
卢泉 梁筱斌 尹远阳
【摘 要】
为满足主流运营商新的IP网络运营要求,实现网络运营流程端到端自动化闭环,基于新时期IP网络的业务需求,研究了引入IP网络控制器的必要性、目标架构和关键技术,在此基础上研究了这些关键技术的应用场景,并基于实验室环境验证其有效性。为电信运营商在未来的IP网络管控中提升业务发放和运维效率、降低运维成本提供重要参考。
【关键词】IP网络;控制器;架构;关键技术
0 引言
2019年6月工信部向国内运营商颁发了5G牌照,我国提前一年进入5G时代,云业务的发展,也驱动运营商部署了大量的云专线业务。主流运营商普遍采用IP网络统一承载4G/5G、云专线业务和已有政企专线业务,这给IP网络管控带来了新的需求和挑战。具体包括:
(1)超海量业务智能管控。5G基站密度是LTE的10倍,导致投资和电费成本激增。此外还有大量的云专线和政企业务需要维护。因此,必须确保在不增加运维成本的情况下,实现对超海量业务的集中智能化管理,以保证业务的可持续发展。
(2)解决误配置问题。在超海量业务场景下,工单量激增,更容易出现向设备下发误配置进而引发全网故障的情况。这就要求管控系统具备配置下发预验证和事务处理能力。
(3)需求多样化。不同的业务有不同的SLA,要求管控系统具备实时调整流量转发路径以满足SLA的能力。
目前业界已普遍达成共识,集中式的IP网络SDN控制器,可很好地解决上述不足,满足上述需求[1]。在控制器技术成熟后,还将纳入生产网络的管控系统中,实现IP网络集中自动化管控,使能端到端网络运营流程自动化闭环。本文将对IP网络控制器的架构、关键技术和应用进行探讨。
1 IP网络控制器总体架构
IP网络控制器包含控制服务和数据采集两个子系统。其总体架构如图1所示:
控制服务子系统包含了集中化的IP网络控制功能模块,其关键技术包括NETCONF、YANG模型解析与映射、拓扑收集、路径计算和下发。
数据采集子系统包含了IP网络的数据采集模块,可供控制器的路径计算模块调用,作为路径计算的约束条件。
这些关键技术解决了传统IP网管缺乏集中式的控制平面的不足,下文将进行展开讨论。
2 IP网络控制器关键技术
2.1 NETCONF协议和YANG模型[2-3]
网络配置协议(NETCONF, Network Configuration Protocol)是一种高度标准化、可编程、对网络设备进行配置和管理的协议。控制器可通过NETCONF实现配置的读取、下发和设备状态采集。
NETCONF协议包含传输层、消息层、操作层和内容层。下一代数据模型(YANG, Yet Another Next Generation)是一种建模语言,工作在NETCONF协议的内容层,是NETCONF的重要组件,用于描述配置和状态等数据,其描述的业务模型称为YANG模型。
与基于命令行的配置下发、SNMP协议和MIB相比,NETCONF协議和YANG模型具备以下前者不具备的特性:
(1)良好的建模能力和扩展性。
(2)事务管理能力。
(3)数据一致性:用户可独占配置数据的修改权,防止多用户操作冲突。
(4)标准化和兼容性:NETCONF协议和YANG模型遵循IETF标准。如图2所示,运营商根据自身需求在控制器中定义业务YANG模型,控制器根据编排器的资源编排结果,基于业务YANG模型,通过适配插件更新相应设备的YANG实例,通过NETCONF完成配置下发实现配置更新的自动化闭环。
综上所述,NETCONF协议和YANG模型更能满足当前和未来IP网络业务发展需求。
2.2 分段路由[4-5]
控制器要具备集中式路径计算能力,首先要求路由器支持分段路由(SR, Segment Routing)。SR包括域内SR和跨域SR两类,可用于SR流量工程(SR-TE, Segment Routing Traffic Engineering)和SR尽力而为转发(SR-BE, Segment Routing Best Effort)[4]。限于篇幅,不再详细介绍。
基于SR-TE,可在头端路由器实现源路由,为客户业务流量提供精准的全局路径调度,保障业务体验。
2.3 BGP-LS协议[6]
全局化的路径优化,必须基于集中式的路径计算。因此,必须具备将完整的域内或跨域拓扑信息同步到一个集中式路径计算实体(PCE, Path Computation Element)的机制。PCE部署在控制器中,控制器和路由器通过携带链路状态的边界网关协议(BGP-LS, Border Gateway Protocol with Link State)建立会话,同步拓扑信息。
与传统路由协议相比,BGP-LS具备以下特性:
(1)强大的可扩展能力:BGP-LS基于BGP TLV扩展而得。
(2)跨IGP域的拓扑收集能力:控制器可通过BGP-LS收集多IGP拓扑,使控制器可同时支持单域和跨域流量调度。
在实际部署中,控制器只需与少数几台维护全网拓扑信息的设备建立BGP-LS会话,即可同步全网拓扑信息。
2.4 PCEP协议[7]
在控制器获取网络完整的链路状态信息后,由PCE完成集中式路径(LSP)计算,通过PCE协议(PCEP, PCE Protocol)将计算好的LSP下发给头端(PCC, Path Computation Client),即支持PCEP的路由器。
PCE主要有两种工作方式,包括:
(1)无状态方式,PCE只响应PCC发起的路径计算请求,不维护LSP状态。
(2)有状态方式,PCE在完成LSP计算后,在本地维护LSP状态,具体还可分为两种模式:
1)被动模式,PCE只保存LSP状态,不主动发起LSP的建立和对其状态进行变更。
2)主动模式,PCE保存LSP状态,可主动发起LSP的建立,根据网络运行情况对其状态进行变更。
在实际部署中,要求控制器具备对LSP的统一集中计算和实时状态优化能力,因此建议将PCE部署为有状态的主动模式。
3 IP网络控制器关键技术的应用
在实验室中搭建编排器、控制器和网络环境,模拟现网移动承载的场景。其中编排器和控制器功能架构如图1所示,实验场景如图3所示。
预置条件:
(1)被测设备由3个不同厂家提供,实验环境为跨厂家混合组网。接入网关和汇聚网关间的接入环为50 GE链路,汇聚网关、二级核心、一级核心和云网关间互联采用100 GE链路;测试仪采用2条10 GE链路分别连接2台接入网关,采用2条100 GE链路分别连接2台云网关。
(2)编排器与控制器对接妥当,已定义好4G/5G基站业务的YANG模型,编排器中已存储模拟的基站业务CRM订单数据和资源管理数据。
(3)控制器中已存储基础网络协议配置数据。
(4)所有被测设备均支持NETCONF协议、YANG模型、BGP-LS和PCEP协议。
(5)每个路由器厂家均在控制器中提供YANG模型适配插件,用于适配和屏蔽运营商业务YANG模型与不同设备YANG模型间的差异。
(6)控制器与所有被测设备间均已通过带外建立NETCONF会话。
(7)汇聚网关、二级核心、一级核心和云网关均支持SR。
实验内容包括以下5个方面:
(1)具备SR功能基础网络协议配置下发验证
1)如图3所示,在接入环配置OSPF和LDP,在汇聚网关到云网关间配置支持SR的ISIS协议,其中每台设备的节点SID范围配置为16000~23999,邻接SID范围配置为15000~15999。
2)邻接SID由每台设备在本地独立分配;节点SID由控制器统一全局分配并下发给设备,其在控制器上规划如表1所示:
3)通过NETCONF协议将上述配置下发到对应设备。
4)在每台接入网关和汇聚网关查看OSPF邻居和LDP邻居状态,均正常,与期望结果一致。
5)在每台汇聚网关、二级核心、一级核心和云网关查看ISIS邻居状态,均正常;查看节点SID,与表1规划值一致。
6)在每台汇聚网关、二级核心、一级核心和云网关查看每个使能ISIS的端口的邻接SID分配情况,记录结果如表2所示:
7)具备SR功能基础网络协议配置均成功下发并生效。
(2)基站业务开通功能验证
1)在接入网关和汇聚网关间部署TLDP和PW,在汇聚网关和云网关间部署MP-BGP、L3VPN和VPN ECMP,一級核心兼作VRR,用于基站业务承载.
2)相关的承载通道和QoS配置数据由编排器根据模拟的CRM订单数据自动生成,下发控制器。
3)控制器根据编排器下发的数据,自动为每台相关设备生成相应的设备级配置数据,并通过NETCONF下发到相应设备。
4)在每台设备上观察相应的承载通道状态(如PW、L3VPN、BGP状态等),状态均正常。
5)在测试仪上构造并发送双向流量,每条链路包含10条流,总流量6 Gbps。
6)在汇聚网关、二级核心、一级核心和云网关上观察每条纵向连接链路的利用率,各条链路利用率基本相同。
7)在测试仪上观察1小时内的统计数据,测试数据报文均可正常收发,无丢包。
8)基于NETCONF和YANG模型,可实现基于模型驱动的业务开通,即业务模型一次定义、重复调用,由编排器自动编排网络资源,控制器自动生成设备配置,并基于设备的配置验证功能保证配置的有效性,有效避免了超海量业务场景下业务开通误配置的出现。同时可实现从业务订单到业务开通的端到端秒级自动化闭环,相比原有的分钟级业务开通方式(基于业务订单手动编排网络资源,再经网管完成配置下发),效率提高了10倍以上,可有效缩短5G网络的建设交付周期。
(3)网络拓扑与SID信息统一收集功能验证
1)控制器与汇聚网关和VRR建立BGP-LS会话,集中收集IGP拓扑。
2)在控制器上查看拓扑,与实验拓扑一致,同时查看SID信息,与表1和表2一致。
3)控制器可正确收集网络拓扑和SID信息。
(4)控制器下发隧道功能验证
1)在控制器上将PCE配置为有状态的主动模式。
2)在控制器上手动规划隧道路径,指定进入设备A的上行流量路径为A→B→D→E→F→H→G,均指定节点SID,通过PCEP将隧道信息下发给设备A;指定进入设备G的下行流量路径为G→H→F→E→D→B→A,均指定节点SID,通过PCEP将隧道信息下发给设备G;不指定进入设备B的上行流量和进入设备H的下行流量路径,其流量仍经IGP最短路径转发。
3)在设备A上查看下发的隧道,状态正常。
4)在设备A上tracert隧道,同时在设备A上去往设备B链路的出方向抓取报文,观察到的标签栈信息如表3所示:
5)在设备G上查看下发的隧道,状态正常。
6)在设备G上tracert隧道,同时在设备G上去往设备H链路的出方向抓取报文,观察到的标签栈信息如表4所示:
7)经验证,通过PCEP下发到PCC的隧道与手动规划结果一致。
(5)控制器路径计算功能验证
1)在汇聚网关至云网关间的各链路配置时延属性,通过NETCONF更新到设备,具体配置值如表5所示:
2)通过BGP-LS更新拓扑信息,在控制器上查看,各链路时延信息与表5一致。
3)在控制器上触发隧道计算,隧道端点分别为设备A和设备H,约束条件为路径总时延最小。
4)控制器通过PCEP将隧道分别下发给设备A和设备H。
5)分别在设备A和设备H上tracert时延最小隧道,结果如表6所示:
6)控制器向汇聚网关和云网关更新策略,DSCP值为EF的流量经最低时延隧道转发,其他流量经IGP最短路径转发。
7)測试仪向设备1灌注6 Gbps流量,其中DSCP值为EF的流量为2 Gbps,DSCP值为0的流量为4 Gbps;向设备H灌注2 Gbps DSCP值为EF的流量,向设备G灌注4 Gbps DSCP值为0的流量。
8)在隧道各途径链路上分别抓取上下行EF流量报文,观察其标签栈信息,结果如表7所示:
9)在测试仪上观察流量统计信息,从设备G接收到4 Gbps DSCP值为0的上行流量,从设备H接收到2 Gbps DSCP值为EF的上行流量;从设备1接收到4 Gbps DSCP值为0的下行流量和2 Gbps DSCP值为EF的下行流量。
10)EF流量路径符合预期,流量出口和收发符合预期。
综上所述,实验内容的5个方面均取得预期结果,符合期望。
4 结束语
本文从运营商业务发展的需求出发,分析了运营商重构原有网络管控系统的需求,基于这些需求介绍了其中的关键技术,最后基于实验室环境对这些关键技术的协同部署进行了验证,初步具备超海量业务高效开通、避免误配置、集中式网络信息收集和路径计算的能力,为下一步现网试点和大规模推广提供了技术储备和实施参考。
参考文献:
[1] 尹远阳,卢泉,孙嘉琪,等. 基于OpenDayLight的IP RAN网络资源编排系统设计及实现[J]. 电信技术, 2017(6): 75-79.
[2] R E, M B, J S, et al. RFC 6241-Network Configuration Protocol (NETCONF)[S/OL]. (2011-06)[2019-08-29]. https://tools.ietf.org/html/rfc6241.
[3] M B. RFC 6020-YANG-A Data Modeling Language for the Network Configuration Protocol (NETCONF)[S/OL]. (2010-10)[2019-08-29]. https://tools.ietf.org/html/rfc6020.
[4] IETF. IETF RFC 8402: Segment Routing Architecture[S]. 2018.
[5] 何晓明,卢泉,邢亮. 分段路由网络研究及其在流量工程中的应用[J]. 电信科学, 2016(6): 186-194.
[6] H G, J M, A F. RFC 7752-North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP[S/OL]. (2016-03)[2019-08-29]. https://tools.ietf.org/html/rfc7752.
[7] J P V, J L L R. RFC 5440-Path Computation Element (PCE) Communication Protocol (PCEP)[S/OL]. (2009-03)[2019-08-29]. https://tools.ietf.org/html/rfc5440.