Resumo

  • O RFC 6525 permitiu zerar o estado de sequência de fluxos SCTP escolhidos sem derrubar a associação nem alterar os fluxos não listados.
  • Sender’s Last Assigned TSN marcava o fim da época anterior. Enquanto o reconhecimento cumulativo não chegasse ali, o receptor respondia “In progress” e retinha os dados posteriores.
  • A reconfiguração tinha sua própria sequência de pedidos, respostas repetíveis e possibilidade de recusa: esquecer a sequência dos dados exigia preservar a memória do controle.

O zero não expulsava o passado da rede

Uma associação SCTP carrega vários fluxos unidirecionais. No RFC 4960, cada fragmento DATA recebe um Transmission Sequence Number válido na associação, enquanto mensagens ordenadas recebem um Stream Sequence Number dentro do fluxo. O RFC 9260 mantém a separação entre reconhecimento global por TSN e ordem local por fluxo.

Um aplicativo pode terminar o uso do fluxo 3 quando fragmentos antigos ainda estão em retransmissão. Voltar o SSN imediatamente a zero permitiria que um fragmento atrasado parecesse pertencer ao novo uso. Fechar a associação inteira, porém, destruiria fluxos e estado de caminho que nada tinham a mudar.

O RFC 6525 definiu em 2012 o chunk RE-CONFIG. Ele não apaga pacotes em trânsito; coordena o ponto em que as duas pontas podem encerrar uma numeração e iniciar outra.

O último TSN atribuído desenhava a fronteira

Outgoing SSN Reset Request leva o número do pedido de reconfiguração, o número de resposta, Sender’s Last Assigned TSN e uma lista opcional de fluxos. Sem lista, todos os fluxos de saída são atingidos; com lista, os demais permanecem inalterados.

O último TSN atribuído é o próximo TSN menos um. Antes de pedir o reset, o emissor para de atribuir novos SSNs aos fluxos envolvidos e enfileira as mensagens seguintes. Se continuasse enviando enquanto o resultado fosse incerto, a perda do pedido misturaria as duas épocas.

O receptor compara a fronteira com seu ponto de reconhecimento cumulativo. Se ainda estiver abaixo, entra em processamento adiado, guarda localmente os dados dos fluxos afetados cujo TSN seja maior e responde “In progress”. A resposta prova que o pedido foi compreendido, não que terminou.

Quando o reconhecimento chega à fronteira, o receptor zera o próximo SSN esperado dos fluxos indicados, libera os TSNs retidos e envia sucesso. Fluxos não listados seguem sua sequência. O recomeço só existe quando ambos conseguem separar o antigo do novo.

A ordem de esquecer precisava lembrar de si mesma

Os números de pedido RE-CONFIG crescem monotonicamente e partem do TSN inicial. A resposta copia o número e pode declarar sucesso, recusa, SSN incorreto, pedido já em andamento, sequência inválida ou operação em andamento.

Uma retransmissão do último pedido recebe a mesma resposta anterior; não provoca outro reset. Ao receber “In progress”, o solicitante reinicia o temporizador sem aumentar os contadores de erro da associação. Não se trata de falha de caminho ou sinal de congestionamento.

O par pode recusar o pedido. O RFC chama essa escolha de administrativa e permite configurá-la mesmo depois da formação da associação. Entender a extensão não equivale a entregar ao outro lado autorização irrestrita para mudar estado.

Pedidos simultâneos também distinguem duplicação total de sobreposição parcial. Se um pedido recebido estiver completamente coberto por um reset de saída já pendente, a resposta pode ser “Nothing to do”. Uma sobreposição apenas parcial continua sendo processada, ainda que um fluxo já em zero seja zerado outra vez. A troca adicional é preferível a fundir, sem prova, duas intenções diferentes.

A mesma extensão permite pedir mais fluxos de entrada ou saída. Um novo fluxo de saída não pode ser usado antes da resposta positiva do par. Portanto, RE-CONFIG não é uma licença genérica para reescrever a associação: cada mudança estrutural tem seu próprio ponto de confirmação.

Entrada e saída mantinham autoridades diferentes

O fluxo SCTP é unidirecional. O mesmo número na direção oposta não forma automaticamente um canal bidirecional. Para zerar a sequência que recebe, uma ponta pede ao par que zere a sequência que ele envia; quem atribuiu os números conhece a fronteira real.

SSN/TSN Reset é uma operação separada, que reinicia todos os SSNs e escolhe novos pontos TSN. O emissor suspende a atribuição de TSN e usa precauções de vida máxima de segmento para evitar ambiguidade no retorno do espaço numérico. Não é sinônimo de reset seletivo.

O RFC 6458 expõe sequências e notificações SCTP ao aplicativo. Por isso a reconfiguração e seus avisos precisam ser habilitados explicitamente: o programa deve saber que sua hipótese de monotonicidade mudou.

I-DATA mudou o contador, não a obrigação de delimitar

O RFC 8260 usa Message Identifiers de 32 bits com I-DATA para intercalar mensagens. Um reset então zera dois contadores MID, para mensagens ordenadas e não ordenadas. A atribuição tardia de TSN usada por muitos escalonadores dificulta a implementação, mas não elimina a fronteira.

Isso também não é confiabilidade parcial. O RFC 7496 define políticas para abandonar mensagens por prioridade ou limite de retransmissões. Abandono decide até quando insistir numa mensagem; reset decide quando um espaço de sequência pode ser reutilizado.

O registro SCTP da IANA atribui o tipo 130 a RE-CONFIG. Ele decodifica números, mas não prova implementação, negociação entre as pontas ou habilitação pelo aplicativo.

RFC 6525 observa ainda que as verification tags do SCTP continuam protegendo contra atacantes cegos. A afirmação é limitada: não autentica a intenção do aplicativo, não resolve um adversário em caminho e não substitui autorização administrativa. Evidência operacional precisa unir capacidade anunciada, configuração e resultado efetivo.

Fontes