Manet Working Group Rajeev Koodli INTERNET DRAFT Charles E. Perkins 2 October 2002 Communication Systems Laboratory Nokia Research Center Service Discovery in On-Demand Ad Hoc Networks draft-koodli-manet-servicediscovery-00.txt Status of This Memo This document is a submission by the manet Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the manet@ietf.org mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract In this document, we describe extensions to suitable ad hoc network routing protocols in order to provide support for service discovery. Typical Internet applications require information such as name resolution, a web proxy IP address, access to print services etc. While [manet] protocols have focussed on providing basic routing support for communication, this document addresses the problem of discovering services along with routes to those services. Koodli, Perkins Expires 2 April 2003 [Page i] Internet Draft Service Discovery in Ad Hoc Networks 2 October 2002 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 2 3. Protocol Overview 3 4. Overview for Table-Driven Protocols 3 5. Overview for On-Demand Protocols 3 6. Protocol Details for Reactive Protocols 4 6.1. Service and Route Resolution . . . . . . . . . . . . . . 5 6.2. Route Discovery only . . . . . . . . . . . . . . . . . . 5 6.3. Route is Present, Service Resolution Required . . . . . . 5 7. Extension Formats 5 7.1. Service Port Request . . . . . . . . . . . . . . . . . . 6 7.2. Service URL Request . . . . . . . . . . . . . . . . . . . 6 7.3. Service Reply Extension . . . . . . . . . . . . . . . . . 7 8. Security Considerations 8 9. IANA Considerations 8 Addresses 9 Koodli, Perkins Expires 2 April 2003 [Page 1] Internet Draft Service Discovery in Ad Hoc Networks 2 October 2002 1. Introduction In this document, we describe extensions to suitable ad hoc network routing protocols in order to provide support for service discovery. Typical Internet applications require information such as name resolution, a web proxy IP address, access to print services etc. While [manet] protocols have focussed on providing basic routing support for communication, this document addresses the problem of discovering services along with routes to those services. The problem of service discovery can be characterized as follows. Applications identify services using names or port numbers rather than IP addresses. These so-called "service selectors" need to be mapped to IP addresses. Routes need to be discovered to the resolved IP addresses, typically at the same time. The process of discovering the [service selector, IP address] binding is service discovery, whereas discovering a path to the resolved IP address is route discovery. 2. Terminology 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 RFC 2119 [1]. In addition, this document uses the following terms: service selector Either a port number, or a Service URL optionally combined with some service attribute specification. service binding An association between a service and the IP address of the node hosting the service application. service request extension Either a Service Port Request extension (see section 7.1) or a Service URL Request extension (see section 7.2). service request message A route discovery message containing a service request extension. service reply message A route reply message containing a service reply extension. Koodli, Perkins Expires 2 April 2003 [Page 2] Internet Draft Service Discovery in Ad Hoc Networks 2 October 2002 Service URL A string as defined in RFC 2608 [2] useful for supplying information about network services. 3. Protocol Overview 4. Overview for Table-Driven Protocols Service Discovery for table-driven prototocols such as OLSR or TBRPF can be managed by simply adding Service Reply extensions to the topology update routing protocol packets. In this way, service information can be made available immediately along with the information about which links are available for creating routes. In this case, the discovery operation is not separate from the operation of processing new topology update messages. 5. Overview for On-Demand Protocols On-demand routing protocols for ad hoc networks typically offer a "Route Request" (RREQ) message to initiate the basic route discovery process, as specified in AODV [4] or DSR [3]. The basic service discovery process uses the same operations and message formats as route discovery, but with extensions with the format in either section 7.1 or 7.2. When a node needs to discover a service, it formulates a service request containing the service selector data which will identify the desired service application. The node then includes the query as an extension to the RREQ, and floods the RREQ. The service query requests resolution of service name into an IP address of a node that offers the requested service. By default, a service query also requests a route to the resolved IP address. There are two kinds of extensions that can be used to request service. The Service Port Request extension (see section 7.1) includes the port number that is associated with the service application. The Service URL Request (see section 7.2) extension utilizes the data formats from Service Location Protocol [2] for more accurate service identification. These two extensions are called "service request" extensions. A node that receives a RREQ with a service request extension (call such a message SREQ) has to perform the following. First, it must determine whether it has a valid service binding for the service selector present in the SREQ. Such a service binding would have a mapping of [service selector, IP address] with valid lifetime. Next, the receiving node must verify if there is a valid route available for the resolved IP address; that is, whether a valid Koodli, Perkins Expires 2 April 2003 [Page 3] Internet Draft Service Discovery in Ad Hoc Networks 2 October 2002 route (e.g., a source route, or a next hop) exists to the node that offers the service specified in SREQ. If these conditions are met, the processing node constructs a RREP and copies the received service selector data to a Service Reply extension to the RREP (call such a message SREP). Then the node transmits the SREP back towards the requester. The Service Reply extension supplies the requested binding with an associated Lifetime. If the processing node has a service binding but no active route to the resolved IP address, it sets the Destination IP address to the resolved IP address, and re-broadcasts the RREQ message. Any node that receives a SREQ message with a non-zero Destination Address may send a SREP message if it has either a route to the destination, or a route to an equivalent service as described in the service request extension. If the extension is already present in a RREP packet, e.g., some other node (or the destination itself) provided the extension, and the service binding Lifetime is greater than that present in its local binding, the processing node forwards the RREP towards the source. If the extension is not present, or has a Lifetime shorter than that present in its local binding, then the processing node creates the SREP packet with the greater Lifetime and forwards it towards the source. If a processing node does not have a service binding, it re-broadcasts the original SREQ packet. 6. Protocol Details for Reactive Protocols We consider the following cases. 1. the source has neither a service binding nor an active route. This would be the case when a node is first attempting to discover a service and a route to that service. 2. the source has a service binding, but an expired route. This may happen due to mobility, link failures or other conditions typical in ad hoc networks. 3. the source has an active route but the service binding is either absent or has expired. The binding may not be present because the source may have communicated with the destination for reason(s) unrelated to the service in question. The binding may have expired because the source has not communicated with the destination for the reason of utilizing the service. Koodli, Perkins Expires 2 April 2003 [Page 4] Internet Draft Service Discovery in Ad Hoc Networks 2 October 2002 6.1. Service and Route Resolution If a source node requires access to a service, and the underlying routing protocol supports on-demand route discovery, then the source creates a Service Request extension (using a message format defined in sections 7.1 or 7.2), include it in a RREQ message and broadcasts the resulting SREQ packet (as it does in typical on-demand routing protocols). The Destination Address MUST be set to zero, and the Destination Sequence Number (if required) MUST be treated as unknown. An intermediate processing node treats the RREQ as a SREQ message since the service request extension is present. Whether or not the Destination Address is zero, the Service Request extension SHOULD be processed. If there is no service binding for the service name present in SREQ, the intermediate node MUST rebroadcast the packet. Depending on whether the intermediate has a valid route to the resolved IP address, there are two cases. 1. When the intermediate node has a valid route to the resolved IP address, it MUST create a Service Reply extension (whose format is defined in 7.3), include the extension in RREP and forward the resulting SREP packet to its previous hop. 2. When the intermediate node does not have a valid route to the resolved IP address, it MUST set the Destination Address to the resolved IP address and the Destination Sequence Number to the last known value in its route table for that destination, and rebroadcast the SREQ message. 6.2. Route Discovery only The protocol behavior of the source is identical to the behavior of an intermediate node described in scenario 2 in Section 6.1 above. 6.3. Route is Present, Service Resolution Required Since the source cannot determine that the IP address (for which the route is present) corresponds to the service name it is seeking to resolve, this scenario is same as in Section 6.1. 7. Extension Formats The extensions introduced in this document use the Type-Length-Value (TLV) format, with 8-bit types. Koodli, Perkins Expires 2 April 2003 [Page 5] Internet Draft Service Discovery in Ad Hoc Networks 2 October 2002 7.1. Service Port Request The extension format is shown below. 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 | Length | Port # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Service Port Request Extension Format The Port # is the port number (for TCP or UDP) at which the service application is known to reside. 7.2. Service URL Request The extension format is shown below. 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 | Length |srv-type length| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Request Predicate \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Service URL Request Extension Format Type TBD Length Length of the extension srv-type> length Length of the string. The string [2]. Service Request Predicate The string [2]. Koodli, Perkins Expires 2 April 2003 [Page 6] Internet Draft Service Discovery in Ad Hoc Networks 2 October 2002 The formats of the and the "Service Request " strings are defined by the Service Location Protocol [2]. 7.3. Service Reply Extension The extension format is shown below. 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 | Length | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URL Length | URL (variable length) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# of URL auths | Auth. blocks (if any) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Service Reply Extension Format The base format is shown in Figure 3. The header fields are described below. The format of the URL and the "Auth. block" strings are defined by the Service Location Protocol [2]. Type TBD Length variable Lifetime The lifetime of the association between the service and the IP address of the node hosting the service. URL Length variable URL The service: URL strings as defined by the Service Location Protocol [2]. # of Auth. blocks The number of Authorization blocks as defined by the Service Location Protocol [2]. Auth. block The Authorization block data as defined by the Service Location Protocol [2]. Koodli, Perkins Expires 2 April 2003 [Page 7] Internet Draft Service Discovery in Ad Hoc Networks 2 October 2002 8. Security Considerations If the endpoints have a security association, the receivers of the SREQ and SREP messages can insert IPsec headers to assure that the senders are not masquerading using someone else's IP address. This does not, however, assure integrity of the routing path between sender and receiver. That would be a property of the underlying routing protocol. However, encryption could be employed to avoid unauthorized inspection of the data fields of the SREQ or SREP messages, regardless of the underlying routing protocol security. The service authorization features from SLP have been maintained by including the Authorization Block data fields from the SLP Service Request message. No such feature is available when the port number alone is used in the service request message. Security may be provided by IPsec AH, if the endpoints have a suitable security association. 9. IANA Considerations References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service Location Protocol, Version 2. Request for Comments (Proposed Standard) 2608, Internet Engineering Task Force, June 1999. [3] D. Johnson and D. Maltz. Dynamic Source Routing in Ad-Hoc Wireless Networks. In Computer Communications Review -- Proceedings of SIGCOMM '96, August 1996. [4] C. Perkins, E. Royer, and S. Das. Ad Hoc On Demand Distance Vector (AODV) Routing (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-manet-aodv-11.txt, July 2002. Koodli, Perkins Expires 2 April 2003 [Page 8] Internet Draft Service Discovery in Ad Hoc Networks 2 October 2002 Addresses Questions about this memo can be directed to the authors: Rajeev Koodli Charles E. Perkins Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, CA 94043 Mountain View, CA 94043 USA USA Phone: +1-650 625-2359 Phone: +1-650 625-2986 EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Koodli, Perkins Expires 2 April 2003 [Page 9]