rfc2165.txt

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

                 implementation which does not include this option MUST
                 be prepared to interoperate with another implementation
                 which does include the option.

      silently discard
                 The implementation discards the datagram without
                 further processing, and without indicating an error to
                 the sender.  The implementation SHOULD provide the
                 capability of logging the error, including the contents
                 of the discarded datagram, and SHOULD record the event
                 in a statistics counter.

3. Protocol Overview

   The basic operation in Service Location is that a client attempts to
   discover the location of a Service.  In smaller installations, each
   service will be configured to respond individually to each client.
   In larger installations, services will register their services with
   one or more Directory Agents, and clients will contact the Directory
   Agent to fulfill requests for Service Location information.  Clients
   may discover the whereabouts of a Directory Agent by
   preconfiguration, DHCP [2, 11], or by issuing queries to the
   Directory Agent Discovery multicast address.







Veizades, et. al.           Standards Track                     [Page 6]

RFC 2165               Service Location Protocol               June 1997


3.1. Protocol Transactions

   The diagram below illustrates the relationships described below:

      +---------------+   we want this info:     +-----------+
      |  Application  | - - - - - - - - - - - -> |  Service  |
      +---------------+                          +-----------+
           /|\                                      |     |
            |                         +-------------+     |
            |                         |                   |
           \|/                       \|/                 \|/
      +---------------+          +-----------+      +----------------+
      |   User Agent  |<-------->|  Service  |      |    Service     |
      +---------------+          |   Agent   |      | Agent which    |
            |                    +-----------+      | does not reply |
            |                         |             | to UA requests |
            |                        \|/            +----------------+
            |                   +-------------+           |
            +------------------>|  Directory  |<----------+
                                |    Agent    |
                                +-------------+      ___________
                                     /|\            / Many other\
                                      +------------>|   SA's    |
                                                    \___________/

   The following describes the operations a User Agent would employ to
   find services on the site's network.  The User Agent needs no
   configuration to begin network interaction.  The User Agent can
   acquire information to construct predicates which describe the
   services that match the user's needs.  The User Agent may build on
   the information received in earlier network requests to find the
   Service Agents advertising service information.

   A User Agent will operate two ways:  If the User Agent has already
   obtained the location of a Directory Agent, the User Agent will
   unicast a request to it in order to resolve a particular request.
   The Directory Agent will unicast a reply to the User Agent.  The User
   Agent will retry a request to a Directory Agent until it gets a
   reply, so if the Directory Agent cannot service the request (say it
   has no information) it must return an response with zero values,
   possibly with an error code set.

   If the User Agent does not have knowledge of a Directory Agent or if
   there are no Directory Agents available on the site network, a second
   mode of discovery may be used.  The User Agent multicasts a request
   to the service-specific multicast address, to which the service it
   wishes to locate will respond.  All the Service Agents which are
   listening to this multicast address will respond, provided they can



Veizades, et. al.           Standards Track                     [Page 7]

RFC 2165               Service Location Protocol               June 1997


   satisfy the User Agent's request.  A similar mechanism is used for
   Directory Agent discovery; see section 5.2.  Service Agents which
   have no information for the User Agent MUST NOT respond.

   When a User Agent wishes to obtain an enumeration of ALL services
   which satisfy the query, a retransmission/convergence algorithm is
   used.  The User Agent resends the request, together with a list of
   previous responders.  Only those Service Agents which are not on the
   list respond.  Once there are no new responses to the request the
   accumulation of responses is deemed complete.  Depending on the
   length of the request, around 60 previous responders may be listed in
   a single datagram.  If there are more responders than this, the
   scaling mechanisms described in section 3.7 should be used.

   While the multicast/convergence model may be important for
   discovering services (such as Directory Agents) it is the exception
   rather than the rule.  Once a User Agent knows of the location of a
   Directory Agent, it will use a unicast request/response transaction.

   The Service Agent SHOULD listen for multicast requests on the
   service-specific multicast address, and MUST register with an
   available Directory Agent.  This Directory Agent will resolve
   requests from User Agents which are unicasted using TCP or UDP. This
   means that a Directory Agent must first be discovered, using DHCP,
   the DA Discovery Multicast address, the multicast mechanism described
   above, or manual configuration.  See section 5.2.

   A Service Agent which does not respond to multicast requests will not
   be useful in the absence of Directory Agents.  Some Service Agents
   may not include this functionality, if an especially lightweight
   implementation is required.

   If the service is to become unavailable, it should be deregistered
   with the Directory Agent.  The Directory Agent responds with an
   acknowledgment to either a registration or deregistration.  Service
   Registrations include a lifetime, and will eventually expire.
   Service Registrations need to be refreshed by the Service Agent
   before their Lifetime runs out.  If need be, Service Agents can
   advertise signed URLs to prove that they are authorized to provide
   the service.

3.2. Schemes

   The Service Location Protocol, designed as a way for clients to
   access resources on the network, is a natural application for
   Universal Resource Locators (URLs).  It is intended that by re-using
   URL specification and technology from the World Wide Web, clients and
   servers will be more flexible and able to be written using already



Veizades, et. al.           Standards Track                     [Page 8]

RFC 2165               Service Location Protocol               June 1997


   existing code.  Moreover, it is hoped that browsers will be written
   to take advantage of the similarity in locator format, so that a
   client can dynamically formulate requests for services that are
   resolved differently depending upon the circumstances.

3.2.1. The "service:"  URL scheme

   The service URL scheme is used by Service Location.  It is used to
   specify a Service Location.  Many Service Types will be named by
   including a scheme name after the "service:"  scheme name.  Service
   Types are used by SAs to register and deregister Services with DAs.
   It is also used by SAs and DAs to return Service Replies to UAs.  The
   formal definition of the "service:" URL scheme is in section 20.2.
   The format of the information which follows the "service:"  scheme
   should as closely as possible follow the URL structure and semantics
   as formalized by the IETF standardization process.

   Well known Service Types are registered with the IANA and templates
   are available as RFCs.  Private Service Types may also be supported.

3.3. Standard Attribute Definitions

   Service Types used with the Service Location Protocol must describe
   the following:

         Service Type string of the service
         Attributes and Keywords
         Attribute Descriptions and interpretations

   Service Types not registered with IANA will use their own Naming
   Authority string.  The registration process for new Service Types is
   defined in [13].

   Services which advertise a particular Service Type must support the
   complete set of standardized attributes.  They may support additional
   attributes, beyond the standardized set.  Unrecognized attributes
   MUST be ignored by User Agents.

   Service Type names which begin with "x-" are guaranteed not to
   conflict with any officially registered Service Type names.  It is
   suggested that this prefix be used for experimental or private
   Service Type names.  Similarly, attribute names which begin with "x-"
   are guaranteed not to be used for any officially registered attribute
   names.

   A service of a given Service Type should accept the networking
   protocol which is implied in its definition.  If a Service Type can
   accept multiple protocols, configuration information SHOULD be



Veizades, et. al.           Standards Track                     [Page 9]

RFC 2165               Service Location Protocol               June 1997


   included in the Service Type attribute information.  This
   configuration information will enable an application to use the
   results of a Service Request and Attribute Request to directly
   connect to a service.

   See section 20.2.1 for the format of a Service Type String as used in
   the Service Location Protocol.

3.4. Naming Authority

   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 a string which uniquely
   identifies an organization.  If no string is provided IANA is the
   default.  IANA stands for the Internet Assigned Numbers Authority.

   Naming Authorities may define Service Types which are experimental,
   proprietary or for private use.  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 5 and 9.

3.5. Interpretation of Service Location Replies

   Replies should be considered to be valid at the time of delivery.
   The service may, however, fail or change between the time of the
   reply and the moment an application seeks to make use of the service.
   The application making use of Service Location MUST be prepared for
   the possibility that the service information provided is either stale
   or incomplete.  In the case where the service information provided
   does not allow a User Agent to connect to a service as desired, the
   Service Request and/or Attribute Request may be resubmitted.

   Service specific configuration information (such as which protocol to
   use) should be included as attribute information in Service
   Registrations.  These configuration attributes will be used by
   applications which interpret the Service Location Reply.

3.6. Use of TCP, UDP and Multicast in Service Location

   The Service Location Protocol requires the implementation of UDP
   (connectionless) and TCP (connection oriented) transport protocols.
   The latter is used for bulk transfer, only when necessary.
   Connections are always initiated by an agent request or registration,
   not by a replying Directory Agent.  Service Agents and User Agents
   use ephemeral ports for transmitting information to the service
   location port, which is 427.




Veizades, et. al.           Standards Track                    [Page 10]

RFC 2165               Service Location Protocol               June 1997


   The Service Location discovery mechanisms typically multicast
   messages to as many enterprise networks as needed to establish
   service availability.  The protocol will operate in a broadcast
   environment with limitations detailed in section 3.6.1.

3.6.1. Multicast vs.  Broadcast

   The Service Location Protocol was designed for use in networks where
   DHCP is available, or multicast is supported at the network layer.
   To support this protocol when only network layer broadcast is
   supported, the following procedures may be followed.

3.6.1.1. Single Subnet

   If a network is not connected to any other networks simple network
   layer broadcasts will work in place of multicast.

   Service Agents SHOULD and Directory Agents MUST listen for broadcast
   Service Location request messages to the Service Location port.  This
   allows UAs which lack multicast capabilities to still make use of
   Service Location on a single subnet.

3.6.1.2. Multiple Subnets

   The Directory Agent provides a central clearing house of information
   for User Agents.  If the network is designed so that a Directory
   Agent address is statically configured with each User Agent and
   Service Agent, the Directory Agent will act as a bridge for
   information that resides on different subnets.  The Directory Agent
   address can be dynamically configured with Agents using DHCP. The
   address can also be determined by static configuration.

   As dynamic discovery is not feasible in a broadcast environment with
   multiple subnets and manual configuration is difficult, deploying DAs
   to serve enterprises with multiple subnets will require use of
   multicast discovery with multiple hops (i.e., TTL > 1 in the IP
   header).

3.6.2. Service-Specific Multicast Address

   This mechanism is used so that the number of datagrams any one
   service agent receives is minimized.  The Service Location General
   Multicast Address MAY be used to query for any service, though one
   SHOULD use the service-specific multicast address if it exists.

   If the site network does not support multicast then the query SHOULD
   be broadcast to the Service Location port.  If, on the other hand,
   the underlying hardware will not support the number of needed