SDN和NFV網絡部署分析

陳 冰 南福星 楊紹光 王 翔

1 中國聯合網絡通信有限公司 北京 100033

2 中國聯通研究院 北京 100032

引言

SDN[1]和NFV[2]是近些年來網絡發展較為熱門的技術。經過幾年的發展，SDN和NFV對網絡變革產生的價值得到了清晰認識和廣泛共識，這兩項技術逐漸邁過炒作階段，進入規模化部署階段：SDN部署的急先鋒Google已基本完成其數據中心網絡的SDN改造，在開放網絡峰會上并沒有進一步展示其關于SDN的新應用場景；公有云巨頭微軟和阿里巴巴則分享了他們關于SDN在云服務上的實戰經驗；而電信運營商AT&T也宣布繼續推進其網絡向SDN轉型的Domain 2.0計劃[3]，基于SDN的“Network on Demand”解決方案衍生的“Switched Ethernet”服務已在全美100多個城市得到部署。

從宏觀上說，SDN最重要的價值就是將網絡從上到下自動化打通，并且提供近乎實時的按需網絡路徑調整能力，大大提升自動化能力，提升網絡能力提供的效率。NFV則提供了基于通用服務器標準硬件的標準運行環境，使網絡業務基于此標準運行環境進行開發和集成，將軟硬件緊耦合系統工程轉化為軟件系統工程，大大縮短業務上市時間，提升業務部署效率。如同智能手機取代功能機一樣，SDN和NFV所產生的效率提升是明確的，必將是未來建設網絡的核心技術。

在具體部署過程中，SDN和NFV技術高度互補，但并不相互依賴。NFV可以不基于SDN技術進行實現，然而兩者相融合則可能產生更大的潛在價值。利用數據中心現有的技術，NFV的目標可以基于非SDN的機制而實現。SDN所提出的控制平面和數據平面解耦的思路，可以進一步提升現有部署服務的性能并簡化其互操作性，減輕運維負擔。NFV能夠為SDN軟件提供其運行所需要的基礎設施。此外，NFV與SDN的目標都是盡可能使用通用/白牌服務器/交換機來實現功能，圖1展示了SDN與NFV在網絡服務上協作互補的關系。SDN只有擁抱NFV，才能完善自己。沒有NFV，SDN停留在網絡拓撲和控制決策層面，沒有靈活的資源可供調度，網絡高層功能的實現會成為絆腳石；沒有SDN，NFV停留在軟件化和虛擬化層面，無法靈活地按需提供服務。只有兩者相結合，NFV的功能才能更加豐富，SDN的控制功能才更顯強大，網絡才能真正“活”了，也才可能變得更有智慧，最終使網絡成為服務。

圖1 SDN與NFV的關系

1 SDN/NFV在數據中心的部署

考慮技術的成熟性、網絡的平滑演進，SDN和NFV的部署需要一個循序漸進的過程。SDN和NFV涉及的范圍非常廣泛，先期的部署需要找到一些突破口。局部的、新興的、層疊的網絡是最容易實施的地方。結合云網絡多租戶需求，DC的虛擬化，VDC成為SDN和NFV實踐的第一個理想的實驗場景。不同于傳統數據中心，云計算以“租用”的方式改變了數據中心內IT資源的交付手段。租戶對資源“按需申請”和“按使用付費”，使得部署在云數據中心網絡中的計算、存儲和網絡資源處于持續改變的狀態。圖2展示了單個租戶所看到的VDC業務部署的拓撲。由于租戶之間是相互隔離的，因此，其它租戶的網絡業務在該圖中并不可見。每個租戶能夠獨立請求一個或多個虛擬的L2網絡，并在此基礎上構建一個L3網絡；不同租戶在其L2和L3網絡中可以共享使用所有可用的地址空間。所有L3網絡的子網可以通過一個服務網關互聯，而該網關同時也是租戶云端網絡接入Internet的網關；租戶可以在該網關上部署子網間以及Internet接入的網絡安全或服務質量策略。這些網絡元素都是經過虛擬化之后與物理網絡元素相分離的，能夠根據租戶的需求按需啟動和部署。

圖2 VDC租戶網絡拓撲

VDC里面，Overlay方式的虛擬網絡又是被最先選擇的方式[4]，因為Overlay方式最容易實現實際部署。用于數據中心網絡虛擬化封裝的協議主要有三個，即VXLAN，NVGRE和STT。它們在設計上的相同之處就是將虛擬網絡由全局唯一的ID進行標識，并打標進數據平面網包的封裝格式中；這三者僅在封裝格式和少部分實現細節上有所區別。當前開源OpenStack已成為云網絡事實管理系統，VDC內部SDN控制器通過Openflow流表模型，對上為OpenStack提供網絡服務，對下對OVS和Overlay網關進行管理，構成VDC內完整解決方案，支持多租戶的云應用，也支持NFV業務功能虛擬化，形成一套基礎環境。圖3展示了經過VXLAN封裝的數據包流經網絡路徑時的變化。從圖3可以看出，不同的虛擬網絡在VXLAN協議中是通過VNID來進行標識，由UDP協議進行封裝的。虛擬機發出的原始網包為標準的以太網格式，在VTEP(軟件交換機或機架頂交換機)進行VXLAN封裝。封裝之后網包的L2和L3層地址分別為源和目的VTEP的地址，而原始網包作為UDP的載荷被封裝進行傳輸。

圖3 基于VXLAN的網絡虛擬化封裝

目前，主要運營商都在進行類似方案的試點，這將逐步形成云應用的模式和業務功能虛擬化的模式，對未來有較深遠的影響。但這只是起點，在此基礎上，云應用將得到很好的支撐，同時，NFV虛擬化使得安全、智能的工作比以前或得到更好的實現，各類安全組件以軟件模塊形式存在，各類智能應用以軟件模塊形成編寫調整，通過很好的集成工作可以快速定義、上線和提供業務，并且能夠支持業務快速地迭代升級。在提供很好業務的同時，SDN基礎設施能力也將逐步演進，從Overlay模式開始逐步硬化轉發能力，最終螺旋式演變回具有更高性能支持的Underlay原生模式，但是功能將更加豐富，并覆蓋原來Overlay定義時所增加的各類功能。

2 SDN/NFV在廣域網的部署

對于城域網、骨干網等廣域網絡，由于牽涉地域廣泛，管理域復雜，實際操作起來難度要大很多。城域網、骨干網以提供連接為主，因此，牽涉到的主要是SDN的工作。在廣域網場景，SDN強調更多的是面向連接的演進，在數據模型上會面向連接，而有可能并不實現流表。在南向協議上，除了Open fl ow細顆粒度接口以外，也會選擇BGP-LS、PCEP、NETCONF等粗顆粒接口，這些粗顆粒接口有時在廣域網上效率可能更高，使得實際操作性能得到保障。在廣域網上，端到端地對某一連接屬性進行控制有一定的應用價值，具體地來說，比如VPN連接、優化的流量路徑[5]。

為實現對大網管理，廣域網的SDN控制器需要分層[6]，最基本的層次是廠家單域控制器，其上是通用單域控制器，再其上是層次化多域控制器。為避免廠商綁定，需要在單域控制器以上定義通用接口。在產業鏈還沒有足夠成熟的時候，往往需要運營商和供應商共同協商制定通用接口。基于這樣的通用接口，要進行開發和對接測試，測試通過后要進行跨域的試點，然后在小規模范圍內試用。實際試點操作時，會遇到既不支持也難以升級到SDN的傳統網絡，這時需要使用Overlay技術，使SDN穿越這些傳統網絡，實現需要的端到端業務功能。廣域網的規模很大，這樣的試點需要做好全局協同，或者就定位為小范圍的試驗網。

在廣域網上，即便單域和多域控制器組合得很好，離應用和部署還有很大的距離。最關鍵的距離就是如何將OSS/BSS系統以演進的方式與SDN控制器連接起來，中間需要一個編排層[7]，編排層進行語言的轉化，把業務需求轉化為SDN控制器認識的網絡需求，同時，對虛擬化網元進行生命周期管理。編排層對一個大的運營商來說非常重要，它很好地解釋了業務對網絡的需求，并很好地進行虛擬網元和SDN連接的串聯，使得智能化的業務能很好地實現。行業的一些開源工具如TOSCA，一些思維方式，如NETCONF/YANG方法值得在應用時考慮。

由于廣域網的SDN化是一個巨大的系統工程，大型的運營商需要啟用從上向下的設計，從OSS/BSS為起點，向下將編排器、層次化多域控制器、單域控制器、廠商單域控制器、廠商設備串起來，打通之后才能對端到端業務部署提供積極的作用。運營商和設備廠商需要通力合作，才有可能把系統定義和部署好。另外，即便在模型定義得很完善之后，實踐仍是第一位的，需要在小規模試點應用中積累經驗，逐步將網絡應用規模擴大。對于中間無法進行SDN協同的傳統網絡，積極采用Overlay或打隧道方式穿越，不必等萬事具備，才開展相關工作。只有SDN的網絡規模不斷壯大，最終才可能實現全網的SDN化。

在廣域網SDN試點和建設過程中，為VDC服務始終是重點需求之一，因為VDC發展迅速，VDC之間互聯對廣域網有一定的需求，廣域網SDN在解決VDC互聯過程中，也實現自身支持功能的完善，從而實現更好地發展。在廣域網SDN發展過程中，面向連接是最基本的需求，此后，針對不同的需求，還會出現其他的軟件定義，如SDN SFC[8]的支持，將為NFV提供必要的更好的連接支持[9]。

下面針對SDN在廣域網上的部署應用，分別選取了AT&T和Google作為運營商和互聯網企業的代表，分析它們在SDN應用上所做的工作和取得的成果。

圖4 隨選以太網服務部署模式

圖5 NetBond VPN服務部署模式

國際領先的運營商AT&T基于SDN技術推出隨選網絡(Network on Demand)業務[10]，通過在線自助服務門戶將網絡服務交付給商業客戶，客戶可以通過該門戶實時地訂購、添加和更改自己的網絡服務等級和擴展帶寬等，從而靈活實現服務變更，更好地適配業務并優化成本。其中，以太網服務允許用戶連接兩個或多個獨立的以太網，形成一個單獨的網絡，帶寬支持達1～10Gbs。圖4展示了隨選以太網服務的兩種部署模式，即“單點-多點”和“多點-多點”兩種常見的企業網絡架構。此外，NetBond VPN服務面向企業客戶提供MPLS VPN與各數據中心之間持續、安全的互聯，使得網絡和計算資源可以彈性串聯，以支持系統的波動需求。圖5展示了隨選VPN服務的部署模式。

在流量路徑優化的應用上，做的最出名也最有特色的是Google的B4。由于SDN能夠實時監控并動態調整網絡帶寬和路徑，傳統通過靜態帶寬預留方式保證服務質量的做法顯得極其低效和僵化。Google廣域網的出口設備有上百條對外鏈路，分成很多的ECMP負載均衡組，在這些均衡組內的多條鏈路之間用的是基于靜態Hash的負載均衡方式。由于靜態Hash的方式并不能做到完全均衡，為避免很大的流量被分發到同一個鏈路上導致丟包，Google不得不使用過量鏈路，提供比實際需要多得多的帶寬。這導致實際鏈路帶寬利用率只有30%～40%，且仍不可避免有的鏈路很空，有的鏈路產生擁塞，設備必須支持很大的包緩存，成本太高，而且也無法對上文中不同的數據區別對待。從一個數據中心到另外一個數據中心，中間可以經過不同的數據中心，比如可以是 A→B→D，也可以是A→C→D，也許有的時候B很忙，C很空，路徑不是最優。除此之外，增加網絡可見性、穩定性，簡化管理，希望靠應用程序來控制網絡，都是其網絡改造的動機之一。以上原因也決定了Google這個基于SDN的網絡，最主要的應用是流量工程，最主要的控制手段是軟件應用程序。圖6展示了Google B4網絡的整體架構。

圖6 Google B4網絡的整體架構

3 總結

總結起來，SDN和NFV是網絡發展明確趨勢；數據中心網絡以VDC和虛擬化為核心，OpenStack、SDN和NFV技術迅速得到應用，形成未來業務系統基礎；廣域網絡復雜度很高，不僅需要多層控制器協同，還需要OSS/BSS與編排器和控制器的協同，大型運營商需要實施自上而下的設計，并推動局部試點，以逐步形成規模應用。在SDN和NFV的部署過程中，兩者需要緊密配合協同工作，才能產生良好的性能與效益提升。但是SDN與NFV架構的核心——控制器的發展仍不明朗，分別代表運營商和設備廠商的ONOS和OpenDaylight仍然在爭奪主導地位；各廠商對SDN的支持程度也有差異，實現協同操作還有一定難度；NFV設備相比SDN設備，其標準更加難以建立，其實現方式也更加碎片化；同時，SDN和NFV的集中控制方式及開放性將使得網絡架構的安全性成為潛在風險，這些都將是未來SDN和NFV發展中需要研究和解決的問題。

參考文獻

[1] Software-Defined Networking:The New Norm for Networks[EB/OL].[2016-01-08].https://www.opennetworking org/images/stories/downloads/sdnresources/white-papers/wp-sdn-newnorm.pdf

[2] Network Functions Virtualisation[EB/OL].[2016-01-08].https://portal.etsi.org/nfv/nfv_white_paper.pdf

[3] Domain 2.0 White Paper[EB/OL].[2016-01-08].https://www.att.com/Common/about_us/pdf/AT&T%20 Domain%202.0%20Vision%20White%20Paper.pdf

[4] Koponen T,Amidon K,Balland P,et al.Network Virtualization in Multi-tenant Datacenters[EB/OL].[2016-01-08].http://www.docin.com/p-1476505232.html

[5] Jain S,Kumar A,Mandal A,et al.B4:experience with a globally-deployed software defined wan[EB/OL].[2016-01-08].http://www.medsci.cn/sci/show_paper.asp?id=9e6d4390449

[6] S Hassas Y,Ganjali Y. Kandoo:a framework for ef fi cient and scalable offloading of control applications[EB/OL].[2016-01-08].http://conferences.sigcomm.org/sigcomm/2012/paper/hotsdn/p19.pdf

[7] Berde P,Gerola M,Hart J,et al.ONOS:towards an open,distributed SDN OS[EB/OL].[2016-01-08].http://www-csstudents.stanford.edu/～rlantz/papers/onos-hotsdn.pdf

[8] Service Function Chaining[EB/OL].[2016-01-08]. https://datatracker.ietf.org/wg/sfc/documents/

[9] Qazi Z A,Tu C C,Chiang L,et al.SIMPLE-fying middlebox policy enforcement using SDN[EB/OL].[2016-01-08].http://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p27.pdf

[10] AT&T Network on Demand[EB/OL].[2016-01-08].http://about.att.com/innovation/showcase/networkondemand