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]