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