朱海東

摘要：隨著云業(yè)務(wù)的深入部署，除接入和連接性服務(wù)外，云網(wǎng)運(yùn)營商還須需要將網(wǎng)絡(luò)端到端帶寬和時延等服務(wù)質(zhì)量保障能力作為網(wǎng)絡(luò)服務(wù)提供給最終客戶。云網(wǎng)運(yùn)營商基于云網(wǎng)一體網(wǎng)絡(luò)架構(gòu)，通過部署性能測量和故障發(fā)現(xiàn)、基于性能的路由、流量統(tǒng)計(jì)和狀態(tài)預(yù)測，以及多域編排等系統(tǒng)，滿足客戶對不同需求層級能力的要求，使能網(wǎng)絡(luò)即服務(wù)（NaaS）能力，實(shí)現(xiàn)網(wǎng)絡(luò)與云化業(yè)務(wù)的有機(jī)結(jié)合。

關(guān)鍵詞：云網(wǎng);多云;NaaS;服務(wù)等級

Abstract： In addition to access and connectivity services， cloud operators also provide multi-factor quality of service （QoS） assurance capabilities （such as end-to-end bandwidth and delay） as the network service to end customers. The cloud network service provider enables network as a service （NaaS） by building performance measure and fault detection， performance aware routing， traffic statistics and state prediction， and multi-domain orchestration systems to match the hierarchy of service needs upon the cloud network architecture.

Key words： cloud network; multi-cloud; NaaS; service-level agreement

一直以來，網(wǎng)絡(luò)規(guī)劃人員采用自頂向下的設(shè)計(jì)方法構(gòu)建并不斷擴(kuò)展數(shù)據(jù)通信網(wǎng)絡(luò)，在過去的20年里成功地完成了業(yè)務(wù)和網(wǎng)絡(luò)IP化過程。近年來，隨著云計(jì)算的成熟應(yīng)用以及信息技術(shù)（IT）行業(yè)與信息通信（IC）行業(yè)的交融，這種以需求為基礎(chǔ)創(chuàng)建的網(wǎng)絡(luò)通常無法如預(yù)期那樣運(yùn)行，也無法隨網(wǎng)絡(luò)規(guī)模的不斷增長而擴(kuò)展，無法滿足客戶的需求[1]。未來網(wǎng)絡(luò)的規(guī)劃設(shè)計(jì)應(yīng)以數(shù)據(jù)和數(shù)據(jù)中心（DC）為核心，圍繞云化業(yè)務(wù)的需求進(jìn)行，這已經(jīng)成為IT和IC行業(yè)的共識。云與網(wǎng)有機(jī)結(jié)合將構(gòu)成云網(wǎng)一體的新型信息系統(tǒng)架構(gòu)。

1 云網(wǎng)的概念

云網(wǎng)（CloudNet）將云計(jì)算架構(gòu)與網(wǎng)絡(luò)能力相結(jié)合。云網(wǎng)一體架構(gòu)充分利用軟件定義網(wǎng)絡(luò)（SDN）和網(wǎng)絡(luò)功能虛擬化（NFV）等技術(shù)提供的動態(tài)可編程能力，實(shí)現(xiàn)服務(wù)設(shè)施按需靈活部署。在該架構(gòu)下，業(yè)務(wù)通過跨Internet連接的若干數(shù)據(jù)中心協(xié)同提供，在提升資源利用率和業(yè)務(wù)可靠性的同時實(shí)現(xiàn)業(yè)務(wù)部署和管理的敏捷性[2]。

1.1 云網(wǎng)一體參與方

在云網(wǎng)一體框架下，客戶的業(yè)務(wù)由云業(yè)務(wù)服務(wù)商（CSP）和網(wǎng)絡(luò)業(yè)務(wù)服務(wù)商（NSP）共同完成。CSP利用架設(shè)在數(shù)據(jù)中心之上的設(shè)備和資源，通過互聯(lián)網(wǎng)或其他網(wǎng)絡(luò)以隨時獲取、按需使用、隨時擴(kuò)展、協(xié)作共享等方式，為用戶提供數(shù)據(jù)存儲、互聯(lián)網(wǎng)應(yīng)用開發(fā)環(huán)境、互聯(lián)網(wǎng)應(yīng)用部署和運(yùn)營管理等服務(wù)。CSP通過云化數(shù)據(jù)中心提供服務(wù)，主要類型有軟件即服務(wù)（SaaS）、平臺即服務(wù)（PaaS）和基礎(chǔ)設(shè)施即服務(wù)（IaaS）等。典型的CSP有阿里云、騰訊云、亞馬遜AWS、微軟Azure等。

除了公有云，互聯(lián)網(wǎng)公司和政府、大型企業(yè)的私有云也是云的重要組成部分，如Facebook通過全球分布的數(shù)據(jù)中心為各區(qū)域客戶提供服務(wù)，各級政府通過政務(wù)云提供便捷的公眾服務(wù)。當(dāng)私有云與公有云配合提供服務(wù)時，即成為混合云。

NSP則為客戶提供網(wǎng)絡(luò)接入服務(wù)、本地互連和跨地域骨干遠(yuǎn)程連接等服務(wù)，這些網(wǎng)絡(luò)服務(wù)是綜合電信運(yùn)營商的基礎(chǔ)電信業(yè)務(wù)之一。目前電信行業(yè)內(nèi)一些運(yùn)營商同時提供云服務(wù)和網(wǎng)絡(luò)連接服務(wù)，轉(zhuǎn)型為云網(wǎng)綜合運(yùn)營商，如中國三大運(yùn)營商：中國電信（天翼云）、中國聯(lián)通（沃云）和中國移動（移動云），它們都運(yùn)營有各自的公用云和專有云業(yè)務(wù);其他國家如西班牙電信（Telefónica）、德電（Deutsche Telekom）等傳統(tǒng)電信運(yùn)營商也紛紛進(jìn)入公有云市場。

1.2 云網(wǎng)一體的研究范圍

參照電氣和電子工程師協(xié)會（IEEE）CloudNet委員會關(guān)注和研究的技術(shù)方向，云網(wǎng)一體架構(gòu)分為以下幾個技術(shù)領(lǐng)域[2]。

（1）云網(wǎng)總體架構(gòu)。

云網(wǎng)總體架構(gòu)包括分布式數(shù)據(jù)中心架構(gòu)、云數(shù)據(jù)中心大規(guī)模路由組織方式、數(shù)據(jù)中心內(nèi)/外部互訪方式以及聯(lián)合云和混合云組網(wǎng)等方面。業(yè)務(wù)的扁平化使得越來越多的數(shù)據(jù)中心網(wǎng)絡(luò)引入Internet全球路由，實(shí)現(xiàn)跨地域的信息服務(wù)，這需要使用基于邊界網(wǎng)關(guān)協(xié)議（BGP）路由屬性和策略對流量流向進(jìn)行優(yōu)化控制。隨著個人和政企業(yè)務(wù)上云的演進(jìn)，聯(lián)合云、混合云等多云方式部署也成為影響云網(wǎng)架構(gòu)的重要推動力量。調(diào)研表明：81%的企業(yè)會采用多云策略，平均每個企業(yè)會使用5朵公用云和（或）私用云[3]。大型互聯(lián)網(wǎng)公司如Twitter也轉(zhuǎn)向了混合云方案，將其冷存儲和Hadoop業(yè)務(wù)遷移到了Google云上。在多云環(huán)境下，端到端業(yè)務(wù)需要在多個網(wǎng)絡(luò)域和管理域間完成交互協(xié)同。

（2）云網(wǎng)資源管理。

云網(wǎng)資源管理根據(jù)業(yè)務(wù)需要動態(tài)按需提供計(jì)算資源、存儲資源和網(wǎng)絡(luò)帶寬、服務(wù)等級等能力，涵蓋的范圍不僅包含數(shù)據(jù)中心基礎(chǔ)設(shè)施和數(shù)據(jù)中心內(nèi)部網(wǎng)絡(luò)（DCN），還要包含數(shù)據(jù)中心互聯(lián)網(wǎng)絡(luò)（DCI），特別是通過多個NSP網(wǎng)絡(luò)資源及CSP自用的骨干專網(wǎng)共同實(shí)現(xiàn)跨數(shù)據(jù)中心互聯(lián)[4]。云網(wǎng)資源管理需要獲取物理網(wǎng)絡(luò)和虛擬拓?fù)涞娜忠晥D和資源使用狀態(tài)，提供最優(yōu)的資源調(diào)度和使用策略，提供彈性、可擴(kuò)展的動態(tài)資源管理方案。

（3）云網(wǎng)虛擬化技術(shù)。

云網(wǎng)虛擬化引入SDN轉(zhuǎn)控分離架構(gòu)和NFV虛擬網(wǎng)元，一方面可以實(shí)現(xiàn)業(yè)務(wù)部署的簡化和自動化，提供敏捷服務(wù)，加速新業(yè)務(wù)上線速度;另一方面在多層、多域、多廠家組網(wǎng)的復(fù)雜網(wǎng)絡(luò)中提供端到端的管理和控制能力。分域化和層次化部署的SDN控制面還能夠提供精細(xì)的控制粒度，提高系統(tǒng)資源利用率和運(yùn)維效率。

（4）云網(wǎng)業(yè)務(wù)和云網(wǎng)安全。

云網(wǎng)業(yè)務(wù)和云網(wǎng)安全包括SaaS、PaaS、IaaS、大數(shù)據(jù)和數(shù)據(jù)分析、內(nèi)容分發(fā)、多業(yè)務(wù)邊緣計(jì)算等業(yè)務(wù)場景及其相關(guān)的安全要求。

在云網(wǎng)一體架構(gòu)下，為了保證端到端的業(yè)務(wù)體驗(yàn)，運(yùn)營商還將提供給客戶端到端帶寬和時延等網(wǎng)絡(luò)服務(wù)質(zhì)量保障能力，從而實(shí)現(xiàn)網(wǎng)絡(luò)即服務(wù)（NaaS）。

2 網(wǎng)絡(luò)架構(gòu)和業(yè)務(wù)需求

2.1 云網(wǎng)一體骨干網(wǎng)架構(gòu)

對云網(wǎng)業(yè)務(wù)服務(wù)商而言，網(wǎng)絡(luò)整體架構(gòu)在很大程度上決定了業(yè)務(wù)組織方式和SDN/NFV等新技術(shù)的部署難度，從而影響資源優(yōu)化利用所能達(dá)到的程度。從網(wǎng)絡(luò)角度看，云網(wǎng)架構(gòu)可以分為數(shù)據(jù)中心內(nèi)外2個部分。數(shù)據(jù)中心內(nèi)部DCN的目標(biāo)架構(gòu)主要有Fat Tree、Spine-Leaf等。數(shù)據(jù)中心之外的骨干網(wǎng)部分，得益于IP網(wǎng)與生俱來的互通性和可達(dá)性，目前NSP和CSP根據(jù)各自商業(yè)目標(biāo)在其資源管控范圍分別建設(shè)和發(fā)展各自的骨干網(wǎng)絡(luò)系統(tǒng)。

如圖1所示，AT&T針對企業(yè)入云提供了NetBond產(chǎn)品[5]，在網(wǎng)絡(luò)中部署NetBond服務(wù)節(jié)點(diǎn)并與CSP背靠背接入，實(shí)現(xiàn)了AT&T企業(yè)多協(xié)議標(biāo)簽交換（MPLS）虛擬專用網(wǎng)絡(luò)（VPN）和多云接入服務(wù)的整合，支持用戶接入私有云和公用云，還實(shí)現(xiàn)了帶寬的按需擴(kuò)展和連接的高安全保障。既是云服務(wù)商，又是內(nèi)容服務(wù)商的Google擁有名為B4和B2的2張骨干網(wǎng)，前者由33個全球節(jié)點(diǎn)構(gòu)成專用的大容量DCI網(wǎng)絡(luò)[6]，后者在全球70多個區(qū)域完成Google數(shù)據(jù)中心與外部鄰接運(yùn)營商互通，是終端用戶訪問Google的各種服務(wù)的必經(jīng)通道[7]。Facebook的網(wǎng)絡(luò)由邊緣接入點(diǎn)（PoP）、全球骨干和若干數(shù)據(jù)中心構(gòu)成。用戶通過Internet接入各地PoP點(diǎn)，再經(jīng)由骨干網(wǎng)訪問數(shù)據(jù)中心，F(xiàn)acebook的骨干網(wǎng)同時承載外部用戶流量和內(nèi)部數(shù)據(jù)中心（DC）間流量[8]。

從業(yè)務(wù)的視角看，上述3種骨干網(wǎng)架構(gòu)沒有把從最終用戶到云中的、業(yè)務(wù)的全部端到端路徑視為一個整體，實(shí)質(zhì)上是在各自網(wǎng)絡(luò)域內(nèi)部進(jìn)行的分段局部優(yōu)化。根據(jù)NSP和CSP網(wǎng)絡(luò)架構(gòu)現(xiàn)狀，用戶端到端業(yè)務(wù)路徑包含基礎(chǔ)網(wǎng)絡(luò)運(yùn)營商N(yùn)SP的接入/城域網(wǎng)、NSP-CSP網(wǎng)間互通PoP、運(yùn)營商骨干網(wǎng)和CSP骨干/DCI專網(wǎng)，以及數(shù)據(jù)中心內(nèi)網(wǎng)DCN等。其中，互通PoP是新引入的網(wǎng)絡(luò)節(jié)點(diǎn)，它不僅要完成傳統(tǒng)BGP域間路由互通，還要滿足業(yè)務(wù)互通對服務(wù)質(zhì)量、安全隔離等要求，是實(shí)現(xiàn)業(yè)務(wù)端到端一致性的關(guān)鍵節(jié)點(diǎn)。當(dāng)用戶基于使用安全性和經(jīng)濟(jì)性等因素選擇多網(wǎng)多云方案時，該方案還需要具備多個NSP和多個CSP間的多域資源組合優(yōu)化和編排能力。圖2分別展示了云網(wǎng)一體架構(gòu)的單網(wǎng)單云和多網(wǎng)多云2種架構(gòu)。

2.2 網(wǎng)絡(luò)能力需求層級

業(yè)務(wù)運(yùn)營對網(wǎng)絡(luò)能力的需求存在若干層級，如圖3所示。

（1）最底層是網(wǎng)絡(luò)物理帶寬、物理覆蓋范圍和站點(diǎn)間可達(dá)性，這些屬性是提供網(wǎng)絡(luò)服務(wù)的基礎(chǔ)。其中，物理帶寬能力包含接入帶寬和傳輸帶寬能力。

（2）按照開放式系統(tǒng)互聯(lián)（OSI）7層模型，可靠性和安全性可分為物理層到網(wǎng)絡(luò)層（L1—L3）、傳輸層到應(yīng)用層（L4—L7）2部分。前者主要由網(wǎng)絡(luò)能力保證，后者則由業(yè)務(wù)應(yīng)用軟件來實(shí)現(xiàn)。

（3）網(wǎng)絡(luò)差異化業(yè)務(wù)保證能力是多業(yè)務(wù)綜合承載的要求，即在一張物理網(wǎng)絡(luò)上按照不同業(yè)務(wù)的服務(wù)質(zhì)量等級分配相應(yīng)資源，不同業(yè)務(wù)對網(wǎng)絡(luò)服務(wù)關(guān)鍵指標(biāo)不同，比如企業(yè)跨DC大量數(shù)據(jù)復(fù)制業(yè)務(wù)關(guān)注在一定時間內(nèi)總數(shù)據(jù)吞吐量，而對網(wǎng)絡(luò)時延和丟包相對不很敏感?；赪EB的交互式應(yīng)用，除了帶寬和丟包率之外，影響傳輸控制協(xié)議（TCP）效率的時延因素成為業(yè)務(wù)保障的重要指標(biāo)。目前，云網(wǎng)業(yè)務(wù)的主要技術(shù)指標(biāo)有帶寬、時延和可靠性等[9]，云網(wǎng)運(yùn)營商在保證各等級業(yè)務(wù)服務(wù)達(dá)標(biāo)的過程中，不僅為價值用戶提供了更多產(chǎn)品選擇，也使得網(wǎng)絡(luò)資源得以充分利用。

（4）網(wǎng)絡(luò)的端到端能力是指從用戶終端到應(yīng)用服務(wù)器的全路徑業(yè)務(wù)保障能力，特別是業(yè)務(wù)路徑可能經(jīng)過一個或多個運(yùn)營商的多個管理域，在相鄰的管理域之間需要保證用戶體驗(yàn)的一致性。通過引入SDN編排系統(tǒng)，消除各個網(wǎng)絡(luò)域采用的不同技術(shù)的形式差異，完成不同管理域間在資源定義、業(yè)務(wù)定義和服務(wù)等級協(xié)議（SLA）定義的映射和轉(zhuǎn)換，同時實(shí)現(xiàn)資源的優(yōu)化配置。

（5）自動化、可視性和可調(diào)性是云網(wǎng)敏捷能力的體現(xiàn)，也是實(shí)現(xiàn)NaaS的靈活按需能力的基礎(chǔ)。在SDN技術(shù)架構(gòu)下，云網(wǎng)運(yùn)營者將網(wǎng)絡(luò)控制和轉(zhuǎn)發(fā)分離，通過集中的控制面獲取全局的資源和資源利用信息，并在路由層面實(shí)現(xiàn)對業(yè)務(wù)端到端全局路徑組合優(yōu)化。借助SDN網(wǎng)絡(luò)規(guī)劃和業(yè)務(wù)部署工具，云網(wǎng)運(yùn)營者還可以實(shí)現(xiàn)業(yè)務(wù)部署的簡化和自動化過程。只有具備了自動化、可視性和可調(diào)性的網(wǎng)絡(luò)，才能作為一種服務(wù)發(fā)布給客戶。

（6）智能化是更加高階的自動化，其目標(biāo)在于實(shí)現(xiàn)基于意圖的網(wǎng)絡(luò)（IBNS），從而為云網(wǎng)資源的設(shè)計(jì)、實(shí)施、運(yùn)營提供覆蓋全生命周期的自動化能力，將業(yè)務(wù)需求和網(wǎng)絡(luò)資源配置實(shí)時同步。

3 關(guān)鍵技術(shù)和系統(tǒng)

3.1 性能測量和故障發(fā)現(xiàn)

云網(wǎng)業(yè)務(wù)的分布式天性使得最終用戶的體驗(yàn)效果除了依賴應(yīng)用軟件外，還依賴于包括數(shù)據(jù)中心里的服務(wù)器、數(shù)據(jù)中心內(nèi)外部網(wǎng)絡(luò)以及運(yùn)行在服務(wù)器上的虛擬化軟件等組件的運(yùn)行情況。從網(wǎng)絡(luò)角度來看，云網(wǎng)運(yùn)營商需要管理和保障數(shù)據(jù)中心內(nèi)、數(shù)據(jù)中心間和用戶到數(shù)據(jù)中心這3個網(wǎng)絡(luò)域的業(yè)務(wù)帶寬、時延和可靠性。研究表明當(dāng)業(yè)務(wù)中斷或體驗(yàn)下降時，用戶很自然地將問題歸結(jié)為終端問題和網(wǎng)絡(luò)問題，而實(shí)際上50%的“網(wǎng)絡(luò)”問題并不是由網(wǎng)絡(luò)引發(fā)的[10]，因此，云網(wǎng)運(yùn)營商需要有效的性能測量系統(tǒng)。

Ping探測是一種檢測網(wǎng)絡(luò)L3連通性和丟包率的通用手段。NSP用IP Ping探測網(wǎng)絡(luò)邊界間的連通性，CSP則使用TCP Ping和HTTP Ping檢驗(yàn)業(yè)務(wù)層的連通性。顯然后者更能符合用戶端到端體驗(yàn)，但會存在2點(diǎn)問題：（1）針對網(wǎng)絡(luò)中每用戶每應(yīng)用的測量不僅占用終端和服務(wù)器計(jì)算資源，同時其產(chǎn)生的海量測量數(shù)據(jù)需要存儲和管理，例如Microsoft Ping mesh系統(tǒng)每天可以產(chǎn)生2 000億個探針和24 T字節(jié)的數(shù)據(jù)[10]，F(xiàn)acebook為了降低對資源的需求采用隨機(jī)選擇部分業(yè)務(wù)進(jìn)行測量[11];（2）將CSP應(yīng)用層的測量結(jié)果應(yīng)用到NSP網(wǎng)絡(luò)層資源管理的映射關(guān)系是十分復(fù)雜的，特別是中間網(wǎng)絡(luò)的路徑上匯集了不同等級的海量應(yīng)用，針對特定應(yīng)用的網(wǎng)絡(luò)問題根因分析缺少自動化手段。網(wǎng)絡(luò)吞吐量和時延的性能測量分為帶內(nèi)和帶外，帶內(nèi)的方式就是在報(bào)文頭中設(shè)置或添加探針字段，在測量點(diǎn)統(tǒng)計(jì)性能指標(biāo)，網(wǎng)絡(luò)中間節(jié)點(diǎn)無感知。帶外的方式則通過在網(wǎng)絡(luò)中增加獨(dú)立的探針數(shù)據(jù)流。由于數(shù)據(jù)網(wǎng)絡(luò)的逐跳轉(zhuǎn)發(fā)天性，這種方式無法保證探針流與業(yè)務(wù)流全程同路徑。

基于業(yè)務(wù)的網(wǎng)絡(luò)性能測量是支撐云網(wǎng)運(yùn)維的重要手段，國際互聯(lián)網(wǎng)工程任務(wù)組（IETF）正在研究、發(fā)展的In-band操作管理維護(hù)（OAM）采用帶內(nèi)機(jī)制，在數(shù)據(jù)包頭增加OAM字段來實(shí)現(xiàn)對網(wǎng)絡(luò)故障檢測、路徑測量、流量等的監(jiān)測，有望成為各種隧道封裝統(tǒng)一的測量機(jī)制。

3.2 基于性能的路由

基于路由的L3尋址是實(shí)現(xiàn)網(wǎng)絡(luò)可達(dá)的基礎(chǔ)手段。現(xiàn)有的內(nèi)部網(wǎng)關(guān)協(xié)議（IGP）和BGP協(xié)議在路由計(jì)算中對網(wǎng)絡(luò)性能，特別是鏈路利用率、擁塞丟包性能、路徑時延等實(shí)時動態(tài)性能變化并不敏感。云網(wǎng)業(yè)務(wù)通?？缭蕉鄠€網(wǎng)絡(luò)域，在域間運(yùn)行的BGP協(xié)議為距離-矢量協(xié)議，其自身甚至對帶寬也不敏感，所以依靠目前的IGP和BGP協(xié)議，無法針對業(yè)務(wù)的服務(wù)質(zhì)量需求和網(wǎng)絡(luò)性能的變化自動調(diào)整業(yè)務(wù)路由。為此，基于IP/MPLS和SDN/Openflow的流量工程隧道被引入到網(wǎng)絡(luò)中完成流量流向的調(diào)整。隧道封裝方式可以有很多種：虛擬局域網(wǎng)（VLAN）、虛擬可擴(kuò)展局域網(wǎng)（VXLAN）、通用路由封裝（GRE）、MPLS、分段路由（SR）等，云網(wǎng)運(yùn)營商可以根據(jù)自身網(wǎng)絡(luò)設(shè)備的支持情況和技術(shù)布局選擇具體方式。

鑒于網(wǎng)絡(luò)中業(yè)務(wù)種類的多樣性和不同業(yè)務(wù)對網(wǎng)絡(luò)資源需求的關(guān)聯(lián)性，優(yōu)化對象只能是網(wǎng)絡(luò)中的高價值流量，或?qū)φW(wǎng)帶寬占用顯著的、數(shù)量少流量高的“大象”流[12]。針對這些高價值流量，應(yīng)用上節(jié)討論的性能測量結(jié)果，采用SDN集中控制方式調(diào)整流量路徑，從而優(yōu)先保障這些業(yè)務(wù)的質(zhì)量。在同一個網(wǎng)絡(luò)管理域中，可以為高價值流量建立端到端流量工程優(yōu)化路徑，當(dāng)存在對丟包、時延等不敏感的背景流量時，網(wǎng)絡(luò)帶寬資源利用率可以接近100%。從網(wǎng)絡(luò)資源全局優(yōu)化角度，業(yè)務(wù)等級數(shù)量越多不一定會使得優(yōu)化效果更好。過多的業(yè)務(wù)等級使得資源分配算法更加復(fù)雜，流向調(diào)整引起的網(wǎng)絡(luò)收斂速度也可能受到影響，甚至導(dǎo)致出現(xiàn)網(wǎng)絡(luò)震蕩。目前在實(shí)踐中，部署2～4個業(yè)務(wù)等級即可取得較好的調(diào)優(yōu)效果。

3.3 流量統(tǒng)計(jì)和狀態(tài)預(yù)測

基于性能的路由落地須要準(zhǔn)確地統(tǒng)計(jì)當(dāng)前在網(wǎng)業(yè)務(wù)流量并預(yù)測調(diào)整后的網(wǎng)絡(luò)狀態(tài)。使用簡單網(wǎng)絡(luò)管理協(xié)議（SNMP）可以以秒級粒度收集網(wǎng)絡(luò)設(shè)備接口流量，業(yè)務(wù)級流量記錄則需要使用Netflow/IPFIX、sFlow等基于采樣的工具，云網(wǎng)的控制面需要將這些信息與網(wǎng)絡(luò)拓?fù)浣Y(jié)合，生成網(wǎng)絡(luò)資源矩陣和流量矩陣。網(wǎng)絡(luò)中某個路徑性能與該路徑上的負(fù)荷有關(guān)，而負(fù)荷是實(shí)時變化的。當(dāng)負(fù)荷的變化主要是由控制面基于策略主動發(fā)起的，在一段時間內(nèi)具有可預(yù)測性，使用流量工程TE技術(shù)進(jìn)行網(wǎng)絡(luò)資源優(yōu)化才可行。這個時間段就是TE調(diào)整的窗口，在這個窗口期內(nèi)，要根據(jù)網(wǎng)絡(luò)性能完成TE策略的計(jì)算或下發(fā)生效。Facebook[11]和Google[12]分別在邊緣PoP和DCI場景實(shí)現(xiàn)了頻度在30 s的調(diào)優(yōu)方案。面對云網(wǎng)系統(tǒng)海量的業(yè)務(wù)流，Telemetry技術(shù)提供效率更高的信息上報(bào)通道，可以提供更加精細(xì)的流量狀態(tài)信息，進(jìn)一步提高調(diào)優(yōu)算法的效果。

3.4 多域編排

對一個由多域異構(gòu)網(wǎng)絡(luò)承載的業(yè)務(wù)，其網(wǎng)絡(luò)轉(zhuǎn)發(fā)面端到端路徑可由多種制式的隧道拼接而成，控制面則歸屬于多個NSP和CSP的管理域范圍。如圖4所示，這需要引入多域編排（MDO）系統(tǒng)，完成多種技術(shù)和多個運(yùn)營商間的資源管理、業(yè)務(wù)管理和域間SLA協(xié)同[13]。單域編排器從SDN控制器獲取資源信息后進(jìn)行本域的資源編排和業(yè)務(wù)編排，并與鄰接域的單域編排器互通。多域編排器則通過應(yīng)用程序編程接口（API）與本管理域中各下級單域編排器實(shí)現(xiàn)通信，完成多個子域間的協(xié)同編排，并實(shí)現(xiàn)對端到端業(yè)務(wù)的SLA保障。

4 結(jié)束語

在業(yè)務(wù)上云和多云時代，云網(wǎng)一體是ICT融合的必由之路。云網(wǎng)運(yùn)營商發(fā)掘和擴(kuò)展網(wǎng)絡(luò)能力，將基礎(chǔ)網(wǎng)絡(luò)接入能力、連接保障能力、按需SLA能力與云化業(yè)務(wù)需求相結(jié)合，提供滿足用戶對高品質(zhì)靈活服務(wù)的需要的新型網(wǎng)絡(luò)服務(wù)，提升網(wǎng)絡(luò)資源的商用價值，實(shí)現(xiàn)供需雙贏。

參考文獻(xiàn)

[1] OPPENHEIMER P. 自頂向下網(wǎng)絡(luò)設(shè)計(jì)（第3版）[M]. 北京：人民郵電出版社， 2011

[2] IEEE- Cloudnet about CloudNet[EB/OL].[2019-01-10].http：//cloudnet2018.ieee-cloudnet.org/about.html

[3] 2018 State of the Cloud Report [EB/OL].[2019-01-10]. https：//www.rightscale.com/lp/state-of-the-cloud

[4] NGUYEN C L， PING W， DUSIT N. Resource Management in Cloud Networking Using Economic Analysis and Pricing Models： A Survey [J]. IEEE Communications Surveys and Tutorials， 2017，19（2）： 954-1001.DOI： 10.1109/COMST.2017.2647981

[5] AT&T NetBond Product Brief [EB/OL].[2019-01-10]. https：//www.business.att.com/products/netbond.html

[6] CHIYAO H， SUBHASREE M， MOHAMMAD A. B4 and After： Managing Hierarchy， Partitioning， and Asymmetry for Availability and Scale in Googles Software-Defined WAN[C]//SIGCOMM 2018. Budapest， Hungary： ACM， 2018. DOI： 10.1145/3230543.3230545

[7] KOK Y， MURTAZA M， JEREMY R. Taking the Edge off with Espresso： Scale， Reliability and Programmability for Global Internet Peering [C]// SIGCOMM '17 Proceedings of the Conference of the ACM Special Interest Group on Data Communication. Los Angeles， USA： 2017. DOI： 10.1145/3098822.3098854

[8] SUNG E Y， TIE X， WONG H Y S， et al. Robotron： Top-down Network Management at Facebook Scale[EB/OL].[2019-01-10]. https：//research.fb.com/publications/robotron-top-down-network-management-at-facebook-scale/

[9] CHRISTOPH A， AJAY B， EMILLIE D. Capacity Planning for the Google Backbone Network [EB/OL].[2019-01-10]. https：//ai.google/research/pubs/pub45385

[10] CHUANXIONG G， LIHUA Y， DONG X. Pingmesh： A Large-Scale System for Data Center Network Latency Measurement and Analysis[EB/OL].（2015-08-23）[2019-01-10]. https：//www.microsoft.com/en-us/research/publication/pingmesh-large-scale-system-data-center-network-latency-measurement-analysis/

[11] BRANDON S， HYOJEONG K， TIMOTHY C. Engineering Egress with Edge Fabric： Steering Oceans of Content to the World [C]//SIGCOMM 2017. USA： ACM， 2017. DOI： 10.1145/3098822.3098853

[12] ALOK K， SUSHANT J， UDAY N. BwE： Flexible， Hierarchical Bandwidth Allocation for WAN Distributed Computing[EB/OL].[2019-01-10]. https：//ai.google/research/pubs/pub43838

[13] RICCARDO G， DAVID P， PAOLO M， et al. Multi-Domain Orchestration and Management of Software Defined Infrastructures： a Bottom-Up Approach[C]//2016 European Conference on Networks and Communications. IEEE Communications Society. USA：IEEE， 2016