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]