運營商SDN云網協同架構和關鍵技術研究

魯子奕　楊文斌

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

關鍵詞：云網協同;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

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

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

1 運營商SDN云網協同架構

的業務需求

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

（1）骨干網絡需要靈活調度、快速部署;因此，運營商需要改變現有業務流程和模式，以滿足用戶快速靈活的上云業務需求。

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

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

（4）重構云網協同架構，需要運營商建立云網一體化新生態。運營商網絡資源與各家云商對接上的應用程序編程接口（API）規范和標準差別很大，需要考慮如何采用高效通用的南向接口實現對接。

2 運營商云網協同業務面臨

的挑戰

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

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

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

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

3 運營商云網協同架構的

設計要點

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

3.1 統一業務編排器

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

統一業務編排器管理和控制全網的設備，展現全局網絡流量動態，收集全向網絡拓撲，統一呈現網絡及設備狀態。編排器還實現全網資源統一管理、業務統籌調度與路徑優化，統一編排用戶上云、云間各種組網的業務流程，為用戶提供云網一站式打通。

針對統一業務編排器，我們提出了2點建議：

（1）業務編排器整個系統架構按照業務和功能進行拆分，并基于現有成熟的微服務架構實現最小粒度化的服務模塊。微服務可以按需組合完成各類業務場景開通，實現完全解耦的模塊化系統架構設計。

（2）統一業務編排器的設計需由具備既熟悉網絡的底層架構、技術和協議，又掌握新型云網絡技術和軟件架構的全棧技術的專業架構師來完成，同時還需要與優秀的系統軟件架構師（包括客戶和合作伙伴）共同合作。

3.2 優化業務流程

運營商的系統會涉及到業務、產品、運營和市場等多方面不同需求和流程，在傳統運營模式下，部門多，環節多，業務周期長，難以適應云網業務的發展。優化系統業務流程在SDN架構設計中至關重要，通過SDN架構重構，抽象業務邏輯，重新定義用戶權限與流程，包括運維人員、最終用戶、云服務商、客戶經理等不同角色賬戶自服務、業務便捷管理等功能，重新規范運營商的業務流程和自動化以實現運營商業務。

針對業務流程的情況，我們的具體建議為：

（1）運營商需要在需求階段和甲方一起對流程進行梳理、確認。因流程的更改會導致軟件系統主要結構的更改，甚至會導致研發和項目進展出現停頓、瓶頸甚至反復，運營商需要在需求階段就對流程進行梳理和確認。

（2）軟件設計架構盡可能實現微服務和模塊化。由于云網協同和SDN項目會涉及運營商內部多個業務部門，業務需求在不同部門、不同時間點可能有不同的理解，因此設計架構上需盡可能微服務和模塊化，即使將來流程調整也不至于推倒重來。

3.3 制定SDN協同器和通用服務

提供者接口（SPI）

SDN協同器負責全程全網（物理網絡）的統一收集、抽象和組建，需要進行網絡資源數據和拓撲的搜集，從而全面掌握服務商的網絡資源，包括設備、鏈路、端口、拓撲等。SDN協同器能夠實現網絡資源和能力的抽象化、模型化，是業務平臺能力和服務支持的基礎組件。通過SDN協調器實現物理網絡向邏輯網絡的轉化，并通過兼容各種異構SDN控制器系統與云商API互聯，與運營商網絡支撐系統對接，從而實現對服務商網絡的統一、快捷和安全的控制和管理[7]。

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

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

（1）南向面向服務商網絡基礎設施廠商SDN控制器、SD-WAN控制器以及第三方云平臺的配置和管理，需要實現對不同廠家控制器環境業務下發及高可用（HA）機制，實現主/備控制器的高可用HA狀態的監測、協商同步和故障處理等。

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

3.4 規范API

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

協同編排器API包括北向API網絡、南向API網絡和東西向集群內網絡[8]。

（1）北向API網絡：通用控制器系統和統一編排器通過該網絡發送和接收北向API的網絡業務信息。

（2）南向API網絡：通用控制器系統通過該API和南向廠商控制器（或者設備）發送和接收的網絡管理信息。

（3）東西向集群API網絡：通用控制器系統通過該網絡備份數據庫數據，發送和接收東西向業務API。

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

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

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

4 運營商云網協同架構涉及

的關鍵技術

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

如圖2所示。文章中，我們將重點介紹云網協同架構中會涉及到幾項關鍵技術。

4.1 云中心VXLAN/EVPN和云商

對接

隨著公有云的真正崛起，SDN作為云網協同的必備技術，其發展經歷了從基于Openflow的SDN流派到網絡廠商的私有SDN流派，再到后來基于開放VXLAN/EVPN的廣義SDN流派。基于VXLAN 的Overlay由于其簡單、易擴展等優勢已經成為數據中心網絡最炙手可熱的技術。

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

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

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

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

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

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

4.2 骨干網技術：MPLS還是

SRTE

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

針對骨干網技術，我們的建議如下：

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

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

5 SD-WAN接入技術

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

針對SD-WAN技術，整合SD-WAN架構兼顧運營商MPLS/SRTE骨干網，真正實現為客戶提供全國范圍內集MPLS VPN、IPSEC VPN、SD-WAN等多種應用的WAN解決方案，解決運營商“最后一公里”的難題。

（1）由于打通了MPLS租戶VPN與SD-WAN租戶VPN（也有稱之為“混合架構”能力），該架構非常適合實現骨干網、SD-WAN與主要云運營商對接，開展云聯網業務

（2）運營商在部署這種架構時，建議將SD-WAN接入控制器和骨干網控制器整合。整合的控制器將MPLS 服務商PE節點統一納管。這樣在開通VPN業務時就可以實現完全的業務自動化

6 結束語

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

參考文獻

[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