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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Request Predicate \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Service URL Request Extension Format
Type TBD
Length Length of the extension
srv-type> length Length of the <service-type> string.
<service-type> The <service-type> string [2].
Service Request Predicate The <predicate> 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 <service-type> and the "Service Request
<predicate>" 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]