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 | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|P|N|m|R| res | # auth blocks | authentication block (if any) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The URL is "service:access-agent://" of the Access Agent, where 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]