CN103634139A

CN103634139A - 多跳回应端会话

Info

Publication number: CN103634139A
Application number: CN201310314282.8A
Authority: CN
Inventors: 亨里克·尼德尔
Original assignee: Accedian Networks Inc
Current assignee: Accedian Networks Inc
Priority date: 2012-07-24
Filing date: 2013-07-24
Publication date: 2014-03-12
Also published as: US20210029010A1; US11451459B2; EP2690823A1; US9960982B2; US20220417126A1; US10826809B2; US20180219758A1; US20140029441A1; US11909615B2

Abstract

本发明涉及用于测量和报告网络中的性能参数的方法，该网络具有用于生成测试协议数据单元的至少一个始发端和用于沿着该网络中的测试路径的连续节段将所述测试协议数据单元进行中继的多个回应端。该方法在始发端处生成测试协议数据单元并且沿着包括多个回应端的测试路径传输所述测试协议数据单元。各回应端沿着所述测试路径将所述测试协议数据单元中继至下一个回应端。通过下列方式收集所述测试协议数据单元中的来自所述多个回应端的性能参数测量结果：在所述始发端和各所述回应端处将时间戳插入所述测试协议数据单元中，从而识别各所述测试协议数据单元在所述始发端和各所述回应端处在沿着所述测试路径的下游方向及上游方向上的离开及到达时间。

Description

多跳回应端会话

相关申请的交叉参考

将2012年7月24日提交的美国专利申请第13/557,138号的全部内容以引用的方式并入本申请中。

技术领域

本发明涉及在以太网OAM（Operations Administration andMaintenance，操作管理和维护）框架的前提下的多跳回应端会话（Multi-hop Reflector Session）。

背景技术

多年来，以太网已经被用作LAN（Local Area Network，局域网）技术，并且各企业已经利用诸如简单网络管理协议（SNMP）、ICMP Echo(因特网控制报文协议回送)（或者IP Ping）、IP路由跟踪（IP Traceroute）和思科单向链路检测协议（UDLD）等因特网协议来管理这些网络。EOAM（以太网操作管理和维护）是用于对MAN（Metropolitan Area Network，城域网）和WAN（Wide Area network，广域网）进行安装、监控和故障排除的一组协议。由于目前存在的是具有广泛用户基础（该广泛用户基础涉及了提供端对端服务的不同运营商）的大规模且复杂的网络，所以作为联网技术的以太网的运用还需要一组新的OAM协议。

IETF（Internet Engineering Task Force，因特网工程任务组）发展并提升了因特网标准。单向主动测量协议（One-way Active MeasurementProtocol，OWAMP）[RFC4656]提供了用于测量网络设备之间的单向指标的公共协议。OWAMP能够被双向地使用从而在两个网络元件之间在两个方向上都测量出单向指标。然而，它无法适应于往返（round-trip）或双向测量。

双向主动测量协议（Two-Way Active Measurement Protocol，TWAMP）[RFC5357]提供了用于测量两个设备之间的往返IP性能（包丢失、包延迟和包抖动）的基于标准的方法。TWAMP使用单向主动测量协议（OWAMP）的方法论和架构来定义对双向或往返指标进行测量的手段。

在TWAMP中存在四个逻辑实体：控制客户端（Control-Client）、会话发起端（Session-Sender）、服务器和会话回应端（Session-reflector）。控制客户端和会话发起端通常是在一个物理设备（“客户端”）中实现的，而服务器和会话回应端通常是在第二个物理设备（“服务器”）中实现的，并且利用它们来进行双向测量。

控制客户端和服务器建立TCP（Transmission Control Protocol，传输控制协议）连接并且通过该连接来交换TWAMP控制信息。当控制客户端想要开始测试时，客户端将测试参数传达至服务器。如果服务器同意进行所述测试，那么一旦客户端发送了开始会话（Start-Session）消息就开始该测试。作为测试的一部分，会话发起端向会话回应端发送基于UDP（User Datagram Protocol，用户数据报协议）的测试包流，并且会话回应端以响应的基于UDP的测试包来响应各个所接收到的包。当会话发起端接收到来自会话回应端的响应包时，该信息被用来计算上述两个设备之间的双向延迟、包丢失和包延迟变化。

ITU（International Telecommunication Union，国际电信联盟）是针对信息通信技术（ICT）的联合国专门机构。ITU标准（被称为“Recommendation”）是ICT网络的运行基础。ITU-T Y.1731性能监控提供了基于标准的以太网性能监控，其包括对以太网帧延迟、帧延迟变化、帧丢失和吞吐量的测量。

IEEE802.1ag IEEE Standard for Local and Metropolitan AreaNetworks Virtual Bridged Local Area Networks Amendment5:ConnectivityFault Management（IEEE802.1ag局域网和城域网_虚拟桥接局域网_修正件5：连通性故障管理的IEEE标准）是由IEEE（Institute of Electrical andElectronics Engineers，美国电气和电子工程师协会）定义的标准。它针对通过桥和局域网（LAN）的路径定义了OAM的协议和实践。它在很大程度上与ITU-T Recommendation Y.1731是相同的。该标准中：

·定义了维护域、这些维护域的组成维护点、以及在创立和管理这些维护域时所需要的被管理对象；

·定义了维护域与由VLAN设备网桥及供应商网桥提供的服务之间的关系；

·描述了被维护点使用以便维护和诊断维护域内的连通性故障的协议及程序；

·提供了用于未来扩展维护点及其协议的容量的手段。

ITU Y.1731和类似的OAM标准（包括但不限于TWAMP）要求在始发端（客户端）与回应端（会话回应端）之间进行明确的协商以建立唯一的流标识符（Flow Identifier）。这种方式阻止了Test PDU（Testprotocol data unit，测试协议数据单元）如图1所示的那样被始发端下游的多个回应端处理。

由于在现有技术中需要明确地生成不同的OAM会话（每一对始发端和回应端就有一个OAM会话），因此无法从始发端生成能够沿着测试路径一次就从一个以上的回应端收集测量结果的Test PDU，即使该Test PDU可以穿过上述这些回应端以到达远端的回应端。

图2至图4来自于ITU Y.1564标准，并且被用来图示延迟需要和为了使以太网电路在安装时合格而需要的其它测量结果。来自于ITUY.1563的图2图示了以太网服务的性能的分层性质。该网络包括定向连接链路或者无连接链路，这些链路被连接至将要对该网络内的以太网层（Ethernet Layer）进行处理的桥。每次当以太网帧正在经过以太网层时，该以太网帧将会被处理以具有完整性并且将会通过下层（Lower Layer，LL）连接而被发送至下一个桥。下层基于多种技术，例如SDH、OTN、PDH、MPLS、ATM和ETY。所有以太网层和下层的性能将会影响被用来提供服务的网络的端对端性能。

上层（Higher layer）可以被用来实现端对端通信。上层可以包括像IP、MPLS和Ethernet一样的允许网络部署具有更大的可扩性的协议。像TCP一样的其它协议提供了如果发生帧丢失就重新传输帧的能力。遗憾的是，TCP的两个缺点是：增加了在用户信息的传输中的延迟；以及对通告窗口（advertised window）最大尺寸、与带宽延迟积（bandwidth-delayproduct）的相互作用和与以太网服务的丢失及延迟的流控制相互作用的可能限制。该实施方式能够基于如下的事实来独立地进行所要求的测量：该事实即是，被用来支持以太网虚拟电路（Ethernet Virtual Circuit，EVC）的链路（或下层LL）可以在层2或层3处运行。

来自于ITU Y.1564的图3提供了以太网服务区域的简单实例并且被称作以太网服务激活测量。该测试的目标是为了验证基于以太网的服务的配置和性能。该测试验证了包括承诺信息速率（Committed InformationRate，CIR）、额外信息速率（Excess Information Rate，EIR）和其它属性的以太网服务属性。该图示出了支持以太网服务实例的网络的不同部分。

该图还示出了UNI参考点出现在访问链路的中间，或者更加准确地说，UNI是其功能被分为客户（UNI-C）组件和网络（UNI-N）组件的参考点。从服务供应商的角度来看，他们需要提供从UNI-C到UNI-C的服务并且这是从创立了测试方法论的角度出发的。

CE（Customer Equipment，客户设备）和运营商的网络在UNI上交换服务帧，服务帧是在UNI上向服务供应商传输的以太网帧（称作入口服务帧）或在UNI上向CE传输的以太网帧（称为出口服务帧）。在各UNI上运行着许多服务。它们在它们的如下属性方面是合格的：

·连接类型

·流量参数：QoS(包括VLAN信息)、流量类型(数据vs.管理)等

·带宽轮廓

·性能标准：FD、FDV、帧丢失率、可用性等

据此，容易看出以太网虚拟电路实际上可以在层2或层3处跨越多个运输网络。这对利用传统方法有效地测量延迟和包丢失提出了挑战。该性能测量仅能够在运输运营商网络（Transport Operator Network）的内部边界之外进行。

来自于ITU-T y.1563的图4图示了在不同的用于支持EVC的下层之间的边界处通常是如何建立测量点（Measurement Point，MP）的。这些MP（或回应端）的定位对于获得适当的测量结果是至关重要的。依照上述该图，双向延迟测量通常是从SRC到DST且返回至SRC来进行的，并且不提供各交换链路（或下层）的详细延迟信息。出于性能测量的目的，该性能测量仅能够在MP是可寻址的网络段的内部边界之外进行。

发明内容

根据一个实施例，提供了一种用于测量和报告网络中的性能参数的方法，所述网络具有用于生成测试协议数据单元的至少一个始发端和用于沿着所述网络中的测试路径的连续节段对所述测试协议数据单元进行中继的多个回应端。所述方法在所述始发端处生成所述测试协议数据单元并且沿着包括所述多个回应端的所述测试路径传输所述测试协议数据单元。各所述回应端沿着所述测试路径将所述测试协议数据单元中继至下一个所述回应端。通过下列方式收集所述测试协议数据单元中的来自所述多个回应端的性能参数测量结果：在所述始发端和各所述回应端处将时间戳插入所述测试协议数据单元中。所述时间戳识别（1）当所述测试协议数据单元离开所述始发端的时间以及（2）当所述测试协议数据单元在沿着所述测试路径的下游方向和上游方向上离开和到达各所述回应端的时间。

在一个实施例中，各所述回应端分别被配置有所述测试路径中的下一个所述回应端的寻址信息，并且所述寻址信息被用来将所述测试协议数据单元中继至下一个所述回应端。各所述回应端被配置有该回应端自己的寻址信息，在所述测试协议数据包从最后一个所述回应端传回至所述始发端的期间内当从下一个所述回应端接收所述测试协议数据包时要使用该回应端自己的寻址信息。

附图说明

通过参照下面的结合附图的说明，可以最好地理解本发明。

图1图示了以太网中从始发端到多个回应端的测试路径。

图2图示了来自于ITU Y.1563的以太网服务的性能的分层结构。

图3是来自于ITU Y.1564的以太网服务激活测量的示例。

图4图示了来自于ITU Y.1563的以太网中的测量点（MP）的位置。

图5图示了针对在多个回应端上的双向环回（loopback）测量而生成了时间戳的地方。

图6是ITU Y.1731销售商专用OAM PDU（ETH-VSP）。

图7是由始发端设定的所有PDU域的表。

图8图示了对于流数据（Stream Data）类型长度值（Type-Length-Value，TLV）的格式的扩展。

图9图示了由始发端生成并且扩展的流数据TLV。

图10图示了在被回应端使用时的所生成并且扩展的流数据TLV。

具体实施方式

尽管将会结合某些优选实施例来说明本发明，但应当理解的是，本发明不限于这些特定的实施例。相反地，本发明旨在涵盖落入由随附的权利要求限定的本发明的精神和范围内的全部替换例、变形例和等同配置。

本实施例是在需要如下框架的前提下发挥作用的：该框架允许如同在诸如ITU-T Y.1731、IETF RFC5357（TWAMP）和IEEE802.1ag等标准中所定义的性能测量。这些标准都依赖于始发端（或会话发起端）的向回应端（或会话回应端）生成测试流量（test traffic）的概念，其中双向测量会要求回应端将测试流量返回（或反映）至始发端。

这些标准具有对两个方向（上行链路uplink和下行链路downlink）的所有的必需指标（延迟、抖动、丢失、乱序等）进行测量和报告以说明网络的性能的能力，利用该能力，这些标准针对层2交换网络凭借双向测量功能（即2×单向）能够实现有效的延迟和包丢失测量。

以太网OAM框架定义了用于连通性验证和性能监控的许多功能。本实施例关注于这些功能中的两者：以太网环回（ETH-LB）和双向帧延迟测量（ETH-DM）。这两项功能都是双向的，即，始发端将会向回应端发送一个或多个测量帧，而回应端（在MAC地址的处理和交换等之后）将这些测量帧发送回始发端。

在ETH-LB中，所有的被测量且被报告的指标（延迟、抖动和帧统计）都基于双向测量。

当测量ETH-DM延迟和抖动（延迟变化）时，DMM/DMR（延迟测量消息/延迟测量应答）信息被扩展为包含具有32位序列号的数据TLV（类型长度值），从而基于双向测量来测量并报告帧统计（即，丢失、乱序、复制包）指标。

本实施例是具有测量并报告针对两个方向的上述指标的能力的双向层3解决方案。2×单向的会话包括始发端和回应端。

当多个回应端被设定在始发端的下游时，该始发端需要明确地直接向各回应端生成Test PDU以获得双向延迟和包丢失测量结果。为了减小测试流量并且为了在被控制得更好的时间窗口内更有效地收集测量结果，需要生成能够穿过多个回应端并且收集具体测量结果的Test PDU。

下列能力是非常令人期望的能力：生成被寻址至第一个回应端的单个Test PDU（或Test PDU的序列），该第一个回应端随后将会把该TestPDU中继至下游的下一个回应端，而该下一个回应端也会把该Test PDU向下游中继，直到回应端链的末尾，并且随后该Test PDU一路上都向上游（通过回应端链）返回直至返回到始发端。这有助于在收集与同一TestPDU相关的测量以提高这些测量的相关性的同时显著地减小测试流量。

本实施例不要求始发端与回应端之间的“OAM会话”的显式配置。所必需的用来唯一地识别潜在的多个OAM会话中的一者的流标识符是由回应端自动生成的。此方法不仅简化了始发端-回应端对的操作，还使得回应端能够将Test PDU向下游中继至另一回应端以扩展由单个2×单向的Test PDU获得的测量的范围，从而将特定时间点处的网络全体操作更好地关联起来。通过让各个回应端先在下游方向（在测试路径中远离始发端并且晚于初始回应端）上然后在上游方向（向着始发端的返回路径）上插入特定的时间戳标记，就能够在提高测量相关性（这是因为这些测量都与同一个初始的Test PDU相关）的同时针对存在有回应端的每个下层连接都获得具体的延迟和包丢失测量。

通过让测试路径中的各回应端插入流数据TLV以保持它们的特定测量并且通过更新如同ITU Y.1731（及有关标准）中所定义的时间戳的意义，就能够通过从始发端生成单个Test PDU来沿着测试路径收集来自多个回应端的测量。在从来自于始发端的单个PDU中收集到更多测量的同时，显著地减少了由始发端生成的测试PDU的数量。基于中间的回应端跳的额外测量显著地加强了可用于更准确地识别在特定节段（一对回应端单元之间）上的延迟和/或包丢失的信息。

在本实施例中，双向延迟测量的发起者被称为始发端（会话发起端），并且回应端（会话回应端）应答该双向延迟测量请求。

图5图示了如下情况：对于从始发端100经过多个回应端（101、102、103、104）的双向环回测量，生成了时间戳（105、106、107、108、109、110、111、112、113、114、115、116、117、118、119、120）。能够获得来自多个回应端（101、102、103、104）的延迟和包丢失测量结果，这些回应端（101、102、103、104）分别相距一跳（尽管各跳可能导致多个子网络或交换链路）。通过利用累积于Test PDU中的测量（凭借插入在Test PDU的有效载荷部分中的流数据TLV），始发端100就能够收集并计算具体的延迟和包丢失性能测量结果。例如，就能够计算出下列的值：

T3orig–T0orig=从始发端(100)一直到回应端n(104)的总双向延迟

T1orig–T0orig=从始发端(100)到回应端1(101)的单向延迟

T1R1–T0R1=从回应端1(101)到回应端2(102)的单向延迟

T1Rn–T0Rn-1=从回应端n-1(103)到回应端n(104)的单向延迟

T1Rn–T0orig=从始发端(100)一直到回应端n(104)的单向延迟

T3Rn-1–T2Rn=从回应端n(104)到回应端n-1(103)的返回延迟

T3R2–T3R1=从回应端2(102)到回应端1(101)的返回延迟

T3R1–T0R1=从回应端1(101)一直到回应端n(104)然后返回的总双向延迟

熟悉本领域的技术人员应当能够基于沿着下游方向的测试路径（朝向末尾的回应端104）和沿着朝向始发端100的上游方向的返回测试路径而累积的多个时间戳，计算出额外的延迟测量信息。

存在有多个可选方案来使得从始发端100到回应端1（101）的TestPDU能够沿着经历多个下游回应端（102、103、104）的测试路径行进。

在一个实施例中，各回应端（101、102、103、104）被配置有将TestPDU中继至下一个下游回应端所需要的寻址信息。利用该方案，各回应端（101、102、103、104）只需要被配置有与它的直接下游的回应端（根据规定的测试路径）有关的信息。当中继回应端将Test PDU中继至下游回应端时，该中继回应端将会把它的寻址信息包含在内以便能够接收来自下游回应端的应答。

在另一实施例中，始发端100使Test PDU直接向测试路径中的回应端（101、102、103、104）链中的最后一个回应端（104）寻址，但使该Test PDU沿着测试路径路由至回应端1（101）。中间回应端（102、103）作为一连串的“路由器”进行操作，其中各回应端将它自己的测量插入到被分配给它的适当流数据TLV中并且随后将Test PDU中继至测试路径中（下游或上游方向上）的下一个回应端。

在又一实施例中，始发端100（通过配置或凭借发现法）知晓沿着测试路径的回应端（101、102、103、104）的列表。这使得始发端100能够预填充所有的所必需的流数据TLV300（每一个回应端101、102、103、104就有一个流数据TLV的实例）作为Test PDU的有效载荷的一部分。索引字段（index field）被各个中间回应端101、102、103、104递增，从而使得能够识别出被分配给它的是哪一个流数据TLV300。下一个/下游回应端的寻址信息也被始发端100包含在Test PDU内。该信息随后被中间回应端（101、102）使用，以将Test PDU在下游方向上中继至下一个回应端和在上游/返回路径方向上向上中继至前一个回应端。

在再一实施例中，Test PDU沿着测试路径向最后一个回应端104寻址。各中间回应端以混杂模式（Promiscuous Mode）进行操作，并且在沿着测试路径在上游或下游方向（根据需要）上将Test PDU中继至下一个回应端之前捕获该Test PDU从而在适当的流数据TLV中插入其自己的测量。

在另外一实施例中，就像已经从始发端100直接接收到Test PDU一样，各个中间回应端向该始发端100生成直接应答。该方案能够生成相同级别的测量，但由于朝着始发端生成的更多数量的应答可能会使始发端溢出或者当在服务中使用时（而不是在服务激活阶段的期间内）可能会影响用户数据的性能，所以必须谨慎。

当在既定的回应端之后存在有多个（下行链路）回应端，例如处于星型拓扑时，期望始发端100将该星型拓扑的各个潜在分支作为不同的测试路径进行处理，并且针对每个可能的路径在独立于其它路径的情况下发起双向测量。

依据本发明适用的各种标准的具体定义而定，如果未提供对至少3个时间戳的原生支持，那么可能需要扩展Test PDU的编码。

支持对TLV的使用以支持至少3个时间戳的标准的示例是ITUY.1731标准。为了支持来自于沿着测试路径被访问的各回应端的测量，ITU Y.1731协议凭借销售商专用OAM-PDU（ETH-VSP）的观念提供了可扩展的编码。对于各个被访问的回应端而言向ETH-VSP编码添加流数据TLV，以支持本发明中所定义的双向测量测试。时间戳（T0至T3）使用了在IEEE1588-2004中定义的时间戳格式。用于ETH-VSP的流数据TLV已被分配了MType=209。

图6图示了ITU Y.1731销售商专用OAM PDU（ETH-VSP）。

图7是由始发端100设定的所有PDU字段的表，这些字段除了OpCode字段302之外都不能被回应端（101、102、103、104）改变。对于此实施例，流数据TLV300被扩展了。

图8图示了对流数据TLV300的格式的扩展。流数据TLV300应当被扩展为包括针对于沿着测试路径的各回应端（101、102、103、104）的唯一标识符（或索引）。预留字段400被用于保持唯一回应端标识符。

此外，Test PDU的有效载荷中的各流数据TLV300应当包括在对来自于测试路径中的各回应端的必不可缺的延迟测量进行收集时所需要的4个时间戳。

图9图示了由始发端100生成和扩展的流数据TLV。

图10图示了所生成和扩展的流数据TLV300，其被回应端（101、102、103、104）在对（直接地或经由上游回应端）从始发端100接收到的Test PDU进行应答时使用。

当诸如RFC5357TWAMP等标准对于每个回应端跳（诸如多个TLV）的至少3个时间戳未提供原生支持时，就需要扩展上述协议。一个实施例是利用测试包的不用的部分（或填充位(filler)）来保持如下的结构：该结构能够存储各个回应端跳的至少4个时间戳以及上行链路和下行链路序列号。这样的结构还能够被扩展为基本上包括在图6中的流数据TLV300中定义的额外信息。MEG级别（MEG Level）包括但不限于：被接收和被发送的MEL（600、601），P位（P-Bit）设定值包括被接收和被发送的PBIT（602、603）等。可以使用被显示为与ITU Y.1731兼容的实施例的一部分的TLV编码或熟悉本领域的技术人员所熟知的任何其它变化例。所选的实施例择取了这样的Test PDU尺寸：该尺寸足够大以便能够保持各个回应端跳的序列号（401、402）和时间戳（403、404、405、406、407、408、409、410）信息，而又不超出由服务器OAM标准以及下面的层2和/或层3网络或网络节段所支持的最大PDU尺寸。

为了识别TLV以用于特定的回应端（101、102、103、104），当回应端（101、102、103、104）接收到具有被设定为VSM（51）的OpCode302的Test PDU时，该回应端搜索该Test PDU的有效载荷中的流数据TLV300的设定值以判定是否已经存在由始发端100为该回应端（101、102、103、104）生成的流数据TLV300。如果未发现流数据TLV300，那么回应端（101、102、103、104）在上一次发现的流数据TLV300之后添加流数据TLV300，并且将End TLV301标记移动到新插入的流数据TLV300之后。回应端（101、102、103、104）将预留/回应端ID字段500设定为被分配给该回应端（101、102、103、104）的唯一ID。

回应端随后设定T0和T1时间戳（105、106、107、108、109、110、111、112）。

如果存在另一下游回应端，则回应端将Test PDU中继至该下一个回应端。

否则，如果回应端是沿着测试路径的回应端链中的最后一个回应端（104），那么它将OpCode字段302改变为VSR（50）并且设定T2和T3时间戳（120、119）。对于在测试路径的末尾处的回应端，T3时间戳119被设定为0。一旦流数据TLV300被更新，VSR就朝着始发端100返回至上游流数据TLV300。

如果回应端101、102、103、104接收到具有已经被设定为VSR的OpCode302的Test PDU，那么它取回具有该回应端的回应端ID的流数据TLV300，并且随后在将Test PDU向上游中继至前一个回应端或始发端100（在沿着返回测试路径没有上游回应端的情况下）之前更新T2和T3时间戳（113、114、115、116、117、118、119、120）。

如果在被分配给该回应端的那个流数据TLV300之前没有发现流数据TLV300，这就表明没有其它的回应端并且Test PDU直接返回至始发端100。

由于回应端会话是自动创立的，因此每当经过预定的时间段（典型地，10秒数量级）没有收到来自始发端100（由唯一的流标识符识别）的Test PDU，就执行逾时机制以关闭回应端会话和自由关联源。如果在闲置时间届满之后接收到来自同一始发端100的新Test PDU，则回应端（101、102、103、104）自动生成新的流标识符。因此，需要有补充标签来向始发端100表示已经自动创立了新的回应端会话。这是通过由回应端（101、102、103、104）返回的识别号（Incarnation Number）（流数据TLV300中的IncNum411）来实现的。IncNum411是从全局识别计数器生成的无符号整数值，并且每次当分配新的IncNum411时，该计数器就增加一（1）。

IncNum=IncNumCnt;

IncNumCnt=IncNumCnt+1;

上面的2步操作被实施为原子操作（atomic operation），以确保在新的IncNum411被分配给回应端实例的同一时刻增加识别号计数器。

全局识别号计数器在系统启动时被初始化一次且被初始化为随机数，以将在系统重启后重新使用用于回应端实例的同一IncNum411的可能性最小化。全局识别计数器的环绕率取决于新的测量流的到达率和已经运行的测量流的再激活率。

在一个实施例中，回应端（101、102、103、104）将新生成的IncNum411与旧的回应端会话实例相比较，并且如果相等，那么回应端（101、102、103、104）就生成新的IncNum411，以避免将相同的IncNum411分配给服务于同一个测量流的回应端会话。

这里所说明的实施例适用于基于软件的、基于HW的和小型可插拔（SFP）的现场可编程门阵列（FPGA）始发端和回应端。本实施例还应用于能够使用层2地址（MAC地址）和/或层3地址（诸如IP地址）来编址的任何网络设备。

图5图示了与图4的系统类似的系统，其中将FPGA构造为嵌入式流量产生器。

图6图示了与图4的系统类似的系统，其中将FPGA构造成执行智能环回。

虽然已经图示和说明了本发明的特定实施例和应用，但应当理解的是，本发明不限于本文中公开的精确构造和组成，并且显然可以根据上述说明在随附的权利要求所限定的本发明的精神和范围内进行各种修改、变化和改变。

Claims

1.一种用于测量和报告网络中的性能参数的方法，所述网络具有用于生成测试协议数据单元的至少一个始发端和用于沿着所述网络中的测试路径的连续节段对所述测试协议数据单元进行中继的多个回应端，所述方法包括：

在所述始发端处生成所述测试协议数据单元并且沿着包括所述多个回应端的所述测试路径传输所述测试协议数据单元，各所述回应端沿着所述测试路径将所述测试协议数据单元中继至下一个所述回应端；以及

通过下列方式收集所述测试协议数据单元中的来自所述多个回应端的性能参数测量结果：在所述始发端和各所述回应端处将时间戳插入所述测试协议数据单元中，所述时间戳用于识别1）当所述测试协议数据单元离开所述始发端的时间以及2）当所述测试协议数据单元在沿着所述测试路径的下游方向及上游方向上离开及到达各所述回应端的时间。

2.根据权利要求1所述的方法，其包括：在所述下游方向及所述上游方向上，基于插入所述测试协议数据单元中的所述时间戳，计算所述测试数据协议单元沿着所述测试路径从所述始发端传送至最后一个所述回应端和从最后一个所述回应端传回至所述始发端的总双向延迟测量结果。

3.根据权利要求1所述的方法，其中，各所述回应端分别被配置有所述测试路径中的下一个所述回应端的寻址信息，并且所述寻址信息被用来将所述测试协议数据单元中继至下一个所述回应端。

4.根据权利要求3所述的方法，其中，各所述回应端被配置有该回应端自己的寻址信息，在所述测试协议数据单元从最后一个所述回应端传回至所述始发端的期间内当从下一个所述回应端接收所述测试协议数据单元时要使用该回应端自己的寻址信息。

5.根据权利要求1所述的方法，其中，

所述性能参数被存储在存储有至少三个时间戳值的所述测试数据协议单元中，并且

如果所述测试数据协议单元未存储有至少三个时间戳值，则将所述测试数据协议单元扩展为存储至少三个时间戳值。

6.根据权利要求1所述的方法，其中，所述始发端使所述测试数据协议单元寻址至最后一个所述回应端，但将所述测试数据协议单元路由至第一个所述回应端，由此沿着所述测试路径的各个后续的所述回应端将各自的性能测量结果插入所述测试数据协议单元中并且将所述测试数据协议单元中继至下一个所述回应端。

7.根据权利要求1所述的方法，其中，所述始发端用各所述回应端的寻址信息预填充所述测试数据协议单元，并且所述寻址信息被用来将所述测试数据协议单元中继至下一个所述回应端。

8.根据权利要求1所述的方法，其中，各所述回应端生成对所述始发端的直接应答。