HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 08:34:25 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 07 Jul 1995 22:00:00 GMT ETag: "323bf0-11d22-2ffdae60" Accept-Ranges: bytes Content-Length: 72994 Connection: close Content-Type: text/plain 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ (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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ (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| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ (cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | \ . \ | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ (cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ (cont) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Attributes | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | \ . \ | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ (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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ (cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Attribute Value | | | | | 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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \
(cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Srv Info Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ (cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr N Type | Addr N length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \
(cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Srv Info Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ (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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ (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. ::= | ::= '==' | '!=' | '<' '>' | '>=' | '<=' ::= '&' (logical AND) | '|' (logical OR) ::= ::= | | | | | ::= 'I' ::= 4 byte signed quantity ::= 'S' ::= 1 byte value, see 'String Types' below ::= 2 byte value, counts number of string bytes ::= If ASCII typed, there is number of characters. If ISO646 or Unicode string type, then there are half of in 2 byte characters in the string bytes. ::= 'F' ::= 4 byte unsigned quantity ::= 'B' ::= 1 byte quantity, only the first bit in the field is read. 0 = FALSE, nonzero = TRUE ::= 'O' ::= a vendor intrepreted sequence of bytes ::= 'D' ::= 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]