[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3832

INTERNET DRAFT                                                W. Zhao
draft-zhao-slp-remote-da-discovery-04.txt              H. Schulzrinne
[Target Category: Standards Track]                Columbia University
January 18, 2003                                           E. Guttman
Expires: July 18, 2003                               Sun Microsystems
                                                         C. Bisdikian
                                                            W. Jerome
                                                                  IBM


          Finding Remote Directory Agents and Service Agents
              in the Service Location Protocol via DNS SRV


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 (2003).  All Rights Reserved.

Abstract

   This document describes how to find Directory Agents (DAs) and
   Service Agents (SAs) in the Service Location Protocol (SLP) at remote
   DNS domains via DNS SRV. It defines the SLP service and the DNS SRV
   Resource Record for the SLP service, describes the usage of Gateway
   DAs, and gives the steps for a User Agent to discover desired
   services in remote DNS domains.




Zhao, et al.            Expires: July 18, 2003                  [Page 1]

Internet Draft            SLP Remote Discovery          January 18, 2003


1. Introduction

   The Service Location Protocol (SLP [RFC2608]) is designed for local
   service discovery within one administrative domain. To extend SLP for
   discovering non-local services in remote DNS domains, a key issue is
   to enable a User Agent (UA) to find remote accessible Directory
   Agents (DAs) and Service Agents (SAs) in given DNS domains without
   relying on multicast. This document describes using DNS SRV [RFC2782]
   for this purpose.

   The SLP service has a service type of "service:slp" (defined in
   Section 2), and is provided by DAs and SAs. For a domain, the SLP
   servers listed as DNS SRV Resource Records (RRs) need to be
   functionally equivalent so that a UA can use any server in the list
   to get the same service information. However, two SLP servers will be
   different if at least one is SA, or they are in different scopes. In
   other words, only DAs in the same scope are functionally equivalent.
   Thus, if all remote accessible SLP servers in a domain are DAs in the
   same scope, then the domain just lists these DAs as DNS SRV RRs,
   otherwise the domain needs to deploy Gateway DAs (defined in Section
   4), and list those Gateway DAs as DNS SRV RRs.

   This document defines the "service:slp" template and the DNS SRV RR
   for the SLP service, describes the usage of Gateway DAs, and gives
   the steps for a UA to discover desired services in remote DNS
   domains.

   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 [RFC2119].

2. The "service:slp" Template

   The "service:slp" template defines the attributes associated with the
   SLP service. Please refer to RFC 2609 [RFC2609] 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: July 18, 2003                  [Page 2]

Internet Draft            SLP Remote Discovery          January 18, 2003


   ----------------------template begins here-----------------------

   template-type = slp

   template-version = 1.0

   template-description =
      This template is designed to enable a UA to discover information
      (including URL, server-type and scope) about all remote accessible
      DAs and SAs in a domain by unicasting a Service Request (SrvRqst)
      with "service:slp" as service type 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 the 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 [RFC1700], as required by RFC
   2782.

   For instance, if a UA makes a standard DNS query [RFC1034] 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)
   in 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: July 18, 2003                  [Page 3]

Internet Draft            SLP Remote Discovery          January 18, 2003


   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 Gateway DA (GDA) carries the "slp-gateway" attribute keyword in its
   DAAdvert, and maintains information (including URL, server-type and
   scope, as defined in the "service:slp" template) about all remote
   accessible DAs and SAs in its domain.

   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. 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 by multicasting "service:directory-agent" and
   "service:service-agent" Service Requests (SrvRqsts) 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 information about all DAs and SAs in its domain to anyone over
   the Internet.

   A remote UA can identify a GDA by the "slp-gateway" attribute keyword
   in the GDA's DAAdvert, then the UA can unicast a SrvRqst with
   "service:slp" as service type and with the Attribute List Extension
   [RFC3059] to the GDA to obtain information about all remote
   accessible DAs and SAs in the 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.

5. Steps for Remote Discovery in SLP

   Assume that a DNS domain D uses SLP to maintain its service
   information, and uses DNS SRV to map its SLP service. The steps for a
   remote client C to discover desired services in D are as follows.

   (1) C makes a DNS query for SRV RRs of the SLP service in D, and
       gets an SLP server list L in a DNS reply.

   (2) C selects a server Z from L based on the priority and weight
       information per RFC 2782.

   (3) C sends a "service:directory-agent" SrvRqst to Z to solicit
       Z's DAAdvert.



Zhao, et al.            Expires: July 18, 2003                  [Page 4]

Internet Draft            SLP Remote Discovery          January 18, 2003


       If Z's DAAdvert has the "slp-gateway" attribute keyword

       then Z is a GDA

         C sends a SrvRqst with "service:slp" as service type and
         with the Attribute List Extension to Z to obtain information
         about all remote accessible DAs and SAs in D.

       else Z is a regular DA

   (4) After finding out the remote accessible DAs and SAs in D, C can
       query these remote DAs or SAs via unicast to discover desired
       services in D.

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 [RFC2782] apply to this
   document.

7. Acknowledgments

   Kevin Arnold gave good suggestions.

8. Normative References

   [RFC2608] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service
       location protocol, version 2", RFC 2608, June 1999.

   [RFC2782] A. Gulbrandsen, P. Vixie and L. Esibov, "A DNS RR for
       specifying the location of services (DNS SRV)", RFC 2782,
       February 2000.

   [RFC2119] S. Bradner, "Key words for use in RFCs to indicate
       requirement levels", BCP 14, RFC 2119, March 1997.

   [RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", STD 2,
       RFC 1700, October 1994.

   [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
       STD 13, RFC 1034, November 1987.



Zhao, et al.            Expires: July 18, 2003                  [Page 5]

Internet Draft            SLP Remote Discovery          January 18, 2003


9. Non-normative References

   [RFC2609] E. Guttman, C. Perkins and J. Kempf, "Service Templates
       and Service: Schemes", RFC 2609, June, 1999.

   [RFC3059] E. Guttman, "Attribute List Extension for the Service
       Location Protocol", RFC 3059, February 2001.

10. Authors' Addresses

   Weibin Zhao
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027-7003

   EMail: zwb@cs.columbia.edu


   Henning Schulzrinne

   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027-7003

   EMail: hgs@cs.columbia.edu


   Erik Guttman
   Sun Microsystems
   Eichhoelzelstr. 7
   74915 Waibstadt
   Germany

   EMail: Erik.Guttman@sun.com


   Chatschik Bisdikian
   IBM Corp.
   Thomas J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY 10532, USA

   EMail: bisdik@us.ibm.com






Zhao, et al.            Expires: July 18, 2003                  [Page 6]

Internet Draft            SLP Remote Discovery          January 18, 2003


   William F. Jerome
   IBM Corp.
   Thomas J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY 10532, USA

   EMail: wfj@us.ibm.com


11. Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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
   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: July 18, 2003                  [Page 7]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/