Network Working Group M. Urueħa Internet-Draft D. Larrabeiti Expires: September 15, 2004 UC3M March 17, 2004 eXtensible Service Location Protocol (XSLP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document specifies the eXtensible Service Location Protocol (XSLP), a lightweight protocol that allows User Agents to obtain Service information from Directory Agents, even from remote domains. Also, XSLP allows User Agents to perform multicast queries to the Service Agents inside the same organization. XSLP is the main protocol of the eXtensible Service Discovery Framework (XSDF). Urueħa & Larrabeiti Expires September 15, 2004 [Page 1] Internet-Draft XSLP Protocol March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Notation Conventions . . . . . . . . . . . . . . . . . . . 4 2. Messages Format . . . . . . . . . . . . . . . . . . . . . . 5 2.1 XSLPv1 Element . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Service Request Element . . . . . . . . . . . . . . . . . 5 2.2.1 Services Target Element . . . . . . . . . . . . . . . 6 2.2.2 Return Element . . . . . . . . . . . . . . . . . . . . 7 2.3 Service Reply Element . . . . . . . . . . . . . . . . . . 7 2.4 Service Advertisement Element . . . . . . . . . . . . . . 8 2.5 Realm Request Element . . . . . . . . . . . . . . . . . . 8 2.5.1 Realm Filter Element . . . . . . . . . . . . . . . . . 9 2.6 Realm Reply Element . . . . . . . . . . . . . . . . . . . 9 2.7 Service Type Request Element . . . . . . . . . . . . . . . 10 2.7.1 Service Types Filter Element . . . . . . . . . . . . . 10 2.8 Service Type Reply Element . . . . . . . . . . . . . . . . 10 2.9 Redirect Element . . . . . . . . . . . . . . . . . . . . . 11 2.10 Common Operation Parameters . . . . . . . . . . . . . . 11 2.10.1 Record Element . . . . . . . . . . . . . . . . . . . 12 3. XSLP Operation Procedures . . . . . . . . . . . . . . . . . 13 3.1 Service Request . . . . . . . . . . . . . . . . . . . . . 14 3.2 Service Advertisement . . . . . . . . . . . . . . . . . . 15 3.3 Realm Request . . . . . . . . . . . . . . . . . . . . . . 16 3.4 Service Type Request . . . . . . . . . . . . . . . . . . . 16 3.5 Redirect Reply . . . . . . . . . . . . . . . . . . . . . . 17 3.6 Remote Domains . . . . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 A. XSLP Constants . . . . . . . . . . . . . . . . . . . . . . . 20 A.1 XBE32 Elements . . . . . . . . . . . . . . . . . . . . . . 20 A.2 Time Constants . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 21 Urueħa & Larrabeiti Expires September 15, 2004 [Page 2] Internet-Draft XSLP Protocol March 2004 1. Introduction XSDF [4] is a framework for Service Discovery. It allows Users to dynamically find available network Services and choose the better ones following certain selection policies. In XSDF, User Agents (UAs) may issue multicast Service requests directly to Service Agents (SAs). In bigger networks, UAs request Service information to a central repository managed by the so-called Directory Agents (DAs). XSLP is the protocol employed by UAs to obtain Service information from SAs and/or DAs. Such information contains the location of the Service, the expected validity time and some selection data to choose the best Service instance, if multiple ones have been discovered. This mechanism allows end hosts, with little or no configuration, to dynamically find the best available network Services. In networks where no DAs have been deployed, as unmanaged LANs, UAs directly query SAs for Services. Such XSLP request messages are sent to SAs in multicast (or broadcast if multicast is not available). SAs with Services that match with such request return these Services to the UA in unicast replies. Multicast XSLP Request +----+ +----+ ----------------------> +----+| | UA | | SA |+ +----+ <---------------------- +----+ Unicast XSLP Replies As multicast requests have scalability issues, larger networks will deploy one or more DAs. Those DAs centralize all Service information from one or more Scopes of a Domain. SAs register the Services from those Scopes at any of these DAs employing XSRP. Then, XSLP messages can be directly issued in unicast to any of these DAs. Unicast XSLP Request +----+ --------------------> +----+ | UA | | DA | +----+ <-------------------- +----+ Unicast XSLP Reply Of course, UAs first need to find the appropriate DAs. As DAs are Services by themselves, when they have no DAs configured, they can bootstrap by querying for DA agents in multicast as if they were any other Service. Once one or more DAs serving a Scope are discovered, all location requests/registrations for Services at those Scopes should be issued in unicast to any of those DAs. As each Scope should be treated as a different environment, both Urueħa & Larrabeiti Expires September 15, 2004 [Page 3] Internet-Draft XSLP Protocol March 2004 modes of operation may coexist in a single network. If DAs are deployed, but they do not manage all the Scopes at the Domain, an UA may issue both, unicast requests to DAs, and multicast requests to SAs from unmanaged Scopes. 1.1 Definitions Domain: A Domain is a single administrative organization containing Users and Services. Scope: A Scope is a subset of Users and Services from a Domain, typically making a logical administrative group. Realm: A Realm is a combination of a Domain and one or more Scopes from such Domain, if any. Service: A Service is any process attached to a network that provides some kind of functionality to Users or other Services. A Service belongs to a single Realm. User Agent (UA): A process working on the User's (or other process) behalf to discover Services, and select the best available one. UAs obtain Service information from Directory Agents and Service Agents via XSLP. Service Agent (SA): A Service Agent is itself a Service that advertise Service information on behalf other processes. SAs are queried by User Agents for Services via XSLP, and/or register Service information in Directory Agents employing XSRP. Directory Agent (DA): A Directory Agent is a Service that, when deployed, acts as a central repository of all Service information from a Realm. Service Agents register its Services in a DA employing the XSRP protocol. Then, User Agents are able to query that information with XSLP. An Scope can be served by multiple DAs that coordinate themselves via XSSP & XSTP protocols. XSDF Agent: Any process that employs any XSDF protocol to interact with other XSDF Agents. All XSDF Agents must implement the XSLP protocol. UAs behave as clients while SAs and DAs are servers. 1.2 Notation Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [1]. Urueħa & Larrabeiti Expires September 15, 2004 [Page 4] Internet-Draft XSLP Protocol March 2004 2. Messages Format This section defines the format of all XSLP messages. These messages are exchanged between an User Agent and, a Directory Agent or several Service Agents. XSDF protocol messages are encoded employing XBE32 [3]. Definitions for common XSDF Elements and Attributes can be found at [5] 2.1 XSLPv1 Element All XSDF messages have a common format: a single XBE32 Element containing a Header, and one or more protocol Operations. XSLP messages are encoded inside a XSLPv1 Element. XSLPv1 Element: Element Name : xslpv1 XBE32 Type : 0x0901 +---------------------------------------------------------------+ : Header Element : +---------------------------------------------------------------+ : XSLP Operation Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : XSLP Operation Element #N : +---------------------------------------------------------------+ : [ Signature Information Element ] : +---------------------------------------------------------------+ Header and Signature Information Elements are defined in [5]. Next subsections describe XSLP Operation Elements. 2.2 Service Request Element UAs send this operation request to DAs or SAs in order to obtain the specified Service information from their common Realm. Urueħa & Larrabeiti Expires September 15, 2004 [Page 5] Internet-Draft XSLP Protocol March 2004 Service Request Element: Element Name : serviceRequest XBE32 Type : 0x0930 +---------------------------------------------------------------+ : Services Target Element : +---------------------------------------------------------------+ : [ Services Filter Element ] : +---------------------------------------------------------------+ : Return Element : +---------------------------------------------------------------+ Services Filter Element is defined in [5]. All Services specified by the Target but the ones with Ids listed in the Filter Element SHOULD be included in the reply operation. The Return Element defines which information Elements SHOULD be returned in such reply. 2.2.1 Services Target Element UA specifies in this Element the Type of the Service it is interested in, for example "printer". It MAY also specify the exact Id of the requested Services, but in any case the Service Type MUST be included. Target Element: Element Name : target XBE32 Type : 0x0821 +---------------------------------------------------------------+ : Service Type Element : +---------------------------------------------------------------+ | [ Service Ids ] | +---------------------------------------------------------------+ Service Ids Attribute and Service Type Element are defined in [5]. All Service Request operations MUST contain the Type of the Services being requested. If the Type Element contains any Path Element, the returned elements MUST provide the requested resources. That is, their Path Elements MUST fully contain, at least, one of the requested Paths ("/" includes "/store/index.html". Although "/s" does not include "/store/index.html", but "/s/all"). If no Path attribute is included, all elements SHOULD be returned, no matter which resources they are providing. When included, the Service Ids Attribute indicates which Services Urueħa & Larrabeiti Expires September 15, 2004 [Page 6] Internet-Draft XSLP Protocol March 2004 should be returned. XSDF Server Agent SHOULD NOT return information about other Services but the ones listed here. When the list does contain unknown Services, those Ids SHOULD be silently skipped. 2.2.2 Return Element In this Element, UA indicates which information of the selected Services should be returned. An empty "return" Element will generate a reply containing just the Service Ids found. If a "serviceState" Element is specified, Services will carry the Element information of the same name, and so on. Return Element: Element Name : return XBE32 Type : 0x0841 +---------------------------------------------------------------+ | [ Service State ] | +---------------------------------------------------------------+ | [ Service Main Information ] | +---------------------------------------------------------------+ | [ Service Location Information ] | +---------------------------------------------------------------+ | [ Service Additional Information ] | +---------------------------------------------------------------+ When "return" Element contains the Service State empty Element, Services in the reply MUST contain their Service State Elements. When "return" Element contains the Service Main Information empty Element, Services in the reply MUST contain their Service Main Information Elements. When "return" Element contains the Service Location Information empty Element, Services in the reply MUST contain their Service Location Information Elements. When "return" Element contains the Service Additional Information empty Element, Services in the reply MUST contain their Service Additional Information Elements. 2.3 Service Reply Element This reply operation is sent back to the UA as a response to a previous "serviceRequest" operation. It contains all the selected Service information and its validity time. Urueħa & Larrabeiti Expires September 15, 2004 [Page 7] Internet-Draft XSLP Protocol March 2004 Service Reply Element: Element Name : serviceReply XBE32 Type : 0x0941 +---------------------------------------------------------------+ : [ Record Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Record Element #N ] : +---------------------------------------------------------------+ Record Element is defined in Section 2.10.1. Each Record Element contains information about a single Service that matches with a previous "serviceRequest". If no Service Records are included, source XSDF Agent does not known any Service that matches. However, empty "serviceReply" operations MUST NOT be sent as a response to multicast queries. 2.4 Service Advertisement Element Service Advertisements MAY be sent by DAs and SAs containing Service information they known. In the so-called Passive DA Discovery process, DAs send multicast messages to all XSDF Agents from the same Realm to advertise its own Service information. Also, Service Advertisements MAY be employed by XSSP [7] as a notification mechanism. Service Advertisement Element: Element Name : serviceAdvert XBE32 Type : 0x0921 +---------------------------------------------------------------+ : Record Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : Record Element #N : +---------------------------------------------------------------+ Record Element is defined in Section 2.10.1. Service Elements inside Record Elements MUST include Service Id, Main and Location Elements. Other Service information is optional and SHOULD NOT appear. 2.5 Realm Request Element This Element defines an optional operation. It requests the Realm of the destination XSDF Agent. Urueħa & Larrabeiti Expires September 15, 2004 [Page 8] Internet-Draft XSLP Protocol March 2004 Realm Request Element: Element Name : realmRequest XBE32 Type : 0xC940 +---------------------------------------------------------------+ : [ Realm Filter Element ] : +---------------------------------------------------------------+ 2.5.1 Realm Filter Element When this optional Element is included, the "realmReply" response SHOULD NOT include the Scopes listed in this field. Realm Filter Element: Element Name : filter XBE32 Type : 0x0841 +---------------------------------------------------------------+ : Realm Element : +---------------------------------------------------------------+ Realm Element is defined in [5]. This Element contains a sorted list of Scopes that SHOULD NOT be included in the "realmReply" response. List MUST be sorted in order to ease Scope search. 2.6 Realm Reply Element This reply operation is sent back to the UA as a response to a previous "realmRequest" operation. It contains the full Realm of the source XSDF Agent but the filtered Scopes. Realm Reply Element: Element Name : realmReply XBE32 Type : 0xC941 +---------------------------------------------------------------+ : Realm Element : +---------------------------------------------------------------+ Realm Element is defined in [5]. Returned Realm Element MUST contain the Realm, source XSDF Agent belongs to. Scopes included in the request Filter parameter SHOULD NOT be included. Urueħa & Larrabeiti Expires September 15, 2004 [Page 9] Internet-Draft XSLP Protocol March 2004 2.7 Service Type Request Element This Element defines an optional operation. It requests the list of Service Types, of all the Services known by the destination XSDF agent. Service Type Request Element: Element Name : serviceTypeRequest XBE32 Type : 0xC950 +---------------------------------------------------------------+ : Realm Target Element : +---------------------------------------------------------------+ : [ Service Types Filter Element ] : +---------------------------------------------------------------+ Realm Target Element is defined in [5]. The Realm Target Element MAY contain the subset of Header's Realm Scopes to request Service Types from. If Realm Target is empty, Service Types, from all the Scopes specified in message Header, are requested. 2.7.1 Service Types Filter Element When this Element is included, the reply "serviceTypeReply" message SHOULD NOT include the Service Types listed in this field. Service Types Filter Element: Element Name : filter XBE32 Type : 0x0841 +---------------------------------------------------------------+ : [ Service Type Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Service Type Element #N ] : +---------------------------------------------------------------+ Service Type Element is defined in [5]. This Element contains a sorted list of Service Types that SHOULD NOT be included in the "serviceTypeReply" response. List MUST be sorted by the Type Attribute in order to ease Service Type search. 2.8 Service Type Reply Element This reply operation is sent back to the UA as a response to a previous "serviceTypeRequest" operation. It contains the list of all Urueħa & Larrabeiti Expires September 15, 2004 [Page 10] Internet-Draft XSLP Protocol March 2004 the Service Types from specified Scopes. Service Type Reply Element: Element Name : serviceTypeReply XBE32 Type : 0xC951 +---------------------------------------------------------------+ : [ Service Type Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Service Type Element #N ] : +---------------------------------------------------------------+ Service Type Element is defined in [5]. Returned Service Type Elements contains information about non-filtered Service Types from specified Scopes. If no Service Types are included, no Services are registered at specified Scopes or all Service Types have been filtered. However, empty "serviceTypeReply" operations MUST NOT be sent as a response to multicast queries. 2.9 Redirect Element This reply operation indicates UA that it SHOULD resent the request to the specified XSDF Agents from the same Realm. Redirect Element: Element Name : redirect XBE32 Type : 0x0911 +---------------------------------------------------------------+ : Service Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : Service Element #N : +---------------------------------------------------------------+ Service Element is defined in [5]. As the UA receiving this response SHOULD forward its XSLP request to the specified Services, all the listed Services MUST refer to XSDF DA or SA agents. Each Service Element MUST contain Service Id, Main and Location Elements. Other Service information is optional and SHOULD NOT appear. 2.10 Common Operation Parameters When an UA requests Service information, SAs and DAs return such information inside a Record Element, that also contains for how long this data is expected to remain valid. This section describes in Urueħa & Larrabeiti Expires September 15, 2004 [Page 11] Internet-Draft XSLP Protocol March 2004 detail the "record" Element. 2.10.1 Record Element This is the main parameter of the "serviceReply" and "serviceAdvert" operations. It contains the advertised Service or the information requested by an UA. Record Element: Element Name : record XBE32 Type : 0x0200 +---------------------------------------------------------------+ : Service Element : +---------------------------------------------------------------+ : Record State Element : +---------------------------------------------------------------+ Service Element is defined in [5]. 2.10.1.1 Record State Element This Element contains meta-information about the associated Service carried inside the Record Element. Record State Element: Element Name : recordState XBE32 Type : 0x0210 +---------------------------------------------------------------+ : Cache State Element : +---------------------------------------------------------------+ Cache State Element is defined in [5]. Cache State Element contains two Attributes about the associated Service, its Age and the remaining TTL. UA SHOULD flush the Service information from its cache when its TTL value is zero. Urueħa & Larrabeiti Expires September 15, 2004 [Page 12] Internet-Draft XSLP Protocol March 2004 3. XSLP Operation Procedures All XSDF Agents MUST follow the common procedures for XSDF Agent initialization, message generation, transmission and processing defined in [5]. This section specifies additional procedures for the XSLP protocol. XSLP is a Client-Server protocol. UAs act as Clients sending operation requests while SAs and DAs act as Servers processing those requests and sending replies back. All XSLP Agents MUST support the UDP transport protocol and MAY also support TCP and SCTP. The port number for all these transport protocols MUST be 727. When a Scope is managed by one or more active DAs, UAs MUST employ unicast transmission to obtain Services from the DAs that manage that Scope. In that case, the UA SHOULD choose the better DA (that supports the "xslp" protocol) as advertised by their Service information. Once a XSLP message with the appropriate operations has been generated, it is sent to the selected DA. If message can not be delivered, next DA from the same Realm SHOULD be chosen. If there are no DAs left, Scope is marked as "unmanaged" and search process MAY follow as defined below. In unmanaged Scopes from local Domain, UAs SHOULD employ multicast XSLP messages in order to reach all the SAs of those Scopes as defined in [5]. However, if a new DA managing a previously unmanaged Scope is discovered, the Scope becomes "managed" and UAs MUST employ unicast XSLP messages as defined above. Service Types have associated IPv6 multicast groups. Thus, multicast queries by Service Type MUST be sent to those groups. For XSLP operations that have no associated Service Type, the IPv6 multicast group derived from the "xsdf:sa" Service Type (FE0X:0:0:0:0:0:1:1216) SHOULD be employed in order to reach all the SAs at unmanaged Scopes. When in an "unmanaged" Scope, SAs MUST reply to multicast queries with unicast messages. However, if the reply operation is empty, SAs MUST NOT respond, exactly the same as if an error has occurred. This rule only applies to multicast queries, for unicast ones, SAs MUST return the empty reply operation. An UA MAY belong to multiple Scopes, some could be managed by DAs while others remain unmanaged. Thus, UAs SHOULD be able to perform both kinds of searches, unicast messages to a single DA and multicast messages to several SAs. While DA MUST support unicast queries, SAs SHOULD support both, unicast and multicast queries from UAs. Urueħa & Larrabeiti Expires September 15, 2004 [Page 13] Internet-Draft XSLP Protocol March 2004 As"LOCAL" Scope only contains Services related to the local Server, it has its own rules. Multicast queries MUST NOT refer to the "LOCAL" scope. Also, "LOCAL" Services SHOULD NOT be included in Service advertisements. In order to obtain Service information from this Scope, an UA MUST employ just unicast messages targeted to the particular XSDF Agent. Service information can be obtained from several Sources and mechanisms, thus multiple versions MAY be returned. However, as Service information SHOULD be the same across all its Scopes, all version MUST be considered as a Single Service where newer information replaces older one. 3.1 Service Request The so-called Active Service Discovery mechanism, allows an UA to obtain information about Services at a specified Realm. UAs will send "serviceRequest" operations, while DAs or SAs will respond with "serviceReply" carrying the matching Services they known. Refer to Section 2.2 and Section 2.3 for a detailed description of "serviceRequest" and "serviceReply" operations. When a SA or a DA receives a valid XSLP message with an authorized "serviceRequest" operation, it MUST follow these steps to process such operation: 1. Obtain the list of Scopes to query Services from the message's Header. 2. Obtain all the Services with the specified Type that belong to the above Scope list. If Service Type Element contains some Path Elements, Services not providing any of the specified resources SHOULD be dropped. 3. If the Target parameter specifies the Ids of the requested Services, XSDF Agent SHOULD find those Services and check that they belong to the specified Realms and have the specified Service Type. 4. If the request operation contains a Filter parameter, specified Services SHOULD be removed from the reply. 5. Once the list of Services that match has been obtained, reply operation MUST generate a Record Element for each one. LAST_UPDATE_TIMESTAMP associated to the Service registration MUST be employed to calculate the Age of the record (by subtracting it from current time). Remaining TTL is calculated as the associated SERVICE_LIFETIME variable minus its Age. Both registration Urueħa & Larrabeiti Expires September 15, 2004 [Page 14] Internet-Draft XSLP Protocol March 2004 variables are defined in [6]. 6. Record's Service Element MUST include the Service Identifier, other information is optional and SHOULD appear if listed in the Return parameter of the "serviceRequest" operation. If specified Service Type has an associated Selection Policy, DA MAY sort/filter returned Services according to that policy. Therefore, if UAs does not have additional Service information they SHOULD try to access the discovered Services in the specified order. A XSDF Agent MAY employ XSLP itself in its initialization phase to discover DAs from a Realm. As the UA does not know any DA from the Realm, all the Scopes are considered to be "unmanaged" and "serviceRequest" operation MUST be sent in a multicast message. In that case, the Service Type to be included in the request MUST be "xsdf:da". XSDF Agents MUST wait for some time, distributed between 0 and INIT_FIND_DELAY, before trying to obtain DA Service information via this mechanism. Also, XSDF Agents MAY employ this mechanism periodically in order to discover new DAs from unmanaged Scopes. Consecutive queries MUST be spaced at least by a RETRY_FIND_DELAY interval. 3.2 Service Advertisement UAs MAY also obtain Service information by the Passive Service Discovery mechanism. In this process UAs do not request Services but DAs and SAs do sent multicast messages advertising Service information inside "serviceAdvert" Elements. Refer to Section 2.4 for a detailed description of the "serviceAdvert" operation. Directory Agents MUST periodically advertise its own Service information inside Service Advertisement messages. Those DA Advertisement messages MUST be sent to the "All XSDF Agents" multicast group as defined in [5]. Consecutive advertisements MUST be spaced at least by a DA_ADVERT_DELAY interval. SAs MAY also employ this mechanism to advertise Services in unmanaged Scopes. However, a SA MUST NOT advertise any Service belonging to a Realm fully managed by one or more active DAs. Service Advertisement messages MAY be also employed to notify modification Events. See XSSP [7] for a complete description of this mechanism. As described in [7], a service becoming unavailable MAY be advertised within a Service Advertisement message with a zero TTL. Directory Agents SHOULD notify that are to become unavailable with this Urueħa & Larrabeiti Expires September 15, 2004 [Page 15] Internet-Draft XSLP Protocol March 2004 mechanism. They MAY advertise also the service information of other alternative DAs, thus UAs and SAs may be able to migrate their XSDF operations to them without disruption. 3.3 Realm Request XSDF Agents that support this kind of transaction may be queried in order to obtain the Realm they belong to. In that case, UAs send "realmRequest" operations. XSDF Agents respond with "realmReply" operations containing their Realms. Refer to Section 2.5 and Section 2.6 for a detailed description of "realmRequest" and "realmReply" operations. When a DA or SA receives a valid XSLP message with an authorized "realmRequest" operation, it MAY generate a "realmReply" response if it supports such operation, or reject it as unsupported (UNKNOWN_XBE32_ELEMENT). Response MUST contain the XSDF Agent's Realm but the Scopes listed in the Filter parameter, if present. In order that UAs and SAs know if a DA supports this operation, the DA MAY advertise the "RealmReply" XBE32 Type (0xC941) in the Capability Attribute of the "xslp" Protocol Element [5]. UAs and SAs MAY employ this operation in the initialization phase in order to obtain the Realm they belong to. In that case, they MAY collect the Realms of pre-configured DAs. Its Realm will be generated as the common Domain, and all the discovered Scopes. 3.4 Service Type Request When XSDF Agents support these optional operations, an UA is able to obtain all the Service Types from a Realm. UAs send "serviceTypeRequest" operations while DAs and SAs answer with "serviceTypeReply" operations. Refer to Section 2.7 and Section 2.8 for a detailed description of "serviceTypeRequest" and "serviceTypeReply" operations. When a SA or a DA receives a valid XSLP message with an authorized "realmRequest" operation, it MAY generate a "serviceTypeReply" response if it supports such operation or reject it as unsupported (UNKNOWN_XBE32_ELEMENT). Response MUST contain the list of all the known Service Types from specified Realm, but the ones listed in the Filter parameter, if present. In order that UAs and SAs know if a DA supports this operation, the DA MAY advertise the "ServiceTypeReply" XBE32 Type (0xC951) in the Capability Attribute of the "xslp" Protocol Element [5]. Urueħa & Larrabeiti Expires September 15, 2004 [Page 16] Internet-Draft XSLP Protocol March 2004 3.5 Redirect Reply A XSDF Agent MAY reply to a XSLP request message with a "redirect" operation. In that case, it has not processed any of the requested operations but indicates that the specified XSDF Agents are better suited to perform such request. Refer to Section 2.9 for a detailed description of the "redirect" operation. When an UA receives a valid "redirect" operation as a response for a request message, it SHOULD generate a new request message with the same operations as the previous one. That message SHOULD be sent to the XSDF Agents included in the "redirect" operation. If Selection information is included, best one SHOULD be chosen. Otherwise, first one SHOULD be selected. If message can not be delivered, next DA SHOULD be chosen until message gets delivered or there are no XSDF Agents left. 3.6 Remote Domains Previous sections refer only to XSLP operations in the local domain. However, XSLP allows Service Discovery in both, remote and local sites. Therefore, when an UA is requested to obtain some Service information form a Realm, it MUST compare the specified Realm's Domain with its own, if any. If both Domains match, Local Service Discovery is requested and the above rules apply. If Domains do not match, a Remote Service Discovery procedure is required. This procedure is exactly the same as the local one when DAs are deployed, but the mechanism to locate the DAs of the remote Domain. Multicast requests MUST NOT be employed to locate DAs from non-local Domains. Instead of pre-configured DAs or multicast queries as in the local case, remote DAs could be located by querying the DNS. DAs managing the Services from the "PUBLIC" Scope MAY be advertised in DNS SRV Resource Records [2] of the remote DNS Domain. Those Resource Records MUST have the following name: "_xslp._udp." plus the remote Domain name. For example, DAs managing "PUBLIC" Services from "example.com" Domain could be located by obtaining the "_xslp._udp.example.com" DNS SRV RR. Once the public DAs from remote Domain have been discovered (including its weight value), UAs SHOULD follow the same procedures already defined to query local DAs. Urueħa & Larrabeiti Expires September 15, 2004 [Page 17] Internet-Draft XSLP Protocol March 2004 4. Security Considerations XSDF Service Discovery Framework relies on security procedures provided by lower layers, as TLS or IPSec ones. However, it defines some authentication mechanisms that SHOULD be employed when similar ones are not being provided by the layers below. See [5] for a detailed description of these mechanisms. XSLP over TLS is named "xslp/tls" and its default port number for the TCP and SCTP transport protocols is 728. In insecure environments, XSDF Agents receiving Service Advertisement messages or "redirect" operations SHOULD carefully check if they came from a trusted XSDF Agent. In order to provide message authentication and integrity, SAs and DAs SHOULD append a Signature Element to messages containing Service Advertisements and Redirect Replies. 5. Acknowledgements XSLP protocol was designed as an evolution of the SLPv2 one and its extensions. It also also includes many ideas borrowed from Rserpool's ASAP. Therefore, we wish to thank the authors of both specifications, as well as Weibin Zhao, Henning Schulzrinne, Erik Guttman, Chatschik Bisdikan and William F. Jerome. They are the authors of the SLP Remote Discovery draft, which is the foundation of the Remote Domains section of this document. Urueħa & Larrabeiti Expires September 15, 2004 [Page 18] Internet-Draft XSLP Protocol March 2004 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [3] Urueħa, M. and D. Larrabeiti, "eXtensible Binary Encoding (XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004. [4] Urueħa, M. and D. Larrabeiti, "Overview of the eXtensible Service Discovery Framework (XSDF)", draft-uruena-xsdf-overview-00 (work in progress), March 2004. [5] Urueħa, M. and D. Larrabeiti, "eXtensible Service Discovery Framework (XSDF): Common Elements and Procedures", draft-uruena-xsdf-common-00 (work in progress), March 2004. [6] Urueħa, M. and D. Larrabeiti, "eXtensible Service Registration Protocol (XSRP)", draft-uruena-xsrp-00 (work in progress), March 2004. [7] Urueħa, M. and D. Larrabeiti, "eXtensible Service Subscription Protocol (XSSP)", draft-uruena-xssp-00 (work in progress), March 2004. Authors' Addresses Manuel Urueħa Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 87 95 EMail: muruenya@it.uc3m.es Urueħa & Larrabeiti Expires September 15, 2004 [Page 19] Internet-Draft XSLP Protocol March 2004 David Larrabeiti Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 99 53 EMail: dlarra@it.uc3m.es Appendix A. XSLP Constants A.1 XBE32 Elements Element Name XBE32 Type ------------ ---------- xslpv1 0x0901 redirect 0x0911 serviceAdvert 0x0921 serviceRequest 0x0930 serviceReply 0x0931 realmRequest 0xC940 realmReply 0xC941 serviceTypeRequest 0xC950 serviceTypeReply 0xC951 filter 0x0841 return 0x0851 record 0x0200 recordState 0x0210 A.2 Time Constants Constant name Default Value Description ------------------ ------------- ----------------------------------- INIT_FIND_DELAY 5 seconds Max delay before obtaining Realm or DAs info via XSLP RETRY_FIND_DELAY 1 hour Min delay before repeating XSLP DA Discovery DA_ADVERT_DELAY 30 minutes Min delay between DA Advertisements Urueħa & Larrabeiti Expires September 15, 2004 [Page 20] Internet-Draft XSLP Protocol March 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Urueħa & Larrabeiti Expires September 15, 2004 [Page 21] Internet-Draft XSLP Protocol March 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urueħa & Larrabeiti Expires September 15, 2004 [Page 22]