Resumen

  • RFC 6525 permitió reiniciar la secuencia de flujos SCTP seleccionados sin derribar la asociación ni alterar los flujos no incluidos.
  • Sender’s Last Assigned TSN fijaba el límite de la época antigua. Si el acuse acumulativo todavía no llegaba allí, el receptor respondía «In progress» y retenía los datos posteriores.
  • La propia reconfiguración tenía números de solicitud, respuestas repetibles y posibilidad de rechazo: para olvidar una secuencia de datos había que recordar con precisión la secuencia del control.

Cero no significaba que el pasado hubiera salido de la red

Una asociación SCTP reúne varios flujos unidireccionales. En el RFC 4960, cada fragmento DATA llevaba un Transmission Sequence Number común a la asociación, mientras cada mensaje ordenado usaba un Stream Sequence Number dentro de su flujo. El RFC 9260 mantiene esa división: TSN sostiene acuses y detección de duplicados; la entrega ordenada se acota al flujo.

Por eso reiniciar un solo contador no era una operación local inocente. Un fragmento viejo podía seguir retrasado aunque la aplicación ya quisiera reutilizar el flujo para otra función. Si el SSN volvía a cero de inmediato, el receptor podría confundir ese fragmento con la nueva época. Si se cerraba la asociación completa, se perdían rutas y flujos que no necesitaban cambiar.

El RFC 6525 introdujo en 2012 el chunk RE-CONFIG. La extensión no borraba tráfico en vuelo. Coordinaba el momento en que los extremos podían dejar atrás una numeración y comenzar otra.

El último TSN asignado era una frontera, no un reloj

La solicitud Outgoing SSN Reset Request incluye un número de solicitud de reconfiguración, un número de respuesta, Sender’s Last Assigned TSN y una lista opcional de flujos. Sin lista abarca todos los flujos salientes; con lista, deja intactos los demás.

El último TSN asignado es el siguiente TSN menos uno. Antes de enviar la solicitud, el emisor deja de asignar SSN nuevos a los flujos afectados y encola los mensajes posteriores. Si continuara transmitiendo mientras desconoce el resultado, una solicitud perdida abriría una ambigüedad entre épocas.

El receptor compara el límite con su punto de acuse acumulativo. Cuando todavía está por debajo, entra en procesamiento diferido. Los datos de los flujos afectados con TSN superior al límite quedan retenidos y la respuesta indica «In progress». El mensaje confirma que la petición fue entendida; no confirma que el reinicio terminó.

Solo al alcanzar el punto acumulativo el receptor lleva a cero el próximo SSN esperado de los flujos indicados, libera los TSN retenidos y responde con éxito. Los flujos no listados continúan con sus secuencias. La novedad no nace de una orden unilateral, sino de una frontera que ambas partes pueden observar.

La orden de olvidar necesitaba su propia memoria

Las solicitudes RE-CONFIG llevan una secuencia monotónica, inicializada a partir del TSN inicial. La respuesta copia el número solicitado y puede comunicar éxito, rechazo, SSN incorrecto, solicitud ya en curso, secuencia inválida o procesamiento en curso.

Si reaparece la última solicitud por una retransmisión, el receptor devuelve la misma respuesta anterior. No ejecuta otro reinicio. La reconfiguración protege así su historial aunque esté cambiando el historial de numeración de los datos.

«In progress» reinicia el temporizador del solicitante y permite retransmitir sin incrementar los contadores de error de la asociación. No es una señal de congestión ni una avería del camino. Tras el éxito, el emisor reinicia el estado saliente, procesa su cola y vuelve a asignar números.

El receptor también puede negarse. RFC 6525 considera administrativa esa decisión, incluso después de formada la asociación. La negociación de la extensión indica que existe un idioma para pedir el cambio; no obliga a aprobar cada petición.

Cada dirección conservaba su autoridad

Los flujos SCTP son unidireccionales. Un número igual en sentido contrario no crea por sí solo una conversación bidireccional. Para reiniciar las secuencias entrantes, un extremo solicita al par que reinicie sus secuencias salientes; quien asignó los números controla el corte real.

SSN/TSN Reset es otra operación. Reinicia todos los SSN entrantes y salientes y establece nuevos puntos TSN. Mientras se tramita, el emisor deja de asignar TSN, y el protocolo usa la vida máxima de segmento para evitar ambigüedad en el retorno circular del espacio numérico. No debe confundirse con el reinicio selectivo de un flujo.

El RFC 6458 expone números y notificaciones SCTP a las aplicaciones. RFC 6525 exige por ello habilitar explícitamente la extensión y sus avisos: una aplicación que espera una progresión monotónica necesita saber cuándo cambió de época.

I-DATA sustituyó el contador, no la obligación de coordinar

El RFC 8260 permite intercalar mensajes y usa Message Identifiers de 32 bits con I-DATA. Al reiniciar, deben volver a cero dos contadores MID por flujo, para mensajes ordenados y no ordenados. La asignación tardía de TSN de muchos planificadores complica la implementación, pero no autoriza un borrado anticipado.

Tampoco es fiabilidad parcial. El RFC 7496 añade políticas para que el emisor abandone mensajes por prioridad o por límite de retransmisiones. Abandonar un mensaje resuelve cuánto seguir intentando; reiniciar un flujo decide cuándo una numeración puede comenzar otra vez.

El registro SCTP de IANA asigna a RE-CONFIG el tipo 130 y enumera parámetros y resultados. Sirve para decodificar evidencia, no para afirmar que un producto implementa la extensión, que dos pares la negociaron o que una aplicación la activó.

Fuentes