主要概念的介紹

SPRING包括兩個大塊的內容, 首先, 控制平面, 通過IGP來advertise標簽label. 在這里, IGP域內的所有router都對其鄰居創建單一跳數的LSP, 并且通過flooding的方式advertise標簽label.

第二部分就是轉發平面的內容, 基本上是ingress router使用label stack(標簽堆棧)來轉發數據包. Label stack就是相當于TE里的ERO對象, 在不需要網絡核心維持狀態信息的情況下, 完成數據包按指定路徑轉發的工作.

這張圖里, 我們要探討一下SPRING技術特別是area 0的advertisement, 這個例子中的網絡有7個路由器(R1,R2,R3….R7). 黑色線代表物理鏈路, 每條鏈路都有關聯的cost值, 如果一個數據包要從R1轉發到R7并且必須是最短路徑轉發, 那么R1是源, R7是目的, 可以通過R1-R2-R3-R7這樣的路徑, 因為這條路徑總cost數值最小, 為3.

SPRING技術允許每臺router不僅僅擁有到其鄰居的單跳ERO, 而且可以把相應的標簽信息放到IGP里面去. 通過flooding的方式, R1作為源路由器對所有路由器有一個認知, 同時也知道如何通過單跳鏈路去往所有路徑和所有路由器的信息. 在這個例子里, 如果觀察右側, 你會看到一個label stack(標簽堆棧), 它可以追蹤數據包在本網絡的所有路徑. 或者從R2到R7的IP數據包使用label stack來完成MPLS TE ERO的功能, 而不是按照最短路徑進行轉發。

Advertise信息類型: Node Segment

SPRING的第二種advertisement就是基于node segment的, 一臺router就是一個node, 也可以稱為Node SID. 在本例里, IGP域里每臺router都有本域其他router的關聯MPLS label信息. 基本上可以說一個label映射到一臺router.

R1 advertise一個label叫Y, 是與R3關聯的, 所以當R1收到一個數據包的top label(棧頂標簽)為Y的時候, 會直接把數據包轉發到R3. 這種advertisement在SPRING里就叫作Node Segment advertisement

Advertisement信息類型: Multi-Hop Segment

第三類advertisement信息類型叫multi-hop segment, 如果R1是LSP的ingress router, 然后這條LSP是通過RSVP-TE signaled, 或者是多條adjacency segment串接起來的, 然后R1把LSP A advertise進IGP里, 并關聯到一個label Z(標簽). 然后針對label A或者LSP A也advertise一個ERO. 如果R1收到一個MPLS數據包, 并且top label是Z的話, 數據包就會通過LSP A被轉發到目的地.

這個multi-hop segment實際上就是起到網絡中出現多鏈路的情況時來追蹤數據包的路徑信息的作用.

如何使用SPRING? 是不是現有所有網絡協議的代替品? 是否為工具箱的其中一種工具? 是否增強了現有協議的功能? 是否解決了特定的用戶問題? 具體怎么定位SPRING這種技術呢?

在我們看來, SPRING只是工具箱里的一種工具, 實際上是作為一種補充作用的工具. 比如我們有多種標簽分發協議, 如RSVP/LDP/BGP等, 并對特定的應用使用特定的協議. SPRING就可以作為這種組合的有效補充, 可以在特定用戶場景解決特定的問題. 今日的網絡是在不斷發展的, 最有可能出現的情況就是如果使用了SPRING, 它會與現有的網絡的各種協議結合起來解決不同的問題.

我們來看一下各種既有協議的特性. 從LDP開始.

LDP就像一個錘子, 錘子很容易釘釘子進木頭并且很容易從木頭上拔出釘子. 同樣的, 單跳FULL-MESH LSP的情況下的自動部署是非常方便的(只要啟用LDP即可, 不需要指定LSP具體路徑). 從另一個方面來看, LDP并不適合指定路徑LSP. 所以, LDP這個協議, 有優勢也有劣勢.螺絲刀很容易把螺絲擰緊和擰松, 但是對釘子就無能為力了. 本例中, 借用類似的比喻, 如果人們需要預定義路徑的LSP, 有些特性只有RSVP(的TE擴展)才能實現, 如帶寬預留, 預留搶占, 呼叫控制等, 并且基本上對于數據包進入LSP的控制和數據平面能有比較完整的關聯.

RSVP不大擅長的是自動發現遠端的隧道(LSP). 如果網絡中LSP和router數量很多, 那么使用full-mesh的RSVP LSP就會有很大的挑戰.IGP就像扳手, 自動發現拓撲和遠程隧道的信息非常厲害. 對于在大規模網絡中分發必要的標簽信息是非常有效的. 然而, IGP對于service label是不太好的, 不能追蹤網絡中間節點的狀態信息, 并且對于P2MP的LSP建立不是非常有效.BGP

BGP就像鏈鋸, BGP對于處理service和AS之間以及transport LSP的能力是有目共睹的, 然而對于需要手工指定路徑的LSP以及P2MP的樹型拓撲的建立, BGP不是最好的選擇.

結論: 只有把所有的工具都放在工具箱里, 并有效的使用, 才能夠解決業務網絡中的流量問題, service問題, LSP問題, 帶寬問題, 等等.

接下來我們探討一下幾個SPRING相關的案例.

Use Case: Spring & Local Path Selection

第一個案例主要是創建流量工程路徑. 從前面內容可以看出, 使用adjacency label stack可以完成這個目的. 然而問題是: stack是怎么決定的? 原則上ingress router可以通過使用CSPF來確定stack, 與其CSPF將計算結果發送給RSVP, 與路徑直接關聯的stack早就被CSPF計算完畢并直接裝載到設備的硬件板卡的ASIC上了. 圖中可以看出這樣的例子: R1要計算到R9的路徑. 算出的路徑是R1-R4-R7-R9, 通過IGP adjacency label advertisement關聯的label stack存在于IGP database里, 然后這就決定了如果要達到R9, 需要走的路徑是407, 然后是709, 接下來就把這些label 通過push的操作送到packet里.

說了這么多, SPRING并沒有預留帶寬, SPRING LSP只存在于ingress router R1上; 路徑上的其他路由器對R1使用這條路徑并無感知. 這就意味著, 我們在路徑計算的時候并不能使用帶寬作為限制條件. 在SPRING的解決方案里, 并沒有 “計算一條路徑 & 預留50M帶寬”的這種說法, 因為控制平面上并沒有做這個預留帶寬的動作. 基于這個原因, 你無法對ingress router的CSPF使用SPRING

Use Case: Spring & TE Controller

基于SPRING在網絡層無法預留帶寬的事實, SPRING相關的流量工程的工作將會主要在TE控制器上完成. 這個控制會追蹤每一條LSP的帶寬預留是怎么完成的, 從而得知需要多少帶寬, 可分配多少帶寬這些信息.

參見圖中需要建立R1到R8的LSP并且分配帶寬為50Mbps. 假設R4和R7之間的鏈路并無足夠的帶寬, 控制器知道這個事實, 因為控制器一直在追蹤經過這條物理鏈路上的所有LSP已使用帶寬, 然后控制器接下來的工作是計算出合適的路徑, 繞過這條物理鏈路, 使用比如R1-R4-R6-R7-R8的路徑. 然后它通過PCEP協議發送路徑信息以及關聯的label stack信息給R1. 要完成這個工作, 需要對PCEP協議做相應的修訂, 這項工作IETF已經有人在做了. 另外, 對BGP LS的修訂也是必要的, 因為控制器需要知道分配給每條物理鏈路的adjacency label value.

BGP LS的標準參見https://tools.ietf.org/html/rfc7752

Use Case: Shortest Path Tree (LDP Alike) LSPs

我們來看另一種IGP的label advertisement, 叫作Node Segment或者叫 SID. 每臺路由器通過IGP來advertise的loopback地址和其他信息, 使得任何路由器能通過最短路徑并且以標簽交換法的方式來達到網絡的任意目的, 從某種角度來說, 這其實是LDP的一種替代協議. RFC草案的一種有爭議的說法是是否可以使用全局標簽(global label). 舉例來說, R7通過IGP把自己的loopback地址做了分發, 并分配label為1001, 然后網絡內任何一臺其他路由器都可以使用1001來通過最短路徑樹來達到R7. 現在問題在于, 當前的MPLS實現一直是使用本地而不是全局的標簽分配, 如果1001與之前給其他應用所分配的標簽值沖突的話怎么辦? 有可能是一個L3VPN情景里R2分配給自己的標簽呢….有的人就建議使用可配置的地址空間或者映射的方式來解決這個問題. 但是在許多避免label沖突的解決方案里, 完全避免global label沖突的一種方法叫label blocks, 我們來看一下怎么解決這個問題.

每臺路由器把自己的loopback通告到IGP里, 并攜帶一個特定的ID(全網唯一)以及一個label范圍. 圖中藍色方塊中顯示了每臺路由器通告進IGP的信息, 然后被flood到整個路由域, 然后所有的路由器對所有的通告都是可以看得到的.

例子中可以看到, R7通告了自己的loopback地址和label ID 7, 這個信息是網絡中唯一的, 也就是說, 沒有其他任何設備會在同樣的域內通告label ID 7. Label范圍與label ID是怎么協調工作的呢? 還是舉例來說, R2通告了label范圍為400-409(包括400和409這兩個label), 如果R2要轉發流量到R7, 那么R2期待流向它自己的數據包攜帶什么label數值, 才可以正確的轉發數據包到R7呢? 這個數值是400加7, R2的label block起始數值為400, 7作為一個index是由R7來通告到網絡的, 這樣的話, 如果R2接收到一個攜帶label數值為407的數據包, 就會把這個數據包通過最短路徑發給R7. 查看本圖的IGP metric數值可以看出, R2到R7的最短路徑需要經過R3, 那么R2通過label swapping的方式將數據包發給R3, 而這個新的label數值則是R3期待接收到的, 根據圖中所示, R3通告了自己的label block范圍是100-109, 這個數值也需要加7才能達到R7, 所以這個數值是100+7=107. 所以在這里如果你查看R2的轉發表, 也就是R2旁邊的橙色方塊, 你可以看到incoming label是407, 然后label swapping以后轉換成label數值是107, 然后直接發送到與R3的直連接口. R3也對label 107做一個操作也就是標簽彈出(pop), 然后發送到去往R7的鏈路. 通過這種方式, 網絡中任何路由器都能知道去往R7所需要的label數值, 從而正確的發送數據報文.

我剛提到過, 其實這是可以代替LDP的一種協議. 雖然這么說, 但很多人仍然需要多點LDP(mLDP)這樣一個東西, 因為SR/SPRING并無多點的解決方案. 另外 一種應用我們待會兒會提到, 那就是提高遠程LFA, 而node advertisement(節點通告)是非常有效的增加remote LFA工作的方式.

Label-Stack “Compression” Hybrid of Node and Link Labels

本圖展現的是一種混合的情況, 結合了adjacency label和node label的方式, 目的是創建轉發數據包所需要的label stack. 假設R1想發送數據到R7, 但路徑并不與IGP最短路徑完全一致. 比如按圖中所示IGP metric, 最短路徑是R1-R2-R3-R7, 但我們現在想要走的路徑是R1-R2-R3-R6-R7. 紅色箭頭所標識的是對IGP最短路徑的偏移, 綠色箭頭的部分是與IGP最短路徑重合的部分.

原則上來說, R1可以直接創建adjacency label的stack, 每跳一個stack, 但我們要使用另外的方法: 對于與IGP最短路徑重合的部分, 我們使用node label. 接下來我們就可以看到, R1建立了一個label stack(本圖右下角). 第一個label是403, 這是R2發送數據包到R3使用最短路徑樹所需要的label. 如果你需要紅色的label 306, 這是R3希望收到的數據包里所包含的label數值, 只有收到了label為306的數據包, R3才會把數據包發給R6. 最后, 標簽堆棧的棧底是label 337, 也就是R6所期望收到的數據包里包含的label value, 只有收到了label 337的數據包, R6才會正確的轉發數據到R7. 通過創建label stack(標簽堆棧)的方式, 我們才能建立基于source generating label的轉發路徑.

Function: FRR – Scheme #1 – IGP R-LFA

現在看一下基于IGP路由的FRR(快速重路由, fast re-route). 在本圖中, 每條鏈路的metric數值都是1. 先假設這是基于LDP的網絡, 并且假設R1對經過R2這個節點的流量(灰色虛線所示)進行保護, 也就是說這個例子與FRR的節點保護功能直接關聯, 同時也對鏈路保護功能直接關聯. 從拓撲中可以看出, R1并無合適的LFA鄰居, 路由器不得不將流量倒換回R0以便于流量從另一個方向走. 但是從R0角度來看, 到R7有兩條ECMP等價路徑, 所以這就有問題了, 要解決這個問題, 建議的方法是遠程LFA方式. 這個例子里, R1使用R4為遠程LFA鄰居. 術語上R4也叫PQ node(PQ節點). 接下來R1把被保護流量封裝到隧道(LDP LSP)里, 然后這條隧道(LDP LSP)是終結到R4上的, 這就是解決問題的關鍵, 這使得流量能夠經過R0, 但是并不會被R0做IGP ECMP方式處理.

要達到這個目的, R1需要知道R4所期待的數據包里包含的label數值, 也就是說R4收到了包含正確label數值的數據包才會發給R7. 如何確認這個label數值呢? R1需要和R4建立一個targeted LDP session. R1從R4處借用了R4通告的label, 并將此label推送到被保護流量的IP報文里. 這個方案是可行的, 但是在大網里, 被許多PLR選作PQ節點的路由器最后可能有很多targeted LDP session, 唯一可能出現的控制平面的擔憂. 如果我們在網絡里做了node segmented 通告(如藍色方塊所示), R1從這些通告中就可以得知R4所需要的label數值, 我們這樣就不需要targeted LDP session了. 這個例子里, R4通告了自己的label range是100-109, R7通告的index是7, 我們就知道從R4角度來說, 它期待的數據包所包含的label數值是100+7=107, R1也知道此信息. 然后R1將label 107 push到IP報文里, 然后再push需要到達PQ節點的外層label. 要達到R4也就是PQ節點的label, 可以是LDP分發的label也可以node SID label. 類似的情形也可以用來保護node SID流量

鏈路保護和節點保護的細節在RFC 4090里有詳細敘述…….當年讀了5遍……為了這次分(Zhuang)享(Bi), 又過了一遍

有些拓撲里, 即使使用遠程LFA的方式也不能做到全方位的保護. 本圖中, R4-R5的鏈路是高metric的, 所以實際上并沒有可以作為遠程LFA鄰居的PQ節點來保護途經R1-R2的流量或者做R2的節點保護. 這怎么辦呢?

要解決這個情況, 可以使用source rated bypass tunnel(我就不翻譯了, 真不知道合適的中文翻譯是啥), 通過RSVP-TE來做信令, 圖中紅色的就是, 或者可以使用adjacency label stack(圖中藍色箭頭所示). 如果我們要保護LDP流量, 為避免在R1-R5之間建立targeted LDP session, R1可以使用IGP node label, 發給R5, 因為R5期待收到這樣的label數值(307). 這樣, R1 push標簽307到IP報文里, 然后再push外層標簽到bypass tunnel(如果是RSVP-TE的話), 或者SR adjacency label.

Use Case: Tail-End Protection – Two Issues To Be Addressed

我們來看另一個案例, PE保護, 也叫作尾端保護. 我們來溫習一下尾端保護的原則, 下一張圖我們看一下IGP中的label通告. 在這一張圖上, 路由更新的流動是從左到右, 而數據報文的流動是從右到左. 用MUC44這臺設備舉例, 當發送數據包給PAR3的時候, 通常是使用FRA21作為出口, 我們想在FRA21整機失效時啟用保護措施. 我們使用FRA22作為protector PE, 這個例子的應用是MPLS L3VPN. FRA22通告context label, 這是用來標識原先預定去往FRA21的流量被PLR半路攔截的. 在我們原先的實現里, context label是通過LDP送達的. 但這意味著這個功能能夠實現的程度是基于IGP metric的, 就類似LDP LFA一樣. 這樣的話實際上是欺騙了PLR, 讓PLR完成LFA的功能, 但是PLR自身并不是很明確的知道實際對于被保護的流量做了攔截并重路由到另外的出口.

考慮另一種情況, 如果PLR和P2之間的metric非常高的話, 流量就會被送回PLI, 這就使得我們原本的保護措施失效了.

上面只是做了簡單解釋, 實際上最詳細的技術細節在RFC 7490有詳細的敘述, 特別是偽代碼那一塊.

USE CASE: Tail-End Protection IGP Signals “Alternative” Connection To Primary Node

可以解決問題的方法就是把context label通過IGP而不是LDP進行通告. 通過嚴格通告的方式, 修復路徑的行為變成了PLR對incoming LDP label進行swap, 換成IGP context label, 本例子里就是label 47, 然后把LDP value 18再push上去, 這個就是P2要轉發流量到FRA22所需要的LDP label

Use Case: Egress Peering Engineering (EPE) – A Route-Resolution Example

另一個案例. 這個解決方案是Juniper的Shawn最喜歡的解決方案, Egress Peering Engineering(EPE, 還是不會翻譯). 圖中我們有AS1, 然后AS1有ASBR1與ASBR2做IBGP peer, 然后ASBR1還與AS2的兩臺ASBR(ASBR3, ASBR4)做EBGP peer. 通常情況下, 如果你考慮從S路由器始發并去往ASBR1的流量, S自己對自己發出的流量走哪個出口并沒有控制的方法, 而這其實是由流量到達ASBR1后才能決定的. 如果我們想要S有這樣的控制, 需要做的是IGP label通告的方式. 具體流程是: ASBR1在IGP域里通告與ASBR3直連鏈路的label, 在本例里,就是label 103. 與此同時也類似的通過IGP通告與ASBR4的直連鏈路的label(本例里是104). 這就意味著, S發送流量去往AS2的時候, S實際上可以控制使用哪條egress鏈路. 使用的方法就是建立特定的label stack(標簽堆棧). 假設800是R1要向ASBR1發送流量所需要的LDP label數值, 那么S就push label 800, 但是在這個label 800下面再push label 104(這是ASBR1和ASBR4的直連鏈路的關聯label數值). 當數據包到達ASBR1的時候 數第二條彈出的規則, label 104被露出來了, 然后ASBR1轉發數據報文到ASBR4, 這就完成了路徑的控制.

Challenges in SPRING

這是最后一張slide, 我們一起來看一下SPRING/SR所面臨的挑戰, C公司(嘿嘿 ^_^)在推SPRING/SR的時候說了很多的好處, 但是并沒有對部署SR所面臨的挑戰進行詳細的分析.

到目前為止目前SPRING的一些草案和RFC并沒有提供對組播的支持, Segment Routing Architecture這一份主draft上原話是 “Segment Routing is defined for unicast. The application of the source-route concept to Multicast is not in the scope of this document.” 然而實際應用中, 肯定要考慮到組播流量的應用. 所以如果你的客戶需要組播業務, 并打算使用SR/SPRING, 那么就要考慮SPRING對組播的支持. 目前來說, 很遺憾沒有解決方案.

第二點, 大家都知道, SR/SPRING的一大好處就是網絡的核心部分不需要維護軟狀態信息, 這句話是沒錯的, 但是, 也是有代價的, 代價就是軟狀態所關聯的一些業務屬性也沒有了(而這時好的東西), 比如auto-bandwidth(MPLS LSP預留動態帶寬調整). 另一個方面就是, 對于映射到MPLS LSP中的流量, 再也無法將實際的數據轉發平面與控制平面進行關聯了, 這是一個很不好的地方.

第三點, SR/SPRING對于網絡中的LSR路由器來說, 引入了一些新的難題, 具體來說, 牽扯到路由器對于特定IP包頭和MPLS包頭的數值的查找結果并結合hash算法進行負載均衡的問題. 最后一點: entropy label確實需要MPLS LSR路由器進行特殊的處理. Juniper和Level 3合作編寫了RFC6790并要求網絡中所有路由器都能處理BGP entropy label, 對于不能處理的設備需要移除entropy label屬性. 但是令人遺憾和郁悶的是, 由于各家廠商實現起來有實際的困難, 所以RFC7447徹底免除了需要對entropy label的支持.

審核編輯：郭婷