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.
AbstractThis 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.
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 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  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)  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. 4]. 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.
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. 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 , or DHCP . 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. Section 4.2.1 of . 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 +-----------+ | (220.127.116.11/25) | | | 18.104.22.168/24| RSIP +--+ ----------------+ server | SLP Scope: A | A +--+ | | | +-----------+ | 10.0.2.0/24 | (22.214.171.124/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 , 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. 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  to load balance access to TN3270E telnet servers.
Template text: ----------------------template begins here ------------------------- template-type = rsip template-version = 0.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  ike-support = BOOLEAN O #True if the server supports IKE as per  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. ----------------------template ends here ---------------------------
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.  Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, April 2001.  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, version 2", RFC 2608, July 1999.  Guttman, E, Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, July 1999.  Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.  Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
 Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, July 1999.  Naugle, J., Kasthurirangan, K. and G. Ledford, "TN3270E Service Location and Session Balancing", RFC 3049, January 2001.  Montenegro, G. and M. Borella, "RSIP Support for End-to-end IPSEC", RFC 3104, October 2001.  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
Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.