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