Agente vs Controlador USP: ¿en qué se diferencian y qué es un Endpoint ID?

Toda conversación USP tiene dos extremos, y TR-369 le asigna a cada uno un trabajo fijo. Ya sea que operes un NOC o construyas la plataforma que hay detrás, te vas a encontrar con los dos roles, Agente y Controlador, y con el identificador que nombra a cada uno, el Endpoint ID, en los USP Records, en los handshakes de WebSocket y en los certificados. Esta guía explica ambos usando solo lo que dice la especificación.

¿En qué se diferencian un Agente y un Controlador USP?

En USP, todo lo que envía o recibe un Message es un Endpoint, un punto de terminación de un Message (§1.4), y cada Endpoint cumple uno de dos roles (§2.1):

• Un Agente (Agent) es un Endpoint que expone Service Elements a uno o más Controladores (§1.4). Los Service Elements son los Objects, Sub-Objects, Commands, Events y Parameters que forman una funcionalidad (§2.3).
• Un Controlador (Controller) es un Endpoint que manipula Service Elements a través de uno o más Agentes (§1.4). Normalmente funciona como interfaz de una aplicación de usuario o de un motor de políticas (§2.1.2).

La dirección es fija: los Controladores solo envían mensajes a Agentes, y los Agentes envían mensajes a Controladores (§2.1).

Si vienes de TR-069, la propia especificación hace el paralelo: describe al Auto-Configuration Server (ACS) como el equivalente en CWMP de un Controlador (§7.6.1). La diferencia está en ese “uno o más”. Un Controlador y un Agente tienen una USP Relationship cuando pueden intercambiar mensajes, lo que normalmente significa que el Controlador ya está en la tabla de Controladores del Agente (§1.4), y esa tabla admite más de un Controlador.

¿Qué guarda cada lado y qué necesita saber del otro?

Los dos roles guardan cosas distintas y necesitan datos distintos del otro:

Los dos modelos de datos responden preguntas distintas en una llamada de soporte. El Instantiated Data Model contiene los Service Elements que el Agente representa en este momento, con su estado (§2.4.1). El Supported Data Model contiene lo que el Agente entiende (§2.4.2), y GetSupportedDM le permite al Controlador saber qué entiende un Agente, en lugar de cuál es su estado actual (§7.5.3).

El Controlador obtiene el Endpoint ID, los datos de MTP y las credenciales del Agente cuando este se conecta por primera vez (§3.2). Cómo encuentra el Agente a su Controlador se explica en cómo un Agente USP encuentra a su Controlador.

¿Cómo se arma un Endpoint ID de USP?

Cada Endpoint se identifica con un Endpoint Identifier, un identificador de la capa USP que es único, a nivel local o global según el scheme con el que se asigna (§2.2). Tiene tres partes:

authority-scheme ":" [authority-id] ":" instance-id

• El authority-scheme indica qué tipo de autoridad asigna el ID y define el formato del authority-id (§2.2).
• El authority-id identifica a esa autoridad. Algunos schemes exigen que vaya vacío, y por eso IDs como os::00256D-0123456789 llevan dos signos de dos puntos seguidos (§2.2.1).
• El instance-id nombra al Endpoint. Solo puede usar letras, dígitos, -, ., _ y caracteres con codificación porcentual (R-ARC.5), y no puede pasar de 50 caracteres (R-ARC.6). Mejor si es corto, porque los usuarios finales podrían ver los Endpoint IDs (§2.2.2).

En un certificado, el ID se escribe como un URN en el espacio de nombres del Broadband Forum: urn:bbf:usp:id: seguido de las mismas tres partes. En cualquier otro lugar, por ejemplo en los campos to_id y from_id de un USP Record, se omite el espacio de nombres (§2.2).

¿Qué authority schemes puede usar un Endpoint ID?

La especificación define doce schemes (§2.2.1), y el requisito R-ARC.2a hace obligatorias sus reglas:

El scheme también define quién responde por la unicidad: el dueño del OUI, del CID, del número de empresa o del nombre de dominio (incluido el OUI dentro de os y ops), el usuario o la máquina que asigna el ID en user, y el propio Endpoint en self (§2.2.1). Antes de asignar IDs a todo un parque de equipos, revisa tres requisitos más:

• R-ARC.3: el OUI del Broadband Forum, 00256D, y su Private Enterprise Number, 3561, están reservados para la documentación y los prototipos del BBF, y nadie más puede usarlos. Por eso aparecen en los ejemplos de arriba.
• R-ARC.4: los schemes proto y doc no se deben usar en entornos de producción.
• R-ARC.4a: un Endpoint que usa fqdn debe presentar certificados TLS con un subjectAltName que permita ese nombre de dominio.

¿Dónde aparece el Endpoint ID durante una sesión?

En una conexión WebSocket segura, el Endpoint ID aparece tres veces, en este orden:

1. Handshake TLSEn el certificadoEl subjectAltName lleva el Endpoint ID en su forma URN.
   • urn:bbf:usp:id:…
2. Handshake WebSocketEn la solicitud de aperturaEl cliente ofrece el subprotocolo v1.usp y pone su propio Endpoint ID en el URI de la solicitud.
   • eid=…
3. USP RecordEn cada RecordDos campos obligatorios nombran al Endpoint de destino y al de origen.
   • to_id
   • from_id

1. En el certificado. Cuando un certificado X.509 autentica a un Endpoint, su subjectAltName debe llevar la forma URN del Endpoint ID o, en el caso de fqdn, el nombre de dominio. Cuando los certificados autentican en la capa del MTP, los Endpoints no deben procesar Records cuyo from_id no coincida con el ID del certificado (R-SEC.0a, §8.1).
2. En el handshake de WebSocket. No se envía ningún USP Record hasta que termina TLS, así que el servidor no puede saber quién es el cliente sin mirar dentro del certificado (§4.3.2.1). El cliente envía el encabezado Sec-WebSocket-Protocol con el valor v1.usp (R-WS.9, R-WS.10) y agrega su Endpoint ID al query del URI de la solicitud como eid (R-WS.10b). Si el ID lleva un signo de porcentaje, ese signo también se codifica, así que doc::agent%21 viaja como doc::agent%2521 (R-WS.10c).
3. En cada Record. Cada USP Record lleva el Endpoint ID de destino en to_id y el de origen en from_id, y ambos campos son obligatorios (§4.1.3.1).

Como el otro lado verifica la identidad contra este valor, trata el Endpoint ID como permanente: uno que cambia después de haberse usado también puede causar un comportamiento impredecible (§2.2.1). Los certificados, la confianza y los roles de los Controladores se explican en seguridad en TR-369.

¿Un Agente y un Controlador pueden compartir Endpoint ID?

Sí, con límites. Un Agente y un Controlador del mismo USP Domain pueden usar el mismo Endpoint ID, y todo Endpoint debe tolerarlo (R-ARC.0, R-ARC.1). Pero los Endpoints que comparten ID no deben comunicarse entre sí por USP (R-ARC.2), y salvo que la autoridad que asignó el ID indique que están relacionados, no se puede suponer ninguna relación entre ellos (§2.2.1). En la modularización del software, compartirlo incluso se recomienda: un USP Service que lleva dentro un Agente y un Controlador debería usar el mismo Endpoint ID para ambos, o el USP Broker no podrá relacionarlos como un solo USP Service (Apéndice VI.2).

Lo que USP no te da es una red de seguridad contra duplicados dentro de un mismo rol. No define ningún proceso para identificar o resolver un Endpoint ID que no sea único entre todos los Agentes o entre todos los Controladores, y el resultado es un comportamiento impredecible (§2.2.1). La única regla incorporada es la de self: un Endpoint que se encuentra con otro que usa su mismo ID debe cambiar el suyo (§2.2.1).

Para el panorama completo, con mensajes, transportes y modelos de datos, empieza por qué es TR-369.