draft-ietf-svrloc-protocol-10.txt John Veizades
INTERNET-DRAFT TGV, Inc.
Scott Kaplan
Erik Guttman
Charles Perkins
IBM Research
February 1, 1996
Service Location Protocol
1.0 Status of this memo
This draft document is a product of the IETF Service Location Working
Group; it will be submitted to the RFC editor as a standards document.
Please respond with comments to the srvloc@tgv.com mailing list.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or
"work in progress."
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
2.0 Abstract
The service location protocol provides a framework for the discovery
and selection of network services. It relies on multicast support at
the network layer of the protocol stack it is using. It does not
specifically rely upon the TCP/IP protocol stack but makes use of
concepts that are found in most TCP/IP protocol implementations.
Traditionally, users find services 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
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.
Service Location provides a dynamic configuration mechanism for
applications in a tightly coupled set of local area networks. It is
not a global resolution system for the entire Internet, rather it is
intended to serve institutional networks with shared services.
Service Location WG
Expires August 1, 1996 [Page 1]
INTERNET-DRAFT Service Location Protocol February-96
Table of Contents
1.0 Status of this memo..............................................1
2.0 Abstract.........................................................1
3.0 Notation Conventions.............................................3
4.0 Terminology......................................................3
5.0 Protocol Overview................................................5
5.1 Protocol Transactions........................................5
5.2 Service and Predicate Representation.........................6
5.3 Additional Notes.............................................6
5.3.1 Interpretation of Service Location Replies............6
5.3.2 Use of TCP and Multicast in Service Location..........7
5.3.3 Multiligual Support...................................7
5.3.4 Standard Attribute Definitions........................7
5.3.5 Naming Authority......................................7
5.4 Service Location PDU header..................................8
5.4.1 Version...............................................8
5.4.2 Functions.............................................8
5.4.3 Length................................................8
5.4.4 Error Codes...........................................9
5.4.5 Transaction Identifier (XID)..........................9
5.4.6 Flags.................................................9
5.4.7 Time To Live..........................................9
5.4.8 Character Encoding....................................9
5.4.9 Language Code........................................10
5.5 Service Request and Reply...................................10
5.6 Directory Agent Discovery Request...........................13
5.7 Scheme Request..............................................14
5.8 Attribute Request and Attribute Reply.......................15
5.9 Service Discovery Request...................................16
6.0 Directory Agents................................................17
6.1 Introduction................................................17
6.2 Directory Agent Discovery...................................18
6.3 Service Registration........................................19
6.4 Service Unregister..........................................21
6.5 SCOPE Discovery and Use.....................................22
6.6 Service Location Scaling and Operating Modes................24
7.0 Server Location Connections.....................................24
8.0 Security Considerations.........................................25
9.0 Multicast vs. Broadcast.........................................25
9.1 Single Subnet...............................................25
9.2 Multiple Subnets............................................25
9.3 Service Multicast Address...................................26
10.0 Service Location in the Internet...............................26
11.0 Protocol Formats...............................................26
11.1 Fields Used in Service Location Packets....................26
11.1.1 Previous Responders' Address Specification..........26
11.1.2 Service Request Predicate...........................27
11.1.3 Reply...............................................30
11.1.4 Service Registration Information....................30
11.1.5 Service Unregister Information......................30
11.1.6 Attribute List......................................30
Veizades, Kaplan, Guttman, Perkins [Page 2]
INTERNET-DRAFT Service Location Protocol February-96
11.1.7 Service Scheme......................................31
11.2 ADDRESS SPECIFICATIONs in Service Location.................31
11.3 Attribute Value encoding rules.............................32
12.0 Implementation Requirements....................................33
13.0 Interesting Constants..........................................34
14.0 Acknowledgments................................................35
15.0 References.....................................................35
16.0 Author's Addresses.............................................37
17.0 Document Expiration............................................37
Appendix A - Technical contents of ISO 639:1988.....................38
3.0 Notation Conventions
<> Values set off in this manner are fully described in section
10.0.
In General, all definitions of items in packets are described in
section 10.0.
| |
\ \ Packet layouts with this notation indicate a variable length
| | field.
4.0 Terminology
User Agent (UA) A process working on the user's behalf to
acquire service attributes and configuration.
The User Agent retrieves service information
from the Service Agents.
Service Agent (SA) A process working on the behalf of one or more
services to advertise service attributes and
configuration.
Service Application A process working on behalf of one or more
services to advertise service attributes and
configuration. Unlike an SA the application
will not directly respond to service queries
and will merely register with Directory Agents.
Service Information A collection of attributes and configuration
information associated with a single service.
The Service Agents advertise service
information for a collection of service
instances.
Veizades, Kaplan, Guttman, Perkins [Page 3]
INTERNET-DRAFT Service Location Protocol February-96
Service The service is a process or system providing a
facility to the network. The goal of service
location is to provide sufficient information
to the user, via the User Agent, to find the
service. The service itself in a context
outside of the service location protocol.
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.
Scheme Each type of service has a unique scheme. The
Scheme defines a template including expected
attributes, values and protocol behavior.
Naming Authority The agency or group which catalogues
given Schemes and Attributes. The default
Naming Authority is IANA. Otherwise the
scheme of the service has the Naming Authority
appended to the end, following a '.'
separator.
Attribute A {class, value} pair describing a
characteristic of a service. Note that a
class is a string and the value can be of
four types: integer, string, boolean and
opaque. The service information advertised
by a Service Agent may include more than one
value per class.
Keyword A string describing a characteristic of a
service. The service information advertised
by a Service Agent may include more than one
keyword, and they may appear in any order. In
this document, Keywords may be used as well as
Attributes in most situations; a Keyword may
be considered an Attribute that only names a
class and requires no values.
Predicate A boolean expression of attributes, relations
and logical operators. The predicate is used
to find services which satisfy particular
requirements. See section 11.1.2.
Scope A collection of systems, networks and other
network components that make up a logical
group. See section 6.5 and 6.6.
Veizades, Kaplan, Guttman, Perkins [Page 4]
INTERNET-DRAFT Service Location Protocol February-96
Campus A campus is a collection of networks, hosts
and related network infrastructure that is
grouped together for geographical or political
reasons.
Agent's Internet All the hosts accessible within the Agent's
multicast radius. If the network does not
support multicast, the agent's internet is
defined by its broadcast radius. The
discovery method used by the service location
protocol requires these techniques to start up
and provide stable operation. Servers outside
of the Agent's radius are considered "outside
of the user's internet."
Address Specification This is the network layer protocol dependent
mechanism for specifing an User Agent. For
Internet systems this is a URL (Universal
Resource Locator see RFC 1738).
5.0 Protocol Overview
5.1 Protocol Transactions
The following describes the operations an User Agent employs to find
services on the attached Internet. The User Agent does not need any
configuration to begin network interaction. The User Agent may build
on the information received in earlier network requests to find the
Service Agents advertising service information, and subsequently the
terms used to describe services that it is interested in. The User
Agent can use this information to construct predicates which describe
the services that match the user's needs.
A User Agent will operate two ways: If the User Agent has already
obtained the location of a Directory Agent, the User Agent will unicast
a request to it, in order to resolve a particular request. The
Directory Agent will unicast a reply to the User Agent. The User Agent
will retry a request to a Directory Agent till it gets a reply, so if
the Directory Agent cannot service the request (say it has no
information) it must return an response with zero values, possibly with
an error code set.
If the User Agent does not have knowledge of a Directory Agent or if
there are no Directory Agents available on the User Agent's internet,
a second mode of discovery is used. The User Agent multicasts a
request to the service multicast address, which the service it wishes
to locate will respond to. All the Service Agents which are listening
to this multicast address will respond, provided they can satisfy the
User Agent's request. Service Agents which have no information for the
User Agent DO NOT respond. This will cause an 'implosion' of
responses.
Veizades, Kaplan, Guttman, Perkins [Page 5]
INTERNET-DRAFT Service Location Protocol February-96
In the case where the User Agent wishes to obtain a complete answer,
an enumeration of ALL services which satisfy the query, there is a
retransmission/convergence algorithm. The User Agent resends the
request, together with a list of previous responders. Only those
Service Agents which are not on the list respond. Once there are no
new responses to the request the accumulation of responses is deemed
complete.
It is important to stress that while the multicast/convergence model
may be important for discovering services (such as Directory Agents) it
is the exception rather than the rule. Once a User Agent knows of
the location of a Directory Agent, it will use a unicast
request/response transaction.
A service is advertised by an application which registers the service
information with a Directory Agent. This Directory Agent will resolve
requests from User Agents as described above. This means that a
Directory Agent must first be discovered, using the multicast mechanism
described above. If the service is to become unavailable, it should
be unregistered with the Directory Agent. The Directory Agent responds
with an acknowledgment to either a registration or unregistration.
The Service Agent or Application must register with an available
Directory Agent. The Service Agent must additionally listen for
multicast requests on the service specific multicast address.
Service Applications will fail in an internet where there are no
Directory Agents. Service Applications are present in this protocol
to provide a lightweight service registration mechanism.
5.2 Service and Predicate Representation
Service information is represented in a text format. The goal is that
the format be human readable and transmittable via email. The location
of network services is encoded as a Universal Resource Locator (URL)
which is also human readable and well defined. Only the datagram
headers are in an encoded form which is not human readable.
5.3 Additional Notes
5.3.1 Interpretation of Service Location Replies
Replies should be considered to be valid at the time of delivery. The
service may, however, fail or change between the time of the reply and
the moment an application seeks to make use of the service. The
application making use of service location must be prepared for the
possibility that the service information provided is either stale or
incomplete. In the case where the service information provided does
not allow an User Agent to connect to a service as desired, the request
may be resubmitted.
Veizades, Kaplan, Guttman, Perkins [Page 6]
INTERNET-DRAFT Service Location Protocol February-96
5.3.2 Use of TCP and Multicast in Service Location
The service location protocol requires the implementation of
connectionless and a connection oriented transport protocols. The
latter is used for bulk transfer, only when necessary. Connections
are always initiated by an agent request or registration, not by a
replying Directory Agent.
The Service Location discovery mechanisms use internetwork wide
multicast. The protocol will operate in a broadcast environment
with limitations detailed in section 9.0.
5.3.3 Multiligual Support
All Service Registrations declare the language in which the strings in
the service attributes are written, by specifying the appropriate code
in the packet header. For each language the Service advertises a
separate registration takes place. The Service needs to be unregisted
only once since the information associated with it will be unique.
There can only be one service of a given type at a given URL reference,
even if it is registered in multiple languages.
All Service Requests specify a requested language in the packet header.
The Directory Agent or Service Agent will respond in the same language
as the request, if it has a registration in the same language as the
request. If this language is not supported, a reply can be sent in the
default language (which is English.) If the 'monolingual bit' flag in
the header is set and the requested language is not supported, no reply
is returned: Instead a SrvAck with the same XID and the error field
set to LANGUAGE_NOT_SUPPORTED is returned.
5.3.4 Standard Attribute Definitions
Service schemes used with the service location protocol must describe
the following:
Scheme of the service
Mutlicast address, if used
Attributes (Tag and values)
Attribute Descriptions and interpretations
Service schemes defined outside of the IANA standardization process
will use their own Naming Authority string and, possibly, a multicast
address from the unassigned range.
5.3.5 Naming Authority
The Naming Authority of a service defines the semantic meaning of the
scheme and attributes registered with and provided by Service Location.
The Naming Authority itself is a string which uniquely identifies an
organization. If no string is provided IANA is the default.
Veizades, Kaplan, Guttman, Perkins [Page 7]
INTERNET-DRAFT Service Location Protocol February-96
Naming Authorities may define Service schemes which are experimental,
proprietary or for private use. The procedure to use is to create a
'unique' Naming Authority string and then specify the Standard
Attribute Definitions as described above. This Naming Authority will
accompany registration and queries, as described below.
5.4 Service Location PDU header
NOTE: The following header is used in all of the packet descriptions
below and is abbreviated by using "Service location header" followed by
the function being used.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version = 1 | function | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |O|M| flags | char encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Code | Reserved (Language Dialect) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.1 Version
This protocol document defines version 1 of the service location
protocol.
5.4.2 Functions
Service location datagrams can be identified as to their operation by
the function field. The following are the defined operations:
Packet Type Abbreviation Function Value
Service Request SrvRqst 1
Service Reply SrvRply 2
Service Registration SrvReg 3
Service Unregister SrvUnreg 4
Service Acknowledge SrvAck 5
Attribute Request AttrRqst 6
Attribute Reply AttrRply 7
5.4.3 Length
The length is the number of bytes after the Service Location PDU
Header.
Veizades, Kaplan, Guttman, Perkins [Page 8]
INTERNET-DRAFT Service Location Protocol February-96
5.4.4 Error Codes
Errors are only valid in reply and service acknowledgment datagrams.
Replies that completed successfully should have a zero value for the
error code.
5.4.5 Transaction Identifier (XID)
The XID (transaction ID) field allows the requester to match replies
to individual requests. A Service Reply will contain the same XID as
the Service Request. A Service Acknowledge will contain the same XID
as the Service Register or Unregister.
Retransmission of the same service location datagram should not contain
an updated XID. The requester creates the XID from an initial random
seed and increments it by one for each request it makes. The XIDs will
eventually wrap back to zero and continue incrementing from there.
If a Service Agent or Application detects a change in the XID in an
unsolicited advertisement of a Directory Agent, it can assume that the
Direcotory Agent has rebooted and has reset its state. The Service
must reregister at this time.
5.4.6 Flags
The flags field is a bit field. Bit 0 is the 'Overflow bit.' See
Section 7.0 for a complete description for the use of this field. Bit
1 is the 'Monolingual bit.' Requests with this bit set indicate that
the User Agent will only accept responses in the language that is
indicated by the Service or Attribute Request. Replies in other
languages should not be sent for this request. All other bits must be
set to zero.
5.4.7 Time to Live
The TTL field is set to the number of minutes the reply can be cached
by any intermediary service. A value of 0 means the information must
not be cached.
5.4.8 Character Encoding
The encoding will determine the interpretation of all character data
which follows. There is no way to mix ASCII and UNICODE, for example.
Values for character encoding can be found in the Internet Assigned
Numbers Authority's (IANA) database
http://www.isi.edu/in-notes/iana/assignments/character-sets and have
the values refered by the MIBEnum value.
Veizades, Kaplan, Guttman, Perkins [Page 9]
INTERNET-DRAFT Service Location Protocol February-96
5.4.9 Language Code
The language code (see Appendix A) is encoded in this field. All
strings within the packet which follows are to be interpreted in this
language.
The language dialect field is reserved for future use.
5.5 Service Request and Reply
The Service Request is used to obtain nearly all information in the
Service Location Protocol. It is a general mechanism for delivering
a query to a Directory Agent or Service Agents. Depending on the
format of the query, different information can be obtained. There are
four applied types of the Service Query: Directory Agent Discovery
Request, Scheme Request, Services Discovery Request and Service
Attributes Request. These are described in the sections which follow.
There is an additional mechanism for determining the range of service
attributes. This is the Attribute Request. It is used to obtain the
tags and values of attributes which will be used to formulate Service
Discovery Requests. The Attribute Request and Attribute Reply will
be described later.
While all of these types of queries may be useful, the only one which
is essential is the Service Discovery Request. If a User Agent has
enough a priori knowledge of what it is looking for it can simply
issue a Service Discovery Request and be done with it. The point of
the other requests is to allow a User Agent to formulate a query when
it has limited or no a priori knowledge of the services available and
their attributes.
The Service Request allows the User Agent to specify the Scheme of the
service and a Predicate in a specific language. The general form of a
Service Request is shown below:
SCHEME[.NAMING AUTHORITY]:/SCOPE/SELECT CLAUSE/WHERE CLAUSE/
Briefly, the SCHEME of the service is a unique service type name. The
NAMING AUTHORITY determines the semantic interpretation of the SCHEME
and the attributes used in the SELECT and WHERE CLAUSE. The SCOPE is
used for range of the query (SCOPEs are determined administratively,
not by network topology as will be described later.) The SELECT CLAUSE
determines what attribute anmd keyword information to return with the
reply. The WHERE CLAUSE determines which services fit the request.
In the case of a multicast request, a list of previous responders is
sent. This list will prevent those in the list from responding, to
be sure that responses from other sources are not drowned out. The
request is multicast repeatedly (with a recommended wait interval of
a second) until there are no new responses, or a certain time has
elapsed. The User Agent may configure a certain 'time out' duration
Veizades, Kaplan, Guttman, Perkins [Page 10]
INTERNET-DRAFT Service Location Protocol February-96
for example, with the Service Location implementation or in the case
where the User Agent doesn't need ALL the replies, as when any one
service will do.
In order for a request to succeed in matching registered information
4 conditions must be met:
(1). The result must have the same scheme as in the request.
(2). It must have the same Naming Authority.
(3). It must have the same Scope.
(4). The conditions specified in the WHERE CLAUSE must match the
attributes and keywords registered for the service.
The format of the Service Request is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = SrvRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|number of previous responders |<Previous Responders Addr Spec>|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Previous Responders Addr Spec> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Request Predicate> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Request
User Agent requests that are generated by a genesis event, i.e., the
rebooting of a system, loading of the network kernel, etc. should be
sent after a random interval between 0 and 5 seconds.
Veizades, Kaplan, Guttman, Perkins [Page 11]
INTERNET-DRAFT Service Location Protocol February-96
The general form of an individual reply is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of URL string | <URL String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <URL String>, Continued. \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Attributes String | <Attributes String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Attributes String>, Continued. \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The URL string conforms to RFC 1738. If the service scheme does not
have a standardized representation, the minimal requirement is:
SCHEME:/ ADDRESS SPECIFICATION /
The reply will always contain the Scheme and the ADDRESS SPECIFICATION.
The Keywords and Attributes String may not be included, if there were
no attributes returned as the result of the query. Attributes are
included in the reply depending on the "select clause" of the query.
A NULL "SELECT CLAUSE" will not include any attribute information. A
LIST selection will specify which attributes to return information
about. A WILD selection will return information about all attributes.
(See Section 5.7.)
If attributes are returned the string takes the form (with arbitrarily
many attributes and values):
(ATTR1 = VAL),(ATTR2 = VAL1, VAL2), (KEYWORD)
The TTL in the header should be set to a value no greater than the
shortest TTL of the list of services in the reply.
Veizades, Kaplan, Guttman, Perkins [Page 12]
INTERNET-DRAFT Service Location Protocol February-96
The format of a Service Reply is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = SrvRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of replies returned | <Reply 1> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Reply 1> (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
\ . \
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Reply N> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Reply
5.6 Directory Agent Discovery Request
Without a priori knowledge of a Directory Agent (DA), a User Agent,
Service Application or Service Agent uses a Service Request to discover
a DA. (See section 6.1 for a priori mechanisms for knowledge of a DA.)
This request is generated by the User Agent or Service Agent or Service
Application in order to discover a Directory Agent. This is a normal
Service Request. The request string takes the form:
DIRECTORY-AGENT://SCOPE/()/
This query is to the Directory Agent multicast address. The scheme of
a Directory Agent is 'DIRECTORY-AGENT', hence it is the scheme used in
the request. No scope is included in the request, since the query is
GLOBAL in scope. If no Naming Authority is included, so 'IANA' is
assumed. We want to reach all the available directory agents. The
query selects "SCOPE", so SCOPE attribute information will be returned,
if there is any. The where clause is empty in the query, so all
Directory Agents will match the request.
The replies may arrive from different sources. They will be similar
to:
URL returned: DIRECTORY-AGENT://srvloc-resolver.catch22.com
Attrs returned: (SCOPE=Accounting)
URL returned: DIRECTORY-AGENT://204.182.15.66
Attrs returned: (SCOPE=Janitorial Services)
If the goal is merely to discover any Directory Agent, the first reply
will do. If the goal, however, is to discover all reachable DAs, the
Veizades, Kaplan, Guttman, Perkins [Page 13]
INTERNET-DRAFT Service Location Protocol February-96
request must be retransmitted after an interval (recommended time is 10
seconds.) This retransmitted request will include a list of DAs which
have already responded. This list takes the same form as the list of
DAs above: a series of "DIRECTORY-AGENT:/ADDRESS SPECIFICATION/"
strings. Directory Agents which receive Directory Agent requests will
only respond if they are not on this list. After there are no new
replies, all Directory Agents are presumed to have been discovered.
5.7 Scheme Request
The User Agent may use the Scheme Request to find all the types of
services that are available on a network.
The format of the Scheme Request is special in that it specifies no
Scheme for the service type. Instead a '*' is used to denote a 'wild
card.' The request may be sent to any Directory Agent. This will
return all the service types that it knows about.
The request may also be sent to the General Multicast Address, in order
to find out all services available on the User Agent's internet (which
are advertised by Directory Agents and Service Agents.) A client can
issue more than one request to insure that all replies have been
received. In each subsequent request, a User Agent adds the list of
schemes that it is aware of. When no new replies arrive from a
request, the User Agent can presume that it has acquired a complete set
of available service types.
*:///()/
* is the wildcard scheme. The Naming Authority is not included so
'IANA' is assumed. There is no scope specified in this example, as the
scope is GLOBAL (ie. all Service Agents will respond.) The select
clause is empty, as no attribute information will be returned.
Finally, the where clause is empty so the request will match all
services.
Replies are sent by the Directory Agent or by Service Agents, in the
case where the request is multicast. These replies take the form:
printer://224.0.3.10 <- these multicast addresses are
http://224.0.3.24 examples only. The actual official
nntp://224.0.3.85 numbers have not been assigned!
nfs-server://244.0.3.115
The scheme defines the type of service. The address to the right of
it defines the multicast address which can be used to send queries to
Service Agents. No other information is returned in the replies, since
the select-clause of the request was NULL. All schemes were returned
since the where-clause was NULL.
If the User Agent is already aware of certain Schemes, as in the case
where it has already received several replies, but wants to be sure
Veizades, Kaplan, Guttman, Perkins [Page 14]
INTERNET-DRAFT Service Location Protocol February-96
that all Schemes are discovered, another request is multicast, with a
selection specifying which Scheme information it is NOT interested in,
as:
*:///(& (SCHEME != PRINTER)
(SCHEME != HTTP)
(SCHEME != NNTP)
(SCHEME != NFS-SERVER)) /
Only Directory Agents or Service Agents which have services other than
these four types will respond to the request. The Naming Authority is
implicitly 'IANA' as none were specified, so only services registered
under this Naming Authority will have their information returned.
To request all services which exist under a different Naming Authority
such as, say, IBM, the following query would be used:
*.ibm:///()/
5.8 Attribute Request and Attribute Reply
Once a User Agent selects a single scheme, it may issue a "get
attributes request" to find all the attributes associated with that
scheme. Since different services with a particular scheme can have
different attributes, to find all the attributes associated with a
scheme, the User Agent must form a union of all attributes returned by
all service Agents. The Attribute information will be used to form
Service Queries.
It has the following form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = AttrRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|number of previous responders |<Previous Responders Addr Spec>|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Previous Responders Addr Spec>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Scheme> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Request
If sent to a Directory Agent, the number of previous responders is zero
and there are no Previous Responder Address Specification. These
Veizades, Kaplan, Guttman, Perkins [Page 15]
INTERNET-DRAFT Service Location Protocol February-96
fields are only used for repeated multicasting, exactly as for the
Service Request.
The replies take the form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = AttrRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Attribute List> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The attribute list has the same form as the attribute list at the end
of a reply.
For example, an Attribute Request for "printer" might elicit the
following reply:
(PAPER COLOR=WHITE,BLUE),
(PAPER SIZE=LEGAL,LETTER,ENVELOPE,TRACTOR FEED),
(PAGES PER MINUTE=1,3,12),
(LOCATION=12th floor, outside deb's cube),
(PROTOCOL=LPR, PCNFS),
(QUEUES=LEGAL,LETTER,ENVELOPE,LETTER HEAD)
5.9 Service Discovery Request
Having obtained the entire list of attributes used to describe a
particular kind of service from a Get Attributes Request, (or using
a priori knowledge of a service's attributes,) the User Agent can build
a query predicate that describes the service needs of the user.
This query is sent directly to a Directory Agent. Following the
example of the last section, suppose a printer is needed on the 12th
floor which prints 12 pages per minute. The response shown above from
the Get Attribute Request indicates that there is a printer on the 12th
floor and that there is one that prints 12 pages per minute. To check
whether they are one and the same printer, issue the following request:
printer:///(& (PAGES PER MINUTE==12) (LOCATION==12th floor))/
Suppose there is no such printer. The Directory Agent responds with
a Service Reply with 0 in the number of responses and no reply values.
The User Agent then tries a less restrictive query to find a printer,
using the 12th floor as "where" criteria, but selecting the PAGES PER
Veizades, Kaplan, Guttman, Perkins [Page 16]
INTERNET-DRAFT Service Location Protocol February-96
MINUTE attribute, to find out how slow it will be:
printer://PAGES PER MINUTE/(LOCATION==12th floor)/
In this case, there is now only one reply:
Returned URL: printer://igore.wco.ftp.com:515
Returned Attrs: ((PAGES PER MINUTE = 3),(PROTOCOL=LPR,PCNFS))
The Address Specification for the printer here, igore.wco.ftp.com:515
is the location of the printer. Files would be printed by spooling
to that port on that host.
In the absence of a Directory Agent, the request above could be
multicast. In this case it would be sent to the printer Multicast
Address and not to the Directory Agent address above. Service Agents
that can satisfy the predicate will reply. Service Agents which cannot
satisfy the reply do not send any reply at all. The only way a User
Agent can be sure there are no services which match the query is by
retrying the request (say 3 times, 5 seconds apart). If no response
comes, the User Agent gives up and assumes there are no such printers.
One final note: The select field of the query is used to control how
much information is returned by the Directory Agent or Service Agent.
As described in full in Section 10.1.2, there are 3 different
selections possible. A NULL selection will return no attribute
information, merely a scheme, the Address Specification. A LIST
selection specifies which attributes should be returned. Finally, a
WILD selection can be sent, which will return all attributes/values.
This WILD selection may produce a large reply, so a TCP connection may
need to be established. Refer to Section 7.0 for details.
6.0 Directory Agents
6.1 Introduction
A Directory Agent acts on behalf of many Service Agents and Service
Applications. It acquires information from them and acts as a single
point of contact to supply that information to User Agents.
The queries that a User Agent multicasts to Service Agents (in an
environment without a Directory Agent) are the same queries that the
User Agent unicasts to a Directory Agent. A User Agent may cache
information about the presence of alternate Directory Agents to use
in case a selected Directory Agent fails.
When scaling service location systems to the size of a campus, a central
repository is added to limit the amount of general queries in the
network infrastructure. A site may also grow to such a size that it is
not feasible to maintain only one central repository of service
information. In this case more Directory Agents are needed. Multiple
Directory Agents are supported within the framework of this protocol.
Veizades, Kaplan, Guttman, Perkins [Page 17]
INTERNET-DRAFT Service Location Protocol February-96
Each Service Agent or application may register with each DA and hosts
may choose a DA to use.
Directory Agents, in the future, may use mechanisms outside of this
protocol to coordinate the maintenance of a distributed database of
service location information, and thus scale to enterprise networks
or larger administrative domains.
6.2 Directory Agent Discovery
A User or Service Agent or Service Application may be statically
configured to use a particular DA. This is discouraged unless the
application resides on a network where any form of multicast or
broadcast is impossible.
Alternatively, a host which uses DHCP may use option number 11 to
obtain a Directory Agent's address. RFC 1533, DHCP Options and BOOTP
Vendor Extensions, specifies this option in section 3.13. The Resource
Location Service as defined in RFC 887 is historic. Service location
provides this service now. The mechanism by which DHCP makes the DA's
address known to the service location protocol implementation is
described in RFC 1533 [18].
The third way to discover DAs is dynamically. This occurs actively by
sending out a Directory Agent Discovery request.
Lastly, the agent may be informed passively as follows:
When a Directory Agent first comes on-line it sends an unsolicited
Service Reply to the general service location multicast address. A
unique number will be used for the XID of this reply each time the DA
comes up.
Every 12 hours a Directory Agent will send an unsolicited Service Reply
again. This will ensure that eventually it will be discovered by all
applications which are concerned. The same XID is used for these
subsequent unsolicited replies.
If a DA supports a particular scope or set of scopes these are placed
in the reply as an attribute value of the service. The class for this
attribute is "SCOPE". Service Agents and Service Applications will,
upon receiving this reply, wait for a random interval of between 0 and
3 seconds and then begin registration of each of the services they
advertise. They will know they have detected a new DA when the see an
unsolicited reply from a given DA source address for the first time.
The first time they receive an unsolicited reply from the same DA with
a different XID, they should reregister, as the DA has come back up
without remembering its previous registration information.
Veizades, Kaplan, Guttman, Perkins [Page 18]
INTERNET-DRAFT Service Location Protocol February-96
An example of what such an unsolicited reply would look like is:
URL: directory-agent://srvloc-resolver.catch22.com
Attributes: (SCOPE=ADMIN)
This directory agent can be reached at the Address Specification
specified, and supports the SCOPE called 'ADMIN'.
When a Service Agent or Application, or User Agent first comes on-line
it may issues a Directory Agent Discovery Request, as defined in 5.6
above.
A Service Agent or Application registers information with ALL newly
discovered Directory Agents when either of the above two events take
place. When scopes are being used on a campus, a Service Agent or
Application may choose a set of scopes to be advertised in and need
only register with Directory Agents that support the scopes in which
they wish to be registered. Services may be registered with DAs
which have no scope.
Note that while it is very highly recommended that all services are
registered with all unscoped DAs and with all DAs which have a certain
(set of) SCOPE values, it is not strictly required. If a service isn't
registered this way, the availability of the service advertisement will
be limited and possibly inconsistent between DAs. This situation may
be acceptable if UAs are preconfigured (statically or by DHCP) to only
use one particular DA in all situations. This approach leaves open
the chance of failure if the preconfigured DA is not available.
Once a User Agent becomes aware of a Directory Agent it will unicast
its queries there. In the event that more than one Directory Agent
is detected, it will select one to communicate with. When scopes are
supported, the User Agent will direct its queries to different
Directory Agents depending on which scopes are appropriate domains for
the query to be answered in.
6.3 Service Registration
After a Service Agent has found a Directory Agent, it begins to
register its advertised services one at a time. A Service Agent must
wait for some random interval between 0 and 3 seconds between each
registration. Registration is done using the Service Registration
packet specifying all attributes for a service. A Directory Agent must
acknowledge each service registration request.
Veizades, Kaplan, Guttman, Perkins [Page 19]
INTERNET-DRAFT Service Location Protocol February-96
The format of a Service Reply is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = SrvReg) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of URL String | <URL String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <URL String> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Attr List String | <Attribute String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Attribute List>, Continued. \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Registration
Service registration may use a connectionless protocol (e.g. UDP), or a
connection oriented protocol (e.g. TCP). The registration operation
may contain more information than can be sent in one datagram. In this
case the Service Agent or Application must use a connection oriented
protocol to register itself with the DA. When a Service Agent or
Application registers the same attribute class more than once for a
service instance, the Directory Agent overwrites the all the values
associated with that attribute class. Separate registrations must be
made for each language that the service is to be advertised in.
Service Registration information is sent in exactly the same form as a
Service Reply:
URL (at least): SCHEME:/ ADDRESS SPECIFICATION
Attributes (if any): (ATTR1 = VALUE), (ATTR2 = VAL1, VAL2)
An example of a service registration is as follows:
URL: printer://igore.wco.ftp.com:515
Attributes: (SCOPE=DEVELOPMENT),
(PAPER COLOR=WHITE),
(PAPER SIZE=LETTER),
(LANGUAGE=POSTSCRIPT, HPGCL),
(LOCATION=12 Floor),
(PROTOCOL=LPR,PCNFS)
The same registration could be done again, in German (note that
'printer' the scheme and SCOPE are IANA terms and will remain in the
Veizades, Kaplan, Guttman, Perkins [Page 20]
INTERNET-DRAFT Service Location Protocol February-96
language they were originally registered with IANA, i.e. English):
URL: printer://igore.wco.ftp.com:515
Attributes: (SCOPE=ENTWICKLUNG),
(PAPIERFARBE=WEISS),
(PAPIERFORMAT=BRIEF),
(DRUECKERSPRACHE=POSTSCRIPT,HPGCL),
(STANDORT=11 Etage),
(PROTOKOLL=LPR,PCNFS)
Registrations must contain an Attribute of SCOPE unless they are
unscoped and then they must be registered with all directory agents.
In the example above, the SCOPE is set to DEVELOPMENT (in English) and
ENTWICKLUNG (in German.)
The Directory Agent may return a server error in the acknowledgment.
This error is carried in the Error Codes field of the service location
packet header. A Directory Agent may decline to register a service if
it is specified with an unsupported SCOPE. In this case a
SCOPE_NOT_SUPPORTED error is returned in the Service Acknowledgment.
An unscoped service registration will match all requests. A request
which specifies a certain scope will therefore return services which
have that scope and services which are unscoped. It is strongly
suggested that one should use scopes in all registrations or none.
See Section 6.5 and Sections 6.6 for details.
A non-error acknowledgment must have the error code set to zero.
Once a DA acknowledges a service registration it makes the information
available to clients.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = SrvAck) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Acknowledgment
In order to offer continuously advertised services, Service Agents
and Applications should start the registration process before the
TTL they used for registration expires.
6.4 Service Unregister
When a service is no longer available for use, the Service Agent or
Application must unregister itself from Directory Agents that it has
been registered with. A service uses the following PDU to unregister
itself.
Veizades, Kaplan, Guttman, Perkins [Page 21]
INTERNET-DRAFT Service Location Protocol February-96
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = SrvUnreg) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <URL String of Service to Unregister> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Unregister
The Service Agent should retry this operation if there is no response
from the Directory Agent. The Directory Agent acknowledges this
operation with a service acknowledgment. Once the Service Agent
receives this acknowledgment, it can assume that the service is no
longer advertised by the Directory Agent.
The Service Unregister Information sent to the Directory Agent has
the following form:
SCHEME:/ADDRESS FAMILY/ ADDRESS SPECIFICATION
This will unregister the service from the Directory Agent in every
language it was registered in. To unregister the printer above, use:
printer://igore.wco.ftp.com:515
In this example the ADDRESS FAMILY is omitted so it is assumed to
be Internet.
6.5 SCOPE Discovery and Use
The scope mechanism in the service location protocol is an important
feature to enhance its scalability. The primary use of scopes is to
provide the capability to organize a campus along administrative lines.
A set of services can be assigned to a given department of an
organization, to a certain building or geographical area or for a
certain purpose. The users of the system can be presented with these
organizational elements as a top level selection, before services
within this domain are sought.
A campus that has grown beyond a size that can be reasonably serviced
by a few DAs can use the SCOPE mechanism. DAs have the attribute class
"SCOPE". The values for this attribute are a list of strings that
represent the administrative areas for which this Directory Agent is an
authority. The semantics and language of the strings used to describe
the SCOPE are entirely the choice of the administrative entity of the
particular domain in which these SCOPEs exist. The values of SCOPE
should be configurable, so the system administrator can set its value.
The SCOPE "LOCAL" is reserved and must not be used, use of this
reserved value may be defined in a future protocol document.
Veizades, Kaplan, Guttman, Perkins [Page 22]
INTERNET-DRAFT Service Location Protocol February-96
Directory Agents advertise the list of all scopes that are available.
A Service Agent or Service Application may then choose at least one
scope in which to be registered, and should register with all
Directory Agents in that scope, as well as all DAs which have no scope.
Failure to be comprehensive in registration according to this rule
will mean that the service advertisement may not be discoverable by all
User Agents.
A Directory Agent which has a SCOPE will send replies to Directory
Agent Discovery requests with the scope information included. Note
that Directory Agent Requests should always select that SCOPE
information be returned. Note that the directory-agent scheme is
registered with the IANA naming authority (which is automatically
selected by leaving the Naming Authority field empty.)
The query:
directory-agent://SCOPE/()/
Could receive the following reply:
Returned URL: directory-agent://diragent.void.com
Returned Attribute: (SCOPE=ADMINISTRATION)
The same Directory Agent which does not support any scopes would reply:
Returned URL: directory-agent://diragent.void.com
Returned Attributes:
If a Directory Agent supported more than one scope it would reply as:
Returned URL: directory-agent://123.12.34.56
Returned Attributes: (SCOPE=ADMIN,DEV,SALES)
Normally all Directory Agents respond to a Directory Agent Request. If
only Directory Agents of a particular set of scopes are desired, issue
a query like the following:
directory-agent:///(SCOPE=ADMIN,SALES)/
Here the SCOPE field of the request is left blank, but the WHERE clause
of the request is filled in with a list of the scopes which can be used
to satisfy the request. Normally a single SCOPE would be filled in for
a query, in the SCOPE field, but in the special case of a DA query this
is not done.
Being a member of a scope means that an agent may use a specific set of
Directory Agents that support its scope. User Agents send all
requests to DAs which support the indicated scope. Services are
registered with the DA(s) in their scope. For a UA to find a service
that is registered in a particular scope they must send requests to a
DA which supports the indicated scope. There is no limitation on scope
Veizades, Kaplan, Guttman, Perkins [Page 23]
INTERNET-DRAFT Service Location Protocol February-96
membership built into the protocol; that is to say, a User Agent or
Service Agent or Application may be a member of more than one scope.
Membership is open to all, unless some external authorization mechanism
is added to limit access.
6.6 Service Location Scaling and Operating Modes
In a very small network, with few nodes, no DA is required. A User
Agent can detect services by multicasting requests. Service Agents
will then reply to them. This does not scale to environments with
many hosts. Further, Service Agents not Service Applications must be
used to make service information available.
In a larger but still administratively simple network, a single DA may
suffice. In this network, the DA will not have any SCOPE. DAs that
are discovered will return no list of SCOPES. Service Applications and
Service Agents should register with this DA even if they are configured
to specifically register with DAs which have a specific scope or set of
scopes. User Agents will query DAs without scopes, even if they are
configured to use DAs with a certain scope. This is because when a DA
with no SCOPE is discovered, it will contain all the available service
information and no scoped DAs will exist.
In a large campus or organization several DAs will be used in order to
divide the load of maintaining service information and to orgainize
which services should be used by which community. In this case ALL DAs
SHOULD HAVE A SCOPE. All Service Registrations that have a scope
should be registered with all DAs of that scope which have been or are
subsequently discovered. Unscoped services should be registered with
all DAs as they are implicitely GLOBAL in scope. User Agents make
requests of DAs which whose SCOPE they are configured to use.
In each case where 'should' is used above, one should keep in mind that
if the rule is not followed the availability of the service information
may be limited or inconsistent across the service location system.
There are thus 3 distinct operating modes. The first requires no
administrative intervention. The second requires only that a DA be
run. The last requires that all DAs be configured to have SCOPE and
that a coherent strategy of assigning SCOPES to services be followed.
Users must be instructed which SCOPES are appropriate for them to use.
This administrative cost will allow users and applications to
dynamically discover services without assistance.
7.0 Service Location Connections
When a Service Location Request results in a reply from a Service or
Directory Agent that will overflow a datagram, the User Agent can open
a connection to the Agent and reissue the request over the connection.
The reply will be returned with the overflow bit set (see section
5.4.6). The reply will contain data, as much as will fit into a single
Veizades, Kaplan, Guttman, Perkins [Page 24]
INTERNET-DRAFT Service Location Protocol February-96
packet. If no MTU information is available for the route, assume that
a maximum packet size is 1460. A Directory Agent MAY send all the
requested data in as many packets as are needed, relying on the
length fields in the reply packet to indicate to the User Agent the
number of packets to expect.
When a request results in overflowed data that cannot be correctly
parsed (say, because of duplicate or dropped IP packets), a User Agent
that wishes to reliably obtain the overflowed data must establish
a connection with the Directory Agent or Service Agent with the data.
The request is simply sent again (with a new XID, however.) The reply
is returned over the connection stream.
A Service registration which exceeds one packet in length should be
made by establishing a connection with a Directory Agent and sending
the registration over the connection stream.
Directory Agents and Service Agents must respond to connection requests
and Services whose registration can exceed a packet in length must be
able to connect and send. User Agents should be able to make requests
over a connection. If they fail to implement this, they must be able
to interpret partial replies and/or reissue requests with more
selective criteria to reduce the size of the replies.
8.0 Security Considerations
There are no provisions in this protocol to insure data integrity, data
authority or data confidentiality. Mechanisms in the underlying
network layer protocol or at the service access point may be used to
provide these functions.
9.0 Multicast vs. Broadcast
The service location protocol was designed for use in networks where
multicast at the network layer is supported; in some instances
multicast may not be supported. To support this protocol in networks
where multicast is not supported the following modifications are made
to support the protocol in an environment where network layer broadcast
is supported.
9.1 Single Subnet
If a network is not connected to any other networks simple network
layer broadcasts will work in place of multicast.
9.2 Multiple Subnets
The Directory Agent provides a central clearing house of information
for User Agents. If the network is designed so that a Directory Agent
address is statically configured with each User Agent, the directory
Agent will act as a bridge for information that resides on different
subnets. The Directory Agent address can be dynamically configured with
Veizades, Kaplan, Guttman, Perkins [Page 25]
INTERNET-DRAFT Service Location Protocol February-96
User Agents using a protocol like the Dynamic Host Configuration
Protocol (Tag Value 11) [18].
9.3 Service Multicast Address
Each service MAY have a unique multicast address to which it belongs
to. This multicast address may be obtained from IANA. This
mechanism is used so that the number of datagrams any one service
receives is minimized.
When undirected queries are made concerning this type of service, the
query should be sent to the matching multicast address. If the subnet
does not support multicast then the query should be broadcast to the
Service Location port. If the underlying hardware will not support the
number of need multicast addresses all services can use the general
service location multicast address.
10.0 Service Location in the Internet
A subsequent protocol document will describe mechanism for supporting
a service discovery protocol in a global Internet.
11.0 Protocol Formats
11.1 Fields Used in Service Location Packets
The following section supplies formal definitions for all protocol
elements introduced in the sections above.
Protocol Element Used in
----------------------------------- -------------
11.1.1 <Previous Responders' Addr Spec> SrvRqst
11.1.2 <Service Request Predicate> SrvRqst
11.1.3 <Reply> SrvRply
11.1.4 <Service Registration Information> SrvReg
11.1.5 <Service Unregister Information> SrvUnReg
11.1.6 <Attribute List> AttrRply
11.1.7 <Service Scheme> AttrRqst
11.1.1 Previous Responders' Address Specification
The previous responders' Address Specification is specified as
<Previous Responders' Address Specification>
::= Address Specification, |
Address Specification,
<Previous Responders' Address Specification>
ie. a list separated and terminated by commas with no intervening white
space. The Address Specification is the address of the Directory Agent
Veizades, Kaplan, Guttman, Perkins [Page 26]
INTERNET-DRAFT Service Location Protocol February-96
or Service Agent which supplied the previous response. The format for
Address Specifications in Service Location is defined in 11.2.
Example:
some.corp.com,128.127.203.63,
11.1.2 Service Request Predicate
The following grammar expresses the form of a Service Request
Predicate:
<predicate> ::= <scheme>[.<name auth>]:/<scope>/<select>/<where>/
<scheme> ::= string representing type of service. Only
'a' to 'z', '+' and '-' are allowed.
<name auth> ::= string representing the Naming Authority.
Only characters from 'a' to 'z', '+' and '-'
are allowed. If this field is omitted 'IANA'
is assumed.
<scope> ::= string representing the directory agent scope.
'/' and ':' are not allowed in this string.
The scopes 'LOCAL' and 'REMOTE' are reserved.
<select> ::= <select-list> |
<select-all> |
<select-none>
<select-list> ::= <select-item> |
<select-item>, <select-list>
<select-item> ::= <attr-tag> | <partial-attr-tag>*
<attr-tag> ::= class name of an attribute of a given scheme
This tag cannot have include the following
characters: '(', ')', ',', '=', '!', '>',
'<', '/', '*'
<partial-tag> ::= the partial class name of an attribute
followed by an '*' matches all class names
which begin with the characters preceding
the '*'
<select-all> ::= *
<select-none> ::=
That is NOTHING or white space.
Becomes:
<where> ::= <where-any> |
<where-list> |
<where-join>
<where-any> ::= ()
<where-list> ::= (& <query-item> <query-list>) |
(| <query-item> <query-list>) |
<query-item>
Veizades, Kaplan, Guttman, Perkins [Page 27]
INTERNET-DRAFT Service Location Protocol February-96
<query-list> ::= <where-list> |
<query-item> |
<query-item> <query-list>
<query-item> ::= (<attr-tag> <comp-op> <attr-val>) |
(<attr-tag>)
<query-join> ::= <join-item> |
<join-item>, <query-join>
<join-item> ::= <attr-tag> |
<attr-tag> <comp-op> <attr-val>
<comp-op> ::= != | == | < | <= | > | >=
<attr-val> ::= any string (see Section 10.3 for the ways
in which attr-vals are interpreted.)
Value strings may not contain '/', ','
'=', '<', '>'. '(' and ')' can only be used
for the purpose of encoding a binary values.
Binary encodings (See Section 10.3) may
include the above reserved characters.
Note on string matches: All strings are case insensitive, with respect
to string matching on queries. All preceding or trailing blanks should
not be considered for a match, but blanks internal to a string are
relevant. For example " Some String " matches "SOME STRING" but not
"some string".
A predicate has a simple structure, which depends on the parentheses,
commas and slashes to delimit the elements. Examples of proper usage
have been given throughout the document. The terms used above are
described below:
predicate:
Placed in a Service Request, this is interpreted by a Service
Agent or Directory Agent to determine what information to
return.
scope:
If this is absent in a Service Request, the request will match
any service regardless of scope. If it is present, only
services registered under that scope will match the request.
select-clause:
This determines what information to return. There are 3 types
of select-clause: NULL, ANY and LIST.
NULL: The reply returns no attribute information for the
PARTICULAR services which satisfy the where-clause.
ANY: The reply returns all attribute information, as above.
LIST: The reply returns the attribute information for the
attributes whose class names are listed, as above.
Recall that an attribute has a class name and a set
of values. The list contains a set of class names.
Elements in the list can be partial names, as 'INT*'
will match 'INTERFACE 1' and 'INTERNAL'.
Veizades, Kaplan, Guttman, Perkins [Page 28]
INTERNET-DRAFT Service Location Protocol February-96
where-clause:
This determines which services the request matches. An empty
where-clause will match all services. The request will be
limited to services which have the Scheme which was defined
prior to the predicate, so the where-clause is not the sole
factor in picking out which services match the request.
where-list:
The where-list is a logical expression. It can be a single
expression, a disjunction or a conjunction. A single expression
must apply for the where-clause to match. A disjunction matches
if any expression in the disjunctive list matches. A conjunction
matches only if all elements in the conjunction match.
Note that there is no logical negation operator: This is
because there is no notion of returning "everything except" what
matches a given criteria.
A where-list can be nested and complex. For example:
(& (| <query-item> <query-item> <query-item>)
<query-item>
(& <query-item> <query-item> <query-item> <query-item>)
)
Notice that white space, tabs or carriage returns can be added
anywhere outside query-items. Each list has 2 or more items in
it, and lists can be nested. Services which fulfill the entire
logical expression match the where-clause.
query-item:
A query item has the form:
(<attr-tag> <comp-op> <attr-val>)
Examples of this would be:
(SOME ATTRIBUTE == SOME VALUE)
(STATUS != RESERVED)
(QUEUE LENGTH <= 234)
query-join:
The query-join is a comma delimited list of conditions which the
service must satisfy in order to match the query. The items are
considered to be logically conjoined. Thus the query-join:
attr1=value1, keyword1, keyword2, attr2>=34
is equivalent to the where-list:
(& (attr1=value1) (keyword1) (keyword2) (attr2>=34))
The query-join cannot be mixed with a where-list. It is provided
as a convenient mechanism to provide a statement of necessary
conditions without building a logical expression.
Veizades, Kaplan, Guttman, Perkins [Page 29]
INTERNET-DRAFT Service Location Protocol February-96
11.1.3 Reply
Service Replies have two fields, a URL String and an attribute list.
URL Strings are either a URL as per RFC 1738 and standardization
according to IANA, or if there is no such standard, at least:
SCHEME:/ ADDRESS SPECIFICATION
SCHEME is a string. Schemes may be standardized by developing a
specification for the "scheme specific" part and registering
them with the IANA.
ADDRESS SPECIFICATION is the service access point of the service.
It is the network address or domain name where the service
can be accessed.
The <attr-list> is returned if the select-clause of the query is
not NULL.
<attr-list> ::= <attribute> | <attribute>, <attr-list>
<attribute> ::= (<attr-tag>=<attr-val-list>) | <attr-tag>
<attr-val-list> ::= <attr-val> | <attr-val>, <attr-val-list>
An attribute with only an attr-tag and no values is a keyword.
A comma cannot appear in an attr-val, as the comma is used as the
multiple value delimiter. Examples of an attr-list are:
(SCOPE=ADMINISTRATION)
(COLOR=RED, WHITE, BLUE)
(DELAY=10 Minutes),(MOST RECENT BUILD=10-5-95),(PRIORITY=LOW,HIGH)
The third example has three attributes in the list. Color can take
on the values red, white and blue. There are several other examples
of replies throughout the document.
11.1.4 Service Registration Information
The Service Registration Information has the same form as a Reply
in the section above. The attribute list must be complete.
11.1.5 Service Unregister Information
The Service Unregister Information takes the form:
SCHEME:/ ADDRESS SPECIFICATION
SCHEME and ADDRESS SPECIFICATION are described above.
11.1.6 Attribute List
The Attribute List is defined in 10.1.3 as <attr-list>.
Veizades, Kaplan, Guttman, Perkins [Page 30]
INTERNET-DRAFT Service Location Protocol February-96
11.1.7 Service Scheme
The Service Scheme is a string describing the type of service. These
strings may only be comprised of 'a' through 'z', '+' and '-'. Upper
case is considered equivalent to lower case in scheme names.
If the scheme name is followed by a '.' and a string (which has the
same limitations) the 'suffix' is considered to be the naming authority
of the service. If the Naming Authority is omitted, IANA is assumed to
be the Naming Authority.
Service Schemes developed for in-house or experimental use may have any
name and attribute semantics provided that they do not conflict with
the standardized schemes. The Service Discovery Multicast Address used
should taken from the range of experimental multicast addresses
reserved by the IANA.
11.2 ADDRESS SPECIFICATIONs in Service Location
The representation of the ADDRESS SPECIFICATION depends on the
PROTOCOL. In the case of IPv4 (refering to RFC 1738):
//<user>:<password>@<host>:<port>
The first slash has already been included in the grammar (separating
the scheme from the ADDRESS SPECIFICATION.) See RFC 1738 for the
complete syntax.
It is preferable to use a fully qualified domain name wherever possible
as renumbering of host addresses will make ip addresses invalid over
time. When no Domain Name Server is available SAs and DAs must use
dotted decimal conventions for IP addresses.
For other address families, such as IPX, NSAP, etc. the proposed
convention is:
<address family>/<non-ip address>
<address family> ::= A string such as IPX, NSAP, etc.
<non-ip address> ::= Address representation depending on address
family. IPX would be <ipx-port>:<mac-addr>
<ipx-port> ::= 4 byte value, represented in hex, ie. the
range 00000000 to FFFFFFFF.
<mac-addr> ::= 6 byte range, represented in hex, ie. the
range 000000000000 to FFFFFFFFFFFF.
An example of a URL for an ipx fileserver could be:
fileserver:/IPX/00000001:00C0D1800E65
Veizades, Kaplan, Guttman, Perkins [Page 31]
INTERNET-DRAFT Service Location Protocol February-96
11.3 Attribute Value encoding rules
Attribute values, and attribute tags are CASE INSENSITIVE for purposes
of lexical comparison.
Attribute values can have be any string with the exception of '(', ')',
'=', '>', '<', '/' and ',' (the comma) except in the case described
below where opaque values are encoded.
While an attribute can take any value, there are three types of values
which differentiate themselves from general strings: Booleans,
Integers and Opaque values.
- Boolean values are either TRUE or FALSE. This is the case
regardless of the language (i.e. in French or Telugu, Boolean TRUE
is 'TRUE', as well as in English.) Boolean attributes can take only
one value.
- Integer values are expressed as a sequence of numbers. The range of
allowable values, for this 32 bit quantity, is -2147483648 to
2147483647.
- Opaque values (i.e. binary values) are expressed in radix-64
notation. The syntax is:
<opaque-val> ::= (<len>:<radix-64-data>)
<len> ::= integer length of the original binary data
<radix-64-data> ::= An encoding of the binary data into a new
format.
Radix-64 encodes every 3 bytes of binary data into 4 bytes of ASCII
data which is in the range of characters which are fully printable
and transferable by mail. For a formal definition of the Radix-64
format see RFC 1521, MIME Part One, Section 5.2 Base64 Content
Transfer Encoding, page 21.
Opaque values can pass things such as bitmaps for building a service
browsing graphical interface or application specific data.
- Keywords may be expressed as an attribute that has no values, and
do not necessarily have to be delimited by parenthesis:
(power pc enabled)
or
(official use only)
or
special-sauce, hold-the-lettuce, (buns=toasted)
Notice that the last example shows the use of two keywords and
an attribute with its value.
Veizades, Kaplan, Guttman, Perkins [Page 32]
INTERNET-DRAFT Service Location Protocol February-96
12.0 Implementation Requirements
A User Agent MAY:
- Listen on the Service Location General Multicast address for
unsolicited Directory Agent Replies. This will increase the set of
Directory Agents available to it for making replies. See Section
6.2.
- Provide a way for the application to configure the default DA, so
that it can be used without needing to find it each initially.
- Be able to request the address of a DA from DHCP, if configured to
do so.
- Be able to send requests to a multicast address. If the
multicast address is not known, the UA must be able to use a
Scheme query to obtain the multicast address for the scheme of the
request.
- Be able to handle numerous replies after a multicast request. The
implementation may be configurable so it will either return the
first reply, all replies until a timeout or keep trying till the
results converge.
A User Agent MUST:
- Be able to unicast requests and receive replies reliably from a DA.
- Be able to detect DAs using a Directory Agent Discovery request
issued when the UA starts up.
A Service Application MAY be able to:
- Get the address of a local Directory Agent by way of DHCP.
A Service Application MUST be able to:
- Listen to the Service Location General Multicast address for
unsolicited Directory Agent Replies. If one is detected, and the
DA has the right scope, all services which are currently being
advertised SHOULD be registered with the DA. See Section 6.2.
- Unicast registrations and unregistrations reliably to a DA.
- Be able to detect DAs using a Directory Agent Discovery request
issued when the Service Application starts up.
A Service Agent MUST be able to:
- Listen to the Service Location General Multicast address for
unsolicited Directory Agent Replies. If one is detected, and the
DA has the right scope, all services which are currently being
advertised SHOULD be registered with the DA. See Section 6.2.
- Unicast registrations and unregistrations reliably to a DA.
- Listen to the multicast address of the service it is advertising.
The incoming requests should be filtered: If the Address
Specification of the SA is in the Previous Responders Address
Specification list, the SA should not respond. Otherwise, a
response to the multicast query should be unicast to the UA
which sent the request.
- Listen to the Service Location General Multicast address for
queries of any type. If the query can be replied to by the
Service Agent, the Service Agent must do so. It must check first
Veizades, Kaplan, Guttman, Perkins [Page 33]
INTERNET-DRAFT Service Location Protocol February-96
to make sure it is not on the list of 'previous responders.'
It will receive 'Scheme' requests this way.
- Be able to detect DAs using a Directory Agent Discovery request
issued when the SA starts up.
A Directory Agent MUST be able to:
- Send an unsolicited Directory Agent Discovery reply to the
Service Location General Multicast address on startup and repeat
it periodically. This reply has a unique XID for the life of the
DA; this XID changes on each reboot (see Section 6.2).
- Listen on the Directory Agent Multicast Address for Directory
agent discovery requests. Filter these requests if the Previous
Responder Address Specification list includes the DA's Address
Specification.
- Listen on the TCP and UDP ports for unicast requests,
registrations and unregistrations and service them.
- Provide a way in which SCOPE information can be used to configure
the Directory Agent.
- Age out the services which have been registered so that when the
service registration's TTL expires, the service advertisement is
withdrawn.
NOTE: Service Applications, Service Agents and User Agents use
ephemeral ports for transmitting information to the service location
port.
13.0 Interesting Constants
IP Port number for unicast requests to Directory Agents:
UDP and TCP Port Number: 427
Multicast Addresses
General Multicast Address: 224.0.1.22
Directory Agent Multicast Address: 224.0.1.35
Further multicast address will be assigned for specific types of
service through the IANA.
Error Codes
No Error 0
LANGUAGE_NOT_SUPPORTED 1
AUTHORITY_NOT_SUPPORTED 2
PROTOCOL_PARSE_ERROR 3
INVALID_REGISTRATION 4
SCOPE_NOT_SUPPORTED 5
Veizades, Kaplan, Guttman, Perkins [Page 34]
INTERNET-DRAFT Service Location Protocol February-96
14.0 Acknowledgments
This protocol owes some of the original ideas to other service location
protocols found in many other networking protocols. Leo McLaughlin
and Mike Ritter (Metricom) provided much input into early version
of this document. Thanks also to Steve Deering (Xerox) for providing
his insight into distributed multicast protocols. Harry Harjono and
Charlie Perkins supplied the basis for the URL based wire protocol
in their Resource Discovery Protocol. Their comments have been very
valuable. Thanks also to Peerlogic, Inc. for supporting this work.
15.0 References
[1] Freier, A. O. "Network Binding Protocol" Xerox Corporation
Unpublished, June 1986.
[2] S. Gursharan, R. Andrews, A. Oppenheimer, Inside AppleTalk.
Addison-Wesley Publishing. 1990
[3] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, NIC,
August 1989.
[4] Saltzer, J., "On the Naming and Binding of Network Destinations",
RFC 1498, M.I.T. Laboratory for Computer Science, August 1993.
[5] Accetta, M. "Resource Location Protocol", RFC 887, NIC, December
1983
[6] Legato Systems, "The Legato Resource Administration Platform",
Legato Systems, 1991.
[7] C. McManis and R. Rom, "The Zeus Name Service Architecture", Sun
Microsystems, 1990.
[8] S. Dyer, "The Hesiod Name Server", Winter Usenix Conference, pp.
183-187, Feb 1988.
[9] D. Oppen and Y. Dalal, "The Clearinghouse: A Decentralized Agent
for Locating Named Objects in a Distributed Environment," Tech. Rep.
OPD-78103, Xerox Office Products Division, 1981.
[10] B. Lampson, "Designing a Global Name Service", Proceedings of the
5th ACM Symposium on Principles of Distributed Computing, pp. 1-10,
1986.
[11] D. Cheriton and T. Mann, "Uniform Access to Distributed Name
Interpretations in the V-system".
[12] P. Mockapetris. "Domain Names - Concepts and Facilities". RFC
1034, NIC, November 1987
Veizades, Kaplan, Guttman, Perkins [Page 35]
INTERNET-DRAFT Service Location Protocol February-96
[13] P. Mockapetris. "Domain Names - Implementation and Specification".
RFC 1035, NIC. November 1987
[14] S. Deering. "Router Discovery Protocol". RFC 1256, NIC 1991.
[15] ISO 639:1988 (E/F) "Code for the representation of names of
languages"; ISO, Geneve, 1988.
[16] T. Berners-Lee, L. Masinter and M. McCahill "Uniform Resource
Locators". RFC 1738, NIC 1994.
[17] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies". RFC 1521, NIC 1993.
[18] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions". RFC 1533, NIC 1993.
[19] R. Droms, "Dynamic Host Configuration Protocol". RFC 1541,
NIC 1993.
Veizades, Kaplan, Guttman, Perkins [Page 36]
INTERNET-DRAFT Service Location Protocol February-96
16.0 Author's Addresses
John Veizades
TGV, Inc.
370A Waller St.
San Francisco, CA 94117
Phone: +1 415 252 8203
Fax: +1 415 252 8248
Email: veizades@tgv.com
Scott Kaplan
346 Fair Oaks St.
San Francisco, CA 94110
Phone: +1 415 285 4526
Email: scott@catch22.com
Erik Guttman
1920 Sacramento St., #8
San Francisco, CA 94109
Phone: +1 415 921 6570
Email: guttman@cs.stanford.edu
Charles Perkins
IBM Corporation
P.O. Box 704
Yorktown Heights NY 10598
Phone: +1 914 784 7350
EMail: perk@watson.ibm.com
17.0 Document Expiration
This document expires August 1, 1996
Veizades, Kaplan, Guttman, Perkins [Page 37]
INTERNET-DRAFT Service Location Protocol February-96
Appendix A - Technical contents of ISO 639:1988 (E/F)
"Code for the representation of names of languages".
Two-letter lower-case symbols are used.
The Registration Authority for ISO 639 is Infoterm,Osterreiches
Normungsinstitut (ON), Postfach 130, A-1021 Vienna, Austria.
aa Afar gn Guarani mr Marathi
ab Abkhazian gu Gujarati ms Malay
af Afrikaans mt Maltese
am Amharic ha Hausa my Burmese
ar Arabic hi Hindi
as Assamese hr Croatian na Nauru
ay Aymara hu Hungarian ne Nepali
az Azerbaijani hy Armenian nl Dutch
no Norwegian
ba Bashkir ia Interlingua
be Byelorussian ie Interlingue oc Occitan
bg Bulgarian ik Inupiak om (Afan) Oromo
bh Bihari in Indonesian or Oriya
bi Bislama is Icelandic
bn Bengali; Bangla it Italian pa Punjabi
bo Tibetan iw Hebrew pl Polish
br Breton ps Pashto, Pushto
ja Japanese pt Portuguese
ca Catalan ji Yiddish
co Corsican jw Javanese qu Quechua
cs Czech
cy Welsh ka Georgian rm Rhaeto-Romance
kk Kazakh rn Kirundi
da Danish kl Greenlandic ro Romanian
de German km Cambodian ru Russian
dz Bhutani kn Kannada rw Kinyarwanda
ko Korean
el Greek ks Kashmiri sa Sanskrit
en English ku Kurdish sd Sindhi
eo Esperanto ky Kirghiz sg Sangro
es Spanish sh Serbo-Croatian
et Estonian la Latin si Singhalese
eu Basque ln Lingala sk Slovak
lo Laothian sl Slovenian
fa Persian lt Lithuanian sm Samoan
fi Finnish lv Latvian, Lettish sn Shona
fj Fiji so Somali
fo Faeroese sq Albanian
fr French mg Malagasy sr Serbian
fy Frisian mi Maori ss Siswati
mk Macedonian st Sesotho
ga Irish ml Malayalam su Sundanese
gd Scots Gaelic mn Mongolian sv Swedish
gl Galician mo Moldavian sw Swahili
Veizades, Kaplan, Guttman, Perkins [Page 38]
INTERNET-DRAFT Service Location Protocol February-96
ta Tamil
te Telugu
tg Tajik
th Thai
ti Tigrinya
tk Turkmen
tl Tagalog
tn Setswana
to Tonga
tr Turkish
ts Tsonga
tt Tatar
tw Twi
uk Ukrainian
ur Urdu
uz Uzbek
vi Vietnamese
vo Volapuk
wo Wolof
xh Xhosa
yo Yoruba
zh Chinese
zu Zulu
Veizades, Kaplan, Guttman, Perkins [Page 39]
