¿Cómo encuentra un Agente USP a su Controlador? DHCP, DNS-SD y mDNS

Un Agente USP en un gateway u ONT recién instalado tiene dos preguntas antes de hacer nada útil: ¿con qué Controlador debe hablar y cómo llega a él? TR-369 llama a la respuesta descubrimiento (discovery), el proceso con el que un Endpoint conoce las propiedades USP y los datos de conexión MTP de otro, y a su contraparte anuncio (advertisement), la forma en que los Endpoints dan a conocer su presencia (§3).

¿Qué necesita saber un Agente sobre su Controlador?

Para trabajar con un Controlador, el Agente necesita su Endpoint ID, sus credenciales y su rol autorizado. Para enviarle algo, además necesita al menos un MTP, una dirección IP, un puerto y, si el MTP lo requiere, una ruta de recurso. Eso puede llegar como una URL completa, como un FQDN que se resuelve en todos esos datos con registros DNS-SD, o por descubrimiento mDNS en la LAN (§3.1).

La especificación da ejemplos de cómo configurarlo, sin limitarse a ellos (§3.1):

• Preconfigurado en el firmware.
• Configurado por un Controlador ya conocido y de confianza.
• Configurado con un mecanismo de arranque aparte, como una interfaz de usuario u otra interfaz de gestión.
• DHCP, DNS o mDNS.

Venga de donde venga, un Agente que permite configurar Controladores por USP los guarda en el Object Device.LocalAgent.Controller del modelo de datos Device:2 (R-DIS.0). En sentido contrario es más simple: el Controlador conoce el Endpoint ID, los datos de MTP y las credenciales del Agente cuando este se conecta por primera vez, aunque un Controlador en la LAN también puede obtener los datos de MTP de un Agente por mDNS (§3.2).

1. ArranqueLlegan los datos del ControladorDel firmware, de un Controlador de confianza, de una interfaz de usuario o de las opciones DHCP 125 y 17.
2. ResoluciónDNS o mDNSRegistros A y AAAA del nombre, más PTR, SRV y TXT si no se conoce el MTP o la ruta.
3. ConexiónPor el MTPPor ejemplo, una sesión WebSocket, que normalmente abre el propio Agente.
4. ConfianzaAutenticar y asignar un rolCertificados preconfigurados, confianza en el primer uso o aprobación de un usuario.

¿Cómo le entrega DHCP su Controlador a un Agente?

La opción DHCPv4 Vendor-Identifying Vendor-Specific Information (código 125) y la opción DHCPv6 Vendor-specific Information (código 17) pueden informarle a un Agente sobre un único Controlador (§3.3). Primero el Agente tiene que pedirlo. Si está configurado para solicitar datos del Controlador, debe incluir en sus solicitudes la DHCPv4 V-I Vendor Class Option (124) o la opción DHCPv6 Vendor Class (16), con el número de empresa del Broadband Forum, 3561 (0x0DE9), y el texto “usp” en minúsculas (R-DIS.1). La respuesta es un conjunto de subopciones encapsuladas (§3.3.1):

El rol de un Controlador descubierto por DHCP se determina de forma programática, con las reglas de la sección de autenticación y autorización (§3.3).

DHCP no incorpora por sí mismo ningún mecanismo de seguridad, así que la especificación recomienda a los ISP usarlo para configurar Controladores solo donde el proveedor del servicio pueda garantizar la seguridad del enlace entre el servidor DHCP y el Agente, y establecer la confianza con certificados preconfigurados u otros medios (§3.3).

¿Dónde entran DNS y mDNS?

Si la subopción 25 trae un FQDN en vez de una URL, hay que resolver el nombre. Con DNS habilitado, el Endpoint pide registros A y AAAA como siempre (R-DIS.6). Si el Agente está resolviendo el FQDN de un Controlador y no conoce el MTP ni la ruta de recurso, también debe pedir los registros DNS-SD: PTR, SRV y TXT (R-DIS.7).

En la LAN, mDNS hace el mismo trabajo sin servidor DNS. Un Endpoint que lo soporta implementa tanto el lado cliente como el lado servidor de RFC 6762 (R-DIS.3) y resuelve por mDNS cualquier nombre del dominio “.local.” (R-DIS.5). Los roles no son simétricos. Se espera que los Agentes se anuncien para que los Controladores los encuentren, y que los Controladores, en vez de anunciarse, descubran Agentes y respondan a sus consultas mDNS. Un Agente usa mDNS para resolver el nombre “.local.” de un Controlador cuando necesita enviarle una Notification (§3.5).

Anunciarse trae una obligación: un Endpoint que anuncia un MTP por mDNS debe escuchar en ese MTP a otros Endpoints que quieran iniciar una comunicación USP (R-DIS.4). Y como mDNS no cruza los límites de segmento de la LAN, la especificación describe un Discovery Proxy que repite lo que descubre entre segmentos (Apéndice IV.2).

¿Cómo son los registros DNS-SD de USP?

DNS-SD (RFC 6763) nombra y estructura registros DNS comunes para que los servicios se puedan descubrir: los registros SRV y TXT describen un servicio, y los PTR ayudan a ubicarlos (§3.7). Un Service Instance Name sigue el patrón <Instance>.<Service>.<Domain>, y en USP la instancia es el Endpoint ID del Endpoint (R-DIS.8). La parte del servicio sale de los nombres que el Broadband Forum registró ante IANA (§3.7.1):

El registro TXT agrega datos que no sirven como criterio de búsqueda (§3.7):

• Los registros de un Agente deben incluir path y name, y name debe coincidir con el Parameter FriendlyName si el Agente lo implementa (R-DIS.9, R-DIS.10).
• Los registros de un Controlador deben incluir path (R-DIS.11).
• Un atributo encrypt, que no lleva valor, indica que hace falta cifrado del MTP para conectarse (R-DIS.11a).

Lo que contiene path depende del MTP: la ruta de recurso de la URI WebSocket (R-WS.3), el destino STOMP al que se suscribió el Endpoint (R-STOMP.31) o, en un Agente MQTT, su Topic de respuesta, el “reply to” (R-MQTT.36). En STOMP y MQTT, los registros A y AAAA apuntan al broker, no al Endpoint (R-STOMP.32, R-MQTT.38).

Los Agentes también se pueden agrupar con registros PTR de subtipo, como _gateway._sub._usp-agt-ws._tcp (§3.7.1, §3.7.3).

¿Cómo se reconocen los equipos CWMP y USP de una misma LAN?

TR-369 reutiliza un mecanismo de CWMP en el que un gateway y un equipo final intercambian datos de identidad por las mismas opciones DHCP específicas del fabricante, para que un ACS o un Controlador puedan saber si comparten LAN (§3.4). El Agente pone sus propios datos en sus solicitudes DHCP (R-DIS.2a), y un Agente que los recibe responde con los suyos en la respuesta DHCP (R-DIS.2b):

El Agente que recibe la respuesta completa Device.GatewayInfo con ManufacturerOUI, ProductClass y SerialNumber, y pone ManagementProtocol en “CWMP” (R-DIS.2c). Si un registro PTR de mDNS coincide con la dirección IP de la respuesta DHCP, el Agente cambia ManagementProtocol a “USP” y guarda el Endpoint ID de ese registro (R-DIS.2d). Más sobre cómo conviven los dos protocolos en TR-069 vs TR-369.

¿Qué pasa cuando el Agente ya encontró un Controlador?

Encontrar un Controlador no es lo mismo que confiar en él. Un Agente puede venir preconfigurado con certificados raíz o de Controladores de confianza, pero la especificación también permite que un Agente sin Controlador asociado confíe en el primero que descubra, o que un usuario apruebe desde una interfaz al Controlador descubierto (§3.1). Un Agente que acepta certificados autofirmados de Controladores debe darles un rol “untrusted” en el primer uso (R-SEC.6), que después tiene que elevar otro Controlador, un desafío (challenge) o un método ajeno a USP (§8.9.3).

La política también puede iniciar la conversación. El Agente envía una notificación OnBoardRequest para empezar el on-boarding con un Controlador, por ejemplo cuando se conecta por primera vez y lo descubre por DHCP (§3.8). Sale con send_resp en true y se reintenta hasta que el Controlador la confirma con un Notify Response (R-NOT.6, R-NOT.6a).

Los dos roles se explican en Agente vs Controlador USP, los transportes en transportes USP comparados y el protocolo completo en qué es TR-369.