1. GİRİŞ
1.7. Genel Bilgiler
1.1.10. Spor ve Ritim
O módulo mobility, por sua vez, contém as declarações necessárias a toda a abordagem de movimento dos nós na rede passível de simulação. Serve essencialmente para monitorizar todos os objectos existentes na rede em termos de posição actual e velocidade.
3.3.5. NODE
Com este módulo é possível declarar uma abstracção de node que posteriormente pode ser especificado para um outro componente de rede física em concreto (por exemplo, computador, servidor, etc.). Com a sua directiva address é possível estipular um endereço IP para o nó, bem como associar protocolos (IPv4RoutingProtocol ou IPv6RoutingProtocol) e aplicações (Sockets e auxílio ao módulo Applications).
A classe node, uma vez instanciada, irá guardar numa lista virtual todos os nós (NodeList) que irão ser utilizados na simulação e também uma lista de canais criados entre os mesmos (ChannelList).
Figura 11 - Módulo Node
Com a actualização modular realizada em 25 de Maio de 2011, alguns destes objectos associados a Node passaram a ser considerados no âmbito de um novo módulo denominado por Network, como é o caso de IPv4 e IPv6.
3.3.6. APPLICATIONS
O módulo Applications, tal como o seu próprio nome indica, permite a instanciação de aplicações associadas a eventuais nós pelos seus canais previamente declarados. De salientar a utilização de OnOffApplication que permite estabelecer tempos em que a aplicação em causa deve estar activa criando um tráfego CBR (onTime) e os tempos em que a mesma não deverá gerar qualquer tráfego (offTime).
Outra directiva importante deste módulo é a de PacketSink em que a ideia original foi a de complementar a declaração de OnOffApplication mas devido a ser de um nível de abstracção maior, então foi considerado separadamente: PacketSink poderá estar associado a aplicações unicast e multicast.
3.3.7. DEVICES
Neste módulo está contida a especificação referente aos dispositivos que podem ser utilizados na autoria de cenários de redes numa óptica de topologia/tecnologia de rede. Temos disponíveis por exemplo a topologia Mesh, Point-To-Point, Wifi, CSMA, UAN,
WiMAX, etc.
Posteriormente os vários tipos de devices foram considerados individualmente devido à crescente contribuição com novos tipos de dispositivos como é exemplo dos módulos LTE, Spectrum, OpenFlow Switch, etc.
Figura 13 - Módulo Devices
3.3.8. INTERNET-STACK
Este módulo contém os principais protocolos utilizados na transmissão de dados, usados sobretudo por aplicações como ftp, cbr, telnet, etc. Entre os vários protocolos a que o módulo cobre a sua especificação, destacam-se os seguintes, TCP,
Figura 14 - Módulo InternetStack
3.3.9. ROUTING
Outro módulo detentor de grande importância em termos de autoria de cenários de redes trata-se de o módulo de routing que possui especificações necessárias para a definição de rotas para envio e recepção de tráfego.
Para rotas estáticas é possível utilizar tags como Ipv4StaticRouting, Ipv6StaticRouting. Para redes mais complexas ou com maior dimensão podemos utilizar encaminhamento com tags como Global routing, AODV (Ad hoc On-Demand Distance
Vector routing) [Moraes, 2003], OLSR (Optimized Link State Routing) [OLSR, 2008] e Nix-vector routing, este último somente disponível (de momento) para Ipv4.
Figura 15 - Módulo Routing
Click routing [Suresh, 2011] e DSDV routing foram outras adições que levaram
a que o módulo routing fosse, tal como o módulo devices, subdividido em vários módulos individuais para cada tipo de encaminhamento.
3.3.10. HELPER
Já o módulo Helper possui ajuda nomeadamente para fins de scripting para que o autor de cenários possa criá-los facilmente, usando para tal informações referentes aos vários módulos anteriormente apresentados.
3.3.11. TEST
Por fim, o módulo test contém scripts para testar o cenário desenvolvido, em termos de:
Build verification test (verificação da construção do programa final para execução);
Unit tests (usados para testar funcionalidades/blocos de código específicos); System tests (testes que envolvem mais do que 1 dos módulos anteriormente descritos);
Examples (nada realmente é testado, no entanto trata-se de uma forma de garantir que o build to programa foi realizado com sucesso);
Performance tests (testes para verificar se os tempos de execução de funcionalidades ou até mesmo do script na sua totalidade são aceitáveis ou não).
3.4. PRINCIPAIS CARACTERÍSTICAS/FUNCIONALIDADES
De entre as várias funcionalidades suportadas pelo NS3, destacam-se as seguintes:
Escalabilidade
Os pacotes gerados para criação de tráfego na rede podem possuir tamanho “virtual de zero bytes”, o que permite obter uma maior facilidade em termos de gestão de memória visto que estes não são alocados na memória física;
Poder representativo
Nem sempre é necessário estipular coordenadas para os nós existentes na rede alvo, pelo que torna muito mais simples a codificação destes, ao contrário de OTcl que exige um posicionamento relativo ou absoluto entre os objectos para que estes não sejam sobrepostos entre si – Por exemplo, os nós que usam canais físicos entre eles não necessitam de especificação de coordenadas;
A codificação para autoria de cenários de redes segue a metodologia POO, pelo que optimiza a extensibilidade e gestão da memória utilizada.
Esta boa prática de programação permite também uma fácil agregação de objectos existentes na rede a simular – Por exemplo, agregar netdevices aos nós e por sua vez canais, protocolos e eventuais aplicações associadas;
Figura 16 - Arquitectura IP em NS3 [Henderson, 2011]
Facilidades de modificação
A sua estrutura baseada em programação orientada a objectos permite que outras funcionalidades/módulos novos possam ser adicionados no futuro sem que para esse fim seja necessário alterar a estrutura da aplicação – por exemplo, a adição de modelos de gestão de energia;
Funcionalidades entre camadas
Tendo em conta o modelo OSI, a informação relativa aos pacotes existentes na rede pode ser transmitida entre as várias camadas do modelo através de tags que contêm informação sobre os pacotes. Esta atribuição de tags aos pacotes permite simultaneamente o controlo do tráfego entre as várias camadas.
Integração de funcionalidades em tempo real
Na execução das redes criadas é possível adicionar a informação existente sobre os pacotes transmitidos na rede para ficheiros do tipo PCAP, o que possibilita a futura utilização destes por plataformas terceiras (por exemplo Wireshark);
É possível integrar agendamento em tempo real para a simulação em que os eventos são sincronizados com um relógio;
Também em tempo real é suportada a utilização da pilha do Linux Kernel TCP/IP (com auxílio às variantes Linux 2.6.18 e Linux 2.6.26).
Desempenho
O desempenho do NS-3 traz uma grande melhoria no processamento relativamente ao NS-2 devido essencialmente à utilização de uma arquitectura multicore
que possibilita o processamento paralelo através da utilização do MPI (Message Passing
Interface) que se constitui um protocolo usado no âmbito das aplicações distribuídas.
3.5. VANTAGENS E DESVANTAGENS
De entre as várias vantagens associadas ao uso de NS-3 para autoria de cenários de redes, destacam-se as seguintes:
Ferramenta opensource – Ao contrário de ferramentas utilizadas para autoria e simulação tais como OPNET e QualNet;
Autoria dos cenários é baseada na metodologia Object-Oriented – Promove possível extensibilidade e facilidades de modificação;
Actualização dos módulos que constituem a sua arquitectura – Módulos tais como core e node sofreram grandes alterações de modo a realçar o realismo dos cenários criados, e;
Existência de grande documentação referente aos vários módulos do programa bem como uma grande comunidade de colaboradores que asseguram um desenvolvimento contínuo da ferramenta.
Já em termos de desvantagens, podemos destacar a seguinte:
Para utilizadores de NS-2, a utilização do NS-3 exige uma familiarização com a linguagem C++ bem como algum conhecimento sobre programação orientada a objectos, e;
Ainda se encontra num estado inicial de desenvolvimento pelo que ainda não cobre um vasto leque de tecnologias, comparativamente a outros simuladores de redes.
3.6. REQUISITOS DE INSTALAÇÃO
Para instalar o Network Simulator 3, é necessário que um conjunto de requisitos seja respeitado. Segue-se uma lista dos requisitos para instalação e execução do NS-3 [Ns3Install, 2011].
O sistema operativo (OS) em que o software deverá ser instalado deve ser um dos seguintes:
Ubuntu/Debian Fedora/RedHat Gentoo
Para o núcleo do NS-3 (ns-3 core) é necessária a pré-instalação do gcc/g++ versão 3.4 ou superior
Python 2.4 ou superior
Ainda relativamente ao sistema operativo alvo de instalação, é necessário ter em conta se o funcionamento do software irá ser apropriado ao que se pretende realizar com o mesmo. Atendendo à Tabela 4, podemos visualizar que funcionalidades são possíveis executar com cada uma das variantes.
Tabela 4 - Variantes e funcionalidades suportadas [Ns3Install, 2011]
Notas:
1. Funciona com gcc4
2. Cygwin possui esta limitação
3. NSC funciona bem com as versões de gcc 3.4, 4.2 ou superior. Devem ser evitadas versões compreendidas entre as releases de 4.0 e 4.1. devido a problemas de compatibilidade verificados com estas versões.
Para todos os efeitos, uma máquina que tenha por base o Linux é a ideal para a instalação do NS-3.
3.7. CONCLUSÃO
Neste capítulo foi realizada uma apresentação do simulador de redes NS-3. Para tal, foram apresentadas as suas principais características e funcionalidades, a sua constituição modular, requisitos de instalação e uma pequena apreciação de vantagens e desvantagens que a ferramenta apresenta actualmente.
No capítulo seguinte será apresentada a Framework NSDL na qual o NS-3 faz parte como plataforma destino no âmbito da autoria de cenários de redes.
4. NSDL (FRAMEWORK)
Neste capítulo é apresentada a Framework Network Scenario Description
Language (NSDL), proposta e desenvolvida no âmbito do trabalho de doutoramento do
Dr. Eduardo Marques na Universidade da Madeira, de forma a proporcionar a interoperabilidade entre diferentes ferramentas de gestão e simulação de redes, e em consequência a optimização da autoria de cenários de redes, desde a sua especificação até à sua simulação.
4.1. INTRODUÇÃO
Cada vez mais surgem novas ferramentas relacionadas com a autoria de cenários de redes e poucas apresentam interoperabilidade entre si. Com a finalidade de diminuir este problema, o NSDL tem por principais objectivo criar pontes entre ferramentas de concepção e monitorização de cenários de redes (especificação textual e/ou gráfica (GUIs) como é o exemplo do VNS e VND) e ferramentas de simulação (NS-2, NS-3, etc.).
De seguida serão apresentadas as principais características do NSDL que permitem confirmar os objectivos previamente mencionados.
4.2. CONCEITOS BÁSICOS
A definição da linguagem NSDL tem por base a linguagem XML que apresenta atributos de qualidade favoráveis às finalidades do NSDL: Entre estes atributos destacam-se a (1) simplicidade, (2) extensibilidade e (3) grande poder de abstracção:
(1) – Uma especificação NSDL é de fácil compreensão pois consiste numa estrutura XML organizada e semanticamente válida, quando seguidas as boas práticas de programação (i.e. indentação);
(2) – O NSDL permite a introdução de extensões que visam abordar a especificação de objectos existentes e/ou até de objectos novos no contexto de uma determinada plataforma de simulação final. O NSDL como extensão do XML detém um conjunto de tags que formam o mundo lexical de tags permitidas na validação NSDL. Este conjunto de tags é incluído no
perfil base pois são utilizadas para especificar elementos que são comuns à
maioria das ferramentas de simulação de cenários de redes. O conceito de
perfil foi introduzido para as eventuais extensões ao NSDL base propostas,
como é o exemplo do trabalho realizado no âmbito desta tese (i.e. perfil NS-3) que será descrito no capítulo 5. Uma extensão da linguagem NSDL inclui o perfil base e um conjunto de tags novas que permitem especificar objectos que existam exclusivamente no contexto da plataforma destino (NS-3 por exemplo), e;
(3) – Com a utilização do NSDL é possível especificar os vários elementos existentes em um determinado perfil com um alto nível de abstracção. Por outro lado, permite também detalhar exaustivamente um certo objecto, especificando para tal os diversos atributos que o perfil prevê para o objecto em causa.
A extensibilidade mencionada anteriormente também leva ao surgimento de um outro atributo muito importante no âmbito da autoria de cenários de redes: A interoperabilidade.
Quando dois perfis possuem elementos de rede coincidentes, é possível obter facilmente dois scripts para serem utilizados nas ferramentas relativas aos perfis através de uma única especificação NSDL: Além de ser uma forma rápida e optimizada de poder simular o mesmo cenário de rede em diversas plataformas finais, permite também que o utilizador não tenha necessariamente grandes conhecimentos de programação nomeadamente as linguagens utilizadas nas ferramentas de simulação de redes, como é o exemplo de OTcl para NS-2, C++ para NS-3, especificação batch para ambientes Linux, etc., pois o utilizador somente necessita programar XML.
De seguida será apresentada a arquitectura que reflecte a abordagem a todos estes atributos de qualidade referidos.
Uma especificação NSDL permite caracterizar diversos objectos existentes numa rede, em grupos contextuais diferentes mas que complementam a robustez de um determinado cenário de redes: Estes grupos são essencialmente rede, visualização e simulação.
4.3. ARQUITECTURA
A arquitectura da Framework NSDL é constituída essencialmente por 3 camadas (Figura 17): Network Scenario Description Language Network Simulation Engine Layer Graphical User Interface Layer
Simulator 1 Simulator 2 .... Simulator N Network Scenarios API 1
Graphical UI 1 Graphical UI 2 .... Graphical UI N
API N API 2
Figura 17 - Arquitectura da Framework NSDL por camadas
Camada superior (Graphical User Interface Layer) – Inclui as diversas ferramentas de autoria gráfica, monitorização e visualização de cenários de redes. Estas ferramentas, uma vez compatíveis com o NSDL, podem ser utilizadas para importação e exportação de uma estrutura NSDL adequada; A exportação visa a criação de uma estrutura NSDL consoante os objectos graficamente representados na ferramenta. Por
outro lado, a importação de um ficheiro NSDL tem por finalidade poder observar graficamente os vários objectos especificados no ficheiro fornecido e eventualmente possibilitar a sua edição. São exemplos de ferramentas gráficas no âmbito da
Framework NSDL, o VNS e o VND, ambas apresentadas no Capítulo 2. De momento o
VND aborda a exportação de um cenário gráfico para um ficheiro NSDL mas o processo de importação também é algo que está a ser considerado como uma futura contribuição. Quanto ao VNS, esta ferramenta permite modelar cenários de redes com o objectivo de obter um script passível de execução no ambiente de simulação NS-2.
Camada intermédia (Network Scenario Description Language) – Esta camada é detentora da linguagem NSDL que serve como uma ponte entre as ferramentas gráficas e as ferramentas de simulação, permitindo assim uma optimização do processo de autoria dos cenários de redes. Esta linguagem é constituída essencialmente por 2 elementos: Network e Scenarios que irão ser descritos com maior detalhe na secção 4.4. Nesta camada são incluídas ainda metodologias de validação e de transformação das estruturas NSDL (maior detalhe no Capítulo 6) que permitem obter scripts passíveis de execução em uma das ferramentas de simulação incluídas na camada inferior.
Camada inferior (Network Simulation Engine Layer) – Por último, a camada inferior aglomera as ferramentas existentes de simulação, detentoras de um perfil NSDL para que possa existir então uma ligação entre esta camada e a intermédia. Destacam-se essencialmente o NS-2 e o NS-3 por serem os simuladores que actualmente detêm um perfil para NSDL. Como fora mencionado, outras ferramentas poderão eventualmente ser alvo de integração nesta Framework NSDL, bastando para tal a criação de um perfil que aborde os objectos que a ferramenta permite simular e os seus respectivos atributos. Como exemplo de contribuições realizadas neste âmbito por parte de colegas da Universidade da Madeira temos por exemplo o trabalho que está a ser realizado pela colega Joana Araújo que consiste em incorporar um perfil de virtualização na linguagem NSDL que permita simular uma rede virtual com auxílio a máquinas virtuais como o
XenServ e o Vyatta.
De seguida será apresentada a estrutura detalhada no NSDL incluído na camada intermédia.
4.4. ESTRUTURA NSDL
Como foi mencionado na secção 4.3, uma estrutura NSDL é constituída por 2 elementos: Network e Scenarios.
O elemento Network inclui todos os objectos que fazem parte de um cenário de rede, sejam estes equipamentos activos (computers, routers, stations, etc.) sejam passivos (links, switches, bridges, etc.). Já o elemento Scenarios é responsável pela definição do comportamento dinâmico da rede (com o sub-elemento Simulations) bem como a definição da posição espacial dos objectos incluídos na rede (com o sub-
elemento Visualizations).
Figura 18 - Estrutura NSDL
Na Figura 18 é ilustrada a estrutura típica de um documento NSDL. Podemos constatar que o elemento Network é composto por Templates, Objects e Views. Os
Templates são de uso opcional e possibilitam especificar objectos de rede de uma forma
muito mais fácil e flexível bastando para o efeito referenciar o template que deve ser utilizado para enriquecer a especificação de um determinado objecto.
Os Objects incluem equipamentos passivos/activos e domínios. Ainda na Figura 18 podemos observar os elementos de maior nível de abstracção (node, link e domain) e que fazem parte do perfil base (Figura 19).
As Views são utilizadas para agrupar um conjunto de objectos de rede. Esta funcionalidade é útil quando é apenas pretendido destacar um conjunto específico de objectos de uma rede e/ou alterar uma definição que todos partilham na sua especificação.
O elemento Scenarios inclui ainda dois sub-elementos denominados por
Simulations e Visualizations, em que o primeiro detém especificações que irão determinar
o comportamento da simulação do cenário em “run-time” (tempo de execução) tais como os tempos de início e fim da simulação, versão do simulador, ficheiros de output de dados, etc. Enquanto o segundo é responsável pela definição da localização espacial dos objectos existentes na rede, o que pode ser muito útil na utilização deste documento numa ferramenta gráfica.
Network Objects Profiles
Basic Objects Profile Node Domain Interface Protocol Application Link Scenarios Visualization Simulation (others…)
De seguida serão apresentados os principais objectos que constituem os elementos de Network e de Scenarios incluídos na Figura 18.
4.4.1. NETWORK
No elemento Network são descritos todos os objectos de rede (mais exactamente no elemento Objects) o que faz com que este elemento detenha maior importância comparativamente ao elemento Scenarios. De entre os principais objectos, destacam-se os seguintes:
Node – Trata-se do tipo de nó com maior nível de abstracção, conhecendo
como principais especificações os computers, routers, switches, entre outros;
Link – Ainda no âmbito da definição física da rede, o elemento Link constitui
uma ligação simples entre dois nós (nodes) e que suporta diversas tecnologias, entre as quais Ethernet, DSL, optic fibre, spectrum, etc.;
Domains - São utilizados para estabelecer pontes entre redes heterogéneas que
possam existir no mesmo cenário de rede, como por exemplo a inclusão de um domínio
DiffServ e um domínio IntServ, ligados ao domínio da internet.
Ainda na especificação do elemento Node, podem ser instanciados diversos elementos que irão afectar o seguimento da simulação do cenário criado. São sobretudo elementos que abordam a dinâmica do cenário entre os quais podemos assinalar os seguintes:
Application – Responsável pela geração de tráfego consoante um determinado
protocolo e parâmetros específicos de configuração. Entre as diversas especificações de aplicações previstas temos o FTP, CBR, Telnet, Pareto que podem funcionar sob TCP ou UDP;
Protocol – Este elemento possui uma denotação contextual muito extensa pelo
que as diversas especificações de protocolo podem ser de várias naturezas: protocolos de encaminhamento, protocolos de transporte, protocolos de endereçamento, etc. IPv4 para endereçamento e TCP/UDP para transporte são os mais utilizados, e;
Interface – Este elemento representa dispositivos que permitem a comunicação
entre nós de rede. No contexto das redes com fios (wired networks) pode até representar um link de comunicação mas já nos ambientes sem fio (wireless) o conceito de link não seria o mais correcto, pois trata-se de um canal virtual e não físico, daí na realidade os fluxos de dados são transmitidos entre interfaces.
Através da Figura 20 podemos observar o expandir da codificação de um cenário NSDL representativo aos vários elementos contidos na tag network: templates,
objects e views e um exemplo declarativo de como é programado na prática. Podemos
observar que a instância de telnet incluída no objecto computer utiliza o template previamente definido. Com este exemplo fica clara a usabilidade dos templates que torna o código mais curto e organizado.
4.4.2. SCENARIOS
O elemento Scenarios, como já foi referido, inclui dois sub-elementos denominados por Simulations e Visualizations.
Simulations – Este elemento inclui a especificação de eventos que devem
ocorrer em tempo de simulação sob um objecto referenciado, definidos através de tempos de início (Start) e o respectivo instante de paragem (Stop); Neste elemento são também especificadas algumas informações ao nível do simulador destino como por exemplo a versão, tempo de paragem da simulação global, versão do simulador, etc. Por fim, o elemento Simulations também inclui a definição opcional de variáveis específicas da