| jt@hpl.hp.com
Hewlett Packard Laboratories 1501 Page Mill road, Palo Alto, CA 94304, USA. | magalhae@uiuc.edu, ccarter@uiuc.edu
University of Illinois at Urbana-Champaign 1304 W Springfield Av, Urbana, IL 61801. |
This paper describes a novel approach to using TCP/IP applications over IrDA and BlueTooth. First, we look into why so few applications are available over IrDA and what is necessary to make the use of those applications attractive to end-users. Then, we present a new scheme that enable the use of the IrDA communication layer by those applications in a transparent fashion with minimal overhead. We describe the various components necessary to implement such a scheme, IrNET, the name resolver and the discovery manager, and explain how we have implemented those components under Linux. We finish by showing a few examples of use of those components with real applications.
Traditionally, research in ad-hoc networking has focused on the challenges of network autoconfiguration [15] and ad-hoc routing [12]. The results of this work have been implemented for several link layers, most notably Ethernet and wireless LANs. Unfortunately, the techniques developed can't be applied to TCP/IP over IrDA, due to the connection oriented nature of IrDA (see section 3.1).
There are at least three well-known methods used to encapsulate TCP/IP over IrDA (see section 4.1), all of them require extensive setup or explicit user intervention to establish a TCP/IP network link between nodes, and so can't truly be classified as ad-hoc.
This paper outlines a novel approach to using TCP/IP applications over IrDA. We describe a transparent and seamless method of establishing TCP/IP connections on the fly and without user intervention, allowing the user to ignore the presence of the IrDA layer and its mechanisms.
In CoolTown, spaces, devices and people have web pages, and can interact using HTTP. This intelligent use of web technology allows users to interact with the environment and devices once they have obtained the devices' URLs. A protocol, e-Squirt [27] disseminates these URLs to interested users via infrared. The Web Presence Manager helps the user communicate with various services available to him in the current context and locality [2].
This project is part of CoolTown and is follows the same philosophy. In this case, we are concerned by how the user interacts with wireless networking technology and how we can make this technology useful to him. Usually, wireless connections are used to support mobile hosts. In a ubiquitous computing environment it is desirable that network connectivity should be transparent to the user, if not seamless.
The basic benchmark we have defined to measure the degree of user-friendliness of our wireless interface is the comparison with removable storage. If copying data to a compact flash or floppy and carrying it to the destination (the so called "sneaker-net") is easier than sending it through the network, then the design of the interface is flawed. It is our firm belief that wireless ad-hoc networking can be successful only if it becomes easier to use and more friendly than removable storage. Unfortunately, we are not yet at that stage.
When HP started developing its CoolTown project, it made sense to use this widely available (although still under-used) link layer. Its main advantage over competitive technology is its directionality, which allows the user interface to be greatly simplified (just point and shoot, no need for messy on-screen selection). Other benefits of IrDA are its low price, widespread availability, high speed and ad-hoc nature.
The problem with IrDA is that only a handful of specialized applications are available for it.
Our goal is to use any common network application totally unmodified over IrDA, especially the applications the user is familiar with. As the vast majority of existing applications use TCP/IP, this means carrying TCP/IP traffic over the IrDA protocol. The other big advantage of TCP/IP is that it is routable, so it enable various kind of Vertical Handoffs [29].
OBEX [8] is supposed to be the "official" way to build applications over IrDA and BlueTooth, but there is today only a few OBEX application available (most of them only implement push functionality and don't even offer browsing), and OBEX doesn't offer the versatility and large application base of TCP/IP (media streaming, instant messaging, gaming and various java networking applications).
One limitation of the IrDA stack is that the lower layer, IrLAP, is strictly point-to-point when connected [4]. However, to ensure that our work can be applied to BlueTooth, we use multiple IrDA dongles. Each dongle can carry a single point-to-point link, but the Linux IrDA stack supports multiple dongles simultaneously, enabling us to form point-to-multipoint networks.
All the existing schemes for carrying TCP/IP over IrDA expect the user to explicitly trigger this connection setup. The TCP/IP over IrDA connection will be closed down at the user's request or if the IrDA connection is broken. IrLAN access points are the only exception to this rule, if a device discover one IrLAN Access Point and is already configured for it, the device can automatically connect to it when in range, but this is not an truly ad-hoc scenario.
Since we aim for transparency, we want to eliminate the necessity of user involvement in TCP/IP over IrDA connection establishment.
So, we could just pretend that IrDA is just another Ethernet link layer. The idea is to add mechanisms on top of IrDA to make it as similar as possible to Ethernet and hide the specificity of IrDA. In other words, to emulate a connectionless broadcast medium over IrDA.
The techniques are fairly well known, but a bit complex. Whenever a new node is discovered on the IrDA medium, a TCP/IP connection is established to it. Standard IP autoconfiguration techniques are used to configure this new node properly within the ad-hoc network. Optionally, an ad-hoc routing algorithm [12] can be used over this set of point to point links to reduce the number of redundant links so that a device doesn't need to connect at the link layer with every device in range.
The problem is that such techniques have significant costs. First, they are complex : extensive debugging and tuning is needed to make them work well and interoperate properly. In fact, it seems that more work will be needed before those techniques are practical [14].
Second, there is significant management overhead, especially if we want the system to react quickly to the dynamic topology changes common to IrDA systems. In fact, even when the user doesn't need network access, his device will spend much of its energy trying to manage and maintain this ad-hoc network with devices in range, which impacts the CPU and battery life of the device. Using reactive routing protocols such as AODV [13] can only reduce the IP level management traffic, however the link layer connections still need to be maintained.
Imagine a hypothetical user walking down a busy street with a BlueTooth capable mobile phone. Further assume that his phone is establishing a TCP/IP over BlueTooth connection with the cellphone of every other person who passes within range, keeping alive those BlueTooth links and exchanging various routing information. The mobile phone's battery would be flat in short order ; such an ad-hoc network is just not practical on a busy city street.
Finally, there are strict limitations to the number of simultaneous
link layer connections. IrDA can have only one active connection per
physical port [4]. With BlueTooth, the limit
is 7 per radio [10]. Increasing the number of
physical ports increases the cost, and is therefore not an attractive
option. Since IrDA can connect to only one device at a time, it is
vital that we ensure it's the right one.
3.3 On-demand TCP
The type of network traffic on ad-hoc wireless links is usually
different from that seen on a wired backbone. Most portable devices
tend to be personal clients directly used by their owner, so traffic
tends to be transaction oriented : there is useful traffic only when
the user performs a network transaction, otherwise no connection is
needed.
Also, the transactions are mostly two kinds, directed (device to device) or toward the infrastructure. Device to device transactions are with people within physical range : the user is physically interacting with someone (i.e. chatting) and wants to complement this with a digital transaction (sending the picture of his new girlfriend or new car). Transactions to the infrastructure use the relevant information or service in the Internet (paying for coffee).
We believe that most ad-hoc interactions will therefore be "one-hop" in nature, from our device directly to a peer or directly to an infrastructure access point. We personally don't want other people to use our bandwidth, CPU and battery life for their private interactions. Note that "our device" might be a set of personal devices configured to work as a unit and linked together by BlueTooth or a similar personal area network technology.
Based on these assumptions, we propose an on-demand TCP/IP scheme, where TCP/IP connections are established only when needed, directly to the intended target, and closed when no longer needed. This slightly increases the complexity of the system and the management overhead, but offers various benefits.
The on-demand scheme proposed act at the IP level (see section 6.3), so all protocols part of the TCP/IP stack are handled properly (including TCP, UDP, RTP and ICMP).
However, the on-demand nature of our approach precludes the use of the classical IP autoconfiguration techniques. Those techniques usually assume a permanently connected broadcast medium and work on top of IP, whereas by default our approach has no IP connectivity. Therefore, we must use novel autoconfiguration techniques integrating IrDA and TCP/IP.
Also, our solution doesn't solve all usage models and network configurations. One of the most important restrictions is that we can't connect to devices out of range if there is no infrastructure. Some usages and configurations require multi-hop routing and permanent TCP/IP connectivity, and in those specific cases more traditional solutions can be used [12].
The two schemes are similar and use the same underlying mechanisms, but there are significant differences. PPP deals with a single link and single IP address which is preconfigured, although some implementations can use a PPP instance for each of several IP addresses to allow multiple links. On the other hand, our scheme deal with IP addresses with are not known in advance, their number is variable and potentially large, and the number of active links also varies and is usually much smaller than the number of IP addresses, so we need a more scalable solution than what PPP offers.
The first is IrNET, interfacing the TCP/IP stack on top of the IrDA stack. We assume fully functional TCP/IP and IrDA stacks. This module allows TCP/IP traffic to flow across an IrDA connection.
The second is the IrNET Control Channel. This is a part of IrNET that exports IrDA events to the rest of the system and allows fine control over IrNET (mapping of specific TCP/IP flows to specific IrDA destinations).
The third is the Discovery Manager. It receives events from IrNET and the TCP/IP stack and sets up the system appropriately in response. Intelligence to control the system and establishment of on-demand connections resides in the Discovery Manager.
Fourth is the IrDA name resolver, which performs name resolution over IrDA.
The network applications present on the system don't interact directly with these components, but continue to use the standard system APIs (see fig. 3.6).
The Linux distribution used is GNU/Linux Debian 2.2 [22], upgraded with kernel 2.4.0 [23]. We tested on HP OmniBook 6000 laptops using the integrated IrDA port (a NSC 87338 FIR chipset) and HP Vectra workstations, using serial IrDA dongles (115 kb/s) or USB IrDA dongles (4 Mb/s).
We mostly reuse existing parts of the Linux OS, such as the TCP/IP stack, the IrDA stack, PPP and the network applications (web browser, web server, streaming MP3 player).
IrNET and its control channel are implemented in a kernel driver module. The IrDA resolver is a libc module. The Discovery Manager is a regular system daemon.
The most common is PPP over IrCOMM [7]. This is the method used to communicate with data-enabled mobile phones (those which support IrDA).
IrCOMM is the IrDA stack's simple serial emulation layer, so it's quite straightforward to setup PPP over this pseudo serial port. Unfortunately, this introduces inefficiency due to PPP framing and serial emulation.
The second option is to use IrLAN [6], which is the official IrDA standard for transporting TCP/IP over IrDA, and is implemented in IrDA LAN Access Points. IrLAN is basically an Ethernet emulation over an IrDA socket.
The third option is to use IrNET [9], which is used by Windows 2000 to connect two PCs together (Direct Cable Connection over IrDA). IrNET is synchronous PPP over an IrDA socket, using only the protocol part of PPP and removing both the serial emulation and the PPP framing for greater performance.
The main benefit is that PPP can deal automatically with IP addresses, IP routing and IP configuration through the IPCP negociation, obviating the necessity of other mechanisms to perform those functions. PPP also has built-in security (authentication [19] and encryption [20]).
PPP is slightly more efficient than Ethernet emulation, as it removes the Ethernet header and can perform IP header compression [17] and IP payload compression [18]. In our tests, the performance of uncompressed IrNET and IrLAN were very close, so it's mainly the rich feature set of PPP that made us prefer IrNET over IrLAN.
The main difference between IrNET and PPP over IrComm is performance, because no PPP framing is done. The other advantage is control, because IrComm doesn't allow to specify the IrDA destination address of the serial connection.
Finally, PPP is usually associated with long term static configuration (dial-up connections). Using PPP in an ad-hoc and dynamic fashion is a challenge that we could not ignore...
A lot of devices connected to the Internet already have an IP address configured (static or via DHCP on a WAN interface). If no IP address is explicitly given, PPP will use this default IP address of the device for the IrNET connection. This IP address may already be in use by another network interface of the device, but that not a problem. In fact, it's a benefit, because all interfaces of the device will be addressed in the same way.
If the device doesn't have any IP address, PPP will pick a random IP address in one of the non-routable IP subnet (such as 10.0.0.0/24). Those addresses are usually good enough for the kind of short lived directed transactions we are talking about.
PPP assigns two IP addresses at each end of the IrNET connection which may or may not be in the same subnet. However, PPP sets the appropriate host-specific route in the IP routing table, so in practice IP traffic always gets to the correct destination.
PPP can also automatically setup proxy ARP, to enable packet forwarding between the IrNET connection and other network interfaces. Our work does not use this feature of PPP, since we assume that devices are personal and the user doesn't want his resources and battery to be used by other people. On the other hand, proxy ARP could be used in the future to implement an IrNET access point.
The Linux PPP stack is composed of a user space daemon, pppd, and a set of kernel modules. The user space daemon is in charge of the protocol part of PPP. One kernel module is the PPP multiplexer, which interfaces the TCP/IP stack and the PPP daemon, and deals with common code (such as compression). A second module is one of the framing modules, which performs the link adaptation and usually interfaces with a TTY.
The IrDA stack is a set of kernel modules and composed of the IrLAP, IrLMP and IrTTP protocols. IrSock (the infrared socket API) is built on top of IrTTP.
Although it would be possible to implement IrNET using the standard external APIs as a user space module between the socket and the TTY APIs, for performance reasons, we interfaced IrNET directly to the PPP multiplexer and IrTTP in the kernel. This allows zero-copy communication between TCP/IP and IrDA (if PPP doesn't perform compression), to minimizing latency and reducing the code size of the IrNET module.
The resulting implementation is quite efficient. With a NSC FIR chipset (4 Mb/s link), the TCP throughput measured by netperf [26] is 3.19 Mb/s (uncompressed). The time to setup the IrNET link is less than 800 ms on a 115 Kb/s link (including full IrDA and PPP setup).
The first function of the control channel is to bind a specific IrNET instance to a specific IrDA destination. When PPP creates a new connection, the IrNET module has no way of determining to which IrDA device the PPP channel should connect. All current TCP/IP over IrDA solutions simply connect to the first device they find. With the control channel, it is possible to specify on the pppd command line the desired destination address, enabling IrNET to properly support multiple devices in range and point-to-multipoint configurations.
The mechanism is simple. The pppd daemon has a command line option (connect) to pass some arbitrary data directly to the input of the PPP driver used. With a regular modem, this is usually the set of AT command to dial the relevant phone number. For IrNET, we have defined a simple set of commands to specify the IrDA address of the connection and a few other parameters.
The second function of the control channel is to export events related to the IrNET connections as well as IrDA discovery events. By reading the /dev/irnet pseudo file, applications are informed when the connection is broken and when new nodes are discovered.
An example event log is :
Discovered 8c3478c8 (bougret) Request from 8c3478c8 (bougret) Connected to 8c3478c8 (bougret) on ppp0 Disconnected with 8c3478c8 (bougret) on ppp0 Discovered 8c3478c8 (bougret) Expired 8c3478c8 (bougret)
Various protocols can be used to associate names to IP addresses. The most common is the Dynamic Name Service, DNS [21], designed to work on the connected Internet, where names are organized in a well known hierarchy (my computer is `bougret.hpl.hp.com'). Other common naming protocols are Network Information Service, NIS (a.k.a. YellowPages) and the use of the static /etc/hosts file.
The user interface of most applications is built around human-readable names. The most common example is HTTP that embeds the DNS name inside the URL. To preserve the user's ability to use names, our system needs to perform name resolution over IrDA.
It may seem a bit paradoxical that we spend so much energy on names when most user interfaces, especially for IrDA, are graphic. But names are present under the graphic skin, and are used between the various component of the system.
The basic idea is to use the underlying link layer discovery. The IrDA stack itself can perform discovery and can build a local database of devices present on the network, including their IrDA address, IrDA nickname and hint bits. Discovery may be done continuously or on demand.
When the user wants want to resolve a destination with a specific IrDA nickname, the resolver query the current IrDA discovery log and extract its IrDA address. This is instantaneous and doesn't generate any additional IrDA traffic.
The second step is to convert the IrDA link layer address into an IP address. We use the IrIAP protocol to query the node associated with the target IrDA address for its IP address.
IrIAP [5] is a basic IrDA protocol that allows IrDA devices to query the IAS database of their peer devices. The IAS is a local database of service record attributes in the IrDA stack. IrIAP can query attributes on an IrDA node by name and obtain their values. The advantage of IrIAP is that it is very efficient, being a link-layer protocol (one request is half the cost of setting up an IrDA socket) and doesn't require server software on the target device.
Our use of IrIAP is straightforward. The Discovery Manager just add a XML string in the IAS database describing the IP configuration (IP address, DNS name...). Then, we can use IrIAP to query this attributes.
To convert from IrDA address to IP address, the resolver sends an IrIAP query for the attribute named "IPconfig" to the target IrDA device. The result of this query will be a XML string containing the IP address needed.
We reuse the "dot" notation of DNS, since most users are familiar with it. Each device on the IrDA link will have a name composed of its IrDA nickname and the suffix ".irda". For example, my computer has the name "bougret.irda".
The name space is not managed, so there may be name collisions, although such occurrences will hopefully be rare on such small networks. One way to resolve collisions is to add an instance number prefix to the name to distinguish different devices (for example "1.bougret.irda" and "2.bougret.irda").
Another option is to use the IrDA attributes found during the operation of the discovery protocol: we can prefix the name with the IrDA class of the device (for example "pda.bougret.irda" and "printer.bougret.irda"). IrDA has only 10 classes of devices and they are used loosely, but this technique will be more useful with BlueTooth, whose discovery protocol SDP is richer and more strict.
We have also introduced an IrDA specific wildcard name, "any.irda", that is not a real device name but resolves to the first device discovered on the IrDA link. This is useful for a line-of-sight link like IrDA because the user can connect to a device without knowing its name by just pointing at it. Of course, the name "any" can be combined with a class prefix (for example "printer.any.irda").
Finally, we can optionally resolve standard DNS names when the hostname part of the DNS name matches the IrDA nickname (as is usually the case). We use the DNS IAS entry of the remote host to make sure we match the proper node.
The IrDA resolver is just another resolver module added to NSS (see fig. 5.4). It exports to the C library a name resolution handler. It receives name resolution requests, try to perform the resolution and return the result or an error.
Any user space application can query the discovery database of the Linux-IrDA stack through its socket interface. This is done via a getsockopt call. We have added another call to allow user space applications to also perform IAP queries. The IrDA resolver is not specially privileged, it just uses those two calls appropriately.
The current resolver has a few interesting configuration options. We can choose to resolve "any.irda" only if there is a single device in range, or also if there are multiple discoveries (in this case we pick the first one). The resolution of DNS names is optional.
The resolver can also be used to resolve IrDA addresses to IP addresses through the gethostbyaddr() call.
The Discovery Manager needs two types of information to perform its function : it needs to know what are the other peer devices that it can reach through the IrDA link, and when it should establish a link with them.
The whole system is based around TCP/IP and IP addresses, so the first task is to collect IP addresses of IrDA peers, and the second to monitor IP traffic to those nodes.
The Discovery Manager also reads Expiry events from the control channel, informing it when nodes have left communication range so that it may remove their IP addresses from the active list (the address binding is kept a bit longer in case the node comes back).
6.3 Monitoring IP traffic
The Discovery Manager must monitor outgoing IP traffic towards nodes
present in its list of active IP addresses.
Our initial version of the Discovery Manager was using TCP/IP filtering facilities that are present on most standard TCP/IP stacks (such as Packet Filter, Net Filter...). The Discovery Manager was creating a list of IP addresses and receiving events for any packet matching the filter.
However, not all TCP/IP stacks support this functionality, so we changed the Discovery Manager to use a virtual network interface. This is a very simple network driver that offer an Ethernet interface to the stack and exchange data with the Connection Manager (a kernel loopback).
The use of such virtual interface is very simple. The Discovery Manager configure the standard IP routing table to forward all discovered IP addresses on the virtual interface. Then, any packet sent to one of those IP addresses will generate an event containing this packet sent to the Discovery Manager (see fig. 6.4).
When the Discovery Manager receives such an event, it first checks the state of the IrDA link associated with this IP address. If the link is unconnected, the Discovery Manager sets up a connection with PPP and IrNET and remove this IP address from the route to the virtual interface. When the IrNET link is up, all packets with this IP address automatically reach their destination. When the link goes down, this IP address is re-routed to the virtual interface.
The Discovery Manager also needs to close unused links. This is done by setting the idle timeout of PPP to 10s so that PPP itself closes the link if inactive. PPP also automatically tears down the PPP connection and the associated IrNET link if the IrDA link is blocked for more than 5s (usually implying that the destination moved out of range). These timeouts may need to be tuned to a specific device or application.
The current system creates a link in response to any packet matching the IP address of the link. This strategy is borrowed from the regular PPP demand mechanism and works well in practice ; unidirectional IP packets are almost always part of a connection and carrying useful information.
We do not, however, support broadcast and multicast traffic. Broadcast packets are typically periodic management packets, and do not normally indicate user demand for link connection. Establishing a link with any device in range to exchange such management packets would contradict our goal of preserving power. Multicast packets can be management or multimedia applications ; dealing efficiently with them in such ad-hoc point-to-point environment is still an open research issue and well beyond the scope of this paper.
It reads events on the IrNET control channel by opening the pseudo file exported by the IrNET module (/dev/irnet). It uses the IrDA resolver to translate IrDA to IP addresses.
It performs IrNET connection establishment by launching pppd, the PPP daemon, with the right command line arguments. One of these arguments is the IrDA address that pppd write on the IrNET control channel. The command line can also contain the PPP idle timeout and the IP address of the interface.
The first version Discovery Manager monitors TCP/IP traffic using the Linux NetFilter framework [24] and its associated IPtables library, but it was not optimal.
Currently, the Discovery Manager no longer use NetFilter but a virtual interface. It can use either the Universal TUN driver [24] or the PPP loopback, both standard features of the Linux kernel. The Discovery Manager just route IP addresses on the virtual network interface (either "tun0" or "ppp0") and read packets on a pseudo file (either "/dev/tun" or "/dev/ppp").
The Discovery Manager has been tested two multipoint configuration. The first configuration is when there is multiple peers, each visible behind a separate dongle. In this case, the Discovery Manager allow to establish multiple TCP/IP connections to these peers simultaneously.
The second configuration is when all the peers are visible behind the same dongle. In this case, because of the limitations of the IrDA protocol, the Discovery Manager allow to establish TCP/IP connections to these peers only in sequence.
Of course, it's impossible to list all the potential use of such technology, as it is only an enabling technology that many applications and developers can use for communication over IrDA, and not and end-user application in itself.
If the user wants to browse the content of another IrDA-capable device, he must only point his device toward it, type "any.irda" in the URL field of the browser, and magically the default web page of the other device will appear in his browser. The user can then transparently browse the various web pages of the device.
This is possible using a standard web browser and server, unmodified, on a system that implements our technique. And all web features (post forms, SSL, cookies, multimedia streaming, java plug-ins) are transparently supported.
This is how it works under the hood. As soon as the user's device discovers the other IrDA device, the Discovery Manager puts its IP address in the active list. When the user type "any.irda" in the browser, the browser resolves it and the IrDA resolver returns the target IP address. Then, the browser establishes a connection to the IP address. The Discovery Manager intercepts those IP packets and establishes the IrNET link. After that, the IP packets flow over IrDA and the HTTP server on the other device handle the incoming request.
However, this protocol currently applies only for documents available on the Internet. By using our technique, the remote appliance can also transparently fetch documents on the squirt sender. The squirt sender just needs to pass a URL referencing itself (its DNS name) and the local document.
An example is an Internet radio [27] developed as part of the CoolTown project. The user can squirt a URL referencing a local MP3 file, the Internet radio will query and stream the file from the user device over IrDA and play it.
Using our setup, any network application can be integrated easily into this interface, without changes.
For example, if the user want to add telnet support to this GUI, he can add an item in the contextual menu associated with each device containing "telnet %n.irda" (assuming that "%n" resolve to the IrDA name of the device).
These characteristics make the deployment of common network applications based on TCP/IP not transparent to the user : the user must explicitly connect the IrDA stack before using the application. Also, due to the ad-hoc nature of the medium, any network solution must be ad-hoc.
In this paper, we have presented a framework and a set of components that connect the IrDA stack on demand and deal with various details of TCP/IP configuration on such an ad-hoc link. This allows the IrDA link layer to be totally transparent to the application and the user. The main advantage of our approach is its simplicity and the reuse of various existing components to ease its implementation.
The components have been implemented in a real operating system and have been used with various real applications successfully.
Our next steps are to implement a similar on-demand TCP framework on
802.11 and BlueTooth, and to integrate these components in our Ad-hoc
Vertical Handoff framework [29].
9 References