唐寅 張進 江逸茗

【摘要】? ? 云網(wǎng)融合和業(yè)務的創(chuàng)新發(fā)展，對網(wǎng)絡的服務質量提出了更高的要求，需要提供能保證確定性帶寬、時延、抖動、丟包率等技術指標的網(wǎng)絡。分段路由作為重要的網(wǎng)絡技術，提供了多條路徑的計算方法以及多路徑選擇技術。在分段路由策略的基礎上，擴展策略模板增加了服務質量參數(shù)，用于表示可提供的網(wǎng)絡服務質量要求;通過結合網(wǎng)絡檢測技術，對多個候選路徑同時質量檢測，根據(jù)檢測的結果來決定選擇哪條路徑作為最優(yōu)路徑，提升了轉發(fā)器對業(yè)務需求定制化的能力，更好的滿足業(yè)務對網(wǎng)絡的應用需求。

【關鍵詞】? ? 分段路由? ? 分段路由策略? ? 確定性網(wǎng)絡? ? 網(wǎng)絡質量

一、背景

云網(wǎng)融合網(wǎng)絡的特征在于提供更加智能、靈活的連接，其技術內(nèi)涵是面向云和網(wǎng)的基礎資源層，通過實施虛擬化/云化乃至一體化的技術架構，最終實現(xiàn)簡潔、敏捷、開放的新型信息基礎設施的資源供給。數(shù)字化轉型的加速，使得云對網(wǎng)絡的需求更加強調靈活定制和快速交付能力，網(wǎng)絡面向云業(yè)務持續(xù)提供可靠連接服務的能力，主要包括 SLA 保障和差異化保障等。為滿足云的靈活多變需求，需要提升智能化方面的能力，網(wǎng)絡資源可以根據(jù)云業(yè)務的需求量、用戶訪問量等因素實現(xiàn)動態(tài)的實時優(yōu)化。

分段路由（Segment Routing，SR）正是在此背景下產(chǎn)生的。通過SR可以簡易的定義一條顯式路徑，網(wǎng)絡中的節(jié)點只需要維護SR的段信息，可應對業(yè)務的實時快速發(fā)展。SR通過對現(xiàn)有路由協(xié)議進行擴展，能使現(xiàn)有網(wǎng)絡更好的平滑演進;同時支持控制器的集中控制模式和轉發(fā)器的分布控制模式，提供集中控制和分布控制之間的平衡。

SR基于源路由的方式，頭節(jié)點和尾節(jié)點承擔了維護SR MPLS隧道狀態(tài)和策略的任務，在基于軟件定義網(wǎng)絡（Software Defined Network，SDN）的場景中，頭節(jié)點也承擔了和控制器對接的角色;因此基于SR的頭端節(jié)點隧道相關的管理是非常重要的。

使用SR技術，帶來的受益主要包括：1.簡化MPLS網(wǎng)絡的控制平面。使用控制器或者路由協(xié)議集中計算路徑并分發(fā)標簽，不再需要額外的隧道協(xié)議。2.具有更好的網(wǎng)絡容量擴展能力。使用的標簽數(shù)量只和網(wǎng)絡規(guī)模相關，與隧道數(shù)量和業(yè)務規(guī)模無關，設備控制層面壓力小。3.更好的向SDN網(wǎng)絡平滑演進?；谠绰酚衫砟?，通過源節(jié)點即可控制數(shù)據(jù)包在網(wǎng)絡中的轉發(fā)路徑，可靈活簡便的實現(xiàn)路徑控制與調整。

二、分段路由策略

SR的發(fā)展初期，使用隧道接口體系進行引流。主要原因為能兼容原有的技術實現(xiàn)路線，早期能滿足大多數(shù)用戶的需要。隨著網(wǎng)絡業(yè)務種類增多，以及不同類型業(yè)務對網(wǎng)絡的要求，隧道接口體系存在著明顯不足，主要包括： 需要預先配置隧道，在無法明確隧道終點的情況下，只能是部署全網(wǎng)狀的隧道，造成可擴展性問題，由于隧道與路徑一對一的關系，因此要配置多個隧道接口用于實現(xiàn)多條路徑，配置繁瑣且影響擴展性。

分段路由策略（Segment Routing Policy，SR Policy）是在SR技術基礎上發(fā)展出來的隧道引流技術。通過SR Policy路徑表示為指定路徑的段列表，指示網(wǎng)絡中的設備遵循指定的路徑。如果數(shù)據(jù)包被導入SR Policy中，段列表由頭端添加到數(shù)據(jù)包上進行轉發(fā)。

為了解決傳統(tǒng)隧道接口體系存在的問題，并為SR Policy后續(xù)創(chuàng)新打造更加堅實的基礎，文獻[1]提出全新的SR Policy體系架構。SR Policy由（頭端，顏色，端點）三元組標識。在給定的頭端節(jié)點上，SR Policy由（顏色，端點）二元組標識。頭端：SR Policy 生成/配置的地方，通常在分段網(wǎng)絡的入口設備。 顏色：用于區(qū)分同一頭端和端點對之間的多條SR Policy;顏色通常代表意圖，表示到達端點的特定方式，例如低延遲、高帶寬等要求。端點：SR Policy的終結點，是一個IPv4/IPv6地址，通常在分段網(wǎng)絡的出口設備。

SR Policy的候選路徑代表將流量從相應SR Policy頭端傳送到端點的特定方式。每條候選路徑有一個優(yōu)先級，路徑的優(yōu)先級值越高則越優(yōu)選。SR Policy具有至少一條候選路徑，其中具有最高優(yōu)先值的候選路徑是生效的路徑。每條候選路徑可以具有一個或者多個段列表，對于被引導至SR Policy的數(shù)據(jù)包，此段列表將被壓入到數(shù)據(jù)包報頭中進行轉發(fā)。

SR Policy提供了靈活的轉發(fā)路徑選擇方法，滿足用戶和業(yè)務不同的轉發(fā)需求。當SR網(wǎng)絡的源節(jié)點和目的節(jié)點之間存在多條路徑時，合理利用SR Policy選擇轉發(fā)路徑，不僅可以方便管理員對網(wǎng)絡進行管理和規(guī)劃，還可以有效地減輕網(wǎng)絡設備的轉發(fā)壓力。

三、確定性網(wǎng)絡的要求

文獻[2]闡述了確定性網(wǎng)絡的技術要求，確定性網(wǎng)絡是指能保證業(yè)務的確定性帶寬、時延、抖動、丟包率指標的網(wǎng)絡，幫助實現(xiàn)從“盡力而為”的網(wǎng)絡到“準時、準確、快速”網(wǎng)絡的過渡，控制并降低端到端時延，抖動，丟包率。確定性網(wǎng)絡的最初提出主要是為了解決低丟包、低時延等工業(yè)互聯(lián)網(wǎng)的需求，確定性網(wǎng)絡技術的部署還可以與固移融合網(wǎng)絡及邊緣云統(tǒng)籌考慮，未來還將繼續(xù)推進在廣域網(wǎng)、5G、邊緣云的落地。SR技術越來越多的應用，也需要結合確定性網(wǎng)絡的理念，提升網(wǎng)絡的服務定制化。

SDN是對傳統(tǒng)網(wǎng)絡架構的一次重構，可以實現(xiàn)資源實時管控、業(yè)務自動下發(fā)、路由分析、流量調度等功能，通過SDN實現(xiàn)差異化服務和業(yè)務流量路徑靈活調優(yōu)等能力。路徑計算單元（Path Computation Element，PCE）是SDN的一種形態(tài)，PCE通過BGP-LS或其他協(xié)議獲取網(wǎng)絡拓撲，以隧道路徑的計算、控制和下發(fā)能力為基礎，路徑計算時可以基于多重約束條件計算路徑，可以支持帶寬、時延、跳數(shù)限制、顯示路徑等約束條件進行選路。當網(wǎng)絡質量發(fā)生改變時，BGP-LS更新上報鏈路時延、帶寬等信息，PCE重新計算出新的更優(yōu)路徑并下發(fā)轉發(fā)器實現(xiàn)路徑的調整。

如圖1所示，BGP-LS搜集的信息，包括了物理鏈路的時延和抖動等參數(shù)，而SR Policy中路徑的端到端時延不僅包括鏈路時延，還包括了轉發(fā)網(wǎng)元的交換時延，因此物理鏈路時延的累加不能完全表達端到端路徑的時延。

四、基于網(wǎng)絡質量的分段路由策略方案

影響分段路由網(wǎng)絡質量的因素，除了導致網(wǎng)絡中斷的幾種情況，還包括了影響網(wǎng)絡質量的幾個因素，如鏈路帶寬利用率，轉發(fā)網(wǎng)元的交換時延，物理鏈路的質量等。

本文方案增加對SR Policy多條候選路徑的檢測能力，并且即使在路由器脫離了PCE的情況下，能夠自主完成SR路徑的網(wǎng)絡質量端到端檢測，并能實現(xiàn)自主的最優(yōu)候選路徑的選擇和切換。對SR Policy的模板進行擴展，在SR Policy模型中增加網(wǎng)絡質量參數(shù)，包括網(wǎng)絡時延、抖動、丟包率參數(shù)，表示使用該SR Policy的業(yè)務所能承受的路徑的最大網(wǎng)絡時延、抖動和丟包率。使得SR Policy可以更直接的表示業(yè)務的需求，省略了從業(yè)務需求到網(wǎng)絡語言再到網(wǎng)絡對象的翻譯過程。

通過結合網(wǎng)絡質量分析（Network Quality Analysis，NQA），對SR Policy的多個候選路徑進行網(wǎng)絡質量檢測;最優(yōu)候選路徑的選擇，不僅需要考慮優(yōu)先級值，還需要根據(jù)網(wǎng)絡質量檢測的結果來決定選擇哪條候選路徑作為最優(yōu)路徑，路徑選擇的結果更好的滿足業(yè)務對網(wǎng)絡的應用需求。

將多條候選路徑的網(wǎng)絡質量檢測結果，包括網(wǎng)絡時延，抖動和丟包率，分別與SR Policy中定義的服務質量參數(shù)進行比較，值不超過SR Policy定義的網(wǎng)絡時延，抖動和丟包率時，認為該候選路徑的網(wǎng)絡質量符合SR Policy的服務質量要求。從符合SR Policy的服務質量要求的候選路徑中，選取優(yōu)先級值最大的候選路徑作為優(yōu)選。當優(yōu)選的路徑發(fā)生改變時，觸發(fā)業(yè)務數(shù)據(jù)流量切換到新的路徑上。

4.1 SR Policy模板擴展

擴展SR Policy的模板，增加網(wǎng)絡服務質量的參數(shù)，包括網(wǎng)絡時延，抖動和丟包率。該參數(shù)作為SR Policy的附帶屬性，是可選值。

時延：表示經(jīng)過SR Policy某條候選路徑的端到端的網(wǎng)絡時延;

抖動：表示候選路徑的端到端網(wǎng)絡時延的變化情況，用某段時間內(nèi)最大時延與最小時延之間的絕對差值表示;

丟包率：所丟失數(shù)據(jù)包數(shù)量占所發(fā)送數(shù)據(jù)包總數(shù)的比率。

定義的參數(shù)值表示服務質量要求的最大邊界值，對某條候選路徑進行檢測得到的值，如果超過定義的參數(shù)值，則認為該候選路徑不符合服務質量要求?？梢允褂眠@幾個參數(shù)的任意組合，來表示特定業(yè)務對SR Policy的網(wǎng)絡質量要求。

4.2 網(wǎng)絡質量分析的要求

NQA實時采集各種網(wǎng)絡運行指標，為用戶提供網(wǎng)絡服務質量的相關結果，實現(xiàn)用戶對網(wǎng)絡運行狀況的準確控制。為了使網(wǎng)絡服務質量可見，使用戶能夠自行檢查網(wǎng)絡服務質量是否達到要求，以一種統(tǒng)計的方法來提供時延、抖動、丟包率等相關統(tǒng)計參數(shù)。

NQA開啟后，對SR Policy下所有的候選路徑同時進行網(wǎng)絡質量檢測，檢測時發(fā)送的檢測報文，使用該候選路徑中段的有序列表進行封裝和轉發(fā)，檢測報文將會按照候選路徑進行轉發(fā)檢測。由于網(wǎng)絡的抖動和丟包率是基于統(tǒng)計的方法計算得到的，因此多個候選路徑的檢測結果計算，必須使用相同的統(tǒng)計周期。

為每條路徑生成檢測結果，包括網(wǎng)絡時延，抖動和丟包率參數(shù)，如圖2所示。

4.3 最優(yōu)候選路徑的選擇

在SR Policy存在多條候選路徑的前提下，用戶首先基于特定業(yè)務的網(wǎng)絡質量需求，為SR Policy設定網(wǎng)絡服務質量參數(shù)，可以設定網(wǎng)絡時延，抖動和丟包的參數(shù)的任意組合;開啟NQA，對SR Policy的所有候選路徑同時進行網(wǎng)絡質量檢測，得到每個有效候選路徑的檢測結果;將檢測結果與SR Policy設定的網(wǎng)絡服務質量參數(shù)進行比較，如果檢測結果值在SR Policy設定的網(wǎng)絡服務質量參數(shù)范圍內(nèi)，則認為該候選路徑符合網(wǎng)絡服務質量要求;如果存在符合網(wǎng)絡服務質量要求的候選路徑，從中選擇最高優(yōu)先級的候選路徑作為最優(yōu)路徑;如不存在符合網(wǎng)絡服務質量要求的候選路徑，則從所有有效候選路徑中選擇最高優(yōu)先級的候選路徑作為最優(yōu)路徑。實現(xiàn)流程如圖3。網(wǎng)絡質量存在不穩(wěn)定性，因此在不同的時間段內(nèi)，最優(yōu)路徑可能會變化。當最優(yōu)路徑發(fā)生變化時，觸發(fā)業(yè)務流量切換到新的最優(yōu)路徑上。多條候選路徑的存在，也可以防止網(wǎng)絡中鏈路故障或節(jié)點故障導致的業(yè)務中斷，提升了網(wǎng)絡的可靠性。

五、結束語

本文方案基于確定性網(wǎng)絡的要求，分析了分段路由策略的技術，通過對分段路由的SR Policy的模板進行擴展，并基于模板設計了對多條候選路徑的網(wǎng)絡質量檢測方案，根據(jù)檢測結果來選擇最優(yōu)的候選路徑，從而更好符合云網(wǎng)融合情況下不同業(yè)務的多樣化網(wǎng)絡需求。

SR Policy面向的是特定業(yè)務的體驗，提供了靈活的轉發(fā)路徑選擇方法，更好的滿足用戶不同的轉發(fā)需求。隨著5G、物聯(lián)網(wǎng)等業(yè)務和應用場景的擴展，SR Policy技術體系也將持續(xù)擴展升級以滿足下一代網(wǎng)絡平臺所需要的能力。

參? 考? 文? 獻

[1]draft-ietf-spring-segment-routing-policy-08，Segment Routing Policy Architecture.SPRING Working Group.July 7， 2020

[2]RFC 8655，Deterministic Networking Architecture.Internet Engineering Task Force （IETF）.October 2019