DNS-SD Extensions

The information below is for an older version of the current proposed rechartering effort
Document Proposed charter Extensions for Scalable DNS Service Discovery WG (dnssdext) Snapshot
Title DNS-SD Extensions
Last updated 2013-10-01
State Start Chartering/Rechartering (Internal Steering Group/IAB Review) Rechartering
WG State Proposed
IESG Responsible AD √Čric Vyncke
Charter Edit AD Ted Lemon
Send notices to rdroms@cisco.com,tjc@ecs.soton.ac.uk,cheshire@apple.com,kerlyn@ieee.org



Zero configuration networking protocols are currently well suited to
discover services within the scope of a single link.  In particular,
the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite
(sometimes referred to using Apple Computer Inc.'s trademark,
Bonjour) are widely used for DNS-based service discovery and
host name resolution where the client and server are co-located
on the same link.

The DNS-SD/mDNS protocol suite is used in many scenarios including
home, campus, and enterprise networks.  However, the zero configuration
mDNS protocol is constrained to link-local multicast scope by design,
and therefore cannot be used to discover services on remote links.

In a home network that consists of a single (possibly bridged) link,
users experience the expected discovery behavior; available services
appear because all devices share a common link.  However, in multi-link
home networks (as envisaged by the homenet WG) or in routed campus or
enterprise networks, devices and users can only discover services on
the same link, which is a significant limitation.  This has led to
calls, such as the Educause petition, to develop an appropriate service
discovery solution to span multiple links or to perform discovery across
a wide area, possibly on remote links.

In addition, the "Smart Energy Profile 2 Application Protocol Standard",
published by ZigBee Alliance and HomePlug Powerline Alliance specifies
the DNS-SD/mDNS protocol suite as the basis for its method of zero
configuration service discovery.  However, its use of wireless mesh
multi-link subnets in conjunction with traditional routed networks will
require extensions to the DNS-SD/mDNS 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 proprietary 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.  It is highly desirable
that any new solution is backwardly compatible with existing DNS-SD/mDNS
servers.  Any solution developed by the dnssdext WG must 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, with one or more links per
       routable prefix, 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 neighboring or non-neighboring 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 
   the information.

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-neighboring 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.