rfc2009.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,448 行 · 第 1/5 页

Network Working Group                                 T. Imielinski
Request for Comments: 2009                                 J. Navas
Category: Experimental                           Rutgers University
                                                      November 1996


                    GPS-Based Addressing and Routing

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

IANA Note:

   This document describes a possible experiment with geographic
   addresses.  It uses several specific IP addresses and domain names in
   the discussion as concrete examples to aid in understanding the
   concepts.  Please note that these addresses and names are not
   registered, assigned, allocated, or delegated to the use suggested
   here.

Table of Contents

   1.      Introduction......................................    2
   1b.             General Architecture......................    3
   1c.             Scenarios of Usage: Interface Issues......    3
   2.      Addressing Model..................................    4
   2a.             Using GPS for Destination Addresses.......    5
   3.      Routing...........................................    7
   3a.              GPS Multicast Routing Scheme (GPSM)......    7
   3a-i.                   Multicast Trees...................    8
   3a-ii.                  Determining the GPS Multicast
                           Addressing........................   10
   3a-iii.                 Building Multicast Trees..........   11
   3a-iv.                  Routing...........................   12
   3a-v.                   DNS Issues........................   12
   3a-vi.                  Estimations.......................   12
   3b.              "Last Mile"  Routing.....................   13
   3b-i.                   Application Level Filtering.......   13
   3b-ii.                  Multicast Filtering...............   13
   3b-iii.                 Computers on Fixed Networks.......   14
   3c.              Geometric Routing Scheme (GEO)...........   14
   3c-i.                   Routing Overview..................   14
   3c-ii.                  Supporting Long-Duration GPScasts.   16
   3c-iii.                 Discovering A Router's Service Area  17



Imielinski & Navas            Experimental                      [Page 1]

RFC 2009            GPS-Based Addressing and Routing       November 1996


   3c-iv.                  Hierarchical Router Structure and
                           Multicast Groups..................   18
   3c-v.                   Routing Optimizations.............   19
   3c-vi.                  Router-Failure Recovery Scheme....   19
   3c-vii.                 Domain Name Service Issues........   20
   4.      Router Daemon and Host Library....................   21
   4a.             GPS Address Library - SendToGPS().........   21
   4b.             Establishing A Default GPS Router.........   22
   4c.             GPSRouteD.................................   22
   4c-i.                  Configuration......................   23
   4d.             Multicast Address Resolution Protocol (MARP) 23
   4e.             Internet GPS Management Protocol (IGPSMP).   24
   5.      Working Without GPS Information...................   25
   5a.             Users Without GPS Modules.................   25
   5b.             Buildings block GPS radio frequencies
                   What then?................................   25
   6.      Application Layer Solution........................   25
   7.      Reliability.......................................   26
   8.      Security Considerations...........................   27
   9.      References........................................   27
   10.     Authors' Addresses................................   27

1.      Introduction

   In the near future GPS will be widely used allowing a broad variety
   of location dependent services such as direction giving, navigation,
   etc. In this document we propose a family of protocols and addressing
   methods to integrate GPS into the Internet Protocol to enable the
   creation of location dependent services such as:

     o     Multicasting selectively only to specific geographical
           regions defined by latitude and longitude. For example,
           sending an emergency message to everyone who is currently
           in a specific area, such as a building or train station.

     o     Providing a given service only to clients who are within a
           certain geographic range from the server (which may be mobile
           itself), say within 2 miles.

     o     Advertising a given service in a range restricted way, say,
           within 2 miles from the server,










Imielinski & Navas            Experimental                      [Page 2]

RFC 2009            GPS-Based Addressing and Routing       November 1996


     o     Providing contiguous information services for mobile users
           when information depends on the user's location. In
           particular providing location dependent book-marks, which
           provides the user with any important information which
           happens to be local (within a certain range) possibly
           including other mobile servers.

   The solutions which we present are flexible (scalable) in terms of
   the target accuracy of the GPS. We also discuss cases when GPS cannot
   be used (like inside buildings).

   The main challenge is to integrate the concept of physical location
   into the current design of the Internet which relies on logical
   addressing.  We see the following general families of solutions:

      a) Unicast IP routing extended to deal with GPS addresses

      b) GPS-Multicast solution

      c) Application Layer Solution using extended DNS

   The first two solutions are presented in this memo. We only sketch
   the third solution.

1b. General Architecture

   We will assume a general cellular architecture with base stations
   called Mobile Support Stations (MSS). We will consider a wide variety
   of cells, including outdoor and indoor cells. We will discuss both
   cases when the mobile client has a GPS card on his machine and cases
   when the GPS card does not work (i.e. - inside buildings).

   We will assume that each MSS covers a cell with a well defined range
   specified as a polygon of spatial coordinates and that the MSS is
   aware of its own range.

1c. Scenarios of Usage and Interface Issues

   Below, we list some possible scenarios of usage for the geographic
   messaging.

   Consider an example situation, of an area of land near a river.
   During a severe rain storm, the local authorities may wish to send a
   flood warning to all people living within a hundred meters of the
   river.






Imielinski & Navas            Experimental                      [Page 3]

RFC 2009            GPS-Based Addressing and Routing       November 1996


   For the interface to such messaging system we propose to use a zoom-
   able map similar to the U.S. Census Bureau's Tiger Map Service.  This
   map would allow a user to view a geographical area at varying degrees
   of magnitude.  He could then use a pointing device, such as a mouse,
   to draw a bounding polygon around the area which will receive the
   message to be sent.  The computer would then translate the drawn
   polygon into GPS coordinates and use those coordinates when sending
   and routing the message.  Geographical regions specified using this
   zoom-able map could be stored and recalled at a later time.  This
   zoom-able map is analogous to the IP address books found in many
   email programs.

   To continue with the above example, local officials would call up a
   map containing the river in danger of overflowing.  They would then
   hand-draw a bounding polygon around all of the areas at least a
   hundred yards from the river.  They would specify this to be the
   destination for a flood warning email to all residents in the area.
   The warning email would then be sent. Similar applications include
   traffic management (for example, reaching vehicles which are stuck in
   traffic) and security enforcement.

   Other applications involve general client server applications where
   servers are selected on the basis of the geographic distance. For
   example, one may be interested in finding out all car dealers within
   2 miles from his/her location.  This leads to an extension of the Web
   concept in which location and distance play important roles in
   selecting information. We are currently in the process of
   implementing location dependent book-marks (hot lists) in which pages
   associated with static and mobile servers which are present within a
   certain distance from the client are displayed on the client's
   terminal.

2.      Addressing Model

   Two-dimensional GPS positioning offers latitude and longitude
   information as a four dimensional vector:

              <Direction, hours, minutes, seconds>

   where Direction is one of the four basic values: N, S, W, E; hours
   ranges from 0 to 180 (for latitude) and 0 to 90 for longitude, and,
   finally, minutes and seconds range from 0 to 60.

   Thus <W, 122, 56, 89> is an example of longitude and <N, 85, 66, 43>
   is an example of latitude.






Imielinski & Navas            Experimental                      [Page 4]

RFC 2009            GPS-Based Addressing and Routing       November 1996


   Four bytes of addressing space (one byte for each of the four
   dimensions) are necessary to store latitude and four bytes are also
   sufficient to store longitude. Thus eight bytes total are necessary
   to address the whole surface of earth with precision down to 0.1
   mile!  Notice that if we desired precision down to 0.001 mile (1.8
   meters) then we would need just five bytes for each component, or ten
   bytes together for the full address (as military versions provide).

   The future version of IP (IP v6) will certainly have a sufficient
   number of bits in its addressing space to provide an address for even
   smaller GPS addressable units.  In this proposal, however, we assume
   the current version of IP (IP v4) and we make sure that we manage the
   addressing space more economically than that.  We will call the
   smallest GPS addressable unit a GPS-square.

2a.     Using GPS for Destination Addresses

   A destination GPS address would be represented by one of the
   following:

     o     Some closed polygon such as:

                   circle( center point, radius )

                   polygon( point1, point2, point3, ... , pointn)

           where each point would be expressed using GPS-square
           addresses.  This notation would send a message to anyone
           within the specified geographical area defined by the closed
           polygon.

     o     site-name as a geographic access path

           This notation would simulate the postal mail service.  In
           this manner, a message can be sent to a specific site  by
           specifying its location in terms of real-world names
           such as the name of a specific site, city, township,
           county, state, etc.  This format would make use of the
           directory service detailed later.












Imielinski & Navas            Experimental                      [Page 5]

RFC 2009            GPS-Based Addressing and Routing       November 1996


   For example, if we were to send a message to city hall in Fresno,
   California, we could send it by specifying either a bounding polygon
   or the mail address.  If we specify a bounding polygon, then we could
   specify the GPS limits of the city hall as a series of connected