MPLS + SDN + NFV2018全球多供应商互操作性测试报告

声明:本文译者钟庆(Cisco)、苏远超(Cisco),原作版权属于EANTC。本翻译文本只供学习参考使用,不代表译者所属公司的立场。

概述

在过去几年中,我们一直专注于测试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

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

互操作测试结果

像往常一样,本白皮书仅记录厂商和设备名称的正面结果(通过测试组合)。图中未提及失败的测试组合,这些将被匿名引用以描述行业的状态。我们的经验表明,参与厂商在我们的测试后会迅速解决互操作性问题,因此通过测试来惩罚他们的学习意愿是没有意义的。保密性对于鼓励制造商用他们最新的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功能是最基本的功能,用于沿着最短路径将流量引导到通告节点。
另一方面,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的前缀可达性。

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列出了这个测试场景的参与者。

图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。
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

图7:SR FRR/LFA链路保护

图8:SR MPLS TI-LFA链路保护

参与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。
在收到发送端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的长度。

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:基于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代理

我们采用两种不同的设置测试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中。在所有的测试组合中,我们用流量产生器验证了所有叶子间的全网状连接。

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

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路由服务器。

图22:无接口模型EVPN IP-VRF-to-IP-VRF

无接口模型
在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

图24:EVPN和IP-VPN互通 设置2

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

图25:EVPN VXLAN-SR MPLS互通

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

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展示了成功的参与者组合。

图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信息。

在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上手动触发路径更新

该测试中的绝大多数初始步骤与有状态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会话。

我们还确认了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行为还是厂商专有实现方式,由控制器通过若干步骤(事务)实现。

图31:L3VPN业务的创建和终止

L2VPN业务的创建和删除2

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将业务重新建模为两个不同的业务,并推送到两台域控制器。然后,每台域控制器将业务转换成设备配置,并推送到网络节点。为了验证业务创建,我们检查了设备的配置,并经由业务路径发送流量。最后,多域控制器成功执行了业务删除,设备配置被成功清除。
业务删除之后,测试流量被丢弃,与预期一致。

图33:多厂商/多域控制器编排

虚拟CPE与NETCONF集成

NETCONF可扩展以管理虚拟资源,例如虚拟客户端设备(vCPE)。
Adva用两台背靠背连接的FSP150 ProVMe参与了此测试,展示了vCPE组件和广域网的集成。在每台Adva设备上都创建一台第三方厂商的虚拟路由器,并对其进行手动配置。

图34:虚拟CPE与NETCONF集成

测试使用Spirent TestCenter在两台CPE和它们的虚拟路由器之间发送用户数据,验证配置成功。然后,vCPE虚拟路由器和Cisco NSO之间建立了NETCONF会话。由于时间关系,测试没有覆盖NETCONF/YANG的进一步应用。

微波

随着运营商将网络升级为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的业务

三层微波传输的弹性

将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:三层微波传输的弹性

时钟同步
在今年的测试中,我们聚焦于时钟/相位传输,涵盖了大量的弹性场景,使用完全和部分辅助定时支持设置,并且为只支持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的相位精度要求和频率要求。最后,我们将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显示给从时钟。该厂商的解释是,由于电信级边界时钟标准化进程仍在进行当中,该功能特性还没有实现。

相位/时间的部分辅助定时支持:时延不对称

该测试在主时钟和边界时钟之间基于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对被测设备的相位输出进行测量。
在这个测试中,我们观察到设备充当边界时钟时表现出不同行为,这与设备内部晶振器的质量有关。引入不对称时延后,一些电信级边界时钟能继续锁定主时钟;而另一些则在引入不对称性时延后进入了保持模式(时钟等级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。这个问题导致电信级边界时钟不能锁定主时钟。

相位/时间同步完全定时支持:微波传输

我们从自由运行模式的从时钟开始测试,采用最高阶调试方案以最高线路速率产生恒定的流(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:相位/时间同步的完全定时支持:微波传输

相位/时间同步:主用时钟源劣化

根据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:相位/时间同步:主用时钟源劣化

相位/时间同步:核心网络支持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年,看看他们将会带来什么!


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/20852.html
分享到:
相关文章
条评论

登录后才可以评论

kk_wu 发表于18-05-25
5