電子發(fā)燒友App
在國家政策的推動下，國內(nèi)IPv6產(chǎn)業(yè)鏈加快成熟，終端和業(yè)務平臺等方面的發(fā)展也加快了IPv6網(wǎng)絡建設的步伐。承載網(wǎng)作為運營商基礎網(wǎng)絡，也面臨向IPv6演進的訴求。
VPN支持IPv6
隨著基站和核心網(wǎng)連接承載的接口IPv4/IPv6雙?；?，承載網(wǎng)需支持6vPE提供雙棧VPN，滿足客戶側IPv6的演進需求。6vPE是在IPv4 MPLS網(wǎng)絡上疊加IPv6 VPN，運營商僅需在業(yè)務的入口PE和出口PE設備上升級支持IPv4和IPv6雙棧就可以支撐業(yè)務的IPv6需求，中間節(jié)點可以仍然是IPv4 MPLS網(wǎng)絡。6vPE控制面協(xié)議還是MPBGP，通過新增地址族在BGP鄰居之間發(fā)布IPv6路由，能夠構建支持IPv6的L3VPN。
雙棧VPN可以同時支持存量的4G基站和新建的5G基站承載。用戶側基于現(xiàn)有模式提供雙棧接入，對于存量4G基站，只分配IPv4地址，通過VLAN子接口接入VPN;對于支持IPv6的5G基站，分配IPv4和IPv6地址，并支持兩種接入方式，既可以在同一VLAN子接口上同時配置IPv4/IPv6地址，也可以在不同VLAN子接口上分別配置IPv4/IPv6地址。建議采用第一種方式來簡化VLAN配置。同樣，核心網(wǎng)也需要支持IPv4和IPv6雙棧。
在VPN內(nèi)，5G基站使用IPv4地址與存量4G基站通信，使用IPv6地址與核心網(wǎng)通信，而4G基站仍然使用IPv4地址與核心網(wǎng)通信。雙棧VPN實現(xiàn)簡單，在滿足業(yè)務要求的同時可以避免IPv4和IPv6之間的復雜轉換（見圖1）。
公網(wǎng)支持IPv6
雙棧VPN可以為客戶提供IPv6服務，但承載網(wǎng)自組網(wǎng)可以是IPv4。
隨著運營商網(wǎng)絡全面向IPv6演進，承載網(wǎng)設備和協(xié)議也需要全面支持IPv6?？刂泼鍵Pv6承載網(wǎng)控制面主要包含了DCN、業(yè)務控制面和南向接口通道等。在傳統(tǒng)IPv4網(wǎng)絡中，由于管理地址空間不足或外部DCN網(wǎng)絡的一些限制，分配給承載網(wǎng)的管理IP非常有限，需要支持網(wǎng)關網(wǎng)元功能。整個承載網(wǎng)只需對網(wǎng)關網(wǎng)元分配IP地址即可，非網(wǎng)關網(wǎng)元可以使用私有IP或者ID與網(wǎng)管通信。同時，由網(wǎng)關網(wǎng)元進行地址轉換，轉換帶來的復雜性使得網(wǎng)關網(wǎng)元的能力受限。DCN演進到IPv6之后，不會再有IPv4管理地址不足的問題，因此也就無需支持網(wǎng)關網(wǎng)元和地址轉換的功能，所有網(wǎng)元都可以直接與網(wǎng)管通信，實現(xiàn)了簡化。此外，DCN自通需要設備生成默認IP地址，在傳統(tǒng)IPv4網(wǎng)絡中，各廠家的默認地址都是以私有方式生成，而IPv6的默認地址可以采用標準的IEEE EUI-64（64bit前綴+EUI-64）或RFC 3041（64bit前綴+64bit隨機地址）兩種方案，相比于IPv4更有利于統(tǒng)一各廠家DCN實現(xiàn)方案，便于實現(xiàn)DCN互通。DCN一般采用OSPF協(xié)議，相應的IPv6 DCN需支持OSPFv3協(xié)議。
業(yè)務控制面的部署與IPv4類似。對于IP地址的規(guī)劃與分配，要與網(wǎng)絡拓撲層次結構相對應，既要有效利用地址空間，又要體現(xiàn)出網(wǎng)絡的可擴展性、靈活性和層次性，同時能滿足路由協(xié)議的要求，以便于在網(wǎng)絡中實現(xiàn)路由聚合，減少路由表的條目，減少對CPU、內(nèi)存的消耗，提高路由算法效率。具體來說，各地市使用一個/48用于環(huán)回地址，每個環(huán)回地址使用/128的地址。每個地市使用一個或者多個/48用于接口互聯(lián)地址，其中為每個連接預留一個/64，地址段使用/127。此處與IPv4的主要區(qū)別在于需部署支持IPv6的協(xié)議，除了ISISv6等路由協(xié)議外，相應的SR擴展、BGP-LS、PCEP等協(xié)議都需支持IPv6。
網(wǎng)絡演進并非一蹴而就，從IPv4控制面到IPv6是一個逐步升級演進的過程，兩者需要在一段較長的時間內(nèi)共存。為了支持平滑演進，控制面也需要支持IPv4/IPv6雙棧。雙棧的部署可以分為下面幾個階段：
-逐步升級設備具有IPv6的能力;
-在維持原來IPv4的DCN和業(yè)務控制面配置不變的情況下，新增網(wǎng)元和接口的IPv6地址，并部署ISISv6或者OSPFv3的進程，與原來的IPv4控制面完全獨立;
-過渡期內(nèi)，如果設備同時部署了IPv4和IPv6地址，優(yōu)先使用IPv6進行通信;
-待全網(wǎng)設備都完成IPv6部署后，再逐步刪除原來的IPv4控制面，只保留IPv6即可。
轉發(fā)面IPv6
在現(xiàn)有的承載網(wǎng)中，轉發(fā)面采用的都是MPLS技術，MPLS優(yōu)雅簡潔的數(shù)據(jù)面很少遭遇挑戰(zhàn)，但復雜的控制面使得網(wǎng)絡部署較為復雜。SR技術簡化并且統(tǒng)一了MPLS控制面，已經(jīng)受到越來越多運營商的青睞。SR技術支持MPLS和IPv6兩種數(shù)據(jù)面，即SR-MPLS和SRv6。當網(wǎng)絡演進到IPv6之后，數(shù)據(jù)面是繼續(xù)保留MPLS還是也采用IPv6？
與SR-MPLS使用20bit的標簽來表示SID不同，SRv6使用的128bit SID更具擴展性。SRv6 SID可以分為locator、function和parameter等三部分，其中l(wèi)ocator用來表達到達該節(jié)點的路由信息，function和parameter則分別表示在該節(jié)點執(zhí)行的具體功能和所需的參數(shù)。
此外SRv6具有很好的端到端特性，在接入網(wǎng)、城域網(wǎng)、骨干網(wǎng)和數(shù)據(jù)中心都統(tǒng)一到IPv6-only的網(wǎng)絡之后，可以很容易為用戶提供端到端服務。SRv6的問題是與現(xiàn)有MPLS轉發(fā)面不兼容，無法平滑演進，現(xiàn)網(wǎng)設備需要硬件升級才能支持SRv6，且由于SRv6 SID開銷過大，導致支持的棧深也很受限。
為了解決SRv6棧深的問題，也有一些其他的可選方案：
-采用層疊模型，overlay的業(yè)務層使用SRv6，但承載網(wǎng)依舊采用SR-MPLS，將客戶的SRv6業(yè)務當成普通IPv6報文來承載;
-在邊界節(jié)點執(zhí)行SRv6和SR-MPLS的轉換，承載網(wǎng)內(nèi)使用SR-MPLS建立業(yè)務路徑，并以SRv6 Binding SID的方式通告給其他網(wǎng)絡，其他網(wǎng)絡將BSID壓入SRv6標簽棧中，SRv6報文到達承載網(wǎng)邊界節(jié)點后，邊界節(jié)點執(zhí)行End.BM的操作將SRv6 BSID映射為SR-MPLS標簽棧，在承載網(wǎng)內(nèi)以MPLS的標簽轉發(fā)，以節(jié)省開銷;
-采用SRoUDP構建端到端SR，SRoUDP是一種在native IP網(wǎng)絡上支持SR的技術，依舊通過MPLS標簽棧來表示SR的segment list，但MPLS標簽棧并未直接封裝在以太網(wǎng)中，而是封裝在UDP報文中，不支持SRoUDP的節(jié)點可以直接以native IP的方式轉發(fā)。SRoUDP兼具SR-MPLS開銷小和SRv6支持native IP轉發(fā)面的優(yōu)勢，但其封裝方式相對復雜。
除了以上方式外，還有CRH、Binding SID、PCEP FS以及IGP靈活算法等技術都可以有助于優(yōu)化SRv6的棧深。當前各種技術處于百花齊放的階段，需關注相關的標準進展和業(yè)界動態(tài)，以確定未來的主流發(fā)展趨勢。
結合基站和核心網(wǎng)IPv6的部署進度以及演進策略，承載網(wǎng)可以分步驟演進支持IPv6。第一階段先部署6vPE，滿足基站和核心網(wǎng)IPv6的承載需求;第二階段將控制面演進到IPv6，解決DCN地址轉換等問題。當前節(jié)點轉發(fā)面可以仍然維持簡潔高效且成熟的MPLS機制，SRv6技術的網(wǎng)絡可編程能力更強，但技術還不成熟，如何提升SRv6指令的封裝效率是行業(yè)關注的重點問題，待SRv6技術成熟后再考慮全面支持轉發(fā)面IPv6。
來源：ZTe刊
工商網(wǎng)監(jiān)
評論