Resumo

  • A atualização resumida do RSVP faz referência a estados Path e Resv antes anunciados por inteiro. Ela mantém uma informação conhecida, mas não substitui a descrição necessária para instalar ou alterar um estado.
  • Pedir o que falta não é o mesmo que verificar o que continua presente. A RFC 2961 reconheceu que um resumo podia deixar de revelar corrupção interna que uma atualização completa teria oportunidade de reparar.
  • Recuperação após reinício e intervalos maiores trouxeram outras obrigações de associação de estado, entrega confiável e detecção de falhas. A economia de mensagens não eliminou o trabalho que elas faziam.

O vizinho devolvia uma lembrança

Em um procedimento de recuperação descrito em 2007, o controlador que acabara de reiniciar podia receber uma ajuda peculiar: seu vizinho a jusante informava quais mensagens Path havia recebido antes. Em vez de começar repetindo todas as descrições, ele podia citar identificadores antigos.

Era uma inversão útil. Na atualização resumida normal, o emissor se refere ao que havia anunciado. Na recuperação da RFC 5063, o vizinho podia resumir o que tinha recebido do outro lado. Se o controlador ainda reconhecesse as referências, haveria menos informação para retransmitir; se não reconhecesse, seria necessário recorrer à descrição mais completa de RecoveryPath.

Essa lembrança não tinha, porém, autorização para produzir um caminho de encaminhamento inexistente. A recuperação devia relacionar a sinalização com estado de encaminhamento preservado. Uma RecoveryPath, sozinha, não criava esse estado. A constituição de um novo caminho exigia os procedimentos apropriados, como uma Path vinda a montante ou uma instrução de gerenciamento no ingresso, sujeitos à política aplicável.

A ressalva ajuda a entender uma história que começara antes. O RSVP estava aprendendo a usar referências curtas para economizar manutenção. Cada referência, no entanto, só podia valer pelo que realmente permitia constatar. Recuperar uma descrição não era provar que o tráfego passava; reconhecer uma reserva não era conferir novamente seu conteúdo.

Antes do resumo, a descrição voltava inteira

Na especificação básica de setembro de 1997, a RFC 2205, os estados Path e Resv eram mantidos por atualizações periódicas. Sem novas atualizações durante tempo suficiente, expiravam. Uma mensagem explícita de remoção podia acelerar a limpeza, mas a perda dessa mensagem não deveria tornar a reserva permanente.

O chamado estado flexível tinha, assim, uma propriedade importante: a continuidade precisava ser sustentada. Só que repetir a descrição inteira também servia para reparar informação perdida ou não propagada. Uma nova passagem da descrição oferecia outra oportunidade de recompor o estado; mudanças de rota exigiam estabelecer as informações pertinentes no novo percurso.

Cada repetição comprava manutenção e recuperação ao mesmo tempo. Com muitas reservas, a conta em transmissão e processamento crescia. Aumentar o intervalo reduzia a carga, mas podia adiar certas correções; encurtá-lo fazia o contrário. Não bastava classificar a repetição como desperdício e apagar sua segunda função.

A RFC 2961, publicada em abril de 2001, separou o conteúdo alterado do conteúdo apenas repetido. Uma mudança exigia uma mensagem de atualização efetiva, inclusive quando atingia objetos de política e não apenas uma quantidade visível de recursos. O resumo não podia transformar uma alteração em mera renovação pelo artifício de reutilizar um número.

A referência precisava de um endereço e de uma história

MESSAGE_ID não era uma matrícula universal da reserva. Seu identificador era interpretado com um epoch e no âmbito do endereço de quem o gerara. Para as Path e Resv originais, esse endereço vinha de RSVP_HOP, não necessariamente do cabeçalho IP externo. O epoch ajudava a distinguir períodos de execução, sobretudo depois de um reinício.

O mecanismo resolvia a pergunta «a qual estado anunciado você se refere?». Não respondia «todos os campos desse estado continuam corretos?». O número não era uma função criptográfica do conteúdo, nem um certificado da capacidade alocada.

Primeiro, o estado completo precisava ser anunciado com MESSAGE_ID. Depois, a mensagem Srefresh podia listar a referência, permitindo que o destinatário localizasse e mantivesse o estado sem receber novamente todos os seus objetos. No desenho de 2001, o resumo não podia ocorrer com frequência menor que a atualização completa substituída. A economia estava inicialmente no tamanho da descrição, não em qualquer extensão arbitrária do período de silêncio.

Outras ferramentas do documento tratavam de custos diferentes. Bundle agrupava mensagens RSVP completas em um datagrama; não fundia várias solicitações em uma única reserva aprovada. Confirmações e retransmissões rápidas melhoravam a entrega de mensagens individuais. A organização do pacote, sua chegada e a decisão sobre recursos continuavam sendo coisas distintas.

Ausência era uma condição detectável

Se o destinatário pertinente não encontrasse o estado citado, podia enviar MESSAGE_ID_NACK. O emissor que ainda tivesse a informação correspondente deveria devolver uma Path ou Resv completa. Se também não a tivesse, não haveria conteúdo correspondente para restituir.

Esse retorno negativo não significava que a rede negara a largura de banda solicitada. Indicava falta de estado reconhecível. Confundir as duas interpretações poderia transformar um problema de sincronização em um diagnóstico de capacidade, ou fazer de uma retransmissão bem-sucedida uma falsa confirmação da reserva inteira.

Em multicast, ainda era preciso saber se o receptor deveria manter aquele estado. Informações de origem e grupo, com verificações de caminho reverso, limitavam quem deveria responder à falta de uma referência. Um nó alheio ao fluxo não precisava reclamar de algo que nunca lhe coube guardar.

O mecanismo conseguia, portanto, tornar uma ausência visível. Isso não o tornava igualmente capaz de examinar qualquer erro dentro de um registro que continuava acessível. Uma lista de identificadores não transportava as descrições necessárias para uma comparação completa.

A entrada podia existir e estar errada

A seção 5.5 da RFC 2961 registra a diferença de forma explícita. Atualizações resumidas ajudam diante de perdas de pacotes e mudanças de rota, mas não preservam exatamente todas as propriedades de recuperação das atualizações completas. A corrupção interna do estado aparece como um exemplo do que poderia escapar.

É uma limitação do desenho, não a afirmação de que houve uma falha específica em determinado operador. Pode-se imaginar uma entrada ainda localizável pelo identificador, mas com parte de sua descrição alterada indevidamente. O resumo consegue renovar a entrada sem necessariamente trazer material para corrigir aquela parte.

O documento propõe dois complementos diferentes. Um guarda um valor de verificação calculado sobre o estado ao emitir uma mensagem por mudança, depois o recalcula para perceber uma alteração que deveria ter provocado outra mensagem e não provocou. O próprio texto diz que esse método não protege contra corrupção interna. Seu alvo é uma mudança que deixou de ser anunciada.

O outro complemento volta a enviar Path e Resv completas ocasionalmente, em intervalo maior que o dos resumos. Assim, reaparece a oportunidade de recuperação oferecida pelo RSVP convencional, sem repetir tudo em cada rodada. A frequência relativa pode ser configurada; no período da mensagem completa, não há motivo para acrescentar também o resumo do mesmo estado.

Juntar as duas propostas numa promessa de «checksum que valida todo o conteúdo remoto» seria trocar a precisão do documento por uma garantia que ele recusou dar. Detectar uma atualização omitida, receber uma descrição de novo e provar a correção de todo o dispositivo não são a mesma atividade.

Autenticar o remetente não restitui os campos omitidos

Também não basta acrescentar autenticação para fechar essa diferença. A RFC 2747 trata a integridade das mensagens RSVP e a autenticação entre vizinhos sob as hipóteses de suas chaves. MESSAGE_ID não é esse mecanismo, e integridade não significa criptografia do conteúdo para confidencialidade.

Mesmo uma Srefresh autêntica não passa a carregar a descrição que economizou. O vizinho pode ser quem diz ser e, ainda assim, a verificação executada continuar limitada a uma referência. É por isso que a discussão de segurança da recuperação de 2007 também distingue a confiança no vizinho da correção de sua associação entre informações anteriores e posteriores ao reinício.

Uma confirmação de recebimento tem limite semelhante. Ela serve ao tratamento de uma mensagem individual; uma mensagem sintaticamente inválida não deve ser confirmada. Mas confirmar a recepção não demonstra a admissão de uma reserva de ponta a ponta, muito menos mede o desempenho do tráfego que a reserva pretende atender. Essas referências históricas tampouco são recomendações de algoritmos atuais.

Menos pacotes não significava menos estados

Em 2009, a RFC 5439 analisou a escala de RSVP-TE levando em conta memória e processamento por estado. Uma lista longa continua exigindo o exame de muitas referências. A redução das descrições é relevante, mas não apaga o número de reservas que o equipamento mantém. Não se pode converter essa análise em um limite universal para roteadores de hoje.

Já a RFC 8370, de maio de 2018, associa intervalos prolongados a obrigações adicionais: entrega confiável, manutenção mais frequente dos estados cujas mensagens ainda não foram confirmadas, detecção explícita da perda da adjacência de sinalização e anúncio das capacidades correspondentes.

Quando a adjacência falha, os estados Path e Resv aprendidos por ela devem ser tratados como expirados. O sistema não pode simplesmente esperar pela próxima atualização distante para perceber a perda do vizinho. A exigência reforçada de confirmações vale para as técnicas ali definidas; não deve ser atribuída retroativamente a qualquer implementação da RFC 2961.

Um vizinho sem a capacidade necessária continua sujeito ao comportamento tradicional. O registro de parâmetros RSVP da IANA fornece os valores comuns de mensagens, objetos e capacidades, mas não demonstra que uma função esteja ativa entre dois equipamentos. Uma capacidade que deixa de aparecer nas mensagens não pode ser presumida apenas porque existia no passado.

Esses documentos descrevem projetos e condições, não uma adoção uniforme por todas as redes. O fio da história é a redistribuição de tarefas: manutenção barata, reposição de descrições, recuperação após reinício e detecção de falhas foram ganhando meios mais explícitos. O estado podia permanecer vivo. A pergunta sobre o que havia sido realmente conferido precisava continuar viva também.