Proposal for Implementation
of the Service Location Protocol (SLP)
By
Hemali Majithia,
Urvi Shah,
Shamit Patel,
Rajesh Mathew.
Service Location Protocol is an IETF standards track protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks. Traditionally, in order to locate services on the network, users of network applications are required to supply the host name or network address of the machine that supplies a desired service. SLP can eliminate the need for users to know the names of network hosts. With SLP, the user only needs to know the description of the service they are interested in. Based on this description, SLP is then able to return the URL of the desired service.
SLP basically has agents and messages to communicate between them
In SLP an agent is a software entity that process SLP protocol messages. There are three types of SLP agents:
User Agent (UA)
The SLP User Agent is a software entity that is looking for the location of one or more services.
Service Agent (SA)
The SLP Service Agent is a software entity that provides the location of one or more services.
Directory Agent (DA)
The SLP Directory Agent is a software entity that acts as a centralized repository for service location information.
In order to be able to provide a "framework" for service location, SLP agents communicate with each other using eleven (11) different types of messages. The dialog between agents is usually limited to very simple exchanges of request and reply messages.
Service Request (SrvRqst)
Message sent by UAs to SAs and DAs to request the location of a service
Service Reply (SrvRply)
Message sent by SAs and DAs in reply to a SrvRqst. The SrvRply contains the URL of the requested service
Service Registration (SrvReg)
Message sent by SAs to DAs containing information about a service that is available.
Service Deregister (SrvDeReg)
Message sent by SAs to inform DAs that a service is no longer available.
Service Acknowledge (SrvAck)
A generic acknowledgment that is sent as a reply to SrvReg and SrvDeReg messages
Attribute Request (AttrRqst)
Message sent by UAs to request the attributes of a service.
Attribute Reply (AttrRply)
Message sent by SAs and DAs in reply to an AttrRqst. The AttrRply contains the list of attributes that were requested
Service Type Request
(SrvTypeRqst)
Message sent by UAs to SAs and DAs request the types of services that are available
Service Type Reply
(SrvTypeRply)
Message by SAs and Das, in reply to a SrvTypeRqst. The SrvTypeRply contains a list of requested service types.
DA Advertisement (DAAdvert)
Message sent by DAs to let SAs and UAs know where they are
SA Advertisement (SAAdvert)
Message sent by SAs to let UAs know where they are
We will be implementing most of the messages and agents for the project.
Directory Agents can be detected using one of the methods
If there are no Directory Agents, then the User Agent is limited to finding the Service Agents on the same link or adjacent links. This is probably fine for many small installations, but Directory Agents have to be used for scalable application of the Service Location Protocol to larger installations with multiple networks. In the rest of this paper, we assume the existence of Directory Agents.
Service Naming and Handles
When a User Agent wishes to acquire a service handle, it sends the Service Type and a string-based query with the desired attributes in a Service Request. When the Service Reply is returned, it contains a URL (Uniform Resource Locator) pointing to the Service. URLs contain the IP address of the Service Agent, or else its name, which DNS can resolve into an IP address. The URL also contains any other information needed by the User Agent to use the service; for instance, for printers, the queue name would be returned as well as the address of the computer hosting the print service.
Conclusion
Service Location Protocol is a simple, lightweight protocol
for automatic maintenance and advertisement of intranet services. It defines
entities known as User Agents, Service Agents, and Directory Agents, and
defines the protocol operations between them. SLP offers an easily understood
model of service operations, and relieves system administrators of the need to
configure service information in most new user installations. Taking services
offline for routine maintenance, or bringing them back online, can occur with
no reconfiguration needed on user machines.
We intend to complete the design phase of the project by 20th October. The second phase, Implementation will span from October 21st to November 20th. The testing phase start from November 21st.