draft-guttman-svrloc-rfc2608bis-03.txt

来自「Pegasus is an open-source implementation」· 文本 代码 · 共 791 行 · 第 1/3 页

Internet Engineering Task Force                  Erik Guttman
INTERNET DRAFT                                    James Kempf
Category: Standards Track
Obsoletes: 2608
August 4, 2002


                  Service Location Protocol, Version 2
                <draft-guttman-svrloc-rfc2608bis-03.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Comments on this document should be sent to the SLP discussion list,
   [e-mail].

   Internet-Drafts are draft documents of the Internet Engineering Task
   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."  See http://www.ietf.org/ietf/1id-abstracts.txt.
   Find shadow directories at http://www.ietf.org/shadow.html.

   Copyright (C) The Internet Society (2001).  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.  This document updates SLPv2, adding clarifications
   and removing features which were neither widely implemented or deemed
   useful.

Acknowledgements

   Authors of previous versions of SLP listed alphabetically are Mike
   Day, Erik Guttman, Scott Kaplan, Charles Perkins and John Veizades.
   Contributors to this version include (in alphabetical order) Kevin
   Arnold, Erik Guttman, Evan Hughes, Terry Lambert, Jim Mayer, Ira
   McDonald, Mikael Pahmp, Matt Peterson and Weibin Zhao.

1. Introduction

   The Service Location Protocol (SLP) provides a flexible and scalable
   framework for provisioning network nodes with information on the



Guttman & Kempf         Expires: 3 February 2003                [Page 1]

Internet Draft               SLPv2 Revision                  August 2002


   existence, location, and configuration of networked services.  Users
   have had to manually configure the location of services by typing in
   their domain names or IP addresses.  SLP eliminates this requirement:
   the user supplies the desired type of service and a set of attributes
   that describe the service.  Based on that description, SLP returns
   all required information to communicate with the service.

   SLP is a dynamic configuration mechanism for applications in networks
   under a common administration.  Client applications using SLP may
   find available services offered by hosts attached on any network
   within an enterprise.

   This document obsoletes SLPv2 [RFC2608], correcting protocol errors
   and removing some requirements.  A separate SLPv2 applicability
   statement [SLPv2AS] describes both the protocol's domain of
   applicability as well as the interoperability of this specification
   with prior versions of the protocol.

2. Terminology and Conventions used in this Document

   Attribute
      An Attribute consists of a tag and a list of typed values.  An
      Attribute without a value list, called a "keyword" attribute, may
      also appear. Attributes are used to describe instances of a
      service type.

   Directory Agent (DA)
      A network element that collects and caches service advertisements.
      There can only be one DA present per host.

   Directory Agent (DA) Service Type
      The Directory Agent Service Type is the service type
      "service:directory-agent".  It is used to discover DAs.

   Naming Authority
      The agency or group that catalogues Service Types and Attributes.
      The default Naming Authority is IANA.  Except for the default
      Naming Authority, requires not describing string, a Naming
      Authority is described by a short string.

   Network Element
      A software process capable of network communication.

   Scope
      A named collection of service advertisements, making up a logical
      administrative group.

   Service Advertisement
      The set consisting of a Service Type, a Service URL, a list of
      Scopes, a Language Tag, a List of Attributes and a lifetime,
      indicating how long the advertisement is valid. This set serves to


Guttman & Kempf         Expires: 3 February 2003                [Page 2]

Internet Draft               SLPv2 Revision                  August 2002


      describe the service and provide information on its location,
      availability, and language locale.

   Service Agent (SA)
      A network element working on the behalf of services to advertise
      them.

   Service Agent (SA) Service Type
      The Service Agent Service Type is the service type
      "service:service-agent". It is used to discover and advertise SAs.

   Service Template
      A structured description of a service, including the Service Type,
      Service URL, and Attributes. See [RFC2609].

   Service Type
      A short string describing the service.  Each type of service has a
      unique Service Type string.  The default service type for a
      'generic' URI is its scheme name.  For example, the service type
      string for "http://www.srvloc.org" is "http".

   Service URL
      A Service URL serves two functions in SLP.  First, it is a handle
      to refer to a service advertisement, for purposes of registration,
      deregistration or requesting associated attributes.  Second, the
      Service URL may indicate the location of a service.  A service URL
      may be of the service: scheme [RFC2609] or any other scheme
      conforming to the URI standard [RFC2396].

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

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

   In packet diagrams, an explicit length field may be followed by a
   variable length field. Variable length fields are terminated by a
   backslash ('\').  Fields are not aligned to 4 byte boundaries.

3. Protocol Overview

   In SLP, service discovery support for a client application is
   provided by  a UA.  Service advertising support for a service is
   provided by an SA.  A third network element, the DA, provides
   scalability to the protocol.

   To discover a service using SLP, the UA MUST issue a Service Request
   (SrvRqst) on behalf of a client application.  The SrvRqst specifies


Guttman & Kempf         Expires: 3 February 2003                [Page 3]

Internet Draft               SLPv2 Revision                  August 2002


   the characteristics of a service required by the client.  The UA MUST
   receive one or more Service Reply (SrvRply) specifying the location
   of all services in the network that match the conditions supplied in
   the SrvRqst, if the request was successful.

   The SLP framework allows a UA to directly issue requests to SAs.
   Such requests SHOULD be multicast.  A SA MUST unicast a reply to the
   UA, containing a Service URL and other information, if the SA
   advertises a service matching the request.

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

   In larger networks, one or more DAs are used.  A DA functions as a
   cache.  If DAs are in use, SAs MUST send Service Registration
   (SrvReg) messages, containing all the services they advertise to DAs.
   SAs MUST receive Service Acknowledgements (SrvAck) messages in reply.
   Advertisements registered with DAs MUST be refreshed or they will
   expire, since each advertisement has a finite lifetime.  If DAs are
   in use, UAs MUST unicast requests to a DA instead of multicasting.
   Deploying DAs thereby  helps reduce the amount of multicast datagrams
   in a network.

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

   There are three possible ways for UAs and SAs to discover DAs.  In
   each case, the agent obtains a DA Advertisement (DAAdvert):

    1) Issue a multicast SrvRqst for the DA Service Type when they start
       up, and receive a unicast advertisement in reply,

    2) Listen for unsolicited advertisements that are  sent periodically
       by Directory Agents,

    3) Obtain Directory Agent addresses via DHCP or static
       configuration, issue a unicast SrvRqst for the Directory Agent
       Service Type, and receive a unicast DAAdvert in reply.

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

   Service advertisements are grouped into named sets called 'scopes'.
   Scope names are expressed as strings. A scope can indicate a
   location, administrative grouping, proximity in a network topology or
   some other category. The mapping between service advertisements and


Guttman & Kempf         Expires: 3 February 2003                [Page 4]

Internet Draft               SLPv2 Revision                  August 2002


   scopes is at the discretion of the network administrator.  SAs and
   DAs MUST be configured with scopes.

   A UA MAY be assigned scopes, in which case the UA is only able to
   discover that particular grouping of services.  This allows a network
   administrator to assign services to particular groups of users.
   Alternatively, the UA MAY be configured with no scope at all.  In
   that case, the UA MUST discover all available scopes and a client
   application may issue requests for any service available on the
   network.

   In the following figure, the UA is configured with scopes X and Y. If
   a service is sought in scope X, the request MUST be multicast because
   no DA supports scope X. If a service is sought in scope Y, the
   request MUST be unicast to the DA.  If the request is made in both
   scopes, the request MUST be both unicast and multicast.

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

3.1 SLP Message Types

   Table 1 contains a brief summary of all SLP, along with the
   requirement level for the SLP agents. SAs MUST accept multicast and
   unicast SrvRqsts.  SAs SHOULD accept Attribute Requests (AttrRqsts),
   see Appendix B.  SAs MAY accept Service Type Requests (SrvTypeRqsts).