How does a USP Agent find its Controller? DHCP, DNS-SD and mDNS

A USP Agent on a freshly installed gateway or ONT has two questions before it can do anything useful: which Controller should it talk to, and how does it reach it? TR-369 calls the answer discovery, the process by which Endpoints learn each other’s USP properties and MTP connection details, and its mirror image advertisement, the way Endpoints make their presence known (§3).

What does an Agent need to know about its Controller?

To work with a Controller, an Agent needs that Controller’s Endpoint ID, its credentials and its authorized Role. To send anything, it also needs at least one MTP, an IP address, a port and, if the MTP requires one, a resource path. That can arrive as a complete URL, as an FQDN that resolves to all of those through DNS-SD records, or through mDNS discovery on the LAN (§3.1).

The specification lists example ways to configure it, which “include but are not limited to” (§3.1):

• Pre-configured in firmware.
• Configured by an already-known-and-trusted Controller.
• Configured through a separate bootstrap mechanism, such as a user interface or another management interface.
• DHCP, DNS or mDNS.

Whatever the source, an Agent that supports USP configuration of Controllers keeps them in the Device.LocalAgent.Controller Object of the Device:2 data model (R-DIS.0). The other direction is simpler: a Controller learns an Agent’s Endpoint ID, MTP details and credentials when the Agent first connects, although a Controller on the LAN can also pick up an Agent’s MTP information through mDNS (§3.2).

1. BootstrapController details arriveFrom firmware, a trusted Controller, a user interface, or DHCP options 125 and 17.
2. ResolveDNS or mDNSA and AAAA records for the name, plus PTR, SRV and TXT when the MTP or path is unknown.
3. ConnectOver the MTPFor example a WebSocket session, which the Agent normally opens itself.
4. TrustAuthenticate and assign a RolePre-configured certificates, trust on first use, or approval by a user.

How does DHCP give an Agent its Controller?

The DHCPv4 Vendor-Identifying Vendor-Specific Information Option (code 125) and the DHCPv6 Vendor-specific Information Option (code 17) can tell an Agent about a single Controller (§3.3). The Agent has to ask first. If it is configured to request Controller information, it must include the DHCPv4 V-I Vendor Class Option (124) or the DHCPv6 Vendor Class option (16) in its requests, with the Broadband Forum enterprise number, 3561 (0x0DE9), and the string “usp” in lower case (R-DIS.1). The answer is a set of encapsulated sub-options (§3.3.1):

The Role of a DHCP-discovered Controller is determined programmatically, through the rules of the authentication and authorization section (§3.3).

DHCP “does not itself incorporate a security mechanism”, so the specification advises ISPs to use it for Controller configuration only where the service provider can assure the security of the link between the DHCP server and the Agent, and to establish trust through pre-configured certificates or other means (§3.3).

Where do DNS and mDNS come in?

When sub-option 25 carries an FQDN rather than a URL, name resolution takes over. With DNS enabled, an Endpoint requests A and AAAA records as usual (R-DIS.6). If the Agent is resolving a Controller’s FQDN and does not know the MTP or the resource path, it must also request the DNS-SD records: PTR, SRV and TXT (R-DIS.7).

On the LAN, mDNS does the same job without a DNS server. An Endpoint that supports it implements both the client and the server side of RFC 6762 (R-DIS.3) and resolves any name in the “.local.” domain through mDNS (R-DIS.5). The roles are asymmetric. Agents are expected to advertise themselves so that Controllers can find them, while Controllers are expected to discover Agents and answer their mDNS requests rather than advertise. An Agent uses mDNS to resolve a Controller’s “.local.” name when it needs to send that Controller a Notification (§3.5).

Advertising comes with an obligation: an Endpoint that advertises an MTP over mDNS must listen on that MTP for other Endpoints that want to start USP communication (R-DIS.4). And since mDNS stops at LAN segment boundaries, the specification describes a Discovery Proxy that repeats what it discovers across segments (Appendix IV.2).

What do USP DNS-SD records look like?

DNS-SD (RFC 6763) names and structures ordinary DNS records so that services can be discovered: SRV and TXT records describe a service, and PTR records help locate them (§3.7). A Service Instance Name follows the pattern <Instance>.<Service>.<Domain>, and in USP the instance is the Endpoint ID of the Endpoint (R-DIS.8). The service part comes from the names the Broadband Forum registered with IANA (§3.7.1):

The TXT record adds details that are not searchable (§3.7):

• Agent records must include path and name, and name must match the FriendlyName Parameter if the Agent implements it (R-DIS.9, R-DIS.10).
• Controller records must include path (R-DIS.11).
• An encrypt attribute, which takes no value, means MTP encryption is required to connect (R-DIS.11a).

What path holds depends on the MTP: the resource path of the WebSocket URI (R-WS.3), the STOMP destination the Endpoint subscribed to (R-STOMP.31), or, for an MQTT Agent, its “reply to” Topic (R-MQTT.36). For STOMP and MQTT, the A and AAAA records point to the broker, not to the Endpoint (R-STOMP.32, R-MQTT.38).

Agents can also be grouped with subtype PTR records, such as _gateway._sub._usp-agt-ws._tcp (§3.7.1, §3.7.3).

How do CWMP and USP devices on the same LAN recognize each other?

TR-369 reuses a CWMP mechanism in which a gateway and an end device swap identity information through the same vendor-specific DHCP options, so that an ACS or a Controller can tell whether they share a LAN (§3.4). The Agent puts its own details in its DHCP requests (R-DIS.2a), and an Agent that receives them answers with its own in the DHCP response (R-DIS.2b):

The receiving Agent then fills Device.GatewayInfo with the ManufacturerOUI, ProductClass and SerialNumber, and sets ManagementProtocol to “CWMP” (R-DIS.2c). If an mDNS PTR record matches the IP address of the DHCP response, the Agent changes ManagementProtocol to “USP” and stores the Endpoint ID from that record (R-DIS.2d). More on how the two protocols coexist in TR-069 vs TR-369.

What happens once the Agent has found a Controller?

Finding a Controller is not the same as trusting it. An Agent can be pre-configured with trusted root or Controller certificates, but the specification also allows an Agent with no current Controller association to trust the first Controller it discovers, or to let a user approve a discovered Controller through a UI (§3.1). An Agent that accepts self-signed Controller certificates must give those Controllers an “untrusted” Role on first use (R-SEC.6), which then has to be raised by another Controller, a challenge or a method outside USP (§8.9.3).

Policy can also start the conversation. An Agent sends an OnBoardRequest notification to begin on-boarding with a Controller, for example when it first comes online and discovers one through DHCP (§3.8). It goes out with send_resp set to true and is retried until the Controller confirms it with a Notify Response (R-NOT.6, R-NOT.6a).

The two roles are explained in USP Agent vs Controller, the transports in USP transports compared, and the whole protocol in what is TR-369.