draft-ietf-dnssd-requirements-05.txt   draft-ietf-dnssd-requirements-06.txt 
DNS-SD/mDNS Extensions K. Lynn DNS-SD/mDNS Extensions K. Lynn
Internet-Draft Verizon Internet-Draft Verizon
Intended status: Informational S. Cheshire Intended status: Informational S. Cheshire
Expires: September 5, 2015 Apple, Inc. Expires: September 20, 2015 Apple, Inc.
M. Blanchet M. Blanchet
Viagenie Viagenie
D. Migault D. Migault
Ericsson Ericsson
March 4, 2015 March 19, 2015
Requirements for Scalable DNS-SD/mDNS Extensions Requirements for Scalable DNS-SD/mDNS Extensions
draft-ietf-dnssd-requirements-05 draft-ietf-dnssd-requirements-06
Abstract Abstract
DNS-SD over mDNS is widely used today for discovery and resolution of DNS-Based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is
services and names on a local link, but there are use cases to extend widely used today for discovery and resolution of services and names
DNS-SD/mDNS to enable service discovery beyond the local link. This on a local link, but there are use cases to extend DNS-SD/mDNS to
document provides a problem statement and a list of requirements. enable service discovery beyond the local link. This document
provides a problem statement and a list of requirements.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2015. This Internet-Draft will expire on September 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 8 skipping to change at page 4, line 8
2.1. Multi-link Naming and Discovery 2.1. Multi-link Naming and Discovery
A list of desired DNS-SD/mDNS improvements from network A list of desired DNS-SD/mDNS improvements from network
administrators in the research and education community was issued in administrators in the research and education community was issued in
the form of the Educause petition [EP]. The following is a summary the form of the Educause petition [EP]. The following is a summary
of their technical issues: of their technical issues:
o Products that advertise services such as printing and multimedia o Products that advertise services such as printing and multimedia
streaming via DNS-SD over mDNS are not currently discoverable by streaming via DNS-SD over mDNS are not currently discoverable by
devices on other links. It is common practice for enterprises and devices on other links. It is common practice for enterprises and
institutions to use wireless links for client access and wired institutions to use wireless links for client access to wired
networks for server infrastructure, typically on different networks and server infrastructure, typically on other subnets.
subnets. DNS-SD used with conventional unicast DNS does work when DNS-SD used with conventional unicast DNS does work when devices
devices are on different links, but the resource records that are on different links, but the resource records that describe the
describe the service must somehow be entered into the unicast DNS service must somehow be entered into the unicast DNS namespace.
namespace.
o DNS-SD resource records may be entered manually into a unicast DNS o DNS-SD resource records may be entered manually into a unicast DNS
zone file [STATIC], but this task must be performed by a DNS zone file [STATIC], but this task must be performed by a DNS
administrator. It is labor-intensive and brittle when IP administrator. It is labor-intensive and brittle when IP
addresses of devices change dynamically, as is common when DHCP is addresses of devices change dynamically, as is common when DHCP is
used. used.
o Automatically adding DNS-SD records using DNS Update works, but o Automatically adding DNS-SD records using DNS Update works, but
requires that the DNS server be configured to allow DNS Updates, requires that the DNS server be configured to allow DNS Updates,
and requires that devices be configured with the DNS Update and requires that devices be configured with the DNS Update
skipping to change at page 8, line 37 skipping to change at page 8, line 37
date by the time it reaches the receiver, even if only by a date by the time it reaches the receiver, even if only by a
few microseconds, or less. Thus timeliness is always an few microseconds, or less. Thus timeliness is always an
engineering trade-off against efficiency. The engineering engineering trade-off against efficiency. The engineering
decisions for SSD should appropriately balance timeliness decisions for SSD should appropriately balance timeliness
against network efficiency. against network efficiency.
REQ14: SSD should operate over existing networks (as described by REQ14: SSD should operate over existing networks (as described by
use cases A-F above) without requiring changes to the network use cases A-F above) without requiring changes to the network
at the physical, link, or internetworking layers. at the physical, link, or internetworking layers.
REQ15: The administrator of an advertised service should be able to
control whether the service is advertised beyond the local
link.
5. Namespace Considerations 5. Namespace Considerations
The traditional unicast DNS namespace contains, for the most part, The traditional unicast DNS namespace contains, for the most part,
globally unique names. Multicast DNS provides every link with its globally unique names. Multicast DNS provides every link with its
own separate link-local namespace, where names are unique only within own separate link-local namespace, where names are unique only within
the context of that link. Clients discovering services may need to the context of that link. Clients discovering services may need to
differentiate between local and global names, and may need to differentiate between local and global names, and may need to
determine when names in different namespaces identify the same determine when names in different namespaces identify the same
service. service.
Devices on different links may have the same mDNS name (perhaps due Devices on different links may have the same mDNS name (perhaps due
to vendor defaults), because link-local mDNS names are only to vendor defaults), because link-local mDNS names are only
guaranteed to be unique on a per-link basis. Also, even devices that guaranteed to be unique on a per-link basis. This may lead to a
are on the same link may have similar-looking names, such as one local label disambiguation problem when results are aggregated (e.g.,
device with the name "Bill" and another device using the similar- for presentation).
looking name "Bi11" (using the digit "1" in place of the letter "l").
This may lead to a local label disambiguation problem between
presented results.
SSD should support rich internationalized labels within Service SSD should support rich internationalized labels within Service
Instance Names, as DNS-SD/mDNS does today. SSD must not negatively Instance Names, as DNS-SD/mDNS does today. SSD must not negatively
impact the global DNS namespace or infrastructure. impact the global DNS namespace or infrastructure.
The problem of publishing local services in the global DNS namespace The problem of publishing local services in the global DNS namespace
may be generally viewed as exporting local resource records and their may be generally viewed as exporting local resource records and their
associated labels into some DNS zone. The issues related to defining associated labels into some DNS zone. The issues related to defining
labels that are interoperable between local and global namespaces are labels that are interoperable between local and global namespaces are
discussed in a separate document discussed in a separate document
 End of changes. 8 change blocks. 
21 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/