專利名稱：一種移動自組織網(wǎng)絡中域名系統(tǒng)的實現(xiàn)方法
技術領域：
本發(fā)明屬于移動自組織網(wǎng)絡MANET(Mobile Ad Hoc Networks)技術領域，是MANET自動配置技術中的域名系統(tǒng)DNS(Domain Name System)的一種實現(xiàn)方法。
背景技術：
移動自組織網(wǎng)絡是一種無基站的無線多跳網(wǎng)絡，是一種具有高度動態(tài)拓撲結構、結點任意移動的、點對點的自創(chuàng)建、自組織、自管理網(wǎng)絡。文獻[1]Ramanathan R，Redi J，“A Brief Overview of mobile Ad hocNetworksChallenges and Directions”，IEEE CommunicationsMagazine，50thAnniversary Commemorative Issue[C]，2002。傳統(tǒng)的DNS要求有一臺專門的域名服務器為網(wǎng)絡內(nèi)的其它結點提供域名服務，這就是集中式的域名服務/解析系統(tǒng)。而在拓撲動態(tài)變化、無線鏈路不穩(wěn)定的MANET中很難找到一臺集中式的域名服務器，因此傳統(tǒng)的DNS在MANET中無法正常工作。也有文獻[2]Jaehoon Jeong，Jungsoo Park，Hyoungjun Kim，and Kishik Park，“Name Service in IPv6 Mobile Ad-hocNetwork”，ICOIN 2003，Jeju，Korea，F(xiàn)ebruary 2003，指出用廣播請求/單播應答的機制來解決MANET中的域名解析問題，其工作原理為需要域名解析的網(wǎng)絡結點向全網(wǎng)廣播一個查詢包，收到廣播的結點將自己的域名與請求解析的域名進行比較，若相同就將自己的IP地址作為應答單播返回給源結點，否則將查詢包廣播出去。這種簡單的廣播請求/單播應答的域名解析機制由于每個結點的每次域名解析都要啟動一次廣播，使得網(wǎng)絡中廣播頻繁，這就容易導致廣播風暴、網(wǎng)絡的利用率急劇下降。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供一種移動自組織網(wǎng)絡中域名系統(tǒng)的實現(xiàn)方法。
本發(fā)明屬于移動自組織網(wǎng)絡MANET(Mobile Ad Hoc Networks)領域，提出了一種適用于MANET的新型分布式域名系統(tǒng)DMDNS(DistributedMANET Domain Name System)。DMDNS采用適時宣告/及時更新、信息捎帶/域名緩存、緩存命中/信息確認、廣播請求/單播應答的新型機制來減少域名請求的廣播次數(shù)，減輕由于網(wǎng)絡廣播所帶來的額外負載，同時保證了域名信息的正確性。在IP地址靜態(tài)配置的情況下，DMDNS減少了域名信息應答時間，使應用程序能夠及時進行通信。
DMDNS是一種分布式的域名系統(tǒng)，它能夠完成MANET中域名到IP地址(IPv4或IPv6)的轉換。實現(xiàn)方法如下DMDNS由域名服務模塊和域名解析模塊組成，MANET內(nèi)的所有結點都同時運行這兩個模塊，域名解析模塊啟動域名解析過程并對收到的域名應答報文進行處理，域名服務模塊監(jiān)聽域名請求的到來，并對收到的域名請求報文進行處理。
域名服務模塊所需的結點域名、生存期、IP地址通過以下方式取得用戶指定的(要求同一MANET域內(nèi)的域名不重復)或由自動生成機制產(chǎn)生的域名和生存期保存在域名配置文件中，域名服務模塊從該配置文件中獲取域名及生存期信息；網(wǎng)卡的IP地址由用戶手工指定(靜態(tài)配置)或通過地址自動生成機制產(chǎn)生(動態(tài)配置)，域名服務模塊從系統(tǒng)的地址信息文件中讀取網(wǎng)卡當前的IP地址。當結點被配置了域名和IP地址后就可以向其它結點提供域名服務了。
運行DMDNS的結點維護著一個域名信息列表(DN_REC_LIST)，也稱為域名緩存，該列表記錄了本結點所知道的域名信息，它包含如下幾個字段序號(sequence number)、域名(NAME)、類別(CLASS)、類型(TYPE)、IP地址、生存期(TTL)、確認標識(VIDvalidation identifier)。序號是一個32位的無符號整數(shù)，用來標識同一結點產(chǎn)生的域名信息的順序，用于其它結點更新自己所保存的域名信息；序號由結點自己生成并維護，被作為域名信息的一部分在網(wǎng)絡中傳輸。確認標識的長度為1位，用于標識該域名信息是否正在確認過程中；確認標識只存在于域名緩存中，它不屬于網(wǎng)絡中傳輸?shù)挠蛎畔?。其它幾個字段和傳統(tǒng)DNS定義的字段意義一致。文獻[3]P.Mockapetris，“DOMAIN NAMES-IMPLEMENTATIONAND SPECIFICATION”，RFC1035，November 1987。DMDNS中的域名信息請求/應答報文格式使用RFC1035定義的格式，RR(Resource Record)中RDATA項的前4個字節(jié)用于保存域名信息中的序號。DMDNS的工作機制·DN_REC_LIST的維護DN_REC_LIST將按如下方式更新(1)DMDNS啟動時，結點自己的域名信息被加入DN_REC_LIST。
(2)結點的IP地址改變時(使用地址自動配置時，結點的IP地址是動態(tài)變化的)，DN_REC_LIST中保存結點本身的域名信息的記錄被更新。
(3)收到的域名信息中的域名在DN_REC_LIST中不存在時，該信息被作為新記錄加入DN_REC_LIST。
(4)收到的域名信息R1和DN_REC_LIST中的某記錄R2進行比較if(R1.域名＝＝R2.域名){if(R1.序號＞R2.序號)將R2更新為記錄R1；else if((R1.序號＝＝R2.序號)&&(R1.IP_P＝＝R2.IP_P)){//IP_P＝{類別，類型，IP地址}if(R1.生存期＞R2.生存期)將R2.生存期更新為R1.生存期；}}(5)DN_REC_LIST中記錄R的生存期定時器TTL_Timer超時，R被刪除。
·域名信息宣告MANET結點在滿足以下條件時，啟動定時器Dn_life_Timer，然后置域名宣告狀態(tài)(Ad_state)為已宣告，并將自己的域名信息廣播出去。域名信息宣告包的格式與域名信息應答包(DN_REP)相同，只是IP頭的目的地址為廣播地址。廣播條件
(1)結點啟動DMDNS時；或(2)結點的IP地址改變時；或(3)結點收到廣播給自己的域名信息請求(DN_REQ)，且Ad_state處于未宣告狀態(tài)。
·域名信息請求域名解析模塊收到應用程序發(fā)來的域名解析請求時，置請求計數(shù)器(Req_Counter)的值為0，然后按如下步驟處理(1)將Req_Counter的值加1，并將結點自己的域名信息加入DN_REQ中；(2)在自己所維護的DN_REC_LIST中查找所請求的域名D_name，若存在相應的域名信息記錄R，就向R.ip單播DN_REQ，并將R.VID置為正在確認狀態(tài)；若不存在就將DN_REQ廣播出去，并在DN_REC_LIST中添加記錄R(R的域名字段為D_name，VID被置為正在確認狀態(tài)，其余字段為空)；(3)啟動定時器R.Reply_wait_Timer，等待DN_REP的到來。
Reply_wait_Timer的值＝2*NODE_TRAVERSAL_TIME*NET_DIAMETER；NODE_TRAVERSAL_TIME結點轉發(fā)報文的處理時間，一般為40毫秒；NET_DIAMETERMANET中兩個結點間的最大跳數(shù)，與網(wǎng)絡規(guī)模有關。
·DN_REQ的處理收到DN_REQ的結點，將按如下步驟處理(1)建立或維護到源結點(發(fā)送DN_REQ的結點)的路由；(2)將DN_REQ中請求的域名與自己的域名進行比較，若相等就轉到(5)；否則，(3)判斷DN_REQ是否為發(fā)給自己的單播包，若是就轉到(6)；否則，(4)將DN_REQ廣播出去，然后轉到(7)；(5)判斷Ad_state的狀態(tài)，若處于未宣告狀態(tài)，就啟動域名信息宣告機制，轉到(7)；否則，(6)向源結點單播DN_REP；(7)根據(jù)DN_REQ中攜帶的源結點的域名信息，在DN_REC_LIST中增加或更新相應(域名與DN_REQ中攜帶的域名相同)的記錄。
·DN_REP的處理收到DN_REP的結點，將按如下步驟處理(1)建立或維護到發(fā)送DN_REP的結點R_node的路由；(2)將DN_REP的目的地址與結點自己的地址進行比較，若不相等就向目的結點轉發(fā)出去，并轉到(6)；否則，(3)失效相應的定時器Reply_wait_Timer，然后將R_node的域名與結點所請求的域名D_name進行比較，若相等就將R_node的IP地址返回給應用程序，并轉到(6)；否則，(4)在DN_REC_LIST中查找域名為D_nme的記錄R，若R.VID處于已確認狀態(tài)，就轉到(6)；否則，(5)刪除記錄R，并重新啟動域名信息請求機制；(6)根據(jù)DN_REP中的域名信息，在DN_REC_LIST中增加或更新相應的記錄。
·序號的維護結點在發(fā)送DN_REP時，除了下面的例外情況，域名信息的序號都要加1，序號被保存在域名配置文件中。
例外情況結點收到單播給自己的DN_REQ，但結點當前的域名與DN_REQ中所請求的域名不等。
·DN_REP中的域名信息(1)DN_REP的目的地址為廣播地址(即域名信息宣告)時，DN_REP中只包含結點自己的域名信息。
(2)DN_REP的目的地址為單播地址時，DN_REC_LIST中生存期大于Min_ttl(一個預定義的閾值，根據(jù)實際網(wǎng)絡環(huán)境而定，可以保存在域名配置文件中)的所有域名信息都被加入DN_REP。
·DN_REC_LIST中確認標識(VID)的維護
(1)在DN_REC_LIST中增加或更新記錄R時，R的VID被置為已確認狀態(tài)。
(2)域名信息請求機制向R.ip單播發(fā)送DN_REQ時，R的VID被置為正在確認狀態(tài)。
·定時器超時的處理(1)若DN_REC_LIST中記錄R的TTL_Timer超時，R被刪除。
(2)若Dn_life_Timer超時，置Ad_state為未宣告狀態(tài)。
(3)若DN_REC_LIST中記錄R的Reply_wait_Timer超時，則if(Req_Counter＜＝2){if(R.VID處于正在確認狀態(tài))刪除記錄R；啟動域名信息請求機制；}else{向應用程序返回“域名不存在”；}比較DMDNS與簡單的廣播請求/單播應答的域名系統(tǒng)的處理機制，我們顯然可以看出本發(fā)明具有以下優(yōu)點(1)減輕了網(wǎng)絡的廣播負載。由于域名信息被結點緩存起來備用，當結點需要域名解析的時候，很有可能請求的域名信息已經(jīng)在緩存中，因此只需單播確認該信息的準確性。由于DMDNS使用了捎帶技術，一次域名請求/應答可以向報文所經(jīng)路徑上的結點傳達多條域名信息，使請求解析的域名在緩存中命中的概率很大。另外，由于網(wǎng)絡結點適時進行域名信息宣告，再加上域名請求/應答報文途徑的結點及時更新自己的緩存，使得在緩存中命中的域名信息的正確性很高，也就是說需要廣播請求的概率很小。因此DMDNS在很大程度上減少了廣播的次數(shù)，從而減輕了網(wǎng)絡廣播所造成的額外負載。
(2)在IP地址靜態(tài)配置時，DMDNS可以減少域名信息應答時間。在IP地址靜態(tài)配置時，域名與IP地址之間的映射是固定的，因此在緩存中命中的域名信息是準確的，不需要驗證其正確性就可以向應用程序返回域名信息應答。另外，如果請求解析的域名在本地緩存中沒有命中，而在請求報文經(jīng)過的結點緩存里命中，該結點可以代替目的結點立即返回域名信息應答。這顯然可以減少域名信息的應答時間。
本發(fā)明已經(jīng)用在中科院計算所IPv6 MANET測試床系統(tǒng)的設計中。
發(fā)明技術方案一種分布式的域名系統(tǒng)的域名服務/解析方法，網(wǎng)絡結點適時進行域名信息宣告，使網(wǎng)絡上的其它結點及時緩存宣告結點的最新域名信息；在域名請求/應答報文中使用捎帶技術，保證相關結點在一次請求/應答周期中獲得盡可能多的域名信息，使得域名解析請求在本地緩存命中的概率加大，從而減輕網(wǎng)絡的廣播負載；在IP地址靜態(tài)配置情況下，在任何網(wǎng)絡結點緩存中命中的域名信息不需確認就可立即應答，可以有效減少域名應答時間；在IP地址動態(tài)配置情況下，利用單播確認過程保證域名信息的正確性，在減少廣播的同時保證了域名解析的有效性。
一種分布式的域名系統(tǒng)的域名服務/解析方法，其具體步驟如下步驟S1結點啟動本域名系統(tǒng)或IP地址改變時，向MANET內(nèi)的其它結點廣播域名信息應答消息DN_REP，宣告自己當前的域名信息；步驟S2收到域名信息宣告的結點，根據(jù)DN_REP中攜帶的域名信息更新自己的域名信息緩存DN_INFO_CACHE；步驟S3要求對域名D_NAME進行解析的結點在自己的DN_INFO_CACHE里查找域名項為D_NAME的記錄R，若存在記錄R，就向R中所記錄的IP地址單播發(fā)送一個域名信息請求消息DN_REQ；若不存在記錄R，就向MANET內(nèi)的所有結點廣播一個DN_REQ；步驟S4收到DN_REQ的結點，首先判斷自己是否為所請求的結點，然后根據(jù)DN_REQ中所攜帶的域名信息更新DN_INFO_CACHE，若自己為所請求的結點，就執(zhí)行步驟5，否則將DN_REQ轉發(fā)出去；步驟5結點對收到的DN_REQ進行應答，結點首先判斷自己上次所宣告的域名信息生存期是否過時，若是就向MANET內(nèi)的所有結點廣播一個DN_REP進行應答；若生存期尚未過時，就向請求結點單播一個DN_REP進行應答，DN_REP中攜帶結點所知的所有有效域名信息；步驟S6收到DN_REP的結點，首先判斷它是否為發(fā)給自己的域名響應消息，若是就執(zhí)行步驟S7，否則將其向請求結點轉發(fā)，然后根據(jù)DN_REP中攜帶的域名信息更新DN_INFO_CACHE；步驟S7判斷DN_REP中攜帶的域名信息是否為自己所請求的信息，若是就向應用程序返回D_NAME所對應的IP地址，否則刪除原來的記錄R，并重新啟動域名解析過程，若兩次域名解析過程完成后，結點仍未收到自己所請求的DN_REP，就向應用程序返回“域名不存在”。


圖1是域名解析流程圖。
圖2是域名服務及消息轉發(fā)流程圖。
具體實施例方式
圖1中的域名解析流程圖，圖中各事件的處理步驟如下步驟S1.1結點收到應用程序的域名解析請求后，在自己的域名緩存里查找所請求的域名D_name；并初始化域名解析嘗試計數(shù)器Counter，其初值為0。
步驟S1.2若域名緩存里存在域名為D_name的記錄R，就向R中所記錄的IP地址發(fā)送DN_REQ，用以確認D_name與IP_addr映射的正確性；若在域名緩存里找不到域名為D_name的記錄，就向全網(wǎng)廣播一個DN_REQ，用以查詢D_name的IP地址。
步驟S1.3DN_REQ報文的IP頭目的地址為R中所記錄的IP。
步驟S1.4DN_REQ報文的IP頭目的地址為廣播地址，在IPv6中為一個預定義的表示MANET內(nèi)所有結點的多播地址。
步驟S1.5啟動等待定時器，等待域名信息應答報文DN_REP的到來；Couter的值加1。
步驟S1.6若定時器超時，就進入S7；否則，一直等待直到DN_REP到來，進入S8。
步驟S1.7判斷該域名解析嘗試是否超過2次，若超過就向應用程序返回“域名不存在”；否則，進入S4，重新廣播DN_REQ。
步驟S1.8根據(jù)DN_REP中的域名信息在域名緩存中添加或更新相應的記錄。
步驟S1.9判斷收到的DN_REP中的域名是否為正在請求的域名，若是就向應用程序返回該域名對應的IP地址；否則，說明原域名緩存中D_name和IP_addr的映射錯誤，進入S10。
步驟S1.10若映射錯誤的記錄R仍存在于域名緩存中，就進入S11；否則，就進入S12。
步驟S1.11將記錄R從域名緩存中刪除，并重新啟動域名解析過程。
步驟S1.12丟棄收到的DN_REP，不作任何其它處理。
圖2是域名服務及消息轉發(fā)流程圖，圖2中各事件的處理步驟如下步驟S2.1當啟動DMDNS或結點自己的IP地址改變時，結點向MANET廣播一個域名信息應答消息DN_REP，將自己當前的域名信息宣告給其它網(wǎng)絡結點。
步驟S2.2根據(jù)收到的域名信息請求/應答消息更新域名信息緩存。
步驟S2.3當收到域名信息請求/應答消息時，根據(jù)消息報文頭的QR標識位(見RFC1035)判斷該消息的類型，若為域名信息請求消息就進入S4；若為域名信息應答消息，就進入S6。
步驟S2.4判斷自己的域名是否為所請求的域名或自己的IP地址是否為DN_REQ的目的IP地址，若是就進行應答，否則將DN_REQ轉發(fā)出去。
步驟S2.5查詢域名宣告狀態(tài)，若宣告的域名生存期已過時，即結點處于域名未宣告狀態(tài)，就向MANET廣播DN_REP；若結點處于域名已宣告狀態(tài)，就向請求解析的結點單播DN_REP。
步驟S2.6根據(jù)收到的DN_REP的IP頭目的地址判斷該DN_REP是否為發(fā)給本結點的消息，若是就按圖1中收到域名信息應答消息后的處理流程；若不是，就將DN_REP轉發(fā)出去。
步驟S2.7根據(jù)消息報文的目的地址將該域名信息請求/應答消息向其它結點轉發(fā)出去。
步驟S2.8向請求結點單播發(fā)送一個域名信息應答消息DN_REP。
權利要求
1.一種分布式的域名系統(tǒng)的域名服務/解析方法，其特征在于，網(wǎng)絡結點適時進行域名信息宣告，使網(wǎng)絡上的其它結點及時緩存宣告結點的最新域名信息；在域名請求/應答報文中使用捎帶技術，保證相關結點在一次請求/應答周期中獲得盡可能多的域名信息，使得域名解析請求在本地緩存命中的概率加大，從而減輕網(wǎng)絡的廣播負載；在IP地址靜態(tài)配置情況下，在任何網(wǎng)絡結點緩存中命中的域名信息不需確認就可立即應答，可以有效減少域名應答時間；在IP地址動態(tài)配置情況下，利用單播確認過程保證域名信息的正確性，在減少廣播的同時保證了域名解析的有效性。
2.根據(jù)權利要求1的分布式的域名系統(tǒng)的域名服務/解析方法，其具體步驟如下步驟S1結點啟動本域名系統(tǒng)或IP地址改變時，向MANET內(nèi)的其它結點廣播域名信息應答消息DN_REP，宣告自己當前的域名信息；步驟S2收到域名信息宣告的結點，根據(jù)DN_REP中攜帶的域名信息更新自己的域名信息緩存DN_INFO_CACHE；步驟S3要求對域名D_NAME進行解析的結點在自己的DN_INFO_CACHE里查找域名項為D_NAME的記錄R，若存在記錄R，就向R中所記錄的IP地址單播發(fā)送一個域名信息請求消息DN_REQ；若不存在記錄R，就向MANET內(nèi)的所有結點廣播一個DN_REQ；步驟S4收到DN_REQ的結點，首先判斷自己是否為所請求的結點，然后根據(jù)DN_REQ中所攜帶的域名信息更新DN_INFO_CACHE。若自己為所請求的結點，就執(zhí)行步驟5，否則將DN_REQ轉發(fā)出去；步驟5結點對收到的DN_REQ進行應答，結點首先判斷自己上次所宣告的域名信息生存期是否過時，若是就向MANET內(nèi)的所有結點廣播一個DN_REP進行應答；若生存期尚未過時，就向請求結點單播一個DN_REP進行應答，DN_REP中攜帶結點所知的所有有效域名信息；步驟S6收到DN_REP的結點，首先判斷它是否為發(fā)給自己的域名響應消息，若是就執(zhí)行步驟S7，否則將其向請求結點轉發(fā)，然后根據(jù)DN_REP中攜帶的域名信息更新DN_INFO_CACHE；步驟S7判斷DN_REP中攜帶的域名信息是否為自己所請求的信息，若是就向應用程序返回D_NAME所對應的IP地址，否則刪除原來的記錄R，并重新啟動域名解析過程，若兩次域名解析過程完成后，結點仍未收到自己所請求的DN_REP，就向應用程序返回“域名不存在”。
全文摘要
本發(fā)明屬于移動自組織網(wǎng)絡MANET技術領域，方法步驟包括MANET結點宣告自己的域名信息，收到結點將域名信息保存在域名信息緩存DN_INFO_CACHE里。對域名D_NAME進行解析的結點在DN_INFO_CACHE里查找域名項為D_NAME的記錄R，若存在記錄R，結點就向R中記錄的IP地址單播一個域名信息請求消息DN_REQ；若R不存在，就向MANET內(nèi)的所有結點廣播一個DN_REQ。收到DN_REQ的結點判斷自己是否為所請求的結點，若是就向請求結點發(fā)送域名信息應答消息DN_REP，否則將DN_REQ轉發(fā)出去。收到DN_REP的結點首先更新DN_INFO_CACHE，然后判斷它是否為自己所請求的DN_REP，若是就接收下來進行處理，否則將其向請求結點轉發(fā)出去。本方法在DN_REQ和DN_REP中使用捎帶技術，使相關結點在一次請求/應答周期中獲得盡可能多的域名信息。
文檔編號H04L12/28GK1564539SQ20041003194
公開日2005年1月12日 申請日期2004年3月31日 優(yōu)先權日2004年3月31日
發(fā)明者周繼華, 石晶林 申請人:中國科學院計算技術研究所