MPLS 的最佳化——Vecloud

　　從SD-WAN廠家的角度來看，只要把流量做好標記送給PE上就行了，PE間的打通並不屬於SD-WAN要考慮的問題。不過對於運營商來說，MPLS VPN是企業廣域網業務的基礎，也是能夠體現服務差異化的最關鍵環節。因此，運營商在設計SD-WAN業務的時候，一定會帶上MPLS VPN一起做考慮。不過，傳統的MPLS VPN所存在的一些侷限性，使得它在與SD-WAN進行整合時顯得很不協調。首先，開通週期太長，交付速度遠遠跟不上業務的需求。其次，頻寬難以按需調整，客戶只能按照峰值頻寬的水平進行超買。另外，無法與雲進行聯動，企業入雲的流量難以納入到服務體系中。

　　快速開通的問題，並非單純地引入SDN控制器對兩端PE/ASBR做自動化配置那麼簡單。在運營商的傳統體系下開通一個MPLS VPN，週期保守估計在45-90天，從開始填寫訂單到最後完成交付，其間要流轉數十個步驟，其中向裝置下發配置這個環節已經是由MPLS VPN網管一類的角色自動完成的，換上SDN控制器來配也沒有任何本質的區別。真正的問題在於，傳統的BOSS系統太過於臃腫，為保證系統的穩定運轉，不僅流程複雜繁瑣，而且很多步驟需要人工介入。因此破題的關鍵在於，運營商要對BOSS的架構和業務流程進行精簡，否則任何網路層面的改進都是杯水車薪。

　　頻寬按需調整，在BOSS層面也面臨著同樣的現實問題。單純從網路的層面來講，調頻寬的方法要看MPLS VPN的QoS模型，如果是Diff-Serv的就是在PE上做限速和Mark，如果是Int-Serv恐怕就要去搞RSVP了。想法是好的，但在現實中運營商可能會遇到一些頭疼的問題。首先，是調頻寬這個動作極容易使網路變得不穩定，一旦客戶調的時候影響了別人，很難去界定責任。其次，按需的粒度很難掌握，細了的話太影響收入，粗了很多時候對客戶就失去吸引力了。另外，按需服務的模式對計費系統衝擊太大，風險性需要進行謹慎的評估。

　　與雲的聯動不足，需要運營商與雲提供商雙方來共同解決。雲機房通常會建設在都會網路核心或者骨幹網這一層面，透過DC Edge來接入運營商的Internet。隨著雲端計算的逐步成熟，一些高價值的企業流量開始流向雲端，然而Internet卻難以為這部分流量提供足夠的連線質量，引入MPLS VPN來解決這一問題是很自然的需求。對於運營商而言，如果不是市場策略上有什麼額外的考慮，單純從技術上來講事情是很簡單的，DC Edge就是CE，只要搞定它與PE間的接入和路由就可以了。

　　接入上沒什麼說的，裸纖/專線/VPN都可以，對於幾個大的公有云，甚至可以直接把PE搬到DC Edge的機房去做直連，透過物理介面或者子介面來隔離租戶。如果由於一些現實的因素，運營商和公有云間做接入存在困難，還可以透過第三方的IXP/CXP來進行中繼。

　　路由這一塊，由於要跨域一般就是靜態路由或者BGP，如果是用靜態路由，就是由控制器把路由配到DC Edge和PE上，如果是用BGP，那就需要控制器去配好Peering和Policy。從分工介面來看，DC Edge和雲內部的網路由公有云提供商來負責，PE和企業側的接入由運營商來負責，雙方的控制器各自封裝好API提供出來，上面的Portal或者編排器拆單後直接呼叫就可以了。對於IaaS流量來說，企業側和雲側的網路在同一地址空間內，路由直接拉通就行了，但是對於SaaS流量來說，雲一側是公網的IP地址，因此路由是沒法直接通的。因此，對於企業側訪問SaaS的流量，運營商還需要在PE送到DC Edge前做NAT，這是一個很容易被忽略的問題，特此進行提示。