|The information below is for an older proposed charter
Extensions for Scalable DNS Service Discovery WG
No document state
||Charter Edit AD
||Send notices to
Currently, zero configuration networking protocols are generally used
to discover services within the scope of a single link. In particular,
the Bonjour protocols suite, comprising mDNS (RFC 6762) and DNS-SD
(RFC 6763), are widely used for discovery and resolution of services,
as well as names, on a single link.
The Bonjour protocol suite is commonly used in many scenarios,
including home networks, commercial and campus enterprise networks,
and may be of use in certain mesh networks. However, the zero
configuration multicast Bonjour protocols are constrained to
link-local scope, so can only be used to discover services on the same
In a typical current home network, which is commonly a single link,
users should experience the desired discovery behaviour, because all
devices share that link. However, in future multi-link home networks
(as envisaged by the homenet WG) and in routed campus or enterprise
networks, devices and thus users can only discover services on the
same links, which is a significant limitation. This has led to calls,
such as those by the Educause petition, to develop an appropriate
service discovery solution to span multiple links, or to perform
discovery across a wide area, not necessarily on directly connected
In addition, the "Smart Energy Profile 2 Application Protocol
Standard", published by ZigBee Alliance and Homeplug Alliance
specifies the Bonjour protocols as its method of zero configuration
discovery. However, its use of wireless mesh multi-link subnets and
its use across traditional routed networks will require extensions to
the Bonjour protocols to allow operation across multiple links.
The scenarios in which multi-link service discovery is required may
be zero configuration environments, environments where administrative
configuration is supported, or a mixture of the two.
As demand for service discovery across wider area routed networks
grows, some vendors are beginning to ship their own early solutions.
It is thus both timely and important that efforts to develop improved,
scalable, autonomous service discovery solutions for routed networks
are coordinated towards producing a single, standards-based solution.
The WG will consider the tradeoffs between reusing/extending existing
protocols, and developing entirely new ones. But it is highly
desirable that any new solution is backwardly compatible with existing
mDNS and DNS-SD deployments. Any solution developed by the dnssdext
WG will not conflict or interfere with the operation of other
zero-configuration service and naming protocols such as uPnP or LLMNR.
Integration with such protocols is out of scope for this WG.
The focus of the WG is to develop a solution for extended, scalable
DNS-SD. This work is likely to highlight problems and challenges with
naming protocols, as some level of coexistence will be required between
local zero configuration name services and those forming part of the
global DNS. It is important that these issues are captured and
documented for further analysis; solving those problems is however not
within the scope of this WG.
Working Group Description
To that end, the primary goals of the dnssdext WG are as follows:
1. To document a set of requirements for scalable, autonomous
DNS-based service discovery in routed, multi-link networks in the
following five scenarios:
(A) Personal Area networks, e.g., one laptop and one printer.
This is the simplest example of a service discovery network,
and may or may not have external connectivity.
(B) Home networks, as envisaged by the homenet WG, consisting of
one or more exit routers, with one or more upstream providers
or networks, and an arbitrary internal topology with
heterogeneous media where routing is automatically configured.
The home network would typically be a single zero configuration
administrative domain with a relatively limited number of
(C) Wireless 'hotspot' networks, which may include wireless networks
made available in public places, or temporary or permanent
infrastructures targeted towards meeting or conference style
events, e.g., as provided for IETF meetings. In such
environments other devices may be more likely to be 'hostile'
to the user.
(D) Enterprise networks, consisting of larger routed networks,
with large numbers of devices, which may be deployments
spanning over multiple sites with multiple upstreams, and
one more more administrative domains (depending on internal
administrative delegation). The large majority of the
forwarding and security devices are configured. These may
be commercial or academic networks, with differing levels
of administrative control over certain devices on the network,
and BYOD devices commonplace in the amps scenario.
(E) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix
networks, which may or may not have external connectivity.
The topology may use technologies including 802.11 wireless,
HomePlug AV and GP, and ZigBee IP.
In the above scenarios, the aim is to facilitate service discovery
across the defined site. It is also desirable that a user or device,
when away from such a site, is still able to discover services
within that site, e.g. a user discovering services in their home
network while remote from it.
It is also desirable that multiple discovery scopes are supported,
from the point of view of announcements and discovery, be the
scope 'site', 'building' or 'room'. A user for example may only
be interested in devices in the same room.
2. To develop an improved, scalable solution for service discovery
that can operate in multi-link networks, where devices may be
in neighbouring or non-neighbouring links, applicable to
the scenarios above. The solution will consider tradeoffs between
reusing/extending existing protocols and developing entirely new
The solution should include documentation or definition of the
interfaces that can be implemented, separately to transport of
3. To document challenges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace.
It is important that the dnssdext WG takes input from stakeholders in
the scenarios it is considering. For example, the homenet WG is
currently evaluating its own requirements for naming and service
discovery; it is up to the homenet WG as to whether it wishes to
recommend adoption of the solution developed in the dnssdext WG, but
coordination between the WGs is desirable.
The WG will produce three documents: an Informational RFC on the
requirements for service discovery protocols operating on potentially
non-neighbouring multi-link networks as described above; a Standards
Track RFC documenting an extended, scalable service discovery solution
that is applicable to those scenarios; and an Informational RFC
describing the problems arising when developing the extended SD solution
and how it affects the integration of local zero configuration and global
DNS name services.