Faculdade de Engenharia da Universidade do...

Faculdade de Engenharia da Universidade do Porto

Compressão de Cabeçalhos de Routing em Redes Ad-Hoc

Paulo André Serôdio Magalhães

Relatório de Final realizado no âmbito da disciplina Preparação para Dissertação

Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Telecomunicações

Orientador: Prof. Dr. Manuel Ricardo

Co-orientador: Mestre Pedro Fortuna

Porto, Fevereiro 2009

ii

Paulo Magalhães, 2009

iii

Resumo

Devido ao crescente número de tecnologias de rede torna-se cada vez mais necessário um melhor controlo no tráfego de modo aumentar a sua escalabilidade e reduzir o seu overhead.

Umas das tecnologias em expansão são as redes Ad-Hoc, redes móveis sem fios, que oferecem inúmeras vantagens em relação às tradicionais, tais como: baixo custo e característica dinâmica. Este tipo de redes utiliza protocolos de routing para realizar o encaminhamento de pacotes entres os diversos nós da rede. Existem 3 classes de protocolos de routing; os proactivos, onde todos os nós guardam toda a informação da topologia da rede, os reactivos em que a rota só é descoberta no momento em que um nó necessita de enviar informação para o destino e os híbridos que utilizam as vantagens dos dois anteriores

Diversas técnicas têm sido desenvolvidas com o objectivo de diminuir o overhead da rede, nomeadamente a compressão do cabeçalho. Esta técnica não é recente e possui neste momento um esquema de compressão robusto para ligações com altas taxas de erros e longos round-trip time, como é o caso do RoHC. Este protocolo permite a compressão de vários tipos de cabeçalho tais como, IP, UDP, RTP e TCP.

Este trabalho tem como objectivo implementar um modelo de compressão de cabeçalhos para ser usado sobre o protocolo de routing Wireless Metropolitan Routing Protocol (WMRP) que é desenvolvido no âmbito do projecto WiMetroNet, este que tem como finalidade criar uma rede privada entre todos os transportes públicos, de modo a permitir o acesso à internet aos seus passageiros.

v

Abstract

Due to the increasing number of network technologies each time becomes more necessary a better traffic control in the way to increase its scalability and reduce its overhead. Ones of the technologies in expansion is the Ad-Hoc networks, mobile networks wireless that offers innumerable advantages such as: low cost and dynamic characteristic. These types of networks use routing protocols to make the routing of packages between different network nodes. There are three classes of protocols of routing: the proactives, where nodes keep all the information of the topology of the network, the reactives, where the route is only discovered at the moment that a node needs to send information for another node and the hybrids that use the advantages of the others two protocols. In the last years it has been developed techniques to reduce overhead of network. One of the techniques is the header compression. This old technique has a robust scheme of compression for links with high bit error ratio and Round-Trip Time, such as, as RoHC. This protocol allows the compression of many types of heading, such as, IP, UDP, RTP and TCP. This work has as aims to implement a model of header compression to be used on the protocol Wireless Metropolitan that it was developed for WiMetronet project, that create a private network between all the public transports to provide the access to Internet for passengers

vii

Índice Resumo............................................................................................ iii Abstract............................................................................................ v Lista Figuras...................................................................................... ix Lista de tabelas................................................................................... x Abreviaturas...................................................................................... xi 1 Introdução ................................................................................. 14 1.1 Problema............................................................................. 15 1.2 Objectivo ............................................................................ 15 1.3 Contribuições........................................................................ 15 1.4 Organização ......................................................................... 15

2 Redes Wireless Móveis ................................................................... 17 2.1 Introdução ........................................................................... 17 2.2 Redes Ad-Hoc........................................................................ 17 2.2.1 Estrutura ....................................................................... 18 2.2.2 Classificação................................................................... 18 2.2.3 Protocolos Proactivos ........................................................ 19 2.2.3.1 Destination Sequenced Distance Vector (DSDV) .................... 19 2.2.3.2 Wireless Routing Protocol (WRP) .................................... 19 2.2.3.3 Optimized Link State Routing (OLSR) ............................... 20 2.2.3.4 Fisheye State Routing (FSR) .......................................... 21 2.2.3.5 Landmark Ad hoc Routing (LANMAR) ................................ 22 2.2.3.6 Topology Dissemination Based Reverse-Path Forwarding (TBRPF)22

2.2.4 Protocolos Reactivos ......................................................... 23 2.2.4.1 Dynamic Source Routing (DSR) ....................................... 23 2.2.4.2 Ad hoc On Demand Distance Vector (AODV) ........................ 24 2.2.4.3 Temporally Ordered Routing Algorithm (TORA) ................... 25 2.2.4.4 Ad-Hoc On Demand Multi-Path Distance Vector Routing(AOMDV) 25 2.2.4.5 Dynamic MANET On-Demand (DYMO)................................. 26

2.2.5 Protocolos Híbridos ........................................................... 27 2.2.5.1 Zone Routing Protocol (ZRP) ......................................... 27

2.2.6 Comparação ................................................................... 28 2.2.7 Conclusões ..................................................................... 29

2.3 Redes Mesh (IEEE 802.11S) ........................................................ 30 2.4 Wireless Network for Metropolitan Transports (Wimetronet) ................ 31

3 Compressão de Cabeçalhos.............................................................. 33 3.1 Introdução ........................................................................... 33 3.2 Evolução ............................................................................. 34 3.2.1 Thinwire........................................................................ 34 3.2.2 Compression TCP (CTCP) .................................................... 34 3.2.3 IP Header Compression (IPHC) .............................................. 35 3.2.4 Compression RTP (CRTP)..................................................... 35 3.2.5 Enhanced Compressed RTP (ECRTP) ....................................... 36

3.3 Robust Header Compression (RoHC) ............................................. 37 3.3.1 Arquitectura ................................................................... 37 3.3.2 Estados de Compressão e Descompressão................................. 37 3.3.3 Modos Operação............................................................... 39 3.3.4 Parâmetros do canal e do contexto ........................................ 40 3.3.5 Pacotes RoHC.................................................................. 41 3.3.6 Métodos de codificação ...................................................... 41 3.3.6.1 Least Significant Bit (LSB) encoding.................................. 41 3.3.6.2 Window-based LSB encoding (W-LSB encoding) .................... 42

3.3.7 RoHC para Multicast .......................................................... 43

viii

3.4 Tráfego de controlo ................................................................ 44 3.4.1 Routing Assisted Header Compression (RAHC) ........................... 44 3.4.2 Scalable and robust end-to-end header compression (SEEHOC) ....... 44 3.4.3 Signaling Compression (SigComp)........................................... 46

3.5 Novas Tendências................................................................... 48 3.5.1 Layered IP Header Compression ............................................ 48 3.5.2 LowPan ......................................................................... 48 3.5.4 Cooperative Header Compression (COHC)................................. 48

3.6 Fluxos TCP de Curta Duração ..................................................... 49 3.6.1 Máquinas de Estados com Contexto replicado............................ 50

4. Wireless Metropolitan Routing Protocol ............................................... 51 4.1 Descrição Geral ..................................................................... 51 4.2 Estrutura do pacote WMRP ........................................................ 52 4.2.1 Estrutura Base................................................................. 52 4.2.2 Estrutura do Cabeçalho ...................................................... 52 4.2.3 Mensagem HELLO ............................................................. 53 4.2.4 Mensagem TC.................................................................. 53 4.2.5 Mensagem MC ................................................................. 54 4.2.6 Mensagem IC................................................................... 54

5. Network Simulation 3 (NS-3) ............................................................ 55 5.1 Introdução ........................................................................... 55 5.2 Instalação ............................................................................ 55 5.3 Conceitos básicos ................................................................... 56

6. Plano Actividades......................................................................... 57 7. Capítulos Futuros ......................................................................... 58 Referências...................................................................................... 59

ix

Lista Figuras Figura 1-Estrutura Plana....................................................................... 18 Figura 2- Estrutura Hierárquica .............................................................. 18 Figura 3-Flooding Normal...................................................................... 20 Figura 4-Flooding OLSR ........................................................................ 20 Figura 5-Descoberta da Rota DSR ............................................................ 23 Figura 6–Route Reply DSR ..................................................................... 24 Figura 7-Tabela Routing AODV................................................................ 26 Figura 8-Tabela Routing AOMDV.............................................................. 26 Figura 9-Esquema WiMetroNet ............................................................... 31 Figura 10-Arquitectura Header Compression ............................................... 33 Figura 11-Cabeçalho Comprimido ............................................................ 34 Figura 12-Arquitectura RoHC ................................................................. 37 Figura 13-Estados do Descompressor ........................................................ 39 Figura 14-Estados e Transições do Compressor ............................................ 40 Figura 15-Transições dos Modos de Operação .............................................. 40 Figura 16-Estrutura do pacote RoHC......................................................... 41 Figura 17-Função LSB .......................................................................... 42 Figura 18-CID Swapping........................................................................ 45 Figura 19-Arquitectura SigComp.............................................................. 46 Figura 20-Rede com um Wireless Terminal conectado a várias estações Base (BS) .. 49 Figura 21–Máquina Estados .................................................................... 50 Figura 22-Pacote WMRP ....................................................................... 52 Figura 23-Header WMRP ....................................................................... 53 Figura 24-Mensagem HELLO................................................................... 53 Figura 25–Mensagem TC ....................................................................... 53 Figura 26-Mensagem MC ....................................................................... 54 Figura 27-Mensagem IC ........................................................................ 54 Figura 28-Plano de actividades ............................................................... 57

x

Lista de tabelas

Tabela 1- Tabela de comparação dos diversos Protocolos de Routing........................... 28

xi

Abreviaturas

6LOWPAN IPv6 over Low power WPAN

ACK Acknowledgement

AIC AdditionalI Information container

AODV Ad hoc On Demand Distance Vector

AOMDV Ad Hoc On Demand Multi-Path Distance Vector routing

BCID Base Context Identifier

BER Bit Error Ratio

CID Context ID

COHC Cooperative Header Compression

CR Context Replication

CRC Cyclic redundancy check

CRTP Compression RTP

CTCP Compression TCP

DSDV Destination Sequenced Distance Vector

DSR Dynamic Source Routing

DV Distance Vector

DYMO Dynamic MANET On-Demand

FC Full Context

FO First Order

FSR Fisheye State Routing

GMTS Generic Multicast Transport Services

GPL GNU General Public Lincense

IARP Intrazone Routing Protocol

IERP Interzone Routing Protocol

IMA IPMacAssociation

IP Internet Protocol

IPHC IP Header Compression

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

IR Initialization and Refresh

LANMAR Landmark Ad hoc Routing

LowPan low power wireless personal area networks

LSB Least Significant Bit

LTA LocalTerminal Association

MAX_CID MAXIMUM CONTEXT ID

MPLS Multi Protocol Label Switching

MPR Multipoint Relay

xii

MRRU Maximum reconstructed reception unit

NACK Negative Acknowledgement

NC No Context

Nodeld Neighbor ID

NS-3 Network Simulation 3

OLSR Optimized Link State Routing

O-MODE MODE Bidireccional optimistic

PRNET Packet Radio Network

QoS Quality of Service

RAHC Routing Assisted Header Compression

RERR Route Error

RIP Routing Information Protocol

R-Mode Mode Bidirectional realible

RoHC Robust Header Compression

RREP Route Reply

RREQ Route Request

RTA RemoteTerminalAssociatio

RTSP Real Time Streaming Protocol-

SC Static Context

SEEHOC Scalable and Robust End-to-End Header Compression

SigComp Signaling Compression

SIP Session Initiation Protocol

SO Second Order

TBRPF Topology Dissemination Based Reverse-Path Forwarding

TCP Transmission Control Protocol

TORA Temporally Ordered Routing Algorithm

U.S.DARPA United States Defense Advanced Research Projects Agency

UDMVM Universal Decompressor Virtual Machine

UDP User Datagram Protocol

U-Mode Mode Unidireccional

UMTS Universal Mobile Telecommunication System

WIMETRONET Wireless Network for Metropolitan Transports

W-LSB Window-based LSB Encoding

WMAX Worldwide Interoperability for Microwave Access

WMRP Wireless Metropolitan Routing Protocol

WRP Wireless Routing Protocol

ZRP Zone Routing Protocol

14

1 Introdução

Com o avanço das tecnologias que envolvem o protocolo de internet (IP), torna-se fundamental um controlo perfeito do tráfego da rede de modo a fornecer uma melhor QoS aos consumidores. Este avanço provoca um aumento em número e complexidade das redes, obrigando o uso de plataformas que garantem um bom funcionamento nas infra-estruturas de rede.

Uma tecnologia em grande expansão é as redes Ad-Hoc, rede móvel sem fios que oferece inúmeras vantagens em relação às tradicionais. Uma das vantagens é o seu baixo custo, que é fundamental para o mercado competitivo de hoje, de fácil instalação, de característica dinâmica permitindo alterar de forma rápida a sua topologia de rede e independente de qualquer terminal critico para o seu funcionamento, vantagem muito importante porque em caso de falha de algum elemento, a rede não é afectada. Estas redes possuem protocolos usados para fazer o routing da informação entre os diversos nós da rede. Dentro estes protocolos existem os que mantêm em cada nó toda a informação das rotas entre os diversos nós da rede (proactivos), outros que só descobrem a rota entre dois nós da rede quando é necessária (reactivos) e os que utilizam as vantagens dos dois anteriores (híbridos). Qualquer rede Ad Hoc instalada terá o seu routing de informação gerido por um dos protocolos mencionados anteriormente.

Cada vez mais são utilizadas técnicas para diminuir o overhead entre os diversos elementos de uma rede. A compressão de cabeçalhos é uma dessas técnicas que visa diminuir o overhead entre os vários nós de uma rede. A compressão de cabeçalhos permite que pacotes de um fluxo com cabeçalhos iguais não sejam todos enviados com o cabeçalho completo. O funcionamento desta técnica é fazer com que, o primeiro pacote a enviar guarde a informação do cabeçalho do pacote num contexto que existe em ambos os nós de comunicação. Este contexto irá permitir que os pacotes seguintes que possuem o mesmo cabeçalho sejam comprimidos para serem enviados pela rede com um tamanho inferior, de modo a diminuir a largura de banda. O pacote irá recuperar o seu cabeçalho original no nó de destino no momento da descompressão. Este método de compressão pode ser para cabeçalhos TCP, UDP, RTP, IPv4 e IPv6.

Dos modelos já existentes de compressão cabeçalhos, o RoHC (Robust Header Compression) é o mais avançado, uma vez que permite fazer a compressão de muitos tipos de cabeçalho tais como, IP, UDP, RTP e TCP. Além disso o RoCH é o mais robusto para ligações com altas taxas de erros e longos round-trip time.

Neste trabalho pretende-se implementar um modelo de compressão de cabeçalhos, para ser usado sobre o protocolo de routing Wireless Metropolitan Routing Protocol (WMRP), protocolo desenvolvido no âmbito do projecto WiMetroNet, que se encontra em fase de desenvolvimento e que tem como finalidade criar uma rede privada para interligar todos os transportes públicos de modo a fornecer acesso à internet aos seus passageiros.

15

1.1 Problema

Actualmente, muitas aplicações de redes móveis Ad-Hoc envolvem dezenas de nós. Devido ao alargamento das redes o uso de uma maior largura de banda irá provocar que a escalabilidade da rede seja crítica, tornando-a muitas vezes não escalável. Torna-se por isso fundamental aplicar novas técnicas, para tornar este tipo de redes mais consistentes.

Uma das técnicas a usar que possibilita a redução do overhead do tráfego TCP/IP é a compressão de cabeçalhos IP. Técnica que foi originalmente concebida para serem usadas sobre pacotes de dados e controlo em ligações de 1-hop. Neste momento, o problema que existe no uso da compressão de cabeçalhos é de não haver um mecanismo eficiente, que possa ser usado sobre certos tipos de tráfego de multihop de modo a aumentar a sua escalabilidade e diminuir o overhead.

Com este trabalho pretende-se obter o ganho que se pode tirar, ao implementar um mecanismo de integração da compressão de cabeçalhos sobre o protocolo routing proactivo Wireless Metropolitan Routing protocol (WMRP), de modo a que este mecanismo venha a ser usado para suprimir o problema referido.

1.2 Objectivo

Esta dissertação tem como objectivo a implementação e o estudo de

um modelo de compressão de cabeçalhos de routing. O estudo irá focar os protocolos de routing das redes móveis sem infra-estrutura fixa (Ad-Hoc), bem como as principais técnicas já existentes dos diversos esquemas de compressão de cabeçalhos de modo a ser desenvolvido um modelo de simulação de compressão de cabeçalhos sobre uma rede Ad Hoc.

Este cenário de simulação será implementado no NS3 (Network Simulator 3) e constituído por uma rede Ad Hoc, usando como protocolo de routing o WMRP.

1.3 Contribuições Este trabalho tem a seguinte contribuição:

1. Implementação de um modelo de compressão para o WRMP em NS-3

1.4 Organização Esta dissertação está organizada do seguinte modo: Capítulo 2, estado de arte das redes móveis Ad-Hoc com uma descrição dos diversos protocolos de routing. Capítulo 3, estado de arte da compressão de cabeçalhos com uma descrição detalhada sobre o protocolo RoHC. Capítulo 4, descrição do WMRP.

16

Capitulo 5, introdução à simulação de eventos discretos e descrição do NS-3. Capítulo 6, Plano de actividades. Capítulo 7, capítulo que descreve os capítulos futuros que serão acrescentados a este documento.

17

2 Redes Wireless Móveis

2.1 Introdução

As redes wireless móveis são uma tecnologia em expansão, estando

actualmente a ser usadas por um grande número de aplicações. Estas redes estão subdivididas em dois tipos, as que possuem infra-estrutura fixa e as que não têm um controlo centralizado.

Nas classes de rede que possuem infra-estrutura fixa, todos os seus equipamentos da rede ligam-se a equipamentos centrais que fazem todo o controlo de tráfego. Para o routing dos pacotes na rede são usados pontos de acesso, equipamentos que são os responsáveis pela comunicação entre os diversos terminais de rede e os equipamentos centrais.

Nas redes móveis que não possuem uma infra-estrutura fixa são designadas como redes móveis Ad-Hoc Uma rede móvel Ad-Hoc é constituída por nós móveis que comunicam entre si sem o uso de ligações físicas.

As redes Ad-Hoc são usadas em aplicações que requerem uma rápida implementação de uma rede de comunicação como em operações militares, serviços de emergência e conferências.

2.2 Redes Ad-Hoc

As redes Ad-Hoc apareceram nos anos 70 pela U.S DARPA (United States Defense Advanced Research Projects Agency) com o nome PRNET (Packet Radio Network) sendo usadas para comunicações de fins militares para aproveitar a sua característica dinâmica.

Na década de 80 estas redes devido as suas inúmeras vantagens, tais como: 1) baixo custo, 2) característica dinâmica, 3) não depender de terminais críticos para determinar a sua organização; foram exploradas para serem usadas em grandes redes.

As redes Ad-Hoc estão divididas em duas categorias: 1) redes de comunicação directa 2) redes de múltiplos saltos. Na primeira categoria os nós estão todos no mesmo raio de transmissão por isso comunicam-se directamente entre si. Relativamente à segunda categoria os nós já comunicam com nós que não pertencem ao seu raio de acção, para ser possível esta comunicação os nós usam um mecanismo de encaminhamento chamado routing para encaminhar os pacotes até ao nó de destino.

18

2.2.1 Estrutura

Os diversos protocolos de routing podem ser estruturados de duas maneiras: 1)

plana - onde todos os nós estão ao mesmo nível (Figura 1); 2) hierárquica - onde as

informações dos nós são organizadas hierarquicamente (Figura 2).

Figura 1- Estrutura Plana

Figura 2- Estrutura Hierárquica

2.2.2 Classificação

A comunicação entre os diversos nós das redes Ad-Hoc é feita pelos protocolos de routing que podem ser classificados de acordo com o algoritmo de routing ou com a política utilizada no descobrimento das rotas. Em termos de algoritmos de routing os mais utilizados são o Distance Vector e o Link-State. No Distance Vector (DV) todos os nós mantêm uma tabela que armazena a informação da distância para todos os nós de destino. A distância entre os nós é calculada baseada na métrica do número de saltos. No DV os nós trocam informações periodicamente com os seus vizinhos para que as tabelas de routing se mantenham actualizadas. Quando existe múltiplos caminhos para um mesmo nó o caminho mais curto é o escolhido. Um dos protocolos baseados em distance vector é o RIP [1] que tem como principal problema ter uma convergência lenta, problema que conduz ao counting-to-infinity, ou seja, alguns nós incrementam continuamente o número de saltos. No Link-state (LS) os nós mantêm a informação da distância para os seus vizinhos e notificam periodicamente o seu estado actual para todos os elementos da rede. O algoritmo Distance Vector comparado com o método Link-State é computacionalmente mais eficiente, fácil de implementar e requer muito menor espaço de armazenamento. Os protocolos de routing também podem ser classificados como proactivos, reactivos ou híbridos.

19

2.2.3 Protocolos Proactivos

Os protocolos proactivos também chamados “table-driven” mantêm tabelas em todos os seus nós com informações de todas as rotas disponíveis. A informação é periodicamente actualizada através de mensagens broadcast que cada nó envia para detectar ligações a novos vizinhos. A informação obtida no envio destas mensagens é o número de saltos entre os nós.

Estas tabelas com a informação das diversas rotas existentes na rede fazem com que a obtenção de uma rota para o envio de pacotes de um nó de origem para um nó de destino seja directamente conseguida sem recorrer a nenhum método de descoberta de rotas. Este processo traz a vantagem de minimizar o atraso no envio dos dados. No entanto a actualização constante das tabelas causa um uso constante da rede para obter informações de routing e troca de pacotes.

O funcionamento de alguns protocolos pertencentes à categoria de proactivos é descrito de seguida:

2.2.3.1 Destination Sequenced Distance Vector (DSDV) O Destination Sequenced Distance Vector (DSDV)[2] é um protocolo

que surgiu em 1994. Cada nó mantém uma tabela de routing com as rotas para todos os nós da rede. As entradas desta tabela possuem para cada rota o endereço para o destino, o número de saltos e um número de sequência. Este protocolo permite apenas uma rota para cada destino.

O DSDV utiliza updates periódicos e updates que resultam de eventos (mudança topologia) para manter as suas tabelas de routing actualizadas. Estes updates consistem no envio de mensagens por parte dos nós para toda a rede.

2.2.3.2 Wireless Routing Protocol (WRP)

O Wireless Routing Protocol (WRP) [3] protocolo baseado no Distance Vector e mantém em cada nó quatro tabelas: tabela distância, tabela de routing , tabela de custo da ligação e a tabela com retransmissão de mensagem (MRL). Uma entrada na tabela de routing contém a distância para o nó destino, a distância do nó antecessor e sucessor com o caminho mais curto para o nó destino e um marcador para identificar o estado, isto é, se é um caminho simples, um loop ou inválido.. Neste protocolo os nós recebem informações de alterações nas ligações através de mensagens de actualização. Estas mensagens são trocadas somente entre vizinhos e contém as actualizações, e uma lista indicando quais nós devem reconhecer as actualizações. A MRL guarda as actualizações de uma mensagem de actualização que são necessárias ser retransmitidas e que vizinhos devem reconhecer a retransmissão. Se houver uma quebra de ligação entre dois nós, eles notificam os seus vizinhos que modificam as suas tabelas de distância e procuram novos caminhos para outros nós. Os nós aprendem sobre a existência de seus vizinhos através de reconhecimentos e outras

20

mensagens. Se um nó não estiver a enviar mensagens, ele deve enviar periodicamente uma mensagem em broadcast para assegurar a conectividade.

2.2.3.3 Optimized Link State Routing (OLSR)

Em 1998 surgiu o Optimized Link State Routing (OLSR )[4], protocolo que usa na sua rede nós designados multipoint relay (MPR). OS MPR têm a funcionalidade de retransmitir a informação proveniente do nó ao qual estes estão ligados. No OLSR somente os nós seleccionados como MPR é que são responsáveis pelo controlo de tráfego, permitindo assim uma redução do overhead na rede ao diminuir o número de retransmissões entre os nós. Nas figuras 3 e 4 podemos ver o alargamento (flooding) normal de um protocolo proactivo em que todos os nós retransmitem para os seus vizinhos as actualizações e o flooding OLSR que só o MPR é que retransmitem as actualizações. Cada nó neste protocolo terá que seleccionar os seus MPR, a selecção dos MPR por parte de cada nó deve ser feita de modo que a informação deste nó principal seja capaz de atingir todos os nós que estejam a 2 saltos do nó em questão.

Figura 3- Flooding Normal

Figura 4- Flooding OLSR

Quando um nó recebe um pacote OLSR, é examinada em cada

mensagem o seu campo Tipo de Mensagem de modo a determinar o destino das mesmas. Cada nó pode receber a mesma mensagem várias vezes. Para evitar que se volte a processar uma mensagem que já recebida anteriormente cada nó mantém a informação (Duplicate tuple) sobre endereço de destino da mensagem, número de sequência da mensagem, um boleano indicando que a mensagem já foi retransmitida, uma lista das interfaces que já receberam esta mensagem e o tempo em que a informação sobre a mensagem expira. Se um nó recebe uma mensagem desconhecida, então vai ter que aplicar os seguintes mecanismos de routing :

o Se o pacote não tem mensagens (i.e, o comprimento do pacote é menor ou igual ao tamanho do cabeçalho) o pacote deve ser descartado.

o Quando o tempo de vida for 0 a mensagem é descartada.

21

o Caso a mensagem já tiver sido encaminhada, ela é descartada. Para determinar se uma mensagem já foi encaminhada, a base de informações de mensagens duplicadas é consultada.

o Se o último salto da mensagem tiver seleccionado este nó como um MPR, a mensagem é caminhada. Se não, a mensagem é descartada. Para obter a informação que o último nó elegeu este como MPR é consultada o conjunto de selectores MPR da vizinhança.

o Se foi determinado que a mensagem deverá ser encaminhada, o campo Tempo de Vida é reduzido a 1 e o campo Contagem de Saltos é acrescido de 1.A mensagem é, então, transmitida via broadcast em todas as interfaces.

O processamento e routing de mensagens são duas actividades distintas. O processamento é a utilização do conteúdo das mensagens, enquanto que o routing é retransmissão das mensagens para os outros nós. Para as mensagens conhecidas haverá sempre o processamento da mensagem, e este processamento poderá ou não incluir o routing da mesma. Para mensagens desconhecidas só o processo de routing é que é aplicado.

Existe um tipo de mensagens em OLSR que devem obrigatoriamente ser processadas em todos os nós. As mensagens obrigatórias que requerem processamento são as seguintes:

o HELLO- mensagem que realiza a tarefa de detecção de ligações, de

vizinhos e sinalização MPR. o TC – mensagem que realiza a tarefa de declaração de topologia o MID – mensagem que declara a presença de múltiplas interfaces em

um nó

2.2.3.4 Fisheye State Routing (FSR) O Fisheye State Routing (FSR) [5] surgiu em 2000 e é um protocolo do

tipo Link-State (LS). A principal diferença entre o FSR e os tradicionais protocolos LS é a maneira como a informação é divulgada. Enquanto que nos protocolos tradicionais LS qualquer actualização que surja num nos nós da rede é difundida por toda a rede, no FSR as actualizações só são trocadas entre os vizinhos, fazendo que as tabelas são actualizadas só com as informações recebidas pelos vizinhos. O FSR utiliza uma técnica similar à fisheye, técnica que captura com grande detalhe os pixels do ponto focal que está perto e diminui esse detalhe quando o ponto focal aumenta. No caso do FSR ele mantém a informação exacta da distância e um caminho de qualidade para os seus nós vizinhos imediatos e progressivamente reduz este detalhe à medida que a distância aumenta.

Em grandes redes a fim de reduzir o tamanho das mensagens de actualizações, o FSR utiliza diferentes períodos de actualizações para diferentes entradas na tabela de routing.

22

2.2.3.5 Landmark Ad hoc Routing (LANMAR)

Para aumentar a escalabilidade em relação a outros protocolos proactivos surgiu o Landmark Ad hoc Routing (LANMAR) [6] que reduz o tamanho das tabelas de routing e os updates de tráfego. No LANMAR os seus nós formam sub-redes de acordo com os seus padrões de mobilidade. Cada uma das sub-redes tem um nó chamado landmark que funciona como marco para esse sub-rede. Todos os nós mantêm unicamente a informação da topologia dos seus vizinhos e de todos os landmarks que representam as sub-redes existentes. No LANMAR os nós trocam periodicamente informação da topologia e da distância dos nós landmarks de cada sub-rede com os seus vizinhos. Quando algum nó necessita de enviar alguma informação para um destino, a informação de routing pode ser consultada na sua tabela de routing caso o nó de destino esteja na mesma sub-rede, se o nó de destino estiver noutra sub-rede os pacotes serão reencaminhados para o nó landmark da sub-rede onde está presente o nó de destino. O LANMAR torna-se mais eficiente que o FSR porque a informação que necessita trocar sobre a topologia é substancialmente mais reduzida.

2.2.3.6 Topology Dissemination Based Reverse-Path Forwarding (TBRPF)

O Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) [7] é um protocolo que fornece routing ao longo dos caminhos mais curtos para cada destino. Cada nó gera uma árvore de dados baseada na informação da topologia da rede e que é armazenada numa tabela. Para reduzir o tráfego na rede, cada nó reporta apenas uma parte de sua árvore de origem para os nós vizinhos. Utiliza diferentes combinações e periódicas actualizações para manter os vizinhos informados sobre a sua própria topologia de árvore. O TBRPF oferece ainda a possibilidade de enviar informações adicionais da topologia, como por exemplo, a árvore completa, para oferecer uma maior robustez em ambientes altamente móveis. O TBRPF pode ser dividido em dois principais módulos. O primeiro chamado “neighbor discovery”, este módulo é usado para descobrir e aprender informação sobre os nós vizinhos. O segundo chamado “routing ” onde TBRPF realiza a descoberta de nós vizinhos através de mensagens diferenciadas (HELLO), que contem apenas a mudança do estado dos vizinhos. Isto resulta em mensagens muito menores do que as usadas em outros protocolos de link-state.

23

2.2.4 Protocolos Reactivos

Nos protocolos reactivos ou on-demand as rotas são encontrados somente quando um nó deseja comunicar com outro. No momento em que um nó necessita de uma rota para um certo destino da rede, ele inicia um processo de descoberta da rota dentro da rede. Este processo é terminado quando a rota é encontrada ou todas as possíveis permutações foram examinadas. Comparando com os protocolos proactivos têm um overhead menor no controlo da mensagem. Entretanto quando se usa um protocolo reactivo pode existir uma grande latência na rede devido à pesquisa da rota para o destino que pode demorar muito tempo.

2.2.4.1 Dynamic Source Routing (DSR) O Dynamic Source Routing (DSR) [8] é um protocolo de routing reactivo

que surgiu em 1996, foi desenvolvido para ser utilizado em redes ad hoc multi-hop. O protocolo consiste de dois mecanismos: descoberta de rotas e manutenção de rotas. DSR permite múltiplas rotas entre um par origem/destino

O DSR utiliza o conceito de source routing para a entrega de pacotes, ou seja, o nó de origem determina toda a sequência de nós por onde passará o pacote até chegar ao seu destino. Cada nó possui uma tabela onde estão armazenadas todas as rotas conhecidas.

Quando um nó necessita de encaminhar um pacote a um destino, este nó de origem verifica se possui na sua tabela alguma rota para esse nó. Caso exista uma rota, será usada para o encaminhamento do pacote, caso contrário, é iniciado o processo de descoberta de rotas para encontrar dinamicamente um caminho para o destino tal como é ilustrado na figura seguinte.

Figura 5- Descoberta da Rota DSR

24

A Figura 6 ilustra a descoberta de uma nova rota no DSR. O processo de funcionamento consiste quando um nó fonte deseja enviar alguma mensagem para um destino e não tem a rota ele inicia o processo de descoberta da rota enviando um pedido em broadcasts de criação de rota (RREQ) para os seus vizinhos, estes, caso não sejam os destinatários vão inserir o seu endereço no pacote RREQ e vão difundir este pedido pelos suas saídas. Este processo é terminado quando a rota for encontrada ou porque chegou ao nó de destino ou devido a um nó intermédio saber o caminho para a rota pretendida. Na figura 6 está ilustrado a mensagem de resposta (RREP) à RREQ, mensagem unicast e é enviada pelo caminho mais curto

Figura 6 – Route Reply DSR

Existe uma outra mensagem, a mensagem de erro na rota (RERR) que é usada para informar que uma das rotas foi quebrada. Cada nó ao receber um RERR irá remover da sua tabela de routing essa rota.

2.2.4.2 Ad hoc On Demand Distance Vector (AODV) Em 1997, surgiu Ad hoc On Demand Distance Vector (AODV)[9] baseado em outros dois protocolos de routing para redes ad hoc, o DSR e o DSDV. É um protocolo reactivo, baseado em Distance Vector, que minimiza o número de broadcasts da rota criando rotas on-demand, ao contrário de manter uma lista completa das rotas como no algoritmo de DSDV o que limita a sua escalabilidade. O AODV para evitar a ocorrência a formação de loops usa números de sequência e os seus nós periodicamente trocam mensagens hello com os seus vizinhos para detectar quebras de ligações. Isto vai provocar overhead.

Em termos de descobertas de rotas é similar ao DSR, as rotas só são descobertas apenas quando são necessárias, utilizando os mecanismos de descoberta de rotas e manutenção de rotas iguais ao DSR. O AODV armazena a informação de routing nas tabelas de routing dos nós activos ao longo da rota, enquanto que no DSR a informação é toda transportada no pacote de dados.[ref9]

25

2.2.4.3 Temporally Ordered Routing Algorithm (TORA) Temporally Ordered Routing Algorithm (TORA) [10] protocolo reactivo baseado no conceito de inversão da ligação (link reversal ). Proposto para ser utilizado em redes altamente dinâmicas. Protocolo do tipo source-initiated e possui múltiplas rotas para o mesmo par origem/destino. O TORA executa basicamente três funções, sendo elas, criação de rotas, manutenção de rotas e eliminação de rotas. No processo de criação a fonte envia um pacote solicitando a rota para o destino desejado. Este pacote se propaga pela rede até chegar ao destino ou até que algum nó intermediário que possui uma rota válida. Assim quando a rota for descoberta é enviado uma resposta para a fonte contendo a altura do nó destino, ou seja, quantos saltos são necessários para que a informação chegue até o seu destino. O processo de manutenção de rotas ocorre quando se percebe uma quebra no link. O nó então faz uma verificação de rota e ajusta a sua altura para a nova configuração. A eliminação da rota ocorre quando existe uma fragmentação da rede. É informado assim a necessidade de se retirar estas rotas das tabelas.

2.2.4.4 Ad-Hoc On Demand Multi-Path Distance Vector Routing (AOMDV)

O Ad Hoc On Demand Multi-Path Distance Vector routing (AOMDV) [11], surgiu em 2001, extende o AODV para fornecer multi-paths. No AOMDV cada RREQ e RREP definem um caminho alternativo para a origem e o destino. Múltiplos caminhos são mantidos nas tabelas de routing de cada nó. Cada entrada na tabela de routing contem uma lista do próximo salto juntamente com o número de saltos (hop-count) para cada destino. O AOMDV para assegurar caminhos loop-free , introduz o valor advertised_hop_count no nó i para o destino d. Este valor indica o máximo hop-count para o destino d do nó i. Um caminho alternativo entre o nó i e o destino d, só é aceite se o hop-count é menor que o advertised_hop_count. Nas figuras 7 e 8 temos ilustrado as tabelas de routing do protocolo AODV e AOMDV, podemos ver que a diferença entre eles é que o AOMDV suporta um lista de rotas para vários caminhos, enquanto que o AODV só tem a possibilidade de guardar a informação de 1-Hop.

26

Figura 7- Tabela Routing AODV

Figura 8- Tabela Routing AOMDV

2.2.4.5 Dynamic MANET On-Demand (DYMO) O Dynamic Manet On-Demand (DYMO) [12] que surgiu em 2005, é usado para redes móveis de multihop. É o sucessor do AODV porque usa várias das características do e tem algumas melhorias como uma maior facilidade de implementação. O DYMO o seu funcionamento consiste em duas operações básicas: 1) Descoberta de rotas, 2) Manutenção das rotas. Na descoberta de rotas, o nó de origem difunde as mensagens RREQ pela rede toda com o objectivo de encontrar o nó de destino. Durante a procura de uma nova rota, os nós intermédios guardam a informação da rota para o nó de origem. Quando o nó de destino é encontrado, este envia a mensagem RREP pela rota encontrada, os nós intermédios neste caso vão guardam a informação com a rota para o nó de destino. Relativamente à manutenção, quando existe uma quebra de ligação ou uma rota não é mais conhecida, o último nó que detecta que não existe a rota envia a mensagem RERR para o nó de origem. O nó de origem ao receber o RERR inicia um novo processo de descoberta de rotas.

27

2.2.5 Protocolos Híbridos

Os protocolos de routing Híbridos combinam as vantagens dos

anteriores para superar algumas lacunas existentes em cada um e para resolver problemas específicos. De seguida é descrito um dos protocolos híbridos.

2.2.5.1 Zone Routing Protocol (ZRP)

O Zone Routing Protocol (ZRP) [13] protocolo híbrido que divide a em duas zonas de routing , intra-zona e a inter-zona executando protocolos independentes para comunicação em cada uma dessas zonas.

O ZRP utiliza um protocolo proactivo para routing intra-zona, através do módulo Intrazone Routing Protocol (IARP). Para que um nó saiba as rotas para todos os nós dentro da zona de routing , cada nó possui uma tabela de routing que indica qual a rota para cada nó pertencente a sua zona de routing . Esta característica permite uma redução na largura de banda e um limite no tamanho da tabela de routing

O desempenho do ZRP está directamente ligado ao raio das zonas. Redes densas com nós em grande movimentação geralmente resultam em zonas de routing pequenas. Redes com pouca movimentação de nós resultam em zonas de routing maiores.

A construção de uma zona de routing requer que o nó inicialmente descubra quem são seus vizinhos. Com base nesses dados e em medidas locais de tráfego um nó pode estimar a sua melhor zona de routing . O routing inter-zonas é realizado por um protocolo reactivo, denominado Interzone Routing Protocol (IERP). Para se alcançar os nós fora da zona de routing , o ZRP faz um pedido de rota para seus nós periféricos. Caso algum destes nós possua a rota para o destino solicitado, esta é enviada ao nó solicitante. Se os seus nós periféricos não possuírem a rota, estes enviam um pedido para seus respectivos nós periféricos, e assim sucessivamente até que se obtenha uma rota para nó requisitado. Com isto, ocorre um atraso na determinação de rotas para nós fora da zona de routing

28

2.2.6 Comparação Tabela 1- Tabela de comparação dos diversos Protocolos de Routing

Tipo

Protocolo

Destino

Updates

Período

Updates

Estrutura Multipath Escalabilidade

(Diminui)

Overhead

(Aumenta)

DSDV Proactivo Vizinhos Periodicamente

e

Mudança

topologia

Plana NÃO O (N) O(N)

WRP Proactivo Vizinhos Periodicamente

e

Mudança

topologia

Plana NÃO O (N*A) O (N)

OLSR Proactivo Vizinhos

(MPR)

Periodicamente

Plana NÃO O (N) O (N)

FSR Proactivo Vizinhos Periodicamente

(diferentes

frequências)

Plana SIM O (N*A) O (N)

LANMAR Proactivo Vizinhos Periodicamente

Hierárquica SIM O (L)+O(G) O (N)

TBRPF Proactivo Vizinhos Periodicamente

Plana NÃO O (N) O (N)

DSR Reactivo Fonte Mudança

topologia Plana SIM O (2N) O (2N)

AODV Reactivo Fonte Mudança

topologia Plana NÃO O (2N) O (2N)

AOMDV Reactivo Fonte Mudança


DYMO Reactivo Fonte Mudança


TORA Reactivo Vizinhos Mudança

topologia Plana SIM O (N*A) O (2N)

ZRP Híbrido Vizinhos Periodicamente

Hierárquica SIM O (L)+ O(e) O (N)

N: número de nós da rede A: número médio de nós vizinhos L: número médio de nós na zona (scope) G: número de grupos lógicos em LANMAR e- número de pares de comunicação

Na tabela 1, estão ilustradas as características chave dos diversos protocolos analisados neste trabalho. Uma das características são os updates, nos proactivos os updates são todos periódicos e têm como destino os vizinhos, enquanto que nos reactivos só têm updates quando surge alguma mudança da topologia da rede e têm como destino o nó de origem. Podemos também observar que em todos os protocolos com estrutura plana à medida que o número de nós (N) vai incrementando a escalabilidade vai diminuir e o overhead aumenta, nos que têm estrutura hierárquica a sua escalabilidade e

29

overhead vai aumentar e diminuir com o número nós e grupos existentes em cada zona.

2.2.7 Conclusões Os protocolos descritos tentam mostrar as várias estratégias usadas para fazer o routing da informação para vários ambientes de rede. Podemos ver que em protocolos com a mesma classificação possuem características diferentes que por vezes foram desenvolvidas para melhorar algumas lacunas existentes em protocolos anteriores. Nos protocolos proactivos em que a informação da topologia da rede está toda nos seus nós vimos que os problemas como counting-to-infinity são minimizados com os protocolos DSDV e WRP. O OLSR trouxe uma nova técnica que permite a redução do overhead de routing ao fazer com que a informação de um nó não seja transmitida para todos os seus nós vizinhos mas sim unicamente para os nós MPR. No FSR baseado no protocolo LS utiliza diferentes períodos de actualizações para diferentes entradas na tabela de routing e não difunde as actualizações pela rede toda mas só pelos seus vizinhos o que provoca uma redução do seu tráfego. Para aumentar significativamente a escalabilidade surgiu o LANMAR que mantém em cada a informação dos nós da sub-rede que pertence e a informação dos nós landmarks de todas as sub-redes existentes. TBRPF permite tal como o LANMARK uma maior escalabilidade pois envia para os seus vizinhos somente as diferenças que existem entre um nó e outro. Relativamente aos protocolos reactivos em que as rotas somente são encontradas quando são necessárias provocando assim uma largura de banda reduzida. Dos protocolos analisados DSR, AODV e TORA vimos que têm características idênticas como é o caso do descobrimento de rotas mas existem algumas características que diferem entre protocolos. Foi visto que o DSR e o AODV as actualizações são usadas no nó de origem enquanto que no TORA as mensagens de actualização tem como destino os vizinhos. O AODV suporta multicast enquanto que o DSR e o TORA já não têm essa capacidade. Em contraste o DSR e o TORA suportam ligações unidireccionais. Relativamente aos protocolos DYMO e AOMDV, são protocolos que vieram trazer melhorias ao AODV principalmente o multipath. Por fim, foi visto neste capítulo os protocolos híbridos, que combinam as características dos protocolos proactivos e reactivos. Um exemplo destes protocolos foi o protocolo analisado ZRP (Zone Routing Protocol) que estabelece duas zonas, uma onde é aplicado as características do protocolo proactivo e a outra que usa as propriedades dos protocolos reactivos para descobrir a rota que vai usar para enviar a informação. Estes protocolos são adequados para redes Ad-Hoc com muitos nós.

30

2.3 Redes Mesh (IEEE 802.11S)

As Redes mesh [14] (rede malha sem fio) são redes que têm uma topologia dinâmica, variável e estão em desenvolvimento. São um sistema autónomo de routers móveis podendo funcionar isoladamente ou ligar-se a uma rede fixa através de gateways. A topologia de uma rede mesh é alterada quando um router é retirado ou necessita de ajustar alguns dos seus parâmetros de transmissão e recepção Estas redes evoluíram a partir das redes Ad-Hoc, mas ao contrário das Ad-Hoc que têm um uso limitado na largura banda as redes mesh são uma alternativa económica às redes de banda larga. São usadas para transmitir dados e voz de uma forma diferente do tradicional cabo ou de redes wireless. Neste tipo de redes os nós estão conectados a um ou a diversos nós, tornando-se possível transmitir informação de um determinado nó para outro através de caminhos diferentes. Este tipo de redes são fiáveis porque fornece caminhos redundantes entre o emissor e o receptor, elimina as falha das ligações únicas o atraso o que permitem operar durante um período extenso de tempo. São redes de rápida implementação e modificação e de razoável custo, características extremamente importantes para os dias de hoje para o competitivo mercado. As redes mesh têm uma área de cobertura ampla porque a comunicação entre os routers mesh e transmissão de longo alcance WiMax permite comunicações de longa distância sem afectar significativamente o desempenho. Tal como foi mencionado anteriormente estas redes são dinâmicas em termos de configuração e organização, porque os clientes e routers mesh estabelecem e mantêm automaticamente a conectividade entre si. Por exemplo, quando um nó é adicionado na rede é activado as funcionalidades de meshing para automaticamente descobrir todas as possíveis rotas e determinar um caminho óptimo para este nó se ligar à Internet. É invulgar que a camada MAC seja responsável por assegurar o transporte de uma frame até ao seu destino, normalmente isso processo é feito pela camada de rede. No IEEE 802.11s, podemos utilizar o protocolo Hybrid Wireless Mesh Protocol (HWMP) para fazer o transporte dos pacotes ao nível da camada de MAC, porque este protocolo é um protocolo de camada MAC, ou seja usa endereços MAC e não endereços IP. O HWMP é um protocolo Hibrido que combina ambos os dois processos de routing, proactivo e reactivo. Se existe uma gateway para fazer a ligação a outro tipo de redes, o HWMP usa o routing proactivo para encontrar e manter a rota para este nó. O protocolo reactivo usado para fazer o routing entre os nós da rede mesh usa as características do AODV. Uma rede Mesh pode ser configurada para trabalhar a nível da camada MAC, usando o protocolo HWMP, ou usando os convencionais protocolos de routing para a camada de rede.

31

2.4 Wireless Network for Metropolitan Transports (Wimetronet)

No intuito de oferecer uma melhor qualidade de serviço aos seus passageiros os transportes públicos (metro, comboios, táxis, autocarros) têm vindo a enfrentar novos desafios. O estudo de um novo cenário para melhorar o conforto dos passageiros tem vindo a ser feito pelo projecto WiMetroNet [15]. O WiMetroNet é uma rede mesh, auto configurável que opera na camada 2.5 sobre tecnologias heterogéneas wireless. Tem como objectivo interligar veículos, paragens e centros de controlo numa rede privada de modo a fornecer acesso à internet e conteúdos multimédia (multicast, streaming) aos passageiros. Cada veículo está equipado com um equipamento de comunicação -Rbridge- que gera o acesso de banda larga wireless a um ou mais pontos de acesso WLAN, que estão localizados no interior de um veículo. Temos ilustrado na figura 9 um esquema de como está estruturada a rede do WiMetroNet

Figura 9- Esquema WiMetroNet

O WiMetroNet é uma tecnologia que utiliza o Multi Protocol Label Switching (MPLS) [15] como tecnologia de rede, o Wireless Metropolitan Routing Protocol (WMRP) como protocolo de routing, suporta mobilidade, lida com tráfego broadcast e mecanismos de segurança para autorização, autenticação e confidencialidade. O MPLS é um protocolo em que as suas técnicas podem ser aplicadas em todos os protocolos de rede da camada 3. O funcionamento do MPLS

32

consiste em adicionar à entrada de uma rede uma label nos pacotes que permitirá que todo o encaminhamento seja feito tendo por base a informação contida na label. O WMRP é um protocolo de routing proactivo, link state, baseado no OLSR e que trabalha sobre a camada 2. O capítulo 4 descreve detalhadamente este protocolo.

33

3 Compressão de Cabeçalhos

3.1 Introdução

Dada a enorme evolução das redes no intuito de fornecer uma maior largura de banda e uma melhor qualidade de serviço (QoS) às aplicações, serviços e consumidores, o uso de técnicas de redução de overhead torna-se cada vez mais importante de modo que os recursos disponíveis sejam utilizados da forma mais eficiente.

Uma das técnicas usadas é a compressão de cabeçalhos IP, permite a redução do tamanho dos cabeçalhos IP provocando um Ganho em relação ao overhead da rede, ou seja, diminuiu. A compressão tem como objectivo eliminar os campos do cabeçalho que têm redundância, ou seja, campos que já tenham sido calculados noutros pacotes. Esta técnica é usada para fazer a compressão de cabeçalhos TCP, UDP, RTP, IPv4 e IPv6.

Na compressão de cabeçalhos o pacote inicial de um fluxo é enviado entre o emissor e receptor contendo o cabeçalho completo, a informação do cabeçalho deste pacote vai ser guardada quer na origem e destino num contexto (figura 10), esta informação armazenada irá permitir que os cabeçalhos dos próximos pacotes sejam comprimidos na origem e no destino sofram o processo inverso, ou seja, o cabeçalho é descomprimido ficando novamente com a informação inicial.

Figura 10- Arquitectura Header Compression

Podemos classificar na compressão de cabeçalhos quatro categorias de

campos no cabeçalho: 1) Constant – campo que não muda entre cabeçalhos num determinado protocolo de sessão, conexão ou contexto. Incluem normalmente o endereço de destino e origem; 2) Delta - campos que sofrem de uma pequena mudança e não mudam a cada momento. Um dos exemplos deste campo é número de sequência TCP; 3) Inferred – campos determinados baseados em outras informações conhecidas. Por exemplo, o campo do tamanho do pacote pode ser derivada da camada subjacente; 4) Random – campos que não têm um padrão regular e que devem ser enviados inalterados, exemplo o checksums. Na Figura 11 temos um esquema típico de um cabeçalho comprimido, onde o primeiro campo é constituído pelo Context ID (CID), este campo identifica qual o contexto a usar na descompressão, de

34

seguida temos o campo que indica quais os valores delta foram alterados, os últimos dois campos estão ilustrados os campos Delta e Random:

Figura 11- Cabeçalho Comprimido

3.2 Evolução A compressão de cabeçalhos teve uma grande evolução desde o primeiro esquema de compressão desenvolvido até aos dias de hoje. Nos pontos seguintes iremos mostrar a evolução dos diversos protocolos de compressão de cabeçalhos. 3.2.1 Thinwire

Em 1984 surgiu o primeiro esquema de compressão de cabeçalhos chamado Thinwire [17], este protocolo permitia uma compressão de 40bytes TCP/IPv4 para 17bytes. No seguimento do Thinwire surgiu o Thinwire II que usava técnicas mais complexas permitindo a compressão dos 40Bytes para 13 bytes.

3.2.2 Compression TCP (CTCP)

Nos anos 90, Van Jacobson concebeu um esquema para compressão de cabeçalho TCP, esta compressão desenvolvida por Van Jacobson conseguia reduzir os 40bytes em 3bytes, técnica esta que oferecia uma melhor performance de compressão relativamente ao Thinwire II, este mecanismo de compressão foi designado por CTCP [18]. Nesta técnica de compressão foi também introduzido um mecanismo de recuperação de erros no qual permitia ao compressor detectar retransmissões. O compressor ao detectar que um pacote não tenha sido entregue envia um pacote completo de modo a sincronizar a informação contida nos contextos

35

3.2.3 IP Header Compression (IPHC) Em 1999, foi introduzida a técnica de compressão IP Header Compression (IPHC) [19], mecanismo de compressão que trouxe melhorias ao cTCP ao introduzir a possibilidade de comprimir cabeçalhos IP (IPv4 e IPV6), cabeçalhos UDP e outros cabeçalhos de outras camadas, como por exemplo o RTP. O IPHC permite a compressão dos cabeçalhos dos pacotes UDP e TCP até 4-7bytes. No IPHC quando a compressão é efectuada em pacotes que não sejam TCP, ao surgir alguma alteração nuns dos campos o compressor envia um pacote com o cabeçalho completo para ser construído um novo contexto no terminal de descompressão. Para prevenir que a descompressão dos cabeçalhos seja correcto, ou seja, para que não ocorra perda de pacotes com cabeçalho completo todos os cabeçalhos são identificados com um número que é gerado no momento da compressão. Isto leva que no momento que seja feita a descompressão se o número for diferente, o pacote é descartado ou armazenado até que o próximo pacote completo restabeleça o contexto. IPHC tem um mecanismo de recuperação de erros que permite quando a descompressão falha na reparação de um contexto é enviado um pedido ao compressor (NACK) para ser enviado o cabeçalho completo.

3.2.4 Compression RTP (CRTP)

Desenvolvido ao mesmo tempo que o IPHC e baseado nele surgiu o protocolo CRTP [20], foi definido para comprimir cabeçalhos IP/UDP/RTP. Este protocolo se o checksum UDP estiver desactivo é capaz de comprimir o cabeçalho RTP no mínimo de 2 bytes, e 4 bytes se o checksum estiver activo. As técnicas utilizadas por este protocolo são as mesmas usadas para o tráfego TCP, suprime os campos estáticos, aplica a codificação diferencial para trocar os campos e elimina mudando campos cuja variância seja previsível. Na detecção de erros, este protocolo adiciona no pacote um número 4bits que vai ser usado para detectar a perda de pacotes. Quando este número de sequência do contexto for incrementado por um outro valor que não seja o 1, o processo de descompressão invalida este contexto e envia um NACK para o compressor. Todos os pacotes serão ignorados até o contexto esteja reparado. Se a ligação tiver um longo round-trip time e se tiver uma grande largura de banda, muitos pacotes consecutivos podem ser descartados antes de o contexto ser reparado. Outro problema que pode resultar quando existe um contexto corrompido é a reordenamento de pacotes. Foi demonstrado que o CRTP não é robusto quando existe perdas consecutivas de pacotes entre os terminais de compressão, o que provoca que este protocolo não seja recomendado para telefonia IP sobre ligações wireless.

36

3.2.5 Enhanced Compressed RTP (ECRTP) Em 2003 foi desenvolvido ECRTP [21] para suprimir algumas lacunas do CRTP. As trocas que existem entre o CRTP e ECRTP são as seguintes: 1) o formato da compressão do pacote UDP é modificado para permitir a actualização de valores RTP diferenciais no contexto do descompressor. Os valores RTP que podem ser seleccionados para serem actualizados são: número de sequência, timestamp, payload e o CSRC. Isto permite que o contexto mantenha-se sincronizado mesmo quando existe algumas perdas de pacotes. 2) Header Checksum (HDRCHKSUM) o pacote UDP pode ser enviado com checksum zero. Isto provoca que a recuperação não seja permitida na descompressão. Para fazer face à falta de checksum UDP, o compressor insere um novo cabeçalho em todos os pacotes comprimidos. Isto permite que o descompressor verifique se o contexto não ficou dessincronizado após a perda de pacotes. O ECRTP usa dois tipos de compressões UDP, tradicionais e estendida. A tradicional somente é comprimido campos IP/UDP e podem actualizar todas as diferenças de primeira ordem para os campos DELTA no contexto. A compressão estendida comprime por inteiro os cabeçalhos IP/UDP/RTP e podem actualizar todas as diferenças de primeira ordem dos campos DELTA.

37

3.3 Robust Header Compression (RoHC)

Devido a limitações de largura de banda, os pacotes IP/TCP/RTP/UDP enviados sobre ligações com alta taxa de erros (BER) e longos round-trip times (RTT) beneficiam das técnicas de compressão de cabeçalho de modo a existir uma boa qualidade de serviço neste tipo de ligações. Os esquemas de compressão mencionados nos capítulos anteriores não têm uma boa performance quando são usados para este tipo de ligações. Foi emergente desenvolver um protocolo de compressão de cabeçalho que fosse robusto para trabalhar sobre estas ligações, uma vez, que este tipo de tecnologia esta cada vez mais a ser usada pelo público em geral

Em 2001 surgiu o ROHC [22] (Robust Header Compression), protocolo de compressão capaz de comprimir muitos tipos de cabeçalhos, tais como IP, UDP, RTP e TCP. O ROCH é robusto para ligações de BER e RTT, sendo por isso mais eficiente que os outros esquemas de compressão de cabeçalhos.

3.3.1 Arquitectura

Tal como podemos ver na figura 12 o ROHC tem uma arquitectura similar aos outros esquemas de compressão. A arquitectura ROHC é constituída pelos seguintes blocos: 1) Nó de origem (S), bloco que envia o pacote de entrada para o compressor, 2) Compressor (C) comprime os pacotes de acordo com o perfil, modo e estado transmitindo de seguida os pacotes resultantes deste mecanismo, 3) Descompressor (D) restaura o pacote original e transmite para o nó de destino, 4) Nó de destino (O) aplicação que descodifica informação original para um fluxo de pacotes de saída.

Figura 12 - Arquitectura RoHC

3.3.2 Estados de Compressão e Descompressão

O ROHC pode ser caracterizado como a interacção entre duas máquinas de estado, uma máquina é o compressor e a outra o descompressor. O compressor e o descompressor têm três estados de operação, no o compressor os estados são: Initialization e Refresh (IR), First Order (FO) e Second Order (SO). Inicialmente o compressor inicia sempre com o estado mais baixo (IR) e transmite gradualmente para o estado mais alto. O compressor pode decidir o estado necessário de compressão baseado em variações dos cabeçalhos do pacote, no feedback do descompressor (positivo (ACKs) ou negativo (NACKs) ou no timeout dos eventos.

38

� Initialization and Refresh (IR) – a finalidade deste estado é de inicializar a parte estática do contexto no descompressor ou recuperar de uma falha. Neste estado o compressor envia o cabeçalho completo. Isto inclui todos os campos estáticos e não estáticos que ainda não foram comprimidos e mais algumas informações adicionais. O compressor permanece neste estado até que o descompressor tenha recebido a informação completa.

� First Order (FO) – este estado comunica eficientemente irregularidades no

fluxo de pacotes. Quando se está operar neste estado, o compressor raramente envia informação sobre todos os campos estáticos, a informação é enviada parcialmente comprimida. Neste estado somente alguns campos estáticos são actualizados. Ele permanece neste estado até que o compressor tenha adquirido todos os parâmetros do novo modelo. Alguns ou todos os pacotes enviados por este estado levam a uma actualização na informação do contexto.

� Second Order (SO) – Estado onde a compressão é óptima. O compressor

entra neste estado quando o cabeçalho a ser comprimido é totalmente previsível dado um SN (número sequência RTP) e o compressor tem a certeza que o descompressor adquiriu todas os parâmetros de funções de SN de outros campos. A descompressão correcta enviada pelo estado SO só depende da descompressão correcta do SN. Todavia, o êxito da descompressão também exige que a informação enviada pelo estado FO tenha sido recebida pelo descompressor.

Relativamente ao Descompressor tem os seguintes estados: � No Context (NC) – estado mais baixo, enquanto o descompressor estiver no

estado NC, ainda não descomprimiu com êxito o pacote. Depois de o pacote ser descompactado correctamente (por exemplo, aquando a recepção de um pacote de inicialização com informações estáticas e dinâmicas), o descompressor pode transitar para o estado full context (FC) e só se houver falhas é que retorna aos estados anteriores.

� Static Context (SC) – o descompressor só opera neste estado quando for detectado algum erro no estado full context (FC). Para transitar novamente para o estado FC basta que receba qualquer pacote enviado pelo estado FO. Ele poderá transitar também para o estado NC caso exista várias falhas de descompressão de cabeçalhos enviados pelo FO.

� Full Context (FC) – estado mais alto, estado em que os cabeçalhos são

descomprimidos correctamente. O descompressor só sairá deste estado caso surja algum erro.

Podemos ver na figura 13 representada as transições entre os estados do descompressor

39

Figura 13- Estados do Descompressor

3.3.3 Modos Operação

Além dos estados, que determinam o nível de compressão existe também modos de operação diferentes. Estes modos de operação controlam o estado lógico das transições e quais as acções a executar em cada estado. O corrente modo de operação pode ser trocado se o descompressor indicar através do canal feedback o modo a trocar. O RoHC usa os seguintes modos:

Unidireccional (U-Mode) – modo de operação em que os pacotes são enviados somente numa direcção do Compressor para Descompressor. Transições entre os estados de compressão são realizadas somente quando houver timeout nos eventos ou irregularidades no fluxo de entrada. Este estado não tem feedback para dar inicio de recuperação de erros, o que torna este estado menos eficaz que os outros dois. A compressão com RoHC deve iniciar-se neste modo. A transição para qualquer dos outros modos pode ser executado logo que um pacote chegue ao descompressor e este envie um feedback indicando o modo de transição desejado.

Bidireccional optimistic (O-Mode) a diferença para o U-Mode é que o canal feedback do Descompressor para Compressor é usado para enviar pedidos de recuperação de erros e actualizações significativas no contexto. Neste modo não usa o refrescamento da informação do contexto. O objectivo deste modo visa maximizar a compressão eficientemente e escassear o uso do canal feedback. Ele reduz o número de cabeçalhos danificados entregue às camadas superiores devido a erros ou contexto inválido. A frequência de contextos inválidos poderá ser superior do que o R-mode, em particular quando existe um grande número de erros.

Bidirectional realible (R-Mode) – este modo usa o canal feedback mais intensivamente e tem uma lógica mais rigorosa que assegura um sincronismo no contexto mais robusto. Este modo visa maximizar a robustez contra a perda e danos mesmo quando existe uma alta BER. Este modo pode ter uma menor probabilidade de contextos inválidos do que o O-Mode, mas um maior número de cabeçalhos danificados podem ser entregues quando o realmente o contexto é inválido.

40

Figura 14- Estados e Transições do Compressor

Figura 15- Transições dos Modos de Operação

3.3.4 Parâmetros do canal e do contexto

O protocolo ROHC é baseado num conjunto de parâmetros que são utilizados para fazer a comunicação entre o canal e o contexto. Em termos de parâmetros no canal temos: MAX_CID:valor inteiro não negativo usado para identificar o maior número ID do contexto a ser utilizado pelo compressor; LARGE_CIDS boleano que caso seja falso o campo CID terá 0 a 1 bytes abrangendo 0 a 15 CIDs, se for verdadeiro o tamanho campo CID poderá ter 1 a 2 bytes podendo abranger 0 a 16383 CIDs; PROFILES, conjunto de inteiros não negativos que indica o perfil suportado pelo descompressor, FEEDBACK_FOR parâmetro que indica qual o canal que é enviado um feedback sobre este canal; Maximum reconstructed reception unit (MRRU): indica o tamanho máximo de octetos do pacote, incluindo o CRC, construído a partir de segmentos que o descompressor permite. Relativamente aos parâmetros por contexto determinam que tipos de pacotes serão usados, se for 0x0000 é enviado um pacote IP descomprimido;

41

0x0001 indica um perfil que usará compressão de RTP/UDP/IP; 0X0002 para compressão UDP/IP e 0x0003 compressão ESP/IP.

3.3.5 Pacotes RoHC

O formato do pacote RoHC é composto pelos campos Padding, Feedback, Header e Payload. O campo Padding é constituído por zero ou mais paddings octetos, este campo é usado para ligações que necessitam que o pacote tenha um tamanho mínimo. O Feedback transporta informação do descompressor para o compressor enviando esta informação em pacotes individuais ou em pacotes encapsulados comprimidos (piggybacked), os pedidos existentes neste campo são os seguintes: 1) ACK – informação que indica que o pacote foi bem descompactado, 2) NACK – indica que a informação do campo dinâmico está errada, por isso o pacote não é descompactado, 3) STATIC-NACK – indica que o contexto estático do descompressor não é válido.Em relação ao campo Header temos os seguintes pacotes: Initialization and Refresh (IR), transporta informação dos campos estáticos bem como parâmetros dos campos dinâmicos; o header pode ser definido pelo seu perfil, mas no entanto deverá ter um CID (context Identifier) de 1 a 2 octetos. O CID pode ser eliminado se existir um só contexto num dado canal.

Figura 16- Estrutura do pacote RoHC

3.3.6 Métodos de codificação

Neste capítulo está descrito alguns dos métodos de codificação usados para os campos do cabeçalho.

3.3.6.1 Least Significant Bit (LSB) encoding A codificação LSB é aplicada em campos do cabeçalho que sofram pequenas variações. Nesta codificação só são transmitidos os k LSB em vez do valor original. Estes bits transmitidos são recebidos pelo descompressor que vai obter o valor original através de um valor de referência (v_ref). É usado neste método um intervalo de interpretação para garantir que a codificação e descodificação seja correcta. Neste intervalo reside o valor original e é o único valor que tem os mesmos k LSB transmitidos. O intervalo de interpretação pode ser descrito como a seguinte função:

42

<---------- Intervalo Interpretação (2^k) ------> |-------------+---------------------------------------| v_ref - p v_ref v_ref + (2^k-1) - p

Figura 17- Função LSB

Esta função tem a seguinte propriedade, para qualquer k, os k LSB devem unicamente identificar um valor em f (vref, k). O parâmetro p é usado para que o intervalo de interpretação possa ser deslocado em relação ao vref. Ao escolher um bom valor para o p a codificação será mais eficaz para os campos com as seguintes características:

1. Para valores dos campos que incrementam, o p=-1 logo: f(vref, k)=[vref+1, vref+2^k ]

2. Para campos que não incrementam, p=0 f(vref, k)=[vref, vref+(2^k-1) ]

3. Para campos que variam ligeiramente, p= 2^(k-1)-1 f(vref, k )= [v_ref - 2^(k-1) + 1, v_ref + 2^(k-1)].

4. Para campos que se prevê que venham a sofrer pequenas mudanças negativas e grandes mudanças positivas, p=2^ (k-2) – 1

f(vref, k) = [v_ref - 2^(k-2) + 1, v_ref + 3 * 2^(k-2)], O compressor (descompressor) usa sempre o valor vref_c (vref_d) como o último valor comprimido (descomprimido) vref que tenha sido verificado pelo CRC.

3.3.6.2 Window-based LSB encoding (W-LSB encoding) Codificação que fornece robustez à codificação LSB quando o compressor não é capaz de determinar com exactidão o valor de referência, vrefd, que será usado no descompressor. O descompressor usa sempre como referência o último valor recebido verificado pelo CRC, o compressor mantém uma janela deslizante de possíveis valores vrefd, janela que inicialmente está vazia. O compressor aplica as seguintes operações à janela deslizante:

43

1. Depois de um valor v (comprimido ou descomprimido) ser enviado e verificado pelo o CRC, o compressor adiciona este valor à janela.

2. Para cada valor v comprimido, o compressor escolhe um k = max(g(v_min,v) , g(v_max,v)), onde v_min e v_max são os valores mínimos e máximo da janela e g é a função f definida na método de codificação LSB.

3. Quando o compressor sabe que certo valor v e todos os valores maiores do que v não serão usados como v_ref no descompressor, a janela irá eliminar esses valores incluindo v. Os meios usados para determinar se o valor v vai ser usado como v_ref são os seguintes:

1. um ACK do descompressor implica que os valores

maiores do que ACKed possam ser removidos da janela deslizante.

2. uma janela com uma largura limite

3.3.7 RoHC para Multicast

Um das dificuldades que existe na compressão de cabeçalhos é manter o sincronismo entre o contexto do descompressor e do compressor [23]. Quando a compressão de cabeçalhos é usada numa ligação peer-to-peer este sincronismo é mantido através do uso de canais feedback que transmitem ACKs caso exista algum problema no lado do descompressor. No caso de a comunicação ser multicast podemos utilizar estes canais bidireccionais para o envio ACKs, mas o uso destes canais nas comunicações multicast irá fazer com que a eficácia de compressão diminua, uma vez que o compressor poderá ter que processar diversos pedidos provenientes dos canais de feedback. Quanto mais membros existir menor será a eficiência da compressão de cabeçalhos. Devido a este problema e que ainda não foi resolvido, o RoHC para funcionar com uma boa eficiência sobre multicast deverá funcionar no U-Mode, uma vez que é o modo de operação em que a informação é só enviada na direcção do Compressor para Descompressor, não tendo qualquer canal feedback.

44

3.4 Tráfego de controlo Um dos grandes problemas da arquitectura dos protocolos RTP/UDP/IP é o grande overhead no tráfego que afecta a largura de banda. Devido a isso deve existir no tráfego de controlo técnicas de compressão de cabeçalhos para se conseguir reduzir este overhead do tráfego. Este tipo de técnicas foi desenvolvido para ligações 1-hop, neste momento ainda não são fiáveis para ser implementadas em redes wireless Ad-Hoc multi-hop porque neste tipo de redes, os dados têm que ser comprimidos e descomprimidos em todos os nós intermédios, o que adiciona um overhead na rede. Este overhead pode ainda aumentar quando estas redes são expandidas, pois o número de compressões e descompressões vai aumentar. Para optimizar o desempenho da compressão de cabeçalhos sobre este tipo de redes estão a ser desenvolvidas técnicas para que o desempenho da compressão de cabeçalhos sobre redes wireless Ad-Hoc seja o melhor. De seguida descrevemos algumas dessas técnicas.

3.4.1 Routing Assisted Header Compression (RAHC) Routing Assisted Header Compression (RAHC) [24] é uma técnica de compressão de cabeçalhos baseada nas informações fornecidas pelo algoritmo de routing de redes Ad-Hoc. RAHC implementado em conjunto com o protocolo on-demand routing de redes Ad-Hoc propõe que os nós intermédios entre a origem e o destino sejam actualizados com a informação do contexto da topologia actual da rede e do caminho criado pelo algoritmo de routing. Uma rota quando é criada entre a origem e o destino, o primeiro pacote a ser enviado vai descomprimido para possibilitar que o nó de destino armazene a informação estática do cabeçalho do pacote de modo a conseguir reconstruir os próximos pacotes comprimidos. Ao surgir alguma falha na topologia da rede, o algoritmo on-demand de routing inicia automaticamente a descoberta de uma nova rota, este processo vai actualizar os contextos de todos os nós. A criação de uma nova rota vai trazer algum overhead mas que será compensado pelo Ganho conseguido pela compressão de cabeçalhos.

3.4.2 Scalable and robust end-to-end header compression (SEEHOC)

Scalable and robust end-to-end header compression (SEEHOC) [25], técnica de compressão de cabeçalhos extremo a extremo que melhora significativamente a eficiência da utilização de redes Ad-Hoc sem introduzir overhead que provoque perda de pacotes. Esta técnica é aplicada em fluxos multimédia de modo a serem transportados nas redes Ad-Hoc. SEEHOC utiliza técnicas para resolver os seguintes desafios técnicos:1)identificar o tipo de

45

pacotes,2)manter o contexto actualizado ao longo dos caminhos que o pacote comprimido atravessa 3) distinguir entre os diferentes fluxos e detectar erros. A identificação de pacotes é usada para identificar que procedimento irá ser efectuado pelo pacote quando é enviado pelo compressor. Caso seja um pacote com full header irá ocorrer uma criação e actualização de fluxo de contexto, se for um pacote parcial ele é usado para actualizar o contexto. Para manter os contextos actualizados ao longo dos caminhos que o pacote comprimido atravessa o SEEHOC utiliza duas técnicas:

o O compressor actualiza o contexto ao longo do caminho periodicamente e não só quando detecta um pacote perdido ou quando é recebido um pedido do descompressor.

o Quando um nó recebe uma nova actualização ele envia essa actualização para jusante.

Os fluxos são distinguidos através do Context ID (CID), mas existe um problema em redes multi-Hop, fluxos originados em compressores diferentes podem ter o mesmo CID. Para fazer face a esse problema o SEEHOC tem uma técnica chamada CID Swapping, que efectua a troca do CID num fluxo caso esse CID já tenha sido noutro fluxo, podemos ver uma ilustração dessa técnica na figura 18.

Figura 18 - CID Swapping

Quando ocorre um bit error nos pacotes isto pode provocar a perda dos pacotes seguintes. Esta perda deve-se ao facto de o erro ser armazenado no contexto que também irá ser pelos pacotes seguintes. Este problema não

46

acontece caso os nós usem um forte checksum que ao detectar frames com bit-errors irá as descartar. No entanto caso os nós usem um checksum fraco, então o algoritmo de compressão deve incluir um mecanismo de detecção de erros.

3.4.3 Signaling Compression (SigComp)

Muitos protocolos de aplicação são usados para comunicações de multimédia em que as mensagens não são optimizadas em termos de tamanho. Como exemplo temos as típicas mensagens SIP em que o seu tamanho varia de algumas centenas de bytes até dois mil ou mais bytes. Com o uso destes protocolos em redes móveis 2.5G e 3G o grande tamanho da mensagem é problemático. Com a baixa taxa de conectividade IP os atrasos da transmissão são significativos. Tendo em conta retransmissões, e a multiplicidade de mensagens que são requeridas em alguns fluxos, as configurações de chamadas e a sua invocação são afectadas. Em 2003 surge o SigComp (Signaling Compression) [26], solução usada para fazer a compressão de mensagens geradas por protocolos de aplicação, tais como SIP (Session Initiation Protocol-RFC3261) e RTSP (Real Time Streaming Protocol- RFC2326) e que elimina o problema anteriormente falado uma vez que, Sigcomp fornece robustez e uma compressão sem perda de mensagens. No processo de descompressão o Sigcomp usa o UDVM (Universal Decompressor Virtual Machine ). Na figura19 temos ilustrado a arquitectura do SigComp

Figura 19- Arquitectura SigComp

47

A arquitectura Sigcomp é composta pela camada das aplicações, camada de transporte e a camada de SigComp. A camada SigComp é constituída pelas seguintes entidades:

� Compressor Dispatcher – camada que recebe as mensagens não comprimidas da camada aplicativo, invoca um compressor, e encaminha as mensagens para a camada transporte

� Decompressor Dispatcher – camada que recebe as mensagens SigComp, invoca o descompressor e encaminha as mensagens descomprimidas para um aplicativo

� Compressor – o compressor invoca o codificador, e mantém o registo dos estados que podem ser usados para compressão. Responsável por fornecer instruções ao UDV para o descompressor descomprimir os dados que serão comprimidos.

� UDVM – máquina virtual que é usada para descomprimir as mensagens SigComp. O UDVM é capaz de comunicar com uma ampla gama de algoritmos de compressão.

48

3.5 Novas Tendências

3.5.1 Layered IP Header Compression A ideia layered compression [27] é aplicar dois diferentes esquemas de compressão, um na camada de rede para que os campos associados a essa camada sejam comprimidos sem qualquer atraso e a outra na camada de transporte que permite que a compressão e a descompressão seja feita no momento que seja mais eficiente de modo a melhorar o desempenho da tradicional compressão de cabeçalhos O layered compression é aplicado em ambientes de rede Ad Hoc usando IP, onde o custo de transmissão e o custo de processamento de compressão/descompressão é maior do que na tradicional rede.

3.5.2 LowPan LowPan (low power wireless personal area networks) é uma simples rede de comunicação de baixo custo que permite conectividade wireless em aplicações com uma potência e uma taxa de transferência limitadas. Tipicamente inclui dispositivos que trabalham em conjunto para conectar ao ambiente físico para aplicações do mundo real. Uns dos exemplos deste tipo de dispositivos são os sensores wireless. O LowPan suporta pacotes de tamanho reduzido, tem um MTU de 127 bytes, e caso a camada de segurança esteja activa só irá ter no máximo 80 octetos para os dados. Tem uma largura de banda baixa, tendo para uma ligação wireless uma taxa de transferência de 250kbps ou menos. Tipicamente, alguns ou todos os dispositivos operam com uma bateria. No fim de melhorar a eficiência energética, o IEEE 802.15.4 ao limitar o tamanho máximo da sua frame a 127 bytes, resultou na incompatibilidade em usar IPv6 uma vez que, o IPv6 requer um suporte de pacotes muito maior que o maior tamanho da frame do IEEE 802.15.4. Para resolver este problema foi desenvolvido um novo mecanismo chamado 6LOWPAN [28] que efectua uma compressão de cabeçalhos para ser possível transportar IPv6 sobre IEEE 802.15.4. O 6LOWPAN suporta diferentes tipos de topologia a partir da mais simples topologia em estrela para a mais complexa arquitectura baseada em redes mesh de camada 2 ou em routing de camada 3. 3.5.4 Cooperative Header Compression (COHC)

Esquema de compressão de cabeçalhos desenvolvido para sistemas de comunicações multi-canal. Esta técnica permite o envio de mensagens em multicast. Não utiliza um canal feedback para sincronizar o compressor com o descompressor porque se torna impraticável devido ao uso de mensagens multicast. O COHC [29] para permitir o sincronismo entre o compressor e o descompressor

49

introduz o conceito additional information container (AIC), informação adicional que cada pacote comprimido tem e que em conjunto com uma determinada base consegue sincronizar o compressor com o descompressor em caso de alguma perda. Um dos cenários em que se usa esta técnica de compressão é quando existe múltiplos caminhos entre a fonte e o destinatário. Na figura 20 temos ilustrado um desses cenários.

Figura 20- Rede com um Wireless Terminal (WT) conectado a várias estações Base (BS)

Neste cenário as BS estão sobre o controlo do controlador de acesso (AC), sendo este AC o último IP antes do wireless terminal. Assim o compressor e o descompressor estão dentro do WT e do AC. As BS funcionam como pontes de acesso, actuam somente como bridges. Estas arquitecturas estão presentes em IEE 822.11 bem como nas futuras redes 4G. 3.6 Fluxos TCP de Curta Duração

Em diversas situações há redundância entre os diferentes campos do cabeçalho TCP/IP dos fluxos que passam pelo mesmo par compressor/descompressor. Um destes exemplos ocorre na WEB no protocolo HTTP onde um Browser abre diversas ligações em simultâneo quando é efectuado um pedido. Isto significa que algumas das informações necessárias para inicializar o contexto de modo a descomprimir os cabeçalhos de um novo fluxo, podem já estar presente no descompressor. Pode ser desejável a reutilização desta informação para remover algum overhead que é acrescentado com a inicialização de um novo contexto. A redução do overhead no processo de estabelecimento do contexto é útil quando ocorrem fluxos num curto espaço-tempo no mesmo par compressor/descompressor, uma vez que uma infinidade de ligações de curta duração vão reduzir o Ganho do uso da compressão de cabeçalhos. Para melhorar o Ganho neste tipo de fluxos, foi desenvolvido um mecanismo no RoHC chamado contexto replicado (context replication) [30].

50

Neste mecanismo o compressor reutiliza ou cria uma cópia de um contexto base para criar o contexto replicado. O contexto base é um contexto que já foi validado tanto pelo compressor como pelo descompressor. Ao ser identificado o contexto base a usar através do Base Context Identifier (BCID)., este é actualizado com os campos do novo fluxo. Depois de o contexto ser actualizado o compressor envia para o descompressor um pacote que contém uma referência com os campos seleccionados no contexto base juntamente com alguns dados para os campos que precisam de ser actualizados na criação do contexto replicado. Finalmente, o descompressor cria o contexto replicado baseado na referência do contexto base juntamente com os dados comprimidos e descomprimidos do pacote recebido.

3.6.1 Máquinas de Estados com Contexto replicado O compressor inicia sempre no estado mais baixo (IR) e transita para o estado contexto replicado (CR) com a restrição de que o compressor pode seleccionar um contexto base apropriado para o fluxo ser comprimido. A transição para o estado de maior compressão é baseada no feedback recebido do descompressor indicando que tem todos os parâmetros necessários para a óptima descompressão. Na figura 21 é mostrado o estado adicional quando se utiliza um contexto replicado

Figura 21 – Máquina Estados

51

4. Wireless Metropolitan Routing Protocol 4.1 Descrição Geral

Este documento descreve em detalhe a especificação v1.0 do

mecanismo de compressão WMRP-HC. O protocolo WMRP-HC é um mecanismo de compressão de cabeçalhos

de controle do protocolo WMRP. Visa o aumento da escalabilidade do WMRP através da redução do overhead médio do tráfego de controlo, bem como, em certos casos, a redução do número de pacotes transmitidos. Assim, acrescenta ao WMRP mais uma estratégia que permite aumentar a sua escalabilidade, permitindo-lhe funcionar com boa performance com um maior número de nós.

O protocolo WMRP é um protocolo proactivo em que cada nó transmite periodicamente um pacote TC contendo o NodeId das Rbridges que ficou a conhecer através da troca de mensagens HELLO. Ao receber um TC enviado por outro nó, uma Rbridge deverá processar o conteúdo da mesma e de seguida retransmite o pacote original para o resto da rede. No entanto, antes de o fazer, tem que actualizar os campos TTL e Hop Count do cabeçalho WMRP que precede cada mensagem presente numa trama WMRP. Daqui se derivam os seguintes requisitos para o WMRP-HC:

R-1) O conteúdo da mensagem WMRP-HC deve estar acessível a todos os nós que participam na rede Ad-Hoc.

R-2) As mensagens TC devem ser actualizadas a cada nó antes de serem reencaminhadas para o resto da rede.

Para cumprir estes requisitos convencionou-se que cada Rbridge manterá um contexto de HC por cada outra Rbridge da rede Ad-Hoc e por cada tipo de mensagem daí proveniente. Assim, cada contexto será identificado pelo tuplo [NodeId origem; MessageTypeId], também designado de WID. Assim para um dado tipo de mensagem WMRP (e.g. TC), o nó emissor desempenha as funções de Compressor e todos os outros nós agem como Descompressores. Ao utilizar o WMRP-HC, o nó emissor de uma mensagem TC deverá efectuar uma operação de compressão. Os nós que irão receber essa trama WMRP-HC terão obrigatoriamente que efectuar uma operação de descompressão, mas para minimizar o overhead computacional decorrente da utilização de HC, é conveniente evitar uma operação de compressão em cada um desses nós. Para tal, o WMRP-HC evita efectuar uma operação de compressão em cada nó que recebe de forma a minimizar a perda de performance decorrente da utilização de HC.

52

4.2 Estrutura do pacote WMRP

4.2.1 Estrutura Base O pacote WMRP é baseado no OLSR e é constituído pelos seguintes campos: 1) tamanho do pacote de 16bits; 2) Número sequência do pacote com 16bits; 3) mensagens de 32 bits. Na figura 22 temos ilustrado o formato do pacote WMRP:

Figura 22- Pacote WMRP

4.2.2 Estrutura do Cabeçalho

O cabeçalho do pacote WMRP é formado pelos seguintes campos: 1) Message Type- campo de 8 bits que indica qual o tipo de mensagem (HELLO,TC,MC,IC), 2) VTime- 8bits que indica quanto tempo a informação é válida, 3) Message Size- 16 bits com o tamanho da mensagem, 4) Originator ID- 32 bits que indica qual o NodelID que gera a mensagem, 5)Time To Live- número de vezes que a mensagem pode ser encaminhada antes de ser descartada, campo de 8 bits 6) Hop Count- número de vezes que a mensagem foi enviada, 8bits de tamanho 7) Message Sequence Number- número único que identifica cada mensagem e que juntamente com o Originator ID, pode ser usado para detectar a duplicação, campo de 16 bits 8) Logical Clock, este campo é composto por 32 bits e indica o número sequência que pode ajudar ordenar eventos provenientes de diferentes nós.

53

Figura 23- Header WMRP

4.2.3 Mensagem HELLO

A mensagem HELLO é usada para detectar novos vizinho. A HELLO tem um campo HTIME de 8bits que indica o tempo que cada nó mantém os seus viznhos na tabela. Estas mensagens são enviadas de num período de 2s e são unicamente transmitidas até 1-hop.

Figura 24- Mensagem HELLO

4.2.4 Mensagem TC

A mensagem TC é usada para cada nó para enviar a lista dos seus vizinhos, com um período de maior ou igual 50s. Estas mensagens são inundadas pela rede e têm um HTIME tal como as mensagens HELLO.

Figura 25 – Mensagem TC

54

4.2.5 Mensagem MC

Relativamente à MC é usada para cada nó anunciar a lista de vizinhos a nível da camada MAC. Têm a lista de endereços MAC e o último MAC detectado. São inundadas pela rede com um período de maior ou igual a 50s.

Figura 26 - Mensagem MC

4.2.6 Mensagem IC

A mensagem IC é usada para cada nó para anunciar as associações IP-MAC, contendo a lista de endereços IP e MAC e o último IP adquirido. Têm um período de 60s. Esta mensagem só é emitida para Rbridges que estão ligados a servidores DHCP.

Figura 27 - Mensagem IC

55

5. Network Simulation 3 (NS-3)

5.1 Introdução

A simulação de eventos discretos é usada para construir um modelo muito próximo da realidade de modo a prever o desempenho de diversas alternativas, efectuar comparações em diversos ambientes e também para ser usada caso o sistema não esteja disponível. Neste tipo de simulação os eventos alteram o estado de forma discreta, mudando somente em cada evento e não ocorrendo nada entre os eventos. A técnica simulação recorre a linguagens de programação para manipular o sistema, programar eventos, avançar o tempo e gerar valores aleatórios. As linguagens de programação mais usadas neste tipo de técnicas são a linguagem C, C++ e FORTRAN. Existe diversos softwares onde é possível simular um evento discreto. No ponto seguinte iremos descrever com detalhe o NS-3, software de simulação de eventos discretos que iremos usar durante o nosso trabalho. O Network Simulator 3 [31] é um novo simulador de eventos discretos de rede para sistemas de Internet, orientado principalmente para investigação e uso educacional. Começou a ser desenvolvido em meados de 2006, estando ainda em fase de desenvolvimento. O NS-3 é um software livre que pode ser modificado sob os termos da GNU General Public Lincense (GPL). Umas das características chave do NS-3 são as: 1) Não é uma extensão do NS-2; 2) Ambos os simuladores são escritos em C++ mas o NS-3 não suporta APIs do NS-2, 3) NS-3 já tem extensões em Python,4) eventualmente será usado para vir a substituir o NS-2 , 5) Usa modelos para protocolos de routing Normalmente é utilizado o ambiente Linux para trabalhar com o NS-3, mas existem também emuladores de Linux para ambientes Windows onde é possível correr o NS-3 em Windows como é o caso do MinGw e o Cygwin. Este tipo de ferramenta para o ambiente Windows ainda está em desenvolvimento.

5.2 Instalação

Relativamente à instalação do NS-3, é necessário instalar o Mercurial, ferramenta de multi-plataforma que é usada por diversos desenvolvedores de software sendo escrita em Python. Podemos ver de seguida os passos a efectuar para a instalação do Mercurial e NS-3:

1. sudo apt-get install build-essential g++ python mercurial 2. mkdir repos 3. cd repos 4. hg clone http://code.nsnam.org/ns-3-dev 5. wget http://www.nsnam.org/releases/ns-3.2.tar.bz2 6. bunzip2 ns-3.2.tar.bz2 7. tar xvf ns-3.2.tar

56

Para fazer a compilação do programa é usado a ferramenta Waf, ferramenta construída sobre Python que faz a compilação, verificação, construção e execução do código fonte. De seguida temos ilustrado os comandos a executar:

1. ./waf –d debug configure # build ns-3 2. ./waf check # runs unit test 3. ./waf –run hello-simulator # run script

5.3 Conceitos básicos

Existe no NS-3 alguns conceitos básicos do sistema que são usados frequentemente numa rede e que cada utilizador deve compreender antes de iniciar o processo de escrita de código. Os conceitos são os seguintes:

1. Nó (Node) - dispositivo básico de computação representado em C++ pela classe Node. A classe Node fornece métodos para representar estes dispositivos em simulações. Devemos comparar o Nó a um computador uma vez que, é necessário adicionar ao Nó funcionalidades, como aplicações, periféricos, protocolos para o seu correcto funcionamento tal como é feito num computador com a instalação dos drivers.

2. Aplicação - programa usado para gerar a simulação pretendida. Este programa é escrito em C++ e é representado pela classe Application. A classe application fornece métodos para controlar

3. Canal – um canal é usado para conectar um computador a uma rede.

No NS-3 é possível conectar um Node a um objecto que representa um canal comunicação. Este objecto é representado pela class Channel. No NS-3 existem diversos tipos de canais como CsmaChannel, PointToPointChannel e WifiChannel

4. Dispositivo rede - No NS-3 o dispositivo de rede abrange o driver e o

hardware simulado. O dispositivo de rede é usado para permitir que o Node comunique com outros Nodes via Channels. É possível um Node ser conectado mais do que canal via diferentes dispositivos de rede. No NS-3 a classe do dispositivo de rede é representada em C++ pela classe NetDevice. Existe diversos tipos de dispositivos de rede no NS-3 como é o caso do CsmaNetChannel, PointToPointNetChannel e WifiNetChannel.

57

6. Plano Actividades No diagrama da figura 28, temos ilustrado o plano de actividades definido para o trabalho a desenvolver nos próximos meses até à entrega final. Como podemos ver no plano, nas primeiras duas semanas irei aprender a trabalhar com o NS-3 e Mercurial, após estas semanas vou iniciar com a implementação do modelo de compressão de cabeçalhos sobre o WMRP, fase que terá cerca de 5 semanas. Depois de ter efectuado a implementação passarei para a fase de testes e validação que durará cerca de 3 semanas e que antecede à fase de Experimentação e Análise onde irei obter os resultados do meu trabalho, esta fase terá uma duração de cerca 6 semanas. Por último, no mês de Junho ficará para a escrita da dissertação.

Figura 28- Plano de actividades

58

7. Capítulos Futuros Este documento irá ser completado com o decorrer do trabalho. Irá ser acrescentado o capítulo de implementação, onde se descreverá toda a implementação efectuada, desde a lógica utilizada na integração, testes funcionais e validação. Terá também um capítulo de experimentação, onde será mostrado tudo que foi medido e análises efectuadas. Por fim acabará com as conclusões sobre todo o trabalho efectuado.

59

Referências

[1] C. Hedrick, “Routing Information Protocol” – RFC1058 , IETF June1988

[2] Charles E_ Perkins , Pravin Bhagwat “Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers”,1994

[3]- Petteri Kuosmanen ”Classification of Ad Hoc Routing Protocols”

[4] – T.Clausen , P.Jacquet , “Optimized Link State Routing Protocol (OLSR)” - RFC3626 , IETF October 2003

[5]- Mario Gerla, Guangyu Pei, Li Ma, Xiaoyan Hong, “Fisheye State Routing Protocol (FSR) for Ad

Hoc Networks”, June 17, 2002

[6]- Mario Gerla, Guangyu Pei, Tsu-Wei Chen, Xiaoyan Hong, “ Landmark Routing Protocol

(LANMAR) for Large Scale Ad Hoc Networks”, November 17, 2002

[7]- R. Ogier , F. Templin , M. Lewis “Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)”, RFC 3684 , IETF , February 2004

[8] David B. Johnson, David A. Maltz, Yih-Chun Hu “The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)” draft-ietf-manet-dsr-10.txt IETF MANET Working Group 19 July

2004

[9] - C. Perkins , E. Belding-Royer , S. Das “Ad hoc On-Demand Distance Vector (AODV) Routing ” - RFC3561, IETF July 2003

[10] Changling Liu, Jörg Kaiser A Survey of Mobile Ad Hoc network Routing Protocols* ,October 2005

[11]- Mahesh K. Marina , Samir R. Das “On-demand Multipath Distance Vector Routing in Ad Hoc Networks”, 2001

[12]- I. Chakeres, C. Perkins “ Dynamic MANET On-demand (DYMO)” Routing,

draft-ietf-manet-dymo-12, February , 2008

[13]- Nicklas Beijar “Zone Routing Protocol (ZRP)”

[14] – M.Scott Corson , Joseph Macker, Stephen G. Batsell “Architectural Considerations for mobile mesh networking ” IEEE 1996

[15]- Pedro Fortuna, “WimetroNet Project” INESC PORTO, Novembro,2008

[16] E. Rosen , A. Viswanathan , R. Callon “Multiprotocol Label Switching Architecture” – RFC 3031 , IETF January 2001

[17] David J. Farber , Gary S. Delp , Thomas M. Conte ., " A Thinwire Protocol for connecting personal computers to the INTERNET ", RFC 914, September 1984

[18] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.

[19] M. Degermark, B. Nordgren, S. Pink "IP Header Compression ", RFC 2507, February 1999

60

[20] S. Casner , V. Jacobson" Compressing IP/UDP/RTP Headers for Low-Speed Serial Links ", RFC 2508, February 1999

[21] T. Koren , S. Casner , J. Geevarghese , B. Thompson , P. Ruddy" Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering ", RFC 3545, July 2003

[22] C. Borman et al, “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed”, RFC 3095, IETF, July 2001.

[23] Elizabeth Martinez, Ana Minaburo, Laurent Toutain, “RoHC for Multicast Distribution Services” 16th International Symposium on Personal, Indoor and Mobile Radio Communications, 2005

[24] – Ranjani Sridharan, Ramalingam Sridhar , Sumita Mishra “ A Robust Header Compression Technique for Wireless Ad Hoc Networks ” Mobile Computing and Communications Review, Volume 7,

Number 3, 2003

[25] – Maher Kaddoura , Steven Schneider “SEEHOC:Scalable and Robust End-to-End Header Compression Techniques for Wireless Ad Hoc Networks ” IEEE Communications Society Globecom

2004 Workshops

[26] A. Surtees , M. West , A.B. Roach , “Signaling Compression (SigComp) Corrections and Clarifications ”, RFC 4896 IETF, June 2007.

[27] – Cédric Westphal “Layered IP Header Compression for IP-enabled Sensor Networks ” ICC 2006

[28] – J. Hui, N. Kushalnagar, G. Montenegro, D. Culler “Transmission of IPv6 Packets over IEEE 802.15.4 Networks ” RFC4944 , IETF ,September 2007

[29] – Tatiana Kozlova Madseny, Frank H.P. Fitzeky, Yasushi Takatoriy, Ramjee Prasady, Marcos Katz “Cooperative IP Header Compression using Multiple Access Points in 4G Wireless Networks ”

Department of Communications Technology, Aalborg University, 2005

[30] G. Pelletier" RObust Header Compression (ROHC): Context Replication for ROHC Profiles", RFC 4164, August 2005

[31] “ns-3 Tutorial” 9 December 2008

Faculdade de Engenharia da Universidade do...

Documents

Transcript of Faculdade de Engenharia da Universidade do...