多跳回應端會話的制作方法
【專利摘要】本發(fā)明涉及用于測量和報告網(wǎng)絡中的性能參數(shù)的方法，該網(wǎng)絡具有用于生成測試協(xié)議數(shù)據(jù)單元的至少一個始發(fā)端和用于沿著該網(wǎng)絡中的測試路徑的連續(xù)節(jié)段將所述測試協(xié)議數(shù)據(jù)單元進行中繼的多個回應端。該方法在始發(fā)端處生成測試協(xié)議數(shù)據(jù)單元并且沿著包括多個回應端的測試路徑傳輸所述測試協(xié)議數(shù)據(jù)單元。各回應端沿著所述測試路徑將所述測試協(xié)議數(shù)據(jù)單元中繼至下一個回應端。通過下列方式收集所述測試協(xié)議數(shù)據(jù)單元中的來自所述多個回應端的性能參數(shù)測量結(jié)果：在所述始發(fā)端和各所述回應端處將時間戳插入所述測試協(xié)議數(shù)據(jù)單元中，從而識別各所述測試協(xié)議數(shù)據(jù)單元在所述始發(fā)端和各所述回應端處在沿著所述測試路徑的下游方向及上游方向上的離開及到達時間。
【專利說明】多跳回應端會話
[0001]相關(guān)申請的交叉參考
[0002]將2012年7月24日提交的美國專利申請第13/557，138號的全部內(nèi)容以引用的方式并入本申請中。
【技術(shù)領(lǐng)域】
[0003]本發(fā)明涉及在以太網(wǎng)OAM (Operations Administration and Maintenance,操作管理和維護)框架的前提下的多跳回應端會話(Mult1-hop Reflector Session)。
【背景技術(shù)】
[0004]多年來，以太網(wǎng)已經(jīng)被用作LAN (Local Area Network,局域網(wǎng))技術(shù),并且各企業(yè)已經(jīng)利用諸如簡單網(wǎng)絡管理協(xié)議(SNMP)、ICMP Echo (因特網(wǎng)控制報文協(xié)議回送)(或者IPPing)、IP路由跟蹤(IP Traceroute)和思科單向鏈路檢測協(xié)議(UDLD)等因特網(wǎng)協(xié)議來管理這些網(wǎng)絡。EOAM (以太網(wǎng)操作管理和維護)是用于對MAN (Metropolitan Area Network,城域網(wǎng))和WAN(Wide Area network,廣域網(wǎng))進行安裝、監(jiān)控和故障排除的一組協(xié)議。由于目前存在的是具有廣泛用戶基礎(chǔ)(該廣泛用戶基礎(chǔ)涉及了提供端對端服務的不同運營商)的大規(guī)模且復雜的網(wǎng)絡，所以作為聯(lián)網(wǎng)技術(shù)的以太網(wǎng)的運用還需要一組新的OAM協(xié)議。
[0005]IETF (Internet Engineering Task Force,因特網(wǎng)工程任務組)發(fā)展并提升了因特網(wǎng)標準。單向主動測量協(xié)議(One-way Active Measurement Protocol, Off AMP) [RFC4656]提供了用于測量網(wǎng)絡設備之間的單向指標的公共協(xié)議。OWAMP能夠被雙向地使用從而在兩個網(wǎng)絡元件之間在兩個方向上都測量出單向指標。然而，它無法適應于往返(round-trip)或雙向測量。
[0006]雙向主動測量協(xié)議(Two-WayActive Measurement Protocol, TffAMP) [RFC5357]提供了用于測量兩個設備之間的往返IP性能(包丟失、包延遲和包抖動)的基于標準的方法。TWAMP使用單向主動測量協(xié)議(OWAMP)的方法論和架構(gòu)來定義對雙向或往返指標進行測量的手段。
[0007]在TWAMP中存在四個邏輯實體:控制客戶端(Control-Client)、會話發(fā)起端(Session-Sender)、服務器和會話回應端(Session-reflector)?？刂瓶蛻舳撕蜁挵l(fā)起端通常是在一個物理設備(“客戶端”)中實現(xiàn)的，而服務器和會話回應端通常是在第二個物理設備(“服務器”)中實現(xiàn)的，并且利用它們來進行雙向測量。
[0008]控制客戶端和服務器建立TCP (Transmission Control Protocol,傳輸控制協(xié)議)連接并且通過該連接來交換TWAMP控制信息。當控制客戶端想要開始測試時，客戶端將測試參數(shù)傳達至服務器。如果服務器同意進行所述測試，那么一旦客戶端發(fā)送了開始會話(Start-Session )消息就開始該測試。作為測試的一部分，會話發(fā)起端向會話回應端發(fā)送基于UDP (User Datagram Protocol,用戶數(shù)據(jù)報協(xié)議)的測試包流,并且會話回應端以響應的基于Μ)Ρ的測試包來響應各個所接收到的包。當會話發(fā)起端接收到來自會話回應端的響應包時，該信息被用來計算上述兩個設備之間的雙向延遲、包丟失和包延遲變化。[0009]ITU (International Telecommunication Union,國際電信聯(lián)盟)是針對信息通信技術(shù)(ICT)的聯(lián)合國專門機構(gòu)。ITU標準(被稱為“Recommendation”)是ICT網(wǎng)絡的運行基礎(chǔ)。ITU-T Y.1731性能監(jiān)控提供了基于標準的以太網(wǎng)性能監(jiān)控，其包括對以太網(wǎng)幀延遲、幀延遲變化、幀丟失和吞吐量的測量。
[0010]IEEE802.lag IEEE Standard for Local and Metropolitan Area NetworksVirtual Bridged Local Area Networks Amendment5: Connectivity Fault Management(IEEE802.lag局域網(wǎng)和城域網(wǎng)_虛擬橋接局域網(wǎng)_修正件5:連通性故障管理的IEEE標準)是由 IEEE (Institute of Electrical and Electronics Engineers,美國電氣和電子工程師協(xié)會)定義的標準。它針對通過橋和局域網(wǎng)(LAN)的路徑定義了 OAM的協(xié)議和實踐。它在很大程度上與ITU-T Recommendation Y.1731是相同的。該標準中:
[0011].定義了維護域、這些維護域的組成維護點、以及在創(chuàng)立和管理這些維護域時所需要的被管理對象；
[0012].定義了維護域與由VLAN設備網(wǎng)橋及供應商網(wǎng)橋提供的服務之間的關(guān)系；
[0013].描述了被維護點使用以便維護和診斷維護域內(nèi)的連通性故障的協(xié)議及程序；
[0014].提供了用于未來擴展維護點及其協(xié)議的容量的手段。
[0015]ITU Y.1731和類似的OAM標準(包括但不限于TWAMP)要求在始發(fā)端(客戶端)與回應端(會話回應端)之間進行明確的協(xié)商以建立唯一的流標識符(Flow Identifier)。這種方式阻止了 Test PDU (Test protocol data unit,測試協(xié)議數(shù)據(jù)單元)如圖1所示的那樣被始發(fā)端下游的多個回應端處理。
[0016]由于在現(xiàn)有技術(shù)中需要明確地生成不同的OAM會話(每一對始發(fā)端和回應端就有一個OAM會話)，因此無法從始發(fā)端生成能夠沿著測試路徑一次就從一個以上的回應端收集測量結(jié)果的Test H)U，即使該Test PDU可以穿過上述這些回應端以到達遠端的回應端。
[0017]圖2至圖4來自于ITU Y.1564標準，并且被用來圖示延遲需要和為了使以太網(wǎng)電路在安裝時合格而需要的其它測量結(jié)果。來自于ITU Y.1563的圖2圖示了以太網(wǎng)服務的性能的分層性質(zhì)。該網(wǎng)絡包括定向連接鏈路或者無連接鏈路，這些鏈路被連接至將要對該網(wǎng)絡內(nèi)的以太網(wǎng)層(Ethernet Layer)進行處理的橋。每次當以太網(wǎng)幀正在經(jīng)過以太網(wǎng)層時，該以太網(wǎng)巾貞將會被處理以具有完整性并且將會通過下層(Lower Layer, LL)連接而被發(fā)送至下一個橋。下層基于多種技術(shù)，例如SDH、0TN、roH、MPLS、ATM和ETY。所有以太網(wǎng)層和下層的性能將會影響被用來提供服務的網(wǎng)絡的端對端性能。
[0018]上層(Higher layer)可以被用來實現(xiàn)端對端通信。上層可以包括像IP、MPLS和Ethernet —樣的允許網(wǎng)絡部署具有更大的可擴性的協(xié)議。像TCP —樣的其它協(xié)議提供了如果發(fā)生幀丟失就重新傳輸幀的能力。遺憾的是，TCP的兩個缺點是:增加了在用戶信息的傳輸中的延遲；以及對通告窗口(advertised window)最大尺寸、與帶寬延遲積(bandwidth-delay product)的相互作用和與以太網(wǎng)服務的丟失及延遲的流控制相互作用的可能限制。該實施方式能夠基于如下的事實來獨立地進行所要求的測量:該事實即是，被用來支持以太網(wǎng)虛擬電路(Ethernet Virtual Circuit, EVC)的鏈路(或下層LL)可以在層2或?qū)?處運行。
[0019]來自于ITU Y.1564的圖3提供了以太網(wǎng)服務區(qū)域的簡單實例并且被稱作以太網(wǎng)服務激活測量。該測試的目標是為了驗證基于以太網(wǎng)的服務的配置和性能。該測試驗證了包括承諾信息速率(Committed Information Rate, CIR)、額外信息速率(ExcessInformation Rate，EIR)和其它屬性的以太網(wǎng)服務屬性。該圖示出了支持以太網(wǎng)服務實例的網(wǎng)絡的不同部分。
[0020]該圖還示出了 UNI參考點出現(xiàn)在訪問鏈路的中間，或者更加準確地說，UNI是其功能被分為客戶(UN1-C)組件和網(wǎng)絡(UN1-N)組件的參考點。從服務供應商的角度來看，他們需要提供從UN1-C到UN1-C的服務并且這是從創(chuàng)立了測試方法論的角度出發(fā)的。
[0021]CE (Customer Equipment,客戶設備)和運營商的網(wǎng)絡在UNI上交換服務巾貞,服務幀是在UNI上向服務供應商傳輸?shù)囊蕴W(wǎng)幀(稱作入口服務幀)或在UNI上向CE傳輸?shù)囊蕴W(wǎng)幀(稱為出口服務幀)。在各UNI上運行著許多服務。它們在它們的如下屬性方面是合格的:
[0022].連接類型
[0023].流量參數(shù):QoS (包括VLAN信息)、流量類型(數(shù)據(jù)vs.管理)等
[0024].帶寬輪廓
[0025].性能標準:FD、FDV、幀丟失率、可用性等
[0026]據(jù)此，容易看出以太網(wǎng)虛擬電路實際上可以在層2或?qū)?處跨越多個運輸網(wǎng)絡。這對利用傳統(tǒng)方法有效地測量延遲和包丟失提出了挑戰(zhàn)。該性能測量僅能夠在運輸運營商網(wǎng)絡(Transport Operator Network)的內(nèi)部邊界之外進行。
[0027]來自于ITU-T y.1563的圖4圖示了在不同的用于支持EVC的下層之間的邊界處通常是如何建立測量點(Measurement Point，MP)的。這些MP (或回應端)的定位對于獲得適當?shù)臏y量結(jié)果是至關(guān)重要的。依照上述該圖，雙向延遲測量通常是從SRC到DST且返回至SRC來進行的，并且不提供各交換鏈路(或下層)的詳細延遲信息。出于性能測量的目的，該性能測量僅能夠在MP是可尋址的網(wǎng)絡段的內(nèi)部邊界之外進行。

【發(fā)明內(nèi)容】

[0028]根據(jù)一個實施例，提供了一種用于測量和報告網(wǎng)絡中的性能參數(shù)的方法，所述網(wǎng)絡具有用于生成測試協(xié)議數(shù)據(jù)單元的至少一個始發(fā)端和用于沿著所述網(wǎng)絡中的測試路徑的連續(xù)節(jié)段對所述測試協(xié)議數(shù)據(jù)單元進行中繼的多個回應端。所述方法在所述始發(fā)端處生成所述測試協(xié)議數(shù)據(jù)單元并且沿著包括所述多個回應端的所述測試路徑傳輸所述測試協(xié)議數(shù)據(jù)單元。各所述回應端沿著所述測試路徑將所述測試協(xié)議數(shù)據(jù)單元中繼至下一個所述回應端。通過下列方式收集所述測試協(xié)議數(shù)據(jù)單元中的來自所述多個回應端的性能參數(shù)測量結(jié)果:在所述始發(fā)端和各所述回應端處將時間戳插入所述測試協(xié)議數(shù)據(jù)單元中。所述時間戳識別(I)當所述測試協(xié)議數(shù)據(jù)單元離開所述始發(fā)端的時間以及(2)當所述測試協(xié)議數(shù)據(jù)單元在沿著所述測試路徑的下游方向和上游方向上離開和到達各所述回應端的時間。
[0029]在一個實施例中，各所述回應端分別被配置有所述測試路徑中的下一個所述回應端的尋址信息，并且所述尋址信息被用來將所述測試協(xié)議數(shù)據(jù)單元中繼至下一個所述回應端。各所述回應端被配置有該回應端自己的尋址信息，在所述測試協(xié)議數(shù)據(jù)包從最后一個所述回應端傳回至所述始發(fā)端的期間內(nèi)當從下一個所述回應端接收所述測試協(xié)議數(shù)據(jù)包時要使用該回應端自己的尋址信息。【專利附圖】

【附圖說明】
[0030]通過參照下面的結(jié)合附圖的說明，可以最好地理解本發(fā)明。
[0031]圖1圖示了以太網(wǎng)中從始發(fā)端到多個回應端的測試路徑。
[0032]圖2圖示了來自于ITU Y.1563的以太網(wǎng)服務的性能的分層結(jié)構(gòu)。
[0033]圖3是來自于ITU Y.1564的以太網(wǎng)服務激活測量的示例。
[0034]圖4圖示了來自于ITU Y.1563的以太網(wǎng)中的測量點(MP)的位置。
[0035]圖5圖示了針對在多個回應端上的雙向環(huán)回(loopback)測量而生成了時間戳的地方。
[0036]圖6 是 ITU Y.1731 銷售商專用 OAM PDU (ETH-VSP)0
[0037]圖7是由始發(fā)端設定的所有PDU域的表。
[0038]圖8 圖示了對于流數(shù)據(jù)(Stream Data)類型長度值(Type-Length_Value,TLV)的格式的擴展。
[0039]圖9圖示了由始發(fā)端生成并且擴展的流數(shù)據(jù)TLV。
[0040]圖10圖示了在被回應端使用時的所生成并且擴展的流數(shù)據(jù)TLV。
【具體實施方式】
[0041]盡管將會結(jié)合某些優(yōu)選實施例來說明本發(fā)明，但應當理解的是，本發(fā)明不限于這些特定的實施例。相反地，本發(fā)明旨在涵蓋落入由隨附的權(quán)利要求限定的本發(fā)明的精神和范圍內(nèi)的全部替換例、變形例和等同配置。
[0042]本實施例是在需要如下框架的前提下發(fā)揮作用的:該框架允許如同在諸如ITU-TY.173UIETF RFC5357 (TWAMP)和IEEE802.lag等標準中所定義的性能測量。這些標準都依賴于始發(fā)端(或會話發(fā)起端)的向回應端(或會話回應端)生成測試流量(test traffic)的概念，其中雙向測量會要求回應端將測試流量返回(或反映)至始發(fā)端。
[0043]這些標準具有對兩個方向(上行鏈路uplink和下行鏈路downlink)的所有的必需指標(延遲、抖動、丟失、亂序等)進行測量和報告以說明網(wǎng)絡的性能的能力，利用該能力，這些標準針對層2交換網(wǎng)絡憑借雙向測量功能(即2X單向)能夠?qū)崿F(xiàn)有效的延遲和包丟失測量。
[0044]以太網(wǎng)OAM框架定義了用于連通性驗證和性能監(jiān)控的許多功能。本實施例關(guān)注于這些功能中的兩者:以太網(wǎng)環(huán)回(ETH-LB)和雙向幀延遲測量(ΕΤΗ-DM)。這兩項功能都是雙向的，即，始發(fā)端將會向回應端發(fā)送一個或多個測量幀，而回應端(在MAC地址的處理和交換等之后)將這些測量幀發(fā)送回始發(fā)端。
[0045]在ETH-LB中，所有的被測量且被報告的指標(延遲、抖動和幀統(tǒng)計)都基于雙向測量。
[0046]當測量ETH-DM延遲和抖動(延遲變化)時，DMM/DMR (延遲測量消息/延遲測量應答)信息被擴展為包含具有32位序列號的數(shù)據(jù)TLV (類型長度值)，從而基于雙向測量來測量并報告幀統(tǒng)計(即，丟失、亂序、復制包)指標。
[0047]本實施例是具有測量并報告針對兩個方向的上述指標的能力的雙向?qū)?解決方案。2X單向的會話包括始發(fā)端和回應端。
[0048]當多個回應端被設定在始發(fā)端的下游時，該始發(fā)端需要明確地直接向各回應端生成Test PDU以獲得雙向延遲和包丟失測量結(jié)果。為了減小測試流量并且為了在被控制得更好的時間窗口內(nèi)更有效地收集測量結(jié)果，需要生成能夠穿過多個回應端并且收集具體測量結(jié)果的Test PDU0
[0049]下列能力是非常令人期望的能力:生成被尋址至第一個回應端的單個Test PDU(或Test PDU的序列)，該第一個回應端隨后將會把該Test PDU中繼至下游的下一個回應端，而該下一個回應端也會把該Test PDU向下游中繼，直到回應端鏈的末尾，并且隨后該Test PDU —路上都向上游(通過回應端鏈)返回直至返回到始發(fā)端。這有助于在收集與同一 Test PDU相關(guān)的測量以提高這些測量的相關(guān)性的同時顯著地減小測試流量。
[0050]本實施例不要求始發(fā)端與回應端之間的“0ΑΜ會話”的顯式配置。所必需的用來唯一地識別潛在的多個OAM會話中的一者的流標識符是由回應端自動生成的。此方法不僅簡化了始發(fā)端-回應端對的操作，還使得回應端能夠?qū)est PDU向下游中繼至另一回應端以擴展由單個2X單向的Test PDU獲得的測量的范圍，從而將特定時間點處的網(wǎng)絡全體操作更好地關(guān)聯(lián)起來。通過讓各個回應端先在下游方向(在測試路徑中遠離始發(fā)端并且晚于初始回應端)上然后在上游方向(向著始發(fā)端的返回路徑)上插入特定的時間戳標記，就能夠在提高測量相關(guān)性(這是因為這些測量都與同一個初始的Test PDU相關(guān))的同時針對存在有回應端的每個下層連接都獲得具體的延遲和包丟失測量。
[0051]通過讓測試路徑中的各回應端插入流數(shù)據(jù)TLV以保持它們的特定測量并且通過更新如同ITU Y.1731(及有關(guān)標準)中所定義的時間戳的意義，就能夠通過從始發(fā)端生成單個Test PDU來沿著測試路徑收集來自多個回應端的測量。在從來自于始發(fā)端的單個PDU中收集到更多測量的同時，顯著地減少了由始發(fā)端生成的測試rou的數(shù)量。基于中間的回應端跳的額外測量顯著地加強了可用于更準確地識別在特定節(jié)段(一對回應端單元之間)上的延遲和/或包丟失的?目息。
[0052]在本實施例中，雙向延遲測量的發(fā)起者被稱為始發(fā)端(會話發(fā)起端)，并且回應端(會話回應端)應答該雙向延遲測量請求。
[0053]圖5圖示了如下情況:對于從始發(fā)端100經(jīng)過多個回應端(101、102、103、104)的雙向環(huán)回測量，生成了時間戳(105、106、107、108、109、110、111、112、113、114、115、116、117、118、119、120)。能夠獲得來自多個回應端(101、102、103、104)的延遲和包丟失測量結(jié)果，這些回應端(101、102、103、104)分別相距一跳(盡管各跳可能導致多個子網(wǎng)絡或交換鏈路)。通過利用累積于Test PDU中的測量(憑借插入在Test PDU的有效載荷部分中的流數(shù)據(jù)TLV)，始發(fā)端100就能夠收集并計算具體的延遲和包丟失性能測量結(jié)果。例如，就能夠計算出下列的值:
[0054]T3orig - TOorig=從始發(fā)端(100) —直到回應端n(104)的總雙向延遲
[0055]Tlorig - TOorig=從始發(fā)端(100)到回應端I (101)的單向延遲
[0056]TlRl -TORl=從回應端1(101)到回應端2(102)的單向延遲
[0057]TlRn - TORn-1=從回應端n_l (103)到回應端η (104)的單向延遲
[0058]TlRn - TOorig=從始發(fā)端(100) —直到回應端η(104)的單向延遲
[0059]T3Rn-l - T2Rn=從回應端η (104)到回應端η_1 (103)的返回延遲
[0060]T3R2 - T3R1=從回應端2 (102)到回應端I (101)的返回延遲
[0061]T3R1 -TORl=從回應端1(101) —直到回應端n(104)然后返回的總雙向延遲[0062]熟悉本領(lǐng)域的技術(shù)人員應當能夠基于沿著下游方向的測試路徑(朝向末尾的回應端104)和沿著朝向始發(fā)端100的上游方向的返回測試路徑而累積的多個時間戳，計算出額外的延遲測量信息。
[0063]存在有多個可選方案來使得從始發(fā)端100到回應端I (101)的Test PDU能夠沿著經(jīng)歷多個下游回應端(102、103、104)的測試路徑行進。
[0064]在一個實施例中，各回應端(101、102、103、104)被配置有將Test PDU中繼至下一個下游回應端所需要的尋址信息。利用該方案，各回應端(101、102、103、104)只需要被配置有與它的直接下游的回應端(根據(jù)規(guī)定的測試路徑)有關(guān)的信息。當中繼回應端將TestPDU中繼至下游回應端時，該中繼回應端將會把它的尋址信息包含在內(nèi)以便能夠接收來自下游回應端的應答。
[0065]在另一實施例中，始發(fā)端100使Test PDU直接向測試路徑中的回應端(101、102、103、104)鏈中的最后一個回應端(104)尋址，但使該Test PDU沿著測試路徑路由至回應端I (101)。中間回應端(102、103)作為一連串的“路由器”進行操作，其中各回應端將它自己的測量插入到被分配給它的適當流數(shù)據(jù)TLV中并且隨后將Test PDU中繼至測試路徑中(下游或上游方向上)的下一個回應端。
[0066]在又一實施例中，始發(fā)端100 (通過配置或憑借發(fā)現(xiàn)法)知曉沿著測試路徑的回應端(101、102、103、104)的列表。這使得始發(fā)端100能夠預填充所有的所必需的流數(shù)據(jù)TLV300 (每一個回應端101、102、103、104就有一個流數(shù)據(jù)TLV的實例)作為Test PDU的有效載荷的一部分。索引字段(index field)被各個中間回應端101、102、103、104遞增，從而使得能夠識別出被分配給它的是哪一個流數(shù)據(jù)TLV300。下一個/下游回應端的尋址信息也被始發(fā)端100包含在Test PDU內(nèi)。該信息隨后被中間回應端(101、102)使用，以將TestPDU在下游方向上中繼至下一個回應端和在上游/返回路徑方向上向上中繼至前一個回應端。
[0067]在再一實施例中,Test PDU沿著測試路徑向最后一個回應端104尋址。各中間回應端以混雜模式(Promiscuous Mode)進行操作，并且在沿著測試路徑在上游或下游方向(根據(jù)需要)上將Test PDU中繼至下一個回應端之前捕獲該Test PDU從而在適當?shù)牧鲾?shù)據(jù)TLV中插入其自己的測量。
[0068]在另外一實施例中，就像已經(jīng)從始發(fā)端100直接接收到Test PDU—樣，各個中間回應端向該始發(fā)端100生成直接應答。該方案能夠生成相同級別的測量，但由于朝著始發(fā)端生成的更多數(shù)量的應答可能會使始發(fā)端溢出或者當在服務中使用時(而不是在服務激活階段的期間內(nèi))可能會影響用戶數(shù)據(jù)的性能，所以必須謹慎。
[0069]當在既定的回應端之后存在有多個(下行鏈路)回應端，例如處于星型拓撲時，期望始發(fā)端100將該星型拓撲的各個潛在分支作為不同的測試路徑進行處理，并且針對每個可能的路徑在獨立于其它路徑的情況下發(fā)起雙向測量。
[0070]依據(jù)本發(fā)明適用的各種標準的具體定義而定，如果未提供對至少3個時間戳的原生支持，那么可能需要擴展Test PDU的編碼。
[0071]支持對TLV的使用以支持至少3個時間戳的標準的示例是ITU Y.1731標準。為了支持來自于沿著測試路徑被訪問的各回應端的測量，ITU Y.1731協(xié)議憑借銷售商專用OAM-PDUC ETH-VSP )的觀念提供了可擴展的編碼。對于各個被訪問的回應端而言向ETH-VSP編碼添加流數(shù)據(jù)TLV，以支持本發(fā)明中所定義的雙向測量測試。時間戳(TO至T3)使用了在IEEE1588-2004中定義的時間戳格式。用于ETH-VSP的流數(shù)據(jù)TLV已被分配了 MType=209。
[0072]圖6 圖示了 ITU Y.1731 銷售商專用 OAM PDU (ETH-VSP)0
[0073]圖7是由始發(fā)端100設定的所有I3DU字段的表，這些字段除了 OpCode字段302之外都不能被回應端(101、102、103、104)改變。對于此實施例，流數(shù)據(jù)TLV300被擴展了。
[0074]圖8圖示了對流數(shù)據(jù)TLV300的格式的擴展。流數(shù)據(jù)TLV300應當被擴展為包括針對于沿著測試路徑的各回應端(101、102、103、104)的唯一標識符(或索引)。預留字段400被用于保持唯一回應端標識符。
[0075]此外，Test PDU的有效載荷中的各流數(shù)據(jù)TLV300應當包括在對來自于測試路徑中的各回應端的必不可缺的延遲測量進行收集時所需要的4個時間戳。
[0076]圖9圖示了由始發(fā)端100生成和擴展的流數(shù)據(jù)TLV。
[0077]圖10圖示了所生成和擴展的流數(shù)據(jù)TLV300，其被回應端(101、102、103、104)在對(直接地或經(jīng)由上游回應端)從始發(fā)端100接收到的Test PDU進行應答時使用。
[0078]當諸如RFC5357TWAMP等標準對于每個回應端跳(諸如多個TLV)的至少3個時間戳未提供原生支持時，就需要擴展上述協(xié)議。一個實施例是利用測試包的不用的部分(或填充位(filler))來保持如下的結(jié)構(gòu):該結(jié)構(gòu)能夠存儲各個回應端跳的至少4個時間戳以及上行鏈路和下行鏈路序列號。這樣的結(jié)構(gòu)還能夠被擴展為基本上包括在圖6中的流數(shù)據(jù)TLV300中定義的額外信息。MEG級別(MEG Level)包括但不限于:被接收和被發(fā)送的MEL(600、601)，P位(P-Bit)設定值包括被接收和被發(fā)送的PBIT (602、603)等。可以使用被顯示為與ITU Y.1731兼容的實施例的一部分的TLV編碼或熟悉本領(lǐng)域的技術(shù)人員所熟知的任何其它變化例。所選的實施例擇取了這樣的Test PDU尺寸:該尺寸足夠大以便能夠保持各個回應端跳的序列號(401、402)和時間戳(403、404、405、406、407、408、409、410)信息，而又不超出由服務器OAM標準以及下面的層2和/或?qū)?網(wǎng)絡或網(wǎng)絡節(jié)段所支持的最大PDU尺寸。
[0079]為了識別TLV以用于特定的回應端(101、102、103、104)，當回應端(101、102、103、104)接收到具有被設定為VSM (51)的0pCode302的Test PDU時，該回應端搜索該TestPDU的有效載荷中的流數(shù)據(jù)TLV300的設定值以判定是否已經(jīng)存在由始發(fā)端100為該回應端(101、102、103、104)生成的流數(shù)據(jù)TLV300。如果未發(fā)現(xiàn)流數(shù)據(jù)TLV300，那么回應端(101、102、103、104)在上一次發(fā)現(xiàn)的流數(shù)據(jù)TLV300之后添加流數(shù)據(jù)TLV300，并且將End TLV301標記移動到新插入的流數(shù)據(jù)TLV300之后?；貞?101、102、103、104)將預留/回應端ID字段500設定為被分配給該回應端(101、102、103、104)的唯一 ID。
[0080]回應端隨后設定TO 和 Tl 時間戳(105、106、107、108、109、110、111、112)。
[0081]如果存在另一下游回應端，則回應端將Test PDU中繼至該下一個回應端。
[0082]否則，如果回應端是沿著測試路徑的回應端鏈中的最后一個回應端(104)，那么它將OpCode字段302改變?yōu)閂SR (50)并且設定T2和T3時間戳(120、119)。對于在測試路徑的末尾處的回應端，T3時間戳119被設定為O。一旦流數(shù)據(jù)TLV300被更新，VSR就朝著始發(fā)端100返回至上游流數(shù)據(jù)TLV300。
[0083]如果回應端101、102、103、104接收到具有已經(jīng)被設定為VSR的0pCode302的Testrou，那么它取回具有該回應端的回應端ID的流數(shù)據(jù)TLV300，并且隨后在將Test PDU向上游中繼至前一個回應端或始發(fā)端100 (在沿著返回測試路徑?jīng)]有上游回應端的情況下)之前更新 T2 和 T3 時間戳(113、114、115、116、117、118、119、120)。
[0084]如果在被分配給該回應端的那個流數(shù)據(jù)TLV300之前沒有發(fā)現(xiàn)流數(shù)據(jù)TLV300，這就表明沒有其它的回應端并且Test PDU直接返回至始發(fā)端100。
[0085]由于回應端會話是自動創(chuàng)立的，因此每當經(jīng)過預定的時間段(典型地，10秒數(shù)量級)沒有收到來自始發(fā)端100(由唯一的流標識符識別)的Test rou，就執(zhí)行逾時機制以關(guān)閉回應端會話和自由關(guān)聯(lián)源。如果在閑置時間屆滿之后接收到來自同一始發(fā)端100的新TestPDU,則回應端(101、102、103、104)自動生成新的流標識符。因此，需要有補充標簽來向始發(fā)端100表示已經(jīng)自動創(chuàng)立了新的回應端會話。這是通過由回應端(101、102、103、104)返回的識別號(Incarnation Number)(流數(shù)據(jù) TLV300 中的 IncNum411)來實現(xiàn)的。IncNum411是從全局識別計數(shù)器生成的無符號整數(shù)值，并且每次當分配新的IncNum411時，該計數(shù)器就增加一(I)。
[0086]IncNum=IncNumCnt;
[0087]IncNumCnt=IncNumCnt+l;
[0088]上面的2步操作被實施為原子操作(atomic operation),以確保在新的IncNum411被分配給回應端實例的同一時刻增加識別號計數(shù)器。
[0089]全局識別號計數(shù)器在系統(tǒng)啟動時被初始化一次且被初始化為隨機數(shù)，以將在系統(tǒng)重啟后重新使用用于回應端實例的同一 IncNum411的可能性最小化。全局識別計數(shù)器的環(huán)繞率取決于新的測量流的到達率和已經(jīng)運行的測量流的再激活率。
[0090]在一個實施例中，回應端(101、102、103、104)將新生成的IncNum411與舊的回應端會話實例相比較，并且如果相等，那么回應端(101、102、103、104)就生成新的IncNum411,以避免將相同的IncNum411分配給服務于同一個測量流的回應端會話。
[0091]這里所說明的實施例適用于基于軟件的、基于HW的和小型可插拔(SFP)的現(xiàn)場可編程門陣列(FPGA)始發(fā)端和回應端。本實施例還應用于能夠使用層2地址(MAC地址)和/或?qū)?地址(諸如IP地址)來編址的任何網(wǎng)絡設備。
[0092]圖5圖示了與圖4的系統(tǒng)類似的系統(tǒng)，其中將FPGA構(gòu)造為嵌入式流量產(chǎn)生器。
[0093]圖6圖示了與圖4的系統(tǒng)類似的系統(tǒng)，其中將FPGA構(gòu)造成執(zhí)行智能環(huán)回。
[0094]雖然已經(jīng)圖示和說明了本發(fā)明的特定實施例和應用，但應當理解的是，本發(fā)明不限于本文中公開的精確構(gòu)造和組成，并且顯然可以根據(jù)上述說明在隨附的權(quán)利要求所限定的本發(fā)明的精神和范圍內(nèi)進行各種修改、變化和改變。
【權(quán)利要求】
1.一種用于測量和報告網(wǎng)絡中的性能參數(shù)的方法，所述網(wǎng)絡具有用于生成測試協(xié)議數(shù)據(jù)單元的至少一個始發(fā)端和用于沿著所述網(wǎng)絡中的測試路徑的連續(xù)節(jié)段對所述測試協(xié)議數(shù)據(jù)單元進行中繼的多個回應端，所述方法包括: 在所述始發(fā)端處生成所述測試協(xié)議數(shù)據(jù)單元并且沿著包括所述多個回應端的所述測試路徑傳輸所述測試協(xié)議數(shù)據(jù)單元，各所述回應端沿著所述測試路徑將所述測試協(xié)議數(shù)據(jù)單元中繼至下一個所述回應端；以及 通過下列方式收集所述測試協(xié)議數(shù)據(jù)單元中的來自所述多個回應端的性能參數(shù)測量結(jié)果:在所述始發(fā)端和各所述回應端處將時間戳插入所述測試協(xié)議數(shù)據(jù)單元中，所述時間戳用于識別I)當所述測試協(xié)議數(shù)據(jù)單元離開所述始發(fā)端的時間以及2)當所述測試協(xié)議數(shù)據(jù)單元在沿著所述測試路徑的下游方向及上游方向上離開及到達各所述回應端的時間。
2.根據(jù)權(quán)利要求1所述的方法，其包括:在所述下游方向及所述上游方向上，基于插入所述測試協(xié)議數(shù)據(jù)單元中的所述時間戳，計算所述測試數(shù)據(jù)協(xié)議單元沿著所述測試路徑從所述始發(fā)端傳送至最后一個所述回應端和從最后一個所述回應端傳回至所述始發(fā)端的總雙向延遲測量結(jié)果。
3.根據(jù)權(quán)利要求1所述的方法，其中，各所述回應端分別被配置有所述測試路徑中的下一個所述回應端的尋址信息，并且所述尋址信息被用來將所述測試協(xié)議數(shù)據(jù)單元中繼至下一個所述回應端。
4.根據(jù)權(quán)利要求3所述的方法，其中，各所述回應端被配置有該回應端自己的尋址信息，在所述測試協(xié)議數(shù)據(jù)單元從最后一個所述回應端傳回至所述始發(fā)端的期間內(nèi)當從下一個所述回應端接收所述測試協(xié)議數(shù)據(jù)單元時要使用該回應端自己的尋址信息。
5.根據(jù)權(quán)利要求1所述的方法，其中， 所述性能參數(shù)被存儲在存儲有至少三個時間戳值的所述測試數(shù)據(jù)協(xié)議單元中，并且 如果所述測試數(shù)據(jù)協(xié)議單元未存儲有至少三個時間戳值，則將所述測試數(shù)據(jù)協(xié)議單元擴展為存儲至少三個時間戳值。
6.根據(jù)權(quán)利要求1所述的方法，其中，所述始發(fā)端使所述測試數(shù)據(jù)協(xié)議單元尋址至最后一個所述回應端，但將所述測試數(shù)據(jù)協(xié)議單元路由至第一個所述回應端，由此沿著所述測試路徑的各個后續(xù)的所述回應端將各自的性能測量結(jié)果插入所述測試數(shù)據(jù)協(xié)議單元中并且將所述測試數(shù)據(jù)協(xié)議單元中繼至下一個所述回應端。
7.根據(jù)權(quán)利要求1所述的方法，其中，所述始發(fā)端用各所述回應端的尋址信息預填充所述測試數(shù)據(jù)協(xié)議單元，并且所述尋址信息被用來將所述測試數(shù)據(jù)協(xié)議單元中繼至下一個所述回應端。
8.根據(jù)權(quán)利要求1所述的方法，其中，各所述回應端生成對所述始發(fā)端的直接應答。
【文檔編號】H04L12/26GK103634139SQ201310314282
【公開日】2014年3月12日 申請日期:2013年7月24日 優(yōu)先權(quán)日:2012年7月24日
【發(fā)明者】亨里克·尼德爾 申請人:埃克斯帝網(wǎng)絡有限公司