業務鏈研究進展及技術展望

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

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

【關鍵詞】業務鏈 流分類器 NSH

1 引言

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

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

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

2 SFC關鍵技術

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

業務鏈主要包括以下關鍵部件：

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

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

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

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

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

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

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

3 SFC研究進展

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

3.1 標準組織研究進展

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

（1）IETF

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

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

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

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

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

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

（2）BBF

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

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

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

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

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

（3）ETSI

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

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

（4）ITU-T

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

3.2 開源組織研究進展

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

（1）Opendaylight

Opendaylight從Helium版本開始支持SFC，其SFC部署架構如圖3所示，通過嵌入SFC數據庫并結合南向接口進行SFC業務的下發與部署。基于不同的應用場景采用不同的南向接口：

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

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

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

ODL SFC架構如圖3所示：

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

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

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

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

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

（2）ONF

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

（3）OpenStack

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

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

（4）OPNFV

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

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

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

2）在TAKER中集成Neutron SFC驅動，并在Neutron中集成OVS驅動，直接實現SFC下發。

3）在TAKER中集成Neutron SFC驅動，并在Neutron中集成ODL SFC驅動，間接實現SFC下發。

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

4 業務鏈技術展望

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

（1）SFC體系架構的深化

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

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

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

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

（3）SFC產業鏈有待重塑

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

5 結束語

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

參考文獻：

[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！！SUM-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