draft-veizades-ipng-svrloc-00.txt John Veizades INTERNET-DRAFT FTP Software, Inc. Scott Kaplan FTP Software, Inc. October 18, 1994 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@ftp.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 April 18, 1994 [Page 1] INTERNET-DRAFT Service Location Protocol October-94 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................................................4 5.1 Service Location PDU header..................................4 5.1.1 Version...............................................5 5.1.2 Functions.............................................5 5.1.3 Length................................................6 5.1.4 Error Codes...........................................6 5.1.5 XID...................................................6 5.1.6 Locale................................................6 5.1.7 Flags.................................................6 5.1.8 Authentication Type...................................6 5.1.9 Authentication Length.................................6 5.1.10 Authentication Information............................7 5.2 Distinguished Attribute Request..............................7 5.3 Get Attributes Request and Reply.............................8 5.4 Service Request and Reply....................................9 5.5 Service Attributes Request and Reply........................10 6.0 Directory Agents................................................11 6.1 Introduction................................................11 6.2 Directory Agent Discovery...................................11 6.3 Service Registration........................................12 6.4 Service Unregister..........................................13 6.5 SCOPE Discovery and Use.....................................13 6.6 SCOPE Propogation...........................................15 7.0 Service Information Versions....................................15 7.1 Information Versions........................................15 7.2 User Agents.................................................15 7.3 Directory Agents............................................17 7.4 Service Agents..............................................17 8.0 Server Location Connections.....................................17 9.0 Special Data Types..............................................17 9.1 Function Resolution.........................................17 9.2 Opaque......................................................18 10.0 Authentication.................................................18 11.0 Multicast vs. Broadcast........................................19 11.1 Non-interneted networks...................................19 11.2 Interneted site...........................................19 12.0 Packet formats.................................................20 12.1 Attributes................................................20 12.2 Service Instance..........................................21 12.3 Addresses.................................................21 12.4 Predicate.................................................21 13.0 Predicate Language.............................................22 Veizades, Kaplan [Page 2] INTERNET-DRAFT Service Location Protocol October-94 14.0 Interesting Constants..........................................23 15.0 Acknowledgments................................................24 16.0 References.....................................................24 17.0 Author's Address...............................................25 18.0 Document Expiration............................................25 Appendix A - Technical contents of ISO 639:1988 (E/F)...............26 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 [Page 3] INTERNET-DRAFT Service Location Protocol October-94 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 and a string describing the type of service as its value. These values are 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 [Page 4] INTERNET-DRAFT Service Location Protocol October-94 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 6 the following must be observed. 1. The constants specified in Section 14 must be used. 2. ICMP error messages should not be sent in response to multicast datagrams. The service location protocol uses a multicast request/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. Responses are multicasted at a pseudo-random interval giving other responders the opportunity to see responses and save network traffic by not responding with redundant information. 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 [17] as one of the string data types. Veizades, Kaplan [Page 5] INTERNET-DRAFT Service Location Protocol October-94 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|M| flags | Auth Type | Auth Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 [Page 6] INTERNET-DRAFT Service Location Protocol October-94 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 local 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 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 Authentication Type Service location allows for the support of several styles of authentication. The values for authentication types are specified in Section 14.0. Veizades, Kaplan [Page 7] INTERNET-DRAFT Service Location Protocol October-94 5.1.9 Authentication Length This field declares how many bytes follow in the Athentication Information segment of the header. 5.1.10 Authentication Information The service location protocol makes provisions for the inclusion of authentication information. The service agent may use the authentication information to allow or deny access to the service information. This is not a security architecture for services. The service agent only limits access to service information. Those who rely on this level of access control to secure service access are depending on security through obfuscation (i.e. if I don't tell you where it is, you can't find it). Authorization and access control should also be added to the service access point. User agents should use the provided facility to verify that the sender of the information that they are relying on is an authorized provider of this information. Note that authentication must be provided external to the service location protocol. The inclusion of authentication information is meant to enable the implementation of such a mechanism, not to provide one. 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 same address that it was received on, that is if the request was received on a multicast address the reply is sent to the multicast address. If the system cannot determine the address a datagram was received on it must send the reply 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 5 seconds divided by the number of distinguished attributes the SA is returning in the response. A service -agent should listen to other replies to this request (same XID) and Veizades, Kaplan [Page 8] INTERNET-DRAFT Service Location Protocol October-94 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 10 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 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 Veizades, Kaplan [Page 9] INTERNET-DRAFT Service Location Protocol October-94 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 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 use 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 all service agents 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 Veizades, Kaplan [Page 10] INTERNET-DRAFT Service Location Protocol October-94 predicate. The reply contains the set of all attributes which satisfy the predicate. The reply is unicast to the sender. 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 Service Reply will always come in the same language as the Service Request. 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. 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 Veizades, Kaplan [Page 11] INTERNET-DRAFT Service Location Protocol October-94 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 Attributes | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | \ . \ | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service Reply 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 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. Veizades, Kaplan [Page 12] INTERNET-DRAFT Service Location Protocol October-94 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 an 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 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 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. Veizades, Kaplan [Page 13] INTERNET-DRAFT Service Location Protocol October-94 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 or responds incorrectly, the SA should mark the registration as inactive. When the DA appears again the SA reregisters with the DA. If all the DAs in a scope are inactive the SA should reregister in another scope for it to be made available. A directory agent may cache information registered with it over boot cycles. If it does it must verify this information using the service instance information version (See section 7.0). 6.3 Service Registration After a service agent has found a directory agent, it begins to register its advertised services one at a time. A service agent must wait for some random interval between 0 and 3 seconds between each registration. Registration is done using the Service Registration packet specifying all attributes for a service. A 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 Veizades, Kaplan [Page 14] INTERNET-DRAFT Service Location Protocol October-94 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. 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. Veizades, Kaplan [Page 15] INTERNET-DRAFT Service Location Protocol October-94 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. An end system finds the scopes that are available in a campus by multicastsing 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 maybe shielded for 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. Veizades, Kaplan [Page 16] INTERNET-DRAFT Service Location Protocol October-94 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. 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 Veizades, Kaplan [Page 17] INTERNET-DRAFT Service Location Protocol October-94 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 Agent's contact their DA for the list of all known scopes both foreign and local. To build this list of scopes DA's 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. 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 Veizades, Kaplan [Page 18] INTERNET-DRAFT Service Location Protocol October-94 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 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 user 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 Veizades, Kaplan [Page 19] INTERNET-DRAFT Service Location Protocol October-94 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. 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. Veizades, Kaplan [Page 20] INTERNET-DRAFT Service Location Protocol October-94 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 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 The following discussion of authentication and security is based on premise that a security and authentication policy has been implemented for the site. The service location protocol can function independent of any site-specific authentication policy. The security and authentication policies need to address three areas; data integrity, data origin authentication and data confidentiality. That is to say that the data that is advertised has not been subject to tampering, that the origin of the advertised information can be corroborated and that the data advertised can be protected from unauthorized viewing. Service location does not make any provisions for protection from unauthorized viewing of data and it is left to the network layer of the protocol to support this functionality. A service can place restrictions on information that is given out to user agents and this level of security should be maintained when this information is registered with a directory agent. A service agent also needs some level of assurance that the directory agent is a trusted Veizades, Kaplan [Page 21] INTERNET-DRAFT Service Location Protocol October-94 entity. Any security mechanism that is used with service location should allow the service agent to verify that the directory agent is authorized to act upon its behalf. This security mechanism should also allow for the directory agent to verify that the service agent is a valid source for the information that it is providing. From the user agent's perspective it must be able to verify that the directory agent is an authoritative source of information and in turn the directory agent must confirm that the user agent is a valid member of the community. All these functions can be implemented using the authentication architecture with-in service location using one of the many authentication schemes already in place, i.e., Kerberos, MD5, etc. The authentication information included in the packet's header as well as the sender and receiver's address will be used as parameters for these authentication protocol. 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. Veizades, Kaplan [Page 23] INTERNET-DRAFT Service Location Protocol October-94 12.0 Packet 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 distinguished attribute is denoted by a standard attribute whose attribute class is "DIST ATTR". A distinguished attribute is always an ASCII type string. Veizades, Kaplan [Page 24] INTERNET-DRAFT Service Location Protocol October-94 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. | Addr1 Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Addr1Type(cont)| 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 [Page 25] INTERNET-DRAFT Service Location Protocol October-94 12.3 Addresses Where addresses are specified they are specified using the following notation: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Type | Addr Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \
(cont.) \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address The address types are specified in the constants section of this document. 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 13.0 Predicate Language ::= | ::= '==' | '!=' | '<' '>' | '>=' | '<=' ::= '&' (logical AND) | '|' (logical OR) ::= ::= | | | | ::= 'I' ::= 4 byte signed quantity Veizades, Kaplan [Page 26] INTERNET-DRAFT Service Location Protocol October-94 ::= '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 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): Byte boundary 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |'&'|'='|'='|'S'| 1 | 0 | 9 |'D'|'I'|'S'|'T'|' '|'A'|'T'|'T'|'R'| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |'S'| 1 | 0 | 7 |'P'|'R'|'I'|'N'|'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'| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Veizades, Kaplan [Page 27] INTERNET-DRAFT Service Location Protocol October-94 14.0 Interesting Constants UDP and TCP Port Number: 427 Multicast Addresses General Multicast Address: To be detirmined Directory Agent Multicast Address: To be detirmined Address Types See Assigned Numbers String Types ASCII 1 ISO646 2 Unicode 3 Error Codes No Error 0 Other Error 255 Authentication Types None 0 MD2 1 MD4 2 MD5 3 Kerberos 4 RSA 5 Plain Text 6 Unix 7 Veizades, Kaplan [Page 28] INTERNET-DRAFT Service Location Protocol October-94 15.0 Acknowledgments This protocol owes some of the original ideas to other service location protocols found in many other networking protocols. Leo McLaughlin (FTP) and Mike Ritter (Apple) provided much input into early version of this document. Thanks also to Steve Deering (Xerox) for providing his insight into distributed multicast protocols. Also thanks to Erik Guttman (FTP) for his assitance in finalizing the specification. 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] Galvin, J., McCloghrie, K., "Security Protocols for version 2 of the Simple Network Management Protocol", RFC 1446, NIC, April 1993. [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, NIC, April 1992. [6] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, M.I.T. Laboratory for Computer Science, August 1993. [7] Accetta, M. "Resource Location Protocol", RFC 887, NIC, December 1983. [8] Legato Systems, "The Legato Resource Administration Platform", Legato Systems, 1991. [9] C. McManis and R. Rom, "The Zeus Name Service Architecture", Sun Microsystems, 1990. [10] S. Dyer, "The Hesiod Name Server", Winter Usenix Conference, pp. 183-187, Feb 1988. [11] 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. [12] B. Lampson, "Designing a Global Name Service", Proceedings of the 5th ACM Symposium on Principles of Distributed Computing, pp. 1-10, 1986. [13] D. Cheriton and T. Mann, "Uniform Access to Distributed Name Interpretations in the V-system". Veizades, Kaplan [Page 29] INTERNET-DRAFT Service Location Protocol October-94 [14] S. Deering. "Router Discovery Protocol". RFC 1256, NIC 1991. [15] P. Mockapetris. "Domain Names - Concepts and Facilities". RFC 1034, NIC, November 1987 [16] P. Mockapetris. "Domain Names - Implementation and Specification". RFC 1035, NIC. November 1987 [17] The Unicode Standard Version 1.0 Volume 1, Addison-Wesley Publishing (ISBN 0-201-56788-1). October 1991. [18] ISO 639:1988 (E/F) "Code for the representation of names of languages"; ISO, Geneve, 1988. 17.0 Author's Addresses John Veizades FTP Software, Inc. 785 Market St. 12th Floor San Francisco, CA 94103 Phone: +1 415 978 2236 Fax: +1 415 543 9002 Email: veizades@wco.ftp.com Scott Kaplan FTP Software, Inc. 785 Market St. 12th Floor San Francisco, CA 94103 Phone: +1 415 978 2204 Fax: +1 415 543 9002 Email: scott@wco.ftp.com 18.0 Document Expiration This document expires January 18, 1995 Veizades, Kaplan [Page 30] INTERNET-DRAFT Service Location Protocol October-94 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 [Page 31] INTERNET-DRAFT Service Location Protocol October-94 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 [Page 32]