本文作者：大河云聯，閆浩
IP網絡從1982年TCP/IP 成為互聯網前身的ARPANET標配以來，隨著互聯網的發展而迅猛擴展。在數據網絡方面基本已經一統天下，做到了 everything over IP。IP網絡作為承載互聯網，物聯網，云計算以及VR，AI等未來各種無限可能的數據服務的底層網絡，其靈活性，擴展性以及對業務的支持可編程需求要求網絡更快的完成自身演進。
從IP網絡的整體發展看，從網絡的基本可以清晰的分為三個階段，當然這三個階段的網絡在現實世界是并存的。
回退到幾十年前，IP網剛誕生時，IP協議和IP網絡還是有很多競爭對手的，比如IPX，Appletalk，Netbios，這些現在聽著很久遠的協議當時還是很流行的。比如IPX在企業網就遠比IP流行。當年的網絡和網絡設備復雜性很大程度體現于支持多種網絡層協議，支持從E1到OC-12，OC-48的多種網絡速率和接口類型。IP以及Ethernet僅是眾多選擇中的一種。
APPANET 選擇TCP/IP組合后，IP的簡單易用，Ethernet的低成本，再加上互聯網的病毒式傳播，短短的20年。這三者的強力組合就像 Intel + 微軟一樣，橫掃數據網絡。 可以認為應用層發軔的Everything Over IP 水到渠成，到了2000年左右，語音網絡，視頻網絡和數據網絡，已經可以說是 Everything Over IP了。
純IP網絡主要在統一網絡層協議和簡化傳輸介質上貢獻顯著。
純IP網絡的轉發
從本質上說是逐跳基于目的IP地址轉發完成這個動作的方式是通過 IGP + BGP 路由協議來實現附加的網絡調控手段：PBR，ACL， IP-Based QoS這個階段的網絡主要實現連通的目的，通過IGP和BGP路由協議，獲取AS域內和域間路由。構成網絡的路由器或交換機根據路由表，形成轉發表。當IP報文到達接口，入方向的芯片提取IP報文頭，根據目的IP查找轉發表，找到出端口。
多年來，大多數企業網，園區網以及相當多運營商的公眾網都采用這種方式。優點是簡單，大多數設備都支持。隨著路由協議的大規模使用和設備的大規模部署，作為整體系統的健壯性，可擴展性和穩定性以及建網成本都有了很大的優化。相應的網絡設備芯片體系也日趨完備。
但從服務的角度則看起來乏善可陳。當業務對網絡有連通以外的要求時，比如要基于源地址進行選路時，設備可以通過PBR（Policy-based routing）實現。但這并不是一種普世的服務，對于少量，臨時，非做不可的需求，可以用CLI在某些節點配置，但沒有人會瘋狂到在全網通過PBR去做路由。網絡工程師通常稱PBR這樣的實現叫做“Feature”。
在那些年里，廠商們各自都有很多Feature。用于炫技，用于投標，用于教育客戶。用于不那么完美的解決某些實際問題。
Feature 有兩個隱含的意思：
另一個現象是當某些需求用Feature無法滿足，或者是設備的性能瓶頸，或者是功能瓶頸時，網絡工程師又設計出各種appliance，疊加了特殊功能的各種大box和小Box，最著名的就是防火墻，還有4-7層交換，廣域網優化等。這些設備說到底，還是在對IP報文的處理上，解決了“基于目的地址尋址”以外的問題。
總結來說，在純IP網絡時代，是靠路由協議+feature+appliance滿足基本需求的。
MPLS based網絡在IP協議和IP網絡PK掉ATM時，盡管ATM協議的復雜和設備昂貴等諸多原因導致了市場的失敗。 IP網也由衷的羨慕ATM實現的虛電路的優勢，對于無連接的IP來說，如果能形成一個按需的虛電路，能夠根據用戶的特點提供不同的服務質量和轉發路徑，是非常有吸引力的事情，再加上當時轉發性能的一些瓶頸，綜合因素促成了MPLS的誕生和流行。
當MPLS開始規劃化使用和部署時，兩個基本概念是代表了運營商期盼已久的事情。
FEC轉發等效類
FEC(Forwarding equivalence class) ，對于相同分類的一組數據報文，提供相同的轉發處理方式。 這里所說的相同分類，相同的目的地址僅是其中的一種，基于不同的標準進行自由的網絡轉發一直是網絡工程師的愿景之一。
LSP：Label-switched path
LSP 基于FEC對報文的分類，實現了端到端的對IP報文封裝，在每跳基于Label進行轉發的單向虛電路，正如IP網絡向Frame Rely,ATM, SONET/SDH 學習的初衷，MPLS把網絡分為Core 和Edge兩個部分，其基本想法是Edge設備封裝各種需求，Core部分僅完成標簽轉發。
在全網通過Label的分發機制，從Edge節點通過Label替代目的IP地址，在網絡的提供了轉發平面的抽象。
MPLS的強大之處在于基于標簽交換，開發了一系列服務。
其中最成功的要算部署相當廣泛的L3VPN服務。其背后原因可能是三層網絡隔離而出現的巨大市場需求。即使在沒有L3VPN的互聯網，IPsec，SSL VPN等技術也發展起來。
其他的VPN如VPLS，盡管有一定的使用。但由于其市場需求有限，且有一些MPLS網絡共性的缺點和自身弱點，始終沒有大規模實施。
MPLS 當年雄心勃勃，在IETF有多個WG，無數RFC在同時演進。但復雜套著復雜，最后很多內容變成曲高和寡的紙上文章。至少在能接觸到的中國運營商和企業網層面無法大規模落地。
MPLS服務的共性弱點
多層協議累加帶來的復雜度和協議之間的配合問題
以實現VPLS的網絡為例，至少需要如下協議：
當多層協議并存時，網絡服務的脆弱性來自每臺設備上的每個協議是否能正常工作。同時，不同協議之間的配合存在問題時，也可能導致問題，比如經典的LDP和IGP之間的同步問題。
另外VPLS自身也存在一些弱點，比如：
MPLS-TE
TE最希望解決的問題是IGP路由協議相同的最短路徑視角造成的流量過于集中在少量路徑上，需要提高整個網絡的利用率。因此TE需要建立和維護大量的端到端tunnel。維護這些tunnel的代價可謂不菲。而在分布式的網絡架構下，TE始終沒有解決好tunnel計算/維護/排障的問題，TE也局限在部分運營商網絡內使用。
當然我們經過了多年之后，我們也知道理想中的FEC不過是存在想象中的美好，現實中99.9%的報文仍然是按照目的地址進行轉發。受限于芯片，設備，協議/標準化，設備，操作等諸多因素制約。
通過對MPLS服務的簡單分析，我們很容易看出，MPLS用Label較好的解決了轉發平面的抽象，但并沒有解決控制平面抽象。正是其控制平面的復雜性給網絡帶來的影響削弱了其部署范圍。 控制平面的復雜性究其本質，還是每個協議各管一段，各滿足一種需求造成的。要做VPN，需要L3VPN 或VPLS，要做流量工程，需要TE，要做QoS，需要IP or MPLS Qos 等等。 如果這些都要，你的設備是否都同時支持？你是否敢都部署？你是否愿意運維這張網絡？相信大多數網工無論是運營商，集成商還是廠商背景的面對這些問題都一臉苦笑。
所以很多技術很多年后，還是被稱為Advanced Technology，而非普世應用。很多時候，泛泛的說，能否實現某個功能？能，但能的前提條件太多：網絡設計考慮，大量配置的復雜度，設備硬件性能支持，多廠家互通時不同設備對相同feature的配置方法和缺省行為，互操作性和兼容性，排障的可操作性。
久而久之，能就成了個理論上的，理想化的說法。 而非實打實可以簡單落地的能力。
Segment Routing 是否是白衣騎士？
這兩年，SR橫空出世，讓人眼前一亮，很有些傳統網絡救世主的樣子，SR有兩個顯著的優點超越了前一階段的MPLS 相關協議。
但很明確的是，SR雖好，仍然需要有人去計算和設計路轉發路徑。誰更合適來做？顯然是SDN。
SDN網絡控制平面和具體的網絡設備解耦，是SDN最重要的特點。控制平面只有在解耦后才能形成強大的大腦，對千變萬化的業務層需求進行適配和編排后，再用不同方式下發成設備的轉發。毋庸置疑，控制平面是否集中，集中后又如何保持HA和對全網拓撲變化的快速收斂都是問題。
從這個層面看，控制平面集中與其說是SDN的特點，不如說是這個階段SDN為了實現而付出的必然而且必要的代價。
從某個角度說：路由需要完成的內容主要是以下三項:
建立拓撲，相當于網絡地圖傳遞不同Node的路由信息，相當于不同村莊的居民根據不同需求，計算出的從甲地到乙地的路徑從這3點看，SDN天然比路由協議有優勢。因為天然就有全網視圖，因為天然就已知各Node的信息。因為對接業務編排，能夠綜合各種需求，進行全局的選路計算。但從落地情況看也不完全如此，主要是第1點，在拓撲變化時，SDN的收斂能力在現階段不如傳統路由協議快速有效。
網絡服務 vs. 網絡為你而服務簡單梳理完網絡的三個發展階段，我們可以比較清楚的看到網絡的變化是從最初提供可達性的IP網絡，到有基本網絡分割服務的MPLS 網絡，到以需求為中心，能夠按需提供服務的SDN網絡。
事實證明為每一種需求單獨創造協議是行不通的，既增加控制平面的復雜性又不具有快速演進的能力。
網絡一直被應用所詬病和抱怨的是，部署速度和同時滿足多種需求的靈活性。網絡越大就越趨近于簡單，基礎的可達服務，而非能為某個application，某個臨時連接，或者某個重要用戶提供的即時定制服務。提供這樣服務的代價在設計層面是不可規模化的，在運維層面是全手工打造的，在排障層面是災難性的。
如何讓網絡在更多維度，更細顆粒度上為上層工作，除了有統一的北向接口，能夠用一個大腦理解拓撲，管理設備，設計路徑是一切成為的可能的基礎。
思科服務部門對網絡生命周期有個定義，首字母連起來是PPDIOO 分別代表P(Prepare)，P(Plan)，D(Design)，I(Implement)，O(Operate)，O(Optimize)。其中的前2個步驟Prepare和Plan主要從需求入手，依次明確戰略，資源，關鍵任務，概念設計及里程碑等內容。從技術角度看可以歸并到設計里。
ITIL 服務周期定義分為5個階段，分別是
Service Strategy 戰略Service Design 設計Service Transition 躍遷Service Operation 運營Continual Service Improvement 持續改進同樣從具體技術層面，可以把戰略和設計合并為設計。
通常的網絡實踐經驗來看，也可以總結為設計（含測試） - 部署 - 運維（含排障） - 優化四個階段。
MPLS網絡的設計階段最終的產出物是做好測試驗證的LLD（Low Level Design）。
通常在HLD（High Level Design）中明確基本布點，流量，互通，QoS等需求后要在LLD中進行量化和給出落地方案。
MPLS 網絡的設計，簡單來說重點就是路由協議+ 設備 = 配置。 因為需要支持多種協議，要做較多考慮。
設備層面：
協議實現層面
多種協議的并存情況下，各種單獨設計之間是否有沖突。如起MPLS以后，不同廠商對QoS模型的缺省影響不同，需要手工配置一致。
SDN網絡只需要考慮控制器的部署位置，網元設備的端口數量，一些必要的配套服務存在等幾個基本條件即可。簡化了網絡設計。
部署階段部署通常包括：
分配和管理各種虛擬資源：IP地址段，VLAN，AS No. 等配置模板：基于配置文件分塊后大致相同的配置內容通常集中配置好，或者做初始配置后，逐個設備單獨登錄配置。MPLS-base網絡即使有配置腳本，也需要有基于協議狀態的復雜檢查過程，才能確定網絡部署正確。
相比而言，SDN的網絡設備配置簡單，通常可輕松的實現自動化，部分設備還可實現啟動后自動部署，其本質也是因為網元設備和控制器之間的多對一關系實現的。
很難的一個事情是MPLS網絡的設計加部署時間周期，把事情考慮周全了，測試驗證做做，寫寫文檔，1-2個月真不算慢的。加上設備到貨，安裝，沒3個月以上是建不起來的。網絡的搭建時間過長，這是大家都有體會也很無奈的一件事。從根上說，我理解問題還是協議/配置/設備三者之間的耦合關系過深。
運維階段監控，變更和排障是運維階段的三大任務。
監控從共性看，拓撲發現及變化，鏈路延遲，丟包，流量的監控，分析，告警。是兩類網絡都不可或缺的功能。
從區別看，MPLS網絡運維需要監控多種路由協議的狀態，因為是全分布式，每個協議在每個接口都可能有Peer，需要對多種狀態進行監控或者事后的排障。底層故障對上層協議會造成相關影響，如何管理和屏蔽大量告警事件是挑戰。
SDN有一點優勢在于能更多的進行白盒監控，即通過對系統內部的性能指標進行監控了解系統的運行狀態，因為從南向看，SDN只需要監控少數幾種協議，監控相對簡單，而面對業務變更更是隨時隨地API可以滿足的。主要復雜度集中在控制平面和業務編排，監控也主要集中在控制平面健壯性，用戶業務狀況，以及控制和轉發的一致性等方面。在大型網絡里因底層鏈路故障導致的大量路徑計算和重新優化會需要控制及時反應。面向最終用戶的Web接口又會需要對各種請求和配置變更做出實時響應和分析。網絡至此更大程度是一個復雜的計算和業務系統。
監控的高級階段一是關聯和聯動底層數據，二是對用戶數據進行挖掘。從這個層面看，兩種網絡都還有很長的路要走。
變更如果說大量的長途故障來自于底層鏈路，屬于推土機挖斷光纖惹的禍，那變更產生的人為配置錯誤是則是故障的另一主要來源。變更的原因很多（軟件升級，硬件更換升級，業務部署，結構優化等等），最終都會落實到調流量，改配置上。
網絡部署后隨著運維時間推移，各種不同業務需求對網絡進行不同的要求后，很難再維護統一的配置模板了。各種臨時的，非標的配置需求逐漸在不同設備上 生根發芽，枝繁葉茂。到最后，沒有人去敢刪除那些可能已經不用的臨時配置。那些配置也就半永久的存在不同設備上。傳統網絡配置長在設備上，各種配置的來龍去脈又只有當事人清楚。時間一長，人，設備，需求的變化會導致配置和實際情況脫節，和現網運維人員脫節。隨便說說，哪張網絡沒有一堆無法說清的Policy，一堆無法刪除的ACL。
有一種說法是：當有了netconf+Yang后, 傳統CLI被替代，也可以自動化。但實際情況是，不論Yang的推廣和落地時間，就算所有廠商設備都通過Netconf接口可下發，但復雜配置的一致性，配置檢查及檢查后的配置刪除回滾以及配置管理仍然是有挑戰的任務。 所以配置下發的自動化 不= SDN，歸根結底的問題是分布式復雜性過多和物理設備緊耦合造成。
SDN則基本擺脫了設備配置的問題。基礎架構數據通過自發現和初始定義可以全部在GUI實現。業務數據通過GUI和API實現，軟件升級時，控制平面的前端，后端，業務編排，底層控制器各組件既可以分別升級也可以統一升級。對轉發沒有明顯影響。
排障MPLS網絡排障充分體現了網絡的復雜性，對協議，廠商設備，具體配置，網絡拓撲，排障工具的理解，運用和分析能力。排障時間對運維和生產網業務是有壓力的影響。這反過來也影響網絡設計時，有可能傾向于更保守的選擇技術和設備。期望減少排障的難度。
SDN的排障更多需要和Devops結合，通過軟件化手段解決。復雜永遠不會消失，只會轉移。傳統網工面臨的挑戰之一就是原有在CLI上的排障手段和思路可能不適用在SDN上，是API還是其他軟件工具。需要抱著開放心態，在運維過程中逐步的探索。
優化網絡的優化不是必然存在的，有時候，優化的潛臺詞是現有網絡不能滿足新的需求，需要設備部分更新換代才能實現新Feature來滿足新的需求。
MPLS Base網絡在優化時，前面的設計，部署，運維的麻煩還得重來一次。
SDN網絡則基本就是兩點
1.控制器集群的Scale-out 隨網絡規模擴大后的橫向擴容
2.網元設備的Scale-out 橫向擴容
綜上所述，網絡的運營想要搞好（故障率低，穩定，滿足業務速度快，質量高），在SDN技術產生前，似乎必然需要一個屬于精英俱樂部的網絡隊伍去完成這些內容。
復雜的Design和完備的設備測試強悍的運維，7/24 隨時Ready處理復雜故障強大的工具支撐嚴格復雜的變更體制和專業團隊運營商由于網絡規模的原因，可以得到廠商或集成商最優先的支持，同時具有相當完備且聚焦網絡運維的工程師團隊。這也是為什么多年來最有實力的運營商一直是網絡運維的翹楚。但反過來想想，這也是網絡需要進步的一個證據，網絡需要更簡單，更靈活，更快的部署和適應業務，更方便和白盒化的監控性能。
SDN網絡則基本在軟件框架內解決了按業務所需的路徑計算，南向接口的全部自動化，當然，SDN作為一種軟件化的理念，必然面臨更多軟件問題直接影響網絡的情況出現，網絡部署和運維更多變成軟件的部署和運維。所有軟件會遇到的頭痛問題，SDN都會遇到。
結語啰里啰嗦說了不少，回頭看下，很多是正確的廢話。其實這么多年感受下來MPLS網絡說到底存在很大的一個問題就是路由協議（路由策略），設備和配置之間的深耦合
路由協議（路由策略）通過本地配置來實現配置在不同廠商設備上的實現不盡相同基于本地配置，內容復雜，多協議等原因，自動化和可編程的難度大，不徹底。
SDN到底應該是如何實現和落地，這一兩年已經開始很多實踐方面的探索，大的愿景已經有了，但具體的落地和途徑其實還是有很多爭論的。 是沿著MPLS網絡繼續發展到SDN，還是從本質問題上更進一步做的更徹底些。還有待時間檢驗。數據網絡已成為數據時代的風火水電，不同范圍，不同規模，不同運營者的網絡其具體發展技術路徑和適用技術不盡相同，每一代網絡的產生和占領市場都在其當時特定情況下符合邏輯。也許純IP網絡，MPLS-Based 網絡和SDN 三者將長期共存，共同發展。
“未來已來，只是分布不那么平均”，我們可以相信發生在云計算上的事情，一定也會發生在網絡上。按需，動態，資源池化，API化，高度自動化和靈活的業務抽象必將成為網絡的主要特征。
京公網安備 11010502049343號