GeoCast - Geographic Addressing and Routing *
Julio C. Navas and Tomasz Imielinski
{navas,imielins}@cs.rutgers.edu
Computer Science Department
Rutgers, The State University
Piscataway, NJ 08855
Abstract
In the near future GPS will be widely used, thus al-
lowing a broad variety of location dependent services
such as direction giving, navigation, etc. In this pa-
per we propose and evaluate a Touting and address-
ing method to integrate geographic coordinates into
the Internet Protocol to enable the creation of lo-
cation dependent services. The main challenge is
to integrate the concept of physical location into the
current design of the Internet which relies on logical
addressing.
1 Introduction
In the near future Global Positioning System (GPS)
cards will be deployed in each car and possibly in
every user terminal. User’s location will become in-
formation that is as common as the date is today;
getting input from GPS, when outdoors, and other
location providing devices, when indoors. Availabil-
ity of location information will have a broad impact
on the application level as well as on network level
software.
Below, we list some of the possible new services
and functionalities:
l Geographic messaging: sending a message se-
lectively only to specific subareas defined by
latitude and longitude. For example, sending
*This research work was supported in psrt by DARPA
under contract numbcrDAAH04-95-l-0596, NSF grant num-
bers CCR 95-09620, IRE 95-09816 and Sponsors of X’IN-
LAB.
Permission to make dk$aUhard copies of all or part of this material for
personal or classroom use is granted without fee provided that the copies
are not made or distributed for profit or comme&al advantage, the &py-
right notice, the title ofthe publication and its date amear. and notice is
g&n that copyright is by &mission of the ACM, Ik. To- copy otherwise,
to republish, to post on servers or to redistribute to lists, requires specific
permission and/or fee
MOBICOM 97 Budapest Hungary
Copyright 1997 ACM 0-89791-988~2/97/9..$3.50
an emergency message to everyone who is cur-
rently in a specific area, such as a building,
train station, or a highway.
l Geographic Advertising and Geographic Ser-
vices: Advertising and providing a given ser-
vice only to clients who are within a certain
geographic range from the server (which may
be mobileitself); such as everyone within a mile
from the server.
l “Who is around” service: finding out who is
currently present in a specific geographic area
defined by an arbitrary polygon.
To support such applications, location should be-
come a first class citizen, starting from the IP level
and proceeding all the way to the application layer.
Routing protocols for geographic messages need to
be developed. Furthermore, the geographic desti-
nation for a message should not be confined to a
single point, but should be able to be specified as
any arbitrary polygon.
The Geographic Messaging Project researched
possible system designs for accomplishing geo-
graphic messaging. Three designs were looked at:
a Domain Name System approach, a multicast ap
preach, and a geographic routing approach. The de-
tails of these approaches are specified in RFC 2009
PI-
This is a DARPA sponsored Integrated Technol-
ogy Demonstration (ITD) which is being led by
Rutgers DataMan Lab within the GloMo (Global
Mobile) program. Under the DARPA experiment,
we have implemented a prototype of the geographic
routing system described in [5] and are in the pro-
cess of evaluating it. The immediate plans call for
the deployment of an experimental national net-
work capable of routing geographic messages with
nodes at Rutgers DataMan Lab, CECOM in Fort
Monmouth (U.S. Army), University of California
at Santa Cruz, and Bolt, Beranek, and Neumann
66
-- -:
_ I-
L-.---.
I
(BBN). The geographic routing system implemen-
tation will soon be made available to the DARPA
GLOMO participants.
The main objective of this paper is to report the
efficacy of the geographic routing approach. Section
2 talks about some background and related work.
Section 3 discusses the addressing model used for
geographic routing. Section 4 gives an overview of
the geographic routing system. Section 5 discusses
some implementationissues of the router itself. Sec-
tion 6 describes the experiments conducted and an-
alyzes the results. Section 7 talks about one future
research direction for geographic routing. Finally,
Section 8 draws some conclusions.
2 Background and Related
Work
Linking an IP Address with a geographical location
has been of interest for quite some time already.
The recent redesign of the Internet Protocol (IP) [2]
and the advent of the Global Positioning System [9]
gave a new stimulus for this work.
The first attempt to design a system that actually
routes packets according to their geographic desti-
nation and the work that is closest to ours is Carte-
sian Routing by Gregory G. Finn [4].
In the proposed redesign of the IP protocol
[2], IP Address Type Space was specifically allo-
cated for geographic addresses [3] [7]. These pro-
posed IPv6 geographical addresses are an abstract
geographically-nested hierarchy with no relation or
connection to any underlying coordinate system.
In [3] and [7] the sender of a “geographic mes-
sage” would be unicasting messages only to such
hosts which have geographic addresses. The meth-
ods in this paper attempt to provide the more gen-
eral ability of sending a message to all recipients
within a geographical area, regardless of whether
the hosts have geographical addresses or not.
Xerox’s PARC lab pioneered early work on loca-
tion dependent services [S].
3 Addressing Model
Two-dimensional GPS positioning offers latitude
and longitude information as a two dimensional vec-
tor, < latitude, longitude >, where longitude ranges
from -180 (west) to 180 (east), and latitude ranges
from -90 (south) to 90 (north).
Thus < 40.48640, -74.44513 > is an exam-
ple of the GPS coordinates for the town of New
67
Brunswick, New Jersey, U.S.A.
Assuming the use of single precision floating-
point numbers, four bytes of addressing space are
necessary to store latitude and four bytes are also
sufllcient to store longitude. Thus a total of eight
bytes are necessary to address the whole surface of
earth with precision down to 0.1 mile!
In the future, once we have more experience using
GPS receivers and are able to determine the optimal
number of significant digits necessary for geographic
routing, we will most likely switch to fixed-point
integers because of their greater efficiency.
3.1 Using a Geographic Destination
Address
A geographic destination address would be repre-
sented by some closed polygon such as:
0 point
l circle( center point, radius )
0 polygon( point(l), paint(2), . . . , point(n-1),
point(n), point(l))
where each vertex of the polygon is represented
using geographic coordinates. This notation would
be used to send a message to anyone within the
specified geographical area defined by the closed
polygon.
For example, if we were to send a message to city
hall in Fresno, California, we could send it by speci-
fying the geographic limits of the city hall as a series
of connected lines that form a closed polygon sur-
rounding it. Therefore the address of the city hall
in Fresno could look lie: polygon([36.80,-119.801,
[36,85,-119.761, . . . ).
4 Routing Geographically
In our Internet Engineering Task Force (IETF) Re-
quest For Comments (RFC) [5], we detailed three
methods for achieving geographically-routed mes-
sages: a geographically-aware router solution, a
multicast solution, and a Domain Name Service
(DNS) solution. At this point in time, we decided
to implement and evaluate the geographically-aware
router solution and not the multicast solution be-
cause of the multiplicity of proposed multicast pro-
tocols. It is not clear which multicast proposal will
become dominant in the future. Furthermore, it
is not clear whether the future dominant multicast
protocol would be able to handle peculiarities of mo-
bile computing such as mobile routers. As such, the
- ~- ---.-
/.
geographically-aware router solution best lent itself
to future research endeavors in geographic routing
because we would have full control of the routers
themselves.
The geographically-aware router solution uses the
polygonal geographic destination information in the
geographic message header directly for routing. Ge-
ographic routing is implemented in the Applica-
tion layer in a manner similar to the way multi-
cast routing was first implemented. That is, a vir-
tual network which uses geographic addresses for
routing will be overlayed onto the current IP inter-
network. We would accomplish this by implement-
ing our own routers which are geographically-aware.
These routers would use IP tunnels to transport
data packets through areas which do not support
geographic routing.
4.1
The Components of the Geo-
graphic Routing Method
GeoRouter
client pmccsx
Figure 1: All of the Components of the Geographic
Routing System
The system is composed of three main com-
ponents: the GeoHosts, GeoNodes, and the
GeoRouters. See figure 1.
4.1.1
GeoRouter
Geographic Routers (GeoRouter) are in charge of
moving a geographic message from a sender to a
receiver. The current prototype GeoRouter has the
following capabilities:
1. Basic multi-hop geographic routing.
2. Automatic detection of multiple network inter-
faces, type of network interface (whether wired
or wireless), other GeoRouters, and base sta-
tion GeoNode programs.
3. Automatic configuration of routing tables
based on detected information. Assumes a flat
network.
4. Manually configurable to do hierarchical net-
work routing.
5. Ability to tunnel through areas that do not
(yet) provide geographic routing.
See section 4.2 for an overview of the geographic
routing algorithm.
4.1.2 GeoNode
A GeoNode is an entry/exit point for the routing
system. The main function of the GeoNode is to
store incoming geographic messages for the dura-
tion of their lifetime and to periodically multicast
them on all of the subnets or wireless cells to which
it is attached. Each subnet and each wireless cell
will have at most one GeoNode. The lifetime of a
geographic message is specified by the sender of the
message. Message lifetimes are necessary because
the receivers of geographic messages may be mobile
and may possibly arrive at the message destination
just after the geographic message first arrives.
Since, most likely, there will be several geographic
messages residing in a GeoNode at one time, the
multicasting of the various messages will be sched-
uled. The scheduling algorithm will take into ac-
count the size of the message, the priority of the
message, and the speed of the subnet’s transport
medium. Clients wishing to receive geographic mes-
sages would then tune in to the appropriate multi-
cast group to receive them.
4.1.3 GeoHost
This daemon is located on all computer hosts which
are capable of receiving and sending geographic
messages.
Its role is to notify all client processes
about the availability of geographic messages, the
host computer’s current geographic location, and
the address of the local GeoNode.
4.2 Routing Overview
Sending a geographic message involves three steps:
sending the message, shuttling the message between
routers, and receiving the message.
68
4.2.1
Sending Geographic Messages
In order to send a geographic message, the pro-
grammer would use the Geographic Library rou-
tine SendToGeo(). The function will, first, con-
tact the local GeoHost Daemon and query it for
the IP address of the local GeoNode. It will then
send the message directly to the GeoNode, which,
in turn, will simply forward the message to the local
GeoRouter.
4.2.2
Router Actions
Figure 2: Geometric Routing Example
Once the datagram arrives at a GeoRouter, it
must first determine if it services any part of the
area of the destination polygon. To do this, the
router determines if the destination polygon and
the router’s service area polygon intersect’ [S] each
other. If not, then the router simply sends the mes-
sage to its parent router.
However, if the polygons intersect each another,
then the router does service the area described by
the intersection polygon. First, if the polygons only
partially intersect, then the router only services part
of the target area.
Therefore, it sends a copy of
the message to it’s parent router for further routing
beyond its own reach. The router now tests each
child node’s service area to see if it intersects the
destination polygon. Those that do will be sent the
geographic message.
In Figure 2, a user on Busch Campus wishes to
send a message to the destination polygon on the
College Ave. Campus. Upon sending the message,
it is passed to the Busch Campus router. By using
polygon intersection, the router determines that it
‘Detectingpo1ygonintersection takes O(n) time.
does not service the target area, so it forwards the
message to its parent, the county router. Using the
same algorithm, the county router decides that its
child node, the College Ave. router services the des-
tination area and forwards the message to it. The
College Ave. router, in turn, forwards the message
to the two GeoNodes which control the target area.
These two GeoNodes then deliver the message to all
of the users in the target area.
The router keeps a cache of the latest geographic
message packets and their destinations. When a
router receives a geographic message packet, it will
use the incoming packet’s Message Id as a key into
the cache. If this is not the first packet to arrive for
this destination and if the timer on the cache entry
has not yet expired, then the cache will return a list
of all of the next hop addresses to which copies of
the packet must be sent.
4.2.3 Receiving Geographic Messages
Once a geographic message has been sent to a
GeoNode from a geographic router, the receive pr*
cess can begin. The GeoNode will store the message
locally, assign a multicast group to it, and append
it to the list of available messages. Periodically, the
GeoNode will multicast the list of available mes-
sages on a well-known group address. Also, the
GeoNode will periodically multicast the message on
its assigned multicast group. The GeoHost daemons
will receive the list of available messages from the
GeoNode and determine if the host computer is lo-
cated inside any of the messages’ destination poly-
gons. When a client process executes a RecvFrom-
Geo() call from the Geographic Library, the func-
tion will join the appropriate multicast address and
receive the geographic message itself.
5 Router Implementation
5.1 Format of a Geographic Message
Header
A geographic message header has the following
format and order:
Message ID
(9 bytes)
Port Number (2 bytes)
Lifetime
Flags
[; ;:eq
Area Type
(1 byt::)
followed by one of the following according to the
Area Type:
69
-.,i=j’
, ,- _
0 Type = 1 (Point)
Latitude (8 bytes)
Longitude (8 bytes)
0 Type = 2 (Circle)
Latitude (8 bytes)
Longitude (8 bytes)
Radius
(8 W-1
0 Type = 3 (Polygon)
Number of Points
(2 bytes)
Latitude[i]
(8 bytes)
Longitude[i]
(8 bytes)
Followed by the message data body of arbitrary
length and content. Note that the Message ID is of
the form:
Host Computer IP Address (4 bytes)
Process ID
(4 bytes)
Message Sequence Number (1 byte)
For example, if the geographic destination is de-
scribed by a point, the header would look like figure
3.
Word #l
Me&e ID
6
i (Host Compute Aamwal ---- - __------- z
__-__-_-___--_-_ :- _----_------ --I
2
__-._---
3
Lifetime
4
i Lifetime i
Flags
8
i Y Cwrdinatf of the Point
i
9
I
I
Figure 3: Geographic Routing Packet Header for a
Point Destination
5.2 How the Routing Table is Imple-
mented
The routing table, which is the heart of the geo-
graphic router, is comprised of three main areas:
70
a cache, a polygon describing the router’s service
area, and lists of child and parent nodes.
5.2.1 Cache
In order to allow for rapid access to the individual
cache items while, at the same time, not wasting
memory space by preallocating a set hash table size,
the router’s cache is implemented as a dynamic hash
table with chaining.
Individual cache items are really a three-tuple
<message id, list of next hops, time-stamp>.
The message id, which is copied from the geo-
graphic message packet header, is used as the key
into the hash table. The message id is being used
because it can be stored in a relatively small space of
fixed width. As such, comparisons between message
ids can be done quickly and in a straight-forward
manner. However, it would be better (though more
complicated and computationally expensive) to use
the actual destination polygon itself as the key into
the cache because this would allow the cache to be
used to full advantage. How to do this, though, is
not obvious and future experiments will deal with
this matter.
The list of next hops is a list of those child or
parent nodes to which this router should forward a
copy of the packet to.
Finally, the time-stamp indicates the age of the
cache item. The time-stamp is updated every time
that the cache item is used. The cache is period-
ically checked for stale cache items. Stale cache
items are those items whose time-stamp is older
than some threshold. For the purposes of these
experiments, the maximum age of a cache item is
thirty seconds and the cache is checked every fifteen
seconds for stale items.
5.2.2 Calculating a Router’s Service Area
A router’s service area is, theoretically, the union of
the service areas of its child nodes. However, such
a union may produce a polygon which has internal
“holes” and which may have sections which are con-
cave. Many algorithms which perform polygon in-
tersection, however, require simple polygons which
are convex. Therefore, instead of calculating the
union of the child node areas, the convex hdl W~IS
calculated instead. In order to calculate the convex
hull, all of the polygonal and circular descriptions
of the child node areas were first converted into a
list of points. For circles, geometry was used to find
ten equidistant points on the circle’s perimeter.