Internet Draft Submission

Internet Draft                                                 Rusty Eddy
Expires August 27, 1996                                           USC/ISI
draft-ietf-rps-location-00.txt                              February, 1996



		Geographic Location Extension to Ripe-181

Status of this Memo

     This document is an Internet-Draft.  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.''

     To learn the current status of any Internet-Draft, please check
     the ``1id-abstracts.txt'' listing contained in the Internet-
     Drafts Shadow Directories on ftp.is.co.za (Africa),
     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


1. Introduction

This document describes two proposals for specifying geographic location
of a database objects such as an Autonomous System (AS).  This
information could be used by mapping tools that provide geographic maps
of the Internet topology.  Two alternatives are documented here, the
first proposal uses a new attribute added to a database object.  The
attribute provides longitude, latitude and size information.  The second
method also uses a new location attribute added to the database object,
this new attribute contains the name of a location object that we
propose.  The two methods describe direct and indirect location
information respectively. 


2. Format of Location String

The format of the geographic ``location string'' or LocString will be a
single string consisting of the latitude, longitude and optionally the
size.  The latitude and longitude are each represented by one to three
integers corresponding to degrees, minutes and seconds, with a direction
appended to the final integers of the latitude and longitude.  If
minutes and/or seconds are not provided values of 0 will be assumed and
size will default to 0, a point.  The directions are north, south, east
and west.





Rusty Eddy              Expires  August 27, 1996                [Page 1]
Internet Draft  Geographic Location Extension to Ripe-181  February, 1996 



For example, the LocString for Irvine, California is:

    33 40 10n 117 49 20w 10m

Representing 33 degrees, 40 minutes and 10 seconds north latitude, and
117 degrees, 49 minutes and 20 seconds west longitude with a 10 meter
encompassing circle.  Informally the LocString would be of the form:

    "LA [MM [SS]](n|s) LO [MM [SS]](e|w) [SIm]"

Where, LA and LO are integers representing the degrees latitude and
longitude, respectively.  MM is an integer representing the number of
minutes.  SS is an integer representing the number of seconds.  The
characters 'n', 's', 'e', 'w' and 'm' are literals corresponding to
north, south, east, west and meters, respectively.


3. Proposals for AS Geographic Location

The following proposals are similar, the first suggests a new attribute
to the Ripe-181[1] aut-num object, the second also suggests new aut-num
attribute and a new ``location'' object.  The following examples use the
aut-num object, however, they may be equally applied to the as-macro,
inet-rtr or route objects as well.  Attributing locations to these other
database objects would provide the geographic topology internal to an
AS, which may represent reality more accurately.


3.1 Direct Location

This method proposes a new aut-num attribute, ``location''.  This
attribute is a single, optional attribute:

    aut-num:       [mandatory] [single]
    ...
    location:      [optional]  [single]

The ``location'' attribute will contain a LocString.  For example, say
AS8800 is an ISP in Irvine, California, it's aut-num could contain the
following:

    aut-num:       AS8800
    location:	   33 40 10n 117 49 20w
    ...


3.2 Direct and Indirect Location

This method proposes the addition of a ``location'' attribute to the
aut-num as in 3.1.  This attribute could directly hold the LocString, or



Rusty Eddy              Expires  August 27, 1996                [Page 2]
Internet Draft  Geographic Location Extension to Ripe-181  February, 1996 
    


the name of a ``location'' object.  The location object could be defined
as:

    location:	  [mandatory] [single]
    loc-string:	  [mandatory] [single]
    descr:	  [optional]  [multiple]
    notify:	  [optional]  [multiple]
    mnt-by:	  [optional]  [multiple]
    changed:	  [mandatory] [multiple]
    source:	  [mandatory] [single]

Using the example in section 3.1, we would have the following:

    aut-num:       AS8800
    location:	   IrvineCA
    ...

and the object ``IrvineCA'' would be:

    location:      IrvineCA
    loc-string:	   33 40 10n 117 49 20w 10m
    descr:	   Example location object in Irvine, CA.
    notify:	   eddy at isi.edu
    mnt-by:	   MAINT-EXAMPLE
    changed:	   eddy at isi.edu 960220
    source:	   EXAMPLE

The loc-name could be any string desired by the creator.  


4. Problems

One obvious problem with using geographic layout inherent to networks,
is that they often span large geographic areas, this is true of many
ISPs.  When attributing a location to an AS, one must pick a single
location to be representative of the AS.  The internal topology of an AS
may be mapped geographically when a location attribute has been added to
the inet-rtr or route objects.


5. Conclusion

The motivation for providing geographic locations was prompted by the
development of the Internet Routing Registry (IRR) visualization tool
(IRRv) as a possible method for topological layout.  Methods for
obtaining the LocString are beyond the scope of this document, however,
it should be noted that RFC 1876[2] specifies a means for containing
location information in Domain Name System.  Also worth noting is a
``Geographic Nameserver'' at http://www.mit.edu:8001/geo, that derives
its information from the Geographic Nameserver database on
martini.eecs.umich.edu.


Rusty Eddy              Expires  August 27, 1996                [Page 3]
Internet Draft  Geographic Location Extension to Ripe-181  February, 1996 



Work in this area will proceed if the community finds this feature
useful. 

6. Thanks

Although we have never spoke, I would like to thank, Juergen
Schoenwaelder (schoenw at ibr.cs.tu-bs.de) for the development of
scotty/tkined, which IRRv is based on and the example geographic layout
script.  Thanks also to Cengiz Alaettinoglu for suggestions that led to
these proposals.


[1] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg,
    M. Terpstra, and J. Yu. Representation of IP Routing Policies in a
    Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam,
    Netherlands, October 1994.

[2] C. Davis, P. Vixie, T. Goodwin, and I. Dickinson.  A Means for
    Expressing Location Information in the Domain Name System,
    RFC 1876, January 1996.


Author's Present Address

Rusty Eddy
Information Sciences Institute
University of Southern California
Marina del Rey, CA 90292
e-mail: eddy at isi.edu