Encaminhamento de mensagens hello - Estrat´ egia MPRstrategy

5.3 Estrat´ egia MPRstrategy

5.3.1 Encaminhamento de mensagens hello

Para conhecer todos os nós a dois saltos de distância, a estratégia utiliza um protocolo de hello. Todos os nós terão de enviar, periodicamente, mensagens hello para os seus vizinhos, que conterão o seu ID e os IDs dos seus próprios vizinhos. Naturalmente, na primeira vez que os nós enviam a mensagem hello, enviarão apenas o seu ID, porque ainda não têm conhecimento dos vizinhos. Assim, este algoritmo necessita de duas itera¸cões para convergir.

Cap´ıtulo 5. Estrat´egias de encaminhamento propostas 44

Todos os nós terão uma Tabela Vizinhos, que conterá todos os seus vizinhos, os respetivos vizinhos destes e o número de vizinhos. A estrutura da tabela está representada na Figura 5.6.

Figura 5.6: Estrutura da Tabela Vizinhos dos n´os na estrat´egia MPRstrateggy

Como o contexto em que se enquadra é o das redes de dados nomeados, foi decidido que as mensagens de hello serão retransmitidas através de interesses e dados. Para isso, todos os nós serão consumidores e, simultaneamente, produtores do prefixo “/hello”. Todos os consumidores enviarão interesses hello de 5 em 5 segundos. O protocolo OLSR recomenda o envio de pacotes de hello de 2 em 2 segundos [34], mas como as simula¸cões feitas são para cenários em que os dispositivos móveis são transportados por pedestres, foi decidido que o intervalo de tempo de 5 segundos era suficiente.

Assim, quando um nó N envia um interesse com o prefixo “/hello”, todos os nós que receberem esse interesse serão, obviamente, os vizinhos de N. Como todos os nós são produtores do prefixo “/hello”, os vizinhos de N não reencaminharão o interesse e, em vez disso, devolverão os dados correspondentes. Para isso, irão à sua Tabela Vizinhos, verificar quais são os seus vizinhos e, de seguida, registarão, no conteúdo do pacote de dados, o seu próprio ID e o ID dos seus vizinhos. O nó N, ao receber o pacote de dados, irá registar na sua Tabela Vizinhos o seu vizinho e os respetivos vizinhos do vizinho.

A Figura 5.7 ilustra um exemplo deste procedimento.

E de notar que os n´os adiam a transmiss˜ao dos pacotes de dados hello por um tempo

THello, calculado aleatoriamente, a fim de evitar colis˜oes. Quando o n´o N enviava o in-

teresse hello, todos os seus vizinhos recebiam-no ao mesmo tempo e, consequentemente, iriam enviar o respetivo pacote de dados hello, também, ao mesmo tempo, o que provo- cava várias colisões entre pacotes. Como resultado, N não recebia a informa¸cão de todos os vizinhos e ficava com um conhecimento incompleto da topologia, o que resultava num mau desempenho do protocolo de encaminhamento. Ao contrário dos outros tempos de atraso criados (TInterest, TData e, como será visto mais à frente, TInterestM P R), que

Cap´ıtulo 5. Estrat´egias de encaminhamento propostas 45

Figura 5.7: Exemplo da troca de mensagens “/hello” na MPRstrategy

os pacotes não serem enviados todos ao mesmo tempo. Na troca de pacotes hello não existem loops de encaminhamento, pois os nós nunca os reencaminham.

Visto que o RTT é cerca de 5ms, foi decidido que o valor máximo para este temporizador seria 5ms. Assim, THello estará entre os 0 e 5ms.

Quando um nó N recebe um pacote de dados “/hello”, com a informa¸cão de um vizinho, é verificado se já possui informa¸cão sobre aquele vizinho na Tabela Vizinhos. Se sim, elimina a informa¸cão obsoleta e insere a nova. Se não, simplesmente acrescenta a nova informa¸cão na tabela.

Além disso, é estabelecido um tempo de vida para a informa¸cão de um vizinho na tabela, através da utiliza¸cão de um temporizador TN eighbor, que é calculado através da

Cap´ıtulo 5. Estrat´egias de encaminhamento propostas 46

TN eighbor = Hellointerval+ THello+ RT T (5.3)

O valor Hellointerval ´e o intervalo de envio de interesses hello, que ´e 5 segundos.

THello ´e o tempo esperado para a retransmiss˜ao dos pacotes de dados hello e, nesta

equa¸cão, tem o valor de 5 ms, que é o seu valor máximo. É escolhido o valor máximo, para não ocorrer a situa¸cão de um nó apagar a informa¸cão do vizinho, simplesmente por este estar no tempo de espera antes da retransmissão dos dados. Por fim, RTT ´

e o tempo necessário, aproximadamente, desde que o nó N envia o interesse hello, até receber o pacote de dados correspondente, que tem o valor de 5ms.

Este temporizador é iniciado quando é criada a informa¸cão desse vizinho na Tabela Vizinhos. Sempre que essa informa¸cão é atualizada, o temporizador é reiniciado. Caso o temporizador chegue ao fim, significa que aquele nó deixou de ser vizinho (pois o nó N não recebeu mais atualiza¸cões deste) e, por isso, a informa¸cão é apagada da Tabela Vizinhos.

5.3.2 Encaminhamento de interesses

Quando um nó tiver um interesse para enviar (com a exce¸cão do interesse com prefixo /hello), quer seja o consumidor ou um nó intermédio, terá de descobrir quais os seus vizinhos terão de reencaminhar o pacote, ou seja, quais são os MPRs, para que todos os vizinhos desses vizinhos recebam o interesse, mas com a menor redundância poss´ıvel. O conjunto de nós MPRs serão colocados num novo campo do cabe¸calho do interesse, designado por campo “MPR”.

5.3.2.1 Algoritmo MPR

O algoritmo MPR, utilizado para calcular o conjunto de vizinhos MPRs de cada n´o, utiliza uma tabela adicional, designada por Tabela provisorio, que est´a representada na Figura 5.8.

O primeiro campo da Tabela provisorio, de um nó N, contém o ID do vizinho de N. O segundo campo contém a quantidade de vizinhos, do vizinho de N, que ainda não estão na área de cobertura dos nós já considerados MPRs. O terceiro campo contém os IDs desses vizinhos e, por fim, o último campo contém uma variável inteira, que indica se o vizinho de N é MPR (1), se já foi considerado não-MPR (0) ou se essa decisão

Cap´ıtulo 5. Estrat´egias de encaminhamento propostas 47

Figura 5.8: Estrutura da Tabela provisorio dos n´os na estrat´egia MPRstrateggy

ainda não foi feita (-1). Esta tabela serve como tabela auxiliar, para averiguar quais dos vizinhos de N (com a mesma quantidade de vizinhos) irão pertencer ao conjunto MPR. Supondo que N tem 5 vizinhos, que contêm todos eles 4 vizinhos cada um, o nó N irá registar na Tabela provisorio todas as informa¸cões desses nós, de forma a perceber quais terá de escolher como MPR, para uma menor redundância poss´ıvel de pacotes na rede. Na Figura 5.9 está representado o fluxograma da técnica dos MultiPoint Relays. É de notar que o vetor com cobertura contém os IDs dos vizinhos dos vizinhos, que já estão na área de cobertura dos nós já considerados MPRs. Já o vetor sem cobertura contém os IDs dos vizinhos do vizinho, que ainda não estão na área de cobertura dos nós já considerados MPRs e servirá para colocar no terceiro campo da Tabela provisorio de cada vizinho de N.

Cap´ıtulo 5. Estrat´egias de encaminhamento propostas 49

Cap´ıtulo 5. Estrat´egias de encaminhamento propostas 50

De seguida, ´e mostrado um exemplo, para ilustrar a ideia do algoritmo MPR. A Figura 5.10 representa um exemplo da tabela Vizinhos de um n´o N.

Figura 5.10: Exemplo da Tabela Vizinhos do n´o N na MPRstrategy

Em primeiro lugar, o nó N terá de ir à tabela Vizinhos e construir uma lista ordenada, por ordem decrescente, com os seus os vizinhos, que contêm mais vizinhos. Neste caso, a lista ficaria: B-A-C-E-F-G-H-D. De seguida, terá de descobrir quais os vizinhos serão MPRs.

O primeiro nó da lista ordenada é o B. Como a lista com cobertura ainda está vazia e não existe nenhum outro vizinho de N com a mesma quantidade de vizinhos do que B, significa que B é o primeiro da lista ordenada e é, também, o vizinho com mais vizinhos. Por isto, o nó B é considerado MPR. De seguida, os vizinhos de B são registados na lista com cobertura, para que N consiga perceber quais os vizinhos dos seus vizinhos já têm cobertura, pelos já considerados MPRs.

O próximo nó da lista ordenada é o nó A, que tem como primeiro vizinho o nó 5. Como este já pertence à lista com cobertura, já receberá o pacote através de outro MPR. A pesquisa dos vizinhos de A continua, até haver algum vizinho que não conste na lista com cobertura ou que acabem os vizinhos de A. O próximo é o nó 2. Este ainda não consta na lista com cobertura. Contudo, como o nó A tem o mesmo número de vizinhos em rela¸cão ao próximo nó da lista ordenada, o nó C, a decisão de se o A é ou não um MPR não é feita neste momento, pois antes é necessário averiguar os vizinhos de todos

Cap´ıtulo 5. Estrat´egias de encaminhamento propostas 51

os nós, que contêm a mesma quantidade de vizinhos do que A, a fim de não considerar nós MPRs desnecessariamente e contribuir para a redundância de pacotes na rede.

De seguida, o nó 2 é registado no vetor sem cobertura do nó A e a pesquisa dos vizinhos do nó A continuaria, mas, neste caso acabou, porque acabaram os vizinhos de A. No entanto, se A tivesse mais algum vizinho, o procedimento seria o mesmo, ou seja, se A tivesse um nó que ainda não pertencesse à lista com cobertura, registaria esse nó no vetor sem cobertura. Caso já pertencesse, descartava esse nó e continuava a pesquisa de vizinhos de A. Quando a pesquisa termina, é feito um registo na Tabela provisorio. Neste caso, o registo teria os valores (A; 1; 2; -1). A sua explica¸cão está representada na Figura 5.11.

Figura 5.11: Exemplo de registo na Tabela provisorio do n´o A na MPRstrategy

O próximo é o nó C. Os seus vizinhos são os nós 5 e 1. O nó 5 já consta na lista com cobertura, mas o nó 1 ainda não. O procedimento é o mesmo que foi utilizado no nó A. Neste caso, o registo na Tabela provisorio teria os valores (C; 1; 1; -1).

O próximo é nó E. Os seus vizinhos são os nós 1 e 2, que não constam na lista com cobertura. Neste caso, o registo na Tabela provisorio teria os valores (E; 2; 1,2; -1). O nó F tem os mesmos vizinhos de E. O registo na Tabela provisorio teria os valores (F; 2; 1,2; -1).

O nó G contém os vizinhos 4 e 8, que não constam na lista com cobertura. Neste caso, o registo na Tabela provisorio teria os valores (G; 2; 4,8; -1).

O último nó, que contém dois vizinhos, é nó H. Os seus vizinhos são os nós 1 e 6, que não constam na lista com cobertura. O registo na Tabela provisorio teria os valores (H; 2; 1,6; -1).

Posto isto, chegou o momento de decidir quais os nós com 2 vizinhos serão MPRs. Para isso, é percorrida a Tabela provisorio, que está representada na Figura 5.12.

Cap´ıtulo 5. Estrat´egias de encaminhamento propostas 52

Figura 5.12: Exemplo da Tabela Provisorio do n´o N na MPRstrategy

Em primeiro lugar, é analisado o nó A. É percorrida a Tabela Provisorio, de forma a procurar se o nó 2 aparece mais vezes. É encontrado no nó E. Como ainda não está decidido se E será ou não um MPR, é verificado se este tem na sua área de cobertura todos os vizinhos de A e ainda um outro nó que A não tenha. Como tem todos e ainda mais o nó 1, o nó A é considerado não-MPR. A mesma situa¸cão acontece para o nó C.

De seguida, é analisado o nó E. O seu primeiro vizinho é encontrado no grupo de vizinhos do nó C, mas como este já foi considerado não-MPR, o procedimento continua. O próximo nó que faz match com o nó 1 é o nó F. Como ainda não está decidido se F será ou não um MPR, é verificado se este tem na sua cobertura todos os vizinhos de E e, ainda, um outro nó que E não tenha. O nó F tem todos os vizinhos de E, mas não tem um outro diferente e, por isso, o procedimento continua. De seguida, é encontrado no nó H, e este não possui todos os vizinhos de E, por isso o procedimento continua. Como não existe outro nó que fa¸ca match com o vizinho 1, é feita a verifica¸cão final: como ainda não está decidido se E é ou não MPR, E é considerado oficialmente MPR e são registados os vizinhos de E, que estavam na lista sem cobertura, na lista com cobertura. O próximo é o nó F. O seu vizinho 1 é encontrado no nó C, que já foi considerado não-MPR e, por isso, continua a pesquisa. É encontrado, também, no nó E, que já foi considerado MPR. De seguida, é verificado se o nó F possui algum outro nó que E não possua. Como não possui, o nó F é considerado não-MPR. Por fim, é também encontrado no nó H, mas aqui nada acontece (porque H não possui todos os vizinhos de F) e, assim, o nó F fica considerado não-MPR.

Cap´ıtulo 5. Estrat´egias de encaminhamento propostas 53

E analisado, agora, o nó G. O seu primeiro vizinho é o nó 4, que não faz match com nenhum nó da Tabela Provisorio. Então, o nó G é logo considerado MPR, sem haver necessidade de analisar os seus restantes vizinhos. Por fim, são registados os vizinhos de G, que estavam na lista sem cobertura, na lista com cobertura.

Finalmente, é analisado o nó H. O seu vizinho 1 é encontrado no nó C, que já foi considerado não-MPR e, por isso, continua a pesquisa. É encontrado, também, no nó E, que já foi considerado MPR. Como H possui outro nó que F não possui, H é considerado temporariamente MPR. Como o seu próximo vizinho, o nó 6, é único na Tabela Provisorio, H é considerado MPR.

Esta estratégia, de marcar os nós como temporariamente MPRs, serve para não serem tomadas decisões precipitadas, testando todas as rela¸cões entre os nós, para uma melhor decisão final da escolha dos MPRs.

No final deste processo, a Tabela Provisorio ´e apagada.

O último nó da lista ordenada é o nó D, que possui apenas um vizinho. Como este já pertence à lista com cobertura, o nó D é considerado não-MPR.

Neste momento, o nó N já decidiu quais os seus vizinhos serão MPRs: B, E, G e H. Conclusão: neste caso, o nó N possui 8 vizinhos, mas apenas 4 deles são considerados MPRs. Serão feitos metade dos reencaminhamentos, o que levará a que o tráfego seja diminu´ıdo em grande medida e a estratégia de encaminhamento tenha um desempenho muito melhor, com o reencaminhamento de interesses controlado.

O próximo passo é colocar esta lista de nós no campo “MPR” do interesse. Quando os vizinhos de N receberem o pacote, através de N, terão de verificar se pertencem à lista de MPRs. Caso não perten¸cam, não reencaminham. Caso perten¸cam e não possuam os dados correspondentes, utilizam o algoritmo MPR para os seus próprios vizinhos, a fim de descobrirem quais deles serão considerados MPRs, alteram o campo “MPR” do interesse com o resultado obtido e, por fim, reencaminham o interesse. O processo repete-se até que o interesse chegue a um produtor ou a um nó que possua os dados correspondentes na sua Content Store.

E de notar que, sempre que um nó intermédio tenha um interesse para encaminhar, este adia a sua transmissão por um tempo TInterestM P R, calculado aleatoriamente, a

fim de evitar colis˜oes. O valor deste temporizador estar´a entre os 0 e 5ms, tal como o

THello. Se durante o per´ıodo de TInterestM P R, o n´o receber os dados correspondentes, o

Cap´ıtulo 5. Estrat´egias de encaminhamento propostas 54

Outro aspeto importante é o facto de que o algoritmo MPR tem em conta a rota do interesse, ou seja, se o interesse recebido por N tem a rota “X-A-N”, quando é executado o algoritmo MPR no nó N, este irá descartar, caso possua, os vizinhos A e X e os vizinhos dos vizinhos A e X nos seus cálculos. Assim, diminuirá a probabilidade de loops.

5.3.3 Encaminhamento de dados

Quanto ao encaminhamento de pacotes de dados, este não foi alterado, ou seja, continua a seguir o percurso inverso do interesse e, caso não perten¸ca à rota do interesse, espera um per´ıodo de TData. Se durante esse per´ıodo não receber outro pacote de dados

igual, reencaminha o pacote ao fim de per´ıodo de TData. Caso contr´ario, descarta o

pacote. ´

E de notar que no reencaminhamento de interesses, os n´os continuam a colocar os seus IDs no campo “Path” do cabe¸calho do pacote.

Poderia ter sido proposta uma outra variante desta estratégia de encaminhamento, que alterasse o encaminhamento dos dados, à semelhan¸ca do que foi feito para os interesses. Em vez de os dados seguirem a rota do interesse, seria utilizado o algoritmo MPR. No entanto, existe uma limita¸cão, que é uma regra das NDNs, que põe em causa este protocolo. Quando um nó recebe um pacote de dados, verifica se tem uma entrada PIT correspondente. Caso não tenha, descarta o pacote não solicitado. Desta forma, como o algoritmo MPR define um conjunto reduzido de nós para reencaminharem o pacote, se esses nós não tiverem recebido o interesse correspondente, irão descartar o pacote e o encaminhamento termina, não conseguindo fazer com que os dados cheguem ao consumidor. Por esta razão, foi decidido que esta estratégia não seria proposta.

Cap´ıtulo 6

Implementa¸c˜ao

Neste cap´ıtulo será descrita a implementa¸cão da rede de dados nomeados no contexto de uma rede Ad Hoc, bem como as três estratégias de encaminhamento implementadas. Além disso, será explicado o funcionamento do simulador utilizado.

Para a implementa¸cão da rede, foi usado o simulador ndnSIM 2.0 [8], que é uma versão estendida do NS-3, que incorpora o paradigma dos dados nomeados.

6.1 Simulador ndnSIM

A ferramenta ndnSIM implementa todas as caracter´ısticas b´asicas da arquitetura NDN, incluindo:

• A utiliza¸c˜ao de um esquema de nomes hier´arquico e o formato de pacotes de interesses/dados;

• O uso de tabelas para o processamento de pacotes, tais como CS, PIT e FIB;

• A abstra¸c˜ao de estrat´egias de encaminhamento;

• A abstra¸cão de interfaces, a fim de suportar a interface entre a arquitetura NDN e as camadas superiores (aplica¸cões) e inferiores (rede, liga¸cão).

No ndnSIM 2.0, todo o encaminhamento e gestão NDN é implementado direta- mente, usando o código fonte do NDN Forwarding Daemon (NFD) [8]. O NDN Forwar- ding Daemon (NFD) é um encaminhador de rede e foi projetado para permitir simular experiências diversificadas, tendo em conta as caracter´ısticas, algoritmos e aplica¸cões das redes NDN. Assim, o NFD implementa e evolui com o protocolo NDN.

Cap´ıtulo 6. Implementa¸c˜ao 56

Nesta seçcão será explicada a estrutura do NFD: em primeiro lugar serão apresenta- das as tabelas usadas pelo NFD, depois a estrutura dos pacotes e, por fim, será explicado o processo de encaminhamento de interesses e dados.

6.2 Tabelas

O NFD implementa a PIT, FIB e CS, al´em de outras tabelas de suporte, como a tabela Strategy Choice e a tabela Measurements.

A tabela Forwarding Information Base (FIB) é usada para encaminhar pacotes de interesse em dire¸cão a potenciais fontes dos dados. É quase idêntica a uma tabela de encaminhamento IP, com a diferen¸ca de que a FIB permite ter uma lista de interfaces de sa´ıda, em vez de uma única. Uma entrada FIB contém o nome do prefixo e um conjunto de NextHops. Quando existe uma entrada FIB para um determinado prefixo significa que pode ser alcan¸cada uma potencial fonte de dados correspondente, através das interfaces contidas no registo de NextHops, nessa entrada FIB. Cada registo de NextHop contém uma interface de sa´ıda, para uma potencial fonte de dados, e o seu custo de encaminhamento.

A tabela Content Store (CS) é uma cache de pacotes de dados. Os pacotes de dados, recebidos por um nó, são colocados nesta cache por um per´ıodo de tempo, a fim de satisfazer os interesses futuros que solicitem os mesmos dados. Cada entrada da Tabela CS contém o pacote de dados, a indica¸cão se o pacote de dados não é solicitado e a hora em que os dados em cache se irão tornar obsoletos.

A tabela Pending Interest Table (PIT) tem como objetivo controlar os interesses en- caminhados em dire¸cão a produtores de dados, para que os dados possam ser enviados para o respetivo consumidor [35]. Além disso, contém interesses satisfeitos recentemente, para que possam ser detetados ciclos. Uma entrada PIT representa um interesse pen- dente ou um interesse que foi recentemente satisfeito e é constitu´ıda por um conjunto de registos de entrada, um conjunto de registos de sa´ıda, dois temporizadores (o temporizador insatisfeito, que expira quando todos os registos da entrada PIT expirarem; e o temporizador straggler, que expira quando a entrada PIT pode ser removida por ter sido satisfeita ou rejeitada, e já não ser necessária para detetar ciclos) e, por fim, uma lista Nonce.

Cada interesse possui um valor Nonce, que pode ser considerado como o seu identi- ficador e serve, principalmente, para verificar se o interesse recebido por um dado n´o ´e

Cap´ıtulo 6. Implementa¸c˜ao 57

duplicado. Supondo que um consumidor envia um interesse com um valor Nonce = x. Caso o mesmo consumidor deseje enviar outro pacote, mesmo sendo igual ao primeiro

No documento Dados nomeados em redes móveis Ad Hoc (páginas 64-78)