RFC 2165
SERVICE LOCATION PROTOCOL (SLP)

Presented by: Yang Cao

Why SLP?

* The Service Location Protocol allows the user to bind the description of 
  a service to the network address of the service.
* SLP eliminates the need for a user to know the name of a network host 
  supporting the service.
* Client can dynamically formulate requests for services that are resolved 
  differently depending upon the circumstances.
* SLP provides a dynamic configuration mechanism for applications in LANs, 
  it's not a global resolution system for the entire Internet

Terminology

* Service information
  A collection of attributes and configuration information associated with
  a single service.
* User Agent (UA)
  A process working on a user's behalf to acquire service attributes and 
  configuration
* Service Agent (SA)
  A process working on the behalf of one or more services to advertise service
  attributes and configuration
* Directory Agent (DA)
  A process which collects information from Service Agents to provide a single
  centralized repository of service information
* Naming Authority
  The agency or group which catalogues given service types and attributes. 
  It defaults to IANA
* Predicate
  A boolean expression of attributes, relations and logical operators, used to
  find services which satisfy particular requirements

Protocol Transactions

     +----------------+   we want this info:	    +-----------+
     |  Application   | ------------------------->  |  Service  |
     +----------------+                             +-----------+
           /|\                                       |         |
            |                            +-----------+         |
            |                            |                     |
           \|/                          \|/                   \|/
   +----------------+             +-----------+     +----------------------+  
   |  User Agent    |<----------->|  Service  |     |       Service        |
   +----------------+             |   Agent   |     |      Agent which 	   |
            |                     +-----------+     |      does not reply  |
            |                            |          |      to UA requests  |
            |                           \|/         +----------------------+
            |                        +-------------+                  |
            +----------------------->|  Directory  |<-----------------+
                                     |    Agent    |
                                     +-------------+     _____________
                                        /|\             / Many other  \
                                         +------------>|   SA's        |
                                                        \_____________/

The basic operation in Service Location is that a client wants to discover 
the location of a service. 

User Agent 
UA operates in two modes:
* Unicast
  If the User Agent has obtained the location of a Directory Agent, the User
  Agent will unicast a request to the Directory Agent.
* Multicast
  If the User Agent doesn't have knowledge of a Directory Agent or if there 
  are no Directory Agents available, the User Agent multicasts a request to 
  the service-specific multicast address.

Service Agent
* listens for multicast requests on the service-specific multicast address, 
  and responds if the request can be satisfied 
* registers with an available Directory Agent.  Service Registrations include 
  a lifetime.  Service Registrations need to be refreshed by the Service Agent
  before their lifetime runs out. 
* deregisters the service with the Directory Agent when the service becomes 
  unavailable

Directory Agent
* must first be discovered by UA or SA.
  FOUR WAYS TO DISCOVER DA:
        using DHCP if UA or SA supports it 
        UA or SA sending out a Directory Agent Discovery request
	DA sending an unsolicited DA Advertisement
        manual configuration.
* resolves requests from User Agents which are unicasted using TCP or UDP. 
* responds SA with an acknowledgment to either a registration or 
  deregistration of  services.  

Schemes

The service URL scheme is used to specify a service location.
 	"service:" URL scheme
Service Types are named as: 
        "service:" scheme name
Service Types are used by SAs to register and deregister Services with DAs. 
It is also used by SAs and DAs to return Service Replies to UAs.

Service Location Scaling and Scopes

When there are several Directory Agents, the services advertised by these DAs
are collected together into logical groups called scopes. 

Three distinct modes: * requires no DA and is intended for a LAN * requires a DA (or DAs) to run, but does not use scope. This mode scales well to a group of interconnected LANs with a limited number of hosts. * The third mode with DAs and scopes allows SLP to be used in an internetworked campus environment. Rules dealing with scopes: Service Agent: * All Service Registrations that have a scope must be registered with all DAs of that scope which have been or are subsequently discovered. * Service Agents MUST register with unscoped DAs even if they are configured to specifically register with DAs that have a specific scope or set of scopes. * Service Registrations that have no scope are only registered with unscoped DAs. User Agents * User Agents make requests of DAs whose scope they are configured to use. * User Agents MAY query DAs without scopes, even if they are configured to use DAs with a certain scope. * Scoped User Agents SHOULD always use a DA that supports their configured scope when possible instead of an unscoped DA to prevent the unscoped DAs from becoming overused. * UAs that issue unscoped requests will discover only unscoped services. Directory Agents * If scoped DAs are used, they will not accept unscoped registrations or requests. * any DA with no scope will have all the available service information.

Service Location General Message Format

Message Header Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Version   |   Function    |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |O|M|U|A|F|rsvd |  Dialect    |     Language Code             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Char Encoding         |         XID                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Function Service Location datagrams can be identified as to their operation 
by the function field.
 
              
Message Type		Abbreviation		Function Value
Service Request		SrvReq			1
Service Reply		SrvRply			2
Service Registration	SrvReg			3
Service Deregister 	SrvDereg	        4
Service Acknowledge	SrvAck			5
Attribute Request	AttrRqst		6
Attribute Reply		AttrRply 		7
DA Advertisement	DAAdvert		8
Service Type Request	SrvTypeRqst		9
Service Type Reply	SrvTypeRply		10

Individual Message Types:
1) Service Request Message
	Function:
		A UA uses Service Request to obtain URLs from a 
		Directory Agent or Service Agent. 
		Without configured knowledge of a DA, a UA or SA also 
		uses a Service Request to discover a DA by specifying 
		the Service Type as "directory agent". 
	Two ways that UA form Service Requests:
	A) Using preconfigured knowledge of a Service Type's Attributes
	B) Issuing Attribute Requests to obtain the attribute values 
	   for a Service Type
	Fields:
	Previous responder list string, Previous responder's address 
	specification, length of predicate string, service request predicate.
	General form of Service request predicates:
		[.]/[]/[predicate]/
	Example of Service Request predicate: 
	lpr//(& (PAGE PER MINUTE==12)
	(UNRESTRICTED_ACCESS)
	(LOCATION==12 th FLOOR))/ 

2) Service Reply Message 
	Function: 
		Normally, Service Request returns a Service Reply
		One exception: service request for the service type 
		"directory-agent" is answered with a DA Advertisement. 
	Message Fields:
		Error code, URL entry count, URL entry list
	Error code:
		0 success
		LANGUAGE_NOT_SUPPORTED
		PROTOCOL_PARSE_ERROR
		SCOPE_NOT_SUPPORTED
		CHARSET_NOT_UNDERSTOOD
3) Directory Agent Advertisement Message
	Message Fields:
		error code, length of URL, URL, length of scope list, 
		scope list
4) Attribute Request Message
	Function:
		Is sent by a User Agent to obtain the attribute values for 
		a Service Type
	Message Fields:
		length of previous responders list string, 
		previous responders address specification, length of URL, 
		URL, length of scope, scope, length of select list, 
		select list 
5) Attribute Reply Message 
	Message Fields: 
		error code, length of attribute list, attribute list
6) Service Type Request Message
        Function:
		is used by UA to determine all the types of services 
		supported on a network.
	Message Fields:length of previous responders string, 
		previous responders address specification, 
		length of naming authority, naming authority, 
		length of scope string, scope string 
7) Service Type Reply Message 
	Message Fields:Error code, number of service types, length of 
		       service type string list, service type string list
8) Service Registration Message
	Function:
		Is sent by SA to register with DA after DA is discovered.
	Message Fields: 
		URL entry, length of attribute list,  attribute list
	Example:
		Lifetime: 10800
		URL:        service:lpr//ignore.wco.ftp.com:515/draft
		Attributes: (SCOPE=DEVELOPMENT),
			      (PAPER COLOR=WHITE),
			      (PAPER SIZE=LETTER),
			       UNRESTRICTED_ACCESS,
                              (LOCATION=12th FLOOR), ...
 9) Service Deregister Message
	Function: 
		Is sent by a Service Agent to Directory Agent when a service 
		is no longer available for use
 	Message Fields:length of URL, URL of service to deregister, 
			authentication block, length of  string, 
			
10) Service Acknowledgement Message
	Function:
		Is sent as the result of a DA receiving and processing 
		a Service Registration or Service Deregistration.
	Message Field: error code
 	Error code:
		0       success
		PROTOCOL_PARSE_ERROR
		INVALID_REGISTRATION
		SCOPE_NOT_SUPPORTED
		CHARSET_NOT_UNDERSTOOD
		AUTHENTICATION_ABSENT
		AUTHENTICATION_FAILED	

Updated on April 24, 1998 by ycao@monet.vill.edu.