SDNLAB技術(shù)分享：SPRING/Segment Routing

主要概念的介紹

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

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

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

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

Advertise信息類型: Node Segment

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

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

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

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

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

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

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

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

BGP就像鏈鋸, BGP對(duì)于處理service和AS之間以及transport LSP的能力是有目共睹的, 然而對(duì)于需要手工指定路徑的LSP以及P2MP的樹型拓?fù)涞慕? BGP不是最好的選擇.

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

接下來我們探討一下幾個(gè)SPRING相關(guān)的案例.

Use Case: Spring & Local Path Selection

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

說了這么多, SPRING并沒有預(yù)留帶寬, SPRING LSP只存在于ingress router R1上; 路徑上的其他路由器對(duì)R1使用這條路徑并無感知. 這就意味著, 我們?cè)诼窂接?jì)算的時(shí)候并不能使用帶寬作為限制條件. 在SPRING的解決方案里, 并沒有 “計(jì)算一條路徑 & 預(yù)留50M帶寬”的這種說法, 因?yàn)榭刂破矫嫔喜]有做這個(gè)預(yù)留帶寬的動(dòng)作. 基于這個(gè)原因, 你無法對(duì)ingress router的CSPF使用SPRING

Use Case: Spring & TE Controller

基于SPRING在網(wǎng)絡(luò)層無法預(yù)留帶寬的事實(shí), SPRING相關(guān)的流量工程的工作將會(huì)主要在TE控制器上完成. 這個(gè)控制會(huì)追蹤每一條LSP的帶寬預(yù)留是怎么完成的, 從而得知需要多少帶寬, 可分配多少帶寬這些信息.

參見圖中需要建立R1到R8的LSP并且分配帶寬為50Mbps. 假設(shè)R4和R7之間的鏈路并無足夠的帶寬, 控制器知道這個(gè)事實(shí), 因?yàn)榭刂破饕恢痹谧粉櫧?jīng)過這條物理鏈路上的所有LSP已使用帶寬, 然后控制器接下來的工作是計(jì)算出合適的路徑, 繞過這條物理鏈路, 使用比如R1-R4-R6-R7-R8的路徑. 然后它通過PCEP協(xié)議發(fā)送路徑信息以及關(guān)聯(lián)的label stack信息給R1. 要完成這個(gè)工作, 需要對(duì)PCEP協(xié)議做相應(yīng)的修訂, 這項(xiàng)工作IETF已經(jīng)有人在做了. 另外, 對(duì)BGP LS的修訂也是必要的, 因?yàn)榭刂破餍枰婪峙浣o每條物理鏈路的adjacency label value.

BGP LS的標(biāo)準(zhǔn)參見https://tools.ietf.org/html/rfc7752

Use Case: Shortest Path Tree (LDP Alike) LSPs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們來看另一個(gè)案例, PE保護(hù), 也叫作尾端保護(hù). 我們來溫習(xí)一下尾端保護(hù)的原則, 下一張圖我們看一下IGP中的label通告. 在這一張圖上, 路由更新的流動(dòng)是從左到右, 而數(shù)據(jù)報(bào)文的流動(dòng)是從右到左. 用MUC44這臺(tái)設(shè)備舉例, 當(dāng)發(fā)送數(shù)據(jù)包給PAR3的時(shí)候, 通常是使用FRA21作為出口, 我們想在FRA21整機(jī)失效時(shí)啟用保護(hù)措施. 我們使用FRA22作為protector PE, 這個(gè)例子的應(yīng)用是MPLS L3VPN. FRA22通告context label, 這是用來標(biāo)識(shí)原先預(yù)定去往FRA21的流量被PLR半路攔截的. 在我們?cè)鹊膶?shí)現(xiàn)里, context label是通過LDP送達(dá)的. 但這意味著這個(gè)功能能夠?qū)崿F(xiàn)的程度是基于IGP metric的, 就類似LDP LFA一樣. 這樣的話實(shí)際上是欺騙了PLR, 讓PLR完成LFA的功能, 但是PLR自身并不是很明確的知道實(shí)際對(duì)于被保護(hù)的流量做了攔截并重路由到另外的出口.

考慮另一種情況, 如果PLR和P2之間的metric非常高的話, 流量就會(huì)被送回PLI, 這就使得我們?cè)镜谋Ｗo(hù)措施失效了.

上面只是做了簡單解釋, 實(shí)際上最詳細(xì)的技術(shù)細(xì)節(jié)在RFC 7490有詳細(xì)的敘述, 特別是偽代碼那一塊.

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

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

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

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

Challenges in SPRING

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

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

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

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

審核編輯：郭婷