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]