[attachment=1132]
CS2K707(P) Seminar Report on
SERVICE LOCATION PROTOCOL
Submitted In Partial Fullment Of The Degree OfBachelor Of Technology
By
DEEPTI TOORY
1.367,S7 CSE
Department of Computer Science & EngineeringNational Institute of Technology, Calicut2004 Monsoon
National Institute of Technology, Calicut
Department of Computer Science & Engineering

Abstract:
The service location protocol provides a scalable framework for the discovery andselection of network services. Using this protocol, computers using the internet need littleor no static conguration for network services for network based applications. This isespecially important as computers become more portable, and users less tolerant or ableto fulll the demands of network system administration


.Contents1 Introduction 11.1 SERVICE LOCATION PROTOCOL . . . . . . . . . . . . . . . . . . . . . . . . 11.2 APPLICATIONS IN LOCAL AREA NETWORKS . . . . . . . . . . . . . . . . 12 SLP TERMINOLOGY 23 SERVICE INFORMATION AND PREDICATE REPRESENTATION 34 SPECIFICATION LANGUAGE 35 SLP IMPLEMENTATION 36 OPERATION OF SLP 47 USE OF PORTS, UDP AND MULTICASTS 48 USE OF TCP 59 RETRANSMISSION OF SLP MESSAGES 610 STRINGS IN SLP MESSAGES 611 ERRORS 712 SERVICE REQUEST 713 SERVICE REPLY 914 SERVICE REGISTRATION 915 SERVICE DEREGISTRATION 1016 SERVICE DISCOVERY USING SLP 1117 ADDITIONAL FEATURES 1218 CONCLUSION 13ii1 Introduction1.1 SERVICE LOCATION PROTOCOLTraditionally, users and services by using the name of a network host (a human readable textstring) which is an alias for a network address. The Service Location Protocol eliminates theneed for a user to know the name of a network host supporting a service. Rather, the user namesthe service and supplies a set of attributes which describe the service. The Service LocationProtocol allows the user to bind this description to the network address of the service.[5]1.2 APPLICATIONS IN LOCAL AREA NETWORKSService Location Protocol provides a dynamic conguration mechanism for applications in localarea networks. It is not a global resolution system for the entire Internet; rather it is intendedto serve enterprise networks with shared services. Applications are modeled as clients that needto and servers attached to the enterprise network at a possibly distant location. For cases wherethere are many dierent clients and/or services available, the protocol is adapted to make useof nearby Directory Agents that o
er a centralised repository for advertised services.[3]12 SLP TERMINOLOGYUser Agent (UA):-A process working on the user's behalf to acquire service attributes and con
guration. TheUser 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 andcon
guration.Directory Agent (DA):-A process which collects information from Service Agents to provide a single repository of serviceinformation in order to centralize it for e
cient access by User Agents. There can only beone DA present per given host.Service Information:-A collection of attributes and conguration information associated with a single service. TheService 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 isaccessed 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 NamingAuthority is IANA, the Internet Assigned Numbers Authority.Attribute:-A (class, value-list) pair of strings describing a characteristic of a service. The value string maybe 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 appropriatefor reaching all hosts within a site. If the site does not support multicast, the agent'ssite network is restricted to a single subnet.Address Speci
cation:-This is the network layer protocol dependent mechanism for specifying an agent. For Internetsystems this is part of a URL (Universe resource locator). [1].23 SERVICE INFORMATION AND PREDICATE REPRESENTATIONService information is represented in a text format. The goal is that the format be human readableand transmissible via email. The location of network services is encoded as a UniversalResource Locator (URL) which is human readable. Only the datagram headers are encoded ina form which is not human readable. Strings used in the Service Location Protocol are NOTnull-terminated.Predicates are expressed in a simple boolean notation using keywords, attributes, and logicalconnectives.The logical connectives and subexpressions are presented in pre
x-order, so that the connectivecomes
rst and the expressions it operates on follow afterwards. [1].4 SPECIFICATION LANGUAGEIn this document, several words are used to signify the requirements of the speci
cation. Thesewords are:-MUST:- This word, or the adjective "required", means that the de
nition is an absoluterequirement of the speci
cation.MUST NOT:- This phrase means that the de
nition is an absolute prohibition of the speci
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 andcarefully 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 setof alternatives. An implementation which does not include this option MUST be prepared tointeroperate 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 capabilityof logging the error, including the contents of the discarded datagram, and SHOULDrecord the event in a statistics counter. [3].5 SLP IMPLEMENTATIONA minimal implementation may consist of either a UA or SA both. The only required featuresof a UA are that it can issue SrvRqsts (service requests) according to the rules below andinterpret DAAdverts, SAAdverts and SrvReply (service reply) messages. The UA MUST issue3requests to DA's as they are discovered. An SA MUST reply to appropriate SrvRqsts withSrvRply 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. AUA that does not know of any DA's SHOULD retry DA discovery, increasing teh waitinginterval 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 SLPThe basic operation of SLP is that a client attempts to discover the location for a service. Insmall installations, each service is con
gured to respond individually to each client. In largerinstallations, service will register their services with one or more directory agents and clientscontact the directory aent to ful
ll request for service location information. This is intended tobe 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 UAsunicast their requests to a DA. SAs listen for these multicast requests to the UA if it hasadvertised the requested service. In the absence of a DA, UAs repeatedly multicast the same request they would have unicastto. 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 announcementssent by DAs, all messages in SLP are requests taht elicit responses. By default, SLP agentssend all messages in UDP datagrams. TCP is used only to send messages that don't
tin a single datagram. [2], [4].7 USE OF PORTS, UDP AND MULTICASTSDA's MUST accept unicast requests and multicast directory agent discovery service requests(forthe service type "service:directory-agent").// SA's MUST accept multicast requests and unicastrequests 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 toSA'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 aresent to the port from which the request was issued. The default maximum transmission unit forUDP messages is 1400 bytes excluding UDP and other headers. If a SLP message does not
tinto a UDP datagram it MUST be truncated to
t, and the OVERFLOW ag is set in the replymessage. A UA which receives a truncated message MAY open a TCP connection with the DAor SA and retransmit the request, using the same XID. It MAY also attempt to make use ofthe 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 address,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 SHOULDand DAs MUST listen for broadcast Service Location messages at port 427. This allows UAswhich 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 anetwork, and localizes service information in the network. [1].8 USE OF TCPA SrvReg or SrvDeReg may be too large to
t into a datagram. To send such large SLP messages,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 ifthey 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 resultincluded, 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 ofattributes and the number of authenticators transmitted. DAs MUST be able to respond to UDP and TCP requests, as well as multicast DADiscovery SrvRqsts. SAs MUST be able to respond to TCP unless the SA will NEVERreceive a request or send a reply which will exceed a datagram in size (e.g., some embeddedsystems). A TCP connection MAY be used for a single SLP transaction, or for multiple transactions.Since there are length
elds in the message headers, SLP Agents can send multiplerequests along a connection and read the return stream for acknowledgments and replies.The initiating agent SHOULD close the TCP connection. The DA SHOULD wait atleast CONFIG CLOSE CONN seconds before closing an idle connection. DAs and SAsSHOULD close an idle TCP connection after CONFIG CLOSE CONN seconds to ensurerobust operation, even when the initiating agent neglects to close it. [1].59 RETRANSMISSION OF SLP MESSAGESRequests which fail to elicit a response are retransmitted. The initial retransmission occursafter a CONFIG RETRY wait period. Retransmissions MUST be made with exponentiallyincreasing wait intervals (doubling the wait each time). This applies to unicast as well as multicastSLP requests.Unicast requests to a DA or SA should be retransmitted until either a response (which mightbe an error) has been obtained, or for CONFIG RETRY MAX seconds.Multicast requests SHOULD be reissued over CONFIG MC MAX seconds until a result hasbeen 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 areunicast, 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 beelicited or the previous responder list and the request will not
t into a single datagram or untilCONFIG MC MAX seconds elapse.UAs which retransmit a request use the same XID. This allows a DA or SA to cache its replyto the original request and then send it again, should a duplicate request arrive. This cachedinformation should only be held very brie y. XIDs SHOULD be randomly chosen to avoidduplicate XIDs in requests if UAs restart frequently. [4].10 STRINGS IN SLP MESSAGESThe escape character is a backslash (UTF-8 0x5c) followed by the two hexadecimal digits ofthe escaped character. Only reserved characters are escaped. For example, a comma (UTF-80x29) is escaped as `9', and a backslash is escaped as `c'. String lists used in SLP de
ne thecomma to be the delimiter between list elements, so commas in data strings must be escaped inthis manner. Backslashes are the escape character so they also must always be escaped whenincluded in a string literally. String comparison for order and equality in SLP MUST be caseinsensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds to ASCII characterencoding). Case insensitivity SHOULD be supported throughout the entire UTF-8 encodedUnicode [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 handling,language tags, previous responder lists. Comparisons of URL strings, however, is casesensitive. White space (SPACE, CR, LF, TAB) internal to a string value is folded to a singleSPACE character for the sake of string comparisons. White space preceding or following astring 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 orderingin 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 indicatesubstring matching. The query including this character matches any character sequence6which conforms to the letters which are not wildcarded. [1].11 ERRORSIf 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 theyresult in an error.LANGUAGE NOT SUPPORTED = 1: There is data for the service type in the scope in theAttrRqst 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 omittedLanguage 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 unsupportedSLP SPI.AUTHENTICATION ABSENT = 6: The DA expected URL and ATTR authentication in theSrvReg and did not receive it.AUTHENTICATION FAILED = 7: The DA detected an authentication error in an Authenticationblock.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 themandatory range.INVALID UPDATE = 13: The DA received a SrvReg without FRESH set, for an unregisteredservice or with inconsistent Service Types. [1] and [4].MSG NOT SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst and does notsupport it.REFRESH REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a DA more frequentlythan the DA's min-refresh-interval.12 SERVICE REQUESTIn 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, thelanguage of the request (ignoring the dialect part of the Language Tag) must match the advertisedservice. [1].h PRListi is the Previous Responder List. This h string-listi contains dotted decimal notationIP (v4) addresses, and is iteratively multicast to obtain all possible results. UAs SHOULDimplement this discovery algorithm. SAs MUST use this to discover all available DAs in their7scope, if they are not already con
gured with DA addresses by some other means. A SA silentlydrops all requests which include the SA's address in the h PRListi. An SA which has multiplenetwork interfaces MUST check if any of the entries in the h PRListi equal any of its interfaces.An entry in the PRList which does not conform to an IPv4 dotted decimal address isignored: 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 algorithmis not intended to
nd all instances; it
nds 'enough' to provide useful results. The h scopelistiis a h string-listi of con
gured scope names. SAs and DAs which have been con
guredwith any of the scopes in this list will respond. DAs and SAs MUST reply to unicast requestswith a SCOPE NOT SUPPORTED error if the h scope-listi is omitted or fails to include ascope they support. Normally, a SrvRqst elicits a SrvRply. There are two exceptions: If theh service-typei is set to "service:directory-agent", DAs respond to the SrvRqst with a DAAdvert.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 LDAPv3search
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 toeach 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 registrationof (x=1,2,3); "(!(Y=0))" matches (y=0,1) since Y can be nonzero. Note the matchingis 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 attributein 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 bedone with the '='
lter. In any other case, a PARSE ERROR is returned. Request terms whichinclude wildcards are interpreted to be Strings. That is, (x=34*) would match 'x=34foo', butnot 'x=3432' since the
rst value is a String while the second value is an Integer; Strings don'tmatch 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=DEFAULTh pi= (empty string) This is a minimal request string. It matches all http services advertisedwith the default scope. h ti=service:pop3 h si=SALES,DEFAULT h pi=(user=wump). Thisis a request for all pop3 services available in the SALES or DEFAULT scope which serve mailto the user `wump'. hti = service : backuph si=BLDG 32 p((q3)(speed1000)) This returns thebackup service which has a queue length less than 3 and a speed greater than 1000. It willreturn this only for services registered with the BLDG 32 scope. h ti=service:directory-agenth si=DEFAULT h pi= This returns DAAdverts for all DAs in the DEFAULT scope. DAs arediscovered by sending a SrvRqst with the service type set to "service:directory-agent". If apredicate is included in the SrvRqst, the DA SHOULD respond only if the predicate can besatis
ed with the DA's attributes. The h scope-listi MUST contain all scopes con
gured forthe UA or SA which is discovering DAs. The h SLP SPIi string indicates a SLP SPI that therequester has been con
gured with. If this string is omitted, the responder does not includeany Authentication Blocks in its reply. If it is included, the responder MUST return a replywhich has an associated authentication block with the SLP SPI in the SrvRqst. If no repliesmay be returned because the SLP SPI is not supported, the responder returns an AUTHENTICATIONUNKNOWN error.813 SERVICE REPLYThe service reply contains zero or more URL entries. A service reply with zero URL entriesMUST 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 broadcastservice 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 obtainedby SLP may not be cached longer than lifetime seconds, unless there is a URL Authenticatorblock present. In that case, the cache lifetime is indicated by the timestamp in the URL Authenticator.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. [1].14 SERVICE REGISTRATIONThe 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 onceper second). The lifetime MAY be set to any value between 0 and 0x

(maximum, around18 hours). Long-lived registrations remain stale longer if the service fails and the SA does notderegister the service.The h service-typei de
nes the service type of the URL to be registered, regardless of thescheme of the URL. The h scope-listi MUST contain the names of all scopes con
gured forthe 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 andY and there are three DAs, whose scopes are "X", "Y" and "X,Y" respectively, the SA willregister the with all three DAs in their respective scopes. All future updates and deregistrationsof the service must be sent to the same set of DAs in the same scopes the service was initiallyregistered in. Theh attr-listi, if present, speci
es the attributes and values to be associatedwith the URL by the DA.A SA con
gured with the ability to sign service registrations MUST sign each of the URLs andAttribute Lists using each of the keys it is con
gured to use, and the DA it is registering withaccepts. (The SA MUST acquire DAAdverts for all DAs it will register with to obtain the DA'sSLP SPI list and attributes. The SA supplies a SLP SPI in each authentication block indicatingthe SLP SPI con
guration required to verify the digital signature. Subsequent registrations ofpreviously registered services MUST contain the same list of SLP SPIs as previous ones or elseDAs will reject them, replying with an AUTHENTICATION ABSENT error. A registrationwith the FRESH ag set will replace *entirely* any previous registration for the same URL inthe same language. If the FRESH ag is not set, the registration is an "incremental" registration.[4].915 SERVICE DEREGISTRATIONA DA deletes a service registration when its Lifetime expires. Services SHOULD be deregisteredwhen 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 acknowledgmentindicating success, the service and/or attributes are no longer advertised by the DA. The DAderegisters the service or service attributes from every scope speci
ed in the SrvDeReg whichit was previously registered in. The SA MUST deregister all services with the same scope listused to register the service with a DA. If this is not done in the SrvDeReg message, the DAreturns a SCOPE NOT SUPPORTED error. The Lifetime
eld in the URL Entry is ignoredfor the purposes of the SrvDeReg. The h tag-listi is a h string-listi of attribute tags to deregister.If no h tag-listi is present, the SrvDeReg deregisters the service in all languages it has beenregistered in. If the h tag-listi is present, the SrvDeReg deregisters the attributes whose tagsare listed in the tag spec. Services registered with Authentication Blocks MUST NOT include ah tag-listi in a SrvDeReg message: A DA will respond with an AUTHENTICATION FAILEDerror in this case. If the service to be deregistered was registered with an authentication blockor blocks, a URL authentication block for each of the SLP SPIs registered must be includedin the SrvDeReg. Otherwise, the DA returns an AUTHENTICATION ABSENT error. If themessage fails to be veri
ed by the DA, an AUTHENTICATION FAILED error is returned bythe DA. [3].1016 SERVICE DISCOVERY USING SLPService discovery is an essential step in mobile computing if a user owning a wirelessly connecteddevice 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 Protocolis fairly capable. It does not only allow simple matching for equality or pre
xes of names, butalso allows a comparisons with mathematical operators such as "", "", which is particularlyintresting when used with location based services. We
nd this to be one of the most importantrequirements for query language features employed in service discovery. By using this querylanguage we can easily search for services within a given area, if for example, services are storedwith geodesic coordinates representing their exact location. Wild card searches for substringsusing the "*" operator, allow us to query for services located in a certain area, described forexample by the street name they are located on. Another handy set of features taht the querylanguage supports are logical disjunctions and conjections, allowing an e
ective an e
ective
ltering query to be executed. [3].1117 ADDITIONAL FEATURESSECURITY:-SLP is designed to make service information available, and it contains no mechanisms to restrictaccess to this information. Its only security property is authentication of the source ofinformation, which prevents SLP from being used to maliciously propagate false informationabout the location of services. [4].DIGITAL SIGNATURE:-An SA can include a digital signature produced with public key cryptography along with itsregistration messages. A DA can then verify the signature before registering or deregisteringany service information on the SAs behalf. These digital signatures are then forwarded in replymessages to UAs, so they can reject unsigned or incorrectly signed service information. Ofcourse, DAs and UAs can only verify signaturs, not produce them. [4].1218 CONCLUSIONThe SLP provides the authentication of service agents as part of the scope mechanism andconsequently, integrity of data received as part of such registration. SLP does not providecon
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 lowerbandwidth in the case of with DAs. However, SLP is only a string based protocol for discoverypurposes which does not address communication among the desegrated devices. Since theobjective of this protocol is to advertise services to a community of users, con
dentiality mightnot generally be needed. When this protocol is used in non-sensitive environments. Specialisedschemes 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: RFC2165. July 2001.14