|
目前,大多數路由器均采用分布式轉發(fā)、集中式路由處理的體系結構。該結構方式使主處理單元與各從處理單元可以根據所處位置及執行任務(wù)的不同采用不同的處理方式,但也使頂層管理軟件對底層各從處理單元難以進(jìn)行協(xié)調統一的管理。硬件抽象層HAL(Hardware Abstraction Layer)在邏輯上介于底層硬件與上層協(xié)議軟件之間,維護兩者之間的數據傳遞,并對底層各接口模塊進(jìn)行管理,屏蔽底層硬件細節,使得應用軟件可以通過(guò)控制HAL達到操縱底層硬件的目的。高性能路由器硬件抽象層的提出成功解決了分布式路由器面臨的通用性支撐軟件系統結構的設計問(wèn)題,為構建開(kāi)放通用的路由器軟件基礎平臺提供了保證。 隨著(zhù)路由器承載業(yè)務(wù)能力的不斷增強,大規模接入匯聚路由器的設計與實(shí)現也被提上了議事日程。ACR(大規模接入匯聚路由器)是3Tnet(高性能寬帶網(wǎng))網(wǎng)絡(luò )的關(guān)鍵設備。該設備采用ACR寬帶接入方式,即通過(guò)帶有遠端用戶(hù)接口單元(RIU)、基于以太網(wǎng)傳輸接口的分合路器(EMDi)組成樹(shù)形分叉地域分布式系統構架,保證大規模的用戶(hù)直接接入骨干高速網(wǎng)絡(luò ),實(shí)現視頻點(diǎn)播、網(wǎng)絡(luò )電視、IP電話(huà)等寬帶業(yè)務(wù),從而更加減化了網(wǎng)絡(luò )拓撲結構,使業(yè)務(wù)引入更加快速,運營(yíng)策略更加多樣化。 大規模用戶(hù)接入方式也給路由器硬件抽象層的實(shí)現方式及信息的實(shí)時(shí)、高速傳輸提出了新的挑戰,主要表現在以下幾個(gè)方面:首先,承載業(yè)務(wù)量的數量及種類(lèi)的增多對路由器內部通信的實(shí)時(shí)性、高效性提出了更多的要求;其次,大規模用戶(hù)接入方式增加了路由器對外接口的數量,從而帶來(lái)了設備管理上的難度;再次,從系統的通用性及可擴展性考慮,要求構建一種具有可擴展性且不依賴(lài)于硬件具體實(shí)現方式的軟件體系結構,方便路由軟件的移植和應用。由此可見(jiàn),硬件抽象層的高度穩定性、可擴展性及可靠性將直接影響路由器的各項性能指標。 由于大規模用戶(hù)接入方式的特性,使得以前基于IPv6路由器的硬件抽象層的實(shí)現方式已經(jīng)不適應數據高速傳輸及多用戶(hù)接入的管理方式。本文將在討論硬件抽象層基本結構的基礎上,提出一種適用于大規模接入匯聚路由器的HAL的通用性軟件結構設計及實(shí)現方式,提供高效、可靠的內部通信,并針對多用戶(hù)接入數量不確定的情況,提出動(dòng)態(tài)加載虛擬驅動(dòng)模塊的實(shí)現方法,增強路由器面向ACR接入方式的可用性。 1 硬件抽象層基本結構及功能實(shí)現 根據文獻提出的方案,高性能路由器硬件抽象層可分為內部通信、虛擬驅動(dòng)及設備管理三大模塊,這三部分模塊相互配合,共同完成面向實(shí)際的用戶(hù)設備接口的功能模擬及硬件細節的屏蔽,并對其進(jìn)行統一協(xié)調的管理。硬件抽象層對用戶(hù)設備接口的功能模擬主要由虛擬驅動(dòng)模塊完成,包括數據包的收發(fā)及協(xié)議報文的預處理等工作,為上層協(xié)議軟件提供標準的API函數;而對用戶(hù)設備的接口管理則由上層網(wǎng)絡(luò )管理軟件通過(guò)設備管理模塊對其進(jìn)行管理配置及監控;內部通信模塊運行于內部以太網(wǎng)絡(luò ),協(xié)調各模塊之間的功能接口,保證各從處理單元與主處理單元之間實(shí)時(shí)可靠的數據傳輸。其基本結構如圖1所示。 圖1 硬件抽象層基本結構示意圖 根據各模塊的功能可知,硬件抽象層內部通信模塊是各分處理單元與主處理單元信息交互的重要傳輸通道。內部通信模塊匯集各底層設備的數據并根據類(lèi)型分流至各上層處理模塊,同時(shí),數據維護模塊對虛擬設備及各處理單元的維護信息也需要通過(guò)內部通信模塊進(jìn)行。因此,內部通信模塊采用何種基于內部以太網(wǎng)的數據傳輸實(shí)現方式,對路由器內部數據的實(shí)時(shí)、有效、可靠傳輸起著(zhù)至關(guān)重要的作用。當前內部通信模塊采用基于分隔符的TCP傳輸方式,在應用層數據包的起始部分附加有特定格式的分隔符和數據長(cháng)度域,解決了由于Nagle算法產(chǎn)生的包粘滯問(wèn)題。但該方式?jīng)]能解決TCP傳輸方式的消耗過(guò)大、實(shí)時(shí)性不強的問(wèn)題。同時(shí),消除分割符恢復報文的完整性也增加了應用程序的處理復雜度,從而不可避免地增加系統的開(kāi)銷(xiāo)并降低系統的實(shí)時(shí)性。系統的實(shí)時(shí)性對于用戶(hù)業(yè)務(wù)急劇增多的ACR路由器而言是一個(gè)迫切需要解決的問(wèn)題。UDP是一個(gè)面向消息的傳輸協(xié)議,其最大數據緩沖區長(cháng)度為8192～65536字節,滿(mǎn)足一次傳輸一個(gè)完整報文的條件。在內部以太網(wǎng)中采用UDP傳輸方式具有明顯的優(yōu)勢。但由于UDP協(xié)議的無(wú)連接性,導致它是一個(gè)不可靠傳輸,文中第二部分將討論如何實(shí)現一種基于UDP的內部通信的可靠性傳輸機制。 硬件抽象層對用戶(hù)設備接口的功能模擬主要通過(guò)虛擬驅動(dòng)進(jìn)行,路由器業(yè)務(wù)類(lèi)型的擴展使得用戶(hù)接口數量增多并呈現接入時(shí)間的不確定性,從而帶來(lái)用戶(hù)設備管理上的難度。針對此種情況,文中第三部分提出動(dòng)態(tài)加載虛擬驅動(dòng)模塊的實(shí)現方法,增強路由器面向多用戶(hù)接入方式的可用性。 2 基于UDP傳輸方式的內部通信的可靠性實(shí)現 內部通信模塊處于硬件抽象層的底層,運行于內部交換網(wǎng)絡(luò ),完成底層硬件與上層控制軟件的數據傳輸,實(shí)現對底層硬件的初步屏蔽分離;針對分布式體系結構特點(diǎn)及多用戶(hù)接入的業(yè)務(wù)需求,內部通信模塊以Client\Server的方式分別運行于主處理單元模塊及各線(xiàn)路接口單元模塊上,采用UDP傳輸協(xié)議進(jìn)行通信,主要基于以下幾點(diǎn)考慮: 首先,UDP協(xié)議是一個(gè)無(wú)連接協(xié)議,傳輸數據之前源端與終端不需建立連接,因此不需維護連接狀態(tài)。這樣服務(wù)器端可以使用一個(gè)或幾個(gè)端口同時(shí)向多個(gè)客戶(hù)端發(fā)送消息,符合分布式結構體系的要求。 其次,UDP信息包很短,只有8個(gè)字節,相對于TCP的20個(gè)字節的信息包的額外開(kāi)銷(xiāo)很小,便于數據的快速傳遞。 再次,吞吐量不受擁塞控制算法的調節,只受應用軟件生成數據的速率、傳輸帶寬和計算機性能的影響,適用于內部以太網(wǎng)絡(luò )的數據傳輸。 但由于UDP方式的無(wú)連接性,使得UDP傳輸的可靠性不強。而可靠性是內部通信模塊所必須具有的性能,因此考慮在應用軟件中實(shí)現UDP傳輸方式的可靠性保證,主要采用以下方式: 2.1 多線(xiàn)程無(wú)連接的C/S通信方式 服務(wù)器端運行在Linux操作系統下,采用多線(xiàn)程方式收發(fā)各類(lèi)數據;客戶(hù)端運行在Vxworks操作系統,采用多任務(wù)方式收發(fā)各類(lèi)數據。這樣由于多線(xiàn)程及多任務(wù)并行運行的特性,在內部以太網(wǎng)的傳輸條件下,使得收發(fā)數據的速率可以滿(mǎn)足系統的要求�；镜幕赨DP協(xié)議的無(wú)連接客戶(hù)端/服務(wù)器端通信程序如圖2所示。 圖2 基于UDP協(xié)議的無(wú)連接客戶(hù)端/服務(wù)器端通信程序 該通信過(guò)程采用多個(gè)客戶(hù)端(各從處理單元)對一個(gè)服務(wù)器端(主處理單元)的方式,使多個(gè)用戶(hù)接口模塊可以在不同時(shí)間接入主控。內部通信根據所傳遞數據的不同類(lèi)型,采用相對固定的不同的端口號,不同的客戶(hù)端采用不同的IP地址,從相同的端口收發(fā)同類(lèi)數據。在服務(wù)器端通過(guò)select()系統調用,既可以輪詢(xún)各個(gè)socket端口以便及時(shí)接收不同端口的數據,又起到定時(shí)器的作用。當規定時(shí)間內收不到數據時(shí),能夠及時(shí)返回繼續在阻塞模式下等待,從而既能及時(shí)收發(fā)數據,又降低資源消耗。 2.2 三次握手過(guò)程 每個(gè)客戶(hù)端與服務(wù)器端進(jìn)行真正的數據傳輸之前,首先要進(jìn)行一個(gè)握手的建立過(guò)程,如圖3所示。握手過(guò)程成功后則表示雙方通信通道正常,只有在得知握手成功后雙方才可以正常地收發(fā)報文,從而克服了UDP協(xié)議方式的面向無(wú)連接性。為了隨時(shí)檢測和維護雙方鏈路的通連性,每個(gè)客戶(hù)端與服務(wù)端在一定的間隔時(shí)間內要互發(fā)KEEPALIVE報文。如果在規定的時(shí)間內收不到對方的KEEPALIVE報文,說(shuō)明斷鏈,要進(jìn)行相應的斷鏈處理。 圖3 握手建立過(guò)程 2.3 接收端丟失確認及滑動(dòng)窗口 發(fā)送UDP報文時(shí)在自定義的內部數據頭中加入所發(fā)送數據的序號,接收端收到后發(fā)送確認信息,如果發(fā)送方在規定時(shí)間內沒(méi)有收到確認信息,則認為該包丟失,會(huì )連同原包的序號重新發(fā)送。 滑動(dòng)窗口的目的主要是為了實(shí)現流量控制,防止擁塞。每個(gè)發(fā)送方維護一個(gè)重發(fā)隊列,保存著(zhù)一定數量的發(fā)送而沒(méi)被確認的報文,該隊列剩余空間的大小可以限制應用部分發(fā)包的速率。由于UDP協(xié)議是基于消息的傳輸協(xié)議而非基于流的,因此不必考慮發(fā)送端可以接收多少數據,只需知道能否接收數據即可。 總之,采用UDP傳輸控制方式主要考慮到其傳輸簡(jiǎn)單快速、額外開(kāi)銷(xiāo)較小的特點(diǎn),但這是以犧牲一定的可靠性為前提的,因此必須在應用程序中增加可靠性保護機制。在實(shí)際應用中證明上述方法可靠高效,能夠維護內部通信有序、快速的數據傳輸。 3 基于多用戶(hù)的用戶(hù)接入管理 在Linux操作系統下,系統把設備映射為一個(gè)特殊的設備文件,用戶(hù)程序可以像對其他文件一樣對該設備文件進(jìn)行讀寫(xiě)操作。虛擬驅動(dòng)模塊運行在Linux操作系統下,模擬從處理單元上的接口單元,形成收發(fā)協(xié)議報文功能和數量與此一致的硬件抽象層虛擬接口單元。因此,每個(gè)實(shí)際的接口單元都在內核中對應一個(gè)注冊的虛擬設備,以便于上層控制軟件對數據平面的管理與數據交互。 3.1 多用戶(hù)虛擬設備驅動(dòng)程序的動(dòng)態(tài)加載 虛擬驅動(dòng)在內核中的功能通過(guò)動(dòng)態(tài)加載方式實(shí)現。通常的動(dòng)態(tài)加載方式是將驅動(dòng)程序作為一個(gè)整體模塊,在需要時(shí)再加入內核;由于多用戶(hù)接入方式使得在某一時(shí)刻內核中注冊的接口單元數量不確定,如果實(shí)施一次性加載會(huì )冗余太多,不利于資源的有效利用。因此,在內核中加載一個(gè)基本模塊的前提下,實(shí)現各虛擬設備的動(dòng)態(tài)加載過(guò)程,達到以一個(gè)基本的虛擬設備控制多個(gè)設備驅動(dòng)模塊的功能。 如圖4所示,對虛擬驅動(dòng)設備的控制由內部通信模塊與設備管理模塊共同完成。設備管理模塊通過(guò)內部通信模塊下達加載、卸載虛擬驅動(dòng)的命令,通過(guò)內部通信模塊與虛擬驅動(dòng)的控制通道進(jìn)行。內部通信模塊通過(guò)調用ioctl()采用不同的命令字完成對虛擬驅動(dòng)模塊的控制過(guò)程。 圖4模塊動(dòng)態(tài)加載過(guò)程 基本驅動(dòng)模塊的加載采用通常的驅動(dòng)模塊加載方式,即調用module_init()函數進(jìn)行基本模塊的初始化及在內核中的注冊過(guò)程。以該基本驅動(dòng)模塊為基礎,當內部通信模塊收到加載某個(gè)用戶(hù)設備接口的命令后,通過(guò)調用該基本模塊的Base_ioctl()在內核中注冊一個(gè)新的驅動(dòng)設備,該注冊設備才是與實(shí)際接口單元相對應的虛擬驅動(dòng)模塊,應用程序對用戶(hù)設備數據的讀寫(xiě)都是通過(guò)這些注冊的接口設備而非基本設備提供的標準函數進(jìn)行。這樣的動(dòng)態(tài)加載過(guò)程使得當沒(méi)有設備加載時(shí)在內核中只存在一個(gè)基本的虛擬驅動(dòng)模塊,只有需要注冊的用戶(hù)才將其對應的設備接口的虛擬驅動(dòng)模塊加載到內核中,從而減少系統冗余,便于管理。 各用戶(hù)接口單元與虛擬驅動(dòng)的數據交互通過(guò)內部通信模塊與虛擬驅動(dòng)的數據通道進(jìn)行,所對應的系統調用為該注冊設備的dev_ioctl()。在該功能函數中,實(shí)現用戶(hù)空間與內核空間的數據交互。 3.2 對多用戶(hù)接口設備虛擬驅動(dòng)的管理 為實(shí)現內核虛擬驅動(dòng)模塊與實(shí)際接口單元的一一對應,必須解決各驅動(dòng)模塊的命名原則問(wèn)題。將每個(gè)實(shí)際接口單元在接入段拓撲中的位置設置為不同的參數,在內部通信中這些參數作為傳輸數據的報頭信息出現,根據它們可以生成一個(gè)唯一的字符串作為對應該接口單元的虛擬驅動(dòng)設備名稱(chēng),而且根據設備名稱(chēng)亦可還原出實(shí)際接口單元的拓撲信息,以供內部通信使用。在內核中維護一個(gè)由各注冊設備名稱(chēng)所組成的動(dòng)態(tài)鏈表,每個(gè)鏈表節點(diǎn)維護一個(gè)收發(fā)報文的數據隊列,虛擬驅動(dòng)與其他模塊的數據交互都通過(guò)該鏈表進(jìn)行。 3.3 對虛擬設備數據讀寫(xiě)過(guò)程 對數據的讀寫(xiě)過(guò)程主要是在虛擬驅動(dòng)模塊、內部通信模塊及上層控制軟件之間進(jìn)行。虛擬驅動(dòng)模塊運行在內核空間,而內部通信模塊運行在用戶(hù)空間,因此,主要解決用戶(hù)空間與內核空間的數據傳遞問(wèn)題。通過(guò)memcpy_tofs()及memcpy_fromfs()系統調用用戶(hù)空間與內核空間的數據交互。 在內核中維護一個(gè)由各注冊設備名稱(chēng)所組成的動(dòng)態(tài)鏈表,每個(gè)鏈表節點(diǎn)維護一個(gè)收發(fā)報文的數據隊列,虛擬驅動(dòng)與其他模塊的數據交互都通過(guò)該鏈表進(jìn)行。接收報文過(guò)程:內部通信模塊將從接口單元接收的報文通過(guò)ioctl()調用傳給虛擬驅動(dòng)。該函數通過(guò)struct net_device *dev結構找到對應的虛擬設備的dev_ioctl()功能函數,調用memcpy_fromfs()將數據拷貝至內核空間,經(jīng)過(guò)處理后通過(guò)netif_rx()函數通知上層協(xié)議有數據傳入。發(fā)送報文過(guò)程:虛擬驅動(dòng)將從上層軟件取出的數據放至自身維護的通過(guò)虛擬接口設備名稱(chēng)維護的數據隊列中,內部通信模塊通過(guò)ioctl()論詢(xún)各接口設備數據隊列是否有數據可讀,如果有數據,虛擬驅動(dòng)通過(guò)memcpy_tofs()調用將數據拷貝至用戶(hù)空間提供的緩沖區中。 文中針對大規模用戶(hù)接入方式的特性,討論了一種基于A(yíng)CR/Tbit路由器的硬件抽象層的通用性軟件結構設計及實(shí)現方式,并研究了其關(guān)鍵技術(shù),包括基于UDP傳輸方式的內部通信的可靠性實(shí)現及基于多用戶(hù)的動(dòng)態(tài)模塊加載技術(shù),適用于路由器承載業(yè)務(wù)量的擴展和多用戶(hù)接入特性,并且在上層軟件實(shí)現中,基本上可以不考慮底層硬件細節,增強了路由器的開(kāi)放性及可擴展性。 |
