基于ACR的硬件抽象層結構及關鍵技術研究

目前,大多數(shù)路由器均采用分布式轉發(fā)、集中式路由處理的體系結構[1]。該結構方式使主處理單元與各從處理單元可以根據(jù)所處位置及執(zhí)行任務的不同采用不同的處理方式,但也使頂層管理軟件對底層各從處理單元難以進行協(xié)調(diào)統(tǒng)一的管理。硬件抽象層hal(hardware abstraction layer)在邏輯上介于底層硬件與上層協(xié)議軟件之間,維護兩者之間的數(shù)據(jù)傳遞,并對底層各接口模塊進行管理,屏蔽底層硬件細節(jié),使得應用軟件可以通過控制hal達到操縱底層硬件的目的。高性能路由器硬件抽象層的提出[2]成功解決了分布式路由器面臨的通用性支撐軟件系統(tǒng)結構的設計問題,為構建開放通用的路由器軟件基礎平臺提供了保證。

隨著路由器承載業(yè)務能力的不斷增強,大規(guī)模接入?yún)R聚路由器的設計與實現(xiàn)也被提上了議事日程。acr(大規(guī)模接入?yún)R聚路由器)是3tnet(高性能寬帶網(wǎng))網(wǎng)絡的關鍵設備。該設備采用acr寬帶接入方式,即通過帶有遠端用戶接口單元(riu)、基于以太網(wǎng)傳輸接口的分合路器(emdi)組成樹形分叉地域分布式系統(tǒng)構架,保證大規(guī)模的用戶直接接入骨干高速網(wǎng)絡,實現(xiàn)視頻點播、網(wǎng)絡電視、ip電話等寬帶業(yè)務,從而更加減化了網(wǎng)絡拓撲結構,使業(yè)務引入更加快速,運營策略更加多樣化。

大規(guī)模用戶接入方式也給路由器硬件抽象層的實現(xiàn)方式及信息的實時、高速傳輸提出了新的挑戰(zhàn),主要表現(xiàn)在以下幾個方面:首先,承載業(yè)務量的數(shù)量及種類的增多對路由器內(nèi)部通信的實時性、高效性提出了更多的要求;其次,大規(guī)模用戶接入方式增加了路由器對外接口的數(shù)量,從而帶來了設備管理上的難度;再次,從系統(tǒng)的通用性及可擴展性考慮,要求構建一種具有可擴展性且不依賴于硬件具體實現(xiàn)方式的軟件體系結構,方便路由軟件的移植和應用。由此可見,硬件抽象層的高度穩(wěn)定性、可擴展性及可靠性將直接影響路由器的各項性能指標。

由于大規(guī)模用戶接入方式的特性,使得以前基于ipv6路由器的硬件抽象層的實現(xiàn)方式已經(jīng)不適應數(shù)據(jù)高速傳輸及多用戶接入的管理方式。本文將在討論硬件抽象層基本結構的基礎上,提出一種適用于大規(guī)模接入?yún)R聚路由器的hal的通用性軟件結構設計及實現(xiàn)方式,提供高效、可靠的內(nèi)部通信,并針對多用戶接入數(shù)量不確定的情況,提出動態(tài)加載虛擬驅(qū)動模塊的實現(xiàn)方法,增強路由器面向acr接入方式的可用性。

1 硬件抽象層基本結構及功能實現(xiàn)

根據(jù)文獻[2]提出的方案,高性能路由器硬件抽象層可分為內(nèi)部通信、虛擬驅(qū)動及設備管理三大模塊,這三部分模塊相互配合,共同完成面向?qū)嶋H的用戶設備接口的功能模擬及硬件細節(jié)的屏蔽,并對其進行統(tǒng)一協(xié)調(diào)的管理。硬件抽象層對用戶設備接口的功能模擬主要由虛擬驅(qū)動模塊完成,包括數(shù)據(jù)包的收發(fā)及協(xié)議報文的預處理等工作,為上層協(xié)議軟件提供標準的api函數(shù);而對用戶設備的接口管理則由上層網(wǎng)絡管理軟件通過設備管理模塊對其進行管理配置及監(jiān)控;內(nèi)部通信模塊運行于內(nèi)部以太網(wǎng)絡,協(xié)調(diào)各模塊之間的功能接口,保證各從處理單元與主處理單元之間實時可靠的數(shù)據(jù)傳輸。其基本結構如圖1所示。

根據(jù)各模塊的功能可知,硬件抽象層內(nèi)部通信模塊是各分處理單元與主處理單元信息交互的重要傳輸通道。內(nèi)部通信模塊匯集各底層設備的數(shù)據(jù)并根據(jù)類型分流至各上層處理模塊,同時,數(shù)據(jù)維護模塊對虛擬設備及各處理單元的維護信息也需要通過內(nèi)部通信模塊進行。因此,內(nèi)部通信模塊采用何種基于內(nèi)部以太網(wǎng)的數(shù)據(jù)傳輸實現(xiàn)方式,對路由器內(nèi)部數(shù)據(jù)的實時、有效、可靠傳輸起著至關重要的作用。當前內(nèi)部通信模塊采用基于分隔符的tcp傳輸方式,在應用層數(shù)據(jù)包的起始部分附加有特定格式的分隔符和數(shù)據(jù)長度域,解決了由于nagle算法產(chǎn)生的包粘滯問題[3]。但該方式?jīng)]能解決tcp傳輸方式的消耗過大、實時性不強的問題[4]。同時,消除分割符恢復報文的完整性也增加了應用程序的處理復雜度,從而不可避免地增加系統(tǒng)的開銷并降低系統(tǒng)的實時性。系統(tǒng)的實時性對于用戶業(yè)務急劇增多的acr路由器而言是一個迫切需要解決的問題。udp是一個面向消息的傳輸協(xié)議[5],其最大數(shù)據(jù)緩沖區(qū)長度為8192～65536字節(jié),滿足一次傳輸一個完整報文的條件。在內(nèi)部以太網(wǎng)中采用udp傳輸方式具有明顯的優(yōu)勢。但由于udp協(xié)議的無連接性,導致它是一個不可靠傳輸,文中第二部分將討論如何實現(xiàn)一種基于udp的內(nèi)部通信的可靠性傳輸機制。

硬件抽象層對用戶設備接口的功能模擬主要通過虛擬驅(qū)動進行,路由器業(yè)務類型的擴展使得用戶接口數(shù)量增多并呈現(xiàn)接入時間的不確定性,從而帶來用戶設備管理上的難度。針對此種情況,文中第三部分提出動態(tài)加載虛擬驅(qū)動模塊的實現(xiàn)方法,增強路由器面向多用戶接入方式的可用性。

2 基于udp傳輸方式的內(nèi)部通信的可靠性實現(xiàn)

內(nèi)部通信模塊處于硬件抽象層的底層,運行于內(nèi)部交換網(wǎng)絡,完成底層硬件與上層控制軟件的數(shù)據(jù)傳輸,實現(xiàn)對底層硬件的初步屏蔽分離;針對分布式體系結構特點及多用戶接入的業(yè)務需求,內(nèi)部通信模塊以clientserver的方式分別運行于主處理單元模塊及各線路接口單元模塊上,采用udp傳輸協(xié)議進行通信,主要基于以下幾點考慮:

首先,udp協(xié)議是一個無連接協(xié)議,傳輸數(shù)據(jù)之前源端與終端不需建立連接,因此不需維護連接狀態(tài)。這樣服務器端可以使用一個或幾個端口同時向多個客戶端發(fā)送消息,符合分布式結構體系的要求。

其次,udp信息包很短,只有8個字節(jié),相對于tcp的20個字節(jié)的信息包的額外開銷很小,便于數(shù)據(jù)的快速傳遞。

再次,吞吐量不受擁塞控制算法的調(diào)節(jié),只受應用軟件生成數(shù)據(jù)的速率、傳輸帶寬和計算機性能的影響,適用于內(nèi)部以太網(wǎng)絡的數(shù)據(jù)傳輸。

但由于udp方式的無連接性,使得udp傳輸?shù)目煽啃圆粡?。而可靠性是?nèi)部通信模塊所必須具有的性能,因此考慮在應用軟件中實現(xiàn)udp傳輸方式的可靠性保證,主要采用以下方式:

2.1 多線程無連接的c/s通信方式

服務器端運行在linux操作系統(tǒng)下,采用多線程方式收發(fā)各類數(shù)據(jù);客戶端運行在vxworks操作系統(tǒng),采用多任務方式收發(fā)各類數(shù)據(jù)。這樣由于多線程及多任務并行運行的特性,在內(nèi)部以太網(wǎng)的傳輸條件下,使得收發(fā)數(shù)據(jù)的速率可以滿足系統(tǒng)的要求?；镜幕趗dp協(xié)議的無連接客戶端/服務器端通信程序如圖2所示。

該通信過程采用多個客戶端(各從處理單元)對一個服務器端(主處理單元)的方式,使多個用戶接口模塊可以在不同時間接入主控。內(nèi)部通信根據(jù)所傳遞數(shù)據(jù)的不同類型,采用相對固定的不同的端口號,不同的客戶端采用不同的ip地址,從相同的端口收發(fā)同類數(shù)據(jù)。在服務器端通過select()系統(tǒng)調(diào)用,既可以輪詢各個socket端口以便及時接收不同端口的數(shù)據(jù),又起到定時器的作用。當規(guī)定時間內(nèi)收不到數(shù)據(jù)時,能夠及時返回繼續(xù)在阻塞模式下等待,從而既能及時收發(fā)數(shù)據(jù),又降低資源消耗。

2.2 三次握手過程

每個客戶端與服務器端進行真正的數(shù)據(jù)傳輸之前,首先要進行一個握手的建立過程,如圖3所示。握手過程成功后則表示雙方通信通道正常,只有在得知握手成功后雙方才可以正常地收發(fā)報文,從而克服了udp協(xié)議方式的面向無連接性。為了隨時檢測和維護雙方鏈路的通連性,每個客戶端與服務端在一定的間隔時間內(nèi)要互發(fā)keepalive報文。如果在規(guī)定的時間內(nèi)收不到對方的keepalive報文,說明斷鏈,要進行相應的斷鏈處理。

2.3 接收端丟失確認及滑動窗口

發(fā)送udp報文時在自定義的內(nèi)部數(shù)據(jù)頭中加入所發(fā)送數(shù)據(jù)的序號,接收端收到后發(fā)送確認信息,如果發(fā)送方在規(guī)定時間內(nèi)沒有收到確認信息,則認為該包丟失,會連同原包的序號重新發(fā)送。

滑動窗口的目的主要是為了實現(xiàn)流量控制,防止擁塞。每個發(fā)送方維護一個重發(fā)隊列,保存著一定數(shù)量的發(fā)送而沒被確認的報文,該隊列剩余空間的大小可以限制應用部分發(fā)包的速率。由于udp協(xié)議是基于消息的傳輸協(xié)議而非基于流的,因此不必考慮發(fā)送端可以接收多少數(shù)據(jù),只需知道能否接收數(shù)據(jù)即可。

總之,采用udp傳輸控制方式主要考慮到其傳輸簡單快速、額外開銷較小的特點,但這是以犧牲一定的可靠性為前提的,因此必須在應用程序中增加可靠性保護機制。在實際應用中證明上述方法可靠高效,能夠維護內(nèi)部通信有序、快速的數(shù)據(jù)傳輸。

3 基于多用戶的用戶接入管理

在linux操作系統(tǒng)下,系統(tǒng)把設備映射為一個特殊的設備文件,用戶程序可以像對其他文件一樣對該設備文件進行讀寫操作。虛擬驅(qū)動模塊運行在linux操作系統(tǒng)下,模擬從處理單元上的接口單元,形成收發(fā)協(xié)議報文功能和數(shù)量與此一致的硬件抽象層虛擬接口單元。因此,每個實際的接口單元都在內(nèi)核中對應一個注冊的虛擬設備,以便于上層控制軟件對數(shù)據(jù)平面的管理與數(shù)據(jù)交互。

3.1 多用戶虛擬設備驅(qū)動程序的動態(tài)加載

虛擬驅(qū)動在內(nèi)核中的功能通過動態(tài)加載方式實現(xiàn)。通常的動態(tài)加載方式是將驅(qū)動程序作為一個整體模塊,在需要時再加入內(nèi)核[6];由于多用戶接入方式使得在某一時刻內(nèi)核中注冊的接口單元數(shù)量不確定,如果實施一次性加載會冗余太多,不利于資源的有效利用。因此,在內(nèi)核中加載一個基本模塊的前提下,實現(xiàn)各虛擬設備的動態(tài)加載過程,達到以一個基本的虛擬設備控制多個設備驅(qū)動模塊的功能。

如圖4所示,對虛擬驅(qū)動設備的控制由內(nèi)部通信模塊與設備管理模塊共同完成。設備管理模塊通過內(nèi)部通信模塊下達加載、卸載虛擬驅(qū)動的命令,通過內(nèi)部通信模塊與虛擬驅(qū)動的控制通道進行。內(nèi)部通信模塊通過調(diào)用ioctl()采用不同的命令字完成對虛擬驅(qū)動模塊的控制過程。

基本驅(qū)動模塊的加載采用通常的驅(qū)動模塊加載方式,即調(diào)用module_init()函數(shù)進行基本模塊的初始化及在內(nèi)核中的注冊過程。以該基本驅(qū)動模塊為基礎,當內(nèi)部通信模塊收到加載某個用戶設備接口的命令后,通過調(diào)用該基本模塊的base_ioctl()在內(nèi)核中注冊一個新的驅(qū)動設備,該注冊設備才是與實際接口單元相對應的虛擬驅(qū)動模塊,應用程序?qū)τ脩粼O備數(shù)據(jù)的讀寫都是通過這些注冊的接口設備而非基本設備提供的標準函數(shù)進行。這樣的動態(tài)加載過程使得當沒有設備加載時在內(nèi)核中只存在一個基本的虛擬驅(qū)動模塊,只有需要注冊的用戶才將其對應的設備接口的虛擬驅(qū)動模塊加載到內(nèi)核中,從而減少系統(tǒng)冗余,便于管理。

各用戶接口單元與虛擬驅(qū)動的數(shù)據(jù)交互通過內(nèi)部通信模塊與虛擬驅(qū)動的數(shù)據(jù)通道進行,所對應的系統(tǒng)調(diào)用為該注冊設備的dev_ioctl()。在該功能函數(shù)中,實現(xiàn)用戶空間與內(nèi)核空間的數(shù)據(jù)交互。

3.2 對多用戶接口設備虛擬驅(qū)動的管理

為實現(xiàn)內(nèi)核虛擬驅(qū)動模塊與實際接口單元的一一對應,必須解決各驅(qū)動模塊的命名原則問題。將每個實際接口單元在接入段拓撲中的位置設置為不同的參數(shù),在內(nèi)部通信中這些參數(shù)作為傳輸數(shù)據(jù)的報頭信息出現(xiàn),根據(jù)它們可以生成一個唯一的字符串作為對應該接口單元的虛擬驅(qū)動設備名稱,而且根據(jù)設備名稱亦可還原出實際接口單元的拓撲信息,以供內(nèi)部通信使用。在內(nèi)核中維護一個由各注冊設備名稱所組成的動態(tài)鏈表,每個鏈表節(jié)點維護一個收發(fā)報文的數(shù)據(jù)隊列,虛擬驅(qū)動與其他模塊的數(shù)據(jù)交互都通過該鏈表進行。

3.3 對虛擬設備數(shù)據(jù)讀寫過程

對數(shù)據(jù)的讀寫過程主要是在虛擬驅(qū)動模塊、內(nèi)部通信模塊及上層控制軟件之間進行。虛擬驅(qū)動模塊運行在內(nèi)核空間,而內(nèi)部通信模塊運行在用戶空間,因此,主要解決用戶空間與內(nèi)核空間的數(shù)據(jù)傳遞問題。通過memcpy_tofs()及memcpy_fromfs()系統(tǒng)調(diào)用用戶空間與內(nèi)核空間的數(shù)據(jù)交互。

在內(nèi)核中維護一個由各注冊設備名稱所組成的動態(tài)鏈表,每個鏈表節(jié)點維護一個收發(fā)報文的數(shù)據(jù)隊列,虛擬驅(qū)動與其他模塊的數(shù)據(jù)交互都通過該鏈表進行。接收報文過程:內(nèi)部通信模塊將從接口單元接收的報文通過ioctl()調(diào)用傳給虛擬驅(qū)動。該函數(shù)通過struct net_device *dev結構找到對應的虛擬設備的dev_ioctl()功能函數(shù),調(diào)用memcpy_fromfs()將數(shù)據(jù)拷貝至內(nèi)核空間,經(jīng)過處理后通過netif_rx()函數(shù)通知上層協(xié)議有數(shù)據(jù)傳入。發(fā)送報文過程:虛擬驅(qū)動將從上層軟件取出的數(shù)據(jù)放至自身維護的通過虛擬接口設備名稱維護的數(shù)據(jù)隊列中,內(nèi)部通信模塊通過ioctl()論詢各接口設備數(shù)據(jù)隊列是否有數(shù)據(jù)可讀,如果有數(shù)據(jù),虛擬驅(qū)動通過memcpy_tofs()調(diào)用將數(shù)據(jù)拷貝至用戶空間提供的緩沖區(qū)中。

文中針對大規(guī)模用戶接入方式的特性,討論了一種基于acr/tbit路由器的硬件抽象層的通用性軟件結構設計及實現(xiàn)方式,并研究了其關鍵技術,包括基于udp傳輸方式的內(nèi)部通信的可靠性實現(xiàn)及基于多用戶的動態(tài)模塊加載技術,適用于路由器承載業(yè)務量的擴展和多用戶接入特性,并且在上層軟件實現(xiàn)中,基本上可以不考慮底層硬件細節(jié),增強了路由器的開放性及可擴展性。