魯子奕　楊文斌

摘要：研究了運營商重構(gòu)新一代云網(wǎng)協(xié)同架構(gòu)所涉及的關(guān)鍵技術(shù)，從架構(gòu)角度出發(fā)，提出了從業(yè)務(wù)編排器、軟件定義網(wǎng)絡(luò)（SDN）協(xié)同器和服務(wù)提供者接口（SPI）到云商應(yīng)用程序編程接口（API）的設(shè)計要點。同時，還深入研究了分段路由隧道（SRTE）、虛擬可擴展局域網(wǎng)（VXLAN）、軟件定義廣域網(wǎng)（SD-WAN）和接入點（PoP）探測等前沿云網(wǎng)網(wǎng)絡(luò)技術(shù)，提出了如何將這些技術(shù)進行整合以實現(xiàn)統(tǒng)一SDN的調(diào)度和管理。

關(guān)鍵詞：云網(wǎng)協(xié)同;SDN編排器;SPI;SD-WAN;VXLAN;SRTE;PoP探測

Abstract： In this paper， the key technologies involved in the reconstruction of a new generation of cloud network architecture for service provider are studied， and the design points of the cloud network orchestration， software defined network （SDN） coordinator， service provider framework （SPI）， and application program interface （API） are put forward. The cloud network technologies including segmented routing tunnel （SRTE）， virtual extensible local area network （VXLAN）， software defined wide area network （SD-WAN） and point-to-point （POP） detection are also studied. To realize unified SDN scheduling and management， the way to integrate above technologies is proposed.

Key words： cloud network; SDN orchestration; SPI; SD-WAN; VXLAN; SRTE; PoP detection

云計算這一嶄新的計算形態(tài)已經(jīng)被大眾所接受，它不依賴單個物理中央處理器（CPU）的縱向計算能力，而是通過網(wǎng)絡(luò)橫向的平臺能力使邏輯資源池的使用和擴展更加方便、靈活。從某種技術(shù)意義上來看，網(wǎng)絡(luò)抽象和延展了分布的物理計算資源，云計算的本質(zhì)就是網(wǎng)絡(luò)計算。從此，計算和網(wǎng)絡(luò)原本2個相對獨立的創(chuàng)新引擎，在技術(shù)能力和規(guī)模效益上得以相互借鑒、相互依存和相互激勵，雙引擎疊加成就了今天信息通信（IT）產(chǎn)業(yè)的飛速發(fā)展。

計算和網(wǎng)絡(luò)雙引擎疊加該如何實現(xiàn)？網(wǎng)絡(luò)如何更好地為云計算提供服務(wù)和支撐，對于傳統(tǒng)運營商來說，還面臨巨大的挑戰(zhàn)。中國運營商網(wǎng)絡(luò)能力未抽象，自動化程度低，難以適應(yīng)互聯(lián)網(wǎng)業(yè)務(wù)快速調(diào)整的需求;因此，如何實現(xiàn)云網(wǎng)協(xié)同，是目前中國運營商、互聯(lián)網(wǎng)應(yīng)用服務(wù)（OTT）和云商非常關(guān)心的話題。近些年，軟件定義網(wǎng)絡(luò)（SDN）技術(shù)的出現(xiàn)，給傳統(tǒng)運營商帶來夢寐以求的、靈活快捷的技術(shù)架構(gòu);但如何實現(xiàn)在運營商內(nèi)部大規(guī)模運行的骨干網(wǎng)絡(luò)SDN部署？如何在異構(gòu)和多廠商環(huán)境部署？如何與云商自動化協(xié)同對接？這些都是我們需要考慮的問題。我們將討論運營商重構(gòu)新一代云網(wǎng)協(xié)同架構(gòu)和技術(shù)實踐。

1 運營商SDN云網(wǎng)協(xié)同架構(gòu)

的業(yè)務(wù)需求

基礎(chǔ)運營商擁有最豐富的光纖和線路網(wǎng)絡(luò)資源;但如何通過SDN、網(wǎng)絡(luò)功能虛擬化（NFV）、云技術(shù)或網(wǎng)絡(luò)新技術(shù)整合運營商現(xiàn)有的優(yōu)勢資源（骨干網(wǎng)、城域網(wǎng)、互聯(lián)網(wǎng)以及各類云資源），加快推動向“新服務(wù)”運營商轉(zhuǎn)型，重構(gòu)網(wǎng)絡(luò)基礎(chǔ)架構(gòu)，以開放姿態(tài)建設(shè)未來網(wǎng)絡(luò)，為用戶提供端到端一站式靈活的解決方案，成為了運營商研究的新課題。尤其是新型計算提供商，追求的已是資源秒級響應(yīng)并按秒計費，而傳統(tǒng)運營商還是靠手工或傳統(tǒng)方式開通業(yè)務(wù)甚至以月為單位。如何根本性改變現(xiàn)有業(yè)務(wù)模式，實現(xiàn)面向云業(yè)務(wù)的靈活調(diào)度、快速部署，也成為運營商關(guān)注的新課題。目前，運營商面臨著如以下的挑戰(zhàn)和需求[1-3]：

（1）骨干網(wǎng)絡(luò)需要靈活調(diào)度、快速部署;因此，運營商需要改變現(xiàn)有業(yè)務(wù)流程和模式，以滿足用戶快速靈活的上云業(yè)務(wù)需求。

（2）運營商大多采用多廠商設(shè)備，現(xiàn)有廠商的設(shè)備有的不支持SDN（雖可逐步替換，但代價沉重），另外，即使各廠商具備SDN能力，控制器是各廠商私有的;因此，如何實現(xiàn)云網(wǎng)協(xié)同和資源統(tǒng)一管理是個巨大挑戰(zhàn)。

（3）從運營商的網(wǎng)絡(luò)接入、骨干到云端，會用到截然不同的網(wǎng)絡(luò)技術(shù)，如何通過云網(wǎng)協(xié)同技術(shù)實現(xiàn)更貼近用戶、更適于跨域部署的云資源布局，讓用戶可以一點接入、多點部署、全網(wǎng)服務(wù)，也需要運營商重點考慮。

（4）重構(gòu)云網(wǎng)協(xié)同架構(gòu)，需要運營商建立云網(wǎng)一體化新生態(tài)。運營商網(wǎng)絡(luò)資源與各家云商對接上的應(yīng)用程序編程接口（API）規(guī)范和標準差別很大，需要考慮如何采用高效通用的南向接口實現(xiàn)對接。

2 運營商云網(wǎng)協(xié)同業(yè)務(wù)面臨

的挑戰(zhàn)

近幾年來，全球電信業(yè)普遍認可基于SDN云網(wǎng)協(xié)同技術(shù)對運營商的戰(zhàn)略意義和商用價值;但是，真正大規(guī)模骨干網(wǎng)絡(luò)部署基于SDN云網(wǎng)協(xié)同編排的落地商用方案并不多見，原因在于運營商骨干網(wǎng)SDN的研發(fā)和工程實踐技術(shù)挑戰(zhàn)仍然很大。項目從立項到開發(fā)的過程面臨許多不確定性，導(dǎo)致研發(fā)周期延長，從而加大項目的風險。結(jié)合大地云網(wǎng)科技過去3年與多種類型的服務(wù)商客戶的合作及部署的實際經(jīng)驗，我們整理和分析運營商云網(wǎng)業(yè)務(wù)面臨的主要挑戰(zhàn)：

（1）異構(gòu)網(wǎng)絡(luò)SDN項目技術(shù)研發(fā)難度大，復(fù)雜度高，且無先例。運營商大型骨干網(wǎng)絡(luò)往往是由不同廠商、不同技術(shù)路線和不同產(chǎn)品設(shè)備所組成的分布式異構(gòu)網(wǎng)絡(luò)系統(tǒng)。在由多廠商高端路由設(shè)備組成的骨干網(wǎng)絡(luò)上完成SDN架構(gòu)和技術(shù)實施仍是世界性的技術(shù)難題。SDN的控制、管理、協(xié)同和業(yè)務(wù)編排不僅涉及到不同廠商的不同網(wǎng)絡(luò)設(shè)備和軟件架構(gòu)功能的分工協(xié)作，還涉及到運營商的業(yè)務(wù)、產(chǎn)品、運營和市場等多方面不同需求的滿足。網(wǎng)絡(luò)能力的抽象和模型化技術(shù)極其復(fù)雜，設(shè)計師必須掌握多領(lǐng)域最新技術(shù)的系統(tǒng)整合設(shè)計，并具有創(chuàng)新實踐的能力和經(jīng)驗。

（2）運營商SDN研發(fā)項目溝通協(xié)調(diào)工作量巨大，資源消耗大。眾所周知，運營商SDN項目將網(wǎng)絡(luò)控制、轉(zhuǎn)發(fā)和管理平面重新劃分與規(guī)范，集中與分布控制的機理在運營商現(xiàn)網(wǎng)SDN改造中不僅面臨接口多，接口規(guī)范不確定、不統(tǒng)一等現(xiàn)實情況，項目研發(fā)的溝通協(xié)調(diào)工作量大，難度大。針對運營商異構(gòu)網(wǎng)絡(luò)SDN架構(gòu)的實施，國際上成功的案例也不多，目前的現(xiàn)狀為：多設(shè)備競爭廠商的網(wǎng)絡(luò)設(shè)備開發(fā)、網(wǎng)絡(luò)操作系統(tǒng)、SDN的架構(gòu)、技術(shù)路線、軟件實現(xiàn)機制、API及軟件數(shù)據(jù)庫，以及其研發(fā)進度完全不同，常會使得SDN技術(shù)架構(gòu)的設(shè)計工作的溝通和協(xié)調(diào)異常艱難。

（3）項目開發(fā)需求多，變化大，風險高，周期長，需有超前的預(yù)見性。由于云網(wǎng)協(xié)同和SDN項目核心軟件的開發(fā)和實現(xiàn)會涉及運營商內(nèi)部多個業(yè)務(wù)部門，針對這些業(yè)務(wù)需求，運營商的不同部門在不同時間點可能有不同的理解。SDN軟件系統(tǒng)平臺研發(fā)團隊必須確保系統(tǒng)架構(gòu)對業(yè)務(wù)的需求變化有一定超前的預(yù)見性，否則面對不同需求，SDN軟件系統(tǒng)研發(fā)容易面臨反復(fù)修訂、更改，從而導(dǎo)致軟件系統(tǒng)主要結(jié)構(gòu)和流程的多次更改。這對于核心系統(tǒng)平臺的質(zhì)量和時效都是一種極大的考驗[4]。

3 運營商云網(wǎng)協(xié)同架構(gòu)的

設(shè)計要點

運營商云網(wǎng)協(xié)同架構(gòu)基于SDN技術(shù)，賦能現(xiàn)有骨干網(wǎng)、互聯(lián)網(wǎng)接入和云網(wǎng)絡(luò)等，運用先進技術(shù)手段重構(gòu)網(wǎng)絡(luò)基礎(chǔ)架構(gòu)，與公有云優(yōu)勢資源整合，提供端到端的網(wǎng)絡(luò)資源自動部署和快捷調(diào)度[5-6]，同時提供彈性帶寬、自助服務(wù)、即時開通的運營服務(wù)，為企業(yè)客戶提供上云服務(wù)、跨云的連接（包括數(shù)據(jù)中心、公有云、私有云）和分支組網(wǎng)等多重場景，包括為用戶輕松解決云計算落地“最后一公里”的問題。運營商云網(wǎng)協(xié)同架構(gòu)如何設(shè)計？如何確保業(yè)務(wù)編排、技術(shù)架構(gòu)、技術(shù)規(guī)范和業(yè)務(wù)流程等眾多方面的合理性和先進性？文章中，我們將針對性地介紹云網(wǎng)協(xié)同架構(gòu)中的幾個設(shè)計關(guān)鍵點。

3.1 統(tǒng)一業(yè)務(wù)編排器

統(tǒng)一業(yè)務(wù)編排器是全網(wǎng)SDN邏輯的核心。如圖1所示，編排器具備運營商骨干網(wǎng)完備的業(yè)務(wù)邏輯，支持多種業(yè)務(wù)支撐系統(tǒng)接口，并且具備API外部擴展能力，可以定義完整的用戶業(yè)務(wù)流程，具體包括用戶業(yè)務(wù)的開通、生成、下發(fā)、計費等，如用戶虛擬專用網(wǎng)絡(luò)（VPN）、終端設(shè)備（TE）隧道業(yè)務(wù)，以及用戶云專線等。

統(tǒng)一業(yè)務(wù)編排器管理和控制全網(wǎng)的設(shè)備，展現(xiàn)全局網(wǎng)絡(luò)流量動態(tài)，收集全向網(wǎng)絡(luò)拓撲，統(tǒng)一呈現(xiàn)網(wǎng)絡(luò)及設(shè)備狀態(tài)。編排器還實現(xiàn)全網(wǎng)資源統(tǒng)一管理、業(yè)務(wù)統(tǒng)籌調(diào)度與路徑優(yōu)化，統(tǒng)一編排用戶上云、云間各種組網(wǎng)的業(yè)務(wù)流程，為用戶提供云網(wǎng)一站式打通。

針對統(tǒng)一業(yè)務(wù)編排器，我們提出了2點建議：

（1）業(yè)務(wù)編排器整個系統(tǒng)架構(gòu)按照業(yè)務(wù)和功能進行拆分，并基于現(xiàn)有成熟的微服務(wù)架構(gòu)實現(xiàn)最小粒度化的服務(wù)模塊。微服務(wù)可以按需組合完成各類業(yè)務(wù)場景開通，實現(xiàn)完全解耦的模塊化系統(tǒng)架構(gòu)設(shè)計。

（2）統(tǒng)一業(yè)務(wù)編排器的設(shè)計需由具備既熟悉網(wǎng)絡(luò)的底層架構(gòu)、技術(shù)和協(xié)議，又掌握新型云網(wǎng)絡(luò)技術(shù)和軟件架構(gòu)的全棧技術(shù)的專業(yè)架構(gòu)師來完成，同時還需要與優(yōu)秀的系統(tǒng)軟件架構(gòu)師（包括客戶和合作伙伴）共同合作。

3.2 優(yōu)化業(yè)務(wù)流程

運營商的系統(tǒng)會涉及到業(yè)務(wù)、產(chǎn)品、運營和市場等多方面不同需求和流程，在傳統(tǒng)運營模式下，部門多，環(huán)節(jié)多，業(yè)務(wù)周期長，難以適應(yīng)云網(wǎng)業(yè)務(wù)的發(fā)展。優(yōu)化系統(tǒng)業(yè)務(wù)流程在SDN架構(gòu)設(shè)計中至關(guān)重要，通過SDN架構(gòu)重構(gòu)，抽象業(yè)務(wù)邏輯，重新定義用戶權(quán)限與流程，包括運維人員、最終用戶、云服務(wù)商、客戶經(jīng)理等不同角色賬戶自服務(wù)、業(yè)務(wù)便捷管理等功能，重新規(guī)范運營商的業(yè)務(wù)流程和自動化以實現(xiàn)運營商業(yè)務(wù)。

針對業(yè)務(wù)流程的情況，我們的具體建議為：

（1）運營商需要在需求階段和甲方一起對流程進行梳理、確認。因流程的更改會導(dǎo)致軟件系統(tǒng)主要結(jié)構(gòu)的更改，甚至會導(dǎo)致研發(fā)和項目進展出現(xiàn)停頓、瓶頸甚至反復(fù)，運營商需要在需求階段就對流程進行梳理和確認。

（2）軟件設(shè)計架構(gòu)盡可能實現(xiàn)微服務(wù)和模塊化。由于云網(wǎng)協(xié)同和SDN項目會涉及運營商內(nèi)部多個業(yè)務(wù)部門，業(yè)務(wù)需求在不同部門、不同時間點可能有不同的理解，因此設(shè)計架構(gòu)上需盡可能微服務(wù)和模塊化，即使將來流程調(diào)整也不至于推倒重來。

3.3 制定SDN協(xié)同器和通用服務(wù)

提供者接口（SPI）

SDN協(xié)同器負責全程全網(wǎng)（物理網(wǎng)絡(luò)）的統(tǒng)一收集、抽象和組建，需要進行網(wǎng)絡(luò)資源數(shù)據(jù)和拓撲的搜集，從而全面掌握服務(wù)商的網(wǎng)絡(luò)資源，包括設(shè)備、鏈路、端口、拓撲等。SDN協(xié)同器能夠?qū)崿F(xiàn)網(wǎng)絡(luò)資源和能力的抽象化、模型化，是業(yè)務(wù)平臺能力和服務(wù)支持的基礎(chǔ)組件。通過SDN協(xié)調(diào)器實現(xiàn)物理網(wǎng)絡(luò)向邏輯網(wǎng)絡(luò)的轉(zhuǎn)化，并通過兼容各種異構(gòu)SDN控制器系統(tǒng)與云商API互聯(lián)，與運營商網(wǎng)絡(luò)支撐系統(tǒng)對接，從而實現(xiàn)對服務(wù)商網(wǎng)絡(luò)的統(tǒng)一、快捷和安全的控制和管理[7]。

需要指出的是，SDN協(xié)調(diào)器的能力將受限于其南向的SDN控制器、軟件定義廣域網(wǎng)（SD-WAN）控制器和運營商網(wǎng)絡(luò)支撐系統(tǒng)所提供的能力。為避免受南向的SDN控制器和SD-WAN控制器能力限制可能帶來的功能限制，SDN協(xié)同器應(yīng)具備通用SDN控制器的基本功能，支持直接配置、控制和管理市場上主流骨干網(wǎng)絡(luò)設(shè)備。SDN協(xié)調(diào)器模塊設(shè)計的優(yōu)劣直接影響業(yè)務(wù)平臺的能力和其未來可持續(xù)迭代和擴展演進。

針對SDN協(xié)同器和通用服務(wù)SPI編排接口，我們的建議如下：

（1）南向面向服務(wù)商網(wǎng)絡(luò)基礎(chǔ)設(shè)施廠商SDN控制器、SD-WAN控制器以及第三方云平臺的配置和管理，需要實現(xiàn)對不同廠家控制器環(huán)境業(yè)務(wù)下發(fā)及高可用（HA）機制，實現(xiàn)主/備控制器的高可用HA狀態(tài)的監(jiān)測、協(xié)商同步和故障處理等。

（2）整合異構(gòu)廠商設(shè)備，實現(xiàn)解耦。多廠商的設(shè)備控制器是各廠商私有的，不能兼容其他廠家設(shè)備。不同廠家定義的YANG model、命令內(nèi)容、配置方式，即使是設(shè)備命名規(guī)則都不相同，要建立一套公認的YANG模型，實現(xiàn)異廠家控制器對接，溝通和技術(shù)都要解決巨大困難。

3.4 規(guī)范API

云網(wǎng)協(xié)同架構(gòu)為數(shù)據(jù)中心、私有云、公有云提供了端到端網(wǎng)絡(luò)接入服務(wù)。API的接口規(guī)范不僅要滿足網(wǎng)絡(luò)資源的管理和對接，還需要和多個云平臺打通并對接，適配多個云平臺以及自動化類型的數(shù)據(jù)中心等可編程平臺，為用戶提供云網(wǎng)一站式打通。由于不同的云服務(wù)商提供的業(yè)務(wù)形式不同、可編程能力和API規(guī)范不同，再加上業(yè)務(wù)開通上的流程差異，要實現(xiàn)跨云的自動化業(yè)務(wù)流程，需要面對的挑戰(zhàn)是巨大的。

協(xié)同編排器API包括北向API網(wǎng)絡(luò)、南向API網(wǎng)絡(luò)和東西向集群內(nèi)網(wǎng)絡(luò)[8]。

（1）北向API網(wǎng)絡(luò)：通用控制器系統(tǒng)和統(tǒng)一編排器通過該網(wǎng)絡(luò)發(fā)送和接收北向API的網(wǎng)絡(luò)業(yè)務(wù)信息。

（2）南向API網(wǎng)絡(luò)：通用控制器系統(tǒng)通過該API和南向廠商控制器（或者設(shè)備）發(fā)送和接收的網(wǎng)絡(luò)管理信息。

（3）東西向集群API網(wǎng)絡(luò)：通用控制器系統(tǒng)通過該網(wǎng)絡(luò)備份數(shù)據(jù)庫數(shù)據(jù)，發(fā)送和接收東西向業(yè)務(wù)API。

針對API規(guī)范，我們的具體建議如下：

（1）云商對接須盡早進行。大部分云商都有各自非標準的API規(guī)范，且每個云商的接入方式、路由設(shè)計以及API還是有著很大的差別，需有經(jīng)驗的開發(fā)人員盡早參與討論和設(shè)計。

（2）云商和運營商的API調(diào)用流程須協(xié)調(diào)好。在資源申請中，運營商是一點登錄還是允許云商和運營商多點登錄，一定要協(xié)調(diào)好。如果可以讓用戶一點接入、多點部署、全網(wǎng)服務(wù)，還需要涉及跨域部署的多服務(wù)商和多站點云資源布局，這其中的技術(shù)也非常復(fù)雜。

4 運營商云網(wǎng)協(xié)同架構(gòu)涉及

的關(guān)鍵技術(shù)

運營商云網(wǎng)協(xié)同架構(gòu)至少涵蓋接入、骨干網(wǎng)和云中心等幾個層面，實現(xiàn)從接入到云中心端到端的網(wǎng)絡(luò)自動化部署和租戶的打通，包括端到端統(tǒng)一調(diào)度資源、服務(wù)等級協(xié)議（SLA）服務(wù)質(zhì)量保障、路徑規(guī)劃和VPN安全管理等。這不僅涉及到整體架構(gòu)的統(tǒng)一規(guī)劃還涉及到許多的技術(shù)實現(xiàn)，如云數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)通常以可擴展虛擬局域網(wǎng)（VXLAN）/以太網(wǎng)虛擬專用網(wǎng)絡(luò)（EVPN）為主，還要考慮Openstack Neutron聯(lián)動;運營商的骨干網(wǎng)通常以多協(xié)議標簽交換（MPLS）/分段路由隧道（SRTE）為主，還要考慮2層虛擬專用網(wǎng)絡(luò)（L2VPN）/3層虛擬專用網(wǎng)絡(luò)（L3VPN）與云中心租戶對接;接入側(cè)傳統(tǒng)的城域網(wǎng)或新型的SD-WAN接入和接入點（PoP）探測技術(shù)還要考慮與MPLS的混合組網(wǎng)實現(xiàn)。這幾個層面須與云網(wǎng)協(xié)同統(tǒng)一管理、協(xié)同工作，才能真正實現(xiàn)企業(yè)客戶從選擇最佳PoP站點接入到骨干網(wǎng)，并實現(xiàn)上云的端到端業(yè)務(wù)快速部署，具體

如圖2所示。文章中，我們將重點介紹云網(wǎng)協(xié)同架構(gòu)中會涉及到幾項關(guān)鍵技術(shù)。

4.1 云中心VXLAN/EVPN和云商

對接

隨著公有云的真正崛起，SDN作為云網(wǎng)協(xié)同的必備技術(shù)，其發(fā)展經(jīng)歷了從基于Openflow的SDN流派到網(wǎng)絡(luò)廠商的私有SDN流派，再到后來基于開放VXLAN/EVPN的廣義SDN流派?；赩XLAN 的Overlay由于其簡單、易擴展等優(yōu)勢已經(jīng)成為數(shù)據(jù)中心網(wǎng)絡(luò)最炙手可熱的技術(shù)。

VXLAN作為一種網(wǎng)絡(luò)虛似化技術(shù)，采用“MAC in UDP”封裝形式，并且基于IP網(wǎng)絡(luò)實現(xiàn)大二層技術(shù)，它是一種用于實現(xiàn)大型云計算和數(shù)據(jù)中心的網(wǎng)絡(luò)二層互通技術(shù)。VXLAN作為一種數(shù)據(jù)封裝技術(shù)，其本身沒有控制平面，其在轉(zhuǎn)發(fā)數(shù)據(jù)前的表項學(xué)習，如ARP表、VXLAN網(wǎng)絡(luò)標識（VNI）、VXLAN隧道終端（VTEP）地址等都是通過數(shù)據(jù)包的泛洪來完成。如果網(wǎng)絡(luò)中存在大量的泛洪流量，勢必對網(wǎng)絡(luò)的性能有所影響;因此，VXLAN數(shù)據(jù)轉(zhuǎn)發(fā)前表項學(xué)習的泛洪流量一開始就是一個重要問題。邊界網(wǎng)關(guān)協(xié)議（BGP）EVPN（RFC7432）標準的出現(xiàn)非常及時，促進了VXLAN的快速發(fā)展和普及，并為VXLAN和其他Overlay技術(shù)奠定了競爭基礎(chǔ)?；贐GP EVPN控制層學(xué)習L2和L3的可達信息，通過EVPN完成在VXLAN轉(zhuǎn)發(fā)數(shù)據(jù)報文前ARP表項學(xué)習、主機路由學(xué)習和VTEP自動發(fā)現(xiàn)，VXLAN+EVPN為云數(shù)據(jù)中心虛擬化、集群和云部署大二層網(wǎng)絡(luò)夯實網(wǎng)絡(luò)基礎(chǔ)。云中心VXLAN EVPN架構(gòu)示意如圖3所示。

云商的按需自動對接實際上就是把某個用戶在云商的虛擬私有云（VPC）網(wǎng)絡(luò)和在運營商骨干網(wǎng)中開通的3層VPN連接打通。典型的云環(huán)境包括基于Host Overlay公有云和基于裸機服務(wù)器托管云。目前一般選擇VXLAN/EVPN作為底層技術(shù)，運營商骨干網(wǎng)一側(cè)會用到基于SD-WAN的MPLS、SRTE的網(wǎng)絡(luò)技術(shù)。SD-WAN到云數(shù)據(jù)中心SDN網(wǎng)絡(luò)的統(tǒng)一編排和租戶管理，如圖4所示。

運營商SD-WAN控制器通過RestAPI與云中心控制器對接。控制器通過企業(yè)用戶的云平臺子賬號調(diào)用API獲取其VPC資源，同時獲取租戶VPC資源信息并打通網(wǎng)絡(luò)VPN運營商SD-WAN控制器，負責服務(wù)商邊緣設(shè)備（PE）的租戶和VPN對接信息的下發(fā)，具體體現(xiàn)為客戶端設(shè)備（CE）和PE之間三層VPN業(yè)務(wù)子接口、關(guān)聯(lián)的BGP-VRF會話以及服務(wù)質(zhì)量（QoS）配置等。運營商SD-WAN業(yè)務(wù)編排器會自動調(diào)用云商平臺開放API，通過云商SDN控制器打通云中心WAN 路由器和VR路由器的租戶VRF對接信息，PE路由器與云中心的WAN 路由器通過VRF自動打通。

針對云中心VXLAN/EVPN和云商對接，我們提出如下建議：

（1）基于VXLAN 的Overlay由于其簡單、易擴展等優(yōu)勢已成為公有云數(shù)據(jù)中心網(wǎng)絡(luò)的技術(shù)首選，SD-WAN基于PE的邏輯子端口VRF與云商對接。雖然在具體技術(shù)上相對成熟，但每家云商VPC的結(jié)構(gòu)不一樣，實際對接中還是存在很多問題。

（2）針對運營商業(yè)務(wù)編排器/SD-WAN控制器，我們需要事先和云商協(xié)商好調(diào)用流程和實現(xiàn)邏輯。云商平臺開放API，但每家云商API沒有統(tǒng)一標準且差別很大;因此和每家云商API對接是一個挑戰(zhàn)。

4.2 骨干網(wǎng)技術(shù)：MPLS還是

SRTE

目前，運營商擁有覆蓋全國甚至全球的大規(guī)模骨干網(wǎng)資源、數(shù)據(jù)中心資源，傳統(tǒng)的手工已經(jīng)不能滿足云的模式，運營商基于SD-WAN的廣域網(wǎng)重構(gòu)項目迫在眉睫。SD-WAN骨干調(diào)度核心思想是流量調(diào)度和基于多租戶的服務(wù)和管理，目前主要有3類方式：第1類基于白牌機+Openflow SDN控制器。Google B4就是基于這個方案（2010—2012年），其核心是其TE調(diào)度和算法，它巧妙地避開了Openflow的眾多缺陷，包括基于源和目的地址配合差分服務(wù)代碼點（DSCP）作為流表的轉(zhuǎn)發(fā)策;但Openflow+白牌機的方案反饋還是有些問題，包括白牌機對 SRTE 支持能力、雙向轉(zhuǎn)發(fā)檢測（BFD）/Tunnel支持性能和數(shù)量、路由策略和VPN能力，以及交換機流表和端口緩存的大小等。運營商基本上不會大規(guī)模采用Openflow+白牌機方案。第2類基于MPLS +SDN控制器，實現(xiàn)全網(wǎng)的流量調(diào)度和VPN租戶管理。MPLS TE多年前已開始部署，就目前運營商客戶部署情況看，絕大部分抱怨MPLS TE的部署過于復(fù)雜;因而真正在生產(chǎn)網(wǎng)TE隧道使用并不多。由于MPLS成熟有余先進不足，運營商將來不會大規(guī)模采用。第3類方案是基于分段路由（SR）實現(xiàn)流量調(diào)度和管理SR+SDN控制器，該方案也是筆者更希望看到的。和MPLS的網(wǎng)絡(luò)類似，SR基于源頭組建一個完整的分層服務(wù)提供商（LSP）路徑，而且可以和現(xiàn)有的MPLS網(wǎng)絡(luò)兼容，只需要對現(xiàn)有的內(nèi)部網(wǎng)關(guān)協(xié)議（IGP）進行簡單地擴展，就可以實現(xiàn)TE、快速重路由（FRR）、MPLS VPN等功能。目前，基于SRTE的SDN控制器技術(shù)在業(yè)界屬于非常領(lǐng)先的技術(shù)，其中SR的基礎(chǔ)轉(zhuǎn)發(fā)表甚至比標簽分發(fā)協(xié)議（LDP）更簡潔，同時還將源路由技術(shù)與SDN理念完美結(jié)合。在流量TE管理方面，SRTE比資源預(yù)留隧道（RSVP-TE）技術(shù)流量標簽隧道狀態(tài)的數(shù)量少很多，也不像LDP/RSVP信令那么復(fù)雜，目前各個廠商新一代的路由設(shè)備基本上都支持SRTE。推薦運營商采用SR+SDN重構(gòu)新一代的骨干網(wǎng)實現(xiàn)流量調(diào)度和管理?；赟RTE SDN控制示意如圖5所示。

針對骨干網(wǎng)技術(shù)，我們的建議如下：

（1）盡管SRTE技術(shù)優(yōu)勢比較明顯，但目前各個硬件廠商（包括第三方控制器+SR路由器）在SRTE具體實現(xiàn)還是有一定差距，有幾點是設(shè)計部署時需要考慮的：如何根據(jù)鏈路質(zhì)量（load/loss/delay）動態(tài)實時調(diào)整TE路徑以實現(xiàn)全局負載均衡、隧道快速倒換策略和逃生算法（如思科PBTS技術(shù)）、配置回滾的一致性、離線流量規(guī)劃、TE路徑的對稱故障檢測等，各商家的方案功能差別比較大，在中國能真正完整實現(xiàn)基于SRTE的SDN控制器更是屈指可數(shù)。

（2）對于運營商和云服務(wù)商，我們都希望能夠基于標準的南向支持NetConF/YANG等協(xié)議控制和管理多廠商網(wǎng)絡(luò)設(shè)備。在開源和開放的大趨勢下，各個廠商都宣稱支持SRTE和NetConF以及開放北向API等。中國運營商如聯(lián)通已經(jīng)成功部署基于多廠商SDN協(xié)同編排器，利用統(tǒng)一協(xié)同編排器實現(xiàn)多廠商設(shè)備的解耦，整合異構(gòu)多廠商設(shè)備，開創(chuàng)了異構(gòu)環(huán)境下多云互聯(lián)的先河。

5 SD-WAN接入技術(shù)

隨著企業(yè)上云和廣域網(wǎng)按需接入的需求日益增加，傳統(tǒng)的MSTP和MPLS等專線業(yè)務(wù)由于成本高、部署周期長等問題已難以滿足云和互聯(lián)網(wǎng)時代的需求，面向基于互聯(lián)網(wǎng)和PoP探測選擇的SD-WAN技術(shù)隨之誕生。SD-WAN就是一種面向分支靈活接入的部署場景，在其設(shè)計和部署時，我們需要考慮南北運營商Internet瓶頸的問題，并會選擇在各地的多個機房部署多線PoP節(jié)點。在PoP層解決了跨運營商互通提升互聯(lián)品質(zhì)，POP之間構(gòu)建了專線骨干網(wǎng)，以確保SD-WAN遠程傳輸業(yè)務(wù)品質(zhì)。由于目前中國運營商MPLS VPN網(wǎng)絡(luò)已大規(guī)模部署，運營商須要考慮把MPLS VPN的PE和租戶VPN集成到SD-WAN系統(tǒng)中。此時，各個PoP節(jié)點的虛擬服務(wù)商邊緣設(shè)備（vPE）/網(wǎng)關(guān)（GW）需要與運營商MPLS網(wǎng)PE節(jié)點對接，并通過OptionA/OptionB 或納管等方式統(tǒng)一管理。這種架構(gòu)能有效提高網(wǎng)絡(luò)性能和混合組網(wǎng)能力，特別是各種高服務(wù)級別的實時流量，而且可方便實現(xiàn)SD-WAN與運營商骨干網(wǎng)MPLS對接。SD-WAN具體技術(shù)實現(xiàn)如圖6所示。

針對SD-WAN技術(shù)，整合SD-WAN架構(gòu)兼顧運營商MPLS/SRTE骨干網(wǎng)，真正實現(xiàn)為客戶提供全國范圍內(nèi)集MPLS VPN、IPSEC VPN、SD-WAN等多種應(yīng)用的WAN解決方案，解決運營商“最后一公里”的難題。

（1）由于打通了MPLS租戶VPN與SD-WAN租戶VPN（也有稱之為“混合架構(gòu)”能力），該架構(gòu)非常適合實現(xiàn)骨干網(wǎng)、SD-WAN與主要云運營商對接，開展云聯(lián)網(wǎng)業(yè)務(wù)

（2）運營商在部署這種架構(gòu)時，建議將SD-WAN接入控制器和骨干網(wǎng)控制器整合。整合的控制器將MPLS 服務(wù)商PE節(jié)點統(tǒng)一納管。這樣在開通VPN業(yè)務(wù)時就可以實現(xiàn)完全的業(yè)務(wù)自動化

6 結(jié)束語

新型云服務(wù)商追求資源邏輯管理和秒級響應(yīng)， 傳統(tǒng)的運營商網(wǎng)絡(luò)已無法支撐業(yè)務(wù)的彈性和快速增長。云網(wǎng)協(xié)同和SDN技術(shù)的出現(xiàn)，將整個物理網(wǎng)絡(luò)抽象并簡化為“單一”邏輯網(wǎng)絡(luò)資源池，并通過軟件定義用戶業(yè)務(wù)的自動化流程，實現(xiàn)多個系統(tǒng)聯(lián)動，完成業(yè)務(wù)端到端快速自動部署。這些年來，中國運營商已開始在大規(guī)模運行的骨干網(wǎng)絡(luò)中進行SDN重構(gòu)，擁抱多云互聯(lián)的時代。個別運營商已實現(xiàn)多廠商異構(gòu)環(huán)境SDN實踐部署并取得寶貴經(jīng)驗。但對于中國運營商的骨干網(wǎng)絡(luò)，在實現(xiàn)SDN轉(zhuǎn)變時還面臨巨大的挑戰(zhàn)，如：運營商缺乏SDN技術(shù)和架構(gòu)，沒有標準規(guī)范，各個廠商設(shè)備實現(xiàn)方式非標準，多廠家異構(gòu)設(shè)備管理，業(yè)界實踐經(jīng)驗不多等。在中國，SDN網(wǎng)絡(luò)技術(shù)作為開放軟件架構(gòu)，在開放性、通用標準和互操作方面還有很多路要走，但無論如何，SDN和云計算作為未來IT發(fā)展的2大最基本的創(chuàng)新引擎，其發(fā)展勢不可擋。相信不遠的將來，SDN與云計算相結(jié)合的云網(wǎng)協(xié)同將會給運營商、云商和客戶帶來一片新的天地。

參考文獻

[1] NADEAU D T， GRAY K. SDN： Software Defined Networks [M].USA： OREILLY， 2014

[2] FILSFILSM C， MICHIELSEN K， TALAULIKAR K. Segment Routing Part1 [M]. Beijing：

China Industry and Information Technology Pushing&Media Group， and The People's Posts and Telecommunications Press， 2017

[3] BGP MPLS-Based Ethernet VPN-EVPN [EB/OL]. [2019-01-18].

https：//tools.ietf.org/html/rfc7432

[4] IETF. BGP MPLS-Based Ethernet VPN：RFC 7432 [S].2015

[5] Segment Routing Architecture [EB/OL]. [2019-01-18].https：//tools.ietf.org/html/rfc8402

[6] IETF. Segment Routing Architecture： RFC 8402[S].2018

[7] Virtual eXtensible Local Area Network （VXLAN）： A Frameworkfor Overlaying Virtualized Layer 2 Networks over Layer 3 Networks [EB/OL]. [2019-01-18].

https：//tools.ietf.org/html/rfc7348

[8] MAHALINGAM M， DUTT D， DUDA K， et al. Virtual eXtensible Local Area Network （VXLAN）： A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks[R]. RFC Editor， 2014