Network Working Group M. Urue±a Internet-Draft D. Larrabeiti Expires: September 15, 2004 UC3M March 17, 2004 Overview of the eXtensible Service Discovery Framework (XSDF) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document provides an overview of the eXtensible Service Discovery Framework (XSDF). It defines a collection of extensible protocols and agents for the dynamic location of network services. XSDF Service Discovery Framework is scalable and can be deployed from unmanaged LANs up to Internet-wide Service Location. XSDF also provides several mechanisms to select among the available services discovered. This allows service providers to implement load sharing or active/backup policies among multiple servers providing the same service. Urue±a & Larrabeiti Expires September 15, 2004 [Page 1] Internet-Draft XSDF Overview March 2004 1. Introduction Service Discovery term refers to the process that allows an User to find a Service. In particular, the main information to be discovered for network Services is its location, that is, the combination of network addresses of the server which is running that Service instance, and a transport protocol port where the Service process is listening. Until the day in which Service Discovery Frameworks will be widely deployed, clients need to known just the hostname of the server providing such Service, as most Services employ well-known ports. This situation requires User's workstation to be pre-configured with the name of the servers providing network Services. This approach lead to high administrative costs, specially when adding new Services to the network. When clients are mobile and connect to several networks, manual configuration becomes a real issue. That is the rationale behind the development of Service Discovery Frameworks. This document provides an overview of the eXtensible Service Discovery Framework. XSDF defines a collection of application protocols and entities, aimed to manage information about network Services as its existence, location, and management data. XSDF is an evolution of the Service Location Protocol (SLP) [1]. It also tries to be compliant with the requirements [4] defined by the Reliable Server Pooling (Rserpool) Working Group. The main features of XSDF and its differences with SLP are: Enhanced Service Model: SLP describes a Service with an URL and a set of attribute-value pairs. Also, SLP services are identified by its URL, which is known to be the source of some problems [5]. In XSDF, services are identified by an UUID [6] and could be defined by employing an extensible hierarchical representation data model. Internet-wide location: SLP was designed for Service Discovery in Local Area Networks inside a single administrative domain. XSDF has been designed to allow Service Discovery from remote sites by querying public Service Directory Agents advertised in DNS SRV Resource Records [3]. Load balancing: Although Service selection is an important step in the Service Discovery process, SLP does not provide a standard mechanism to choose the best service located. XSDF includes the service selection model of Rserpool thus enabling common selection mechanisms as load balancing or primary/backup servers. Such selection process can be done both, by the end hosts and by the XSDF Directory Agents. As XSDF Agents are themselves Services, Urue±a & Larrabeiti Expires September 15, 2004 [Page 2] Internet-Draft XSDF Overview March 2004 they can employ the XSDF Framework to discover other low loaded XSDF Agents. End-to-End solution: As end clients are aware of the different servers from a pool, they can connect directly to the chosen one. Therefore there is not need of stateful middleware, as in other solutions like L4/L7 switches. High Availability: Once deployed, Service Discovery may became a critical component of the Network. XSDF defines the XSTP/XSSP protocols to provide a scalable and highly available Service repository distributed among multiple DAs sharing a common Realm. Zero Configuration: As in SLP, neither UAs nor SAs need to be configured with the location of DAs. XSDF may also bootstrap by employing multicast searches and DA advertisements. However, as DAs are Services themselves, XSDF does not require special messages for DA Discovery. In a XSDF capable network, a client does not need to know any Service but IP connectivity (via DHCP or IPv6 autoconf.). Then, it may be able to obtain any kind of Service information, for example the local DNS server. As in SLP, XSLP only handles Service Discovery (and additionally Service selection). Once an UA choose one Service, it will employ any other protocol outside of the scope of XSDF (unless it was also a XSDF Service, of course). XSDF will just provide the location and protocol information to begin further Service communication. This document does not contain the specification of XSDF protocols but an overview of the XSDF Framework. XSDF protocols are defined in separate documents. See [8] for a detailed description of common XSDF procedures and data structures. 1.1 Definitions Domain: A Domain is a single administrative organization containing Users and Services. Scope: A Scope is a subset of Users and Services from a Domain, typically making a logical administrative group. Realm: A Realm is a combination of a Domain and one or more Scopes from such Domain, if any. Service: A Service is any process attached to a network that provides some kind of functionality to Users or other Services. A Service belongs to a single Realm. Urue±a & Larrabeiti Expires September 15, 2004 [Page 3] Internet-Draft XSDF Overview March 2004 User Agent (UA): A process working on the User's (or other process) behalf to discover Services, and select the best available one. UAs obtain Service information from Directory Agents and Service Agents via XSLP. Service Agent (SA): A Service Agent is itself a Service that advertise Service information on behalf other processes. SAs are queried by User Agents for Services via XSLP, and/or register Service information in Directory Agents employing XSRP. Directory Agent (DA): A Directory Agent is a Service that, when deployed, acts as a central repository of all Service information from a Realm. Service Agents register its Services in a DA employing the XSRP protocol. Then, User Agents are able to query that information with XSLP. An Scope can be served by multiple DAs that coordinate themselves via XSSP & XSTP protocols. XSDF Agent: Any process that employs any XSDF protocol to interact with other XSDF Agents. Depending on the protocol a XSDF Agent may behave as a client or as a server (i.e. becoming itself a Service). Urue±a & Larrabeiti Expires September 15, 2004 [Page 4] Internet-Draft XSDF Overview March 2004 2. Architecture A XSDF Framework is formed by multiple XSDF Agents and several protocols to communicate them. Each of these protocols deals with a different part of the Service Discovery process. The XSDF protocols are: eXtensible Service Location Protocol (XSLP): User Agents employ this protocol to get Service information from Service Agents and/or Directory Agents. Please note that a SA or a DA can behave as an UA and query other SAs/DAs for XSDF Service information. XSLP protocol specification can be found at [9]. eXtensible Service Register Protocol (XSRP): When a Scope is served by one or more Directory Agents, Service Agents register Service information in such DAs, thus aggregating all Services of the Scope in a central cache. XSRP is the protocol employed by SAs to register Service information in a DA. XSRP protocol specification can be found at [10]. eXtensible Service Subscription Protocol (XSSP): This protocol allows a XSDF Agent to subscribe itself to any changes made to Service information by registering a notification channel. All changes affecting the specified subscription are sent through that channel. Directory Agents with common Scopes employ this protocol to be subscribed to Service registration operations from those Scopes. XSSP protocol specification can be found at [11]. eXtensible Service Transfer Protocol (XSTP): In order to achieve high availability or just scalability, a single Scope can be served by several Directory Agents. Those DAs employ the XSTP protocol to obtain the Services known by the other DAs, and to notify subscribed Services with XSRP operations affecting Service information registered in the common Scope. XSTP protocol specification can be found at [12]. All XSDF protocols are quite simple client-server ones. That allows UAs, and specially SAs, to be implemented in embedded platforms with low processing power. XSDF messages may be encoded with any suitable encoding mechanism for hierarchical structured data, as XML does. However, XBE32 [7] binary encoding is preferred as it is more compact, and can be more easily parsed than plain XML. Urue±a & Larrabeiti Expires September 15, 2004 [Page 5] Internet-Draft XSDF Overview March 2004 This figure provides an overview of the XSDF architecture and its protocols: +----+ XSLP +----+ XSTP +----+ XSRP +----+ | UA | ----> | DA | <----> | DA | <---- | SA | +----+ XSSP +----+ XSSP +----+ +----+ | ^ | XSLP | +----------------------------------------+ The main objective of the XSDF Framework is that User Agents were able to obtain information about available Services. Such information is maintained by the Service Agents. In small scenarios, UAs are able to query SAs for the services via XSLP multicast queries. In bigger networks, there is an intermediate Service information broker called Directory Agent. A DA does not generate Service information but only acts as a central cache of Service information. SAs periodically refresh Service information in DAs via XSRP, in order that UAs ask them for such information via unicast XSLP. When multiple DAs handle the same collection of Services, all DAs need to have the same information in order to provide the same view to UAs. In that case, DAs employ: XSTP to acquire Service information from other DAs, and XSSP to be subscribed to changes in other DA's Services in order to quickly apply those changes to its own Service cache. 2.1 Realm Model As SLP, XSDF employs the Scope mechanism to aggregate Services and Users in administrative groups. Therefore, User searches are restricted to Services from its own group. XSDF adds the "Domain" object to allow remote Service Discovery. A Realm is a combination of a domain (if any) and one or more Scopes. XSDF Agents must be configured with a Realm, although UAs may search for Services in other Realms, that is, from remote Domains. Each organization will define Scopes tailored to its needs. However, the XSDF Framework defines three default Scopes: DEFAULT: By default all Services belong to the "DEFAULT" Scope and have no Domain. This well-known Scope is useful for unmanaged networks. Urue±a & Larrabeiti Expires September 15, 2004 [Page 6] Internet-Draft XSDF Overview March 2004 LOCAL: Services that belong to this Scope, are only meaningfully to the local server. For example managing Services as SNMP or SSH/ Telnet. PUBLIC: Public services from remote domains belong to the Realm with the specified DNS domain and a "PUBLIC" Scope. In order to simplify SA and UA implementation, DAs of the same Scope behave as a single repository, thus a Service can be registered in a single DA but be available by querying any other DAs of the same Scope. Please notice that, this description only applies to XSDF Agents in the same Scope. As a XSDF Agent may belong to several Scopes, it should handle each Scope as a separate environment. A XSLP +----+ XSRP +---------------> | DA | <---------------+ | +----+ | | B B | +----+ XSLP +----+ XSTP +----+ XSRP +----+ A,B,C | UA | ----> | DA | <----> | DA | <---- | SA | A,B,C +----+ +----+ XSSP +----+ +----+ | ^ | XSLP | +----------------------------------------+ For example, in the above figure, the SA has Services from 3 different Scopes (A, B, C). It should register Services from the first one at the single DA that manages that Scope. Services from Scope B could be registered at any of the two DAs which serve Scope B. Finally, SA should reply to direct UA requests from the last Scope as there is no DA managing that Scope. The same applies to XSLP queries from UAs. If an UA wants to fetch Services from all the Scopes, it will need to send unicast requests to DAs managing those Scopes and a Multicast request to query SAs from the unmanaged C Scope. Also, only the two DAs sharing the B Scope will employ XSTP/ XSSP to keep Service information in sync. 2.2 Service Model In SLP, a Service is defined by an URL and a set of attribute-value pairs. In Rserpool, Service information carries one or more transport protocol identifiers, that is, a port and one or more IP address per transport protocol, along with selection policy information. XSDF Service model mix both approaches with a single extensible representation. Service information is divided in four parts: Urue±a & Larrabeiti Expires September 15, 2004 [Page 7] Internet-Draft XSDF Overview March 2004 Service Identifier: All Services are identified by a single UUID, which is unique inside a Domain. Service State: This refers to the volatile information about the Service that cannot be cached for long time. A good example of State information is the workload of the server. Also, Service State includes version information of other Service information. Service Main Information: This information defines the Type of the Service, its selection policy, and other important Service-dependent information. Service Location Information: In order to establish a connection with a network Service, clients need to known its attachment point to the network and the available protocols to access to the Service. Location information specifies data such as its IP addresses, transport ports and configured application protocols. Service Additional Information: While previous information allows automatic Service Discovery, the so called Additional Information contains data intended for human consumption as a textual description of the Service or the mail address of the Service administrator. When requesting Service information, an UA may specify which kind of information it is interested in. This allows automatic UAs to download just Service State, Main and Location Information to choose a Service, and later just check the State to see if Service information need to be updated. All without downloading the Additional information that may be quite long as it is very verbose for human consumption. 2.3 Cache Model In the XSDF Framework, Service information can be stored in multiple places. That information is generated and maintained by Service Agents and no other XSDF Agent but the home SA should modify Service Information. Thus, the only authoritative source of information about a Service instance is the home SA. Then, to improve network performance, that information may be cached by the other two XSDF Agents: UAs and DAs. Service Agents assigns a lifetime to its Service information. This lifetime specifies the amount of time that Service data is expected to remain valid. Therefore, Service information may be cached by UAs only until the lifetime period expires. A Directory Agent is just a central cache for Service information. Urue±a & Larrabeiti Expires September 15, 2004 [Page 8] Internet-Draft XSDF Overview March 2004 When a SA registers a Service in the DA via XSRP, it specifies the expected Lifetime of that information. When an UA requests Service information to the DA via XSLP, DA reply also contains the Age an the Time To Live of that information. Age is the amount of time Service information has been cached in the DA before the reply was generated. Time To Live is the amount of time left that Service information can be cached in the client. That is, time to live equals the lifetime of the Service minus its DA cache age. Whenever a SA refresh Service information cached in the DA, age is set to zero and time to live is set to the specified lifetime value. Lifetime value configures the UA cache behavior. However, Service information cached in DAs may be flushed before its lifetime expires if not refreshed by the home SA. When a Service registration/update is acknowledged, DA specifies the "minLife" and "maxLife" values for next update. SAs should update Service information before "maxLife" time expires but after "minLife". This mechanism has been designed to avoid Service update storms from SAs to DAs. It also allows DAs to cache, for "maxLife" milliseconds, Service information with zero lifetime, that is, that should not be cached by UAs. lifetime +----+ age/ttl +----+ <-------- +----+ | UA | <-------- | DA | XSRP | SA | +----+ XSLP +----+ --------> +----+ min/maxLife XSSP subscriptions follow the same minLife-maxLife mechanism to "cache" subscription information. If a subscription is not refreshed before maxLife, that subscription is deleted and further notifications are not sent to subscription's notification channel. 2.4 Selection Model When an UA requests Service information via XSLP, it can found several Service instances that fit its needs. In that case, some kind of selection process should happen. For example, a list of all Services (for example printers) could be shown to the user who chooses one of them. For Services that allows automatic selection, XSDF provides a version of the selection model from Rserpool. Each Service Type may have an associated selection policy. Also, each Service instance may provide some kind of metric about the "goodness" of the Service. XSDF allows each Service Type to define its own selection policy and Urue±a & Larrabeiti Expires September 15, 2004 [Page 9] Internet-Draft XSDF Overview March 2004 related metrics. But defines the following selection policies that must be supported by all XSDF implementations: Round Robin: This policy states that each time a client wants to access a Service, it chooses a different one. Services may have an associated "weight" information, thus Service instances with greater "weight" should be accessed proportionality more times than servers with lower "weight" values. Least Used: Services with this policy indicate that clients should access to servers with the lowest "workload" state value. Most Resources: Services with this policy tell clients that they should access to servers with the greatest "resources" state value. Closest: Services with this policy tell clients that they should access to servers with the lowest latency from its point of view. Of course, if the selected Service is offline or has zero "resources" left, clients should try the next discovered one, sorted by the selection policy in use. Along with the "weight", "workload" and "resources" values, XSDF defines a fourth selection metric that is applied to before other selection policies: "priority". When two Services of the same type have different "priority" value, clients should access to the Service with the greatest one. Only if the Service with the greatest priority is offline, clients are able to access the next Service with greater priority. When two or more Services have the same priority, one of them is chosen following the associated selection policy. Unlike ASAP, where selection process is always performed in the client side, in XSDF selection process could be done by the UA, the DA or both. SAs may include selection information inside the Service information in order that UAs choose the best discovered Service. Also SAs may specify in the XSRP Service registration, Selection information for the DA. In that case, DA sorts the registered Services from the same Type and, when an UA requests Service information, the DA may provide just the better Services. A SA may provide the first, second or both kinds of selection data, which also can be different. Urue±a & Larrabeiti Expires September 15, 2004 [Page 10] Internet-Draft XSDF Overview March 2004 3. Applicability Statement XSDF could be deployed in a broad set of scenarios, from unmanaged LANs to big Enterprise Networks and even in Internet. As each network has its own requirements, each scenario will need to deploy all kind of XSDF agents and protocols or just a subset of them. 3.1 Unmanaged Networks The first scenario is a single LAN that has little or no server infrastructure (i.e. no DNS server), for example a SOHO were there are only only client stations, or home appliances. Scopes: DEFAULT DEFAULT DEFAULT +----+ +----+ +----+ | UA | | SA | ... | SA | +----+ +----+ +----+ | ^ ^ | XSLP | | +-------------+----------+ In this scenario, XSDF Service Discovery can be achieved just by deploying User Agents and Service Agents at the same "DEFAULT" scope. Then, XSLP protocol is employed to perform multicast/broadcast searches. If multiple Services are found, selection process will be performed by UAs. 3.2 Small Network The second scenario is a network with multiple LANs where multicast searches are too inefficient. In that case, a Directory Agent should be deployed. Therefore Service Agents should employ XSRP to register its Services in the DA. Scopes: A A A XSLP +----+ XSRP +----+ +-------> | DA | <---- | SA | +----+ +----+ +----+ | UA | +----+ +----+ +----+ +-------> | DA | <---- | SA | XSLP +----+ XSRP +----+ Scopes: B B B If the number of Services and Users is small, all XSDF agents may belong to the same Scope. Otherwise, multiple Scopes could be defined. Those Scopes could be managed by a single DA or by several ones but each DA only handles one Scope. As UAs ask DAs for Services, Urue±a & Larrabeiti Expires September 15, 2004 [Page 11] Internet-Draft XSDF Overview March 2004 selection process could be done at the DA. Thus, DA may reply to the UA with the Service list ordered by server workload. 3.3 Enterprise Network The last scenario is an Enterprise network were there are many subgroups of Users and Services and also critical Services rely on XSDF Service Discovery. Therefore, both scalability and high availability of the XSDF Service is required. Scopes: AB AB AC AC +----+ XSLP +----+ XSTP +----+ XSRP +----+ | UA | ----> | DA | <----> | DA | <---- | SA | +----+ XSSP +----+ XSSP +----+ +----+ In an Enterprise network, there will be multiple Scopes, and Scopes with critical Services will be handled by two or more DAs. In that case all XSDF protocols will be deployed. XSTP and XSSP will allow DAs with common Scopes to share its Service information and provide a common view to UAs and SAs. Selection process could not only be done in the DAs, but also in the UAs in order to quickly react to server failures. 3.4 Internet XSDF can be also employed to advertise public Services in Internet. For example a pool of Web servers may employ XSDF to achieve load balancing. This could be done by deploying public available DAs managing the pool Services with "PUBLIC" Scope, and advertising such DAs in the DNS server of the organization. 1. SRV RR? +-----+ Server +------------------>| DNS | Pool | +-----+ +----+ | +----+| +----+ 2. XSLP +----+ XSTP +----+ XSRP +----+|+ | UA | -------> | DA | <----> | DA | <---- | SA |+ +----+ +----+ XSSP +----+ +----+ Scopes: PUBLIC PUBLIC PUBLIC In this scenario, an UA willing to contact a Service from the "example.com" Domain first will ask for the "_xslp._udp.example.com" DNS SRV Resource Record. This record will contain a list of the preferred public DAs. Then, the UA is able to ask, via XSLP, for the desired Service (i.e. www) in the "PUBLIC" Scope. At last, the DA will reply with the least-loaded, available servers. Urue±a & Larrabeiti Expires September 15, 2004 [Page 12] Internet-Draft XSDF Overview March 2004 4. Security considerations XSDF security model is based on the Realm concept. Services and Users belong to Realms. Therefore an User (i.e. an UA) should access only to Service information from its own Realm. The same applies to other XSDF Agents, SAs should register Services only at DAs from compatible Realms. These authorization relationships are defined by each protocol. For example, an User from a Realm should access via XSLP to Service information from that Realm, however he must not be able to deregister those Services via XSRP. Some Scopes may be public, and any User from other domains may be able to obtain information via XSLP. However, others Scopes could be restricted and must require authorization in order to grant access. In that case, XSDF Agents should be authenticated in order to check their access rights. XSDF relies on IPSec and TLS to provide authenticated and secure protocol message exchange among XSDF Agents. However, XSDF has some security mechanisms that should be employed when not provided by lower layers (i.e. SCTP already provides a Cookie mechanism). 4.1 Cookie mechanism XSDF provides a simple Cookie mechanism to reduce the risk of Denial of Service (DoS) attacks. A XSDF server Agent may reject any request message without processing it with a reply error message that carries a Cookie value. In that case, the client should reissue the same message but including this Cookie value. Once a valid Cookie is received by the XSDF server, it may process the included operations. This mechanism does not prevent DoS attacks but made it harder to perform attacks with spoofed IP addresses. 4.2 EAP Authentication XSDF provides two kinds of authentication, first one is suitable for User authentication while the other one allows Server messages to be authenticated. Users may be authenticated employing EAP [2] messages. The process is very similar to the Cookie mechanism. When an unauthenticated user wishes to request a message from a restricted Scope, the XSDF server Agent may reject that message without processing it. The reply error message will carry an EAP request message, for example a MD5-Challenge. Then, the client will employ the requested authentication mechanism and return the EAP response along with the original XSDF requests. Urue±a & Larrabeiti Expires September 15, 2004 [Page 13] Internet-Draft XSDF Overview March 2004 Once properly authorized, XSDF server Agent would perform the requested operations. 4.3 Public Key Signature The above mechanism may be suitable for, shared secret based, user authentication. However, in order to provide server message authentication (i.e. DA advertisement), public key signatures are a better mechanism. XSDF messages may contain a Signature Information Element. That element contains a digest of the message, encrypted with the XSDF Agent private key. Therefore, any XSDF Agent with the public key of the source one may check if the message is valid and has been generated by the claimed XSDF Agent. When XSDF is deployed in insecure environments, all User Agents must know (or obtain via other mechanisms) the public keys of the Directory Agents from its Realm, in order to validate DA Advertisements. Otherwise, is very easy to advertise a rogue DA and compromise the security of, not only XSDF, but other types of Services obtained via XSDF. For example, a rogue DA may carry out a DoS attack by answering to all XSLP request with an empty Service list. Even worse, it may reply with rogue Services that perform man-in-the-middle attacks to Users and real Services. 5. Acknowledgements The eXtensible Service Discovery Framework is an evolution of the one defined by the Service Location Protocol, and owes many of the ideas discussed at the Srvloc Working Group. Besides, XSDF tries to cover some of the requisites defined by the Rserpool Working Group, thus it has also benefited from their efforts. Therefore, we wish to thank all the RFC and draft authors from both communities, including Erik Guttman, Weibin Zhao, James Kempf, John Loughney, Maureen Stillman, Quiaobing Xie, Randall Stewart, Michael Tuexen, and many others. Urue±a & Larrabeiti Expires September 15, 2004 [Page 14] Internet-Draft XSDF Overview March 2004 References [1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [2] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [4] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J. and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002. [5] Guttman, E., "The serviceid: URI Scheme for Service Location", draft-guttman-svrloc-serviceid-02 (work in progress), August 2002. [6] Mealling, M., "A UUID URN Namespace", draft-mealling-uuid-urn-03 (work in progress), March 2004. [7] Urue±a, M. and D. Larrabeiti, "eXtensible Binary Encoding (XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004. [8] Urue±a, M. and D. Larrabeiti, "eXtensible Service Discovery Framework (XSDF): Common Elements and Procedures", draft-uruena-xsdf-common-00 (work in progress), March 2004. [9] Urue±a, M. and D. Larrabeiti, "eXtensible Service Location Protocol (XSLP)", draft-uruena-xslp-00 (work in progress), March 2004. [10] Urue±a, M. and D. Larrabeiti, "eXtensible Service Registration Protocol (XSRP)", draft-uruena-xsrp-00 (work in progress), March 2004. [11] Urue±a, M. and D. Larrabeiti, "eXtensible Service Subscription Protocol (XSSP)", draft-uruena-xssp-00 (work in progress), March 2004. [12] Urue±a, M. and D. Larrabeiti, "eXtensible Service Transfer Protocol (XSTP)", draft-uruena-xstp-00 (work in progress), March 2004. Urue±a & Larrabeiti Expires September 15, 2004 [Page 15] Internet-Draft XSDF Overview March 2004 Authors' Addresses Manuel Urue±a Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 87 95 EMail: muruenya@it.uc3m.es David Larrabeiti Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 99 53 EMail: dlarra@it.uc3m.es Urue±a & Larrabeiti Expires September 15, 2004 [Page 16] Internet-Draft XSDF Overview March 2004 Appendix A. Example of a 'printer' Service A.1 XML Encoding 8e9d7823-d5ac-497c-91d0-fb07ea0c3fb2 f85444f4eb 0 printer Alice's printer Least Used (0x0002) 14 false true 169.254.85.139 fe80::202:b3ff:fe3c:da7a ipp tcp/631, sctp/631 lpr tcp/515, sctp/515 Acme Laser Printer 2000 http://www.acme.com/printers/lp200.html Urue±a & Larrabeiti Expires September 15, 2004 [Page 17] Internet-Draft XSDF Overview March 2004 A.2 XBE32 Encoding 01000284 35110014 8e9d7823 d5ac497c ....5... ...#..I| 91d0fb07 ea0c3fb2 01100020 0111000f ......?. ... .... 331a000c 000000f8 5444f4eb 0311000c 3....... TD...... 32320008 00000000 0120006c 0121000f 22...... . .l.!.. 2812000b 7072696e 74657200 28140013 (...prin ter.(... 416c6963 65277320 7072696e 74657200 Alice's printer. 03210014 31330008 00020000 32350008 .!..13.. ....25.. 0000000d 10000018 20020009 636f6c6f ........ ...colo 72000000 30020005 00000000 10000018 r...0... ........ 2002000a 6475706c 65780000 30020005 ...dupl ex..0... ff000000 01300054 01310020 32150008 .....0.T .1. 2... a9fe558b 35160014 fe800000 00000000 ..U.5... ........ 0202b3ff fe3cda7a 01320018 28610007 .....>.z .2..(a.. 69707000 321a000c 00060277 00840277 ipp.2... ...w...w 01320018 28610007 6c707200 321a000c .2..(a.. lpr.2... 00060203 00840203 0140008c 2867001b ........ ....(g.. 41636d65 204c6173 65722050 72696e74 Acme Las er Print 65722032 30303000 2868002c 68747470 er 2000. (h.,http 3a2f2f77 77772eb1 636d652e 636f6d2f ://www.a cme.com/ 7072696e 74657273 2f6c7032 3030302e printers /lp2000. 68746d6c html Urue±a & Larrabeiti Expires September 15, 2004 [Page 18] Internet-Draft XSDF Overview March 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Urue±a & Larrabeiti Expires September 15, 2004 [Page 19] Internet-Draft XSDF Overview March 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urue±a & Larrabeiti Expires September 15, 2004 [Page 20] Network Working Group M. Urue±a Internet-Draft D. Larrabeiti Expires: September 15, 2004 UC3M March 17, 2004 eXtensible Service Discovery Framework (XSDF): Common Elements and Procedures Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines the common Attributes and Elements employed by the eXtensible Service Discovery Framework (XSDF) protocols. It defines the data elements employed to encode Service information, as well as the common procedures and operations for all XSDF protocols. For example it includes the XSDF Agent initialization process, and details the rules for the creation, transmission, reception and processing of XSDF protocols' messages. Urue±a & Larrabeiti Expires September 15, 2004 [Page 1] Internet-Draft XSDF: Common Elements & Procedures March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Notation Conventions . . . . . . . . . . . . . . . . . . . 5 2. User Element . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Description Element . . . . . . . . . . . . . . . . . . . 6 3. Service Element . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Service State Element . . . . . . . . . . . . . . . . . . 8 3.1.1 Meta-Information Element . . . . . . . . . . . . . . . 9 3.1.2 Selection State Element . . . . . . . . . . . . . . . 10 3.2 Service Main Information Element . . . . . . . . . . . . . 11 3.2.1 Service Type Element . . . . . . . . . . . . . . . . . 12 3.2.2 Selection Information Element . . . . . . . . . . . . 13 3.3 Service Location Information Element . . . . . . . . . . . 15 3.3.1 Inet Element . . . . . . . . . . . . . . . . . . . . . 15 3.3.2 Protocol Element . . . . . . . . . . . . . . . . . . . 17 3.4 Service Additional Information Element . . . . . . . . . . 18 3.4.1 Icon Element . . . . . . . . . . . . . . . . . . . . . 20 3.4.2 Naming Authority Element . . . . . . . . . . . . . . . 21 4. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 22 4.1 Header Element . . . . . . . . . . . . . . . . . . . . . . 22 4.1.1 Realm Element . . . . . . . . . . . . . . . . . . . . 23 4.1.2 Endpoint Element . . . . . . . . . . . . . . . . . . . 25 4.1.3 Authentication Information Element . . . . . . . . . . 25 4.2 Error Element . . . . . . . . . . . . . . . . . . . . . . 26 4.3 Ignore Message Element . . . . . . . . . . . . . . . . . . 28 4.4 Signature Information Element . . . . . . . . . . . . . . 28 4.5 Common Operation Parameters . . . . . . . . . . . . . . . 30 4.5.1 Realm Target Element . . . . . . . . . . . . . . . . . 30 4.5.2 Services Filter Element . . . . . . . . . . . . . . . 30 4.5.3 Update Information Element . . . . . . . . . . . . . . 31 4.5.4 Cache State Element . . . . . . . . . . . . . . . . . 32 5. Common Procedures . . . . . . . . . . . . . . . . . . . . . . 33 5.1 XSDF Agent initialization . . . . . . . . . . . . . . . . 33 5.2 Message generation . . . . . . . . . . . . . . . . . . . . 34 5.2.1 Creating new messages . . . . . . . . . . . . . . . . 34 5.2.2 Replying to Request messages . . . . . . . . . . . . . 36 5.3 Message transmission . . . . . . . . . . . . . . . . . . . 36 5.3.1 Message transport over TCP/SCTP . . . . . . . . . . . 37 5.3.2 Message transport over unicast UDP . . . . . . . . . . 37 5.3.3 Message transport over multicast UDP . . . . . . . . . 38 5.4 Message reception . . . . . . . . . . . . . . . . . . . . 40 5.4.1 Ignore Message Operation . . . . . . . . . . . . . . . 42 Urue±a & Larrabeiti Expires September 15, 2004 [Page 2] Internet-Draft XSDF: Common Elements & Procedures March 2004 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 44 A. XSDF Constants . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1 XBE32 Attributes & Elements . . . . . . . . . . . . . . . 45 A.2 Timers and Constants . . . . . . . . . . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . 48 Urue±a & Larrabeiti Expires September 15, 2004 [Page 3] Internet-Draft XSDF: Common Elements & Procedures March 2004 1. Introduction XSDF stands for eXtensible Service Discovery Framework. It defines an architecture with several entities and protocols for the management and location of Service information [12]. All XSDF protocols follow the Client-Server paradigm. One XSDF Agent acts as client, sending request operations, while the peer XSDF Agent acts as a server, processing those operations and sending replies back. Additionally, some protocols allow XSDF Agents to send unsolicited messages. XSDF operations can be classified in four groups: Requests: These operations are employed when a client XSDF Agent asks a server one for some information, as "get public Services from remote 'xyz' Domain" or to perform some action. For example: "Register a Service at local 'xyz' Scope". Replies: These operations are responses to previous request ones. They are sent by the server to the client and carry: the requested data or an acknowledge, as "Service has been successfully registered". Errors: These are reply operations returned by the server because a client has sent an invalid request. For example if someone tries to update an unknown Service. Advertisements: These operations are generated by a XSDF Agent asynchronously, without being requested by a client. Examples are XSLP Service Advertisements [13] or XSTP Service Notifications [16]. By definition, a XSDF Agent acting as a server (i.e. a DA or a SA) is itself a Service. Therefore, they should have its own Service information, in particular a Service Id. Client XSDF Agents may be also Services, though. First part of this document defines common Elements and Attributes of XSDF messages. Second part specifies the operational procedures shared by all XSDF protocols. 1.1 Definitions Domain: A Domain is a single administrative organization containing Users and Services. Urue±a & Larrabeiti Expires September 15, 2004 [Page 4] Internet-Draft XSDF: Common Elements & Procedures March 2004 Scope: A Scope is a subset of Users and Services from a Domain, typically making a logical administrative group. Realm: A Realm is a combination of a Domain and one or more Scopes from such Domain, if any. Service: A Service is any process attached to a network that provides some kind of functionality to Users or other Services. A Service belongs to a single Realm. User Agent (UA): A process working on the User's (or other process) behalf to discover Services, and select the best available one. UAs obtain Service information from Directory Agents and Service Agents via XSLP. Service Agent (SA): A Service Agent is itself a Service that advertise Service information on behalf other processes. SAs are queried by User Agents for Services via XSLP, and/or register Service information in Directory Agents employing XSRP. Directory Agent (DA): A Directory Agent is a Service that, when deployed, acts as a central repository of all Service information from a Realm. Service Agents register its Services in a DA employing the XSRP protocol. Then, User Agents are able to query that information with XSLP. An Scope can be served by multiple DAs that coordinate themselves via XSSP & XSTP protocols. XSDF Agent: Any process that employs any XSDF protocol to interact with other XSDF Agents. Depending on the protocol a XSDF Agent may behave as a client or as a server (i.e. becoming itself a Service). 1.2 Notation Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [1]. Urue±a & Larrabeiti Expires September 15, 2004 [Page 5] Internet-Draft XSDF: Common Elements & Procedures March 2004 2. User Element This Element contains information about a XSDF User. Users, as Services, belong to a single Realm, that is, a Domain and one or more Scopes from that Domain. User Element: Element Name : user XBE32 Type : 0x0600 +---------------------------------------------------------------+ | [ Name ] | +---------------------------------------------------------------+ | [ URL #1 ] | +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ | [ URL #N ] | +---------------------------------------------------------------+ : [ Description Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Description Element #N ] : +---------------------------------------------------------------+ Name Attribute: Attribute Name : name XBE32 Type : 0x2861 Value Type : string Value Length : variable This Attribute contains the login name of the XSDF User. Users are identified by name, thus an User name MUST be unique inside its Domain. To obtain a globally unique name, User name MAY be appended with a "@" followed by the Domain she belongs to. URL Attribute: Attribute Name : url XBE32 Type : 0x2862 Value Type : string Value Length : variable This Attribute contain an URL pointing to additional information about this User, as her mail address or a web page. 2.1 Description Element This Element contains human readable text with additional information about the Element that contains it. As a Description Element contains text in a single language, multiple Description Elements MAY be Urue±a & Larrabeiti Expires September 15, 2004 [Page 6] Internet-Draft XSDF: Common Elements & Procedures March 2004 included with the same information in multiple languages. Description Element: Element Name : desc XBE32 Type : 0x0610 +---------------------------------------------------------------+ | Text | +---------------------------------------------------------------+ | [ Language = "en" ] | +---------------------------------------------------------------+ Text Attribute: Attribute Name : text XBE32 Type : 0x2863 Value Type : string Value Length : variable This Attribute contains the actual human-readable description text. Language Attribute: Attribute Name : lang XBE32 Type : 0x2864 Value Type : string Value Length : variable This Attribute specifies which language is employed in the previous "text" field. Languages MUST be encoded as defined in [9]. The default value of this Attribute is "en". Urue±a & Larrabeiti Expires September 15, 2004 [Page 7] Internet-Draft XSDF: Common Elements & Procedures March 2004 3. Service Element This is the most important Element of the XSDF messages, as it contains all the information about a Service. That information includes: instance identifier, its Service Type, its network location, the protocols that could be employed to access it, its state, additional human-readable data, etc. Service Element: Element Name : service XBE32 Type : 0x0100 +---------------------------------------------------------------+ | Service Identifier | +---------------------------------------------------------------+ : [ Service State Element ] : +---------------------------------------------------------------+ : [ Service Main Info Element ] : +---------------------------------------------------------------+ : [ Service Location Info Element ] : +---------------------------------------------------------------+ : [ Service Additional Info Element ] : +---------------------------------------------------------------+ Service Identifier Attribute: Attribute Name : id XBE32 Type : 0x3511 Value Type : opaque16 Value Length : 128 bits This mandatory Attribute contains a single 16 octet value that uniquely identifies this Service instance. The following Service identifiers are reserved by the IETF and SHOULD NOT be employed to identify any Service: Reserved Values Description ------------------------------------ ------------------ 00000000-0000-0000-0000-000000000000 Unknown XSDF Agent ffffffff-ffff-ffff-ffff-ffffffffffff All XSDF Agents 3.1 Service State Element This Element contains all the volatile information of a Service. Urue±a & Larrabeiti Expires September 15, 2004 [Page 8] Internet-Draft XSDF: Common Elements & Procedures March 2004 Service State Element: Element Name : serviceState XBE32 Type : 0x0110 +---------------------------------------------------------------+ : Meta-Information Element : +---------------------------------------------------------------+ : [ Selection State Element ] : +---------------------------------------------------------------+ 3.1.1 Meta-Information Element This Element contains the version information about all the Service information Elements, including Service State itself. By comparing two "metaInfo" Elements from the same Service, a XSDF Agent is able to know which Service information is newer and which Service Elements have been modified. Meta-Information Element: Element Name : metaInfo XBE32 Type : 0x0111 +---------------------------------------------------------------+ | State Timestamp | +---------------------------------------------------------------+ | [ Main Info Sequence Number = 0 ] | +---------------------------------------------------------------+ | [ Location Info Sequence Number = 0 ] | +---------------------------------------------------------------+ | [ Additional Info Sequence Number = 0 ] | +---------------------------------------------------------------+ State Timestamp Attribute: Attribute Name : stateTimestamp XBE32 Type : 0x331a Value Type : int64 Value Length : 64 bits This is the timestamp when Service State Element was generated. This timestamp could be obtained from a real clock or a logical one. The only requisite is that a newer state MUST have a greater timestamp value than an old one. Urue±a & Larrabeiti Expires September 15, 2004 [Page 9] Internet-Draft XSDF: Common Elements & Procedures March 2004 Main Info Sequence Number Attribute: Attribute Name : mainInfoSeqNum XBE32 Type : 0x321b Value Type : int32 Value Length : 32 bits Whenever a Service information Element is modified, its associated counter MUST be increased by one. This Attribute contains the sequence value associated to current "serviceMainInfo" Element. Default value is "0", meaning initial version. Location Info Sequence Number Attribute: Attribute Name : locationInfoSeqNum XBE32 Type : 0x321c Value Type : int32 Value Length : 32 bits Whenever a Service information Element is modified, its associated counter MUST be increased by one. This Attribute contains the sequence value associated to current "serviceLocationInfo" Element. Default value is "0", meaning initial version. Additional Info Sequence Number Attribute: Attribute Name : addInfoSeqNum XBE32 Type : 0x321d Value Type : int32 Value Length : 32 bits Whenever a Service information Element is modified, its associated counter MUST be increased by one. This Attribute contains the sequence value associated to current "serviceAddInfo" Element. Default value is "0", meaning initial version. 3.1.2 Selection State Element This Element contains all the volatile information required by a selection algorithm (i.e. Least Used/Most Resources) to evaluate the "goodness" of the associated Service. In order to perform an accurate selection, these values SHOULD have been recently measured. Selection State Element: Element Name : selectState XBE32 Type : 0x0311 +---------------------------------------------------------------+ | [ Resources ] | +---------------------------------------------------------------+ | [ Workload ] | Urue±a & Larrabeiti Expires September 15, 2004 [Page 10] Internet-Draft XSDF: Common Elements & Procedures March 2004 +---------------------------------------------------------------+ Resources Attribute: Attribute Name : resources XBE32 Type : 0x3231 Value Type : int32 Value Length : 32 bits This optional Attribute specifies the number of resources available to the users of this Service. It MUST be a non-negative value. "Most Resources" Selection policy chooses the Service with the greatest "resources" value. Services with a zero "resources" value are temporary unavailable, no matter which Selection policy is in use, and SHOULD NOT be accessed by Users. Workload Attribute: Attribute Name : workload XBE32 Type : 0x3232 Value Type : int32 Value Length : 32 bits This optional Attribute specifies the number of resources consumed by current users accessing to the associated Service. It MUST be a non-negative value. Lower the value, greater the capacity to be allocated to new users. "Least Used" selection policy prefers Services with lower workload. Each Service MAY define its own workload metric. By default, the workload of a Service equals to the workload of the server where Service is executing. 3.2 Service Main Information Element This Element specifies the Type of this Service instance. It MAY also contain a human-readable name for this Service, along with the Selection policy that SHOULD be employed to choose between Services with the same Type. Service Main Information Element: Element Name : serviceMainInfo XBE32 Type : 0x0120 +---------------------------------------------------------------+ : Service Type Element : +---------------------------------------------------------------+ | [ Alias ] | +---------------------------------------------------------------+ : [ Selection Information Element ] : +---------------------------------------------------------------+ Urue±a & Larrabeiti Expires September 15, 2004 [Page 11] Internet-Draft XSDF: Common Elements & Procedures March 2004 Alias Attribute: Attribute Name : alias XBE32 Type : 0x2814 Value Type : string Value Length : variable This optional Attribute ease human selection of Services by naming a Service with an name better than with its numeric id. 3.2.1 Service Type Element This Element identifies the Type of this Service instance. If a Service could be distributed among several servers, this Element also identifies which parts of such Service are provided by this instance. Service Type Element: Element Name : serviceType XBE32 Type : 0x0121 +---------------------------------------------------------------+ | Type | +---------------------------------------------------------------+ | [ Path #1 = "/" ] | +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ | [ Path #N ] | +---------------------------------------------------------------+ Type Attribute: Attribute Name : type XBE32 Type : 0x2812 Value Type : string Value Length : variable This Attribute identifies which kind of Service is provided by this server. Examples of Service types could be "printer" or "xsdf:da". Path Attribute: Attribute Name : path XBE32 Type : 0x2813 Value Type : string Value Length : variable If this Service Type could provide resources arranged in some kind of hierarchical structure (i.e. a file server), these Attributes specify which branches of the resource tree are provided by this particular Service instance. The default value for this field is "/", that is, the root of resource tree. Urue±a & Larrabeiti Expires September 15, 2004 [Page 12] Internet-Draft XSDF: Common Elements & Procedures March 2004 3.2.2 Selection Information Element This Element contains all the pseudo-static information required by a selection algorithm to evaluate the "goodness" of the associated Service. Selection Information Element: Element Name : selectInfo XBE32 Type : 0x0321 +---------------------------------------------------------------+ | Policies | +---------------------------------------------------------------+ | [ Priority = 0 ] | +---------------------------------------------------------------+ | [ Weight ] | +---------------------------------------------------------------+ Policies Attribute: Attribute Name : policies XBE32 Type : 0x3133 Value Type : opaque2 Value Length : variable This Attribute contains a list of Selection policies that may be applied to choose between Services with the same Type as the associated one. If multiple Selection policies are specified, they MUST be sorted by preference. Policies with greater preference MUST be placed at the beginning. Selection algorithms defined in this document are: Value Selection Policy ------ -------------------- 0x0000 None 0x0001 Round Robin 0x0002 Least Used 0x0003 Most Resources 0x0004 Closest Each Service Type MAY define its own Selection Policy and related metric Attributes. However, all XSDF implementations MUST support the following selection policies: None This value does not specifies any selection algorithm but tells that all Services SHOULD be returned. Urue±a & Larrabeiti Expires September 15, 2004 [Page 13] Internet-Draft XSDF: Common Elements & Procedures March 2004 Round Robin Service selection probability SHOULD be distributed among all Services proportionally to its "weight" value. Thus, Service instances with greater "weight" SHOULD be accessed proportionality more times than servers with lower "weight" values. Least Used Selection process SHOULD choose the Service with the lowest "workload" Service State Attribute. As this value may change continuously, XSDF Agents SHOULD obtain/refresh it if stalled. Most Resources Selection process SHOULD choose the Service with the greatest "resurces" Service State Attribute. As the "Least Used" policy, if greatest "resources" value is shared by several Services, next Selection policy (or Round Robin, if none is specified) SHOULD be used to choose the best one among them. As "workload" attribute, "resorces" value SHOULD be refreshed if Service information have been stalled (i.e. has zero ttl). Closest This Selection policy does not have any associated metric attribute, but Selection process SHOULD choose the server with lower latency from its point of view. This document does not define how to measure such "latency". Priority Attribute: Attribute Name : priority XBE32 Type : 0x3234 Value Type : int32 Value Length : 32 bits This optional Attribute contains the priority of this Service instance. Selection algorithm SHOULD always choose among services with the greatest priority (note that priority value MAY be negative). This selection mechanism is useful to deploy services with an active/backup access policy. The default value for this field is 0. Weight Attribute: Attribute Name : weight XBE32 Type : 0x3235 Value Type : int32 Value Length : 32 bits This optional Attribute specifies the relative performance of this service instance compared to other services of the same Type. It MUST be a positive value. This field is employed by the Round Robin mechanism (a.k.a. Weighted Round Robin) in order to load balance among several servers with different processing power. Services with Urue±a & Larrabeiti Expires September 15, 2004 [Page 14] Internet-Draft XSDF: Common Elements & Procedures March 2004 an unspecified "weight" value SHOULD have the same value as the lowest specified one. 3.3 Service Location Information Element This Element contains all the information required to contact with the process running at the specified Server, which provides the associated Service. Service Location Information Element: Element Name : serviceLocationInfo XBE32 Type : 0x0130 +---------------------------------------------------------------+ : Inet Element : +---------------------------------------------------------------+ : Protocol Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : Protocol Element #N : +---------------------------------------------------------------+ 3.3.1 Inet Element This Element contains the network location of the Server, as well as additional capabilities of the network layer. This document only specifies IP related information. XSDF MAY be extended to support other network technologies. Inet Element: Element Name : inet XBE32 Type : 0x0131 +---------------------------------------------------------------+ | [ IPv4 Addresses ] | +---------------------------------------------------------------+ | [ IPv6 Addresses ] | +---------------------------------------------------------------+ | [ Hostname #1 ] | +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ | [ Hostname #N ] | +---------------------------------------------------------------+ | [ Capabilities16 ] | +---------------------------------------------------------------+ Urue±a & Larrabeiti Expires September 15, 2004 [Page 15] Internet-Draft XSDF: Common Elements & Procedures March 2004 IPv4 Addresses Attribute: Attribute Name : ipv4Addrs XBE32 Type : 0x3215 Value Type : opaque4 Value Length : variable This Attribute contains the list of IPv4 addresses of the Server providing this Service. IPv6 Addresses Attribute: Attribute Name : ipv6Addrs XBE32 Type : 0x3516 Value Type : opaque16 Value Length : variable This Attribute contains the list of IPv6 addresses of the Server providing this Service. Hostname Attribute: Attribute Name : hostname XBE32 Type : 0x2817 Value Type : string Value Length : variable This Attribute contains the DNS name of the Server providing this Service. If no domain name is present, but just the Server hostname (i.e. no dots), the fully qualified name can be obtained by appending the Domain that this Service belongs to. Capabilities16 Attribute: Attribute Name : capabilities16 XBE32 Type : 0x3118 Value Type : opaque2 Value Length : variable This optional Attribute contains the list of additional capabilities of the IP stack of the Server providing this Service, which are currently enabled. Capabilities are encoded as 2 octet values (See IANA Assigned Protocol Numbers): Value Inet Capability ------ --------------- 0x3200 Encap Security Payload for IPv6 [RFC2402] 0x3300 Authentication Header for IPv6 [RFC2406] Urue±a & Larrabeiti Expires September 15, 2004 [Page 16] Internet-Draft XSDF: Common Elements & Procedures March 2004 3.3.2 Protocol Element This Element identifies a protocol that could be employed to access this Service. It includes transport port numbers and additional protocol capabilities. Protocol Element: Element Name : protocol XBE32 Type : 0x0132 +---------------------------------------------------------------+ | Name | +---------------------------------------------------------------+ | Transport Protocols & Ports | +---------------------------------------------------------------+ | [ Capabilities16 ] | +---------------------------------------------------------------+ Capabilities16 Attribute is defined in Section 3.3.1. Name Attribute is defined in Section 2 Protocols are identified by its name, for example "pop3". Protocol name is carried as a string inside the Protocol's Name Attribute. Transport Protocols & Ports Attribute: Attribute Name : transPorts XBE32 Type : 0x321a Value Type : opaque4 Value Length : variable This Attribute contains a list of the preferred port numbers (and its Transport Protocol) where Service process is listening for requests. Last 2 octets encode the port number, while first 2 octets encode the Transport Protocol (See IANA Assigned Protocol Numbers): Value Transport Protocol ------ ------------------------------------------- 0x0006 Transmission Control Protocol (TCP) [RFC793] 0x0011 User Datagram Protocol (UDP) [RFC768] 0x0084 Stream Control Transmission Protocol (SCTP) [RFC2960] The Capabilites16 is an optional Attribute that contains the list of additional capabilities of this protocol. Capabilities are encoded as 2 octet values and each protocol MAY define the values for its own Capabilities set. XBE32 based protocols MAY advertise additional operations, by including its Operation Element TLV 2 octet Type as a capability. Urue±a & Larrabeiti Expires September 15, 2004 [Page 17] Internet-Draft XSDF: Common Elements & Procedures March 2004 3.4 Service Additional Information Element This Element contains additional management information about the Service. Service Additional Information Element: Element Name : serviceAddInfo XBE32 Type : 0x0140 +---------------------------------------------------------------+ | [ Vendor ] | +---------------------------------------------------------------+ | [ VendorURL ] | +---------------------------------------------------------------+ | [ Model ] | +---------------------------------------------------------------+ | [ ModelURL ] | +---------------------------------------------------------------+ | [ Version ] | +---------------------------------------------------------------+ | [ URL ] | +---------------------------------------------------------------+ : [ Description Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Description Element #N ] : +---------------------------------------------------------------+ : [ Icon Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Icon Element #N ] : +---------------------------------------------------------------+ : [ Operator Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Operator Element #N ] : +---------------------------------------------------------------+ : [ Naming Authority Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Naming Authority Element #N ] : +---------------------------------------------------------------+ User, Description Elements and URL Attribute are defined in Section 2. Vendor Attribute: Attribute Name : vendor XBE32 Type : 0x2865 Value Type : string Value Length : variable Urue±a & Larrabeiti Expires September 15, 2004 [Page 18] Internet-Draft XSDF: Common Elements & Procedures March 2004 This optional Attribute defines the vendor of this Service. Vendor URL Attribute: Attribute Name : vendorURL XBE32 Type : 0x2866 Value Type : string Value Length : variable This optional Attribute contains an URL pointing to more information about this Service's vendor. Model Attribute: Attribute Name : model XBE32 Type : 0x2867 Value Type : string Value Length : variable This optional Attribute defines the name of the HW/SW model providing this Service. Model URL Attribute: Attribute Name : modelURL XBE32 Type : 0x2868 Value Type : string Value Length : variable This optional Attribute contains an URL pointing to more information about this model. Version Attribute: Attribute Name : version XBE32 Type : 0x2869 Value Type : string Value Length : variable This optional Attribute contains the version info of the model that provides this Service. The URL Attribute contains an URL pointing to additional information about this Service. The Description Element contains some textual information about this Service. The Operator Element is an User Element which contains some information about the User responsible of this Service. Urue±a & Larrabeiti Expires September 15, 2004 [Page 19] Internet-Draft XSDF: Common Elements & Procedures March 2004 3.4.1 Icon Element This Element contains graphical information about a Service. The only mandatory data is an URL pointing to the image file. Icon Element: Element Name : icon XBE32 Type : 0x0620 +---------------------------------------------------------------+ | URL | +---------------------------------------------------------------+ | [ mimeType ] | +---------------------------------------------------------------+ | [ width ] | +---------------------------------------------------------------+ | [ height ] | +---------------------------------------------------------------+ | [ depth ] | +---------------------------------------------------------------+ URL Attribute is defined in Section 2. MIME Type Attribute: Attribute Name : mimeType XBE32 Type : 0x286a Value Type : string Value Length : variable This optional Attribute defines which is the MIME Type of the image file pointed by the icon URL. For example "image/png". Width Attribute: Attribute Name : width XBE32 Type : 0x326b Value Type : int32 Value Length : 32 bits This optional Attribute defines the width, in pixels, of the above image. Height Attribute: Attribute Name : height XBE32 Type : 0x326c Value Type : int32 Value Length : 32 bits This optional Attribute defines the height, in pixels, of the above Urue±a & Larrabeiti Expires September 15, 2004 [Page 20] Internet-Draft XSDF: Common Elements & Procedures March 2004 image. Depth Attribute: Attribute Name : depth XBE32 Type : 0x326d Value Type : int32 Value Length : 32 bits This optional Attribute defines the pixel's color depth of the above image. 3.4.2 Naming Authority Element This Element allows Service Agents to include vendor specific Service information. Such Elements and Attributes are named with a vendor prefix followed by a colon (":"). This Element points to the template describing those additional Elements and Attributes. Naming Authority Element: Element Name : namingAuth XBE32 Type : 0x0710 +---------------------------------------------------------------+ | Prefix | +---------------------------------------------------------------+ | Template | +---------------------------------------------------------------+ Prefix Attribute: Attribute Name : prefix XBE32 Type : 0x2873 Value Type : string Value Length : variable This Attribute contains the name prefix (without colon) for the Attributes and Elements defined by this Naming Authority (i.e. "acme"). Template Attribute: Attribute Name : template XBE32 Type : 0x2874 Value Type : string Value Length : variable This Attribute carries an URL pointing to the template which defines the additional elements employed in this Service information. Urue±a & Larrabeiti Expires September 15, 2004 [Page 21] Internet-Draft XSDF: Common Elements & Procedures March 2004 4. Messages Format All XSDF messages are encoded inside a single XBE32 Element. This Element's Type identifies the protocol version. All XSDFv1 protocols share the same message format: a Header Element followed by one or more protocol operation Elements. XSDF Message Element: +---------------------------------------------------------------+ : Header Element : +---------------------------------------------------------------+ : XSDF Operation Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : XSDF Operation Element #N : +---------------------------------------------------------------+ : [ Signature Information Element ] : +---------------------------------------------------------------+ 4.1 Header Element This Element defines the common header for all XSDF messages. It identifies both peers of a XSDF transaction. When replying to a message, Source and Destination Elements are interchanged. Header Element: Element Name : header XBE32 Type : 0x0810 +---------------------------------------------------------------+ | Transaction Identifier | +---------------------------------------------------------------+ : Realm Element : +---------------------------------------------------------------+ : Source Endpoint Element : +---------------------------------------------------------------+ : Destination Endpoint Element : +---------------------------------------------------------------+ : [ Authentication Information Element ] : +---------------------------------------------------------------+ Urue±a & Larrabeiti Expires September 15, 2004 [Page 22] Internet-Draft XSDF: Common Elements & Procedures March 2004 Transaction Identifier Attribute: Attribute Name : xid XBE32 Type : 0x3281 Value Type : opaque4 Value Length : variable This Attribute contains an unique identifier for this XSDF transaction. It is randomly generated by the client XSDF Agent and returned in the response message by the server one. This field allows clients to correlate outstanding requests with its responses. It MAY be employed by the server to quickly reply to retransmissions. Source Endpoint Element: Element Name : source XBE32 Type : 0x0811 This Attribute identifies the XSDF Agent (UA, SA or DA) and/or User that has generated this message. Source Service Id value MUST NOT be a reserved one (i.e. "Unknown XSDF Agent" or "All XSDF Agents"). In that case, message MUST be silently dropped. Destination Endpoint Element: Element Name : destination XBE32 Type : 0x0812 This Attribute identifies the XSDF Agent (UA, SA or DA) and/or User that this message is sent to. A XSDF agent MUST check that the destination service id of any received XSDF message equals: its own id, the "Unknown XSDF Agent" id, or the "All XSDF Agents" id. Otherwise, it SHOULD skip this message and return an UNKNOWN_SERVICE_ID error. 4.1.1 Realm Element The Realm Element identifies the Domain and Scopes that XSDF operations should be applied at. A XSDF agent MUST check that the specified Realm, from the received XSDF message is compatible with its own Realm. Otherwise it SHOULD drop this message and return an UNKNOWN_REALM error. Urue±a & Larrabeiti Expires September 15, 2004 [Page 23] Internet-Draft XSDF: Common Elements & Procedures March 2004 Realm Element: Element Name : realm XBE32 Type : 0x0700 +---------------------------------------------------------------+ | [ Domain ] | +---------------------------------------------------------------+ | Scope #1 | +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ | Scope #N | +---------------------------------------------------------------+ Domain Attribute: Attribute Name : domain XBE32 Type : 0x2871 Value Type : string Value Length : variable This Attribute contains a hierarchical identifier of the organization providing one or more Services. Employing a DNS full qualified Domain name allows UAs to found remote DAs by DNS queries. Organizations MAY advertise its public DAs encoded in DNS SRV Resource Records. See XSLP [13] for details. Scope Attribute: Attribute Name : scope XBE32 Type : 0x2872 Value Type : string Value Length : variable This Attribute contains the name of the Scope, that belongs to the specified Domain, if any. Scope namespace is flat and allow organizations to aggregate Users and Services in different administrative groups. This document defines the following Scopes: DEFAULT: XSDF Agents that are not configured with a Realm belong to the "DEFAULT" Scope and have no domain. LOCAL: This Scope is reserved to Services referred to the server itself. Services from this Scope MUST NOT belong to any other Scope. DAs MUST NOT manage Services from this Scope. Thus, SAs MUST NOT register them. Multicast requests MUST NOT refer to the "LOCAL" Scope. SAs and DAs SHOULD reply just to unicast queries of Services from this Scope. Urue±a & Larrabeiti Expires September 15, 2004 [Page 24] Internet-Draft XSDF: Common Elements & Procedures March 2004 PUBLIC: Public services from remote Domains MUST belong to the the Realm with the specified Domain and a "PUBLIC" Scope. 4.1.2 Endpoint Element This Element identifies one of the peers of a XSDF transaction. Endpoint Element: +---------------------------------------------------------------+ : [ Service Element ] : +---------------------------------------------------------------+ : [ User Element ] : +---------------------------------------------------------------+ Service Element is defined in Section 3. User Element is specified in Section 2 Service Element identifies the source/destination XSDF Agent of this message. However, it MAY not appear as UAs are not required to have associated Service information. Service Element MUST contain the Service Identifier, and MAY also include its Service State. Other Service information is optional and SHOULD NOT appear. User Element contains information about the User responsible of the source/destination XSDF Agent. This field MAY identify the public key employed to sign this message. See Section 4.4 for details. 4.1.3 Authentication Information Element This optional Element MAY be employed by XSDF Agents to provide some security when lower layers do not provide such mechanisms. Authentication Information Element: Element Name : authInfo XBE32 Type : 0x0813 +---------------------------------------------------------------+ | [ Cookie ] | +---------------------------------------------------------------+ | [ EAP Information ] | +---------------------------------------------------------------+ Urue±a & Larrabeiti Expires September 15, 2004 [Page 25] Internet-Draft XSDF: Common Elements & Procedures March 2004 Cookie Attribute: Attribute Name : cookie XBE32 Type : 0x2184 Value Type : opaque Value Length : variable This Attribute contains an opaque binary value. XSDF Server Agents MAY reject a Request message and set a Cookie. The client MUST reissue the Request message including this value in the Header's Authentication Information. EAP Information Attribute: Attribute Name : eapInfo XBE32 Type : 0x2185 Value Type : opaque Value Length : variable This Element contains an EAP packet as defined in [5]. An XSDF Server Agent MAY reject a Request message due Scope Authorization issues. In that case, it will generate an EAP-Request and sent it back to the client. Then, the client will generate a new XSDF message with the EAP-Response value. 4.2 Error Element Each XSDF protocol defines its own set of errors associated with its protocol operations. However, all kinds of XSDF protocol errors are encoded using the same Error Element format. Also, there are some common errors that MAY appear at all XSDF protocols. This section specifies both, the XSDF Error Element and the list of common XSDF errors. Error Element: Element Name : error XBE32 Type : 0x08F1 +---------------------------------------------------------------+ | Code | +---------------------------------------------------------------+ | [ Name ] | +---------------------------------------------------------------+ : [ Description Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Description Element #N ] : +---------------------------------------------------------------+ Description Element is specified in Section 2.1. Urue±a & Larrabeiti Expires September 15, 2004 [Page 26] Internet-Draft XSDF: Common Elements & Procedures March 2004 Code Attribute: Attribute Name : code XBE32 Type : 0x3283 Value Type : opaque4 Value Length : 32 bits This Attribute contains the code number of this kind of error. Name Attribute: Attribute Name : name XBE32 Type : 0x2861 Value Type : string Value Length : variable This Attribute is optional, and contains the name of this kind of error. The Description Elements contain a full description of this error. Multiple descriptions are allowed to carry error messages in several languages. This is the list of all the common XSDF errors: Error Code Error Name Cause ---------- --------------------- ----------------------------------- 0x00000001 XBE32_ERROR Invalid XBE32 encoded message 0x00000002 UNKNOWN_XBE32_ELEMENT Unknown XBE32 Element found 0x00000003 PARSING_ERROR Invalid XSDF message 0x00000004 OVERFLOW_ERROR Message size limit reached 0x00000005 UNKNOWN_REALM Incompatible Header's Realm 0x00000006 UNKNOWN_SERVICE_ID Incompatible Header's Destination 0x00000007 AUTHENTICATION_ERROR Authentication required 0x00000008 BUSY_NOW_ERROR Server is busy with other requests, retry later 0x00000009 INTERNAL_ERROR Other errors An Error Element MAY carry additional Elements and Attributes with relevant information in order to pinpoint the cause of the error. XSDF implementations MUST be able to receive messages containing XBE32 Elements not defined neither here nor in companion documents. In that case, it MUST follow the rules specified in XBE32 [11] to notify an unknown Element inside an UNKNOWN_XBE32_ERROR Error. This Element SHOULD contain the Ids and/or the Names of unknown XBE32 Errors found. Such data is encoded inside the Element Id and Element Name TLVs defined in XBE32 [11]. UNKNOWN_REALM Error Element SHOULD contain the incompatible Realm Urue±a & Larrabeiti Expires September 15, 2004 [Page 27] Internet-Draft XSDF: Common Elements & Procedures March 2004 Element of the received request message's Header. The reply message's Header itself SHOULD contain an empty Realm. UNKNOWN_SERVICE_ID Error SHOULD contain the Service Element from the received request message's Destination Endpoint. That Service Element MUST contain the unknown Id. Other Service information is optional and SHOULD NOT appear. AUTHENTICATION_ERROR Error Element SHOULD contain a Cookie Attribute, an Authorization Information Element or both. See Section 5 for a description of the procedures involving this Error. 4.3 Ignore Message Element This operation MAY be employed by XSDF Agents to prevent other ones to process the message that includes it. Any XSDF Agent MUST check if its id is listed in the "serviceIds" attribute. In that case it SHOULD stop processing this message. Ignore Message Element: Element Name : ignoreMessage XBE32 Type : 0x0830 +---------------------------------------------------------------+ | Service Ids | +---------------------------------------------------------------+ Service Ids Attribute: Attribute Name : serviceIds XBE32 Type : 0x3582 Value Type : opaque16 Value Length : variable This Attribute contains a list of Service Identifiers. They identify XSDF Agents that MUST avoid processing this message. 4.4 Signature Information Element This Element MAY be included in XSDF messages to provide both message integrity and source authentication. Source endpoint signs with its public key the digest value of the whole message but the Signature Value Attribute. Keys are assigned to User names. In order to identify which key has been employed to sign this message, Source Endpoint Element MUST include an User Element. Urue±a & Larrabeiti Expires September 15, 2004 [Page 28] Internet-Draft XSDF: Common Elements & Procedures March 2004 Signature Information Element: Element Name : signatureInfo XBE32 Type : 0x08e1 +---------------------------------------------------------------+ | Digest Method | +---------------------------------------------------------------+ | Signature Method | +---------------------------------------------------------------+ | Signature Value | +---------------------------------------------------------------+ Digest Method Attribute: Attribute Name : digestMethod XBE32 Type : 0x3286 Value Type : opaque4 Value Length : 32 bits This Attribute identifies which kind of algorithm has been employed in order to obtain a digest of the whole XSDF message, but the Signature Value Attribute. Digest Method is encoded as a 4 octet value (See IANA Assigned IKE Numbers): Value Hash Algorithm ---------- -------------- 0x00000001 MD5 [RFC1321] 0x00000002 SHA FIPS 180-1 Signature Method Attribute: Attribute Name : signatureMethod XBE32 Type : 0x3287 Value Type : opaque4 Value Length : 32 bits This Attribute identifies which kind of algorithm has been employed to encrypt the digest of the XSDF message. Signature Method is encoded as a 4 octet value (See IANA Assigned IKE Numbers): Value Encryption Algorithm ---------- ------------------------- 0x00000001 DES-CBC [RFC2405] 0x00000002 IDEA-CBC [RFC2409] 0x00000003 Blowfish-CBC [RFC2409] 0x00000004 RC5-R16-B64-CBC [RFC2409] 0x00000005 3DES-CBC [RFC2409] 0x00000006 CAST-CBC [RFC2409] Urue±a & Larrabeiti Expires September 15, 2004 [Page 29] Internet-Draft XSDF: Common Elements & Procedures March 2004 Signature Value Attribute: Attribute Name : signatureValue XBE32 Type : 0x2188 Value Type : opaque Value Length : variable This Attribute contains the encrypted digest value of this whole message but this Attribute itself. In order to check if the message has been modified, receiver should perform the same digest process and compare it with the decrypted signature. If they are not equal, message MUST be silently dropped and MUST NOT be processed. 4.5 Common Operation Parameters Each XSDF protocol defines its own set of operation Elements. However, many protocol operations share common parameters. This sections defines those common Elements. 4.5.1 Realm Target Element Any operation containing a Realm Target parameter SHOULD be applied to all the Scopes from the specified Realm subset. Target Element: Element Name : target XBE32 Type : 0x0821 +---------------------------------------------------------------+ : [ Realm Element ] : +---------------------------------------------------------------+ Realm Element is specified in Section 4.1.1. Realm Element MUST be a subset of message Header's one, that is, do not specify another Domain and contain Scopes that have been already listed at message's Header. Otherwise, message processing SHOULD be silently aborted. If no Realm is specified, this target applies to all the Scopes specified in message Header's. 4.5.2 Services Filter Element Any request operation containing a Filter Element SHOULD remove the services listed in the "serviceIds" attribute from response message. Urue±a & Larrabeiti Expires September 15, 2004 [Page 30] Internet-Draft XSDF: Common Elements & Procedures March 2004 Services Filter Element: Element Name : filter XBE32 Type : 0x0822 +---------------------------------------------------------------+ | [ Service Ids ] | +---------------------------------------------------------------+ Service Ids Attribute is defined in Section 4.3. Service Id Attribute contains a sorted list of Service Identifiers. List MUST be sorted in order to ease Service Id search. 4.5.3 Update Information Element This Element is included in reply and advertisement operations and allows server XSDF Agent to control the refresh rate of Service Registrations or Subscriptions from client XSDF Agents. It may be also included in the requests to suggest XSDF Server Agents which is the better update interval. Update Information Element: Element Name: updateInfo XBE32 Type: 0x0521 +---------------------------------------------------------------+ | Minimum Life | +---------------------------------------------------------------+ | Maximum Life | +---------------------------------------------------------------+ Minimum Life Attribute: Attribute Name : minLife XBE32 Type : 0x3253 Value Type : int32 Value Length : 32 bits This Attribute indicates that associated information SHOULD NOT be refreshed until this time has elapsed. Time is measured in milliseconds. Maximum Life Attribute: Attribute Name : maxLife XBE32 Type : 0x3254 Value Type : int32 Value Length : 32 bits Urue±a & Larrabeiti Expires September 15, 2004 [Page 31] Internet-Draft XSDF: Common Elements & Procedures March 2004 This Attribute contains the maximum time in milliseconds that associated information is going to remain registered. An Update request SHOULD be issued before this time expires, or the associated registration/subscription will be deleted. 4.5.4 Cache State Element This Element contains how much time the associated Service information has been cached, and the validity time left. Cache State Element: Element Name : cacheState XBE32 Type : 0x0211 +---------------------------------------------------------------+ | Age | +---------------------------------------------------------------+ | Time to Live | +---------------------------------------------------------------+ Age Attribute: Attribute Name : age XBE32 Type : 0x3221 Value Type : int32 Value Length : 32 bits This Attribute contains the Age of this Service, that is, the time passed since cached Service information was last updated. It is measured in milliseconds. Time to Live Attribute: Attribute Name : ttl XBE32 Type : 0x3222 Value Type : int32 Value Length : 32 bits This Attribute contains the expected amount of time in milliseconds that Service data is expected to keep being valid. Urue±a & Larrabeiti Expires September 15, 2004 [Page 32] Internet-Draft XSDF: Common Elements & Procedures March 2004 5. Common Procedures This section defines operational procedures common to all XSDF protocols. In particular this section covers XSDF Agent initialization and XSDF message creation, transmission and reception, including common operation processing. Unless explicitly said, all XSDF protocols MUST adhere to the procedures described here. 5.1 XSDF Agent initialization XSDF Agents MUST belong to a Realm. They MAY obtain such information from several ways (sorted by preference): 1. Static configuration. XSDF Agents MUST be able to read its Realm from a configuration file. 2. Dynamic configuration via DHCP [2]. Realm MAY be built from the Domain name [3] and the SLP Scope List [8] DHCP Options. 3. Dynamic configuration from DAs via XSLP. If DA addresses are pre-configured (or obtained via DHCP), an UA or SA MAY query those DAs to obtain their Realms via "realmRequest" operations. See [13] for details. 4. Use of the "DEFAULT" Realm. If all the above mechanisms fail, UAs and SAs MUST set its Realm to the empty Domain and one Scope called "DEFAULT". The behavior of XSDF Agents changes whether a Scope is managed or not by DAs. Therefore, XSDF Agents MUST be able to know if a Realm is managed by DAs and, in that case, obtain the Service information about those DAs, at least their IP addresses. UAs and SAs MAY obtain such information from several ways (sorted by preference): 1. Static configuration. A XSDF Agent MUST be able to read the Service information about DAs managing its Realm Scopes from a configuration file. 2. Dynamic configuration via DHCP [2]. XSDF Agents MAY obtain the address of DAs via the SLP Directory Agent DHCP Option [8]. 3. Dynamic configuration via XSLP. XSDF Agents MAY obtain DA Service information by performing Active Service Discovery for the "xsdf:da" Service Type, or by receiving DA Service Advertisements (a.k.a. Passive Service Discovery). See [13] for details. 4. Stand-Alone state. If all the above mechanisms fail, XSDF Agent MUST consider that there are no DAs in that Scope (unless the Urue±a & Larrabeiti Expires September 15, 2004 [Page 33] Internet-Draft XSDF: Common Elements & Procedures March 2004 XSDF Agent is itself a DA, of course) and behave as in its Stand-Alone state. The common initialization phase of a XSDF Agent ends when it knows the Realm it belongs to, and the DAs, if any, managing those Scopes. A Scope not managed by any DAs is called unmanaged Scope. 5.2 Message generation All XSDF protocols share a common message format. A XSDF message is included inside a single Element. That Element is defined by each protocol and allows protocol versioning. However, that Element always have the same structure, a Header Element, followed by one or more operation Elements and an ending optional Signature Element. Each protocol defines its own set of operations, but the other elements are common for all XSDF protocols. In particular, this section focus on how Header Element should be created. 5.2.1 Creating new messages This subsection refers to request and advertisement message creation. Refer to next subsection for generation of reply messages. When a XSDF Agent wants to create a new message that is not a reply to another message, it MUST build a Header Element following these steps: 1. Generate a new transaction identifier (XID). It SHOULD be unique in order to identify the XSDF message. Uniqueness MUST be granted for message validity time. A simple XID counter with a random initial number should be enough. 2. Realm Element SHOULD contain the common known Realm between source and destination XSDF Agents. That is, the same Domain, if any, and the subset of common Scopes. If the destination Realm is unknown (i.e. multicast message), Realm Element SHOULD contain the full Realm of the source XSDF Agent. If unknown, Realm Element MAY be empty but only during the initialization phase. See [13] for details. 3. As SAs and DAs are Services themselves, when creating a message, they MUST build an Source Endpoint Element containing at least a Service Element with its Id. Other Service information is optional and MAY NOT appear. An UA MAY NOT have a Service Id, therefore it MUST build a Source Endpoint Element but it MAY NOT contain a Service Element. 4. Destination Endpoint Element MUST contain a Service Element with Urue±a & Larrabeiti Expires September 15, 2004 [Page 34] Internet-Draft XSDF: Common Elements & Procedures March 2004 the Service Id of the remote XSDF Agent. Other Service information is optional and SHOULD NOT appear. However, if the Service Id of the remote peer is unknown, the Service Id MUST be set to the "Unknown XSDF Agent" reserved value. The above description only applies to unicast messages. Multicast messages MUST have the Destination Service Id set to the "All XSDF Agents" reserved value. 5. If a previous request message was rejected due to an AUTHENTICATION_ERROR including a Cookie Element. A new request message SHOULD be generated containing exactly the same operations, but including an Authentication Element in its Header. This Element MUST carry the Cookie Element returned in the error reply. 6. A request message MAY be also rejected because it was not authenticated and contained a restricted Realm. In that case, Error Element SHOULD carry an EAP Request message. As above, a new message SHOULD be generated with the same operations and an Authentication Element. This Element MUST contain the appropriate EAP response message by performing the specified authentication method. Please refer to Section 4.1 for a detailed description of the Header Element. In order to provide message integrity and authentication (when not provided by lower layers), XSDF Agents MAY include a Signature Element at the end of a XSDF message. In order to generate such Element, XSDF Agents MUST perform the following steps: 1. Set the Signature Method Attribute with the encryption algorithm associated with its Public/Private Key pair. 2. Choose a supported digest algorithm and fill the Digest Method Attribute with its identifier. 3. Employ the above algorithm to obtain the hash value of the whole message, including its Header, Operations and Signature Element but its last Signature Attribute. 4. Encrypt the digest value with the Private Key and set the result in the Signature Value Attribute. Please refer to Section 4.4 for a detailed description of the Signature Element. Urue±a & Larrabeiti Expires September 15, 2004 [Page 35] Internet-Draft XSDF: Common Elements & Procedures March 2004 5.2.2 Replying to Request messages After a message containing operation requests is processed, a reply message SHOULD be sent back with operation replies and/or errors. However, XSDF Agents MUST NOT send Errors as replies to multicast requests in any case. Also, XSDF Agents MUST always reply to unicast addresses. When a XSDF Agent wants to create a reply message to a previously received valid one, it MUST build a Header Element following these steps: 1. Transaction identifier (XID) MUST be copied from previous request message. 2. Realm Element SHOULD contain the common known Realm between source and destination XSDF Agents. If the Realm Element at request message's Header contains unknown Scopes, reply message SHOULD list just the subset of common Scopes, if any. If Realms are incompatible, reply message SHOULD contain an empty Realm. 3. Replying XSDF Agent MUST build a Source Endpoint Element containing at least a Service Element with its own Service Id. Other Service information is optional and MAY NOT appear. 4. Unless Source Service Element in request message was empty, Destination Endpoint Element MUST contain, at least, a Service Element with the same Id as in previous message's Source one. Other Service information is optional and SHOULD NOT appear. Please refer to Section 4.1 for a detailed description of the Header Element. 5.3 Message transmission XSDF has been designed to allow protocol messages to be transmitted over several transport protocols. XSDF Agents SHOULD support UDP and TCP transport protocols and MAY support SCTP. Each XSDF protocol defines the subset of transport protocols that could be employed for message transmission. XSDF employs XBE32 [11] to encode all its messages. In XBE32, complex Elements could be delimited by length or with an End-of-data TLV. However, this latter mechanims SHOULD NOT be employed in UDP tranmission and is restricted to TCP and SCTP transport protocols. All XSDF messages MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., the most significant byte first), no matter which Urue±a & Larrabeiti Expires September 15, 2004 [Page 36] Internet-Draft XSDF: Common Elements & Procedures March 2004 transport protocol is employed. Each XSDF protocol defines its own default Server port. However, as any other Service, XSDF Agents MAY advertise other ports in its Service information. The only exception is XSLP that MUST employ UDP/ 727 port number. Clients MAY employ any ephemeral port to send request messages. Servers MUST reply from the same port number where previous message was received. When the same Realm is handled by several DAs, those DAs exchange registered Service information among them, thus providing an unified view of the common Realm. Therefore, XSDF operations aiming to that Realm could be issued to any of the DAs that manage such Realm. In particular, XSDF Agents SHOULD follow the Selection policy advertised by DAs to choose the better one to send XSDF operations to. 5.3.1 Message transport over TCP/SCTP When a client XSDF Agent wants to communicate with a server one over TCP or SCTP, client MUST initiate the TCP/SCTP connection. Once such connection is established, both, request and reply messages of the transaction are exchanged. A single connection MAY be employed for multiple XSDF transactions. The initiating XSDF Agent SHOULD close the connection. However, the server peer SHOULD close the connection when it has been idle for MAX_IDLE_CONN_TIME. Whenever a XSDF request message is sent, source XSDF Agent SHOULD set an REPLY_TIMER. If the timer expires before a response (i.e. containing reply operations or errors) has been received, message transmission to destination XSDF Agent MUST be skipped. In that case, its Service information SHOULD be flushed from cache and next XSDF Agent SHOULD be chosen. If there are no XSDF Agents left, message transmission MUST be aborted and upper layer SHOULD be notified with an error message. 5.3.2 Message transport over unicast UDP As UDP does not provide a reliable, ordered-delivery mechanism to transport messages. XSDF Agent SHOULD implement additional procedures when transmitting messages over UDP. Some kind of ordered delivery could be achieved by the Header's XID Attribute. When there are multiple outstanding requests, client MAY employ XID to correlate received replies with request messages. Notice that this mechanism does not ensure that request messages are received nor processed in the same order as sent. However, XSDF Agents MUST process request operations from the same message in the same order as received. Thus, XSDF Agents SHOULD NOT issue requests Urue±a & Larrabeiti Expires September 15, 2004 [Page 37] Internet-Draft XSDF: Common Elements & Procedures March 2004 in multiple, concurrent UDP messages when there are order constrains between them. XSDF messages SHOULD be restricted to 1232 octets when sent over UDP datagrams. When a XSDF reply message does not fit, it SHOULD be truncated removing the last reply operations and an OVERFLOW_ERROR Element SHOULD be appended. In that case, XSDF message, including the ending Error Element SHOULD also adhere to the size limit. Each UDP datagram MUST contain a single XSDF message, although such message MAY include several operations. Whenever a XSDF request message is sent, source XSDF Agent SHOULD set an UDP_REPLY_TIMER. If the timer expires before a response (i.e. containing reply operations or errors) has been received, the outstanding message SHOULD be retransmitted again, up to UDP_MAX_RETRIES. The initial retransmission MUST occur after INITIAL_RETRY_TIME. Next retransmissions MUST wait an exponentially increased delay, by doubling the time, or the range of the random interval, each time. Retransmitted messages MUST be identical to the initial one, including the XID. Whenever a new message is generated, a new XID MUST be generated. XSDF Agents MAY briefly cache reply messages in order to quickly respond to retransmitted requests (i.e. if first reply message get lost). If the transport layer returns an error from remote peer, or the MAX_RETRIES limit is reached, request message transmission to that XSDF Agent MUST be skipped. In that case, its Service information SHOULD be flushed from cache and next XSDF Agent SHOULD be chosen. If there are no XSDF Agents left, message transmission MUST be aborted and upper layer SHOULD be notified with an error message. 5.3.3 Message transport over multicast UDP Multicast transmission MAY be employed by the XSLP and XSTP protocols. Other XSDF protocols (i.e. XSRP and XSSP) MUST employ only unicast transmission. In IPv4 networks, all XSDF multicast messages MUST be sent to the administratively scoped SLP multicast [6] address (239.255.255.253). In isolated networks, XSDF Agents MAY be configured to employ the all hosts broadcast address (255.255.255.255). In both cases the default TTL is 255. In IPv6 networks there are not broadcast addresses, but there is enough space for several multicast ranges in every scope. XSDF uses the same multicast group-id assignments as SLPv2 [10]: Urue±a & Larrabeiti Expires September 15, 2004 [Page 38] Internet-Draft XSDF: Common Elements & Procedures March 2004 FF0X:0:0:0:0:0:0:116 All XSDF Agents FF0X:0:0:0:0:0:0:123 All XSDF Directory Agents FF0X:0:0:0:0:0:1:1000 XSDF Agents with hash(Service Type) == 1 ... FF0X:0:0:0:0:0:1:13FF XSDF Agents with hash(Service Type) == 1023 The FF0X prefix refers to the appropriate multicast scope between FF01 - FF05, as defined in [7]. XSDF Agents MUST NOT send or join to multicast groups which have a greater scope than the unicast scopes of the associated interface. For example if an interface has only a link local address, the XSDF Agent should join just to the multicast groups in scopes FF01 and FF02. For each scope there are 1023 multicast addresses reserved for SLP, XSLP Service Requests should be sent to the multicast address that is generated as a hash of the specified Service Type. The hash algorithm is defined in SLPv1 [4] as follows: An unsigned 32 bit value V is initialized to 0. Each byte of the Service Type UTF-8 encoded string value is considered consecutively. The current value V is multiplied by 33, then the value of the current string byte is added. Each byte in the Service Type string is processed in this manner. The result is contained in the low order 10 bits of V. For example, the following code implements this algorithm: unsigned long slp_hash(const char *pc, unsigned int len) { unsigned long h = 0; while (len-- != 0) { h *= 33; h += *pc++; } return (0x3FF & h); /* round to a range of 0-1023 */ } There is only one exception to this mapping between Service Types and IPv6 multicast groups. Queries for the "xsdf:da" Service Type MUST be sent to the "All XSDF Directory Agents" (FF0X:0:0:0:0:0:0:123) multicast groups. DAs MUST join to the appropriate "All XSDF Directory Agents" multicast groups. Note that this algorithm is to be applied only to IPv6 multicast groups. In IPv4, all Service Types are mapped to the single SLP multicast group (239.255.255.253). Unless specifically configured not to do so, XSDF Agents MUST be able to receive Service Advertisements to discover new DAs from its Realm. Therefore, IPv6 XSDF Agents MUST join to the "All XSDF Agents" Urue±a & Larrabeiti Expires September 15, 2004 [Page 39] Internet-Draft XSDF: Common Elements & Procedures March 2004 multicast group in all the appropriate IPv6 scopes. Also, IPv4 XSDF Agents MUST join to the SLP multicast group (239.255.255.253) and be able to receive broadcast messages (255.255.255.255). When transmitting a request message to a multicast group, XSDF Agents follow some rules very similar to ones described in previous section. In particular, XSDF messages MUST NOT be larger than 1232 octets and retransmitted messages MUST be identical to the initial one, including its XID value. When sending a multicast request (i.e. not multicast Advertisements), XSDF Agents MAY send up to MC_MAX_RETRIES additional messages. Second message MUST NOT be sent before INITIAL_RETRY_TIME has passed. Further messages MUST follow an exponential backoff by doubling the wait interval each time. Those "messages" could be retransmissions or reissued requests: o Whenever a request message is sent to a multicast group, source XSDF Agent SHOULD set an UDP_REPLY_TIMER. If no reply message is received before it expires, initial request SHOULD be retransmitted. Retransmitted messages MUST be identical to the original one, including its XID field. o Once one or more replies have been received, source XSDF Agent MAY reissue the same request in order to obtain even more Service information. In order to reissue a request, Source XSDF Agent MUST create a new message with a different XID containing the request operations. Also, XSDF Agent MUST include after the message's Header an "ignoreMessage" operation. This Element SHOULD contain the Service Id of all the XSDF Agents that have replied to the request since it was sent in the first time. Request MAY be reissued until no more reply messages are received or until the MC_MAX_RETRIES limit is reached. Initial request message, plus retransmissions, plus reissued requests MUST NOT be in any case greater than the MC_MAX_RETRIES value. 5.4 Message reception All XSDF messages MUST follow the XBE32 [11] encoding rules. Otherwise, message processing MUST be aborted an a XBE32_ERROR Error Element MUST be created. When the message is properly encoded but an unknown Element or Attribute is found, receiving XSDF Agent MUST check the first two bits of the Element type as described in [11]. o If unknown XBE32 Element is mandatory, message processing MUST be aborted. Otherwise, that element MUST be skipped and message processing SHOULD continue. Urue±a & Larrabeiti Expires September 15, 2004 [Page 40] Internet-Draft XSDF: Common Elements & Procedures March 2004 o Unknown XBE32 Element MAY be reported back inside an UNKNOWN_XBE32_ELEMENT Error Element. It is RECOMMENDED that all unknown Elements found were reported inside a single Error Element. When a XSDF message is received by a XSDF Agent, it SHOULD follow these steps in order to check the Header Element: 1. Realm Element SHOULD contain a Compatible Realm with receiving XSDF Agent one. If Domain Attributes do not match or all listed Scopes are unknown, message processing SHOULD be aborted and an UNKNOWN_REALM Error SHOULD be generated. Realm Element MAY be empty, but in that case the message SHOULD contain a "realmRequest" operation. See [13] for details. 2. Unless received from an UA, Source Endpoint Element MUST contain a Service Element with the Id of the source XSDF Agent. Such Id value MUST NOT be a reserved one (i.e. Unknown XSDF Agent or All XSDF Agents). In that case, message MUST be silently dropped. 3. Multicast/broadcast requests MUST contain an "All XSDF Agents" Service Id value in the Destination Endpoint Element. Otherwise, message MUST be silently dropped. 4. Destination Endpoint Element of any unicast messages, unless received from an UA, MUST contain a Service Element with the Id of the receiving XSDF Agent, or the "Unknown XSDF Agent" value. Otherwise, message processing MUST be aborted and an UNKNOWN_SERVICE_ID Error Element MUST be created. 5. XSDF messages MAY include an Authentication Element in its Header. In that case, XSDF Agent MUST check if it contains a valid Cookie Element and/or an EAP Element that authenticates the peer Agent. XSDF Agent MUST ensure that User is authorized to access to the specified Realm. Whenever a received message does not adhere to the XSDF syntax, message processing MUST be aborted and a PARSING_ERROR Error Element MUST be created. When message processing has been aborted and an Error Element has been created, a reply MUST be sent back. Refer to Section 5.2.2 for reply message generation. However, the above rule only applies to unicast request messages. When a reply or a multicast message generates an error, receiving XSDF Agent MUST NOT reply back, and they MUST silently discard such invalid message. A XSDF Agent MAY reject a XSDF message without a valid Cookie Element Urue±a & Larrabeiti Expires September 15, 2004 [Page 41] Internet-Draft XSDF: Common Elements & Procedures March 2004 or from an unauthenticated peer willing to access a restricted Realm. In that case, it MUST generate a reply message containing an AUTHENTICATION_ERROR Error. This Element SHOULD contain the appropriate Elements: a Cookie or an EAP request message to authenticate the peer. Protocol operations SHOULD be skipped until a new request message containing the appropriate Authentication Elements is received. After Header Element has been validated, XSDF Agent begins processing message operations sequentially. Following subsection describe processing of common XSDF operations. 5.4.1 Ignore Message Operation When an Ignore Message Element is found, XSDF Agent MUST search for its own Service Id inside the Service Ids list. If found, message processing MUST be aborted. Otherwise, message operation processing MUST continue. In both cases, this operation does not generate any reply Element. A detailed description of the Ignore Message Element can be found at Section 4.3. Please note that XSDF Agent MUST find exactly its own Service Id. Special values as "Unknown XSDF Agent" or "All XSDF Agents" Ids MUST be skipped. 6. Acknowledgements The Service model defined by XSDF was heavily influenced by the Service Templates defined for SLPv2, the Parameters of the ASAP and ENRP Rserpool protocols, and specially, by Erik Guttman's "serviceid" draft, which details the problems derived from the usage of an URL to identify a Service. Also, most of the protocol procedures detailed in this document are borrowed from the SLP specifications. Urue±a & Larrabeiti Expires September 15, 2004 [Page 42] Internet-Draft XSDF: Common Elements & Procedures March 2004 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [4] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, June 1997. [5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [7] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998. [8] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999. [9] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [10] Guttman, E., "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001. [11] Urue±a, M. and D. Larrabeiti, "eXtensible Binary Encoding (XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004. [12] Urue±a, M. and D. Larrabeiti, "Overview of the eXtensible Service Discovery Framework (XSDF)", draft-uruena-xsdf-overview-00 (work in progress), March 2004. [13] Urue±a, M. and D. Larrabeiti, "eXtensible Service Location Protocol (XSLP)", draft-uruena-xslp-00 (work in progress), March 2004. [14] Urue±a, M. and D. Larrabeiti, "eXtensible Service Registration Protocol (XSRP)", draft-uruena-xsrp-00 (work in progress), March 2004. [15] Urue±a, M. and D. Larrabeiti, "eXtensible Service Subscription Urue±a & Larrabeiti Expires September 15, 2004 [Page 43] Internet-Draft XSDF: Common Elements & Procedures March 2004 Protocol (XSSP)", draft-uruena-xssp-00 (work in progress), March 2004. [16] Urue±a, M. and D. Larrabeiti, "eXtensible Service Transfer Protocol (XSTP)", draft-uruena-xstp-00 (work in progress), March 2004. Authors' Addresses Manuel Urue±a Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 87 95 EMail: muruenya@it.uc3m.es David Larrabeiti Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 99 53 EMail: dlarra@it.uc3m.es Urue±a & Larrabeiti Expires September 15, 2004 [Page 44] Internet-Draft XSDF: Common Elements & Procedures March 2004 Appendix A. XSDF Constants A.1 XBE32 Attributes & Elements Element Name XBE32 Type ------------ ---------- service 0x0100 serviceState 0x0110 metaInfo 0x0111 serviceMainInfo 0x0120 serviceType 0x0121 serviceLocationInfo 0x0130 inet 0x0131 protocol 0x0132 serviceAddInfo 0x0140 cacheState 0x0211 selectState 0x0311 selectInfo 0x0321 updateInfo 0x0521 user 0x0600 desc 0x0610 icon 0x0620 realm 0x0700 namingAuth 0x0710 header 0x0810 source 0x0811 destination 0x0812 authInfo 0x0813 target 0x0821 filter 0x0822 ignoreMessage 0x0830 signatureInfo 0x08e1 error 0x08f1 Urue±a & Larrabeiti Expires September 15, 2004 [Page 45] Internet-Draft XSDF: Common Elements & Procedures March 2004 Attribute Name XBE32 Type Value Type Value Length -------------- ---------- ---------- ------------ id 0x3511 opaque16 128 bits type 0x2812 string variable path 0x2813 string variable alias 0x2814 string variable ipv4Addrs 0x3215 opaque4 variable ipv6Addrs 0x3516 opaque16 variable hostname 0x2817 string variable capabilities16 0x3118 opaque2 variable transPorts 0x3219 opaque4 variable stateTimestamp 0x331a int64 64 bits mainInfoSeqNum 0x321b int32 32 bits locationInfoSeqNum 0x321c int32 32 bits addInfoSeqNum 0x321d int32 32 bits age 0x3221 int32 32 bits ttl 0x3222 int32 32 bits lifetime 0x3223 int32 32 bits resources 0x3231 int32 32 bits workload 0x3232 int32 32 bits policies 0x3133 opaque2 variable priority 0x3234 int32 32 bits weight 0x3235 int32 32 bits minLife 0x3253 int32 32 bits maxLife 0x3254 int32 32 bits name 0x2861 string variable url 0x2862 string variable text 0x2863 string variable lang 0x2864 string variable vendor 0x2865 string variable vendorURL 0x2866 string variable model 0x2867 string variable modelURL 0x2868 string variable version 0x2869 string variable mimeType 0x286a string variable width 0x326b int32 32 bits height 0x326c int32 32 bits depth 0x326d int32 32 bits domain 0x2871 string variable scope 0x2872 string variable prefix 0x2873 string variable template 0x2874 string variable xid 0x3281 opaque4 variable serviceIds 0x3582 opaque16 variable code 0x3283 opaque4 32 bits cookie 0x2184 opaque variable eapInfo 0x2185 opaque variable digestMethod 0x3286 opaque4 32 bits Urue±a & Larrabeiti Expires September 15, 2004 [Page 46] Internet-Draft XSDF: Common Elements & Procedures March 2004 signatureMethod 0x3287 opaque4 32 bits signatureValue 0x2188 opaque variable A.2 Timers and Constants Timer name Description --------------- ---------------------------------------------- REPLY_TIMER Timeout for TCP/SCTP replies UDP_REPLY_TIMER Timeout for UDP request message retransmission Constant name Default Value Description ---------------------- ------------- ----------------------------- MAX_IDLE_CONN_TIME 5 minutes Lifetime of idle connections UDP_INITIAL_RETRY_TIME 2 seconds First retransmission delay UDP_MAX_RETRIES 3 times Max number of request message retransmissions over UDP MC_MAX_RETRIES 3 times Max number of additional multicast request messages Urue±a & Larrabeiti Expires September 15, 2004 [Page 47] Internet-Draft XSDF: Common Elements & Procedures March 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Urue±a & Larrabeiti Expires September 15, 2004 [Page 48] Internet-Draft XSDF: Common Elements & Procedures March 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urue±a & Larrabeiti Expires September 15, 2004 [Page 49] Network Working Group M. Urue±a Internet-Draft D. Larrabeiti Expires: September 15, 2004 UC3M March 17, 2004 eXtensible Service Location Protocol (XSLP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document specifies the eXtensible Service Location Protocol (XSLP), a lightweight protocol that allows User Agents to obtain Service information from Directory Agents, even from remote domains. Also, XSLP allows User Agents to perform multicast queries to the Service Agents inside the same organization. XSLP is the main protocol of the eXtensible Service Discovery Framework (XSDF). Urue±a & Larrabeiti Expires September 15, 2004 [Page 1] Internet-Draft XSLP Protocol March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Notation Conventions . . . . . . . . . . . . . . . . . . . 4 2. Messages Format . . . . . . . . . . . . . . . . . . . . . . 5 2.1 XSLPv1 Element . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Service Request Element . . . . . . . . . . . . . . . . . 5 2.2.1 Services Target Element . . . . . . . . . . . . . . . 6 2.2.2 Return Element . . . . . . . . . . . . . . . . . . . . 7 2.3 Service Reply Element . . . . . . . . . . . . . . . . . . 7 2.4 Service Advertisement Element . . . . . . . . . . . . . . 8 2.5 Realm Request Element . . . . . . . . . . . . . . . . . . 8 2.5.1 Realm Filter Element . . . . . . . . . . . . . . . . . 9 2.6 Realm Reply Element . . . . . . . . . . . . . . . . . . . 9 2.7 Service Type Request Element . . . . . . . . . . . . . . . 10 2.7.1 Service Types Filter Element . . . . . . . . . . . . . 10 2.8 Service Type Reply Element . . . . . . . . . . . . . . . . 10 2.9 Redirect Element . . . . . . . . . . . . . . . . . . . . . 11 2.10 Common Operation Parameters . . . . . . . . . . . . . . 11 2.10.1 Record Element . . . . . . . . . . . . . . . . . . . 12 3. XSLP Operation Procedures . . . . . . . . . . . . . . . . . 13 3.1 Service Request . . . . . . . . . . . . . . . . . . . . . 14 3.2 Service Advertisement . . . . . . . . . . . . . . . . . . 15 3.3 Realm Request . . . . . . . . . . . . . . . . . . . . . . 16 3.4 Service Type Request . . . . . . . . . . . . . . . . . . . 16 3.5 Redirect Reply . . . . . . . . . . . . . . . . . . . . . . 17 3.6 Remote Domains . . . . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 A. XSLP Constants . . . . . . . . . . . . . . . . . . . . . . . 20 A.1 XBE32 Elements . . . . . . . . . . . . . . . . . . . . . . 20 A.2 Time Constants . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 21 Urue±a & Larrabeiti Expires September 15, 2004 [Page 2] Internet-Draft XSLP Protocol March 2004 1. Introduction XSDF [4] is a framework for Service Discovery. It allows Users to dynamically find available network Services and choose the better ones following certain selection policies. In XSDF, User Agents (UAs) may issue multicast Service requests directly to Service Agents (SAs). In bigger networks, UAs request Service information to a central repository managed by the so-called Directory Agents (DAs). XSLP is the protocol employed by UAs to obtain Service information from SAs and/or DAs. Such information contains the location of the Service, the expected validity time and some selection data to choose the best Service instance, if multiple ones have been discovered. This mechanism allows end hosts, with little or no configuration, to dynamically find the best available network Services. In networks where no DAs have been deployed, as unmanaged LANs, UAs directly query SAs for Services. Such XSLP request messages are sent to SAs in multicast (or broadcast if multicast is not available). SAs with Services that match with such request return these Services to the UA in unicast replies. Multicast XSLP Request +----+ +----+ ----------------------> +----+| | UA | | SA |+ +----+ <---------------------- +----+ Unicast XSLP Replies As multicast requests have scalability issues, larger networks will deploy one or more DAs. Those DAs centralize all Service information from one or more Scopes of a Domain. SAs register the Services from those Scopes at any of these DAs employing XSRP. Then, XSLP messages can be directly issued in unicast to any of these DAs. Unicast XSLP Request +----+ --------------------> +----+ | UA | | DA | +----+ <-------------------- +----+ Unicast XSLP Reply Of course, UAs first need to find the appropriate DAs. As DAs are Services by themselves, when they have no DAs configured, they can bootstrap by querying for DA agents in multicast as if they were any other Service. Once one or more DAs serving a Scope are discovered, all location requests/registrations for Services at those Scopes should be issued in unicast to any of those DAs. As each Scope should be treated as a different environment, both Urue±a & Larrabeiti Expires September 15, 2004 [Page 3] Internet-Draft XSLP Protocol March 2004 modes of operation may coexist in a single network. If DAs are deployed, but they do not manage all the Scopes at the Domain, an UA may issue both, unicast requests to DAs, and multicast requests to SAs from unmanaged Scopes. 1.1 Definitions Domain: A Domain is a single administrative organization containing Users and Services. Scope: A Scope is a subset of Users and Services from a Domain, typically making a logical administrative group. Realm: A Realm is a combination of a Domain and one or more Scopes from such Domain, if any. Service: A Service is any process attached to a network that provides some kind of functionality to Users or other Services. A Service belongs to a single Realm. User Agent (UA): A process working on the User's (or other process) behalf to discover Services, and select the best available one. UAs obtain Service information from Directory Agents and Service Agents via XSLP. Service Agent (SA): A Service Agent is itself a Service that advertise Service information on behalf other processes. SAs are queried by User Agents for Services via XSLP, and/or register Service information in Directory Agents employing XSRP. Directory Agent (DA): A Directory Agent is a Service that, when deployed, acts as a central repository of all Service information from a Realm. Service Agents register its Services in a DA employing the XSRP protocol. Then, User Agents are able to query that information with XSLP. An Scope can be served by multiple DAs that coordinate themselves via XSSP & XSTP protocols. XSDF Agent: Any process that employs any XSDF protocol to interact with other XSDF Agents. All XSDF Agents must implement the XSLP protocol. UAs behave as clients while SAs and DAs are servers. 1.2 Notation Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [1]. Urue±a & Larrabeiti Expires September 15, 2004 [Page 4] Internet-Draft XSLP Protocol March 2004 2. Messages Format This section defines the format of all XSLP messages. These messages are exchanged between an User Agent and, a Directory Agent or several Service Agents. XSDF protocol messages are encoded employing XBE32 [3]. Definitions for common XSDF Elements and Attributes can be found at [5] 2.1 XSLPv1 Element All XSDF messages have a common format: a single XBE32 Element containing a Header, and one or more protocol Operations. XSLP messages are encoded inside a XSLPv1 Element. XSLPv1 Element: Element Name : xslpv1 XBE32 Type : 0x0901 +---------------------------------------------------------------+ : Header Element : +---------------------------------------------------------------+ : XSLP Operation Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : XSLP Operation Element #N : +---------------------------------------------------------------+ : [ Signature Information Element ] : +---------------------------------------------------------------+ Header and Signature Information Elements are defined in [5]. Next subsections describe XSLP Operation Elements. 2.2 Service Request Element UAs send this operation request to DAs or SAs in order to obtain the specified Service information from their common Realm. Urue±a & Larrabeiti Expires September 15, 2004 [Page 5] Internet-Draft XSLP Protocol March 2004 Service Request Element: Element Name : serviceRequest XBE32 Type : 0x0930 +---------------------------------------------------------------+ : Services Target Element : +---------------------------------------------------------------+ : [ Services Filter Element ] : +---------------------------------------------------------------+ : Return Element : +---------------------------------------------------------------+ Services Filter Element is defined in [5]. All Services specified by the Target but the ones with Ids listed in the Filter Element SHOULD be included in the reply operation. The Return Element defines which information Elements SHOULD be returned in such reply. 2.2.1 Services Target Element UA specifies in this Element the Type of the Service it is interested in, for example "printer". It MAY also specify the exact Id of the requested Services, but in any case the Service Type MUST be included. Target Element: Element Name : target XBE32 Type : 0x0821 +---------------------------------------------------------------+ : Service Type Element : +---------------------------------------------------------------+ | [ Service Ids ] | +---------------------------------------------------------------+ Service Ids Attribute and Service Type Element are defined in [5]. All Service Request operations MUST contain the Type of the Services being requested. If the Type Element contains any Path Element, the returned elements MUST provide the requested resources. That is, their Path Elements MUST fully contain, at least, one of the requested Paths ("/" includes "/store/index.html". Although "/s" does not include "/store/index.html", but "/s/all"). If no Path attribute is included, all elements SHOULD be returned, no matter which resources they are providing. When included, the Service Ids Attribute indicates which Services Urue±a & Larrabeiti Expires September 15, 2004 [Page 6] Internet-Draft XSLP Protocol March 2004 should be returned. XSDF Server Agent SHOULD NOT return information about other Services but the ones listed here. When the list does contain unknown Services, those Ids SHOULD be silently skipped. 2.2.2 Return Element In this Element, UA indicates which information of the selected Services should be returned. An empty "return" Element will generate a reply containing just the Service Ids found. If a "serviceState" Element is specified, Services will carry the Element information of the same name, and so on. Return Element: Element Name : return XBE32 Type : 0x0841 +---------------------------------------------------------------+ | [ Service State ] | +---------------------------------------------------------------+ | [ Service Main Information ] | +---------------------------------------------------------------+ | [ Service Location Information ] | +---------------------------------------------------------------+ | [ Service Additional Information ] | +---------------------------------------------------------------+ When "return" Element contains the Service State empty Element, Services in the reply MUST contain their Service State Elements. When "return" Element contains the Service Main Information empty Element, Services in the reply MUST contain their Service Main Information Elements. When "return" Element contains the Service Location Information empty Element, Services in the reply MUST contain their Service Location Information Elements. When "return" Element contains the Service Additional Information empty Element, Services in the reply MUST contain their Service Additional Information Elements. 2.3 Service Reply Element This reply operation is sent back to the UA as a response to a previous "serviceRequest" operation. It contains all the selected Service information and its validity time. Urue±a & Larrabeiti Expires September 15, 2004 [Page 7] Internet-Draft XSLP Protocol March 2004 Service Reply Element: Element Name : serviceReply XBE32 Type : 0x0941 +---------------------------------------------------------------+ : [ Record Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Record Element #N ] : +---------------------------------------------------------------+ Record Element is defined in Section 2.10.1. Each Record Element contains information about a single Service that matches with a previous "serviceRequest". If no Service Records are included, source XSDF Agent does not known any Service that matches. However, empty "serviceReply" operations MUST NOT be sent as a response to multicast queries. 2.4 Service Advertisement Element Service Advertisements MAY be sent by DAs and SAs containing Service information they known. In the so-called Passive DA Discovery process, DAs send multicast messages to all XSDF Agents from the same Realm to advertise its own Service information. Also, Service Advertisements MAY be employed by XSSP [7] as a notification mechanism. Service Advertisement Element: Element Name : serviceAdvert XBE32 Type : 0x0921 +---------------------------------------------------------------+ : Record Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : Record Element #N : +---------------------------------------------------------------+ Record Element is defined in Section 2.10.1. Service Elements inside Record Elements MUST include Service Id, Main and Location Elements. Other Service information is optional and SHOULD NOT appear. 2.5 Realm Request Element This Element defines an optional operation. It requests the Realm of the destination XSDF Agent. Urue±a & Larrabeiti Expires September 15, 2004 [Page 8] Internet-Draft XSLP Protocol March 2004 Realm Request Element: Element Name : realmRequest XBE32 Type : 0xC940 +---------------------------------------------------------------+ : [ Realm Filter Element ] : +---------------------------------------------------------------+ 2.5.1 Realm Filter Element When this optional Element is included, the "realmReply" response SHOULD NOT include the Scopes listed in this field. Realm Filter Element: Element Name : filter XBE32 Type : 0x0841 +---------------------------------------------------------------+ : Realm Element : +---------------------------------------------------------------+ Realm Element is defined in [5]. This Element contains a sorted list of Scopes that SHOULD NOT be included in the "realmReply" response. List MUST be sorted in order to ease Scope search. 2.6 Realm Reply Element This reply operation is sent back to the UA as a response to a previous "realmRequest" operation. It contains the full Realm of the source XSDF Agent but the filtered Scopes. Realm Reply Element: Element Name : realmReply XBE32 Type : 0xC941 +---------------------------------------------------------------+ : Realm Element : +---------------------------------------------------------------+ Realm Element is defined in [5]. Returned Realm Element MUST contain the Realm, source XSDF Agent belongs to. Scopes included in the request Filter parameter SHOULD NOT be included. Urue±a & Larrabeiti Expires September 15, 2004 [Page 9] Internet-Draft XSLP Protocol March 2004 2.7 Service Type Request Element This Element defines an optional operation. It requests the list of Service Types, of all the Services known by the destination XSDF agent. Service Type Request Element: Element Name : serviceTypeRequest XBE32 Type : 0xC950 +---------------------------------------------------------------+ : Realm Target Element : +---------------------------------------------------------------+ : [ Service Types Filter Element ] : +---------------------------------------------------------------+ Realm Target Element is defined in [5]. The Realm Target Element MAY contain the subset of Header's Realm Scopes to request Service Types from. If Realm Target is empty, Service Types, from all the Scopes specified in message Header, are requested. 2.7.1 Service Types Filter Element When this Element is included, the reply "serviceTypeReply" message SHOULD NOT include the Service Types listed in this field. Service Types Filter Element: Element Name : filter XBE32 Type : 0x0841 +---------------------------------------------------------------+ : [ Service Type Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Service Type Element #N ] : +---------------------------------------------------------------+ Service Type Element is defined in [5]. This Element contains a sorted list of Service Types that SHOULD NOT be included in the "serviceTypeReply" response. List MUST be sorted by the Type Attribute in order to ease Service Type search. 2.8 Service Type Reply Element This reply operation is sent back to the UA as a response to a previous "serviceTypeRequest" operation. It contains the list of all Urue±a & Larrabeiti Expires September 15, 2004 [Page 10] Internet-Draft XSLP Protocol March 2004 the Service Types from specified Scopes. Service Type Reply Element: Element Name : serviceTypeReply XBE32 Type : 0xC951 +---------------------------------------------------------------+ : [ Service Type Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Service Type Element #N ] : +---------------------------------------------------------------+ Service Type Element is defined in [5]. Returned Service Type Elements contains information about non-filtered Service Types from specified Scopes. If no Service Types are included, no Services are registered at specified Scopes or all Service Types have been filtered. However, empty "serviceTypeReply" operations MUST NOT be sent as a response to multicast queries. 2.9 Redirect Element This reply operation indicates UA that it SHOULD resent the request to the specified XSDF Agents from the same Realm. Redirect Element: Element Name : redirect XBE32 Type : 0x0911 +---------------------------------------------------------------+ : Service Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : Service Element #N : +---------------------------------------------------------------+ Service Element is defined in [5]. As the UA receiving this response SHOULD forward its XSLP request to the specified Services, all the listed Services MUST refer to XSDF DA or SA agents. Each Service Element MUST contain Service Id, Main and Location Elements. Other Service information is optional and SHOULD NOT appear. 2.10 Common Operation Parameters When an UA requests Service information, SAs and DAs return such information inside a Record Element, that also contains for how long this data is expected to remain valid. This section describes in Urue±a & Larrabeiti Expires September 15, 2004 [Page 11] Internet-Draft XSLP Protocol March 2004 detail the "record" Element. 2.10.1 Record Element This is the main parameter of the "serviceReply" and "serviceAdvert" operations. It contains the advertised Service or the information requested by an UA. Record Element: Element Name : record XBE32 Type : 0x0200 +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : Record State Element : +---------------------------------------------------------------+ Service Element is defined in [5]. 2.10.1.1 Record State Element This Element contains meta-information about the associated Service carried inside the Record Element. Record State Element: Element Name : recordState XBE32 Type : 0x0210 +---------------------------------------------------------------+ : Cache State Element : +---------------------------------------------------------------+ Cache State Element is defined in [5]. Cache State Element contains two Attributes about the associated Service, its Age and the remaining TTL. UA SHOULD flush the Service information from its cache when its TTL value is zero. Urue±a & Larrabeiti Expires September 15, 2004 [Page 12] Internet-Draft XSLP Protocol March 2004 3. XSLP Operation Procedures All XSDF Agents MUST follow the common procedures for XSDF Agent initialization, message generation, transmission and processing defined in [5]. This section specifies additional procedures for the XSLP protocol. XSLP is a Client-Server protocol. UAs act as Clients sending operation requests while SAs and DAs act as Servers processing those requests and sending replies back. All XSLP Agents MUST support the UDP transport protocol and MAY also support TCP and SCTP. The port number for all these transport protocols MUST be 727. When a Scope is managed by one or more active DAs, UAs MUST employ unicast transmission to obtain Services from the DAs that manage that Scope. In that case, the UA SHOULD choose the better DA (that supports the "xslp" protocol) as advertised by their Service information. Once a XSLP message with the appropriate operations has been generated, it is sent to the selected DA. If message can not be delivered, next DA from the same Realm SHOULD be chosen. If there are no DAs left, Scope is marked as "unmanaged" and search process MAY follow as defined below. In unmanaged Scopes from local Domain, UAs SHOULD employ multicast XSLP messages in order to reach all the SAs of those Scopes as defined in [5]. However, if a new DA managing a previously unmanaged Scope is discovered, the Scope becomes "managed" and UAs MUST employ unicast XSLP messages as defined above. Service Types have associated IPv6 multicast groups. Thus, multicast queries by Service Type MUST be sent to those groups. For XSLP operations that have no associated Service Type, the IPv6 multicast group derived from the "xsdf:sa" Service Type (FE0X:0:0:0:0:0:1:1216) SHOULD be employed in order to reach all the SAs at unmanaged Scopes. When in an "unmanaged" Scope, SAs MUST reply to multicast queries with unicast messages. However, if the reply operation is empty, SAs MUST NOT respond, exactly the same as if an error has occurred. This rule only applies to multicast queries, for unicast ones, SAs MUST return the empty reply operation. An UA MAY belong to multiple Scopes, some could be managed by DAs while others remain unmanaged. Thus, UAs SHOULD be able to perform both kinds of searches, unicast messages to a single DA and multicast messages to several SAs. While DA MUST support unicast queries, SAs SHOULD support both, unicast and multicast queries from UAs. Urue±a & Larrabeiti Expires September 15, 2004 [Page 13] Internet-Draft XSLP Protocol March 2004 As"LOCAL" Scope only contains Services related to the local Server, it has its own rules. Multicast queries MUST NOT refer to the "LOCAL" scope. Also, "LOCAL" Services SHOULD NOT be included in Service advertisements. In order to obtain Service information from this Scope, an UA MUST employ just unicast messages targeted to the particular XSDF Agent. Service information can be obtained from several Sources and mechanisms, thus multiple versions MAY be returned. However, as Service information SHOULD be the same across all its Scopes, all version MUST be considered as a Single Service where newer information replaces older one. 3.1 Service Request The so-called Active Service Discovery mechanism, allows an UA to obtain information about Services at a specified Realm. UAs will send "serviceRequest" operations, while DAs or SAs will respond with "serviceReply" carrying the matching Services they known. Refer to Section 2.2 and Section 2.3 for a detailed description of "serviceRequest" and "serviceReply" operations. When a SA or a DA receives a valid XSLP message with an authorized "serviceRequest" operation, it MUST follow these steps to process such operation: 1. Obtain the list of Scopes to query Services from the message's Header. 2. Obtain all the Services with the specified Type that belong to the above Scope list. If Service Type Element contains some Path Elements, Services not providing any of the specified resources SHOULD be dropped. 3. If the Target parameter specifies the Ids of the requested Services, XSDF Agent SHOULD find those Services and check that they belong to the specified Realms and have the specified Service Type. 4. If the request operation contains a Filter parameter, specified Services SHOULD be removed from the reply. 5. Once the list of Services that match has been obtained, reply operation MUST generate a Record Element for each one. LAST_UPDATE_TIMESTAMP associated to the Service registration MUST be employed to calculate the Age of the record (by subtracting it from current time). Remaining TTL is calculated as the associated SERVICE_LIFETIME variable minus its Age. Both registration Urue±a & Larrabeiti Expires September 15, 2004 [Page 14] Internet-Draft XSLP Protocol March 2004 variables are defined in [6]. 6. Record's Service Element MUST include the Service Identifier, other information is optional and SHOULD appear if listed in the Return parameter of the "serviceRequest" operation. If specified Service Type has an associated Selection Policy, DA MAY sort/filter returned Services according to that policy. Therefore, if UAs does not have additional Service information they SHOULD try to access the discovered Services in the specified order. A XSDF Agent MAY employ XSLP itself in its initialization phase to discover DAs from a Realm. As the UA does not know any DA from the Realm, all the Scopes are considered to be "unmanaged" and "serviceRequest" operation MUST be sent in a multicast message. In that case, the Service Type to be included in the request MUST be "xsdf:da". XSDF Agents MUST wait for some time, distributed between 0 and INIT_FIND_DELAY, before trying to obtain DA Service information via this mechanism. Also, XSDF Agents MAY employ this mechanism periodically in order to discover new DAs from unmanaged Scopes. Consecutive queries MUST be spaced at least by a RETRY_FIND_DELAY interval. 3.2 Service Advertisement UAs MAY also obtain Service information by the Passive Service Discovery mechanism. In this process UAs do not request Services but DAs and SAs do sent multicast messages advertising Service information inside "serviceAdvert" Elements. Refer to Section 2.4 for a detailed description of the "serviceAdvert" operation. Directory Agents MUST periodically advertise its own Service information inside Service Advertisement messages. Those DA Advertisement messages MUST be sent to the "All XSDF Agents" multicast group as defined in [5]. Consecutive advertisements MUST be spaced at least by a DA_ADVERT_DELAY interval. SAs MAY also employ this mechanism to advertise Services in unmanaged Scopes. However, a SA MUST NOT advertise any Service belonging to a Realm fully managed by one or more active DAs. Service Advertisement messages MAY be also employed to notify modification Events. See XSSP [7] for a complete description of this mechanism. As described in [7], a service becoming unavailable MAY be advertised within a Service Advertisement message with a zero TTL. Directory Agents SHOULD notify that are to become unavailable with this Urue±a & Larrabeiti Expires September 15, 2004 [Page 15] Internet-Draft XSLP Protocol March 2004 mechanism. They MAY advertise also the service information of other alternative DAs, thus UAs and SAs may be able to migrate their XSDF operations to them without disruption. 3.3 Realm Request XSDF Agents that support this kind of transaction may be queried in order to obtain the Realm they belong to. In that case, UAs send "realmRequest" operations. XSDF Agents respond with "realmReply" operations containing their Realms. Refer to Section 2.5 and Section 2.6 for a detailed description of "realmRequest" and "realmReply" operations. When a DA or SA receives a valid XSLP message with an authorized "realmRequest" operation, it MAY generate a "realmReply" response if it supports such operation, or reject it as unsupported (UNKNOWN_XBE32_ELEMENT). Response MUST contain the XSDF Agent's Realm but the Scopes listed in the Filter parameter, if present. In order that UAs and SAs know if a DA supports this operation, the DA MAY advertise the "RealmReply" XBE32 Type (0xC941) in the Capability Attribute of the "xslp" Protocol Element [5]. UAs and SAs MAY employ this operation in the initialization phase in order to obtain the Realm they belong to. In that case, they MAY collect the Realms of pre-configured DAs. Its Realm will be generated as the common Domain, and all the discovered Scopes. 3.4 Service Type Request When XSDF Agents support these optional operations, an UA is able to obtain all the Service Types from a Realm. UAs send "serviceTypeRequest" operations while DAs and SAs answer with "serviceTypeReply" operations. Refer to Section 2.7 and Section 2.8 for a detailed description of "serviceTypeRequest" and "serviceTypeReply" operations. When a SA or a DA receives a valid XSLP message with an authorized "realmRequest" operation, it MAY generate a "serviceTypeReply" response if it supports such operation or reject it as unsupported (UNKNOWN_XBE32_ELEMENT). Response MUST contain the list of all the known Service Types from specified Realm, but the ones listed in the Filter parameter, if present. In order that UAs and SAs know if a DA supports this operation, the DA MAY advertise the "ServiceTypeReply" XBE32 Type (0xC951) in the Capability Attribute of the "xslp" Protocol Element [5]. Urue±a & Larrabeiti Expires September 15, 2004 [Page 16] Internet-Draft XSLP Protocol March 2004 3.5 Redirect Reply A XSDF Agent MAY reply to a XSLP request message with a "redirect" operation. In that case, it has not processed any of the requested operations but indicates that the specified XSDF Agents are better suited to perform such request. Refer to Section 2.9 for a detailed description of the "redirect" operation. When an UA receives a valid "redirect" operation as a response for a request message, it SHOULD generate a new request message with the same operations as the previous one. That message SHOULD be sent to the XSDF Agents included in the "redirect" operation. If Selection information is included, best one SHOULD be chosen. Otherwise, first one SHOULD be selected. If message can not be delivered, next DA SHOULD be chosen until message gets delivered or there are no XSDF Agents left. 3.6 Remote Domains Previous sections refer only to XSLP operations in the local domain. However, XSLP allows Service Discovery in both, remote and local sites. Therefore, when an UA is requested to obtain some Service information form a Realm, it MUST compare the specified Realm's Domain with its own, if any. If both Domains match, Local Service Discovery is requested and the above rules apply. If Domains do not match, a Remote Service Discovery procedure is required. This procedure is exactly the same as the local one when DAs are deployed, but the mechanism to locate the DAs of the remote Domain. Multicast requests MUST NOT be employed to locate DAs from non-local Domains. Instead of pre-configured DAs or multicast queries as in the local case, remote DAs could be located by querying the DNS. DAs managing the Services from the "PUBLIC" Scope MAY be advertised in DNS SRV Resource Records [2] of the remote DNS Domain. Those Resource Records MUST have the following name: "_xslp._udp." plus the remote Domain name. For example, DAs managing "PUBLIC" Services from "example.com" Domain could be located by obtaining the "_xslp._udp.example.com" DNS SRV RR. Once the public DAs from remote Domain have been discovered (including its weight value), UAs SHOULD follow the same procedures already defined to query local DAs. Urue±a & Larrabeiti Expires September 15, 2004 [Page 17] Internet-Draft XSLP Protocol March 2004 4. Security Considerations XSDF Service Discovery Framework relies on security procedures provided by lower layers, as TLS or IPSec ones. However, it defines some authentication mechanisms that SHOULD be employed when similar ones are not being provided by the layers below. See [5] for a detailed description of these mechanisms. XSLP over TLS is named "xslp/tls" and its default port number for the TCP and SCTP transport protocols is 728. In insecure environments, XSDF Agents receiving Service Advertisement messages or "redirect" operations SHOULD carefully check if they came from a trusted XSDF Agent. In order to provide message authentication and integrity, SAs and DAs SHOULD append a Signature Element to messages containing Service Advertisements and Redirect Replies. 5. Acknowledgements XSLP protocol was designed as an evolution of the SLPv2 one and its extensions. It also also includes many ideas borrowed from Rserpool's ASAP. Therefore, we wish to thank the authors of both specifications, as well as Weibin Zhao, Henning Schulzrinne, Erik Guttman, Chatschik Bisdikan and William F. Jerome. They are the authors of the SLP Remote Discovery draft, which is the foundation of the Remote Domains section of this document. Urue±a & Larrabeiti Expires September 15, 2004 [Page 18] Internet-Draft XSLP Protocol March 2004 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [3] Urue±a, M. and D. Larrabeiti, "eXtensible Binary Encoding (XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004. [4] Urue±a, M. and D. Larrabeiti, "Overview of the eXtensible Service Discovery Framework (XSDF)", draft-uruena-xsdf-overview-00 (work in progress), March 2004. [5] Urue±a, M. and D. Larrabeiti, "eXtensible Service Discovery Framework (XSDF): Common Elements and Procedures", draft-uruena-xsdf-common-00 (work in progress), March 2004. [6] Urue±a, M. and D. Larrabeiti, "eXtensible Service Registration Protocol (XSRP)", draft-uruena-xsrp-00 (work in progress), March 2004. [7] Urue±a, M. and D. Larrabeiti, "eXtensible Service Subscription Protocol (XSSP)", draft-uruena-xssp-00 (work in progress), March 2004. Authors' Addresses Manuel Urue±a Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 87 95 EMail: muruenya@it.uc3m.es Urue±a & Larrabeiti Expires September 15, 2004 [Page 19] Internet-Draft XSLP Protocol March 2004 David Larrabeiti Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 99 53 EMail: dlarra@it.uc3m.es Appendix A. XSLP Constants A.1 XBE32 Elements Element Name XBE32 Type ------------ ---------- xslpv1 0x0901 redirect 0x0911 serviceAdvert 0x0921 serviceRequest 0x0930 serviceReply 0x0931 realmRequest 0xC940 realmReply 0xC941 serviceTypeRequest 0xC950 serviceTypeReply 0xC951 filter 0x0841 return 0x0851 record 0x0200 recordState 0x0210 A.2 Time Constants Constant name Default Value Description ------------------ ------------- ----------------------------------- INIT_FIND_DELAY 5 seconds Max delay before obtaining Realm or DAs info via XSLP RETRY_FIND_DELAY 1 hour Min delay before repeating XSLP DA Discovery DA_ADVERT_DELAY 30 minutes Min delay between DA Advertisements Urue±a & Larrabeiti Expires September 15, 2004 [Page 20] Internet-Draft XSLP Protocol March 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Urue±a & Larrabeiti Expires September 15, 2004 [Page 21] Internet-Draft XSLP Protocol March 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urue±a & Larrabeiti Expires September 15, 2004 [Page 22] Network Working Group M. Urue±a Internet-Draft D. Larrabeiti Expires: September 15, 2004 UC3M March 17, 2004 eXtensible Service Registration Protocol (XSRP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document specifies the eXtensible Service Registration Protocol (XSRP), a lightweight protocol that allows Service Agents to register Service information at Realms managed by one or more Directory Agents. Then, User Agents will be able to obtain that Service information from Directory Agents. XSRP is one of the protocols of the eXtensible Service Discovery Framework (XSDF). Urue±a & Larrabeiti Expires September 15, 2004 [Page 1] Internet-Draft XSRP Protocol March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Notation Conventions . . . . . . . . . . . . . . . . . . . 4 2. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 XSRPv1 Element . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Register Service Element . . . . . . . . . . . . . . . . . 5 2.3 Register Service Acknowledgment Element . . . . . . . . . 6 2.4 Update Service Element . . . . . . . . . . . . . . . . . . 7 2.5 Update Service Acknowledgment Element . . . . . . . . . . 8 2.6 Deregister Service Element . . . . . . . . . . . . . . . . 9 2.7 Deregister Service Acknowledgment Element . . . . . . . . 10 2.8 Error Element . . . . . . . . . . . . . . . . . . . . . . 10 2.9 Common Operation Parameters . . . . . . . . . . . . . . . 11 2.9.1 Register State Element . . . . . . . . . . . . . . . . 11 2.9.2 Register Information Element . . . . . . . . . . . . . 11 3. XSRP Operation Procedures . . . . . . . . . . . . . . . . . . 13 3.1 Service Agent Initialization . . . . . . . . . . . . . . . 13 3.2 Service Registration . . . . . . . . . . . . . . . . . . . 14 3.3 Service Registration Update . . . . . . . . . . . . . . . 16 3.4 Service Deregistration . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 A. XSRP Constants . . . . . . . . . . . . . . . . . . . . . . . . 21 A.1 XBE32 Elements . . . . . . . . . . . . . . . . . . . . . . 21 A.2 Variables, Timers and Constants . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 22 Urue±a & Larrabeiti Expires September 15, 2004 [Page 2] Internet-Draft XSRP Protocol March 2004 1. Introduction XSDF [4] is a framework for Service Discovery. It allows Users to dynamically find available network Services and choose the better ones following certain selection policy. In XSDF, User Agents (UAs) may issue multicast Service requests directly to Service Agents (SAs). In bigger networks, UAs request Service information to a central repository managed by the so-called Directory Agents (DAs). XSRP is the protocol employed by SAs to register Service information at DAs which manage Service's Scopes. A DA acts as a central cache of Service information from the Scopes it manages. Service information must be refreshed periodically to avoid becoming stalled. A Service must be deregistered when it becomes unavailable. Also, when registering a Service via XSRP, SA may instruct DA to apply some Selection policy to Services with the same Type. Therefore, when a DA replies to an UA XSLP request, it MAY sort Services or just provide a subset of them. Note that this DA Selection process is independent from the one performed by UAs when including Selection data in Service information. 1.1 Definitions Domain: A Domain is a single administrative organization containing Users and Services. Scope: A Scope is a subset of Users and Services from a Domain, typically making a logical administrative group. Realm: A Realm is a combination of a Domain and one or more Scopes from such Domain, if any. Service: A Service is any process attached to a network that provides some kind of functionality to Users or other Services. A Service belongs to a single Realm. User Agent (UA): A process working on the User's (or other process) behalf to discover Services, and select the best available one. UAs obtain Service information from Directory Agents and Service Agents via XSLP. Service Agent (SA): A Service Agent is itself a Service that advertise Service information on behalf other processes. SAs are queried by User Agents for Services via XSLP, and/or register Service information in Directory Agents employing XSRP. Urue±a & Larrabeiti Expires September 15, 2004 [Page 3] Internet-Draft XSRP Protocol March 2004 Directory Agent (DA): A Directory Agent is a Service that, when deployed, acts as a central repository of all Service information from a Realm. Service Agents register its Services in a DA employing the XSRP protocol. Then, User Agents are able to query that information with XSLP. An Scope can be served by multiple DAs that coordinate themselves via XSSP & XSTP protocols. XSDF Agent: Any process that employs any XSDF protocol to interact with other XSDF Agents. Depending on the protocol a XSDF Agent may behave as a client or as a server (i.e. becoming itself a Service). XSRP Agent: A XSRP Agent is a XSDF Agent that implements the XSRP protocol (i.e. a SA or DA). SAs behave as clients while DAs are servers. Home SA Information of a Service must be managed by a single Service Agent and it is called the Home SA of the Service. Compatible Realms Two Realms are compatible if the have the same Domain and one or more common Scopes. 1.2 Notation Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [1]. Urue±a & Larrabeiti Expires September 15, 2004 [Page 4] Internet-Draft XSRP Protocol March 2004 2. Messages Format This section defines the format of all XSRP messages. These messages are exchanged between a Service Agent and a Directory Agent. XSDF protocol messages are encoded employing XBE32 [3]. Definitions for common XSDF Elements and Attributes can be found at [5] 2.1 XSRPv1 Element All XSDF messages have a common format: a single XBE32 Element containing a Header, and one or more protocol Operations. XSRP messages are encoded inside a XSRPv1 Element. XSRPv1 Element: Element Name : xsrpv1 XBE32 Type : 0x0a01 +---------------------------------------------------------------+ : Header Element : +---------------------------------------------------------------+ : XSRP Operation Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : XSRP Operation Element #N : +---------------------------------------------------------------+ : [ Signature Information Element ] : +---------------------------------------------------------------+ Header and Signature Information Elements are defined in [5]. Next subsections describe XSRP Operation Elements. 2.2 Register Service Element A SA sends this operation request to a DA in order to register the specified Service at some Scopes managed by the DA. Urue±a & Larrabeiti Expires September 15, 2004 [Page 5] Internet-Draft XSRP Protocol March 2004 Register Service Element: Element Name : registerService XBE32 Type : 0x0a10 +---------------------------------------------------------------+ : Realm Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : Register State Element : +---------------------------------------------------------------+ : Register Information Element : +---------------------------------------------------------------+ : [ Update Information Element ] : +---------------------------------------------------------------+ Realm Target, Service, and Update Information Elements are defined in [5]. Register State and Information Elements are defined in Section 2.9.1 and Section 2.9.2. The Realm Target Element MAY contain the subset of Header's Realm Scopes where Service should be registered at. If Realm Target is empty, Service should be registered at all the Scopes specified in message Header. When a Service is first registered, the Service Element MUST contain the following information: Id, Service State, Service Main Information, Service Location and Service Additional Information. SAs MUST specify some properties when registering a Service. Register Information MUST contain the expected lifetime of Service information. Selection State and Information Elements MAY be also included. In that case, SA requests DA to assign a Selection policy to the specified Service Type. SAs MAY include an Update Information Element to suggest DAs which is the appropriate refresh interval for this new Service. However, a SA MUST follow the update interval set by the DA in its reply, no matter which was the suggested one. 2.3 Register Service Acknowledgment Element This operation is sent by a DA to acknowledge a previous "registerService" operation issued by a SA. Urue±a & Larrabeiti Expires September 15, 2004 [Page 6] Internet-Draft XSRP Protocol March 2004 Register Service Acknowledgment Element: Element Name : registerServiceAck XBE32 Type : 0x0a11 +---------------------------------------------------------------+ : Realm Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : Update Information Element : +---------------------------------------------------------------+ Realm Target, Service and Update Information Elements are defined in [5]. The Realm Target Element MUST contain the subset of Header's Realm Scopes where Service has been registered at. If Realm Target is empty, Service has been registered at all the Scopes specified in message's Header. Service Element MUST contain the Id of the Service that has been registered. Other Service information is optional and SHOULD NOT appear. In the Update Information Element, the DA defines the time interval when a SA SHOULD refresh the Service registration with an "updateService" request. Otherwise, Service will be deregistered after "maxLife" time. 2.4 Update Service Element This operation is sent by a SA to refresh Service information registered at DA managed Scopes. It MAY also update the Service information and registration properties. Urue±a & Larrabeiti Expires September 15, 2004 [Page 7] Internet-Draft XSRP Protocol March 2004 Update Service Element: Element Name : updateService XBE32 Type : 0x0a20 +---------------------------------------------------------------+ : Realm Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : [ Register State Element ] : +---------------------------------------------------------------+ : [ Register Information Element ] : +---------------------------------------------------------------+ : [ Update Information Element ] : +---------------------------------------------------------------+ Realm Target, Service, and Update Information Elements are defined in [5]. Register State and Information Elements are defined in Section 2.9.1 and Section 2.9.2. The Realm Target Element MAY contain the subset of Header's Realm Scopes where Service is registered at. If Realm Target is empty, Service should be updated at all the Scopes specified in message's Header. Service Element MUST contain the Id and State Elements of the registered Service. Other Service information MAY be included by the SA in order to update the already registered one. In that case, appropriate attributes in the "metaInfo" Element MUST be incremented and also updated as they are inside the Service State Element. Register State and Information Elements MAY be also included to update registration properties. Selection State and Information Elements MUST NOT be included, unless a Selection policy was assigned when Service was first registered. Even in that case, Selection policy MUST be the same than previously registered one. SAs MAY include an Update Information Element to suggest DAs which is the appropriate refresh interval for this Service. However, a SA MUST follow the update interval set by the DA in its reply, no matter which was the suggested one. 2.5 Update Service Acknowledgment Element This operation is sent by a DA to acknowledge a previous "updateService" operation issued by a SA. Urue±a & Larrabeiti Expires September 15, 2004 [Page 8] Internet-Draft XSRP Protocol March 2004 Update Service Acknowledgment Element: Element Name : updateServiceAck XBE32 Type : 0x0a21 +---------------------------------------------------------------+ : Realm Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : Update Information Element : +---------------------------------------------------------------+ Realm Target, Service and Update Information Elements are defined in [5]. The Realm Target Element MUST contain the subset of Header's Realm Scopes where updated Service is registered at. If Realm Target is empty, updated Service has been updated at all the Scopes specified in message's Header. Service Element MUST contain the Id of the updated Service. Other Service information is optional and SHOULD NOT appear. In the Update Information Element, the DA defines the time interval when a SA SHOULD refresh the Service registration with another "updateService" request. Otherwise, Service will be deregistered after "maxLife" time. 2.6 Deregister Service Element With this operation, a SA requests to the destination DA to deregister the specified Service from the Scopes it was registered at. Deregister Service Element: Element Name : deregisterService XBE32 Type : 0x0a30 +---------------------------------------------------------------+ : Realm Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ Realm Target and Service Elements are defined in [5]. The Realm Target Element MAY contain the subset of Header's Realm Scopes where Service is registered at. If Realm Target is empty, Urue±a & Larrabeiti Expires September 15, 2004 [Page 9] Internet-Draft XSRP Protocol March 2004 Service should be deregistered from all the Scopes specified in message's Header. Service Element MUST contain the Id of the registered Service. Other Service information is optional and MAY NOT appear. 2.7 Deregister Service Acknowledgment Element This operation is sent by a DA to acknowledge a previous "deregisterService" operation issued by a SA. Deregister Service Acknowledgment Element: Element Name : deregisterServiceAck XBE32 Type : 0x0a31 +---------------------------------------------------------------+ : Realm Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ Realm Target and Service Elements are defined in [5]. The Realm Target Element MUST contain the subset of Header's Realm Scopes where Service was registered at. If Realm Target is empty, Service has been deregistered from all the Scopes specified in message's Header. Service Element MUST contain the Id of the deregistered Service. Other Service information is optional and SHOULD NOT appear. 2.8 Error Element XSDF defines a single Error Element for all kind of protocol errors. Refer to [5] for the format of the Error Element and for a detailed description of common XSDF errors. These are the XSRP specific errors that MAY be generated by a DA: Error Code Error Name Cause ---------- ------------------- --------------------------------- 0x000a0001 SERVICE_COLLISION Service Id registration collision 0x000a0002 SERVICE_NOT_FOUND Cannot found registered Service 0x000a0003 INVALID_HOME_SA Service updated by an invalid SA 0x000a0004 INCOMPATIBLE_POLICY Selection policy mismatch with registered Services An XSRP Error is encoded inside a single Error Element containing Urue±a & Larrabeiti Expires September 15, 2004 [Page 10] Internet-Draft XSRP Protocol March 2004 error Code and Name Attributes, and optional Description Elements. All XSRP Error Elements MUST contain an additional Service Element with the Id of the Service that has caused such error. Other Service information is optional and SHOULD NOT be included. INCOMPATIBLE_POLICY Error Element SHOULD also contain the Selection Information Element, if any, associated with the registered Service, which is in conflict with the requested one. 2.9 Common Operation Parameters When a Service is registered and later updated, the SA could specify the Service data itself but also some registration information. This section defines that registration information, that could appear in "registerService" and "updateService" requests. 2.9.1 Register State Element This Element specifies the volatile properties of a Service registration. Register State MUST be included in "registerService" requests (even if it is empty) and MAY be updated later by "updateService" requests. Record Element: Element Name : registerState XBE32 Type : 0x0310 +---------------------------------------------------------------+ : [ Selection State Element ] : +---------------------------------------------------------------+ Selection State Element is defined in [5]. Selection State Element contains the volatile information for DA Selection process associated to a certain Service Type. 2.9.2 Register Information Element This Element specifies the properties of a Service registration. Register Information MUST be included in "registerService" requests and some data MAY be updated later by "updateService" requests. Urue±a & Larrabeiti Expires September 15, 2004 [Page 11] Internet-Draft XSRP Protocol March 2004 Record State Element: Element Name : registerInfo XBE32 Type : 0x0320 +---------------------------------------------------------------+ : Cache Information Element : +---------------------------------------------------------------+ : [ Selection Information Element ] : +---------------------------------------------------------------+ Selection Information Element is defined in [5]. Selection Information Element MAY be included in Service Registration. In that case, SA requests DA to apply the specified Selection policy to Services with the same Type than registered one. All Selection Information, but Selection policy, MAY be later updated, but only if it was initially registered. 2.9.2.1 Cache Information Element This Element contains the expected lifetime of associated Service information. It MUST be specified at Service registration and MAY be updated later when included inside "updateService" requests. Cache Information Element: Element Name : cacheInfo XBE32 Type : 0x0221 +---------------------------------------------------------------+ | Lifetime | +---------------------------------------------------------------+ Lifetime Attribute: Attribute Name : lifetime XBE32 Type : 0x3223 Value Type : int32 Value Length : 32 bits This Attribute contains the maximum amount of time, measured in milliseconds, that associated Service information is expected to keep being valid. Urue±a & Larrabeiti Expires September 15, 2004 [Page 12] Internet-Draft XSRP Protocol March 2004 3. XSRP Operation Procedures All XSDF Agents MUST follow the common procedures for message generation, transmission and processing defined in [5]. This section specifies additional procedures for XSRP Agents. All XSDF SAs and DAs MUST implement XSRP. However, as DA are not mandatory entities within the XSRP framework, in some scenarios XSRP would not be used. This document only refers to SA/DA interaction. For UA/SA and UA/DA interactions please refer to XSLP [6]. Every Service MUST have an 16 byte UUID [2], unique at the Domain it belongs to. Each Service MAY belong to a Realm with multiple Scopes. A Service MUST always belong to the same Realm. Therefore, SAs MUST update and deregister Service information at all the Scopes Service was registered at. Also, Service information MUST be managed by a single SA, called Home SA, to ensure that Service information SHOULD be the same across all the Scopes that Service belongs to. XSRP is a Client-Server protocol. SA acts as a Client sending operation requests while the DA acts as a Server processing those requests and sending replies back. All XSRP Agents MUST support TCP as transport protocol and MAY also support UDP and SCTP. The default port number for all the transport protocols is 721. 3.1 Service Agent Initialization As any other XSDF Agent, SAs MUST be configured with the Realm it belongs to, and obtain the DAs managing those Scopes, if any. Therefore, they MUST perform the initialization procedures specified in [5]. When a Service Agent starts, it MUST generate an unique 16 byte Service identifier, as defined in [2]. SAs and DAs MUST be configured with the Realm they belong to. All Services managed by a XSRP Agent MUST belong to its Realm or to a Scope subset of such Realm. It MAY occur that a SA belongs to a Realm that is managed by no DA. In that case, it SHOULD behave as a Stand-Alone SA for Services from such Realm, and answer to direct XSLP requests from UAs as described in [6]. However, it MUST keep listening for DA Advertisements from such Realm to continue its registration process. The same could occur if all the existing DAs from a compatible Realm became unavailable: SAs SHOULD behave as Stand-Alone ones until another DA from that Realm is found. Urue±a & Larrabeiti Expires September 15, 2004 [Page 13] Internet-Draft XSRP Protocol March 2004 When in Stand-Alone mode, SAs MUST join to the appropriate IPv4 and IPv6 multicast groups, as defined in [5], for the Services that belong to the Scopes not managed by any DA. In particular, they SHOULD join to the multicast groups associated with the "xsdf:sa" Service Type. When a SA knows one or more DAs from Compatible Realms, that support the "xsrp" Protocol; that SA MUST register, and later update, the Services belonging to those Realms. However, Services from "LOCAL" Scope are restricted to the local server. Therefore, they MUST NOT be managed by DAs nor registered in them. SAs MUST wait for some time, distributed between 0 and REGISTRATION_DELAY, before registering Services at any new Realm (i.e. by discovering a new DA from a previously Stand-Alone Realm). Additionally, DA's Service Advertisement MAY include an Update Information Element inside its "xsrp" Protocolo Element. In that case, SAs MUST wait a random interval between "minLife" and "maxLife" advertised attributes. As a SA is itself a Service, SAs SHOULD register its Service information at the compatible Realms they belong to. The Type Attribute for SA Service information is "xsdf:sa". The initialization phase ends when the SA has registered all the Services at DAs from Compatible Realms, and behaves as a Stand-Alone SA for remaining Services at unmanaged Scopes. 3.2 Service Registration SAs register its Services at a Realm by sending a "registerService" request to any DA from such Realm. Multiple Services MAY be registered at once by including multiple "registerService" requests within a single XSRP message. Refer to Section 2.2 and Section 2.3 for a detailed description of "registerService" requests and "registerServiceAck" replies. Error descriptions can be found at Section 2.8 Once the XSRP message with the "registerService" operation(s) has been generated, it is sent to the DA. If message can not be delivered, next DA from the same Realm SHOULD be chosen. If there are no DAs left, registration procedure is aborted and SA falls back to the Stand-Alone behavior for that Realm. When a DA receives a valid XSRP message with some authorized "registerService" operations, it MUST follow these steps to process each operation: Urue±a & Larrabeiti Expires September 15, 2004 [Page 14] Internet-Draft XSRP Protocol March 2004 1. Obtain the list of Scopes to register Service at, from the request's Target Element. If it is empty, get the one in message's Header. Those Scopes MUST have been listed in message's Header. Otherwise, message processing SHOULD be silently aborted. 2. Check that no other Service with the same Id has been already registered at the same Scopes as the ones in previous list. In that case, operation MUST be skipped and a SERVICE_COLLISION Error Element MUST be created. 3. Search for a registered Service with the same Type as the request's one. If there is another Service with the same Type but with an incompatible Selection policy, operation SHOULD be skipped and an INCOMPATIBLE_POLICY Error Element SHOULD be created. 4. If no error has occurred, DA MUST register the Service, with the specified Service information and Registration properties, at all the Scopes in the register list. 5. Choose an update interval and create a "registerServiceAck" reply. Suggested Update Information MAY be taken into account. 6. Set the associated LAST_UPDATE_TIMESTAMP and HOME_SA variables, with current registration time and the Service Id of message's Source SA, respectively . 7. Set a MAX_LIFE_TIMER associated to the new registered Service. Such timer MUST expire after "maxLife" time, as advertised in the "registerServiceAck" reply. For each "registerService" request, DA MUST generate a "registerServiceAck" if the Service has been registered, or an Error Element if an error has occurred. Both replies MUST include the Id of the Service being registered. When receiving a valid XSRP message containing one or more "registerServiceAck" replies, SA MUST check the Minimum and Maximum Life Attributes and set an UPDATE_TIMER associated to the registered Service. The expiration time MUST be distributed between "minLife" and "maxLife" milliseconds. In order that SAs know which Selection Policies are supported by a DA, it MAY advertise inside its "xsrp" Protocol Element [5] a Selection Information Element with the supported Selection Policies. Urue±a & Larrabeiti Expires September 15, 2004 [Page 15] Internet-Draft XSRP Protocol March 2004 3.3 Service Registration Update When the UPDATE_TIMER associated to a Service expires, SA SHOULD refresh Service at every Scope where Service is registered at. Thus, it MUST send "updateService" requests to DAs that manage such Scopes. Service information MAY be also updated by the same mechanism at any time. However, information updates SHOULD be delayed until "minLife" time has passed since last refresh, at least. Refer to Section 2.4 and Section 2.5 for a detailed description of "updateService" requests and "updateServiceAck" replies. Error descriptions can be found at Section 2.8. Once the XSRP message with the "updateService" operation(s) is generated, it is sent to the DA. If message can not be delivered, next DA from the same Realm SHOULD be chosen. If there are no DAs left, registration procedure is aborted and SA falls back to the Stand-Alone behavior for that Realm. When a DA receives a valid XSRP message with some authorized "updateService" operations, it MUST follow these steps to process each operation: 1. Obtain the list of Service's registered Scopes, from the request's Target Element. If it is empty, get the one in message's Header. Those Scopes MUST have been listed in message's Header. Otherwise, message processing SHOULD be silently aborted. 2. Search for the Service registration to be updated at Scopes in previous list . If no Service with the specified Id is found, operation MUST be skipped and an SERVICE_NOT_FOUND Error Element MUST be created. 3. Check that message's Source SA Service Id equals to associated HOME_SA variable. Otherwise, operation MUST be skipped and an INVALID_HOME_SA Error MUST be created. 4. If update request contains a Selection Information Element, check that Service was registered with the same Selection policy. Otherwise, operation SHOULD be skipped and an INCOMPATIBLE_POLICY Error SHOULD be created. 5. If no error has occurred, DA MUST update Service at all Scopes it is registered at. Specified Service information and Registration properties MUST be updated, if any. However, older data MUST NOT overwrite newer one. State Timestamp Attribute of both Service State Elements MUST be compared before any update action takes Urue±a & Larrabeiti Expires September 15, 2004 [Page 16] Internet-Draft XSRP Protocol March 2004 place. 6. Choose an update interval and create an "updateServiceAck" reply. Suggested Update Information MAY be taken into account. 7. Update associated LAST_UPDATE_TIMESTAMP variable with current update time. 8. Reset MAX_LIFE_TIMER associated with the updated Service. Such timer MUST expire after "maxLife" time, unless refreshed, as advertised in the "updateServiceAck" reply. For each "updateService" request, DA MUST generate a "updateServiceAck" if the Service has been updated, or an Error Element if an error has occurred. Both replies MUST include the Id of the Service being updated. When receiving a valid XSRP message containing one or more "updateServiceAck" replies, SA MUST check the Minimum and Maximum Life Attributes and reset the UPDATE_TIMER associated to the registered Service. The expiration time MUST be distributed between "minLife" and "maxLife" milliseconds. 3.4 Service Deregistration When a network Service stops or becomes somehow unavailable, its Home SA MUST delete it from all the Realms it was registered at, by employing a XSRP "deregisterService" request. Multiple Services MAY be deregistered within a single message by including multiple "deregisterService" requests. Refer to Section 2.6 and Section 2.7 for a detailed description of "deregisterService" requests and "deregisterServiceAck" replies. Error descriptions can be found at Section 2.8 Once the XSRP message with the "deregisterService" operation(s) is generated, it is sent to the DA. If message can not be delivered, next DA from the same Realm SHOULD be chosen. If there are not DAs left, registration procedure is aborted and SA falls back to the Stand-Alone behavior for the remaining Services of that Realm. When a DA receives a valid XSRP message with some authorized "deregisterService" operations, it MUST follow these steps to process each operation: 1. Obtain the list of Service's registered Scopes, from the request's Target Element. If it is empty, get the one in message's Header. Those Scopes MUST have been listed in message's Urue±a & Larrabeiti Expires September 15, 2004 [Page 17] Internet-Draft XSRP Protocol March 2004 Header. Otherwise, message processing SHOULD be silently aborted. 2. Search for the Service to be deregistered at Scopes in previous list. If no Service with the specified Id is found, operation MUST be skipped and an SERVICE_NOT_FOUND Error Element MUST be created. 3. Check that Source's SA Service Id equals to associated HOME_SA variable. Otherwise, operation MUST be skipped and an INVALID_HOME_SA Error Element MUST be created. 4. If no error has occurred, DA MUST deregister specified Service from all the Scopes it was registered at by deleting Service information and Registration properties and associated variable from its cache and clearing the associated MAX_LIFE_TIMER. For each "deregisterService" request, DA MUST generate a "deregisterServiceAck" if the Service has been deregistered, or an Error Element if an error has occurred. Both replies MUST include the Id of the Service being deregistered. When a MAX_LIFE_TIME associated to a Service registration expires, DA MUST unregister such Service from all Scopes it was registered at. Service information and Registration properties MUST be deleted from cache. Urue±a & Larrabeiti Expires September 15, 2004 [Page 18] Internet-Draft XSRP Protocol March 2004 4. Security Considerations XSDF Service Discovery Framework relies on security procedures provided by lower layers, as TLS or IPSec ones. However, it defines some authentication mechanisms that SHOULD be employed when similar ones are not being provided by the layers below. See [5] for a detailed description of these mechanisms. XSRP over TLS is named "xsrp/tls" and its default port number for the TCP and SCTP transport protocols is 722. Please note that checking HOME_SA variable tries to avoid collisions and ill-behaved configurations. It can not be seen as a security mechanism as Service Id of a SA can be easily obtained and faked. UA selection process requires that Service providers expose certain server information to its clients as the current load or backup servers. Such information disclosure MAY be avoided by employing DA Selection process instead. 5. Acknowledgements XSRP protocol was designed to implement part of the features of SLPv2 and ASAP protocols, thus we would like to acknowledge the efforts from their authors: Erik Guttman, Charles Perkins, Jhon Veizades, Michael Day, Randall Stewart, Quiabing Xie, Maureen Stillman and Michael Tuexen. Urue±a & Larrabeiti Expires September 15, 2004 [Page 19] Internet-Draft XSRP Protocol March 2004 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Mealling, M., "A UUID URN Namespace", draft-mealling-uuid-urn-03 (work in progress), March 2004. [3] Urue±a, M. and D. Larrabeiti, "eXtensible Binary Encoding (XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004. [4] Urue±a, M. and D. Larrabeiti, "Overview of the eXtensible Service Discovery Framework (XSDF)", draft-uruena-xsdf-overview-00 (work in progress), March 2004. [5] Urue±a, M. and D. Larrabeiti, "eXtensible Service Discovery Framework (XSDF): Common Elements and Procedures", draft-uruena-xsdf-common-00 (work in progress), March 2004. [6] Urue±a, M. and D. Larrabeiti, "eXtensible Service Location Protocol (XSLP)", draft-uruena-xslp-00 (work in progress), March 2004. Authors' Addresses Manuel Urue±a Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 87 95 EMail: muruenya@it.uc3m.es David Larrabeiti Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 99 53 EMail: dlarra@it.uc3m.es Urue±a & Larrabeiti Expires September 15, 2004 [Page 20] Internet-Draft XSRP Protocol March 2004 Appendix A. XSRP Constants A.1 XBE32 Elements Element Name XBE32 Type ------------ ---------- xsrpv1 0x0a01 registerService 0x0a10 registerServiceAck 0x0a11 updateService 0x0a20 updateServiceAck 0x0a21 deregisterService 0x0a30 deregisterServiceAck 0x0a31 registerState 0x0310 registerInfo 0x0320 cacheInfo 0x0221 A.2 Variables, Timers and Constants Variable name Description --------------------- --------------------------------------- HOME_SA SA Service Id of registered Service SERVICE_LIFETIME Expected lifetime of registered Service LAST_UPDATE_TIMESTAMP DA timestamp of last Service update Timer name Description -------------- ------------------------------------------- UPDATE_TIMER SA timer to refresh registered Service MAX_LIFE_TIMER DA timer to delete Service if not refreshed Constant name Default Value Description ------------------ ------------- --------------------------------- REGISTRATION_DELAY 2000 ms SA max delay before registering a Service at a newly discovered DA Urue±a & Larrabeiti Expires September 15, 2004 [Page 21] Internet-Draft XSRP Protocol March 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Urue±a & Larrabeiti Expires September 15, 2004 [Page 22] Internet-Draft XSRP Protocol March 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urue±a & Larrabeiti Expires September 15, 2004 [Page 23] Network Working Group M. Urue±a Internet-Draft D. Larrabeiti Expires: September 15, 2004 UC3M March 17, 2004 eXtensible Service Subscription Protocol (XSSP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document specifies the eXtensible Service Subscription Protocol (XSSP), a lightweight protocol that allows XSDF Agents to be subscribed to the Service information repository. XSDF subscribed Agents are notified when any change occurs. Directory Agents from the same Realm are subscribed among them in order to synchronize the common Service repository. XSSP is one of the protocols of the eXtensible Service Discovery Framework (XSDF). Urue±a & Larrabeiti Expires September 15, 2004 [Page 1] Internet-Draft XSSP Protocol March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Notation Conventions . . . . . . . . . . . . . . . . . . . 5 2. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 XSSPv1 Element . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Subscribe Service Element . . . . . . . . . . . . . . . . 6 2.3 Subscribe Service Acknowledgment Element . . . . . . . . . 7 2.4 Update Subscription Element . . . . . . . . . . . . . . . 8 2.5 Update Subscription Acknowledgment Element . . . . . . . . 9 2.6 Unsubscribe Service Element . . . . . . . . . . . . . . . 10 2.7 Unsubscribe Service Acknowledgment Element . . . . . . . . 11 2.8 Error Element . . . . . . . . . . . . . . . . . . . . . . 11 2.9 Common Operation Parameters . . . . . . . . . . . . . . . 12 2.9.1 Subscription Target Element . . . . . . . . . . . . . 12 2.9.2 Subscribe Information Element . . . . . . . . . . . . 13 3. XSSP Operation Procedures . . . . . . . . . . . . . . . . . . 16 3.1 Service Subscription . . . . . . . . . . . . . . . . . . . 16 3.2 Update Subscription . . . . . . . . . . . . . . . . . . . 17 3.3 Service Unsubscription . . . . . . . . . . . . . . . . . . 19 3.4 Service Event Notification . . . . . . . . . . . . . . . . 20 3.4.1 XSTP Service Notifications . . . . . . . . . . . . . . 20 3.4.2 XSLP Service Advertisements . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 A. XSSP Constants . . . . . . . . . . . . . . . . . . . . . . . . 23 A.1 XBE32 Elements . . . . . . . . . . . . . . . . . . . . . . 23 A.2 Variables and Timers . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 24 Urue±a & Larrabeiti Expires September 15, 2004 [Page 2] Internet-Draft XSSP Protocol March 2004 1. Introduction XSDF [3] is a framework for Service Discovery. It allows Users to dynamically find available network Services and choose the better ones following certain selection policy. In XSDF, User Agents (UAs) may issue multicast Service requests directly to Service Agents (SAs). In bigger networks, UAs request Service information to a central repository managed by the so-called Directory Agents (DAs). XSSP is a protocol that allows any XSDF Agent to be subscribed to changes in the Service information handled by other XSDF Agent. This allows XSDF Agents that need an up-to-date view of certain Services, to receive modification events from those Services. Without XSSP, these XSDF Agents would need to continuously poll Service information. Any kind of XSDF Agent may be a XSSP client but only XSDF Agents that handle Service information (i.e. SAs and DAs) could be XSSP servers. Obviously SAs will only notify events that affect its own set of Services. In the case of DAs, XSSP allows two types of subscriptions: Local subscriptions: Subscribers will be only notified of XSRP operations issued by SAs to that particular DA. Modification events that came from other DAs at the common Realm will not be forwarded. Global subscriptions: In this case, all the changes to the Service repository will be sent to the subscribers, no matter if those changes came from a XSRP operation issued to that particular DA or to another one from the common Realm. Regarding to the Service information to be subscribed to, XSSP allows three types of subscription Targets: By Realm: Subscribed XSDF Agent will receive change notifications from all the Services belonging to the specified Realm. By Service Type: A XSDF Agent is only interested in the events related to the Services with the specified Type. By Service Id: These individual subscriptions monitors just a single Service specified by its Id. XSDF Agent to be notified is represented as a Service. Usually, the notification XSDF Agent will be the same that issues the XSSP operations. However, it MAY specify another notification Service. Also, multicast notifications MAY be requested by including a multicast address in the Service information Element. A subscription Urue±a & Larrabeiti Expires September 15, 2004 [Page 3] Internet-Draft XSSP Protocol March 2004 is identified by the notification Service Id. Therefore, the same notification Service Id MUST NOT be employed in multiple subscriptions at the same XSSP Server. In XSSP, subscriptions do not specify just which is the Target Service subset, but also what kind of events SHOULD be notified. Those event types are identified by XSRP operations [6], because most of modifications are caused by XSRP operations themselves. 1.1 Definitions Domain: A Domain is a single administrative organization containing Users and Services. Scope: A Scope is a subset of Users and Services from a Domain, typically making a logical administrative group. Realm: A Realm is a combination of a Domain and one or more Scopes from such Domain, if any. Service: A Service is any process attached to a network that provides some kind of functionality to Users or other Services. A Service belongs to a single Realm. User Agent (UA): A process working on the User's (or other process) behalf to discover Services, and select the best available one. UAs obtain Service information from Directory Agents and Service Agents via XSLP. Service Agent (SA): A Service Agent is itself a Service that advertise Service information on behalf other processes. SAs are queried by User Agents for Services via XSLP, and/or register Service information in Directory Agents employing XSRP. Directory Agent (DA): A Directory Agent is a Service that, when deployed, acts as a central repository of all Service information from a Realm. Service Agents register its Services in a DA employing the XSRP protocol. Then, User Agents are able to query that information with XSLP. An Scope can be served by multiple DAs that coordinate themselves via XSSP & XSTP protocols. XSDF Agent: Any process that employs any XSDF protocol to interact with other XSDF Agents. Depending on the protocol a XSDF Agent may behave as a client or as a server (i.e. becoming itself a Service). Urue±a & Larrabeiti Expires September 15, 2004 [Page 4] Internet-Draft XSSP Protocol March 2004 XSSP Agent: A XSRP Agent is a XSDF Agent that implements the XSSP protocol (i.e. an UA, SA or DA). Any XSDF Agent MAY behave as a client while only SAs and DAs MAY be XSSP Servers. Notification Service: XSSP Servers send modification Events to subscribed Notification Services. Usually, XSSP Clients will be also Notification Services, but it may not be always the case. Modification Events: The type Events to be sent when a Service changes, can be identified by its associated XSRP operation. Events will we delivered as defined by the Notification Protocol chosen. 1.2 Notation Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [1]. Urue±a & Larrabeiti Expires September 15, 2004 [Page 5] Internet-Draft XSSP Protocol March 2004 2. Messages Format This section defines the format of all XSSP messages. These messages are exchanged between a XSSP Client and a XSSP Server (i.e. a SA or a DA). XSDF protocol messages are encoded employing XBE32 [2]. Definitions for common XSDF Elements and Attributes can be found at [4]. 2.1 XSSPv1 Element All XSDF messages have a common format: a single XBE32 Element containing a Header, and one or more protocol Operations. XSSP messages are encoded inside a XSSPv1 Element. XSSPv1 Element: Element Name : xsspv1 XBE32 Type : 0x0b01 +---------------------------------------------------------------+ : Header Element : +---------------------------------------------------------------+ : XSSP Operation Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : XSSP Operation Element #N : +---------------------------------------------------------------+ : [ Signature Information Element ] : +---------------------------------------------------------------+ Header and Signature Information Elements are defined in [4]. Next subsections describe XSSP Operation Elements. 2.2 Subscribe Service Element A XSDF Client sends this operation request to a XSSP Server in order to create the specified Subscription. Events from the Services at the included Target SHOULD be sent to the specified Notification Service. Urue±a & Larrabeiti Expires September 15, 2004 [Page 6] Internet-Draft XSSP Protocol March 2004 Subscribe Service Element: Element Name : subscribeService XBE32 Type : 0x0b10 +---------------------------------------------------------------+ : Subscription Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : Subscribe Information Element : +---------------------------------------------------------------+ : [ Update Information Element ] : +---------------------------------------------------------------+ Service and Update Information Elements are defined in [4]. Subscription Target and Subscribe Information Elements are defined in Section 2.9. The Subscription Target Element MUST contain which kind of Services XSSP Client wants to be subscribed to. If Target Element is empty, Notification Service should be subscribed to all the Scopes specified in the message's Header. When a Subscription is to be created, the Service Element MUST contain the following information: Id, Service State, Service Main Information and Service Location. Other Service information is optional and MAY NOT appear. XSSP Clients MUST specify some properties when creating a subscription. Subscribe Information Element MUST contain whether subscription is Global or Local, and which kind of Events SHOULD be notified. XSSP Clients MAY include an Update Information Element to suggest XSSP Servers which is the appropriate refresh interval for this new Subscription. However, a XSSP Client MUST follow the update interval set by the XSSP Server in its reply, no matter which was the suggested one. 2.3 Subscribe Service Acknowledgment Element This operation is sent by a XSSP Server to acknowledge a previous "subscribeService" operation issued by a XSSP Client. Urue±a & Larrabeiti Expires September 15, 2004 [Page 7] Internet-Draft XSSP Protocol March 2004 Subscribe Service Acknowledgment Element: Element Name : subscribeServiceAck XBE32 Type : 0x0b11 +---------------------------------------------------------------+ : Subscription Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : Update Information Element : +---------------------------------------------------------------+ Service and Update Information Elements are defined in [4]. Subscription Target Element is defined in Section 2.9.1. The Subscription Target Element MUST contain which kind of Services the Notification Service has been subscribed to. If Target Element is empty, Service has been subscribed to all the Scopes specified in the message's Header. Service Element MUST contain the Id of the notification Service that has been subscribed. Other Service information is optional and SHOULD NOT appear. In the Update Information Element, the XSSP Server defines the time interval when a XSSP Client SHOULD refresh the Service subscription with an "updateSubscription" request. Otherwise, Subscription will be unregistered after "maxLife" time. 2.4 Update Subscription Element This operation is sent by a XSSP Client to refresh a Subscription at Services handled by a XSSP Server (SA/DA). It MAY also update the notification Service information and some Subscription properties. Urue±a & Larrabeiti Expires September 15, 2004 [Page 8] Internet-Draft XSSP Protocol March 2004 Update Subscription Element: Element Name : updateSubscription XBE32 Type : 0x0b20 +---------------------------------------------------------------+ : Subscription Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : [ Subscribe Information Element ] : +---------------------------------------------------------------+ : [ Update Information Element ] : +---------------------------------------------------------------+ Service and Update Information Elements are defined in [4]. Subscription Target and Subscribe Information Elements are defined in Section 2.9. The Subscription Target Element MUST contain which kind of Services XSSP Agent has been subscribed to. If Target Element is empty, Subscription SHOULD be refreshed at all the Scopes specified in the message's Header. Service Element MUST contain the Id and State Elements of the subscribed Service. Other Service information MAY be included by the XSSP Client in order to update the already registered one. In that case, appropriate attributes in the "metaInfo" Element MUST be incremented as they are carried inside the Service State Element. Subscribe Information Element MAY be also included to update Subscription properties. Global Subscription Attribute MUST NOT be changed from initial Subscription creation. However, Events to be notified MAY be updated. XSSP Clients MAY include an Update Information Element to suggest XSSP Servers which is the appropriate refresh interval for this Subscription. However, a XSSP Client MUST follow the update interval set by the XSSP Server in its reply, no matter which was the suggested one. 2.5 Update Subscription Acknowledgment Element This operation is sent by a XSSP Server to acknowledge a previous "updateSubscription" operation issued by a XSSP Client. Urue±a & Larrabeiti Expires September 15, 2004 [Page 9] Internet-Draft XSSP Protocol March 2004 Update Subscription Acknowledgment Element: Element Name : updateSubscriptionAck XBE32 Type : 0x0b21 +---------------------------------------------------------------+ : Subscription Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : Update Information Element : +---------------------------------------------------------------+ Service and Update Information Elements are defined in [4]. Subscription Target Element is defined in Section 2.9.1. The Subscription Target Element MUST contain which kind of Services the Notification Service is subscribed to. If Target Element is empty, Service is subscribed to all the Scopes specified in the message's Header. Service Element MUST contain the Id of the Notification Service whose subscription has been refreshed. Other Service information is optional and SHOULD NOT appear. In the Update Information Element, the XSSP Server defines the time interval when a XSSP Client SHOULD refresh the Subscription with an "updateSubscription" request. Otherwise, Subscription will be deregistered after "maxLife" time. 2.6 Unsubscribe Service Element With this operation, a XSSP Client requests to the destination XSSP Server to unregister the specified Notification Service from the Targets it was subscribed to. Unsubscribe Service Element: Element Name : unsubscribeService XBE32 Type : 0x0b30 +---------------------------------------------------------------+ : Subscription Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ Service Element is defined in [4]. Subscription Target Element is defined in Section 2.9.1. Urue±a & Larrabeiti Expires September 15, 2004 [Page 10] Internet-Draft XSSP Protocol March 2004 The Subscription Target Element MUST contain which kind of Services XSSP Client is subscribed to. If Target Element is empty, subscription SHOULD be unsubscribed from all the Scopes specified in the message's Header. Service Element MUST contain the Id of the subscribed Service. Other Service information is optional and MAY NOT appear. 2.7 Unsubscribe Service Acknowledgment Element This operation is sent by a XSSP Server to acknowledge a previous "unsubscribeService" operation issued by a XSSP Client. Unsubscribe Service Acknowledgment Element: Element Name : unsubscribeServiceAck XBE32 Type : 0x0b31 +---------------------------------------------------------------+ : Subscription Target Element : +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ Service Element is defined in [4]. Subscription Target Element is defined in Section 2.9.1. The Subscription Target Element MUST contain which kind of Services XSSP Client was subscribed to. If Target Element is empty, Notification Service has been unsubscribed from all the Scopes specified in the message's Header. Service Element MUST contain the Id of the unsubscribed Notification Service. Other Service information is optional and SHOULD NOT appear. 2.8 Error Element XSDF defines a single Error Element for all kind of protocol errors. Refer to [4] for the format of the Error Element and for a detailed description of common XSDF errors. These are the XSSP specific errors that MAY be generated by a XSSP Server: Error Code Error Name Cause ---------- ---------------------- --------------------------------- 0x000b0001 SUBSCRIPTION_COLLISION Notification Service Id collision 0x000b0002 SUBSCRIPTION_NOT_FOUND Cannot found Subscription 0x000b0003 UNSUPPORTED_PROTOCOL Unsupported Notification Protocol Urue±a & Larrabeiti Expires September 15, 2004 [Page 11] Internet-Draft XSSP Protocol March 2004 0x000b0004 INVALID_SUBSCRIPTION Invalid Global/Local Subscription A XSSP Error is encoded inside a single Error Element containing: Error Code and Name Attributes, and optional Description Elements. All XSSP Error Elements MUST contain an additional Service Element with the Id of the Notification Service whose Subscription has caused the error. Other Service information is optional and SHOULD NOT be included. UNSUPPORTED_PROTOCOL Error Element SHOULD also contain the supported Notification Protocols encoded in Protocol Elements as defined in [4]. INVALID_SUBSCRIPTION Error Element SHOULD also contain the allowed Subscribe Information Element which is in conflict with the requested one. 2.9 Common Operation Parameters When a Subscription is created or later updated, the XSDF Agent MUST specify the notification Service but also some additional Subscribe information. This section defines that Subscription information, that could appear in "subscribeService" and "updateSubscription" requests. It also specifies the Subscription Target Element that appears in all XSSP operations. 2.9.1 Subscription Target Element XSSP Clients specify with this Element in which kind of Services they are interested at. It MAY include the Service's Scopes, the Service Type or the exact Id of the Services to be subscribed to. In the latter case the Service Type MUST be also included. Target Element: Element Name : target XBE32 Type : 0x0821 +---------------------------------------------------------------+ : [ Realm Element ] : +---------------------------------------------------------------+ : [ Service Type Element ] : +---------------------------------------------------------------+ | [ Service Ids ] | +---------------------------------------------------------------+ Realm and Service Type Elements, and Service Ids Attribute are defined in [4]. Urue±a & Larrabeiti Expires September 15, 2004 [Page 12] Internet-Draft XSSP Protocol March 2004 The Realm Element MAY contain the subset of Header's Realm Scopes to be subscribed to. If Realm Element is empty and no Service Type Element has been specified, Subscription SHOULD cover all the Scopes specified in the message's Header. XSSP Clients MAY be subscribed to all Services from the common Realm with a specified Service Type. If the Type Element contains any Path Element, the XSSP Server SHOULD notify changes in the Services providing the requested resources. That is, their Path Elements MUST fully contain, at least, one of the requested Paths. When included, the Service Ids Attribute indicates to which particular Service instances the XSSP Client is subscribed to. When the list does contain unknown Services, Subscription SHOULD be accepted and those Ids SHOULD be remembered. 2.9.2 Subscribe Information Element This Element specifies the properties of a Service Subscription. Subscribe Information MUST be included in "subscribeService" requests. Event data MAY be later updated by an "updateSubscription" request. Record State Element: Element Name : subscribeInfo XBE32 Type : 0x0420 +---------------------------------------------------------------+ | Global Subscription | +---------------------------------------------------------------+ : Event Information Element : +---------------------------------------------------------------+ Global Subscription Attribute indicates whether DA SHOULD notify only local changes to the Service being handled, or it SHOULD also forward modification Events from other DAs. SAs only support Local Subscriptions and SHOULD reject Global Subscriptions with an INVALID_SUBSCRIPTION error. 2.9.2.1 Event Information Element This Element specifies which kind of modifications SHOULD be notified to the subscribed Services. Urue±a & Larrabeiti Expires September 15, 2004 [Page 13] Internet-Draft XSSP Protocol March 2004 Event Information Element: Element Name : eventInfo XBE32 Type : 0x0421 +---------------------------------------------------------------+ | [ Register Service ] | +---------------------------------------------------------------+ | [ Update Service ] | +---------------------------------------------------------------+ | [ Update Service Information ] | +---------------------------------------------------------------+ | [ Deregister Service ] | +---------------------------------------------------------------+ | [ Expired Service ] | +---------------------------------------------------------------+ Register Service Element: Element Name : registerService XBE32 Type : 0x0a10 If this this empty Element is included in the Event list, subscribed XSSP Client SHOULD be notified whenever a new Service matching the associated Subscription is initially registered. Update Service Element: Element Name : updateService XBE32 Type : 0x0a20 If this this empty Element is included in the Event list, subscribed XSSP Client SHOULD be notified whenever a Service matching the associated Subscription is updated, even if only Service State has changed. Update Service Element: Element Name : updateServiceInfo XBE32 Type : 0x0a22 If this this empty Element is included in the Event list, subscribed XSSP Client SHOULD be notified whenever a Service matching the associated Subscription is updated, but only if other Service information, not only State one, has changed. This element MUST be ignored if "updateService" one is also requested. Deregister Service Element: Element Name : deregisterService XBE32 Type : 0x0a30 Urue±a & Larrabeiti Expires September 15, 2004 [Page 14] Internet-Draft XSSP Protocol March 2004 If this this empty Element is included in the Event list, subscribed XSSP Client SHOULD be notified whenever a Service matching the associated Subscription is unregistered by employing XSRP. Expired Service Element: Element Name : expiredService XBE32 Type : 0x0a32 If this this empty Element is included in the Event list, subscribed XSSP Client SHOULD be notified whenever a Service matching the associated Subscription expires, that is, its associated "maxlife" expires without being updated. Urue±a & Larrabeiti Expires September 15, 2004 [Page 15] Internet-Draft XSSP Protocol March 2004 3. XSSP Operation Procedures All XSDF Agents MUST follow the common procedures for message generation, transmission and processing defined in [4]. This section specifies additional procedures for XSSP Agents. XSSP is a Client-Server protocol. Any XSDF Agent MAY act as a Client sending operation requests while only SAs or DAs MAY act as XSSP Servers processing those requests and sending replies back. All XSSP Agents MUST support the TCP transport protocol and MAY also support UDP and SCTP. The default port number for all these transport protocols is 725. 3.1 Service Subscription XSSP Clients subscribe themselves to Services handled by XSSP Servers (SAs/DAs) by sending a "subscribeService" request to that very XSSP Server. Multiple Subscriptions MAY be registered at once by including multiple "subscribeService" requests within a single XSSP message. Refer to Section 2.2 and Section 2.3 for a detailed description of "subscribeService" requests and "subscribeServiceAck" replies. Error descriptions can be found at Section 2.8 Once the XSSP message with the "subscribeService" operation(s) has been generated, it is sent to the XSSP Server. In the case of Global Subscriptions from a Scope, any DA from that Scope MAY be chosen. In that case, if message can not be delivered, next DA from the same Realm MAY be chosen. When a XSSP Server receives a valid XSSP message with some authorized "subscribeService" operations, it MUST follow these steps to process each operation: 1. If Subscription Target Element contains any Scope, check that those Scopes MUST have been listed in the message's Header. Otherwise, message processing SHOULD be silently aborted. 2. Check that no other Subscription with the same Notification Service Id has been already registered. In that case, operation MUST be skipped and a SUBSCRIPTION_COLLISION Error Element MUST be created. 3. Check that the Notification Protocol specified in the Service information Element is supported. Otherwise, operation MUST be skipped and a UNSUPPORTED_PROTOCOL error Element MUST be generated, listing the allowed Notification Protocols. Urue±a & Larrabeiti Expires September 15, 2004 [Page 16] Internet-Draft XSSP Protocol March 2004 4. SAs SHOULD NOT accept Global Subscriptions as they only handle a small subset of Services. If a SA receives a "subscribeService" operation with the Global Subscription Attribute set to "true", operation SHOULD be skipped and an INVALID_SUBSCRIPTION Error Element SHOULD be created. 5. If no error has occurred, XSSP Server MUST register the Subscription, with the specified Notification Service information and associated properties, at all the specified Targets. 6. Choose an update interval and create a "subscribeServiceAck" reply. Suggested Update Information MAY be taken into account. 7. Set the associated LAST_UPDATE_TIMESTAMP variable with current subscription time. 8. Set a MAX_LIFE_TIMER associated to the new registered Subscription. Such timer MUST expire after "maxLife" time, unless refreshed, as advertised in the "subscribeServiceAck" reply. For each "subscribeService" request, XSSP Server MUST generate a "subscribeServiceAck" if the Subscription has been accepted, or an Error Element if an error has occurred. Both replies MUST include the Id of the Notification Service being subscribed. When receiving a valid XSSP message containing one or more "subscribeServiceAck" replies, XSSP Client MUST check the Minimum and Maximum Life Attributes and set an UPDATE_TIMER associated to the Subscription. The expiration time MUST be distributed between "minLife" and "maxLife" milliseconds. 3.2 Update Subscription When the UPDATE_TIMER associated to a Subscription expires, subscribed XSSP Client SHOULD refresh the Subscription at every Target where Notification Service is subscribed to. Thus, it MUST send an "updateSubscription" request to the XSSP Server that handles that Subscription. Notification Service information MAY be also updated by the same mechanism at any time. However, information updates SHOULD be delayed until "minLife" time has passed since last refresh, at least. Refer to Section 2.4 and Section 2.5 for a detailed description of "updateSubscription" requests and "updateSubscriptionAck" replies. Error descriptions can be found at Section 2.8. Once the XSSP message with the "updateSubscription" operation(s) is Urue±a & Larrabeiti Expires September 15, 2004 [Page 17] Internet-Draft XSSP Protocol March 2004 generated, it MUST be sent to the same XSSP Server where Subscription was registered at. In the case of Global Subscriptions from a Scope, if message can not be delivered, next DA from the same Realm MAY be chosen, and the full subscription process MAY be restarted. When a XSSP Server receives a valid XSSP message with some authorized "updateSubscription" operations, it MUST follow these steps to process each operation: 1. If Subscription Target Element contains any Scope, check that those Scopes MUST have been listed in the message's Header. Otherwise, message processing SHOULD be silently aborted. 2. Search for the Subscription to be updated by its Notification Service Id. Check that it is subscribed to the specified Target. If no subscription with the specified Id is found, operation MUST be skipped and an SUBSCRIPTION_NOT_FOUND Error Element MUST be created. 3. If update request contains a Subscription Information Element, check that Notification Service was registered with the same Global Subscription Attribute. Otherwise, operation SHOULD be skipped and an INVALID_SUBSCRIPTION Error SHOULD be created. 4. If no error has occurred, XSSP Server MUST update the Subscription at all the Targets it is registered at. Specified Notification Service information (but the Notification Protocol) and Subscription properties MUST be updated, if any. 5. Choose an update interval and create an "updateSubscriptionAck" reply. Suggested Update Information MAY be taken into account. 6. Update associated LAST_UPDATE_TIMESTAMP variable with current update time. 7. Reset MAX_LIFE_TIMER associated with the updated Subscription. Such timer MUST expire after "maxLife" time, as advertised in the "updateSubscriptionAck" reply. For each "updateSubscription" request, XSSP Server MUST generate an "updateSubscriptionAck" if the Subscription has been updated, or an Error Element if an error has occurred. Both replies MUST include the Id of the Notification Service being updated. When receiving a valid XSSP message containing one or more "updateSubscriptionAck" replies, XSSP Client MUST check the Minimum and Maximum Life Attributes and reset the UPDATE_TIMER associated to the updated Subscription. The expiration time MUST be distributed Urue±a & Larrabeiti Expires September 15, 2004 [Page 18] Internet-Draft XSSP Protocol March 2004 between "minLife" and "maxLife" milliseconds. 3.3 Service Unsubscription When a XSSP Client no longer wants to receive notification Events, it MAY unsubscribe itself by employing a XSSP "unsubscribeService" request. Multiple Subscriptions MAY be deregistered within a single message by including multiple "unsubscribeService" requests. Refer to Section 2.6 and Section 2.7 for a detailed description of "unsubscribeService" requests and "unsubscribeServiceAck" replies. Error descriptions can be found at Section 2.8 Once the XSSP message with the "unsubscribeService" operation(s) is generated, it is sent to the XSSP Server where Subscription was registered at. When a XSSP Server receives a valid XSSP message with some authorized "unsubscribeService" operations, it MUST follow these steps to process each operation: 1. If Subscription Target Element contains any Scope, those Scopes MUST have been listed in the message's Header. Otherwise, message processing SHOULD be silently aborted. 2. Search for the Subscription to be unregistered by its Notification Service Id. Check that it is registered to the specified Target. If no Subscription with the specified Id is found, operation MUST be skipped and a SUBSCRIPTION_NOT_FOUND Error Element MUST be created. 3. If no error has occurred, XSSP Server MUST unsubscribe specified Notification Service from all the Targets it was registered at. This can be achieved by deleting Notification Service information, Subscription properties and associated variables; and clearing the associated MAX_LIFE_TIMER. For each "unsubscribeService" request, XSSP Server MUST generate an "unsubscribeServiceAck" if the Subscription has been deregistered, or an Error Element if an error has occurred. Both replies MUST include the Id of the Notification Service being unsubscribed. When a MAX_LIFE_TIME associated to a subscription expires, XSSP Server MUST unregister that Subscription from all the Targets it was registered at. Notification Service information and Subscription properties MUST be deleted. Urue±a & Larrabeiti Expires September 15, 2004 [Page 19] Internet-Draft XSSP Protocol March 2004 3.4 Service Event Notification XSSP only deals with the management of Subscriptions. Other protocol MUST be employed to send the Notifications themselves. Two XSDF protocols MAY be employed to deliver modification Events: XSLP: When specifying the "xslp" protocol, XSSP Server employs XSLP Service Advertisement operations [5] to notify Service modifications. XSTP: In this case, XSTP Service Notifications [7] encode modification Events as XSRP operations [6]. Both XSDF protocols allows unicast and multicast Event notification, by specifying the appropriate unicast/multicast address in the Service Location information Element. Following the rules defined in [4], multicast notifications MUST be included in a XSDF message containing the "All XSDF Agents" Destination Service Id. Unicast notifications will be delivered to the destination Service identified by the included Notification Service Id. In order that XSSP Clients know which Notification Protocols are supported by the XSSP Server, it MAY advertise them inside its "xssp" Protocol Element [4] information. For each supported Notification Protocol, the parent Protocol Element SHOULD contain another Protocol Element with the corresponding Name Attribute (i.e. "xstp" for XSTP). Supported Transport protocols for the Notification Protocol SHOULD be also included inside the "transPorts" Attribute with the associated port value set to zero. Depending on the Event forwarding topology, Global Subscriptions MAY generate Event loops (i.e. a DA forwarding an external Event twice). To avoid this phenomenon, XSDF messages containing external Events SHOULD contain an "ignoreMessage" operation [4], listing all the DAs that have forwarded this Event, including its source DA. 3.4.1 XSTP Service Notifications When a XSSP Server accepts a Subscription that employs the "xstp" Notification protocol, it SHOULD encode each modification event as a XSRP operation inside a XSTP Service Notification [7] Element. This Element SHOULD also include additional registration information associated to the Service being modified as its HOME_SA. This Notification protocol is intended for DAs to keep Service repository in sync. A DA SHOULD forward the XSRP operations it receives to its subscribed DAs. XSSP DAs MUST support the "xstp" notification protocol. However, SAs MAY also support this Urue±a & Larrabeiti Expires September 15, 2004 [Page 20] Internet-Draft XSSP Protocol March 2004 notification protocol. In that case, SAs SHOULD map Service information changes into XSRP operations. When a new Service starts, it SHOULD generate a "registerService" Event, while a "deregisterService" Element SHOULD be notified when it goes down. SAs SHOULD also generate periodically "updateRegistration" to subscribed XSSP Clients. 3.4.2 XSLP Service Advertisements For Subscriptions that employ the "xslp" notification protocol, XSSP Servers SHOULD sent Service modification events as XSLP Service Advertisements [5]. "serviceAdvert" operations MAY include full Service information or just the Service information Elements that have changed. In either case, Service Element MUST contain at least its Id and the Service State Element. It is RECOMMENDED that Service update events just contain the updated Service subelements, if any, not all the Service information ones. When a new Service starts, full Service information, but the Additional Information Element SHOULD be included in the "serviceAdvert" to be sent to subscribed XSDF Agents. Service updates SHOULD be sent before the advertised Service TTL expires. When a Service goes down, a Service Advertisement with a zero TTL SHOULD be generated. 4. Security Considerations XSDF Service Discovery Framework relies on security procedures provided by lower layers, as TLS or IPSec ones. However, it defines some authentication mechanisms that SHOULD be employed when similar ones are not being provided by the layers below. See [4] for a detailed description of these mechanisms. XSSP over TLS is named "xssp/tls" and its default port number for the TCP and SCTP transport protocols is 726. 5. Acknowledgements XSSP shares the same objectives of RFC3082: Notification and Subscription for SLP, written by James Kempf and Jason Goldschmidt. Also, XSSP and XSTP protocols are the XSDF's counterpart of Rserpool's ENRP and mSLP, thus we wish to thank its authors: Quiaobing Xie, Randall R. Stewart Maureen Stillman, Weibin Zhao, Henning Schulzrinne and Erik Guttman. Urue±a & Larrabeiti Expires September 15, 2004 [Page 21] Internet-Draft XSSP Protocol March 2004 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Urue±a, M. and D. Larrabeiti, "eXtensible Binary Encoding (XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004. [3] Urue±a, M. and D. Larrabeiti, "Overview of the eXtensible Service Discovery Framework (XSDF)", draft-uruena-xsdf-overview-00 (work in progress), March 2004. [4] Urue±a, M. and D. Larrabeiti, "eXtensible Service Discovery Framework (XSDF): Common Elements and Procedures", draft-uruena-xsdf-common-00 (work in progress), March 2004. [5] Urue±a, M. and D. Larrabeiti, "eXtensible Service Location Protocol (XSLP)", draft-uruena-xslp-00 (work in progress), March 2004. [6] Urue±a, M. and D. Larrabeiti, "eXtensible Service Registration Protocol (XSRP)", draft-uruena-xsrp-00 (work in progress), March 2004. [7] Urue±a, M. and D. Larrabeiti, "eXtensible Service Transfer Protocol (XSTP)", draft-uruena-xstp-00 (work in progress), March 2004. Authors' Addresses Manuel Urue±a Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 87 95 EMail: muruenya@it.uc3m.es Urue±a & Larrabeiti Expires September 15, 2004 [Page 22] Internet-Draft XSSP Protocol March 2004 David Larrabeiti Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 99 53 EMail: dlarra@it.uc3m.es Appendix A. XSSP Constants A.1 XBE32 Elements Element Name XBE32 Type ------------ ---------- xsspv1 0x0b01 subscribeService 0x0b10 subscribeServiceAck 0x0b11 updateSubscription 0x0b20 updateSubscriptionAck 0x0b21 unsubscribeService 0x0b30 unsubscribeServiceAck 0x0b31 subscribeInfo 0x0420 eventInfo 0x0421 registerService 0x0a10 updateService 0x0a20 updateServiceInfo 0x0a22 deregisterService 0x0a30 expiredService 0x0a32 A.2 Variables and Timers Variable name Description --------------------- -------------------------------------------- LAST_UPDATE_TIMESTAMP Server timestamp of last Subscription update Timer name Description -------------- ---------------------------------------------------- UPDATE_TIMER Client timer to refresh subscription MAX_LIFE_TIMER Server timer to delete subscription if not refreshed Urue±a & Larrabeiti Expires September 15, 2004 [Page 23] Internet-Draft XSSP Protocol March 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Urue±a & Larrabeiti Expires September 15, 2004 [Page 24] Internet-Draft XSSP Protocol March 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urue±a & Larrabeiti Expires September 15, 2004 [Page 25] Network Working Group M. Urue±a Internet-Draft D. Larrabeiti Expires: September 15, 2004 UC3M March 17, 2004 eXtensible Service Transfer Protocol (XSTP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines the eXtensible Service Transfer Protocol (XSTP), a lightweight protocol that allows Directory Agents from a common Realm to download all the available Service information (for example, at startup), in order to share the same view of their Service information repository. XSTP is one of the protocols of the eXtensible Service Discovery Framework (XSDF). Urue±a & Larrabeiti Expires September 15, 2004 [Page 1] Internet-Draft XSTP Protocol March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Notation Conventions . . . . . . . . . . . . . . . . . . . 4 2. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 XSTPv1 Element . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Service Transfer Request Element . . . . . . . . . . . . . 5 2.2.1 Registration Target Element . . . . . . . . . . . . . 6 2.3 Service Transfer Reply Element . . . . . . . . . . . . . . 6 2.3.1 Registration Element . . . . . . . . . . . . . . . . . 7 2.4 Service Notification Element . . . . . . . . . . . . . . . 8 2.5 Common Operation Parameters . . . . . . . . . . . . . . . 8 2.5.1 Registration State Element . . . . . . . . . . . . . . 8 2.5.2 Registration Information Element . . . . . . . . . . . 9 3. XSTP Operation Procedures . . . . . . . . . . . . . . . . . . 11 3.1 Directory Agent Initialization . . . . . . . . . . . . . . 11 3.2 Service Transfers . . . . . . . . . . . . . . . . . . . . 13 3.3 Service Notifications . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 A. XSTP Constants . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1 XBE32 Elements . . . . . . . . . . . . . . . . . . . . . . 17 A.2 Time Constants . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Urue±a & Larrabeiti Expires September 15, 2004 [Page 2] Internet-Draft XSTP Protocol March 2004 1. Introduction XSDF [4] is a framework for Service Discovery. It allows Users to dynamically find available network Services and choose the better ones following certain selection policies. In XSDF, User Agents (UAs) may issue multicast Service requests directly to Service Agents (SAs). In bigger networks, UAs request Service information to a central repository managed by the so-called Directory Agents (DAs). XSTP is a protocol that allows a Directory Agent to fetch all the Service information known by another DA from a common Realm. This allows DAs to share a common view of the Service repository. This allows that any XSDF operations (but Local Subscriptions [8]) may be issued to any active DA of the Realm, with similar results. XSTP is employed to build the initial Service repository from a "mentor" DA, and latter check that repositories are in sync by periodically downloading the Service Registrations from random DAs. XSSP [8] is also employed in order to be subscribed to Service modifications in other DAs. Those modification Events are delivered by employing XSTP Service Notification messages. 1.1 Definitions Domain: A Domain is a single administrative organization containing Users and Services. Scope: A Scope is a subset of Users and Services from a Domain, typically making a logical administrative group. Realm: A Realm is a combination of a Domain and one or more Scopes from such Domain, if any. Service: A Service is any process attached to a network that provides some kind of functionality to Users or other Services. A Service belongs to a single Realm. User Agent (UA): A process working on the User's (or other process) behalf to discover Services, and select the best available one. UAs obtain Service information from Directory Agents and Service Agents via XSLP. Service Agent (SA): A Service Agent is itself a Service that advertise Service information on behalf other processes. SAs are queried by User Agents for Services via XSLP, and/or register Service information in Directory Agents employing XSRP. Urue±a & Larrabeiti Expires September 15, 2004 [Page 3] Internet-Draft XSTP Protocol March 2004 Directory Agent (DA): A Directory Agent is a Service that, when deployed, acts as a central repository of all Service information from a Realm. Service Agents register its Services in a DA employing the XSRP protocol. Then, User Agents are able to query that information with XSLP. An Scope can be served by multiple DAs that coordinate themselves via XSSP & XSTP protocols. XSDF Agent: Any process that employs any XSDF protocol to interact with other XSDF Agents. XSTP Agent: A XSTP Agent is a Directory Agent that employs the XSTP protocol in order to synchronize the Service repository with other, XSTP capable, Directory Agents. 1.2 Notation Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [1]. Urue±a & Larrabeiti Expires September 15, 2004 [Page 4] Internet-Draft XSTP Protocol March 2004 2. Messages Format This section defines the format of all XSTP messages. These messages are exchanged between two Directory Agents. XSDF protocol messages are encoded employing XBE32 [3]. Definitions for common XSDF Elements and Attributes can be found at [5] 2.1 XSTPv1 Element All XSDF messages have a common format: a single XBE32 Element containing a Header, and one or more protocol Operations. XSTP messages are encoded inside a XSTPv1 Element. XSTPv1 Element: Element Name : xstpv1 XBE32 Type : 0x0c01 +---------------------------------------------------------------+ : Header Element : +---------------------------------------------------------------+ : XSTP Operation Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : XSTP Operation Element #N : +---------------------------------------------------------------+ : [ Signature Information Element ] : +---------------------------------------------------------------+ Header and Signature Information Elements are defined in [5]. Next subsections describe XSTP Operation Elements. 2.2 Service Transfer Request Element A XSTP Client sends this operation request to a DA in order to fetch the registered Service information from their common Realm. DA will reply with one "serviceTransferReply" operation Element. Service Transfer Request Element: Element Name : serviceTransferRequest XBE32 Type : 0x0c10 +---------------------------------------------------------------+ : Registration Target Element : +---------------------------------------------------------------+ | [ Directory State Timestamp ] | +---------------------------------------------------------------+ Urue±a & Larrabeiti Expires September 15, 2004 [Page 5] Internet-Draft XSTP Protocol March 2004 Directory State Timestamp Attribute: Attribute Name : stateTimestamp XBE32 Type : 0x331a Value Type : int64 Value Length : 64 bits When a Directory State Timestamp parameter is included, the response message SHOULD only include Service Registrations that have been updated since the specified time, as defined by their associated LAST_UPDATE_TIMESTAMP variables. 2.2.1 Registration Target Element Registration Target Element defines which Service Registrations SHOULD be returned. Those Registrations MAY be identified by the Scopes they belong to, or by their particular Service Ids. Target Element: Element Name : target XBE32 Type : 0x0821 +---------------------------------------------------------------+ : [ Realm Element ] : +---------------------------------------------------------------+ | [ Service Ids ] | +---------------------------------------------------------------+ Realm Element and Service Ids Attribute are defined in [5]. The Realm Element MAY contain the subset of Header's Realm Scopes to be downloaded. If Realm Element is empty and no Service Ids Attribute has been specified, all the Services belonging to the Scopes specified in the message's Header SHOULD be transfer. When included, the Service Ids Attribute indicates which Services should be returned. XSTP Directory Agent SHOULD NOT return information about other Services but the ones listed here. When the list does contain unknown Services, those Ids SHOULD be silently skipped. 2.3 Service Transfer Reply Element This response operation is sent back by the DA to the XSTP Client as an answer to a previous "serviceTransferRequest" operation. They contain all the selected Service information and its associated Registration information. Urue±a & Larrabeiti Expires September 15, 2004 [Page 6] Internet-Draft XSTP Protocol March 2004 Service Transfer Reply Element: Element Name : serviceTransferReply XBE32 Type : 0x0c11 +---------------------------------------------------------------+ : Realm Target Element : +---------------------------------------------------------------+ : [ Registration Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Registration Element #N ] : +---------------------------------------------------------------+ Realm Target Element is defined in [5]. The Realm Target Element MUST contain the subset of Header's Realm Scopes where Registrations belong to. If Realm Target is empty, Services are registered at all the Scopes specified in the message's Header. 2.3.1 Registration Element Registration Element does contain all the information associated with a registered Service. Registration Element: Element Name : registration XBE32 Type : 0x0500 +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : Registration State Element : +---------------------------------------------------------------+ : Registration Information Element : +---------------------------------------------------------------+ Service Element is defined in [5]. Registration State and Information Elements are defined in Section 2.5. Service Element MUST contain all the information known by the DA, that is: Service Id, State, Main Information, Location and Additional Information. Registration State and Information Elements contain additional data associated with the registered Service as its remaining TTL or its HOME_SA variable. Urue±a & Larrabeiti Expires September 15, 2004 [Page 7] Internet-Draft XSTP Protocol March 2004 2.4 Service Notification Element DAs are subscribed [8] among them, in order to quickly receive Service modifications that affect the common Realm. When the "xstp" notification protocol is employed, DAs sent the XSRP operations they accept inside "serviceNotify" operations. Service Notification Element: Element Name : serviceNotify XBE32 Type : 0x0c21 +---------------------------------------------------------------+ : XSRP Operation Element : +---------------------------------------------------------------+ : [ Registration State Element ] : +---------------------------------------------------------------+ : [ Registration Information Element ] : +---------------------------------------------------------------+ All XSRP operations are defined in [7]. Registration State and Information Elements are defined in Section 2.5.2. The only XSRP operation Elements that could be included in a "serviceNotify" operation are the following requests: Register Service, Update Service and Deregister Service Elements. Registration State Element contains additional data that the source DA has updated when the XSRP operation has been processed. It SHOULD be included in all "serviceNotify" Elements but the ones carrying a Deregister Service operation. Registration Information Element MUST be included in any "serviceNotify" Elements, carrying a Register Service operation. This Element does contain additional Registration information about the new Service. 2.5 Common Operation Parameters DAs need to store more data about a registered Service that just the Service information itself. Therefore, that additional data should be also transferred with its associated Service information when the XSTP protocol is employed. This section defines the two Elements that form that information. 2.5.1 Registration State Element This Element includes the volatile Registration information associated to a Service. Urue±a & Larrabeiti Expires September 15, 2004 [Page 8] Internet-Draft XSTP Protocol March 2004 Registration State Element: Element Name : registrationState XBE32 Type : 0x0510 +---------------------------------------------------------------+ : Cache State Element : +---------------------------------------------------------------+ : Update Information Element : +---------------------------------------------------------------+ : [ Selection State Element ] : +---------------------------------------------------------------+ Cache, Update Information and Selection State Elements are defined in [5]. Cache State Element contains two Attributes about the associated Service, its Age and the remaining TTL. Both values SHOULD be calculated from the current time, LAST_UPDATE_TIMESTAMP and Lifetime Attribute of the associated Service. Update Information Element SHOULD be identical to the one included in the last XSRP reply sent by the DA. XSTP Client SHOULD employ the "maxLife" value minus the Age to set the MAX_LIFE_TIMER for the Service. Selection State Element contains the volatile information for DA Selection process that MAY be associated to the Service Type of the Registration. 2.5.2 Registration Information Element This Element includes the pseudo-static Registration information associated to a Service. Registration Information Element: Element Name : registrationInfo XBE32 Type : 0x0520 +---------------------------------------------------------------+ : [ Source Endpoint Element ] : +---------------------------------------------------------------+ : [ Selection Information Element ] : +---------------------------------------------------------------+ Endpoint and Selection Information Elements are defined in [5]. Source Endpoint parameter is an Endpoint Element containing the Service information about the HOME_SA of a new Service Registration. Urue±a & Larrabeiti Expires September 15, 2004 [Page 9] Internet-Draft XSTP Protocol March 2004 At least, the included Service Element MUST contain the SA Service Id. Other Service information is optional and MAY NOT appear. Selection Information Element contains the policy information for DA Selection process that MAY be associated to the Service Type of the Registration. Urue±a & Larrabeiti Expires September 15, 2004 [Page 10] Internet-Draft XSTP Protocol March 2004 3. XSTP Operation Procedures All XSDF Agents MUST follow the common procedures for XSDF Agent initialization, message generation, transmission and processing defined in [5]. This section specifies additional procedures for the XSTP protocol. XSTP is a Client-Server protocol. DAs act as XSTP Servers and respond to requests sent by XSTP Clients. XSTP MAY also be employed as a Notification Protocol for XSSP Subscriptions [8]. All XSTP Agents MUST support the TCP transport protocol and MAY also support SCTP and UDP. The default port number for these transport protocols is 723. 3.1 Directory Agent Initialization As any other XSDF Agent, DAs MUST be configured with the Realm it belongs to, and locate other DAs managing those Scopes, if any. Therefore, they MUST perform the initialization procedures specified in [5]. When a Directory Agent starts, it MUST generate its own Service information, including an unique 16 byte Service identifier, as defined in [2]. Once its Service information is created, DA MUST register and latter refresh its own Service information at all the Scopes it belongs to. The Type Attribute for DA Service information is "xsdf:da". Each Scope MAY be managed by one or more DAs. In the first case, that DA is in the so-called Stand-Alone state. It will receive all the XSDF requests from the XSDF Agents of the Scope. In that scenario, neither XSTP nor XSSP protocols are mandatory, and DAs MAY NOT implement it. However, if the same Scope is managed by multiple DAs, they MUST implement both protocols in order that every DA has an up-to-date copy of the Services registered in that Scope. The initialization phase of a DA ends when it knows whether, there are no more DAs managing any of its Scopes (thus in the Stand-Alone state), or there are more DAs. In the latter case the starting DA SHOULD populate its Service repository from a "mentor" DA as follows: 1. DAs SHOULD wait a random delay between 0 and INIT_DELAY before beginning its initialization process to avoid that two DAs starting simultaneously fail to locate each other. 2. After all active DAs from compatible Realms are located, one of them MUST be chosen as the "mentor" DA. Advertised Selection Urue±a & Larrabeiti Expires September 15, 2004 [Page 11] Internet-Draft XSTP Protocol March 2004 policy, if any, SHOULD be employed to choose among the DAs that support the "xssp" and "xstp" protocols. If "mentor" DA becomes unavailable while performing the initialization process, next DA SHOULD be chosen and the process SHOULD be restarted until there are no active DAs left. In that case, the starting DA MUST fallback to the Stand-Alone behavior. 3. Starting DA MUST subscribe itself to all the Events from "mentor" DA by employing XSSP and "xstp" as its Notification Protocol. Received Events SHOULD NOT be processed but enqueued for latter use. 4. Once the Global Subscription has been accepted, starting DA MUST begin a Service Transfer of all the common Scopes with "mentor" peer. See Section 3.2 for details. 5. When the Service Transfer ends, starting DA SHOULD apply the enqueued modification Events to its new repository copy. After these steps, starting DA SHOULD have an exact copy of the Service repository of its "mentor" DA. To keep this data in sync with other DAs, each DA MUST be subscribed to local Events in every other active DA managing a common Scope. Once all the Local Subscriptions have been accepted, including another one with its "mentor" DA, starting DA SHOULD deregister the initial Global Subscription to avoid receiving multiple copies of each Event. The above initialization process description refers only to a single Scope. However, if the starting DAs belongs to multiple Scopes, it SHOULD repeat the above process until: it has obtained from "mentor" DAs the Service repository of all its Scopes, or it is in the Stand-Alone state for Scopes without other active DAs. The "LOCAL" Scope is the only exception to this rule. DAs MUST NOT consider the "LOCAL" Scope as a Scope to be shared with other DAs. At this point the starting DA is considered to be ready to begin. Therefore, it SHOULD start accepting XSDF requests from XSDF Agents and start sending Service Notifications and Advertisements. It is RECOMMENDED that at this point the starting DA (or a new Stand-Alone DA) sends a Service Advertisement to the "All XSDF Agents" multicast group in order to disclose its Service information. No matter if the DA is in the Stand-Alone state or already initialized from a "mentor" DA, every DA MUST be aware of new DAs managing a compatible Realm. In that case, if the new DA supports the "xssp" protocol, all DAs from common Scopes MUST be subscribed to local Events from the new DA. In order to avoid a flooding of Subscription requests, each DA MUST wait a random interval between Urue±a & Larrabeiti Expires September 15, 2004 [Page 12] Internet-Draft XSTP Protocol March 2004 zero and SUBSCRIPTION_DELAY before trying to be subscribed. Additionally, Service Advertisement of the new DA MAY include an Update Information Element inside its "xssp" Protocol Element. In that case, DAs MUST wait a random interval between "minLife" and "maxLife" advertised attributes. A DA could discover new DAs from its own Scope by multiple ways. All DAs, unless configured to do not so, MUST join to the "All XSDF Agents" multicast group in order to receive DA Service Advertisements. Active DA Discovery MAY be also employed. Both mechanisms are defined in [6]. Additionally, new DAs could be also discovered inside Service Notifications or be querying its own Service repository after a Service Transfer has been completed. 3.2 Service Transfers A XSTP Client that wants to fetch the Service repository of a DA, will send a XSTP message containing a "serviceTransferRequest" operation. The DA will reply with another XSTP message containing a "serviceTransferReply" operation. Refer to Section 2.2 and Section 2.3 for a detailed description of "serviceTransferRequest" and "serviceTransferReply" Elements. When a DA receives a valid XSTP message with an authorized "serviceTransferRequest" operation, it MUST follow these steps to process such operation: 1. Obtain the list of Scopes from the request's Target Element to transfer Services. Those Scopes MUST have been listed in message's Header. Otherwise, message processing SHOULD be silently aborted. If Target Element is empty, get the ones in message's Header. 2. If the Target parameter specifies the Ids of the requested Services, DA SHOULD find those Services and check that they belong to the specified Scopes. 3. If the request operation contains a Directory Timestamp parameter, Services not updated after the specified time SHOULD NOT be transferred. 4. For each Service to be transferred, a new Registration Element containing all the Service information and associated Registration data MUST be created. 5. Send the requested Registration Elements inside a "serviceTransferReply" Element. Urue±a & Larrabeiti Expires September 15, 2004 [Page 13] Internet-Draft XSTP Protocol March 2004 If the XSTP Client is itself a DA, transferred Registrations SHOULD be employed to update its Service repository. However, older data MUST NOT overwrite newer one. Both Registrations MUST be compared by the State Timestamp Attribute inside the associated Service Element. Older transferred Registrations SHOULD be skipped. Based on each transferred Service Registration, the following variables and timer SHOULD be updated/created: HOME_SA: New Services MUST set the HOME_SA variable from the Source Endpoint Element, carried inside the Registration Information one. SERVICE_LIFETIME: This value SHOULD be calculated as the sum of the Age and TTL Attributes of the Cache State Element, carried inside the Registration State one. LAST_UPDATE_TIMESTAMP: This variable SHOULD be updated with the current time minus the Age Attribute. MAX_LIFE_TIMER: This associated timer SHOULD be cleared, and set again to expire after "maxLife" (in the Update Information Element) minus "Age" time elapses. It is RECOMMENDED that DAs perform Service Transfers from random DAs at the compatible Realm to periodically check that the Service repository keeps in sync. 3.3 Service Notifications Modification Events delivered by XSTP are encoded inside "serviceNotify" operations. Refer to Section 2.4 for a detailed description of the "serviceNotify" Element. DAs SHOULD be subscribed to all the DAs from compatible Realms in order to apply the received modification Events to its own Service repository. They MUST renew those Local Subscriptions periodically thus checking that peer DAs keep being active. They SHOULD also honor the registered Subscriptions by generating modification Events caused by XSRP operations or by other external Events. Those external Events SHOULD be forwarded only to its Global Subscribers, while both Local and Global Subscribers SHOULD be informed of XSRP operations targeted to itself. DAs SHOULD react to external XSRP operations received inside Service Notification Elements as if they were local ones, as defined in [7]. However, DAs SHOULD also process the additional Registration data carried by the XSTP Service Notification Element as described in Urue±a & Larrabeiti Expires September 15, 2004 [Page 14] Internet-Draft XSTP Protocol March 2004 Section 3.2. When a DA receives a XSRP "updateService" operation Event for an unknown Service Id, it MUST discard such Event but it MAY perform a Service Transfer from the Source DA in order to obtain the missing Service Registrations. 4. Security Considerations XSDF Service Discovery Framework relies on security procedures provided by lower layers, as TLS or IPSec ones. However, it defines some authentication mechanisms that SHOULD be employed when similar ones are not being provided by the layers below. See [5] for a detailed description of these mechanisms. XSTP over TLS is named "xstp/tls" and its default port number for the TCP and SCTP transport protocols is 724. 5. Acknowledgements XSSP and XSTP share the same objectives of mSLP and Rserpool's ENRP. In particular, DA initialization process is owed from ENRP Server's one. Thus we would like to acknowledge the members of the Rserpool Working Group, and specially to Qiaobing Xie, Randall R. Stewart and Maureen Stillman. Urue±a & Larrabeiti Expires September 15, 2004 [Page 15] Internet-Draft XSTP Protocol March 2004 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Mealling, M., "A UUID URN Namespace", draft-mealling-uuid-urn-03 (work in progress), March 2004. [3] Urue±a, M. and D. Larrabeiti, "eXtensible Binary Encoding (XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004. [4] Urue±a, M. and D. Larrabeiti, "Overview of the eXtensible Service Discovery Framework (XSDF)", draft-uruena-xsdf-overview-00 (work in progress), March 2004. [5] Urue±a, M. and D. Larrabeiti, "eXtensible Service Discovery Framework (XSDF): Common Elements and Procedures", draft-uruena-xsdf-common-00 (work in progress), March 2004. [6] Urue±a, M. and D. Larrabeiti, "eXtensible Service Location Protocol (XSLP)", draft-uruena-xslp-00 (work in progress), March 2004. [7] Urue±a, M. and D. Larrabeiti, "eXtensible Service Registration Protocol (XSRP)", draft-uruena-xsrp-00 (work in progress), March 2004. [8] Urue±a, M. and D. Larrabeiti, "eXtensible Service Subscription Protocol (XSSP)", draft-uruena-xssp-00 (work in progress), March 2004. Authors' Addresses Manuel Urue±a Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 87 95 EMail: muruenya@it.uc3m.es Urue±a & Larrabeiti Expires September 15, 2004 [Page 16] Internet-Draft XSTP Protocol March 2004 David Larrabeiti Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 99 53 EMail: dlarra@it.uc3m.es Appendix A. XSTP Constants A.1 XBE32 Elements Element Name XBE32 Type ------------ ---------- xstpv1 0x0c01 serviceTransferRequest 0x0c10 serviceTransferReply 0x0c11 serviceNotify 0x0c21 registration 0x0500 registrationState 0x0510 registrationInfo 0x0520 directoryState 0x0710 A.2 Time Constants Constant name Default Value Description ------------------ ------------- ---------------------------------- INIT_DELAY 5000 ms DA initialization delay SUBSCRIPTION_DELAY 2000 ms DA max delay before subscribing to a newly discovered DA Urue±a & Larrabeiti Expires September 15, 2004 [Page 17] Internet-Draft XSTP Protocol March 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Urue±a & Larrabeiti Expires September 15, 2004 [Page 18] Internet-Draft XSTP Protocol March 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urue±a & Larrabeiti Expires September 15, 2004 [Page 19] Network Working Group M. Urue±a Internet-Draft D. Larrabeiti Expires: September 15, 2004 UC3M March 17, 2004 eXtensible Binary Encoding (XBE32) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines the eXtensible Binary Encoding (XBE32). It has been designed to represent hierarchical data in a compact and extensible format. Data elements are binary encoded inside Type-Length-Value (TLV) structures, which are 32-bit aligned to be easily parsed by computers. XBE32 is NOT a binary encoding for XML documents, but an encoding format for small, lightweight network protocols. Urue±a & Larrabeiti Expires September 15, 2004 [Page 1] Internet-Draft XBE32 Binary Encoding March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Notation Conventions . . . . . . . . . . . . . . . . . . . 3 2. Common TLV Format . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Unspecified Length . . . . . . . . . . . . . . . . . . . . 5 3. XBE32 TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 TLV with inner TLV Values . . . . . . . . . . . . . . . . 6 3.2 TLV with a Variable-Length Value . . . . . . . . . . . . . 7 3.3 TLV with 1 Octet Values . . . . . . . . . . . . . . . . . 7 3.4 TLV with 2 Octets Values . . . . . . . . . . . . . . . . . 8 3.5 TLV with 4 Octets Values . . . . . . . . . . . . . . . . . 8 3.6 TLV with 8 Octets Values . . . . . . . . . . . . . . . . . 9 3.7 TLV with 12 Octets Values . . . . . . . . . . . . . . . . 9 3.8 TLV with 16 Octets Values . . . . . . . . . . . . . . . . 10 4. XBE32 Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 Extensible Elements: Ids and Names . . . . . . . . . . . . 11 4.2 Complex Elements . . . . . . . . . . . . . . . . . . . . . 12 4.3 Attribute Elements . . . . . . . . . . . . . . . . . . . . 12 4.3.1 Opaque Values . . . . . . . . . . . . . . . . . . . . 13 4.3.2 String Value . . . . . . . . . . . . . . . . . . . . . 14 4.3.3 Boolean Values . . . . . . . . . . . . . . . . . . . . 14 4.3.4 Integer Values . . . . . . . . . . . . . . . . . . . . 14 4.3.5 Float Values . . . . . . . . . . . . . . . . . . . . . 14 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 A. XBE32 Examples . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 18 Urue±a & Larrabeiti Expires September 15, 2004 [Page 2] Internet-Draft XBE32 Binary Encoding March 2004 1. Introduction Nowadays, the most popular format to represent hierarchical structured information is XML and it is being employed in multiple network protocols. Although its textual representation allows extensible protocols and ease protocol development and debugging, it requires more bandwidth than a binary counterpart. This document defines the XBE32 encoding. A simple binary encoding for network protocols that carry hierarchical data. All XBE32 elements are encoded inside 32 bit aligned TLV structures to ease the parsing process. As data is clearly delimited, XBE32 does not require to escape characters as XML does, thus easing message creation. As TLVs have 2 octet Type an Length fields, it is well suited for simple protocols with small messages and a small set of identifiers. However, in order to be extensible, it supports variable-length binary and string identifiers. Also, XBE32 allows complex elements with an undefined length in order to start sending a message before its total length is known. In order to be employed by modern programming languages, XBE32 defines common data types as Integer, Float, Boolean, String or Arrays. Other data types can be represented as opaque binary data, also defined by XBE32. 1.1 Notation Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [1]. Urue±a & Larrabeiti Expires September 15, 2004 [Page 3] Internet-Draft XBE32 Binary Encoding March 2004 2. Common TLV Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Values : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (16 bits): This field describes which kind of value is inside this TLV. This field has the following internal structure: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|E| Meta | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type's highest-order two bits specify the actions that must be taken if the processing entity does not recognize that Type: C - Continue Processing: 0 - Discard this TLV and stop processing TLVs left. 1 - Skip this TLV and continue processing. E - Notify Error: 0 - Do not report to the sender that this Type is unknown. 1 - Report to the sender that this Type is unknown. Meta (6 bits): This field describes the internal structure of the Values field: Meta Values structure --------- ------------------------------ 0x00-0x1F Multiple, variable-length TLVs 0x20-0x2F Single, variable-length Value 0x30 Multiple, 1 octet Values 0x31 Multiple, 2 octet Values 0x32 Multiple, 4 octet Values 0x33 Multiple, 8 octet Values 0x34 Multiple, 12 octet Values 0x35 Multiple, 16 octet Values 0x36-0x3F Reserved Urue±a & Larrabeiti Expires September 15, 2004 [Page 4] Internet-Draft XBE32 Binary Encoding March 2004 Length (16 bits): This field contains the unsigned length of the whole TLV structure measured in octets, padding not included. Length SHOULD be always greater than 4 octets, that is, the length of the Type and Length values. The only exception to this rule is a complex TLV with a zero length value which is explained in next subsection. Value (variable length): The Values field contains the actual XBE32-encoded data. If a primitive Value is not aligned to 4 octet words, empty space MUST be filled with zeros (0x00). 2.1 Unspecified Length In some circumstances a message can not be delayed/stored until all the data to be encoded is available. However, as a TLV should contain the total length of the structure, it can not be sent before all the data becomes available or the length can be inferred somehow. For that reason, XBE32 allows a complex TLV (i.e. containing other TLVs) to have an "undefined length". In that case, the last of the inner TLVs MUST be an End-of-data TLV. "Undefined" length is specified by setting the complex TLV Length field to zero (0x0000). End-of-data TLV has the Type field set to zero (0x0000) and 4 octet length, thus it is empty and MUST NOT contain any value: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0000 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This mechanism allows XBE32 to encode complex TLVs of arbitrary length. However, only complex elements may have an unspecified length. Primitive Values MUST NOT be larger than 65532 octets. Urue±a & Larrabeiti Expires September 15, 2004 [Page 5] Internet-Draft XBE32 Binary Encoding March 2004 3. XBE32 TLVs Some Values transmitted may not be 4 octet word aligned, thus in that case padding MUST be added (up to 3 padding octets) to align the TLV structure to 4 octet words. Padding octets MUST be filled with zeros (0x00) in transmission and MUST be ignored in reception. 3.1 TLV with inner TLV Values This figure displays a complex TLV containing several TLV Values. If Length field is "undefined" (0x0000), complex TLV MUST end with a 4 octet End-of-data TLV. If total length is specified, End-of-data TLV MUST NOT appear. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type.Meta = 0x00-0x1F | Length = 0 or 4 + TLVs Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type #1 | Length #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Values #1 : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type #N | Length #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Values #N : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [ End-of-data TLV ] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As XBE32 TLVs are always aligned to 4 octets words, the global TLV will be also aligned to 4 octet word thus padding MUST NOT be added, and the Length field will contain the total length of the TLV. Note that in the case of TLVs Values with padding, the Length of the global TLV MUST NOT be calculated as 4 plus the sum of the Length (or Extended Length TLV) fields of all the TLV values, which do not include the padding octets. Urue±a & Larrabeiti Expires September 15, 2004 [Page 6] Internet-Draft XBE32 Binary Encoding March 2004 3.2 TLV with a Variable-Length Value This figure displays a XBE32 TLV containing a single Value: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type.Meta = 0x20-0x2F | Length = 4 + Value.length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Value : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | 0x00 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length field contains the sum of the TLV header (Type and Length) plus the length in octets of the encoded Value. As the Value may not be aligned to 4 octet words, padding MUST be added. In that case the Length field does not contain the total length of the TLV structure but the length without the padding octets. 3.3 TLV with 1 Octet Values This figure displays a XBE32 TLV containing N, 1 octet Values: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type.Meta = 0x30 | Length = 4 + N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value #1 | Value #2 | Value #3 | Value #4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value #N | 0x00 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field contains the sum of the TLV header (Type and Length) plus the number of 1 octet values. As the number of Values may not multiple of 4, up to 3 padding octets SHOULD be added. In that case the length field does not contain the total length of the TLV structure but the total length without the padding octets. Urue±a & Larrabeiti Expires September 15, 2004 [Page 7] Internet-Draft XBE32 Binary Encoding March 2004 3.4 TLV with 2 Octets Values This figure displays a XBE32 TLV containing N, 2 octet Values: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type.Meta = 0x31 | Length = 4 + 2*N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value #1 | Value #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value #N | 0x0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field contains the sum of the TLV header (Type and Length) plus the number of 2 octet values multiplied by two. As the number of Values may not multiple of 2, two padding octets SHOULD be added. In that case the length field does not contain the total length of the TLV structure but the total length without padding octets. 3.5 TLV with 4 Octets Values This figure displays a XBE32 TLV containing N, 4 octet Values: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type.Meta = 0x32 | Length = 4 + 4*N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These TLVs are always aligned to 4 octet words. Length field MUST contain the total length of the TLV as padding MUST NOT be added. Urue±a & Larrabeiti Expires September 15, 2004 [Page 8] Internet-Draft XBE32 Binary Encoding March 2004 3.6 TLV with 8 Octets Values This figure displays a XBE32 TLV containing N, 8 octet Values: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type.Meta = 0x33 | Length = 4 + 8*N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Value #1 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Value #N + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These TLVs are always aligned to 4 octet words. Length field MUST contain the total length of the TLV as padding MUST NOT be added. 3.7 TLV with 12 Octets Values This figure displays a XBE32 TLV containing N, 12 octet Values: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type.Meta = 0x34 | Length = 4 + 12*N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Value #1 | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Value #N + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Urue±a & Larrabeiti Expires September 15, 2004 [Page 9] Internet-Draft XBE32 Binary Encoding March 2004 These TLVs are always aligned to 4 octet words. Length field MUST contain the total length of the TLV as padding MUST NOT be added. 3.8 TLV with 16 Octets Values This figure displays a XBE32 TLV containing N, 16 octet Values: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type.Meta = 0x35 | Length = 4 + 16*N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Value #1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Value #N + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These TLVs are always aligned to 4 octet words. Length field MUST contain the total length of the TLV as padding MUST NOT be added. Urue±a & Larrabeiti Expires September 15, 2004 [Page 10] Internet-Draft XBE32 Binary Encoding March 2004 4. XBE32 Elements XBE32 has been designed to encode hierarchical data in a compact binary format easily generated and parsed by machines. Hierarchical data can be represented as a tree where each node has a name. The "leaf" nodes of the tree are also named but they are the only ones that carry data. In XBE32 each node on the tree is known as "Element". Every Element has an identifier, that could be a binary one or a human-readable name. There are two kinds of Elements in XBE32 based in if they carry primitive data. "Attribute Elements" are the "leafs" of the tree and carry primitive values. "Complex Elements" on the other hand don't carry primitive data, but are the parents of other Elements, that could be Attribute Elements or another Complex Elements themselves. As most of the protocols will employ a small set of elements to build its messages, XBE32 Elements MAY be identified just by its Type field. Every protocol may define its own set of Subtypes not employed in the base specification of XBE32: Meta Subtype Element -------- --------- --------------------- 0x00-0x1F 0x01-0xFF Complex Element TLV 0x20-0x35 0x03-0xFF Attribute Element TLV 4.1 Extensible Elements: Ids and Names The above mechanism allows a compact representation and is suitable for the initial definition of the mandatory operations and parameters of a protocol. However, a 2 octet Type field is not enough for truly extensible protocols, as it could be a too small namespace for vendor extensions or experimental operations. In order to cope with this requirement, XBE32 allows Extensible Elements. This kind of XBE32 Elements are not identified by their Type field but include an initial TLV with an identifier Value. After that identifier TLV, it may contain more TLVs with the specified Values (in the case of an Extensible Attribute Element) of sub-elements (if Extensible Element is a Complex one). All the Types with the Meta field set to 0x10 and Subtype field set to 0x00 are reserved for Extensible Element TLVs. Note that C and E bits may have any value. Therefore up to four different Extensible Urue±a & Larrabeiti Expires September 15, 2004 [Page 11] Internet-Draft XBE32 Binary Encoding March 2004 Elements could be defined. For example, an optional Complex Element that should not notified if unknown, will have the 0x9000 Type Value. Meta Subtype Description ---- ------- ---------------------- 0x10 0x00 Extensible Element TLV An XBE32 Extensible Element MUST have an identifier, which can be a human-readable UTF-8 string called "Name" or an opaque sequence of octets called "Id". XBE32 has defined two TLVs to carry those identifiers: Type TLV Description ------ ----------------------- 0x2000 Extensible Element Name 0x2001 Extensible Element Id 4.2 Complex Elements A Complex Element is a TLV containing Multiple, XBE32 Encoded Values (Type.Meta=0x00-0x1F). Unless a non-zero Subtype is specified, the first TLV-encoded Value MUST be an Element Name (Type=0x2000) or an Element Id (Type=0x2001) one, which value MUST be 4 octets long. If some Subtype value is assigned to the Complex Element to be encoded, the upper TLV MUST have that non-zero value in the Subtype field. As the Element is identified by that value, the Element Id/ Name TLVs are not needed and SHOULD NOT appear. A Complex Element may contain zero or more XBE32 Elements that could be Attribute Elements, Complex Elements or a combination of both. Any TLV different to an XBE32 Element TLV (i.e. Element Values TLV) is forbidden and MUST NOT appear inside a Complex Element TLV. 4.3 Attribute Elements An Attribute Element does not have any children Element as the Complex Element does, but zero or more simple values. An Extensible Attribute Element without an assigned Subtype has a format very similar to a Complex Element but containing one or more TLV Values. That is, a TLV with a zero (0x00) Subtype containing Multiple XBE32 Encoded Values (Meta=0x00-0x1F). The first one MUST be Element Id (Type=0x2001) or an Element Name (Type=0x2000) TLV. Some XBE32 TLVs (Meta=0x30-0x35) are able to carry several fixed-length values inside a single TLVs, while others Urue±a & Larrabeiti Expires September 15, 2004 [Page 12] Internet-Draft XBE32 Binary Encoding March 2004 (Meta=0x20-0x2F) only allows one Value per TLV. As an Attribute Element may have several values of the same type, an Extensible Attribute Element with a Element Id/Name TLV SHOULD carry one of the former, multi-value TLVs or one or more of the latter, single-value TLVs with the same type. Those are the TLVs containing Values that may appear inside an Extensible Attribute Element: Type TLV Description ------ ------------------------ 0x2100 Single opaque Value 0x2800 Single string Value 0x3000 Multiple opaque1 Values 0x3001 Multiple int8 Values 0x3002 Multiple boolean Values 0x3100 Multiple opaque2 Values 0x3101 Multiple int16 Values 0x3200 Multiple opaque4 Values 0x3201 Multiple int32 Values 0x3202 Multiple float32 Values 0x3300 Multiple opaque8 Values 0x3301 Multiple int64 Values 0x3302 Multiple float64 Values 0x3400 Multiple opaque12 Values 0x3500 Multiple opaque16 Values When a Subtype value is assigned to the Attribute Element, its XBE32 encoding fits in a single TLV. In that case, the Attribute TLV Type MUST have the appropriate Meta value (0x20-0x35) in order to carry its Value or Values. 4.3.1 Opaque Values An Opaque value is a sequence of octets that should not be parsed by a XBE32 entity but just being delivered to the upper layer. The Opaque values defined by XBE32 are: Type TLV Description ------ ------------------------ 0x2100 Single opaque Value 0x3000 Multiple opaque1 Values 0x3100 Multiple opaque2 Values 0x3200 Multiple opaque4 Values 0x3300 Multiple opaque8 Values 0x3400 Multiple opaque12 Values 0x3500 Multiple opaque16 Values Urue±a & Larrabeiti Expires September 15, 2004 [Page 13] Internet-Draft XBE32 Binary Encoding March 2004 4.3.2 String Value This TLV contains a single UTF-8 encoded String: Type TLV Description ------ ------------------- 0x2800 Single string Value 4.3.3 Boolean Values A boolean value is encoded inside an octet value. "False" is encoded as 0x00 while "True" is encoded as 0xFF. Other values than 0x00 or 0xFF MUST NOT appear as an encoded boolean value. Type TLV Description ------ ----------------------- 0x3002 Multiple boolean Values 4.3.4 Integer Values Signed integer values MUST be encoded as a two's complement binary number in network byte order (a.k.a. Big Endian, i.e., the most significant byte first). The integer values defined by XBE32 are: Type TLV Description ------ --------------------- 0x3001 Multiple int8 Values 0x3101 Multiple int16 Values 0x3201 Multiple int32 Values 0x3301 Multiple int64 Values 4.3.5 Float Values Float values MUST be encoded as specified in [2]. The floating point values defined by XBE32 are: Type TLV Description ------ ----------------------- 0x3202 Multiple float32 Values 0x3302 Multiple float64 Values Urue±a & Larrabeiti Expires September 15, 2004 [Page 14] Internet-Draft XBE32 Binary Encoding March 2004 5. Acknowledgements We would like to thank Miguel Fernandez by his valuable comments. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985. Authors' Addresses Manuel Urue±a Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 87 95 EMail: muruenya@it.uc3m.es David Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 99 53 EMail: dlarra@it.uc3m.es Urue±a & Larrabeiti Expires September 15, 2004 [Page 15] Internet-Draft XBE32 Binary Encoding March 2004 Appendix A. XBE32 Examples 123456789 AUTH_ERROR Invalid Password en 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x08F1 (error) | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x3283 (code) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x07 | 0x5B | 0xCD | 0x15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x2861 (name) | Length = 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'A' | 'U' | 'T' | 'H' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | '-' | 'E' | 'R' | 'R' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'O' | 'R' | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0610 (desc) | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x2863 (text) | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'I' | 'n' | 'v' | 'a' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'l' | 'i' | 'd' | ' ' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'P' | 'a' | 's' | 's' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'w' | 'o' | 'r' | 'd' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x2864 (lang) | Length = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'e' | 'n' | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0000 (End-of-data) | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Urue±a & Larrabeiti Expires September 15, 2004 [Page 16] Internet-Draft XBE32 Binary Encoding March 2004 Alice, Bob 2e2312c1-4f8d-431d-ac6e-500880b42e2c, 0399eac8-69ac-4ee6-95df-9f72d128f33a 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x2001 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | 0x00 | 0x28 | 0x03 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x2800 | Length = 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'A' | 'l' | 'i' | 'c' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'e' | 0x00 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x2800 | Length = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'B' | 'o' | 'b' | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 | Length = 48 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x2000 | Length = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'i' | 'd' | 's' | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x3500 | Length = 36 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x2E | 0x23 | 0x12 | 0xC1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x4F | 0x8D | 0x43 | 0x1D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xAC | 0x6E | 0x50 | 0x08 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x80 | 0xB4 | 0x2E | 0x2C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 | 0x99 | 0xEA | 0xC8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x69 | 0xAC | 0x4E | 0xE6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x95 | 0xDF | 0x9F | 0x72 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xD1 | 0x28 | 0xF3 | 0x3A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Urue±a & Larrabeiti Expires September 15, 2004 [Page 17] Internet-Draft XBE32 Binary Encoding March 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Urue±a & Larrabeiti Expires September 15, 2004 [Page 18] Internet-Draft XBE32 Binary Encoding March 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urue±a & Larrabeiti Expires September 15, 2004 [Page 19]