業(yè)務鏈研究進展及技術展望

黃燦燦++陳華南++伍佑明++朱永慶++龔霞

【摘 要】業(yè)務鏈是SDN/NFV創(chuàng)新業(yè)務模式，已成為業(yè)界的研究熱點，為了探討如何更好地推進業(yè)務鏈技術的發(fā)展，在分析運營商業(yè)務承載痛點的基礎上，對業(yè)務鏈關鍵技術及研究進展進行了分析與探討，并指出業(yè)務鏈未來研究方向，希望能為后續(xù)技術研究及應用提供指引。

【關鍵詞】業(yè)務鏈 流分類器 NSH

1 引言

網(wǎng)絡能力升級換代的迫切需求給運營商網(wǎng)絡帶來了極大的挑戰(zhàn)。近20年，互聯(lián)網(wǎng)在業(yè)務承載方面基本采用“拓撲敏感型”模式，即通過增強網(wǎng)元功能以支持新業(yè)務的功能要求，但大量中間件（MiddleBox）的串接直接導致了網(wǎng)絡功能的臃腫，專用設備陷入困境，運營商核心競爭力嚴重下降，被逐步排擠到產(chǎn)業(yè)鏈邊緣。隨著移動互聯(lián)網(wǎng)、云業(yè)務及IoT等新型業(yè)務的發(fā)展，用戶有了即時交互式體驗需求，要求可按需靈活制定個性化網(wǎng)絡，這對網(wǎng)絡基礎設施提出了很高要求。

SFC（Service Function Chaining，業(yè)務鏈）是面向用戶、應用的新型業(yè)務模式[1]，是SDN、NFV及云等技術的深度融合解決方案。業(yè)務鏈借助虛擬化技術，將傳統(tǒng)網(wǎng)元功能的處理流程進行動態(tài)靈活編排，以虛擬形態(tài)構建可變的業(yè)務處理流，解決了由網(wǎng)絡中間件所導致的服務功能無法復用、底層網(wǎng)絡拓撲依賴、流量繞轉等問題。

業(yè)務鏈架構涉及業(yè)務編排器、業(yè)務鏈控制器、流量分類器/轉發(fā)器及業(yè)務鏈標識等多方面的關鍵技術，這些技術正處于研究及實驗室原型驗證階段，暫無成熟商用可規(guī)模應用的解決方案。各大標準及開源組織陸續(xù)開展了業(yè)務鏈核心技術研究，各自研究進度不一致，暫無專門組織對各組織的研究成果進行集成和推進。因此，為更好地推進業(yè)務鏈技術的發(fā)展，本文擬從標準及開源項目著手，梳理業(yè)務鏈技術研究進展，并研判各技術發(fā)展趨勢，為后續(xù)研究工作提供技術參考及指引。

2 SFC關鍵技術

SFC技術包括底層虛擬化資源分配、網(wǎng)絡業(yè)務處理功能定義以及用戶業(yè)務處理鏈定義等功能，用于實現(xiàn)網(wǎng)絡服務的自動化部署及提供，聚焦基于特定場景的業(yè)務鏈實現(xiàn)，包括基于多租戶的業(yè)務鏈、基于城域邊緣的業(yè)務鏈以及基于Gi-LAN的業(yè)務鏈等。隨著技術的研究深入，業(yè)界在業(yè)務鏈架構及業(yè)務流程方面已達成一致，具體如圖1所示。

業(yè)務鏈主要包括以下關鍵部件：

SFC編排器：通過intent-based的北向接口將定義SFC需求的能力開放給用戶。在收到用戶請求后，將用戶特征抽象成流分類條目，并將用戶的需求翻譯成一系列有序的網(wǎng)絡功能。另外編排器會通過SF（Service Function，業(yè)務功能）instance管理器收集SF type和SF group（用于SF instance負載均衡）的狀態(tài)并維護相應的目錄，選擇網(wǎng)絡功能（SF group）進行鏈接，實現(xiàn)SFC的編排。

SFC網(wǎng)絡控制器：接受SFC編排器下發(fā)的某用戶SFC，通過SF Instance管理器收集SF instance狀態(tài)信息。SFC網(wǎng)絡控制器負責選擇最優(yōu)SF instance，形成SFP（Service Function Path，業(yè)務鏈路徑），以轉發(fā)表的形式通過南向接口下發(fā)給SFF（Service Function Forwarder，業(yè)務功能轉發(fā)器），指導其進行報文轉發(fā)，并將流分類條目以及所對應的SFC下發(fā)給分流器。

SF Instance管理器：負責SF實例的生命周期的管理。它負責實時跟蹤SF類型、SF group的狀態(tài)及位置并在SFC編排器上進行注冊，同時將SF instance的狀態(tài)和位置在SFC網(wǎng)絡控制器上進行注冊。

分流器：基于某種策略（例如五元組）對用戶的流量進行分類，并根據(jù)該分類找到其對應的SFC，將SFC報文頭插入到報文中。分流器可以是一個單獨的物理實體，也可以集成在SFF中。一條SFC上可以有多個分流器。

策略平臺：為SFC編排器提供運營商策略規(guī)則。

SFF：負責將數(shù)據(jù)報文轉發(fā)至指定的SF實例。通過查看數(shù)據(jù)報文的SF報文頭中的路徑ID和服務ID，并結合網(wǎng)絡控制器下發(fā)的轉發(fā)表來做轉發(fā)決策。SFF會維護基于SF專用報文頭（例如NSH）的轉發(fā)表，也會維護普通的L2～L3層轉發(fā)表（在性能允許的情況下會維護L4～L7層轉發(fā)表），以滿足對不攜帶SF專用報文頭數(shù)據(jù)報文的轉發(fā)。

SF：對收到的數(shù)據(jù)包進行特殊處理的功能模塊。一個SF可以是虛擬網(wǎng)元，也可以是物理網(wǎng)元；多個SF可以在同一管理域存在。多個SF可以共存于同一個物理設備。SF可以是SFC封裝感知的，也可以是SFC封裝不感知的，如果是封裝不感知的，需要經(jīng)過SF代理網(wǎng)元進行翻譯。

3 SFC研究進展

SFC技術自提出以來就成為產(chǎn)業(yè)鏈各方關注重點，成為運營商、云服務提供商、硬件/軟件提供商及客戶共同努力的目標，寄望于與SDN/NFV及云共同發(fā)展。國際各大標準組織配合開源組織對SFC進行了理論體系的構建和產(chǎn)品原型的開發(fā)，兩者的高效協(xié)作促進了SFC標準的快速成型和落地，如表1所示。

3.1 標準組織研究進展

IETF、BBF等標準組織則從SFC場景、部署、運維和管理等方面重點提出需求，并結合開源組織產(chǎn)品進行SFC各場景的POC試驗。在理論研究方面IETF是領導者，它定義了SFC的框架、流程、協(xié)議以及包格式等，并針對流量優(yōu)化和運維管理等細節(jié)進行了深入研討。

（1）IETF

IETF是SFC技術的大本營，對SFC的原理、架構、實現(xiàn)機制、優(yōu)化與運維管理進行了全面而深入的梳理和探討，為SFC原型化、產(chǎn)品化以及進一步在現(xiàn)網(wǎng)部署提供了理論依據(jù)，具有極高的參考價值。但IETF較為關注細節(jié)技術問題的解決方案，而對SFC在現(xiàn)網(wǎng)中端到端部署與實施缺少多維度的、宏觀到微觀的探討，亟需相關文檔的輸入。

IETF SFC組已正式發(fā)布2個RFC（Request For Commets），對SFC的架構、組件、協(xié)議機制、功能、管理、診斷、設計分析以及安全模型等進行了深入研究。在研Draft文稿聚焦在數(shù)據(jù)中心、移動網(wǎng)、寬帶網(wǎng)絡、vCPE以及大流量場景的SFC解決方案。IETF主要研究內(nèi)容聚焦在以下方面：endprint

1）業(yè)務鏈架構研究：層次化SFC架構，其中跨域及層次化轉發(fā)機制成為研究熱點。

2）控制平面技術研究[2]：SFC對控制協(xié)議的選擇存在較多的爭議，暫無統(tǒng)一的解決方案。是使用傳統(tǒng)協(xié)議的擴展，還是使用全新構建的協(xié)議（例如SF instance資源發(fā)現(xiàn)協(xié)議OSP（Off-path Signaling Protocol，偏離路徑簽名協(xié)議）），需根據(jù)SFC部署場景、規(guī)模以及產(chǎn)品成熟度來區(qū)分斟酌。

3）數(shù)據(jù)平面技術研究：工作組創(chuàng)新性地提出了NSH（Network Service Header，網(wǎng)絡業(yè)務頭封裝）[3]，通過攜帶SPID（Service Path ID）和SID（Service ID）給SFF提供報文匹配信息。工作組對NSH進行了深入細致的研究，包括NSH TLV、NSH服務轉發(fā)流程、NSH radius屬性定義、NSH的DHCP屬性、基于UDP的NSH、基于IPv6擴展的NSH等，已成為SFC轉發(fā)面協(xié)議的主流事實標準。在應用中，分類器維護NSH映射表，通過匹配SPID和SID，大大提高了SFF的效率，解決了傳統(tǒng)的SF需要匹配五元組或者其他參數(shù)來識別特征流量、在參數(shù)組合繁多的情況下SF的映射表龐大等問題。另外NSH還可通過攜帶metadata，靈活地傳遞更加個性化的報文處理指令以及運行維護參數(shù)。同時，工作組還關注通過LISP/PCEP/BGP LS/IPv6等擴展報文頭來攜帶SFC信息的補充方案，為現(xiàn)有網(wǎng)絡升級提供技術參考。

4）流量/路徑優(yōu)化場景研究：SFC各組件的多種部署方式使得它存在流量繞轉和路徑繁雜等潛在問題。SFC流量存在從SFF轉發(fā)至SF再返回SFF的迂回過程，直接導致了帶寬的浪費和時延抖動的增加。針對該問題，工作組提出SF旁路和SF流量卸載兩種解決方案。SFC流量卸載將SF不感興趣的流量通過指令的方式卸載到SFF進行處理，該方案的討論在群組中較為活躍。另外較為受關注的還有基于策略的路徑優(yōu)化、負載均衡問題分析、SFC動態(tài)路徑選擇等，這些優(yōu)化方案著重于方法論和流程的闡述，但缺少基于具體網(wǎng)絡業(yè)務場景的應用介紹。

（2）BBF

BBF是運營商主導的標準組織，較為關注應用場景和案例，對運營出現(xiàn)的問題一般聚焦于需求以及解決方案框架，而具體技術多數(shù)會通過通告的方式引用IETF的成果，也因此受制于IETF SFC組的進度。BBF從運營商的角度出發(fā)，針對不同的應用場景以及相應的不同解決方案，全方位地給出對比與選擇建議，為指導運營商部署SFC給出了可行的建議。

研究項目SD326[4]針對FSC（Flexible Service Chaining，柔性業(yè)務鏈）的市場需求及應用場景進行研究，并構建了“靈活業(yè)務鏈網(wǎng)絡架構”。TR-178所定義的層次化BNG被SD326視為SFC在城域網(wǎng)邊緣的業(yè)務鏈應用場景，并在此基礎上擴展出了6種應用模式，包括CGNAT以及Web Filtering、接入以及父母控制、DPI和Lawful Intercept、DPI和URL過濾、主機安全以及嚴格SLA、物理以及虛擬網(wǎng)絡下的業(yè)務鏈彈性冗余等場景。針對運營商部署需求，BBF重點關注以下3個方面的研究內(nèi)容：

1）復雜業(yè)務鏈相關問題包括開環(huán)和閉環(huán)業(yè)務鏈、動態(tài)業(yè)務鏈部署、路徑動態(tài)變更、對稱和非對稱轉發(fā)、跨CO/POP/DC的業(yè)務鏈、跨運營商業(yè)務鏈以及虛擬遷移場景下的接口地址移動等。

2）運營級業(yè)務鏈相關問題包括基于session/用戶業(yè)務鏈的QoS部署與保障、基于帶寬/時延/OAM等因素的業(yè)務鏈SLA制定。

3）跨域場景下的自動配置包括用戶感知的session認證和計費、動態(tài)負載均衡和高可靠性、按需的靈活帶寬配給。

（3）ETSI

ETSI（歐洲電聯(lián)）是歐洲運營商和設備商主導的標準組織，是NFV的制定者及主導者，提出采用NFVFG方式實現(xiàn)NFV環(huán)境下的業(yè)務鏈，且組織產(chǎn)業(yè)鏈進行相應場景試點，為運營商部署提供技術參考。NFVFG架構如圖2所示：

ETSI對業(yè)務鏈研究比較零散，分布在各個研究文檔中。其中GS NFV 001提出NFVFG的應用案例[5]，如圖2所示，重點關注NFVFG框架及實現(xiàn)方式、虛擬化功能與物理實體之間映射、虛擬化功能與專用設備之間的協(xié)同等方面，運營商可按照全網(wǎng)絡業(yè)務功能處理性能情況靈活在網(wǎng)絡任意位置進行業(yè)務功能部署。GS NFV-EVE 005關注SFC、SDN及NFV之間的實現(xiàn)關系[6]，基于IETF SFC架構探討SDN控制器引入方式，以及在NFVI環(huán)境下SDN控制器及SFC實現(xiàn)場景，提出運營商多租戶實現(xiàn)方案及跨NFVI實現(xiàn)模型。GS NFV-MAN 001對NFVFG的信息單元進行規(guī)范[7]，制定vnffgd和vnffgr的元數(shù)據(jù)內(nèi)容（metadata），為NFVFG應用提供基礎信息模型。

（4）ITU-T

ITU-T（國際電信聯(lián)盟-電信標準局）是國際電信聯(lián)盟管理下專門制定電信標準的分支機構，主要關注業(yè)務鏈在網(wǎng)絡中的部署模型、各個實體之間的協(xié)議交互以及端到端測試方法論。其中，ITU-T Y-series Recommendations–Supplement 41研究了業(yè)務鏈部署架構及功能要求[8]，并提出線性、遞歸和分支等3種業(yè)務鏈部署模式，同時深入研究直接和間接互聯(lián)場景下業(yè)務路徑選擇策略。ITU-T Y.3512[9]從云計算NaaS角度切入，提出實現(xiàn)業(yè)務鏈的必要條件，包括業(yè)務鏈應用的要求、NaaS對多租戶業(yè)務鏈的安全隔離要求等。在研項目Q.SCO聚焦在端局場景下業(yè)務鏈實現(xiàn)的信令需求，追求更加容易地實現(xiàn)多個系統(tǒng)間的交互，提升部署靈活性。

3.2 開源組織研究進展

開源組織通過原型開發(fā)直接對理論進行驗證，為新技術產(chǎn)品化落地提供共享的第一手材料，近年來得到了極大的發(fā)展。Opendaylight主要聚焦于SFC控制面和轉發(fā)面的協(xié)同和實踐；Openstack主要關注SFC對底層虛擬化資源分配；而OPNFV則關注自頂向下地構建端到端SFC開發(fā)平臺。endprint

（1）Opendaylight

Opendaylight從Helium版本開始支持SFC，其SFC部署架構如圖3所示，通過嵌入SFC數(shù)據(jù)庫并結合南向接口進行SFC業(yè)務的下發(fā)與部署?；诓煌膽脠鼍安捎貌煌哪舷蚪涌冢?/p>

REST Plug-in接口用于從SFC數(shù)據(jù)庫下發(fā)配置（包括ACL、分類器、SF及其群組、SFST（Service Function Schedule Type，服務功能調度類型）、SFF以及RSP（Rendered Service Path，提供服務的路徑））到支持REST API的網(wǎng)絡設備上。

OVSDB接口用于在支持OVSDB的OVS（Open Virtual Switch）上創(chuàng)建SFC組件。控制器部署SFC-OVS功能，將SFC數(shù)據(jù)庫信息映射成OVS（支持OVSDB接口）可識別的組件信息（例如：Bridge/Termination port等），并通過OVSDB MD-SAL接口下發(fā)，從而實現(xiàn)OVS的SFC組件功能創(chuàng)建。

Openflow南向接口用于將控制器SFC數(shù)據(jù)庫中的ACL映射成Openflow規(guī)則，并通過Openflow南向接口下發(fā)到OVS，使其可以通過Openflow規(guī)則來對SFC路徑進行選擇和轉發(fā)。

ODL SFC架構如圖3所示：

為提升業(yè)務鏈集成的便利性，ODL加大對SFC研究投入，主要研究內(nèi)容如下：

1）整合ODL GBP（Group Based Policy，基于組的策略）的研究成果，利用GBP意向性語言、統(tǒng)一映射模型以及統(tǒng)一的接口自動化地將用戶意圖映射到底層網(wǎng)絡，解決了理解應用需求的開發(fā)者和基礎設施團隊之間的脫節(jié)問題。

2）增強SFC分類器對NSH封裝的支持能力，通過Openflow擴展支持NSH，實現(xiàn)基于MAC地址、端口、協(xié)議（TCP、UDP和SCTP）以及IPv4/IPv6的流量分類。

3）深入研究業(yè)務路徑選擇算法，未來將支持隨機（Random）、輪詢（Round Robin）、負載均衡（Load Balancing）與最短路徑（Shortest Path）4種算法。同時通過SF group實現(xiàn)SF負載均衡，使用YANG模型描述SF以及LISP等功能。

4）研究OVS轉發(fā)插件（SFC Openflow Renderer）監(jiān)聽與控制SFC轉發(fā)流程，對SFC路徑所對應的SFF進行編程，通過Pipeline模式將報文牽引至相應的SFC路徑。

（2）ONF

ONF（Open Networking Foundation，開放網(wǎng)絡基金會）致力于SDN的發(fā)展和標準化，在業(yè)務鏈方面的工作主要聚焦于業(yè)務鏈場景下Openflow協(xié)議的擴展和開發(fā)。ONF TS-027[10]基于IETF理論基礎，提出了ONF SFC架構，重點研究SFC信息模型以及各個模塊之間的接口；基于Openflow協(xié)議探討L2-L7流量分類擴展，提出Openflow對NSH的擴展實現(xiàn)，包括Match字段新增OXM_OF_SFCH_PATH_ID和OXM_OF_SFCH_PATH_INDEX支持，并在分類器、轉發(fā)器及業(yè)務功能對新字段支持及動作實現(xiàn)方面進行了詳細的深入研究。同時，ONF TS-027提供SDN實現(xiàn)L2傳輸層業(yè)務鏈的案例和代碼，關注并分析了L5～L7層的業(yè)務鏈實現(xiàn)所面臨的問題，為業(yè)務鏈部署提供了技術參考。

（3）OpenStack

OpenStack是一個開源的云計算管理平臺項目，項目目標是提供實施簡單、可大規(guī)模擴展、豐富、標準統(tǒng)一的云計算管理平臺。OpenStack已被業(yè)界認可為VIM的代表，SFC方面的研究成果在OPNFV的POC項目中得以應用。

OpenStack從網(wǎng)絡編排和配置部署兩個方面針對SFC進行了相關功能的支持和升級：在網(wǎng)絡編排方面，OpenStack通過在TAKCER中內(nèi)置SFC API，并與NFVO/VNFM聯(lián)動來完成SFC的編排與SF生命周期的管理；在配置部署方面，Neutron項目設置業(yè)務嵌入及建鏈研究組（Service Insertion And Chaining）負責研究SFC底層驅動，以先實現(xiàn)自動化配置下發(fā)?，F(xiàn)階段Neutron已實現(xiàn)了與ODL GBP的整合，并計劃在下一個研究周期引入NFP（Network Function Plug-in，網(wǎng)絡功能插件）能力。

（4）OPNFV

OPNFV在基于自身架構的基礎上，結合Openday-light、Openstack以及OVS所推出的開源組件構建自頂向下的端到端SFC開發(fā)平臺，目前已經(jīng)發(fā)布了Brahmaputra[11]和Colorado版本，但其版本更新較大程度上取決于其他組織版本的更新速度。

OPNFV SFC業(yè)務部署架構如圖4所示，研究工作聚焦在網(wǎng)絡編排、VNF管理以及業(yè)務下發(fā)等方面。網(wǎng)絡編排和VNF管理在Brahmaputra版本中使用TACKER，可集成任何第三方的開源VNF Manager管理工具，并支持三種業(yè)務配置下發(fā)模式，以滿足不同部署場景下的需求：

1）在TAKCER中集成ODL SFC驅動，直接實現(xiàn)SFC下發(fā)。ODL SFC驅動通過ODL控制器中的OVSDB向OVS下發(fā)配置，通過netconfig/yang向VNF下發(fā)配置。

2）在TAKER中集成Neutron SFC驅動，并在Neutron中集成OVS驅動，直接實現(xiàn)SFC下發(fā)。

3）在TAKER中集成Neutron SFC驅動，并在Neutron中集成ODL SFC驅動，間接實現(xiàn)SFC下發(fā)。

除了支持以上開源組織發(fā)布版本外，OPNFV還從運營商的角度考慮SFC端到端部署和維護等方面，包括SF生命周期管理、分類器設置（如匹配顆粒度、隧道起點、服務路徑起點、Metadata使用方式）和服務路徑轉發(fā)等方向。在下一個研究周期，OPNFV將開展與OPEN-O和OpenStack Gluon的合作。endprint

4 業(yè)務鏈技術展望

業(yè)務鏈被譽為SDN/NFV的一顆明珠，自提出而來，成為產(chǎn)業(yè)界研究的熱點。雖然標準組織及開源組織開展了一系列的技術研究及原型系統(tǒng)開發(fā)，但整體整合能力較弱，各自實現(xiàn)中嵌入了很多替代技術，成熟通用可推廣的產(chǎn)品暫未面市，未來還需繼續(xù)深化以下方面的研究：

（1）SFC體系架構的深化

SFC編排器、網(wǎng)絡控制器、SF管理等功能界定并沒有標準化，各個功能實體之間的協(xié)議制定和實現(xiàn)也僅僅停留在需求階段。開源組織更多的是按照各自的思路進行實踐，力圖在短時間內(nèi)勘定事實標準，但實際上并不利于運營商SFC體系架構的實現(xiàn)、功能實體的互通以及統(tǒng)一部署。

現(xiàn)有的傳統(tǒng)標準組織在業(yè)務鏈場景與具體端到端解決方案的映射方面存在缺口，開源組織存在業(yè)務鏈具體實現(xiàn)的聯(lián)合協(xié)同問題。由于NSH報文頭格式的引入，新舊業(yè)務功能實體之間出現(xiàn)互通問題。Metadata在各個不同業(yè)務中的使用和攜帶方式?jīng)]有統(tǒng)一的標準，阻礙業(yè)務端到端實現(xiàn)以及OAM的實時監(jiān)測。SFC多種組合和部署模式導致流量優(yōu)化的復雜性，對SF/SFP負載均衡、路徑優(yōu)化、低時延節(jié)能等方面需求更多，需要得到重點關注。

（2）SFC運維管理有待完善

SFC運維管理研究剛提上議程，包括SFC時延、抖動、丟包測量方法、性能測試架構、NSH KPI、OAM機制、多層OAM協(xié)同機制、NSH時間戳、trace問題、OAM的YANG模型、SFC可靠性、故障管理、冗余機制等方面的解決方案，目前還需持續(xù)加大研究力度。

（3）SFC產(chǎn)業(yè)鏈有待重塑

以軟件為核心的SFC發(fā)展促進傳統(tǒng)產(chǎn)業(yè)鏈的重新洗牌，但目前缺乏豐富的SF市場，市面上已有的VNF產(chǎn)品都是各提供商的私有產(chǎn)品，發(fā)展速度落后于市場需求，產(chǎn)業(yè)界應推動公共服務模塊的開源，加速技術發(fā)展。此外，運營商急迫需要SFC實現(xiàn)面向用戶的業(yè)務靈活提供，但受限于業(yè)務模式拓展，當前可應用范圍有限。

5 結束語

本文介紹了業(yè)務鏈基本架構和功能組件，同時對業(yè)界各標準和開源組織的業(yè)務鏈技術研究進展進行了總結和分析，在此基礎上，探討了業(yè)務鏈技術演進趨勢及后續(xù)重點研究方向。綜合來看，業(yè)務鏈將帶來互聯(lián)網(wǎng)產(chǎn)業(yè)的新爆發(fā)點，已得到各方的認可及投入，市場前景潛力巨大。隨著SDN/NFV技術的發(fā)展和引入，如果按照傳統(tǒng)的運營模式對虛擬化系統(tǒng)進行技術要求，在很大程度上將限制新技術的應用與推廣，在新IP領域，DevOps將會成為智慧運營的核心。運營商應結合自身業(yè)務發(fā)展，對業(yè)務流程進行重構，以實現(xiàn)逐個攻破的模式，開展嵌入式研發(fā)，快速推動業(yè)務鏈各項技術的研發(fā)與應用，在實現(xiàn)業(yè)務增長的同時帶動整個產(chǎn)業(yè)鏈的發(fā)展。

參考文獻：

[1] E J Halpern， E C Pignataro. Service Function Chaining （SFC） Architecture[EB/OL]. [2017-04-14]. https：//www.rfc-editor.org/rfc/pdfrfc/rfc7665.txt.

[2] M Boucadair. Service Function Chaining （SFC） Control Plane Components & Requirements[EB/OL]. [2017-04-14]. https：//datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/.

[3] P Quinn， U Elzur. Network Service Header[EB/OL]. [2017-04-14]. https：//datatracker.ietf.org/doc/draft-ietf-sfc-nsh/？include_text=1.

[4] Broadband Forum SD326. Flexible Service Chaining[EB/OL]. [2017-04-14]. http：//www.broadband-forum.org/.

[5] GS NFV 001. Network Functions Virtualisation Use Case[EB/OL]. [2017-04-14]. http：//www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf.

[6] GS NFV-EVE 005. Report on SDN Usage in NFV Architectural Framework[EB/OL]. [2017-04-14]. http：//cn.bing.com/search？q=GS+NFV-EVE+005&go=%E6%90%9C%E7%B4%A2&qs=n&form=QBRE&sp=-1&pq=gs+nfv-eve+005&sc=0-14&sk=&cvid=A46015047C674DA5B8A3502F50ADB3C5.

[7] GS NFV-MAN 001. Network Functions Virtualisation Mana-gement and Orchestration[EB/OL]. [2017-04-14]. http：//www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/

01.01.01_60/gs_NFV-MAN001v010101p.pdf.

[8] ITU-T Y-series Recommendations–Supplement 41. Deployment models of service function chaining[EB/OL]. [2017-04-14]. http：//www.itu.int/dms_pubrec/itu-t/rec/y/T-REC-Y.Sup41-201607-I?。UM-HTM-E.htm.

[9] ITU-T Y 3512. Cloud computing–Functional requirements of Network as a Service[EB/OL]. [2017-04-14]. http：//www.itu.int/rec/T-REC-Y.3512/en.

[10] ONF TS-027. L4-L7 Service Function Chaining Solution Architecture[EB/OL]. [2017-04-14]. https：//www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/L4-L7_Service_Function_Chaining_Solution_Architecture.pdf.

[11] Brady Johnson. OPNFV SFC Brahmaputra Release Planning[EB/OL]. [2017-04-14]. https：//wiki.opnfv.org/display/SWREL/Releases+Brahmaputra+Release+Plan. ★endprint