Internet DRAFT - draft-guttman-svrloc-as
draft-guttman-svrloc-as
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]
