Network Working Group W. Zhao
Request for Comments: 3832 H. Schulzrinne
Category: Experimental Columbia University
E. Guttman
Sun Microsystems
C. Bisdikian
W. Jerome
IBM
July 2004
Remote Service Discovery in the
Service Location Protocol (SLP) via DNS SRV
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Remote service discovery refers to discovering desired services in
given remote (i.e., non-local) DNS domains. This document describes
remote service discovery in the Service Location Protocol (SLP) via
DNS SRV. It defines the DNS SRV Resource Records for SLP Directory
Agent services, discusses various issues in using SLP and DNS SRV
together for remote service discovery, and gives the steps for
discovering desired services in remote DNS domains.
1. Introduction
This document describes remote service discovery in the Service
Location Protocol (SLP) [RFC2608] via DNS SRV [RFC2782]. We consider
remote service discovery as discovering desired services in given
remote DNS domains, and local service discovery as discovering
desired services within the local administrative domain.
SLP provides a scalable framework for local service discovery and
selection. In SLP, User Agents (UAs) discover desired services in
the local administrative domain by querying all Service Agents (SAs)
via multicast or querying a Directory Agent (DA) via unicast. To
Zhao, et al. Experimental [Page 1]
RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
query a DA using unicast, a UA needs to first learn about the DA via
DHCP, static configuration or multicast (listening for DAAdvert
multicast or issuing DA discovery SrvRqst multicast).
DNS SRV provides good support for remote service discovery. However,
if multiple servers are discovered via DNS SRV for a service, only
priority and weight can be used to make a selection. If additional
service properties (such as cost, speed and service quality) need to
be considered in the selection process, DNS SRV becomes insufficient.
We propose that using SLP and DNS SRV together can provide better
support for remote service discovery. First, a UA uses DNS SRV to
find SLP DAs at a remote DNS domain. Then, the UA uses SLP to query
one of those DAs to discover desired services. In this way, we can
avoid the limitations in using SLP and DNS SRV separately. On one
hand, without DNS SRV, an SLP UA needs to depend on static
configuration to learn about remote DAs because DHCP and multicast DA
discovery are not generally applicable beyond the local
administrative domain. On the other hand, without SLP, DNS SRV has
limited support for service selection.
In this document, we first define the DNS SRV Resource Records (RRs)
for SLP DA services, which are used to map a given DNS domain to
remotely accessible (i.e., accessible from the Internet) DAs in that
domain. Then, we discuss various issues in using SLP and DNS SRV
together for remote service discovery. Finally, we give the steps
for discovering services in remote DNS domains.
1.1. Notation Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
2. The DNS SRV RRs for SLP DA services
According to RFC 2782 [RFC2782], the DNS SRV RRs for SLP DA services
are defined as follows:
_slpda._Proto.Name TTL Class SRV Priority Weight Port Target
where "slpda" is the symbolic name for SLP DA services, the Proto
field is either "tcp" or "udp", and the Target field is the domain
name of an SLP DA. Please refer to [RFC2782] for detailed
explanation of each field in DNS SRV RRs.
datatracker.ietf.org