rfc2608.txt

SLP协议在linux下的实现。此版本为1.2.1版。官方网站为www.openslp.org

Network Working Group                                        E. Guttman
Request for Comments: 2608                                   C. Perkins
Updates: 2165                                          Sun Microsystems
Category: Standards Track                                   J. Veizades
                                                          @Home Network
                                                                 M. Day
                                                      Vinca Corporation
                                                              June 1999


                  Service Location Protocol, Version 2

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   The Service Location Protocol provides a scalable framework for the
   discovery and selection of network services.  Using this protocol,
   computers using the Internet need little or no static configuration
   of network services for network based applications.  This is
   especially important as computers become more portable, and users
   less tolerant or able to fulfill the demands of network system
   administration.

Table of Contents

    1. Introduction                                                    3
        1.1. Applicability Statement  . . . . . . . . . . . . . . .    3
    2. Terminology                                                     4
        2.1. Notation Conventions . . . . . . . . . . . . . . . . .    4
    3. Protocol Overview                                               5
    4. URLs used with Service Location                                 8
        4.1. Service: URLs  . . . . . . . . . . . . . . . . . . . .    9
        4.2. Naming Authorities   . . . . . . . . . . . . . . . . .   10
        4.3. URL Entries  . . . . . . . . . . . . . . . . . . . . .   10
    5. Service Attributes                                             10
    6. Required Features                                              12
        6.1. Use of Ports, UDP, and Multicast   . . . . . . . . . .   13



Guttman, et al.             Standards Track                     [Page 1]

RFC 2608         Service Location Protocol, Version 2          June 1999


        6.2. Use of TCP   . . . . . . . . . . . . . . . . . . . . .   14
        6.3. Retransmission of SLP messages   . . . . . . . . . . .   15
        6.4. Strings in SLP messages  . . . . . . . . . . . . . . .   16
              6.4.1. Scope Lists in SLP . . . . . . . . . . . . . .   16
    7. Errors                                                         17
    8. Required SLP Messages                                          17
        8.1. Service Request  . . . . . . . . . . . . . . . . . . .   19
        8.2. Service Reply  . . . . . . . . . . . . . . . . . . . .   21
        8.3. Service Registration . . . . . . . . . . . . . . . . .   22
        8.4. Service Acknowledgment . . . . . . . . . . . . . . . .   23
        8.5. Directory Agent Advertisement. . . . . . . . . . . . .   24
        8.6. Service Agent Advertisement. . . . . . . . . . . . . .   25
    9. Optional Features                                              26
        9.1. Service Location Protocol Extensions . . . . . . . . .   27
        9.2. Authentication Blocks  . . . . . . . . . . . . . . . .   28
              9.2.1. SLP Message Authentication Rules . . . . . . .   29
              9.2.2. DSA with SHA-1 in Authentication Blocks  . . .   30
        9.3. Incremental Service Registration   . . . . . . . . . .   30
        9.4. Tag Lists  . . . . . . . . . . . . . . . . . . . . . .   31
   10. Optional SLP Messages                                          32
       10.1. Service Type Request   . . . . . . . . . . . . . . . .   32
       10.2. Service Type Reply   . . . . . . . . . . . . . . . . .   32
       10.3. Attribute Request  . . . . . . . . . . . . . . . . . .   33
       10.4. Attribute Reply  . . . . . . . . . . . . . . . . . . .   34
       10.5. Attribute Request/Reply Examples . . . . . . . . . . .   34
       10.6. Service Deregistration   . . . . . . . . . . . . . . .   36
   11. Scopes                                                         37
       11.1. Scope Rules  . . . . . . . . . . . . . . . . . . . . .   37
       11.2. Administrative and User Selectable Scopes. . . . . . .   38
   12. Directory Agents                                               38
       12.1. Directory Agent Rules  . . . . . . . . . . . . . . . .   39
       12.2. Directory Agent Discovery  . . . . . . . . . . . . . .   39
             12.2.1. Active DA Discovery  . . . . . . . . . . . . .   40
             12.2.2. Passive DA Advertising . . . . . . . . . . . .   40
       12.3. Reliable Unicast to DAs and SAs. . . . . . . . . . . .   41
       12.4. DA Scope Configuration   . . . . . . . . . . . . . . .   41
       12.5. DAs and Authentication Blocks. . . . . . . . . . . . .   41
   13. Protocol Timing Defaults                                       42
   14. Optional Configuration                                         43
   15. IANA Considerations                                            44
   16. Internationalization Considerations                            45
   17. Security Considerations                                        46
    A. Appendix:  Changes to the Service Location Protocol from
                  v1 to v2                                            48
    B. Appendix:  Service Discovery by Type:  Minimal SLPv2 Features  48
    C. Appendix:  DAAdverts with arbitrary URLs                       49
    D. Appendix:  SLP Protocol Extensions                             50
        D.1. Required Attribute Missing Option  . . . . . . . . . .   50



Guttman, et al.             Standards Track                     [Page 2]

RFC 2608         Service Location Protocol, Version 2          June 1999


    E. Acknowledgments                                                50
    F. References                                                     51
    G. Authors' Addresses                                             53
    H. Full Copyright Statement                                       54

1. Introduction

   The Service Location Protocol (SLP) provides a flexible and scalable
   framework for providing hosts with access to information about the
   existence, location, and configuration of networked services.
   Traditionally, users have had to find services by knowing the name of
   a network host (a human readable text string) which is an alias for a
   network address.  SLP eliminates the need for a user to know the name
   of a network host supporting a service.  Rather, the user supplies
   the desired type of service and a set of attributes which describe
   the service.  Based on that description, the Service Location
   Protocol resolves the network address of the service for the user.

   SLP provides a dynamic configuration mechanism for applications in
   local area networks.  Applications are modeled as clients that need
   to find servers attached to any of the available networks within an
   enterprise.  For cases where there are many different clients and/or
   services available, the protocol is adapted to make use of nearby
   Directory Agents that offer a centralized repository for advertised
   services.

   This document updates SLPv1 [RFC 2165], correcting protocol errors,
   adding some enhancements and removing some requirements.  This
   specification has two parts.  The first describes the required
   features of the protocol.  The second describes the extended features
   of the protocol which are optional, and allow greater scalability.

1.1. Applicability Statement

   SLP is intended to function within networks under cooperative
   administrative control.  Such networks permit a policy to be
   implemented regarding security, multicast routing and organization of
   services and clients into groups which are not be feasible on the
   scale of the Internet as a whole.

   SLP has been designed to serve enterprise networks with shared
   services, and it may not necessarily scale for wide-area service
   discovery throughout the global Internet, or in networks where there
   are hundreds of thousands of clients or tens of thousands of
   services.






Guttman, et al.             Standards Track                     [Page 3]

RFC 2608         Service Location Protocol, Version 2          June 1999


2. Terminology

      User Agent (UA)
                A process working on the user's behalf to establish
                contact with some service.  The UA retrieves service
                information from the Service Agents or Directory Agents.

      Service Agent (SA) A process working on the behalf of one or more
                services to advertise the services.

      Directory Agent (DA) A process which collects service
                advertisements.  There can only be one DA present per
                given host.

      Service Type Each type of service has a unique Service Type
                string.

      Naming Authority The agency or group which catalogues given
                Service Types and Attributes.  The default Naming
                Authority is IANA.

      Scope A set of services, typically making up a logical
                administrative group.

      URL A Universal Resource Locator [8].

2.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 RFC 2119  [9].

      Syntax        Syntax for string based protocols follow the
                    conventions defined for ABNF [11].

      Strings       All strings are encoded using the UTF-8 [23]
                    transformation of the Unicode [6] character set and
                    are NOT null terminated when transmitted.  Strings
                    are preceded by a two byte length field.

      <string-list> A comma delimited list of strings with the
                    following syntax:

                       string-list = string / string `,' string-list

   In format diagrams, any field ending with a \ indicates a variable
   length field, given by a prior length field in the protocol.




Guttman, et al.             Standards Track                     [Page 4]

RFC 2608         Service Location Protocol, Version 2          June 1999


3. Protocol Overview

   The Service Location Protocol supports a framework by which client
   applications are modeled as 'User Agents' and services are advertised
   by 'Service Agents.'  A third entity, called a 'Directory Agent'
   provides scalability to the protocol.

   The User Agent issues a 'Service Request' (SrvRqst) on behalf of the
   client application, specifying the characteristics of the service
   which the client requires.  The User Agent will receive a Service
   Reply (SrvRply) specifying the location of all services in the
   network which satisfy the request.

   The Service Location Protocol framework allows the User Agent to
   directly issue requests to Service Agents.  In this case the request
   is multicast.  Service Agents receiving a request for a service which
   they advertise unicast a reply containing the service's location.

      +------------+ ----Multicast SrvRqst----> +---------------+
      | User Agent |                            | Service Agent |
      +------------+ <----Unicast SrvRply------ +---------------+

   In larger networks, one or more Directory Agents are used.  The
   Directory Agent functions as a cache.  Service Agents send register
   messages (SrvReg) containing all the services they advertise to
   Directory Agents and receive acknowledgements in reply (SrvAck).
   These advertisements must be refreshed with the Directory Agent or
   they expire.  User Agents unicast requests to Directory Agents
   instead of Service Agents if any Directory Agents are known.

 +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
 | User  |                    | Directory |                   |Service |
 | Agent |                    |   Agent   |                   | Agent  |
 +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+

   User and Service Agents discover Directory Agents two ways.  First,
   they issue a multicast Service Request for the 'Directory Agent'
   service when they start up.  Second, the Directory Agent sends an
   unsolicited advertisement infrequently, which the User and Service
   Agents listen for.  In either case the Agents receive a DA
    Advertisement (DAAdvert).

        +---------------+ --Multicast SrvRqst-> +-----------+
        |    User or    | <--Unicast DAAdvert-- | Directory |
        | Service Agent |                       |   Agent   |
        +---------------+ <-Multicast DAAdvert- +-----------+





Guttman, et al.             Standards Track                     [Page 5]

RFC 2608         Service Location Protocol, Version 2          June 1999


   Services are grouped together using 'scopes'.  These are strings