tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2608

 Errata 
Proposed STD
Pages: 54
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SVRLOC

Service Location Protocol, Version 2

Part 1 of 3, p. 1 to 12
None       Next RFC Part

Updates:    2165
Updated by:    3224


Top       ToC       Page 1 
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

Top      ToC       Page 2 
        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

Top      ToC       Page 3 
    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.

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
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- +-----------+

Top      ToC       Page 6 
   Services are grouped together using 'scopes'.  These are strings
   which identify services which are administratively identified.  A
   scope could indicate a location, administrative grouping, proximity
   in a network topology or some other category.  Service Agents and
   Directory Agents are always assigned a scope string.

   A User Agent is normally assigned a scope string (in which case the
   User Agent will only be able to discover that particular grouping of
   services).  This allows a network administrator to 'provision'
   services to users.  Alternatively, the User Agent may be configured
   with no scope at all.  In that case, it will discover all available
   scopes and allow the client application to issue requests for any
   service available on the network.

   +---------+   Multicast  +-----------+   Unicast   +-----------+
   | Service | <--SrvRqst-- |   User    | --SrvRqst-> | Directory |
   |  Agent  |              |   Agent   |             |   Agent   |
   | Scope=X |   Unicast    | Scope=X,Y |   Unicast   |  Scope=Y  |
   +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+

   In the above illustration, the User Agent is configured with scopes X
   and Y. If a service is sought in scope X, the request is multicast.
   If it is sought in scope Y, the request is unicast to the DA.
   Finally, if the request is to be made in both scopes, the request
   must be both unicast and multicast.

   Service Agents and User Agents may verify digital signatures provided
   with DAAdverts.  User Agents and Directory Agents may verify service
   information registered by Service Agents.  The keying material to use
   to verify digital signatures is identified using a SLP Security
   Parameter Index, or SLP SPI.

   Every host configured to generate a digital signature includes the
   SLP SPI used to verify it in the Authentication Block it transmits.
   Every host which can verify a digital signature must be configured
   with keying material and other parameters corresponding with the SLP
   SPI such that it can perform verifying calculations.

   SAs MUST accept multicast service requests and unicast service
   requests.  SAs MAY accept other requests (Attribute and Service Type
   Requests).  SAs MUST listen for multicast DA Advertisements.

   The features described up to this point are required to implement.  A
   minimum implementation consists of a User Agent, Service Agent or
   both.

   There are several optional features in the protocol.  Note that DAs
   MUST support all these message types, but DA support is itself

Top      ToC       Page 7 
   optional to deploy on networks using SLP. UAs and SAs MAY support
   these message types.  These operations are primarily for interactive
   use (browsing or selectively updating service registrations.)  UAs
   and SAs either support them or not depending on the requirements and
   constraints of the environment where they will be used.

  Service Type Request   A request for all types of service on the
                         network.  This allows generic service browsers
                         to be built.

  Service Type Reply     A reply to a Service Type Request.

  Attribute Request      A request for attributes of a given type of
                         service or attributes of a given service.

  Attribute Reply        A reply to an Attribute Request.

  Service Deregister     A request to deregister a service or some
                         attributes of a service.

  Service Update         A subsequent SrvRqst to an advertisement.
                         This allows individual dynamic attributes to
                         be updated.

  SA Advertisement       In the absence of Directory Agents, a User
                         agent may request Service Agents in order
                         to discover their scope configuration.  The
                         User Agent may use these scopes in requests.

   In the absence of Multicast support, Broadcast MAY be used.  The
   location of DAs may be staticly configured, discovered using SLP as
   described above, or configured using DHCP. If a message is too large,
   it may be unicast using TCP.

   A SLPv2 implementation SHOULD support SLPv1 [22].  This support
   includes:

    1. SLPv2 DAs are deployed, phasing out SLPv1 DAs.

    2. Unscoped SLPv1 requests are considered to be of DEFAULT scope.
       SLPv1 UAs MUST be reconfigured to have a scope if possible.

    3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1
       DA. SLPv1 SAs MUST be reconfigured to have a scope if possible.

    4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2
       requests with SLPv2 replies.

Top      ToC       Page 8 
    5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same
       way.  That is, incoming requests from agents using either version
       of the protocol will be matched against this common set of
       registered services.

    6. SLPv2 registrations which use Language Tags which are greater
       than 2 characters long will be inaccessible to SLPv1 UAs.

    7. SLPv2 DAs MUST return only service type strings in SrvTypeRply
       messages which conform to SLPv1 service type string syntax, ie.
       they MUST NOT return Service Type strings for abstract service
       types.

    8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service
       URLs with abstract service types.  They only match Service URLs
       with concrete service types.

   SLPv1 UAs will not receive replies from SLPv2 SAs and SLPv2 UAs will
   not receive replies from SLPv1 SAs.  In order to interoperate UAs and
   SAs of different versions require a SLPv2 DA to be present on the
   network which supports both protocols.

   The use of abstract service types in SLPv2 presents a backward
   compatibility issue for SLPv1.  It is possible that a SLPv1 UA will
   request a service type which is actually an abstract service type.
   Based on the rules above, the SLPv1 UA will never receive an abstract
   Service URL reply.  For example, the service type 'service:x' in a
   SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'.
   If the request was made with SLPv2, it would return the attributes of
   this service.

4. URLs used with Service Location

   A Service URL indicates the location of a service.  This URL may be
   of the service: scheme [13] (reviewed in section 4.1), or any other
   URL scheme conforming to the URI standard [8], except that URLs
   without address specifications SHOULD NOT be advertised by SLP. The
   service type for an 'generic' URL is its scheme name.  For example,
   the service type string for "http://www.srvloc.org" would be "http".

   Reserved characters in URLs follow the rules in RFC 2396 [8].

Top      ToC       Page 9 
4.1. Service: URLs

   Service URL syntax and semantics are defined in  [13].  Any network
   service may be encoded in a Service URL.

   This section provides an introduction to Service URLs and an example
   showing a simple application of them, representing standard network
   services.

   A Service URL may be of the form:

      "service:"<srvtype>"://"<addrspec>

   The Service Type of this service: URL is defined to be the string up
   to (but not including) the final `:'  before <addrspec>, the address
   specification.

   <addrspec> is a hostname (which should be used if possible) or dotted
   decimal notation for a hostname, followed by an optional `:'  and
   port number.

   A service: scheme URL may be formed with any standard protocol name
   by concatenating "service:" and the reserved port [1] name.  For
   example, "service:tftp://myhost" would indicate a tftp service.  A
   tftp service on a nonstandard port could be
   "service:tftp://bad.glad.org:8080".

   Service Types SHOULD be defined by a "Service Template" [13], which
   provides expected attributes, values and protocol behavior.  An
   abstract service type (also described in [13]) has the form

      "service:<abstract-type>:<concrete-type>".

   The service type string "service:<abstract-type>" matches all
   services of that abstract type.  If the concrete type is included
   also, only these services match the request.  For example:  a SrvRqst
   or AttrRqst which specifies "service:printer" as the Service Type
   will match the URL service:printer:lpr://hostname and
   service:printer:http://hostname.  If the requests specified
   "service:printer:http" they would match only the latter URL.

   An optional substring MAY follow the last `.'  character in the
   <srvtype> (or <abstract-type> in the case of an abstract service type
   URL). This substring is the Naming Authority, as described in Section
   9.6.  Service types with different Naming Authorities are quite
   distinct.  In other words, service:x.one and service:x.two are
   different service types, as are service:abstract.one:y and
   service:abstract.two:y.

Top      ToC       Page 10 
4.2. Naming Authorities

   A Naming Authority MAY optionally be included as part of the Service
   Type string.  The Naming Authority of a service defines the meaning
   of the Service Types and attributes registered with and provided by
   Service Location.  The Naming Authority itself is typically a string
   which uniquely identifies an organization.  IANA is the implied
   Naming Authority when no string is appended.  "IANA" itself MUST NOT
   be included explicitly.

   Naming Authorities may define Service Types which are experimental,
   proprietary or for private use.  Using a Naming Authority, one may
   either simply ignore attributes upon registration or create a local-
   use only set of attributes for one's site.  The procedure to use is
   to create a 'unique' Naming Authority string and then specify the
   Standard Attribute Definitions as described above.  This Naming
   Authority will accompany registration and queries, as described in
   Sections 8.1 and 8.3.  Service Types SHOULD be registered with IANA
   to allow for Internet-wide interoperability.

4.3. URL Entries

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Reserved    |          Lifetime             |   URL Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |URL len, contd.|            URL (variable length)              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |# of URL auths |            Auth. blocks (if any)              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   SLP stores URLs in protocol elements called URL Entries, which
   associate a length, a lifetime, and possibly authentication
   information along with the URL. URL Entries, defined as shown above,
   are used in Service Replies and Service Registrations.

5. Service Attributes

   A service advertisement is often accompanied by Service Attributes.
   These attributes are used by UAs in Service Requests to select
   appropriate services.

   The allowable attributes which may be used are typically specified by
   a Service Template  [13] for a particular service type.  Services
   which are advertised according to a standard template MUST register
   all service attributes which the standard template requires.  URLs
   with schemes other than "service:" MAY be registered with attributes.

Top      ToC       Page 11 
   Non-standard attribute names SHOULD begin with "x-", because no
   standard attribute name will ever have those initial characters.

   An attribute list is a string encoding of the attributes of a
   service.  The following ABNF [11] grammar defines attribute lists:

   attr-list = attribute / attribute `,' attr-list
   attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag
   attr-val-list = attr-val / attr-val `,' attr-val-list
   attr-tag = 1*safe-tag
   attr-val = intval / strval / boolval / opaque
   intval = [-]1*DIGIT
   strval = 1*safe-val
   boolval = "true" / "false"
   opaque = "\FF" 1*escape-val
   safe-val = ; Any character except reserved.
   safe-tag = ; Any character except reserved, star and bad-tag.
   reserved = `(' / `)' / `,' / `\' / `!'  / `<' / `=' / `>' / `~' / CTL
   escape-val = `\' HEXDIG HEXDIG
   bad-tag = CR / LF / HTAB / `_'
    star = `*'

   The <attr-list>, if present, MUST be scanned prior to evaluation for
   all occurrences of the escape character `\'.  Reserved characters
   MUST be escaped (other characters MUST NOT be escaped).  All escaped
   characters must be restored to their value before attempting string
   matching.  For Opaque values, escaped characters are not converted -
   they are interpreted as bytes.

      Boolean      Strings which have the form "true" or "false" can
                   only take one value and may only be compared with
                   '='.  Booleans are case insensitive when compared.

      Integer      Strings which take the form [-] 1*<digit> and fall
                   in the range "-2147483648" to "2147483647" are
                   considered to be Integers.  These are compared using
                   integer comparison.

      String       All other Strings are matched using strict lexical
                   ordering (see Section 6.4).

      Opaque       Opaque values are sequences of bytes.  These are
                   distinguished from Strings since they begin with
                   the sequence "\FF".  This, unescaped, is an illegal
                   UTF-8 encoding, indicating that what follows is a
                   sequence of bytes expressed in escape notation which
                   constitute the binary value.  For example, a '0' byte
                   is encoded "\FF\00".

Top      ToC       Page 12 
   A string which contains escaped values other than from the reserved
   set of characters is illegal.  If such a string is included in an
   <attr-list>, <tag-list> or search filter, the SA or DA which receives
   it MUST return a PARSE_ERROR to the message.

   A keyword has only an <attr-tag>, and no values.  Attributes can have
   one or multiple values.  All values are expressed as strings.

   When values have been advertised by a SA or are registered in a DA,
   they can take on implicit typing rules for matching incoming
   requests.

   Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is
   disallowed.  A DA or SA receiving such an <attr-list> MUST return an
   INVALID_REGISTRATION error.



(page 12 continued on part 2)

Next RFC Part