Mobilidade em Redes de Comunicação 2006/2007

Trabalho elaborado por: Ricardo Nuno Mendão da Silva rnsilva@student.dei.uc.pt 501066530 Jorge Miguel Morgado Henriques jmmh@student.dei.uc.pt 501066554

Índice

1. Introdução ............................................................................................................................. 3

2. Objectivos .............................................................................................................................. 4

3. Arquitectura .......................................................................................................................... 4

3.1. Esquema Geral ............................................................................................................. 4

3.2. Esquema de funcionamento dos Objectos .................................................................. 6

3.2.1. MobileNode ............................................................................................................. 7

3.2.2. HomeAgent .............................................................................................................. 7

3.2.3. ForeignAgent ........................................................................................................... 9

3.2.4. CorrespondentNode ................................................................................................ 9

3.2.5. Router .................................................................................................................... 10

3.3. Esquema de funcionamento da comunicação ........................................................... 11

3.3.1. Interfaces. .............................................................................................................. 13

3.3.2. Router .................................................................................................................... 14

4. Diagrama de Classes ............................................................................................................ 14

4.1. package mobileIP ....................................................................................................... 15

4.2. package communication ............................................................................................ 16

4.3. package gui ................................................................................................................ 19

4.4. package gui.designers ................................................................................................ 21

4.5. package model ........................................................................................................... 22

5. Testes de funcionamento .................................................................................................... 25

6. Conclusão ............................................................................................................................ 37

7. Bibliografia .......................................................................................................................... 38

1. Introdução

Com a evolução das redes e sistemas, aliada à eminente procura de novos serviços e de maior qualidade, converge-se de um sistema de multi-plataformas de redes, para uma única plataforma. Integrando as tecnologias já implementadas entre si, desenvolvendo mecanismos de interoperabilidade, aproveitando as actuais plataformas, são os desafios actuais da área da mobilidade. Foi neste âmbito que o IETF criou um grupo de trabalho especificamente para investigar, desenvolver e aplicar o que chamou de Mobile IP. O Mobile IP é um protocolo desenhado para permitir que os utilizadores possam transitar entre redes, sem perder a conectividade, ou seja, permitir utilizadores ligados na rede A que ao transitarem para a rede B, mantenham o seu IP original da rede A, funcionando em modo transparente para os emissores.

O objecto m óvel fica assim associado a dois IP’s, o seu IP original e o Care-of-Address que é o IP do agente estrangeiro. Existem ainda outras duas entidades, nomeadamente o agente local e o agente estrangeiro. Os agentes são os responsáveis pelo processo de registo e gestão de ligações de visitantes. No caso do agente estrangeiro, cabe-lhe a responsabilidade de receber pedidos de ligação, dos objectos moveis , pedir permissão ao agente local do objecto móvel, e registar o objecto móvel, mantendo uma tabela actualizada com toda a lista dos seus visitantes. O agente local, para além de analisar os pedidos dos agentes estrangeiros, mantém ainda uma tabela de objectos seus, localizados noutras redes. Essa tabela é actualizada sempre que permite um pedido de um agente estrangeiro, sempre que um objecto móvel regressa a casa e sempre que o tempo de ligação dos objectos móveis, em redes estrangeiras, termina.

Um pacote destinada ao objecto móvel, é sempre encaminhado para o seu agente local, sendo que este ao receber o pacote verifica se o destinatário encontra-se na rede local ou fora desta. No caso de se encontrar fora, o agente local encapsula o pacote com o tipo de encapsulamento acordado no momento de registo, ou seja, um pacote destinado a um agente local, situado no exterior, pode ser encapsulado de três modos: Genérico, Básico e Mínimo, definidos respectivamente pelos RFC1701, RFC2003 e RFC2004. Após o encapsulamento, o pacote é novamente enviado para a rede, prosseguindo o seu destino até atingir o Care-of-Address.

No caso do Genérico é adicionada uma nova área chamada GRE (Generic Routing Encapsulation) [IETF94], como o nome indica é um caso genérico, baseando-se no encapsulamento de um pacote com o cabeçalho GRE e posteriormente com um outro qualquer cabeçalho de entrega, ao qual no RFC cham am de “Delivery Header”.

No encapsulamento básico, o pacote é directamente encapsulado pelo cabeçalho de entrega, utilizando o protocolo IP-within-IP, ou seja um pacote IP dentro de outro[IETF96]. Acontecendo o mesmo no encapsulamento Mínimo, contudo neste último o cabeçalho original é comprimido[IETF96a].

Durante este relatório, vai se descrever e testar um simulador de Mobile IP desenvolvido em Java, que se baseia na existência de três redes distintas, uma local, uma do agente estrangeiro e outra de um elemento que apenas comunica com o agente móvel. O simulador está desenvolvido de forma a permitir a interacção directa do utilizador com o agente móvel, podendo mover este entre a sua rede local e a rede estrangeira. É ainda possível efectuar testes de comunicação entre o agente móvel e o elemento da terceira rede.

2. Objectivos Pretende-se desenvolver um simulador que implemente e demonstre o funcionamento básico do sistema de Mobile IP. É assim necessário recriar um ambiente, apresentado graficamente para total compreensão e controlo dos elementos.

3. Arquitectura Neste ponto vai se descrever o sistema criado e os objectos intervenientes.

3.1. Esquema Geral

Figura 1 - Esquema geral

Na figura 1, pode-se observar o esquema geral do simulador montado. Podem-se observar três redes: a rede do CorrespondentNode (Superior Esquerda) à qual durante este trabalho se cham ou de rede “C”; a rede local (Superior Direita) a que se cham ou rede “A”; e rede estrangeira (Inferior) a que se cham ou rede “B”.

Para melhor controlar o sistema de comunicação entre as três redes, foi criado um Router central, equipado com uma interface para cada Rede.

Na rede A e B, pode-se observar os Agentes. Os agentes aparentemente são objectos iguais, mas têm comportamentos diferentes, como se irá observar nos pontos seguintes. Pode-se observar ainda o CorrespondentNode na rede C e o MobileNode (o portátil) no universo.

No esquema geral existe ainda um painel lateral que fornece dados globais e necessários para que o utilizador controle perfeitamente o MobileNode, nomeadamente as suas coordenadas e a força do sinal wireless da rede local (Rede A) e da rede estrangeira (Rede B). No mesmo painel pode-se ainda observar o estado do buffer do Router (ver ponto 3.2).

Cada um dos objectos descritos, possui ainda uma janela de propriedades, onde é possível verificar que actividades estão a realizar e nos casos onde se aplica, verificar as tabelas de visitantes. Na figura que se segue pode-se observar a janela de propriedades do foreignAgent.

Figura 2 - Propriedades do ForeignAgent

Para ver as tabelas de propriedades, basta o utilizador seguir os passos da figura 3.

Figura 3 - Caminho para propriedades.

Como se pode observar, basta ir a View -> Properties e escolher o objecto que pretendemos observar.

O simulador contém também um cenário de teste, que pode ser acedido em Run -> xtalk (Figura 4).

Figura 4 - Acesso ao xtalk.

Figura 5 – xtalk

No xtalk é possível o utilizador enviar mensagem de mobileNode para o CorrespondentNode em modo normal e em modo full (Ver ponto 5).

3.2. Esquema de funcionamento dos Objectos

Para descrever o esquema de funcionamento vai se analisar objecto a objecto.

3.2.1. MobileNode

O MobileNode, como o nome indica, é o objecto móvel simulado neste trabalho, que circula entre redes, por controlo directo do utilizador . Para melhor entender o funcionamento deste elemento à que analisar o seu diagrama de estados, representado na figura seguinte.

Figura 6 - Diagrama de estados do MobileNode

Ao iniciar a aplicação é iniciado o M obileNode, passando do estado idle ao estado “em pesquisa”. No estado “em pesquisa”, o M obileNode encontra-se em constante pesquisa de redes, especificamente neste simulador, em constante pesquisa e comparação do sinal da rede A e B. Ao encontrar um a nova rede, passa ao estado “A pedir ligação”, estado onde é criada e enviada a Registration Request. Depois de recebida a confirmação e de ligada, volta novamente ao estado de pesquisa. Desta feita e enquanto não for detectada uma rede com melhor sinal, vai renovando de tempo a tempo o seu registo, voltando sempre ao estado de pesquisa. No caso de detectar a rede caseira com rede mais forte, o Mobile Node passa para o estado “A regressar a casa”, onde envia um Registration Request com o tempo de vida a 0, ligando-se imediatamente. De regresso à rede caseira, volta novamente ao estado de pesquisa.

De notar que em todos os estados o MobileNode tem a capacidade de comunicação com o exterior.

3.2.2. HomeAgent

O homeAgent é o agente local, cujo comportamento se reflecte no diagrama de estados apresentado de seguida.

Figura 7 - Diagrama de estados do HomeAgent

Ao ser ligado o Hom eAgente passa para o estado “Activo & & BroadCasting”. Neste estado o HomeAgent aguarda a recepção de pacotes e emite de tempo a tempo um broadcast para a rede, a notificar a sua presença. Ao receber um Registration Request com o timetolive diferente de 0, o que significa que se trata de um novo pedido vindo de um Foreign Agent, o Hoem Agent passa para o estado “A processar confirm ação”, onde analisa os dados do pedido. Se aceite, transita para o estado “A enviar confirm ação” onde envia a confirm ação ao Foreign Agent, transitando logo para o estado “Actualizar a m obilty binding table”. Neste estado actualiza a tabela e regressa ao estado “Activo & & BroadCasting”.

No caso de o Home Agent receber um Registration Request com timetolive igual a zero, transita para o estado “Actualizar a m obilty binding table”, sabendo que se trata de um objecto móvel da sua rede que regressou a esta. No novo estado retira esse objecto móvel da tabela e volta ao estado “Activo & BroadCasting”.

Na situação de receber um pacote normal, destinado a um elemento da sua rede, passa para o estado “A encam inhar”, reencam inha o pacote e regressa ao estado “Activo & BroadCasting”.

3.2.3. ForeignAgent

O foreign Agent limita-se a reencaminhar pedidos de registo e actualização de ligações, como tal o seu diagrama de estados é o seguinte:

Figura 8 - Diagrama de estados do Foreign Agent

Como se pode observar, depois de ligado o Foreign Agent, tal como o Home Agent mantém se no estado activo e a enviar broadcast’s de aviso de presença. Ao receber um Registration Request, transita para o estado “A encam inhar para o HA”, onde verifica o ip do hom e Agent e reenvia-lhe o Registration Request recebido, voltando ao estado “Activo”.

Ao receber um Registration Reply, significa que é uma resposta com sucesso de um Home Agent, ai o foreign agent transita para o estado “A actualizar a m obility binding table”, onde dá entrada do novo visitante. Actualizada a tabela e passa para o estado “A enviar ao M N”, onde envia a confirmação de registo com sucesso ao MobileNode, regressando ao estado activo.

No estado activo, caso recebe um pacote, transita para o estado “A reencam inhar”, onde analisa se o pacote vem encapsulado ou não e actua consoante o resultado, acabando sempre por reencam inhar o m esm o para o seu destino e voltar ao estado “Activo & Broadcasting”.

3.2.4. CorrespondentNode

O correspondente Node é neste cenário o elemento mais simples, cujo papel se limita em enviar e receber pacotes sem qualquer tipo específico ou restrição. Como tal o seu funcionamento é apresentado no seguinte diagrama de estados.

Figura 9 - Diagrama de estados do CorrespondentNode

Como se pode verificar, depois de ligado o CorrespondentNode só tem um estado, o estado “Activo”. Nesse estado encontra-se constantemente à espera de pacotes, podendo em simultâneo enviar os seus próprios pacotes, justificando assim o símbolo MultiState do estado activo.

3.2.5. Router O router é o elemento extra nesta simulação, mas que desempenha um papel bastante importante. O seu funcionamento contudo é simples, como se pode verificar de seguida.

Figura 10 - Diagrama de estados do router.

Como se pode observar pela figura 10, o router depois de ligado pode receber duas ordens que lhe irão alterar o estado. Uma e pressupõe-se a primeira, a ordem de nova rota, que transita o router para o estado “A adicionar rotas”. A outra ocorre quando este recebe um pacote, transitando para o estado “A reencam inhar”. O funcionam ento interno do router é analisado no ponto 3.3. deste relatório.

3.3. Esquema de funcionamento da comunicação Para desenvolver este simulador foram utilizadas comunicações reais do tipo datagrama (UDP), criando-se sockets reais. Ora, como na realidade apenas existe um IP físico, toda essa parte é simulada, sendo a diferenciação da comunicação efectuada através da distinção de portos, ou seja, por detrás da sim ulação de IP’s está um a com unicação real a ocorrer sobre a mesma interface, que divide as várias ligações pelos vários portos. O esquema seguinte reflecte a implementação em camadas.

Aplicação Gráfica Simulada

Cam ada sim ulada de vários IP’s

Camada física de IP único

Figura 11 - Esquema de camadas

Na camada física são utilizados os portos segundo a tabela demonstrada de seguida.

Porto HomeAgent ForeignAgent

Envio para o exterior 10025 10027

Recepção do exterior 10026 10028

Envio Local 10040 10042

Recepção Local 10041 10043

Envio de BroadCast 10050 10044

Recepção de BroadCast

10051 10045

Podia-se ter utilizado o porto de broadcast junto com o local, contudo foram separados para simplificar a implementação. Estes são os portos utilizados por cada entidade para a comunicação real.

Na cam ada de sim ulação de IP’s entra a sim ulação de pacotes IP, construídos com todos os campos como se de um pacote real se tratasse, mas que na altura de serem enviados, são convertidos numa string e metidos num socket real.

A conversão do pacote IP para string obedece a um protocolo de comunicação predefinido, de forma a que o que um elemento envia, seja aquilo que o outro recebe. Esse protocolo é bastante simples e resume-se a escrever todos os elementos constituintes de um pacote IP num a string, separados por “:”, term inando a string com “\r\n”, com o se pode ver no exem plo que se segue:

this.setFrame(new String(ha.getAddress()+":"+coa.getAddress()+":"+s.getAddress()+":"+dest.getAddress()+":"+protocol+":"+data+":\r\n"));

De notar, que também os pacotes encapsulados são suportados por este método.

Na camada da aplicação, nada destas configurações são visíveis. Apenas o IP de cada elemento é mostrado nas janelas de propriedades, sendo tudo o resto funcionamento transparente.

Resumindo, o que acontece quando por exemplo o CorrespondenteNode envia um pacote para o MobileNode, estando este na rede local, resulta no seguinte esquema:

Figura 12 - Esquema de transição de pacotes.

Na aplicação escreve-se um texto e envia-se para o MobileNode . (Camada Aplicação Gráfica)

Com esse texto é criado um pacote IP virtual. (Camada Simulada IP).

Esse pacote virtual é enviado fisicamente, utilizando sockets UDP, entre portos diferentes.

Os encaminhadores apenas verificam o pacote IP simulado e não o seu conteúdo.

3.3.1. Interfaces. Para efectuar todo o processo de comunicação com a rede física, foram criados objectos a que se chamaram Interfaces. Imagine-se um switch de 20 portas, cada uma dessas portas é uma Interface.

As Interfaces têm a capacidade de receber e enviar dados simultaneamente, isto porque estão dotadas de uma thread responsável pela recepção de dados.

Desenvolveram-se ainda dois tipos de Interfaces, Interfaces sem buffer e com buffer. A grande vantagem do buffer, neste cenário, reside no facto de garantir menos perdas de pacotes, maior rapidez na rede e menor consumo de processamento, isto porque um equipamento dotado de interfaces sem buffer, tem a cada interacção verificar se cada uma das suas interfaces recebeu algum pacote, sendo inviável para equipamentos com mais de uma interface. Assim, com um buffer e todas as interfaces de um equipamento a escrever para o mesmo, optimiza-se bastante o cenário de rede.

3.3.2. Router

O router, como já foi visto anteriormente, tem a capacidade de adicionar rotas. Para adicionar uma rota é-lhe fornecido apenas o IP da rede da nova rota. Ai, o router cria uma interface especificamente para aquela rede. Essa interface contém um número de identificação que será utilizado para reencaminhar o tráfego entre as diferentes interfaces do router. Para tal, o router mantém uma tabela actualizada, tendo cada entrada a rede e respectiva interface.

O router contém também um buffer, que distribui por todas as suas interfaces, ou seja, todas as interfaces ao receberem um pacote guardam-no no buffer. O router apenas tem de verificar o buffer e caso este tenha pacotes :

Verificar o IP de destino.

Obter o IP de rede do IP de destino

Obter o número da interface ligada à rede obtida, pesquisando na tabela de encaminhamento.

Reencaminhar o pacote para a interface obtida.

Por opção, sempre que o buffer atingir o limite e o router não conseguir dar vazão a tantos pacotes, os novos que chegarem serão descartados. Assim, o tamanho do buffer deverá ser configurado para um valor aceitável consoante o volume de tráfego da rede.

4. Diagrama de Classes Neste ponto vai se descrever e justificar o diagrama de classes desenvolvido na implementação do simulador. Não vai ser um diagrama, mas vários, correspondendo cada um a uma package. Para melhor compreender o que segue, deve-se observar a seguinte figura.

Figura 13 - Package criadas.

Ora, na figura 13 pode-se observar as packages criadas no projecto MobileIP. Respectivamente dizem respeito a :

Images - contém as imagens utilizadas no ambiente gráfico.

Mobileip – contém as classes principais. (Main, MainFrame e MainPanel), que constroem toda a aplicação.

MobileIP.communication – contém todas as classes referentes aos objectos de com unicação, ou seja, que funcionam na cam ada “Sim ulação IP ” e contacto com a cam ada “Física”.

MobileIP.gui – contém as janelas secundárias e as classes necessárias ao carregamento de imagens.

MobileIP.gui.designers – contém as classes responsáveis por criar e desenhar os modelos.

MobileIP.model – contém os modelos principais deste projecto, ou seja, os objectos que se vêm e com os quais se interage na aplicação.

De seguida vai se entrar dentro de cada package e analisar ao pormenor cada classe.

4.1. package mobileIP

Figura 14 - Classes de MobileIP.

Diagrama de Classes 1 - Package Mobile.

Nas duas ultimas imagens pode-se observar primeiro as classes e depois o seu diagrama.

Como se pode observar a classe Main é uma classe directa de objecto, que apenas serve para iniciar a aplicação. A classe MainFrame é então a classe que cria a toda a interface, ou seja a janela principal, os menus, o painel lateral e o MainPanel. O MainPanel é nesta package, do ponto de vista do simulador, a classe mais importante, pois é no MainPanel onde todo o sistema é criado, inicializado e actualizado.

O MainPanel é constituído pelos seguintes métodos:

Inicializador() – Método responsável por criar e iniciar instancias de todos os objectos interactivos da aplicação. Método onde se definem aspectos desde a localização gráfica dos elementos, até ao seu IP, ou aos portos de comunicação.

paintComponent() – Sobrepõe-se ao método com o mesmo nome da sua classe superior e tem a função de desenhar graficamente os objectos. Com o método em modo override, sempre que se evocar o método do super repaint(), será este método a ser chamado.

Key_pressed() e key_released() – Métodos evocados quando se clica numa tecla, permitindo assim a navegação do Mobile Node pelo ambiente gráfico. Sempre que o key_pressed é evocado, o método repaint() é chamado para desenhar a nova configuração.

4.2. package communication

Figura 15 - Classes da Package communication.

Diagrama de Classes 2- package communication.

Na figura 15 e no diagrama 2, pode-se observar as classes que constituem esta package e o seu relacionamento hierárquico. Tendo o Diagrama em consideração e a contar da esquerda para a direita, as classes são :

Buffer – classe que herda de LinkedList e implementa a funcionalidade já descrita neste relatório, de buffer. A diferença para o seu objecto superior é que este tem o buffer tem um limite máximo configurável e métodos sincronizados, podendo servir como memória partilhada entre Threads. Os seus métodos principais são:

isFull - Método que verifica se o buffer atingiu o limite da sua capacidade.

Read – Método que lê o primeiro elemento da lista, devolve-o, e retira-o desta.

Write – Método que permite inserir um elemento no buffer.

Connection – Classe que herda directamente de objecto e é utilizada para criar uma ligação IP, virtual, nos elementos desta aplicação. O construtor recebe a rede em que se pretende a ligação, como parâmetro e define os vários elemento da ligação, como IP, mascara e gateway.

DNS - Classe que deriva de HashTable e é utilizada apenas como auxilio, mantendo um registo entre os nomes e os IP’s. A sua im portância é irrelevante para o funcionamento do MobileIP.

IP – classe muito simples que representa um IP como apenas como string e contém um elem ento que define se está atribuído ou não, bastante útil na gestão da lista e IP’s do foreignAgent.

Interface – Classe que descende directamente e objecto e constrói o elemento descrito no ponto 3.3.1. . Implementa a interface Runnable, cujo método Run irá ser responsável por receber os pacotes da rede. Contém ainda os métodos:

Send – permite enviar pacotes para um IP específico.

BroadCast – permite à interface enviar pacotes de broadcast.

InterfaceV2 - Classe que descende de Interface, acrescentando –lhe a capacidade de escrita para buffer, ou seja, recebe um buffer por parâmetro, enviando-lhe todo e qualquer pacote recebido.

IPacket - Classe que representa um pacote IP, constituído pelos principais elementos que de um pacote fazem parte. Possui dois construtores, um para pacotes normais e o outro para pacotes encapsulados (IP-Within-IP).

Na implementação deste simulador entendeu-se apenas utilizar o método de encapsulamento Básico. Caso se pretende-se implementar os restantes, teriam que ser desenvolvidos um construtor para cada tipo de encapsulamento.

Message – Classe que representa as mensagens de pedido de registo e de resposta, ou seja, reúne o que à em comum entre as mensagens de request e as mensagens de reply.

Request – Classe que herda de Message, acrescentando-lhe mais uns atributos apenas específicos da mensagem de request.

Reply - Classe que herda de Message, acrescentando apenas mais uns atributos específicos da mensagem de reply.

Tunnel - Classe que descende de DatagramSocket, implementando um método especifico para envio, recepção e envio de broadcast’s na rede física real. Funciona assim na cam ada “Fisica” deste sim ulador, servindo de interface directa com a “Interface ou InterfaceV2” que funcionam na cam ada de “Sim ulação IP”.

Network – Classe que constrói cada rede, no caso desta implementação, a Rede A, B e C. Os métodos mais importantes são:

Getdot – Método que recebe um ip e devolve um string constituída pelos três primeiros bytes desse ip, do tipo 192.168.10. .

setIpList – Define um a lista para um a dada rede, de IP’s disponíveis a atribuir.

upDateIpList – Actualiza o estado de um específico ip da lista, ou seja, se está atribuído ou não.

Dhcp – m étodo que selecciona da lista de IP’s, um que não esteja atribuído e devolve-o, actualizando a lista.

4.3. package gui

Figura 16 - Classes de gui.

Diagrama de Classes 3 - package gui.

Na figura 16 e no diagrama 3, pode-se observar as classes que constituem a package gui. Nesta package temos todo o conjunto de ferramentas necessárias para construir um aspecto gráfico e ainda as janelas secundárias deste simulador. Descrevendo as classes, têm-se:

Entity – Representa graficamente uma entidade utilizada na simulação. Ou seja é um objecto com dimensão, posição e imagem.

MobileEntity – descende de entity e representa as entidades com mobilidade, ou seja, acrescenta a funcionalidade a uma entity de se mover. Os métodos mais relevantes são:

Move – redefine a posição da entidade no espaço.

distanciaEntrePontos – que baseado no teorema de Pitágoras devolve a distancia entre a entidade móvel e um outro qualquer ponto. Este método é o utilizado para calcular as forças de sinal das redes, em conformidade com a localização do MobileNode.

Point – Classe que define um ponto no espaço. Constituído por coordenadas x e y.

Sprite – Classe que constrói um objecto baseado numa imagem. Permite desenha-lo e obter as suas dimensões.

SpriteStore – Classe que representa um repositório de dados utilizado para guardar as Sprites que vai criando. Assim, existe um método que recebe um caminho para uma imagem, cria uma sprite com a mesma e guarda a numa tabela.

MiniJanela – Classe que descende de JFrame e constrói a base gráfica para a janela visualizada no momento em que o utilizador abre a janela de propriedades de um objecto.

PropWindow – Classe que descende de MiniJanela e que tem como função redefinir-lhe os atributos, adaptando-a ao objecto cujas propriedades vai mostrar. Tem ainda os importantes métodos:

Update(String) - m étodo que actualiza a janela de log’s.

Update(Hashtable) – método que actualiza a visualização da mobilty binding table.

XTalk – Classe bastante importante neste simulador pois é responsável por criar o objecto que fornece os mecanismos de teste, ou seja, permite efectuar a comunicação em vários modos, entre o CorrespondentNode e o MobileNode. Também ele descende de JFrame e implementa a interface Runnable, cujo método Run implementado por uma thread local é utilizado para efectuar o teste de fullload. O fullload consiste em bombardear o outro ponto da rede com pacotes, permitindo mover o MobileNode e verificar o que acontece.

4.4. package gui.designers

Figura 17 - Classes de gui.designer.

Diagrama de Classes 4 - package gui.designers

Ao observar a figura 17 e o diagrama 4 pode-se verificar as classes constituintes desta package, sendo o nome de cada uma bastante intuitiva da sua funcionalidade. Especificando:

AgentDesigner – desenha e constrói os agentes, tanto home como foreign.

CNodeDesigner – desenha e constrói o correspondent node.

MobileDesigner – desenha e constrói o mobileNode.

Network Designer – desenha e constrói cada rede, no caso desta implementação, a Rede A, B e C.

RouterDesigner – desenha e constrói o router central.

A implementação destas classes é bastante simples, pois limitam-se a desenhar a parte gráfica, visto descenderem de Entity e a construir o objecto para o qual foram implementados. Os Designers são classes que reúnem numa só a construção gráfica e física dos modelos utilizados nesta simulação. As classes dos próprios modelos encontram-se na package seguinte.

4.5. package model

Figura 18 - Classes da package model.

Diagrama de Classes 5 - package model.

Nas duas últimas figuras, pode-se então observar as classes constituintes da package model, representando as classes finais de cada ramo, as entidades interactivas deste simulador. As classes descritivamente, são:

ActivObject - Classe que reúne todos os objectos com nome e propriedades.

Agent – Classe que representa o objecto Agente, implementando os pontos comuns ao dois tipos de agente existentes. Implementa ainda a interface Runnable, permitindo aos agentes implementar o método Run, utilizando threads.

HomeAgent – Classe que descende de Agent e representa o objecto Home Agent. Os métodos mais importantes do HomeAgent são:

Run - Método implementado pelas threads do home agent. Uma das threads foca-se na comunicação normal, a outra no processo de envio e broacast’s e actualização do tempo de vida dos seus Agentes eu estão no exterior.

isForMe - Método que verifica se o pacote recebido é para o agente. Para tal apenas compara o ip de destino com o seu.

packetAnalizer – é o método evocado no momento em que o agente recebe um pacote para uma entidade local. Neste método o agente verifica se a entidade local se encontra fora ou não, reencaminhando o pacote para a interface certa, consoante o resultado da sua pesquisa.

registrationReply – Método evocado no momento em que recebe um RegistrationRequest com timetolife diferente de 0. Neste método o agente regista o Mobile Node na sua tabela, constroí a Message Reply e eniva-a ao FA.

timeUpdate – Método chamado de 3 em 3 segundos para actualizar o tempo de ligação de cada Mobile Node na rede estrangeira.

ForeignAgent - Classe que descende de Agent e representa o objecto Home Agent. Os métodos mais importantes do HomeAgent são:

Run – Método que implementa os trechos de código corrido por cada uma das três threads que o constituem. Uma trata da comunicação com a rede interna, a segundo com a rede externa e a terceira preocupa-se com os broadcast’s e actualização da m obility binding table.

isForMe - Método que verifica se o pacote recebido é para o agente. Para tal apenas compara o ip de destino com o seu.

RegistrationrequestHA – Método que envia um pedido de registo de um Mobile Node ao seu HomeAgent.

regNewMN – Método que invocado quando o FA recebe um RegistrationReply de um HÁ. Neste método o FA actualiza a sua mobility binding table com o novo registo e reenvia a mensagem recebida ao Mobile Node. Este método é utilizado tanto em modo de renovação e ligação como de nova ligação.

timeUpdate – Método chamado de 3 em 3 segundos para actualizar o tempo de ligação de cada Mobile Node registado na Mobility Binding Table. Quando esse tempo chega a 0, remove o MN da tabela.

Talker – Classe que reúne vários atributos comuns aos objectos falantes, neste caso o Mobile Node e o CorrespondentNode. Implementa também a interface Runnable.

MobileNode - Classe que representa o objecto falante móvel. O MN possui três threads que implementam o método Run. Uma para comunicação normal , a outra para pesquisa da melhor rede em cada posição e a última para verificar constantemente o tempo de vida da ligação actual, sendo responsável por realizar pedidos de renovação. Os principais métodos do Mobile Node são:

receiveAdvertisment - Método evocado quando a thread de pesquisa recebe um pacote de uma rede que não de ligação actual. Neste método é comparado a força dessa rede com a actual e no caso da nova rede ser mais forte, é enviado um registration Request.

sendregistrationRequest – Método evocado pelo método a cima referido, responsável por criar uma Message Requeste e enviá-la para a nova rede detectada.

receiveConfirmation – Método evocando quando é recebida um Message reply, verificando o sucesso do mesmo.

sendHomeRequest – Metodo evocado quando o MN detecta que a sua rede de casa tem mais força que qualquer outra. Assim, envia um RegistrationRequest com o TTL a 0 para o seu Home Agent.

Router – Classe que implementa o objecto Router, tendo como principais métodos:

addRoute – Método utilizado para adicionar uma nova rota na tabela e routing.

Routing – Método que recebe um pacote, determina qual a interface de destino e devolve essa interface.

Run – Método implementado por uma thread responsável por a cada pacote que retira o buffer, obter a sua interface de destino através do método routing e enviá-lo pela mesma.

5. Testes de funcionamento

Neste ponto irão ser descritos os testes e funcionamento efectuados.

Ao iniciar a aplicação, o utilizador depara-se com o representado na figura seguinte.

Figura 19 - Cenário principal.

Para melhor controlar o sistema, o utilizador deverá abrir as propriedades do MobileNode, do Foreign Agent e do Home Agent. Como tal deverá ir ao menu -> View - > Properties e ai escolher as propriedades que deseja observar.

Figura 20 - Menu View.

Abertas as propriedades dos três, o utilizador fica com o seguinte cenário.

Figura 21 - Cenário com as propriedades visíveis.

Em cada janela de propriedades, o utilizador pode verificar o que cada um dos três elementos está a realizar, para além do respectivo IP e nos casos dos agentes da mobility binding Table.

Para primeiro teste vamos deslocar o Mobile Node para uma zona onde a força do sinal A seja menor que a força do sinal B, ou seja, que exista uma rede com sinal mais forte, que não a sua.

Figura 22 - deslocar o mobile node.

Como se pode observar a rede B tem um sinal com força superior à rede A, então ocorreu um registo no FA da rede B, como comprovam as mobility binding tables. Focando as propriedades do Home Agent e do Foreign temos:

Figura 23 - Propriedades do HA.

Figura 24 - Propriedades do FA.

Pode-se verificar os passos efectuados por cada um, descritos nos logs e o novo registo na tabela. Do lado do MobileNode aparece a confirmação de ligação na nova rede.

Figura 25- Propriedades do MN.

Ligado na rede estrangeira, vai se iniciar o xtalk e realizar comunicação com o CorrespondentNode.

Figura 26 - Iniciar o Xtalk

Figura 27 - Xtalk.

O xtalk é um sistema baseado no Messenger, mas vocacionado para o cenário de teste, fornecendo dois modos de comunicação, simples e full Load. De seguida vai se demonstrar a comunicação simples, mantendo o Mobile Node na rede estrangeira.

Figura 28 - Comunicação simples em rede estrangeira.

Agora, o derradeiro teste passa por meter o CorrespondentNode a enviar em Full Load, e mover o Mobile Node para a sua rede nativa, voltar a move-lo para a rede estrangeira e a comunicação nunca ser quebrada.

Figura 29 - Início de full Load.

Na figura 29 pode-se observar o início do envio em full Load. De notar que o buffer do router está a ficar cheio, em full mode ele está sempre a encher e vazar. (Barra a verde).

Mantendo o full Load a correr, regressa-se com o Mobile Node a casa.

Figura 30 - Regresso a casa em full Load

Na figura 30, pode-se para além de provar a continuidade da comunicação, comprovar que o MN está em casa, observando a Mobility Binding Table do seu Home Agent, que já não contêm o registo. A do FA mantêm esse registo, na altura do screenshot o TTL ia em 40 segundos, sendo o tempo que faltaria para o FA remover a entrada da sua tabela.

Agora o Mobile Node vai refazer o caminho, novamente até à rede B.

Figura 31 - Nova saída com o mesmo Full Load.

Na figura 30, pode-se verificar o novo registo na rede B ia a continuidade da recepção de pacotes, indo já no pacote 2090.

De notar que neste cenário de teste, em Full Load é normal ocorrerem perdas de pacotes, derivas pelo limite do buffer em relação ao sistema de processamento, ou seja, a capacidade das entidades intervenientes na comunicação processarem os pacotes é bastantes inferior à capacidade de um ciclo while(1) a enviar pacotes em altíssimos débitos.

Testada a comunicação e registo, falta demonstrar a renovação do registo por parte do Mobile Node.

Figura 32 - MN em Rede estrangeira.

Nesta figura pode-se ver a vermelho o tempo de vida da ligação. Do lado dos agentes o tempo é de 55000 = 55segundos, enquanto que o MN pensa que o tempo é de 46segundos, dando assim um intervalo de segurança, ou seja, o Mobile Node pensa que o tempo está quase a acabar quando ainda tem mais 10 segundos. De 30 em 30 segundos o Mobile Node efectua um pedido de renovação da ligação, dando origem ao apresentado na figura seguinte.

Figura 33 - renovação de ligação.

Pode-se então verificar a vermelho a alteração do tempo de vida, tanto no FA como no HA, a azul no log do FA, o registo “Avisar M N que a ligação esta renovada”, e no log do M N os Dados da Message Reply recebida, como resultado da actualização do tempo.

6. Conclusão O Mobile IP ainda é uma criança, ou melhor, uma ferramenta pouco utilizada, que com a convergência referida na introdução deste documento, deverá ver o seu auge no momento em que todas as comunicações móveis utilizarem a plataforma IP, ou seja, talvez no pico do 4G, ou seja, bastante tempo após a sua definição[IETF96b].

Quanto ao protocolo em si, teoricamente é simples e demonstra uma solução bastante inteligente. Em cenário de simulação, através de uma aplicação situada numa só máquina torna-se algo complicado, quando se tenta realizar mesmo comunicação com sockets, o que aconteceu no simulador descrito neste relatório, contudo tal foi possível recorrendo ao sistema de portos.

Neste momento e no fim de todo este processo de desenvolvimento, responsável por um acumular de novos conceitos na área, fica claro que na prática o Mobile IP dependerá de vários factores externos ao protocolo que o podem afectar negativamente. Também fica a dúvida de até que ponto a sua implementação em IPv4, sem optimização de rotas, irá trazer vantagens, não representando muitas vezes redundância na comunicação e alargamento desnecessário do volume de tráfego.

7. Bibliografia [IETF94] http://www.ietf.org/rfc/rfc1701.txt

[IETF96] http://www.ietf.org/rfc/rfc2003.txt

[IETF96a] http://rfc.net/rfc2004.html

[IETF96b] http://www.faqs.org/rfcs/rfc2002.html

[wiki06] http://en.wikipedia.org/wiki/Mobile_ip