電信運營商網(wǎng)絡的自動化質(zhì)量測量（Telemetry）技術(shù)要求

1電信運營商網(wǎng)絡的自動化質(zhì)量測量(Telemetry)技術(shù)要求本文件規(guī)定了電信運營商網(wǎng)絡的自動化質(zhì)量測量(Telemetry)的技術(shù)架構(gòu)和應用場景以及Telemetry技術(shù)在管理平面、控制平面、數(shù)據(jù)平面的技術(shù)要求本文件適用于網(wǎng)絡設備Telenetry研發(fā)、測試及應用。2規(guī)范性引用文件下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件，僅所注日期的版本適用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改單)適用于本文件。IETFRFC6020網(wǎng)絡配置協(xié)議(NetworkConfigurationProtocol(NETOONF))IETFRFO6241一種用于網(wǎng)絡配置協(xié)議的數(shù)據(jù)建模語言(YANG-ADataModelingLanguagefortheNetworkConfigurationProt3術(shù)語、定義和縮略語3.1術(shù)語和定義下列術(shù)語和定義適用于本文件。自動化質(zhì)量測量telemetryTelemetry是一項遠程從物理設備或虛擬設備上高速采集數(shù)據(jù)的技術(shù)。通過推模式(PushMode),Telemetry機制提供更實時更高速的數(shù)據(jù)采集功能。Google遠程過程調(diào)用協(xié)議googleremoteprocedurecallprotocoGRPC是一個基于HTTp/2傳輸層協(xié)議承載的高性能、通用的RPC框架。Goolge協(xié)議緩沖存儲器googleprotocolbufferGPB是一種與語言無關(guān)、平臺無關(guān)、擴展性好的用于通信協(xié)議、數(shù)據(jù)存儲的序列化結(jié)構(gòu)數(shù)據(jù)格式模型路徑指的是預配置的采集信息的模板集合中的URL,通過指定這些URL,就可以指定采集的對象以下縮略語適用于本文件。AS自治系統(tǒng)AutonomousSystemASG匯聚服務網(wǎng)關(guān)AggregationServiceGatewayBMPBGP監(jiān)控協(xié)議BGPMonitoringProtocolBSC基站子系統(tǒng)BaseStationSubsystem2CSG基站網(wǎng)關(guān)CellSiteGatowaDNP動態(tài)網(wǎng)絡探測器DynamicNetworkProbeeNodeB演進節(jié)點BEvolvedNodeBGPBGoolge協(xié)議緩沖存儲器GoogleProtocolBufferGRPCGoogle遠程過程調(diào)用協(xié)議GoogleRemoteProcedureCallProtocolIPFIXIP流信息導出IPFlowInformationExportMME移動性管理組件MobilityManagementEntity操作，管理和維護Operations,Administratio無線網(wǎng)絡控制站無線業(yè)務側(cè)網(wǎng)關(guān)服務網(wǎng)關(guān)簡單網(wǎng)絡管理協(xié)議SinpleNetworkManagenent4Telemetry架構(gòu)和應用場景4.1Telemetry典型架構(gòu)Telemetry技術(shù)支持遠程從物理設備或虛擬設備上高速采集數(shù)據(jù)。設備通過推模式(PushMode)主動向采集器上送設備數(shù)據(jù)信息(也包括網(wǎng)絡、業(yè)務情況),提供實時高速的數(shù)據(jù)采集功能。通過高速實時的推送網(wǎng)絡設備的數(shù)據(jù)指標，Telemetry技術(shù)可以為網(wǎng)絡問題定位、網(wǎng)絡質(zhì)量優(yōu)化和網(wǎng)絡調(diào)整提供基礎(chǔ)的數(shù)據(jù)支持。相對于現(xiàn)有網(wǎng)絡信息的采集和呈現(xiàn)方式，Telenetry能提供更詳細、更細粒度、更實時的網(wǎng)絡信息，可用于網(wǎng)絡的微突發(fā)檢測等場景。Telenetry技術(shù)的典型架構(gòu)如圖1所示，Telenetry的采樣數(shù)據(jù)源自網(wǎng)絡設備上數(shù)據(jù)轉(zhuǎn)發(fā)面、控制面和管理面的數(shù)據(jù)，這些數(shù)據(jù)按照YANG模型描述，利用GPB/JSON格式編碼，并通過GRPC協(xié)議將數(shù)據(jù)上送至采集器和分析器進行分析處理。Telemetry技術(shù)是模型驅(qū)動的。模型驅(qū)動是指用戶或者網(wǎng)管可以通過指定模型路徑的方式來通知設備，需要推送哪些數(shù)據(jù)，同時數(shù)據(jù)也按照此模型的描述進行上報。通過統(tǒng)一的模型對網(wǎng)絡設備上的數(shù)據(jù)進行描述，有利于設備實現(xiàn)細顆粒度的數(shù)據(jù)采集。管面樣3YANG是一種數(shù)據(jù)建模語言，用于設計可以為各種傳輸協(xié)議操作的配置數(shù)據(jù)模型、狀態(tài)數(shù)據(jù)模型、遠程調(diào)用模型和通知機制等。GPB(GoogleProtocolBuffer)編碼格式，是一種與語言無關(guān)、平臺無關(guān)、擴展性好的用于通信協(xié)議、數(shù)據(jù)存儲的序列化結(jié)構(gòu)數(shù)據(jù)格式。在設備和采集器之間傳輸數(shù)據(jù)時，采用GPB格式編碼傳輸?shù)臄?shù)據(jù)比其他格式編碼的數(shù)據(jù)具有更高的信息負載能力，保證了Telemetry業(yè)務的數(shù)據(jù)吞吐能力，同時降低了CPU占用和帶寬。GRPC協(xié)議(GoogleRemoteProcedureCallProtocol)是一個基于HTTP/2傳輸層協(xié)議承載的高性能通用RPC框架。使用相同的proto(原型)文件后，設備和采集器之間可以建立GRPC連接。此時，設備和采集器可以在GRPC通道上使用不同的編碼格式傳輸數(shù)據(jù)，例如通過采集器和分析器：采集器位于網(wǎng)管側(cè)，用于接收和存儲網(wǎng)絡設備上報的監(jiān)控數(shù)據(jù)：分析器位于網(wǎng)管側(cè)，用于分析采集器接收和存儲的網(wǎng)絡設備上報的監(jiān)控數(shù)據(jù)4.2Telemetry實現(xiàn)機制Telemetry技術(shù)采用訂閱模式(推模式)上送數(shù)據(jù)，即設備以周期性推送的方式向采集器主動推送數(shù)據(jù)，而不是被動的等待采集器定時查詢，避免查詢請求在網(wǎng)絡傳輸中的延遲和大量查詢請求對網(wǎng)絡和設備帶來的壓力，提升了監(jiān)控性能。目前已經(jīng)存在的網(wǎng)絡監(jiān)控方式多是以拉模式上送數(shù)據(jù)，例如SNMP。現(xiàn)以典型的網(wǎng)絡監(jiān)控場景周期性采樣網(wǎng)絡設備接口流量數(shù)據(jù)為例，對比傳統(tǒng)的拉模式和Telemetry推模式：傳統(tǒng)拉模式的查詢與設備之間是一問一答的交互。假如1分鐘內(nèi)交互了1000次完成查詢，即解析了1000次查詢請求報文，第2分鐘將再次解析1000次查詢請求，如此持續(xù)下去，即使第1分鐘和第2分鐘下發(fā)的1000次查詢請求是一樣的，后續(xù)設備每分鐘都重復解析1000次。Telemetry機制是推送機制，它是第一分鐘解析1000次訂閱請求，然后每分鐘持續(xù)推送數(shù)據(jù)給網(wǎng)管。每分鐘都節(jié)省了1000次查詢請求報文的解析。傳統(tǒng)拉模式查詢一次只能獲取一個接口的一個報文，而Telemetry機制則可一次獲取多個接口的數(shù)據(jù)，然后將數(shù)據(jù)打包上送采集器，進一步減少交互報文數(shù)。Telemetry典型的工作過程如下用戶或者網(wǎng)管可以通過命令行配置設備的Telenetry采樣功能，配置完畢后，設備會與上送目標建立GRPC連接，并且推送數(shù)據(jù)至采集器。對Telemetry設備側(cè)進行配置時，需要創(chuàng)建以下幾個關(guān)鍵組件：一采樣傳感器：用于對指定采樣路徑的信息進行采集并上送： -—訂閱：將采樣傳感器和上送目標組關(guān)聯(lián)起來。Telemetry采集上報的數(shù)據(jù)首先需要采樣傳感器來完成采集過程。用戶需要對采樣傳感器的名稱、采樣路徑等信息進行配置，設備根據(jù)配置的采樣路徑和過濾條件對指定的數(shù)據(jù)進行采集和后續(xù)的上送過程。如果需要取消訂閱，則需要對設備進行重新配置。如果設備和上送目標之間的連接斷開了，設備會進行重新連接，連接成功后再次上送數(shù)據(jù)，但是重連期間的采樣數(shù)據(jù)會丟失。在系統(tǒng)重啟或主備倒換時，Telemotry業(yè)務的配置會保存重啟或倒換完成后，Telemetry業(yè)務會重新加載配置，業(yè)務會繼續(xù)運行。AcAow——各設備主動與智能運維系統(tǒng)建立GRPC通道。然后在設備上配置訂閱： 各設備通過GRPC通道將訂閱數(shù)據(jù)上報給采集器；——采集器接收、存儲、加工處理各設備上報的數(shù)據(jù)；——控制器下發(fā)調(diào)優(yōu)指令對網(wǎng)絡進行調(diào)優(yōu)——調(diào)優(yōu)指令下發(fā)生效后，新的采樣數(shù)據(jù)又會反饋到采集器；智能運維系統(tǒng)可以分析調(diào)優(yōu)后的效果是否符合預期，持續(xù)優(yōu)化。另一種利用Telemetry輔助流量調(diào)優(yōu)的重要場景是運營商骨干網(wǎng)/城域網(wǎng)場景，其基本的流程與上面相同。網(wǎng)絡設備的管理平面與網(wǎng)管系統(tǒng)(MS)交互，提供管理平面的相關(guān)信息，例如性能數(shù)據(jù)，網(wǎng)絡登陸數(shù)據(jù)，網(wǎng)絡告警和網(wǎng)絡故障數(shù)據(jù)，以及網(wǎng)絡相關(guān)的統(tǒng)計和狀態(tài)數(shù)據(jù)[1]。Tclenetry管理面的協(xié)議應支持以下技術(shù)要求：一支持方便的數(shù)據(jù)訂閱：用戶應用應該能夠方便地選擇數(shù)據(jù)的導出方式，例如數(shù)據(jù)類型、導出頻次等——支持結(jié)構(gòu)化的數(shù)據(jù)：為了支持自動化的網(wǎng)絡運維，未來需要機器代替人來執(zhí)行網(wǎng)絡數(shù)據(jù)的解析和操作。模式化的語言(例如YANG)能夠很好的描述結(jié)構(gòu)化的數(shù)據(jù)，同時支持標準化的數(shù)據(jù)編碼和方便的格式轉(zhuǎn)化；-—支持高速的數(shù)據(jù)傳送：為了實現(xiàn)信息的實時交互，網(wǎng)絡設備需要能夠以很高的頻次發(fā)送大量的數(shù)據(jù)，因此需要緊湊的編碼格式來壓縮數(shù)據(jù)，以提升傳輸?shù)男释瑫r，推模式也能有效減少服務器和客戶端的信息交互。NETCONF是一個常用的網(wǎng)絡管理協(xié)議，主要用于設備的配置，也支持數(shù)據(jù)的收集。YANGPush[2]擴展了NETOONF,支持用戶應用訂閱某個YANG數(shù)據(jù)庫。這種訂閱是可定制的，它會觸發(fā)持續(xù)的數(shù)據(jù)上送，向上層提供YANG的配置和操作對象的變化情況。這樣就可以基于這些配置和操作狀態(tài)的遠程鏡像，在網(wǎng)絡中開發(fā)新的功能為了優(yōu)化上送的效率，在分布式的數(shù)據(jù)采集場景中(例如直接從線卡“推”數(shù)據(jù)到采集器),可以通過基于UDP的通道上報數(shù)據(jù)[3],從而提高基于NETOONF的Telemetry的上報效率。GNMI[4][5]是一種基于GRPC[6][7]框架的網(wǎng)絡管理協(xié)議。通過定義一個GRPC服務，既可以完成設備的配置，同時也可以完成Telmetry的配置GRPC是一種基于HTTP/2[8]的開源的微服務通信框架，能很好的滿足Telenetry的需求，其相關(guān)特性如下：——GPRC使用全雙工的流傳輸模型，同時支持二進制的編碼模式，提供了更高的傳輸效率；--GPRC支持跨操作系統(tǒng)平臺的特性：-—GPRC支持內(nèi)嵌的負載均衡和錯誤恢復機制。6控制面的Telemetry指的是不同網(wǎng)絡協(xié)議的運行狀態(tài)的監(jiān)控，可能涉及從Layer2到Layer7的各種控制協(xié)議。跟蹤這些網(wǎng)絡協(xié)議的運行狀態(tài)，有助于實時、細粒度的探測，定位，甚至是預測各種網(wǎng)絡問題，進一步的也有助于網(wǎng)絡的優(yōu)化?？刂泼娴腡elemetry的一個例子是BGP監(jiān)控協(xié)議(BMP)[9].它目前被用來監(jiān)控BGP的路由，以及支持其他應用，具體場景包括BGP的對端分析、AS分析、前級分析、安全分析等。BMP的用途主要是監(jiān)控BGP會話，它支持通過一個方便的接口來獲取路由視圖。BMP監(jiān)控設備通過事先建立的BMPTCP會話從被監(jiān)控設備上收集BGP路由信息。BGP終結(jié)點的監(jiān)控通過BMPPeerUp和PoerDown通告來執(zhí)行。BGP路由信息被封裝在BMP路由監(jiān)控消息和BMP路由鏡像消息中，具體內(nèi)容包括最初導出的路由表項，也包括實時的路由更新。BGP的統(tǒng)計信息通過BMP的統(tǒng)計上報消息上報，具體上報的機制可以通過時間觸發(fā)，或者事件觸發(fā)。數(shù)據(jù)轉(zhuǎn)發(fā)面的Telemetry指的是上報數(shù)據(jù)轉(zhuǎn)發(fā)面的QoS、性能等相關(guān)信息，可能關(guān)系到某個流或是某個業(yè)務。網(wǎng)絡設備提供數(shù)據(jù)的數(shù)量、質(zhì)量和及時性，決定了數(shù)據(jù)轉(zhuǎn)發(fā)面的Telenetry的實際能力。為了滿足數(shù)據(jù)提供的嚴格要求，網(wǎng)絡設備數(shù)據(jù)轉(zhuǎn)發(fā)面作為監(jiān)測數(shù)據(jù)的產(chǎn)生者，需要滿足如下的技術(shù)需求：——設備數(shù)據(jù)轉(zhuǎn)發(fā)面的主要功能是用戶數(shù)據(jù)的處理和轉(zhuǎn)發(fā)：盡管提供網(wǎng)絡的可視性非常重要，但是Telemetry只是一個輔助性的功能，因此它不應該妨礙設備上正常流量的處理和轉(zhuǎn)發(fā)(換言之，Telemetry的功能不應該降低設備轉(zhuǎn)發(fā)性能或者改變設備的轉(zhuǎn)發(fā)行為):-—涉及網(wǎng)絡0AM的應用可能要求流量的端到端的可見性，如果同時監(jiān)測不同源節(jié)點的多條這樣的流量就會導致需要大量的數(shù)據(jù)上報。但是不論使用帶內(nèi)的通道傳輸，還是帶外的通道傳輸，都需要保證這些監(jiān)測數(shù)據(jù)流量不給網(wǎng)絡帶寬帶來過于嚴重的壓力，給正常的網(wǎng)絡流量轉(zhuǎn)發(fā)帶來影響：—數(shù)據(jù)轉(zhuǎn)發(fā)面設備應該盡量提供實時的數(shù)據(jù)，最小化傳送時廷。長時間的處理、傳輸、存儲或分析時延會損害控制回路的有效性，甚至導致監(jiān)測數(shù)據(jù)失效；-—數(shù)據(jù)應該是結(jié)構(gòu)化的和可標記的，以方便應用的解析和使用。同時，不同的應用可能有不同的數(shù)據(jù)類型的需求。數(shù)據(jù)平面設備需要能夠提供足夠的靈活性和可編程性，來支持準確的數(shù)據(jù)提供；——數(shù)據(jù)轉(zhuǎn)發(fā)面的Telemetry應該支持增量的部署，并且支持網(wǎng)絡中的某些設備不感可選的，數(shù)據(jù)轉(zhuǎn)發(fā)面的Telemetry可以基于不同數(shù)據(jù)轉(zhuǎn)發(fā)面的信息收集技術(shù)或者多種技術(shù)的組合，基于業(yè)務需求及實現(xiàn)機制可按不同的分類方式對數(shù)據(jù)轉(zhuǎn)發(fā)面的Telenetry進行劃主動/被動：主動和被動方式(以及混合方式)在[10]中有詳細的介紹。被動方式包括7了TCPDUMP,IPFIX[11],sflow和流量鏡像。這些方案通常只能覆蓋較少量的數(shù)據(jù)。如果需要提升數(shù)據(jù)覆蓋，帶寬的耗費量將急劇增大。主動方式包括了Ping,Traceroute,OWAMP[12],和TWAMP[13]。這些方案是基于在網(wǎng)絡中插入測試包來實現(xiàn)的，僅能提供非直接的網(wǎng)絡測量結(jié)果。混合的方案包括In-situ0NM[14],IPFPM[15]和多點交替標記[16],它們能夠提供相對折衷，同時更靈活的測量方式，但是通常這些方案實現(xiàn)起來更復雜。帶內(nèi)/帶外：在導出到采集器之前，Telenetry的監(jiān)測數(shù)據(jù)如果承載在用戶的數(shù)據(jù)包中，這樣的方案被認為是帶內(nèi)的(例如In-situOAM),如果是Telmetry數(shù)據(jù)直接導出到采集器，不需要修改用戶包。這樣的方案被認為是帶外的。也存在著混合的方案，在這類方案中僅Telemetry的指示或者部分數(shù)據(jù)是在用戶數(shù)據(jù)包中攜帶的，例如IPFPM。端到端的方案/網(wǎng)絡內(nèi)的方案：一些端到端的方案，能夠提供從網(wǎng)絡的終結(jié)點發(fā)起測量，例如Ping.其他的方案通常在網(wǎng)絡內(nèi)起作用，對于終端Host是透明的。但是如果有必要，網(wǎng)絡內(nèi)的方案也能夠比較容易的被擴展到終端主機。流/路徑/節(jié)點：依賴于Telenetry對象，方案可以是基于流的(例如In-situOAM),基于路徑的(例如Traceroute),或者是基于節(jié)點的(例如IPFIX)。交替標記的方案包括IPFPM和多點交替標記，主要用于測量IP網(wǎng)絡或者0verlay網(wǎng)絡的丟包、延時和抖動，可以被用于點到點，以及多點到多點的流。交替標記的方案通過創(chuàng)建批量的標記數(shù)據(jù)包來實現(xiàn)。在該方案中，會修改數(shù)據(jù)包頭的某一個Bit的值，或者是修改包頭中某一個Lable值來作為標記。這些標記的數(shù)據(jù)包可以在網(wǎng)絡中被準確的識別，通過比較相關(guān)的數(shù)據(jù)包計數(shù)器的統(tǒng)計數(shù)據(jù)的差異，可以對這些數(shù)據(jù)包所在的流進行丟包率的計算。類似的，通過選擇一個特殊的數(shù)據(jù)包進行標記，可以對這個數(shù)據(jù)包所在的流進行時延的測算。每個標記周期，交替標記方案針對需要監(jiān)測的每個流需要配置兩個計數(shù)器，一個用于統(tǒng)計發(fā)送數(shù)據(jù)情況，一個用于統(tǒng)計接收到的數(shù)據(jù)情況。例如，如果需要n個測量點，需要監(jiān)測m個流，那么每個標記周期，需要的數(shù)據(jù)包計數(shù)器的數(shù)量級應該是nm*2。通常網(wǎng)絡需要提供豐富的網(wǎng)絡性能測量數(shù)據(jù)(例如數(shù)據(jù)包計數(shù)等),因此傳統(tǒng)的IPFPM方式存在著擴展性的問題。多點交替標記方法旨在解決這些問題，該方案可以應用在不需要分析細節(jié)的場景中，使性能監(jiān)控更加靈活在多點交替標記方案中，應用可以首先配置一個入口節(jié)點到出口節(jié)點之間的端到端的監(jiān)控。如果網(wǎng)絡一切正常，這個只能反映大致情況的監(jiān)控就足夠了，同時可以節(jié)省網(wǎng)絡資源。如果應用從端到端的監(jiān)控中發(fā)現(xiàn)了問題，可以配置更加細化的監(jiān)控方案來定位問題?；谟布膭討B(tài)網(wǎng)絡探測器(DNP)[17]提供了一種可編程的方法來定制應