Resumen

  • Como ATM UNI no podía cambiar la QoS de un VC activo, el circuito anterior debía seguir funcionando mientras se construía el sustituto; sólo al terminar se trasladaba tráfico y se cerraba el viejo.
  • Si el reemplazo fallaba, una ampliación devolvía error, pero una reducción podía considerarse exitosa manteniendo la asignación mayor.

Éxito sin coincidencia física

RSVP aceptaba cambios de reserva en cualquier momento; ATM UNI 3.x y 4.0 no modificaba parámetros QoS después de crear el VC. La RFC 2380 resolvió la diferencia con sustitución: mantener intacto el VC viejo, preparar uno nuevo, mover tráfico después de completar la preparación y cerrar el anterior sólo entonces. Si el nuevo fallaba, el viejo seguía.

Una ampliación fallida debía responder con error porque faltaban recursos. Una reducción fallida se trataba como exitosa: el circuito grande ya satisfacía la demanda menor. Era ineficiente, pero preservaba el servicio y la semántica de errores RSVP. La respuesta no afirmaba que ATM hubiera liberado capacidad; solicitud vigente y recursos retenidos eran comprobantes distintos.

La inactividad no era una orden

Los VC IP sobre ATM ordinarios podían expirar por silencio. RSVP ya tenía mensajes y temporizadores para gobernar la vida de la reserva. Por eso un VC controlado por RSVP no podía desaparecer por inactividad: temporizador infinito en el iniciador y ninguna limpieza equivalente en el receptor. El silencio medía tráfico; no autorizaba liberar recursos.

El receptor pedía y el emisor construía

La reserva RSVP era orientada al receptor, mientras el control ATM era orientado al emisor. El emisor de la subred tenía que iniciar los VC QoS y el receptor aceptarlos. Un RESV no era un recibo de circuito creado.

Control y datos tampoco podían compartir el VC QoS. Una avería irrecuperable de datos era fallo de asignación. Si fallaba de forma irrecuperable el VC de control, debían soltarse los VC QoS asociados para que el reenvío no sobreviviera a la reserva sin explicación.

Multicast prefirió duplicación breve a pérdida

Enviar por el VC viejo y el nuevo podía duplicar paquetes; usar un nuevo VC incompleto podía omitir receptores. Al crear un VC multicast nuevo, no se enviaba hasta incorporar a todos. Al mover un único extremo a un VC QoS existente, se añadía primero y se eliminaba después del camino best effort. Esa ventana duplicada evitaba un vacío.

La transición podía ser simultáneamente una reserva menor, una respuesta positiva, un circuito grande, un coste aún alto y un servicio continuo. Ningún estado resumía por sí solo el proceso.