版权及立场声明
原作版权属于EANTC。
本翻译文本只供学习参考使用,不代表译者所属公司的立场。
钟庆 苏远超
05/2018
3
MPLS + SDN + NFV World Congress 2018 Multi-Vendor Interoperability Test
编者的话
分组传送网络处于平稳且成
功的演进周期当中。数年来
革 命 式 的 软 件 定 义 网 络
(SDN))呼声甚嚣云上,但
却缺乏实际的部署,业界逐
渐地聚焦到演进式的SDN解决
方案。今天的SDN-WAN解决方
案是可互操作的,集成了现
有的MPLS实现,同时兼顾了
运营商网络路由和业务的多
样性和复杂性。
Carsten Rossenhövel
Managing Director,EANTC
另外,参与我们测试的厂商数量不断增长,秘诀的
另一方面在于:实现MPLS/SDN并不是轻而易举的,
有许多不同的可选方式。微波厂商此次展示了全面
的MPLS数据平面和控制平面集成;一家白盒路由器
厂商和一家为白盒提供协议栈的厂商展示了SDN集成;
一家首次参与的厂商展示了如何快速地实现SRv6。
所有这些都是非常不错的成功案例,扩展了运营商
选择和解决方案的多样性。
不可否认,今年我们测试的MPLS/SDN用例、场景是
迄今为止最为复杂的;然而,这似乎是满足未来业
务需求的最为可行的演进路径。
这次有21家厂商参与了EANTC互操作性测试——有史
以来数量最多的一次。EVPN(EVPN)业务和Segment
Routing(SR)的MPLS实现(SR MPLS)的互操作性情
况令人非常欣慰。我们看到,多厂商互操作成功的
数量取得了切实的进展,更为复杂的测试用例体现了
实现的成熟度,以及配置和故障排除的效率。有一个
重大的演进在悄悄地发生:未来将不再需要传统的
LDP和RSVP-TE信令协议,这将大大的提高核心、汇
聚网络的可扩展性和效率。
路径计算单元协议(PCEP)测
试也比去年更令人鼓舞;路由
器(PCC,路径计算客户端)
和控制器(PCE,路径计算单
元) 的实现越来越多地考虑到
了多厂商的场景,同时乐于以
合作的方式实现互操作。在其
它领域,例如Segment Routing
的IPv6实现(SRv6),少数厂
商正在进行突破性的工作,可
能需要稍多一些时间才会广泛
部署。
这类开发成功的秘诀是什么呢?秘诀是行业持续和
一致的标准化要求。在几周前伦敦举行的第101届
IETF会议上,George Swallow退休了。作为MPLS标
准的主要发明者之一,他和很多其他主要贡献者花
了二十年的时间来定义、扩展今天的运营商分组传
送网络并推动其成熟。因此,MPLS仍将长期存在,
几乎运行在全球所有运营商传送网络上,并转变为
SDN-WAN,准备好随时满足未来的需求。数据转发、
信令和路由技术的不断扩展和创新确保了它将长期
使用下去。
展望未来:2018年将作为“5G部署启动之前一年”
被我们记住。需要认识到的真实情况是:运营商发
现还有许多事情要做,而且不能再拖延了——骨干
网需要扩展以满足预期的5G流量增长和更多的基站
站点;SDN控制器需要为每个新的“切片”(业务类
型)计算最优路径;移动边缘计算和业务虚拟化也
将创造更多的东西向流量。需要集成多个网络部件
和网元来构建统一的端到端5G传送网络。
我们乐于看见参与的厂商已经
在做相应的准备以满足5G传送
网络的要求。网络时钟同步是
5G相关测试领域的一项内容,
此次测试中再次得到了大量厂
商的支持——参与者在我们的
测试中持续改进多厂商网络时
钟方案至今大概已有十年了。
解决方案非常可靠,事实上这
个测试领域的结果在我们的互
操作测试中始终是最可靠的。
明年,我们将进一步提高时钟
同步的精度要求,满足一些5G
Release 15的要求。此外,我
们计
划扩大SDN测试范围,重新审视今年参与度很有限的
领域或者成功案例很少的领域。未来几年,我们将
更多地关注“域”,甚至可能是业务编排:自动化
业务提供、故障管理、性能监控以及其它管理相关
方面变得越来越重要。这似乎一直是MPLS的成功格
言:
Editor’s Note ...................................... 3
Participants and Devices ................... 4
Interoperability Test Results .............. 5
Segment Routing ............................... 5
Ethernet Virtual Private Network ..... 13
Software Defined Networking.......... 23
Clock Synchronization ..................... 32
Summary ......................................... 38
目录 编者的话 …………………………3
介绍 ………………………………4
参与者和设备 ……………………4
互操作测试结果 …………………5
Segment Routing ……………… 5
EVPN………………………………13
拓扑………………………………20
SDN ………………………………22
微波………………………………29
时钟同步…………………………31
总结………………………………37
4
永不停歇——总是希望做得更好!要让5G业务落地,
需要做很多事情,让我们开始吧!
概述 在过去几年中,我们一直专注于测试EVPN、Segment
Routing(SR),以及使用路径计算单元(PCE)来
影响流量转发和路由策略。
因此今年是时候鼓励比以往更多的厂商参与我们的
互操作性测试,来考察这些技术的成熟度了。我们
今年测试的挑战性目标是集成。
我们很高兴与总共21家厂商一同进行了测试。对于
某些测试场景,有多达10家厂商在同一拓扑中进行
了两两互操作。
对于Segment Routing而言,作为MPLS网络新标准,
今年绝对是其地位得到巩固的一年。在Segment
Routing、EVPN和SDN部分中,涉及MPLS的所有测试
场景我们均使用Segment Routing。 因此,这向我们
展示了厂商实现的成熟程度,以及行业下一步发展
的明确方向。
我们还首次测试了数据平面使用 IPv6的 SR实现
(SRv6),并验证了一些新提议标准的厂商互操作
性:
• “BGP Signaling of IPv6-Segment-Routing-
based VPN Networks”
• “Segment Routing Prefix SID extensions for
BGP”
• “IPv6 Segment Routing Header (SRH)”
• “SRv6 Network Programming”
• “Topology Independent Fast Reroute
using Segment Routing”
在EVPN部分,包含了大部分新参与的厂商,他们普
遍已经支持EVPN桥接(EVPN Bridging)和EVPN集成路
由和桥接(EVPN IRB)。EVPN已经成为数据中心应
用场景下的成熟技术,同时我们看到它越来越成为
统一的控制平面技术以提供跨广域网和核心网的
L2VPN/L3VPN业务。
PCEP实现也表现出良好的成熟度。今年,我们总共
测试了31种不同厂商产品的PCE和PCC互操作。今年
也是我们测试软/硬件解耦的第一年,一些白盒子和
网络操作系统(NOS)厂商参与了测试。
此外,在NETCONF/YANG部分,我们通过使用标准化
的IETF YANG模型,在多厂商环境中提供了端到端的
L3VPN服务,取得了一个显著的里程碑。
与往常一样,分组时钟同步领域显示了一致的结果,
许多厂商支持最新的用于时间/相位同步的PTP
Profile。
在微波部分,我们看到了将无线传输集成到
IP/MPLS传送网络中的许多努力。我们认为这是支
持下一代移动网络的关键要求。同时端到端网络切
片也将在不同的5G用例中发挥关键作用。
参与方及相应设备
参与方 设备
Adva FSP150 ProVMe
Arista Networks 7050SX2-72Q
7280SR-48C6
BISDN GmbH Basebox controller (external)
Switch AG7648
(Delta Electronics)
Calnex Calnex Paragon-T
Calnex Paragon-X
Cisco ASR 9000
CSR1kv
IOS XRv9000
NCS 5500
Network Services Orchestrator
(NSO)
Nexus 7702
Nexus 93180-FX
Delta Electronics AGC7648A
ECI Telecom NPT-1800
Ericsson Baseband 6620
Baseband 6630
MINI-LINK 6651
MINI-LINK 6352
MINI-LINK 6366
MINI-LINK 6691
MINI-LINK 6693
Router 6371
Router 6471
Router 6672
Router 6675
Huawei CX6608
CX600-X2-M8A
NE40E-X2-M8A
NE40E-M2K
NE9000-8
Network Cloud Engine (NCE)
IP Infusion OcNOS-AS7712-32X
OcNOS-Virtual Control Machine
5
表 1:参与方及相应设备
互操作测试结果 像往常一样,本白皮书仅记录厂商和设备名称的正
面结果(通过测试组合)。图中未提及失败的测试
组合,这些将被匿名引用以描述行业的状态。我们
的经验表明,参与厂商在我们的测试后会迅速解决
互操作性问题,因此通过测试来惩罚他们的学习意
愿是没有意义的。保密性对于鼓励制造商用他们最
新的beta解决方案参与进来,并为测试和学习提供
安全的环境至关重要。
术语
当用于说明多厂商互操作测试结果时,我们使用
“测试”(tested)这个术语。当用于说明基于单一
厂商的设备进行业务或者协议评估时,使用术语
“演示”(demonstrated)。
测试设备
在参与测试设备厂商的协助下,我们生成和测量流
量,模拟和分析控制和管理协议,并执行时钟同步
分 析 。 我 们 感 谢 Calnex , Ixia 和 Spirent
Communications在整个测试活动中提供的测试设备
和支持。
Segment Routing Segment Routing正成为事实上的SDN架构。利用源
路由模式,SR为MPLS和原生IPv6网络带来了可扩展、
简单、端到端的流量工程。
SR架构允许采用不同的控制平面模型。在分布式模
型中,网元(NE)使用动态协议来分配和分发
Segment标识符(SID)。用于此目的的路由协议可
以是IGP,如带SR扩展的IS-IS或OSPF,也可以是带
有SR扩展的BGP。
在集中式模型中,外置的控制器可用于计算路径,
然后将其编码在SID列表中。PCEP、BGP、NETCONF
等多种方式可用于向网元发送SR策略。本白皮书在
相应章节介绍PCEP的测试结果。
另外,SR架构可以在不同的数据平面上实现:基于
MPLS的SR(SR MPLS)和基于IPv6的SR(SRv6).
在SR部分,我们将介绍测试过的若干不同控制平面
协议和数据平面封装的组合。
基于IPv6的Segment Routing (SRv6)
基于SRv6的IPv6路由
Segment Routing使用网络编程的概念,实现在指定
路径而不是默认的IGP最短路径上的报文转发。
SRv6网络编程 IETF草案 (filsfils-spring-srv6-
network-programming)规定了很多标准SRv6功能。
在这个场景中我们测试了END和END.X功能。
END功能是最基本的功能,用于沿着最短路径将流
量引导到通告节点。
参与者 设备
Ixia IxNetwork
Novus One
Juniper
Networks
MX80-P
MX104
MX240
QFX10002-72Q
QFX5110-48S
Meinberg LANTIME M1000S
LANTIME M4000
Metaswitch
Networks
Metaswitch CNRouter
Microsemi TimeProvider 2300
TimeProvider 2700
TimeProvider 4100
TimeProvider 5000
TimeProvider 5000 Expansion 10
NEC iPASOLINK VR
Nokia 7750 SR-7
Network Services Platform (NSP)
Oscilloquartz OSA5421 HQ++
Spirent
Communications
Attero-100G
TestCenter (STC)
TestCenter Virtual (STCv)
UTStarcom SOO Station
UAR500
ZTE
Corporation
ZENIC WAN Controller
ZXR10 M6000-3S
ZXR10 M6000-5S
ZXR10 M6000-8S PLUS
ZXR10 M6000-18S
ZXR10 T8000-18
6
另一方面,END.X功能用于沿着最短路径将流量引导
到通告节点后,将其交叉连接到特定的邻居。
在我们的测试中,我们验证了Cisco和UTStarcom设
备的END和END.X数据平面转发行为及IPv6 SR报头
(SRH)的处理,结果与预期一致。SRv6封装流量由
Spirent TestCenter(STC)和Ixia IxNetwork生成。
在第一个场景中,UTStarcom UAR500执行END功能,
Cisco NCS5500执行END.X功能。在第二个场景中,
双方角色互换,也取得了相同结果。
图1:基于SRv6的IPv6路由
基于SRv6的IPv4 VPN
IETF草案“dawra-idr-srv6-vpn”定义了基于SRv6
的BGP EVPN和L3 VPN的处理过程和消息,以提供从
MPLS VPN到SRv6 VPN的迁移路径。
为了提供基于SRv6的VPN业务,出口PE通过MP-BGP
协议通告与VPN路由相关联的SRv6-VPN SID。SRv6-
VPN SID是与 IETF草案“ filsfils-spring-srv6-
network-programming” 中 所 定 义 的 END.DT 或
END.DX功能相关联的SRv6 SID。
在我们的测试中,厂商配置IPv4 L3VPN,出口节点
执行END.DT4功能,该END功能会解封装并进行(特
定)IPv4路由表查找。
入口PE将VPN报文封装在外层的IPv6报头中,目的
地址设置为出口PE所提供的SRv6-VPN SID。更进一
步,入口PE插入Segment Routing报头(SRH),基
于SID列表字段中列出的SID实现流量工程。
另外,在这个测试用例执行过程中,中转节点(P)
执行END功能,用下一个SID来更新数据包的IPv6目
的地址。由于节点P包含在上述SRH的SID列表中,
所以这种行为是可能的。
在测试中,测试仪发送从TG1到TG2的单向流量。
图2:基于SRv6的IPv4 VPN
在该测试中,我们另外验证了BGP可用于通告从出
口运营商边缘设备(出口PE)到入口运营商边缘设
备(入口PE)节点的特定VPN的前缀可达性。
7
Segment Routing和LDP互操作 我们测试了可以用SR映射服务器来提供SR和LDP网络
的互通。映射服务器为附着在不支持SR的LDP节点的
前缀通告远端绑定Segment ID。
另外,我们验证了即使网络只有一部分支持Segment
Routing,而其他部分只依赖LDP进行标签分配和分
发时,仍然可以构建端到端LSP。
首先,我们验证了映射服务器为不支持SR的节点通
告前缀范围及其关联的SID/标签。
图3:SR/LDP互操作
然后,我们验证了SR节点(映射客户端)处理被通
告的映射,并对MPLS转发表进行相应的编程。
最后,我们验证了网络边缘节点对数据路径进行了
正确的编码,并且业务在SR节点和只支持LDP的节
点之间正常工作。
以下厂商参与了设置1的测试:
• LDP节点:Arista 7280SR-48C6,Cisco
NCS5500,Delta AGC7648A,Spirent TestCenter
• SR节点:Arista 7280SR-48C6,IP Infusion
OcNOS (AS7712-32X),Juniper MX80-P
• SR映射服务器节点:Arista 7280SR-48C6,
Cisco NCS 5500,Nokia 7750 SR-7
以下厂商参与了设置2的测试:
• LDP节点:Ericsson MINI-LINK 6693
• SR节点:Ixia IxNetwork
• SR映射服务器节点:IP Infusion OcNOS
(AS7712-32X),Nokia 7750 SR-7
Segment Routing Anycast Segment
——双平面网络中实现不相交路径 在这个部分,我们验证了Segment Routing Anycast
Segment可在双平面网络中实现流量转发路径分离。
Segment Routing为在双平面网络中实现不相交路径
提供了一种新的解决方案。“不相交”的含义是通
过不相交的路径传送不同的业务流量。这可以在SR
路由器上利用SR Anycast Segment实现。Anycast
SID用于指定属于同一平面的一组路由器。Anycast
集合中的每台SR路由器通告相同的Anycast SID,该
Anycast SID表示去往该Anycast集合中最近节点的
IGP最短路径(支持ECMP)。在这个测试中,我们测
试了业务流量可以根据入口PE配置的策略被引导至
特定的平面。
以下厂商参与了测试:
• 入口PE节点:Ixia IxNetwork,Juniper MX104
• P节点:Ericsson Router 6675,Juniper MX80-
P
• Anycast节点:Arista 7280SR-48C6,Cisco
ASR9000,ECI NPT-1800,Ericsson Router
6675,Huawei CX6608,Nokia 7750 SR-7
• 出口PE节点:Ixia IxNetwork,Juniper MX80-P
Segment Routing基于CoS的
多平面网络流量引导 采用与前面一致的测试床,如图4所示,我们验证
了入口PE的策略可以将流量引导到不同的平面,具
体是用DSCP标记来区分不同的流,并将它们映射到
两个不同的平面。
图5列出了这个测试场景的参与者。
8
图4:Segment Routing——基于Anycast Segment实
现双平面网络中的不相交路径
以下设备商参与了测试:
• 入口PE节点:Arista 7280SR-48C6,Juniper
MX104
• P节点:Juniper MX80-P
• Anycast节点:Arista 7280SR-48C6,ECI NPT-
1800,Ericsson Router 6675,Huawei CX6608
• 出口PE节点: Juniper MX80-P,Spirent
TestCenter
图5:Segment Routing基于CoS的流量引导
BGP Segment Routing
Segment Routing可用于大型数据中心,可以非常简
单地在数据中心交换矩阵中提供流量工程和快速重
路由功能。BGP可扩展的特性使其成为Clos拓扑结
构中路由协议的流行选择。
基于这些理由,我们设置了两个使用BGP-LU的拓扑。
在第一个测试中,我们使用BGP标签单播(BGP-LU)
NLRI在五个叶子节点(Leaf)和一个主干节点(Spine)
之间交换IPv4前缀和相关联的标签。然后我们测试
了另外一个由一个主干节点和三个叶子节点组成的
拓扑,不过这次厂商在BGP-LU NLRI中启用了BGP
Prefix-SID属性。
在后一个测试床中,我们验证了设备的SR转发和
SID通告均是正确的。
我们测试了所有叶子节点之间以及叶子节点和仿真
器节点 (Ixia和Spirent) 之间的全网状流量转发。
以下厂商设备参与了BGP-LU测试场景 :Arista
7280SR-48C6、Cisco NCS5500、Ixia IxNetwork、
Juniper MX104和Spirent TestCenter。
9
Ixia IxNetwork和Spirent TestCenter作为流量产生
器和仿真叶子节点。
对于标签单播 NLRI携带 Prefix-SID标签( BGP-
LU+SID)的场景,Arista、Cisco和Ixia采用与BGP-
LU场景相同的设备,Ixia IxNetwork作为流量产生
器和仿真叶子节点。
图6:BGP Segment Routing
在这个测试中,我们发现其中一家作为路由服务器
(Route Server)的厂商无法处理/传播带有Prefix-
SID TLV的BGP更新,导致接收更新时引发BGP会话震
荡。基于此原因,我们在路由服务器功能中删除了
该厂商。
弹性和监控 Segment Routing FRR/TI-LFA
Segment Routing旨在成为一种支持为业务提供严格
服务水平协议(SLA)保证的传送技术。为此,SR必
须提供一种在链路故障情况下能够恢复端到端连接
的本地修复机制。当受保护节点或者本地修复点
(PLR)具有可以去往目的地的直连邻居,且不会
将流量环回到PLR时,LFA方法才适用:当受保护的
路径故障时,流量将被送往邻接节点,邻接节点再
将流量转发到目的地。
当以上条件不满足时,可使用与拓扑无关的LFA
(TI-LFA)。TI-LFA是基于Segment Routing的保护
机制, 此保护机制建立在已被验证的IP-FRR概念之
上。TI-LFA不需要在本地修复节点(PLR)和修复
节点(通常称为PQ节点)之间增加任何额外的信令。
这两种情况下(译者注:FRR/LFA和TI-LFA)都提
供了针对目的地的链路故障保护。SRLG保护针对另
外一种场景,假设主用链路失效,一组预先配置的
链路与主用链路共享风险,目的地需要在这种情况
下得到保护。
在测试中,最初我们使用流量产生器产生的双向流
量进行丢包基线测量。
之后,厂商在网络节点上配置LFA/TI-LFA,验证在
FIB表中已安装了备份转发表项。当流量通过主用
路径转发时,我们断开链路,并基于丢包来测量业
务中断时间。我们观察到此时流量采用备份路径转
发。
最后,厂商配置了一条新链路(链路2),将其配
置为与失效链路具有相同的SRLG。我们在这种情况
下测试了基于SRLG的TI-LFA。
我们测试了以下三种场景:针对SR MPLS和SRv6数据
平面的FRR/LFA链路保护,TI-LFA链路保护和TI-
LFA本地SRLG保护。
参与MPLS数据平面IP FRR/LFA链路保护测试的厂商
是(图7):
• PQ节点:ECI NPT-1800,Ericsson Router
6675,Huawei CX6608
• PLR节点:ECI NPT-1800,Ericsson Router
6675,Huawei CX6608,Juniper MX80-P
• P节点:ECI NPT-1800,Huawei CX6608,
Juniper MX80-P
• 出口PE:ECI NPT-1800,Ericsson Router
6675,Huawei CX6608,Juniper MX80-P
参与MPLS数据平面TI-LFA链路保护测试的厂商是
(图8):
• PQ节点:Cisco ASR 9000,ECI NPT-1800,
Huawei CX6608,Juniper MX-80-P
• PLR节点:Cisco ASR 9000,ECI NPT-1800,
Ericsson Router 6675,Juniper MX80-P
• P节点:ECI NPT-1800,Ericsson Router
6675,Huawei CX6608,Juniper MX80-P
• 出口PE:Ericsson Router 6675,Huawei
CX6608,Juniper MX80-P,Nokia 7750 SR-7
10
图7:SR FRR/LFA链路保护
图8:SR MPLS TI-LFA链路保护
11
参与MPLS数据平面TI-LFA本地SRLG保护测试的厂商
是:Cisco ASR 9000作为PLR节点,Ericsson Router
6675作为P节点,Cisco ASR 9000作为PQ节点以及
Nokia 7750 SR-7作为出口PE节点。
图9:SR MPLS TI-LFA本地SRLG保护
在SR MPLS测试期间,我们观察到许多厂商可以提供
快速重路由,但不是所有厂商都可以测试TI-LFA,
可以测试基于SRLG的TI-LFA的厂商更少。我们鼓励
厂商研发这些功能特性,以便明年可以测试更多的
组合。
图10:SRv6 FRR/LFA链路保护
对于SRv6,UTStarcom的TI-LFA实现基于集中控制
器SOO Station,控制器运行PQ算法并计算收敛后路
径。
图11:SRv6 TI-LFA保护
参与SRv6 FRR、TI-LFA和基于SRLG的TI-LFA的厂商
是:
• PQ节点:UTStarcom UAR500
• PLR节点:UTStarcom UAR500
• 出口PE:Ixia IxNetwork,Spirent TestCenter
我们很高兴在SR MPLS和SRv6上能测试同样的功能特
性,这表明两种实现之间的差距正在缩小。
LSP Ping/Trace
IETF标准RFC 8287为基于MPLS数据平面的Segment
Routing定义了LSP ping和traceroute方法。与传统
的LSP ping/traceroute类似,SR故障检测和隔离工
具也是基于MPLS回显请求和回显应答。但是,SR
LSP ping/traceroute包含一个新的TLV类型,即
Segment ID sub-TLV。
12
在收到发送端LSR发送的MPLS回显请求中携带的sub-
TLV时,响应 LSR需要核对从 sub-TLV中获取的
Segment ID和本地通告的Segment ID,以确定MPLS
回 显 请 求 是 否 经 由 正 确 的 路 径 转 发 。 LSP
ping/traceroute响应在MPLS回显应答中携带。我们
验证了 SR发送者可以向目标 SR响应者发起 LSP
ping/traceroute请求,响应者向SR发送者发送LSP
ping/traceroute应答予以响应。
图12:LSP ping/traceroute
参与LSP ping/traceroute测试的厂商是:
• 入口节点:Cisco ASR 9000,Huawei N40E-
M2K,Nokia 7750 SR
• P节点:Cisco ASR 9000,Huawei N40E-
M2K,Nokia 7750 SR
• 出口PE:Cisco ASR 9000,Huawei N40E-
M2K,Nokia 7750 SR
在测试中,我们注意到厂商对用于SR LSP的FEC
stack TLV中的sub-TLV类型/长度有不同的解读。一
些厂商声称标准(RFC 8287)中没有明确说明是否
将保留字节视为长度的一部分。在互操作测试之后,
一家参与厂商在IETF提出了技术勘误请求,以澄清
sub-TLV的长度。
13
EVPN
基于VLAN的EVPN MPLS业务下的多厂商
Active/Active站点
EVPN支持数据平面和控制平面分离,允许在数据平
面使用不同封装机制,例如MPLS和虚拟可扩展局域
网(VXLAN)。
图13:基于MPLS/Segment Routing的
Active/Active EVPN
该测试验证了Segment Routing MPLS数据平面上的
EVPN功能。
在SR域内,使用带有SR扩展的IS-IS作为IGP协议。
在这个场景中,我们测试了四个不同的厂商组合。
在所有组合里面,Cisco IOS XRv9000都充当路由反
射器。
在检查IGP和Segment Routing信息后,我们验证了
EVPN路由类型1、2、3和4均已正确导入。
最 后 , 我 们 用 Ixia IxNetwork 和 Spirent
TestCenter发送端到端单播流量,没有发现丢包。
对于多归属站点,使用一台额外的CE设备与PE节点
间建立链路聚合组(LAG),CE这个角色由Nokia
7750 SR-7机箱内的虚拟交换机或者Arista 7280SR-
48C6来担任。
我们验证了Active/Active的多归属站点的别名
(aliasing)功能,并且非指定转发器(NDF)阻断
了远端站点的BUM流量。
对于PE角色,我们测试了如下设备:多归属站点配
置中包括Arista 7280SR-48C6,Cisco NCS5500,
Cisco ASR9000,Juniper MX104和Nokia 7750 SR-
7;单归属配置中Ixia IxNetwork执行PE仿真。详细
的厂商组合信息详见图13。
E-Line MEF将E-Line定义为点到点以太网业务。IETF现在
提出了一个解决方案框架,用于在MPLS网络中通过
EVPN来支持这项业务。IETF在草案“VPWS support
of the EVPN”中讨论了这些特性,要求使用VPWS来
满足E-Line的要求。此外,EVPN继承的功能也使得
VPWS的实现更为有效。
在测试中,我们在两台给定的PE之间建立了一个点
到点连接,如图14所示。我们在每对PE之间配置一
个EVPN实例,并在EVPN实例内启用VPWS。
由于时间有限,一些参与厂商只测试了单归属模式。
在这种测试中,我们验证了ESI字段被设置为0,
Ethernet Tag字段被映射为VPWS标识符,两者都在
基于EVI的EVPN自动发现路由(EVPN AD per EVI)
中携带。
以 下 厂 商 参 与 了 这 个 场 景 的 测 试 : Cisco
NCS5500(双归属),Huawei NE9000-8 (单归属),
Juniper MX104 (单归属) 和Nokia 7750 SR-7 (双
归属) 作为PE路由器。 另外,Ixia IxNetwork和
Spirent TestCenter 作为仿真PE和流量产生器。
Cisco IOS XRv9000用作路由反射器,一台运行在
Nokia 7750 SR-7路由器上的虚拟交换机用作CE设备。
14
图14:基于SR MPLS的E-Line业务
E-Tree MEF将E-Tree定义为点到多点以太网业务(译注:原
文为E-Line,应为笔误)。同样地,IETF提出了一个
解决方案,用于在MPLS网络中通过EVPN支持此项业
务。
在这个场景中,我们验证了EVPN技术可以支持E-
Tree功能要求。基于现有IETF标准(RFC 8317),
我们测试了每条附着电路(AC)确定是根或者叶子
站点的场景。
图15:E-Tree业务——每条AC是根或者叶子站点
我们验证了在叶子AC上学习到的MAC地址,在通告时
会带有预期的叶子标志,并在远端PE中作为叶子MAC
地址进行安装。
我们也验证了两台PE间按RFC 8317的规定交换ESI叶
子标签,用于标识叶子产生的BUM流量。
以下厂商参加了这个测试场景:Juniper MX104和
Nokia 7750 SR-7。
EVPN 增强 ARP代理
在EVPN中,PE用MP-BGP向其它PE通告MAC/IP地址和
MPLS标签。
EVPN的ARP代理(ARP Proxy)功能在类型2 MAC/IP通
告路由中通告MAC地址及其对应的IP地址,从而消
除了传送网络中的ARP泛洪。当PE从它的直连主机
收到ARP请求时,它拦截ARP请求并为请求的IP执行
IP/MAC查找。如果查找成功,PE将代表所请求的IP
端点发送ARP回复。ARP请求不会在整个EVPN网络或
者任何其它AC上泛洪。如果查找不成功,PE将在
EVPN网络内和其它本地CE上泛洪ARP请求。
图16:EVPN ARP代理
15
我们采用两种不同的设置测试ARP代理功能。在第一
个设置中,只使用对称IRB转发。在第二个设置中,
只转发纯二层流量,不涉及路由。
得益于厂商对ARP代理功能的广泛支持,今年我们可
以设置典型的Clos拓扑,其中主干层用作底层路由
(IPv4)和叠加网络(EVPN)eBGP会话的路由服务
器。在设置1中,Arista 7050SX2-72Q 和Juniper
QFX5110-48S充当路由服务器。
以下厂商参与了设置1的叶子角色测试,如图16所示:
Arista 7050SX2- 72Q,Arista 7280SR-48C6,Cisco
Nexus 93180-FX,IP Infusion OcNOS (AS7712-32X),
Juniper MX104 , Juniper MX240 , Metaswitch
CNRouter,ZTE ZXR10 M6000-8S PLUS。
对 于 设 置 2 , 叶 子 角 色 由 BISDN Basebox 和 IP
Infusion OcNOS (AS7712-32X) 担 任 。 Arista
7050SX2-72Q用作路由服务器。
不幸的是,今年没有足够的厂商支持以测试ND代理
功能。
IGMP代理
IGMP代理(IGMP Proxy)机制的目标是减少跨多台PE
路由器EVPN实例内的IGMP消息(包括查询和报告)
泛滥,就像EVPN中的ARP/ND抑制机制减少EVPN上的
ARP消息泛滥一样。
VXLAN域中的主机通过为其感兴趣的组播组发送IGMP
成员关系报告(加入)来表示它们对给定子网/VLAN
上的组播组的兴趣。另外,IGMP路由器(例如,
IGMPv1)周期性地发送成员资格查询来找出该子网
上是否还有主机有兴趣接收该组播组的业务。
此外,对于指定的组播组(*,G)或者组播发送者
(S,G),如果没有物理/虚拟组播路由器连接到
EVPN网络上,则希望EVPN网络为连接到那个子网的
所有主机充当分布式的组播路由器。
在这个测试中,Cisco Nexus 93180-FX和Nokia 7750
SR-7作为PE路由器。我们在Cisco单归属PE路由器后
仿真了一台主机,此仿真主机发送IGMP报告,我们
观察到在EVPN叠加网络上此消息作为类型6路由
(SMET路由)进行传播。
Nexus 9000叶子基于仿真主机上收到的加入请求产
生EVPN类型6路由。多站点边界网关(BGW)转发此
消息,并无缝地将SMET路由转发给外部EVPN 发言者
(Nokia)。
另一方面,其中一家厂商目前实现的行为是发送封
装后的IGMP消息给IGMP代理,以避免不必要的未知
组播泛洪。
图17:EVPN IGMP代理
EVPN路由 EVPN IRB
EVPN IRB正在IETF进行标准化,它为数据中心环境
下的EVPN跨子网转发提供解决方案。MP-BGP EVPN通
过主机IP地址路由(类型2路由)或者IP前缀路由
(类型5路由)分发三层可达性信息,从而实现不
同VXLAN叠加网络中主机之间的通信。根据入口或/
和出口网络虚拟化边缘(NVE)所需要进行的查找,
草案定义了两种不同的IRB:非对称IRB和对称IRB。
非对称IRB要求在入口NVE执行IP和MAC查找,在出
口NVE只要求MAC查找;而在对称IRB中,入口和出
口NVE都要求IP和MAC查找。
所有的测试场景都采用三层Clos拓扑,也称为“叶
子和主干”网络(如RFC 7938所述)。路由服务器
作为主干交换机,汇聚一组EVPN PE设备作为叶子。
每台叶子设备连接固定数量的IPv4子网。然后我们
在主干和叶子设备的底层网络上配置eBGP。同时在
主干和叶子之间用eBGP分发EVPN叠加网络路由,转
发平面采用VXLAN。
在这个设置中,两个IPv4子网由流量产生器仿真,
并都连接到叶子设备的EVPN-VXLAN中。在所有的测
试组合中,我们用流量产生器验证了所有叶子间的
全网状连接。
16
EVPN – 对称IRB
图18:EVPN对称IRB
如图18所示,以下厂商作为EVPN PE路由器成功地参
与了测试:
• 设置1:Arista 7050SX2-72Q (双归属),Arista
7280SR-48C6 (双归属),Cisco Nexus 93180-FX,
Ixia IxNetwork,Nokia 7750 SR-7
• 设置2:Arista 7050SX2-72Q (双归属),Arista
7280SR-48C6 (双归属 ), Ixia IxNetwork,
Juniper MX104,Juniper MX240 (双归属),
Spirent TestCenter (STC)
Juniper QFX5110-48S和Arista 7050SX-72Q 充当主
干交换机和BGP路由服务器。
EVPN – 非对称IRB
以下厂商作为EVPN PE成功地参与了这个测试:
• 设置1:Arista 7050SX2-72Q (双归属),Arista
7280SR-48C6 (双归属),Metaswitch
CNRouter,Spirent TestCenter (STC),
• 设置2:Arista 7050SX2-72Q (双归属),Arista
7280SR-48C6 (双归属),Ixia IxNetwork,
Nokia 7750 SR-7
Arista 7050SX2-72Q作为主干节点并充当路由服务
器。设置如图19所示。
图19:EVPN非对称IRB
17
EVPN IP-VRF-to-IP-VRF
EVPN前缀通告草案正在IETF进行标准化,它提供了
一个解决方案以有效地在数据中心环境中处理EVPN
跨子网转发。在EVPN网络环境中,需要为IRB接口后
面的子网和IP提供前缀通告。这个场景被称为EVPN
IP-VRF-to-IP-VRF。
EVPN前缀通告草案为IP-VRF-to-IP-VRF模型提供了
不同的实现选项:
• 无接口(Interface-less)模型,该模型不需要补
充广播域(SBD)和叠加网络索引
• 基于无编号SBD的完整接口IRB(Interface-full
with unnumbered SBD IRB model)模型,该模型需
要SBD,同时需要MAC地址作为叠加网络索引
• 基于 SBD的完整接口 IRB模型 (Interface-full
with SBD IRB model),该模型需要SBD,同时需
要网关IP地址作为叠加网络索引
在该测试中,我们聚焦于使用VXLAN作为数据平面的
数据中心交换矩阵的EVPN-VXLAN。eBGP用于底层网
络和叠加网络的NLRI交换。主干节点上的eBGP配置
做了修改,以避免BGP更新在叶子节点间传播时修改
下一跳属性。
对于所有的测试,我们验证了VXLAN虚拟网络标识符
(VNI)直接映射到EVPN EVI。我们确认类型5路由
(IP前缀通告路由)携带了正确的IP前缀和长度,
以及对应的网关地址(在无接口模型下值为0)。路
由表通过CLI进行了验证。另外,完整接口模型用到
了类型2路由。它携带了MAC地址长度和MAC地址。IP
地址长度设置为0。接下来,我们从所有IPv4子网向
其它IPv4子网发送IPv4测试流量,并且期望在所有
IPv4子网上接收的流量无丢包。
基于无编号SBD的完整接口IRB模型
该测试如图20所示,以下厂商作为PE路由器参与测
试:
• Cisco Nexus 93180-FX,Nokia 7750 SR-7
图20:基于无编号SBD的完整接口IRB模型
基于SBD的完整接口IRB模型
在这个测试例中,我们观察到一些问题,因为在类
型2和类型5路由中采用了不同的VNI值,一些厂商不
能正确地处理数据平面,虽然在这种情况下类型5路
由的VNI值是无关紧要的。
由于这个原因,设置1和设置2中的IxNetwork和
Spirent TestCenter只能成功产生到Nokia 7750 SR-
7节点的流量。
图21:基于SBD的完整接口IRB模型
该测试如图21所示,以下厂商作为PE路由器参与测
试:
• 设置1:Ixia IxNetwork,Nokia 7750 SR-7
• 设置2:Nokia 7750 SR-7,Spirent TestCenter
• 设置 3: Juniper MX104-MX240 (双归属 ),
Juniper QFX10002-72Q,Nokia 7750 SR-7,ZTE
ZXR10 M6000-18S,ZTE ZXR10 M6000-8S PLUS
另外在设置3中,Arista 7050SX2-72Q和Juniper
QFX5110-48S在这个场景中充当主干/BGP路由服务器。
18
无接口模型
在EVPN叠加网络中,无接口模型用前缀通告(路由
类型5)实现IP路由,是得到最广泛支持的模型。
该测试如图22所示,以下厂商作为PE路由器参与了
测试:
• Arista 7050SX2-72Q (双归属),Arista 7280SR-
48C6 (双归属),Cisco Nexus 93180-FX,Ixia
IxNetwork,Juniper MX104,Juniper MX240 (双
归属),Juniper QFX10002-72Q,Nokia 7750 SR-
7,Spirent TestCenter,ZTE ZXR10 M6000-8S
PLUS,ZTE ZXR10 M6000-18S
Arista 7050SX2-72Q和Juniper QFX5110-48S 充当路
由服务器。
测试中我们没有观察到任何问题,这体现了成熟的
厂商实现和清晰的标准流程定义。
EVPN互通 EVPN和IP-VPN 互通
图23:EVPN和IP-VPN互通 设置1
图22:无接口模型EVPN IP-VRF-to-IP-VRF
19
EVPN最重要的用例之一是跨IP/MPLS核心网将数据中
心互联起来。该测试的目标是验证基于IP-VPN的广
域网络和基于EVPN的数据中心网络的互通案例。
系统必须在EVPN网络和所支持的IPVPN技术之间提供
控制平面和数据平面互通。
对于设置1(图23),我们测试了以下厂商:
• EVPN-VXLAN PE角色: Arista 7050SX2-72Q,
Arista 7280SR-48C6,ZTE ZXR10 M6000-8S PLUS
• IP-VPN/MPLS PE 角色:Ixia IxNetwork
• IP-VPN - EVPN 网关角色:Cisco ASR 9000,
Nokia 7750 SR-7
• BGP路由反射器角色:Cisco IOS XRv9000
• BGP路由服务器/主干角色:Arista 7050SX2-72Q
设置2是为了允许厂商参与不同的网络功能,或者
演示不同产品线的相同功能。
对于设置2(图24),我们测试了以下厂商:
• EVPN-VXLAN PE角色: Arista 7050SX2-72Q,
Arista 7280SR-48C6,Cisco Nexus 93180-FX,
Ixia IxNetwork,Huawei CX6608,Nokia 7750
SR-7,Spirent TestCenter
• IP-VPN/MPLS PE角色:ZTE ZXR10 T8000-18
• IP-VPN - EVPN网关角色:Cisco Nexus 7702,
Huawei NE9000-8
• 边界网关角色:Cisco Nexus 93180-FX
• BGP路由服务器角色:Arista 7050SX2-72Q
图24:EVPN和IP-VPN互通 设置2
20
21
•
• i
a
I
x
EVPN-VXLAN和EVPN-MPLS互通
在数据中心网络中,比较常见的是运行纯IP网络,
不支持MPLS。这种情况下,VXLAN是支持多租户的一
种数据平面选项。该测试的目标是验证基于EVPN-
MPLS的广域网络和基于EVPN-VXLAN的数据中心网络
互通用例。
该测试聚焦于“集成式互联解决方案”,意味着NVO
网关和广域网边缘功能集成在同一系统中。该系统
必须在EVPN-VXLAN网络和广域网支持的EVPN-MPLS技
术之间提供控制平面和数据平面的互通。
今年我们有机会全部采用Segment Routing ISIS来测
试MPLS部分。
如图25所示,数据中心网络中的设备提供EVPN-
VXLAN连接。IP/MPLS边缘路由器实现EVPN-VXLAN网
络和EVPN-MPLS互联,实现控制平面和数据平面互操
作。我们在完成底层网络和叠加网络的BGP会话测试
后,检查了每台IP/MPLS边缘设备(PE)上的BGP路
由表,每台PE设备均从每台远端EVPN PE处接收到类
型3路由。
我们在站点间产生单播以太网流量,并开始验证每
台网络节点上的MAC/IP通告路由(类型2路由)。
IP/MPLS网络部分的MAC/IP通告路由携带了共同EVI
的RD、MAC地址以及与MAC地址相关联的MPLS标签。
VXLAN网络部分的MAC/IP通告路由携带了共同EVI的
RD、MAC地址、与MAC地址相关联的VNI以及作为扩
展团体属性的VXLAN封装信息。
在这个场景中,我们测试了以下厂商:
• EVPN-VXLAN PE角色:Arista 7050SX2-72Q (双归
属),Arista 7280SR-48C6 (双归属),Cisco
Nexus 93180-FX , Huawei CX6608 , Ixia
IxNetwork, Spirent TestCenter, ZTE ZXR10
M6000-18S , ZTE ZXR10 M6000-8S PLUS ,
Metaswitch CNRouter (双归属),IP Infusion
OcNOS (AS7712-32X) (双归属)
• VXLAN-MPLS网关角色:Arista 7050SX2- 72Q,
Nokia 7750 SR-7
• 路 由 反 射 器 / 路 由 服 务 器 角 色 : Arista
7050SX2- 72Q,Juniper MX240
图25:EVPN VXLAN-SR MPLS互通
22
SDN 提高网络灵活性是运营商的目标,采用集中式网络
管理协议和针对应用的业务编排架构可以帮助运营
商达成这个目标。以下两个章节介绍 PCEP及
NETCONF/YANG互操作测试的描述、结果和总结。
PCEP
RFC 5440定义了PCEP,作为路由器(PCC,路径计算
客户端)和控制器(PCE,路径计算单元)之间通信
的机制。PCEP会话在TCP上运行,它使得PCC和PCE节
点能够交换路径计算的请求、响应、会话状态和报
告。PCE计算出流量工程路径,并推送给PCC。PCE和
PCC都可以触发计算和提供路径要求。PCEP也可以用
来重新优化和更新现有路径。
为了演示所有可互操作的PCEP组合,我们为每一个
组合测试一条单向LSP,因此单个PCC头端已足以展
示PCC和PCE的互操作性。
今年,我们注意到参测厂商越来越多地用PCEP来管
理SR-TE路径。大多数参与厂商更愿意采用SR-TE来
测试PCEP,而不是采用在2017年已进行过大量测试
的RSVP-TE。
有状态PCE模型:PCE发起SR-TE路径
当需要调整LSP部署来响应应用需求时,支持LSP的
动态创建和拆除很有用。
在该测试中,我们验证了在单个IGP域内由PCE发起、
创建的SR-TE路径。我们也验证了状态的同步和删除
LSP。
测试拓扑包括了三个网络节点,其中一个充当PCC。
参 与 厂 商 选 择 ISIS-TE 以 同 步 TED( 译 者 注 :TE
Database,流量工程数据库)信息。LSP限制在“次优
路径”上,这使得测试流量不遵循IGP最短路径。
开始测试时,我们在网络节点上验证了有状态PCEP
会话状态和TED信息。PCE发起LSP之后,我们检查了
PCE上的LSP数据库,并确保在每个PCC上都建立了传
送路径表项。
为了验证状态同步,我们要求参与厂商中断PCEP会
话(由PCE或PCC发起),清空PCE上的LSP数据库,
然后重新建立PCEP会话。会话恢复后,我们验证了
PCC上的现有LSP同步到了PCE上,并验证了测试流量
不受PCEP会话中断的影响。
最后,PCE删除LSP,我们验证了PCC上的LSP信息被
删除。LSP删除之后,测试流量按照预期遵循IGP最
短路径转发。图26展示了成功的参与者组合。
23
图26:PCE发起SR-TE路径创建和删除
值得一提的是,目前厂商对带宽限制的支持有限,
因此我们在测试中去掉了这个要求。有一家厂商的
实现在PCEP会话恢复之后,报告了异常的LSP状态
同步过程,进而触发了删除LSP操作。一些测试组
合由于最大SID深度(MSD)不匹配而无法通过。
最后,我们观察到一家厂商的TED状态同步实现方
式与别人不一样,这带来了互操作的挑战,结果是
在LSP数据库重新同步过程中产生了错误报告。
有状态PCE模型:PCC发起SR-TE路径
根据定义,一旦PCC与选定的PCE节点成功建立了
PCEP会话,它就可以向PCE发送包含了路径属性和
限制的路径计算请求(PCReq消息)。PCE接收到路
径请求之后,计算出LSP,并将其推送到请求的PCC。
对需要某些特定网络条件来运行的应用来说,这很
有帮助。在该测试中,我们检查PCEP对等体上的
TED和LSP信息,以验证SR-TE LSP的发起和创建过程,
并经由创建的隧道发送测试流量。流量从PCC侧产
生,通过有别于IGP最短路径路由的“次优路径”
发往下一个网络节点。与PCE发起的测试类似,厂
商选择ISIS-TE来同步TED信息。
24
在PCC发起的LSP创建后,检查PCEP对等体上LSP的
“Delegate(托管)”标志,验证PCC将LSP托管给了
PCE。最后测试删除LSP,并确认TED和LSP数据库被
清除。如预期一致,LSP删除后,测试流量遵循IGP
最短路径而不是“次优路径”转发。图27展示了成
功的组合。
图27:PCC发起SR-TE创建和删除
我们注意到厂商实现的PCC发起功能存在一些差异。
一些厂商的PCC使用携带空的显式路由对象(ERO)
的路径计算报告消息来发起LSP,而不是使用PCReq。
还有一些实现默认地将LSP托管给PCE,或者是没有
撤销托管的选项。
PCEP网络中的SR-TE路径更新和重新优化
SDN架构集中地进行网络管理决策,PCE节点应该能
够根据不同条件进行本地和全局的网络业务更新。
本测试验证了网络状态改变时,PCEP对等体重新计
算和安装重新优化之后路径的能力。由于可能的触
发因素范围很广,同时厂商在支持各种触发因素上
存在差异,因此我们要求参与者使用以下三种选项
之一来触发路径重新计算:
• 在原有路径上增加链路代价
• 断开主用路径上的链路
• PCE仿真解决方案(即Ixia IxNetwork,Spirent
TestCenter)中,在PCE上手动触发路径更新
25
该测试中的绝大多数初始步骤与有状态PCE模型下
PCE发起SR-TE路径和PCC发起SR-TE一致,因此我们
尽可能将运行LSP更新过程作为那些测试的一个中间
步骤。除一个测试组合外,图26和图27列出的所有
的厂商组合均参与了该测试。在那些组合中,我们
重用了测试拓扑,但是更新的LSP将使用直连路径,
而不是图中突出显示的“次优路径”。图28展示了
其它成功的厂商组合,它们参与了这个测试,但是
在之前没有列出。
图28:SR-TE路径更新和重新优化
跨域SR-TE——BGP-LS和PCE集成
图29:BGP-LS和PCE集成
在跨域网络中,拓扑信息、流量工程数据库(TED)
和链路状态数据库(LSDB)仍然是每个域的本地信
息。为了创建跨两个或更多网络自治域的TE LSP,
PCE可以使用BGP链路状态协议(BGP-LS)。
该测试要求参与厂商建立一条最优的跨IGP域的LSP。
我们验证了PCC和PCE之间的PCEP会话,验证了PCE
与跨多个域的路由器建立了BGP-LS会话。
26
我们还确认了PCE具有两个域完整的网络拓扑结构。
之后,要求PCE跨两个网络域创建一条端到端的LSP,
并在PCC节点上验证了该LSP。测试拓扑和厂商角色
如图29所示。
Cisco IOS XRv9000、 Nokia Network Services
Platform和ZTE ZENIC WAN Controller充当了PCE角
色,而Cisco ASR 9000、Nokia 7750 SR-7和ZTE
ZXR10 M6000-3S作为PCC参加。由于涉及到厂商数量
和网络节点上的可用端口数量不同,拓扑结构略有
不同。
跨域SR-TE
PCEP的另一个用例是对跨自治域的SR-TE路径进行编
程。当针对应用的流量工程可以利用多个自治域的
拓扑信息来向PCC头端发送最佳路径时,这将非常有
价值。
该测试中,PCE通过BGP-LS学习多个域的拓扑。 同
时用SR出口对等体工程(EPE)SID对AS间的链路进
行建模。然后,PCE利用这些信息计算最佳路径,并
将其推送到PCC头端。验证自治域间的LSP创建后,
关闭路径上的一条链路,触发路径的重新计算。PCE
计算出一条替代路径,并成功将其推送到PCC上。我
们验证了PCC上的标签栈,并要求PCE厂商删除LSP。
成功删除LSP后,PCEP对等体上的LSP信息也被清除。
测试中ZTE ZXR10 T8000-18作为PCC头端参与,而
Cisco IOS XRv9000担任PCE角色。图30显示了完整拓
扑和LSP。
图30:跨域SR-TE
NETCONF/YANG
为降低业务编排和运营的负担,很多运营商在研究
考察零接触网络(zero-touch networks)。他们研
究的一个共同课题是如何成功地定义和实施多厂商
网络业务。
网络配置协议(例如NETCONF和RESTCONF)和YANG
建模语言的组合是可选的工具。标准化组织尝试定
义可供不同厂商用来定义相同网络业务的业务目录,
如三层和二层VPN。以下两个测试覆盖了这两种用
例。
L3VPN业务的创建和删除
本测试定义了L3VPN业务的参数。IETF RFC 8299用
YANG定义了L3VPN业务模型,本测试期望控制器将
业务参数从YANG转换成网络节点上厂商特定的
NETCONF/YANG配置参数。
业务模型指定了接口参数、虚拟路由和转发表
(VRF)实例和CE-PE路由。测试采用编排器的北向
接口执行业务的创建和删除。厂商可选用MPLS或者
SRv6作为他们的首选传送数据平面。
为了验证业务的创建和删除,我们检查了网络节点
上的运行配置。业务创建之后,通过网络发送流量,
和预期的一样,没有流量丢失。我们还通过比较测
试前后网络节点上的配置,确认业务编排是非侵入
式的(译注:业务编排不会已有业务造成影响)。
设备配置都能够匹配上,只有个别出现额外的不可
读字符的情况。相关厂商解释说,额外的字符不会
影响设备的操作。
六家厂商成功地参与了这个测试。Cisco NSO和
Huawei NCE作为NETCONF/YANG编排器。ECI NPT-
1800 、 Ericsson Router 6471 、 Metaswitch
CNRouter和UTStarcom UAR500充当运营商边缘设备
(PE)。Cisco NSO北向开放NETCONF/YANG接口,而
Huawei NCE北向开放RESTCONF/YANG接口。
成功的组合如图31所示。最后值得一提的是,IETF
尚未在标准中定义基于SRv6数据平面的L3VPN YANG
数据模型(这是草案 draft-raza-spring-srv6-
yang-01正在进行的工作),因此目前设置相关的
NETCONF行为还是厂商专有实现方式,由控制器通
过若干步骤(事务)实现。
27
图31:L3VPN业务的创建和终止
L2VPN业务的创建和删除
NETCONF/YANG的另一个用例是L2VPN业务的建模和部
署。该测试设置与之前L3VPN类似,业务参数略有不
同——例如业务VLAN。在这个测试中,由于缺乏对
YANG 模 型 草 案 如 IETF draft-ietf-l2sm-l2vpn-
service-model的支持,业务是直接在编排器上建模
的。
编排器在PE上成功地发起和删除了L2VPN业务。通过
在两个客户站点间发送流量,验证了网络业务的成
功部署。有两家厂商参与了此测试:Cisco NSO充当
编排器,UTStarcom UAR500充当PE。UTStarcom选择
SRv6作为传送数据平面。
图32:L2VPN业务的创建和删除
多厂商/多域控制器编排
SDN架构可以跨多个网络域。通常,每个域由一个
域控制器控制,而跨域业务由具有所有子域全面视
图的多域控制器进行编排。
该测试尝试了三种管理协议:NETCONF、RESTCONF
和PCEP。由这三种协议的组合管理两个网络域。网
络域通过两台PE直接互联。我们要求厂商创建和删
除由RFC 8299建模的端到端L3VPN业务。四家厂商参
与了此测试。一个域由Cisco NSO通过NETCONF/YANG
管理两台Ericsson PE。另外一个域由Huawei NCE通
过PCEP管理两台 Huawei PE。一个Huawei NCE
(Super)实例使用NETCONF/YANG和RESTCONF/YANG
管理域控制器。
图33描述了参与组件之间的测试拓扑和连接。测试
开始时,我们检查了网络节点和控制器上的管理会
话和配置信息。然后,要求多域控制器触发业务创
建,并监控两台域控制器的北向接口。多域控制器
用RFC 8299 YANG将业务重新建模为两个不同的业务,
并推送到两台域控制器。然后,每台域控制器将业
务转换成设备配置,并推送到网络节点。为了验证
业务创建,我们检查了设备的配置,并经由业务路
径发送流量。最后,多域控制器成功执行了业务删
除,设备配置被成功清除。
业务删除之后,测试流量被丢弃,与预期一致。
28
图33:多厂商/多域控制器编排
虚拟CPE与NETCONF集成
NETCONF可扩展以管理虚拟资源,例如虚拟客户端设
备(vCPE)。
Adva用两台背靠背连接的FSP150 ProVMe参与了此测
试,展示了vCPE组件和广域网的集成。在每台Adva
设备上都创建一台第三方厂商的虚拟路由器,并对
其进行手动配置。
图34:虚拟CPE与NETCONF集成
测试使用Spirent TestCenter在两台CPE和它们的虚
拟路由器之间发送用户数据,验证配置成功。然后,
vCPE虚拟路由器和Cisco NSO之间建立了NETCONF会
话。由于时间关系,测试没有覆盖NETCONF/YANG的
进一步应用。
29
微波 随着运营商将网络升级为LTE-A,准备向5G演进,人
们对微波传输所扮演的角色提出了疑问。我们看到
的一个趋势是将专门的微波设备集成到标准IP/MPLS
路由器领域,在以下的测试中将研究这个问题的两
个特定方面。
带宽通知
今天,移动回传网络通常是运行于微波设备之上的
路由器所组成的覆盖网络。过去,这两个领域之间
的沟通有限,但是随着ITU-T Y.1731定义了带宽通
知消息(ETH-BN),微波系统现在具备了向路由器
发送带宽变化信号的能力。
这使得路由器可以根据ETH-BN数据包内提供的带宽
信息,将业务策略应用到发给微波系统的流量上。
测试开始时,微波节点使用如表2中所示的可能的最
高阶调制方式,发送端到端流量。然后,使用RF衰
减器模拟微波节点间的恶劣天气条件,验证汇聚路
由器可以处理带宽通知消息(ETH-BN),并能够基
于ETH-BN提供的带宽信息,将业务策略应用到发给
微波系统的流量上。
图35:带宽通知
我们成功地测试了以下组合:Ericsson Router 6672
在两个组合中均作为汇聚路由器,微波链路分别在
两台NEC iPASOLINK VR、一台Ericsson MINI-LINK
6366和MINI-LINK 6691之间建立。
表2:使用的调制方案和频道间隔
基于MPLS的三层微波业务
该测试的目的是验证微波平台建立的IP/MPLS业务
可以穿越或者终结在现有基础设施上的能力。
我们根据不同的传输需求测试了两种不同的组合,
验证了多厂商场景下,具有IP/MPLS能力的微波系
统与IP/MPLS汇聚路由器能够建立L3VPN业务。
在第一个场景中,使用IS-IS作为IGP协议,LDP作
为MPLS标签分配和分发协议。在第二个场景中,
IGP修改为OSPF、LDP不变。我们在两家不同微波厂
商和一台路由器(作为汇聚路由器)之间以及在两
家直连的微波厂商之间都建立了端到端业务。
本测试中 Ericsson MINI-LINK 6366、 Ericsson
MINI- LINK 6691和NEC iPASOLINK VR 微波节点充
当PE/P节点。Juniper MX80在使用ISIS和LDP的
L3VPN的组合中作为P节点参与。另外一个只有
Ericsson MINI-LINK 6691和NEC iPASOLINK VR的组
合中,测试了使用OSPF和LDP的L3VPN。
图36:基于三层微波MPLS的业务
30
三层微波传输的弹性
将IP/MPLS引入到微波网络,可以在接入网络中提供
额外的弹性,提高端到端业务可用性。
该测试的目的是验证微波节点可以在不同路径上重
新路由流量,应对无线链路的质量劣化。
我们用Spirent TestCenter充当CE,在网络上发送
双向流量。微波节点使用如表2中所示高阶调制方案,
验证了经由主用路径转发流量,没有出现丢包。然
后,使用RF衰减器,模拟恶劣的天气条件,减少通
道的可用带宽。
本测试中Ericsson MINI-LINK 6691和NEC iPASOLINK
VR 充当P节点,Ericsson MINI-LINK 6366和NEC
iPASOLINK VR 充当微波站和 PE节点。 Ericsson
MINI- LINK 6651和NEC iPASOLINK VR 作为提供网络
弹性的节点参与。Juniper MX80充当PE路由器。
图37:三层微波传输的弹性
31
时钟同步 在今年的测试中,我们聚焦于时钟/相位传输,涵盖
了大量的弹性场景,使用完全和部分辅助定时支持
设置,并且为只支持Sync-E(同步以太网)的传统网
络提供了网络边缘的PTP部署。
我们在最优和次优条件下测试了时间信号的传输行
为:不对称网络延时、保持性能、两个主时钟的源
切换等等。
我们将终端应用的时钟精度等级目标定义为±
1.5μs(ITU-T建议G.8271的精度等级4),0.4μs
作为空口的相位预算。因此,作为终端应用前的最
后一步,网络时钟精度的要求必须为±1.1μs。
我们采用了实验室屋顶L1天线提供的GPS作为主参考
时钟(PRTC)。同步测试团队今年工作量相当饱满,
有超过40个成功组合,他们都乐于测试全新的软件
版本、产品和接口类型,包括100GE接口的PTP支持。
我们的测试帮助发现了一些小问题,不过厂商的研
发部门反应迅速,提供了修复补丁和故障排查支持。
相位/时间的部分定时支持
此 测 试 仅 使 用 ITU-T G.8275.2 profile ( PTP
telecom profile,用于从网络获取基于部分定时支
持的相位/时间同步),没有任何类似SyncE的物理
频率参考。
在这种设置中,主时钟配备了GPS输入,从时钟和边
界时钟则从自由运行状态开始启动。
测试首先在边界时钟上启用PTP,Calnex Paragon-X
根据G.8261测试用例12中定义的profile模拟数据包
延迟变化(PDV)。在Meinberg LANTIME M4000作为T-
GM和Ericsson Router 6675作为电信级边界时钟(T-
BC)的组合中(以及本文档中其他所有出现这种组合
的地方),边界时钟未能基于衰减profile锁定主时
钟。因此,我们同意使用损伤的弱化版本,其中的
所有参数都降低了50%。
边界时钟锁定到主时钟后,我们让从时钟通过PTP锁
定到边界时钟,并验证其满足ITU-T G.823 SEC Mask
要求的相位精度和频率。
我们成功地测试了以下组合:Meinberg LANTIME
M4000和Oscilloquartz OSA5421 HQ++ 作为主时钟,
Ericsson-Router 6675和Meinberg LANTIME M1000S
作为边界时钟,Microsemi TimeProvider 2300、
Microsemi TimeProvider 4100 和 Oscilloquartz
OSA5421 HQ++作为从时钟。
Calnex Paragon-X 用 来 提 供 PTP 损 伤 。 Calnex
Paragon-X或Calnex Paragon-T对被测设备的相位输
出进行测量。
在这个测试例的另一个设置中,我们计划用透明时
钟来代替边界时钟,但在此情况下,当引入损伤后,
从时钟未能锁定到主时钟。
图38:相位/时钟的部分定时支持
相位/时间的部分辅助定时支持
该 测 试 在 主 时 钟 和 边 界 时 钟 之 间 基 于 ITU-T
G.8275.2 profile运行,边界时钟和从时钟之间参
测者可选择运行G.8275.1或G.8275.2。
主时钟和边界时钟都连接到GPS,从时钟通过PTP锁
定到边界时钟。然后,根据G.8261测试用例12中定
义的profile启动损伤来模拟数据包延迟变化。一
些组合使用了损伤的弱化版本,其中所有参数都降
低了50%。
断开GPS与电信级边界时钟-主时钟的连接之后,我
们验证边界时钟切换到PTP,并确认其输出满足±
1.1μs的相位精
32
度要求和频率要求。最后,我们将GPS天线重新连接
到电信级边界时钟-主时钟,进行重新测量。
我们成功地测试了以下组合:Ericsson Router 6471、
Meinberg LANTIME M4000、Microsemi TimeProvider
4100和Oscilloquartz OSA5421 HQ++ 作为主时钟参
与。Ericsson-Router 6675、Ericsson MINI-LINK
6651、Ericsson MINI-LINK 6366 、
Meinberg LANTIME M1000S和Oscilloquartz OSA5421
HQ++作为边界时钟参与;Oscillo- quartz OSA5421
HQ++、Microsemi Time Provider 2300、Microsemi
TimeProvider 4100、Huawei
NE40E-M2K 、 Huawei NE40E-X2-M8A 和 Ericsson
Baseband 6630作为从时钟参与。
Calnex Paragon-X 用 来 提 供 PTP 损 伤 。 Calnex
Paragon-X或Calnex Paragon-T对被测设备的相位输
出进行测量。
图39:相位/时间的部分辅助定时支持
图40:相位/时钟的部分辅助定时支持
在一个组合中,我们观察到边界时钟的一个问题:
当向下游的不同客户端同时使用ITU G.8275.1和
8275.2 profile时,APTS备用路径未能达到就绪/锁
定状态。 在另一个组合中,我们观察到边界时钟变
成了电信级主时钟(T-GM),因此并没有增加跳数,
并且把值删除掉了,也没有把电信级主时钟的父ID
显示给从时钟。该厂商的解释是,由于电信级边界
时钟标准化进程仍在进行当中,该功能特性还没有
实现。
33
相位/时间的部分辅助定时支持:时延不对
称
该 测 试 在 主 时 钟 和 边 界 时 钟 之 间 基 于 ITU-T
G.8275.2 profile运行,边界时钟和从时钟之间参
测者可选择运行G.8275.1或G.8275.2。
图41:相位/时间的部分辅助定时支持:时延不对称
主时钟和边界时钟都连接到GPS。然后,根据G.8261
测试用例12中定义的profile启动损伤以模拟数据包
延迟变化。一些组合使用了损伤的弱化版本,其中
所有参数都降低了50%。
将 GPS 从 边 界 时 钟 断 开 之 后 , 我 们 用 Calnex
Paragon-X引入了额外的125μs不对称时延,验证了
边界时钟可以计算和补偿所引入的不对称性。
我们成功测试了这些组合:Ericsson Router 6471、
Meinberg LANTIME M4000 、 Micro- semi
TimeProvider 4100和Oscilloquartz OSA5421 HQ++
作为主时钟参与,Ericsson Router 6675、Meinberg
LANTIME M1000S、Microsemi TimeProvider 2700和
Oscilloquartz OSA5421 HQ++ 作为边界时钟参与,
Ericsson MINI-LINK 6651、Ericsson MINI-LINK
6366、Ericsson Baseband 6630、Huawei NE40E-X2-
M8A、Huawei NE40E-M2K、Microsemi TimeProvider
2300、NEC iPASOLINK VR 和Oscilloquartz OSA5421
HQ++ 作为从时钟参与。
图42:相位/时间的部分辅助定时支持:时延不对称
Calnex Paragon-X 用 来 提 供 PTP 损 伤 。 Calnex
Paragon-X或Calnex Paragon-T对被测设备的相位输
出进行测量。
在这个测试中,我们观察到设备充当边界时钟时表
现出不同行为,这与设备内部晶振器的质量有关。
引入不对称时延后,一些电信级边界时钟能继续锁
定主时钟;而另一些则在引入不对称性时延后进入
了保持模式
34
(时钟等级160),即优选内部振荡器的时间。一旦
执行了校准,它们会恢复到时钟等级6。
相位/时间同步:时钟源故障倒换
图43:相位/时间同步:时钟源故障倒换
在这个设置中,两个主时钟都从普通GPS天线处获
得GPS信号。我们让边界时钟锁定到主用主时钟,
然后断开主用主时钟的GPS输入,以降低它的质量。
我们验证了边界时钟切换到备用主时钟,并测量了
从时钟的瞬态响应。我们还测试了主时钟是否按照
电信profile发送了正确的时钟等级值,这将使得
边界时钟上运行的备用最佳主时钟算法在测试的每
一步都能够正确地选择最佳主时钟。
测试使用字段优先级2作为仲裁参数。我们成功测
试 了 以 下 组 合 : Ericsson Baseband 6620 、
Meinberg LANTIME M4000 、 Meinberg LANTIME
M1000S 、 Microsemi TimeProvider 5000 和
Oscilloquartz OSA5421 HQ++ 作为主时钟参加,
Ericsson Router 6675、Huawei NE40-M2K和NEC
iPASOLINK VR作为边界时钟参加,Huawei NE40E-
X2- M8A 、 Meinberg M1000S 、 Microsemi
TimeProvider 2300 、 NEC iPASOLINK VR 、
Oscilloquartz OSA5421 HQ++和UTStarcom UAR500
作为从时钟参加。
此外,有两个组合使用了100GbE链路:作为边界时
钟的Ericsson Router 6675与作为从时钟的Huawei
NE40E-X2-M8A和UTStarcom UAR500之间的连接是
100GbE。
在一个失败的组合中(未在本报告中显示),我们
观察到一个与ptpTimeScale标志设置为TRUE有关的
问题,设备此时 currentUTCOffset设置为 36s,
currentUTCOffsetValid为FALSE。按照PTP标准第
8.2.4.2 a)节规定,ptpTimescale为TRUE情况下,
currentUTCOffset应从主参考时钟(本例中为GPS)
获得。因此,我们期望的UTC偏移量应该为37s,且
有效标志应该设置为TRUE。这个问题导致电信级边
界时钟不能锁定主时钟。
35
相位/时间同步完全定时支持:微波传输
我们从自由运行模式的从时钟开始测试,采用最高
阶调试方案以最高线路速率产生恒定的流(10%的
576字节数据包,30%的64字节数据包,60% 的字节
数据包),测试期望无丢包。
从时钟锁定之后,使用Calnex Paragon-T设备进行
基线测量。为了模拟恶劣的天气条件,我们使用射
频衰减器降低微波网络两个节点之间的带宽。如预
期一致,节点通过改变调制方式来应对。
然后,我们验证了PTP流量优先于其他数据流量,不
受调制方式变化的影响,从时钟的输出保持了所要
求的质量水平。由于带宽的减少,我们观察到有其
它数据包被丢弃。
在第一种设置中,微波站充当边界时钟,而在第二
种设置中,微波站充当透明时钟。
我们成功地测试了以下组合:Meinberg LANTIME
M4000和Microsemi Time-Provider 5000作为主时钟
参与,Ericsson MINI-LINK 6352、Ericsson MINI-
LINK 6651和NEC iPASOLINK VR作为边界时钟参与,
NEC iPASOLINK VR作为透明时钟参与,Ericsson
Router 6371 、 Huawei CX600-X2-M8A 、 Huawei
NE40E-X2-M8A 、 Meinberg LANTIME M1000S 和
Microsemi Time-Provider 4100作为从时钟参与。
图44:相位/时间同步的完全定时支持:微波传输
36
相位/时间同步:主用时钟源劣化
根据ITU-T G.8275中定义的体系结构,边界时钟可
以充当主时钟,也可以充当另一个PTP时钟的从时钟。
本测试的目标是测试边界时钟端口的角色从主切换
为从以及做相反切换的能力。
该测试基于ITU-T G.8275.1 profile进行。
我们为主时钟和其中一个边界时钟(BC-A)提供了
GPS信号。测试允许主时钟和边界时钟A锁定到GPS输
入。边界时钟A充当上游边界时钟(BC-B)的主用主
时钟。
然后,断开边界时钟A的天线模拟GPS故障,并且验
证两个边界时钟通过PTP锁定到中央主时钟。最后,
恢复边界时钟A的GPS,验证边界时钟B再次锁定到下
游边界时钟A。
我们成功地测试了以下组合:Ericsson Router 6675
和Microsemi TimeProvider 4100作为主时钟参与,
Ericsson Router 6371、Huawei CX600-X2-M8A、NEC
iPASOLINK VR以及Oscilloquartz OSA5421 HQ ++作
为边界时钟B参与,Meinberg LANTIME M1000S作为边
界时钟A参与。
Ericsson Router 6675和Huawei NE40E-X2-M8A之间
的链路采用100GbE。
在其他失败的组合中(图中未显示),由于功能未
实现,因此充当BC-A的设备无法将端口的运行模式
从主切换为从。
图45:相位/时间同步:主用时钟源劣化
37
相位/时间同步:核心网络支持Sync-E
图46:相位/时间同步:核心网络支持Sync-E
核心网络无法部署PTP的场景下,通常在网络边缘部
署一个或多个“分布式主时钟”,并为其提供GPS。
该测试例的目的是验证在GPS不可用且Sync-E用作
GPS备份时,边界时钟的保持性能与相位/时间稳定
性的关系。
在这种设置中,主时钟和边界时钟均配备了来自普
通GPS天线的GPS信号。
在边界时钟和主时钟之间(上游)只有Sync-E,而
边 界 时 钟 和 从 时 钟 之 间 ( 下 游 ) 应 用 ITU-T
G.8275.1。
首先,测试先让从时钟稳定锁定时钟,然后模拟连
接到边界时钟的GPS天线故障。
我们测量到,保持状态至少在30分钟以内可以满足
±1.1μs的相位精度要求。
我们成功地测试了以下组合:Meinberg LANTIME
M4000和Oscilloquartz OSA5421 HQ ++作为主时钟
参与,Ericsson Router 6471、Meinberg LANTIME
M1000S和Oscilloquartz OSA5421 HQ ++作为边界时
钟参与,Huawei NE40E-X2-M8A、Meinberg LANTIME
M1000S和Microsemi TimeProvider 4100作为从时钟
参与。
在另外一个组合中(图中没有显示),我们观察到
GPS被拔出后,电信级边界时钟如预期一样进入了
holdover-within-of-spec(时钟等级135),但是只
过了7分钟就变为holdover-out-of-spec(时钟等级
165)。这意味着从时钟失去了对边界时钟的PTP锁
定。
总结 我们整个EANTC团队很高兴在柏林实验室与21个厂
商的专业团队一起工作。在两周紧张的工作期间,
他们取得了长足的进展,也以此共同推动了行业的
发展。祝贺他们所有人,我们也期待2019年,看看
他们将会带来什么!
38