Resumen

  • RFC 3532 permite cambiar los recursos de un elemento de conmutación virtual activo sin reiniciarlo y exige conservar su estado existente. No exige que todo protocolo avise de antemano: el controlador puede enterarse cuando una petición posterior falla y consulta la disponibilidad.
  • Una recepción fiable separa la autoridad, la cuota antigua, el uso vivo, la decisión de liberar o denegar, la congelación, la vía de conocimiento, los servicios entre particiones y el resultado de la aplicación. «Reparto completado» no cierra esa cadena.

El reinicio tenía una virtud incómoda: nadie podía ignorar que había ocurrido una transición. En el reparto estático descrito por RFC 3532, los controladores afectados se desconectan, normalmente se libera el estado configurado, el elemento virtual baja y después debe reconstruirse. El reparto dinámico evita esa ruptura y mantiene el estado de la partición activa.

Al desaparecer la frontera visible aparece otra más difícil de observar. La sesión sigue abierta, pero el presupuesto cambió. Las entradas siguen instaladas, pero su soporte de colas, búferes, conexiones o ancho de banda puede haberse reducido. La continuidad del control no es identidad de capacidad, y ninguna de las dos prueba el resultado de la aplicación.

RFC 3532 se publicó en mayo de 2003 como Informational y declara que no especifica un estándar de Internet. Es un documento de requisitos, no un protocolo completo. Su escenario principal son los conmutadores GSMP. Para conmutadores no GSMP y equipos de reenvío por prefijo más largo, advierte que los requisitos pueden ser necesarios sin ser suficientes.

Una sola palabra de éxito oculta cuatro propietarios

El elemento de conmutación, SE, conmuta paquetes y ofrece recursos divisibles. Una partición o SE virtual reúne una parte de ellos. Un controlador opera la partición activa. El gestor de particiones, PM, decide cuántos SE virtuales existen y qué recursos recibe cada uno.

El PM solicita el reparto, el SE lo aplica, el controlador utiliza la partición y el PM puede negociar con él un cambio mientras está activa. Son superficies distintas. Una fila que diga «capacidad actualizada» no conserva quién pidió, quién ejecutó, quién usaba y quién llegó a saberlo.

Las entidades son lógicas y pueden estar juntas o distribuidas. La separación lógica no demuestra aislamiento físico ni un dominio de fallo distinto. La convivencia física tampoco fusiona sus permisos. Una recepción debe nombrar el rol y la identidad de ejecución que lo encarnaba en ese momento.

El ejemplo de la RFC imagina al propietario de un SE que divide la infraestructura y arrienda el control de elementos virtuales a terceros. No acredita ningún contrato real. El derecho del arrendatario, la autoridad del PM, la autorización del controlador y la cuota aplicada por el SE son afirmaciones diferentes.

La reducción correcta puede terminar en una denegación

El SE debe impedir que un controlador use más recursos que su asignación actual. Esa obligación hace efectiva la nueva frontera. No permite borrar recursos vivos para presentar una cifra menor como éxito.

Si el PM intenta liberar recursos de una partición activa y alguno está en uso, el SE debe denegar la solicitud. La denegación protege el trabajo existente y cumple el requisito. Distingue capacidad libre que puede moverse ahora de capacidad ocupada que exige coordinación.

Después, el PM debería congelar la partición, pedir al controlador que reduzca la utilización o hacer ambas cosas. Una partición congelada entrega lo que no usa, mantiene sus conexiones actuales y devuelve recursos a medida que se cierran. No está operando con normalidad, pero tampoco está apagada. Es un proceso de drenaje.

Si el controlador no libera suficiente capacidad, el PM conserva una salida: el apagado virtual, que vuelve inactiva la partición y desconecta controladores. Evita que los recursos queden retenidos para siempre, pero interrumpe. No puede contarse como reducción dinámica sin impacto solo porque al final la cuota objetivo aparece disponible.

La prueba debe incluir cuota anterior, uso observado, cuota solicitada, tipos de recurso, decisión del SE, congelación, negociación y destino de lo ocupado. Una instantánea con el nuevo número borra si el sistema esperó, drenó o destruyó actividad.

El error posterior es una vía de notificación, no ruido

Un protocolo de control puede ofrecer notificación proactiva: el SE comunica asíncronamente el cambio al controlador. Es la vía temporal más clara, pero RFC 3532 no la hace obligatoria para todos los protocolos porque exige alguna forma de notificación reactiva.

La variante reactiva explícita aparece cuando una petición futura falla con un error que identifica una reasignación de recursos. En la variante implícita, el controlador solo recibe un error genérico, desconocido o relacionado con recursos. Debe consultar los recursos disponibles para decidir si la reasignación causó la escasez.

El PM también puede contactar directamente al controlador. Ese canal necesita autenticación, entrega, acuse y prueba de cambio interno. Un mensaje enviado no demuestra que el planificador adoptó el límite. Un error devuelto no demuestra que el software lo interpretó. Una consulta demuestra lo que el SE informó en ese instante, no la conducta futura.

Por eso conviene conservar cuatro tiempos: asignación, conocimiento, adaptación y observación del servicio. La separación puede durar el tránsito de un mensaje, hasta la siguiente petición o hasta que una investigación relacione un error genérico con la cuota. Durante ese intervalo, el SE puede aplicar correctamente el límite y el controlador actuar coherentemente con su mapa viejo.

La automatización debe registrar la vía exacta: aviso proactivo, error reactivo explícito, error implícito más consulta o contacto directo. Después debe enlazar la versión del modelo, el acuse y el nuevo intento del controlador. Sin esa evidencia, «informado» es una inferencia.

El inventario verifica el libro del SE, no la conducta del controlador

El PM debe poder consultar recursos, particiones configuradas y asignación por partición. Para automatizar el intercambio con controladores, debe obtener del SE las direcciones de los controladores conectados al elemento virtual. También puede conocer protocolo y versión.

Ese inventario prueba lo que el SE declara en el momento de la consulta. Permite encontrar al interlocutor. No prueba que recibió el aviso, aceptó el presupuesto, dejó de pedir capacidad inexistente o preservó el servicio.

Si el deseo del PM y el informe del SE difieren, hay un problema de aplicación o conciliación. Si coinciden pero el controlador sigue usando la cuota antigua, hay un problema de conocimiento o adaptación. Si los tres coinciden y el usuario falla, la investigación continúa en el plano de datos y la aplicación. «Desincronización» no debería mezclar los tres casos.

La consulta tiene fecha y alcance. Debe fijar identidad del SE, partición, esquema de recursos, valores, hora y resumen de respuesta. El inventario posterior no debe reescribir el histórico, porque el valor presente no reconstruye lo que cada actor sabía al emitir la petición fallida.

Los servicios entre particiones dibujan una segunda frontera

Un SE puede proporcionar un servicio de un SE virtual a otro, como un enlace virtual. Debe exponer qué servicios existen y el PM debe poder configurarlos. Si el cambio añade o quita un puerto virtual, el SE debe avisar a los controladores conectados cuando su protocolo lo admita.

Así, una modificación local en el libro de cuotas puede alterar una dependencia usada por otra partición. La segunda partición puede conservar su asignación directa y perder capacidad o un puerto en el servicio compartido. No ser objetivo de la orden no equivale a no estar afectada por el resultado.

La verificación necesita dos recorridos. Primero, comprobar que particiones representativas fuera del impacto conservan asignación e identidad de proceso. Segundo, enumerar los servicios que cruzan la frontera modificada y probar sus puertos, capacidad y comportamiento. El primero evita una interrupción de toda la plataforma; el segundo evita que un plan mínimo ignore una dependencia real.

Compartir chasis, PM, protocolo o configuración no basta para ampliar el impacto. Lo determinan las asignaciones cambiadas, las entradas ejecutables, las dependencias directas y las migraciones necesarias.

La autoridad para repartir no certifica que la cuota sea segura

Solo un PM autorizado puede repartir dinámicamente un SE. Debe existir un proceso seguro por el que una entidad autorizada seleccione al PM controlador, de forma explícita o mediante descubrimiento autorizado. Solo ese PM o su agente puede pedir reducciones o informar aumentos a los controladores.

En sentido inverso, el PM debe autenticar que una solicitud de cambio procede de un controlador autorizado para el SE virtual indicado. La regla impide que un ocupante intente modificar la envolvente de otro.

La autenticación identifica a quien presenta una credencial bajo una política de confianza. La autorización decide si puede ejecutar esa operación sobre esa partición. Ninguna prueba el derecho comercial, la suficiencia de la cuota, la aplicación efectiva o el resultado.

La selección del PM requiere histórico. Si la autoridad cambia, una credencial válida hoy no legitima retroactivamente una orden antigua. Cada petición debe ligarse a la selección, credencial, versión de política, partición y resumen vigentes al decidir.

La evolución hacia ForCES no rellena una prueba de producción

RFC 3654 y RFC 3746 describieron después requisitos y un marco para separar elementos de reenvío y control. RFC 5810 y RFC 5812 especificaron el protocolo y modelo ForCES; RFC 7121 trató su alta disponibilidad. Aportan contexto histórico.

No convierten RFC 3532 en estándar, no generan un recibo de ejecución ausente ni prueban que un despliegue usara ForCES. RFC 3654 y RFC 3746 son Informational; RFC 5810, RFC 5812 y RFC 7121 son Proposed Standard. Cada texto conserva fecha, estado y alcance.

Los metadatos, el historial y las erratas identifican el documento. No observan una partición activa. El linaje de una arquitectura no es adopción.

Conservar la transición, no solo el valor vigente

La cadena empieza por SE, PM, controlador, partición, ubicación física, selección del PM, credenciales, versión de política y resumen de la solicitud. Añade tipos deterministas, cuota antigua, uso medido y objetivo.

Después registra la decisión del SE: liberación inmediata de lo libre, denegación por uso, congelación, negociación o apagado. Verifica qué estado se mantuvo y cómo se impuso el nuevo límite.

Luego identifica el conocimiento: aviso proactivo, error explícito, error implícito con consulta o contacto directo. Enlaza la versión actualizada y el reintento. Una consulta posterior del SE completa el expediente, pero no reemplaza el acuse del controlador.

Por último prueba servicios entre particiones, particiones no afectadas, capacidad de datos y resultado de aplicación. El PM acredita la orden, el SE la cuota, el controlador su modelo, el servicio el comportamiento y la aplicación el resultado del usuario.

Una frase ejecutiva honesta diría: «El gestor autorizado movió estos recursos libres a esta hora; el SE conservó estos estados; el controlador se enteró por esta vía y adoptó este modelo; después se observaron estas dependencias y resultados». Lo desconocido no debe rellenarse con «éxito».

Evidence boundary

Este Article no identifica implementación, proveedor, operador, SE, PM, controlador, ocupante, contrato, pool, partición, despliegue, incidente, caída, evento de seguridad ni resultado de cliente. No informa adopción actual, capacidad, utilización, pérdida, latencia ni resultado de servicio.

RFC 3532 se trata como documento Informational de requisitos de mayo de 2003, no como estándar ni protocolo completo. Su supuesto determinista no se extiende a agrupaciones estadísticas o sobreasignación. Los textos posteriores de GSMP, Megaco y ForCES mantienen su estado y no prueban conformidad de un sistema real.

Las notas divulgadas de Heng Lu aportan una lente editorial: limitar la autoridad a la operación que controla y cerrar el resultado con evidencia de código en ejecución. No establecen intención del IETF, conducta de una implementación ni hecho de despliegue.

La conclusión limitada es que una partición activa puede reasignarse sin reinicio mientras el controlador permanece ignorante hasta un aviso, error, consulta o contacto posterior. Estado conservado e inventario actualizado son necesarios, pero no son el resultado del servicio.

Sources