Resumo

  • A RFC 3473 permitiu que um Notify RSVP-TE chegasse diretamente a um nó não adjacente registrado e usasse o ACK da RFC 2961 para confirmar o recebimento.
  • Notify não substituía PathErr nem ResvErr; o ACK provava a chegada do alerta, não a convergência do estado, a troca de proteção ou a volta do serviço.

Um alarme pode chegar antes do reparo que descreve. A RFC 3473 transformou essa diferença em estrutura de protocolo.

Publicada em janeiro de 2003, a especificação concretizou no RSVP-TE as funções GMPLS da RFC 3471. Rótulos generalizados, LSP bidirecional, restrições, proteção, separação entre controle e dados e recuperação ganharam objetos. A RFC 3472 fez o paralelo no CR-LDP. O Notify resolveu uma questão particular: avisar depressa o nó capaz de reagir quando ele não era vizinho do erro.

Uma Notify Request em Path pedia aviso para montante; em Resv, para jusante. O objeto trazia o endereço IPv4 ou IPv6 do Notify Node. Cada receptor deveria guardá-lo no estado correspondente e normalmente propagá-lo.

Esse endereço não era identidade imutável. Política local podia alterá-lo na saída. Se houvesse vários objetos, apenas o primeiro tinha significado. E a presença da solicitação não garantia que um Notify seria produzido.

Diante do erro apropriado, o detector podia visar um nó não adjacente. Nós intermediários encaminhavam a mensagem inalterada, ou o emissor a encapsulava em novo cabeçalho IP para o destino. Sem Router Alert, a trilha do aviso ficava diferente da falha e do caminho comum de PathErr/ResvErr.

ERROR_SPEC identificava erro e detector ou enlace falho; descritores delimitavam sessões. Um evento podia notificar as duas direções, mas não era permitido gerar Notify sem solicitação anterior adequada.

A RFC 2961 forneceu Message ID e ACK. O destinatário deveria acusar o Notify. Isso respondia apenas se aquela mensagem RSVP identificada chegou ao nó escolhido.

Não dizia se a falha era fisicamente verdadeira, se todos os estados foram removidos, se a rota alternativa tinha capacidade, se o comutador óptico mudou, se os pacotes voltaram ou se a aplicação respondeu. A RFC 3473 declarou que Notify não substituía mensagens de erro existentes. Era evidência suplementar, não commit da máquina RSVP.

Path_State_Removed separava ainda mais mensagem e ação. Um nó podia registrar em PathErr que realmente descartara o estado Path. O ACK do alerta e esse recibo local eram fatos diferentes; nenhum representava todos os saltos.

Avisos com o mesmo destino e ERROR_SPEC podiam ser agregados. Evento, temporizador ou outro método dependiam da implementação; o padrão temporizado era um milissegundo. A agregação reduzia carga, mas o instante do envelope não era necessariamente o de cada evento, e sessões reunidas não passavam a ter recuperação atômica.

O estado administrativo exigia confirmação posterior. Após enviar Down em Notify, o nó deveria ver um Path com Down em prazo configurável, trinta segundos por padrão. Sem isso, iniciava remoção e erros adicionais. O primeiro alerta não era conclusão.

Também podia falhar só o canal de controle. Durante espera de reinício, estado RSVP e encaminhamento podiam ser preservados. “Canal degradado” não provava perda de dados; “canal ativo” tampouco provava ressincronização ou serviço.

A entrega direta mudou a segurança. RSVP normalmente tinha integridade salto a salto. A RFC 3473 indicou IPsec para o Notify não adjacente ou permitiu desativá-lo. Mesmo autenticado e reconhecido, o alerta só demonstrava fatos limitados sobre emissor, conteúdo e recebimento.

As RFCs 4090, 4872 e 4873 detalharam desvio rápido, recuperação fim a fim e por segmento. Elas acrescentaram ações, sem fundir aviso, decisão, comutação e resultado observado.

Pelo princípio de código em execução de Heng Lu, Notify continuava símbolo até a transição pretendida aparecer no sistema que deveria agir. A especificação mínima deixava agregação e política locais. As camadas de realidade impediam que o ACK herdasse a autoridade de um serviço comprovadamente recuperado.

O registro completo conserva Path/Resv da solicitação, destino efetivo, detector, ERROR_SPEC, sessões, Message ID, envio, recebimento e ACK. Mantém separados PathErr/ResvErr, remoção, proteção ou teardown, programação, sinal, tráfego e aplicação. “Recuperado” pertence ao fim dessa cadeia.

Fontes