# ¿Cómo encuentra un Agente USP a su Controlador? DHCP, DNS-SD y mDNS Equipo de ingeniería de Dodderware · Publicado 2026-10-28 · https://blog.dodderware.com/es/descubrimiento-usp-dhcp-mdns/ [Read in English](https://blog.dodderware.com/usp-discovery-dhcp-mdns/) > **Respuesta corta:** Un Agente USP necesita el Endpoint ID, las credenciales y el rol de su Controlador, y cómo llegar a él (MTP, dirección, puerto y ruta). TR-369 permite que vengan del firmware, de un Controlador de confianza, de un mecanismo de arranque o de la red. Por DHCP, la opción 125 (17 en DHCPv6) puede entregar su URL o FQDN y su Endpoint ID, y DNS-SD resuelve el resto. 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. **Llegan los datos del Controlador** (Arranque): Del firmware, de un Controlador de confianza, de una interfaz de usuario o de las opciones DHCP 125 y 17. 2. **DNS o mDNS** (Resolución): Registros A y AAAA del nombre, más PTR, SRV y TXT si no se conoce el MTP o la ruta. 3. **Por el MTP** (Conexión): Por ejemplo, una sesión WebSocket, que normalmente abre el propio Agente. 4. **Autenticar y asignar un rol** (Confianza): Certificados preconfigurados, confianza en el primer uso o aprobación de un usuario. *De la dirección de un Controlador a una relación USP que funciona. Diagrama de Dodderware, basado en TR-369 §3.1, §3.3, §3.6, §4.3.2 y §8.* ## ¿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): | Subopción | Opción 125 de DHCPv4 | Opción 17 de DHCPv6 | Dónde queda en el modelo de datos | | -------------------------------------------- | -------------------- | ------------------- | ------------------------------------------------------------------- | | URL o FQDN del Controlador | 25 | 25 | Depende del MTP | | Código de aprovisionamiento | 26 | 26 | `Device.LocalAgent.Controller.{i}.ProvisioningCode` | | Espera mínima entre reintentos USP | 27 | 27 | `Device.LocalAgent.Controller.{i}.USPNotifRetryMinimumWaitInterval` | | Multiplicador del intervalo de reintento USP | 28 | 28 | `Device.LocalAgent.Controller.{i}.USPNotifRetryIntervalMultiplier` | | Endpoint ID del Controlador | 29 | 29 | `Device.LocalAgent.Controller.{i}.EndpointID` | 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 `..`, 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): | MTP | Servicio del Agente | Servicio del Controlador | | --------------- | --------------------- | ------------------------ | | WebSocket | `_usp-agt-ws._tcp` | `_usp-ctr-ws._tcp` | | MQTT | `_usp-agt-mqtt._tcp` | `_usp-ctr-mqtt._tcp` | | STOMP | `_usp-agt-stomp._tcp` | `_usp-ctr-stomp._tcp` | | CoAP (obsoleto) | `_usp-agt-coap._udp` | `_usp-ctr-coap._udp` | 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). > **¿Sabías que…?** > > La lista de IANA todavía incluye `_usp-agt-coap._udp` y `_usp-ctr-coap._udp`, aunque el MTP CoAP quedó obsoleto en USP > 1.3 (§3.7.1, §4.2). UNIX Domain Socket, el MTP que llegó en esa misma versión, no tiene ningún nombre de servicio: > funciona entre procesos dentro de un mismo equipo, así que no hace falta anunciarlo por mDNS (§4.6.1, Issue History). ## ¿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): | Campo | Solicitud, DHCPv4 125 | Solicitud, DHCPv6 17 | Respuesta, DHCPv4 125 | Respuesta, DHCPv6 17 | | --------------------- | --------------------- | -------------------- | --------------------- | -------------------- | | DeviceManufacturerOUI | 1 | 11 | 4 | 14 | | DeviceSerialNumber | 2 | 12 | 5 | 15 | | DeviceProductClass | 3 | 13 | 6 | 16 | 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](https://blog.dodderware.com/es/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](https://blog.dodderware.com/es/agente-vs-controlador-usp/), los transportes en [transportes USP comparados](https://blog.dodderware.com/es/mtp-usp-websocket-mqtt-stomp/) y el protocolo completo en [qué es TR-369](https://blog.dodderware.com/es/que-es-tr-369/). > **Dónde encaja DWS Support** > > Una vez que el Agente encontró a su Controlador, el trabajo pasa a ser la gestión diaria del equipo. DWS Support > gestiona equipos TR-069 y TR-369 desde una sola consola, eligiendo el protocolo por equipo, y su controlador USP nativo > se conecta a los Agentes por WebSocket con USP Records. > > [Conoce DWS Support](https://dodderware.com/es/productos/dws-support/) ## ¿Sabías que…? - Para pedir los datos del Controlador por DHCP, el Agente envía el número de empresa del Broadband Forum, 3561, y el texto “usp” en la opción 124 de DHCPv4 o en la 16 de DHCPv6. (TR-369 §3.3) - Los mismos códigos de subopción, del 25 al 29, llevan los datos del Controlador tanto en la opción 125 de DHCPv4 como en la 17 de DHCPv6. (TR-369 §3.3.1) - Desde USP 1.2, el descubrimiento por DHCP le entrega al Agente el Endpoint ID del Controlador. (TR-369 Issue History) - En mDNS se espera que los Agentes se anuncien. Los Controladores no, pero descubren a los Agentes y responden a sus consultas. (TR-369 §3.5) - Un Agente que todavía no tiene Controlador puede confiar en el primero que descubra. Si acepta el certificado autofirmado de un Controlador, ese Controlador empieza con un rol “untrusted”. (TR-369 §3.1, §8.5) ## Preguntas frecuentes ### ¿Qué opciones DHCP usa USP para descubrir al Controlador? El Agente pregunta con 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, y el texto “usp”. La respuesta llega en la opción 125 de DHCPv4 o la 17 de DHCPv6, con las subopciones 25 a 29 para la URL o el FQDN del Controlador, un código de aprovisionamiento, dos ajustes de reintento y el Endpoint ID del Controlador. ### ¿Cuál es el nombre de servicio DNS-SD de un Controlador USP? Depende del MTP. Un Controlador al que se llega por WebSocket usa _usp-ctr-ws._tcp y un Agente usa _usp-agt-ws._tcp. MQTT y STOMP tienen sus propios nombres, como _usp-ctr-mqtt._tcp y _usp-ctr-stomp._tcp. El nombre de instancia que va delante del servicio es el Endpoint ID. ### ¿Un Agente USP tiene que usar DHCP para encontrar a su Controlador? No. TR-369 menciona DHCP, DNS y mDNS como ejemplos, junto con un Controlador preconfigurado en el firmware, uno configurado por un Controlador ya conocido y de confianza, y un mecanismo de arranque aparte, como una interfaz de usuario. La propia especificación aclara que la lista no es exhaustiva. ### ¿Es seguro descubrir el Controlador USP por DHCP? DHCP no tiene un mecanismo de seguridad propio. La especificación recomienda a los ISP usarlo para configurar Controladores solo cuando 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. ### ¿Cómo encuentra un Controlador a sus Agentes? El Controlador conoce el Endpoint ID, los datos de MTP y las credenciales de un Agente cuando este se conecta por primera vez, y un Controlador en la LAN también puede obtener los datos de MTP de un Agente por mDNS. Cada Controlador lleva su propio registro de Agentes conocidos. ### ¿Qué es un OnBoardRequest en USP? Una notificación que envía el Agente para empezar el on-boarding con un Controlador, por ejemplo cuando se conecta por primera vez y lo descubre por DHCP. Se envía pidiendo respuesta y se reintenta hasta que el Controlador la confirma con un Notify Response. ## Fuentes - Broadband Forum, TR-369 – The User Services Platform, Issue 1 Amendment 5 (USP 1.5), enero de 2026. - Dodderware, documentación de producto e ingeniería de DWS Support. - §3: Descubrimiento y anuncio - §3.1, §3.2: Información del Controlador en el Agente e información del Agente en el Controlador - §3.3, §3.3.1: Uso de DHCP para obtener la información del Controlador, subopciones DHCP - §3.4: Uso de DHCP para intercambiar GatewayInfo con equipos CWMP - §3.5, §3.6: Uso de mDNS y de DNS - §3.7: Registros DNS-SD, nombres de servicio USP registrados ante IANA y ejemplos - §3.8, §7.6.3.4: SendOnBoardRequest() y la notificación OnBoardRequest - §4.2, §4.3.1, §4.3.2, §4.4.4, §4.5.6, §4.6.1: Requisitos de descubrimiento de cada MTP, el binding obsoleto de CoAP - §8.5, §8.9.3: Certificados autofirmados y asignación de roles a los Controladores - Apéndice IV.2, Issue History: Discovery Proxy, cambios en el descubrimiento en USP 1.2 y 1.3 [Leer la especificación TR-369](https://usp.technology/specification/index.htm) TR-369 © The Broadband Forum. Todos los derechos reservados. Citado brevemente y parafraseado con fines explicativos; los diagramas son de Dodderware. --- **Gestiona equipos TR-069 y TR-369 desde una sola consola.** DWS Support reúne cada ONT y router del hogar en una consola web, hable el protocolo que hable: TR-069 por GenieACS o un ACS integrado, TR-369 por un controlador USP nativo. Se instala en tu propia infraestructura. [Solicita una demo](https://dodderware.com/es/productos/dws-support/#get-started)