Discovery protocol SLP - universAAL/middleware GitHub Wiki

• Define the role of the protocol

The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration.

• Define significant scenarios where the protocol is actually involved

SLP provides a dynamic configuration mechanism for applications in local area networks. Applications are modeled as clients that need to find servers attached to any of the available networks within an enterprise. For cases where there are many different clients and/or services available, the protocol is adapted to make use of nearby Directory Agents that offer a centralized repository for advertised services.

SLP is intended to function within networks under cooperative administrative control. Such networks permit a policy to be implemented regarding security, multicast routing and organization of services and clients into groups which are not be feasible on the scale of the Internet as a whole. SLP has been designed to serve enterprise networks with shared services, and it may not necessarily scale for wide-area service discovery throughout the global Internet, or in networks where there are hundreds of thousands of clients or tens of thousands of services.

• Provide and overview of protocol architecture (free to organize this section in according to the available info sources: wikipedia, rfc, official specs)

The Service Location Protocol supports a framework by which client applications are modeled as 'User Agents' and services are advertised by 'Service Agents.' A third entity, called a 'Directory Agent' provides scalability to the protocol. The User Agent issues a 'Service Request' (SrvRqst) on behalf of the client application, specifying the characteristics of the service which the client requires. The User Agent will receive a Service Reply (SrvRply) specifying the location of all services in the network which satisfy the request. The Service Location Protocol framework allows the User Agent to directly issue requests to Service Agents. In this case the request is multicast. Service Agents receiving a request for a service which they advertise unicast a reply containing the service's location.

In larger networks, one or more Directory Agents are used. The Directory Agent functions as a cache. Service Agents send register messages (SrvReg) containing all the services they advertise to Directory Agents and receive acknowledgements in reply (SrvAck). These advertisements must be refreshed with the Directory Agent or they expire. User Agents unicast requests to Directory Agents instead of Service Agents if any Directory Agents are known.

User and Service Agents discover Directory Agents two ways. First, they issue a multicast Service Request for the 'Directory Agent' service when they start up. Second, the Directory Agent sends an unsolicited advertisement infrequently, which the User and Service Agents listen for. In either case the Agents receive a DA Advertisement (DAAdvert).

Services are grouped together using 'scopes'. These are strings which identify services which are administratively identified. A scope could indicate a location, administrative grouping, proximity in a network topology or some other category. Service Agents and Directory Agents are always assigned a scope string. A User Agent is normally assigned a scope string (in which case the User Agent will only be able to discover that particular grouping of services). This allows a network administrator to 'provision' services to users. Alternatively, the User Agent may be configured with no scope at all. In that case, it will discover all available scopes and allow the client application to issue requests for any service available on the network.

Service Agents and User Agents may verify digital signatures provided with DAAdverts. User Agents and Directory Agents may verify service information registered by Service Agents. The keying material to use to verify digital signatures is identified using a SLP Security Parameter Index, or SLP SPI. Every host configured to generate a digital signature includes the SLP SPI used to verify it in the Authentication Block it transmits. Every host which can verify a digital signature must be configured with keying material and other parameters corresponding with the SLP SPI such that it can perform verifying calculations. SAs MUST accept multicast service requests and unicast service requests. SAs MAY accept other requests (Attribute and Service Type Requests). SAs MUST listen for multicast DA Advertisements. The features described up to this point are required to implement. A minimum implementation consists of a User Agent, Service Agent or both. There are several optional features in the protocol. Note that DAs MUST support all these message types, but DA support is itself optional to deploy on networks using SLP. UAs and SAs MAY support these message types. These operations are primarily for interactive use (browsing or selectively updating service registrations.) UAs and SAs either support them or not depending on the requirements and constraints of the environment where they will be used.

• quick protocol stack snippet by providing a concise description of every layer
• Define existing device constraints for protocol adoption: general purpose device vs specific one. This section aims at quickly mark those protocols designed for unrealistic AAL Node

This section defines the minimal implementation requirements for SAs and UAs as well as their interaction with DAs. A DA is not required for SLP to function, but if it is present, the UA and SA MUST interact with it as defined below. A minimal implementation may consist of either a UA or SA or both. The only required features of a UA are that it can issue SrvRqsts according to the rules below and interpret DAAdverts, SAAdverts and SrvRply messages. The UA MUST issue requests to DAs as they are discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or SAAdvert messages. The SA MUST also register with DAs as they are discovered. UAs perform discovery by issuing Service Request messages. SrvRqst messages are issued, using UDP, following these prioritized rules:

1. A UA issues a request to a DA which it has been configured with by DHCP.
2. A UA issues requests to DAs which it has been statically configured with.
3. UA uses multicast/convergence SrvRqsts to discover DAs, then uses that set of DAs. A UA that does not know of any DAs SHOULD retry DA discovery, increasing the waiting interval between subsequent attempts exponentially (doubling the wait interval each time.) The recommended minimum waiting interval is CONFIG_DA_FIND seconds.
4. A UA with no knowledge of DAs sends requests using multicast convergence to SAs. SAs unicast replies to UAs according to the multicast convergence algorithm.

• Define how the selected protocol answers to node addressing challenge
• Try to provide the ad-hoc definition of “node-addressing” for the specific protocol. (Maybe there exist different definitions of “addressing” for the reviewed protocols)
• Provide examples and simple scenarios where the addressing features are involved
• Define well-know limitations and possible draw-backs in protocol adoption

So far, the only two existing possibilities to use SLP with Java were either to use the OpenSLP Java API or make use of the SLP implementation that ships with Solaris. The former requires an slpd daemon to run on the machine, this is not always possible (e.g. on mobile or embedded devices). The latter has the same limitations and runs only on Solaris hosts. JSP 140 was launched to develop a more usable API for Java but this request has been withdrawn.

SLP limitations: Like any new system, a number of limitations exist with SLP in its current state. Most of these limitations relate to the scalability of the system. SLP adopted many of the scalability features of AppleTalk, while at the same time trying to improve upon AppleTalk's limitations in large network environments. Many of SLP's scalability features, however, have not yet been fully implemented.

Just as AppleTalk defined the concept of a "zone", in which services could be searched for in a hierarchical manner, SLP defines the very similar concept of a "scope." Unfortunately Apple's implementation of scopes in NSL (called "neighborhoods") is somewhat limiting. In Mac OS 9, for example, the scope in which a particular service is registered is usually set to the search domain (from the TCP/IP control panel) for that service's machine. All services without search domains appear in the same, non-hierarchical list.

SLP also attempted to mimic AppleTalk's ability to provide dynamic naming services without need for any centralized name server or other agent. SLP uses a technique known as IP multicast for this purpose. IP multicast requires the cooperation of IP routers, the devices which connect IP subnets together to form intranets. Most current IP routers implement IP multicast, which is used for such features as IP-based audio and video broadcasting and video conferencing. However IP multicasting may not be completely implemented across some intranets. In the absence of IP multicasting, SLP name lookups will only work within the subnet on which they are performed, or within the groups of subnets over which IP multicast is supported.

In large environments, AppleTalk's independence from centralized name servers was sometimes viewed as a limitation. NBP used multicast to enable independence from name servers, and AppleTalk multicasts could propagate throughout the intranet. SLP attempts to improve upon NBP by optionally allowing names servers, called "directory agents" or DA's. DA's minimize the need to use IP multicast, and can result in significantly less traffic than a completely distributed system like NBP. They can also enhance the protocol's hierarchical scope concept, and provide other services. Unfortunately, at the current time, no commercially supported DA is available, so IP multicast must continue to be used. As SLP momentum continues, however, it is expected that DA's will be available in the near future.

Despite its current limitations, SLP remains very useable for specific tasks, such as dynamic service location on all but the largest of intranets. Even within large intranets, SLP should function well for workgroup-specific service location. And as both Apple and third-parties enhance their implementations, most current limitations should soon be eliminated, providing an IP service location system that is just as easy to use as AppleTalk's.

jSLP fills this gap and provides both SLP User Agent (UA) and SLP Service Agent (SA) functionality. It supports peer to peer service discovery via multicast convergence and unicast client server discovery with a Directory Agent (DA) like OpenSLP in the network. Since it is pure Java without any native code parts or system daemons, jSLP can run on mobile devices and might help to build service oriented middleware systems that do not rely on heavyweight XML-based discovery protocols.

• Define and describe available (OS) protocol implementations

There are two versions of jSLP available. The standalone distribution is designed to run with arbitrary Java programs. The OSGi version enables the OSGi framework to locate services via SLP. The recent R-OSGi project integrates jSLP to remotely access OSGi services from distributed OSGi platforms.

Java Management Extensions (JMX, JSP 160 ) defines the integration of JMX and SLP, the examples run with jSLP if the divergences between RFC 2614 and jSLP are regarded.