IP網絡控制器架構與關鍵技術

盧泉 梁筱斌 尹遠陽

【摘 ?要】

為滿足主流運營商新的IP網絡運營要求，實現網絡運營流程端到端自動化閉環，基于新時期IP網絡的業務需求，研究了引入IP網絡控制器的必要性、目標架構和關鍵技術，在此基礎上研究了這些關鍵技術的應用場景，并基于實驗室環境驗證其有效性。為電信運營商在未來的IP網絡管控中提升業務發放和運維效率、降低運維成本提供重要參考。

【關鍵詞】IP網絡;控制器;架構;關鍵技術

0 ? 引言

2019年6月工信部向國內運營商頒發了5G牌照，我國提前一年進入5G時代，云業務的發展，也驅動運營商部署了大量的云專線業務。主流運營商普遍采用IP網絡統一承載4G/5G、云專線業務和已有政企專線業務，這給IP網絡管控帶來了新的需求和挑戰。具體包括：

（1）超海量業務智能管控。5G基站密度是LTE的10倍，導致投資和電費成本激增。此外還有大量的云專線和政企業務需要維護。因此，必須確保在不增加運維成本的情況下，實現對超海量業務的集中智能化管理，以保證業務的可持續發展。

（2）解決誤配置問題。在超海量業務場景下，工單量激增，更容易出現向設備下發誤配置進而引發全網故障的情況。這就要求管控系統具備配置下發預驗證和事務處理能力。

（3）需求多樣化。不同的業務有不同的SLA，要求管控系統具備實時調整流量轉發路徑以滿足SLA的能力。

目前業界已普遍達成共識，集中式的IP網絡SDN控制器，可很好地解決上述不足，滿足上述需求[1]。在控制器技術成熟后，還將納入生產網絡的管控系統中，實現IP網絡集中自動化管控，使能端到端網絡運營流程自動化閉環。本文將對IP網絡控制器的架構、關鍵技術和應用進行探討。

1 ? ?IP網絡控制器總體架構

IP網絡控制器包含控制服務和數據采集兩個子系統。其總體架構如圖1所示：

控制服務子系統包含了集中化的IP網絡控制功能模塊，其關鍵技術包括NETCONF、YANG模型解析與映射、拓撲收集、路徑計算和下發。

數據采集子系統包含了IP網絡的數據采集模塊，可供控制器的路徑計算模塊調用，作為路徑計算的約束條件。

這些關鍵技術解決了傳統IP網管缺乏集中式的控制平面的不足，下文將進行展開討論。

2 ? ?IP網絡控制器關鍵技術

2.1 ?NETCONF協議和YANG模型[2-3]

網絡配置協議（NETCONF， Network Configuration Protocol）是一種高度標準化、可編程、對網絡設備進行配置和管理的協議。控制器可通過NETCONF實現配置的讀取、下發和設備狀態采集。

NETCONF協議包含傳輸層、消息層、操作層和內容層。下一代數據模型（YANG， Yet Another Next Generation）是一種建模語言，工作在NETCONF協議的內容層，是NETCONF的重要組件，用于描述配置和狀態等數據，其描述的業務模型稱為YANG模型。

與基于命令行的配置下發、SNMP協議和MIB相比，NETCONF協議和YANG模型具備以下前者不具備的特性：

（1）良好的建模能力和擴展性。

（2）事務管理能力。

（3）數據一致性：用戶可獨占配置數據的修改權，防止多用戶操作沖突。

（4）標準化和兼容性：NETCONF協議和YANG模型遵循IETF標準。如圖2所示，運營商根據自身需求在控制器中定義業務YANG模型，控制器根據編排器的資源編排結果，基于業務YANG模型，通過適配插件更新相應設備的YANG實例，通過NETCONF完成配置下發實現配置更新的自動化閉環。

綜上所述，NETCONF協議和YANG模型更能滿足當前和未來IP網絡業務發展需求。

2.2 ?分段路由[4-5]

控制器要具備集中式路徑計算能力，首先要求路由器支持分段路由（SR， Segment Routing）。SR包括域內SR和跨域SR兩類，可用于SR流量工程（SR-TE， Segment Routing Traffic Engineering）和SR盡力而為轉發（SR-BE， Segment Routing Best Effort）[4]。限于篇幅，不再詳細介紹。

基于SR-TE，可在頭端路由器實現源路由，為客戶業務流量提供精準的全局路徑調度，保障業務體驗。

2.3 ?BGP-LS協議[6]

全局化的路徑優化，必須基于集中式的路徑計算。因此，必須具備將完整的域內或跨域拓撲信息同步到一個集中式路徑計算實體（PCE， Path Computation Element）的機制。PCE部署在控制器中，控制器和路由器通過攜帶鏈路狀態的邊界網關協議（BGP-LS， Border Gateway Protocol with Link State）建立會話，同步拓撲信息。

與傳統路由協議相比，BGP-LS具備以下特性：

（1）強大的可擴展能力：BGP-LS基于BGP TLV擴展而得。

（2）跨IGP域的拓撲收集能力：控制器可通過BGP-LS收集多IGP拓撲，使控制器可同時支持單域和跨域流量調度。

在實際部署中，控制器只需與少數幾臺維護全網拓撲信息的設備建立BGP-LS會話，即可同步全網拓撲信息。

2.4 ?PCEP協議[7]

在控制器獲取網絡完整的鏈路狀態信息后，由PCE完成集中式路徑（LSP）計算，通過PCE協議（PCEP， PCE Protocol）將計算好的LSP下發給頭端（PCC， Path Computation Client），即支持PCEP的路由器。

PCE主要有兩種工作方式，包括：

（1）無狀態方式，PCE只響應PCC發起的路徑計算請求，不維護LSP狀態。

（2）有狀態方式，PCE在完成LSP計算后，在本地維護LSP狀態，具體還可分為兩種模式：

1）被動模式，PCE只保存LSP狀態，不主動發起LSP的建立和對其狀態進行變更。

2）主動模式，PCE保存LSP狀態，可主動發起LSP的建立，根據網絡運行情況對其狀態進行變更。

在實際部署中，要求控制器具備對LSP的統一集中計算和實時狀態優化能力，因此建議將PCE部署為有狀態的主動模式。

3 ? IP網絡控制器關鍵技術的應用

在實驗室中搭建編排器、控制器和網絡環境，模擬現網移動承載的場景。其中編排器和控制器功能架構如圖1所示，實驗場景如圖3所示。

預置條件：

（1）被測設備由3個不同廠家提供，實驗環境為跨廠家混合組網。接入網關和匯聚網關間的接入環為50 GE鏈路，匯聚網關、二級核心、一級核心和云網關間互聯采用100 GE鏈路;測試儀采用2條10 GE鏈路分別連接2臺接入網關，采用2條100 GE鏈路分別連接2臺云網關。

（2）編排器與控制器對接妥當，已定義好4G/5G基站業務的YANG模型，編排器中已存儲模擬的基站業務CRM訂單數據和資源管理數據。

（3）控制器中已存儲基礎網絡協議配置數據。

（4）所有被測設備均支持NETCONF協議、YANG模型、BGP-LS和PCEP協議。

（5）每個路由器廠家均在控制器中提供YANG模型適配插件，用于適配和屏蔽運營商業務YANG模型與不同設備YANG模型間的差異。

（6）控制器與所有被測設備間均已通過帶外建立NETCONF會話。

（7）匯聚網關、二級核心、一級核心和云網關均支持SR。

實驗內容包括以下5個方面：

（1）具備SR功能基礎網絡協議配置下發驗證

1）如圖3所示，在接入環配置OSPF和LDP，在匯聚網關到云網關間配置支持SR的ISIS協議，其中每臺設備的節點SID范圍配置為16000～23999，鄰接SID范圍配置為15000～15999。

2）鄰接SID由每臺設備在本地獨立分配;節點SID由控制器統一全局分配并下發給設備，其在控制器上規劃如表1所示：

3）通過NETCONF協議將上述配置下發到對應設備。

4）在每臺接入網關和匯聚網關查看OSPF鄰居和LDP鄰居狀態，均正常，與期望結果一致。

5）在每臺匯聚網關、二級核心、一級核心和云網關查看ISIS鄰居狀態，均正常;查看節點SID，與表1規劃值一致。

6）在每臺匯聚網關、二級核心、一級核心和云網關查看每個使能ISIS的端口的鄰接SID分配情況，記錄結果如表2所示：

7）具備SR功能基礎網絡協議配置均成功下發并生效。

（2）基站業務開通功能驗證

1）在接入網關和匯聚網關間部署TLDP和PW，在匯聚網關和云網關間部署MP-BGP、L3VPN和VPN ECMP，一級核心兼作VRR，用于基站業務承載.

2）相關的承載通道和QoS配置數據由編排器根據模擬的CRM訂單數據自動生成，下發控制器。

3）控制器根據編排器下發的數據，自動為每臺相關設備生成相應的設備級配置數據，并通過NETCONF下發到相應設備。

4）在每臺設備上觀察相應的承載通道狀態（如PW、L3VPN、BGP狀態等），狀態均正常。

5）在測試儀上構造并發送雙向流量，每條鏈路包含10條流，總流量6 Gbps。

6）在匯聚網關、二級核心、一級核心和云網關上觀察每條縱向連接鏈路的利用率，各條鏈路利用率基本相同。

7）在測試儀上觀察1小時內的統計數據，測試數據報文均可正常收發，無丟包。

8）基于NETCONF和YANG模型，可實現基于模型驅動的業務開通，即業務模型一次定義、重復調用，由編排器自動編排網絡資源，控制器自動生成設備配置，并基于設備的配置驗證功能保證配置的有效性，有效避免了超海量業務場景下業務開通誤配置的出現。同時可實現從業務訂單到業務開通的端到端秒級自動化閉環，相比原有的分鐘級業務開通方式（基于業務訂單手動編排網絡資源，再經網管完成配置下發），效率提高了10倍以上，可有效縮短5G網絡的建設交付周期。

（3）網絡拓撲與SID信息統一收集功能驗證

1）控制器與匯聚網關和VRR建立BGP-LS會話，集中收集IGP拓撲。

2）在控制器上查看拓撲，與實驗拓撲一致，同時查看SID信息，與表1和表2一致。

3）控制器可正確收集網絡拓撲和SID信息。

（4）控制器下發隧道功能驗證

1）在控制器上將PCE配置為有狀態的主動模式。

2）在控制器上手動規劃隧道路徑，指定進入設備A的上行流量路徑為A→B→D→E→F→H→G，均指定節點SID，通過PCEP將隧道信息下發給設備A;指定進入設備G的下行流量路徑為G→H→F→E→D→B→A，均指定節點SID，通過PCEP將隧道信息下發給設備G;不指定進入設備B的上行流量和進入設備H的下行流量路徑，其流量仍經IGP最短路徑轉發。

3）在設備A上查看下發的隧道，狀態正常。

4）在設備A上tracert隧道，同時在設備A上去往設備B鏈路的出方向抓取報文，觀察到的標簽棧信息如表3所示：

5）在設備G上查看下發的隧道，狀態正常。

6）在設備G上tracert隧道，同時在設備G上去往設備H鏈路的出方向抓取報文，觀察到的標簽棧信息如表4所示：

7）經驗證，通過PCEP下發到PCC的隧道與手動規劃結果一致。

（5）控制器路徑計算功能驗證

1）在匯聚網關至云網關間的各鏈路配置時延屬性，通過NETCONF更新到設備，具體配置值如表5所示：

2）通過BGP-LS更新拓撲信息，在控制器上查看，各鏈路時延信息與表5一致。

3）在控制器上觸發隧道計算，隧道端點分別為設備A和設備H，約束條件為路徑總時延最小。

4）控制器通過PCEP將隧道分別下發給設備A和設備H。

5）分別在設備A和設備H上tracert時延最小隧道，結果如表6所示：

6）控制器向匯聚網關和云網關更新策略，DSCP值為EF的流量經最低時延隧道轉發，其他流量經IGP最短路徑轉發。

7）測試儀向設備1灌注6 Gbps流量，其中DSCP值為EF的流量為2 Gbps，DSCP值為0的流量為4 Gbps;向設備H灌注2 Gbps DSCP值為EF的流量，向設備G灌注4 Gbps DSCP值為0的流量。

8）在隧道各途徑鏈路上分別抓取上下行EF流量報文，觀察其標簽棧信息，結果如表7所示：

9）在測試儀上觀察流量統計信息，從設備G接收到4 Gbps DSCP值為0的上行流量，從設備H接收到2 Gbps DSCP值為EF的上行流量;從設備1接收到4 Gbps DSCP值為0的下行流量和2 Gbps DSCP值為EF的下行流量。

10）EF流量路徑符合預期，流量出口和收發符合預期。

綜上所述，實驗內容的5個方面均取得預期結果，符合期望。

4 ? ?結束語

本文從運營商業務發展的需求出發，分析了運營商重構原有網絡管控系統的需求，基于這些需求介紹了其中的關鍵技術，最后基于實驗室環境對這些關鍵技術的協同部署進行了驗證，初步具備超海量業務高效開通、避免誤配置、集中式網絡信息收集和路徑計算的能力，為下一步現網試點和大規模推廣提供了技術儲備和實施參考。

參考文獻：

[1] ? ? 尹遠陽，盧泉，孫嘉琪，等. 基于OpenDayLight的IP RAN網絡資源編排系統設計及實現[J]. 電信技術， 2017（6）： 75-79.

[2] ? ?R E， M B， J S， et al. RFC 6241-Network Configuration Protocol （NETCONF）[S/OL]. （2011-06）[2019-08-29]. https：//tools.ietf.org/html/rfc6241.

[3] ? ? M B. RFC 6020-YANG-A Data Modeling Language for the Network Configuration Protocol （NETCONF）[S/OL]. （2010-10）[2019-08-29]. https：//tools.ietf.org/html/rfc6020.

[4] ? ? ?IETF. IETF RFC 8402： Segment Routing Architecture[S]. 2018.

[5] ? ?何曉明，盧泉，邢亮. 分段路由網絡研究及其在流量工程中的應用[J]. 電信科學， 2016（6）： 186-194.

[6] ? ?H G， J M， A F. RFC 7752-North-Bound Distribution of Link-State and Traffic Engineering （TE） Information Using BGP[S/OL]. （2016-03）[2019-08-29]. https：//tools.ietf.org/html/rfc7752.

[7] ? ?J P V， J L L R. RFC 5440-Path Computation Element （PCE） Communication Protocol （PCEP）[S/OL]. （2009-03）[2019-08-29]. https：//tools.ietf.org/html/rfc5440.