Simulador de roteamento
57
Click here to load reader
description
Transcript of Simulador de roteamento
UNIVERSIDADE DO VALE DO ITAJAÍ
CONRADO VARDANEGA
SIMULADOR DE ROTEAMENTO IP
SÃO JOSÉ
2005
CONRADO VARDANEGA
SIMULADOR DE ROTEAMENTO IP
Trabalho de Conclusão de Curso apresentado como
requisito parcial para obtenção do título de Bacharel em
Ciência da Computação na Universidade do Vale do
Itajaí, Centro de Educação São José.
Orientador: Prof. Marcelo Maia Sobral
RESUMO
Neste trabalho se propôs construir um simulador de roteamento IP, o qual seria utilizado para
fins de experimentação de roteamento em diversas topologias. O produto permite simular,
textualmente, redes com computadores, roteadores e enlaces ponto-a-ponto. Os roteadores
podem descobrir suas rotas dinamicamente através de RIP ou, se assim desejado for, as rotas
podem ser informadas manualmente.
A entrada de dados é textual, sendo necessário codificar a representação da rede a ser
simulada. A saída do simulador é personalizável e, também, textual. É possível mostrar
apenas mensagens referente ao funcionamento do RIP, sobre decisões de roteamento,
ocupação do meio físico, etc.
O simulador leva em conta a taxa de transferência dos meios físicos, calculando o tempo que
os datagramas levam para chegar aos seus destinos. Os computadores e roteadores
implementam fielmente o algoritmo de encaminhamento IP.
No capítulo 4 há vários exemplos de cenários simulados com e sem roteadores, com enlaces
de diversas capacidades, com roteamento estático e dinâmico.
Palavras-chave: roteamento, simulação, rip, simulação de roteamento, endereçamento
hierárquico, cidr, ospf, vetor de distância, estado de enlace.
CONRADO VARDANEGA
SIMULADOR DE ROTEAMENTO IP
Este Trabalho de Conclusão de Curso foi julgado adequado para obtenção do título de
Bacharel em Ciência da Computação e aprovado pelo Curso de Ciência da Computação da
Universidade do Vale do Itajaí, Centro de Educação São José.
São José, 16 de dezembro de 2005.
Apresentada à banca avaliadora formada pelos professores:
Prof. Marcelo Maia Sobral, Msc. UNIVALI – Centro de Educação São José
Orientador
Prof. Alexandre Moraes Ramos, membro da banca examinadora
Prof. Henrique Simas, membro da banca examinadora
ÍNDICE DE FIGURAS
Figura 1 – As camadas do modelo OSI. ...................................................................................12
Figura 2 – Camadas TCP/IP e OSI...........................................................................................13
Figura 3 – Exemplo de um endereço IP. ..................................................................................14
Figura 4 – Classes de endereços IP. .........................................................................................15
Figura 5 – Exemplo de sub-rede...............................................................................................16
Figura 6 – Máscara de sub-rede................................................................................................16
Figura 7 – Exemplo de tabela de roteamento. ..........................................................................18
Figura 8 – Exemplo de rede como um grafo. ...........................................................................20
Figura 9 – (a) Roteamento com vetor de distância: um exemplo de rede. (b) Tabela de
roteamento incial em A.............................................................................................................21
Figura 10 – Tabela de roteamento final em A. .........................................................................22
Figura 11 – (a) Uma rede. (b) Os pacotes de estado de enlace para esta rede..........................25
Figura 12 – Mudanças de estado em modelos discretos...........................................................31
Figura 13 – Mudanças de estado em modelos contínuos. ........................................................32
Figura 14 – Simulação típica com dois nós..............................................................................35
Figura 15 – Um barramento Ethernet no cnet. .........................................................................35
Figura 16 – Exemplo de uma rede gerada aleatoriamente........................................................36
Figura 17 – Representação de uma Interface............................................................................38
Figura 18 – Representação de um Roteador.............................................................................38
Figura 19 - Dois computadores interligados ............................................................................45
Figura 20 - Dois computadores conectados por meio de um roteador .....................................46
Figura 21 - Rede com dois computadores e dois roteadores ....................................................48
SUMÁRIO
1 INTRODUÇÃO..............................................................................................................8 1.1 Contextualização ............................................................................................................8 1.2 Problema.........................................................................................................................8 1.3 Objetivos.........................................................................................................................9 1.3.1 Objetivo geral .................................................................................................................9 1.3.2 Objetivos específicos......................................................................................................9 1.3.3 Escopo e delimitação......................................................................................................9 1.4 Resultados esperados......................................................................................................9 1.5 Justificativa...................................................................................................................10 1.6 Aspectos metodológicos ...............................................................................................10 1.7 Cronograma ..................................................................................................................10
2 REDE DE COMPUTADORES....................................................................................11 2.1 Arquitetura da rede .......................................................................................................11 2.2 Arquitetura TCP/IP.......................................................................................................13 2.2.1 Endereçamento IP.........................................................................................................14 2.2.2 Endereçamento hierárquico ..........................................................................................14 2.2.3 Sub-redes ......................................................................................................................15 2.2.4 Roteamento interdomínio sem classe (CIDR) ..............................................................16 2.3 Algoritmo de encaminhamento IP................................................................................17 2.4 Descoberta de rotas.......................................................................................................20 2.4.1 Estático .........................................................................................................................20 2.4.2 Vetor de distância .........................................................................................................21 2.4.3 Estado de enlace ...........................................................................................................24
3 SIMULAÇÃO ..............................................................................................................27 3.1 Vantagens e desvantagens da simulação ......................................................................27 3.1.1 Vantagens .....................................................................................................................27 3.1.2 Desvantagens ................................................................................................................28 3.2 Estrutura de um simulador típico .................................................................................28 3.2.1 Variáveis de estado.......................................................................................................29 3.2.2 Eventos .........................................................................................................................29 3.2.3 Entidades e atributos.....................................................................................................29 3.2.4 Recursos e fila de recursos ...........................................................................................30 3.2.5 Tempo real e tempo de simulação ................................................................................30 3.2.6 Mecanismos de avanço do tempo.................................................................................30 3.3 Simulação discreta e simulação contínua .....................................................................31 3.4 Funcionamento de um simulador .................................................................................32 3.4.1 Evento Chegada............................................................................................................32 3.4.2 Evento Saída .................................................................................................................33 3.4.3 Evento Fim da Simulação.............................................................................................33 3.4.4 Avanço do relógio de simulação ..................................................................................33
7
3.5 Simuladores de rede já existentes.................................................................................34 3.5.1 cnet ...............................................................................................................................34 3.5.2 Network Simulator (ns) ................................................................................................36 3.6 Simulação de uma rede.................................................................................................37 3.6.1 Elementos básicos ........................................................................................................37 3.6.2 Componentes do simulador de rede..............................................................................37 3.6.3 Avanço do tempo..........................................................................................................39
4 FRAMEWORK DE SIMULAÇÃO DE ROTEAMENTO IP......................................40 4.1 Organização geral do framework .................................................................................40 4.2 Visão geral dos elementos do framework de simulação de roteamento.......................40 4.2.1 A interface de rede........................................................................................................41 4.2.2 Computadores e Roteadores .........................................................................................41 4.2.3 Meio físico....................................................................................................................42 4.3 A interface de módulo de roteamento...........................................................................43 4.4 Módulo de roteamento RIP ..........................................................................................43 4.5 Interface com o usuário ................................................................................................43 4.6 Exemplos de simulação ................................................................................................44 4.6.1 Cenário 1: dois computadores diretamente conectados................................................44 4.6.2 Cenário 2: dois computadores interligados por meio de um roteador..........................46 4.6.3 Cenário 3: demonstrando o tratamento de uso do meio físico .....................................48 4.6.4 Conclusão sobre os exemplos de simulação.................................................................51 4.7 Extensibilidade do framework......................................................................................51
5 CONSIDERAÇÕES FINAIS .......................................................................................52
ANEXOS..................................................................................................................................54 ANEXO 1: Diagrama de classes do framework de simulação discreta ...................................55 ANEXO 2: Diagrama de classes do framework de simulação de roteamento IP.....................56
REFERÊNCIAS .......................................................................................................................57
1 INTRODUÇÃO
1.1 Contextualização
O propósito de criar um simulador de roteamento é dar suporte às aulas de redes de
computadores (ministradas em alguns cursos de graduação). Se a aula se limita à exposição
teórica ou mesmo quando há prática, limita-se às experiências que podem ser feitas em
laboratório, de forma que o aprendizado é, com freqüência, prejudicado.
Assim, o presente trabalho vem propor que o simulador seja usado como ferramenta de apoio
no ensino destas disciplinas.
1.2 Problema
Permitir que acadêmicos que estejam cursando a disciplina de redes possam experimentar
roteamento em laboratório é uma experiência restrita, visto que há uma diversidade
considerável de topologias em que o roteamento pode ser experimentado. Desta forma, uma
experiência prática (real), estaria limitada a algumas poucas topologias que se consiga montar
em laboratório e conforme a tecnologia dos equipamentos que estivessem disponíveis.
Um simulador de roteamento tornaria possível praticar o roteamento em um ambiente de
simulação, ampliando as possibilidades de topologias e configurações possíveis.
Em suma, há três possíveis formas de exercitar o roteamento, a saber:
1. Sistema real: consiste em realizar os experimentos na prática, usando computadores,
roteadores e outros equipamentos de rede. Esta possibilidade implica a limitação das
diferentes topologias possíveis.
2. Modelo analítico: consiste em elaborar um modelo matemático que represente a rede e o
roteamento. É complexo devido ao grande número de variáveis a serem consideradas.
3. Modelo de simulação: consiste em elaborar um modelo que espelhe a topologia que se
deseja experimentar, focando os elementos essenciais, e que possa ser executado
iterativamente. É relativamente mais simples que o modelo analítico e capaz de
proporcionar resultados razoáveis.
9
Das possíveis formas ora apresentadas, a simulação apresenta bons resultados como
ferramenta de apoio ao aprendizado. A CISCO1, por exemplo, faz uso de um simulador
próprio para ministrar seus cursos de treinamento.
Ao analisar alguns dos simuladores de rede encontrados na Internet, constata-se que (i) apenas
algumas delas permitem exercitar roteamento (nem todas são voltadas para este propósito) e
(ii) costumam ser de uso complexo, demandando mais tempo estudando a forma de utilizar a
ferramenta do que realmente fazendo uso prático.
1.3 Objetivos
1.3.1 Objetivo geral
Criar um simulador de roteamento IP.
1.3.2 Objetivos específicos
1. Simular roteamento estático, RIP e OSPF.
2. Criar um framework para simular roteamento.
3. Criar uma interface para fácil operação do simulador.
1.3.3 Escopo e delimitação
O simulador que se pretende construir será uma ferramenta estritamente acadêmica e não irá
representar produtos comerciais. Será limitado a demonstrar como o roteamento de
datagramas IP (IP versão 4, ou IPv4) é realizado ao longo da rede simulada, mas sem
considerar padrões de tráfego de aplicações de rede. Permitirá simular vários cenários com
várias topologias diferentes. Por fim, não irá fornecer informações sobre ocupação de
recursos.
1.4 Resultados esperados
Espera-se construir, ao término deste trabalho, um simulador que permita realizar
experiências de roteamento em variadas topologias. Como subproduto deve-se disponibilizar
um framework, com o qual se possa estender o simulador com novas funcionalidades, que não
constam no escopo deste trabalho.
1 CISCO: um dos maiores fornecedores de equipamentos e treinamento em redes de computadores do mundo.
10
1.5 Justificativa
O simulador de roteamento IP será uma ferramenta de utilização imediata, fornecendo uma
interface com o usuário amigável e intuitiva de forma que possa ser utilizado sem que seja
necessário dedicar muito tempo de estudo sobre como usar a ferramenta.
O simulador, assim proposto, tornaria-se uma conveniente ferramenta para que os acadêmicos
que estão cursando as disciplinas de redes possam, individualmente, exercitar o roteamento
com suas próprias topologias, sem que, para tanto, precisem dispor de equipamentos reais.
1.6 Aspectos metodológicos
O presente trabalho caracteriza-se como um trabalho de desenvolvimento. Por este fato, a
metodologia a ser utilizada é estritamente de levantamento de bibliografia, projeto e
implementação.
1.7 Cronograma
PRAZO TCC Etapa 06/04/2005 1 Revisão bibliográfica: Redes de computadores e roteamento IP. 04/05/2005 1 Revisão bibliográfica: simulação discreta. Pesquisa de outros simuladores
e linguagens de simulação. 18/05/2005 1 Revisão bibliográfica: aspectos ergonômicos, etc. 01/06/2005 1 Apresentação do ambiente de simulação proposto. 17/08/2005 2 Realização: implementação do framework. 14/09/2005 2 Realização: implementação do simulador. 05/10/2005 2 Realização: implementação da interface. 26/10/2005 2 Validações. 09/11/2005 2 Conclusão da documentação.
2 REDE DE COMPUTADORES
Neste capítulo são apresentados alguns fundamentos de redes de computadores que são
importantes ao considerar-se a construção de um simulador de roteamento.
Definição: rede de computadores é “um conjunto de computadores autônomos,
interconectados” (TANENBAUM, 1997, p. 2). Diz-se que são interconectados se eles são
capazes de trocar informações entre si; e que são autônomos quando não dependem uns dos
outros para executar uma determinada tarefa.
2.1 Arquitetura da rede
O papel principal de uma rede é possibilitar a comunicação entre computadores. Para tanto, é
necessária uma infra-estrutura física para comunicação e software nos computadores que
implemente as funções de comunicação. As funções de comunicação são responsáveis por
transportar as mensagens entre processos em computadores diferentes. Devido ao grande
número de requisitos para tais funções, adota-se uma abordagem em camadas. A cada camada
é atribuída uma tarefa específica (ou um conjunto delas), tornando-a independente das
demais. Cada camada, entretanto, só se comunica com as camadas adjacentes: uma camada
oferece serviços à camada imediatamente superior e usa serviços da camada imediatamente
inferior.
Existe um modelo de camadas formalizado para interconexão de sistemas abertos,
denominado “modelo OSI” (Open System Interconnection). Este modelo separa em sete
tarefas diferentes o trabalho de transportar dados de um lado a outro. As camadas do modelo
OSI são as apresentadas na figura 1, que ilustra a forma como as camadas são dispostas.
12
Figura 1 – As camadas do modelo OSI.
As funções de cada camada do modelo OSI são:
1. Camada física: é a parte da rede que lida com sinais elétricos, ópticos ou de outra natureza
que venham a ser usados. Em outras palavras, converte uma seqüência de bits em um sinal
analógico e vice-versa.
2. Camada de enlace: agrupa os bits, tratando-os como unidades denominadas quadros.
3. Camada de rede: responsável por encaminhar pacotes por diversos dispositivos para que
chegue ao seu destino.
4. Camada de transporte: faz a multiplexação de fluxos dentro de um computador, o que
possibilita a comunicação entre processos em diferentes computadores.
5. Camada de sessão: controla fluxos de dados, conectados ou não, e que tenham uma
associação lógica. Isto inclui sincronização e restabelecimento de fluxos, por exemplo.
Não há implementação em um protocolo específico da Internet, sendo incorporada à
camada de aplicação quando necessário.
6. Camada de apresentação: realiza qualquer conversão que a camada de aplicação possa
exigir para tornar os dados utilizáveis, a exemplo de compactação ou criptografia. Na
prática, esta camada não é amplamente utilizada, pois estas tarefas costumam ser
efetuadas na camada de aplicação do modelo OSI.
7. Camada de aplicação: representa a aplicação final, que se comunica e troca mensagens
com outras aplicações. As aplicações são responsáveis pelos serviços de rede vistos pelos
usuários finais.
Uma vez explicadas as atribuições de cada uma das camadas do modelo OSI, pode-se mostrar
como estão organizadas as camadas da arquitetua TCP/IP (e como suas camadas se
relacionam com o modelo OSI.
13
2.2 Arquitetura TCP/IP
O TCP/IP é uma família de protocolos usada nas comunicações de computador. Embora seu
nome seja uma composição de dois destes protocolos (o IP e o TCP), a família tem outros
protocolos, como o ARP, ICMP e UDP. Esta família de protocolos costuma ser chamada
também de pilha. Recebe este nome porque os dados transportados percorrem a pilha em
seqüência (cada camada só se comunica com outra camada imediatamente acima ou abaixo).
Feit (1993, p. 27) mostra como estão organizados os principais protocolos TCP/IP e como
eles se correspondem com o modelo OSI (figura 2). O autor, por conveniência, agrupa as
camadas física e de enlace (camadas 1 e 2), denominando-as “camadas inferiores” (lower
layers).
Figura 2 – Camadas TCP/IP e OSI.
Fonte: Feit (1993, p.27) (modificado)
As camadas do modelo TCP/IP são:
1. Camada de aplicação: é a aplicação final que faz uso da comunicação prestada pela rede.
A camada de aplicação do modelo TCP/IP abrange as camadas de aplicação, apresentação
e sessão do modelo OSI (figura 2). Feit compara os dois modelos desta forma pelo fato do
TCP/IP não implementar as camadas de apresentação e de sessão, cujas atribuições,
quando necessárias, costumam ser implementadas na camada de aplicação, o que justifica
esta organização.
2. Camada TCP e UDP: fornece serviços de transporte distintos para a camada de aplicação.
Sucintamente, com o protocolo TCP é possível transmitir dados de forma confiável e em
seqüência, enquanto com o protocolo UDP não há garantia de entrega nem de seqüência
de chegada.
14
3. Camada IP: realiza roteamento, encaminhando os segmentos TCP ou UDP recebidos para
o host apropriado. Fará o encaminhamento de acordo com a tecnologia utilizada na
camada inferior.
4. Camadas 1 e 2 (física e enlace): Esta camada é responsável por converter endereços
físicos (endereço de hardware como, por exemplo, MAC Address) para endereços IP e
vice-versa.
Para que os hosts que executam o TCP/IP possam se comunicar, é necessário que sejam
endereçados, o que é explicado na sessão a seguir.
2.2.1 Endereçamento IP
Para que possa existir a comunicação em rede, é necessário endereçar os nós que irão se
comunicar. Para tanto, deve-se criar uma regra segundo a qual serão atribuídos endereços
únicos aos nós. O endereçamento IP ocorre na camada de rede (equivalente ao nível 3 do
modelo OSI), o que pode ser conferido na figura 2.
Um endereço IP2 é formado por 32 bits (4 octetos), o que significa que a totalidade de
endereços disponíveis é de 2x1032. Um exemplo de endereço IP é mostrado na figura 3, em
notação decimal com pontos e, logo abaixo, seu valor binário (32 bits, com espaços para
facilitar a visualização de cada octeto).
Figura 3 – Exemplo de um endereço IP.
2.2.2 Endereçamento hierárquico
A fim de permitir que os datagramas IP sejam roteados entre diversas redes IP, os endereços
foram organizados em uma hierarquia. Segundo Peterson (2000, p. 683), o roteamento
hierárquico é uma forma de roteamento que considera a estrutura hierárquica do espaço de
endereçamento como base para tomar decisões de encaminhamento (tradução livre). Assim,
os endereços IP foram distribuídos em classes, cada uma com características exclusivas.
2 Trata-se aqui do IPv4, conforme escopo deste trabalho.
15
As classes nas quais os endereços IPs foram distribuídos inicialmente3 são apresentadas na
figura 4. Os primeiros bits do endereço identificam a qual classe uma determinada rede
pertence. Assim, confrontando o endereço IP exemplificado na figura 3 com as classes na
figura 4, pode-se concluir que o endereço IP pertence a uma rede classe C.
Figura 4 – Classes de endereços IP. Fonte: Tanenbaum (1997, p. 475)
Os primeiros bits do endereço (à esquerda) identificam o endereço da rede, enquanto os
demais bits identificam o host na rede. O que determina quantos bits são dedicados a
identificar a rede é a classe.
Tanenbaum (1997, p. 475) diz que “atualmente há dezenas de milhares de redes conectadas à
Internet, e esse número dobra a cada ano”. Ao longo do tempo, este fato acarretou a
possibilidade de esgotarem-se os endereços disponíveis para conexão de novas redes.
2.2.3 Sub-redes
As sub-redes foram concebidas para permitir que uma organização possa fazer divisões do seu
espaço de endereçamento para uso interno, criando assim redes IP menores e facilitando sua
administração. Por exemplo: uma empresa que tenha recebido um endereço classe C
200.193.3.0 (256 endereços), poderá segmentá-la em várias redes diferentes (para serem
usadas em LANs diferentes).
Um exemplo desta segmentação está na figura 5: a rede 200.193.3.0 foi segmentada em oito
sub-redes, com 32 endereços em cada uma.
3 Esta organização não é usada atualmente na Internet pelos motivos explicitados mais adiante.
16
Figura 5 – Exemplo de sub-rede.
Ainda na figura 5, três bits que originalmente seriam destinados ao host agora são a sub-rede
(“ID da sub-rede”). Para determinar quantos bits são usados pela sub-rede, usa-se a máscara
de sub-rede. Uma máscara tem o mesmo formato de um endereço IP (32 bits). Os bits da
máscara (figura 6) que correspondem aos bits da rede são definidos como 1, e os demais (bits
do host) são definidos como zero (FEIT, 1993, p. 94; TANENBAUM, 1997, p. 477).
Figura 6 – Máscara de sub-rede
Assim, para descobrir a qual sub-rede pertence um endereço IP desta rede (192.168.3.0),
examina-se os bits da sub-rede: se forem 000, é a primeira sub-rede; se forem 001, é a
segunda, e assim por diante.
Com a utilização do CIDR, descrito a seguir, o conceito de sub-redes e a organização
hierárquica ora apresentados não são mais usados.
2.2.4 Roteamento interdomínio sem classe (CIDR)
A hierarquia original de endereçamento IP, com o tempo, apresentou alguns problemas. O
primeiro é denominado ineficiência de atribuição de endereços4 (PETERSON, 2000, p. 316), o
que causou a rápida escassez de redes IP disponíveis para serem alocadas. Tanenbaum (1997,
p. 495) explica que as organizações, prevendo a expansão de suas próprias infra-estruturas,
solicitavam ao NIC (Network Information Center) redes classe B (com 65.536 endereços) em
vez de uma rede classe C (com apenas 256 endereços). O fato é que, para a maioria destas
organizações, uma rede classe C era muito pequena e uma rede classe B era muito grande.
O segundo problema denomina-se explosão das tabelas de roteamento. Tanenbaum (1993, p.
496) explica que, se houvesse meio milhão de redes classe C em uso no mundo, cada roteador
4 Do inglês address assignment inefficiency.
17
da Internet precisaria ter meio milhão de rotas. Isto implicaria melhorar os processadores,
memória e I/O dos roteadores, e a complexidade dos algoritmos relacionados à gerência
destas tabelas de roteamento também cresceria rapidamente.
Ante o exposto, para melhorar a eficiência de endereçamento, foi criado o CIDR: roteamento
interdomínio sem classe (classless inter-domain routing) (RFC 1519, setembro de 1993). A
idéia consiste em alocar redes em blocos contíguos e de tamanho variado. A vantagem disto é
que, por exemplo, o que antes seriam duas redes classe C (que exigiam duas rotas), agora são
um bloco com uma máscara de rede, implicando uma única rota. Por exemplo:
• Redes: 200.193.0.0 e 200.193.1.0 (ambas classe C) o Rotas antes do CIDR:
200.193.0.0/255.255.255.0 200.193.1.0/255.255.255.0
o Rotas depois do CIDR: 200.193.0.0/255.255.254.0 ou 200.193.0.0/23
No exemplo, a rota “depois do CIDR” está em notação decimal com pontos e, em seguida,
com máscara de bits. A máscara aplicada ao bloco exemplificado pode ser notada também
como o número de bits “1” da máscara: convertendo a máscara 255.255.254.0 para bits,
teremos 23 bits “1” e o restante “0”. Este número, 23, é a máscara de bits.
Um dos grandes benefícios proporcionados pelo CIDR é o agregamento de rotas. Com isso,
roteadores que antes precisavam ter várias rotas para redes IP contíguas agora passam a ter
apenas uma rota que agrega tantas redes quanto forem necessárias em uma única entrada na
tabela de roteamento. Assim, evita-se a explosão de tabelas de roteamento explicadas por
Tanenbaum (1993, p. 496).
2.3 Algoritmo de encaminhamento IP
O algoritmo de encaminhamento é aquele que decide qual caminho irá tomar um determinado
datagrama IP que chega ao roteador. Para tomar esta decisão, o roteador irá procurar uma rota
na tabela de roteamento adequada.
Antes de explicar o algoritmo propriamente dito, é necessário mostrar e explicar como é
composta uma tabela de roteamento (figura 7). Trata-se de uma lista com um prefixo de rede,
máscara e next hop5.
5 O termo foi mantido no original em inglês para assegurar consistência, pois há divergência na sua tradução.
18
Figura 7 – Exemplo de tabela de roteamento.
Fonte: Peterson (2000, p. 314)
Cada linha da tabela é uma rota e, com o prefixo de rede e a máscara, é possível determinar
quais são os endereços IP que existem na respectiva rede. O valor next hop é o endereço do
roteador ao qual o datagrama deverá ser encaminhado ou, ainda, a interface através da qual o
datagrama poderá ser entregue diretamente ao host de destino (se for o caso).
Ao receber um datagrama, o roteador com a tabela de roteamento (figura 7) irá testar cada
rota, fazendo uma comparação com o endereço IP de destino e cada uma das rotas, a fim de
determinar se há uma rota adequada para encaminhar o datagrama. O primeiro passo é uma
operação lógica AND bit-a-bit da máscara com o endereço IP de destino, o que irá resultar em
um endereço IP correspondente ao prefixo de rede. Se o prefixo de rede for o mesmo da rota
que está sendo testada, então a rota será aceita para este datagrama. Quando uma rota é
encontrada e o datagrama é encaminhado, o algoritmo é interrompido.
Para que o algoritmo funcione corretamente é necessário que as rotas estejam com suas
máscaras ordenadas, iniciando-se pelas máscaras mais específicas6 e terminando-se com as
mais abrangentes. Assim evita-se que uma rota mais abrangente sobreponha-se a uma mais
específica.
Peterson (2000, p. 315) demonstra o algoritmo de encaminhamento (forward) assim:
1 D = Endereço IP de destino 2 para cada rota da tabela de roteamento (prefixo, máscaraSubrede, nextHop) 3 D1 = máscaraSubrede & D // AND bit-a-bit 4 se D1 = prefixo 5 se nextHop é uma interface 6 entregue o datagrama diretamente ao host de destino 7 senão 8 entregue o datagrama a nextHop // o próximo roteador
O algoritmo irá percorrer a tabela de roteamento, examinando cada entrada nela existente. A
entrada do algoritmo é o endereço IP de destino (presume-se que as rotas já tenham sido
carregadas). Para cada rota da tabela será feito o seguinte teste:
6 Entende-se por máscara mais específica aquela que contém mais bits “1” e vice-versa.
19
1. Realiza-se uma operação AND bit-a-bit (bitwise AND) entre a máscara de rede e o
endereço IP de destino. O produto da operação é o prefixo de rede (linha 3).
2. O prefixo encontrado (etapa anterior) é igual ao prefixo da rota que está sendo testada?
a. Sim. O endereço IP de next hop ao qual será entregue o datagrama é uma
interface?
i. Sim. Entregue o datagrama diretamente ao host de destino.
ii. Não. Entregue o datagrama diretamente ao host identificado por next hop
(roteador intermediário).
b. Não. A rota é recusada. Se houverem mais rotas na tabela, testa a próxima rota.
Se o algoritmo terminar sem que nenhuma rota tenha sido testada com sucesso, conclui-se que
não há rota para o destino informado.
Um exemplo de execução do algoritmo para um datagrama cujo endereço IP de destino é
128.96.34.221, considerando-se a tabela de roteamento da figura 7, seria assim:
1. É feita a operação AND bit-a-bit entre a máscara da primeira rota e o endereço IP de
destino. O resultado é o prefixo de rede 128.96.34.128.
2. O prefixo de rede encontrado (128.96.34.128) é diferente do prefixo de rede da primeira
rota (128.96.34.0). A primeira rota não é aceita.
3. Reinicia-se o processo, agora com a segunda rota. A operação AND bit-a-bit entre a
máscara da segunda rota e o endereço IP de destino resulta no prefixo de rede
128.96.34.128.
4. O prefixo de rede encontrado (128.96.34.128) é igual ao prefixo de rede da segunda rota
(128.96.34.128). Portanto, a segunda rota é aceita.
5. Na segunda rota, next hop é uma interface. Portanto, o datagrama será entregue
diretamente ao host.
Neste exemplo só temos como destino uma rede remota (que é 128.96.33.0, máscara
255.255.255.0). Não seria possível rotear datagramas com outros endereços IP de destino
além dos que são abrangidos pelos prefixos existentes na tabela.
Uma rota freqüentemente utilizada chama-se rota default. É uma rota que será sempre aceita
ao ser testada pelo algoritmo de encaminhamento. Tem sub-rede 0.0.0.0 e máscara 0.0.0.0
20
que, por questão de ordenação de máscaras, ficará no final da tabela de roteamento. Qualquer
endereço IP que seja testado com esta máscara será aceito: o resultado do AND bit-a-bit de
qualquer endereço IP com máscara 0.0.0.0 será sempre 0.0.0.0. Portanto, o algoritmo de
encaminhamento aceitará esta rota e fará o encaminhamento do datagrama.
2.4 Descoberta de rotas
Peterson (2000, p. 282) explica que o roteamento é um problema de teoria de grafos. Isto
justifica-se pelo fato de que uma rede pode ser representada por vértices e arestas e, entre dois
pontos (origem e destino), há necessidade de determinar-se o caminho mais curto. Nesta
acepção, a figura 8 mostra a visualização de uma rede como um grafo, no qual os vértices
representam roteadores, e as arestas, enlaces. A cada aresta é atribuído um custo. Assim, o
problema se resume em encontrar uma árvore de espalhamento mínimo.
Figura 8 – Exemplo de rede como um grafo.
Fonte: Peterson (2000, p. 283)
São apresentadas, a seguir, a abordagem estática e duas abordagens dinâmicas, chamadas
vetor de distância (distance-vector) e estado de enlace (link-state).
2.4.1 Estático
A forma mais elementar de pôr uma rede em funcionamento é fazendo uso de rotas estáticas.
Peterson (2000, p. 283), Feit (1993, p. 141) e Tanenbaum (1997, p. 396) explicam que
bastaria determinar os caminhos de menor custo e configurá-los manualmente em cada
roteador. No entanto, esta abordagem apresenta vários problemas:
• Não lida com falhas dos enlaces ou dos nós.
• Não considera a possibilidade de nós ou enlaces serem adicionados.
• Implica não haver alteração dos custos dos enlaces.
21
Estas desvantagens explicam por que esta abordagem não se ajusta a mudanças na rede. Por
conta disso, Tanenbaum (1997, p. 396) descreve-a como roteamento não-adaptativo.
Para contornar estas dificuldades, adotam-se protocolos de roteamento, que provêem uma
forma distribuída e dinâmica de encontrar o caminho de menor custo, mudança de nós ou
enlaces e mudanças nos custos. Peterson (2000, p. 283) afirma que ser distribuído é
característica imprescindível de um bom protocolo de roteamento.
2.4.2 Vetor de distância
O nome deste algoritmo remete à idéia de lidar com a distância, o que é feito levando-se em
conta o custo dos enlaces. Consiste em armazenar, em um vetor, o custo para se chegar a
todos os demais nós da rede. É necessário que cada roteador conheça o custo do enlace para
cada roteador ao qual está diretamente conectado (usualmente este custo é 1 e costuma ser
relacionado com a quantidade de hops). Um enlace que não está funcionando recebe o valor
de custo infinito.
Considere-se, para fins de exemplo, a rede que consta na figura 9. O roteador A tem como
tabela de roteamento inicial a da figura 9 (a), a qual apresenta custo inicial 1 para os vizinhos
imediatos7 e custo infinito para chegar aos demais destinos.
Figura 9 – (a) Roteamento com vetor de distância: um exemplo de rede. (b) Tabela de roteamento incial em A.
Fonte: Peterson (2000, p. 284 e 285)
O próximo passo é cada roteador enviar, a seus vizinhos imediatos, a sua própria lista de
distâncias. O roteador A, por exemplo, enviaria para os roteadores B, C, E e F a tabela da
figura 9 (b).
7 Conforme definido por Peterson (2000, p. 284), immediate neighbors são roteadores que podem ser acessados diretamente sem passar por outros roteadores intermediários.
22
Quando um roteador recebe a lista de distâncias de outro roteador, a distância para cada um
dos destinos é comparada com as distâncias que já estão na sua própria lista. Assim, o
roteador A recebe de B a informação de que B pode chegar a C com custo 1, ou seja, A chega
a C com custo 2. Como o custo 2 é maior que o atualmente na lista de A, a informação é
ignorada. Por outro lado, quando recebe a informação de que C pode chegar a D com custo 1,
A conclui que pode chegar a D com custo 2. Como 2 é menor que infinito, o valor atualmente
em sua lista, a rota é aceita e inserida na tabela de roteamento.
O processo de troca de mensagens entre os roteadores com informação sobre rotas até que
todos tenham informações consistentes é chamado de convergência (PETERSON, 2000, p.
286). Concluído todo o processo, a tabela de roteamento final em A é mostrada na figura 10.
Figura 10 – Tabela de roteamento final em A. Fonte: Peterson (2000, p. 285) (modificado)
Os roteadores têm sempre uma visão parcial da rede: o roteador A não sabe qual será o
caminho completo para chegar até G, mas apenas o próximo roteador, que é F. É
característica de um algoritmo distribuído (como este) que todos os roteadores atingem uma
visão consistente da rede (ao término da convergência) mas sem um ponto centralizador.
Há duas circunstâncias diferentes em que um roteador pode decidir enviar sua lista aos
vizinhos imediatos. A primeira é a da atualização periódica, em que o roteador envia
atualizações mesmo que a lista de distâncias permaneça inalterada. Desta forma, os roteadores
vizinhos sabem que o originário continua funcionando, bem como se, por acaso, algum enlace
parou de funcionar. A segunda é baseada em disparadores (triggers), ou seja, um roteador
atualiza sua tabela de roteamento assim que recebe uma atualização.
Quando um nó falha, seus vizinhos normalmente percebem a mudança e logo propagam
novas listas de distâncias para seus vizinhos. A detecção da falha de um nó pode ser feita de
duas maneiras. Na primeira, os nós ficam continuamente enviando um pacote de controle para
23
seus vizinhos e aguardando respostas de confirmação. A ausência de resposta significa uma
falha. Na segunda maneira, um nó é considerado falho quando não se receberam dele novas
listas de distâncias nos últimos ciclos de atualização.
2.4.2.1 O problema da contagem para o infinito
Este problema pode eventualmente acontecer conforme o momento em que a detecção de
falha acontece. Por exemplo: se o enlace entre A e E (figura 9) pára de funcionar, A irá
divulgar distância infinita para E (inacessível), mas B e C irão divulgar distância de 2 hops
para E. Dependendo do exato momento em que os eventos acontecem, o nó B, ao receber a
informação de que C pode chegar a E em 2 hops, conclui que pode chegar a E em 3 hops e
repassa isso para A. Então, o nó A conclui que pode chegar a E em em 4 hops e repassa isso
para C. O nó C conclui que pode chegar a E em 5 hops, e assim por diante. O ciclo termina
somente quando as distâncias aingem um valor que seja considerado infinito. No entanto,
enquanto isso não acontece, nenhum dos nós sabe que E está inalcançável e a rede não
estabiliza.
Há duas soluções possíveis para o problema: (i) horizonte dividido (split horizon) e (ii)
horizonte dividido com poison-reverse (split horizon with poison-reverse).
A solução com horizonte dividido consiste em não propagar de volta rotas para o nó de onde
elas vieram. Os nós precisam armazenar na sua lista de distâncias o nó que informou a rota
utilizada. Assim, se B tem a rota «E, 2, A» (respectivamente destino, distância, next hop) em
sua lista de distâncias, ao propagar sua lista para A não irá repassar esta rota, pois ela veio de
A.
A solução horizonte dividido com poison-reverse, ao contrário, envia a rota de volta à sua
origem, mas com valor negativo na rota para assegurar que A não tentará chegar a E passando
por B.
2.4.2.2 Restrições do vetor de distância
Peterson (2000, p. 288) afirma que, ainda que se faça uso das técnicas citadas (horizonte
dividido e horizonte dividido com poison-reverse), a convergência é mais lenta do que
usando-se o algoritmo de estado de enlace, cuja vantagem-chave é justamente a velocidade de
convergência.
24
Além disso, as técnicas abordadas para evitar a contagem para o infinito são úteis apenas para
loops que envolvem dois nós. Caso envolvam mais de dois nós, medidas mais drásticas são
necessárias.
2.4.2.3 RIP (Routing Information Protocol)
O RIP é uma das implementações mais amplamente utilizadas do algoritmo de vetor de
distância. Roteadores executando RIP enviam suas rotas a cada 30 segundos e também
enviam uma mensagem de atualização sempre que uma atualização de outro roteador cause
mudanças na sua tabela de roteamento.
Embora seja possível adotar diferentes métricas para considerar os custos dos enlaces, o RIP
aplica a abordagem mais simples, que é considerar todos os enlaces como sendo de custo 1.
Como conseqüência, o RIP determinará sempre o caminho com menos hops. O número
máximo de hops é 15, e um caminho com 16 hops será considerado infinito. Assim, o RIP
acaba restringindo-se também a redes relativamente pequenas.
2.4.3 Estado de enlace
A condição inicial para o roteamento com estado de enlace é similar ao roteamento com vetor
de distância: cada roteador conhece o estado do enlace com cada um dos seus vizinhos
(funcional ou fora do ar) e o custo de cada enlace. O princípio do roteamento com estado de
enlace consiste em propagar o estado de seus enlaces para todos os nós da rede, de tal forma
que cada um deles, sozinho, seja capaz de fazer um mapa completo da rede. Dessa forma é
possível determinar o caminho mais curto para qualquer ponto da rede, usando-se algum
algoritmo para determinar caminhos mínimos em grafos.
Ante o exposto, o ponto crucial para o funcionamento adequado do roteamento por estado de
enlace consiste em transmitir, de forma confiável, as informações de roteamento para todos os
nós. Esta é uma tarefa difícil (TANENBAUM, 1997, p. 413; PETERSON, 2000, p. 293), pois, à
medida que os LSPs são distribuídos, as rotas nos nós são alteradas e, eventualmente,
diferentes roteadores com diferentes versões da topologia poderão causar inconsistências,
loops, hosts inalcançáveis, etc.
2.4.3.1 Propagação de informação de roteamento
A troca de informações de roteamento entre os roteadores é feita com intercâmbio de pacotes
de estado de enlace (link-state packets) (TANENBAUM, 1997, p. 413; PETERSON, 2000, p.
25
293). O algoritmo através do qual estes pacotes são disseminados na rede chama-se flooding
ou reliable flooding8.
Um pacote de estado de enlace (doravante chamado apenas de LSP – link-state packet)
carrega as seguintes informações:
• o identificador do nó que criou o LSP;
• uma lista de todos os vizinhos do nó, com o custo do enlace para cada um deles;
• um número de seqüência;
• um “tempo de vida” (time to live) para o LSP.
Uma rede e os LSPs gerados pelos nós são exemplificados na figura 11.
Figura 11 – (a) Uma rede. (b) Os pacotes de estado de enlace para esta rede.
Para que a transmissão de LSPs seja confiável entre roteadores adjacentes, adota-se uma
técnica de confirmação e, quando necessário, retransmissão.
Um LSP é enviado por um nó a todos os seus vizinhos. Um nó X, se recebe um LSP de Y, irá
repassá-los aos seus vizinhos, exceto de volta a Y. O número de seqüência é usado para
identificar o quão recente é um LSP: se um roteador recebe dois LSP do mesmo roteador de
origem, irá considerar apenas aquele que tem o número de seqüência maior (mais recente).
Caso sejam iguais, considera um e descarta o outro (que é idêntico ao primeiro).
Cada nó, ao repassar adiante um LSP, decrementa o valor do tempo de vida (time to live, ou
TTL). Isso assegura que um LSP não permanecerá indefinidamente na rede, sendo eliminado
da rede quando seu valor chega a zero. Além disso, descartando cópias de LSPs da mesma
origem com mesmo número de seqüência, evita-se a propagação de LSPs repetidos.
8 Peterson (2000, p. 293) define disseminação confiável (reliable flooding) como o processo para garantir que todos os nós da rede receberão informação sobre o estado dos enlaces de todos os demais nós.
26
2.4.3.2 Determinando a rota a ser adotada
Uma vez que os nós da rede já tenham trocado todos os respectivos LSPs, todos os nós são
capazes de criar um grafo completo da rede. Assim, é possível aplicar-se um algoritmo de
busca de caminhos mínimos (por exemplo, o algoritmo SPF de Dijkstra) para calcular o
caminho mais curto para qualquer destino que se deseje atingir: os roteadores são os vértices
de um grafo, e os enlaces são as arestas com seus respectivos custos.
2.4.3.3 Open Shortest Path First (OSPF)
O OSPF é uma implementação do algoritmo de roteamento com estado de enlace amplamente
utilizada. É um padrão aberto, daí o termo Open no nome do protocolo.
São características do OSPF:
• Hierarquia adicional: eventualmente, os nós podem receber mais LSPs do que são capazes
de armazenar. Para contornar isso, as redes podem ser segmentadas em áreas, de tal forma
que um nó não precisa saber exatamente como chegar a uma determinada rede, mas
apenas à área onde ela se encontra.
• Autenticação dos LSP: graças a isto, a rede não fica sujeita a LSPs gerados por nós mal
configurados ou LSPs gerados com o propósito de prejudicar a rede (a disseminação de
informações erradas pode causar um colapso na rede). Os métodos de autenticação podem
ser os mais variados, e podem ser diferentes em diferentes áreas.
• Balanceamento de carga: caso haja mais de uma rota com o mesmo custo, o tráfego será
distribuído nestas rotas.
Explicados os funcionamentos dos protocolos de roteamento que se pretende usar no
simulador, serão dadas algumas definições a respeito da simulação computacional e será
explicado de que forma ela será usada para realizar a simulação de roteamento.
3 SIMULAÇÃO
A simulação computacional de sistemas (a partir daqui chamada apenas simulação9) consiste
no emprego de técnicas matemáticas em computadores digitais com o propósito de imitar um
processo ou operação do mundo real (FREITAS, 2001, p. 3). Para que seja possível simular, é
necessário criar um modelo computacional que corresponda à situação real que se deseja
simular.
3.1 Vantagens e desvantagens da simulação
3.1.1 Vantagens
A idéia de construir um simulador para apoiar o ensino e aprendizado do roteamento IP
recebe respaldo nas vantagens citadas por Freitas (2001, p. 3), quando diz que a simulação é
usada para “descrever o comportamento do sistema”. Também ratifica a vantagem de
empregar um simulador quando afirma ser possível fazer uso de animações, permitindo que se
visualize o comportamento dos sistemas durante as simulações. Estas animações podem ser de
grande valia no simulador de roteamento, evidenciando em um diagrama o trajeto percorrido
por uma mensagem desde sua origem até seu destino.
Uma das mais fortes razões que justificam a criação do simulador para tal propósito é o caso
em que “experimentar o sistema real é dispensioso” (FREITAS, 2001, p. 5). Se, para uma
turma de 20 acadêmicos, fosse entregue quatro roteadores a cada um deles, seria necessário
dispor de 80 roteadores por turma (não se levou em conta ainda o espaço físico necessário,
cabeamento, energia elétrica e outros requisitos). E, ainda assim, a experiência seria limitada à
quantidade disponibilizada por aluno.
Ainda poderia indagar-se quanto ao uso de modelos analíticos em vez de modelos de
simulação. Freitas (2001, p. 11) defende a simulação afirmando que é, geralmente, mais fácil
de aplicar do que os modelos analíticos. Além disso, os modelos analíticos requerem um
número muito grande de simplificações para torná-los matematicamente tratáveis.
O simulador de roteamento encontra amparo em mais uma vantagem relevante: “um estudo de
simulação costuma mostrar como um sistema realmente opera, em oposição à maneira com
que todos pensam que ele opera” (FREITAS, 2001, p. 12). Assim, dúvidas e confusões dos
9 Freitas (2001, p. 3) afirma que hoje (à época em que o autor escreve) simulação é praticamente sinônimo de simulação computacional digital, na qual um modelo computacional é executado.
28
acadêmicos a respeito de como o roteamento funciona poderão ser resolvidas por meio de
experiências com o simulador.
3.1.2 Desvantagens
A simulação, segundo Freitas (2001, p. 12), apresenta três desvantagens:
• A construção de modelos requer treinamento especial. São necessários o conhecimento e a
experiência sobre o sistema a ser simulado por parte da pessoa que irá construir o modelo,
caso contrário, os resultados serão insatisfatórios (pobres ou mesmo inconsistentes).
• Os resultados são, muitas vezes, difíceis de interpretar.
• É difícil validar um modelo de simulação e, por conseqüência, os resultados obtidos com
experimentos nele realizados.
No simulador de roteamento que se propõe fazer, as desvantagens não inviabilizam o uso da
simulação, visto que:
• Almeja-se a compreensão do roteamento em uma rede e não a avaliação de seu
desempenho ou diagnóstico. Assim, o problema é simplificado no tocante a precisão de
valores (principalmente temporais) trabalhados no simulador.
• Os resultados serão apresentados ao usuário do simulador de forma estrategicamente
amigável.
• O resultado de uma simulação serão as rotas determinadas para uma dada rede, o que pode
ser verificado manualmente. Portanto, há uma relativa facilidade na sua interpretação.
3.2 Estrutura de um simulador típico
Aqui são apresentadas as diversas partes e conceitos usados para construir um simulador. O
simulador, por sua vez, abrange um escopo bem deliminado de um sistema, o qual é objeto da
simulação. Por exemplo, pode-se simular a operação de um caixa de supermercado, caso em
que temos entradas (pessoas chegando para serem atendidas) e saídas (pessoas saindo com
suas compras). Neste caso, pode-se realizar várias medições: tempo médio de atendimento de
cada cliente, quantidade média e máxima de clientes na fila, tempo máximo de espera para ser
atendido, etc.
29
3.2.1 Variáveis de estado
São variáveis cujos valores definem o estado do sistema simulado. Os valores destas variáveis
armazenam justamente o estado do sistema, de forma que a simulação pode ser interrompida e
retomada caso estes valores ainda estejam disponíveis.
Exemplo de variável de estado: quantidade de pessoas na fila do caixa aguardando
atendimento.
3.2.2 Eventos
São os acontecimentos (programados ou não) que ocorrem ao longo da simulação,
modificando o estado do sistema. Mudanças no estado do sistema são causadas sempre pela
ocorrência de um evento.
São eventos, por exemplo, a chegada de pessoas ao caixa, o início do atendimento e a saída da
pessoa.
3.2.3 Entidades e atributos
A entidade pode ser classificada como estática ou dinâmica. A entidade estática irá servir
outras entidades e pode representar, por exemplo, um balcão de atendimento, que levará
algum tempo atendendo clientes ou uma máquina, que processará peças. Já uma entidade
dinâmica move-se através do sistema (do modelo que está sendo simulado), que pode ser, por
exemplo, os clientes em um balcão de atendimento ou peças a serem processadas por uma
máquina.
As entidades têm características próprias que são individuais, as quais são armazenadas em
atributos. Diversas entidades semelhantes, as quais têm os mesmos atributos, são
diferenciadas entre si pelos valores destes atributos. Um atributo pode armazenar informações
como, por exemplo, o nome de uma peça, um número seqüencial, um código ou outras
informações que forem pertinentes e interessantes à simulação.
Os atributos podem ser usados para gerar estatísticas que se deseje obter. Por exemplo, se é
interessante determinar o tempo médio de permanência das peças no sistema em simulação, a
entidade deverá armazenar o momento de chegada ao modelo (do relógio de simulação), para
que na sua saída do sistema possa calcular a diferença de tempo no momento de sua saída
(tempo de permanência) e que isso seja somado a uma variável de tempo total de
permanência, além de incrementar a quantidade de peças que deixaram o sistema. Assim, é
30
possível determinar o tempo médio de permanência das peças no sistema dividindo-se o
tempo total pelo contador de peças.
3.2.4 Recursos e fila de recursos
É uma entidade estática que presta serviços às entidades dinâmicas. Tem uma capacidade, ou
seja, é capaz de atender uma ou mais entidades por vez. Se porventura a entidade estática não
for capaz de atender uma entidade dinâmica que está chegando, ela deverá aguardar em uma
fila de espera.
As filas, por sua vez, podem adotar políticas de tratamento diferentes, como, por exemplo,
FIFO (first in, first out), em que o primeiro a chegar será o primeiro a ser atendido (política
mais comum). A fila também apresenta uma capacidade limitada, e uma vez esgotada poderá
descartar a entidade ou encaminhá-la a outro recurso ou mesmo outra fila.
3.2.5 Tempo real e tempo de simulação
Uma distinção importante em simulação é do tempo real e do tempo de simulação.
Dependendo do que está sendo simulado (riqueza de detalhes, unidade de tempo, etc.), o
tempo de simulação poderá ser maior ou menor do que o tempo real. Em outras palavras,
simular três segundos de um determinado processo pode levar 15 minutos ou, ao contrário,
simular 15 minutos de um outro processo poderá levar menos de um segundo.
3.2.6 Mecanismos de avanço do tempo
Para avançar o tempo de simulação pode-se adotar dois algoritmos distintos: avanço do tempo
para o próximo evento e avanço com incremento fixo (LAW, 2000, p. 7; FREITAS, 2001, p.
68). O primeiro funciona avançando o relógio de simulação diretamente ao horário em que
ocorrerá o próximo evento. O segundo incrementa a unidade do relógio um a um,
independentemente de haver ou não um evento a ser executado no novo momento, e pode ser
entendido como uma aproximação para simulação contínua.
O algoritmo mais utilizado nas ferramentas comerciais de simulação e por simulações,
segundo Law (2000, p. 7) e Freitas (2001, p. 68), é o de avanço para o próximo evento, o qual
será adotado neste simulador de roteamento.
Os eventos são armazenados em uma estrutura denominada “lista de eventos futuros” (LEF),
a qual deverá mantê-los em ordem de tempo de execução. A finalidade disso é permitir que os
31
eventos sejam executados em ordem de tempo e que o relógio de simulação possa ser
avançado para o horário do próximo evento.
3.3 Simulação discreta e simulação contínua
Uma diferenciação sobre dois tipos possíveis de modelos de simulação diz respeito à forma
como os valores das variáveis de estado variam no modelo. Um modelo de simulação leva em
conta o tempo, registrando um valor numérico correspondente ao momento em que um dado
evento ocorre.
Nos modelos discretos (“modelos de mudança discreta” é o termo apropriado), as variáveis de
estado sofrem alteração apenas em momentos pontuais (quantidade contável de eventos).
Assim, um exemplo de gráfico que mostra o comportamento de uma variável discreta é
ilustrado na figura 12.
Figura 12 – Mudanças de estado em modelos discretos.
Fonte: Freitas (2001, p. 64)
Já nos modelos contínuos (“modelos de mudança contínua”) o valor da variável se modifica
continuamente no tempo (quantidade infinita de eventos), e não apenas em momentos
pontuais. Um exemplo do comportamento de uma variável contínua é mostrado na figura 13.
Freitas (2001, p. 64) explica que o nível duma caixa d’água que é esvaziada é um caso de
variável contínua, pois o nível d’água varia continuamente ao longo do tempo.
32
Figura 13 – Mudanças de estado em modelos contínuos.
Fonte: Freitas (2001, p. 65)
Alguns modelos contínuos podem ser discretizados, ou seja, tratados como modelos discretos,
após algumas suposições realizadas sobre as variáveis de estado. Também é possível fazer um
modelo misto, no qual uma variável podem variar ora de forma contínua, ora de forma
discreta.
No simulador de roteamento será adotada a simulação discreta, já que os elementos de rede
que serão simulados sofrem mudanças de estado em quantidade finita. Um roteador, por
exemplo, trocará uma determinada quantidade de mensagens até a conclusão da convergência,
e então a rede estará estabilizada. Há, portanto, uma quantidade finita de eventos que mudarão
o estado de um roteador até a conclusão do processo de convergência.
3.4 Funcionamento de um simulador
Uma vez que se tem os elementos de simulação ora descritos, resta descrever como eles
interagem para proporcionar uma simulação. Basicamente, a simulação ocorre com três tipos
de eventos: Evento Chegada, Evento Saída e Evento Fim da Simulação.
3.4.1 Evento Chegada
Trata-se do evento de chegada de uma entidade no modelo de simulação. Esta entidade pode
ser, por exemplo, uma pessoa que chega à fila do caixa do supermercado. Compete a este
evento realizar o seguinte:
1. Guardar, em um atributo da entidade, o momento em que a entidade chegou ao sistema.
Assim que a entidade deixar o sistema, será possível determinar quanto tempo ela
permaneceu no sistema.
2. Verificar se o recurso que a entidade irá utilizar está disponível. Caso esteja livre, a
entidade deverá ocupar imediatamente o recurso e um evento para tratar o término do uso
33
do recurso deverá ser criado e inserido na LEF. Caso esteja ocupado, a entidade será
colocada em uma fila de espera.
3. Criar o evento de chegada da próxima entidade e colocá-lo na LEF.
3.4.2 Evento Saída
Assim que a entidade termina de utilizar o recurso, as ações deste tipo de evento deverão ser
realizadas:
1. Incrementar o contador de entidades atendidas.
2. Calcular o tempo de permanência da entidade no sistema, subtraindo do horário atual
(tempo de simulação) o horário de chegada da entidade no sistema.
3. Se houver alguma entidade na fila, aguardando para utilizar o recurso, alocar o recurso
para esta entidade e inserir na LEF um evento para tratar o término do uso do recurso por
esta entidade. Se a fila estiver vazia, o recurso é definido como “livre”.
3.4.3 Evento Fim da Simulação
Quando a simulação for concluída, este evento deverá ser executado, o qual irá calcular
estatísticas que tenham sido programadas no modelo e compor um relatório final para o
usuário.
3.4.4 Avanço do relógio de simulação
Conforme mencionado na seção 3.2.6, o relógio de simulação é avançado diretamente ao
horário de simulação do próximo evento a ser executado. Para tanto, os eventos que são
armazenados na LEF (lista de eventos futuros) devem estar ordenados por horário de
ocorrência, a fim de que o relógio de simulação seja avançado para o evento mais iminente.
Para tanto, os eventos devem ser inseridos na LEF já de forma ordenada.
Assim, a execução do simulador ocorre desta forma:
1. Retirar da LEF o próximo evento a ser executado.
2. Definir o relógio do simulador com o horário de execução deste evento.
3. Executar o evento retirado da LEF.
O algoritmo repete-se até que (i) não haja mais eventos na LEF ou (ii) tenha sido atingido o
horário de simulação limite (neste caso, mesmo havendo mais eventos na LEF, termina a
simulação).
34
3.5 Simuladores de rede já existentes
Uma busca realizada na Internet por simuladores de rede retorna muitos resultados. Foram
escolhidos dois que, de alguma forma, podem atender a necessidade de simular roteamento,
com ressalvas ou não.
3.5.1 cnet
O cnet é um simulador de rede que, em relação ao modelo OSI, fornece a camada de
aplicação e a camada física. Assim, é possível escrever protocolos (em linguagem ANSI-C) e
experimentá-los com esta ferramenta. O cnet permite gerar erros na camada física, os quais
devem ser tratados pelas camadas superiores. Na ferramenta, que é visual, é possível dispor
nós (hosts ou roteadores) e conectá-los com enlaces ponto-a-ponto ou segmentos Ethernet.
Entre as camadas fornecidas pelo cnet é possível implementar tantas quantas forem
necessárias. Para uma rede ponto-a-ponto (com dois nós), por exemplo, uma única camada
intermediária (de enlace) seria suficiente para simplesmente transmitir quadros de um lado a
outro de forma confiável. Já para uma rede maior, seria necessário implementar uma camada
de rede, para poder lidar com roteamento, controle de congestionamento, etc.
Para escrever estes protocolos é usada uma linguagem orientada a eventos que, segundo a
documentação do cnet, é similar a escrever protocolos para o kernel de um sistema
operacional.
O cnet oferece uma infra-estrutura para simular protocolos que se deseje escrever e trabalha
com a pilha de protocolos inteira. Ao contrário do simulador que se propõe construir, não
consta nenhuma facilidade para simular o roteamento IP com o cnet.
3.5.1.1 Exemplos de utilização do cnet
A figura 14 mostra um caso típico de simulação com o cnet: dois nós ligados com um enlace
ponto-a-ponto. A simulação, que está em andamento, pode ser interrompida e continuada
passo-a-passo.
35
Figura 14 – Simulação típica com dois nós.
A Figura 15 mostra um barramento Ethernet representado no cnet, novidade da versão 2. É
possível coletar estatísticas Ethernet, conforme demonstrado na mesma figura.
Figura 15 – Um barramento Ethernet no cnet.
A Figura 16 mostra uma topologia gerada aleatoriamente pelo cnet, com um misto de nós com
diferentes sistemas operacionais, já interconectados.
36
Figura 16 – Exemplo de uma rede gerada aleatoriamente.
3.5.2 Network Simulator (ns)
O ns é um simulador orientado a objetos, usa simulação discreta e é escrito em C++ e OTcl10.
Seu propósito é simular redes locais e redes de longa distância. Implementa a camada de
transporte (com TCP e UDP), camada de aplicação (com vários protocolos, como telnet, ftp,
web, etc.), camada de rede (IP) e camada de enlace (Ethernet e várias outras). Entretanto, a
entrada de dados no simulador é feita usando-se scripts OTcl e, para tanto, é necessário
adquirir alguma experiência com esta linguagem.
Quando o ns é associado com o “nam” (network animator), que é um ambiente que faz
animações gráficas da rede simulada, e o nam Graphical Editor (interface gráfica para entrada
de dados no simulador), acaba tornando-o um pouco mais viável para seu uso em laboratório
com estudantes de graduação. Ainda assim, a documentação diz que estudantes poderão fazer,
sem conhecer a linguagem OTcl, apenas algumas tarefas simples no simulador.
Conforme consta na documentação do ns, trata-se de um simulador complexo para o usuário
iniciante (no uso desta ferramenta). Isso faz com que o ns seja pouco prático para uso no
ambiente de ensino de roteamento, pois haveria de se dedicar um considerável tempo extra
para aprender a usar o simulador.
10 OTcl consiste na linguagem Tcl estendida com recursos de orientação a objetos.
37
3.6 Simulação de uma rede
Uma vez descritos os componentes de um simulador, define-se agora como os elementos de
uma rede podem ser mapeados para um modelo de simulação.
3.6.1 Elementos básicos
Conforme descrito na seção 3.2, serão usados elementos básicos de simulação que, por fim,
servirão de base para os componentes da rede a serem simulados. São estes elementos
básicos:
• Filas – representam buffers de dados em interfaces nos roteadores e nos hosts.
• Recursos – representam elementos que realizam alguma tarefa consumindo tempo (por
exemplo, o mecanismo de transmissão em um enlace e o processador de roteamento).
• Blocos – representam unidades lógicas onde datagramas entram e de onde saem (por
exemplo, um roteador e um enlace).
• Entidades – representam os datagramas que circularão na rede simulada.
• Eventos – são responsáveis pela dinâmica da simulação, ao representar as ações
executadas em instantes pontuais (por exemplo, chegada de datagrama, liberação de
enlace).
3.6.2 Componentes do simulador de rede
Aqui são detalhados os componentes de rede e como eles são implementados no simulador.
Por questão de projeto, algumas restrições que não refletem a realidade podem ser adotadas na
modelagem dos componentes.
3.6.2.1 Interface
É um bloco dotado de fila de saída que representa uma interface (por exemplo, Ethernet) de
um dispositivo. A fila da interface representa o buffer que as interfaces têm. A capacidade do
recurso é 1, ou seja, processa apenas uma mensagem por vez. A capacidade da fila do recurso
é dada em bytes. Interfaces são ligadas a um host (computador ou roteador) e a um enlace.
38
Figura 17 – Representação de uma Interface.
A interface não tem uma fila de entrada (no sentido do enlace para o host). Datagramas
oriundos do enlace atravessam o recurso diretamente, chegando ao host sem consumir
recursos ou tempo.
3.6.2.2 Computador
Um computador é um nó que tem sempre apenas uma interface11. O Computador será capaz
de gerar datagramas com destinos a serem definidos pelo usuário, a fim de simular o
roteamento na rede diagramada pelo usuário. O Computador poderá também receber
datagramas, os quais serão contabilizados (para fins de estatísticas) e descartados.
3.6.2.3 Roteador
Embora apresente algumas semelhanças com Computador, difere por geralmente ter mais de
uma interface e, além disso, uma única fila de entrada (cuja capacidade é dada em bytes).
Dados recebidos em quaisquer interfaces são encaminhadas à fila de entrada (figura 18). Seu
processamento será a decisão de roteamento.
Figura 18 – Representação de um Roteador.
11 Embora seja possível, na realidade, instalar várias interfaces de rede em um computador, neste simulador assume-se que terá sempre apenas uma interface.
39
3.6.2.4 Datagrama
É uma entidade dinâmica que irá circular no modelo de simulação. Poderá carregar dados de
usuário (datagramas gerados por computadores) ou dados de protocolos (RIP e OSPF). Terá
tamanho variado, o qual irá influenciar diretamente na ocupação de recursos ao longo da
simulação.
Na hipótese de um datagrama ser encaminhado a uma interface cuja fila não tenha espaço
para este datagrama, ele será descartado.
3.6.2.5 Enlace
É um bloco com recurso sem fila que representa um meio físico. Tem taxa de transmissão,
atraso de propagação e taxa de erros. O tempo de transmissão é o tempo durante o qual um
enlace fica ocupado transmitindo um datagrama, definido pelo atraso de propagação, tamanho
do datagrama e taxa de transmissão. Tem como estado livre ou ocupado.
Tem duas especializações, que são os enlaces ponto-a-ponto e barramento (por exemplo,
Ethernet). Ambos são half-duplex.
3.6.2.6 Protocolos de roteamento
São funcionalidades a serem agregadas de forma modular ao componente Roteador, com a
finalidade de executar os protocolos propostos (RIP e OSPF).
3.6.3 Avanço do tempo
Neste simulador serão implementados eventos nulos (gerados periodicamente) cujo propósito
é permitir que uma interface visual mostre a movimentação de datagramas ao longo da rede
simulada. Visa também evitar que a simulação termine em momentos em que não haja
datagramas na rede, pois a lista de eventos estaria vazia, causando o término da simulação.
4 FRAMEWORK DE SIMULAÇÃO DE ROTEAMENTO IP
Os elementos de rede a serem simulados foram mapeados em elementos de simulação (blocos
e recursos). Neste capítulo serão abordados detalhes a respeito de como estes mapeamentos
foram feitos e deram origem ao framework de simulação de roteamento IP.
4.1 Organização geral do framework
O framework de simulação de roteamento foi implementado na linguagem Java e está
organizado em dois pacotes:
• org.cvarda.simulacao: é um framework de simulação discreta, com classes genéricas
para implementação de simuladores discretos. Para implementar um simulador, basta
especializar as classes fornecidas neste pacote. A implementação destas classes baseia-
se na forma de funcionamento de um simulador discreto, especificado na seção
“Estrutura de um simulador típico” (página 28).
• org.cvarda.siroip: este é o framework de simulação de roteamento IP, cujo
detalhamento será feito logo adiante.
A vantagem da separação das estruturas, conforme apresentado, é que o framework de
simulação discreta abstrai do simulador de roteamento tarefas comuns a simuladores
discretos, como, por exemplo, a organização de eventos na lista de eventos futuros. Desta
forma, o simulador de roteamento implementa, especificamente, detalhes inerentes à
simulação de roteamento.
4.2 Visão geral dos elementos do framework de simulação de roteamento
Os elementos que estão disponíveis para um usuário do framework são as classes Computador,
Roteador, MeioFisico e InterfaceRede. Computador e Roteador são, essencialmente, hosts
na rede, o que significa que não têm diferença na prática. Entretanto, para o framework, o
computador é um host que não faz encaminhamento de datagramas e possui apenas uma
interface de rede (InterfaceRede). Já o roteador pode possuir n interfaces de rede e faz
encaminhamento entre interfaces de rede.
O MeioFisico é um recurso que representa um enlace ponto-a-ponto. Duas interfaces de rede
estão ligadas por meio de um MeioFisico. O MeioFisico pode ter sua taxa de transmissão
(em bits) especificada no momento em que o recurso é criado.
41
A qualquer roteador pode ser “plugado” um objeto que implemente a interface
ModuloRoteamento. Esta interface é implementada pela classe ModuloRip, que então permite
que os roteadores troquem mensagens RIP e atualizem suas tabelas de rotas. Outros
protocolos (OSPF, por exemplo) podem ser escritos e “plugados” ao simulador, bastando
implementar a interface ModuloRoteamento.
As próximas seções mostram informações mais detalhadas sobre os elementos do simulador.
4.2.1 A interface de rede
O bloco que é comum a todos os computadores e roteadores na rede é a interface (ou “placa”)
de rede. Neste framework, uma interface de rede é composta de um buffer, que armazena os
datagramas a serem enviados para a rede, e uma configuração IP (um objeto ConfigIP, que
armazena o endereço IP e máscara de rede).
No contexto deste simulador, uma interface de rede sempre possui uma configuração IP
(endereço e máscara).
No simulador, a conexão entre interfaces de rede é feita pelo compartilhamento de um mesmo
recurso, o MeioFisico (descrito adiante).
4.2.2 Computadores e Roteadores
Os computadores e roteadores têm algumas características comuns que foram generalizadas
na classe Host, a qual é especializada em Computador e Roteador (detalhados no diagrama de
classes do simulador, anexo dois). Estas características comuns consistem em:
• Uma lista (List) para armazenar referências aos objetos InterfaceRede (que, no caso
do Computador, é apenas uma);
• Uma tabela de roteamento (TabelaRotas);
• Implementação do método de encaminhamento de datagramas
(encaminha(Datagrama)).
• Um método recebeDatagrama(Datagrama), vazio.
A tabela de roteamento, implementada pela classe TabelaRoteamento, é responsável por
armazenar as rotas de um host. Esta classe implementa a pesquisa da tabela de roteamento
(método localizaRotaPara(EnderecoIP)): recebe no argumento o endereço IP de um
destinatário e retorna uma rota ou, caso nenhuma seja adequada, null.
42
O encaminhamento de datagramas é a implementação do algoritmo de encaminhamento
descrito à página 17 (em “Algoritmo de encaminhamento IP”).
O método recebeDatagrama() é executado quando o host que recebe um datagrama é o
destinatário ou se for destinado ao broadcast de sua rede IP. O Roteador sobrescreve este
método, de forma a analisar se o datagrama recebido é uma mensagem RIP, por exemplo, e
então encaminhá-la para o módulo de roteamento configurado no roteador.
Já o Computador não implementa o método recebeDatagrama(), já que, quando recebe um
datagrama, não faz nenhum tratamento especial.
4.2.2.1 Computador
O computador possui um método próprio para ativar a geração de datagramas, permitindo,
assim, gerar tráfego na rede que está sendo simulada. O método ativaGeradorDatagramas
(String destino) recebe no argumento um endereço IP (textual) que é o destinatário dos
datagramas a serem gerados. Os datagramas gerados têm tamanho fixado em 1500 bytes.
4.2.2.2 Roteador
O roteador possui o método setModuloRoteamento() que serve para passar a referência de um
objeto que implemente a interface ModuloRoteamento (descrita a seguir). Quando fornecido
um módulo de roteamento (que pode ser RIP, OSPF ou outro qualquer), o roteador receberá
datagramas destinados a ele e os passará para o módulo de roteamento, o qual fará o
tratamento conforme a especificação do protocolo que implementa.
4.2.3 Meio físico
O meio físico, no simulador, é um recurso compartilhado entre duas interfaces de rede,
caracterizando sua interconexão. A taxa de transferência do meio físico pode ser informada no
construtor e, caso seja omitido, será usado um valor padrão (64000 bits/segundo, ou 64 Kbps).
O meio físico controla sua utilização, de forma que uma interface de rede fica impossibilitada
de enviar um datagrama caso esteja ocupado. Se ocorrer de uma interface tentar enviar um
datagrama enquanto o meio físico encontra-se ocupado, ela será colocada em uma lista de
“aguardando notificação”, o que significa que ela será avisada quando o meio estiver
disponível novamente.
43
4.3 A interface de módulo de roteamento
A interface ModuloRoteamento deve ser implementada por uma classe que represente um
protocolo de roteamento. No framework, é fornecida a implementação do protocolo RIP, que
é a classe ModuloRip. A interface consiste nos seguintes métodos:
public void setRoteador(Roteador roteador); public void inicia(); public void processa(Datagrama datagrama); public boolean podeEncaminhar(Datagrama datagrama);
Assim que um módulo de roteamento é fornecido ao roteador, lhe é passada a referência para
o roteador (de forma que possa acessar suas interfaces de rede e tabela de rotas) e, em
seguida, chamado o método inicia(), para que o módulo faça operações inerentes à sua
inicialização, conforme a especificação do protocolo que implementa. Também não
implementa, ainda, verificação da “idade” das rotas dinâmicas, de forma a incrementar o
custo de rotas que não estão mais sendo divulgadas até que sejam removidas.
4.4 Módulo de roteamento RIP
A implementação do protocolo de roteamento RIP é fornecida no framework e é usada da
seguinte forma:
Roteador roteador = new Roteador(“Roteador 1”); // ... criação do restante da rede roteador.setModuloRoteamento(new ModuloRip());
Ao ser inicializado pelo roteador através do método inicia(), o módulo RIP irá fazer sua
primeira divulgação de rotas e, em seguida, agendar um evento para a próxima divulgação, a
ser executada após 30 segundos.
Atualmente o módulo RIP não implementa nenhuma técnica para solucionar o problema da
contagem para o infinito (página 23). As possíveis implementações seriam as técnicas do
horizonte dividido e horizonte dividido com poison-reverse.
4.5 Interface com o usuário
A interface com o usuário ainda é textual, de tal forma que é necessário criar a rede a ser
simulada diretamente no código em Java, compilado e, finalmente, executado. Felizmente,
embora não seja uma interface visual, é intuitiva e demanda pouco conhecimento da
linguagem para utilização, bastando alguns exemplos para se interar de como utilizá-lo.
44
A classe SimuladorRoteamento possui alguns atributos booleanos, públicos e estáticos, que
podem ser modificados a fim de fazer com que a saída textual do simulador seja a desejada.
Os atributos são:
• MOSTRAR_MSGS_ROTEAMENTO: mensagens relativas a decisão de roteamento,
como rotas encontradas para um destinatário ou falha, caso uma rota não tenha sido
encontrada.
• MOSTRAR_MSGS_MEIO_FISICO: mensagens pertinentes ao meio físico,
mostrando quando o meio não pôde ser alocado por encontrar-se ocupado, interfaces
de rede que são notificadas de sua liberação, etc.
• MOSTRAR_DEBUG_BUFFER: mensagens relativas à inserção e remoção de
datagramas nos buffers das interfaces de rede.
• MOSTRAR_MENSAGENS_RIP: mensagens relativas à divulgação de rotas e
recepção de mensagens RIP.
• MOSTRAR_QUALQUER_COISA: mensagens de depuração que não se enquadram
em nenhuma das situação das já definidas.
A interface pode ser gráfica, embora ainda não tenha sido implementada. Ela permitiria (i) a
entrada dos dados da rede de forma mais fácil e amigável, (ii) visualizar a dinâmica do
roteamento ao longo da rede e (iii) mostrar os resultados visualmente. São apenas algumas das
vantagens a serem exploradas com implementações visuais.
4.6 Exemplos de simulação
Serão expostos aqui alguns cenários, em ordem crescente de complexidade, envolvendo
roteamento mínimo, roteamento estático e roteamento dinâmico.
4.6.1 Cenário 1: dois computadores diretamente conectados
Neste exemplo temos dois computadores, rotulados PC-1 e PC-2, interligados entre si por um
meio físico ponto-a-ponto denominado Link-1, com capacidade de transmissão de 256.000
bits por segundos (256 Kbps). A figura 19 mostra como a rede foi disposta.
45
Figura 19 - Dois computadores interligados
Para gerar algum tráfego de exemplo, o PC-1 será solicitado a enviar um datagrama para o
PC-2. Para tanto, criaremos uma classe Cenario1 que representará este cenário:
import org.cvarda.siroip.*; public class Cenario1 extends SimuladorRoteamento { public Cenario1() { MOSTRAR_MSGS_ROTEAMENTO = true; MOSTRAR_MSGS_MEIO_FISICO = true; Computador pc1 = new Computador("PC-1", "192.168.1.1", "255.255.255.0"); Computador pc2 = new Computador("PC-2", "192.168.1.2", "255.255.255.0"); MeioFisico link1 = new MeioFisico("Link-1", 256000); link1.conecta(pc1.getInterface(), pc2.getInterface()); pc1.ativaGeradorDatagramas("192.168.1.2"); executaSimulador(); } public static void main(String[] args) { new Cenario1(); } }
Inicialmente definem-se quais tipos de mensagens devem ser apresentadas (neste caso, de
roteamento e do meio físico). Dois objetos que representam PC-1 e PC-2: pc1 e pc2,
respectivamente. O link é representado pelo recurso link1. Após instanciar estes elementos,
conecta-se as interfaces através do método conecta() do meio físico. Isto fará com que as
interfaces de rede recebam a referência a este recurso de forma que possam compartilhá-lo.
Em seguida, o gerador de datagramas é ativado em PC-1, com destino o PC-2 (endereço
192.168.1.2). Não há necessidade de adição de rotas aqui, pois os computadores já têm suas
rotas mínimas e podem acessar hosts em sua própria rede IP.
Por fim, executa-se o simulador (executaSimulador()). O produto da simulação é:
0.0: [PC-1] novo datagrama dgram(id=1) 0.0: [PC-1] dgram(id=1) saindo por iface 192.168.1.1 0.0: [Link-1] alocado para dgram(id=1). 0.0: [PC-1: 192.168.1.1] o dgram(id=1) foi enviado para a rede. 0.046875: [Link-1] foi liberado. 0.046875: [PC-2: 192.168.1.2] recebeu o dgram(id=1). 0.046875: [PC-2] DESTINO (PC-2) RECEBEU dgram(id=1, 192.168.1.1->192.168.1.2).
46
O número real, à esquerda, representa o tempo de simulação. O texto entre colchetes, em
seguida, é o rótulo do host, recurso ou outro elemento de simulação que gerou a mensagem.
Quando o rótulo é seguido de dois pontos e um endereço IP, a mensagem originou-se da
interface que tem o respectivo endereço IP.
A seqüência mostra o surgimento do datagrama no PC-1, que representa o datagrama que teria
sido gerado por uma aplicação neste computador. Mostra também os momentos em que o
enlace é ocupado e liberado. A variação no tempo de simulação (mudando de 0.0 para
0.046875) mostra o tempo que levou a transferência do datagrama entre os dois PCs.
4.6.2 Cenário 2: dois computadores interligados por meio de um roteador
Este caso apresenta uso da rota default, que deve ser atribuída aos PCs. O cenário é mostrado
na figura 20:
Figura 20 - Dois computadores conectados por meio de um roteador
Para este exemplo será gerado um datagrama a partir do PC-2 com destino o PC-1. A classe
Cenario2 que representa este cenário fica assim:
47
import org.cvarda.siroip.*; public class Cenario2 extends SimuladorRoteamento { public Cenario2() { MOSTRAR_MSGS_ROTEAMENTO = true; MOSTRAR_MSGS_MEIO_FISICO = true; Computador pc1 = new Computador("PC-1", "192.168.27.3", "255.255.255.0"); Computador pc2 = new Computador("PC-2", "192.168.21.8", "255.255.255.0"); MeioFisico link1 = new MeioFisico("Link-1", 64000); MeioFisico link2 = new MeioFisico("Link-2", 256000); Roteador roteador = new Roteador("Roteador-1"); roteador.adicionaInterface("192.168.27.254", "255.255.255.0"); roteador.adicionaInterface("192.168.21.254", "255.255.255.0"); link1.conecta(pc1.getInterface(), roteador.getInterface("192.168.27.254")); link2.conecta(roteador.getInterface("192.168.21.254"), pc2.getInterface()); pc1.routeDefault("192.168.27.254"); pc2.routeDefault("192.168.21.254"); pc2.ativaGeradorDatagramas("192.168.27.3"); executaSimulador(); } public static void main(String[] args) { new Cenario2(); } }
A execução do cenário 2 gera a seguinte saída:
0.0: [PC-2] novo datagrama dgram(id=1) 0.0: [PC-2] dgram(id=1) saindo por gw 192.168.21.254 0.0: [Link-2] alocado para dgram(id=1). 0.0: [PC-2: 192.168.21.8] o dgram(id=1) foi enviado para a rede. 0.046875: [Link-2] foi liberado. 0.046875: [Roteador-1: 192.168.21.254] recebeu o dgram(id=1). 0.046875: [Roteador-1] dgram(id=1) saindo por iface 192.168.27.254 0.046875: [Link-1] alocado para dgram(id=1). 0.046875: [Roteador-1: 192.168.27.254] o dgram(id=1) foi enviado para a rede. 0.234375: [Link-1] foi liberado. 0.234375: [PC-1: 192.168.27.3] recebeu o dgram(id=1). 0.234375: [PC-1] DESTINO (PC-1) RECEBEU dgram(id=1, 192.168.21.8->192.168.27.3).
O datagrama (1500 bytes) gerado pelo PC-2 foi enviado à rede no momento inicial (0,0) e
chegou ao roteador após 0,046875 segundos (transferido no link de 256 Kbps). Em seguida, o
roteador enviou o datagrama para seu destino, o PC-1, e chegou no momento 0,234375
(transferido no link de 64 Kbps). O PC-1 constatou ser o destinatário do datagrama e o
considerou recebido.
Se o datagrama chegou no momento 0,234375, pode-se concluir que seu tempo de
transferência foi de 0,234375 – 0,046875, ou seja, 0,1875 segundos. Considerando que a taxa
de transmissão do link 2 é quatro vezes maior do que o link 1, se fizermos 0,046875 x 4,
teremos 0,1875, que é justamente o tempo de transmissão do mesmo datagrama no link 1.
48
4.6.3 Cenário 3: demonstrando o tratamento de uso do meio físico
Nos cenários anteriores não ocorreu em nenhum momento uma interface tentar enviar um
datagrama por um meio físico que estivesse ocupado. Este cenário será usado para demonstrar
este tratamento. O cenário é mostrado na figura 21.
Figura 21 - Rede com dois computadores e dois roteadores
Inicialmente será mostrado o código com rotas estáticas e, mais adiante, usando RIP para
descoberta das rotas. Serão ativados, simultaneamente, os geradores de datagramas nos PCs 1
e 2, cada um tendo como destinatário o outro PC, de forma que um dos roteadores encontrará
o Link-2 ocupado quando for tentar transmitir.
A classe Cenario3 para demonstrar o funcionamento exposto será assim:
import org.cvarda.siroip.*; public class Cenario3 extends SimuladorRoteamento { public Cenario3() { MOSTRAR_MSGS_ROTEAMENTO = true; MOSTRAR_MSGS_MEIO_FISICO = true; Computador pc1 = new Computador("PC-1", "192.168.3.36", "255.255.255.0"); Computador pc2 = new Computador("PC-2", "192.168.4.17", "255.255.255.0"); MeioFisico link1 = new MeioFisico("Link-1", 64000); MeioFisico link2 = new MeioFisico("Link-2", 64000); MeioFisico link3 = new MeioFisico("Link-3", 64000); Roteador r1 = new Roteador("Roteador-1"); Roteador r2 = new Roteador("Roteador-2"); r1.adicionaInterface("192.168.3.254", "255.255.255.0"); r1.adicionaInterface("192.168.1.1", "255.255.255.0"); r2.adicionaInterface("192.168.1.2", "255.255.255.0"); r2.adicionaInterface("192.168.4.254", "255.255.255.0"); link1.conecta(pc1.getInterface(), r1.getInterface("192.168.3.254")); link2.conecta(r1.getInterface("192.168.1.1"), r2.getInterface("192.168.1.2")); link3.conecta(r2.getInterface("192.168.4.254"), pc2.getInterface()); pc1.routeDefault("192.168.3.254"); pc2.routeDefault("192.168.4.254"); r1.routeAdd("192.168.4.0", "255.255.255.0", "192.168.1.2"); r2.routeAdd("192.168.3.0", "255.255.255.0", "192.168.1.1"); pc1.ativaGeradorDatagramas("192.168.4.17"); pc2.ativaGeradorDatagramas("192.168.3.36"); executaSimulador();
49
} public static void main(String[] args) { new Cenario3(); } }
Uma diferença importante a ser observada em comparação aos cenários anteriores são quatro
linhas que adicionam rotas aos PCs e aos roteadores: pcx.routeDefault(...), as quais
adicionam rotas default aos PCs, e r1.routeAdd(...), que adicionam rotas estáticas aos
roteadores.
A saída gerada pela sua execução é a seguinte:
0.0: [PC-1] novo datagrama dgram(id=1) 0.0: [PC-2] novo datagrama dgram(id=2) 0.0: [PC-1] dgram(id=1) saindo por gw 192.168.3.254 0.0: [PC-2] dgram(id=2) saindo por gw 192.168.4.254 0.0: [Link-1] alocado para dgram(id=1). 0.0: [PC-1: 192.168.3.36] o dgram(id=1) foi enviado para a rede. 0.0: [Link-3] alocado para dgram(id=2). 0.0: [PC-2: 192.168.4.17] o dgram(id=2) foi enviado para a rede. 0.1875: [Link-1] foi liberado. 0.1875: [Roteador-1: 192.168.3.254] recebeu o dgram(id=1). 0.1875: [Link-3] foi liberado. 0.1875: [Roteador-2: 192.168.4.254] recebeu o dgram(id=2). 0.1875: [Roteador-1] dgram(id=1) saindo por gw 192.168.1.2 0.1875: [Roteador-2] dgram(id=2) saindo por gw 192.168.1.1 0.1875: [Link-2] alocado para dgram(id=1). 0.1875: [Roteador-1: 192.168.1.1] o dgram(id=1) foi enviado para a rede. 0.1875: [Link-2] não pôde ser alocado para dgram(id=2) porque está em uso. 0.1875: [Link-2] ocupado p/ transferir dgram(id=2)! 0.375: [Link-2] foi liberado. 0.375: [Roteador-2: 192.168.1.2] notificando liberacao a interface 192.168.1.2 0.375: [Link-2] alocado para dgram(id=2). 0.375: [Roteador-2: 192.168.1.2] o dgram(id=2) foi enviado para a rede. 0.375: [Roteador-2: 192.168.1.2] recebeu o dgram(id=1). 0.375: [Roteador-2] dgram(id=1) saindo por iface 192.168.4.254 0.375: [Link-3] alocado para dgram(id=1). 0.375: [Roteador-2: 192.168.4.254] o dgram(id=1) foi enviado para a rede. 0.5625: [Link-2] foi liberado. 0.5625: [Roteador-1: 192.168.1.1] recebeu o dgram(id=2). 0.5625: [Link-3] foi liberado. 0.5625: [PC-2: 192.168.4.17] recebeu o dgram(id=1). 0.5625: [Roteador-1] dgram(id=2) saindo por iface 192.168.3.254 0.5625: [PC-2] DESTINO (PC-2) RECEBEU dgram(id=1, 192.168.3.36->192.168.4.17). 0.5625: [Link-1] alocado para dgram(id=2). 0.5625: [Roteador-1: 192.168.3.254] o dgram(id=2) foi enviado para a rede. 0.75: [Link-1] foi liberado. 0.75: [PC-1: 192.168.3.36] recebeu o dgram(id=2). 0.75: [PC-1] DESTINO (PC-1) RECEBEU dgram(id=2, 192.168.4.17->192.168.3.36).
É possível observar que no instante 0,1875 o Link-2 foi alocado para enviar o datagrama de
id=1, o qual foi enviado à rede. No mesmo tempo, 0,1875, o tentou-se alocar o meio físico,
gerando a mensagem “ocupado p/ transferir dgram(id=2)!”. Assim, somente no momento
0,375, quando o meio foi liberado, a interface que tentou, sem sucesso alocar o meio, recebe a
notificação de liberação e tenta novamente enviar o datagrama, desta vez, com sucesso.
50
Assim, o primeiro datagrama chegou ao seu destino no instante 0,5625 e o segundo
datagrama, em 0,75.
4.6.3.1 Usando roteamento dinâmico
Uma modificação no cenário atual será feita para demonstrar como o roteamento dinâmico é
feito no framework. As modificações realizadas foram as seguintes: (i) oculta-se todas as
mensagens removendo-se os atributos no início do construtor, (ii) remove-se a inicialização
do geradores de datagramas e (iii) escrevemos na saída as tabelas de rotas dos roteadores.
O código do construtor deverá ser o seguinte:
Computador pc1 = new Computador("PC-1", "192.168.3.36", "255.255.255.0"); Computador pc2 = new Computador("PC-2", "192.168.4.17", "255.255.255.0"); MeioFisico link1 = new MeioFisico("Link-1", 64000); MeioFisico link2 = new MeioFisico("Link-2", 64000); MeioFisico link3 = new MeioFisico("Link-3", 64000); Roteador r1 = new Roteador("Roteador-1"); Roteador r2 = new Roteador("Roteador-2"); r1.adicionaInterface("192.168.3.254", "255.255.255.0"); r1.adicionaInterface("192.168.1.1", "255.255.255.0"); r2.adicionaInterface("192.168.1.2", "255.255.255.0"); r2.adicionaInterface("192.168.4.254", "255.255.255.0"); link1.conecta(pc1.getInterface(), r1.getInterface("192.168.3.254")); link2.conecta(r1.getInterface("192.168.1.1"), r2.getInterface("192.168.1.2")); link3.conecta(r2.getInterface("192.168.4.254"), pc2.getInterface()); pc1.routeDefault("192.168.3.254"); pc2.routeDefault("192.168.4.254"); r1.setModuloRoteamento(new ModuloRip()); r2.setModuloRoteamento(new ModuloRip()); executaSimulador(); r1.printRoutingTable(); r2.printRoutingTable();
As modificações irão mostrar na saída apenas as tabela de rotas dos dois roteadores após o
processo de convergência:
51
Tabela de rotas de Roteador-1 Tipo Custo Destino Mascara Gateway ---- ----- --------------- --------------- --------------- E 1 192.168.1.0 255.255.255.0 iface 192.168.1.1 E 1 192.168.3.0 255.255.255.0 iface 192.168.3.254 D 2 192.168.4.0 255.255.255.0 192.168.1.2 Tabela de rotas de Roteador-2 Tipo Custo Destino Mascara Gateway ---- ----- --------------- --------------- --------------- E 1 192.168.1.0 255.255.255.0 iface 192.168.1.2 D 2 192.168.3.0 255.255.255.0 192.168.1.1 E 1 192.168.4.0 255.255.255.0 iface 192.168.4.254
A coluna Tipo identifica se a rota é dinâmica (D) ou estática (E). A coluna Custo mostra a
quantidade de hops até o destino.
4.6.4 Conclusão sobre os exemplos de simulação
Estes cenários visam demonstrar como se usa o framework tal como se encontra em seu
estágio atual. Nos exemplos, procurou-se demonstrar casos simples mais que reflitam casos
reais e que sirvam para demonstrar o potencial do simulador.
Outros exercícios podem ser feitos, bastando fazer modificações nas classes apresentadas,
para simular topologias mais complexas, com vários PCs, roteadores e enlaces.
4.7 Extensibilidade do framework
Há várias formas de se agregar funcionalidade ao framework. Eis algumas delas:
• Implementação de novos módulos de roteamento: novos protocolos podem ser escritos
para o simulador, bastando que o autor implemente a interface ModuloRoteamento
(descrita na página 43). Assim, o simulador poderia ter, por exemplo, o protocolo
OSPF para novas simulações.
• Implementação de um meio físico em barramento: permitiria que vários computadores
ou roteadores disputassem o acesso a um meio compartilhado, tornando possível
simular cenários mais realistas, que não sejam compostos apenas por enlaces ponto-a-
ponto.
• Interface visual com animação: poderia permitir ao usuário visualizar o trajeto
percorrido pelo datagrama na rede simulada, em vez de exigir que o usuário interprete
várias linhas da saída textual do simulador.
5 CONSIDERAÇÕES FINAIS
De forma ampla, o objetivo do trabalho foi atingido, que era construir um simulador de
roteamento IP. Entretanto, os objetivos específicos foram atingidos parcialmente. É possível
realizar roteamento estático e dinâmico e o framework foi concluído e está funcional.
O simulador faz o roteamento estático, que é pré-requisito para que o dinâmico funcione. O
roteamento dinâmico foi parcialmente implementado: o módulo RIP não envelhece rotas que
não são mais divulgadas e não trata o problema clássico da contagem para o infinito. No
entanto, as rotas são divulgadas e os roteadores realmente “aprendem” as rotas, conforme foi
demonstrado no capítulo 4. Também não faz a divulgação de rotas quando sua tabela de rotas
sofre alteração. O protocolo OSPF, embora planejado para o simulador, não foi
implementado.
O framework está pronto e consiste num conjunto de classes e uma interface, os quais são
usados para usar e extender o framework. A rede é construída instanciando-se objetos que
representam os componentes da rede e o simulador pode ser extendido através da interface de
módulo de roteamento, para permitir o uso de protocolos de roteamento como RIP, OSPF ou
outro que se deseje usar.
A interface amigável de fácil operação não pôde ser implementada por restrições de tempo.
Para simular, é necessário escrever código Java, compilar e executar o simulador.
Com o simulador no estágio atual, é possível simular redes com computadores (apenas uma
interface de rede), roteadores (com n interfaces) e meios físicos ponto-a-ponto. Os meios
físicos levam em conta a taxa de transferência do meio. A geração de tráfego se dá pela
ativação do gerador de datagramas em um computador ou através da ativação de um módulo
de roteamento, que causará a troca de mensagens de roteamento (portanto, gerando tráfego).
Os datagramas tiveram seu tamanho fixado em 1500 bytes.
O simulador não leva em conta detalhes pertinentes às camadas acima ou abaixo da camada
de rede, atendo-se estritamente à esta camada. A representação do datagrama não é fiel à
realidade, pois ele não “carrega dados” como um datagrama real, e seu tamanho é
representado simplesmente por um atributo numérico no objeto que o representa, o qual é
usado para calcular o tempo de transferência nos enlaces (de acordo com sua taxa de
transferência).
53
Futuramente, a implementação de uma interface com o usuário permitirá que o simulador seja
efetivamente utilizável como um aplicativo com entrada e saída visuais, de forma intuitiva.
Pequenas alterações darão, também, mais realismo à simulação, como, por exemplo,
dimensionar o datagrama com mensagens RIP de acordo com a quantidade de rotas que ele
carrega.
ANEXOS
ANEXO 1: Diagrama de classes do framework de simulação discreta
BlocoChegada BlocoSaidaEventoChegada EventoSaida
SimuladorhorarioAtual : intlef : ListaEventosFuturos
adicionaEvento(evento : Evento)executaSimulador()executaSimulador(tempoLimite : double)
Entidade
ListaEventosFuturoslef : ArrayList
insereEvento(evento : Evento)pegaProximoEvento() : Eventosize() : inttemMais() : boolean
+tem uma
Bloco
chegada()saida()
Eventobloco : Blocoentidade : EntidadehorarioDeExecucao : int
executa()
+ligado a
+contém
+ligado a
ANEXO 2: Diagrama de classes do framework de simulação de roteamento IP
BlocoSimuladorRoteamento
Broadcast
ConfigIPprefixo : Prefixoendereco : EnderecoIPmascara : Mascarabroadcast : Broadcast
DatagramaprocedenciatamanhotipoVEIO_DA_REDEVEIO_DO_HOSTenderecoOrigem : EnderecoIPenderecoDestino : EnderecoIP
marcaProcedencia()tamanho()veioDaRede()veioDoHost()
DatagramaRiprotas : Set
novaRota()iterator()
Hostinterfaces : ArrayList<InterfaceRede>tabelaRotas : TabelaRotas
adicionaInterface(ip : String, mascara : String)ehBroadcast(ip : EnderecoIP) : booleanehEnderecoLocal(ip : EnderecoIP) : booleanconecta(iface : InterfaceRede)encaminha(datagrama : Datagrama)getInterface(ip : EnderecoIP) : InterfaceRedegetInterface(ip : String) : InterfaceRedegetTabelaRotas() : TabelaRotasrecebeDatagrama()routeAdd(rota : Rota)routeAdd(prefixo : String, mascara : String, gateway : String)routeDefault(gw : String)
InterfaceRedebuffer : Bufferhost : HostmeioFisico : MeioFisicoip : EnderecoIP
atribuiIP(ip : String, mascara : String)conecta(host : Host)conecta(meioFisico : MeioFisico)enviaProximoDoBuffer()getConfigIP() : ConfigIP
Mascara
ModuloRip<<ModuloRoteamento>>
ModuloRoteamentoVazio<<ModuloRoteamento>>
Prefixo
RedeIPbroadcast : Broadcastmascara : Mascaraprefixo : Prefixo
calculaPrefixo()pertence()
SimuladorRoteamento
TabelaRotasrotas
getRota()getRotas()iterator()localizaRotaPara()routeAdd()substitui()tamanho()temRota()
Computadorgerador : GeradorDatagrama
ativaGeradorDatagramas()getInterface()
ModuloRoteamento
inicia()podeEncaminhar()processa()setRoteador()
<< interface >>
RoteadormoduloRoteamento : ModuloRoteamento
printRoutingTable()setModuloRoteamento()
EnderecoIPenderecoLong : long
long2string()toLong()
MeioFisicoaguardandoNotificacao : ListemUso : intinterface1 : InterfaceRedeinterface2 : InterfaceRedetaxaBits : int
aguardandoNotificacao()aloca()conecta()interfaceRemota()libera()livre()tempoTransferencia()
RotaDINAMICA : byteESTATICA : bytecusto : intgateway : EnderecoIPiface : InterfaceRedeTIPO : byte
REFERÊNCIAS
TANENBAUM, Andrew S. Redes de Computadores. 4. ed. Rio de Janeiro: Campus Ltda., 1997. 923p. ISBN 85-352-0157-2.
PETERSON, Larry; DAVIE, Bruce. Computer Networks: A Systems Approach. 2nd. ed. San Francisco, CA (USA): Morgan Kaufmann Publishers, 2000. 748 p. ISBN 1-55860-577-0.
FREITAS FILHO, Paulo José de. Introdução à Modelagem e Simulação de Sistemas: com Aplicações em Arena. 1. ed. Florianópolis: Visual Books Ltda., 2001. 322p. ISBN 8-57-502046-3.
FEIT, Sidnie. TCP/IP: Architecture, Protocols, and Implementation. Singapore: McGraw-Hill Book Co., 1993. 466p. ISBN 0-07-020346-6.
FULLER, Vince, LI, Tony et al. Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy (RFC 1519). 1993. Disponível em: <http://rtg.ietf.org/rfc/rfc1519.txt>. Acesso em 27 abr. 2005.
MOY, John. OSPF Version 2 (RFC 2328). 1998. Disponível em: <http://rtg.ietf.org/rfc/rfc2328.txt>. Acesso em 09 jun. 2005.
LAW, Averill M.; KELTON, W. David. Simulation Modeling and Analysis. 3rd ed. United States: McGraw-Hill Higher Education, 2000. 760 p. ISBN 0-07-059292-6.
MCDONALD, Chris. The cnet network simulator: Getting started. Disponível em: <http://www.csse.uwa.edu.au/cnet>. Acesso em 01 jun. 2005.
FALL, Kevin; VARADHAN, Kannan. The ns Manual (formely ns Notes and Documentation). 2005. Disponível em: <http://www.isi.edu/nsnam/ns/ns-documentation.html>. Acesso em 05 jun. 2005.
