Abhayakara / draft-ietf-homenet-simple-naming-arch

Simple Naming Architecture for Homenet
0 stars 0 forks source link

Description of a Service discovery lookup #7

Open mglt opened 7 years ago

mglt commented 7 years ago

I believe it would be useful to provide an example to illustrate how service discovery works in the homenet. This is illustrative but I think that is usefull.

This section illustrates the envisioned exchanges between the different elements in the home network in order to perform a service discovery lookup.

When the user has plugged its laptop to the home network, it has been provisioned with one DNS Proxy. The DNS Proxy can be advertised as the traditional DNS Resolution Service for example using the DHCPv6 option DNS Recursive Name Server option described in [4] or the

Neighbor Discovery Extension Recursive DNS Server Option described in [5]. The DNS Proxy is thus expected to transparently distinguish between a homenet naming resolution and a global DNS resolution.

The DNS Proxy is at least provisioned with the home.arpa domain. A DNS request that concerns the provisioned domain will trigger a homenet resolution while requests that concern non-provisionned domains will trigger a Global DNS resolution. The current homnet resolution is not yet implemented but the use of DNS Proxy that performs different resolution upon the requested domain name is widely used. Most CPE handles resolution for ".local" with multicast while non ".local" domain names resolution are performed on the Global Internet.

Discovery Proxy/Relay are expected to work as authoritative servers, but instead of reading the response from a file, the response is retrieved from the LAN through a multicast DNS exchange. As a result, it is expected that at least every HNR implements a Discovery Relay, and that at least one Discovery Proxy is instantiated on the whole home network. There is no constraint of having multiple Discovery Proxies that extends their domain using Discovery Relays. The zone covered by a Discovery Proxy is designated as Proxy Zone. The Proxy Zones can typically be: proxy-zone-1.home.arpa, proxy-zone- 2.home.arpa, proxy-zone-3.home.arpa.

As each link may have multiple Discovery Proxies, the total number of Discovery Proxies can exceed the number of links. In the simplest case, the home network has a single Proxy Zone: home.arpa, a single Discovery Proxy: The selection of the Discovery Proxy is performed using HNCP and the multiple Discovery Relay attached to the Discovery Proxy.

Finally, some devices may have registered to the Advertising Proxy. The Advertising Proxy is seen for resolution as an Authoritative Server answering to unicast.

As a result, devices can register there hostname under some Proxy Zone there are attached to. Each Proxy zone is coordinated by a Discovery Proxy. Similarly the hostanme can also be registered on the Advertising Proxy. Coordination of the Discovery Proxies and the Advertising Proxy is provided by the Discovery Broker. The Discovery Broker is unique to the home network. It is responsible for discovering the various sources where home network names or services can be registered, and thus avoid the complexity to be perfomed by each individual node.

A user is for example looking at the various printers available in the home network. By default the domain associated to the home network will be home.arpa.

The Host sends to the DNS Proxy the following request:

  _printer._tcp.home.arpa IN PTR ?

Upon receiving this request, the DNS Proxy interprets the home.arpa as being the well known home network suffix. The entity responsible for the resolution inside the home network is the Broker Discovery.

In order to perform the resolution with the home network, the Broker Discovery needs to query the various Proxy Zones as well as the Advertising Proxy.

The DNS Proxy forward the following query to the Discovery Broker

  _printer._tcp.home.arpa IN PTR ?

The Discovery Broker forwards the query to the various Discovery Proxies which either retrieve from its cache or sends a multicast DNS query to its Proxy Zone:

  _printer._tcp.local IN PTR ?

Suppose that a printer responds to the multicast query with the following response to the Discovery Proxy:

  _printer._tcp.local IN PTR mDNS Printer.local

The Discovery Proxy responds to the Discover Broker.

  _printer._tcp.home.arpa IN PTR mDNS Printer.home.arpa

The response is returned back the DNS Proxy, which finalize the Discovery Proxy resolution.

In addition to the Broker Discovery also requests the Advertising Proxy

  _printer._tcp.home.arpa IN PTR ?

The Advertising Proxy responds as a standard authoritative DNS server with the following response to the DNS Proxy

  _printer._tcp.home.arpa IN PTR registered-printer.home.arpa

The DNS Proxy aggregates the two responses and sends back to the original host the following response:

  _printer._tcp.home.arpa IN PTR registered-printer.home.arpa

  _printer._tcp.home.arpa IN PTR mDNS Printer.home.arpa

The remaining resolution follows the general rules where SRV, TXT, A RRSets are requested in order to finalize the discovery of the service.

Abhayakara commented 7 years ago

This feels like too much detail for the homenet architecture. I think you're on the right track, though. Perhaps the way this should be done is to just describe some use cases; service discovery would be one use case. We can talk briefly about the flow of traffic, but reference the document that explains how to do it for more detail.

Of course, the argument can be made that this document is where that should be specified. That's going to make it a real doorstop, though—a lot of reading.

Abhayakara commented 7 years ago

Oh, next steps:

mglt commented 7 years ago

The text was in the appendix. This is clearly illustrative. I understand the use case description as a few lines introducing such a section.

Abhayakara commented 7 years ago

I think Stuart agreed with you that this was worth doing. :)