Resumo

  • A RFC 3654 não determinou que um Forwarding Element continuasse sempre encaminhando nem que parasse sempre ao perder a associação com seu Control Element. Ela exigiu que a arquitetura detectasse a perda, restabelecesse a associação, ressincronizasse o estado e permitisse definir antes a reação do FE.
  • A RFC 7121 descreveu depois dois modos de recuperação: um retorna à pré-associação; outro pode tentar CEs de reserva e manter o encaminhamento até o vencimento de um prazo. Reconectar não prova, por si só, que todo o estado do FE foi restaurado.

Um equipamento integrado, duas funções lógicas

Em novembro de 2003, a RFC 3654 descreveu um elemento de rede como componentes de controle e encaminhamento que cooperam, mas podem parecer um roteador IP integrado para os sistemas externos. O Control Element (CE) executa funções como protocolos de roteamento e sinalização; o Forwarding Element (FE) lida com o processamento de cada pacote. A separação é lógica, não exige dois chassis. A RFC menciona escalabilidade e evolução independente dos planos, sem afirmar que esse desenho já era amplamente implantado. RFC 3654

A situação difícil surge quando o FE ainda conserva tabelas e funções configuradas, mas deixa de estar associado ao CE que as administra. Dizer que “o controle falhou” não informa o destino dos pacotes: o FE pode seguir com o estado atual, parar ou tentar alcançar um CE de reserva. A RFC 3654 trata essas possibilidades como perguntas distintas.

A regra exigia uma escolha, não uma resposta única

O requisito arquitetural 7 reúne quatro obrigações: detectar a perda de associação, restaurá-la, ressincronizar o estado com eficiência e pré-definir a ação do FE. Seguir encaminhando ou interromper as operações são exemplos no documento; ele não escolhe uma conduta universal. O requisito de protocolo 8 repete essa distinção. RFC 3654

Continuar pode preservar o tráfego, mas deixa o FE dependente do estado que já possui. Parar reduz esse período, embora torne o serviço dependente da associação de controle. São consequências para o projeto avaliar, não incidentes que a RFC diga ter ocorrido. A exigência é tornar a resposta conhecida antes da falha, em vez de deixar que o silêncio da implementação decida por acaso.

A alta disponibilidade posterior acrescentou modos e um relógio

A RFC 5810, publicada em 2010 como protocolo Standards Track, definiu o protocolo ForCES e sua Transport Mapping Layer para atender aos requisitos da RFC 3654. A RFC 5812 descreveu o modelo do FE: capacidades, estado atual, configuração pretendida e blocos funcionais lógicos. Capacidade não é estado instantâneo, e nenhum dos dois é a configuração desejada. RFC 5810 RFC 5812

Em 2014, a RFC 7121 acrescentou um procedimento de alta disponibilidade dentro do elemento de rede. O FE Protocol Object identifica o CE principal e os de reserva; intervalos e políticas de heartbeat ajudam a detectar problemas de conectividade. No modo 0, padrão, a perda de associação leva o FE à pré-associação; se ele se associar depois, seu estado precisa ser recriado. O modo 1 permite recuperação por reinício: o FE tenta os CEs de reserva em ordem circular enquanto corre o CE Failover Timeout Interval. Durante o estado “não associado”, ele pode seguir encaminhando, conforme a política configurada. Se o prazo expira sem associação, o FE volta à pré-associação e desativa seu caminho de encaminhamento. Depois da reconexão, o CE pode tentar sincronizar o estado perdido; o método fica fora do escopo da arquitetura ForCES e normalmente envolve novas mensagens de configuração e consultas. RFC 7121

Heartbeat também não é um veredito sobre a rota. A RFC 3654 permite priorizar a rapidez dos heartbeats usados para detectar perda de associação em vez da entrega estritamente confiável. Já tabelas de encaminhamento e configurações críticas exigem entrega robusta. Um sinal ausente pode participar de uma mudança de estado da associação, mas não prova sozinho uma falha física, rotas incorretas ou a indisponibilidade total do equipamento. RFC 3654

A RFC 3532, outro documento ForCES, abordou a realocação dinâmica de recursos e o atraso possível entre a mudança no elemento de comutação e o modelo do controlador. É uma questão próxima, mas diferente: aqui o foco é a ação pré-definida do FE e a recuperação após perder a associação. A RFC 3654 é Informational; os padrões posteriores documentam o detalhamento do desenho, não a adoção por um operador específico. RFC 3532 RFC 3746 RFC 1812 Registro da RFC 3654 Datatracker da RFC 3654

Fontes