主要概念的介紹

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

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

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

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

Advertise信息類型: Node Segment

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

R1 advertise一個label叫Y, 是與R3關聯(lián)的, 所以當R1收到一個數(shù)據(jù)包的top label(棧頂標簽)為Y的時候, 會直接把數(shù)據(jù)包轉(zhuǎn)發(fā)到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里, 并關聯(lián)到一個label Z(標簽). 然后針對label A或者LSP A也advertise一個ERO. 如果R1收到一個MPLS數(shù)據(jù)包, 并且top label是Z的話, 數(shù)據(jù)包就會通過LSP A被轉(zhuǎn)發(fā)到目的地.

這個multi-hop segment實際上就是起到網(wǎng)絡中出現(xiàn)多鏈路的情況時來追蹤數(shù)據(jù)包的路徑信息的作用.

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

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

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

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

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

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

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

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

Use Case: Spring & Local Path Selection

第一個案例主要是創(chuàng)建流量工程路徑. 從前面內(nèi)容可以看出, 使用adjacency label stack可以完成這個目的. 然而問題是: stack是怎么決定的? 原則上ingress router可以通過使用CSPF來確定stack, 與其CSPF將計算結果發(fā)送給RSVP, 與路徑直接關聯(lián)的stack早就被CSPF計算完畢并直接裝載到設備的硬件板卡的ASIC上了. 圖中可以看出這樣的例子: R1要計算到R9的路徑. 算出的路徑是R1-R4-R7-R9, 通過IGP adjacency label advertisement關聯(lián)的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在網(wǎng)絡層無法預留帶寬的事實, SPRING相關的流量工程的工作將會主要在TE控制器上完成. 這個控制會追蹤每一條LSP的帶寬預留是怎么完成的, 從而得知需要多少帶寬, 可分配多少帶寬這些信息.

參見圖中需要建立R1到R8的LSP并且分配帶寬為50Mbps. 假設R4和R7之間的鏈路并無足夠的帶寬, 控制器知道這個事實, 因為控制器一直在追蹤經(jīng)過這條物理鏈路上的所有LSP已使用帶寬, 然后控制器接下來的工作是計算出合適的路徑, 繞過這條物理鏈路, 使用比如R1-R4-R6-R7-R8的路徑. 然后它通過PCEP協(xié)議發(fā)送路徑信息以及關聯(lián)的label stack信息給R1. 要完成這個工作, 需要對PCEP協(xié)議做相應的修訂, 這項工作IETF已經(jīng)有人在做了. 另外, 對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地址和其他信息, 使得任何路由器能通過最短路徑并且以標簽交換法的方式來達到網(wǎng)絡的任意目的, 從某種角度來說, 這其實是LDP的一種替代協(xié)議. RFC草案的一種有爭議的說法是是否可以使用全局標簽(global label). 舉例來說, R7通過IGP把自己的loopback地址做了分發(fā), 并分配label為1001, 然后網(wǎng)絡內(nèi)任何一臺其他路由器都可以使用1001來通過最短路徑樹來達到R7. 現(xiàn)在問題在于, 當前的MPLS實現(xiàn)一直是使用本地而不是全局的標簽分配, 如果1001與之前給其他應用所分配的標簽值沖突的話怎么辦? 有可能是一個L3VPN情景里R2分配給自己的標簽呢….有的人就建議使用可配置的地址空間或者映射的方式來解決這個問題. 但是在許多避免label沖突的解決方案里, 完全避免global label沖突的一種方法叫l(wèi)abel blocks, 我們來看一下怎么解決這個問題.

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

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

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

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

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

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

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

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

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

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

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

要解決這個情況, 可以使用source rated bypass tunnel(我就不翻譯了, 真不知道合適的中文翻譯是啥), 通過RSVP-TE來做信令, 圖中紅色的就是, 或者可以使用adjacency label stack(圖中藍色箭頭所示). 如果我們要保護LDP流量, 為避免在R1-R5之間建立targeted LDP session, R1可以使用IGP node label, 發(fā)給R5, 因為R5期待收到這樣的label數(shù)值(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通告. 在這一張圖上, 路由更新的流動是從左到右, 而數(shù)據(jù)報文的流動是從右到左. 用MUC44這臺設備舉例, 當發(fā)送數(shù)據(jù)包給PAR3的時候, 通常是使用FRA21作為出口, 我們想在FRA21整機失效時啟用保護措施. 我們使用FRA22作為protector PE, 這個例子的應用是MPLS L3VPN. FRA22通告context label, 這是用來標識原先預定去往FRA21的流量被PLR半路攔截的. 在我們原先的實現(xiàn)里, context label是通過LDP送達的. 但這意味著這個功能能夠?qū)崿F(xiàn)的程度是基于IGP metric的, 就類似LDP LFA一樣. 這樣的話實際上是欺騙了PLR, 讓PLR完成LFA的功能, 但是PLR自身并不是很明確的知道實際對于被保護的流量做了攔截并重路由到另外的出口.

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

上面只是做了簡單解釋, 實際上最詳細的技術細節(jié)在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要轉(zhuǎn)發(fā)流量到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路由器始發(fā)并去往ASBR1的流量, S自己對自己發(fā)出的流量走哪個出口并沒有控制的方法, 而這其實是由流量到達ASBR1后才能決定的. 如果我們想要S有這樣的控制, 需要做的是IGP label通告的方式. 具體流程是: ASBR1在IGP域里通告與ASBR3直連鏈路的label, 在本例里,就是label 103. 與此同時也類似的通過IGP通告與ASBR4的直連鏈路的label(本例里是104). 這就意味著, S發(fā)送流量去往AS2的時候, S實際上可以控制使用哪條egress鏈路. 使用的方法就是建立特定的label stack(標簽堆棧). 假設800是R1要向ASBR1發(fā)送流量所需要的LDP label數(shù)值, 那么S就push label 800, 但是在這個label 800下面再push label 104(這是ASBR1和ASBR4的直連鏈路的關聯(lián)label數(shù)值). 當數(shù)據(jù)包到達ASBR1的時候 數(shù)第二條彈出的規(guī)則, label 104被露出來了, 然后ASBR1轉(zhuǎn)發(fā)數(shù)據(jù)報文到ASBR4, 這就完成了路徑的控制.

Challenges in SPRING

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

到目前為止目前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.” 然而實際應用中, 肯定要考慮到組播流量的應用. 所以如果你的客戶需要組播業(yè)務, 并打算使用SR/SPRING, 那么就要考慮SPRING對組播的支持. 目前來說, 很遺憾沒有解決方案.

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

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

審核編輯：郭婷