The Service Location Protocol (SLP) provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration for 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.
Traditionally, users find services by using the name of a network host (a human readable text string), which is an alias for a network address. SLP (Service Location Protocol) eliminates the need for a user to know the name of a network host supporting a service. Rather, the user names the service and supplies a set of attributes, which describe the service. SLP (Service Location Protocol) allows the user to bind this description to the network address of the service.
SLP (Service Location Protocol) provides a dynamic configuration mechanism for applications in local area networks. It is not a global resolution system for the entire Internet; rather it is intended to serve enterprise networks with shared services. Applications are modeled as clients that need to find servers attached to the enterprise network at a possibly distant location. 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.
The basic operation in SLP is that a client attempts to discover the location for a service. In small installations, each service is configured to respond individually to each client. In larger installations, service will register their services with one or more directory agents and clients contact the directory agent to fulfill request for service location information. This is intended to be similar to URL specifications and make user of URL technology.
Protocol Structure
| 8 | 16 | 32 bits |
| Version | Function | Length |
| O M U A F rsvd | Dialect | Language Code |
| Char encoding | XID | |
- Version - The current version is version 1
- Function - The function field describes the operation of the Service location datagram. The following message types exist:
| Function Value | Message Type | Abbreviation |
| 1 | Service Request | SrvReq |
| 2 | Service Reply | SrvRply |
| 3 | Service Registration | SrvReg |
| 4 | Service Deregister | SrvDereg |
| 5 | Service Acknowledge | SrvAck |
| 6 | Attribute Request | AttrRgst |
| 7 | Attribute Reply | AttrRply |
| 8 | DA Advertisement | DAADvert |
| 9 | Service Type Request | SrvTypeRqst |
| 10 | Service Type Reply | SrvTypeRply |
- Length - Number of bytes in the message including the Service location header.
- O - The overflow bit.
- M - The monolingual bit.
- U - RL Authentication bit present.
- A - Attribute authentication bit present.
- F - If the F bit is set in a Service Acknowledgement, the directory agent has registered the service as a new entry.
- Rsvd - These bits are reserved and must have a value of 0.
- Dialect - To be use by future versions of the SLP. Must be set to zero.
- Language Code - The language encoded in this field indicates the language in which the remainder of the message should be interpreted.
- Character Encoding - The characters making up strings within the remainder of this message may be encoded in any standardized encoding
- XID - Transaction Identifier. Allows matching replies to individual requests.
Sponsor Source: SLP is defined by IETF (http://www.ietf.org) RFC2165.
Reference:
http://www.javvin.com/protocol/rfc2165.pdf: Service Location Protocol
