[attachment=1156]

---

SERVICE LOCATION PROTOCOL

Seminar Report on SERVICE LOCATION PROTOCOL
Presented by:DEEPTI TOOR
Department of Computer Science & Engineering
National Institute of Technology, Calicut
Monsoon National Institute of Technology, Calicut
ABSTRACT
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 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..

INTRODUCTION
1.1 SERVICE LOCATION PROTOCOL
Traditionally, users and services by using the name of a network host (a human readable text string) which is an alias for a network address. The 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. The Service Location Protocol allows the user to bind this description to the network address of the service.
1.2 APPLICATIONS IN LOCAL AREA NETWORKS
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 nd 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.
12 SLP TERMINOLOGY
User Agent (UA):-
A process working on the user's behalf to acquire service attributes and configuration. The User Agent retrives service information from the Service Agents or Directory Agents.
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 repository of service information in order to centralize it for efficient access by User Agents. There can only be one DA present per given host.
Service Information:-
A collection of attributes and con guration information associated with a single service. The Service Agents advertise service information for a collection of service instances. Service:-
The service is a process or system providing a facility to the network. The service itself is accessed using a communication mechanism external to the Service Location Protocol.
Service Type:-
Each type of service has a unique Service Type string. The Service Type de nes a template, called a "Service Scheme", including expected attributes, values and protocol behaviour.
Naming Authority:-
The agency or group which catalogues given Service Types and Attributes. The default Naming Authority is IANA, the Internet Assigned Numbers Authority.
Attribute:-
A (class, value-list) pair of strings describing a characteristic of a service. The value string may be interpreted as a boolean , integer or opaque value if it takes speci c forms.
Predicate:-
A boolean expression of attributes, relations and logical operators. The predicate is used to nd services which satisfy particular requirements.
Site Network:-
All the hosts accessible within the Agents's multicast radius, which defaults to a value appro- priate for reaching all hosts within a site. If the site does not support multicast, the agent's site network is restricted to a single subnet. Address Specification:-
This is the network layer protocol dependent mechanism for specifying an agent. For Internet systems this is part of a URL (Universe resource locator).
23 SERVICE INFORMATION AND PREDICATE REP-
RESENTATION
Service information is represented in a text format. The goal is that the format be human read- able and transmissible via email. The location of network services is encoded as a Universal Resource Locator (URL) which is human readable. Only the datagram headers are encoded in a form which is not human readable. Strings used in the Service Location Protocol are NOT null-terminated.
Predicates are expressed in a simple boolean notation using keywords, attributes, and logi- cal connectives. The logical connectives and subexpressions are presented in pre x-order, so that the connective comes rst and the expressions it operates on follow afterwards.
4 SPECIFICATION LANGUAGE
In this document, several words are used to signify the requirements of the speci cation. These words are:-
MUST:- This word, or the adjective "required", means that the de nition is an absolute requirement of the speci cation.
MUST NOT:- This phrase means that the de nition is an absolute prohibition of the spec- i cation.
SHOULD:- This word, or the adjective recommended, means that, in some circumstances, valid reasons may exist to ignore this item, but the full implications must be understood and carefully weighted before choosing a di erent course. Unexpected results may result otherwise.
MAY:- This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does not include the option. Silently Discard:- The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the ca- pability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter. [3].
5 SLP IMPLEMENTATION
A minimal implementation may consist of either a UA or SA both. The only required features of a UA are that it can issue SrvRqsts (service requests) according to the rules below and interpret DAAdverts, SAAdverts and SrvReply (service reply) messages. The UA MUST issue 3requests to DA's as they are discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or SAAdvert messages. The SA MUST also register with DA's as they are discovered. UA's perform discovery by issuing Service Request messages. SrvRqst messages are issued, using UDP, following these prioritised rules: A UA issues a request to a DA which it has been con gured with by DHCP.
A UA issues requests to DA's which it has been statically con gured with. UA uses multicast/convergence SrvRqsts to discover DA's, then uses that set of DA's. A UA that does not know of any DA's SHOULD retry DA discovery, increasing teh waiting interval between subsequent attempts exponentially (doubling the wait interval each time). The recommended minimum waiting interval is CONFI DA FIND seconds. A UA with no knowledge of DA's sends requests using multicast convergence to SA's. SA's unicast replies to UA's according to the multicast convergence algorithm. [2].
6 OPERATION OF SLP
The basic operation of SLP is that a client attempts to discover the location for a service. In small installations, each service is con gured 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 aent to ful ll request for service location information. This is intended to be similar to URL speci cations and make user of URL technology.
SLP has two modes of operations:-
When a DA is present, it collects all the service information advertised by SAs, and UAs unicast their requests to a DA. SAs listen for these multicast requests to the UA if it has advertised the requested service. In the absence of a DA, UAs repeatedly multicast the same request they would have unicast to. When a DA is present, UAs receive faster responses, SLP uses less network bandwidth, and fewer(or zero) multicast messages are issued. Aside from unsolicited announcements sent by DAs, all messages in SLP are requests taht elicit responses. By default, SLP agents send all messages in UDP datagrams. TCP is used only to send messages that don't t in a single datagram. [2], [4].
7 USE OF PORTS, UDP AND MULTICASTS
DA's MUST accept unicast requests and multicast directory agent discovery service requests(for the service type "service:directory-agent").// SA's MUST accept multicast requests and uni- cast requests both. The SA can distinguish between them by whether the REQUEST MCAST ag is set in the SLP Message header. The Service Location Protocol uses multicast for discovering DA's and for issuing requests to SA's by default.
The reserved listening port for SLP is 427. This is the destination port for all SLP messages. 4SLP messages MAY be transmitted on an ephemeral port. Replies and acknowledgements are sent to the port from which the request was issued. The default maximum transmission unit for UDP messages is 1400 bytes excluding UDP and other headers. If a SLP message does not t into a UDP datagram it MUST be truncated to t, and the OVERFLOW ag is set in the reply message. A UA which receives a truncated message MAY open a TCP connection with the DA or SA and retransmit the request, using the same XID. It MAY also attempt to make use of the truncated reply or reformulate a more restrictive request which will result in a smaller reply. SLP Requests messages are multicast to The Administratively Scoped SLP Multicast ad- dress, which is 239.255.255.253. The default TTL use for multicast is 255. In isolated networks, broadcasts will work in place of multicast. To that end, SAs SHOULD and DAs MUST listen for broadcast Service Location messages at port 427. This allows UAs which do not support multicast the use of Service Location on isolated networks. Setting multicast TTL to less than 255 (the default) limits the range of SLP discovery in a network, and localizes service information in the network. [1].
8 USE OF TCP
A SrvReg or SrvDeReg may be too large to t into a datagram. To send such large SLP mes- sages, a TCP (unicast) connection MUST be established. To avoid the need to implement TCP, one MUST ensure that: - UAs never issue requests larger than the Path MTU. SAs can omit TCP support only if they never have to receive unicast requests longer than the path MTU. UAs can accept replies with the 'OVERFLOW' ag set, and make use of the rst result included, or reformulate the request. - Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in a single datagram. This means limiting the size of URLs, the number of attributes and the number of authenticators transmitted. DAs MUST be able to respond to UDP and TCP requests, as well as multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP unless the SA will NEVER receive a request or send a reply which will exceed a datagram in size (e.g., some embedded systems). A TCP connection MAY be used for a single SLP transaction, or for multiple transac- tions. Since there are length elds in the message headers, SLP Agents can send multiple requests along a connection and read the return stream for acknowledgments and replies. The initiating agent SHOULD close the TCP connection. The DA SHOULD wait at least CONFIG CLOSE CONN seconds before closing an idle connection. DAs and SAs SHOULD close an idle TCP connection after CONFIG CLOSE CONN seconds to ensure robust operation, even when the initiating agent neglects to close it.
59 RETRANSMISSION OF SLP MESSAGES
Requests which fail to elicit a response are retransmitted. The initial retransmission occurs after a CONFIG RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). This applies to unicast as well as mul- ticast SLP requests. Unicast requests to a DA or SA should be retransmitted until either a response (which might be an error) has been obtained, or for CONFIG RETRY MAX seconds. Multicast requests SHOULD be reissued over CONFIG MC MAX seconds until a result has been obtained. UAs need only wait till they obtain the rst reply which matches their request. That is, retransmission is not required if the requesting agent is prepared to use the ' rst reply' instead of 'as many replies as possible within a bounded time interval'. When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, they contain a h PRListi of previous responders. Initially the h PRListi is empty. When these requests are unicast, the h PRListi is always empty. Any DA or SA which sees its address in the h PRListi MUST NOT respond to the request. The message SHOULD be retransmitted until the h PRListi causes no further responses to be elicited or the previous responder list and the request will not t into a single datagram or until CONFIG MC MAX seconds elapse. UAs which retransmit a request use the same XID. This allows a DA or SA to cache its reply to the original request and then send it again, should a duplicate request arrive. This cached information should only be held very brie y. XIDs SHOULD be randomly chosen to avoid duplicate XIDs in requests if UAs restart frequently.
10 STRINGS IN SLP MESSAGES
The escape character is a backslash (UTF-8 0x5c) followed by the two hexadecimal digits of the escaped character. Only reserved characters are escaped. For example, a comma (UTF-8 0x29) is escaped as `9', and a backslash is escaped as `c'. String lists used in SLP de ne the comma to be the delimiter between list elements, so commas in data strings must be escaped in this manner. Backslashes are the escape character so they also must always be escaped when included in a string literally. String comparison for order and equality in SLP MUST be case insensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds to ASCII character encoding). Case insensitivity SHOULD be supported throughout the entire UTF-8 encoded Unicode [6] character set. The case insensitivity rule applies to all string matching in SLPv2, including Scope strings, SLP SPI strings, service types, attribute tags and values in query han- dling, language tags, previous responder lists. Comparisons of URL strings, however, is case sensitive. White space (SPACE, CR, LF, TAB) internal to a string value is folded to a single SPACE character for the sake of string comparisons. White space preceding or following a string value is ignored for the purposes of string comparison. For example, " Some String " matches "SOME STRING".
String comparisons (using comparison operators such as `' or `') are done using lexical ordering in UTF-8 encoded characters, not using any language speci c rules. The reserved character `*' may precede, follow or be internal to a string value in order to in- dicate substring matching. The query including this character matches any character sequence 6which conforms to the letters which are not wildcarded.
11 ERRORS
If the Error Code in a SLP reply message is nonzero, the rest of the message MAY be truncated. No data is necessarily transmitted or should be expected after the header and the error code, except possibly for some optional extensions to clarify the error. Errors are only returned for unicast requests. Multicast requests are silently discarded if they result in an error.
LANGUAGE NOT SUPPORTED = 1: There is data for the service type in the scope in the AttrRqst or SrvRqst, but not in the requested language.
PARSE ERROR = 2: The message fails to obey SLP syntax.
INVALID REGISTRATION = 3: The SrvReg has problems { e.g., a zero lifetime or an omitted Language Tag.
SCOPE NOT SUPPORTED = 4: The SLP message did not include a scope in its h scope-listi supported by the SA or DA.
AUTHENTICATION UNKNOWN = 5: The DA or SA receives a request for an unsupported SLP SPI.
AUTHENTICATION ABSENT = 6: The DA expected URL and ATTR authentication in the SrvReg and did not receive it.
AUTHENTICATION FAILED = 7: The DA detected an authentication error in an Authenti- cation block.
VER NOT SUPPORTED = 9: Unsupported version number in message header.
INTERNAL ERROR = 10: The DA (or SA) is too sick to respond.
D BUS NOW = 11: UA or SA SHOULD retry, using exponential back o
.
OPTION NOT UNDERSTOOD = 12: The DA (or SA) received an unknown option from the mandatory range.
INVALID UPDATE = 13: The DA received a SrvReg without FRESH set, for an unregistered service or with inconsistent Service Types. [1] and [4].
MSG NOT SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst and does not support it.
REFRESH REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a DA more fre- quently than the DA's min-refresh-interval.
12 SERVICE REQUEST
In order for a Service to match a SrvRqst, it must belong to at least one requested scope, support the requested service type, and match the predicate. If the predicate is present, the language of the request (ignoring the dialect part of the Language Tag) must match the adver- tised service.
h PRListi is the Previous Responder List. This h string-listi contains dotted decimal notation IP (v4) addresses, and is iteratively multicast to obtain all possible results. UAs SHOULD implement this discovery algorithm. SAs MUST use this to discover all available DAs in their 7scope, if they are not already con gured with DA addresses by some other means. A SA silently drops all requests which include the SA's address in the h PRListi. An SA which has multiple network interfaces MUST check if any of the entries in the h PRListi equal any of its inter- faces. An entry in the PRList which does not conform to an IPv4 dotted decimal address is ignored: The rest of the h PRListi is processed normally and an error is not returned. Once a h PRListi plus the request exceeds the path MTU, multicast convergence stops. This algorithm is not intended to nd all instances; it nds 'enough' to provide useful results. The h scope- listi is a h string-listi of con gured scope names. SAs and DAs which have been con gured with any of the scopes in this list will respond. DAs and SAs MUST reply to unicast requests with a SCOPE NOT SUPPORTED error if the h scope-listi is omitted or fails to include a scope they support. Normally, a SrvRqst elicits a SrvRply. There are two exceptions: If the h service-typei is set to "service:directory-agent", DAs respond to the SrvRqst with a DAAd- vert. If set to "serviceervice-agent", SAs respond with a SAAdvert. If this eld is omitted, a PARSE ERROR is returned - as this eld is REQUIRED. The h predicatei is a LDAPv3 search lter. This eld is OPTIONAL. Services may be discovered simply by type and scope. Otherwise, services are discovered which satisfy the h predicatei. If present, it is compared to each registered service. If the attribute in the lter has been registered with multiple values, the lter is compared to each value and the results are ORed together, i.e., "(x=3)" matches a reg- istration of (x=1,2,3); "(!(Y=0))" matches (y=0,1) since Y can be nonzero. Note the matching is case insensitive. Keywords (i.e., attributes without values) are matched with a "presence" lter, as in "(keyword=*)". An incoming request term MUST have the same type as the at- tribute in a registration in order to match. Thus, "(x=33)" will not match ' x=true', etc. while "(y=foo)" will match 'y=FOO'. "(|(x=33)(y=foo))" will be satis ed, even though "(x=33)" cannot be satis ed, because of the `|' (boolean disjunction). Wildcard matching MUST be done with the '=' lter. In any other case, a PARSE ERROR is returned. Request terms which include wildcards are interpreted to be Strings. That is, (x=34*) would match 'x=34foo', but not 'x=3432' since the rst value is a String while the second value is an Integer; Strings don't match Integers. Examples of Predicates follow. h ti indicates the service type of the SrvRqst, h si gives the h scope-listi and h pi is the predicate string. h ti=service:http h si=DEFAULT h pi= (empty string) This is a minimal request string. It matches all http services advertised with the default scope. h ti=service:pop3 h si=SALES,DEFAULT h pi=(user=wump). This is a request for all pop3 services available in the SALES or DEFAULT scope which serve mail to the user `wump'. hti = service : backuph si=BLDG 32 p((q3)(speed1000)) This returns the backup service which has a queue length less than 3 and a speed greater than 1000. It will return this only for services registered with the BLDG 32 scope. h ti=service:directory-agent h si=DEFAULT h pi= This returns DAAdverts for all DAs in the DEFAULT scope. DAs are discovered by sending a SrvRqst with the service type set to "service:directory-agent". If a predicate is included in the SrvRqst, the DA SHOULD respond only if the predicate can be satis ed with the DA's attributes. The h scope-listi MUST contain all scopes con gured for the UA or SA which is discovering DAs. The h SLP SPIi string indicates a SLP SPI that the requester has been con gured with. If this string is omitted, the responder does not include any Authentication Blocks in its reply. If it is included, the responder MUST return a reply which has an associated authentication block with the SLP SPI in the SrvRqst. If no replies may be returned because the SLP SPI is not supported, the responder returns an AUTHEN- TICATION UNKNOWN error.
813 SERVICE REPLY
The service reply contains zero or more URL entries. A service reply with zero URL entries MUST be returned in response to a unicast Service Request, if no matching URLs are present. A service reply with zero URL entries MUST NOT be sent in response to a multicast or broad- cast service request (instead, if there was no match found or an error processing the request, the service reply should not be generated at all). If the reply over ows, the UA MAY simply use the rst URL Entry in the list. A URL obtained by SLP may not be cached longer than lifetime seconds, unless there is a URL Authenticator block present. In that case, the cache lifetime is indicated by the timestamp in the URL Au- thenticator. An authentication block is returned in the URL Entries, including the SLP SPI in the SrvRqst. If no SLP SPI was included in the request, no Authentication Blocks are returned in the reply. URL Authentication Blocks are de ne in later section.
14 SERVICE REGISTRATION
The h entryi is a URL Entry. The lifetime de nes how long a DA can cache the registration. SAs SHOULD reregister before this lifetime expires (but SHOULD NOT more often than once per second). The lifetime MAY be set to any value between 0 and 0x (maximum, around 18 hours). Long-lived registrations remain stale longer if the service fails and the SA does not deregister the service. The h service-typei de nes the service type of the URL to be registered, regardless of the scheme of the URL. The h scope-listi MUST contain the names of all scopes con gured for the SA, which the DA it is registering with supports. The default value for the h scope-listi is "DEFAULT". The SA MUST register consistently with all DAs. If a SA is con gured with scopes X and Y and there are three DAs, whose scopes are "X", "Y" and "X,Y" respectively, the SA will register the with all three DAs in their respective scopes. All future updates and deregistrations of the service must be sent to the same set of DAs in the same scopes the service was initially registered in. Theh attr-listi, if present, speci es the attributes and values to be associated with the URL by the DA. A SA configured with the ability to sign service registrations MUST sign each of the URLs and Attribute Lists using each of the keys it is configured to use, and the DA it is registering with accepts. (The SA MUST acquires DAAdverts for all DAs it will register with to obtain the DA's SLP SPI list and attributes. The SA supplies a SLP SPI in each authentication block indicating the SLP SPI configuration required to verify the digital signature. Subsequent registrations of previously registered services MUST contain the same list of SLP SPIs as previous ones or else DAs will reject them, replying with an AUTHENTICATION ABSENT error. A registration with the FRESH ag set will replace *entirely* any previous registration for the same URL in the same language. If the FRESH ag is not set, the registration is an "incremental" registration.
915 SERVICE DEREGISTRATION
A DA deletes a service registration when its Lifetime expires. Services SHOULD be deregis- tered when they are no longer available, rather than leaving the registrations to time out. [3]. The h scope-listi is a h string-listi. The SA MUST retry if there is no response from the DA. The DA acknowledges a SrvDeReg with a SrvAck. Once the SA receives an acknowledgment indicating success, the service and/or attributes are no longer advertised by the DA. The DA deregisters the service or service attributes from every scope speci ed in the SrvDeReg which it was previously registered in. The SA MUST deregister all services with the same scope list used to register the service with a DA. If this is not done in the SrvDeReg message, the DA returns a SCOPE NOT SUPPORTED error. The Lifetime eld in the URL Entry is ignored for the purposes of the SrvDeReg. The h tag-listi is a h string-listi of attribute tags to deregis- ter. If no h tag-listi is present, the SrvDeReg deregisters the service in all languages it has been registered in. If the h tag-listi is present, the SrvDeReg deregisters the attributes whose tags are listed in the tag spec. Services registered with Authentication Blocks MUST NOT include a h tag-listi in a SrvDeReg message: A DA will respond with an AUTHENTICATION FAILED error in this case. If the service to be deregistered was registered with an authentication block or blocks, a URL authentication block for each of the SLP SPIs registered must be included in the SrvDeReg. Otherwise, the DA returns an AUTHENTICATION ABSENT error. If the message fails to be veri ed by the DA, an AUTHENTICATION FAILED error is returned by the DA.
1016 SERVICE DISCOVERY USING SLP
Service discovery is an essential step in mobile computing if a user owning a wirelessly con- nected device enters a new environment and wants to use services in the surrounding area. In our scenario we decided to use SLP as a service discovery protocol for a di erent reasons. First, SLP is an open standard. Second, the query language of the Service Location Protocol is fairly capable. It does not only allow simple matching for equality or pre xes of names, but also allows a comparisons with mathematical operators such as "", "", which is particularly intresting when used with location based services. We nd this to be one of the most important requirements for query language features employed in service discovery. By using this query language we can easily search for services within a given area, if for example, services are stored with geodesic coordinates representing their exact location. Wild card searches for substrings using the "*" operator, allow us to query for services located in a certain area, described for example by the street name they are located on. Another handy set of features taht the query language supports are logical disjunctions and conjections, allowing an e ective an e ective ltering query to be executed.
1117 ADDITIONAL FEATURES
SECURITY:-
SLP is designed to make service information available, and it contains no mechanisms to re- strict access to this information. Its only security property is authentication of the source of information, which prevents SLP from being used to maliciously propagate false information about the location of services.
DIGITAL SIGNATURE:-
An SA can include a digital signature produced with public key cryptography along with its registration messages. A DA can then verify the signature before registering or deregistering any service information on the SAs behalf. These digital signatures are then forwarded in reply messages to UAs, so they can reject unsigned or incorrectly signed service information. Of course, DAs and UAs can only verify signaturs, not produce them. [4].
18 CONCLUSION
The SLP provides the authentication of service agents as part of the scope mechanism and consequently, integrity of data received as part of such registration. SLP does not provide con dentiality. In this paper two architectures were discussed- with DAs and without DAs. The advantages of SLP are that it is simple to implement, OS independent and uses lower bandwidth in the case of with DAs. However, SLP is only a string based protocol for discovery purposes which does not address communication among the desegrated devices. Since the objective of this protocol is to advertise services to a community of users, con dentiality might not generally be needed. When this protocol is used in non-sensitive environments. Specialised schemes might be able to provide con dentiality, if needed in future.
13References
[1] S., Breger, H., Schulzrrinne, S., Sidiroglou and X. Wu. Ubiquitous computing using SIP.
Communication of ACM. June 2003, California.
[2] E., Guttman. Service Location Protocol: Automatic Discovery of IP Network Services.
IEEE Internet Computing. July/August 1999. http://computerinternet/.
[3] http://javvinprotocol/rfc2165.pdf.
[4] A., MacWilliams, T., Reicher, and B., Bruegge. IEEE distributed systems online, 2004.
[5] J., Guttman, Veizades, E., Perkins, C and S Kaplan. Service Location Protocol: RFC
2165. July 2001.
14