SDN/NFV關鍵技術問題分析和標準化進展

馬軍鋒

摘要：著重分析SDN/NFV技術在商用部署中面臨的關鍵技術問題，包括開放接口標準化和互操作，通用硬件和控制器的性能，與現網系統的協同、安全以及集成部署等問題，并梳理國際標準組織和開源項目在SDN/NFV技術領域的進展情況。認為SDN/NFV的部署應是一個漸進式的過程，傳統網絡與SDN/NFV網絡將會長期共存。業界需要盡快統一架構、接口和協議標準，推動不同廠商功能組件的系統集成，從而最終實現網絡即服務。

關鍵詞： SDN/NFV ；控制器；虛擬化

當前，傳統網絡的演進發展正面臨越來越多的挑戰，既要面對OTT競爭，承受降低日目前投資成本（CAPEX）/運營成本（OPEX）的壓力，提升網絡差異化服務的能力，又要滿足消費者體驗需求的互聯網化，與其他行業跨界融合及構建全連接網絡的訴求，網絡架構重構已成為網絡可持續發展的必然要求。中國三大運營商相繼發布網絡轉型戰略（電信CTNET 2025、移動NovoNet 2020愿景、聯通CUBE-NET 2.0），期望通過使用軟件定義網絡（SDN）/網絡功能虛擬化（NFV）、云計算、網絡虛擬化等新技術來構建一張“資源可全局調度，能力可全面開放，容量可彈性伸縮，架構可靈活調整”的新一代網絡，更好地適應從“消費型互聯網”向“產業互聯網”的網絡轉型，支撐國家“互聯網+”發展戰略。而在這場技術變革中，SDN/NFV是被業界普遍看好的促進現網升級演進，未來網絡技術創新的重要技術，其所倡導的控制轉發分離、網絡能力接口的開放、軟硬件解耦以及網絡功能的虛擬化，將會促進產業重心由硬向軟快速調整，推動網絡架構向軟件化、集約化、智能化和開放化的目標網絡架構演進。但是，現階段SDN/NFV的技術遠未成熟，現網演進策略尚不清晰，一些關鍵技術問題還有待產業界協作解決。

1 SDN/NFV關鍵技術問題

技術可以創新，但網絡發展必須是演進的，新技術的應用必須要充分考慮現網的平滑演進，這是網絡發展的一般規律。當前，運營商存量網絡規模大且設備極度復雜，部署SDN/NFV技術將是一項浩大的系統工程，多數運營商對如何實現現網到SDN/NFV的平滑演進，如何解決多廠商的兼容性、互聯互通和集成部署等問題尚存疑慮，很難真正推動商用化規模部署。正如SDN/NFV產業聯盟理事長韋樂平先生的判斷：“SDN/NFV整體處在現場試驗、試商用和早期商用階段，即整體剛從過度期望進入幻滅到成熟期，估計1～4年陸續進入發展期，4～8年陸續進入穩定發展期”。因此，在一些關鍵技術問題上，如果產業界沒有達成共識并形成統一標準，SDN/NFV很難實現商用化規模部署。

（1）開放接口的標準化和互操作問題

SDN/NFV打破了原有封閉的網絡架構，實現控制轉發分離，軟硬件解耦，以及向上層業務開放網絡能力。為此，在SDN架構下，引入了新的接口，這些接口的標準化對實現開放網絡架構至關重要，也是實現多廠商方案高效集成，擺脫廠商鎖定的先決條件。

南向接口（SBI）是控制器與轉發設備之間下發流表的通信接口，目前呈現多樣化發展態勢（業界定義了超過15種的通信協議），這增加了廠商解決方案和運維部署的復雜度，也給不同廠商解決方案的互通帶來更大的挑戰。SBI最終能否統一成少數幾種協議（如OpenFlow或NETCONF/YANG），應是業界需要亟待解決的一個問題。

北向接口（NBI）是直接為業務應用服務的，其設計與業務應用的需求密切相關，具有多樣化的特征。目前市場上已經出現了20余種不同的控制器，盡管每種控制器都宣稱遵循RESTful的接口標準，但是對外提供的接口都不完全相同，充分說明NBI標準尚未統一。

東西向接口主要解決控制平面的擴展性問題，實現“組大網”。同時還要考慮與非SDN網絡控制平面的互通。目前，關于SDN東西向接口的研究剛剛起步，業界還存在著比較大的爭議。

上述問題帶來一個直接的影響，就是跨廠商的控制器與轉發設備，以及與上層業務之間不能實現完全解耦，需要逐一適配，增加了互操作的成本。

（2）性能問題

性能是運營商網絡的關鍵指標之一。數據面的轉發性能（如吞吐量、時延）直接影響到用戶業務體驗；控制面性能決定網絡規模大小，以及業務承載容量。在SDN/NFV架構下，實現了控制與轉發分離，通用硬件對專有硬件的替代，性能問題成為關注的焦點。在數據平面，芯片是主要瓶頸，三態內容尋址存儲器（TCAM）表項的容量直接影響到OpenFlow流表的數量，同時OpenFlow協議定義的靈活的報文格式及操作指令，也使得專用集成電路（ASIC）芯片全面支持OpenFlow協議越來越困難。而對于通用x86實現的轉發面，其吞吐量更是無法達到線速轉發的相關要求（根據測試的數據，128字節，10 G物理接口吞吐量<1 G；1 518字節，吞吐量<9 G）。這就需要考慮在數據處理的靈活性和吞吐量之間尋找平衡。在控制平面，SDN集中控制架構，對于控制器的性能提出了更高要求，Pakcet-in消息的處理能力、管理交換機的最大數量、流建立速率、集群能力等都是一些關鍵指標。從前期測試數據來看，目前中國主流廠商在這些指標上還存在明顯的差異，很難滿足大規模組網的需求。

另外，在引入NFV后，一方面硬件通用化、網元功能的軟件化導致網絡輸入/輸出（I/O）能力難以匹配電信網絡的需求，計算能力難以滿足特殊功能（如加解密、編解碼、深度報文解析等）需求；另一方面，引入NFV后給中間件帶來一定性能損耗。如何降低軟件的開銷并通過引入軟硬件加速技術滿足電信網絡高速轉發、密集計算的性能需求成為NFV需要解決的挑戰之一。目前業界也提出了一些性能加速解決方案，如單根I/O虛擬化（SR-IOV）、數據平面開發工具集（DPDK）、超線程技術和硬件加速機制等。

（3）可靠性和擴展性問題

現有網絡從抗毀性的需求出發設計了分布式的控制機制，網絡中的每個網元都獨立地學習路由，生成轉發表項，并在此基礎上引入故障快速檢測、快速重路由、保護倒換等機制，實現鏈路/節點的故障保護，提升網絡可靠性。而且采用分布式的分層架構，從本質上來說分散了每個網元設備的路由運算壓力，能夠有效支撐網絡的大規模擴展（截至2016年6月底，骨干網的IPv4路由條目>620 000條）。而SDN架構采用集中的控制機制，由控制器集中完成路由計算并下發流表到轉發設備，因此它成為整個網絡的中樞大腦，一旦故障就會全網癱瘓，因此控制器的可靠性對于網絡而言至關重要。如何避免控制器單點故障，當鏈路或節點故障時，網絡故障如何快速上報，并快速完成流表的更新，這些問題對于控制器的實現都具有挑戰。而且對于大規模的網絡部署，我們還需要考慮控制器的分層部署，以及多個控制器之間的相互協作。

在設備層面，傳統的電信網絡設備采用軟硬一體的封閉架構，使用專有硬件，能夠滿足線速轉發的要求，而且無論是硬件還是軟件的故障都能夠快速檢測并啟動保護機制，達到99.999%的高可靠性要求。而引入NFV之后，采用通用硬件設備目前很難達到5個9的可靠性要求（一般通用商用化設備可靠性只能達到99.9%），而且原有軟硬一體化設備分成了3層，并引入管理和編排（MANO）深度介入網元的自動伸縮等流程，因此，硬件資源層、虛擬資源層、虛擬網絡功能（VNF）和MANO每層如何增強，3層如何協同，VNF與MANO如何配合等都會影響到整個系統的可靠性，這需要建立一套完整的可靠性體系并對3層如何協同提出明確的要求。但是，硬件資源的池化，將有助于在設備層面根據業務的需求靈活實現擴縮容，這是傳統電信網絡設備無法實現的。

（4）與現有運維系統的協同問題

在SDN/NFV架構下，引入新的網元管理實體，對現有網絡體系架構下的系統和設備運維都會產生影響，特別是傳統網絡與SDN/NFV網絡共存階段，如何處理與傳統網絡中運營支撐系統（OSS）/基本服務集運營支持系統（BSS）等管理、運維系統的關系，原有OSS/BSS及網管系統如何與MANO協作配合，物理網絡功能（PNF）和VNF如何協同管理，控制器與原有非SDN設備如何對接等，上述問題的解決將會是一個長期復雜的過程，需要在SDN/NFV實際應用部署中不斷探索和完善。SDN/NFV產業聯盟理事長韋樂平給出了一個觀點，他認為網管系統的演進方向應當是“縱向分割，橫向協同”，新系統基于開源碼和開放應用程序編程接口（API），負責虛擬資源的動態管理，而原有網管系統負責物理網元的管理，通過頂層的業務生命周期管理編排提供橫跨虛擬資源和物理資源的端到端業務；而新老系統通過信息模型的轉換實現橫向互通，很理想，但不現實。

（5）安全問題

相比傳統電信設備，軟硬件分離的特點以及網絡的開放性給網絡帶來了新的潛在安全問題：一是引入新的高危區域——虛擬化管理層；二是彈性、虛擬網絡使安全邊界模糊，安全策略難于隨網絡調整而實時、動態遷移；三是用戶失去對資源的完全控制以及多租戶共享計算資源，帶來的數據泄漏與攻擊風險。在NFV環境中，可能存在安全風險的關鍵組件包括VNF組件實例，綁定到VNF組件實例的本地網絡資源，遠程設備上對本地VNF組件實例的參考，VNF組件實例占用的本地、遠程以及交換存儲等。在發生安全事故的情況下，如何保證這些關鍵組件所涉及的硬件、內存不被非法訪問，如何保證VNF上應用的現有授權不被改變，本地和遠程資源徹底清除崩潰的VNF資源及授權不被濫用，是NFV安全面臨的關鍵技術挑戰。

此外，控制器開源和開放的特性，使其自身也具有潛在的安全風險，需要建立一套隔離、防護備份機制來確保其安全穩定地運行，這既包含控制器自身的安全問題，也包含控制器和應用層之間以及控制器和轉發設備之間的安全問題。

（6）集成部署問題

運營商引入SDN/NFV技術，其中的一個初衷是期望通過推動硬件和軟件的分離，軟件功能的分層解耦，進一步細化和拉長產業鏈環節，從而擺脫廠商鎖定。引入NFV后，原先由單一廠商提供整套軟硬件一體的系統，將分解成來自不同廠商的不同組件，復雜度會大大提升。從架構上看將會是一個巨大的信息通信技術（ICT）系統集成工程，包括NFV基礎設施（NFVI）的集成、VNF的集成和業務網絡的集成，涉及的系統、廠商、地域和接口都非常多。現階段，NFV相關接口的標準化進度不一，部分接口將直接采用開源軟件，部分API難以完全標準化。此外，開源軟件和廠商定制化軟件解決方案所采用的私有協議和接口，都將成為NFV系統集成和工程聯調面臨的巨大挑戰。

2 SDN/NFV標準化新進展

上述問題需要業界盡快達成共識并形成統一標準，包括架構、接口和協議，這樣才能推動SDN/NFV商用化落地。但是，與傳統計算機通信（CT）的標準化制定方式不同，在SDN/NFV領域，標準化工作更加重視從標準文檔到開源代碼的實現，其標準化工作分為兩部分：一部分由標準組織，如開放網絡基金會（ONF）、國際互聯網工程任務組（IETF）、歐洲電信標準化協會（ETSI）、城域以太網論壇（MEF）等制訂技術標準，定義技術架構、接口協議、信息模型等；另一部分由開源社區，如開放網絡操作系統（ONOS）、OpenDaylight、網絡功能虛擬化開放平臺（OPNFV）等推動代碼實現和系統集成，形成事實上的標準，從而加快從標準文檔到解決方案的落地。

（1）ONF

ONF是推動SDN技術標準的重要國際標準組織之一，其標準化工作涵蓋SDN技術的各個方面，主要包括SDN架構、南/北向接口、信息模型、轉發模型、向SDN網絡遷移的案例及工具等，并且高度重視開源工作，成立了19個開源項目支持各領域的技術研究和標準化。

當前，作為SDN技術架構的最早提出者，ONF在南向OpenFlow協議和NBI標準化方面具有一定的影響力。OpenFlow協議目前已經推出多個版本，1.5.1是其最新版本。但是，OpenFlow1.x協議有個特點就是需要根據不同的數據平面技術做大量的協議擴展工作，為此，ONF提出了OpenFlow 2.0的概念——協議無關的轉發，不但流量轉發路徑可編程，而且針對特定數據平面技術的處理流程也可編程，這樣就將對不同數據平面技術的支持從協議層面轉移到了應用層面，從而避免了每支持一種數據技術就要擴展協議的問題。目前，ONF已發布技術白皮書，并成立OF-PIF項目推動標準化。同時，斯坦福大學也發起成立了一個相關的開源項目P4，開展相關的技術研究。

在NBI方面，ONF成立多個工作組，包括通用信息模型（CIM）、NBI、光傳送工作組（OTWG）等，同時成立了BOULDER和ENGLEWOOD兩個開源項目。CIM工作組繼承了國際電信聯盟電信標準化組織（ITU-T）、電信管理論壇（TMF）等標準組織對于電信網絡的建模方法，致力于定義一個對于各種網絡技術公共的信息模型。通用信息模型包含與具體網絡技術無關的核心信息模型（例如拓撲、轉發等對象），與特定網絡技術相關的信息模型（比如光傳送網（OTN）、IP等）以及應用相關模型（比如NBI工作組當前定義的一些接口）等。2015年11月，CIM工作組發布了CIM1.1版本。OTWG采納CIM的模型，對OTN等傳送技術建模。2016年6月，OTWG發布TR527版本1.0，描述了控制器間接口功能需求以及控制器和協同器/應用層間功能需求，其中包括拓撲服務、連接服務、路徑計算服務、虛擬網絡服務、通告服務等。NBI工作組則從兩個視角定義NBI，一個是自底向上的功能型NBI，重點在網絡資源抽象及控制能力的開放，包括網絡拓撲、第2層虛擬專用網（L2VPN）、第3層虛擬專用網（L3VPN）、隧道等接口；另一個是自頂向下基于意圖的接口，關注應用或者服務的需求，同具體的網絡技術無關。目前，開源BOULDER項目提供基于意圖的NBI軟件。

（2）IETF

IETF作為互聯網領域的重要標準組織之一，也同步開展SDN/NFV相關標準化工作，涉及2個研究組和9個工作組，其中SDN RG主要針對SDN模型進行定義和分類、網絡描述語言（和相關的工具）、抽象和接口、網絡或節點功能的正確操作驗證等；NFV RG主要關注固定和移動網絡基礎設施的虛擬化、基于虛擬化網絡功能的新網絡架構、家庭和企業網絡環境的虛擬化、虛擬化和非虛擬化基礎設施與服務的并存等問題研究。9個工作組涉及Internet、路由、傳輸、安全4個領域，研究內容涵蓋移動網絡、數據中心內部網絡虛擬化，用于網絡安全控制和監測控制功能的新信息模型、軟件接口和數據模型等。其中路由系統接口（I2RS）工作組的核心思想是在目前傳統網絡設備的路由及轉發系統基礎上開放新的接口來與外部控制層通信，外部控制層通過設備反饋的事件、拓撲變化、流量統計等信息來動態地下發路由狀態、策略等到各個設備上去。選擇使用IETF現有的管理協議NETCONF和YANG來實現路由系統的開放。目前I2RS工作組已經完成了大部分路由信息庫（RIB）和拓撲的數據模型工作，正在開展NETCONF的協議改進討論。SPRING單播源路由工作組，在網絡中實現分段路由能力，主要針對兩種數據平面技術（MPLS和IPv6）進行源路由標準開發。目前該工作組已經形成了技術方案，規程已經比較完善，在進一步確定技術細節后即可發布。而針對多播流量，支持源路由在技術上更加復雜，主要是路徑的標識數量大帶來的挑戰，IETF的BIER工作組采用BitString的形式來解決這個問題。目前BIER的工作組技術方案基本確定，標準還在開發過程中。IETF內NFV方面主要工作是由業務功能鏈（SFC）工作組從事。NFV將網絡業務分解成基于通用軟件的功能模塊，而為了實現一個完整業務套餐，需要實現功能組裝，并在業務層面將用戶流量按照一定的形式在不同的功能模塊之間進行路由。

（3）ETSI

2001年11月，由運營商主導在ETSI成立NFV ISG工作組，成為推動NFV基礎架構標準的主要國際標準組織之一，主要制訂支持NFV硬件和軟件的基礎設施要求和架構規范，以及虛擬網絡功能的指南。目前已發布架構、需求、應用案例等多個技術文稿及一系列PoC文檔。目前，NFV ISG已完成第1階段的工作（2014年下半年，發布了NFV用戶案例、需求、架構和術語等V2版本，以及標準化Gap分析等新版標準文檔），并進入第2階段。第2階段的工作重點是：發展可互操作的NFV生態系統，進一步澄清第1階段定義參考點和需求，擴大行業的參與，澄清NFV與SDN以及相關標準組織、產業、開源社區的關系。為了適應2階段工作，NFV ISG也進行了相應的組織架構調整，在技術指導委員會（TSC）下，設立了5個工作組，包括IFA組研究的MANO功能及接口、加速技術；REL組研究的可靠性模型、故障檢測及可靠性框架；TST組研究的測試方法及開源組件等；EVE組研究的NFV網絡演進及生態體系建設；SEC組研究的與安全相關的內容。第2階段中參與最廣泛，并且進展最快的是IFA工作組，IFA共計完成15個項目的立項，分別關注加速資源的抽象和接口的標準化，研究架構演進（將NFVO分解為業務編排和資源編排，將VNFM分為通用VNFM和專用VNFM、VNFD重構等），研究NFV接口、模板相關的信息模型，標準化Or-Vi/Vi-Vnfm/Or-Vnfm/Ve-Vnfm/Os-Ma-nfvo等參考點包含的接口、需求和信息元定義等。

（4）MEF

2014年9月，MEF發布了“第三張網”的愿景，提出了生命周期服務編排（LSO）的理念，指出未來網絡應該包含服務編排功能、API、協議無關的網絡即服務（NaaS）信息模式以及在物理和虛擬服務端點之間的服務定義等。LSO是一個平臺，其能夠處理從客戶訂單到服務交付的控制，從數據采集到性能等級的保障，從故障修復到提供業務報告，以及為客戶提供各種分析報告等一系列服務。LSO的六大功能包括實施、控制、性能、保障、使用和分析，從而敏捷地部署動態服務，提高新型企業網絡服務的交付速度，讓客戶自己就能簡單地通過一個Web門戶來配置和管理這些產品及服務。以MEF的LSO理念，SDN控制器通過對北向API的抽象，引入了虛擬網絡，屏蔽了應用匹配不同網絡技術的復雜度，從而在端到端的虛擬網絡抽象層上實現端到端業務，將相關的網絡實施交給控制器去做。目前，MEF開放式生命周期服務編排（OpenLSO）和開放連接服務（OpenCS）計劃，為實際引進編排和連接服務層的基于開源的解決方案提供了演進路徑。

（5）OpenDaylight和ONOS

SDN是對網絡架構的一次重構，從分布式網絡架構轉向集中式控制網絡架構，引入SDN控制器來實現對網絡的控制，為各種網絡應用提供抽象統一的網絡資源訪問服務。作為網絡的中樞大腦，業界都力爭掌握控制器的主導權，積極圍繞控制器構建開放的產業生態。目前，主流的控制器平臺主要包括OpenDaylight和ONOS。前者由思科發起并主導，主要定位于數據中心的應用場景，最新版本是鈹（Beryllium，第4個版本）版本；后者由斯坦福大學發起，主要定位于運營商廣域網場景，最新版本是Goldeneye版本（第7個版本）。經過近幾年的發展，兩大系統平臺都已構建自身的產業生態，而且在架構和功能實現上有越來越多的相似點，都包含一系列動態可拔插的網絡功能組件，SBI以插件的方式支持多種協議，通過業務抽象層對控制器平臺代碼提供統一的接口，屏蔽底層設備協議的差別，使網絡服務與底層設備協議完全解耦；通過RESTful接口，提供網絡模型、網元、拓撲等多種API供應用層調用。另外，OpenDaylight的應用場景也不再局限于數據中心，通過增強其分布式集群的能力，來適應運營商廣域網組網的需求。

當前，基于兩個主流控制器平臺的商用部署都有一些成功案例。

（6）OPNFV

OPNFV是NFV開放平臺項目，旨在提供運營商級的綜合開源平臺以加速新產品和服務的引入，實現由ETSI規定的NFV架構與接口，提供運營商級的高可靠、高性能、高可用的開源NFV平臺。OPNFV的定位是集成上游開源社區的成果（如OpenStack、OpenDaylight、ONOS、開放虛擬交換機（OVS）、分布式的對象存儲和文件系統（CEPH）等），并且推動上游社區加速接納NFV相關需求。OPNFV將項目分為4類：需求類、集成與測試類、合作開放類、文檔類。其中需求類項目的主要目標是發現NFV需求和上游社區版本間的差距，然后將需求提交到上游社區，并且推動上游社區接納，代碼相關的工作在上游社區完成。2016年3月，OPNFV發布第2個版本Brahmaputra，提供包括OpenDaylight、ONOS和Open Contrail等多個SDN控制器的集成，超過30個項目貢獻了規范和社區資源。

（7）協同器開源項目

SDN協同器是運營商網絡和業務相結合的核心組件，是運營商網絡業務創新的使能平臺，提供跨域、跨層、跨廠家的網絡資源抽象和業務編排；向下對接控制器，向上對接IT系統。運營商迫切希望基于SDN/NFV加速業務創新，實現敏捷運營，因此紛紛建設ICT業務使能平臺——端到端的業務協同器，通過集中的網絡能力抽象，跨域資源統一編排，加速網絡業務創新，進而依托網絡業務的優勢向上延伸整合平臺即服務（PaaS）和軟件即服務（SaaS）成為ICT的掌控者。目前包括中國移動Open-O和西班牙電信Open-MANO等多個開源項目，都是由運營商主導，希望構建自主可控的協同器平臺，以避免被廠商鎖定。

3 結束語

使用SDN/NFV、網絡虛擬化等新技術重構傳統網絡架構是網絡演進發展的必然趨勢。但是，由于現網大量設備和系統的存在，不可能以“一刀切”的方式徹底革命，因此SDN/NFV的部署應是一個漸進式的過程，傳統網絡與SDN/NFV網絡將會長期共存，這要求業界盡快統一架構、接口和協議標準，推動不同廠商功能組件的系統集成，實現真正意義上的控制轉發分離，軟硬分離，業務功能模塊的任意組合，從而最終實現網絡即服務。當然，芯片、網絡操作系統、協同器等關鍵技術和系統的突破也是必須的。

參考文獻

[1] Linux Foundation. Platform Overview[EB/OL].[2016-09-10].https：//www.opendaylight.org/platform-overview/

[2] Open Networking Lab. Introducing ONOS-A SDN Network Operating System for Service Providers [EB/OL]. [2016-09-12]. http：//onosproject.org/wp-content/uploads/2014/11/Whitepaper-ONOS-final.pdf

[3] The P4 Language Consortium. The P4 Language Specification [S/OL]. [2016-09-15].http：//p4.org/wp-content/uploads/2016/03/p4_v1.1.pdf

[4] MEF. Vision and Strategy Based on Network as a Service Princeples [EB/OL]. （2014-09-30） [2016-09-12].http：//www.mef.net/Assets/Documents/MEF_Third_Network_Vision_FINAL.pdf

[5] Linux Foundation. OPNFV Plugfest Report[R/OL]. [2016-09-15]. https：//www.opnfv.org/sites/opnfv/files/collateral/files/inaugural_opnfv_plugfest_report_0.pdf

[6] Open Source SDN. Our Projects [EB/OL]. （2015-09-13） [2016-09-16].http：//opensourcesdn.org/our-projects/

[7] IEEE Software Defined Networks. OpenSource MANO [EB/OL]. （2016-07-17） [2016-09-20]. http：//sdn.ieee.org/newsletter/july-2016/opensource-mano

[8]楊洋，張國穎. SDN北向接口標準化簡介[EB/OL].（2016-07-01）[2016-09-20].http：//www.sdnlab.com/17275.html

[9] Network Functions Virtualization （NFV）. Management and Orchestration， Functional Requirements Specification[S]： ETSI GS NFV-IFA 010