IBM TotalStorage Productivity Center Protocols
Abstract There are industry standards and protocols that are the basis of the IBM TotalStorage Productivity Center. The understanding of these concepts is important for installing and customizing the IBM TotalStorage Productivity Center. This Technote provides an overview of Service Location Protocol.
Contents
The Service Location Protocol (SLP) is an Internet Engineering Task Force (IETF) standard, documented in Request for Comments (RFCs) 2165, 2608, 2609, 2610, and 2614. SLP provides a scalable framework for the discovery and selection of network services. SLP enables the discovery and selection of generic services, which could range in function from hardware services such as those for printers or fax machines, to software services such as those for file servers, e-mail servers, Web servers, databases, or any other possible services that are accessible through an IP network. Traditionally, to use a particular service, an end-user or client application needs to supply the host name or network IP address of that service. With SLP, however, the user or client no longer needs to know individual host names or IP addresses (for the most part). Instead, the user or client can search the network for the desired service type and an optional set of qualifying attributes. For example, a user could specify to search for all available printers that support Postscript. Based on the given service type (printers), and the given attributes (Postscript), SLP searches the user's network for any matching services, and returns the discovered list to the user.
SLP architecture
The Service Location Protocol architecture includes three major components: A Service Agent (SA), a User Agent (UA), and a Directory Agent (DA). The SA and UA are required components in an SLP environment, whereas the SLP DA is optional. The SMI-S specification introduces SLP as the method for the management applications (the CIM clients) to locate managed objects. In SLP a SA is used to report to UAs that a service that has been registered with the SA is available. Following is a description of these components.
Service Agent
The Service Location Protocol Service Agent is a component of the SLP architecture that works on behalf of one or more network services to broadcast the availability of those services by using broadcasts. The SA replies to external service requests using IP unicasts to provide the requested information about the registered services, if it is available. The SA can run in the same process or in a different process as the service itself. But in either case, the SA supports registration and de-registration requests for the service. The service registers itself with the SA during startup, and removes the registration for itself during shutdown. In addition, every service registration is associated with a life-span value, which specifies the time that the registration will be active. A service is required to reregister itself periodically, before the life-span of its previous registration expires. This ensures that expired registration entries are not kept. For instance, if a service becomes inactive without removing the registration for itself, that old registration will be removed automatically when its life-span expires. The maximum life-span of a registration is 65,535 seconds (about 18 hours).
User Agent
The Service Location Protocol User Agent is a process working on the behalf of the user to establish contact with some network service. The UA retrieves (queries for) service information from the service agents or directory agents. The UA is a component of SLP that is closely associated with a client application or a user who is searching for the location of one or more services on the network. You can use the SLP UA by defining a service type that you want the SLP UA to locate. The SLP UA then retrieves a set of discovered services, including their service Uniform Resource Locator (URL) and any service attributes. You can then use the service's URL to connect to the service. The SLP UA locates the registered services, based on a general description of the services that the user or client application has specified. This description usually consists of a service type, and any service attributes, that are matched against the service URLs registered in the SLP Service Agents. The SLP UA usually runs in the same process as the client application, although it is not necessary to do this. The SLP UA processes find requests by sending out multicast messages to the network and targeting all SLP SAs within the multicast range with a single User Datagram Protocol (UDP) message. The SLP UA is, therefore, able to discover these SAs with a minimum of network overhead. When an SA receives a service request, it compares its own registered services with the requested service type and any service attributes, if specified, and returns matches to the UA using a unicast reply message. The SLP UA follows the multicast convergence algorithm, and sends out repeated multicast messages until no new replies are received. The resulting set of discovered services, including their service URL and any service attributes, are returned to the client application or user. The client application or user is then responsible for contacting the individual services, as needed, using the service's URL.
A SLP UA is not required to discover all matching services that exist on the network, but only enough of them to provide useful results. This restriction is mainly due to the transmission size limits for UDP packets, which could be exceeded when there are many registered services or when the registered services have lengthy URLs or a large number of attributes. However, in most modern SLP implementations, the UAs are able to recognize truncated service replies and establish TCP connections to retrieve all of the information of the registered services. With this type of UA and SA implementation, the only exposure that remains is when there are too many SAs within the multicast range, which could cut short the multicast convergence mechanism. This exposure can be mitigated by the SLP administrator by setting up one or more SLP DAs.
Directory Agent
The Service Location Protocol Directory Agent (DA) is an optional component of SLP that collects and caches network service broadcasts. The DA is primarily used to simplify SLP administration and to improve SLP performance. The SLP DA can be thought of as an intermediate tier in the SLP architecture, placed between the user agents (UAs) and the service agents (SAs), such that both UAs and SAs communicate only with the DA instead of with each other. This eliminates a large portion of the multicast request or reply traffic on the network, and it protects the SAs from being overwhelmed by too many service requests if there are many UAs in the environment. When SLP DAs are present, the behavior of both SAs and UAs changes significantly. When an SA is first initializing, it performs a DA discovery using a multicast service request and specifies the special, reserved service type service:directory-agent. This process is also called active DA discovery, and it is achieved through the same mechanism as any other discovery using SLP. Similarly, in most cases, an SLP UA also performs active DA discovery using multicasting when it first starts up. However, if the SLP UA is statically configured with one or more DA addresses, it uses those addresses instead. If it is aware of one or more DAs, either through static configuration or active discovery, it sends unicast service requests to those DAs instead of multicasting to SAs. The DA replies with unicast service replies, providing the requested service Uniform Resource Locators (URLs) and attributes. The SLP DA functions very similarly to an SLP SA, receiving registration and deregistration requests, and responding to service requests with unicast service replies. There are a couple of differences, however, where DAs provide more functionality than SAs. One area, mentioned previously, is that DAs respond to service requests of the service:directoryagent service type with a DA advertisement response message, passing back a service URL containing the DA's IP address. This allows SAs and UAs to perform active discovery on DAs. One other difference is that when a DA first initializes, it sends out a multicast DA advertisement message to advertise its services to any existing SAs (and UAs) that might already be active on the network. UAs can optionally listen for, and SAs are required to listen for, such advertisement messages. This listening process is also sometimes called passive DA discovery. When the SA finds a new DA through passive DA discovery, it sends registration requests for all its currently registered services to that new DA.
Why to use an SLP DA
The primary reason to use DAs is to reduce the amount of multicast traffic involved in service discovery. In a large network with many UAs and SAs, the amount of multicast traffic involved in service discovery can become so large that network performance degrades. By deploying one or more DAs, UAs must unicast to DAs for service and SAs must register with DAs using unicast. The only SLP-registered multicast in a network with DAs is for active and passive DA discovery. SAs register automatically with any DAs they discover within a set of common scopes. Consequently, DAs within the UAs scopes reduce multicast. By eliminating multicast for normal UA request, delays and timeouts are eliminated. DAs act as a focal point for SA and UA activity. Deploying one or several DAs for a collection of scopes provides a centralized point for monitoring SLP activity. You can deploy any number of DAs for a particular scope or scopes, depending on the need to balance the load. In networks without multicast outing enabled, you can configure SLP to use broadcast. However, broadcast is very inefficient, because it requires each host to process the message. Broadcast also does not normally propagate across routers. As a result, in a network without multicast, DAs can be deployed on multihomed hosts to bridge SLP advertisements between the subnets.
When to use DAs
Use DAs in your enterprise if any of the following conditions are true: Multicast SLP traffic exceeds 1 percent of the bandwidth on your network, as measured by snoop. UA clients experience long delays or timeouts during multicast service request. You would like to centralize monitoring of SLP service advertisements for particular scopes on one or several hosts. Your network does not have multicast enabled, and consists of multiple subnets that must share services.