Internet DRAFT - draft-silverajan-slpmip6
draft-silverajan-slpmip6
Network Working Group B. Silverajan
Internet-Draft Tampere University of Technology
Expires: November 3, 2006 May 2, 2006
Service Location Protocol Extensions for Mobile IPv6
draft-silverajan-slpmip6-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 November 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies extensions to the Service Location Protocol
verson 2 (SLPv2) which allow applications residing in Mobile IPv6
nodes to interact with SLPv2 agents in fixed networks. Each mobile
node contains a Visiting Agent which communicates with Access Agents
residing in fixed networks. In networks already deployed with SLPv2-
based service infrastructure, this allows applications in visiting
mobile nodes to use SLPv2 and provide site-local services without
needing prior knowledge or static configuration of the networks they
visit. By monitoring changes in Access Agent Advertisements,
Silverajan Expires November 3, 2006 [Page 1]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
Visiting Agents can decide if the mobile node has moved to a new
network, and if it is necessary to rediscover and reregister site-
local services. This document extends SLPv2 and the SLP API with new
message types, error codes and function calls. Both C and Java API
bindings are provided.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Principle of Operation . . . . . . . . . . . . . . . . . . . . 5
3. New SLP Messages . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Access Agent Advertisement . . . . . . . . . . . . . . . . 6
3.2. Address Request . . . . . . . . . . . . . . . . . . . . . 8
3.3. Address Reply . . . . . . . . . . . . . . . . . . . . . . 8
4. Protocol Timing Defaults . . . . . . . . . . . . . . . . . . . 9
5. AA Discovery Mechanisms . . . . . . . . . . . . . . . . . . . 9
5.1. Passive AA Discovery . . . . . . . . . . . . . . . . . . . 9
5.2. Active AA Discovery . . . . . . . . . . . . . . . . . . . 10
6. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. DA Discovery Mechanism . . . . . . . . . . . . . . . . . . . . 11
8. Extensions to Service Location API . . . . . . . . . . . . . . 11
8.1. C Language Binding . . . . . . . . . . . . . . . . . . . . 11
8.1.1. SLPAutoFindSrvs . . . . . . . . . . . . . . . . . . . 11
8.1.1.1. Synopsis . . . . . . . . . . . . . . . . . . . . . 11
8.1.1.2. Description . . . . . . . . . . . . . . . . . . . 12
8.1.1.3. Parameters . . . . . . . . . . . . . . . . . . . . 12
8.1.1.4. Returns . . . . . . . . . . . . . . . . . . . . . 13
8.1.2. SLPAutoFindAttrs . . . . . . . . . . . . . . . . . . . 13
8.1.2.1. Synopsis . . . . . . . . . . . . . . . . . . . . . 13
8.1.2.2. Description . . . . . . . . . . . . . . . . . . . 13
8.1.2.3. Parameters . . . . . . . . . . . . . . . . . . . . 14
8.1.2.4. Returns . . . . . . . . . . . . . . . . . . . . . 14
8.1.3. SLPAutoReg . . . . . . . . . . . . . . . . . . . . . . 14
8.1.3.1. Synopsis . . . . . . . . . . . . . . . . . . . . . 15
8.1.3.2. Description . . . . . . . . . . . . . . . . . . . 15
8.1.3.3. Parameters . . . . . . . . . . . . . . . . . . . . 15
8.1.3.4. Returns . . . . . . . . . . . . . . . . . . . . . 16
8.2. Java Language Binding . . . . . . . . . . . . . . . . . . 16
8.2.1. autoFindServices . . . . . . . . . . . . . . . . . . . 17
8.2.1.1. Synopsis . . . . . . . . . . . . . . . . . . . . . 17
8.2.1.2. Description . . . . . . . . . . . . . . . . . . . 17
8.2.2. autoFindAttributes . . . . . . . . . . . . . . . . . . 17
8.2.2.1. Synopsis . . . . . . . . . . . . . . . . . . . . . 17
8.2.2.2. Description . . . . . . . . . . . . . . . . . . . 17
8.2.3. autoRegister . . . . . . . . . . . . . . . . . . . . . 18
8.2.3.1. Synopsis . . . . . . . . . . . . . . . . . . . . . 18
8.2.3.2. Description . . . . . . . . . . . . . . . . . . . 18
Silverajan Expires November 3, 2006 [Page 2]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
9. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Using Site-local services . . . . . . . . . . . . . . . . 19
9.2. Providing Site-local services . . . . . . . . . . . . . . 20
10. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 21
11. Security considerations . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Silverajan Expires November 3, 2006 [Page 3]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
1. Introduction
This document presents a set of extensions for the use of the Service
Location Protocol version 2 (SLPv2) [1] in Mobile IPv6 [2]. It
extends the work done in [3], which modifies SLPv2 for use in IPv6.
SLPv2 is a flexible protocol which can be configured statically or
dynamically and provides a scalable solution ranging from small
unmanaged ad-hoc networks to large enterprise networks. The aim of
these extensions is to address important features that enable rapid
and successful service discovery in Mobile IPv6 environment. These
features include:
o support for movement detection
o location awareness when entering and leaving home and foreign
networks
o capabilities of locally and dynamically discovering and using the
visited network's capabilities for service discovery effectively
o reactive procedures such as automatic rediscovery and registration
of site-local services and service types.
This document offers a solution for SLPv2-aware applications in
mobile nodes to rediscover, use and offer site-local services
whenever the mobile node moves from one network space to another,
without the mobile node or its applications relying on aid or tunnels
from either the Mobile IPv6 home agent or SLPv2 agents residing in
the home network. By doing so, it enriches location-sensitive,
SLPv2-aware applications with a notion of movement awareness.
The proposed extensions introduce new SLPv2 agents, message types,
error codes and API function calls to the SLP API. No changes are
made in the role of existing SLPv2 agents or the protocol. This
preserves the design intent of not affecting the functionality and
definition of the existing SLPv2 infrastructure using the User Agent,
Service Agent and Directory Agent.
Two new agents are introduced: A Visiting Agent (VA), and an Access
Agent (AA). A Visiting Agent resides in the mobile node. An Access
Agent is a small lightweight agent residing in every IPv6 subnet that
the mobile node visits and serves as a beacon for incoming mobile
nodes containing VAs.
The two new agents are designed to interoperate transparently with
existing SLPv2 agents. From the perspective of an existing UA, SA or
DA in the network, the new agents will be regarded as normal UAs or
SAs. Similarly, if a Visiting Agent enters an IPv6 subnet that does
not have an Access Agent, it can directly communicate with a DA if
one resides in the subnet. Otherwise the VA uses link-local
Silverajan Expires November 3, 2006 [Page 4]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
multicast to communicate with other UAs and SAs that reside in the
subnet.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [4].
In format diagrams, any field ending with a \ indicates a variable
length field, given by a prior length field in the protocol.
2. Principle of Operation
Each mobile node is modelled with a Visiting Agent. Client and
server applications in the mobile node use and provide services in
the visited network using the Visiting Agent. Therefore, depending
on the context, the role of the Visiting Agent can be perceived as
either a User Agent, a Service Agent, or both.
Access Agents are used to model every visited network. In the real
sense, this means that each IPv6 subnet (including the home subnet)
that serves a mobile node SHOULD contain at least one node that
serves as an Access Agent.
Access Agents periodically send AA advertisements using link-local
multicast. When a mobile node enters into a new network, its
Visiting Agent listens for AA advertisements which contain
information about the network's existing Directory Agents, the
network's multicast capabilities, and the Access Agent's willingness
to proxy service requests and provide service replies on behalf of
the Visiting Agent.
Using the information gleaned from the AA Advertisement, a Visiting
Agent can then perform service discovery of site-wide services in one
of 3 ways:
o If a Directory Agent exists, it can be used by the Visiting Agent
to request for services in the foreign network (behaving like a
User Agent).
o If the foreign network allows the mobile node to perform multicast
operations directly as a local node with the foreign multicast
router, the Visiting Agent can search and offer services
dynamically (behaving like a local node in the foreign network)
o Using an Access Agent willing to serve as a request and
advertising proxy on behalf of Visiting Agents. This is
beneficial in cases where a Directory Agent is absent and if the
Mobile IPv6 implementation of the mobile node supports multicast
solely by virtue of bidirectionally tunneling multicast packets to
Silverajan Expires November 3, 2006 [Page 5]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
and from the home network. In this case, the Visiting Agent uses
unicast packets to communicate with the Access Agent. Unicast
service requests received from the Visiting Agent are multicast
using site-local scope by the Access Agent, and replies from the
network are returned to the Visiting Agent. Similarly, the Access
Agent accepts service registrations from the Visiting Agent and
advertises them in the fixed network on the Visiting Agent's
behalf.
Since Mobile IPv6 shields movement of the mobile node from
applications, the Visiting Agent can monitor changes in the source of
AA advertisements to see if its mobile node has moved to a new link.
Upon movement, the Visiting Agent can perform a series of steps to
rediscover and reprovision services of interest in the new network.
3. New SLP Messages
Three new messages are defined:
o Access Agent Advertisement
o Address Request
o Address Reply
Message Type Abbreviation Function-ID
------------ ------------ ----------
AA Advertisement AAAdvert 12
Address Request AddRqst 13
Address Reply AddRply 14
3.1. Access Agent Advertisement
AA advertisements extend section 8 in [1] with this information:
Silverajan Expires November 3, 2006 [Page 6]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AAAdvert = 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Known DA URL | Known DA URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|P|N|m|R| res | # auth blocks | authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The URL is "service:access-agent://<addr>" of the Access Agent, where
<addr> is the globally unique IPv6 address of the Access Agent.
If the Access Agent knows of the existence of at least one site-local
Directory Agent, it MUST piggy-back the location of the Directory
Agent in its advertisement.
The AAAdvert MAY include a list of attributes the Access Agent
supports. This attribute list SHOULD be kept short so that the
AAAdvert will not exceed the path MTU in size.
The 'M' flag denotes the network's multicast capability. The 'M'
flag is set to 1, if the foreign network is capable of supporting
multicasting by the mobile node as if it were a local node (i.e. the
local multicast router in the foreign subnet allows the mobile node
to join multicast groups natively). Otherwise it is set to 0.
The 'P' flag denotes the willingness of the Access Agent to serve as
a proxy for the Visiting Agent. If the Access Agent is willing to
serve as a proxy for incoming Visiting Agents, the 'P' flag is set to
1. Otherwise it is set to 0.
The 'N' flag denotes the current network's capability to support
Notification and Subscription for SLP, RFC 3082 [5]. If the 'N' flag
is set to 1, the SLP implementation in the foreign network is capable
of supporting RFC 3082. Otherwise it is set to 0.
The 'm' flag denotes the current network's capability to support
mSLP, RFC 3528 [6]. If the 'm' flag is set to 1, the SLP
implementation in the foreign network contains MDAs and MSAs.
Otherwise it is set to 0.
The 'R' flag denotes the current network's capability to support
Silverajan Expires November 3, 2006 [Page 7]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
Remote Service Discovery for SLP, RFC 3832 [7]. If the 'R' flag is
set to 1, the SLP implementation in the foreign network allows agents
to use DNS SRV Resource records to discover remote DAs in other
networks. Otherwise it is set to 0.
The next 3 bits are reserved and SHOULD be set to 0.
The AAAdvert contains one AAAdvert Authentication block for each SLP
SPI the Access Agent can produce Authentication Blocks for. If the
Visiting Agent possesses the ability to verify the Authentication
Block of the AAAdvert, and the AAAdvert fails verification, the
Visiting Agent MUST discard the AAAdvert.
3.2. Address Request
Address requests extend section 8 in [1] with this information:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AddRqst = 13) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address request messages contain only the Service Location header,
with the Function-ID set to 13. It is a unicast-only message,
designed to elicit a response from a communicating peer, to return
the IPv6 address from which the Address Request packet was sent. To
a certain extent, the AddRqst message allows a Visiting Agent to
query its own care-of address from an Access Agent. The AddRqst
message can also be used for diagnostic purposes.
3.3. Address Reply
Address replies extend section 8 in [1] with this information:
Silverajan Expires November 3, 2006 [Page 8]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AddRply = 14) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Peer Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An Address Reply is used to send a response to an Address Request
message. The Address Reply message contains the Service Location
Header with the Function-ID set to 14. The body of the message
contains the 128-bit IPv6 address of the peer from which the original
Address Request was received.
4. Protocol Timing Defaults
Interval name Section Default Value Meaning
------------------- ------- ------------- ------------------------
CONFIG_AA_BEAT 4.1 10 seconds AA Heartbeat, so that VAs
passively detect new AAs.
CONFIG_AA_FIND 4.2 30 seconds Minimum interval to wait
before repeating Active
AA discovery.
5. AA Discovery Mechanisms
Visiting Agents can discover Access Agents either through unsolicited
AAAdverts or through active AAAdvert solicitation. AAAdverts MUST be
sent using the IPv6 link-local multicast address FF02::1:1259. This
address is calculated as specified by section 4.1, SLPv2 Multicast
Group-IDs for IPv6 [3], for the "service:access-agent" service type.
Both the Visiting Agent and the Access Agent MUST join this multicast
address.
5.1. Passive AA Discovery
AAs MUST send unsolicited AAAdverts once per CONFIG_AA_BEAT.
Unsolicited AAAdverts have an XID of 0. VAs MUST listen for
Silverajan Expires November 3, 2006 [Page 9]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
AAAdverts passively, as shown.
+----------------+ +--------------+
| Visiting Agent | | Access Agent |
+----------------+ +--------------+
| |
| <-- Link-local Multicast AA Adv --- |
| |
5.2. Active AA Discovery
Active AA Discovery can be performed if the Visiting Agent stops
receiving AA Adverts after CONFIG_AA_FIND seconds, or is able to
ascertain its mobile node has moved. This could happen in two ways:
o The Visiting Agent receives movement notification information
through a separate network management application or the Visiting
Agent is explicitly prompted by a human user of the mobile node.
o The Visiting Agent receives "out-of-band" movement notification
information, through a low-level library capable of monitoring the
IP or data link layer.
To perform active AA Discovery, the VA uses link-local multicast to
send an SrvRqst with the service type set to "service:access-agent".
In response, the AA replies with a link-local multicast AAAdvert.
The XID value of the reply MAY correspond with the XID value of the
SrvRqst packet. Solicited AA Advertisements sent in response to any
SrvRqst packets SHOULD NOT be sent more than once per CONFIG_AA_FIND
seconds. If duplicate or unique SrvRqst packets arrive sooner than
this time, the AA SHOULD discard them.
+----------------+ +--------------+
| Visiting Agent | | Access Agent |
+----------------+ +--------------+
| |
| --Link-local Multicast SrvRqst---> |
| |
| <--Link-local Multicast AA Adv --- |
| |
| |
Silverajan Expires November 3, 2006 [Page 10]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
6. Error Codes
In addition to the error codes defined in section 7 of [1], the
following error codes are defined:
AA_BUSY_NOW 16: VA SHOULD retry, using exponential back off.
AA_NOT_PROXY 17: AA does not proxy requests or advertisements.
AA_USE_DA 18: Use DA instead of AA for requests and registrations.
AA_PEER_ADDRESS_MISMATCH 19: AA has received a Service Registration
Request from VA, containing a URL which does not match the
originating IP address.
AA_OP_UNSUPPORTED 20: AA does not support the requested operation.
7. DA Discovery Mechanism
In order to receive DAAdvert messages, an Access Agent MUST join the
SVRLOC-DA multicast group with at least site-local scope.
When a Visiting Agent moves into a foreign network that does not have
an Access Agent, it SHOULD join the SRVLOC_DA multicast group with
link-local scope.
8. Extensions to Service Location API
This section describes function calls that extend the API for Service
Location [8] to support automatic service rediscovery and
reregistrations.
8.1. C Language Binding
Bindings in C language are defined in this section, and the syntax
has been intentionally preserved to match the existing API. The
SLPError, SLPHandle, SLPSrvURLCallback, SLPAttrCallback and
SLPRegReport types are defined in [8].
8.1.1. SLPAutoFindSrvs
8.1.1.1. Synopsis
SLPError SLPAutoFindSrvs(SLPHandle hSLP,
const char *pcServiceType,
const char *pcScopeList,
const char *pcSearchFilter,
SLPSrvURLCallback callback,
void *pvCookie,
unsigned short findmode);
Silverajan Expires November 3, 2006 [Page 11]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
8.1.1.2. Description
Issue an auto-query upon movement for services on the language
specific SLPHandle, or forget a previous auto-query for services.
Results are returned through the callback.
When findmode is set to 1, the first query for services returns the
results through the callback, with exactly the same functionality as
SLPFindSrvs(), as defined by section 4.5.5 in [8]. Subsequently, the
callback is invoked each time the mobile node moves into a new
network space to return results for the requested service to be auto-
discovered.
When findmode is set to 0, the auto-discovery for the service is
disabled. In this case, the exact signature of the function provided
when first invoking SLPAutoFindSrvs (including the name of the
callback and the service type) MUST be given.
8.1.1.3. Parameters
hSLP
The language specific SLPHandle on which to search for
services.
pcServiceType
The Service Type String, including authority string if any, for
the requested service, such as can be discovered using
SLPFindSrvTypes(), described in section 4.5.4 of [8]. This
could be, for example "service:printer:lpr" or "service:nfs".
May not be the empty string.
pcScopeList
A pointer to a char containing comma separated list of scope
names. May not be the empty string, "".
pcSearchFilter
A query formulated of attribute pattern matching expressions in
the form of a LDAPv3 Search Filter, see [9]. If this filter is
empty, i.e. "", all services of the requested type in the
specified scopes are returned.
callback
A callback function through which the results of the operation
are reported.
pvCookie
Silverajan Expires November 3, 2006 [Page 12]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
Memory passed to the callback code from the client. May be
NULL.
findmode
Legal values are 1 and 0. When the value is 1, an auto-query
is initiated. when the value is 0, an autoquery previously
requested, matching the same signature, is cancelled.
8.1.1.4. Returns
If an error occurs in starting the operation, one of the SLPError
codes is returned.
8.1.2. SLPAutoFindAttrs
8.1.2.1. Synopsis
SLPError SLPAutoFindAttrs(SLPHandle hSLP,
const char *pcServiceType,
const char *pcScopeList,
const char *pcAttrIds,
SLPAttrCallback callback,
void *pvCookie,
unsigned short findmode);
8.1.2.2. Description
Issue an auto-query upon movement for returning service attributes
matching the attribute ids for the indicated service type, or forget
a previous auto-query for service attributes. Results are returned
through the callback.
The result is filtered with an SLP attribute request filter string
parameter, the syntax of which is described in [1]. If the filter
string is the empty string, i.e. "", all attributes are returned.
When findmode is set to 1, the first query for service attributes
returns the results through the callback, with exactly the same
functionality as SLPFindAttrs(), as defined by section 4.5.6 in [8].
Subsequently, the callback is invoked each time the mobile node moves
into a new network space to return results for the desired service
attributes to be auto-discovered.
When findmode is set to 0, the auto-discovery is disabled. In this
case, the exact signature of the function provided when first
invoking SLPAutoFindAttrs (including the name of the callback, the
service type and attributes) MUST be given.
Silverajan Expires November 3, 2006 [Page 13]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
8.1.2.3. Parameters
hSLP
The language specific SLPHandle on which to search for
attributes.
pcServiceType
The Service Type String, including authority string if any, for
the request, such as can be discovered using SLPFindSrvTypes(),
described in section 4.5.4 of [8]. This could be, for example
"service:printer:lpr" or "service:nfs". May not be the empty
string.
pcScopeList
A pointer to a char containing comma separated list of scope
names. May not be the empty string, "".
pcAttrIds
The filter string indicating which attribute values to return.
Use empty string, "", to indicate all values. Wildcards
matching all attribute ids having a particular prefix or suffix
are also possible. See [1] for the exact format of the filter
string.
callback
A callback function through which the results of the operation
are reported.
pvCookie
Memory passed to the callback code from the client. May be
NULL.
findmode
Legal values are 1 and 0. When the value is 1, an auto-query
is initiated. when the value is 0, an autoquery previously
requested, matching the same signature, is cancelled.
8.1.2.4. Returns
If an error occurs in starting the operation, one of the SLPError
codes is returned.
8.1.3. SLPAutoReg
Silverajan Expires November 3, 2006 [Page 14]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
8.1.3.1. Synopsis
SLPError SLPAutoReg(SLPHandle hSLP,
const char *pcServiceType,
const char *pcAttrIds,
unsigned int ServicePort,
const unsigned short usLifetime,
SLPBoolean fresh,
SLPRegReport callback,
void *pvCookie,
unsigned short regmode);
8.1.3.2. Description
This function is responsible for registering and unregistering local
services that are provided the mobile node, in the foreign networks
being visited. The pcSrvType parameter is a service type name given
by the application. The Service URL to be registered SHOULD be
constructed from the Service Type, care-of address and service port.
Because the application is usually unaware of the current care-of
address of the mobile node, it is the Visiting Agent's responsibility
for constructing a Service URL. However, if the Visiting Agent
implementation is unable to obtain the care-of address, it MAY be
constructed from the Service Type, home address and service port.
If regmode is set to 1, then the service is registered with either
the Access Agent or the Directory Agent in the foreign network. If
the fresh flag is SLP_FALSE, then an existing registration is
updated. Services are unregistered automatically from the previous
foreign network and registered in the new network.
If regmode is set to 0, then all services matching the Service URL
are unregistered from the current Access Agent or Directory Agent.
Automatic registrations will not be performed when the mobile node
moves again.
8.1.3.3. Parameters
hSLP
The language specific SLPHandle on which to register the
advertisement.
pcServiceType
The Service Type String, such as can be discovered using
SLPFindSrvTypes(), described in section 4.5.4 of [8]. This
could be, for example "service:ftp". May not be the empty
string.
Silverajan Expires November 3, 2006 [Page 15]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
pcAttrIds
The filter string indicating which attribute values to return.
Use empty string, "", to indicate all values. Wildcards
matching all attribute ids having a particular prefix or suffix
are also possible. See [1] for the exact format of the filter
string.
ServicePort
The port number in which the service is provided. If it is set
to 0, then the default port for the service is assigned. If no
default port exists, then the SLPError SLP_INVALID_REGISTRATION
is returned.
usLifetime
An unsigned short giving the life time of the service
advertisement, in seconds. The value must be an unsigned
integer less than or equal to SLP_LIFETIME_MAXIMUM and greater
than zero.
fresh
An SLPBoolean that is SLP_TRUE if the registration is new or
SLP_FALSE if a reregistration.
callback
A callback function to report the operation completion status.
pvCookie
Memory passed to the callback code from the client. May be
NULL.
regmode
Legal values are 1 and 0. When the value is 1, an auto-
register is performed. when the value is 0, a deregistration
matching the same service URL, is performed.
8.1.3.4. Returns
If an error occurs in starting the operation, one of the SLPError
codes is returned.
8.2. Java Language Binding
Bindings in Java language are defined in this section. Similar to
the C Language Bindings in the previous section, the syntax has been
intentionally preserved to match the existing API. New methods are
defined for addition into the Advertiser and Locator interfaces
defined in [8].
Silverajan Expires November 3, 2006 [Page 16]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
8.2.1. autoFindServices
8.2.1.1. Synopsis
public abstract void
autoFindServices(ServiceLocationEnumeration enumeration,
ServiceType type,
Vector scopes,
String searchFilter,
int findmode)
throws ServiceLocationException
8.2.1.2. Description
Issue an auto-query upon movement for services, or forget a previous
auto-query for services. Results are returned through
ServiceLocationEnumeration variable. This method belongs to the
Locator interface.
When findmode is set to 1, the first query for services returns the
results in the enumeration parameter. Subsequently, the enumeration
variable is updated each time the mobile node moves into a new
network space to return results for the requested service to be auto-
discovered.
When findmode is set to 0, the auto-discovery for the service is
disabled. In this case, the exact signature of the function provided
when first invoking autoFindSrvs MUST be given.
8.2.2. autoFindAttributes
8.2.2.1. Synopsis
public abstract void
autoFindAttributes(ServiceLocationEnumeration enumeration,
ServiceType type,
Vector scopes,
Vector attributeIds,
int findmode)
throws ServiceLocationException
8.2.2.2. Description
Issue an auto-query upon movement for returning service attributes
matching the attribute ids for the indicated service type, or forget
a previous auto-query for service attributes. Results are returned
through ServiceLocationEnumeration variable. This method belongs to
the Locator interface.
Silverajan Expires November 3, 2006 [Page 17]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
When findmode is set to 1, the first query for service attributes
returns the results in the enumeration parameter. Subsequently, the
enumeration variable is updated each time the mobile node moves into
a new network space to return results for the requested service to be
auto-discovered.
When findmode is set to 0, the auto-discovery for the service is
disabled. In this case, the exact signature of the function provided
when first invoking autoFindAttributes MUST be given.
8.2.3. autoRegister
8.2.3.1. Synopsis
public abstract void
autoRegister(ServiceType type,
int port,
int lifetime,
Vector attributes,
int regmode)
throws ServiceLocationException
8.2.3.2. Description
This method is responsible for registering and unregistering local
services that are provided by the mobile node, in the foreign
networks being visited. The ServiceURL to be registered SHOULD be
constructed from the ServiceType, care-of address and service port.
Because the application is usually unaware of the current care-of
address of the mobile node, it is the Visiting Agent's responsibility
for constructing a ServiceURL. However, if the Visiting Agent
implementation is unable to obtain the care-of address, it MAY be
constructed from the ServiceType, home address and service port.
This method belongs to the Advertisor interface.
If regmode is set to 1, then the service is registered with either
the Access Agent or the Directory Agent in the foreign network.
Services are unregistered automatically from the previous foreign
network and registered in the new network.
If regmode is set to 0, then all services matching the ServiceURL
constructed are unregistered from the current Access Agent or
Directory Agent. Automatic registrations will not be performed when
the mobile node moves again.
Silverajan Expires November 3, 2006 [Page 18]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
9. Usage Scenarios
The following scenarios depict the interaction between a Visiting
Agent and an Access Agent, for using services as well as offering
services in foreign networks. It is assumed that the Visiting Agent
has successfully detected movement as well as received AA Adverts
from the new Access Agent in a new link. This means the Visiting
Agent MUST cache the location of the Access Agent or Directory Agent
it has interacted with in the previous network. Also, the Visiting
Agent MUST cache its own previous care-of address used for service
registrations in the previous network.
9.1. Using Site-local services
Upon receiving the new AA Advertisement, the Visiting Agent checks
the Advertisement.
o If the Advertisement contains a Directory Agent URL:
* The Visiting Agent MUST use the Directory Agent for all service
requests in the new network.
* If the Visiting Agent sends SrvRqst packets to the Access
Agent, the Access Agent MUST return an SrvRply back to the
Visiting Agent with the Error Code AA_USE_DA.
o If the Advertisement does not contain a Directory Agent URL:
* If the 'M' flag is set, the Visiting Agent SHOULD use site
local multicast for service requests.
* If the 'P' flag is set, the Visiting Agent SHOULD use the
Access Agent for service requests, by sending unicast SrvRqst
packets to the Access Agent. The Access Agent then performs
site-local service discovery, and returns replies back to the
Visiting Agent with unicast SrvRply packets. The XID value of
the unicast replies MUST be equal to the original SrvRqst
packets.
* If both 'M' and 'P' are set, the Visiting Agent MAY choose
either option.
* If 'P' is not set, and the Visiting Agent sends SrvRqst packets
to the Access Agent, the Access Agent MUST return an SrvRply
back to the Visiting Agent with the Error Code AA_NOT_PROXY.
* If neither 'P' nor 'M' is set, the AAAdvert is used by the
Visiting Agent for movement detection only.
Note: If the Visiting Agent moves into a new network but is unable to
locate an Access Agent, it SHOULD solicit for DA Adverts on the link-
local scope, to issue service requests to the Directory Agent. If
neither an Access Agent nor a Directory Agent is present, the
Visiting Agent MUST perform service discovery using only link-local
multicast.
Silverajan Expires November 3, 2006 [Page 19]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
9.2. Providing Site-local services
Upon receiving an AA Advertisement, it is first inspected by the
Visiting Agent. If a new Access Agent or Directory Agent is to be
used, the Visiting Agent SHOULD first unregister all services
registered with the Access Agent or the Directory Agent in the
previous network.
o If the Advertisement contains a Directory Agent URL:
* The Visiting Agent MUST use the Directory Agent for all service
registrations in the new network.
* If the Visiting Agent sends SrvReg packets to the Access Agent,
the Access Agent MUST return an SrvAck back to the Visiting
Agent with the Error Code AA_USE_DA.
o If the Advertisement does not contain a Directory Agent URL:
* If the 'M' flag is set, the Visiting Agent SHOULD join the site
local multicast groups for the service types it is offering to
listen for service requests and respond with service replies.
* If the 'P' flag is set, the Visiting Agent SHOULD use the
Access Agent for service provision, by sending unicast SrvReg
packets to the Access Agent. The Access Agent then
acknowledges valid registrations with SrvAck packets containing
Error Code 0, and the XID value equal to the received SrvReg.
It then joins the site local multicast groups for the service
types the Visiting Agent is offering to listen for service
requests and respond with service replies.
* If both 'M' and 'P' are set, the Visiting Agent MAY choose
either option.
* If 'P' is not set, and the Visiting Agent sends SrvReg packets
to the Access Agent, the Access Agent MUST return an SrvAck
back to the Visiting Agent with the Error Code AA_NOT_PROXY.
* If 'P' is set, but the Access Agent wishes to proxy only
service requests for the Visiting Agent, but not service
provision, the Access Agent MUST reply to a received SrvReg
packet with an SrvAck packet containing the Error Code
AA_OP_UNSUPPORTED.
* If neither 'P' nor 'M' is set, the AAAdvert is used by the
Visiting Agent for movement detection only.
Note:
When the Access Agent receives an SrvReg from a Visiting Agent, the
Access Agent SHOULD check that the address in the Service URL matches
the source IPv6 address from which the packet was received. Since
the Service URL SHOULD be constructed using the care-of address of
the Visiting Agent, an address mismatch could imply that the mobile
node has already moved into a new network and has obtained a new
care-of address, but that its Visiting Agent is unaware of it.
Therefore, the Access Agent SHOULD NOT accept the registration, and
Silverajan Expires November 3, 2006 [Page 20]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
SHOULD reply to the SrvReg with an SrvAck containing the Error Code
AA_PEER_ADDRESS_MISMATCH.
Upon receiving an SrvAck with this Error Code, a Visiting Agent
SHOULD ascertain its care-of address, and perform active AA
Discovery, if necessary.
If the Visiting Agent moves into a new network but is unable to
locate an Access Agent, it SHOULD solicit for DA Adverts on the link-
local scope, to issue service registrations to the Directory Agent.
If neither an Access Agent nor a Directory Agent is present, the
Visiting Agent MUST perform service advertisement and provision using
only link-local multicast. In every case, all services offered in
the previous network SHOULD be unregistered.
10. Implementation Notes
Obtaining the care-of address by the Visiting Agents, for
constructing Service URLs for registration in foreign networks is not
a very straightforward process. This is due to the fact that Mobile
IPv6 provides network transparency to applications by design.
However, methods exist for obtaining the Care-of Address, such as
low-level socket libraries for Mobile IPv6 exporting movement and
address information. If such methods are not available to the
Visiting Agent, it MAY resort to communication with the Access Agent
using AddRqst and AddRply messages described in this document, to
obtain a suitable IPv6 address with which site-local services can be
registered.
11. Security considerations
The responsibility of authenticating mobile nodes in foreign networks
lies with Mobile IPv6. SLP uses digital signatures for content
verification of messages. Service Agents and User Agents may verify
digital signatures provided with DAAdverts. User Agents and
Directory Agents may verify service information registered by Service
Agents. The keying material to use to verify digital signatures is
identified using a SLP Security Parameter Index, or SLP SPI. Because
the roles of the Access Agent and Visiting Agent transiently depend
on and provide the UA-SA-DA interaction model, there is nothing in
these extensions which weakens or strengthens this technique.
12. Acknowledgements
The following persons provided extensive feedback and review of
Silverajan Expires November 3, 2006 [Page 21]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
previous versions of this draft: Mark Borst (mark@mwborst.com), Jarmo
Harju (harju@cs.tut.fi). Joona Hartman (joona.hartman@nokia.com)
provided extensive portions of the agent implementations. Julio
Martinez (juliomb@gmail.com) provided reference implementations of
the SLP API in Java.
13. References
[1] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Guttman, E., "Service Location Protocol Modifications for IPv6",
RFC 3111, May 2001.
[4] Bradner, S., "BCP 14, Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[5] Kempf, J. and J. Goldschmidt, "Notification and Subscription for
SLP", RFC 3082, March 2001.
[6] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced
Service Location Protocol (mSLP)", RFC 3528, April 2003.
[7] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W.
Jerome, "Remote Service Discovery in the Service Location
Protocol (SLP) via DNS SRV", RFC 3832, July 2004.
[8] Kempf, J. and E. Guttman, "An API for Service Location
Protocol", RFC 2614, June 1999.
[9] Howes, T., "The String Representation of LDAP Search Filters",
RFC 2254, December 1997.
Silverajan Expires November 3, 2006 [Page 22]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
Author's Address
Bilhanan Silverajan
Tampere University of Technology
Korkeakoulunkatu 1
33720 Tampere
Finland
Email: Bilhanan.Silverajan@tut.fi
Silverajan Expires November 3, 2006 [Page 23]
Internet-Draft SLP Extensions for Mobile IPv6 May 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Silverajan Expires November 3, 2006 [Page 24]
