[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 05 06 07 08 09 10 11 12 13 14 15 16 RFC 2165

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/