羅光峰，李奕群，陳慧光

?

面向隨選網(wǎng)絡的業(yè)務編排系統(tǒng)研發(fā)實踐

羅光峰，李奕群，陳慧光

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

為滿足SDN/NFV時代業(yè)務快速上線的要求，需要對現(xiàn)有網(wǎng)絡運營系統(tǒng)進行重構，以隨選網(wǎng)絡業(yè)務的實踐為背景，詳細介紹了編排器在運營系統(tǒng)中的定位與作用，然后闡述了編排器的核心設計思路以及核心組件工作流引擎。

隨選網(wǎng)絡；SDN；NFV；編排器；運營支撐系統(tǒng)

1 引言

美國運營商AT&T在網(wǎng)絡重構中，提出了Domain2.0和ECOMP架構，旨在通過網(wǎng)絡的虛擬化和集中控制提升業(yè)務開通和運維的自動化，從而提升客戶體驗。在NFV領域中，ETSI（European Telecommunications Standards Institute，歐州電信標準化協(xié)會）標準組織定義了相關軟件框架MANO（NFV management and orchestration，NFV管理和編排），包含orchestrator（編排器）、VNF管理器和VIM（virtualized infrastructure manager，虛擬設施管理器）。ECOMP中的MSO（master service orchestrator，主業(yè)務編排器）就承擔了MANO中NFVO的角色。另有Verizon公司的SDN/NFV計劃，目標是同時考慮SD-WAN和NFV的業(yè)務需求，通過構建一個端到端編排器（end-to-end orchestrator），實現(xiàn)跨SDN與NFV的端到端的業(yè)務。

在SDN/NFV技術時代，各大運營商都有各自的技術演進計劃。其中一個重要目標就是通過新技術、新網(wǎng)絡體系實現(xiàn)隨選網(wǎng)絡業(yè)務。隨選網(wǎng)絡指在業(yè)務層面提供客戶自主定義網(wǎng)絡業(yè)務的功能，在配置層面實現(xiàn)業(yè)務對應的網(wǎng)絡配置自動化、網(wǎng)絡資源按需指配。在業(yè)界的技術發(fā)展中，給負責實現(xiàn)業(yè)務層面自動配置功能的子系統(tǒng)命名為“編排器”。Linux基金會在2015年成立了針對編排器的開源項目Open-O，2017年初AT&T 開源了其ECOMP系統(tǒng)，Open-O項目與ECOMP合并，更名為ONAP項目，并吸引了更多運營商、設備廠商、芯片廠商的加入，共同推動編排器的設計和實現(xiàn)。

本文針對SDN/NFV時代對網(wǎng)絡運營系統(tǒng)的要求，分析了編排器設計的目標，提出了一種業(yè)務編排器的架構設計和實現(xiàn)方案，并通過開發(fā)實踐，對編排器做出了驗證，可為下一代運營系統(tǒng)的設計提供參考。

2 隨選網(wǎng)絡系統(tǒng)中的業(yè)務編排

圖1 業(yè)務編排在系統(tǒng)中的位置

編排一詞在維基百科中的定義如下：編排在計算領域主要指通過相應的工具、架構和過程部署（開通）一個業(yè)務，此過程涉及的軟件與硬件統(tǒng)一部署，需要支持自動化的工作流程。

在隨選網(wǎng)絡系統(tǒng)中，編排器承擔著業(yè)務設計、開發(fā)/實現(xiàn)、上線、開通、變更、關閉、下線整個生命周期的管理職責，業(yè)務編排在系統(tǒng)架構中的位置如圖1所示。

在業(yè)務的生命周期中，編排器需要滿足業(yè)務的靈活設計與快速上線要求，為業(yè)務編排設計人員（通常為網(wǎng)絡運維人員）提供用戶友好的設計工具，滿足業(yè)務定義的直觀、準確、可測試等特性；業(yè)務編排將接收客戶訂購的請求，并將其分解為預定義的工作流程，在流程中通過調用已有的原子能力實現(xiàn)每一個步驟。例如其中涉及配置相關的步驟，需要調用與控制器相對應的原子能力，通過控制北向接口將配置指令下達控制器，并由控制器負責最終的執(zhí)行。在業(yè)務開通流程中力求無人工參與，從而大幅縮短開通時限。業(yè)務開通流程中編排器的角色和其他系統(tǒng)的配合示例如圖2所示。

圖2 自動化的業(yè)務開通流程示例

3 通過工作流引擎實現(xiàn)資源編排

編排器對外提供的業(yè)務編排功能基于工作流引擎，當出現(xiàn)新的業(yè)務場景時，系統(tǒng)可對現(xiàn)有能力進行重新組合，快速生成新業(yè)務以滿足需求。運營人員通過可視化的拖拽、連線的操作，完成業(yè)務需要的配置。

工作流引擎主要由以下4個模塊組成。

（1）服務目錄

用于存儲系統(tǒng)支持哪些功能、每個功能有哪些接口、接口中有哪些參數(shù)、參數(shù)類型等。

（2）設計器

提供UI，并能從服務庫中選擇服務進行組合，形成需要的業(yè)務配置序列，存儲成業(yè)務模板。

（3）校驗器

對設計好的流程和模板進行測試驗證，發(fā)現(xiàn)潛在的錯誤或缺陷。

（4）執(zhí)行器

加載一個由設計器生成的業(yè)務模板，按照模板的描述執(zhí)行一系列操作，完成業(yè)務配置。

工作流引擎組成與工作原理如圖3所示。

對以上工作過程解釋如下。

步驟1 能力編排引擎從一個公共的服務庫（后述）中獲取系統(tǒng)可用的服務以及每個服務的接口規(guī)格，形成自己的服務庫。

步驟2 當運營人員需要設計一個工作流時，設計器可從服務目錄中讀取可用服務（并展示于UI），供設計人員使用。

步驟3 設計人員使用設計UI，通過拖拽服務及連線（接口調用），完成一個業(yè)務場景需要的流程設計。其中，接口調用過程需要指定必要I/O參數(shù)，這些參數(shù)的規(guī)格（類型、可取值范圍等），須從服務目錄中獲取，并在UI中進行展示約束。

步驟4 設計完成的工作流，進入校驗階段。通過自動化測試腳本，對工作流進行測試驗證。若發(fā)生錯誤，工作流返回設計器，需要設計人員進行調整和更正。

步驟5 校驗成功的工作流進入執(zhí)行器，具備運行條件。應用層通過執(zhí)行器提供的API可啟動某個工作流的執(zhí)行，完成配置。

步驟6 工作流的執(zhí)行可被監(jiān)控，并可根據(jù)需要由系統(tǒng)定時或事件觸發(fā)。

圖3 工作流引擎組成與工作原理

4 業(yè)務編排的兩態(tài)（開發(fā)態(tài)與運行態(tài)）

編排器管理業(yè)務的全生命周期，涉及開發(fā)態(tài)和運行態(tài)。業(yè)務的設計、開發(fā)/實現(xiàn)屬于開發(fā)態(tài)，業(yè)務的開通、變更、關閉屬于運行態(tài)。業(yè)務編排的兩態(tài)在編排器中通過DevOps平臺實現(xiàn)無縫的銜接，通過在DevOps平臺中定制業(yè)務編排相關工具（例如模型語法分析與測試、運行環(huán)境與開發(fā)環(huán)境數(shù)據(jù)的同步等），實現(xiàn)業(yè)務從開發(fā)到部署的全流程自動化、持續(xù)化。業(yè)務編排兩態(tài)示意如圖4所示。

業(yè)務編排通過開發(fā)態(tài)和運行態(tài)以及DevOps平臺實現(xiàn)業(yè)務的全生命周期管理，依賴于以下能力。

圖4 業(yè)務編排兩態(tài)示意

（1）業(yè)務編排的基礎是良好定義的原子能力

?·?從業(yè)務編排的視角看，所有能夠在業(yè)務編排中調用的服務都是原子能力。

?·? 原子能力依照提供方大致可以分為網(wǎng)絡類原子能力（例如通過Device YANG實現(xiàn)網(wǎng)元的配置）、NFV/云類原子能力（例如通過TOSCA VNFD拉起VNF）、資源類原子能力（例如電路資源的查詢與預占）、服務保障類原子能力（例如業(yè)務的端到端測試）。

（2）端到端編排依賴于全面準確的資源清單在業(yè)務的開通流程中，總是需要資源的申請（例如IP地址），這些資源的申請需要自動化完成，資源管理模塊承擔著相關職責，并通過接口為業(yè)務編排模塊提供相應的原子能力。

（3）業(yè)務編排提供靈活性與復雜性的平衡

??·?通過主工作流的編排，實現(xiàn)業(yè)務開通流程的定義與管理，可以適應不同業(yè)務不同組織的定制化要求。

??·?子工作流、NFV-NS、SDN-service YANG都可以整合細粒度的原子能力，并能夠提供事務（例如回滾操作）的支持，作為主工作流的一個步驟（在workflow中定義的一個task）。

5 隨選網(wǎng)絡編排器開發(fā)實踐

在編排器原型系統(tǒng)實現(xiàn)中，OpenStack的Mistral組件因其輕量、簡單、易于集成和二次開發(fā)的特點，被用于實現(xiàn)核心編排能力的workflow引擎基礎。Mistral引擎基于YAML定義了一套workflow模型語言，并采用了YAQL作為數(shù)據(jù)處理的模板語言，當前版本為2.0，Mistral的模型語言語法簡潔、易于理解、支持任務執(zhí)行結果的檢查和條件分支控制，可以滿足編排引擎的功能需求。

然而，要達到前述的“可視化”和“兩態(tài)”的轉換，還需要對其進行擴展。首先，需要一個可視化設計器，網(wǎng)絡運維人員使用該設計器，通過拖拽和連線，即能完成一個業(yè)務場景的設計。更重要的是，雖然Mistral的workflow模型語言語法簡潔，但運維人員使用編輯器手動編寫，不僅效率低，且容易出錯。這就需要設計器不僅具備可視化，而且能夠自動生成Mistral的workflow模型語言。其次，要實現(xiàn)上述的拖拽，首先要具備一個“服務庫”，服務庫的每個服務就是一個可拖拽的組件。因此，需要設計器能夠從服務庫獲取服務描述，并解析出需要的信息，供設計人員使用。例如，一個服務的接口，需要何種參數(shù)，參數(shù)類型是string還是integer，參數(shù)允許何種取值范圍等。這些約束，必須在服務描述模型中包含。所以，這點要求，需要服務庫“生成”這種模型，設計器解析模型來展現(xiàn)。最后，工作流需要一個運行狀況的可視化，當一個工作流編寫驗證完成，從開發(fā)態(tài)進入運行態(tài)，需要對其運行狀態(tài)進行監(jiān)控和展現(xiàn)。便于在發(fā)生錯誤的時候，由專業(yè)人員定位和解決問題。

同時，為了滿足編排的需要，編排器的核心能力集必須原子化、組件化。這不僅滿足了編排引擎的需要，而且由于各個原子能力的自治、解耦，給系統(tǒng)的分布式部署、獨立負載均衡帶來了極大方便。本次原型開發(fā)，采用了微服務架構實現(xiàn)了編排器的核心服務庫。為實現(xiàn)這些服務的管理，引入統(tǒng)一的微服務總線（microservice bus，MSB）。微服務向MSB注冊自己的接口信息和節(jié)點信息，MSB負責管理微服務的負載均衡、故障檢測，對微服務接口的調用，也是經(jīng)由MSB代理轉發(fā)。最后，上述工作流的設計器需要的服務庫，也由MSB統(tǒng)一導出。從實現(xiàn)上，MSB采用業(yè)界經(jīng)典的Nginx作為基礎服務調用代理模塊，通過擴展的OpenResty插件，完成服務的管理。

值得提出的是，為了方便開發(fā)，保持與工作流引擎的一致性，微服務開發(fā)的數(shù)據(jù)建模，也采用了基于YAML的Swagger標準。開發(fā)態(tài)和運行態(tài)，以YAML語言作為基礎傳遞信息。

對于編排器來說，南向要對接各種設備廠商的控制器或者設備。這些廠商的接口規(guī)格通常有較大差別。因此，在編排器實踐中，采用一個驅動層（driver），將各個廠商的接口統(tǒng)一抽象成公共模型。這樣，微服務層即可針對該抽象模型進行無差異編排。

隨選網(wǎng)絡的編排器實現(xiàn)的開發(fā)架構如圖5所示。

為了驗證在實際的生產(chǎn)環(huán)境下，上述設計是否符合業(yè)務需求，檢驗業(yè)務編排系統(tǒng)架構是否滿足設計目標，需要從以下兩個方面進行。

? 需要滿足業(yè)務需求：業(yè)務模型的定義、業(yè)務開通、業(yè)務變更、業(yè)務關閉。

? 需要滿足運維管理需求：業(yè)務流程執(zhí)行過程的監(jiān)控、業(yè)務執(zhí)行過程故障的檢查、系統(tǒng)擴展、系統(tǒng)運維管理。

在實際驗證過程中，為了更貼近實際業(yè)務需求，在實施方案中采用一個典型的業(yè)務場景作為業(yè)務需求，用于驗證業(yè)務編排系統(tǒng)。圖6給出了一個在園區(qū)通過一個虛擬化網(wǎng)元vCPE，為客戶提供site-to-internet的場景。

圖5 隨選網(wǎng)絡的編排器實現(xiàn)的開發(fā)架構

圖6 園區(qū)隨選業(yè)務開通流程示意

在實際驗證環(huán)境中按照實際生產(chǎn)環(huán)境進行部署，系統(tǒng)完整支持熱備份和集群，業(yè)務編排系統(tǒng)包含了幾個關鍵組件。

（1）設計態(tài)

服務目錄管理：為了實現(xiàn)直觀便捷的編排，所有業(yè)務編排系統(tǒng)中的微服務接口是通過Swagger規(guī)范定義的，這些接口需要登記到服務目錄中，用于輔助設計器的實現(xiàn)。

工作流設計器：通過圖形化的界面，為運維人員提供可視化的工作流編排設計工具，管理設計好的工作流模板，并將確認版本發(fā)布到工作流引擎。

（2）運行態(tài)

? 微服務總線：業(yè)務編排系統(tǒng)完全基于微服務架構實現(xiàn)，所有的功能模塊和驅動以微服務的方式開發(fā)和部署，微服務總線實現(xiàn)了微服務的注冊、路由和負載均衡。

? 工作流引擎：基于OpenStack的Mistral引擎，為了滿足業(yè)務編排中訂單處理的需求，對引擎進行了擴展，用以實現(xiàn)工作流執(zhí)行的控制和工作流執(zhí)行信息的通知。

? 北向接口和訂單處理：API、訂單校驗與分析、訂單監(jiān)控、在途訂單管理。

? 微服務：資源管理、租戶管理、路由管理、VPN配置、QoS配置、接口配置。

? 南向驅動層：實現(xiàn)了多廠商（中興、華為、華三）SDN控制器的適配。

驗證結果記錄如下。

步驟1 完成業(yè)務編排系統(tǒng)的搭建，所有的微服務都要完成部署和測試，并注冊到微服務總線。

步驟2 完成服務目錄的更新，將所有的微服務登記到服務目錄中，并完成適當?shù)淖⑨屨f明，比如輸入/輸出參數(shù)的中文簡介、是否為異步調用接口等。

步驟3 使用設計器完成業(yè)務模型的定義，通過圖形化的界面，拖拽服務目錄中的服務項作為工作流模型中的任務，并實現(xiàn)任務之間的先后順序，完成任務中服務需要的參數(shù)配置。

VPN業(yè)務開通工作流模板樣例如圖7所示，工作流的模型以YAML格式保存。

這個工作流模型中定義了多個任務，任務采用了順序執(zhí)行方式，首先執(zhí)行的是task1，當task1執(zhí)行成功后，執(zhí)行task2，然后是task3。從工作流模型中可以看到，工作流中的一個任務就是調用一個微服務，微服務的調用都是通過微服務總線的統(tǒng)一入口實現(xiàn)，微服務的數(shù)據(jù)輸入?yún)?shù)都可以在模型中指定，微服務的輸出亦可以保存并用于后續(xù)任務。

步驟4 通過用戶門戶，用戶可以訂購產(chǎn)品，并將訂單發(fā)送給業(yè)務編排系統(tǒng)。

步驟5 業(yè)務編排系統(tǒng)接收到訂單后，通過訂單處理查詢并確認通過哪一個工作流模型實現(xiàn)

version: '2.0' serviceopenworkflow: description: workflow type: direct input: - ORDER_IPVPN tasks: task1: action: yihe.sync input: headers: Content-Type: application/json method: post body: orderid: <% $.ORDER_IPVPN.get(orderId) %> atom: Bisop.OrderOrcha.iomReviewOrderInfo url: http://172.18.1.105:8080/iom/reviewOrderInfo publish: task1_r: <% task(task1).result.content %> on-success: - task2 task2: action: yihe.async input: headers: Content-Type: application/json method: post body: dispatchType: <% $.ORDER_IPVPN.get(OperType) %> totalInterVPC: <% $.ORDER_IPVPN.get(TotalInterVPC) %> vpcIdZ: '' ctYUNRegEmail: <% $.ORDER_IPVPN.get(CTYUNRegEmail) %> speedA: <% $.ORDER_IPVPN.get(AppSpeedA) %> yunResCityA: <% $.ORDER_IPVPN.get(YUNCityA) %> routeProtocol: <% $.ORDER_IPVPN.get(RoutProtocol) %> custId: <% $.ORDER_IPVPN.get(CustId) %> vpnNetCode: <% $.ORDER_IPVPN.get(vpnNbr) %> ctYUNACCNBR: <% $.ORDER_IPVPN.get(CTYUNACCNBR) %> netStruct: <% $.ORDER_IPVPN.get(Networkexp) %> ceIpA: <% $.ORDER_IPVPN.get(VPC_IPSegmentA) %> yunRespoolldZ: '' yunRespoolIdA: <% $.ORDER_IPVPN.get(YUNNameA) %> formType: <% $.ORDER_IPVPN.get(FormType) %> comments: <% $.ORDER_IPVPN.get(ProjectRemark) %> speedZ: '' yunResCityZ: '' changeType: '' vpcIdA: <% $.ORDER_IPVPN.get(VPCIDA) %> custName: <% $.ORDER_IPVPN.get(CustName) %> proInstId: <% $.ORDER_IPVPN.get(CircuitID) %> workId: <% $.ORDER_IPVPN.get(orderId) %> centerPoint: <% $.ORDER_IPVPN.get(CenterPoint) %> vpnLinkCode: '' ceIpZ: '' workType: <% $.ORDER_IPVPN.get(ProductID) %> atom: Bisop.OrderOrcha.cloudResourceRequest url: http:// 172.18.1.105:8080/CloudClientService/cloudResourceRequest publish: task2_r: <% task(task2).result.content %> on-success: - task3…

此訂單，然后通過工作流引擎的接口啟動相應的流程。

步驟6 工作流引擎將依據(jù)模型中定義的步驟和任務執(zhí)行的條件逐一完成任務。

步驟7 工作流引擎在執(zhí)行過程中會通過通知訂單，處理任務執(zhí)行的進展情況和結果。

步驟8 用戶門戶隨時可以通過北向接口獲得訂單執(zhí)行的進展情況，并向用戶展示。

在業(yè)務驗證過程中，完成全部業(yè)務流程的實現(xiàn)，包括業(yè)務開通、業(yè)務變更、業(yè)務關閉，也包括了一些異常流程的驗證，例如業(yè)務開通過程中的停開、業(yè)務開通過程中異常情況的處理等。

在完成的驗證過程中，異常情況的處理最為復雜，例如任務的執(zhí)行異常，需要重新執(zhí)行，在重新執(zhí)行時還需要修改任務的輸入?yún)?shù)，Mistral開源項目并不完全支持，需要通過擴展實現(xiàn)。

通過開發(fā)實踐，對業(yè)務編排系統(tǒng)的設計做出了驗證，基本滿足了最初對業(yè)務編排的要求。

新系統(tǒng)架構帶來的優(yōu)勢如下。

? 工作流引擎不僅實現(xiàn)了控制流的調度管理，同時實現(xiàn)了數(shù)據(jù)流的傳遞，可以結合微服務總線完美實現(xiàn)對微服務的調用。

? 微服務作為基礎能力可以通過工作流方式完成編排，有利于微服務的重用。

? 微服務由于實現(xiàn)的是基礎功能，功能需求穩(wěn)定變化少，對應的微服務軟件版本穩(wěn)定，通過編排隨時可以為新的業(yè)務需求創(chuàng)建工作流模板，無需編寫軟件代碼，即可為新業(yè)務提供服務。

? 在實踐驗證過程，對工作流引擎進行了必要的擴展。

? 通過對開源項目的擴展，實現(xiàn)了異常情況下任務的干預（重試），對工作流的執(zhí)行實現(xiàn)回滾操作。

現(xiàn)有業(yè)務編排系統(tǒng)版本還有如下不足。

? 開源的工作流引擎在性能方面存在不足，雖然執(zhí)行集群方式的水平擴展，但是單機的壓力測試表明，高并發(fā)下的流程啟動處理能力不足，還無法滿足大型項目的需求。需要對工作流引擎進行重構才能實現(xiàn)單機性能的提升。

? 在實踐過程中，遇到了不同種類的業(yè)務，既有低數(shù)量耗時長（以天為單位）的長流程，也有高并發(fā)耗時短（以秒為單位）的短流程，目前的流程引擎采用公平原則進行處理，對于需要盡快處理的訂單，無法確保優(yōu)先執(zhí)行。建議通過劃分資源分區(qū)的方式對不同類型的流程進行單獨處理。

? 通過圖形化的界面和服務目錄結合使用，已經(jīng)可以設計工作流模型，但是在設計過程中對于任務的輸入/輸出參數(shù)的配置還稍顯復雜，對于運維人員要求較高，需要理解微服務的概念。

? 運維工具不足，開源項目提供的運維工具只實現(xiàn)了查詢和管理基本功能，無法提供統(tǒng)計、監(jiān)控和聯(lián)合查詢等需求，也沒有與統(tǒng)一運維框架（例如Zabbix）結合。

6 結束語

本文所描述的編排器在設計上參考了國際標準最新進展及業(yè)界網(wǎng)絡運營系統(tǒng)的實踐。通過面向工作流的編排引擎，組合基礎設施能力形成業(yè)務能力，實現(xiàn)業(yè)務與資源的映射；通過模板化的NFV和業(yè)務建模，規(guī)范化研發(fā)實現(xiàn)，提高系統(tǒng)的可維護和可擴展能力。構建開發(fā)和運營的雙態(tài)系統(tǒng)，使得業(yè)務需求能迅速轉化成系統(tǒng)能力，不斷擴充業(yè)務場景，實現(xiàn)自身的迭代演進。

該系統(tǒng)未來將在實際運行中根據(jù)需求持續(xù)優(yōu)化，支持隨選網(wǎng)絡系統(tǒng)形態(tài)和相關業(yè)務形態(tài)分步分階段地演進。同時通過積極加入業(yè)界開源組織，吸納先進設計理念，并將自身創(chuàng)新成果貢獻于開源項目，實現(xiàn)開放共贏，共同推動網(wǎng)絡技術革新和重構。

[1] IETF. YANG-a data modeling language for the network configuration protocol (NETCONF): RFC6020[S]. 2010.

[2] IETF. NETCONF configuration protocol: RFC4741[S]. 2006.

[3] Wikipedia. Orchestration[EB/OL]. (2016-09-20)[2017-11-10]. https://en.wikipedia.org/wiki/Orchestration_(computing).

[4] 何曉明, 冀暉, 毛東峰, 等. 電信IP網(wǎng)向SDN演進的探討[J]. 電信科學, 2014, 30(6): 131-137.

HE X M, JI H, MAO D F, et al. Discussion of evolution of carrier IP network to SDN[J]. Telecommunications Science, 2014, 30(6): 131-137.

[5] 顧戎, 王瑞雪, 李晨, 等. 云數(shù)據(jù)中心SDN/NFV組網(wǎng)方案、測試及問題分析[J]. 電信科學, 2016, 32(1): 126-130.

GU R, WANG R X, LI C, et al. Analysis on network scheme and resolution test of SDN/NFV technology co-deployed in cloud datacenter[J]. Telecommunications Science, 2016, 32(1): 126-130.

[6] 馬書惠, 毋濤. NFV標準與開源技術現(xiàn)狀[J]. 電信科學, 2016, 32(3): 43-47.

MA S H, WU T. Standards and open source technology of NFV[J]. Telecommunications Science, 2016, 32(3): 43-47.

[7] 張松. 精益軟件度量——實踐者的觀察與思考[M]. 北京: 人民郵電出版社, 2013.

ZHANG S. Lean software measurement-observer’s observation and reflection[M]. Beijing: Posts&Telecom Press, 2013.

[8] NEWMAN S. Building microservices[M]. Sebastopol: O’Reilly Media, 2015.

R&D practice of service orchestration system for on-demand network

LUO Guangfeng, LI Yiqun, CHEN Huiguang

Beijing Research Institute of China Telecom Co., Ltd., Beijing 102209, China

In order to meet the requirements of services quickly on line in the SDN/NFV era, existing network operating system needs to be refactored. Based on the background of the practice of on-demand network services, R&D practice of orchestrator for on-demand network service was introduced, then the orchestrator’s role in software system architecture was explained in detail.

on-demand network, software defined networking, network function virtualization, orchestrator, operation support system

TN929

A

10.11959/j.issn.1000?0801.2017327

2017?11?10；

2017?12?08

羅光峰（1973?），男，中國電信股份有限公司北京研究院軟件工程師，主要研究方向為SDN領域軟件架構與實現(xiàn)。

李奕群（1975?），男，中國電信股份有限公司北京研究院軟件工程師，主要從事隨選網(wǎng)絡編排器、控制器相關開發(fā)工作。

陳慧光（1985?），男，中國電信股份有限公司北京研究院軟件工程師，主要從事隨選網(wǎng)絡編排器、控制器相關開發(fā)工作。