Resumen

  • El FAS podía permitir, rechazar, redirigir o imponer condiciones, mientras que el conmutador seguía originando y ejecutando la conectividad.
  • FAR, FAA, FAU, FUN, FUA, FCR y FCA eran recibos de etapas diferentes, no una única prueba del servicio.
  • AMBIGUOUS, NO_SUCH_FLOW y una sección de seguridad vacía muestran por qué decisión, acción del dispositivo, estado y cobro no deben fundirse.

RFC 2124, publicado en marzo de 1997, abordó un problema práctico de las redes ATM. La representación de políticas de conexión aún no estaba normalizada, pero una organización quería aplicar reglas comunes a varios switches. LFAP permitía que la Connection Control Entity (CCE) del conmutador consultara a un Flow Admission Service (FAS) externo.

La ficha del RFC Editor y el registro del IETF Datatracker fijan el alcance: era un documento Informational, no un estándar de Internet. Su importancia histórica está en la frontera operacional que dejó escrita.

El veredicto llegaba antes que el estado

El switch iniciaba todos los intercambios. Antes de establecer un flujo, la CCE enviaba un Flow Admission Request (FAR) con identificador, direcciones, servicio, hora local y datos opcionales. El FAS respondía con un Flow Admission Acknowledge (FAA).

El FAA podía permitir o rechazar, incluir políticas opcionales u obligatorias y ordenar una redirección. Era una decisión sobre la descripción recibida, no una prueba de que el circuito existiera. Si la CCE no entendía una política opcional, podía ignorarla. Si no entendía una política obligatoria, debía abortar el flujo y comunicar el error mediante un Flow Admission Update.

Así, un SUCCESS del FAS no borraba el límite físico y lógico del switch. El FAS definía la condición; el dispositivo debía demostrar después qué había podido ejecutar.

Los contadores no completaban la historia

Una vez activa la conexión, la CCE emitía Flow Update Notifications (FUN). Podían transportar hora, estado, bytes y paquetes, celdas o tramas enviados y recibidos. Un FUN podía ser periódico, responder a un cambio o ser solicitado.

Los contadores tenían dos semánticas. Un valor acumulado empezaba con el establecimiento del flujo; un delta cubría el periodo desde el FUN anterior. Perder ese dato podía convertir dos números correctos en una suma falsa. Incluso un total correcto no probaba entrega a la aplicación, legitimidad del usuario ni derecho de cobro.

El Flow Update Acknowledge (FUA) marcaba una transferencia concreta. Con SUCCESS, la información del FUN había sido aceptada y pasaba a ser responsabilidad del FAS. La frase habla de custodia informativa. No garantiza persistencia, integridad histórica, consenso entre instancias ni resultado para el cliente.

El FAS también podía enviar un Flow Change Request (FCR) para cambiar política o detener el flujo. El switch contestaba con un Flow Change Acknowledge (FCA). Si faltaba capacidad, aparecía POLICY_REJECT; si faltaba el estado, NO_SUCH_FLOW. La autorización inicial no convertía el control posterior en un hecho automático.

La ambigüedad estaba en el contenido, no solo en el número

RFC 2124 permitía repetir una respuesta cuando un Flow ID duplicado llegaba en un FAR idéntico al anterior, salvo quizá el Message ID. Si cualquier otro contenido cambiaba, el FAS devolvía AMBIGUOUS y exigía otro identificador. La repetición segura se definía por el mensaje completo.

NO_SUCH_FLOW era una confesión explícita de divergencia. El FAS podía recibir datos de una conexión que nunca admitió o cuya admisión había perdido; el conmutador podía recibir un cambio para un flujo que ya no conocía. La recuperación exigía volver a admitir, informar o detener, no escoger por fe una de las dos bases de datos.

Para el failover, un prefijo del FAS combinado con un identificador de la CCE pretendía crear una identidad global. Sin soporte del prefijo, una llamada podía parecer dos en el punto de acumulación después del cambio a un FAS alternativo. La unicidad nominal ayudaba, pero no certificaba que las réplicas compartieran el mismo estado.

Un punto de control sin modelo de seguridad

LFAP reducía la traducción de políticas en cada fabricante. A la vez, permitía que el FAS negara, redirigiera o detuviera conexiones. Pese a ese poder, la sección Security Considerations solo indica que el memo no discute cuestiones de seguridad.

Una sesión TCP no demostraba el origen autorizado del mandato. Un puerto registrado tampoco lo hacía. El actual registro de servicios y puertos de IANA incluye csi-lfap en el puerto 3145 y advierte por separado de uso no autorizado conocido del puerto.

La tesis no duplica la cobertura existente. RFC 2063 define la arquitectura de medición, y su artículo BTW estudia el hueco temporal de la lectura asíncrona. RFC 2123 documenta NeTraMet, y su artículo analiza la proyección mediante reglas. RFC 2124 separa la decisión central del estado ejecutado y del registro económico posterior.

La primacía del código en ejecución, la especificación inicial mínima y decisión futura localizada y las capas de realidad de Heng Lu ayudan a expresar la lección: una orden administrativa no sustituye a su ejecución verificable.

LFAP anticipó el control programable. Su herencia más útil es una disciplina de recibos: quién decidió, qué ejecutó el switch, cuándo coincidieron los estados y qué información quedó bajo custodia.

Fuentes