# Name of submitters: James Kempf <james.kempf@sun.com>
#                     Gabriel Montenegro <gab@sun.com>
#
# Language of service template: en
#
# Security Considerations:
#   RSIP clients can use Service Location Protocol to find RSIP
#   servers having particular security characteristics. If secure
#   access to such information is required, SLP security should be
#   used.

# Finding an RSIP Server with SLP

# Abstract

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

# 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.

# 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].

#  Terminology

#    We reproduce here some SLP terminology from [2] for readers
#    unfamilar 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.
#
#       Service Agent (SA)
#
#                  A process working on behalf of one or more
#                  services to advertise the services and their
#                  capabilites.
#
#       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.

# 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 advertisment 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.
#
#    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.

# 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 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 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.

# 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 collects all the returned service URLs.
#
#     2. For each service URL, the client performs an SLP attribute
#        request for the attribute LOAD. The integer load figures
#        are returned.
#
#     3. The client sorts through the returned load figures and
#        selects the URL having the least number of connections.
#        The client establishes its RSIP session with that server.
#
#    Because of network delays, this procedure does not guarantee
#    that a client will always obtain a connection with the lightest
#    loaded server, but it does provide a high probability that the
#    selected server is more lightly loaded.
#
#    A similar procedure is used in [9] to load balance access to
#    TN3270E telnet servers.

# The RSIP Service Type Template

template-type = rsip

template-version = 1.0

template-description=
The service:rsip type provides advertisements for clients seeing
realm-specific IP (RSIP) servers. RSIP servers use the Realm
Specific IP protocol to manage addresses and other resources
from one realm on behalf of a client in another realm.

template-url-syntax=
; No additional URL path information required. An example service
; URL for an RSIP server is: service:rsip://gateway.mydomain:4455

ipsec-support = BOOLEAN O
# True if the server supports IPSEC as per [10]
TRUE,FALSE

ike-support = BOOLEAN O
# True if the server supports IKE as per [10]
TRUE,FALSE

tunnel-type = STRING L M O
IP-IP
# The tunneling methods supported by the RSIP server. Clients
# should include this attribute in a query so that they obtain a
# server offering a tunneling method for which they have
# support. Default is IP-IP. The values are currently
# restricted to IP-IP, L2TP, GRE and NONE. A server can support
# multiple tunnel types.
IP-IP,L2TP,GRE,NONE

transport = STRING L M O
TCP
# Transport used by the RSIP protocol itself.
TCP,UDP

load = INTEGER O
# If the server supports load balancing, this attribute should be
# set to an integer from 0 to 100. 0 is the lowest indication of
# load and 100 the highest.  Clients can query for this attribute
# and obtain load information, from which they can make an
# intelligent decision about which server to use.
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,
21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,
41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,
61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,
81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100

# Security Considerations

#    Service type templates provide information that is used to
#    interpret information obtained by clients through SLP. If the
#    RSIP template is modified or if a false template is
#    distributed, RSIP servers may not correctly register
#    themselves, or RSIP clients may not be able to interpret
#    service information.
#
#    SLP provides an authentication mechanism for UAs to assure that
#    service advertisments only come from trusted SAs. [2]  If trust
#    is an issue, particularly with respect to the information
#    sought by the client about IPSEC and IKE support, then SLP
#    authentication should be enabled in the network.

# Summary

#    This document describes how SLP can be used by RSIP clients to
#    find RSIP servers.  A service type template for an RSIP SLP
#    service type is presented.  In addition, a few techniques for
#    provisioning access to service advertisements for particular
#    gateway servers, and for load balancing using SLP were
#    provided.  The result should allow RSIP service provisioning
#    that is considerably more dynamic and robust than when
#    traditional service discovery mechanisms are used.

# References

#     [1] M. Borella, D. Grabelsky, J. Lo, and K. Taniguchi.  Realm
#         Specific IP: Protocol Specification.
#         draft-ietf-nat-rsip-protocol-05.txt (work in progress).
#
#     [2] E. Guttman, C. Perkins, J. Veizades, and M. Day.  Service
#         Location Protocol, version 2  RFC 2608, July, 1999.
#
#     [3] E. Guttman, C. Perkins, J. Kempf  Service Templates and
#         service: Schemes  RFC 2609, July, 1999.
#
#     [4] S. Bradner.  Key Words for Use in RFCs to Indicate
#         Requirement Levels.  RFC 2119, March 1997.
#
#     [5] A. Gulbrandsen, and P. Vixie.  A DNS RR for specifying the
#         location of services (DNS SRV).  RFC 2052, October, 1996.
#
#     [6] R. Droms  Dynamic Host Configuration Protocol.  RFC 2131,
#         March, 1997.
#
#     [7] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro.  Realm
#         Specific IP: Framework.
#         draft-ietf-nat-rsip-framework-03.txt (work in progress).
#
#     [8] C. Perkins and E. Guttman.  DHCP Options for Service
#         Location Protocol.  RFC 2610, July 1999.
#
#     [9] J. Naugle, K.  Kasthurirangan, and G. Ledford.  TN3270E
#         Service Location and Session Balancing.
#         draft-ietf-tn3270e-service-loc-03.txt (work in progress).
#
#    [10] G. Montenegro and M. Borella. RSIP Support for End-to- end
#         IPSEC. draft-ietf-nat-rsip-ipsec-02.txt (work in
#         progress).
#
#    [11] E. Guttman, "Service Location Protocol: Automatic
#         Discovery of IP Network Services," IEEE Internet
#         Computing, July/August 1999.  Available at:
#         http://computer.org/internet/ic1999/w4toc.htm

# Authors' Addresses

#   Questions about this document may be directed to:

#          James Kempf
#          Sun Labs Networking and Security Center
#          Sun Microsystems, Inc.
#          901 San Antonio Road
#          Mailstop UMPK 15-214
#          Palo Alto, CA 94303
#          USA
#
#          Phone:     +1 650 786 5890
#          Fax:       +1 650 786 6445
#          Email:     james.kempf@sun.com
#
#
#          Gabriel E. Montenegro
#          Sun Labs Networking and Security Center
#          Sun Microsystems, Inc.
#          901 San Antonio Road
#          Mailstop UMPK 15-214
#          Palo Alto, CA 94303
#          USA
#
#          Voice:     +1 650 786 6288
#          Fax:       +1 650 786 6445
#
#          Email:  gab@sun.com

# Copyright (c) The Internet Society (2000). All Rights Reserved.

#   This document and translations of it may be copied and furnished to
#   others, and derivative works that comment on or otherwise explain it
#   or assist in its implementation may be prepared, copied, published
#   and distributed, in whole or in part, without restriction of any
#   kind, provided that the above copyright notice and this paragraph are
#   included on all such copies and derivative works. However, this
#   document itself may not be modified in any way, such as by removing
#   the copyright notice or references to the Internet Society or other
#   Internet organizations, except as needed for the purpose of
#   developing Internet standards in which case the procedures for
#   copyrights defined in the Internet Standards process must be
#   followed, or as required to translate it into languages other than
#   English.
#
#   The limited permissions granted above are perpetual and will not be
#   revoked by the Internet Society or its successors or assigns.
#
#   This document and the information contained herein is provided on an
#   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
#   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
#   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
#   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
#   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.