Resumen

  • La RFC 2379 recomendó transportar los mensajes de control RSVP por la ruta de datos de mejor esfuerzo que ya existía, aunque esos mensajes fueran a provocar la creación de circuitos virtuales ATM separados con parámetros de calidad de servicio.
  • Su enseñanza perdurable es probatoria: PATH o RESV, el estado RSVP, la admisión, el VC configurado y el rendimiento observado son comprobantes relacionados, nunca una sola certeza.

Pedir una garantía desde una ruta que no la ofrecía

RSVP nació para solicitar reservas de recursos y ATM podía construir circuitos virtuales con atributos de servicio definidos. Aun así, la RFC 2379 no exigió crear primero un canal protegido para la propia señalización. Indicó que los mensajes RSVP circularan por la ruta de mejor esfuerzo ya usada para llegar al destino o, en multidifusión, por la ruta ordinaria hacia el grupo.

La decisión reducía mecanismos. Alguna ruta de mejor esfuerzo tenía que existir antes de establecer una sesión e iniciar una reserva. Reutilizarla para el control evitaba abrir y sostener más circuitos ATM sólo para pedir otros circuitos. Así, el plano de control solicitaba un servicio superior mientras atravesaba un transporte inferior.

El documento no rebautizó ese transporte como fiable. Reconoció que un VC de mejor esfuerzo quizá no proporcionara toda la fiabilidad que RSVP prefería. La tolerancia procedía del tiempo: RSVP mantenía estado blando, renovado periódicamente. La pérdida de algún paquete no tenía por qué romper la sincronización si una actualización posterior conservaba o reconstruía el estado.

Eso tampoco volvía irrelevante la pérdida. Un mensaje perdido debía interpretarse junto con los refrescos siguientes, la expiración del estado, la decisión de admisión y la continuidad del circuito. La fiabilidad pertenecía a la secuencia, no a un paquete aislado.

Una reserva y un VC separado

ATM invitaba a compartir. Varias sesiones RSVP podían, en teoría, agregarse sobre un mismo circuito y consumir menos recursos. Pero la agregación aún era materia de investigación. La recomendación operativa fue utilizar un VC independiente para cada reserva RSVP.

Con ello quedaba expuesta la cadena completa. Una sesión RSVP no era ya un circuito ATM. Había que traducir la reserva a parámetros ATM, decidir la admisión, crear o elegir el VC y clasificar el tráfico. Y la existencia del VC tampoco acreditaba por sí sola que los paquetes recibieran el trato solicitado.

Las RFC compañeras dividieron el trabajo: la 2380 fijó requisitos de implementación; la 2381 relacionó los servicios Integrated Services de carga controlada y garantizado con ATM; la 2382 proporcionó el marco general. Esa distribución impedía atribuir a un solo mensaje el éxito de todas las etapas.

El atajo heredaba su extremo

Los atajos ATM podían atravesar límites de subredes IP lógicas. PATH y RESV podían entonces seguir caminos asimétricos. La RFC 2379 recurrió al comportamiento RSVP ya definido—el objeto NHOP y el reenvío de mensajes que llegaran por la interfaz equivocada—para manejar esa asimetría.

Más importante era quién elegía el extremo. Un atajo QoS no debía inventar un destino por su cuenta. Cuando el tráfico de mejor esfuerzo ya había elegido un atajo, el VC de QoS activado por RSVP debía terminar en el mismo punto. Si nunca se creaba el atajo de mejor esfuerzo, el modelo recomendado tampoco creaba un atajo QoS entre subredes.

No era una prohibición de servicio reservado. Los VC QoS salto a salto seguían disponibles. Era una regla de procedencia: el contexto de reenvío de mejor esfuerzo descubría el destino y la construcción QoS seguía esa decisión. El circuito resultante probaba una configuración, no convertía retrospectivamente en exitosos el descubrimiento, la admisión y la entrega.

La multidifusión no cabía en un único molde

En una sesión multicast, algunos receptores podían pedir niveles de QoS diferentes y otros ninguno. El marco compañero distinguía modelos completamente heterogéneos, de heterogeneidad limitada, homogéneos y homogéneos modificados. La RFC 2379 no proclamó uno como respuesta universal. Exigió al menos heterogeneidad limitada u homogeneidad modificada y prefirió que ambos estuvieran disponibles con un modo de selección.

Esa moderación también es historia de Internet. La buena práctica no borró la diversidad real para simplificar el diagrama. Estableció un mínimo aplicable y mantuvo visible el desacuerdo entre receptores.

Cuatro comprobantes

Una lectura segura conserva por separado la ruta de mejor esfuerzo que transportó el control; el estado RSVP y sus refrescos; el resultado de admisión y el VC ATM configurado; y, por último, los contadores y observaciones de aplicación que muestran el servicio recibido.

Un PATH enviado no demuestra que regresara RESV. RESV no demuestra admisión. Un VC activo no demuestra clasificación correcta. Una etiqueta QoS no demuestra latencia, pérdida ni entrega. La arquitectura conectaba esos planos sin declararlos idénticos.