發布日期：2022-10-18 點擊率：66
（續上文）Enterprise Oriented SD-WAN給企業帶來的價值非常明顯，在北美訊速地搶占了銀行、零售、連鎖等行業，包括很多世界500強的大型客戶，2015年下半年開始，SD-WAN成為了業界炙手可熱的新寵。由于SD-WAN對于上述一系列關鍵技術的利用，能夠顯著地提高Internet線路的QoE，這使得Internet線路在某些場景中，得以部分地代替MPLS線路在企業組網中的作用，因此降低了企業對于MPLS的依賴性。
因此，當時業界談論最多的話題，就是“SD-WAN能否取代傳統的MPLS VPN？”。MPLS VPN是全球各大運營商的支撐性業務，SD-WAN的突然崛起，迫使著大T們開始思考應對之策。
本文作為下篇將對“SP Oriented SD-WAN”進行介紹。首先，會介紹廠家給出的SDN-Gateway的方案。其次，將對運營商青睞的vCPE方案進行介紹。最后，簡單地聊下MPLS VPN的優化問題。
二、SP Oriented SD-WAN
關于“SD-WAN能否取代傳統的MPLS VPN”，其實這個問題的答案很明顯。SD-WAN最大的價值之一，就是在Hybrid WAN的場景下更有效地去管理與使用WAN線路，幫助企業提高在WAN這一塊的ROI。因此，SD-WAN的出發點并不是要對抗MPLS VPN，因此就談不上要取代MPLS VPN，因為兩者并不在一個層面上。
無論是從紙面上來看設計，還是從實踐中看效果，SD-WAN確實實現了它所承諾的價值。運營商也很快地就看清楚了問題的本質，盡管SD-WAN客觀上會降低企業對于MPLS VPN的需求，但這是技術演進的自然結果，另外SD-WAN在靈活性、自動化、應用感知、上云等方面相比于傳統的技術方案，也有著不可比擬的優勢。權衡之下，與其把SD-WAN放到對立面，倒不如想辦法把其拉到統一的戰線上，作為一個新的業務增長點。因此，運營商并沒有排斥SD-WAN，而是對其表現出了相當開放的態度，這與很多人的設想是恰恰相反的。
SD-WAN的廠家們心里也很清楚，要做大事情就一定得把生態搞好，運營商作為生態中最關鍵的環節，有必要建立起一個融洽的合作模式。首先，純Overlay的方案存在著一定的局限性，雖然說是Transport Independent，但是如果Transport的線路質量確實不行，那也是巧婦難為無米之炊，另外對于跨國企業來說，如果不用MPLS純走Internet，那么基本上就約等于不能用。其次，運營商擁有著廣泛的客戶基礎，業務的覆蓋范圍更廣，無論在運營還是運維方面都有著巨大的優勢，這正是SD-WAN廠家們最為欠缺的環節，一些大型的客戶動輒就幾千個分支，雖然技術上是ZTP + Cloud Managed，但是從渠道和服務的角度來說，就完全是另外一回事了。
雙方一拍即合。第一種合作的思路是，運營商把廠家的方案買下來，然后自己來做渠道和服務，除了能夠分一部分SD-WAN的利潤外，更關鍵地是可以把各種WAN線路打包到方案中，為企業提供一站式、差異化的WAN解決方案。如果有足夠實力的話，還可以對產品進行一些定制，把SD-WAN的能力嵌入到自己的業務系統當中。第一種思路，不需要對Enterprise Oriented SD-WAN的技術架構進行改動，同時有著清晰的盈利模式，對于廠家來說是零成本，對于運營商來說是一種快速進入市場的有效手段。
第二種思路，是對原有方案的架構進行調整。最初所設計的SD-WAN方案是Enterprise Oriented的，從技術上來看是找不到運營商位置的，如果要做一個SP Oriented的SD-WAN，就需要在方案中引入SP的角色。那么SP Oriented SD-WAN該怎么做呢？
1、SD-WAN Gateway
廠家給出的方案，是在運營商的POP點里面放SD-WAN Gateway，負責終結企業側CPE發起的隧道，然后轉發到運營商的IP/MPLS網絡。在這種方案中，Enterprise SD-WAN中的CPE上所有能力都被保留了，不過端到端的Overlay變成了，兩頭的Last Mile用Overlay而Middle Mile交給運營商去做，如果運營商有能力的話就可以把MPLS VPN集成進去，如果短期集成不了MPLS VPN，Middle Mile這段用Overlay打過去也不是不可以。
實際上這是種很不錯的思路，各方接受起來都很自然。從客戶的角度來看，不需要去額外地購買的設備，而且傳統的WAN設備也可以通過隧道接進去了，另外SD-WAN的運維也轉交給運營商去做了。從廠家的角度來看，Enterprise Oriented的特色得以被保留，CPE仍然是高價值的產品，同時有效地解決了純Overlay的局限性，另外通過SD-WAN Gateway也得以參與到運營商的組網中。從運營商的角度來看，SD-WAN Gateway不僅提供了對接MPLS的入口，另外也提供了更加靈活的接入方式，對于Last Mile不可達的Off-Net Customer，走Overlay做接入能夠省去很多的麻煩事兒。
以SD-WAN Gateway為核心的SP Oriented SD-WAN，保留了Enterprise Oriented SD-WAN的所有能力。在此基礎上，主要是提供了對多租戶的支持，并在控制邏輯方面進行了相應的加強。
1.1 整體設計
對于運營商來說，SD-WAN Gateway作為業務的接入設備，在位置上和SR/PE并沒有本質上的區別。對于Pure Play的SD-WAN廠家來說，他們在POP里面并沒有存量的SR/PE，所以就只能推新的設備進去。形態上就是x86的盒子，相比于Enterprise Oriented SD-WAN方案中的CPE，SD-WAN Gateway作為不同客戶流量的匯聚點，接口的速率和數量都會做相應的增強，而且由于它要負責大量隧道的終結，因此對CPU和內存的要求高很多，通常會需要專用的Crypto Accelerator。而對于傳統的設備廠商來說，比如Juniper、ALU和華為，他們在POP里面有存量的SR/PE，這時候可以選擇把SD-WAN Gateway以板卡的形式插到SR/PE的機框上，以避免多引入一個物理設備的麻煩。隨著CORD在運營商中的推進，SD-WAN Gateway的形態開始逐漸向vCPE進行靠攏，關于vCPE等到后面CORD的部分再來做介紹。
控制器。從宏觀的架構來看，除了Staging Server、Controller和Analytics以外，可能會需要AAA來專門做鑒權。從細節來看，由于多租戶需求的出現，以及設備、拓撲復雜度的提高，使得控制器所用的數據模型以及業務流程都會發生一定的變化。從位置來看，On-Premise是不可行的，需要放到運營商自己的機房當中。通常是在地市級的核心機房里面，負責控制下屬的各個接入機房中的SD-WAN Gateway，以及本地企業分支的CPE。
Portal也要做相應的調整，而且運營商很可能要自己來做定制，部署的位置也取決于運營商站在什么層面上來看待SD-WAN的業務，所以這里就不多說了。
1.2 多租戶是怎么實現的？
企業側接入SD-WAN Gateway的流量，需要能夠與VRF進行關聯。按廠家的意思就是用IPSec直接打進來，把接入網這一段OTT掉。在這種方式中，需要能夠對IPSec流量關聯VRF，大概有下面這幾種辦法：（1）用GREoverIPSec，為GRE口關聯VRF；（2）用MPLSoverGREoverIPSec，用MPLS來關聯；（3）用VxLANoverIPSec，通過VNI來關聯VRF；（4）通過VTI口來關聯VRF；（5）用ISAKMP Profile綁定VRF，識別SPI后直接關聯VRF；（6）用私有的IPSec封裝，在IPSec后面單獨加VPN的字段。比較而言，從標準化程度來講（1）是最好的，從封裝效率上來講（3）和（4）要好一些，不同廠家的實現中會有不同的選擇。
不過，按運營商現有的接入網絡來看，除IPSec以外，VLAN/QinQ/L2TP/GRE/MPLS VPN甚至是傳輸專線都有是有可能的，這對于SD-WAN Gateway的要求就比較高了。此時，傳統的設備廠商相比于Pure Play的廠商就有明顯的優勢了
經過特定VRF的路由后，這里考慮跨地區的流量，流量要被送到目的站點所接入的SD-WAN Gateway上。根據實際情況，又有不同的方式：（1）如果SD-WAN Gateway間要走GRE/IPSec，就還是用上面剛剛所介紹的方法；（2）如果SD-WAN Gateway間要走MPLS VPN，且SD-WAN Gateway自己具備MPLS VPN的能力，這時可以直接給出向流量標記Service Label；（3）如果SD-WAN Gateway間要走MPLS VPN，但是SD-WAN Gateway并不具備MPLS VPN的能力，那么SD-WAN Gateway就要通過接口/子接口和PE做連接，同時與PE間起IGP多實例，或者BGP/MP-BGP打通路由，然后由PE來完成MPLS VPN的工作，這實際上可以看作是VRF-Lite的方案。
不僅是SD-WAN Gateway，整個系統實際上都需要進行多租戶的改造。對于CPE來說，要接入SD-WAN Gateway，可能需要對特定的封裝提供支持。對于控制器來說，要明確CPE所屬的租戶，以及SD-WAN Gateway上所接入的租戶列表，然后在分發策略和路由的時候，需要能帶著租戶的信息下去。對于Portal來說，則要提供RBAC的能力，對不同賬號的權限進行區分與隔離。多租戶所帶來的細節問題，還有很多很多，無法逐一而述了。
1.3 端到端的控制如何實現？
在Enterprise Oriented的方案中，控制器看待站點間的連接的角度很簡單，兩個設備+雙向的隧道。在SP Oriented的方案中，由于控制器不僅要控制企業側的CPE，還要控制運營商的SD-WAN Gateway，另外SD-WAN Gateway的引入還將路徑切分成了多段，路由的控制上也很為復雜了。這些都對SP Oriented的控制器提出了很大的挑戰，甚至可能需要在集中式和分布式間重新進行決策。
首先，端到端的拓撲就十分的復雜。簡單來想，可能是（SD-WAN CPE—SD-WAN Gateway—SD-WAN CPE）做本地中繼，可能是（SD-WAN CPE—SD-WAN Gateway—SD-WAN Gateway—SD-WAN CPE）做跨地區的隧道拼接，也不排除會做（SD-WAN CPE—N*SD-WAN Gateway—SD-WAN CPE）的POP點組網。如果有Non SD-WAN的設備打隧道接進來，這個設備的控制是不歸控制器來管的，雖然控制的設備少了，但實際上控制器的建模卻變得更加復雜了。如果Non SD-WAN設備接入SD-WAN Gateway，而SD-WAN CPE間不走SD-WAN Gateway直接打隧道，就更加混亂了。和路由目前來看，SP Oriented SD-WAN還沒有一個標準的路由控制邏輯，只能是摸著石頭過河。
在實際的部署中，SD-WAN Gateway不可能會是單點，相比于主備運營商更喜歡負載分擔，那么還要考慮HA下的均衡問題。而且一個地區的POP點會有很多個，如何在POP點間進行流量的優化，也是一個重要的問題。
另外一個現實的問題是，運營商不可能完全OTT接入網和MPLS。Overlay在Internet上做接入，雖然在靈活性上有很大的優勢，便于接入Off-Net的客戶，但是對于本地的On-Net客戶這種方式卻不見得合適。對于一些運營商來說，CPE—BRAS—SD-WAN Gateway—SR/PE的流量模型并不符合路由的規范，而且BRAS、SD-WAN Gateway、SR/PE這三者間的形態關系也是千差萬別，現網部署起來會遇到很多麻煩。所以說對于On-Net的客戶，SD-WAN Gateway接入這一端更習慣于over在專線上。這樣的話還要協同接入網的網管/控制器，如果再考慮與MPLS VPN網管/控制器的協同，整個SP Oriented SD-WAN的編排/控制系統會變得無比復雜。全場景、端到端的編排/控制，目前來看還有相當大的差距。
1.4 公網訪問如何實現？
如果是要做Local DIA，那么分流在分支的CPE本地就完成了，流量模型是Branch CPE—BRAS—Internet。如果是要做Backhaul，是由總部/數據中心的CPE統一分流，流量模型的一種可能是Branch CPE—SD-WAN Gateway—HQ/DC CPE—Internet，另一種可能是直接Branch CPE—HQ/DC CPE—Internet。關于DIA和Backhaul，在Enterprise Oriented SD-WAN部分已經介紹過了，這里就不再贅述。
除了Local DIA和Backhaul以外，SP Oriented還提供了Regional Break Out的方式，流量模型是Branch CPE—SD-WAN Gateway—Internet，由SD-WAN Gateway完成公網和VPN流量的分流，公網流量可能還需要進一步地對國內流量和國際流量進行區分，以提供不同的路由策略。Regional Break Out要求SD-WAN Gateway能夠提供NAT、安全和HQoS的相關能力，同時要求SD-WAN Gateway具有Internet的連通性。對于客戶來說，Regional Break Out的優勢在于，既可以避免Internet流量繞行總部/數據中心，降低了時延與帶寬消耗，又可以通過SD-WAN Gateway為本地的多個分支集中地提供安全、WAAS這些服務，避免了以分支為單位去使用這些服務的成本。對于運營商來說，客戶在本地所有分支的Internet業務可以集中地管理起來，比如對上下行帶寬的統一分配。
至于公網流量如何才能從Branch CPE送到SD-WAN Gateway上，還是要看接入的方式是怎么樣的。如果要Overlay在Internet上，那么控制器就要下發路由把公網流量通過隧道送給SD-WAN Gateway，此時流量模型實際上是Branch CPE—BRAS—SD-WAN Gateway—Internet，在現網中運營商不一定會愿意提供這種連接方式，這取決于運營商如何去看待BRAS和SD-WAN Gateway兩者的關系。如果是over在專線上，路徑上就不會出現BRAS，這時相當于一根線上同時跑了寬帶和VPN兩種業務，需要在計費方式上做好考慮。
2、vCPE
在運營商傳統的POP點中，為了支撐話音、寬帶、專線等不同專業的業務，需要采購大量專用的硬件設備，開放性和靈活性很差。在Cloud/NFV/SDN等新型架構的驅動下，全球各大運營商紛紛投身于POP點云化的重構進程中。POP點云化后，各類專用的硬件設備在形態上將被基于通用x86平臺的VNF所替代，在架構上轉發和控制得以分離解耦，這對于運營商具有巨大的價值。一方面在于開放性、靈活性等方面的提高，長期來看能夠有效地降低成本。另一方面，運營商得以將各種增值服務的VNF以服務的形式提供給客戶，這將是一筆相當可觀的業務增收，也是破局“管道化”困境的有效方式。
在這一大背景下，SD-WAN的架構也得到了新的延伸，以vCPE為核心的解決方案開始占據SP Oriented SD-WAN的主流。這里有必要對vCPE的概念進行一下說明，從字面上來直觀理解的話，vCPE應該是指一個與CPE具有相同功能的VNF，但實際上業界對于vCPE的定義并非如此。由于傳統的CPE是一個泛指的概念，涉及路由、防火墻、WAAS等諸多技術，因此對CPE進行虛擬化的結果，通常并不是一個VNF，而是vRouter、vFW、vWAAS等多個VNF，它們各自完成一部分功能，然后通過服務鏈串接在一起，共同交付vCPE的能力。雖然在某些產品和語境下，vCPE可以指代一個特定的VNF，但是在通用語境下vCPE是指一套完整的解決方案。
至于SD-WAN與vCPE間的關系，從SD-WAN的角度來看：
如果理解起來仍然比較晦澀，那么換作vCPE的角度來看就清楚很多：
可以看到的是，SD-WAN和vCPE并不存在嚴格的包含于被包含的關系。以這篇文章的出發點來說，可暫且把vCPE看作是SP-Oriented SD-WAN中的一種實現形式。下面就來對vCPE進行一個簡單的介紹。
2.1 整體架構
一套完整的vCPE方案的實現需要Cloud、NFV和SDN技術的緊密協同。首先，要有一個x86的平臺來提供虛擬化的能力，可以是在Distributed vCPE中的SD-WAN CPE上，也可以是在Centralized vCPE中的x86資源池中。其次，要有一套虛擬化的中間件+云管平臺，如開源的KVM+OpenStack。然后，需要一套VNFM+NFVO，對VNF進行管理和編排。SDN這塊，云POP點的控制器、SD-WAN的控制器，可能是同一套，也可能是兩套，另外一些方案中還會包括接入網的網管/控制器。Portal就很難說了，完全取決于廠家的實現和運營商的集成。
vCPE是否要做成多租戶的？除了廠家的實現以外，其實還取決于運營商的銷售策略。如果是賣VNF的模式，那么一個實例只就能屬于一個租戶，這時不強制要求多租戶。如果并不直接賣VNF，而是包裝成網絡能力來賣，這時做成多租戶就比較劃算了，不過要考慮好性能、容量、配額和擴縮容的問題。
實際上，vCPE就是POP點云化的一個企業級用例，上述vCPE的架構也就是POP點云化的架構。關于這套大的架構，本身就可以獨立成一篇長文，這里不做深入的展開。
2.2 Distributed vCPE和Centralized vCPE
之前提到過，所有能力都在企業邊緣提供的方式被稱為Distributed vCPE，實際上Enterprise Oriented SD-WAN中的CPE很可能就是Distributed vCPE的一種表現形式，本地集成VNF，然后通過一些引流手段把它們串在一起。與之相對應的是Centralized vCPE，所有能力都位于POP點中，并由運營商以服務的形式來集中提供。那么，哪種方式更好一些呢？
先來看看市場方面的因素。從廠商的角度來看，如果其產品的能力比較全，就會傾向于Distributed的方式，把所有的功能都自己做在盒子里，如果其產品能力上有較大的缺口，那不可避免地就要做第三方集成，傾向性就會稍弱一些。從運營商的角度來看，一般會更傾向于Centralized的方式，一方面有利于運維，另一方面能夠增強自身在企業組網中的地位。從客戶的視角來看，Distributed是買硬件+服務，Centralized只需要買服務，如果Distributed和Centralized的使用體驗一致，從成本來說自然是Centralized更好一些
不過，Centralized并不會完全地壓倒Distributed。一來，目前運營商的POP點云化還處在早期的階段，技術上距離成熟還有相當的一段距離。再者，一些VNF部署在企業邊緣會獲得更好的使用體驗，比如WAAS。Hybrid vCPE在兩者間取了一個平衡，一部分能力在企業邊緣的盒子上，一部分能力在POP點中，由客戶根據實際情況來自行訂購。Hybrid的方式固然靈活，但是VNF的分散性對于運維來說是一個不小的挑戰。
2.3 Centralized vCPE的流量模型
Centralized vCPE的目標是最大程度地簡化企業側的設備，最好是只留下二層的功能，把路由也移到POP點里面去。對于運營商來說，自然希望借此獲得對于企業業務更加完整的控制權，對于一些中小型的客戶來說，這避免了自己去維護路由的工作，實現網絡的即插即用。因此，目前在很多的vCPE應用案例中，都會見到這種二層接入的方式。這時VPN和公網的流量都會發給POP點中的vCPE，vCPE不僅僅是虛擬化了企業側的終端，實際上把BRAS和SR的一部分活兒也都一起給做了。
Centralized vCPE主要包括vRouter、vFW和vWAAS，在實際的部署中會有不同的串接順序。當然，某些廠商也會將不同的能力集成到一個VNF中去實現，比如SD-WAN VNF很可能就是一個集多種能力于一身，這時流量的模型就要簡單很多。這里考慮最常見的串接順序vRouter—vFW下的流量模型，vFW采用路由模式。vRouter對流量的處理主要包括：（1）對流量進行識別；（2）為企業側的接入設備分配IP地址；（3）對流量進行限速；（4）將流量送給vFW。在vFW對流量的處理主要包括：（1）對流量進行識別；（2）對公網流量和VPN流量進行分流；（3）執行安全策略；（4）公網流量送給NAT設備，VPN流量送給PE。
具體來看數據面的轉發。目前NSH的應用還非常少見，這里不做分析。
可以看到的是，由于涉及到運營商的網絡，因此底層的連接變得非常復雜，要針對現網的實際環境來做具體的方案設計。而且，由于拓撲沒有一定固定的形態，因此對控制器的要求也很高，很可能需要做一些定制化的開發。
3. MPLS VPN的優化
從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，這是一個很容易被忽略的問題，特此進行提示。
下一篇： PLC、DCS、FCS三大控
上一篇： 高頻微波高密度互連板
