Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2608

Service Location Protocol, Version 2

Pages: 54
Proposed Standard
Errata
Updates:  2165
Updated by:  3224
Part 1 of 3 – Pages 1 to 12
None   None   Next

Top   ToC   RFC2608 - 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   RFC2608 - 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   RFC2608 - 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   RFC2608 - 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   RFC2608 - 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   RFC2608 - 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   RFC2608 - 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   RFC2608 - 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   RFC2608 - 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   RFC2608 - 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   RFC2608 - 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   RFC2608 - 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 Section