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

Versions: 00 01 02 03 04 05 06 RFC 3832

INTERNET DRAFT                                            Weibin Zhao
draft-zhao-slp-remote-da-discovery-02.txt         Henning Schulzrinne
February 6, 2002                                  Columbia University
Expires: August 6, 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: August 6, 2002                 [Page 1]

Internet Draft            SLP Remote Discovery          February 6, 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: August 6, 2002                 [Page 2]

Internet Draft            SLP Remote Discovery          February 6, 2002


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

   template-type = slp

   template-version = 1.0

   template-description =
      This template is designed to enable a UA to discover the URLs
      and scopes of all DAs and SAs in a domain by using a unicast
      SrvRqst with service type as "service:slp".

   template-url-syntax =
      ; No additional URL information is required. An example service
      ; URL for the SLP service is: service:slp://myda.mydomain:427

   server-type = STRING L
   DA
      # The type of the server that provides the SLP service
   DA,SA

   scope = STRING 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

   or




Zhao, et al.            Expires: August 6, 2002                 [Page 3]

Internet Draft            SLP Remote Discovery          February 6, 2002


       _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 is a special DA, which serves a special scope called "SLP" (it
   may serve other scopes at the same time), and maintains the
   information (URL, server-type, and scope) about all DAs and SAs in
   its domain using the "service:slp" template. A GDA gets the needed
   information via static configuration or listening for DAAdvert and
   SAAdvert multicast.

   A UA or SA can identify a GDA by its special scope "SLP". A UA can
   send a SrvRqst with service type as "service:slp" and with the
   Attribute List Extension to retrieve information about all DAs and
   SAs in its domain. If the UA just wants to discover DAs (or SAs), it
   needs to use the predicate "server-type=DA" (or "server-type=SA") in
   its SrvRqst.

   The deployment of GDAs in a domain is optional, but is recommended
   for a domain that supports remote discovery in SLP. GDAs provide an
   efficient way for a remote UA to discover the type and scope of all
   servers listed in DNS SRV using a single SrvRqst unicast to a GDA
   instead of multi-round of message exchanges with all servers.

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.

   (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,

       If Z replies a DAAdvert to C

       then Z is a DA

            If Z's DAAdvert includes the "SLP" scope

            then Z is a GDA

                 C sends a "service:slp" SrvRqst with the Attribute



Zhao, et al.            Expires: August 6, 2002                 [Page 4]

Internet Draft            SLP Remote Discovery          February 6, 2002


                 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

   The authors would like to thank Erik Guttman and Kevin Arnold for
   their valuable comments and suggestions.

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.




Zhao, et al.            Expires: August 6, 2002                 [Page 5]

Internet Draft            SLP Remote Discovery          February 6, 2002


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

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
   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: August 6, 2002                 [Page 6]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/