Salutation and SLP

by Pete St. Pierre,Sun Microsystems and Tohru Mori, IBM Jpan

The Technical Committee of the Salutation Consortium is now working to enhance the Salutation Architecture to support directory-based service discovery by utilizing Service Location Protocol (SLP). This work will achieve better scalability of the architecture in large workgroup or enterprise environments.

The current proposal has the Salutation Manager (SLM) searching for a SLP directory agent through multicast, broadcast, or manual configuration. If it finds one, the SLM will use SLP protocol instead of Salutation protocol to register and un-register Functional Units it supports with the SLP directory. Furthermore, the SLM will use SLP Protocol to search for services requested by Salutation client applications.

For a small workgroup, where a directory service is not available or not necessary, the SLM may not find a SLP directory agent. In this case, SLM will use Salutation protocol broadcasts to find other SLMs and advertise the capabilities of the Functional Units it supports. Salutation Protocol is also used to locate the services requested by Salutation client applications.

The Salutation API is designed to make Salutation applications unaware of the underlying transport and discovery protocols. Therefore the application programmer does not need to know if a directory exists or not. Furthermore, since the SLP directory agent can be a gateway to a LDAP-based directory, the Salutation API and SLM provide a single application interface to all three of these protocols. Salutation, SLP, and LDAP are all complementary with Salutation providing a single API into each.

SLP Components: There are three discreet components to SLP. These are Service Agents (SA), User Agents (UA) and Directory Agents (DA). A Service Agent is a process working on the behalf of one or more services to advertise the services. A User Agent is a process working on the user's behalf to establish contact with a useful service. The UA may retrieve service information from a Directory Agent. A Directory Agent collects and caches service advertisements from SAs.

SLP Message Types: SLP supports a number of message types. In discussing the basic operation of SLP entities in a Salutation environment, we will describe the use of SLP messages for registering and de-registering services, requesting services, and replying to service requests.

- SrvReg: A Service Agent issues one SrvReg message for each instance of a service that it provides. These messages contain a URL for the service, a set of attribute/value pairs that describe the service, and a lifetime for the service.

- SrvAck: A Directory Agent returns a SrvAck message when a SrvReg message has been processed. SrvAck messages are unicast to the Service Agent that sent the registration.

- SrvDeReg: A Service Agent issues a SrvDeReg when an instance of a service becomes unavailable.

- SrvRqst: A User Agent issues a SrvRqst message to locate a service. The request may include a set of attribute/value pairs for selecting services that meet certain criteria.

- SrvRply: A Directory Agent responds with SrvRply when a service provided matches the criteria specified in a SrvRqst. A SrvRply that contains no URLs may be generated in response to a SrvRqst message.

SLP also supports messages for requesting the attributes of a specific service, requesting a list of all available services, and for Directory Agents to advertise themselves. Complete explanation of these messages can be found in the Service Location Protocol specification.

How Salutation Utilizes SLP in Enterprise Networks

As part of the FU registration process, a Service Agent sends a SrvReg message to a Directory Agent. This registration contains the service URL for the specific instance of the service, as well as attribute/value pairs that describe the service. Directory Agents that have been configured in the network cache these registrations. Once a registration has been cached, a DA responds with a SrvAck message. Service registrations also contain a lifetime. If the service has become unavailable but was unable to de-register itself, lifetime values allow a DA to expire cached registrations. This situation should only occur if an SA is unable to issue an SrvDeReg message. During normal operation SAs will periodically refresh their registrations with subsequent SrvReg messages. These "refresh" messages are not required to contain a full set of attributes, though may contain updated information if the values have changed.

User Agents make requests from DAs when a service is required. There are different ways a UA may discover a DA. In addition to statically configuring the UA with the address of the DA, a UA may request the address of a DA using the Dynamic Host Configuration Protocol (DHCP). While these two options exist, it is important that SLP be able to operate without manual configuration. For this reason, a UA may use the SrvRqst to find a DA. The SrvRqst is multicast to the IANA assigned multicast address for Service Location Protocol. The "service" requested in this message is called "directory-agent". Because this is a multicast request, it may receive more than one unicast reply. The resulting list of directory agents can then be used for other service requests.

Once a UA has the address of a DA, subsequent service requests can be made directly to that entity. Let us look at printers as an example. If a UA is trying to locate a printer service, a SrvRqst is constructed. This message contains the service type "printer", with an optional list of attributes and values. The attribute/value pair describes the type of printer desired. This message is unicast to a directory agent either pre-configured, or discovered through the multicast. The DA receiving the SrvRqst performs a lookup on the cached registrations, attempting to match the attributes and values requested. A SrvRply is then unicast to the requesting UA. This reply contains zero or more service URLs, depending on the match results. The client may then use the service URL to locate the printer.

Summary: SLP brings the scalability of directory based service discovery to Salutation to create a robust platform for service discovery. Using SLP and Salutation together, network appliances of the future can be designed to discover and communicate with each other in environments that range from the corporate office to the kitchen counter.