Fase de Roteamento Proativo

Experiˆencias anteriores com disponibilidade e redes overlay demonstram que uma grande maioria dos n´os podem ser alcanc¸ados diretamente ou usando um ´unico n´o intermedi´ario [Savage et al., 1999; Andersen et al., 2001; Gummadi et al., 2004]. Isso acontece porque, na maioria dos casos, faltas de natureza n˜ao maliciosa que afetam uma rota s˜ao circunscritas a uma determinada regi˜ao da rede, e

4. Roteamento e Encaminhamento de Pacotes na ROTI 24

o uso de rotas alternativas que evitem a regi˜ao afetada ´e suficiente para contornar o problema. Com base nessa observac¸˜ao, a ROTI usa roteamento proativo para possibilitar aos n´os aprenderem sobre todos os destinos alcanc¸´aveis dentro de um raio de at´e dois hops. Nessa fase proativa, cada n´o difunde localmente uma mensagemROUTE-UPDATEcontendo sua lista de vizinhos. Quando um n´o recebe um ROUTE-UPDATE, ele atualiza todas as informac¸˜oes de rotas simples que passam pelo emissor dessa mensagem no seu cache, o que pode envolver a inclus˜ao de novas rotas e a remoc¸˜ao de rotas antigas. OsROUTE-UPDATEs s˜ao reenviados periodicamente a n˜ao ser que haja alguma alterac¸˜ao na lista de

vizinhos, o que faz com que um novoROUTE-UPDATEcontendo a lista modificada seja enviado.

A figura 4.1 mostra um exemplo de execuc¸˜ao do protocolo proativo. A topologia considerada ´e apresentada na figura 4.1(a). A figura 4.1(b) mostra as mensagens de roteamento geradas pelo protocolo; um ROUTE-UPDATE ´e representado na forma n: v1, . . . , vm, onde n ´e o n´o emissor do

ROUTE-UPDATEe v1, . . . , vm ´e a sua lista de vizinhos. A figura 4.1(c) mostra como ficam os caches

de rotas de cada n´o da rede ap´os as trocas de mensagens da figura 4.1(b) (para economizar espac¸o, os vizinhos de cada n´o foram mostrados em um ´unica linha, mas o cache n˜ao faz distinc¸˜ao entre rotas diretas e indiretas).

a d

b c

e f

g

(a) Rede exemplo

a d b c e f g a: b,d,e a: b,d,e a: b,d,e b: a,c b: a,c c: b,d,g c: b,d,g d: a,c, f d: a,c, f d: a,c, f e: a, f e: a, f f: d,e,g f: d,e,g g: c, f g: c, f

(b) Mensagens de roteamento trocadas

N´o Cache de rotas

vizinhos: b, d, e a c: bc, dc f : d f , e f vizinhos: a, c d: ad, cd b e: ae g: cg vizinhos: b, d, g c a: ba, da f : d f , g f vizinhos: a, c, f b: ab, cb d e: ae, f e g: cg, f g

N´o Cache de rotas

vizinhos: a, f b: ab e d: ad, f d g: f g vizinhos: d, e, g f a: da, ca c: dc, gc vizinhos: c, f b: cb g d: cd, f d e: f e

(c) Caches de rotas ap´os as mensagens de roteamento

Figura 4.1: Exemplo de execuc¸˜ao do protocolo de roteamento proativo

4. Roteamento e Encaminhamento de Pacotes na ROTI 25

ativos e alcanc¸´aveis. Entretanto, faltas transit´orias podem fazer com que uma atualizac¸˜ao seja ocasi- onalmente perdida, sem que isso signifique necessariamente que o n´o deva ser considerado inalcan- c¸´avel. Para acomodar tais faltas, um vizinho s´o ´e considerado inalcanc¸´avel quando Uthr atualizac¸˜oes

consecutivas n˜ao s˜ao recebidas. Quando isso acontece, o n´o registra esse vizinho como inalcanc¸´avel e o exclui de seus pr´opriosROUTE-UPDATEs. Caso o vizinho volte a ser alcanc¸´avel, o n´o espera rece- ber U_thr0 < Uthratualizac¸˜oes consecutivas antes de inseri-lo novamente nos seusROUTE-UPDATEs. O

objetivo de esperar um tempo antes de incluir um vizinho anteriormente inalcanc¸´avel nas atualizac¸˜oes ´e dar mais estabilidade `as rotas, evitando que n´os com alcanc¸abilidade intermitente sejam anunciados como poss´ıveis intermedi´arios.

Para proteger contra ataques de replay, cada ROUTE-UPDATE cont´em um n´umero de seq¨uˆencia seq, que ´e incrementado cada vez que uma atualizac¸˜ao ´e emitida. Na pr´atica, por´em, n´umeros de seq¨uˆencia n˜ao podem crescer indefinidamente, pois s˜ao transmitidos em um campo de tamanho li- mitado contido no cabec¸alho dos pacotes. Uma dificuldade que isso acarreta ´e como lidar com a necessidade de reaproveitar n´umeros de seq¨uˆencia (isto ´e, reiniciar a contagem), que surge quando o valor m´aximo represent´avel ´e atingido ou o n´o ´e reinicializado. A soluc¸˜ao adotada na ROTI ´e enviar umROUTE-UPDATE contendo seq = 0 e um timestamp do instante de envio da mensagem. Os n´os que recebem esseROUTE-UPDATEremovem de seus caches todas as rotas simples que passam pelo seu emissor. Os caches s˜ao preenchidos por uma atualizac¸˜ao subseq¨uente com seq > 0. UmROUTE-

UPDATE ´e aceito como v´alido se o seu seq ´e maior do que o anterior ou se seq = 0 e o timestamp ´e maior do que o timestamp anterior emitido pelo mesmo n´o.

OsROUTE-UPDATEs s˜ao assinados digitalmente como forma de garantir sua autenticidade e evitar que sejam forjados. Cabe observar que assinar uma mensagem de roteamento oferece protec¸˜ao apenas contra elementos externos que tentam se passar por n´os do overlay; isso n˜ao evita que um n´o overlay envie atualizac¸˜oes contendo dados inv´alidos, uma ameac¸a leg´ıtima quando os n´os podem ter sido comprometidos (a sec¸˜ao 4.1.3 discute como dados de roteamento falsos s˜ao tratados).

Uma preocupac¸˜ao com o roteamento proativo s˜ao os problemas decorrentes da recepc¸˜ao de um grande n´umero de atualizac¸˜oes de rotas em curtos espac¸os de tempo. Um n´umero excessivo de men- sagens de roteamento pode esgotar algum recurso computacional de um n´o, como mem´oria ou ca- pacidade de processamento. Por exemplo, um roteador pode consumir toda a sua capacidade de processamento verificando assinaturas digitais, uma operac¸˜ao computacionalmente custosa. Embora o custo de gerac¸˜ao de uma assinatura digital seja maior que o custo de verificac¸˜ao, um n´o malicioso poderia simplesmente enviar uma grande quantidade de mensagens repetidas que teriam de ser pro- cessadas individualmente por um n´o correto. Um excesso de atualizac¸˜oes pode ser tamb´em provocado por flutuac¸˜oes nas informac¸˜oes de alcanc¸abilidade (flapping). Para proteger contra esses problemas, a freq¨uˆencia de emiss˜ao de atualizac¸˜oes de rotas na ROTI ´e limitada: um n´o n˜ao deve gerarROUTE-

UPDATEs a intervalos menores do que∆upd. Se a topologia ao redor de um n´o muda a uma taxa maior

do que essa, este n´o deve esperar at´e∆upd depois do envio da sua ´ultima atualizac¸˜ao antes de enviar

uma nova. Para fazer valer essa limitac¸˜ao, os n´os podem descartar ou — se houver espac¸o dispon´ıvel — armazenar em um buffer a ´ultima atualizac¸˜ao recebida menos de∆upd antes da atualizac¸˜ao ante-

rior. Essa restric¸˜ao n˜ao se aplica quando o n´umero de seq¨uˆencia ´e reiniciado, conforme explicado anteriormente.

4. Roteamento e Encaminhamento de Pacotes na ROTI 26

Este protocolo ´e relativamente eficiente, j´a que cada n´o envia O(n) c´opias de uma atualizac¸˜ao (uma para cada vizinho), o que corresponde a O(n2) atualizac¸˜oes para o total da rede. Para fins

de comparac¸˜ao, isso ´e uma ordem de grandeza menor do que o custo de um protocolo tradicional de estado de enlaces. Isso ocorre porque em protocolos de estado de enlaces as atualizac¸˜oes de roteamento s˜ao enviadas para todos os n´os da rede atrav´es de inundac¸˜ao, mecanismo que gera na ordem de O(n2) c´opias de cada mensagem, enquanto que no protocolo discutido acima elas s˜ao

difundidas apenas localmente (isto ´e, o n´o que recebe uma atualizac¸˜ao n˜ao a repassa aos seus vizinhos como em um protocolo de estado de enlaces).