Internet Engineering Task Force Erik Guttman INTERNET DRAFT Category: Standards Track December 18, 2001 Expires in six months Applicability Statement for Service Location Protocol, Version 2 draft-guttman-svrloc-as-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Comments on this document should be sent to the SLP discussion list, srvloc-discuss@lists.sourceforge.net. Internet-Drafts are draft documents of the Internet Engineering Task valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." See http://www.ietf.org/ietf/1id-abstracts.txt. Find shadow directories at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (2001). All Rights Reserved. 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 of network services for network based applications. This document describes the domain for which the protocol applies, in short networks under a common administration, compatibility issues among different versions of the protocol and provides an overview to the various IETF documents which concern the use of SLP. 1. Introduction The Service Location Protocol has been published in three successive versions. Service Location Protocol, Version 1 (SLPv1) [RFC2165] contained excessive functionality, unclear language and errors. Service Location Protocol, Version 2 (SLPv2) [RFC2608] broke binary comptibility with this version of the protocol while retaining the basic mechanisms and data elements. SLPv2 was designed have limited compatibility with SLPv1 through the use of DAs which support both protocols. Significant implementation and deployment experience has informed the current effort to revise SLPv2 so as to remove features which have Guttman, E. Expires: 19 June 2002 [Page 1] Internet Draft SLPv2 Revision December 2001 not been found essential or easy to understand. 2. Domain of Applicability SLP is intended to function within networks under cooperative administrative control. Such networks permit a policy to be implemented regarding security, multicast routing and organization of services and clients into groups which are not be feasible on the scale of the Internet as a whole. SLP has been designed to serve enterprise networks with shared services, and it may not necessarily scale for wide-area service discovery throughout the global Internet, or in networks where there are hundreds of thousands of clients or tens of thousands of services. 3. Backwards Compatibility The Service Location Protocol has been published in two preceding versions as a proposed standard: SLPv1 [RFC 2165] and SLPv2 [RFC 2608]. SLPv1 contained certain errors and features which deployment experience and interoperability testing showed required significant revision. SLPv2 breaks binary compatibility with SLPv1. The basic protocol operations are very similar. DAs have been successfully produced which support both SLPv1 and SLPv2, provided that certain features of SLPv1 are not used. The current revision of SLPv2 retains binary compatibility, but does deprecate some features. This has been done carefully to retain investment in SLPv2 agents even while transitioning to SLPv2bis. - Preserve investment in existing SLPv2 SAs and DAs SLPv2 SAs and DAs implement a superset of the features of SLPv2bis. There is therefore no reason to upgrade existing, deployed SLPv2 DAs and SAs in order to interoperate with newly deployed SLPv2bis agents. - SLPv2bis reduces requirements on SAs Many features of SLP have not proven essential for service discovery. An important use of SLP is in embedded servers for which the minimum feature set is critical given limited server resources. - SLPv2 UAs are compatible with SLPv2bis SAs if properly used SLPv2 UAs implement a superset of functions supported by SLPv2bis SAs. As long as UAs restrict their queries to those supported by SLPv2bis, the UA can obtain the same answer from both SLPv2 and SLPv2bis SAs. Guttman, E. Expires: 19 June 2002 [Page 2] Internet Draft SLPv2 Revision December 2001 3.1 Incompatibility Matrix Incompatibility SLPv1 SLPv2 SLPv2bis --------------- ---------------- ---------------- ------------------ 1) Unscoped Agents treat un- Treat unscoped As SLPv2 SLPv1 scoped as match- requests as Requests ing all scopes. having 'DEFAULT' scope. Recon- figure SLPv1 UAs if possible! 2) Unscoped Accept registra- SLPv2 DAs accept As SLPv2 SLPv1 DAs tions and re- only registra- quests from all tions with >0 scopes. DA scopes. Re- configure SLPv1 SAs if possible! 3) Language Tags may be only Tags may be 2 or As SLPv2 Tag Length 2 bytes long. more characters. If >2 characters SLPv1 UAs will be unable to discover those services. 4) Service Service types Abstract types As SLPv2 Types may only be of are allowed, as the form 'service:x:y'. 'service:x' or These cannot be 'x'. ??? returned to SLPv1 UAs. 5) Message SLPv1 header. SLPv2 header. Exactly as SLPv2. Header Not compatible. 6) Monolingual If not set, No monolingual As SLPv2. bit complicated bit support rules apply exists in SLPV2. toward ignoring language tag matching for queries. 7) Character Character SLPv2 supports As SLPv2. Encoding encoding is the UTF-8 char- explicit in the acter set only. SLPv1 header. 8) URL auth- Indicates a URL This flag is not The flag is not Guttman, E. Expires: 19 June 2002 [Page 3] Internet Draft SLPv2 Revision December 2001 enticator auth block supported. 0 or supported. Auth flag follows. more auth blocks blocks are not supported. supported at all. 9) Attribute Indicates an The flag is not The flag is not Authentica- attribute auth- supported. 0 or supported. Attr tor flag enticator block more auth blocks auth blocks are follows. may follow not supported. attributes. 10) Dialect Reserved. Set SLPv2 has no Exactly as SLPv2. field to 0. dialect field. 11) Multicast This flag is not This flag indi- As SLPv2. Flag present in SLPv1 cates rules to follow in the case of an error or zero results (do not reply). 12) Fresh Flag When this flag When this flag FRESH flag must be is present in a is present in a set, overwriting SrvAck, DA tells SrvReg, the reg- existing regs with the SA a SrvReg istration over- the same URL (in is new, not wri- writes existing the same language). ting over an ex- registrations If not set, the isting entry. with the same result is the URL. When ab- INVALID_UPDATE sent, reg adds error. incrementally to existing regs. 13) Use of XID XID in unsol- XID is set to 0 As SLPv2. icited DAAdverts for unsolicited are used to in- DAAdverts. dicate DA reboot Otherwise XIDs state. are nonzero. Incompatibility SLPv1 SLPv2 SLPv2bis --------------- ---------------- ---------------- ------------------ 14) Messsage SLPv1 defines SLPv2 redefines Exactly as SLPv2. Formats formats for all message framing of formats. messages. 15) Error Codes Defines 0-7 Adds 9-15 No longer send 5-7 as these concern SLP authentication Guttman, E. Expires: 19 June 2002 [Page 4] Internet Draft SLPv2 Revision December 2001 16) Authentica- Algorithms are All algorithms No algorithms are tion blocks defined for redefined for defined for cal- calculation of calculation of culation of digests. digests. digests. 17) Search SLPv1 defines a SLPv2 redefines SLPv2bis uses only filters search filter search filter: a proper subset of format, combin- use LDAPv3 fil- LDAPv3 search fil- ing service type ters, without ters (which simp- scope and filter extensible lifies SA implem- matching rules. entation). 18) Scope as an SLPv1 defines SLPv2 defines As SLPv2. Attribute scope as an scope separately attribute of a as a modifier to service. SLPv2 messages. 19) Reserved SLPv1 reserves SLPv2 does not As SLPv2. strings SCOPE, SERVICE, reserve any LOCAL, REMOTE, words. TRUE and FALSE 20) Required SLPv1 requires UA send SrvRqst, As SLPv2 but messages all messages. receive SrvRply AttrRqst/AttrRply and DAAdvert. is a SHOULD (as SA send SrvReg, most applications SrvRply and SA- of SLP require Advert, receive attributes). SrvRqst, DA- Advert & SrvAck. DAs: no options. 21) Authentic- Use protected Use SLP SPIs, a Do not use SLP tion scope config- separate field authentication. uration. in messages. Omit SLP SPIs! 22) Multicast Use global Use one Admin As SLPv2. group scope group(s), relative address some never except for SLPv2 defined! for IPv6. 23) Wildcards Attribute re- As SLPv1. SLPv2bis does not in attri- quests allow support wildcards bute lists wildcards to be in tag lists of the tag list. AttrRqst messages. 24) Attribute AttrRqst allows As SLPv1. SLPv2bis does not Request by request for all support AttrRqst service attributes of by service type. type services of a Only AttrRqst by given service service URL is Guttman, E. Expires: 19 June 2002 [Page 5] Internet Draft SLPv2 Revision December 2001 type. supported. 25) Scope Priority order Priority order A new, simplified, configura- is given, but is given, but priority order is tion rules not clear. very complex defined. Relies because of RFC on fixes to RFC 2610 'MANDATORY' 2610. flag, which is not clear. 26) Elide Initial and As SLPv1. All strings are spaces final spaces matched as is. in strings are String matches elided in all fail if messages string fields. include extra spaces. 27) Language SLPv1 presents SLPv2 states SLPv2bis states Tag match only an ISO subtags MAY the entire tag 636 tag. be ignored. must match (with case insensitive matching). 3.2 Requirements for SLPv2 UAs to interoperate with SLPv2bis In order to guarantee interoperability into the future, SLPv2bis UAs will use a new API which do not expose features which have been deprecated in SLPv2. SLPv2 UAs have to restrict their use of certain feature which are exposed, or they will only get results if there is a DA which supports those features present in the network, or SAs with full SLPv2 support. These features include: 1. Do not use language tags with subtags unless that is really desired. Note that English "en" does not match British English "en-BR". Use 'en' if possible to represent English. 2. Send Attribute Requests by URL only (not by service type). 3. Do not include wildcards in tag lists in Attribute Requests. 4. Send only 'simple' search filters (no logical OR or NOT, only a single comparison term or a conjoined list of comparison terms.) 5. Do not be lazy about preceding and trailing white space. Only Guttman, E. Expires: 19 June 2002 [Page 6] Internet Draft SLPv2 Revision December 2001 include it in requests if it should be there. 6. Do not expect Authentication Blocks or SLP SPI strings. In addition SLPv2 SAs MUST restrict themselves in the following ways: 1. Always set FRESH bit on registration. 2. Do not use language tags with subtags unless that is really desired. Note that English 'en' does not match British English "en-BR". Use 'en' if possible to represent English. 3. Do not send tag lists in SrvDereg messages. 4. Do not be lazy about preceding and trailing white space. Only include it in attribute lists, for example, if it should be there. 5. Do not send Authentication Blocks or SLP SPI strings. 3.3 Subtleties and Gotchas The following topics need to be considered: - Apps may require complex search filters. Describe options. - New DAs MUST support old features. Specify them. 4. Other Documents Concerning SLP Several IETFT working groups have defined ways to use SLP to discover services. [AAA] [TRIP] [RFC3105] [RFC3049] [IPS] External standards organizations and consortia are also specifying how to use SLP. [SALUTATION] [IEEE] [DMTF] The following RFCs augment the base SLPv2bis protocol [RFC2608bis]: [RFC2609] "Service Templates and service: schemes" - Standards Track Defines the Service: URL scheme and how to define and use service templates. Service templates allow interoperability through the use of common registered descriptions of services. [RFC2610] "DHCP Options for Service Location" - Standards Track DHCP option 78 configures SLP agents with DA addresses. Option 79 configures a SLP agent with a scope list. Note that this document has been revised for republication, correcting some errors found in the current document. [RFC2610bis] [RFC2614] "An API for Service Location" - Informational Guttman, E. Expires: 19 June 2002 [Page 7] Internet Draft SLPv2 Revision December 2001 This document describes an abstract, C and Java API to expose the functions of SLP to applications in a well known, protable manner. This document will be revised to accomodate change in SLPv2. The Java portion of the document will be published externally as part of a JSR [JSR]. [RFC2926] "Conversion of LDAP Schema to and from SLP Templates" - Informational This document describes conversion of schema to templates or the reverse. [RFC3059] "Attribute List Extension for the Service Location Protocol" - Standards Track This extension allows a UA to obtain the list of attributes associated with a service advertisement in a SrvRply message. This saves an extra round trip (AttrRqst/AttrRply) and elimates a potential race condition where a service is discovered but its attributes change or it is deregistered before its attributes can be obtained. [RFC3089] "Notification and Subscription for SLP" - Experimental This mechanism allows scalable dynamic discovery of services, through the use of multicast announcements in the form of SrvReg messages, if there are subscribers. [RFC3111] "SLPv2 Modifications for IPv6" - Standards Track This document describes the few change in SLPv2 which are required to support the protocol over IPv6. [VENDOR] This document updates SLPv2, describing the vendor extension mechanisms. These provide an open ended set of practices which will not generate name collisions in the future (so they are safe). At the same time, this approach will not lead to interoperability, so it is discouraged. 5. Security Considerations This document describes the relation between different versions of SLP. Where security features of the protocol have changed, this has been noted. The most important 6. Acknowledgements The author wishes to thank the contributions through the years of the SVRLOC WG and the SRVLOC discussion list. I am grateful to my employers who have supported this work: FTP Software, Peer Logic, Oracle and Sun Microsystems. Guttman, E. Expires: 19 June 2002 [Page 8] Internet Draft SLPv2 Revision December 2001 References [DIAMETER] [DMTF] [IANA] http://www.iana.org/numbers.html [IEEE] [IPS] [IPTEL] [JSR] [mSLP] [RFC 2165] Veizades, et. al, "Service Location Protocol", RFC 2165, July 1997. [RFC 2608] E. Guttman, et. al, "Service Location Protocol version 2", RFC 2608, June 1999. [RFC2608bis] Guttman, E, Kempf, J., "Service Location Protocol, Version 2", draft-guttman-svrloc-rfc2608bis-01.txt, December 2001, a work in progress. [RFC 2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 1999. [RFC 2610] Perkins, C., Guttman, E., "DHCP Options for Service Location", RFC 2610, June 1999. [RFC 2610bis] Guttman, E., "DHCP Options for Service Location", draft- guttman-svrloc-rfc2610bis-01.txt, September 2001. A work in progress. [RFC2614] Kempf, J., Guttman, E., "An API for Service Location", RFC 2614, June 1999. [RFC2926] Kempf, J., et. al. "Conversion of LDAP Schema to and from SLP Templates", RFC 2926, September 2000. [RFC3049] Naugle, J., et. al., "TN3270E Service Location and Session Balancing", RFC 3049, January 2001. [RFC3059] Guttman, E., "Attribute List Extension for the Service Location Protocol", RFC 3059, February 2001. [RFC3089] Kempf, J., Goldschmidt, J., "Notification and Subscription for Guttman, E. Expires: 19 June 2002 [Page 9] Internet Draft SLPv2 Revision December 2001 SLP", RFC 3082, March 2001. [RFC3105] Kempf, J., Montenegro, G., "Finding an RSIP Server with SLP", RFC 3105, October 2001. [RFC3111] Guttman, E., "SLPv2 Modifications for IPv6", RFC 3111, May 2001. [SALUTATION] [VENDOR] Guttman, E., "Vendor Extensions for SLPv2", draft-guttman- svrloc-vendor-ext-07.txt, a work in progress. Author's Contact Information Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany erik.guttman@sun.com Guttman, E. Expires: 19 June 2002 [Page 10]