Zone Routing Protocol - ZRP[1] Rafael de M. S. Fernandes 1 1 Programa de Engenharia de Sistemas e Computação - Coppe/UFRJ Rio de Janeiro - RJ - Brasil rafaelmsf@cos.ufrj.br Resumo. O protocolo ZRP busca reunir as melhores características dos protocolos pró-ativos e reativos. Ele é definido como um protocolo Híbrido, pois parte do funcionamento ocorre como um protocolo pró-ativo e outra parte como um protocolo reativo. Durante este trabalho será apresentado como o protocolo ZRP funciona e como ele faz para se comportar hora como pró-ativo, hora como reativo. 1. Introdução Nas redes Ad Hoc diversos problemas ocorrem, entre eles o problema de determinar a melhor rota para encaminhamentos de pacotes. Devido a natureza móvel dos nós neste tipo de rede, as rotas estão constantemente sendo modificas e as vezes até sumindo. Nos estudos sobre roteamento em redes Ad Hoc dois tipos de protocolos foram criados, os protocolos reativos e os pró-ativos. Os protocolos reativos determinam as rotas usadas sob-demanda, ou seja, somente quando se necessita de uma rota é que o protocolo irá iniciar o descobrimento desta rota. Os protocolos Dynamic Source Routing (DSR)[2] e Ad-hoc On demand Distance Vector (AODV)[3] são exemplos de protocolos reativos. Já os protocolos pró-ativos propagam continuamente informações sobre as rotas, mantendo o conhecimento das rotas sempre atualizado para que quando um pacote necessite de uma rota, a mesma já esteja determinada e seja usada imediatamente. Os protocolos Wireless Routing Protocol (WRP)[4] e Destination-Sequenced Distance-Vector (DSDV)[5] são exemplos de protocolos pró-ativos. Mas os dois protocolos possuem desvantagens grandes. Enquanto o protocolo reativo demanda muito tempo para determinar a rota, o pró-ativo ocupa espaço na banda durante a troca de informações além de necessitar de processamento e memória do dispositivo móvel. Para tentar amenizar os problemas de ambos os protocolos, o ZRP funciona como um protocolo híbrido, ou seja, parte do protocolo funciona como um protocolo pró-ativo e outra parte como um protocolo reativo. Na próxima seção serão apresentadas as características do protocolo e seu funcionamento. 2. Características A especificação do protocolo não define o protocolo pró-ativo usado pelo ZRP. Mas apesar disto o protocolo possui algumas características próprias. Algumas características estão listadas abaixo:
O ZRP necessita, na sua zona de roteamento, explicada mais a frente, que sejam enviadas mensagens periódicas para manter o roteamento local. O protocolo suporta dispositivos de fabricantes diferentes, desde que cada um tenha um IP único associado a cada interface de rede. O protocolo é totalmente distribuído e não depende de uma unidade central. Existe prevenção de loops no roteamento através de número de seqüência e do endereço de origem. Não é fornecido nenhuma forma de segurança através do ZRP. 3. Funcionamento 3.1. Protocolo de Roteamento IntraZona (IARP) O protocolo possue uma área chamada Zona de Roteamento de um nó N, que é definida como um conjunto de nós A, na qual a menor distância, em saltos, desde o nó N até cada um dos nós em A é um parâmetro inteiro (p) chamado Raio de Zona. É importante observar que é atribuído a cada nó o raio de zona (parâmetro p), e conseqüentemente sua zona de roteamento, não necessariamente sendo igual a todos os nós. Observe que as zonas de roteamento podem se sobrepor. Dentro da Zona de Roteamento o protocolo ZRP funciona como um protocolo pró-ativo, ou seja, cada nó sabe exatamente as rotas para todos os nós dentro de sua zona de roteamento. Para que um nó saiba as rotas para os nós dentro da zona de roteamento, cada nó possui uma tabela de roteamento que indica qual é a rota para cada nó pertencente a sua zona de roteamento. Como o ZRP não define qual é o protocolo pró-ativo utilizado, a construção desta tabela é feita de acordo com a especificação do protocolo pró-ativo escolhido para funcionar na zona de roteamento. Os nós que ficam exatamente a uma distância p, em saltos, de um nó N são chamados Nós Periféricos. A construção da zona de roteamento requer que o nó inicialmente descubra quem são seus vizinhos. Um vizinho é definido como um nó na qual uma comunicação direta (ponto a ponto) pode ser estabelecida e ainda a distância é de um passo. A identificação dos nós vizinhos pode ser feita diretamente pelo protocolos de MAC, como no caso de protocolos de polling. Em outros casos, a descoberta dos vizinhos pode ser implementada através do Neighbor Discovery Protocol (NDP). Este protocolo funciona com envio periódico de mensagens HELLO. A recepção do HELLO pode ser usada para indicar o estado da conexão comum vizinho. 3.1.1. Tamanho do Raio de Zona O desempenho do ZRP está diretamente ligada ao tamanho do raio de zona. Em geral redes densas com nós se movimentando rapidamente favorecem zonas de roteamento pequenas. Já redes esparsas com nós se movendo lentamente, favorecem zonas de roteamento grandes.
A maneira mais fácil e provavelmente menos eficiente de determinar o tamanho da zona de roteamento é através de configuração manual. O administrador da rede, se houver um, ou o fabricante do dispositivo podem fazer esta configuração. No caso de uma rede que sofre poucas variações, este método pode ser eficaz. Alternativamente o ZRP pode configurar sua zona de roteamento dinamicamente. Um nó pode estimar sua zona de roteamento ótima, baseado em medidas locais do tráfego. Em [6], o autor apresenta maneiras de determinar a melhor zona de roteamento on-line. Se um nó alterar seu tamanho da zona de roteamento, o protocolo pró-ativo irá convergir rapidamente, pois ele precisa apenas alterar sua tabela de roteamento. 3.2. Protocolo de Roteamento InterZona (IERP) Ao contrário do IARP, o ZRP define o protocolo usado no roteamento reativo. Para se alcançar os nós fora da zona de roteamento, o ZRP faz um pedido de rota para seus nós periféricos. Se algum nó periférico possuir em sua zona de roteamento (ele verifica em sua tabela de roteamento) o nó requisitado, ele envia a rota para o nó que requisitou a rota. Caso os nós periféricos não possuam a rota para o nó requisitado, eles enviam pedido para seus nós periféricos, e assim sucessivamente até encontrar uma rota para o nó requisitado. Esta parte do algoritmo se comporta como um protocolo reativo. O protocolo evita loops inserindo em cada pedido de rota um número seqüencial. Quando um pedido chega em um nó o mesmo verifica na sua tabela de pedidos se existe algum pedido do dispositivo, cujo número seqüencial já tenha passado por ele. Caso afirmativo, ele descarta o pacote, caso contrário ele repassa o pedido. 3.3. Exemplo Agora será apresentado um exemplo em que o nó S quer enviar informações para um nó fora de sua zona de roteamento. A configuração dos vizinhos de S está apresentada na figura 1. Neste exemplo o valor da variável que define o raio de zona é p=2 para todos os nós e o nó K representa os nós que não estão na zona de roteamento de S. Figura 1. Configuração dos Vizinhos de S Nesta figura é observado que os nós que estão dentro da zona de roteamento do nó S são os nós A, B, C, D, E, F, G, H, I, J, sendo os nós G, H, I, J nós periféricos.
No exemplo, S irá enviar um pacote para o nó X. Caso X fosse um nó dentro da zona de roteamento de S, a rota já estaria definida. A figura 2 mostra a configuração da rede inteira. Figura 2. Configuração da Rede Inteira No momento em que S tem um pacote a enviar para X, S irá procurar em sua tabela de roteamento se ele tem uma rota para X. Como S não possui rota para X, S irá enviar para seus nós periféricos uma requisição para determinar a rota para X. Os nós periféricos então irão fazer o mesmo procedimento de S, se eles tiverem uma rota para X irão avisar ao S que eles conhecem a rota, caso contrário irão enviar para os nós periféricos. A figura 3 apresenta este cenário. Figura 3. Pedido de Rota para X feito por I Observe que quando o pedido de rota para X vai de I para E, o nó E descarta este pedido, pois o pedido já passou por E quando S enviou o pedido de rota para os nós periféricos. Isso garante que não haja loops na requisição de rotas. Finalmente, quando o pedido de rota chega no nó T, o mesmo possui rota para X,
então T envia a informação para I que ele tem rota para X. Então I informa para S que a rota para X passa por I e por T. A figura 4 apresenta a resposta de T. Figura 4. Caminho da Resposta de T 4. Conclusão O protocolo ZRP tem a vantagem de utilizar o melhor dos protocolos reativos e pró-ativos, pois ele evita o congestionamento de banda e limita sua tabela de roteamento utilizando o protocolo pró-ativo apenas em uma determinada parte da rede, na zona de roteamento, e utiliza um protocolo reativo somente quando é necessário enviar pacotes para os nós fora da sua zona de roteamento, causando atrasos de determinação de rota somente nestes casos. O protocolo ainda apresenta boa escalabilidade, pois as mudanças na topologia são rapidamente detectadas e as tabelas de roteamento rapidamente modificadas. Mas existem algumas desvantagens importantes. A primeira delas é que como não está definido o protocolo de roteamento intrazona, várias zonas podem ter protocolos diferentes. Uma outra desvantagem é que se o raio de zona for pequeno o atraso decorrente da espera pela resposta de requisição de rotas é muito grande se o pacote for para um nó fora da zona de roteamento. Bibliografia [1] Z. J. Haas M. R. Pearlman P. Samar, The Zone Routing Protocol (ZRP) for Ad Hoc Networks - IETF Internet Draft, 2002, www3.ietf.org/proceedings/02nov/ I-D/draft-ietf-manet-zone-zrp-04.txt [2] D. B. Johnson, Dynamic Source Routing in Ad Hoc Wireless Networks, 1996, citeseer.ist.psu.edu/johnson96dynamic.html [3] C. E. Perkins E. M. Royer, Ad hoc On Demand Distance Vector Routing, Mobile Computing Systems and Applications, pp. 90-100, Feb, 1999. [4] S. Murthy, J. J. Garcia-Luna Aceves, A Routing Protocol for Packet Radio Networks, MOBICOM 95, pp. 86-95, nov, 1995. [5] C. Perkins, Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers, ACM SIGCOMM 94, pp. 234-244, 1994. [6] M. R. Pearlman Z. J. Haas, Determining the Optimal Configuration for the Zone Routing Protocol, IEEE JSAC, August, 1999.