1、背景

隨著業(yè)務應用的推陳出新和用戶規(guī)模的不斷增長，網(wǎng)絡呈現(xiàn)出“高速率、大規(guī)模、多接入、不可預期”的特點。傳統(tǒng)網(wǎng)絡管控方式和手段已經(jīng)難以解決現(xiàn)有網(wǎng)絡和未來網(wǎng)絡的挑戰(zhàn)。

[[311748]]

 

因此，網(wǎng)絡管理者迫切需要顛覆傳統(tǒng)網(wǎng)絡監(jiān)測及故障排除方法，提出能夠應對網(wǎng)絡狀態(tài)測量、網(wǎng)絡失效檢測、故障定位與恢復等場景用例的實時靈活的測量解決方案。

P4開創(chuàng)了數(shù)據(jù)平面可編程的新時代，這為網(wǎng)絡管控提供了從數(shù)據(jù)平面直接獲取狀態(tài)信息的嶄新途徑。數(shù)據(jù)平面可編程技術的平臺無關、協(xié)議無關和可重構性使網(wǎng)絡管理者可以重塑網(wǎng)絡測量及網(wǎng)絡管控流程。

[[311749]]

 

圖1 Nick McKeown 教授于2014 年首次設計并提出了數(shù)據(jù)平面特定領域編程語言P4

2、傳統(tǒng)網(wǎng)絡測量

網(wǎng)絡測量是網(wǎng)絡管控的基礎手段和數(shù)據(jù)來源。按照測量方式的不同，傳統(tǒng)意義上的網(wǎng)絡測量(Network Measurement)可以分為主動測量(Active Measurement)、被動測量(Passive Measurement)和混合測量(Hybrid Measurement)。

主動測量通過向網(wǎng)絡中主動發(fā)送探測分組，并根據(jù)探測分組受網(wǎng)絡影響而發(fā)生的特性變化來分析網(wǎng)絡行為。被測量的網(wǎng)絡性能指標通常是丟包率、延遲、抖動、TTL和帶寬等。常見的主動測量協(xié)議包括PING、Traceroute、IP測量協(xié)議(IP Measurement Protocol，IPMP)、單向主動測量協(xié)議(One-Way Active Measurement Protocol，OWAMP)、雙向主動測量協(xié)議(Two-Way Active Measurement Protocol，TWAMP)、MPLS丟包/延遲測量協(xié)議(MPLS L/DM Protocol)等。

主動測量的優(yōu)點是使用靈活，缺點是給網(wǎng)絡增加額外帶寬/處理開銷，往往會引起海森堡效應(Heisenberg effect)，即觀察者的介入干擾測量結果。

被動測量通過捕獲流經(jīng)測量點的分組來測量網(wǎng)絡狀態(tài)、流量特征和性能參數(shù)。被動測量使用控制平面消息即可監(jiān)測網(wǎng)絡流量狀態(tài)性能，被監(jiān)測的性能指標通常是包/字節(jié)統(tǒng)計值、協(xié)議類型、隊列長度和延遲統(tǒng)計信息。常見的被動測量協(xié)議有網(wǎng)絡數(shù)據(jù)流統(tǒng)計協(xié)議(Cisco Netflow)、sFlow、IP流量信息輸出協(xié)議(IPFIX)、數(shù)據(jù)包采樣協(xié)議(PSAMP)。

被動測量不會產生額外的測量負載，因此不會影響網(wǎng)絡本身特性。但被動測量往往只能監(jiān)測交換節(jié)點本地狀態(tài)信息，而不能監(jiān)測網(wǎng)絡狀態(tài)和丟包率等全局狀態(tài)信息。

混合測量通過靈活組合主/被動測量方法，或結合主/被動測量優(yōu)點重新設計測量機制的方式，對網(wǎng)絡進行協(xié)同測量。典型代表有反應式測量(Reactive Measurement)、帶內測量(In-band Measurement)和交替標記性能測量(Alternate Marking-Performance Measurement，AM-PM)。

表1 網(wǎng)絡測量方案及其分類

 

帶內測量是近幾年興起的一種混合測量方法，通過路徑中間交換節(jié)點對數(shù)據(jù)包依次插入元數(shù)據(jù)(Measure metadata)的方式完成網(wǎng)絡狀態(tài)采集。相較于傳統(tǒng)網(wǎng)絡測量方案，帶內測量能夠對網(wǎng)絡拓撲、網(wǎng)絡性能和網(wǎng)絡流量實現(xiàn)更細粒度的測量。目前，帶內測量的研究方向主要為IETF IPPM工作組[1]和OPSA工作組主導的帶內OAM(In-situ Operation Administration and Maintenance，IOAM)和P4聯(lián)盟主導的帶內網(wǎng)絡遙測(In-band Network Telemetry，INT)。

3、帶內網(wǎng)絡遙測

帶內網(wǎng)絡遙測由Barefoot、Arista、Dell、Intel和VMware于2015年共同提出[2]，是一種不需要網(wǎng)絡控制平面干預，網(wǎng)絡數(shù)據(jù)平面收集和報告網(wǎng)絡狀態(tài)的框架。在帶內網(wǎng)絡遙測架構中，交換設備轉發(fā)處理攜帶遙測指令(Telemetry instructions)的數(shù)據(jù)包。當遙測數(shù)據(jù)包經(jīng)過該設備時，這些遙測指令告訴具備網(wǎng)絡遙測功能的網(wǎng)絡設備應該收集并寫入何種網(wǎng)絡狀態(tài)信息。

如圖2所示，帶內網(wǎng)絡遙測系統(tǒng)由遙測服務器和具備帶內網(wǎng)絡遙測功能的交換機組成。根據(jù)實際遙測任務的需要，該系統(tǒng)還可能需要時間同步服務器等設備完成輔助工作。

帶內網(wǎng)絡遙測的數(shù)據(jù)包處理流程如下：1.普通數(shù)據(jù)報文到達帶內網(wǎng)絡遙測系統(tǒng)的第一個交換節(jié)點時，帶內網(wǎng)絡遙測模塊通過 在交換機上設置的采樣方式匹配并鏡像出該報文，根據(jù)遙測任務的需要在四層頭部后插入INT頭部，將INT頭部所指定的遙測信息封裝成元數(shù)據(jù)(MetaData，MD)插入到INT頭部之后;2.報文轉發(fā)到中間節(jié)點時，設備匹配INT頭部后插入MD;3.報文轉發(fā)到帶內網(wǎng)絡遙測系統(tǒng)最后一跳時，交換設備匹配INT頭部插入最后一個MD并提取全部遙測信息并通過gRPC等方式轉發(fā)到遙測服務器。4.遙測服務器解析遙測報文內的遙測信息，上報給上層遙測應用程序。

 

圖2 帶內網(wǎng)絡遙測工作流程

既有方案一：P4-based INT

基于P4實現(xiàn)的帶內網(wǎng)絡遙測(P4-based INT)是最早的帶內網(wǎng)絡遙測實現(xiàn)方案[3]。P4-based INT包括兩種實體：INT traffic sources和INT traffic sinks。INT traffic sources負責將遙測指令嵌入到正常數(shù)據(jù)包或遙測數(shù)據(jù)包中。INT traffic sinks對遙測結果進行提取和上報。INT traffic sources和INT traffic sinks可以是應用、終端網(wǎng)絡協(xié)議棧、網(wǎng)管程序、NIC、發(fā)送側/接收側ToR交換機等。

表2 帶內網(wǎng)絡遙測系統(tǒng)術語及其說明

 

隨著逐跳增加INT元數(shù)據(jù)，遙測數(shù)據(jù)包大小逐漸增加，這可能導致數(shù)據(jù)包大小超過鏈路MTU值。P4-based INT給出了兩種解決方案：(1)根據(jù)INT跳數(shù)及逐跳元數(shù)據(jù)長度適當增大鏈路MTU配置值;(2)根據(jù)三層路徑MTU發(fā)現(xiàn)機制確定逐跳鏈路MTU，中間節(jié)點根據(jù)遙測數(shù)據(jù)包長度選擇是否插入遙測數(shù)據(jù)。

既有方案二：INT in 6TiSCH

Abdulkadir Karaagac等人將帶內網(wǎng)絡遙測從有線網(wǎng)絡拓展到無線網(wǎng)絡場景中[4]，針對工業(yè)無線傳感器網(wǎng)絡提出了一種帶內網(wǎng)絡遙測方案INT in 6TiSCH。該方案以最小化資源消耗和通信開銷作為設計目標，能夠處理6TiSCH網(wǎng)絡功能異常監(jiān)測、擁塞控制、集中路由和調度管理等場景和用例。

INT in 6TiSCH在IEEE 802.15.4 MAC幀中Information Elements(IEs)字段插入遙測數(shù)據(jù)。遙測報文由三部分組成：IEs Subtype ID、INT Header及INT Content。

其中，INT Header由三部分組成：INT Control header(8 bits)、Sequence Number(8 bits)及Bitmap(8 bits)。INT Control header用于定義遙測模式及遙測功能。Sequence Number用于區(qū)分來自同一節(jié)點的不同INT遙測數(shù)據(jù)。Bitmap中每個bit位代表一種預定義的遙測數(shù)據(jù)。

 

圖3 INT in 6TiSCH中插入的INT報文格式

值得注意的是，INT Control header中的HBH Mode(2 bits)定義了三種遙測模式，當Mode=00時，中間節(jié)點全部遙測;當Mode=10時，中間節(jié)點將隨機添加遙測數(shù)據(jù);當Mode=01時，中間節(jié)點根據(jù)上一次添加遙測數(shù)據(jù)的時間、轉發(fā)幀長度及剩余跳數(shù)計算概率值，并依據(jù)概率值進行遙測數(shù)據(jù)添加。HBH Mode在一定程度上能夠降低帶內網(wǎng)絡遙測的帶寬開銷。

Bitmap Mode定義了兩種位圖模式：內容位圖(Content Bitmap)和節(jié)點位圖(Node Bitmap)。內容位圖模式下，中間節(jié)點將依據(jù)Bitmap字段的遙測組合進行遙測數(shù)據(jù)的添加。節(jié)點位圖模式下，中間節(jié)點允許自行添加位圖及INT數(shù)據(jù)。

INT in 6TiSCH定義的遙測數(shù)據(jù)模型包括：Node ID(2 Byte)、Receive Channel & Timestamp(2 Byte)、Utilization indicator(1 Byte)、RSSI(1 Byte)及其他保留信息類型。

既有方案三：NetVision

Zhengzheng Liu等人提出了網(wǎng)絡遙測即服務的概念[5]，并設計了帶內網(wǎng)絡遙測平臺NetVision。NetVision主動發(fā)送與網(wǎng)絡狀態(tài)和遙測任務相匹配的適當數(shù)量和格式的探針數(shù)據(jù)包，降低了遙測開銷，提高了網(wǎng)絡遙測的覆蓋性和可擴展性。在路徑規(guī)劃方面，NetVision采用段路由進行簡單靈活的路由控制，通過更改SR標簽的方式定制探測路徑。

為了降低網(wǎng)絡管理員部署帶內網(wǎng)絡遙測的難度，NetVision設計了一套包括遙測元數(shù)據(jù)和查詢原語在內的遙測原語，并封裝為遙測服務API，可以對外提供端到端延遲測量、實時包傳輸速率計算、鏈路/節(jié)點包黑洞發(fā)現(xiàn)等功能。

 

圖4 NetVision架構及處理流程

NetVision探針為“SR+INT”雙棧結構，SR Stack包括SR列表長度和輸出端口標簽，INT Stack包括標簽列表長度和遙測標簽列表。路由器通過彈出SR標簽并放入INT標簽完成一次遙測轉發(fā)。

 

圖5 NetVision探針封裝格式

既有方案四：INTCollector

INTCollector是一種針對帶內網(wǎng)絡遙測計算及數(shù)據(jù)存儲開銷大的問題而設計的從帶內網(wǎng)絡遙測原始數(shù)據(jù)中提取并過濾重要網(wǎng)絡信息的機制[6]。INTCollector只過濾諸如新流到達或逐跳延遲劇烈變化等重要網(wǎng)絡事件，并將重要網(wǎng)絡時間存儲在時間序列數(shù)據(jù)庫中，從而降低CPU使用率和存儲成本。INTCollector為INT信息處理設計了快慢兩條通道，快通道用于處理INT報告數(shù)據(jù)包，慢通道用于處理重要事件并將其存儲到數(shù)據(jù)庫中。實驗結果表明，INTCollector機制可以將帶內網(wǎng)絡遙測存儲數(shù)據(jù)量減少2-3個數(shù)量級，并降低遙測服務器負載。

綜上所述，帶內網(wǎng)絡遙測是一種隨路測量方案。因此，帶內網(wǎng)絡遙測存在一些固有的缺點。首先，帶內網(wǎng)絡遙測檢測范圍有限，預先定義的隨路檢測特性使得帶內網(wǎng)絡遙測往往無法及時獲得全網(wǎng)全狀態(tài)的網(wǎng)絡視圖。因此帶內網(wǎng)絡遙測只能監(jiān)測特定路徑上的某些數(shù)據(jù)包的遙測數(shù)據(jù)。其次，由于將遙測指令和數(shù)據(jù)封裝到正常數(shù)據(jù)包中，正常數(shù)據(jù)包的有效載荷比降低，遙測開銷較大。最后，遙測指令和數(shù)據(jù)的構造、封裝、填充和提取等環(huán)境增加了交換機處理負擔。

值得注意的是，與帶內網(wǎng)絡遙測相對應的是帶外網(wǎng)絡遙測(Out-band Network Telemetry，ONT)。帶外網(wǎng)絡遙測通過監(jiān)控設備單獨發(fā)送探測報文，收集鏈路狀態(tài)信息。探測報文與網(wǎng)絡業(yè)務無關，因此測量結果并不準確。帶外網(wǎng)絡遙測與帶內網(wǎng)絡遙測的遙測數(shù)據(jù)包生成、接收處理流程不同，對網(wǎng)絡本身產生的影響和測量精度也不相同。嚴格來說，帶外網(wǎng)絡遙測應屬于主動遙測的范疇。

傳統(tǒng)網(wǎng)絡測量技術因其靜態(tài)、低效、開銷大等缺陷，在網(wǎng)絡狀態(tài)監(jiān)測與管理上存在精度和時效性等性能問題。因此，帶內網(wǎng)絡遙測系統(tǒng)亟需解決以下幾個技術需求：

• 性能

帶內網(wǎng)絡遙測系統(tǒng)應能根據(jù)遙測需求，快速生成并下發(fā)遙測方案，上報網(wǎng)絡狀態(tài)信息。

• 可拓展性

帶內網(wǎng)絡遙測系統(tǒng)應能夠應對未來網(wǎng)絡異質化和高速化挑戰(zhàn)，滿足各類服務的遙測需求。

• 輕量級

有限的網(wǎng)絡資源導致網(wǎng)絡帶內網(wǎng)絡遙測系統(tǒng)必須是輕量級的，以減少資源消耗和通信開銷。

• 魯棒性

網(wǎng)絡遙測系統(tǒng)應該能夠應對網(wǎng)絡節(jié)點或鏈路故障，不依賴于特定的遙測服務器或網(wǎng)絡節(jié)點進行部署，并且能夠適應網(wǎng)絡狀態(tài)頻繁變化。

• 安全性

對用戶數(shù)據(jù)包的遙測操作可能伴隨著用戶隱私泄露和安全風險問題。因此，帶內網(wǎng)絡遙測需要研究如何通過技術手段減少對用戶數(shù)據(jù)的影響。

4、帶內網(wǎng)絡遙測應用

帶內網(wǎng)絡遙測技術的應用范圍已經(jīng)從最初的網(wǎng)絡運維可視化、故障定位拓展到了網(wǎng)絡測量、擁塞控制、路徑?jīng)Q策、流量工程和網(wǎng)絡數(shù)據(jù)平面驗證等領域。

 

[[311750]]

4.1網(wǎng)絡測量

 

為了滿足網(wǎng)絡運行、維護和安全的需要，控制平面需要實時獲取網(wǎng)絡流量狀態(tài)。網(wǎng)絡查詢成為日漸興起的研究領域。常見的網(wǎng)絡查詢包括：大小流檢測、異常流量檢測等。帶內網(wǎng)絡遙測可以收集統(tǒng)計的網(wǎng)絡狀態(tài)信息如表3所示。

表3 帶內網(wǎng)絡遙測統(tǒng)計信息分類

 

現(xiàn)有遙測系統(tǒng)可以實時收集和分析測量數(shù)據(jù)，但存在兩個普遍問題：(1)僅支持單一遙測任務;(2)處理和存儲開銷隨流量及查詢量增加而增大。

學術界的研究人員也關注到了上面的問題，Arpit Gupta等人針對遙測提供了一個聲明式接口，可以滿足11種遙測任務的查詢需求[7]。這11種遙測任務包括：TCP新建連接查詢、Slowloris DOS攻擊查詢、Zorro Attacks查詢、SSH暴力破解攻擊查詢、Superspreader、端口掃描查詢、DDoS攻擊查詢、TCP SYN Flood攻擊查詢、TCP Incomplete Flows查詢、DNS Tunneling檢測查詢、DNS反向攻擊查詢。

網(wǎng)絡狀態(tài)測量也是帶內網(wǎng)絡遙測在產業(yè)應用方面最為典型的場景。Barefoot 推出的Deep Insight是全球首個可以運行在商業(yè)級服務器上的提供逐包狀態(tài)監(jiān)測的網(wǎng)絡系統(tǒng)，能夠實時解釋、分析和定位數(shù)據(jù)包延遲發(fā)生的原因和位置[8]。結合機器學習技術，Barefoot Deep Insight可以在納秒級分辨率上實現(xiàn)對網(wǎng)絡性能的有狀態(tài)自動化異常監(jiān)測。

 

 

圖6 DeepInsight的口號便是納秒級逐數(shù)據(jù)包洞察

 

 

 

[[311750]]

4.2微突發(fā)檢測

 

微突發(fā)(Microbursts)是指端口在非常短的時間(毫秒級別)內收到非常多的突發(fā)數(shù)據(jù)，以至于瞬時突發(fā)速率達到平均速率的數(shù)十倍、數(shù)百倍，甚至超過端口帶寬的現(xiàn)象。受限于秒級流量監(jiān)控周期的技術局限性，SNMP協(xié)議或網(wǎng)絡性能檢測工具很難采集毫秒級的微突發(fā)流量。帶內網(wǎng)絡遙測通過在數(shù)據(jù)包轉發(fā)時刻記錄交換機隊列長度的方式便可以輕松檢測網(wǎng)絡微突發(fā)程度。

圖7 基于遙測的微突發(fā)檢測[9]

 

 

[[311750]]

4.3故障快照

 

由于網(wǎng)絡遙測通過端口計數(shù)器、數(shù)據(jù)包采樣和hop-by-hop帶內遙測等方式提取網(wǎng)絡狀態(tài)數(shù)據(jù)，因此會產生大量的遙測數(shù)據(jù)。由于這類遙測數(shù)據(jù)缺乏關于異常網(wǎng)絡行為的上下文狀態(tài)和可操作信息，網(wǎng)絡管理員不得不采用各類狀態(tài)監(jiān)測工具進行長時間的巨量數(shù)據(jù)分析，才能找到網(wǎng)絡問題的根本原因。針對這一問題，Mellanox提出故障快照 (What Just Happened，WJH)技術[10]。

 

[[311751]]

 

圖8 故障快照 (What Just Happened，WJH)

 

 

故障快照技術利用Mellanox Spectrum™和Spectrum™-2以太網(wǎng)交換機芯片，以T-比特級別的速率檢測所有端口上的數(shù)據(jù)包，然后識別異常行為，并將其整合為簡潔、具體且可操作的數(shù)據(jù)，從而簡化網(wǎng)絡故障排除和快速恢復。

4.4擁塞控制

 

網(wǎng)絡源端可以利用帶內網(wǎng)絡遙測提供的豐富的網(wǎng)絡狀態(tài)信息進行擁塞避免和控制。

速率控制協(xié)議(Rate Control Protocol，RCP)通過調整鏈路容量分配進行擁塞控制。網(wǎng)絡中的每個RCP路由器根據(jù)入口鏈路利用率、平均隊列長度、流平均RTT等網(wǎng)絡狀態(tài)參數(shù)周期性計算每條鏈路上的公平共享速率(Fair-share rate)。

RCP*是在RCP基礎上設計的針對個流狀態(tài)統(tǒng)計的擁塞控制方案。RCP*在終端主機上針對每個流部署速率限制器和速率控制器。網(wǎng)絡控制平面為每個流分配AppSpecific_0和AppSpecific_1兩個內存地址存儲公平速率。其中，AppSpecific_0儲存當前公平速率版本號，AppSpecific_1存儲真正的公平速率。每個流的速率控制器周期性通過“收集-計算-更新”三個階段查詢和更新網(wǎng)絡狀態(tài)。

在收集階段，速率控制器以毫秒為周期統(tǒng)計逐跳交換機ID、隊列長度、鏈路利用率和鏈路公平共享率(即AppSpecific_0值和AppSpecific_1值)。

在計算階段，發(fā)送方速率控制器根據(jù)收集信息計算延路每條鏈路的平均隊列長度，然后使用RCP擁塞控制算法計算每條鏈路的公平共享速率R_link。

在更新階段，每個流的速率控制器異步更新所有鏈路上的公平共享速率。

由于RCP*在每個RTT周期內發(fā)送一次公平速率調整遙測數(shù)據(jù)包，因此RCP*的開銷與TCP相似。值得注意的是，RCP*的CSTORE指令在遙測基礎上增加了向交換機“寫數(shù)據(jù)”的操作，開辟了一種新的擁塞控制方案。

4.5路由決策

 

網(wǎng)絡遙測為路由決策提供了除網(wǎng)絡連接、網(wǎng)絡跳數(shù)以外的更多、更詳細的網(wǎng)絡狀態(tài)參數(shù)，例如鏈路時延、丟包率、網(wǎng)絡擁塞情況和鏈路利用率等。因此，基于這些網(wǎng)絡狀態(tài)參數(shù)，結合Segement Route等新型路由方式，網(wǎng)絡節(jié)點可以制定個性化的性能路由。

4.6流量工程

 

在運行多路徑路由協(xié)議的數(shù)據(jù)中心網(wǎng)絡中，終端主機允許根據(jù)數(shù)據(jù)包頭部值選擇路由路徑。以VLAN標簽為例，終端主機通過改變VLAN ID值選擇不同的轉發(fā)路徑。

Vimalkumar Jeyakumar等人在設計了一種基于帶內網(wǎng)絡遙測的負載均衡方案[11]。終端主機在其發(fā)出的數(shù)據(jù)包中插入由路徑VLAN ID、鏈路利用率TX-Utilization、鏈路發(fā)送字節(jié)數(shù)TX-Bytes構成的遙測指令。其中，設置鏈路發(fā)送字節(jié)數(shù)字段的目的是在鏈路利用率沒有更新的情況下評估路徑擁塞程度。

接收方在收到遙測數(shù)據(jù)包后回傳給發(fā)送方。發(fā)送方根據(jù)遙測字段信息構建“路徑-擁塞程度”的映射表。其中擁塞程度可以用逐跳鏈路利用率最大值或總和表示。發(fā)送方根據(jù)擁塞程度映射表選擇合適路徑進行轉發(fā)。

4.7網(wǎng)絡智慧化

 

限制網(wǎng)絡智慧化部署的瓶頸除了算力算法問題，實時數(shù)據(jù)供給也是一大挑戰(zhàn)。而帶內網(wǎng)絡遙測恰恰能夠為網(wǎng)絡智慧化方案的部署提供源源不斷的實時網(wǎng)絡狀態(tài)數(shù)據(jù)。

5、未來展望

帶內網(wǎng)絡遙測已經(jīng)得到了學術界和產業(yè)界的廣泛關注。學術界更加關注帶內網(wǎng)絡遙測能否給網(wǎng)絡閉環(huán)控制帶來新的解決思路，產業(yè)界已經(jīng)有成熟的網(wǎng)絡監(jiān)管產品問世。帶內網(wǎng)絡遙測技術方興未艾，但也面臨著一些挑戰(zhàn)。

5.1通用遙測模型

 

帶內網(wǎng)絡遙測具有數(shù)據(jù)平面可編程、隨路測量、可重配置等特點。如何利用這些特點破解傳統(tǒng)測量無法被普遍適用的局面，對完善網(wǎng)絡遙測研究具有重要意義。目前學術界和產業(yè)界缺乏針對一體化融合網(wǎng)絡互聯(lián)互通場景的通用遙測模型的研究。利用可編程數(shù)據(jù)平面的靈活性和可擴展性針對異構網(wǎng)絡特性設計隨路遙測方案，形成統(tǒng)一網(wǎng)絡狀態(tài)視圖成為帶內網(wǎng)絡遙測技術的潛在應用場景。

5.2性能損失評估

 

帶內網(wǎng)絡遙測可以插入數(shù)據(jù)包中的遙測元數(shù)據(jù)數(shù)量受數(shù)據(jù)包原始大小及網(wǎng)絡最大傳輸單元(MTU)的限制。這也意味著帶內網(wǎng)絡遙測侵占部分網(wǎng)絡帶寬。除此之外，帶內網(wǎng)絡遙測支持VXLAN-GPE、Geneve、NSH、TCP和UDP等多種封裝協(xié)議。這些封裝協(xié)議大多包含頭部校驗過程。因此，元測量數(shù)據(jù)的插入需要更新校驗和字段，這將會增加交換機的處理開銷。目前，學術界缺少關于帶內網(wǎng)絡遙測對網(wǎng)絡性能損失產生的影響評估研究。

5.3個流數(shù)據(jù)分析

 

相較于其他測量方案，帶內網(wǎng)絡遙測可以捕捉更為詳盡的個流網(wǎng)絡狀態(tài)信息(如網(wǎng)絡流逐跳延遲、逐跳緩存大小、多路徑傳輸?shù)淖勇窂教匦缘?。這些個流網(wǎng)絡狀態(tài)信息的是傳統(tǒng)測量方案無法獲取或未曾研究的。如何針對個流建立準確的統(tǒng)計分析模型(如時間序列分析、回歸分析、關聯(lián)分析等)并基于這些模型設計部署網(wǎng)絡管理、優(yōu)化方案成為未來帶內網(wǎng)絡遙測研究的重要任務。

5.4遙測數(shù)據(jù)聚合

 

首先，帶內網(wǎng)絡遙測可能會產生大量遙測數(shù)據(jù)，除了占據(jù)網(wǎng)絡帶寬以外，還加重了服務器數(shù)據(jù)收集、存儲和分析負擔。假如網(wǎng)絡所有節(jié)點轉發(fā)的所有流量都進行帶內網(wǎng)絡遙測，一個節(jié)點將為每個數(shù)據(jù)包添加幾十個字節(jié)的遙測數(shù)據(jù)，數(shù)據(jù)包在整個轉發(fā)路徑可能會累計大量跟蹤數(shù)據(jù)，這些累計跟蹤數(shù)據(jù)甚至可能會超過原始數(shù)據(jù)包的大小。數(shù)據(jù)平面匯聚產生的遙測數(shù)據(jù)量與遙測元數(shù)據(jù)量、流量規(guī)模、網(wǎng)絡規(guī)模等有關。遙測服務器如何處理規(guī)模龐大的遙測數(shù)據(jù)是遙測系統(tǒng)性能衡量的關鍵環(huán)節(jié)。因此，遙測終點在匯報遙測數(shù)據(jù)時，應考慮對遙測數(shù)據(jù)進行預先壓縮、篩選和聚合處理，以減少遙測服務器壓力。

其次，現(xiàn)有狀態(tài)采集字段只能存放一些必不可少的有限數(shù)據(jù)。隨著網(wǎng)絡自動化技術、虛擬化技術、網(wǎng)絡融合、分組光纖融合的發(fā)展趨勢，帶內網(wǎng)絡遙測要按需并可交互地采集并提供更多網(wǎng)絡數(shù)據(jù)。因此，未來帶內網(wǎng)絡遙測技術的研究需要充分考慮數(shù)據(jù)字段的定義、聚合、獲取和過濾的靈活性和可擴展性。

最后，現(xiàn)有遙測原語(primitives)和模型過于復雜，帶內網(wǎng)絡遙測需要對遙測數(shù)據(jù)(如節(jié)點、鏈路、端口、路徑、流、時間戳等)查詢原語進行簡化。

5.5遙測安全風險

 

帶內網(wǎng)絡遙測的數(shù)據(jù)平面可編程性導致潛在的軟件漏洞、后門、病毒帶來安全問題。帶內網(wǎng)絡遙測伴隨著對網(wǎng)絡數(shù)據(jù)包的查看、插入、封裝等包級操作。這些操作給用戶信息的保密和安全帶來一定威脅。除此之外，惡意INT Source通過不斷構造遙測數(shù)據(jù)包，侵占網(wǎng)絡帶寬，消耗中間節(jié)點處理能力，也可能會造成網(wǎng)絡可用資源枯竭的情況。因此，帶內網(wǎng)絡遙測系統(tǒng)中的節(jié)點認證與鑒權方案亟需研究。

6、參考文獻/資料

[1].https://datatracker.ietf.org/wg/ippm/documents/

[2].Kim C, Sivaraman A, Katta N, et al. In-band network telemetry via programmable dataplanes[C]//ACM SIGCOMM. 2015.

[3].https://p4.org/assets/INT-current-spec.pdf

[4].Karaagac A, De Poorter E, Hoebeke J. In-Band Network Telemetry in Industrial Wireless Sensor Networks[J]. IEEE Transactions on Network and Service Management, 2019.

[5].劉爭爭, 畢軍, 周禹, et al. 基于P4的主動網(wǎng)絡遙測機制[J]. 通信學報, 2018, 39(S1):168-175.

[6].Tu N V , Hyun J , Kim G Y , et al. INTCollector: A High-performance Collector for In-band Network Telemetry[C]// 2018 14th International Conference on Network and Service Management (CNSM). IEEE Computer Society, 2018.

[7].Gupta A, Harrison R, Canini M, et al. Sonata: Query-driven streaming network telemetry[C]//Proceedings of the 2018 Conference of the ACM Special Interest Group on Data Communication. ACM, 2018: 357-371.

[8].https://barefootnetworks.com/static/app/pdf/DI-UG42-003ea-ProdBrief.pdf

[9].https://support.huawei.com/enterprise/zh/doc/EDOC1100059517/46d2dd1d

[10].https://www.mellanox.com/related-docs/solutions/SB_Mellanox_WJH.pdf

[11].Jeyakumar V, Alizadeh M, Geng Y, et al. Millions of little minions: Using packets for low latency network programming and visibility[C]//ACM SIGCOMM Computer Communication Review. ACM, 2014, 44(4): 3-14.