In order to construct the geographical representation, we need to obtain the latitude and longitude that corresponds to the IP address of each MBone router. The Pablo project at UIUC has also investigated geographic-based network visualization, displaying bars on the globe to represent traffic from the UIUC Web server to individual cities [8]. Under the presumption that most of the client sites are in domains that represent a single location, they used the InterNIC domain database to map the domain name to the location registered in the database when the domain name was assigned.
Since by nature many important MBone nodes belong to transit providers covering a wide geographic area, InterNIC-registered addresses for domain names are not an accurate source of accurate host location data. Hosts of large administrative entities such as backbone providers are often the most critical in building a true picture of network usage. Even client domains, e.g., nist.gov, csiro.au or in2p3.fr, can encompass several different campuses within an organization.
Given the absence of any generally applicable mapping, we have been constructing a database of latitudes and longitudes indexed by IP address and domain name, using a collection of manually intensive methods including the InterNIC database, traceroutes, network maps, Web searches, personal knowledge about organizations and network structure, and personal communication.
Our visualization system itself has proven itself useful in the detection of anomalies in these geographic mappings; clicking on a tunnel in the 3D scene triggers the display of hypertext information about its endpoints, providing a useful feedback loop.
Since it is unlikely in the short term that each network node will be able to self-determine its geographic location, visualizations like this one still depend on parties such as ourselves to build and maintain a database of mappings, or administrators at each site volunteering to provide/maintain current geographic information.
Even with no general automatic solution, the networking infrastructure can facilitate this process by providing mechanisms for the transport and indexing of bindings between network entities and geographic, administrative, and logical location. One of the co-authors (BF) is involved with MBone tool development, and is adding such a reporting mechanism to the next generation of MBone tools in order to facilitate further visualization work. Although these options require that the router administrator manually configure the geographic location during router configuration, we hope that administrators will comply in the spirit of cooperation.
One potential long term solution it to attempt to harness the interest of the Internet community itself. We distribute our database both to assist others performing similar visualizations, and to encourage people that know about particular sites to submit corrections and additions. We have made the hostname-geography database available through the NLANR Planet Multicast Web site [10], This site also houses 3D VRML interactive maps of the current state of the MBone, automatically updated nightly, as well as the tools used to create these maps from the original Cambridge database.