# Name of submitters: James Kempf # Gabriel Montenegro # # 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.