专利名称：一种移动自组织网络中域名系统的实现方法
技术领域：
本发明属于移动自组织网络MANET(Mobile Ad Hoc Networks)技术领域，是MANET自动配置技术中的域名系统DNS(Domain Name System)的一种实现方法。
背景技术：
移动自组织网络是一种无基站的无线多跳网络，是一种具有高度动态拓扑结构、结点任意移动的、点对点的自创建、自组织、自管理网络。文献[1]Ramanathan R，Redi J，“A Brief Overview of mobile Ad hocNetworksChallenges and Directions”，IEEE CommunicationsMagazine，50thAnniversary Commemorative Issue[C]，2002。传统的DNS要求有一台专门的域名服务器为网络内的其它结点提供域名服务，这就是集中式的域名服务/解析系统。而在拓扑动态变化、无线链路不稳定的MANET中很难找到一台集中式的域名服务器，因此传统的DNS在MANET中无法正常工作。也有文献[2]Jaehoon Jeong，Jungsoo Park，Hyoungjun Kim，and Kishik Park，“Name Service in IPv6 Mobile Ad-hocNetwork”，ICOIN 2003，Jeju，Korea，February 2003，指出用广播请求/单播应答的机制来解决MANET中的域名解析问题，其工作原理为需要域名解析的网络结点向全网广播一个查询包，收到广播的结点将自己的域名与请求解析的域名进行比较，若相同就将自己的IP地址作为应答单播返回给源结点，否则将查询包广播出去。这种简单的广播请求/单播应答的域名解析机制由于每个结点的每次域名解析都要启动一次广播，使得网络中广播频繁，这就容易导致广播风暴、网络的利用率急剧下降。
发明内容
本发明的目的在于提供一种移动自组织网络中域名系统的实现方法。
本发明属于移动自组织网络MANET(Mobile Ad Hoc Networks)领域，提出了一种适用于MANET的新型分布式域名系统DMDNS(DistributedMANET Domain Name System)。DMDNS采用适时宣告/及时更新、信息捎带/域名缓存、缓存命中/信息确认、广播请求/单播应答的新型机制来减少域名请求的广播次数，减轻由于网络广播所带来的额外负载，同时保证了域名信息的正确性。在IP地址静态配置的情况下，DMDNS减少了域名信息应答时间，使应用程序能够及时进行通信。
DMDNS是一种分布式的域名系统，它能够完成MANET中域名到IP地址(IPv4或IPv6)的转换。实现方法如下DMDNS由域名服务模块和域名解析模块组成，MANET内的所有结点都同时运行这两个模块，域名解析模块启动域名解析过程并对收到的域名应答报文进行处理，域名服务模块监听域名请求的到来，并对收到的域名请求报文进行处理。
域名服务模块所需的结点域名、生存期、IP地址通过以下方式取得用户指定的(要求同一MANET域内的域名不重复)或由自动生成机制产生的域名和生存期保存在域名配置文件中，域名服务模块从该配置文件中获取域名及生存期信息；网卡的IP地址由用户手工指定(静态配置)或通过地址自动生成机制产生(动态配置)，域名服务模块从系统的地址信息文件中读取网卡当前的IP地址。当结点被配置了域名和IP地址后就可以向其它结点提供域名服务了。
运行DMDNS的结点维护着一个域名信息列表(DN_REC_LIST)，也称为域名缓存，该列表记录了本结点所知道的域名信息，它包含如下几个字段序号(sequence number)、域名(NAME)、类别(CLASS)、类型(TYPE)、IP地址、生存期(TTL)、确认标识(VIDvalidation identifier)。序号是一个32位的无符号整数，用来标识同一结点产生的域名信息的顺序，用于其它结点更新自己所保存的域名信息；序号由结点自己生成并维护，被作为域名信息的一部分在网络中传输。确认标识的长度为1位，用于标识该域名信息是否正在确认过程中；确认标识只存在于域名缓存中，它不属于网络中传输的域名信息。其它几个字段和传统DNS定义的字段意义一致。文献[3]P.Mockapetris，“DOMAIN NAMES-IMPLEMENTATIONAND SPECIFICATION”，RFC1035，November 1987。DMDNS中的域名信息请求/应答报文格式使用RFC1035定义的格式，RR(Resource Record)中RDATA项的前4个字节用于保存域名信息中的序号。DMDNS的工作机制·DN_REC_LIST的维护DN_REC_LIST将按如下方式更新(1)DMDNS启动时，结点自己的域名信息被加入DN_REC_LIST。
(2)结点的IP地址改变时(使用地址自动配置时，结点的IP地址是动态变化的)，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，然后置域名宣告状态(Ad_state)为已宣告，并将自己的域名信息广播出去。域名信息宣告包的格式与域名信息应答包(DN_REP)相同，只是IP头的目的地址为广播地址。广播条件
(1)结点启动DMDNS时；或(2)结点的IP地址改变时；或(3)结点收到广播给自己的域名信息请求(DN_REQ)，且Ad_state处于未宣告状态。
·域名信息请求域名解析模块收到应用程序发来的域名解析请求时，置请求计数器(Req_Counter)的值为0，然后按如下步骤处理(1)将Req_Counter的值加1，并将结点自己的域名信息加入DN_REQ中；(2)在自己所维护的DN_REC_LIST中查找所请求的域名D_name，若存在相应的域名信息记录R，就向R.ip单播DN_REQ，并将R.VID置为正在确认状态；若不存在就将DN_REQ广播出去，并在DN_REC_LIST中添加记录R(R的域名字段为D_name，VID被置为正在确认状态，其余字段为空)；(3)启动定时器R.Reply_wait_Timer，等待DN_REP的到来。
Reply_wait_Timer的值＝2*NODE_TRAVERSAL_TIME*NET_DIAMETER；NODE_TRAVERSAL_TIME结点转发报文的处理时间，一般为40毫秒；NET_DIAMETERMANET中两个结点间的最大跳数，与网络规模有关。
·DN_REQ的处理收到DN_REQ的结点，将按如下步骤处理(1)建立或维护到源结点(发送DN_REQ的结点)的路由；(2)将DN_REQ中请求的域名与自己的域名进行比较，若相等就转到(5)；否则，(3)判断DN_REQ是否为发给自己的单播包，若是就转到(6)；否则，(4)将DN_REQ广播出去，然后转到(7)；(5)判断Ad_state的状态，若处于未宣告状态，就启动域名信息宣告机制，转到(7)；否则，(6)向源结点单播DN_REP；(7)根据DN_REQ中携带的源结点的域名信息，在DN_REC_LIST中增加或更新相应(域名与DN_REQ中携带的域名相同)的记录。
·DN_REP的处理收到DN_REP的结点，将按如下步骤处理(1)建立或维护到发送DN_REP的结点R_node的路由；(2)将DN_REP的目的地址与结点自己的地址进行比较，若不相等就向目的结点转发出去，并转到(6)；否则，(3)失效相应的定时器Reply_wait_Timer，然后将R_node的域名与结点所请求的域名D_name进行比较，若相等就将R_node的IP地址返回给应用程序，并转到(6)；否则，(4)在DN_REC_LIST中查找域名为D_nme的记录R，若R.VID处于已确认状态，就转到(6)；否则，(5)删除记录R，并重新启动域名信息请求机制；(6)根据DN_REP中的域名信息，在DN_REC_LIST中增加或更新相应的记录。
·序号的维护结点在发送DN_REP时，除了下面的例外情况，域名信息的序号都要加1，序号被保存在域名配置文件中。
例外情况结点收到单播给自己的DN_REQ，但结点当前的域名与DN_REQ中所请求的域名不等。
·DN_REP中的域名信息(1)DN_REP的目的地址为广播地址(即域名信息宣告)时，DN_REP中只包含结点自己的域名信息。
(2)DN_REP的目的地址为单播地址时，DN_REC_LIST中生存期大于Min_ttl(一个预定义的阈值，根据实际网络环境而定，可以保存在域名配置文件中)的所有域名信息都被加入DN_REP。
·DN_REC_LIST中确认标识(VID)的维护
(1)在DN_REC_LIST中增加或更新记录R时，R的VID被置为已确认状态。
(2)域名信息请求机制向R.ip单播发送DN_REQ时，R的VID被置为正在确认状态。
·定时器超时的处理(1)若DN_REC_LIST中记录R的TTL_Timer超时，R被删除。
(2)若Dn_life_Timer超时，置Ad_state为未宣告状态。
(3)若DN_REC_LIST中记录R的Reply_wait_Timer超时，则if(Req_Counter＜＝2){if(R.VID处于正在确认状态)删除记录R；启动域名信息请求机制；}else{向应用程序返回“域名不存在”；}比较DMDNS与简单的广播请求/单播应答的域名系统的处理机制，我们显然可以看出本发明具有以下优点(1)减轻了网络的广播负载。由于域名信息被结点缓存起来备用，当结点需要域名解析的时候，很有可能请求的域名信息已经在缓存中，因此只需单播确认该信息的准确性。由于DMDNS使用了捎带技术，一次域名请求/应答可以向报文所经路径上的结点传达多条域名信息，使请求解析的域名在缓存中命中的概率很大。另外，由于网络结点适时进行域名信息宣告，再加上域名请求/应答报文途径的结点及时更新自己的缓存，使得在缓存中命中的域名信息的正确性很高，也就是说需要广播请求的概率很小。因此DMDNS在很大程度上减少了广播的次数，从而减轻了网络广播所造成的额外负载。
(2)在IP地址静态配置时，DMDNS可以减少域名信息应答时间。在IP地址静态配置时，域名与IP地址之间的映射是固定的，因此在缓存中命中的域名信息是准确的，不需要验证其正确性就可以向应用程序返回域名信息应答。另外，如果请求解析的域名在本地缓存中没有命中，而在请求报文经过的结点缓存里命中，该结点可以代替目的结点立即返回域名信息应答。这显然可以减少域名信息的应答时间。
本发明已经用在中科院计算所IPv6 MANET测试床系统的设计中。
发明技术方案一种分布式的域名系统的域名服务/解析方法，网络结点适时进行域名信息宣告，使网络上的其它结点及时缓存宣告结点的最新域名信息；在域名请求/应答报文中使用捎带技术，保证相关结点在一次请求/应答周期中获得尽可能多的域名信息，使得域名解析请求在本地缓存命中的概率加大，从而减轻网络的广播负载；在IP地址静态配置情况下，在任何网络结点缓存中命中的域名信息不需确认就可立即应答，可以有效减少域名应答时间；在IP地址动态配置情况下，利用单播确认过程保证域名信息的正确性，在减少广播的同时保证了域名解析的有效性。
一种分布式的域名系统的域名服务/解析方法，其具体步骤如下步骤S1结点启动本域名系统或IP地址改变时，向MANET内的其它结点广播域名信息应答消息DN_REP，宣告自己当前的域名信息；步骤S2收到域名信息宣告的结点，根据DN_REP中携带的域名信息更新自己的域名信息缓存DN_INFO_CACHE；步骤S3要求对域名D_NAME进行解析的结点在自己的DN_INFO_CACHE里查找域名项为D_NAME的记录R，若存在记录R，就向R中所记录的IP地址单播发送一个域名信息请求消息DN_REQ；若不存在记录R，就向MANET内的所有结点广播一个DN_REQ；步骤S4收到DN_REQ的结点，首先判断自己是否为所请求的结点，然后根据DN_REQ中所携带的域名信息更新DN_INFO_CACHE，若自己为所请求的结点，就执行步骤5，否则将DN_REQ转发出去；步骤5结点对收到的DN_REQ进行应答，结点首先判断自己上次所宣告的域名信息生存期是否过时，若是就向MANET内的所有结点广播一个DN_REP进行应答；若生存期尚未过时，就向请求结点单播一个DN_REP进行应答，DN_REP中携带结点所知的所有有效域名信息；步骤S6收到DN_REP的结点，首先判断它是否为发给自己的域名响应消息，若是就执行步骤S7，否则将其向请求结点转发，然后根据DN_REP中携带的域名信息更新DN_INFO_CACHE；步骤S7判断DN_REP中携带的域名信息是否为自己所请求的信息，若是就向应用程序返回D_NAME所对应的IP地址，否则删除原来的记录R，并重新启动域名解析过程，若两次域名解析过程完成后，结点仍未收到自己所请求的DN_REP，就向应用程序返回“域名不存在”。
图1是域名解析流程图。
图2是域名服务及消息转发流程图。
具体实施例方式
图1中的域名解析流程图，图中各事件的处理步骤如下步骤S1.1结点收到应用程序的域名解析请求后，在自己的域名缓存里查找所请求的域名D_name；并初始化域名解析尝试计数器Counter，其初值为0。
步骤S1.2若域名缓存里存在域名为D_name的记录R，就向R中所记录的IP地址发送DN_REQ，用以确认D_name与IP_addr映射的正确性；若在域名缓存里找不到域名为D_name的记录，就向全网广播一个DN_REQ，用以查询D_name的IP地址。
步骤S1.3DN_REQ报文的IP头目的地址为R中所记录的IP。
步骤S1.4DN_REQ报文的IP头目的地址为广播地址，在IPv6中为一个预定义的表示MANET内所有结点的多播地址。
步骤S1.5启动等待定时器，等待域名信息应答报文DN_REP的到来；Couter的值加1。
步骤S1.6若定时器超时，就进入S7；否则，一直等待直到DN_REP到来，进入S8。
步骤S1.7判断该域名解析尝试是否超过2次，若超过就向应用程序返回“域名不存在”；否则，进入S4，重新广播DN_REQ。
步骤S1.8根据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是域名服务及消息转发流程图，图2中各事件的处理步骤如下步骤S2.1当启动DMDNS或结点自己的IP地址改变时，结点向MANET广播一个域名信息应答消息DN_REP，将自己当前的域名信息宣告给其它网络结点。
步骤S2.2根据收到的域名信息请求/应答消息更新域名信息缓存。
步骤S2.3当收到域名信息请求/应答消息时，根据消息报文头的QR标识位(见RFC1035)判断该消息的类型，若为域名信息请求消息就进入S4；若为域名信息应答消息，就进入S6。
步骤S2.4判断自己的域名是否为所请求的域名或自己的IP地址是否为DN_REQ的目的IP地址，若是就进行应答，否则将DN_REQ转发出去。
步骤S2.5查询域名宣告状态，若宣告的域名生存期已过时，即结点处于域名未宣告状态，就向MANET广播DN_REP；若结点处于域名已宣告状态，就向请求解析的结点单播DN_REP。
步骤S2.6根据收到的DN_REP的IP头目的地址判断该DN_REP是否为发给本结点的消息，若是就按图1中收到域名信息应答消息后的处理流程；若不是，就将DN_REP转发出去。
步骤S2.7根据消息报文的目的地址将该域名信息请求/应答消息向其它结点转发出去。
步骤S2.8向请求结点单播发送一个域名信息应答消息DN_REP。
权利要求
1.一种分布式的域名系统的域名服务/解析方法，其特征在于，网络结点适时进行域名信息宣告，使网络上的其它结点及时缓存宣告结点的最新域名信息；在域名请求/应答报文中使用捎带技术，保证相关结点在一次请求/应答周期中获得尽可能多的域名信息，使得域名解析请求在本地缓存命中的概率加大，从而减轻网络的广播负载；在IP地址静态配置情况下，在任何网络结点缓存中命中的域名信息不需确认就可立即应答，可以有效减少域名应答时间；在IP地址动态配置情况下，利用单播确认过程保证域名信息的正确性，在减少广播的同时保证了域名解析的有效性。
2.根据权利要求1的分布式的域名系统的域名服务/解析方法，其具体步骤如下步骤S1结点启动本域名系统或IP地址改变时，向MANET内的其它结点广播域名信息应答消息DN_REP，宣告自己当前的域名信息；步骤S2收到域名信息宣告的结点，根据DN_REP中携带的域名信息更新自己的域名信息缓存DN_INFO_CACHE；步骤S3要求对域名D_NAME进行解析的结点在自己的DN_INFO_CACHE里查找域名项为D_NAME的记录R，若存在记录R，就向R中所记录的IP地址单播发送一个域名信息请求消息DN_REQ；若不存在记录R，就向MANET内的所有结点广播一个DN_REQ；步骤S4收到DN_REQ的结点，首先判断自己是否为所请求的结点，然后根据DN_REQ中所携带的域名信息更新DN_INFO_CACHE。若自己为所请求的结点，就执行步骤5，否则将DN_REQ转发出去；步骤5结点对收到的DN_REQ进行应答，结点首先判断自己上次所宣告的域名信息生存期是否过时，若是就向MANET内的所有结点广播一个DN_REP进行应答；若生存期尚未过时，就向请求结点单播一个DN_REP进行应答，DN_REP中携带结点所知的所有有效域名信息；步骤S6收到DN_REP的结点，首先判断它是否为发给自己的域名响应消息，若是就执行步骤S7，否则将其向请求结点转发，然后根据DN_REP中携带的域名信息更新DN_INFO_CACHE；步骤S7判断DN_REP中携带的域名信息是否为自己所请求的信息，若是就向应用程序返回D_NAME所对应的IP地址，否则删除原来的记录R，并重新启动域名解析过程，若两次域名解析过程完成后，结点仍未收到自己所请求的DN_REP，就向应用程序返回“域名不存在”。
全文摘要
本发明属于移动自组织网络MANET技术领域，方法步骤包括MANET结点宣告自己的域名信息，收到结点将域名信息保存在域名信息缓存DN_INFO_CACHE里。对域名D_NAME进行解析的结点在DN_INFO_CACHE里查找域名项为D_NAME的记录R，若存在记录R，结点就向R中记录的IP地址单播一个域名信息请求消息DN_REQ；若R不存在，就向MANET内的所有结点广播一个DN_REQ。收到DN_REQ的结点判断自己是否为所请求的结点，若是就向请求结点发送域名信息应答消息DN_REP，否则将DN_REQ转发出去。收到DN_REP的结点首先更新DN_INFO_CACHE，然后判断它是否为自己所请求的DN_REP，若是就接收下来进行处理，否则将其向请求结点转发出去。本方法在DN_REQ和DN_REP中使用捎带技术，使相关结点在一次请求/应答周期中获得尽可能多的域名信息。
文档编号H04L12/28GK1564539SQ20041003194
公开日2005年1月12日 申请日期2004年3月31日 优先权日2004年3月31日
发明者周继华, 石晶林 申请人:中国科学院计算技术研究所