隨著計算能力以指數級增長，2011年我們已經進入"澤字節"時代（1ZB=一萬億GB）。高清視頻、云計算、社交網絡、物聯網、電子商務在改變著我們的生活，不斷的帶來驚喜。持續的市場發展為眾多電信運營商帶來了機遇，同時也帶來了前所未有的壓力。許多運營商預計網絡業務流量年平均增長率將達到50%以上，"數據洪水"在摧毀、破壞原有的東西，推動更快的技術變革。

運營商精心打造的"網絡堤壩"--IP骨干網已經成為最脆弱的層面：骨干網居高不下的單位比特成本、缺失的安全管控能力、復雜的運維模式成為發展新業務、新應用不可逾越的最大障礙。為了改變這種狀態，避免"被管道化"，運營商也嘗試開始變革。中國電信"骨干雙網差異化運行＋城域雙平面運行"的模式，希望能通過差異化的服務擺脫困境，實現從純管道業務向高價值互聯網業務的轉型。中國移動構建的移動互聯網"智能管道"希望增加管道業務能力，做到精細化運營。在幾種不同的承載網絡技術變革探索途徑中，我們可以發現新型IP骨干網的共通之處，包括：降低比特成本，提高業務承載能力，構建可管可控可信的網絡(如圖1所示)。

圖1：新型IP 骨干網的關鍵能力

一、超高速以太骨干網

為了滿足網絡流量迅速增長的需求，運營商一直在尋找既可以有效保證業務提供又能減少單位比特成本的方案。高速以太網就是一種方案。10GE鏈路已經在運營商骨干網廣泛部署，在不斷提升高密萬兆端口的同時，如何用更高速的鏈路減少鏈路數量，克服多鏈路捆綁的局限性，同時簡化路由處理和簡化MPLS部署已經成為一種迫切的需求。最直接的網絡擴容方式，是升級端口速率、提高設備容量。

骨干級別路由器一直以來均以不斷提升的整體容量作為立命之本。從每槽位10GE線速到每槽位100GE線速的發展，遠非表面看到的端口能力提升這么簡單，其中蘊藏著整個路由器硬件架構的變革（如圖2所示）。

圖2 骨干路由器單機性能發展

CrossBar矩陣架構以集中交換、集中仲裁、靜態選路為特點，無論芯片技術如何提升，也無法沖破整個架構對其整機性能提升的桎梏,骨干級別路由器則多采用CLOS架構.CLOS交換架構由貝爾實驗室Charles Clos博士在1953年的《無阻塞交換網絡研究》論文中首次提出，后被廣泛應用于TDM網絡。近二十年來包交換網絡的高速發展，迫切需要超大容量和具備優異可擴展性的交換架構，CLOS這個古老而新穎的技術再一次煥發出旺盛的生命力。CLOS交換架構可以做到嚴格的無阻塞（Non-blocking）、可重構（Re-arrangeable）、可擴展（Scalable），相比傳統的CrossBar架構在突發流量處理、擁塞避免、遞歸擴展上均有巨大的提升（如圖3所示）。

圖3 CLOS多級交換網架構

針對高速的包交換系統，出現了為CLOS架構而設計的信元動態路由選路方式。動態路由關鍵點在于能負荷分擔地均衡利用所有可達路徑，結合信元拆分和重組技術，實現嚴格的無阻塞交換。動態路由方式另一個突出優點，即平滑支持更高速率的網絡端口，比如40GE/100GE。這是因為它可以充分利用所有可用路徑形成一個大的數據流通道，比如24條3.125Gbps通道可以支持100GE數據流。相反，靜態路由方式則受限于單條路徑的帶寬，比如基于XAUI接口的Crossbar交換，網絡端口速率最高只能達到10Gbps，無法支持40GE和100GE。通過對整體背板總線和交換網板能力的提升，新一代骨干級別路由器在CLOS架構下更是大放異彩，實現了對100GE接口線速能力的支持。

目前40G POS已經開始商用，100G逐漸成為業界關注的熱點。盡管100GE遲遲沒有完成業內芯片之間的標準統一，國內運營商網絡的100G傳輸也還在單廠商試點過程中，但是作為高端骨干級別路由器已經發展到了具備100GE接口線速提供能力的階段。同時，大量使用的萬兆以太接口密度也在新一代骨干路由器上得以規模提升。在目前運營商網絡上部署的骨干路由器，大多只能提供單槽位4個萬兆的線速能力，為了擴展端口，只能采用昂貴的集群方式實現端口擴展。新一代的骨干路由器單槽位能夠提供的萬兆線速能力已經達到了8、16甚至24，更有甚者已經提前發布了48端口萬兆線速的遠期路標。這樣的單機容量已經是現網部署的骨干路由器單機容量的2倍、4倍甚至10倍以上。無論從整體性能，還是占機架空間，或者部署復雜度等方面比較，新一代骨干路由器均以明顯優勢將現網骨干路由器及其集群遠遠拋在身后。

二、云業務承載

雖然在骨干網上部署100GE是必由之路，但是這對于運營商構建新型IP骨干網還遠遠不夠，畢竟業務才是是驅動帶寬迅速增長的根本原因。業務數據越來越集中，運營商的骨干網流量模型也呈現出"數據中心化"的趨勢。

數據中心的流量模型與傳統網絡有非常大的區別，在新型的數據中心中，由于資源的虛擬化，以及各類設備之間實現數據交互，大多數流量停留在數據中心內部，根據統計2010年數據中心內部設備之間的橫向數據流量占到總流量70%以上。同樣，城域IP骨干網的流量模型也正在從傳統的"縱向穿透型"向"內容分發型"演變，越來越多的流量會停留在城域網內部。IP骨干網將負責資源節點間全網狀資源分發的承載，如廣電網絡的視頻分發網、電信的IPTV CDN分發網、運營商大容量NAT資源池、AC資源池等（如圖4所示）。

圖4 新型IP骨干網流量模型

城域骨干網"數據中心化"不僅帶來流量模型的變化，對業務模型也提出了新的挑戰。分布式集群、虛擬機跨數據中心遷移、應用級容災等業務需求都要求IP骨干網能夠支持更大范圍的二層網絡互聯。隨著二層網絡域的擴大，MAC地址泛濫、二層環路、多路徑選擇等成為必須解決的問題。數據中心內部的二層域擴展目前通過Trill/SPB/Fabric Path/IRF/VSS等技術解決，而跨城域/跨廣域的二層網絡擴展面臨更加嚴峻的考驗。因為現網部署的路由器大都是通過CPU來實現MAC地址學習、控制平面與轉發平面的緊耦合關系導致虛擬機遷移時路由頻繁的更新和撤銷，增加了控制平面的負擔和潛在隱患。

跨站點二層網絡互聯主要有三種方式：裸光纖、MPLS網絡、IP網絡。從資源復用性，調度能力等因素考慮，目前以MPLS網絡為核心成為業界主流研究的方向。IETF的MPLS和L2VPN工作組的聯合主席Loa Andersson談到未來MPLS相關領域的技術方向也表示：L2VPN將主要聚焦在數據中心領域的應用。

H3C提出PE路由器MACinMAC+VPLS+IRF2融合方案，解決IP骨干網二層網絡互聯面臨的種種問題。通過將用戶MAC封裝進入PBB頭內部， N-PE不需要學習用戶MAC地址， 只學習U-PE MAC地址，表項可以大規模減小。采用PBB+VPLS嵌套組網，不同VPN用戶在核心層可以共享PW資源，從而減少網絡的PW連接數目（如圖5所示）。

圖5 MACinMAC+VPLS融合技術

在骨干級別路由器引入IRF虛擬化技術是H3C的創新之舉，尤其在城域網數據中心化的云網絡趨勢面前，虛擬化技術應用在城域范圍，使得無論是城域范圍內的數據中心/內容中心前端網絡的互聯，還是提供云服務的服務器之間跨數據中心互聯都開啟了新的一頁。虛擬化技術的使用，使得多臺骨干級別路由器成為一臺邏輯路由器，使得網元大幅度減少，從而使得網絡規劃復雜度大大降低。尤其在服務器之間跨數據中心互聯應用下，虛擬化技術使得全網狀互聯的VPLS網絡LDP數驟減，從而使得網絡規劃配置更簡單，網元壓力更小，對組播等業務的支持更好，同時還滿足了網絡高可靠性雙機部署的要求。

三、下一代網絡IPv6

現有的IP骨干網并沒有解決安全性問題，網絡攻擊成本低，防范和追溯的成本高。新一代IP骨干網必須解決網絡的可管可控可信問題，這也是構建"智能管道"的基石。盡管IPv6并不能概括下一代互聯網的全部，但已經形成了一個完整成熟的標準體系，能夠有效提升網絡的可控可管可擴可信能力。由于IPv4地址的短缺和物聯網、移動互聯網等業務的驅動，IPv6的建設速度明顯提速。到2013年年底前，我國將開展國際互聯網協議第6版（IPv6）網絡小規模商用試點，形成成熟的商業模式和技術演進路線；2014年至2015年，開展大規模部署和商用，實現國際互聯網協議第4版與第6版主流業務互通。

IPv6的演進方向已經確定，但整個產業鏈的成熟需要用戶終端、運營商、ISP內容提供商的合作推進，可以預見演進過程不會一蹴而就。為了解決IPv4地址已經耗盡，而IPv6尚未準備就緒的矛盾，在IPv6過渡期內引入運營商級大容量NAT方案，延長IPv4的使用期限，保證業務的平滑過渡，為IPv6的部署爭取時間成為IP骨干網向下一代網絡演進的必經階段。傳統NAT技術在政企客戶/集團客戶中大量使用，但是當網絡規模擴大至運營級時，網絡建設的關鍵點便集中在大容量、高可靠、用戶溯源、與現有城域網的結合等多方面。

圖6 大容量NAT部署模式

如圖6所示，在運營商城域骨干網部署大容量NAT有多種方式：集中式、分布式、混合式。集中式是指在城域網骨干核心層（CR）位置旁掛大規模NAT設備（LSN）。分布式是指在城域網骨干邊緣層（SR/BRAS）位置旁掛大規模NAT設備（LSN）。混合式是上述兩種部署模式的折中。

大容量NAT444是一種提高IPv4資源利用率的手段，但始終存在效率低、穩定性差、管理復雜、溯源困難等問題；而且NAT的大量使用造成諸多應用的限制。為了滿足長期的發展，必須向IPv6演進（如圖6所示）。

圖7 NAT444雙棧演進方案

NAT444可以實現向IPv6的平滑演進。演進路徑為NAT444'雙棧+NAT444'純IPv6。其中NAT444+雙棧的階段會持續較長的一段時間，最終實現純IPv6網絡升級。

新一代IP骨干網將擔當起三網融合的任務，為多種業務提供支撐的平臺。相信新一輪的技術變革將重塑一個堅強智能的IP骨干網。