（續(xù)上文）Enterprise Oriented SD-WAN給企業(yè)帶來的價(jià)值非常明顯，在北美訊速地?fù)屨剂算y行、零售、連鎖等行業(yè)，包括很多世界500強(qiáng)的大型客戶，2015年下半年開始，SD-WAN成為了業(yè)界炙手可熱的新寵。由于SD-WAN對(duì)于上述一系列關(guān)鍵技術(shù)的利用，能夠顯著地提高Internet線路的QoE，這使得Internet線路在某些場(chǎng)景中，得以部分地代替MPLS線路在企業(yè)組網(wǎng)中的作用，因此降低了企業(yè)對(duì)于MPLS的依賴性。

因此，當(dāng)時(shí)業(yè)界談?wù)撟疃嗟脑掝}，就是“SD-WAN能否取代傳統(tǒng)的MPLS VPN？”。MPLS VPN是全球各大運(yùn)營(yíng)商的支撐性業(yè)務(wù)，SD-WAN的突然崛起，迫使著大T們開始思考應(yīng)對(duì)之策。

本文作為下篇將對(duì)“SP Oriented SD-WAN”進(jìn)行介紹。首先，會(huì)介紹廠家給出的SDN-Gateway的方案。其次，將對(duì)運(yùn)營(yíng)商青睞的vCPE方案進(jìn)行介紹。最后，簡(jiǎn)單地聊下MPLS VPN的優(yōu)化問題。

二、SP Oriented SD-WAN

關(guān)于“SD-WAN能否取代傳統(tǒng)的MPLS VPN”，其實(shí)這個(gè)問題的答案很明顯。SD-WAN最大的價(jià)值之一，就是在Hybrid WAN的場(chǎng)景下更有效地去管理與使用WAN線路，幫助企業(yè)提高在WAN這一塊的ROI。因此，SD-WAN的出發(fā)點(diǎn)并不是要對(duì)抗MPLS VPN，因此就談不上要取代MPLS VPN，因?yàn)閮烧卟⒉辉谝粋€(gè)層面上。

無論是從紙面上來看設(shè)計(jì)，還是從實(shí)踐中看效果，SD-WAN確實(shí)實(shí)現(xiàn)了它所承諾的價(jià)值。運(yùn)營(yíng)商也很快地就看清楚了問題的本質(zhì)，盡管SD-WAN客觀上會(huì)降低企業(yè)對(duì)于MPLS VPN的需求，但這是技術(shù)演進(jìn)的自然結(jié)果，另外SD-WAN在靈活性、自動(dòng)化、應(yīng)用感知、上云等方面相比于傳統(tǒng)的技術(shù)方案，也有著不可比擬的優(yōu)勢(shì)。權(quán)衡之下，與其把SD-WAN放到對(duì)立面，倒不如想辦法把其拉到統(tǒng)一的戰(zhàn)線上，作為一個(gè)新的業(yè)務(wù)增長(zhǎng)點(diǎn)。因此，運(yùn)營(yíng)商并沒有排斥SD-WAN，而是對(duì)其表現(xiàn)出了相當(dāng)開放的態(tài)度，這與很多人的設(shè)想是恰恰相反的。

SD-WAN的廠家們心里也很清楚，要做大事情就一定得把生態(tài)搞好，運(yùn)營(yíng)商作為生態(tài)中最關(guān)鍵的環(huán)節(jié)，有必要建立起一個(gè)融洽的合作模式。首先，純Overlay的方案存在著一定的局限性，雖然說是Transport Independent，但是如果Transport的線路質(zhì)量確實(shí)不行，那也是巧婦難為無米之炊，另外對(duì)于跨國企業(yè)來說，如果不用MPLS純走Internet，那么基本上就約等于不能用。其次，運(yùn)營(yíng)商擁有著廣泛的客戶基礎(chǔ)，業(yè)務(wù)的覆蓋范圍更廣，無論在運(yùn)營(yíng)還是運(yùn)維方面都有著巨大的優(yōu)勢(shì)，這正是SD-WAN廠家們最為欠缺的環(huán)節(jié)，一些大型的客戶動(dòng)輒就幾千個(gè)分支，雖然技術(shù)上是ZTP + Cloud Managed，但是從渠道和服務(wù)的角度來說，就完全是另外一回事了。

雙方一拍即合。第一種合作的思路是，運(yùn)營(yíng)商把廠家的方案買下來，然后自己來做渠道和服務(wù)，除了能夠分一部分SD-WAN的利潤(rùn)外，更關(guān)鍵地是可以把各種WAN線路打包到方案中，為企業(yè)提供一站式、差異化的WAN解決方案。如果有足夠?qū)嵙Φ脑?，還可以對(duì)產(chǎn)品進(jìn)行一些定制，把SD-WAN的能力嵌入到自己的業(yè)務(wù)系統(tǒng)當(dāng)中。第一種思路，不需要對(duì)Enterprise Oriented SD-WAN的技術(shù)架構(gòu)進(jìn)行改動(dòng)，同時(shí)有著清晰的盈利模式，對(duì)于廠家來說是零成本，對(duì)于運(yùn)營(yíng)商來說是一種快速進(jìn)入市場(chǎng)的有效手段。

第二種思路，是對(duì)原有方案的架構(gòu)進(jìn)行調(diào)整。最初所設(shè)計(jì)的SD-WAN方案是Enterprise Oriented的，從技術(shù)上來看是找不到運(yùn)營(yíng)商位置的，如果要做一個(gè)SP Oriented的SD-WAN，就需要在方案中引入SP的角色。那么SP Oriented SD-WAN該怎么做呢？

1、SD-WAN Gateway

廠家給出的方案，是在運(yùn)營(yíng)商的POP點(diǎn)里面放SD-WAN Gateway，負(fù)責(zé)終結(jié)企業(yè)側(cè)CPE發(fā)起的隧道，然后轉(zhuǎn)發(fā)到運(yùn)營(yíng)商的IP/MPLS網(wǎng)絡(luò)。在這種方案中，Enterprise SD-WAN中的CPE上所有能力都被保留了，不過端到端的Overlay變成了，兩頭的Last Mile用Overlay而Middle Mile交給運(yùn)營(yíng)商去做，如果運(yùn)營(yíng)商有能力的話就可以把MPLS VPN集成進(jìn)去，如果短期集成不了MPLS VPN，Middle Mile這段用Overlay打過去也不是不可以。

實(shí)際上這是種很不錯(cuò)的思路，各方接受起來都很自然。從客戶的角度來看，不需要去額外地購買的設(shè)備，而且傳統(tǒng)的WAN設(shè)備也可以通過隧道接進(jìn)去了，另外SD-WAN的運(yùn)維也轉(zhuǎn)交給運(yùn)營(yíng)商去做了。從廠家的角度來看，Enterprise Oriented的特色得以被保留，CPE仍然是高價(jià)值的產(chǎn)品，同時(shí)有效地解決了純Overlay的局限性，另外通過SD-WAN Gateway也得以參與到運(yùn)營(yíng)商的組網(wǎng)中。從運(yùn)營(yíng)商的角度來看，SD-WAN Gateway不僅提供了對(duì)接MPLS的入口，另外也提供了更加靈活的接入方式，對(duì)于Last Mile不可達(dá)的Off-Net Customer，走Overlay做接入能夠省去很多的麻煩事兒。

以SD-WAN Gateway為核心的SP Oriented SD-WAN，保留了Enterprise Oriented SD-WAN的所有能力。在此基礎(chǔ)上，主要是提供了對(duì)多租戶的支持，并在控制邏輯方面進(jìn)行了相應(yīng)的加強(qiáng)。

1.1 整體設(shè)計(jì)

對(duì)于運(yùn)營(yíng)商來說，SD-WAN Gateway作為業(yè)務(wù)的接入設(shè)備，在位置上和SR/PE并沒有本質(zhì)上的區(qū)別。對(duì)于Pure Play的SD-WAN廠家來說，他們?cè)赑OP里面并沒有存量的SR/PE，所以就只能推新的設(shè)備進(jìn)去。形態(tài)上就是x86的盒子，相比于Enterprise Oriented SD-WAN方案中的CPE，SD-WAN Gateway作為不同客戶流量的匯聚點(diǎn)，接口的速率和數(shù)量都會(huì)做相應(yīng)的增強(qiáng)，而且由于它要負(fù)責(zé)大量隧道的終結(jié)，因此對(duì)CPU和內(nèi)存的要求高很多，通常會(huì)需要專用的Crypto Accelerator。而對(duì)于傳統(tǒng)的設(shè)備廠商來說，比如Juniper、ALU和華為，他們?cè)赑OP里面有存量的SR/PE，這時(shí)候可以選擇把SD-WAN Gateway以板卡的形式插到SR/PE的機(jī)框上，以避免多引入一個(gè)物理設(shè)備的麻煩。隨著CORD在運(yùn)營(yíng)商中的推進(jìn)，SD-WAN Gateway的形態(tài)開始逐漸向vCPE進(jìn)行靠攏，關(guān)于vCPE等到后面CORD的部分再來做介紹。

控制器。從宏觀的架構(gòu)來看，除了Staging Server、Controller和Analytics以外，可能會(huì)需要AAA來專門做鑒權(quán)。從細(xì)節(jié)來看，由于多租戶需求的出現(xiàn)，以及設(shè)備、拓?fù)鋸?fù)雜度的提高，使得控制器所用的數(shù)據(jù)模型以及業(yè)務(wù)流程都會(huì)發(fā)生一定的變化。從位置來看，On-Premise是不可行的，需要放到運(yùn)營(yíng)商自己的機(jī)房當(dāng)中。通常是在地市級(jí)的核心機(jī)房里面，負(fù)責(zé)控制下屬的各個(gè)接入機(jī)房中的SD-WAN Gateway，以及本地企業(yè)分支的CPE。

Portal也要做相應(yīng)的調(diào)整，而且運(yùn)營(yíng)商很可能要自己來做定制，部署的位置也取決于運(yùn)營(yíng)商站在什么層面上來看待SD-WAN的業(yè)務(wù)，所以這里就不多說了。

1.2 多租戶是怎么實(shí)現(xiàn)的？

企業(yè)側(cè)接入SD-WAN Gateway的流量，需要能夠與VRF進(jìn)行關(guān)聯(lián)。按廠家的意思就是用IPSec直接打進(jìn)來，把接入網(wǎng)這一段OTT掉。在這種方式中，需要能夠?qū)PSec流量關(guān)聯(lián)VRF，大概有下面這幾種辦法：（1）用GREoverIPSec，為GRE口關(guān)聯(lián)VRF；（2）用MPLSoverGREoverIPSec，用MPLS來關(guān)聯(lián)；（3）用VxLANoverIPSec，通過VNI來關(guān)聯(lián)VRF；（4）通過VTI口來關(guān)聯(lián)VRF；（5）用ISAKMP Profile綁定VRF，識(shí)別SPI后直接關(guān)聯(lián)VRF；（6）用私有的IPSec封裝，在IPSec后面單獨(dú)加VPN的字段。比較而言，從標(biāo)準(zhǔn)化程度來講（1）是最好的，從封裝效率上來講（3）和（4）要好一些，不同廠家的實(shí)現(xiàn)中會(huì)有不同的選擇。

不過，按運(yùn)營(yíng)商現(xiàn)有的接入網(wǎng)絡(luò)來看，除IPSec以外，VLAN/QinQ/L2TP/GRE/MPLS VPN甚至是傳輸專線都有是有可能的，這對(duì)于SD-WAN Gateway的要求就比較高了。此時(shí)，傳統(tǒng)的設(shè)備廠商相比于Pure Play的廠商就有明顯的優(yōu)勢(shì)了

經(jīng)過特定VRF的路由后，這里考慮跨地區(qū)的流量，流量要被送到目的站點(diǎn)所接入的SD-WAN Gateway上。根據(jù)實(shí)際情況，又有不同的方式：（1）如果SD-WAN Gateway間要走GRE/IPSec，就還是用上面剛剛所介紹的方法；（2）如果SD-WAN Gateway間要走M(jìn)PLS VPN，且SD-WAN Gateway自己具備MPLS VPN的能力，這時(shí)可以直接給出向流量標(biāo)記Service Label；（3）如果SD-WAN Gateway間要走M(jìn)PLS VPN，但是SD-WAN Gateway并不具備MPLS VPN的能力，那么SD-WAN Gateway就要通過接口/子接口和PE做連接，同時(shí)與PE間起IGP多實(shí)例，或者BGP/MP-BGP打通路由，然后由PE來完成MPLS VPN的工作，這實(shí)際上可以看作是VRF-Lite的方案。

不僅是SD-WAN Gateway，整個(gè)系統(tǒng)實(shí)際上都需要進(jìn)行多租戶的改造。對(duì)于CPE來說，要接入SD-WAN Gateway，可能需要對(duì)特定的封裝提供支持。對(duì)于控制器來說，要明確CPE所屬的租戶，以及SD-WAN Gateway上所接入的租戶列表，然后在分發(fā)策略和路由的時(shí)候，需要能帶著租戶的信息下去。對(duì)于Portal來說，則要提供RBAC的能力，對(duì)不同賬號(hào)的權(quán)限進(jìn)行區(qū)分與隔離。多租戶所帶來的細(xì)節(jié)問題，還有很多很多，無法逐一而述了。

1.3 端到端的控制如何實(shí)現(xiàn)？

在Enterprise Oriented的方案中，控制器看待站點(diǎn)間的連接的角度很簡(jiǎn)單，兩個(gè)設(shè)備+雙向的隧道。在SP Oriented的方案中，由于控制器不僅要控制企業(yè)側(cè)的CPE，還要控制運(yùn)營(yíng)商的SD-WAN Gateway，另外SD-WAN Gateway的引入還將路徑切分成了多段，路由的控制上也很為復(fù)雜了。這些都對(duì)SP Oriented的控制器提出了很大的挑戰(zhàn)，甚至可能需要在集中式和分布式間重新進(jìn)行決策。

首先，端到端的拓?fù)渚褪值膹?fù)雜。簡(jiǎn)單來想，可能是（SD-WAN CPE—SD-WAN Gateway—SD-WAN CPE）做本地中繼，可能是（SD-WAN CPE—SD-WAN Gateway—SD-WAN Gateway—SD-WAN CPE）做跨地區(qū)的隧道拼接，也不排除會(huì)做（SD-WAN CPE—N*SD-WAN Gateway—SD-WAN CPE）的POP點(diǎn)組網(wǎng)。如果有Non SD-WAN的設(shè)備打隧道接進(jìn)來，這個(gè)設(shè)備的控制是不歸控制器來管的，雖然控制的設(shè)備少了，但實(shí)際上控制器的建模卻變得更加復(fù)雜了。如果Non SD-WAN設(shè)備接入SD-WAN Gateway，而SD-WAN CPE間不走SD-WAN Gateway直接打隧道，就更加混亂了。和路由目前來看，SP Oriented SD-WAN還沒有一個(gè)標(biāo)準(zhǔn)的路由控制邏輯，只能是摸著石頭過河。

在實(shí)際的部署中，SD-WAN Gateway不可能會(huì)是單點(diǎn)，相比于主備運(yùn)營(yíng)商更喜歡負(fù)載分擔(dān)，那么還要考慮HA下的均衡問題。而且一個(gè)地區(qū)的POP點(diǎn)會(huì)有很多個(gè)，如何在POP點(diǎn)間進(jìn)行流量的優(yōu)化，也是一個(gè)重要的問題。

另外一個(gè)現(xiàn)實(shí)的問題是，運(yùn)營(yíng)商不可能完全OTT接入網(wǎng)和MPLS。Overlay在Internet上做接入，雖然在靈活性上有很大的優(yōu)勢(shì)，便于接入Off-Net的客戶，但是對(duì)于本地的On-Net客戶這種方式卻不見得合適。對(duì)于一些運(yùn)營(yíng)商來說，CPE—BRAS—SD-WAN Gateway—SR/PE的流量模型并不符合路由的規(guī)范，而且BRAS、SD-WAN Gateway、SR/PE這三者間的形態(tài)關(guān)系也是千差萬別，現(xiàn)網(wǎng)部署起來會(huì)遇到很多麻煩。所以說對(duì)于On-Net的客戶，SD-WAN Gateway接入這一端更習(xí)慣于over在專線上。這樣的話還要協(xié)同接入網(wǎng)的網(wǎng)管/控制器，如果再考慮與MPLS VPN網(wǎng)管/控制器的協(xié)同，整個(gè)SP Oriented SD-WAN的編排/控制系統(tǒng)會(huì)變得無比復(fù)雜。全場(chǎng)景、端到端的編排/控制，目前來看還有相當(dāng)大的差距。

1.4 公網(wǎng)訪問如何實(shí)現(xiàn)？

如果是要做Local DIA，那么分流在分支的CPE本地就完成了，流量模型是Branch CPE—BRAS—Internet。如果是要做Backhaul，是由總部/數(shù)據(jù)中心的CPE統(tǒng)一分流，流量模型的一種可能是Branch CPE—SD-WAN Gateway—HQ/DC CPE—Internet，另一種可能是直接Branch CPE—HQ/DC CPE—Internet。關(guān)于DIA和Backhaul，在Enterprise Oriented SD-WAN部分已經(jīng)介紹過了，這里就不再贅述。

除了Local DIA和Backhaul以外，SP Oriented還提供了Regional Break Out的方式，流量模型是Branch CPE—SD-WAN Gateway—Internet，由SD-WAN Gateway完成公網(wǎng)和VPN流量的分流，公網(wǎng)流量可能還需要進(jìn)一步地對(duì)國內(nèi)流量和國際流量進(jìn)行區(qū)分，以提供不同的路由策略。Regional Break Out要求SD-WAN Gateway能夠提供NAT、安全和HQoS的相關(guān)能力，同時(shí)要求SD-WAN Gateway具有Internet的連通性。對(duì)于客戶來說，Regional Break Out的優(yōu)勢(shì)在于，既可以避免Internet流量繞行總部/數(shù)據(jù)中心，降低了時(shí)延與帶寬消耗，又可以通過SD-WAN Gateway為本地的多個(gè)分支集中地提供安全、WAAS這些服務(wù)，避免了以分支為單位去使用這些服務(wù)的成本。對(duì)于運(yùn)營(yíng)商來說，客戶在本地所有分支的Internet業(yè)務(wù)可以集中地管理起來，比如對(duì)上下行帶寬的統(tǒng)一分配。

至于公網(wǎng)流量如何才能從Branch CPE送到SD-WAN Gateway上，還是要看接入的方式是怎么樣的。如果要Overlay在Internet上，那么控制器就要下發(fā)路由把公網(wǎng)流量通過隧道送給SD-WAN Gateway，此時(shí)流量模型實(shí)際上是Branch CPE—BRAS—SD-WAN Gateway—Internet，在現(xiàn)網(wǎng)中運(yùn)營(yíng)商不一定會(huì)愿意提供這種連接方式，這取決于運(yùn)營(yíng)商如何去看待BRAS和SD-WAN Gateway兩者的關(guān)系。如果是over在專線上，路徑上就不會(huì)出現(xiàn)BRAS，這時(shí)相當(dāng)于一根線上同時(shí)跑了寬帶和VPN兩種業(yè)務(wù)，需要在計(jì)費(fèi)方式上做好考慮。

2、vCPE

在運(yùn)營(yíng)商傳統(tǒng)的POP點(diǎn)中，為了支撐話音、寬帶、專線等不同專業(yè)的業(yè)務(wù)，需要采購大量專用的硬件設(shè)備，開放性和靈活性很差。在Cloud/NFV/SDN等新型架構(gòu)的驅(qū)動(dòng)下，全球各大運(yùn)營(yíng)商紛紛投身于POP點(diǎn)云化的重構(gòu)進(jìn)程中。POP點(diǎn)云化后，各類專用的硬件設(shè)備在形態(tài)上將被基于通用x86平臺(tái)的VNF所替代，在架構(gòu)上轉(zhuǎn)發(fā)和控制得以分離解耦，這對(duì)于運(yùn)營(yíng)商具有巨大的價(jià)值。一方面在于開放性、靈活性等方面的提高，長(zhǎng)期來看能夠有效地降低成本。另一方面，運(yùn)營(yíng)商得以將各種增值服務(wù)的VNF以服務(wù)的形式提供給客戶，這將是一筆相當(dāng)可觀的業(yè)務(wù)增收，也是破局“管道化”困境的有效方式。

在這一大背景下，SD-WAN的架構(gòu)也得到了新的延伸，以vCPE為核心的解決方案開始占據(jù)SP Oriented SD-WAN的主流。這里有必要對(duì)vCPE的概念進(jìn)行一下說明，從字面上來直觀理解的話，vCPE應(yīng)該是指一個(gè)與CPE具有相同功能的VNF，但實(shí)際上業(yè)界對(duì)于vCPE的定義并非如此。由于傳統(tǒng)的CPE是一個(gè)泛指的概念，涉及路由、防火墻、WAAS等諸多技術(shù)，因此對(duì)CPE進(jìn)行虛擬化的結(jié)果，通常并不是一個(gè)VNF，而是vRouter、vFW、vWAAS等多個(gè)VNF，它們各自完成一部分功能，然后通過服務(wù)鏈串接在一起，共同交付vCPE的能力。雖然在某些產(chǎn)品和語境下，vCPE可以指代一個(gè)特定的VNF，但是在通用語境下vCPE是指一套完整的解決方案。

至于SD-WAN與vCPE間的關(guān)系，從SD-WAN的角度來看：

• 如果SD-WAN CPE是基于x86的白盒，而且自身具備單獨(dú)作為vCPE載體的能力，這時(shí)SD-WAN CPE就可以被稱為vCPE，vCPE就是SD-WAN方案中的一個(gè)組件。
• 如果SD-WAN CPE以虛擬機(jī)的形態(tài)存在，那么可以作為vCPE方案中的一類VNF，這時(shí)可以說vCPE是SD-WAN方案中的一種實(shí)現(xiàn)手段。
• 如果在vCPE方案中，只提供vRouter、vFW等傳統(tǒng)的VNF，并不提供SD-WAN VNF，那么vCPE和SD-WAN兩者并無直接的聯(lián)系。

如果理解起來仍然比較晦澀，那么換作vCPE的角度來看就清楚很多：

• 如果所有的能力都在企業(yè)邊緣提供，稱為Distributed vCPE，無論企業(yè)邊緣的設(shè)備是不是SD WAN CPE。
• 如果所有的能力都在POP點(diǎn)提供，稱為Centralized vCPE，無論提不提供SD-WAN VNF。
• 如果一部分能力在企業(yè)邊緣提供，一部分能力在POP點(diǎn)提供，稱為Hybrid vCPE，無論是否存在SD WAN CPE或者SD-WAN VNF。

可以看到的是，SD-WAN和vCPE并不存在嚴(yán)格的包含于被包含的關(guān)系。以這篇文章的出發(fā)點(diǎn)來說，可暫且把vCPE看作是SP-Oriented SD-WAN中的一種實(shí)現(xiàn)形式。下面就來對(duì)vCPE進(jìn)行一個(gè)簡(jiǎn)單的介紹。

2.1 整體架構(gòu)

一套完整的vCPE方案的實(shí)現(xiàn)需要Cloud、NFV和SDN技術(shù)的緊密協(xié)同。首先，要有一個(gè)x86的平臺(tái)來提供虛擬化的能力，可以是在Distributed vCPE中的SD-WAN CPE上，也可以是在Centralized vCPE中的x86資源池中。其次，要有一套虛擬化的中間件+云管平臺(tái)，如開源的KVM+OpenStack。然后，需要一套VNFM+NFVO，對(duì)VNF進(jìn)行管理和編排。SDN這塊，云POP點(diǎn)的控制器、SD-WAN的控制器，可能是同一套，也可能是兩套，另外一些方案中還會(huì)包括接入網(wǎng)的網(wǎng)管/控制器。Portal就很難說了，完全取決于廠家的實(shí)現(xiàn)和運(yùn)營(yíng)商的集成。

vCPE是否要做成多租戶的？除了廠家的實(shí)現(xiàn)以外，其實(shí)還取決于運(yùn)營(yíng)商的銷售策略。如果是賣VNF的模式，那么一個(gè)實(shí)例只就能屬于一個(gè)租戶，這時(shí)不強(qiáng)制要求多租戶。如果并不直接賣VNF，而是包裝成網(wǎng)絡(luò)能力來賣，這時(shí)做成多租戶就比較劃算了，不過要考慮好性能、容量、配額和擴(kuò)縮容的問題。

實(shí)際上，vCPE就是POP點(diǎn)云化的一個(gè)企業(yè)級(jí)用例，上述vCPE的架構(gòu)也就是POP點(diǎn)云化的架構(gòu)。關(guān)于這套大的架構(gòu)，本身就可以獨(dú)立成一篇長(zhǎng)文，這里不做深入的展開。

2.2 Distributed vCPE和Centralized vCPE

之前提到過，所有能力都在企業(yè)邊緣提供的方式被稱為Distributed vCPE，實(shí)際上Enterprise Oriented SD-WAN中的CPE很可能就是Distributed vCPE的一種表現(xiàn)形式，本地集成VNF，然后通過一些引流手段把它們串在一起。與之相對(duì)應(yīng)的是Centralized vCPE，所有能力都位于POP點(diǎn)中，并由運(yùn)營(yíng)商以服務(wù)的形式來集中提供。那么，哪種方式更好一些呢？

先來看看市場(chǎng)方面的因素。從廠商的角度來看，如果其產(chǎn)品的能力比較全，就會(huì)傾向于Distributed的方式，把所有的功能都自己做在盒子里，如果其產(chǎn)品能力上有較大的缺口，那不可避免地就要做第三方集成，傾向性就會(huì)稍弱一些。從運(yùn)營(yíng)商的角度來看，一般會(huì)更傾向于Centralized的方式，一方面有利于運(yùn)維，另一方面能夠增強(qiáng)自身在企業(yè)組網(wǎng)中的地位。從客戶的視角來看，Distributed是買硬件+服務(wù)，Centralized只需要買服務(wù)，如果Distributed和Centralized的使用體驗(yàn)一致，從成本來說自然是Centralized更好一些

不過，Centralized并不會(huì)完全地壓倒Distributed。一來，目前運(yùn)營(yíng)商的POP點(diǎn)云化還處在早期的階段，技術(shù)上距離成熟還有相當(dāng)?shù)囊欢尉嚯x。再者，一些VNF部署在企業(yè)邊緣會(huì)獲得更好的使用體驗(yàn)，比如WAAS。Hybrid vCPE在兩者間取了一個(gè)平衡，一部分能力在企業(yè)邊緣的盒子上，一部分能力在POP點(diǎn)中，由客戶根據(jù)實(shí)際情況來自行訂購。Hybrid的方式固然靈活，但是VNF的分散性對(duì)于運(yùn)維來說是一個(gè)不小的挑戰(zhàn)。

2.3 Centralized vCPE的流量模型

Centralized vCPE的目標(biāo)是最大程度地簡(jiǎn)化企業(yè)側(cè)的設(shè)備，最好是只留下二層的功能，把路由也移到POP點(diǎn)里面去。對(duì)于運(yùn)營(yíng)商來說，自然希望借此獲得對(duì)于企業(yè)業(yè)務(wù)更加完整的控制權(quán)，對(duì)于一些中小型的客戶來說，這避免了自己去維護(hù)路由的工作，實(shí)現(xiàn)網(wǎng)絡(luò)的即插即用。因此，目前在很多的vCPE應(yīng)用案例中，都會(huì)見到這種二層接入的方式。這時(shí)VPN和公網(wǎng)的流量都會(huì)發(fā)給POP點(diǎn)中的vCPE，vCPE不僅僅是虛擬化了企業(yè)側(cè)的終端，實(shí)際上把BRAS和SR的一部分活兒也都一起給做了。

Centralized vCPE主要包括vRouter、vFW和vWAAS，在實(shí)際的部署中會(huì)有不同的串接順序。當(dāng)然，某些廠商也會(huì)將不同的能力集成到一個(gè)VNF中去實(shí)現(xiàn)，比如SD-WAN VNF很可能就是一個(gè)集多種能力于一身，這時(shí)流量的模型就要簡(jiǎn)單很多。這里考慮最常見的串接順序vRouter—vFW下的流量模型，vFW采用路由模式。vRouter對(duì)流量的處理主要包括：（1）對(duì)流量進(jìn)行識(shí)別；（2）為企業(yè)側(cè)的接入設(shè)備分配IP地址；（3）對(duì)流量進(jìn)行限速；（4）將流量送給vFW。在vFW對(duì)流量的處理主要包括：（1）對(duì)流量進(jìn)行識(shí)別；（2）對(duì)公網(wǎng)流量和VPN流量進(jìn)行分流；（3）執(zhí)行安全策略；（4）公網(wǎng)流量送給NAT設(shè)備，VPN流量送給PE。

具體來看數(shù)據(jù)面的轉(zhuǎn)發(fā)。目前NSH的應(yīng)用還非常少見，這里不做分析。

• 客戶接入vRouter這一段?？赡艿耐?fù)溆泻芏?，（L2 Switch—POP GW—vSwitch—vRouter）、（L2 Switch—POP GW—vRouter）、（L2 Switch—vSwitch—vRouter）、（L2 Switch—POP GW—vSwitch—vRouter）。由于要接入二層，因此可以選擇VLAN/QinQ或者VxLAN，考慮到與物理拓?fù)浣怦钭遃xLAN會(huì)稍好一些，一些節(jié)點(diǎn)上會(huì)需要做轉(zhuǎn)換/拼接。
• vRouter到vFW這一段。如果在同一個(gè)節(jié)點(diǎn)上，拓?fù)涫牵╲Router—vSwitch—vFW），直接VLAN不用走隧道。如果不在一個(gè)節(jié)點(diǎn)上，拓?fù)渚褪牵╲Router—vSwitch—vSwitch—vFW），vSwitch間走VxLAN就行。少數(shù)情況下，拓?fù)鋾?huì)是（vRouter—vFW），可以選擇MPLSoverGRE，如果不支持MPLS可以用VRF Aware GRE。
• vFW到NAT/PE這一段。由于NAT/PE通常是物理設(shè)備，因此拓?fù)渥詈弥苯泳褪牵╲FW-NAT/PE），可以選擇MPLSoverGRE，如果不支持MPLS可以用VRF Aware GRE。一些POP點(diǎn)中還會(huì)引入vNAT/vPE，這時(shí)就可以（vFW—vSwitch—vSwitch—vNAT/vPE）了。

可以看到的是，由于涉及到運(yùn)營(yíng)商的網(wǎng)絡(luò)，因此底層的連接變得非常復(fù)雜，要針對(duì)現(xiàn)網(wǎng)的實(shí)際環(huán)境來做具體的方案設(shè)計(jì)。而且，由于拓?fù)錄]有一定固定的形態(tài)，因此對(duì)控制器的要求也很高，很可能需要做一些定制化的開發(fā)。

3. MPLS VPN的優(yōu)化

從SD-WAN廠家的角度來看，只要把流量做好標(biāo)記送給PE上就行了，PE間的打通并不屬于SD-WAN要考慮的問題。不過對(duì)于運(yùn)營(yíng)商來說，MPLS VPN是企業(yè)廣域網(wǎng)業(yè)務(wù)的基礎(chǔ)，也是能夠體現(xiàn)服務(wù)差異化的最關(guān)鍵環(huán)節(jié)。因此，運(yùn)營(yíng)商在設(shè)計(jì)SD-WAN業(yè)務(wù)的時(shí)候，一定會(huì)帶上MPLS VPN一起做考慮。不過，傳統(tǒng)的MPLS VPN所存在的一些局限性，使得它在與SD-WAN進(jìn)行集成時(shí)顯得很不協(xié)調(diào)。首先，開通周期太長(zhǎng)，交付速度遠(yuǎn)遠(yuǎn)跟不上業(yè)務(wù)的需求。其次，帶寬難以按需調(diào)整，客戶只能按照峰值帶寬的水平進(jìn)行超買。另外，無法與云進(jìn)行聯(lián)動(dòng)，企業(yè)入云的流量難以納入到服務(wù)體系中。

快速開通的問題，并非單純地引入SDN控制器對(duì)兩端PE/ASBR做自動(dòng)化配置那么簡(jiǎn)單。在運(yùn)營(yíng)商的傳統(tǒng)體系下開通一個(gè)MPLS VPN，周期保守估計(jì)在45-90天，從開始填寫訂單到最后完成交付，其間要流轉(zhuǎn)數(shù)十個(gè)步驟，其中向設(shè)備下發(fā)配置這個(gè)環(huán)節(jié)已經(jīng)是由MPLS VPN網(wǎng)管一類的角色自動(dòng)完成的，換上SDN控制器來配也沒有任何本質(zhì)的區(qū)別。真正的問題在于，傳統(tǒng)的BOSS系統(tǒng)太過于臃腫，為保證系統(tǒng)的穩(wěn)定運(yùn)轉(zhuǎn)，不僅流程復(fù)雜繁瑣，而且很多步驟需要人工介入。因此破題的關(guān)鍵在于，運(yùn)營(yíng)商要對(duì)BOSS的架構(gòu)和業(yè)務(wù)流程進(jìn)行精簡(jiǎn)，否則任何網(wǎng)絡(luò)層面的改進(jìn)都是杯水車薪。

帶寬按需調(diào)整，在BOSS層面也面臨著同樣的現(xiàn)實(shí)問題。單純從網(wǎng)絡(luò)的層面來講，調(diào)帶寬的方法要看MPLS VPN的QoS模型，如果是Diff-Serv的就是在PE上做限速和Mark，如果是Int-Serv恐怕就要去搞RSVP了。想法是好的，但在現(xiàn)實(shí)中運(yùn)營(yíng)商可能會(huì)遇到一些頭疼的問題。首先，是調(diào)帶寬這個(gè)動(dòng)作極容易使網(wǎng)絡(luò)變得不穩(wěn)定，一旦客戶調(diào)的時(shí)候影響了別人，很難去界定責(zé)任。其次，按需的粒度很難掌握，細(xì)了的話太影響收入，粗了很多時(shí)候?qū)蛻艟褪ノα?。另外，按需服?wù)的模式對(duì)計(jì)費(fèi)系統(tǒng)沖擊太大，風(fēng)險(xiǎn)性需要進(jìn)行謹(jǐn)慎的評(píng)估。

與云的聯(lián)動(dòng)不足，需要運(yùn)營(yíng)商與云提供商雙方來共同解決。云機(jī)房通常會(huì)建設(shè)在城域網(wǎng)核心或者骨干網(wǎng)這一層面，通過DC Edge來接入運(yùn)營(yíng)商的Internet。隨著云計(jì)算的逐步成熟，一些高價(jià)值的企業(yè)流量開始流向云端，然而Internet卻難以為這部分流量提供足夠的連接質(zhì)量，引入MPLS VPN來解決這一問題是很自然的需求。對(duì)于運(yùn)營(yíng)商而言，如果不是市場(chǎng)策略上有什么額外的考慮，單純從技術(shù)上來講事情是很簡(jiǎn)單的，DC Edge就是CE，只要搞定它與PE間的接入和路由就可以了。

接入上沒什么說的，裸纖/專線/VPN都可以，對(duì)于幾個(gè)大的公有云，甚至可以直接把PE搬到DC Edge的機(jī)房去做直連，通過物理接口或者子接口來隔離租戶。如果由于一些現(xiàn)實(shí)的因素，運(yùn)營(yíng)商和公有云間做接入存在困難，還可以通過第三方的IXP/CXP來進(jìn)行中繼。

路由這一塊，由于要跨域一般就是靜態(tài)路由或者BGP，如果是用靜態(tài)路由，就是由控制器把路由配到DC Edge和PE上，如果是用BGP，那就需要控制器去配好Peering和Policy。從分工界面來看，DC Edge和云內(nèi)部的網(wǎng)絡(luò)由公有云提供商來負(fù)責(zé)，PE和企業(yè)側(cè)的接入由運(yùn)營(yíng)商來負(fù)責(zé)，雙方的控制器各自封裝好API提供出來，上面的Portal或者編排器拆單后直接調(diào)用就可以了。對(duì)于IaaS流量來說，企業(yè)側(cè)和云側(cè)的網(wǎng)絡(luò)在同一地址空間內(nèi)，路由直接拉通就行了，但是對(duì)于SaaS流量來說，云一側(cè)是公網(wǎng)的IP地址，因此路由是沒法直接通的。因此，對(duì)于企業(yè)側(cè)訪問SaaS的流量，運(yùn)營(yíng)商還需要在PE送到DC Edge前做NAT，這是一個(gè)很容易被忽略的問題，特此進(jìn)行提示。