


中圖分類號:TN915.03; TP393.03 文獻標志碼:A 文章編號:1009-6868 (2013) 05-0016-006
提出一種支持多樣化網絡業務融合的軟件定義網絡(SDN)基礎架構——SDNIMS。SDNIMS在數據平面上提供了高靈活度的可編程性,支持以軟件定義方式實現不同業務異質化的融合數據轉發;利用網絡虛擬化,為不同的業務網絡提供獨立且相互隔離管理控制平面;支持多種業務在統一的SDN網絡基礎設施中的部署。
軟件定義網絡;業務融合;網絡虛擬化
In this paper, we propose a software-defined network infrasturcture for multiple services (SDNIMS). This infrastructure converges different networks and services. In SDNIMS data plane, highly flexible programmability allows software-defined data forwarding to be implemented for heterogeneous services. The network is also virtualized to provide separate control planes for different network services. The proposed infrasturcture allows diverse services to be deployed in a unified SDN.
software-defined networks; service convergence; network virtualization
軟件定義網絡(SDN)[1]是一種革新的網絡體系架構設計技術。由于其支持控制與轉發分離、開放的編程接口,以及軟件可定義的轉發控制,SDN極大地提高了實現網絡與業務的管理控制的靈活性。當前,SDN已在諸多領域成功應用,但SDN在核心網絡架構設計中的應用仍存在大量問題,包括SDN對網絡/業務異構性支持、在大規模網絡中控制平面的可擴展性與安全性等。
網絡與業務融合是未來網絡發展的重要趨勢,網絡基礎設施應能支持不同業務融合高效地轉發。SDN技術為實現這一目標提供了一條嶄新途徑。利用SDN的可編程性,設計者能夠有效解決網絡架構設計中復雜的網絡管理與控制問題。
為使SDN網絡支持業務融合與服務異質化的網絡環境,首先需要在SDN轉發平面上提供高靈活度的軟件可編程性,以支持多樣化的用戶需求、設備、通信協議及數據處理方式;其次,需要在控制平面上對不同業務網絡進行區分和隔離。將SDN網絡資源映射到不同虛擬網絡,實現網絡虛擬化是一種可行的隔離方案。
1 SDN相關工作
為使SDN網絡支持業務融合,文獻[2]提出了一種基于OpenFlow的自治SDN框架模型,支持多種業務部署在統一的物理網絡上,并在控制平面中利用自治網絡技術提高網絡和業務的自管理能力。OpenFlow 1.3協議[3]在轉發平面中引入了多級流表構成流水線,流表項的匹配采用類型/長度/值(TLV)格式。TLV格式易于擴展,適于支持多種不同的業務和網絡協議。歐盟FP7的SPARC[4]多個研究項目探索了如何擴展OpenFlow以滿足電信級網絡的需求,如支持標簽交換和多業務融合。
SDN網絡的虛擬化是多業務SDN網絡體系結構研究中的另一關鍵技術[5]。虛擬化需要通過抽象、分配、隔離等機制將SDN物理網絡映射為多個虛擬SDN網絡,且能夠在各虛擬SDN網絡上互不影響地部署不同的網絡架構和協議體系,支持不同的網絡業務,并可按需對虛擬網絡進行動態的資源配置。
現有的SDN網絡虛擬化方案可分為3類。一是基于交換機的虛擬化[6],此類方案提供良好的隔離性,但不適于動態的擴展和調整。第二類包括ADVisor[7]、FlowVisor[8]等方案,在交換機與控制器間加入一個虛擬化層。此方案簡單易部署,但其虛擬化層對用戶透明,用戶無法通過軟件編程方式來動態調整其資源配置。第三類方案在控制器上實現虛擬化,如SPARC、FlowN[9]等,將虛擬化管理作為網絡操作系統(NOS)的一項基礎服務,支持虛擬化配置的動態調整。
文獻[10]探索了在OpenFlow網絡中部署內容中心網絡(ICN)的方法。研究表明,基于SDN進行創新網絡研究通常需擴展SDN功能。然而擴展現有SDN的架構和功能,往往需要代碼重寫和升級,缺乏靈活性。理想方式是支持用戶直接對設備編程,定義新屬性和功能。
2 面向多業務融合的SDN
基礎架構
2.1 目標與需求
業務融合要求在統一的SDN基礎設施上支持多樣化的業務和應用。不同種類的業務通常需要不同的傳輸模式、協議和網絡管理和控制方式。SDN控制與轉發分離的設計思想以及開放、靈活、可編程的特征,為實現多業務融合提供了一條新途徑。本文的目標是對SDN網絡架構進行擴展,提出一種面向多業務類型、具有高靈活性和可編程性的SDN網絡基礎架構——SDNIMS。在該架構設計中需解決以下問題:
(1)支持多樣化網絡業務的融合
SDNIMS架構支持業務運營者以軟件定義方式部署多種類型網絡業務。該架構應滿足不同特性業務的需求,包括實時話音、圖像和廣播電視業務,傳統互聯網等,并支持創新網絡技術的研究;也可支持不同數據傳遞模式,在物理接口支持的情況下,實現基于電路交換、標簽交換或光交換的SDN。業務開發者能根據業務特性獨立地選擇不同的數據傳輸模式、通信協議以及數據處理方式,并在該架構中部署網絡業務或進行創新性研究。
(2)網絡的虛擬化與隔離
SNDIMS在轉發平面上支持多業務的融合;同時也支持不同業務具有各自獨立的控制邏輯。SDNIMS將物理網絡資源映射到不同虛擬SDN網中;同時,保證虛擬網之間相互隔離,包括網絡拓撲/資源的隔離、數據流隔離以及控制流的隔離。網絡虛擬化對于上層用戶透明,不同的業務提供者可在虛擬網中部署完全異質化的網絡架構(尋址/路由和網絡協議)、業務以及控制管理邏輯。
(3)物理網絡的高靈活可編程性
OpenFlow利用軟件定義的流表實現對轉發行為的可編程。SDNIMS進一步擴展了用戶對物理設備的可編程能力。除流表外,SDN交換機還具有多方面可編程性,用戶可對交換結點的多種行為進行細粒度編程,滿足業務多樣化以及日趨復雜的網絡管理控制的需求。交換結點的可編程性包括:可編程的傳輸轉發/交換方式(如分組轉發、虛電路交換、標簽交換等)、可編程的網絡協議、可編程的數據流處理(轉發、過濾、QoS控制等)以及可編程的網絡管理控制(性能監測、資源管理等)。
2.2 SDNIMS體系架構
SDNIMS的體系結構模型如圖1所示。圖1整體上分為3個層次:物理網絡層、SDN控制器層、業務管理與控制層。
物理網絡層(即數據轉發層)完成數據傳輸與轉發功能,是整個架構的底層基礎設施。物理網絡由一系列支持SDN的交換結點依據運營商規劃的拓撲互聯而成。SDN結點在上層控制器的控制下進行數據流處理(利用擴展的OpenFlow協議)。SDNIMS架構中的交換結點(及物理網絡)均支持多樣化、高靈活的可編程。在SDN控制器層的統一策略和編程控制下,物理網絡構成統一融合的多業務數據傳輸平面,支持多種業務以不同接入方式、傳輸/交換模式和網絡協議進行傳輸。
SDN控制器層在架構中承擔SDN控制器的角色,在邏輯上可看作是一個集中式控制器,對數據轉發層的行為進行統一控制和管理。在物理上,控制器層可由若干相互協作的控制器構成,或采用云計算平臺實現,以提高可靠性和可擴展性。對外,整個SDN控制器層表現為一個集中式的邏輯控制器實體。
在功能結構上,控制器層由網絡操作系統(NOS)及若干基本功能組件(拓撲、資源管理等)構成。其南向接口采用擴展的OpenFlow協議,實現對物理設備的編程和控制;其北向提供SDN應用編程接口(API),使高層軟件能對物理網絡中的數據傳輸進行編程和控制。SDN網絡的虛擬化是SDNIMS控制器層的重要功能,實現底層物理網絡與虛擬SDN網絡之間的映射,并保證虛擬網絡之間相互隔離。
業務管理/控制層,實現各種業務網絡的控制和管理功能。SDNIMS支持基于虛擬網絡構建業務網絡,不同虛擬網分配給不同的業務提供者,獨立部署其業務及其管控邏輯。在用戶視角上虛擬SDN網絡與實際SDN網絡并無差異,均向用戶提供NOS、基本的SDN功能及開放的SDN API。業務提供者可在業務控制器上利用SDN的方法,在虛擬SDN網中部署其網絡業務和應用。
總體來看,SDNIMS允許不同業務網絡的數據流共享統一融合的數據轉發平面;同時通過網絡虛擬化,將不同業務網絡的控制平面的功能相互隔離,分別獨立由其各自業務提供者來進行控制和管理。
2.3 SDNIMS功能模型與組件
SDNIMS架構的功能模型及其主要功能組件如圖2所示。架構的底層由高可編程的SDN交換機構成。通過擴展的OpenFlow協議,上層軟件可對交換機進行多種功能的軟件定義,以支持網絡虛擬化與多業務融合。SDNIMS的控制部分包括兩個層次:SDN控制器層負責全局SDN網絡的管理控制,業務管理控制層負責業務網絡(虛擬SDN網絡)的管理控制。
2.3.1 高靈活可編程SDN交換機
OpenFlow交換機僅支持通過流表實現數據流處理的可編程。該方式適合于互聯網的分組轉發,但難以滿足異構網絡協議和多業務融合的需求。新型SDN交換機需提供更多的可編程性,包括:
(1)流表匹配項的可編程
OpenFlow的流表使用分組中一組固定字段作為數據流的匹配項。這實際上是對IP協議進行了預先優化,但無法靈活支持其他協議類型,包括用戶定義的新型協議。新型交換機將允許用戶靈活定義流表匹配項的格式、位置和類型等屬性,實現對異構協議的支持。
(2)數據流操作與處理的可編程
現有OpenFlow流表無法支持諸如隧道封裝、標簽交換、服務質量(QoS)控制等復雜的數據流處理能力,而這些能力往往是實現網絡業務管理控制必需的。解決這一問題的方法是提供一種軟件定義的方式,使業務開發者能夠按需擴展數據流的處理能力。
(3)網絡維護/管理處理與操作的可編程
交換機設計將性能監測、資源/隊列管理等維護管理的底層操作行為標準化,并開放其編程接口。上層軟件能夠編程和配置這些底層操作,設計基于軟件定義的網絡的維護管理功能。
SDN交換機設計結構分為控制通道與數據通道兩部分,如圖3所示。為支持異構網絡協議,數據通道中引入了可編程的協議解析組件,可根據協議描述模版,解析到達分組的協議格式,并提取指定字段作為流表匹配項。協議描述模版由上層控制器配置,使解析組件能識別任意協議格式。輸出的流表匹配項以TLV格式表示,在后續的數據流水線(Pipeline)中用于進行流表匹配。
數據流水線中使用并行化的多級流表。通過編程,可將不同業務/協議的流表相互獨立,配置成不同的流水線,進行并行處理。流表的操作集合是可擴展的,上層軟件可按需定義和添加新的操作方法,以支持復雜的數據流處理,如標簽交換、QoS操作、隧道封裝、安全性等。
系統支持以軟件定義的方式實現網絡管理/維護功能。交換機還增加了與網絡管理相關的操作和處理功能。通過對一些特殊流表的配置,上層軟件可利用這些操作協同完成網絡維護/管理功能。同樣,上層軟件可定義交換機上各隊列的屬性、調度策略、帶寬和優先級,實現網絡資源的精細化管控。
交換機的控制通道負責與上層控制器的交互,其協議采用擴展的OpenFlow。協議擴展用于支持交換機上新增的可編程屬性,包括可編程的協議解析和數據流操作,以及性能測量與隊列管理等。
2.3.2 SDN控制器層
SDN控制器層對整個物理網絡實現管理和控制,同時向上層提供編程接口。在邏輯上,控制器層是一個集中式實體,包括兩部分:網絡操作系統(NOS)以及一組SDN基礎功能組件。NOS及功能組件主要提供了數據流編程與控制、網絡管理、網絡虛擬化等3類功能。
數據流編程/控制功能用于定義交換機上與數據流處理相關的行為和配置,如接口配置、協議描述模板、流表及流表的操作等。網絡管理組件提供網絡維護管理相關的功能,如拓撲發現和管理、路由,以及網絡資源管理和性能監測等。
為支持多業務融合,控制器層實現了SDN網絡的虛擬化。不同網絡業務分別在隔離的虛擬網中開發和部署。虛擬網管理組件的結構如圖4所示。圖4實現物理網絡與虛擬網之間的拓撲與資源的映射、網絡事件的映射與分發以及資源分配與隔離等功能。虛擬網向上層軟件提供一個虛擬的NOS以及一組SDN服務組件及其API接口。系統從兩個方面實現虛擬網絡之間的隔離。一方面通過統一控制的資源及網絡事件映射,將不同虛擬網的管理控制平面相互隔離;另一方面,通過對底層交換機的編程(包括對流表、隊列的配置),使不同虛擬網絡的數據平面也實現了相互隔離。
轉發平面為支持多業務虛擬網,交換機中的多級流表和隊列將被編程配置成圖5所示的形式。利用多級流表的特性,交換機對不同虛擬網絡使用的流表進行了隔離。流表被進行邏輯劃分,分別為每個虛擬網形成一條獨立流表流水線,并為每條數據流水線配置獨立的數據轉發隊列。為區分不同虛擬網的數據流,利用交換機對網絡協議和操作的可編程性,在邊緣交換機上對不同虛擬網的數據流添加虛擬網標識(VNID)標簽(在全網中標識其所屬虛擬網)。交換機多級流表中的0號流表作為全局流表,用于匹配和識別到達分組的VNID,并根據VNID將分組引導到其對應虛擬網的流水線上。若到達分組無可匹配VNID,則控制器可向0號流表下發一條特殊流表項,為到達分組添加相應的VNID標簽,然后進行后續的處理。
SDNIMS允許不同的虛擬網采用不同的網絡體系和尋址路由架構。虛擬SDN控制器可根據各自的需要生成專用的流表,這些流表經控制器層的虛擬網管理組件的映射,被編程和配置到物理網絡交換機中該虛擬網的流表流水線中。在圖5中,虛擬網1支持信息中心網絡(ICN)網絡架構,其流表中使用統一資源定位符(URL)進行匹配和數據轉發;虛擬網2支持標簽交換,在其流表中利用分組的多協議標簽交換(MPLS)標簽來進行轉發;采用傳輸控制協議/網間協議(TCP/IP)架構的虛擬網絡則在流表中采用傳統的k元組匹配方式處理分組。
2.3.3 業務網絡的管理與控制層
不同虛擬網絡用戶可獨立開發和部署其業務網絡的控制和管理功能。SDNIMS向虛擬網用戶提供標準SDN網絡編程API,用戶可使用虛擬網NOS、SDN組件及API,利用SDN設計方法和工具,在虛擬SDN網絡中開發和部署其網絡業務和應用。在SDNIMS中,業務管控系統的功能和設計結構是與其網絡業務特性高度相關的,取決于虛擬網用戶的設計。
3 SDNIMS架構的應用場景
實例
SDNIMS的一個應用場景如圖6所示。圖6將現有的話音通信業務、廣播電視業務和傳統互聯網部署在統一的SDN物理網絡上。不同的網絡業務具有不同的需求。話音業務實時性要求高,在管理控制上類似于電路交換的控制。廣播電視業務對于網絡帶寬需求較高,同時需要交換節點能夠支持廣播式轉發。
多業務部署時,首先為每種業務網絡定義所需的網絡拓撲及資源屬性(包括帶寬、流表、優先級等),然后定義各業務網絡的數據平面所采用的傳輸協議。SDNIMS交換機支持用戶自定義的傳輸協議,用戶可根據需要選擇高效的數據傳輸模式。例如,話音業務和廣電業務均可采用標簽交換形式,從而避免繁瑣的TCP/IP封裝。在此基礎上,運營者可利用SDN API來設計和部署其業務管理與控制邏輯。
4 結束語
本文提出了一種支持多業務融合的SDN網絡基礎架構——SDNIMS。SDNIMS在數據平面上提供了高靈活度的可編程性,支持以軟件定義方式實現不同業務異質化數據的融合轉發;同時利用網絡虛擬化,為不同的業務網絡提供獨立且相互隔離管理控制平面,支持多樣化業務在統一的SDN基礎設施中的融合。
參考文獻
[1] MCKEOWN N. Software-defined networking: the new norm for network [R]. White Paper. ONF, 2012.
[2] WANG W, HU Y, QUE X, et al. Autonomicity design in Openflow based software defined networking [C]//Proceedings of the 2012 IEEE Globecom Workshops(GC Wkshps12), Dec 3-7,2012, Anaheim, CA, USA. Piscataway, NJ, USA: IEEE, 2012:818-823.
[3] PFAFF B, LANTZ B, HELLER B, et al. OpenFlow switch specification, version 1.3.0 [S]. Open Networking Foundation, 2012.
[4] EU FP7 project: SPARC (Split Architecture Carrier Grade Networks) [EB/OL]. [2012-09-12]. http://www.fp7-sparc.eu/.
[5] CHOWDHU N M K, BOUTABA R. A survey of network virtualization [J]. Computer Networks, 2010,54(4):862-876.
[6] SONKOLY B, GULY?S A, CZENTYE J, et al. Integrated OpenFlow virtualization framework with flexible data, control and management functions [C]//Proceedings of the 31st Annual Joint Conference of the IEEE Computer and Communications (INFOCOM12), Mar 25-30,2012, Orlando, FL, USA. Piscataway, NJ, USA: IEEE, 2012.
[7] SALVADORI E,DORIGUZZI CORIN R, GEROSA M, et al. Demonstrating generalized virtual topologies in an OpenFlow network [J]. ACM SIGCOMM Computer Communication Review, 2011,41(4):458-459.
[8] SHERWOOD R, GIBB G, YAP K, et al. Flowvisor: A network virtualization layer [R]. OpenFlow Switch Consortium, 2009.
[9] DRUTSKOY D, KELLER E, REXFORD J. Scalable network virtualization in software-defined networks [J]. IEEE Internet Computing, 2013,17(2):20-27.
[10] VELTRI L, MORABITO G, SALSANO S, et al. Supporting information-centric functionality in software defined networks [C]//Proceedings of the IEEE International Conference on Communications (ICC12), Jun 10-15,2012, Ottawa, Canada. Piscataway, NJ,USA: IEEE, 2012: 6645-6650.