Embed Size (px)
Citation preview
版权及立场声明
原作版权属于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
