rfc3105.txt

RFC 的详细文档！

Network Working Group                                           J. Kempf
Request for Comments: 3105                           NTT DoCoMo USA Labs
Category: Experimental                                     G. Montenegro
                                                        Sun Microsystems
                                                            October 2001

                    Finding an RSIP Server with SLP

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

IESG Note

   The IESG notes that the set of documents describing the RSIP
   technology imply significant host and gateway changes for a complete
   implementation.  In addition, the floating of port numbers can cause
   problems for some applications, preventing an RSIP-enabled host from
   interoperating transparently with existing applications in some cases
   (e.g., IPsec).  Finally, there may be significant operational
   complexities associated with using RSIP.  Some of these and other
   complications are outlined in section 6 of the RFC 3102, as well as
   in the Appendices of RFC 3104.  Accordingly, the costs and benefits
   of using RSIP should be carefully weighed against other means of
   relieving address shortage.

Abstract

   This document contains an SLP service type template that describes
   the advertisements made by RSIP servers for their services.  Service
   Location Protocol (SLP) is an IETF standards track protocol
   specifically designed to allow clients to find servers offering
   particular services.  Since RSIP (Realm Specific IP) clients require
   a mechanism to discover RSIP servers, SLP is a natural match for a
   solution.  The service type template is the basis for an Internet
   Assigned Numbers Authority (IANA) standard definition of the
   advertisements offered by RSIP servers, an important step toward
   interoperability.






Kempf & Montenegro            Experimental                      [Page 1]

RFC 3105            Finding an RSIP Server with SLP         October 2001


Table of Contents

   1.  Introduction ...............................................  2
   2.  Notation Conventions .......................................  2
   3.  Terminology ................................................  2
   4.  Using SLP for RSIP Service Discovery .......................  3
   5.  Using Scopes for Server Provisioning .......................  4
   6.  Load Balancing .............................................  6
   7.  The RSIP Service Type Template .............................  7
   8.  Security Considerations ....................................  9
   9.  Summary ....................................................  9
   References .....................................................  9
   Authors' Addresses ............................................. 10
   Full Copyright Statement ....................................... 11

1. Introduction

   Realm Specific IP (RSIP) [7] enables an RSIP client in one realm to
   borrow addresses and other resources from another realm.  It does so
   by engaging in an RSIP protocol [1] exchange with an RSIP server.
   The RSIP protocol requires the RSIP server to have a permanent
   presence on both realms.

   There are a variety of traditional ways an RSIP client could go about
   locating the appropriate RSIP server.  However, Service Location
   Protocol (SLP) [2][11] is an IETF standards track protocol
   specifically designed to facilitate location of services and their
   servers by clients.  SLP provides a number of features that simplify
   locating RSIP servers.  In this document, we describe how RSIP
   clients can use SLP to discover RSIP servers.

2.  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 [4].

3.  Terminology

   We reproduce here some SLP terminology from [2] for readers
   unfamiliar with SLP.

   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.




Kempf & Montenegro            Experimental                      [Page 2]

RFC 3105            Finding an RSIP Server with SLP         October 2001


   Service Agent (SA)

      A process working on behalf of one or more services to advertise
      the services and their capabilities.

   Directory Agent (DA)

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

   Scope

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

   Service Advertisement

      A URL, attributes, and a lifetime (indicating how long the
      advertisement is valid), providing service access information and
      capabilities description for a particular service.

4.  Using SLP for RSIP Service Discovery

   SLP provides the framework in which RSIP clients and servers make
   contact.  Here is a description of how an RSIP server and client find
   each other using SLP:

   1. The RSIP server implements a SLP SA while the RSIP client
      implements an SLP UA.

   2. The RSIP SA constructs a service advertisement consisting of a
      service URL, attributes and a lifetime.  The URL has service type
      "service:rsip", and attributes defined according to the template
      in Section 7.

   3. If an SLP DA is found, the SA contacts the DA and registers the
      advertisement.  If no DA is found, the SA maintains the
      advertisement itself, answering multicast UA queries directly.

   4. When the RSIP client requires contact information for an RSIP
      server, the UA either contacts the DA using unicast or the SA
      using multicast.  The UA includes a query based on the attributes
      to indicate the characteristics of the server it requires.

   5. Once the UA has the host name or address of the RSIP server as
      well as the port number, it can begin negotiation using the RSIP
      protocol.




Kempf & Montenegro            Experimental                      [Page 3]

RFC 3105            Finding an RSIP Server with SLP         October 2001


   This procedure is exactly the same for any client/server pair
   implementing SLP and is not specific to RSIP.

   Many protocols use a variety of traditional methods for service
   discovery.  These methods include static configuration, purpose-build
   protocols for discovery, special features in the protocol itself, DNS
   SRV RRs [5], or DHCP [6].  SLP provides a number of advantages over
   these traditional methods:

   1. Discovery of services using SLP is dynamic, whereas many of the
      traditional methods only allow static or weakly dynamic (i.e.,
      difficult to update) discovery.  Clients only discover services
      that are actually active with SLP.  Furthermore, if subsequent to
      initial discovery a server goes down, the client can reissue an
      SLP query and obtain a new server.  On the server side, no
      databases must be updated to provide dynamic discovery, the
      servers advertise themselves.

   2. SLP requires no third party configuration.  Only the server
      offering the service and the client seeking it are required to
      know the details for the particular service type.

   3. SLP allows clients to specify the attributes describing the
      desired server.  A client discovers servers that meet a set of
      specific requirements.  This reduces the amount of network traffic
      involved in selecting a server when many possible choices are
      available.

   4. SLP contains a number of scaling mechanisms (DAs, scopes,
      multicast convergence algorithm), that facilitate deployment in
      large enterprise networks as well as in smaller networks.

5.  Using Scopes for Server Provisioning

   One particular design feature of SLP that is useful for RSIP is
   scopes.  Scopes in SLP are a mechanism for provisioning access to
   particular service advertisements.  An administrator assigns UAs and
   SAs to particular scopes to assure that UAs only find SAs in those
   scopes.  Scopes are not an access control mechanism for the service
   itself, however.  UAs from outside the scope can still access
   services in a particular scope (unless the service itself provides
   for access control), they just won't be able to find the services
   using SLP.

   Scopes are useful for RSIP service advertisement provisioning because
   they allow a system administrator to tie particular RSIP clients to
   specific RSIP servers.  For example, consider the network
   architecture described in Section 4.2.1 of [7].  RSIP clients are



Kempf & Montenegro            Experimental                      [Page 4]

RFC 3105            Finding an RSIP Server with SLP         October 2001


   recommended to find "the nearest" RSIP server, but exactly how that
   should be arranged is left unspecified.  SLP provides a way for
   system administrators to precisely specify which realm an RSIP client
   resides in, by tying the realm to an SLP scope.  The diagram from
   Section 14.1 is reproduced here, with SLP scopes included to
   illustrate how clients could be directed to the right RSIP servers.

                                +-----------+
                                |           |
                                |   RSIP    |
                                |  server   +---- 10.0.0.0/8
                                |     B     |   SLP Scope: B
                                |           |
                                +-----+-----+
                                      |
                                      | 10.0.1.0/24
                       +-----------+  | (149.112.240.0/25)
                       |           |  |
       149.112.240.0/24|    RSIP   +--+
       ----------------+   server  |    SLP Scope: A
                       |      A    +--+
                       |           |  |
                       +-----------+  | 10.0.2.0/24
                                      | (149.112.240.128/25)
                                      |
                                +-----+-----+
                                |           |
                                |   RSIP    |
                                |  server   +---- 10.0.0.0/8
                                |     C     |     SLP Scope: C
                                |           |
                                +-----------+

   Clients on the upper 10.0.0.0/8 network are configured to use SLP
   scope B, while clients on the lower 10.0.0.0/8 network are configured
   to use SLP scope C.  RSIP servers B and C (as clients of server A)
   use SLP to locate RSIP server A, as do other RSIP clients on the
   10.0.1.0/24 and 10.0.2.0/24 subnets.  Within these two subnets, all
   clients have their scopes configured to be A.

   Note that specifying a particular SLP scope for RSIP clients does not
   restrict the SLP scope for other services advertised by SLP.  SLP UAs
   can be configured for multiple scopes, so the scope configured for
   printing may be different from the scope configured for RSIP service.

   Since SLP scopes are configured through a DHCP option [8], along with
   the IP address, system administrators can easily switch a cluster of
   machines from one realm to another by simply changing the scope and



Kempf & Montenegro            Experimental                      [Page 5]

RFC 3105            Finding an RSIP Server with SLP         October 2001


   IP address assignments on the DHCP server.  For example, in the above
   architecture, suppose a system administrator wanted to remove RSIP
   server B so that clients on the upper 10.0.0.0/8 subnet were directly
   on subnet 10.0.1.0/24.  These clients now communicate with RSIP
   server A.  By simply changing the address assignments and scope
   configuration of these clients on the DHCP server, the realm can be
   effectively switched.

6.  Load Balancing

   While SLP itself contains no specific provision for load balancing,
   load balancing can easily be implemented using SLP.  The only
   requirement is that the service type template specify an attribute
   indicating server load.  In the case of RSIP, the service type
   template in Section 7  contains such an attribute.  The attribute
   indicates the number of RSIP client sessions currently being
   supported by the server.

   In order to perform load balancing, the RSIP server must update its
   service advertisement periodically as new connections are accepted.
   An RSIP client seeking to find the server having the lightest load
   performs the following series of SLP operations.

   1. As in Section 4, the client issues an SLP service request and