Período de Convergência do OSPF

Quando um nó detecta uma mudança no estado do enlace, e.g. uma falha de enlace/nó (mudança de estado não planejada) ou adição de novo enlace/nó (mudança de estado planejada), o protocolo OSPF adota uma abordagem reativa, ou seja, procura adaptar a configuração da rede às mudanças causadas pelo novo estado do enlace para garantir a redistribuição dos fluxos de tráfego na nova estrutura de topologia. O período decorrido entre a detecção da mudança de estado e a atualização das tabelas RIB e FIB de acordo com a nova topologia corresponde ao período de convergência do OSPF.

De forma geral, as etapas executadas por cada nó OSPF durante o período de convergência são: detecção da falha, a modificação e notificação dos novos estados do enlace (LSA), recálculo do SPF na RIB e o preenchimento da FIB [VASSEUR et al, 2004]. O tempo de execução destas etapas no OSPF depende da topologia da rede, da quantidade de nós existentes, da carga de tráfego, da quantidade de prefixos de rede existentes e da velocidade de processamento do nó.

A Figura 2.5 adaptada de [VASSEUR et al, 2004], ilustra esses passos que cada nó OSPF realiza ao detectar uma falha.

Figura 2.5 Tempo de Recuperação de um nó OSPF

Os nós adjacentes à uma falha normalmente detectam essa falha através de mensagens de controle OSPF ponto a ponto nomeadas hello (passo (1) da Figura 2.5). As mensagens do tipo hello são geradas localmente por cada nó para seus nós vizinhos a cada 10 segundos [MOY, 1998] (valor padrão, que pode ser alterado para o mínimo a cada 1 segundo [BASU and RIECKE, 2001]). Caso haja timeout nessas mensagens hello (entre 30 e 60 segundos [IANNACCONE et al, 2004]), as rotinas de roteamento do OSPF interpretam como um evento de falha do enlace adjacente. Alguns hardwares possuem temporizadores que evitam várias sinalizações de mudança de estado para rotinas de roteamento (LinkDown) causadas por oscilações no enlace. Os temporizadores atuam quando o enlace volta do estado inativo (falha) para o estado ativo, esperando então 10 segundos para sinalizar as rotinas de roteamento [FRANCOIS et al, 2005]. Porém, dependendo do equipamento utilizado, como em equipamentos CISCO, existe um temporizador em software em seu sistema denominado carrier-delay, que atrasa o processamento dos sinais de falha do hardware (útil quando o hardware não possui um temporizador corretamente implementado). A configuração padrão do carrier-delay de fábrica é 2 segundos para sinalizar as rotinas de roteamento sobre uma falha, e 12 segundos para sinalizar uma recuperação da falha [IANNACCONE et al, 2002].

Ao detectar e interpretar uma mudança no estado do enlace (falha ou evento

LinkDown), as rotinas de roteamento atualizam as informações do estado do enlace local na RIB e notificam/propagam essa informação através de mensagens LSAs, sendo ilustrado no passo (2) da Figura 2.5. Essa notificação propaga o LSA a todos os seus nós vizinhos, que atualizam suas RIBs e repassam o LSA para seus próximos nós vizinhos de forma a inundar todos os nós do mesmo AS. O processo de atualizar a RIB e notificar o

LSA aos vizinhos pode levar de 10 a 50 milissegundos por nó [IANNACCONE et al, 2004], sem ainda considerar o atraso de propagação dos enlaces.

As rotinas de roteamento de um nó, ao receber uma mensagem LSA com alteração do estado do enlace, não executam o cálculo SPF imediatamente, pois podem existir outras mensagens LSA na rede, mas ainda não recebidas e processadas pelo nó. Caso esse cálculo fosse aplicado imediatamente, poderia acarretar vários cálculos SPF: um para cada mensagem LSA nova que seja recebida e processada. Por exemplo, para um nó detectar que uma falha seja do nó adjacente, esse nó deve receber as demais mensagens LSA (que indicam falha de enlace) de outros nós vizinhos ao nó falho para então atualizar sua RIB e identificar esse tipo de falha. Apenas quando receber todas as LSAs o nó deveria calcular o SPF, caso contrário haverá várias execuções SPF desnecessárias. Por esse motivo as rotinas de roteamento OSPF não executam o cálculo SPF imediatamente, mas sim após certo intervalo de tempo definido (spf_interval, que é definido por padrão em aproximadamente 5,5 segundos [IANNACCONE et al, 2004]) para poder receber os demais LSA. Após esse tempo, as rotinas de roteamento podem seguramente realizar o cálculo SPF apenas uma vez e atualizar a FIB. O tempo de execução do SPF também é um fator a ser considerado, pois necessita realizar o cálculo da árvore SPF inteira (necessita entre 100 e 400 milissegundos [IANNACCONE et al, 2004] dependendo da configuração e tamanho da topologia). Essa etapa é ilustrada no passo (3) da Figura 2.5.

O último passo (4) é o preenchimento/atualização das rotas na FIB. Nesse passo, em equipamentos do backbone Tier-1, em torno de 20 entradas são atualizadas na FIB por milissegundo [IANNACCONE et al, 2004]. Uma alteração no estado do enlace que afete milhares de entradas em uma FIB é regularmente encontrada em backbones [IANNACCONE et al, 2004]. Portanto, considerando esses valores, uma FIB com 10000 entradas afetadas levaria em torno de 500 milisegundos para ser preenchida.

Dentre todos esses passos, os demais nós da rede (não adjacentes à falha) possuem como tempo de recuperação somente a atualização da RIB com notificação aos demais nós, o spf-interval com o cálculo SPF na RIB, e o preenchimento da FIB (passos (2), (3) e (4) da Figura 2.5).

O estudo [IANNACCONE et al, 2002] realizou uma avaliação desses passos no

backbone Sprint utilizando as configurações padrão do OSPF. Para um evento LinkDown detectado em um nó, obteve-se um tempo de convergência para esse nó entre 5,1 e 5,9 segundos (carrier-delay + notificação + spf-interval + SPF) e adicionando 1,5 segundos

de atualização na RIB/FIB, resulta em um total entre 6,6 e 7,4 segundos. Para um evento de LinkUp detectado, obteve-se um tempo de convergência entre 17,5 e 17,6 segundos (carrier-delay + notificação + spf-interval + SPF) e adicionando 1,5 segundos de atualização na RIB/FIB, resulta em um total entre 19,0 e 19,1 segundos. Dependendo das características da topologia e do tráfego utilizados, pode-se atingir até alguns minutos [BOUTREMANS, 2002] se utilizar detecção de falha por software.

Quando todos os nós terminarem a reação ao novo estado do enlace, chega-se então ao final do período de convergência do OSPF.