Mobile Service Discovery Over Wireless Links Status of this Memo This document is being readied as an individual submission to the Internet Engineering Task Force (IETF). Comments should be submitted to the author. Distribution of this memo is unlimited. This document is an Internet-Draft. 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 made obsolete 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.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract In this document, a concept of main directory agent (MDA) is introduced. The main directory agent utilizes conjoined operations of Mobile IP and SLP including new proposed extensions. The MDA expedites service & location discovery process for mobile hosts and provides local system administrators with control over the usage of deployed services. It provides a mechanism for local system administrators to enforce local policies for the allocation of local access resources when desired. The MDA based service discovery by mobile hosts is particularly effective in the case of wireless networks. Wireless links have substantially lower bandwidth, suffer from higher error rates and need to support higher mobility of hosts/data terminals compared to wired links (e.g. LAN). Thus, to disseminate any information to mobile hosts over the wireless links the multicasting or broadcasting paradigm should be used sparingly. In view of this, optional extensions to Mobile IP and SLP protocol are recommended and discussed in this document. Again, the intent is to make the overall service discovery process expeditious and effective for mobile hosts. Table Of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3 2.1 Specification language . . . . . . . . . . . . . . .6 3. Service Goals . . . . . . . . . . . . . . . . . . . . . . . . . .6 3.1 Assumptions. . . . . . . . . . . . . . . . . . . . .6 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . . . 6 5. MDA Operations. . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 MDA Selection. . . . . . . . . . . . . . . . . . . . 9 5.2 MDA Selection by DHCP. . . . . . . . . . . . . . . . 10 5.3 Special Tunnel Protocol. . . . . . . . . . . . . . . 10 5.4 Server Agent Selection By MDA. . . . . . . . . . . . 11 6. Proposed Extensions . . . . . . . . . . . . . . . . . . . . . . 12 6.1 Proposed Mobile IP Extensions. . . . . . . . . . . . . . 12 6.2 Proposed SLP Extensions. . . . . . . . . . . . . . . . . 14 6.3 Service Location Protocol –Header Message Format . . . . 14 6.4 DA registration Request Message . . . . . . . .. . . . . 15 6.5 Agent Service Inquiry & Response . . . . . . . . . . . . 17 7. Service Location Transaction. . . . . . . . . . . . . . . . . . . 17 7.1 Service Location Connections. . . . . . . . . . . . . . .17 7.2 Synchronous Assumptions. . . . . . . . . .. . .. . . . . 17 7.3 Indempotency. . . . . . . . . . . . . . . . . . . . . . .17 8. Security Considerations. . . . . . . . . . . . . . . .. . . . . . 17 9. References. . . . . . . .. . . . . . . . . . . . . . . . . . . . 17 Authors Address . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Mobile IP [13] is designed to allow a node/mobile host to change its point of attachment without losing its ability to communicate. The, SLP protocol enables a client application on a host to automatically discover network services and have the service request fulfilled according to rules defined in [14]. In situations, where there are many service agents (SAs) advertising services, the protocol utilizes directory agents (DAs). The DA acts like a centralized repository of cached service agent advertisements. The service agent advertisement contains description of service type(s) and attributes in a human readable form. If many service agents provide the same service, then SLP relies on the human cognition of the user to select an appropriate service agent (interpret URLs). Perhaps the value of this service can be further enhanced if the directory agents are equipped with additional functionality to assist mobile users in selecting appropriate service agents. To precipitate service agent selection, the DAs need to collect additional/supplementary information. It is recommended that instead of every DA only a subset of DAs should be required to perform these additional functions. The DAs that perform these additional functions are referred to as the main directory agents (MDAs) in this document. Currently, both Mobile IP and SLP operations rely on multicasting or broadcasting mechanisms to accomplish most of their intended functions. In future, a large portion of users are expected to be roamers, then the cumulative impact of message transfers spawned by mobile hosts relying on multicast or broadcast for service(s) discovery is likely to become significant. Anticipating the above outcome, it becomes critical that the overall service discovery process be optimized to reduce the number of message exchanges required per mobile host per service discovery request. Furthermore if wireless access is contemplated, the total message transfers become even more critical since wireless links inherently have limited bandwidth and are prone to high error rates. Considering the recent development of IEEE 802.11 Wireless LAN (WLAN) standards, a substantial growth of WLAN deployment is envisioned. Additionally, Mobile IP and SLP are designed to operate independently, though there is a potential to synergies their operations. The conjoined operations can deliver a new capability whereby a host can change its point of network attachment and automatically discover network services more expeditiously at the visiting location. Consequently, optional new extensions to both SLP and Mobile IP [13,14] are advocated in this document. It is recommended that IETF include these optional extensions as part of Mobile IP & SLP standard specifications. 2. Terminology The following terminology borrowed from Mobile IP [13] and SLP [14] specifications is used to discuss the operation of service discovery by mobile hosts. Host A host computer, or simply “host,” is the ultimate consumer of communication services. A host generally executes application programs on behalf of user(s), employing network and/or Internet communication services in support of this function. An Internet host corresponds to the concept of an “End-System” used in the OSI protocol suite [zz]. Node A host or a router. Mobile Host A host that changes its point of attachment from one network or subnet to another. Home Agent A router on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node. Foreign Agent Chapter 1 A router on a mobile host's visited network that provides routing services to the mobile host while registered. The foreign agent detunnels and delivers datagrams to the mobile node that were tunneled by the mobile node's home agent. For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes. Agent Advertisement An advertisement message constructed by attaching a special Extension to a router advertisement [4] message. Care-of Address The termination point of a tunnel toward a mobile node, for datagrams forwarded to the mobile node while it is away from home. The protocol can use two different types of care-of address: a "foreign agent care-of address" and "co-located care- of address". The care-of address is an address of a foreign agent with which the mobile node is registered. The "co-located care-of address" is an externally obtained local address perhaps by DHCP. Correspondent Node A peer with which a mobile node is communicating. A correspondent node may be either mobile or stationary. Foreign Network Any network other than the mobile node's Home Network. Home Address An IP address that is assigned for an extended period of time to a mobile node. It remains unchanged regardless of where the node is attached to the Internet. Home Network/Site Network A network, possibly virtual, having a network prefix matching that of a mobile node's home address. Note that standard IP routing mechanisms will deliver datagrams destined to a mobile node's Home Address to the mobile node's Home Network. Link A facility or medium over which nodes can communicate at the link layer. A link underlies the network layer. Link-Layer Address The address used to identify an endpoint of some communication over a physical link. Typically, the Link-Layer address is an interface's Media Access Control (MAC) address. Mobility Agent Either a home agent or a foreign agent. Mobility Binding The association of a home address with a care-of address, along with the remaining lifetime of that association. Tunnel The path followed by a datagram while it is encapsulated. The model is that, while it is encapsulated, a datagram is routed to a knowledgeable decapsulating agent, which decapsulates the datagram and then correctly delivers it to its ultimate destination. Visited Network A network other than a mobile node's Home Site Network, to which the mobile node is currently connected. Visitor List A list of mobile nodes visiting a foreign agent. Host Client/User Agent/Client Application A host client/user agent/Client Application is an application software in an Internet host using SLP protocol to obtain service location parameters. DHCP server A DHCP server is an Internet host that returns configuration parameters to DHCP clients. Service Agent (SA) A process working on the behalf of one or more services to advertise service attributes and configuration. Service Information A collection of attributes and configuration information associated with a single service. The Service Agents advertise service information for a collection of service instances. Service The service is a process or system providing a facility to the network. The service itself is accessed using a communication mechanism external to the Service Location Protocol. Directory Agent (DA) A process which collects information from Service Agents to provide a single repository of service information in order to centralize it for efficient access by User Agents. There can only be one DA present per given host. Service Type Each type of service has a unique Service Type string. The Service Type defines a template, called a "service scheme", including expected attributes, values and protocol behavior. Service Registration Servers making use of the Service Location Protocol [14] register themselves and their attributes. They use the templates to generate the service registrations. In registering, the service must use the specified values for its attributes. Presentation of Service Information Client applications may access and display service information. The template provides type information and explanatory text, which may be helpful to the end user. Attribute A (class, value-list) pair of strings describing a characteristic of a service. Scope A collection of services that make up a logical group. URL A Universal Resource Locator - see [zz]. Address Specification This is the network layer protocol dependent mechanism for specifying an application/agent on a node. For Internet systems this is part of a URL. 2.1 Specification Language 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 [2]. 3. Service Goals The common denominator for conjoining the operations of Mobile IP and SLP protocols is a host that changes its point of network attachment and expects to discover network services at the visiting location. Since future networks are anticipated to support a large number of mobile hosts perhaps with wireless links, there is an expectation of higher efficiency and effectiveness of these protocols from an access link perspective. Efficiency implies the ability to accomplish the automatic service discovery task with minimum number of message transfers compared to the normal case (with the current SLP implementation). The number of message transfer is critical for wireless links, otherwise there is potential for a severe scaling problem. Similarly effectiveness implies the ability to choose the most appropriate service agent with respect to the mobile host’s visiting location if multiple parties provide the same service from different locations. In view of this the document describes a solution with potential to address both of these issues. 3.1 Assumptions All assumptions considered in Mobile IP and SLP specification [13,14] are valid. Additionally, it is assumed that there is at least one directory agent in the network to provide the necessary network service information as defined in [14]. 4.0 An Architectural Overview The diagram below illustrates the relationships discussed: +---------------+ User want this info: +-----------+ | Application | - - - - - - - - - - - ->| Service | +---------------+ +-----------+ /|\ | | | +-----------+ | | \|/ | | +-----------+ | | SLP Approach | Service | | | +-------------->| Agent |<----+ | | | +-----------+ | | | | | | | \|/ | \|/ | \|/ +---------------+ SLP +-----------+ | +----------------+ | Mobile |<-------->| Directory | | | Service | | User Agent | Approach | Agent | | | Agent which | +---- ----------+ +-----------+ | | does not reply | /|\/|\ | | | to UA requests | | | Proposed \|/ | +----------------+ | | Approach +---------------+ | | | +--------------->| Main |<--+ | | Unicast Request |Directory Agent|<-----------+ | Unicast Response +---------------+ | /|\ /|\ | | | | \|/ | | Proposed +----------+ | +----------------| Foreign/ | | Approach |DHCP Agent| | ___________ +----------+ | ___________ / Many other\ | / Many other\ | DA's |<-------------------+------->| SA's | \___________/ \___________/ A somewhat general overview of automatic service discovery process by mobile host. The process utilizes the conjoined operations of Mobile IP and SLP as discussed below. A mobile host is leased a long-term IP address on a home network. The mobile host is identified by this IP address. The network-prefix of this IP address identifies the mobile host’s home network address. On the foreign network, the services of a foreign agent as specified in Mobile IP [13] may be utilized. In the case of a wireless link, the foreign agent advertisement may be delivered over a radio link to assist a mobile host detect if it has moved away from its home network. Whenever a mobile host roams to a foreign network, it is expected to acquire a care-of address on the foreign network. Obviously there are two ways to acquire a care-of address; either from a foreign agent advertisement or by an external mechanisms such as DHCP [13]. Similarly if a client application in a mobile host needs to fulfill a service request while at a visiting location, there are two cases to consider. One when a foreign-agent is present and the other, when no foreign agent is present at the visiting location. Case 1: When a foreign agent is present at the visiting location. It is recommended that whenever a mobile host registers with the foreign agent if there is a DA serving the region, then the DA address be included in the registration response [13] to mobile hosts. The foreign agent only forwards the address of a DA if it has been chosen by it as its Main Directory Agent (MDA). Thus prior to forwarding the DA address to the mobile host, the foreign agent need to select one or more DAs as the Main Directory Agent(s)(MDA) details of which are provided in a later section. The MDAs eliminate the need for mobile hosts to individually discover DAs using multicast or broadcast mechanism [13]. Thus resulting in an expedited overall service discovery process. Once the mobile has the MDA address it can use a unicast {Unicast SrvRqst with or without a scope attribute [13]} message to inquire about any service that it desires to discover at the visiting location. As per the SLP specification [14], a DA may not be able to listen to all the service agent advertisements. Thus, it is proposed that a MDA should contact other DA(s) to compile the complete information on services provided in the network. Hence, it is recommended that a MDA initially should resort to multicasting/broadcasting to become aware of other DAs/MDAs in the network. Then onwards the MDA should use only unicast to collect service availability information from other DAs/MDAs on a periodic basis. Discussion: It is envisioned that in future the existing networks both wireline or wireless will have IP based core network. In such networks, having multicast messages in the core may not be critical. However, on the access side, particularly if it is a wireless access, it is essential that the number of message exchanges per service discovery request per host be minimized. Case 2: When no foreign agent is present at the visiting location. In this case the mobile host acquires the care-of address by an external mechanism, perhaps using a DHCP. An external mechanism may also be used to pair a DA with a DHCP server. In this case the paired DA acts as the MDA. If there is no DA present in the network then the service discovery should default to the process as defined in the current SLP specification [14]. Furthermore, stationary hosts can also make use of the MDA functionality to select the most appropriate service agents. In this case, it is proposed that at the bootup time a host be informed about the MDA if present in the network by the serving DHCP. The DA identified by the DHCP may be manually configured to play the role of the MDA. The system administrator is required to data-fill the appropriate DHCPs with MDA address(es). 5.0 Main Directory Agent (MDA) Operations As per the SLP specification [14], a DA will not be able to listen to all the service agent advertisements. Thus, if a host needs to discover a particular service it will issue a service specific multicast request. The service agents who can fulfill the service request will respond and the host will choose one if there are more than one present. In this scenario, the service specific multicast potentially could generate multiple responses from multiple service agents near and far to a host. Even if a DA is used as an arbitrator, still there could be more than one potential response to a host’s service request. As, a single DA may not be able to listen to all SA advertisements. The host would be required to access multiple DAs/SAs and issue multiple service specific multicasts. If there are multiple SA /& DAs deployed then a single service request from a host potentially could produce multiple responses. In order to reduce multiple responses, it is recommended that whenever a host desires to discover a service it should first contact the serving MDA. This entails that the host must be made aware of the serving MDA by a foreign agent or a DHCP (as mentioned previously). Otherwise the host would have to default to the second mode of the service discovery process as defined in [14]. Obviously if the MDA is used a service discovery request from a host will be completed with one response from the MDA. However, to accomplish this, the MDA may use Directory Agent Discovery Multicast Address [14] to find out about all the locally accessible services at a site network. The MDA may also issue the Directory Agent Discovery Multicasts repeatedly including Service Type as "directory agent" and with different TTL values. In each subsequent multicast service request MDA should increase the TTL value (perhaps up to a maximum, e.g. TTL =6) and include all the Service Types that it has discovered so far. After each multicast, the MDA should wait for CONFIG_INTERVAL_3 [14] to receive the responses. If no new response arrives within this response wait time then the MDA should presume that it has located all available DAs. The MDA should perform this service discovery search periodically but with the time gap sufficient not to unduly congest the site network. The MDA is also required to collect additional information from its neighboring DAs "read only basis" or from the service agents that have registered with it and perhaps from other network nodes such as Mobile IP AAA/DIAMETER Servers, etc. This ancillary information is required for selecting and steering mobile hosts to appropriate service agents. Discussion: Instead of advocating a passive role as defined for DAs in RFC 2165 (Where DAs are a simple repository of service advertisements), the MDA are recommended on an optional basis to provide a more active supervising role. These entities may screen users, monitor server operations, support user preferences, etc. It is recommended that a MDA may use ancillary information collected periodically through its service searches to steer users to most suitable service providers (service agents). However, it is possible that the MDAs may direct users to particular server/servers by providing limited information only to the users. Thus the selection of a pertinent server on behalf of a mobile user may involve consulting user preferences and server operational data, etc. by the MDA and potentially may involve the use of a number of protocols such as SLP, MIP, LDAP, DIAMETER, IPSEC, etc. However, in this document only Mobile IP and SLP are considered. Furthermore, the MDA is expected to provide only a loose recommendation in response to a service discovery request by a mobile user whereas the actual decision to choose a server for a particular is still left to users for reasons of flexibility. Thus, the enforcement of strict recommendations to realize the maximum benefits of the MDA concept is possible but it is an implementation issue. As such the focus of this document is to propose new extensions. These extensions will enable the MDA effectively improve the overall service discovery process. The motivation is that the value set of DAs will be increased substantially with the inclusion of the MDA concept thereby encouraging DA & SA deployment (outside the public Internet domain) and subsequently increasing the use of Mobile IP & SLP by other networks, e.g. wireless networks. The next few sections detail the required Mobile IP and SLP extensions. 5.1 MDA Selection By Foreign Agent The foreign agent accomplishes the MDA selection by listening to all DA advertisements. Each DA advertisement is required to include a time stamp value (new SLP extension recommendation). The foreign agent uses the time stamp values in the advertisements to determine which DAs are relatively nearby and which are far way. The foreign agent subsequently should respond with a DA Service Inquiry to subset of these nearby DAs. The Foreign agent should consider the nearby DAs list (if there are more than one) as the list of potential MDAs. The Agent Service Inquiry and the Agent Inquiry Response are two new functions recommended for SLP (details provided in a latter section). The functions are recommended to be of generic nature and potentially be useable by any SLP agent. These functions should enable an agent solicit information from any other agent about its current operational conditions. Obviously, the Agent Service Inquiry will be coded using the SLP service URL scheme [14]. Similar to the SLP Attribute Request function this function should also be constructed using a list of new operational attributes. The attributes should be able to characterize the operational capabilities of any agent e.g. DA, SA, Mobility Agent, Network Node, etc. To probe an agent about its current operational state, two new functions are proposed for SLP, namely Agent Service Inquiry and Agent Inquiry Response (the details of these message provided in a later section). The agent receiving the Agent Service Inquiry should respond with the Agent Inquiry Response that embodies the current values of the requested attributes. This document only makes a suggestion about these new attributes that can describe any agent’s operational capabilities. The actual description and details about these attributes are to be included in a separate document. The intent is that these attributes and their schema be officially registered with IANA. For that matter, a separate RFC needs to be created. As such the description of these attribute is considered beyond the scope of this document. A foreign agent appraises a DA for the MDA role. The foreign agent uses the information collected via Agent Inquiry Responses from multiple DAs. Once the foreign agent decides on a particular DA for the MDA role it includes that MDA address in its Registration Response messages to mobile hosts as described in section 6.1. A foreign agent also determines if additional MDAs are required by periodically polling the MDAs about their current operational status. These two new proposed functions are also expected to mitigate this. If for an example, more than one MDA is considered by the foreign agent, then the foreign agent can alternatively include their addresses in a round-robin fashion in its registration reply messages to visiting mobile hosts. Thus the foreign agent has the flexibility to implement different algorithms for load distribution among multiple MDAs. 5.2 MDA Selection By DHCP In case there are no foreign agents in the networks, mobile hosts are expected to rely on DHCP for mobility [13]. The DHCP is expected to deliver co care-of-address to visiting hosts. The DHCP can also identify the serving MDA to mobile hosts. However, it would require that the MDA address(s) be manually configured. In this scenario the MDA benefits are limited. The load distribution flexibility and automatic MDA failure recovery is not possible without manual invocation. 5.3 Special Tunnel Protocol In certain cases a directory agent location may be much closer to the host’s current foreign agent location than its home agent location. Thereupon, if a directory agent has to forward a service discovery response to mobile host, the datagram will be routed to the mobile’s home agent and subsequently will be tunneled back to the foreign agent. This may result in large delay in service discovery by mobile hosts. Obviously there is a need to minimize this delay by allowing the MDA and the foreign agent to be able to establish IP tunnels on behalf of all the visiting hosts served by the foreign agent at the visiting location. Currently Mobile IP lacks this flexibility to establish these additional tunnels. Consequently, it is recommended that the MDA and the foreign agent be able allowed to establish a compound tunnel. In fact, it is recommended that the compound tunnel be established using IPSEC protocol. Thus the tunnel will enable secure and quick delivery of responses by the MDA to mobile hosts served by a foreign agent. As an example, the service discovery process may adopt the following message flow between a mobile host and the MDA: 1. Mobile Host shall receive and process Foreign Agent Advertisements or 2. The Foreign Agents should accept Agent Solicitations from a Mobile Host and then it should respond with an Agent Advertisement. 3. The foreign agents should register the mobile host at the foreign/visiting networks and notify the Main Directory Agent (MDA) address to the mobile host. 4. Mobile Host desiring to discover service(s) at visiting subnet, should unicast a SLP Service Request with MDA as the destination address. The SLP Service Discovery Request may include a scope or multiple scopes or be without a scope. 5. The foreign agents should forward this unicast service discovery request received from the mobile host over the compound tunnel already established between the foreign agent and the MDA. 6. The MDA should accept all SLP Service Discovery Requests. Subsequently it should try to fulfill the service request by itself or with the help of neighboring DAs & MDAs. Finally it should forward a response to the mobile host (positive or negative). 7. The MDA may utilize a special compound tunnel (IP-in-IP encapsulation or [MIP-IPinIP]) between itself and the foreign agent for sending responses to mobile hosts as discussed above. 5.4 Server Agent Selection by MDA The MDA should collect ancillary information and use it to refine its response to mobile host requested service searches. Additionally the MDA should provide the server recommendations as part of the service discovery search response to a mobile host. The MDA service discovery search response should include a prioritized list of servers providing the requested Service Type. As an example, the server with the highest priority may be included at the top of the sorted list and so forth. Another example, if there are multiple servers that can provide the requested service(s) but some of them are heavily loaded and others are lightly loaded. In that case the MDA may create a sorted list of servers based on their loading. Optionally the MDA may not even include some these servers who are heavily loaded. Thus numerous examples can be constructed to illustrate substantial added value realizable if the MDAs are considered to enhance the service discovery and search process. The MDAs can also be utilized to ensure that both the service quality and resource usage objectives are be optimally met. Thus, the server recommendation provide by the MDA to a client may be on the basis of a number of different criterion, e.g. server occupancy, service tariff, transit delays, administrative scope, network policy, etc. The enhanced service discovery and search process is dependent on the solicitation and collection of additional relevant data. Thus, in order to implement this server agent selection and recommendation capability, the MDA would be required to collect additionally two new sets of data on a periodic basis. One set of data relates to server/agent operational aspects such as, # of users served, etc. And the other set of data relates to the current network conditions, e.g. network link transit delays between a server and the MDA, etc. To enable the MDA to solicit additional information two new SLP functions are proposed, namely the SLP Agent Service Inquiry and the SLP Agent Inquiry Response functions and details of which are included in the next section. These SLP service functions enable the MDA to collect the required set of operational data. In the second case it is recommended that the SLP DA advertisements, the SLP SA advertisements and the new two messages should include a timestamp. Perhaps the timestamp field should be 8 byte in SNTP format [zz]. The timestamp values included in these messages will facilitate the listening agents to determine total transit delays. Between SA and DA and between FA and DA respectively. As both sets of information are time dependent it needs to be periodical collected. For this reason, the DA and SA will issue advertisements and the SLP Agent Service Inquiry message periodically. Thus the MDA will make server recommendation while consulting current information rather than stale information. In summary the MDA concept provides opportunities to expedites and make more effective the service & location discovery process, particularly for the mobile hosts. The MDA based service discovery process requires additional Mobile IP and SLP related specific functions that are detailed in the next section. 6.0 Specific Extensions Proposed for Mobile IP & SLP In this document when a DA takes on the role of the MDA, its functional responsibility expands relative to as defined in [14]. Consequently, the MDA encompasses additional functionality. Furthermore the MDA meet its expanded obligations by utilizing specific extensions proposed to Service Location Protocol (SLP) and Mobile IP and discussed in this section. Thus, the requisite changes to SLP and Mobile IP are in terms of additional operations entailing new messages and/or additional message fields. Only the changes to SLP and Mobile IP to accomplish these additional tasks in support of service discovery process (as proposed in this document) are considered and described in this section. The operations not impacted, are not considered and default to as per rules defined in SLP and Mobile IP specifications [13,14]. 6.1 Proposed Mobile IP Extensions In Mobile IP [13] mobile hosts use two types of messages to exchange information with the foreign agents, namely Registration Request and Registration Reply. These messages are sent to well known port number 434 using UDP transport. Mobile IP also defines two types of registration procedures, one via a foreign agent, which forwards it to mobile host’s home agent and the other directly with the mobile node's home agent. Both registration procedures involve the exchange of Registration Request and Registration Reply messages. As explained earlier, a foreign agent should pick one or more DAs for the MDA role. To accomplish it, the foreign agents need to listen to all DA advertisements at the well-known port 427. It should also accept the SLP defined service scheme to extract information included in these advertisements particularly the DA address. Subsequently, the foreign agent need to include this DA network addresses in mobile hosts’ registration reply messages. To affect this a new extensions is proposed for Mobile IP. The following ordering of extensions is presumed (in line with the Mobile IP recommendations): a) The IP header, followed by the UDP header, followed by the fixed-length portion of the Registration Request, followed by b) If present, any non-authentication Extensions expected to be used by the home agent (which may or may not also be used by the foreign agent), followed by c) The Mobile-Home Authentication Extension, followed by d) If present, any non-authentication Extensions used only by the foreign agent, followed by e) The Mobile-Foreign Authentication Extension, if present, followed by f) The Mobile-IP DA Address Extension, if present. The items (a) and (c) always appear in every Registration Request sent by the mobile host. Items (b), (d), and (e) are optional. However, item (f) is last item to be included if the foreign agent accepts service location facilitator role. The following UDP header is used for Registration Reply Message from the foreign agent to the mobile hosts: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Directory Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 (Registration Reply) Code A value indicating the result of the Registration Request. See RFC 2002 for currently defined Code values. Lifetime The Lifetime field is set to the number of seconds remaining before the registration is considered expired. Home Address The IP address of the mobile node. Home Agent The IP address of the mobile node's home agent. Identification A 64-bit number used for matching Registration Requests with Registration Replies, and for protecting against replay attacks of registration messages. Extensions The fixed portion of the Registration Reply is followed by one or more of the Extensions. The Mobile-Home Authentication Extension is always included in all Registration Replies returned by the home agent. DA Address Extension The IP address of the selected DA extracted from the DA Advertisement listened to by the foreign agent is included as the last item in Registration Reply. 6.2 Proposed SLP Extensions The requisite changes to SLP are in terms of additional operations entailing new messages and/or additional message fields. Only the changes to SLP to accomplish these additional tasks in support of the service discovery process as proposed in this document are only detailed in this section. The operations not impacted are not considered and default to as per rules defined in SLP specifications [13,14]. 6.3 Service Location Protocol - Header Message Format Primarily changes considered in this document to the SLP datagram header are an addition of “D” bit borrowed from rsvd field and new function values. These changes are shown with bold letters in the following SLP datagram header figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Function | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|M|U|A|F|D|rsvd| Dialect | Language Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Char Encoding | XID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Functions Service Location datagrams and associated operations can be identified by the function field. The following are the new operations achieved with the introduction of the following new function values: Message Type Abbreviation Function Value Agent Service Inquiry AgntServInq 12 Agent Inquiry Response AgntInqRsp 13 DA Registration Request UsrRegRqst 15 DA Registration Response UsrRegRsp 16 rsvd This field has been shorten by one bit. The stolen bit is used for “D” bit. D If the 'D' bit is set in a DA Registration Request, the directory agent has been chosen as the MDA and it requested to registered with the issuing network agent (e.g. a foreign agent). The MDA may use these new operations to collect ancillary information to/from foreign agents, user agent, service agents, directory agents, and other network agents etc. The ancillary information basically is an expanded list of attributes and associated values. The new attributes should also be coded or represented using the same predicate principles as defined for service discovery attributes in RFC 2165. Furthermore, these new operations to collect ancillary information should be followed by responses containing the current values of the requested attributes. It is expected that some of new attributes will be assigned dynamic values, e.g. the occupancy of an agent i.e. the ratio of the number of users currently being served to the maximum that can be served, etc. In addition, if a receiving agent has not/prefers not to furnish the requested information, it should simply return a response with an empty list. This empty list response allows the querying agent/network agent to immediately detect that the requested information is not available. Hence the requesting agent need not wait for a timeout and avoid repeatedly retransmitting the request. The MDA and other network nodes such as Mobile IP Home Agent and Foreign Agent are required to accept the use of SLP RFC 2165. In SLP the messages are encoded using the service URL Scheme with the formal definition of URLs included in RFC 1738. Basically the information that follows the “service:” scheme adopts the URL structure and semantics. The SLP also allows supporting of additional attributes, beyond the standardized set. 6.4 DA Registration Request & Response The DA Registration Request is used by a Foreign Agent to obtain IP address or URL of a Directory Agent (DA) and also to indicate to the DA that it has been chosen as the MDA. Consequently if a foreign agent has conscripted a DA as its MDA, the “D” bit in the SLP datagram header should be set high. The format of the Service Request is as follows: 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 = DARegReq) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of URL | URL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of predicate string |Registration Request| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ Registration Request , contd. \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The DA Registration Request from the foreign agent also implies to the MDA that a special compound tunnel (as discussed earlier) be set using the URL for the DA Registration Response message. Again the DA Registration Request & Response predicates should be constructed as shown below: ::= ['.']'/''/''/' ::= string representing type of service. Only alphanumeric characters, '+', and '-' are allowed. ::= string representing the Naming Authority. Only alphanumeric characters, '+', and '-' are allowed. If this field is omitted then "IANA" is assumed. ::= string representing the directory agent scope. '/', ',' (comma) and ':' are not allowed in this string. The scopes "LOCAL" and "REMOTE" are reserved. ::= class name of an attribute of a given Service Type. This tag cannot include the following characters: '(', ')', ',', '=', '!', '>', '<', '/', '*', except where escaped. ::= a class name of an attribute which will have no values. This string has the same limits as the , except that white space internal to the keyword is illegal. ::= | | ::= That is NOTHING, or white space. ::= '(' '&' ')' | '(' '|' ')' | '(' ')' '(' ')' ::= | ::= | | ',' | ',' ::= ::= "!=" | "==" | '<' | "<=" | '>' | ">=" ::= any string, Value strings may not contain '/', ',' '=', '<', '>', or '*' except where escaped '(' and ')' may be used in attribute values for the purpose of encoding a binary values. Binary encodings may include the above reserved characters. An DA Registration Reply Message takes the form: 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 = DARegRply) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Timestamp ……………………………………| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |………………………….. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Error Code may have the following values: 0 Success or other values which will indicate reasons for not responding to the corresponding Inquiry. 6.5 Agent Service Inquiry & Response The Agent Service Inquiry and the Agent Inquiry Response are two new messages proposed as the SLP function extensions in this document. The Agent Service Inquiry & Response message template includes an expanded list of new attributes. These new attributes enable network agents and nodes such as MDA, DA, Foreign Agent, etc. to collect from each other ancillary information describing their current operational conditions. The DAs/MDAs are expected to use these new functions periodically to monitor and report the current operating situations of the registered service agents on behalf of mobile users. Obviously, the Agent Service Inquiry & Response messages should be coded same as the SLP Attribute Request messages using ABNF (ZZ) and as shown in the previous section. The description/specification of these new attributes (included as part of Agent Service Inquiry/Response message set) should be language independent thus ensuring global applicability. This document only makes a suggestion as to what kind of these new attributes should be. The actual description and details about these attributes requires a separate RFC document. As the specification/ description of these new attributes and their schema need to be officially registered with IANA, it is not included in this draft RFC document. 7.0 Service Location Transactions 7.1 Service Location Connections No changes expected, same as SLP [14] 7.2 No Synchronous Assumption 7.3. Idempotency All Service Location actions are still idempotent. 8.0 Security Considerations No new requirements entertained beyond being already considered in SLP [14]. References [1] Alexander, S. and R. Droms. DHCP Options and BOOTP Vendor Extensions. RFC 2131, March 1997. [2] Atkinson, R. IP Encapsulating Security Payload. RFC 1827, August 1995. [3] Balenson, D. Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, February 1993. [4] Berners-Lee, T. and D. Connolly. Hypertext Markup Language - 2.0. RFC 1866, November 1995. [5] Berners-Lee, T., L. Masinter, and M. McCahill. Uniform Resource Locators (URL). RFC 1738, December 1994. [6] Borenstein, N. and N. Freed. MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. RFC 2045, November 1996. [7] Bradner, Scott. Key words for use in RFCs to Indicate Requirement Levels. BCP 14, RFC 2119, March 1997. [8] Deering, Stephen E., editor. ICMP Router Discovery Messages. RFC 1256, September 1991. [9] Droms, Ralph. Dynamic Host Configuration Protocol. RFC 2131, March 1997. [10] Mockapetris, P. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. STD 13, RFC 1035, November 1987. [11] Narten, T., E. Nordmark, and W. Simpson. Neighbor Discovery for IP version 6 (IPv6). RFC 1970, August 1996. [12] Rivest, Ronald. The MD5 Message-Digest Algorithm. RFC 1321, April 1992. [13] Charles Perkins. Mobile IP. RFC 2002, [14] J. Veizades et.al. Service Location Protocol. RFC 2165, June 1997. Author's Address Questions about this memo can be directed to: Jastinder Jawanda Nortel Networks 2201 Lakeside Blvd. Richardson, Texas, 75083-3871 Phone: +1 972 684 4611 Fax: +1 972 684 3744 Email: jawanda@nortel.com