INTERNET DRAFT Weibin Zhao
draft-zhao-slp-remote-da-discovery-03.txt Henning Schulzrinne
March 25, 2002 Columbia University
Expires: September 25, 2002 Chatschik Bisdikian
William Jerome
IBM
The SLP Service and Remote Discovery in SLP
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes remote discovery in the Service Location
Protocol (SLP) via DNS SRV. It defines the "service:slp" template and
the name of DNS SRV RR for the SLP service, describes the usage of
Gateway Directory Agents, and gives the steps for a User Agent to
discover desired services in a remote DNS domain.
Zhao, et al. Expires: September 25, 2002 [Page 1]
Internet Draft SLP Remote Discovery March 25, 2002
1. Introduction
The Service Location Protocol (SLP [1]) provides a lightweight
mechanism for service discovery within one administrative domain. In
addition to the local domain, SLP can be used to discover desired
services in specific remote DNS domains. The key issue for remote
discovery in SLP is to enable a User Agent (UA) to learn about remote
Directory Agents (DAs) or/and remote Service Agents (SAs) without
relying on multicast.
As a mechanism to map a specific service in a given DNS domain to a
list of server names, DNS SRV [2] provides a convenient way for a UA
to discover the SLP service in a remote DNS domain. The SLP service
has a service type of "service:slp" (defined in section 2), and is
provided by SAs and DAs. A simple way to map the SLP service is to
list SAs or/and DAs (if DAs are deployed) as DNS SRV RRs. However,
this simple approach has two limitations: (1) a remote UA needs to
guess that each server listed in DNS SRV is a DA or SA (see section
5); (2) a remote UA needs to go through the server list in DNS SRV to
discover all scopes. A more efficient and scalable way to support
remote discovery in SLP is to deploy Gateway DAs (GDAs), and list
GDAs as DNS SRV RRs.
This document defines the "service:slp" template and the name of DNS
SRV RR for the SLP service, describes the usage of GDAs, and gives
the steps for a UA to discover desired services in a remote DNS
domain.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted according to RFC 2119 [3].
2. The "service:slp" Template
The "service:slp" template defines the attributes associated with the
SLP service. Please refer to RFC 2609 [4] for detailed explanation of
the syntax.
Name of submitters: Weibin Zhao <zwb@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu>
Language of service template: en (English)
Security Considerations:
Standard SLP authentication SHOULD be used to protect valuable
SLP server and scope information.
Template Text:
Zhao, et al. Expires: September 25, 2002 [Page 2]
Internet Draft SLP Remote Discovery March 25, 2002
----------------------template begins here-----------------------
template-type = slp
template-version = 1.0
template-description =
This template is designed to enable a UA to discover the
information (URL, server-type, and scope) about of all remote
accessible SLP server agents (DAs and SAs) in a domain by
sending a unicast SrvRqst with service type as "service:slp"
to a Gateway DA.
template-url-syntax =
; No additional URL information is required. An example service
; URL for the SLP service is: service:slp://myda.mydomain:427
slp-server-type = STRING L
DA
# The type of the server that provides the SLP service
DA,SA
slp-scope = STRING M L
# The serving scopes of this server
-----------------------template ends here------------------------
3. The DNS SRV RR for the SLP service
The name of DNS SRV RR for the SLP service has the following format:
_slp._<protocol>.<domain>
where <protocol> is either "tcp" or "udp", and <domain> is a domain
name (such as example.com). Note that "slp" is the symbolic name for
the SLP service in Assigned Numbers [5], as required by RFC 2782 [2].
For instance, if a UA makes a standard DNS query [6] for SRV RRs of
the SLP service using the name:
_slp._tcp.example.com or _slp._udp.example.com
then the UA will receive a list of SRV RRs (which matches the query)
from a DNS reply, such as
_slp._tcp.example.com IN SRV 0 0 427 da1.example.com
_slp._tcp.example.com IN SRV 0 0 427 da2.example.com
Zhao, et al. Expires: September 25, 2002 [Page 3]
Internet Draft SLP Remote Discovery March 25, 2002
or
_slp._udp.example.com IN SRV 0 0 427 da1.example.com
_slp._udp.example.com IN SRV 0 0 427 da2.example.com
4. Gateway DA
A GDA carries the "slp-gateway" attribute keyword in its DAAdvert,
and maintains the information (URL, server-type, and scope) about all
remote accessible DAs and SAs in its domain using the "service:slp"
template.
By default, a GDA SHOULD be statically configured only since the
administrator normally needs to decide which DAs and SAs should be
accessible from remote UAs. In general, a domain may just want part
of its DAs and SAs to be remote accessible. The administrator can
manually configure a GDA using serialized registration files, and
update "service:slp" registrations at a GDA using SrvReg and SrvDeReg
messages.
Note that a GDA MAY be configured to periodically perform active DA
and SA discovery (when multicast is available) to gather information
about DAs and SAs in its domain. However, this feature MUST be used
with caution because a GDA configured in this way may expose the
information of all DAs and SAs in its domain to anyone over the
Internet.
A UA can identify a GDA by the "slp-gateway" attribute keyword in its
DAAdvert. Thus, a UA can send a SrvRqst with service type as
"service:slp" and with the Attribute List Extension [7] to a GDA to
retrieve information about all remote accessible DAs and SAs in the
GDA's domain. If the UA just wants to discover DAs (or SAs), it needs
to use the predicate "slp-server-type=DA" (or "slp-server-type=SA")
in the SrvRqst message.
The deployment of GDAs in a domain is optional. But for a domain that
supports remote discovery in SLP, the deployment of GDAs is
recommended since it provides an efficient way for a remote UA to
discover the type and scope of all remote accessible SLP server
agents (DAs and SAs) using a single SrvRqst unicast to a GDA instead
of a multi-round of message exchanges with all those SLP server
agents.
5. Steps for Remote Discovery in SLP
Assume that all services in a DNS domain D are maintained by SLP, and
D uses DNS SRV to map its SLP service. The steps for a remote client
C to discover desired services in D are as follows.
Zhao, et al. Expires: September 25, 2002 [Page 4]
Internet Draft SLP Remote Discovery March 25, 2002
(1) C makes a DNS query for SRV RRs of the SLP service in D, and
gets an SLP server list L from a DNS reply.
(2) C selects a server Z from L based on the metric information
returned from the DNS SRV RRs as per RFC 2782 [2].
(3) C sends a "service:directory-agent" SrvRqst to Z to solicit
Z's DAAdvert,
If Z replies with a DAAdvert to C
then Z is a DA
If Z's DAAdvert includes the "slp-gateway" attribute keyword
then Z is a GDA
C sends a "service:slp" SrvRqst with the Attribute
List Extension to Z to obtain information about all
DAs and SAs in D.
else Z is a regular DA
else Z is an SA
C sends a "service:service-agent" SrvRqst to Z to solicit
Z's SAAdvert.
(4) After finding out the URLs and scopes of DAs and SAs in D, C can
query these remote DAs or SAs via unicast to discover desired
services.
6. Security Considerations
To enable remote discovery in SLP, the local domain information is
exposed to external users. Thus, standard SLP authentication SHOULD
be used to protect valuable service information.
There is a risk that any SA could advertise any service on a
generally accessible DA. Such a DA SHOULD reject all registrations
that cannot be authenticated.
The security considerations for DNS SRV [2] apply to this document.
7. Acknowledgments
Erik Guttman reviewed the whole document in detail and gave many
valuable comments. Kevin Arnold also provided good suggestions.
Zhao, et al. Expires: September 25, 2002 [Page 5]
Internet Draft SLP Remote Discovery March 25, 2002
8. References
[1] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location
protocol, version 2", RFC 2608, June 1999.
[2] A. Gulbrandsen, P. Vixie and L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)", RFC 2782, February 2000.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[4] E. Guttman, C. Perkins and J. Kempf, "Service Templates and
Service: Schemes", RFC 2609, June, 1999.
[5] J. Reynolds and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[6] P. Mockapetris, "Domain Names - Concepts and Facilities", STD
13, RFC 1034, November 1987.
[7] E. Guttman, "Attribute List Extension for the Service Location
Protocol", RFC 3059, February 2001.
9. Authors' Addresses
Weibin Zhao
Henning Schulzrinne
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027-7003
Email: {zwb,hgs}@cs.columbia.edu
Chatschik Bisdikian
William F. Jerome
IBM T. J. Watson Research Center
P.O.Box 218
Yorktown Heights, NY 10598-0218
Email: {bisdik,wfj}@us.ibm.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
Zhao, et al. Expires: September 25, 2002 [Page 6]
Internet Draft SLP Remote Discovery March 25, 2002
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zhao, et al. Expires: September 25, 2002 [Page 7]