王峰，趙慧玲

（中國電信股份有限公司北京研究院，北京 102209）

NFV開源技術(shù)

王峰，趙慧玲

（中國電信股份有限公司北京研究院，北京 102209）

NFV是運營商網(wǎng)絡(luò)重構(gòu)的核心組成部分，開源則是加速NFV發(fā)展的重要動力。如何利用開源技術(shù)推動NFV在電信網(wǎng)絡(luò)的應(yīng)用，是運營商在當(dāng)前面臨的重大課題。以國際標(biāo)準(zhǔn)化組織ETSI提出的NFV參考框架為參考，全面梳理了NFV開源技術(shù)體系，重點對NFVI、VNF、MANO等領(lǐng)域的主流開源項目的工作背景、技術(shù)路線、發(fā)展方向進行了深入剖析，并結(jié)合運營商實際情況指出了相關(guān)開源技術(shù)在現(xiàn)網(wǎng)引入時面臨的技術(shù)瓶頸、解耦障礙和運營難題，提出了相應(yīng)的工作建議。

網(wǎng)絡(luò)功能虛擬化；開源；解耦架構(gòu)；網(wǎng)絡(luò)重構(gòu)

1 引言

NFV（network function virtualization，網(wǎng)絡(luò)功能虛擬化）是當(dāng)前網(wǎng)絡(luò)領(lǐng)域的熱點，其目標(biāo)是利用虛擬化技術(shù)和標(biāo)準(zhǔn)化的通用IT設(shè)備實現(xiàn)網(wǎng)絡(luò)功能。開源能夠進一步推動網(wǎng)絡(luò)的開放性，促進電信網(wǎng)絡(luò)中私有、專用和封閉的網(wǎng)元的替換。因此，開源NFV是運營商網(wǎng)絡(luò)重構(gòu)的利器[1]。

NFV 的理念源自 ETSI（European Telecommunications Standards Institute，歐洲電信標(biāo)準(zhǔn)化協(xié)會）于2012年11月發(fā)起的NFV ISG（Industry Specification Group，行業(yè)規(guī)范組），其主要目標(biāo)是定義NFV架構(gòu)，并與業(yè)界主流標(biāo)準(zhǔn)化組織和開源社區(qū)互動促進標(biāo)準(zhǔn)生成，推動設(shè)備廠商驗證并提供應(yīng)用參考[2]。當(dāng)前，ETSI NFV ISG已經(jīng)制訂了NFV參考框架，如圖1所示，完成了NFV的需求、架構(gòu)和應(yīng)用場景分析，正在引導(dǎo)可支持互操作的NFV生態(tài)建設(shè)，明確NFV與SDN（software defined networking，軟件定義網(wǎng)絡(luò)）等領(lǐng)域的相關(guān)標(biāo)準(zhǔn)、開源項目的協(xié)作關(guān)系[3]。

為了加速 NFV 技術(shù)標(biāo)準(zhǔn)從概念驗證向商用化部署，主流運營商、設(shè)備商與 Linux基金會在2014年9月聯(lián)合發(fā)起OPNFV（open platform for NFV，NFV開放平臺）項目，旨在利用開源社區(qū)力量開發(fā)和集成符合NFV需求和架構(gòu)的開源參考平臺。OPNFV以整合已有和新增的開源組件為基礎(chǔ)，開展相關(guān)組件的性能、一致性和互操作性的驗證，達(dá)到構(gòu)建完善的NFV事實標(biāo)準(zhǔn)的目標(biāo)。遵循這一愿景，OPNFV開源平臺中，已經(jīng)包含有KVM、Ceph、OpenDaylight、OpenStack、Open vSwitch（OVS）等眾多開源項目[3]。

實踐證明，在NFV的研發(fā)應(yīng)用過程中，開源能夠有效地推進硬件設(shè)備、虛擬化環(huán)境、網(wǎng)元應(yīng)用乃至運營系統(tǒng)的全面解耦，這也是運營商引入NFV的重要工作目標(biāo)。ETSI NFV參考框架示意如圖1所示，綜合考慮標(biāo)準(zhǔn)化組織和開源社區(qū)中NFV系統(tǒng)互操作方面的工作進展，NFV解耦首先將從虛擬化基礎(chǔ)設(shè)施與硬件廠商設(shè)備的解耦以及NFVO（NFV orchestrator，NFV編排器）、各網(wǎng)元EMS（element management system，網(wǎng)元管理系統(tǒng)）與運營商的上層網(wǎng)管/支撐系統(tǒng)對接集成開始，然后實現(xiàn)直接模式下全局 NFVO和 VNFM（virtual network function manager，虛擬網(wǎng)絡(luò)功能管理器）、VIM（virtualized infrastructure manager，虛擬化基礎(chǔ)設(shè)施管理器）的解耦，最后是最具難度的VNF（virtualized network function，虛擬網(wǎng)元功能）和NFVI（NFV infrastructure，網(wǎng)絡(luò)功能虛擬化基礎(chǔ)設(shè)施）的解耦。在上述3個階段中，開源軟件都能夠在標(biāo)準(zhǔn)編制、接口定義、原型驗證乃至現(xiàn)網(wǎng)系統(tǒng)實現(xiàn)等方面提供全方位支持。

圖1 ETSI NFV參考框架示意

綜上所述，開源是NFV發(fā)展的重要動力。本文將對 NFV開源技術(shù)進行全面的研究和分析，闡述NFVI、VNF以及MANO（management and orchestration，管理與編排）的開源技術(shù)體系，并對主流開源項目的工作背景、技術(shù)路線開展深入的對比，并提出NFV開源技術(shù)在當(dāng)前面臨的主要問題。

2 NFVI及VNF開源技術(shù)

NFVI是虛擬網(wǎng)元部署和運行的基礎(chǔ)，其核心在于利用標(biāo)準(zhǔn)化的虛擬化手段支持多租戶，從而能夠為不同類型虛擬網(wǎng)元的同時運行按需提供資源支持。針對不同網(wǎng)元在功能、性能等方面的要求，用于承載VNF的NFVI可以有多種實現(xiàn)類型，如圖2所示。

圖2 典型的NFVI實現(xiàn)方式示意

圖2中所示的基于NFVI的網(wǎng)元部署方案各有特點，其優(yōu)點和不足的對比分析見表1[4]。

表1 典型NFVI實現(xiàn)方式的優(yōu)缺點

NFVI開源技術(shù)需要靈活滿足虛擬網(wǎng)元功能對計算、存儲、網(wǎng)絡(luò)等資源的需求。其中，在計算方面，需要考慮如何選擇合適的x86架構(gòu)虛擬化技術(shù)（如KVM、Xen、Docker等）用于網(wǎng)元承載；在存儲方面，因為電信網(wǎng)絡(luò)大部分網(wǎng)元功能具有無需向磁盤寫數(shù)據(jù)等特性，所以可直接利用云計算領(lǐng)域的成熟開源項目（如Ceph）；在網(wǎng)絡(luò)方面，則需要關(guān)注虛擬網(wǎng)元功能（如OVS）及其I/O性能提升技術(shù)（如DPDK、VPP等）。

2.1 NFVI開源技術(shù)

基于虛擬化環(huán)境的軟件網(wǎng)元部署是NFV的核心理念之一。當(dāng)前，在虛擬化層面，KVM和Xen是主流的x86架構(gòu)硬件虛擬化技術(shù)，它們普遍利用了底層硬件處理器對虛擬化技術(shù)的支持（如Intel VT、AMD-V），以有效提升虛擬化資源的處理性能。兩者的架構(gòu)如圖3所示。

圖3 KVM和Xen虛擬化架構(gòu)示意

圖3（a）中KVM作為Linux的內(nèi)核模塊，通過QEMU（面向完整x86系統(tǒng)的開源仿真器，具有高性能、跨平臺等特性）為每臺虛擬機提供模擬的磁盤、網(wǎng)絡(luò)等設(shè)備，提供高性能的 I/O支持；圖3（b）中Xen則只有域0具有訪問硬件I/O設(shè)備的特權(quán)，它負(fù)責(zé)接收來自各個域 U（即虛擬機）中的設(shè)備前端驅(qū)動程序發(fā)來的 I/O請求，進而通過其具備的設(shè)備后端驅(qū)動程序驅(qū)動設(shè)備完成請求。

在此前的IT云中，Xen在性能、穩(wěn)定性和成熟度等方面更具優(yōu)勢，從而具有廣泛的應(yīng)用（如AWS、阿里云都采用基于Xen的虛擬化技術(shù)）。但是，在新興的NFV場景中，網(wǎng)元應(yīng)用具有的高網(wǎng)絡(luò)I/O壓力使得Xen架構(gòu)中的域0容易成為瓶頸，這使得KVM成為開源NFVI的首選[5,6]。

容器作為輕量級虛擬化方案，正在IT基礎(chǔ)設(shè)施平臺領(lǐng)域獲得推廣。其中，Docker是當(dāng)前最為知名的容器引擎，同時Rocket、runC等開源項目也正在快速成長中。多個容器可直接在共享的宿主Linux上分別加載和運行應(yīng)用程序，并利用cgroup、namespace等Linux內(nèi)部機制實現(xiàn)不同容器間的隔離、權(quán)限管理和資源額度分配。作為操作系統(tǒng)層的虛擬化，容器不像虛擬機一樣需要虛擬出完整的硬件平臺并運行獨立的操作系統(tǒng)，具有部署快捷、擴展性強、整合密度高等特點。

利用容器承載VNF是當(dāng)前NFV領(lǐng)域的研究熱點。與基于硬件的虛擬化技術(shù)側(cè)重在資源層面實現(xiàn)物理向虛擬的轉(zhuǎn)換不同，容器更強調(diào)的是軟件組件的細(xì)粒度和松耦合。利用微服務(wù)（micro service）理念改造軟件網(wǎng)元，進而通過容器承載微服務(wù)是容器在NFV領(lǐng)域引入的關(guān)鍵，這也為網(wǎng)元的研發(fā)、部署、管理提出了新的挑戰(zhàn)。另外，在高帶寬、低時延的網(wǎng)絡(luò)流量壓力下，基于容器部署的微服務(wù)間通信在同步性、時效性等方面的能力有待進一步驗證。同時，容器技術(shù)自身也還存在不足（如Docker的向后兼容問題），更加劇了在當(dāng)前利用容器平臺承載虛擬網(wǎng)元功能的風(fēng)險。

2.2 VNF開源技術(shù)

NFV實現(xiàn)了網(wǎng)元設(shè)備的軟硬件解耦及網(wǎng)元功能的抽象，降低了傳統(tǒng)網(wǎng)絡(luò)設(shè)備制造領(lǐng)域的門檻。開源的VNF已經(jīng)由來已久，但此前主要在數(shù)據(jù)中心網(wǎng)絡(luò)被廣泛部署應(yīng)用，如：以 LVS、Nginx為代表的虛擬負(fù)載均衡，以iptables為代表的虛擬防火墻，以O(shè)VS為代表的虛擬交換機。當(dāng)前，開源領(lǐng)域也出現(xiàn)了面向電信網(wǎng)絡(luò)的開源VNF技術(shù)，例如OpenEPC、OpenIMS等，它們以純軟件的方式實現(xiàn)電信網(wǎng)絡(luò)的網(wǎng)元功能，使之更適合于在虛擬化基礎(chǔ)設(shè)施上運行。

在VNF的設(shè)計與實現(xiàn)中，x86架構(gòu)及其虛擬化技術(shù)能否為虛擬網(wǎng)元功能提供足夠的性能支持是亟待解決的問題，開源的 DPDK（data planedevelopment kit，數(shù)據(jù)平面開發(fā)套件）是針對這一問題的主流解決方案。DPDK是x86架構(gòu)平臺上用于報文快速處理的庫和驅(qū)動的集合，其核心思想是支持運行在 Linux用戶態(tài)空間的應(yīng)用程序能夠直接驅(qū)動物理網(wǎng)絡(luò)設(shè)備而無需陷入操作系統(tǒng)的核心態(tài)，從而有效提升性能。當(dāng)前，很多軟件都在借助DPDK改善網(wǎng)絡(luò)數(shù)據(jù)處理效能，如FD.io開源項目。FD.io的目標(biāo)是提供模塊化、可擴展的用戶空間的 I/O服務(wù)框架，能支持高吞吐量、低時延、高資源利用率的I/O服務(wù)。它貢獻的VPP（vector packet processing）是利用了DPDK技術(shù)的可供商用的vSwitch/vRouter方案，與同類開源技術(shù)相比擁有數(shù)量級上的性能優(yōu)勢。

與DPDK專注于提升運行在Linux用戶態(tài)的虛擬網(wǎng)元功能的I/O性能不同，I/O Visor開源項目的思路是在Linux內(nèi)核中拓展I/O虛擬化能力，從而提供可擴展的網(wǎng)絡(luò)系統(tǒng)基礎(chǔ)。使用I/O Visor，Linux內(nèi)核中可以運行多個VNF乃至完整的服務(wù)鏈（service chain），系統(tǒng)在處理網(wǎng)絡(luò)流量時也無需進行內(nèi)核模塊的加載，能夠確?；A(chǔ)設(shè)施更新升級時不會中斷網(wǎng)絡(luò)操作。同時，I/O Visor支持在操作系統(tǒng)內(nèi)核態(tài)直接處理網(wǎng)絡(luò)I/O，也避免了傳統(tǒng)的需要經(jīng)由系統(tǒng)調(diào)用進入用戶態(tài)的做法，有效地提升了VNF性能。

3 MANO開源技術(shù)

NFV MANO涵蓋了支持基礎(chǔ)設(shè)施虛擬化的軟硬件資源的編排和生命周期管理以及VNF的生命周期管理。如圖1所示，MANO主要包括3個模塊：NFVO負(fù)責(zé)網(wǎng)絡(luò)服務(wù)生命周期管理和總體資源管理等功能；VNFM負(fù)責(zé)監(jiān)控VNF實例的整個生命周期（包括配置、擴展和終結(jié)等）；VIM負(fù)責(zé)管理和控制 NFVI中的計算、存儲和網(wǎng)絡(luò)資源。其中，VNFM和具體的VNF有密切的關(guān)系，在當(dāng)前還缺少完善的開源解決方案，而VIM則相對成熟。

3.1 MANO開源技術(shù)概述

對于運營商而言，網(wǎng)絡(luò)資源的運維和調(diào)度是其核心競爭力，特別是NFV能夠更便捷地支持網(wǎng)絡(luò)服務(wù)的規(guī)模伸縮和質(zhì)量優(yōu)化，因此MANO吸引了眾多運營商的目光，有很多運營商主導(dǎo)的開源MANO項目被提出，例如：Telefonica發(fā)起的OpenMANO、中國移動發(fā)起的Open-O、AT&T發(fā)起的 ECOMP（enhanced control, orchestration, management & policy，增強控制、編排、管理和策略）等。同時，標(biāo)準(zhǔn)化組織和開源社區(qū)也在MANO領(lǐng)域做出很多工作，例如：ETSI OSM（open source MANO）、OpenStack Tacker等。另外，還有一些企業(yè)在MANO功能模塊方面做出了貢獻，例如Gigaspace推出的編排器Cloudify、Canonical推出的VNF管理器Juju等[7]。

在經(jīng)歷了開源項目爆發(fā)期之后，MANO在當(dāng)前正走向項目整合的方向。將多個相關(guān)領(lǐng)域的小型開源項目匯集整合到大型項目中，有利于產(chǎn)業(yè)的聚焦，避免重復(fù)研發(fā)，擴大社區(qū)影響力。例如，ETSI OSM 在其發(fā)布的首個版本中，就利用了OpenMANO實現(xiàn)資源編排，利用Juju實現(xiàn)VNF配置和管理，同時它還引入了ETSI NFV范圍之外的開源服務(wù)編排組件RIFT.ware。2017年2月，同屬于 Linux基金會的兩大開源組織 Open-O和ECOMP合并成為ONAP（open network automation platform，開放網(wǎng)絡(luò)自動化平臺）項目。同為運營商主導(dǎo)的MANO項目，Open-O和ECOMP在架構(gòu)設(shè)計、功能實現(xiàn)等方面存在共性，并且都具有良好的發(fā)展勢頭，其中，Open-O擁有眾多運營商支持并成為OPNFV上游項目，ECOMP則已經(jīng)在AT&T實現(xiàn)現(xiàn)網(wǎng)的規(guī)模部署。兩個項目合并成立ONAP意味著 NFV已經(jīng)度過初始的技術(shù)驗證階段，即將走向規(guī)模部署、規(guī)模商用的階段。

NFV MANO開源項目當(dāng)前不夠成熟，但在ETSI發(fā)布的標(biāo)準(zhǔn)架構(gòu)的指引下，該領(lǐng)域的開源項目都具有較為清晰的定位。不同背景的開源項目會有不同的發(fā)展路徑，其中：標(biāo)準(zhǔn)化組織主導(dǎo)開源工作的原則之一是項目要服務(wù)于標(biāo)準(zhǔn)的制定，通過開源代碼驗證標(biāo)準(zhǔn)的合理性和可行性，并為文檔工作的完善提供依據(jù)[8]；運營商主導(dǎo)的項目則以滿足電信網(wǎng)絡(luò)重構(gòu)的現(xiàn)實需求為目標(biāo)，會在標(biāo)準(zhǔn)化架構(gòu)的基礎(chǔ)上結(jié)合自身需求進行能力的增減，并通過社區(qū)凝聚產(chǎn)業(yè)生態(tài)，加速落地；設(shè)備廠商發(fā)起的項目，更主要的是發(fā)揮自身在相關(guān)領(lǐng)域的特長，為前兩類開源社區(qū)的能力完善和資源整合提供支持。為了確保自身利益，運營商主導(dǎo)的開源項目會設(shè)定一些規(guī)則，例如ONAP在號召運營商加入的同時對設(shè)備廠商董事成員名額進行了限制，這也是其與另兩類開源項目不同的地方。

3.2 VIM開源技術(shù)

VIM是NFV MANO中相對成熟的模塊，利用云計算和SDN的理念是當(dāng)前實現(xiàn)VIM的主流思路。開源領(lǐng)域的 OpenStack云管理平臺和以O(shè)penDaylight、ONOS為代表的SDN控制器的融合構(gòu)建成為了VIM領(lǐng)域廣為使用的方案。

VIM 作為底層虛擬化基礎(chǔ)設(shè)施的管理平臺，需要負(fù)責(zé)計算、存儲、網(wǎng)絡(luò)資源池的統(tǒng)一管理和協(xié)同調(diào)度。OpenStack作為當(dāng)前最具影響力的開源云管理平臺項目，可實現(xiàn)在單一管理平臺上對多個數(shù)據(jù)中心的管理，并具備通用的安全、身份識別服務(wù)、API 及用戶界面。OpenStack的Nova、Cinder、Neutron等組件在云計算資源池的計算、存儲、網(wǎng)絡(luò)等領(lǐng)域的資源管理方面吸引了眾多合作伙伴，實現(xiàn)了對云基礎(chǔ)設(shè)施資源的全面管理。因此，OpenStack被眾多 NFV項目用作虛擬化基礎(chǔ)設(shè)施的管理組件，例如OPNFV。同時，OpenStack在VIM模塊上的成功推動了其向 NFV MANO的全棧拓展。Tacker是 OpenStack社區(qū)中遵循 ETSI MANO架構(gòu)實現(xiàn)NFVO和VNFM的組件服務(wù)，在端到端VNF平臺模板交付、VNF服務(wù)目錄、NFV生命周期管理等方面做出突出工作。

VNF部署的動態(tài)性、擴展性對網(wǎng)絡(luò)連接提出了更高的要求，SDN則能夠很好地支持NFV在電信網(wǎng)絡(luò)的引入?？刂破髯鳛镾DN的核心也是開源領(lǐng)域的重點，其中最具影響力的是 OpenDaylight和 ONOS。經(jīng)過多年的發(fā)展，兩個開源項目相互借鑒相互影響，在整體架構(gòu)和技術(shù)路線上正日益趨同，例如采用 Karaf架構(gòu)提升擴展性、北向采用模型驅(qū)動、南向支持多種協(xié)議等。類似此前MANO開源項目分析，OpenDaylight和ONOS分別是設(shè)備廠商和運營商主導(dǎo)。因此，OpenDaylight更符合廠商利益，并更適于和現(xiàn)網(wǎng)的平滑過渡；ONOS則更多體現(xiàn)了運營商的意志，貼合電信網(wǎng)絡(luò)重構(gòu)需求。

NFVI的發(fā)展趨勢之一是容器的應(yīng)用，因此容器集群的管理也是當(dāng)前VIM領(lǐng)域的熱點，主流開源項目包括Kubernetes、Mesos、Swarm、Rancher等。其中，源自Google的Kubernetes在當(dāng)前最受關(guān)注，其在服務(wù)發(fā)現(xiàn)與容錯調(diào)度等方面有較大優(yōu)勢；Mesos的調(diào)度機制分為資源委派和調(diào)度框架兩個層次，更適用于復(fù)雜分布式應(yīng)用的部署；Swarm是主流容器技術(shù)Docker的原生功能，在使用維護上較為簡潔；Rancher作為后起之秀，則具備了對上述3家容器集群管理引擎的支持。如上文所述，容器的關(guān)鍵并非只是虛擬化資源交付方式的簡單改變，更重要的是它能夠更好地支持以微服務(wù)的粒度對VNF進行靈活的編排。相應(yīng)的，容器的集群管理和資源調(diào)度解決的將不僅是VIM層面的問題，而且可以擴展到NFVO、VNFM等多個層面。隨著基于容器的NFV技術(shù)的發(fā)展，以Kubernetes為代表的容器集群管理項目也將成為NFV MANO的重要選擇。

4 開源NFV問題

對于運營商而言，開源是一把雙刃劍：一方面，它能夠充分借助社區(qū)的力量，幫助運營商脫離設(shè)備廠商的鎖定，使得整個網(wǎng)絡(luò)系統(tǒng)更加靈活；另一方面，在開源社區(qū)中，運營商、設(shè)備廠商有著不同的訴求，對運營商的掌控力提出新的挑戰(zhàn)。另外，開源項目依托相對松散的社區(qū)提供代碼維護和支持，在軟件質(zhì)量、版本兼容、代碼冗余等方面存在不確定性，為其在現(xiàn)網(wǎng)的引入增加了障礙。結(jié)合開源項目的發(fā)展現(xiàn)狀，運營商在運用開源NFV時需特別關(guān)注以下方面。

（1）技術(shù)瓶頸

開源NFV在性能、可靠性等方面存在瓶頸，這主要是因為作為其基礎(chǔ)的x86架構(gòu)及其虛擬化技術(shù)此前重點面向的是計算密集型應(yīng)用而并非類似網(wǎng)元功能的 I/O密集型應(yīng)用，雖然其網(wǎng)絡(luò)處理能力在DPDK、SR-IOV等軟硬件技術(shù)輔助下已有較大幅度提升，但是仍難以滿足高性能轉(zhuǎn)發(fā)的需求。同時，電信網(wǎng)絡(luò)網(wǎng)元所需的高可靠性保障在此前需要依賴于專用硬件的特別設(shè)計，而在NFV場景下憑借通用IT設(shè)備和軟件高可用設(shè)計來實現(xiàn)相關(guān)目標(biāo)還需要更多的工作。

（2）解耦障礙

解耦是運營商部署NFV的重要目標(biāo)，但在當(dāng)前存在巨大障礙。主要原因來自兩個方面：一個方面是設(shè)備商為了解決上述 NFV開源技術(shù)的瓶頸，必然會在NFV架構(gòu)的軟硬件堆棧開展優(yōu)化，以建立技術(shù)壁壘；另一個方面是NFV除了在縱向上具有基礎(chǔ)設(shè)施、虛擬網(wǎng)絡(luò)和運營支撐等層次外，橫向上還有橫向的管理編排域，眾多接口和協(xié)議標(biāo)準(zhǔn)分散在不同的標(biāo)準(zhǔn)化組織中，從而影響了兼容性和互操作性的實現(xiàn)。運營商的需求引領(lǐng)將是解決這一問題的關(guān)鍵，通過開源項目打造確?；ヂ?lián)互通的事實標(biāo)準(zhǔn)是實現(xiàn)NFV架構(gòu)在各個層次上充分解耦的重要手段。

（3）運營難題

雖然運營商已經(jīng)在NFV開源項目中發(fā)揮了一定的主導(dǎo)作用，但是總體而言，運營商在軟件設(shè)計開發(fā)、開源社區(qū)運營等方面尚不具有足夠的實力，其中最典型的難題之一就是如何針對自身需求開展開源組件選型進而整合為業(yè)務(wù)系統(tǒng)。為此，SDN和NFV領(lǐng)域的重要標(biāo)準(zhǔn)化組織ONF（Open Networking Foundation，開放網(wǎng)絡(luò)基金會）提出了開放式創(chuàng)新渠道（open innovation pipeline），目標(biāo)是在開放平臺上提供大量可應(yīng)用框架，為運營商提供多種多樣的解決方案，降低運營商進入軟件開發(fā)領(lǐng)域的成本和障礙。另外，開源的引入絕不意味著運營商不再需要設(shè)備商的支持，圍繞開源技術(shù)的集成服務(wù)和技術(shù)支撐將促使運營商和設(shè)備商此前建立的簡單買賣關(guān)系轉(zhuǎn)型為更深入的研發(fā)運營合作關(guān)系。

5 結(jié)束語

開源驅(qū)動的以軟件為中心的架構(gòu)正在加速網(wǎng)絡(luò)的變革，以使得運營商能夠應(yīng)對市場競爭的持續(xù)加劇、用戶需求的不斷變化以及自身業(yè)務(wù)增收的巨大壓力，NFV則是這一變革的重要組成部分。開源項目的涌現(xiàn)促進了NFV領(lǐng)域完備軟件化體系的形成，有力地推動了NFV的標(biāo)準(zhǔn)制定、系統(tǒng)研發(fā)及落地實踐。

NFV以及SDN、云計算構(gòu)成了當(dāng)前運營商網(wǎng)絡(luò)重構(gòu)的核心要素，它們的核心理念都是 CT產(chǎn)業(yè)與IT產(chǎn)業(yè)的能力融合。而開源作為IT產(chǎn)業(yè)迅猛發(fā)展的重要推手，也勢必會在 CT產(chǎn)業(yè)發(fā)揮重大作用。運營商應(yīng)牢牢把握這一趨勢，借助開源的力量，掌控核心技術(shù)，建立事實標(biāo)準(zhǔn)，加快業(yè)務(wù)創(chuàng)新，降低運營成本，進而打造開源生態(tài)，引領(lǐng)產(chǎn)業(yè)發(fā)展。

[1] 中國電信集團公司. CTNet 2025網(wǎng)絡(luò)架構(gòu)白皮書 [R/OL]. (2016?07?11)[2017?01?15]. http://www.chinatelecom.com. cn/news/06/bps/. China Telecom. CTNet 2025 network architecture white paper [R/OL]. (2016?07?11)[2017?01?15]. http://www.chinatelecom. com.cn/news/06/bps/.

[2] European Telecommunications Standards Institute. Network functions virtualisation: network operator perspectives on in-dustry progress [R/OL]. (2014?10?17)[2017?01?15]. https:// portal.etsi.org/Portals/0/TBpages/NFV/Docs/NFV_White_Paper3.pdf.

[3] 馬軍鋒. SDN/NFV關(guān)鍵技術(shù)問題分析和標(biāo)準(zhǔn)化進展[J]. 中興通訊技術(shù), 2016, 22(6): 12-16. MA J F. Key technical problems and standardization progress of SDN/NFV [J]. ZTE Technology Journal, 2016, 22(6): 12-16.

[4] 趙慧玲. SDN/NFV的發(fā)展與挑戰(zhàn)[C/OL]//2016全球SDNFV技術(shù)大會, 2016年6月1日, 北京. [2016?06?01]. http://net. zhiding.cn/ network_security_zone/2016/0601/3078383.shtml. ZHAO H L. Developments and challenges of SDN/NFV [C/OL]//Global SDNFV Technology Conference 2016, June 1, 2016, Beijing, China. [2016?06?01]. http://net.zhiding.cn/network_ security_zone/2016/ 0601/3078383.shtml.

[5] Wind River. Open solutions for NFV [R/OL]. (2015?11?01) [2017?01?16]. http://www.windriver.com.cn/products/titaniumserver/2415-Open-Checklist.pdf.

[6] Red Hat. Network functions virtualization with Red Hat [R/OL]. (2015?09?03)[2017?01?16].https://www.redhat.com/en/files/ resources/en-rhel- nfv-value-inc0285929_v1_0815_kvm.pdf.

[7] IEEE. IEEE softwarization eNewsletter – July 2016 [R/OL]. (2016?07?13)[2017?01?16]. http://resourcecenter.fd.ieee.org/ fd/product/enewsletters/FDSDNNL0005.

[8] Open Source MANO. A conversation with the OSM Leadership Group [EB/OL]. (2016?10?01)[2017?01?16]. https://osm.etsi. org/news-events/news/a-conversation-with-the-osm-leadership-group.

王峰（1979?），男，中國電信股份有限公司北京研究院教授級高級工程師，主要研究方向為云計算、軟件定義網(wǎng)絡(luò)。

趙慧玲，女，長期從事電信網(wǎng)絡(luò)領(lǐng)域技術(shù)和標(biāo)準(zhǔn)工作?，F(xiàn)任中國通信學(xué)會常務(wù)理事；中國通信學(xué)會信息通信網(wǎng)絡(luò)技術(shù)專業(yè)委員會主任委員；中國通信學(xué)會北京通信學(xué)會副理事長；中國通信標(biāo)準(zhǔn)協(xié)會網(wǎng)絡(luò)與業(yè)務(wù)能力技術(shù)工作委員會主席；工業(yè)和信息化部科學(xué)技術(shù)委員會委員；中國電信科學(xué)技術(shù)委員會常務(wù)委員兼核心網(wǎng)組負(fù)責(zé)人；國際標(biāo)準(zhǔn)組織MEF顧問董事；SDN、NFV產(chǎn)業(yè)聯(lián)盟技術(shù)委員會副主任。發(fā)表技術(shù)文章百余篇、技術(shù)專著12部，曾獲得多個國家及省部級科學(xué)技術(shù)進步獎項。

Open source technology of NFV

WANG Feng, ZHAO Huiling
Beijing Research Institute of China Telecom Co., Ltd., Beijing 102209, China

NFV is a core component of the operator network reconstitution, and open source is an important driving force to accelerate the development of NFV. How to use open source technology to promote the application of NFV in telecom network is a major issue faced by operators. NFV open source technology system was surveyed comprehensively according to the NFV reference framework proposed by ETSI, and the background, core technology and development trend of mainstream open source projects of NFVI, VNF and MANO was analyzed. Finally, some critical problems (such as technical bottlenecks, decoupling obstacles and operational difficulties) and corresponding solutions were presented to help operators to make better use of open source technology of NFV.

network function virtualization, open source, decoupling architecture, network reconstitution

TP393

A

10.11959/j.issn.1000?0801.2017105

2017?02?20；

2017?04?04

國家高技術(shù)研究發(fā)展計劃（“863”計劃）基金資助項目（No.2015AA016106）

Foundation Item：The National High Technology Research and Development Program of China (863 Program)(No.2015AA016106)