draft-ietf-svrloc-protocol-06.txt John Veizades
INTERNET-DRAFT TGV, Inc.
Scott Kaplan
CoroNet Systems Inc.
Erik Guttman
Peerlogic, Inc.
July 6, 1995
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 WG
Expires January 6, 1996 [Page 1]
INTERNET-DRAFT Service Location Protocol July-95
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 Service Location PDU header..................................6
5.1.1 Version...............................................6
5.1.2 Functions.............................................6
5.1.3 Length................................................7
5.1.4 Error Codes...........................................7
5.1.5 XID...................................................7
5.1.6 Locale................................................7
5.1.7 Flags.................................................7
5.1.8 Time To Live..........................................8
5.2 Distinguished Attribute Request..............................8
5.3 Get Attributes Request and Reply.............................9
5.4 Service Request and Reply...................................10
5.5 Service Attributes Request and Reply........................12
6.0 Directory Agents................................................12
6.1 Introduction................................................12
6.2 Directory Agent Discovery...................................13
6.3 Service Registration........................................14
6.4 Service Unregister..........................................14
6.5 SCOPE Discovery and Use.....................................15
6.6 SCOPE Propogation...........................................17
7.0 Service Information Versions....................................17
7.1 Information Versions........................................18
7.2 User Agents.................................................18
7.3 Directory Agents............................................19
7.4 Service Agents..............................................19
8.0 Server Location Connections.....................................19
9.0 Special Data Types..............................................20
9.1 Function Resolution.........................................20
9.2 Opaque......................................................20
10.0 Authentication.................................................21
11.0 Multicast vs. Broadcast........................................21
11.1 Non-interneted networks...................................21
11.2 Interneted site...........................................21
11.3 Service Multicast Address.................................21
12.0 Data Element Formats...........................................22
12.1 Attributes................................................22
12.2 Service Instance..........................................23
12.3 Addresses.................................................24
12.4 Predicate.................................................24
13.0 Predicate Language.............................................25
Veizades, Kaplan, Guttman [Page 2]
INTERNET-DRAFT Service Location Protocol July-95
14.0 Interesting Constants..........................................27
15.0 Acknowledgments................................................28
16.0 References.....................................................28
17.0 Author's Address...............................................29
18.0 Document Expiration............................................29
Appendix A - Technical contents of ISO 639:1988 (E/F)...............30
3.0 Notation Conventions
<> Values set off in this manner are fully described in section
12.0.
In General, all definitions of items in packets are described in
section 12.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. There can only be one SA per a
given host.
Service Instance The address (service access point) of one
service, together with service specific
configuration information.
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.
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 is out of band
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
Veizades, Kaplan, Guttman [Page 3]
INTERNET-DRAFT Service Location Protocol July-95
it for efficient access by User Agents. There
can only be one DA present per given host.
Distinguished Attribute A special attribute at the top level of the
service location naming taxonomy. The
Distinguished Attribute has "DIST ATTR" as its
class name, a 32 bit value describing the type
of service and a text string as its value.
The 32 bit quantity is registered with IANA.
Attribute A {class, value} pair describing a
characteristic of a service. Note that a
class is a string and the value can be of
five types: integer, string, boolean, function
(see section 9.0), and opaque. The service
information advertised by a Service Agent may
include more than one value per class.
Standard Attribute An attribute whose class name and values have
a standard interpretation. These should be
clearly defined and registered with a
standards organization.
Predicate A boolean expression of attributes, relations
and logical operators. The predicate is used
to find services which satisfy particular
requirements. See section 12.4 and 13.0.
Scope A collection of systems, networks and other
network components that make up a logical
group. See section 6.5 and 6.6.
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."
Veizades, Kaplan, Guttman [Page 4]
INTERNET-DRAFT Service Location Protocol July-95
5.0 Protocol Overview
The following describes the operations an end system needs to perform
to find services on the attached network. The user agent, end system,
does not need any configuration to begin network interaction. The user
agent builds on the information it retrieves in earlier network
requests to find the service agents advertising service information,
then finds the terms used to describe services that it is interested
in. The user agent can use this information to send out predicates
which describe the services that match the user's needs.
The service location protocol requires the implementation of a
connectionless and a connection oriented transport protocols, this
would be UDP and TCP in the Internet protocol suite. These protocols
should be supported over a network protocol layer that supports
internetwork wide multicast. The protocol will operate in a broadcast
enviroment with the limitations outlined in section 11.
Note: When implementing this protocol over IP version 4 the following
must be observed.
1. The constants specified in Section 14 must be used.
2. The address format for describing IP addresses specified in section
12.3 must be used.
3. ICMP error messages should not be sent in response to multicast
datagrams.
The service location protocol uses a multicast request/unicast response
interaction. Since the requester does not know the number of
responders to a request, the request may generate more responses than
the requester is able to handle. Therefore the requester sends a series
of requests. Each request contains the information learned in the
previous requests. The protocol requires responders to scan this list
and respond only if they have information not in the list.
Character strings are represented as a {type, length, value} tuple.
Implementers of this specification are strongly encouraged to be able to
send and receive Unicode [15] as one of the string data types.
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 end
system 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 end system to connect to a service as desired, the request must
be resent.
Veizades, Kaplan, Guttman [Page 5]
INTERNET-DRAFT Service Location Protocol July-95
5.1 Service Location PDU header
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 | XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locale |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|M| flags |
+-+-+-+-+-+-+-+-+
5.1.1 Version
This protocol document defines version 1 of the service location
protocol.
5.1.2 Functions
Service location datagrams can be identified as to their operation by
the function field. The following are the defined operations:
Packet Types Abbreviation Function Value
Distinguished Attribute Request DistAttrRqst 1
Distinguished Attribute Reply DistAttrRply 2
Attribute Class Request AttrRqst 3
Attribute Class Reply AttrRply 4
Service Request SrvRqst 5
Service Reply SrvRply 6
Service Registration SrvReg 7
Service Unregister SrvUnreg 8
Service Acknowledge SrvAck 9
Service Attributes Request SrvAttrRqst 10
Version Request VerRqst 11
Version Reply VerRply 12
Function Resolve Request FuncReslvRqst 13
Function Resolve Reply FuncReslvRply 14
Scope Request ScopeRqst 15
Scope Reply ScopeRply 16
Veizades, Kaplan, Guttman [Page 6]
INTERNET-DRAFT Service Location Protocol July-95
5.1.3 Length
The length is the number of bytes after the Service Location PDU
Header.
5.1.4 Error Codes
Errors are only valid in reply and service acknowledgement datagrams.
Replies that completed successfully should have a zero value for the
error code.
5.1.5 Transaction Identifier (XID)
The XID (transaction ID) field allows the requester to match replies
to individual requests. 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. The responder copies the XID from
the request into its reply.
5.1.6 Locale
All service location requests and responses contain the "locale" field.
This allows clients to advertise their preference as to the language
in which responses should be returned. The locale field is comprised
of four 8 bit values using the lower case ASCII representation of the
symbols defined in ISO 639 (reprinted in Appendix A). The first two
bytes should be left zeroed (0x0) for further expansion. Services
should have a default locale. If they are able to respond in a
language that corresponds with the client's requested locale they
should, otherwise they should respond with data in their default
locale and set the locale code to the default locale.
5.1.7 Flags
The flags field is a bit field. Bit 0 is the 'Overflow bit.' See
section 8.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 end system will only accept responses in the language that is
indicated in the locale field of the header. Replies in other
languages should not be sent for this request. All other bits must be
set to zero.
5.1.8 Time to Live
The TTL field is set to the number of seconds the reply can be cached
by any intermediary service. A value of 0 means the information must
not be cached.
NOTE: The preceding header is used in all of the packet discriptions
below and is abbreviated by using "Sevice location header" followed by
Veizades, Kaplan, Guttman [Page 7]
INTERNET-DRAFT Service Location Protocol July-95
the function being used.
5.2 Distinguished Attribute Request
The client uses the Distinguished Attribute Request to find all the
types of services that are available on a network. Service agents
respond with a list of Distinguished Attributes that they support.
Like most service location PDUs, 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 distinguished
attributes that it is aware of to the "distinguished attributes"
field of the datagram. The "Num Dist Attrs found" indicates how many
"previously found" Distinguished Attributes will follow.
Service agents look for distinguished attributes that they support but
are not in the list. If any such distinguished attributes exist, the
service agent replies with these distinguished attributes. The number
of distinguished attributes the service agent returns is in the
datagram as "Num Dist Attrs found".
The service agent's reply is sent to the unicast address of the sender.
The service agent should wait before responding. The wait time should
be a random interval between 0 and 2 seconds.
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.
A distinguished attribute defines a class of objects of a particular
type, i.e., printers, modems, file servers, etc. These attributes are
registered through the Internet Numbering Authority (IANA). Examples are
"DIST ATTR" as the class and "PRINTER" as the value, or "NFS FILE SERVER"
as the value. Since the class "DIST ATTR" is standardized, this class
name should not be used in any other attribute.
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 = DistAttrRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Dist Attrs found | <Distinguished Attribute> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Distinguished Attribute> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Distinguished Attributes Request
Veizades, Kaplan, Guttman [Page 8]
INTERNET-DRAFT Service Location Protocol July-95
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 = DistAttrRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Dist Attrs returned | <Distinguished Attribute> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Distinguished Attribute> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Distinguished Attributes Reply
5.3 Get Attributes Request and Reply
Once a user agent selects a single distinguished attribute, it sends a
"get attributes request" to find all the attributes associated with
that distinguished attribute. Since different services with a
particular distinguished attribute can have different attributes, to
find all the attributes associated with a distinguished attribute, the
user agent must form a union of all attributes returned by all service
agents.
If a user agent is unable to process all the replies from the service
agents it may reissue the request. It can get the attributes from
these service agents by reissuing the request. The user agent places
the addresses of the service agents that it already has replies from
in the "service addresses" field of the request. Service agents should
only reply if they are not on the "service addresses" list of the
request. With a packet length of 1500 bytes, this protocol can support
~200 IPv4 respondents. Networks with greater than 200 service agents
need to install a directory agent (see Section 6.0).
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 services agents found| <Dist Attr> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Dist. Attr> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Addresses> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attributes Request
Veizades, Kaplan, Guttman [Page 9]
INTERNET-DRAFT Service Location Protocol July-95
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of Attrs returned | <Attribute 1> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Attribute 1> (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
\ . \
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Attribute N> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attributes Reply
5.4 Service Request and Reply
Having obtained the entire list of attributes which the service agent
uses to describe services, the user agent can build a query predicate
that describes the service needs of the user. The query is a predicate
based on the list of attributes received. The query is multicast to
the multicast address of the distinguished attribute of the service
which is being queried for or unicast to service agents that support
the indicated distinguished attribute. Service agents that can satisfy
the predicate reply with the attributes that they used to satisfy the
predicate. The reply contains the set of all attributes which satisfy
the predicate. The reply is unicast to the sender. One reply packet
is returned for each service that the the service agent finds which
will fulfill the requested predicate.
As in the case of the Get Attributes Request, the service reply must be
localized to a single language. The locale field of the Service
Reply's header must be set to the language of the reply. The request
predicate can only be satisfied in the context of the language in which
the attribute classes and values are stated in. The Service Reply
contains the address of the agent which fulfilled the request. This
address should be used in future requests for information about the
service. The specific service may not be using the service locaton
protocol and the agent is acting on behalf of this service, so service
location request must be sent to the agent specified by this address.
If the Service Information Addess is zero the agent and the service are
collocated. If a server contains more than one instance of a
particular type of service all these services maybe returned in a
single datagram.
Veizades, Kaplan, Guttman [Page 10]
INTERNET-DRAFT Service Location Protocol July-95
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 services agents found| <Predicate> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Predicate> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Addresses> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Request
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Services | <Service Instance> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Instance> (cont) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Attributes | <Attribute 1> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Attribute 1> (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
\ . \
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Attribute N> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Reply
Veizades, Kaplan, Guttman [Page 11]
INTERNET-DRAFT Service Location Protocol July-95
5.5 Service Attributes Request and Reply
After a user agent has received a response to its Service Request it
will know the address of one or more services, as well as the attribute
values used to satisfy the query. That gives the user agent sufficient
information to know that a service is useful and how to access it. The
user agent may desire further information, however. The Service
Attributes Request returns all the advertised attributes and their
range of values for a given service instance. The user agent can then
provide a complete profile of a given service, which might be of
interest to a user.
The service request contains the service instance of the service in
question. This request should be unicast to the service agent or the
directory agent which provided the user agent with the Service Reply
from which the Service Instance information was extracted. The
response to this request should be sent in a Service Reply packet.
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 = SrvAttrRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Instance> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Attributes Request
6.0 Directory Agents
6.1 Introduction
A directory agent acts as a proxy for many service agents. It
acquires information from service agents and acts as a single point
of contact to supply that information. A service agent registers
information with the directory agent so it can reply to service
location requests the way that the service agent would. The directory
agent should be able to respond in a timely fashion to user agent
requests and return accurate information about the services that are
being exported by the service agent.
The queries that a user agent sends to service agents (i.e. 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 other directory agents to use as fall
back directory agents in case a selected directory agent fails.
In scaling service location systems to the size of a campus a central
Veizades, Kaplan, Guttman [Page 12]
INTERNET-DRAFT Service Location Protocol July-95
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 another directory agent is instanciated.
Multiple directory agents are supported within the framework of this
protocol. Each SA registers with each DA and hosts may either use each
DA in a round robin fashion or may pick which DA to use in a
nondeterministic fashion.
6.2 Directory Agent Discovery
When a directory agent first comes on line it sends an unsolicited
Attributes Reply to the general service location multicast address. 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 upon receiving this reply must
wait for a random interval of between 0 and 10 seconds and then begin
registration of each of the services that the service agent advertises.
When a service agent or user agent first comes on-line it issues a
service request for the distinguished attribute "DIR AGENT"; directory
agents reply to this query. A service agent may examine the enclosed
authorization information and determine if the directory agent is an
authorized agent.
A service agent registers information with all directory agents when
either of the above two events take place. When scopes are being used
on a campus a service agent 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.
Once a user agent becomes aware of a directory agent it will unicast
its queries to it. In the event that more than one directory agents
are 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.
A directory agent continues to send the above reply at a period of 5
minutes. SAs that fail to detect this heart beat from the DA in
which they are registered with should check to see if the DA is still
alive. The SA should send a Version Request (see section 7.2) to
determine if the DA still has the most recent version of the service
information that the SA had previously registered with the DA. If it
fails to respond, the SA should mark the registration as inactive.
When the DA appears again the SA reregisters with the DA. If the DA
responds incorrectly, the SA should reregister with it. If all the
DAs in a scope are inactive the SA should reregister in another scope
for it to be made available.
After a service agent has found a directory agent, it begins to
register its advertised services one at a time. A service agent must
Veizades, Kaplan, Guttman [Page 13]
INTERNET-DRAFT Service Location Protocol July-95
6.3 Service Registration
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 Service Registration
Packet has the same format as a Service Reply packet, except for the
function type. They are different in order to avoid ambiguities. A
directory agent must acknowledge each service registration request.
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 must use a connection oriented protocol to
register itself with the DA. When a service agent 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 locale
that the service is to be advertised in.
If a subsequent registration has a different version number (see
section 7.0) from a prior one, for the same service, the new packet
will be taken as an update. The version number of the service will be
changed to the most recent version number in the Directory Agent's
service information cache.
The DA must send a service acknowledgment for every registration.
The directory agent may return a server error in the acknowledgment,
if for instance, a registered service lacks an addresss. This error is
carried in the Error Codes field of the service location packet header.
A non-error acknowledgement 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
6.4 Service Unregister
When a service is no longer available for use, the service must
unregister itself from directory agents that it has been registered
with. A service uses the following PDU to unregister itself.
Veizades, Kaplan, Guttman [Page 14]
INTERNET-DRAFT Service Location Protocol July-95
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Instance> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 conceptual 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. Directory agents
advertise the list of all scopes that are available. A service agent
chooses at least one scope in which to be registered. A service agent
must register with all directory agents in that scope.
Being a member of a scope means that you use a specific set of
directory agents that support your scope. User agents send all
requests to DAs which support the indicated scope. Service Agents
register with the DA(s) in their scope. For a UA to find a service
that is registered in a particular scope they must contact a DA which
supports the indicated scope. There is no limitation on scope
membership built into the protocol; that is to say, a user agent or
service agent may be a member of more than one scope. Membership is
open to all agents, unless some authorization mechanism is added to
limit access.
Veizades, Kaplan, Guttman [Page 15]
INTERNET-DRAFT Service Location Protocol July-95
An end system finds the scopes that are available in a campus by
multicasting a DA discovery request to all directory agents. The
discovery message contains the scope or scopes, if known, that are
being used, as part of the attribute request. Directory Agents that
support the scope(s) in question return reply. If no scope is
specified, all directory agents respond to this request. This exchange
will give the end system a list of all scopes that it can use for scope
membership but this may not be the list of all scopes available on the
users internet. Some scopes may be shielded from registration
and queries using an access control system as described above.
A SA may not register with scopes outside of the SA's internet.
After an end system has picked a scope to use as its default scope it
may ask a directory agent for the list of all available scopes known to
the DA, including those that are not within the user agent's internet.
To get this list the user agent sends a scope list request to the
directory agent.
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 = ScopeRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scope List Request
The directory agent responds with a scope list reply. Every scope
that is available for use to the user agent is listed in the reply.
In addition to the list of all scopes the directory agent also
returns the list of scopes that are outside of the boundaries of
the user agents internet. For each foreign scope the directory agent
returns the scope name and the hosting directory agents' service
instances. Foreign directory agents and scopes maybe used to support
name spaces that are outside of the autonomous domain the user agent
belongs to. Resources within those foreign networks can be found
using the normal service location queries. The propogation of foreign
scopes to directory agents in the user agents multicast perimeter is
outside the scope of this document though global directory services
may provide this service.
Veizades, Kaplan, Guttman [Page 16]
INTERNET-DRAFT Service Location Protocol July-95
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 = ScopeRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of local scopes | number of foreign scopes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Local Scope List> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Foreign Scope List> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scope List Reply
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Name (Typed String) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num of supporting DAs | Service Instance List |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Instance List(cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Foreign Scope
6.6 SCOPE Propagation
User Agents contact their DA for the list of all known scopes both
foreign and local. To build this list of scopes, DAs must propagate
this information from one DA to another. DAs use a multicast address
specific to DAs to propagate this information from one DA to another.
When a new DA comes online it sends a DA scope list request to the DA
multicast address. Other DAs respond using the Scope List Reply with
all the scopes they support both locale and foreign. At the end of
this interaction the DA will know about all available scopes and DAs
which support them.
7.0 Service Information Versions
Service location information can live in three locations: at the
service agent, the directory agent and/or the user agent. A service
agent has the authoritative version of the service information. The
directory agents and the user agents have copies of the service agent's
information. The "information version" provides an indication to the
user and directory agents that the copies that they hold are out of
sync with the authoritative database in the service agent. In addition
to the information version a time to live is set with each reply packet
Veizades, Kaplan, Guttman [Page 17]
INTERNET-DRAFT Service Location Protocol July-95
this value in seconds is the maximum time a value maybe cached
reguardless of the information version. A value of 0 indicated that
information may not be cached.
7.1 Information Versions
For every service instance advertisement, the service agent attaches an
information version to the advertisement. This version number is a way
for the service agent to tag the current state of the information that
it is advertising. When this information changes, the service agent
increments the version. Agents that are caching this information can
ask the service agent for the version of the current service
information.
For very volatile information, which must be gathered each time a
request is made, the service agent implements the value as a
'function'. This means that on replying to each request, the service
agent or directory agent must resolve the function. The version number
does not need to change when the function's resolution value does.
This mechanism allows caching of service information and version state,
even for very volatile information or information which may depend on
the state of transactions within a distributed system. (See section
9.0 for details on function resolution.) SAs may not respond to UAs
with unresolved function values. The information contained in such
replies is very volitile and should not be cached the information
version is set to zero and these replies may not be cached.
7.2 User Agents
When a user agent caches information that it has received from a
service agent or directory agent it should verify the version number is
still valid. It can do this by requesting the service instance's
current version number from the source of the cached information.
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 = VerRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Instance> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Request
Veizades, Kaplan, Guttman [Page 18]
INTERNET-DRAFT Service Location Protocol July-95
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 = VerRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Reply
The information may be invalid for several reasons. The service agent
may not exist, the service instance may no longer exist or the end
system may not be authorized to use the service. Error values are
returned for all the above reasons. When an error is received a user
agent must invalidate the cached information. A user agent may try to
revalidate the information, unicasting the original predicate to the
service agent or may try to reacquire a service provider multicasting
the original predicate.
7.3 Directory Agents
Directory agents must return correct information since they are acting
on behalf of service agents. Service agents must update directory
agents when their databases change. The service agent must unregister
any service instance before any information about the service is
changed. This limits the availability of any incorrect or transient
false advertisements. As soon as the service agent has a new set of
service information to advertise, it reregisters it with the Directory
Agent.
A Directory Agent will still need to verify that the information it is
caching is accurate, as a service agent might have gone down. It can
do this by periodically sending version number requests of services
that it has information cached about. These requests are sent to the
service agent that registered the information.
7.4 Service Agents
Service agents advertise information that they authoritatively own.
When a service agent advertises information, it also indicates the
information version. When the service agent registers with a directory
agent, the service agent is responsible for invalidating the directory
agent's cached state before the information changes at the service
agent. The service agent must then reregister the new information with
the Directory Agent.
8.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.
Veizades, Kaplan, Guttman [Page 19]
INTERNET-DRAFT Service Location Protocol July-95
The response will be received over the same connection. A directory or
service agent indicates an overflow via the overflow flag in the
service location packet header. The operations that can overflow are
the attribute reply, the service reply and service register. This
operation requires the implementation of a reliable byte stream
protocol, like TCP, by the user, service, and directory agents.
9.0 Special Data Types
9.1 Function Resolution
The attribute value of an attribute can be a function. A function is a
handle for a rapidly changing attribute value that must be resolved at
the service agent (e.g. a piece of code that the service agent runs to
determine an attribute like whether a service is on-line). The
function data that is passed to the service agent is an opaque value
that allows the service agent to identify the method to determine the
attribute's value.
The type of any value that is returned in a Function Resolve Reply must
be a basic type: string, integer, boolean or opaque. A function
resolve reply cannot return another function value. A Function Resolve
Reply must have a TTL of zero.
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 = FuncReslvRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Function Resolution Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Function Resolve Request
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 = FuncReslvRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Attr Type | <Attribute> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Attribute> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Function Resolve Reply
9.2 Opaque
The Opaque data type allows for the inclusion of vendor defined data
types. When this data type cannot be resolved by a user agent it
Veizades, Kaplan, Guttman [Page 20]
INTERNET-DRAFT Service Location Protocol July-95
should be ignored. Directory agents should store and pass these
values on unintrepreted. Opaque types are uniquely identified by their
TAG under a given standarization authority.
10.0 Authentication
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.
11.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.
11.1 Single Subnet
If a network is not connected to any other networks simple network
layer broadcasts will work in place of multicast.
11.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
end systems using a protocol like the IP Dynamic Host Configuration
Protocol.
11.3 Service Multicast Address
Each service must have a unique multicast address to which it belongs
to. This multicast address is obtained from the 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.
Veizades, Kaplan, Guttman [Page 21]
INTERNET-DRAFT Service Location Protocol July-95
12.0 Data Element Formats
12.1 Attributes
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 |S| Std. Auth. | num values |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Attribute Class> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Attribute Value> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length The number of bytes in the attribute,
including the length field
S bit set if the attribute is a standard
attribute
Standardization Authority A number assigned to an organization
which defines semantics for attributes.
(Registered with IANA)
Number of Values The number of values returned in the
attribute value field.
Attribute Class <typed string>
Attribute Value <typed string> |
<integer> |
<function> |
<boolean> |
<opaque> |
<distinguished attribute>
Attributes are {class, value} pairs that define a characteristic of a
service. There are three classes of attributes: distinguished
attributes, standard attributes and regular attributes.
A standard attribute is indicated by setting the standard attribute
bit. Standard attributes have a well defined interpretation within
a given standardization authority. Distinguished attributes are
standard attributes in all standardization authorities. A
Veizades, Kaplan, Guttman [Page 22]
INTERNET-DRAFT Service Location Protocol July-95
distinguished attribute is denoted by a standard attribute whose
attribute class is "DIST ATTR". A distinguished attribute is
always the 32 bit multicast address assigned by IANA followed by a
typed string giving the ASCII representation of the distinguished
attribute.
12.2 Service Instance
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 | Num of Addrs. | Addr 1 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr 1 length | <Address 1> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Address 1> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Srv Info Length | <Service Info for Address 1> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Info for Address 1> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr N Type | Addr N length | <Address N> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Address N> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Srv Info Length | <Service Info for Address N> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Info for Address N> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Instance
A service instance is the address of the service in question, the port
of the service access point and any additional service specific
information needed to make the service connection. A service address
is typed to support a variety of network protocols. The service
specific information may be service layer protocol specific information
that facilitates the service rendezvous. When more than one network
interface or protocol is used to support a service on an end system,
multiple addresses can be added to a service instance using the number
of addresses field.
Veizades, Kaplan, Guttman [Page 23]
INTERNET-DRAFT Service Location Protocol July-95
12.3 Addresses
The address types are specified in the assigned numbers RFC. Address
representation will vary from one network protocol to another.
An IPv4 address is represented as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol Bit Array |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the port is the redevous port for the protocol in question
and the protocol is a bit map of which protocols are supported for
connections. When bit 1 (LSB) is set UDP is supported and when bit
two is set TCP is supported.
12.4 Predicate
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Predicate length | <Predicate> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Predicate> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Predicate
Veizades, Kaplan, Guttman [Page 24]
INTERNET-DRAFT Service Location Protocol July-95
13.0 Predicate Language
All values are represented in network byte order.
<predicate> ::= <relational op> <attr class> <attr value> |
<boolean op> <predicate> <predicate>
<relational op> ::= '==' | '!=' | '<'
'>' | '>=' | '<='
<boolean op> ::= '&' (logical AND) | '|' (logical OR)
<attr class> ::= <typed string>
<attr value> ::= <integer> | <typed string> | <function> |
<boolean> | <opaque> |
<distinguished attribute>
<integer> ::= 'I' <int val>
<int val> ::= 4 byte signed quantity
<typed string> ::= 'S' <string type> <len> <string bytes>
<string type> ::= 1 byte value, see 'String Types' below
<len> ::= 2 byte value, counts number of string bytes
<string bytes> ::= If ASCII typed, there is <len> number of
characters. If ISO646 or Unicode string
type, then there are half of <len> in 2
byte characters in the string bytes.
<function> ::= 'F' <resolution>
<resolution> ::= 4 byte unsigned quantity
<boolean> ::= 'B' <bool val>
<bool val> ::= 1 byte quantity, only the first bit in the
field is read. 0 = FALSE, nonzero = TRUE
<opaque> ::= 'O' <len> <opaque val>
<opaque val> ::= a vendor intrepreted sequence of bytes
<distinguished attribute> ::= 'D' <unsigned int> <typed string>
<unsigned int> ::= 4 byte unsigned integer
Veizades, Kaplan, Guttman [Page 25]
INTERNET-DRAFT Service Location Protocol July-95
Example:
The predicate language is expressed in reverse polish notation. A
predicate query reqeusting all printers on the 12'th floor would read
as follows (all quoted characters are ASCII representations of a
one byte value. Otherwise all bytes are to be taken as a literal
decimal values). The example uses 239.56.125.101 as the multicast
address for printers, which is invalid.
Byte boundary
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|'&'|'='|'='|'D'|239| 56|125|101|'S'| 1 | 0 | 9 |'D'|'I'|'S'|'T'|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|' '|'A'|'T'|'T'|'R'|'S'| 1 | 0 | 7 |'P'|'R'|'I'|'N'|'T'|'E'|'R'|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|'='|'='|'S'| 1 | 0 | 8 |'L'|'O'|'C'|'A'|'T'|'I'|'O'|'N'|'S'| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 11|'1'|'2'|'''|'T'|'H'|' '|'F'|'L'|'O'|'O'|'R'|
+---+---+---+---+---+---+---+---+---+---+---+---+---+
14.0 Interesting Constants
UDP and TCP Port Number: 427
Multicast Addresses
General Multicast Address: 224.0.1.22
Directory Agent Multicast Address: 224.0.1.35
String Types
ASCII 1
ISO646 2
Unicode 3
JIS 4
SJIS 5
EUC 6
Error Codes
No Error 0
Other Error 255
Veizades, Kaplan, Guttman [Page 26]
INTERNET-DRAFT Service Location Protocol July-95
15.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.
16.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
[13] P. Mockapetris. "Domain Names - Implementation and Specification".
RFC 1035, NIC. November 1987
Veizades, Kaplan, Guttman [Page 27]
INTERNET-DRAFT Service Location Protocol July-95
[14] S. Deering. "Router Discovery Protocol". RFC 1256, NIC 1991.
[15] The Unicode Standard Version 1.0 Volume 1, Addison-Wesley
Publishing (ISBN 0-201-56788-1). October 1991.
[16] ISO 639:1988 (E/F) "Code for the representation of names of
languages"; ISO, Geneve, 1988.
[17] K. Lunde, "Understanding Japanese Information Processing,"
O'Reilly & Associates, Inc. 1993
17.0 Author's Addresses
John Veizades
TGV, Inc.
101 Cooper St
Santa Cruz, CA 95060
Phone: +1 415 252 8203
Email: veizades@tgv.com
Scott Kaplan
CoroNet Systems Inc.
5150 El Camino Real, Suite C-22
Los Altos, CA 94022
Phone: +1 415 960 3255 x 216
Fax: +1 415 960 3288
Email: scott@coronet.com
Erik Guttman
PeerLogic, Inc.
555 De Haro St., Suite 300
San Francisco, CA 94107
Phone: +1 415 626 4545
Email: guttman@cs.stanford.edu
18.0 Document Expiration
This document expires January 6, 1996
Veizades, Kaplan, Guttman [Page 28]
INTERNET-DRAFT Service Location Protocol July-95
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 [Page 29]
INTERNET-DRAFT Service Location Protocol July-95
ta Tamil
te Tegulu
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 [Page 30]
