Network Working Group M. Urue盿
Internet-Draft D. Larrabeiti
Expires: September 15, 2004 UC3M
March 17, 2004

eXtensible Service Location Protocol (XSLP)
<draft-uruena-xslp-00.txt>

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.

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盿 & 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盿 & 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盿 & 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盿 & 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盿 & 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盿 & 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盿 & 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盿 & 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盿 & 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盿 & 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 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盿 & 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盿 & 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盿 & 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盿 & 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盿 & 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盿 & 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盿 & 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盿 & 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盿, M. and D. Larrabeiti, "eXtensible Binary Encoding
(XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004.

[4] Urue盿, M. and D. Larrabeiti, "Overview of the eXtensible
Service Discovery Framework (XSDF)",
draft-uruena-xsdf-overview-00 (work in progress), March 2004.

[5] Urue盿, 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盿, M. and D. Larrabeiti, "eXtensible Service Registration
Protocol (XSRP)", draft-uruena-xsrp-00 (work in progress), March
2004.

[7] Urue盿, M. and D. Larrabeiti, "eXtensible Service Subscription
Protocol (XSSP)", draft-uruena-xssp-00 (work in progress), March
2004.

Authors' Addresses

Manuel Urue盿
Universidad Carlos III de Madrid
Av. Universidad 30
Legan塻, Madrid 28911
ES

Phone: +34 91 624 87 95
EMail: muruenya@it.uc3m.es

Urue盿 & Larrabeiti Expires September 15, 2004 [Page 19]

Internet-Draft XSLP Protocol March 2004

David Larrabeiti
Universidad Carlos III de Madrid
Av. Universidad 30
Legan塻, 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盿 & 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

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盿 & 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盿 & Larrabeiti Expires September 15, 2004 [Page 22]