Resumo

  • RFC 3469 dividiu a recuperação MPLS em detecção, espera, notificação, operação e retorno efetivo do tráfego.
  • Um caminho pré-estabelecido podia compartilhar o defeito, não ter capacidade reservada, oferecer serviço limitado ou deixar o tráfego sem uma segunda proteção.

Uma linha de backup no inventário parecia uma promessa concluída. RFC 3469 mostrou que ela era apenas uma entrada numa cadeia maior. Quando o caminho de trabalho falhava, ainda era necessário saber quem percebeu o dano, quem o declarou, quem podia mover o tráfego e se a alternativa tinha recursos naquele instante.

Publicado em fevereiro de 2003 como RFC Informacional, o documento não definiu um protocolo único nem relatou desempenho de uma implantação. Reinicialização ficou fora do escopo. Ele forneceu linguagem comum para comparar soluções e, sobretudo, impediu que “recuperação” escondesse vários acontecimentos independentes.

O primeiro corte foi entre reroteamento e comutação de proteção. Rerotear significava criar um caminho depois da falha. Proteger significava usar um caminho preparado antes. Os modelos podiam trabalhar em sequência: uma troca rápida restabelecia conectividade provisória, a rede chegava a um estado semiestável e, após convergência, o tráfego migrava para uma nova rota de trabalho.

O caminho pronto podia, porém, atravessar o mesmo enlace, nó ou risco físico. Podia ter rótulos sem banda reservada. Podia ter sido criado para outro uso e apenas pré-qualificado. Podia falhar antes ou ao mesmo tempo que a rota principal. A presença do objeto de controle não demonstrava disponibilidade no plano de dados.

RFC 3469 organizou o primeiro ciclo em cinco tempos. T1 ia do comprometimento à detecção. T2 era a espera configurada. T3 levava o Fault Indication Signal ao Path Switch LSR quando o detector não era o ponto de reparo. T4 cobria as ações e eventual coordenação com o Path Merge LSR. T5 só terminava quando o tráfego voltava a chegar ao ponto que sofrera interrupção.

Esse T5 recusava o atalho mais comum: encerrar o cronômetro quando a mudança de configuração retorna sucesso. O rótulo pode ter mudado enquanto os pacotes ainda se perdem, chegam fora de ordem, aguardam em fila ou disputam capacidade insuficiente. Comutação concluída é um recibo de controle; tráfego recuperado é outro.

Havia também o ciclo de reversão. Reparar a infraestrutura não bastava: era preciso detectar a limpeza, esperar estabilidade quando necessário, notificar, executar a volta e observar o tráfego no caminho preferido. Uma volta apressada podia reintroduzir a falha. Make-before-break diminuía perda e reordenação, sem eliminar a validação.

O ciclo de reroteamento dinâmico começava num estado semiestável. Protocolos convergiam, um hold-down limitado podia impedir oscilação, um novo caminho era montado e o tráfego mudava outra vez. A proteção rápida comprava tempo para engenharia; não prometia que o primeiro desvio seria permanente.

Configuração de caminho e alocação de recursos eram dimensões separadas. A alternativa podia ser pré-estabelecida, pré-qualificada ou criada sob demanda. Banda, buffers e processamento podiam ser pré-reservados ou obtidos após a falha. O RFC chamou de equivalente a rota que preservava as garantias e de limitada a que aceitava serviço inferior. Uma rota limitada era útil, mas não deveria virar o novo normal sem decisão.

Em 1+1, o tráfego seguia simultaneamente por dois caminhos e o ponto de fusão escolhia. Em 1:1, o recurso de proteção podia transportar carga preemptível até que o fluxo protegido precisasse dele. Nos arranjos 1:n e m:n, um conjunto de reservas compartilhadas atendia apenas os cenários previstos. Contar backups não informava quais falhas simultâneas eram cobertas.

O ponto de reparo alterava tempo e abrangência. Reparo local agia perto do enlace ou vizinho defeituoso. Reparo global podia contornar uma região maior e ganhar separação, mas dependia de notificação até um ponto distante. Uma saída alternativa podia restaurar encaminhamento sem recriar o caminho original. Um túnel de desvio podia agregar várias proteções e, ainda assim, não ter capacidade para ativá-las juntas.

A proteção também podia ser seletiva. Uma porção de tráfego ou um grupo de caminhos recebia tratamento, sem que as demais classes fossem salvas. A referência histórica aos bits EXP deve ser entendida pela posterior definição Traffic Class de RFC 5462; o ponto é quem entra no conjunto protegido.

Falha total e degradação não eram iguais. Um defeito suave precisava ultrapassar um limiar configurado para ser declarado. Sinais de camada inferior podiam acelerar a detecção. Se o equipamento que observava não tinha autoridade de reparo, enviava FIS a quem tinha. Observação, declaração, notificação e ação formavam registros distintos.

Depois da troca, aparecia uma janela perigosa. No modo revertivo, o tráfego aguardava a estabilidade da rota preferida. Enquanto usava sua única proteção, podia ficar sem defesa contra outra falha, e os recursos do caminho antigo ainda permaneciam presos. No modo não revertivo, a alternativa virava caminho de trabalho, o caminho reparado podia virar proteção ou uma nova dupla era construída.

Daí a diferença entre tempo de recuperação e tempo de restauração completa. O primeiro somava detecção, espera, aviso, operação e retorno do tráfego. O segundo continuava até o uso de enlaces devidamente projetados para a carga do cenário. Os números coincidiam apenas se a primeira recuperação já fosse equivalente e permanente.

O quadro comparativo incluía vulnerabilidade durante a montagem, capacidade de backup, latência adicional, qualidade, reordenação, estado, perda e cobertura. A referência de comutação comparável a 50 milissegundos de SONET era um objetivo de projeto, não medição nem garantia de aplicação.

RFC 4090 formalizou depois fast reroute RSVP-TE. RFC 4426, 4427 e 4428 aprofundaram funções, termos e recuperação multicamada. RFC 5714 tratou de IP fast reroute. Esses textos mostram continuidade técnica, mas não provam adoção, diversidade física nem sucesso do usuário.

Pela primazia do código em execução de Heng Lu, “pré-estabelecido” e “recuperado” continuam símbolos até tabelas, recursos e tráfego concordarem. A especificação inicial mínima ajuda a entender as primitivas combináveis do RFC. As camadas de realidade impedem que alarme, decisão, pacote e resultado sejam fundidos.

A herança de RFC 3469 é uma regra de prova. O backup no mapa não encerra a investigação. É preciso registrar quem detectou, quem declarou, aonde chegou o sinal, quem tinha autoridade, que recursos estavam livres, onde os pacotes reapareceram, qual qualidade restou e quando o serviço voltou a ter proteção para outra falha.

Fontes