Shu NAKAMAE <firstname.lastname@example.org>
Yuji SEKIYA <email@example.com>
Jun MURAI <firstname.lastname@example.org>
With the growing demands on address space becoming more and more urgent, the use of Internet Protocol Version 6 (IPv6) as the next generation of IP is becoming eminent. Much research is going into the realization of an IPv6 world. Though IPv6 is similar in many ways to its successor IPv4, many factors must be taken into consideration during this transition period.
One such factor is the smooth management of the IPv6 network. As the answer to the lack of address space, IPv6 holds a potential for a network the size of which has never been seen before. The manner in which the network is managed will to a great extent determine whether this huge network will function.
This research has as its goal the creation of a visualization for an IPv6 network as a means of aiding in network management. The objectives of such a visualization would be to
After probing the possibilites of various types of three-dimensional visualization, this research chooses and implements a system of creating a visualization unique to IPv6. In so doing, the smooth management of an IPv6 network is enabled by giving the manager a more coherent grasp of the network and thereby simplifying decisionmaking such as address assignment and allocation.
Many of the merits of Internet Protocol Version 6 (IPv6) have to do with the manner in which the network is managed. This is because most of the problems in IPv4, which IPv6 was created to overcome, were not problems in how the protocol functioned, but in what the protocol was prepared to handle. IPv4 was simply not made to handle networks of the gigantic proportions of today. Many of IPv6's new capabilities were created to handle larger sizes.
One of these capabilities is the manner of registration. The registry system for IPv6 in many ways should mimic that of IPv4, which provides management information through whois. However, as the IPv4 network grew to hitherto unforeseen proportions, even as the need for more address space became more and more urgent, it was evident that the centralized management of addresses was becoming more and more difficult.
IPv6 came about as a solution to the demand for more address space than IPv4 could provide. However, if address management was difficult in IPv4 because of its great size, then address management for IPv6 would be many times that in difficulty. IPv6 would support a infinitely larger, multi-layered network. Registration items such as address prefix, organization name, and so on would have to be kept for each and every organization that registers for an address.
Scalability is another major point of difference between IPv6 network management and that of IPv4. The management of IPv4 was completely centralized, creating an inflexible structure as well as an enormous workload. Not only is such a centralized system impractical to maintain for IPv6, it is impossible. The workload would be much too great to support in any one place. The solution is to make the whole structure scalable through Aggregatable Address Allocation. With Aggregatable Address Allocation, the whole network becomes completely hierarchical on a worldwide scale, with the levels being dictated by the address architecture. The whole system is in turn managed by a distributed registry system placed at various aggregation points.
Aggregatable Address Allocation gives IPv6 a distinct hierarchy (figure 1) embedded within its very address structure. This hierarchy was thus placed as a means to ensure scalability with the new network.
Figure 1. Sample of the IPv6 hierarchy
The 128-bit IPv6 address is split up at predefined levels, defining the heirarchy. The top level is called the TLA ID, standing for Top-Level Aggregation Identifiers, the second level is NLA ID, standing for Next-Level Aggregation Identifiers, and the bottom level is SLA ID, standing for Site-level Aggregation Identifiers.
An example of this is the Widely Integrated Distributed Environment (WIDE) 6bone. The WIDE 6bone is an experimental IPv6 network being run and maintained in Japan. The WIDE 6bone is run under the 6bone JP, a Japan-wide experimental IPv6 backbone. All experiments at the 6bone JP are done under a temporary TLA of 16 bits, 3ffe. A pTLA, standing for pseudo TLA, of 8 bits was set up to act instead of the temporary TLA. From there, as seen in table 1, the NLA portion in the WIDE 6bone has been split up into three layers called NLA1, POP-ID (Point of Presence ID), and ORG (ORGanization ID) each being given an address block of 8 bits, giving them an address prefix of 32 bits, 40 bits, and 48 bits respectively.
|16 bits||8 bits||8 bits||8 bits||8 bits||16 bits|
Under the pTLA 05 assigned to the 6bone JP, the WIDE 6bone run by the WIDE Project has recieved a 01 designation as an NLA1. Under the WIDE NLA1, there are now 9 POP-IDs and 30 ORG-IDs, making a total of 5 layers, from pTLA to SLA.
This hierarchy makes it possible for IPv6 to maintain and run the Internet of the future. However, with the onslaught of data inherent to the large address architecture of IPv6, ways in which to more easily manage thiese data becomes more and more important.
This is where visualizations come in. Visualizations are a means that reduce the risk of human error. They do this by creating an environment that makes the human decision-making process easier. Visualizations allow a user to "see" the information as a picture, which permits a much larger sphere of data comprehension than simple text.
With its greatly increased address space, even if just by sheer size, a full-scale IPv6 network can be considered to be much more complex than that of a conventional IPv4 network. On the other hand, the clear-cut hierarchy allows for the network to be grasped in a very simple, organized way. Whether the network can be handled at the abstract level as a complex and convulsed object or a simple and easily understandable object depends on whether the peculiars of IPv6 are correctly taken into consideration. However, because IPv6 is the successor of IPv4, its hierarchy is often neglected when considering the network as a whole. This can be seen when looking at IPv6 network visualizations that resemble an extremely complex IPv4 visualization. Visualizations should be varied according to the object they depict in order to express their differences. Yet in spite of this fact, network visualizations unique to IPv6 have yet to be created.
The goal of this research is to provide such an IPv6 unique visualization, a visualization designed with the specifications of IPv6 in mind.
The visualization will concentrate on the following points:
This chapter explains the design and concept behind the new IPv6 visualization. It goes about this by explaining the factors that the visualization must express and the process from raw data to visualization.
Conventional two-dimensional IPv4 visualizations simply cannot handle the data influx required to be contained in an IPv6 visualization. However, at present IPv6 visualizations have followed much in the manner of IPv4 visualizations, mainly because the two versions are so similar and because a valid manner of IPv6 unique visualizations has yet to be proposed. The problem is that although IPv4 and IPv6 share many characteristics, IPv6 has many added capabilites that must be expressed in the visualization. In order to support a larger network, IPv6 possesses a much more complex network structure than IPv4.
On the other hand, though the conventional IPv4 visualizations are invalid, any and all means of facilitating its management are necessary and helpful. This is because of the potentially humongous workload inherent in the running of an IPv6 network.
Therefore it is vital that a visualization that caters to IPv6's distinct idiosyncrasies be created.
The obvious solution is to try a completely new approach to network visualizations.
The purpose of this IPv6 visualization is to create a way in which the hierarchy inherent in the IPv6 address architecture becomes at once apparent, as well as to help make the many facets of network management data easily accessible. The hierarchy is deeply related to network mangement, for instance in terms of address assignment policy. However regular topographical information is by no means unnecessary. How then to create a visualization that could handle both? The conclusion is to ceate a three-dimensional (3D) visualization.
To visualize an IPv6 network by displaying both its hierarchy and its topology, a three-dimensional interface is the only one that can be seriously considered. The reasons are manyfold, and while some are merely useful others are vital to the management of an IPv6 network.
The primary problem with visualizing an IPv6 network by conventional means is the lack of ability to express hierarchy. With a network designed to support hierarchy as means of clean and organized address allotment, there is something fundamentally wrong with not being able to see these layers. At the same time, topographical data was not something that could be ignored. The problem was that displaying hierarchical information two-dimensionally creates an extremely chaotic map.
Attempts have in fact been made to express the hierarchy with a conventional two-dimensional topology map, such as is used in IPv4. These entail hierarchical expression by means such as color coding. However these attempts at best convey very little and at worst only serve to make the already convoluted map even more confusing.
For instance, figure 2 shows the network visualization of the experimental WIDE 6bone used at present. As can be seen, even for a small experimental network such as this, the map can become extremely complicated. What is not so evident is that this map shows a network of three different layers. The shaded nodes in dotted lines belong to the highest layer (NLA1), the large nodes in the middle the next (POP-ID), and the small nodes on either side and on top the lowest (ORG-ID).
Figure 2. A 2D chaos
The core reason for a three-dimensional visualization lies here. The hierarchy in the IPv6 network was in fact an added dimension to the conventional IPv4 network. Though the topographical maps of IPv4 could be satisfactorily expressed in two dimensions, IPv6's added dimension of "depth" implied another dimension of 3D (figure 3). A three-dimensional visualization would allow the user to view either only topography, only hierarchy, or both at once, just by the simple means of changing viewing angle.
Figure 3. Topology + Hierarchy = 3D
It is also arguable that because the address itself contains the hierarchy, one has only to look at the address to grasp the layers. However, though it is true that the address prefix of any given site defines the layer it belongs to, the prefix is not at once apparent when looked at. By physically separating the layers in a three-dimensional visualization, it becomes at once apparent whether one is referring to a TLA holder, an NLA holder or an SLA holder.
The creation of a valid visualization is a problem that requires decisions in many different areas. First and foremost, a three-dimensional interface must be decided on. The actual interface will directly influence the manner in which the actual visualization will be implemented. Another major point of consideration is what to display in this visualization and how to display it. The kind of information that would be deemed useful to a network manager must be chosen as well as in which manner to display them to the best effect.
As mentioned before, it was necessary to decide the precise details of what exactly is to be shown in the visualization. How to obtain this information once it was deemed necessary was also an important decision.
The proposed visualization was a visualization at the site level as opposed to a visualization at the end node or leaf level. The objective was to represent the various networks at their various layers and as well as the connection between them.
The information needed to implement the visualization was to be found in the registry system placed at various registry points. Pertinent information such as address prefix, organization name, and routing can all be accessed from the database in this registry system through Structured Query Language (SQL) query.
To further facilitate the understanding of the network presently being visualized for management, the ability to display traceroute results would be included in the implementation. Because the whole implementation has a site level focus, such a display would not help to understand routing within any given site, but it would make any site level network disruptions at once obvious as well as which portions of the network "tree" are presently inaccessible.
As it is the hierarchy that regulates and organizes the large IPv6 network by ensuring its scalability, it was decided that the primary concept of the visualization be in showing the layered tree structure. The secondary goals were to express the topographical structure and peripheral management data and thus justify the use of a three-dimensional interface.
As the goal of this particular visualization was to ensure the visibility of the IPv6 network hierarchy, the two kinds of visualizations that were put into consideration were the Cam/Cone Trees and the Information Cubes.
As both were kinds of visualization slated to the display of hierarchical systems, it became a matter of examining the capabilities of each. The Cam/Cone Trees allowed for perhaps a clearer view of the layered structure while the Information Cube would have the added plus of being able to clearly display related data.
In the end, the Cam/Cone Tree choice won out, and the decision was not a hard one as it won on the merit of its visible layers.The new visualization would be a cone tree, each node would be a site or aggregation point within the IPv6 network. Furthermore, it was decided that the various layers would not only be visible by physical separation, but would also be color coded to enhance distinction. The lines connecting the various sites would represent a kind of connection by means of changing line types as well as color and width, much in the same way as has often been done for IPv4 visualizations.
The visualization would be a cone tree, opening out toward the bottom. Each node would be represented by a sphere posted with its organization name, address, and prefix length. Nodes would be connected to each other, according to their actual network connections, by a thin pipe.
The system would consist of two main parts and three modules. The first part communicates to the registry system to get the raw data for the visualization. The second part processes that raw data to create a Virtual Reality Modeling Language (VRML) script to be read into a browser. A description of the modules will be given in the next chapter.
It was finally decided that the ideal visualization scenario would go as follows: the data to be made into the visualization would be taken from the registry system database through the use of an SQL query, on the basis of the range of view specified by the user. The results of the query would be dumped into a file that would in turn be processed by a translation program and turned into a Virtual Reality Modeling Language (VRML) script. The resultant VRML script now has only to be accessed by a browser to be viewed.
This chapter describes the actual visualization implementation. First the merits of the chosen interface are explained, and from there the actual protocol used in visualization, from the manner in which the raw data are obtained to how they are processed and finally visualized.
The research was done under the 6bone JP and the WIDE 6bone. The 6bone JP, as mentioned in the previous chapter, is an experimental Japan-wide IPv6 backbone. The WIDE 6bone, which is run under the 6bone JP, is an IPv6 experimental network maintained by the WIDE Project. The address registration of the two networks are both managed by the WIDE Project. All data for the research done in this paper were taken from the WIDE 6bone Registry.
Several options were considered as an interface for the visualization. The first was to use Virtual Reality Modeling Language, more commonly known as VRML. Another option was to use some different three-dimensional implementation such as Natto View. The final option was to create a completely new three-dimensioanl interface using Java.
In the end however, it was VRML's already widespread use that was the deciding factor. VRML was versatile enough to present the needed visualization while already being a widely recognized and heavily used interface. VRML also had the added benefit of being a Web-based viewer, which meant that the visualized nodes could be directly hyper-linked to the nodes Web site. By using VRML, the same visualization could be seen on various different platforms and browsers without compatibility problems.
The visualization is, at its most basic level, a kind of client/server implementation. The registry data are held with the various SQL registry system databases. The user accesses the data through an SQL query and this received data are diverted into a file. The implementation then takes the data from that file and, using the information, writes out a VRML script, which when seen on an appropriate browser, shows the visualization (figure 4).
Figure 4. A screen shot of the interface
The implementation consists of three major modules shown in table 2.
|Name of Module||Description of Function||Medium of Implementation|
|Data Collecting Module||collects raw data from the registry||SQL|
|Data Organizing Module||rewrites data into processable form||C|
|Data Processing Module||processes data into VRML form||C|
As the table shows, the first module collects raw data from the registry systems dispersed throughout the network. The registry system for the 6bone JP and the WIDE 6bone is maintained in a database accessible through the use of SQL. The module collects the data and dumps it into a preset file.
The second module then takes this file and rearranges the contents into a usable form, which is again dumped into a file. The final processing module can now turn the contents into VRML, dumping the information into the final file (figure 5). The second and third modules are written in C.
Figure 5. The modules
The Data Collection Module collects the raw data for the visualization and pipes them to a file, in this case called "registrydata.txt". This is done through an SQL query. A basic query produces the name of the organization and its address block for the level that is being asked for. For instance, with the WIDE Registry an SQL query for the information on the NLA1 level will produce nine entries, all under the WIDE Project TLA.
The data now in the file "registrydata.txt" cannot be used as is. Therefore, the Data Organizing Module rewrites the contents to usable form. The SQL query result comes with small embellishments to make the data easier to see. These include labeling and lines. The Data Organizing Module first removes all these excesses. Then it takes the organization name and address block, which are on the same line, and separates them: the name on the first line, the address block on the second. Each hierachical level is separated by a signifier, the word "fin."
The Data Processing Module now takes these data and turns them into VRML. On the basis of the number of occurrences of the word "fin" the module knows how many layers to create. The module also goes through a comparison routine to discover which child nodes belong under which parent nodes. As each layer is drawn in a circle, the spacing for this circle can now be automatically calculated, according to the number of child nodes belonging to each parent node.
This chapter evaluates the implementation described in the previous chapter, and then offers some points of refinement based on this evaluation.
The underlying objective of the visualization is in helping make the potentially enormous IPv6 network manageable. To this end the visualization's first goal was to enable the display of horizontal topographical data of the network or its "spread" while at the same time managing the vertical hierarchical data or its "depth."
The implementation discussed here attempted to do this by the physical separation of the layers. The hierarchical structure was further emphasized by color coordination.
In this aspect the visualization was a success. As the cone tree type of visualization is a direct three-dimensional extension of the now familiar two-dimensional hierarchical tree structure, the network layers were indeed beautifully apparent. As can be seen in the comparison between the two visualizations in figure 6, even when compared with an implementation of an Information Cube, the other hierarchical data expression type explained before, the cone tree approach was better in respect that the layers where evident as such, at all levels within the present scope of view.
Figure 6. A cone tree vs. an information cube
Figure 7. A prototype of the WIDE 6bone in 3D
However due to the characteristic "cone" created by the connection lines between the layers, the topographical data become difficult to view. In this aspect the visualization did not quite come up to the standard as expected and some remedial action must be considered. The obvious answer is to remove the connecting lines and consider another means of showing vertical connection such as color coding.
Another comparison to be made is the difference between figure 2 and figure 7. The virtually nonexistant hierarchical layers in figure 2 are apparent in figure 7, which at the same time does not convey quite the chaotic hassle of the flat visualization.
The visualization also links to each node's site topology map, and can be made to display the address and/or addres prefix. This allows network managers to obtain more information from any one single source than was ever previously possible.
There were many problems that came up during the implementation of the IPv6 visualization. Many were simply hard decisions to make, while others were limitations imposed by the tools being used to create the visualizaiton.
The manner in which to plot the various nodes was one of these. Though the visualization concentrated on the hierarchical aspect of the IPv6 network, the merit of creating a three-dimensional visualization was that both topological data and hierarchical data could be viewed at the same time. The difference hierarchical layer was easily expressed by giving different layers on different values on the Z axes. However, how to incorporate the topographical data at the same time was something to consider.
The difficulty in plotting also had much to do with the limitation of the interface. VRML was chosen as the interface for its already widespread use, and not necessarily because it offered the optimum capabilities. Experimentation proved that though in many ways VRML is indeed a versitile language in which to create three-dimensional images, it was extremely difficult map out irregular shapes.
Another problem was the way in which to handle the scaling of the visualization. Of course VRML provides the ability to zoom in and out as well as to focus on certain points. However this is within the scope of an already created and displayed visualization. If a user after seeing the whole network, now wished to have only a portion of it displayed, then he/she would be required to specify this to the SQL server in another query, run the converter program, and create a new VRML script. In other words the inability to dynamically modify an up-and-running visualization was a problem.
Simple scope was also a problem when considering the scale of the visualization. In the network visualization, the depth of the the hierarchy did not seem to be much of a problem. The numbers of layers are to a certain extent limited and one can always scroll down. However, because of the tree structure used and displayed in this type of visualization, the lower layers would become tremendously wide. So wide in fact as to exceed the limits of the screen when seen up close.
The last major problem lay in the decision of how to handle multi-homed sites. These sites that at once have a single identity at two or more levels should be expressed as such.
From the evaluation above, the first point of refinement would of course be clarification of the network topology view. The topographical view can be greatly improved in two aspects. First, the horizontal view is greatly interrupted by the diagonal lines connecting the adjacent layers. Though the cone tree visualization displays the hierarchy admirably and should not be changed, perhaps it should be modified to show the hierarchical connection in a different manner. Second, the manner in which to plot the topological information itself can be considered as a small field of research on its very own.
As the research progressed, it became more and more apparent that this sort of multifaceted visualization could prove to be extremely useful to network and address management. The fact that hierarchical layers were now apparent meant that the address structure itself was evident. This factor could become useful in situations such as address renumbering. An obvious refinement fo the visualization would then be to create an interface where address renumbering could be done directly through this three-dimensional interface. This would of course add more reasons to change the interface from simple VRML to something with more dynamic and interactive capabilities:
In a world where the spread of the Internet grows at exponential speed, the lack of address space is a dire problem. As the world rushes to solve this problem through the creation of IPv6, many problems surface. One such problem is the management of address assignment as well as of the network itself. The two jobs are made difficult by the sheer size of the network. Another problem is the fact that present day IPv6 experimental networks are managed in large part by IPv4 network managers. This means that the IPv6 network is tied to the concepts of IPv4.
However, IPv6 is not simply a version of IPv4 with a mammoth address space. It has characteristics of its own, which require a completely new outlook. This new outlook is provided by the visualization created in research stated here.
People understand things by the way they picture them. Because of this, visualizations have a great effect on people's understanding of things. With only conventional IPv4 visualizations available for the IPv6 network, IPv6 will never amount to more than a jacked-up version of IPv4. Instead it must become a whole new protocol, a new world unto itself, something to completely replace IPv4. IPv6 unique visualizations will help IPv6 to attain this status.
The research stated in this paper explores the differences in the two versions of IP and strives to create a visualization that reflects these differences.
In conclusion, the results of the visualization can be said to be a success. The hitherto hard to distinguish hierarchy was indeed well marked out. Compared with the conventional flat layout, the new three-dimensional visualization allows for a true understanding of the new IPv6 network and its structure. The manner of address assignment and network management information are at once easily understood and readily available.
Unfortunately with the topographical side still left as a project for further improvement, the results cannot be called a complete success. However that the present state of visualization in IPv6 management was sadly lacking is an indisputable fact. The road to understanding IPv6 must begin somewhere. The visualization presented here in this research has shown ample results to pave the way for clearer, more useful visualizations and therefore understanding of the superstructure that is an IPv6 network.
With this new visualization, the IPv6 network becomes a sphere of space that can be easily navigated, instead of the daunting jungle it could easily become. Address assignment and network maintenance will become more manageable and will continue to be manageable even in the face of an ever-expanding IPv6 network.
 S. Williamson, M. Kosters, D. Blacka, J. Singh, and K. Zeilstra. "Referral Whois (RWhois) Protocol V1.5." RFC 2167, June 1997.
 R. Hinden, M. O'Dell, and S. Deering. "An IPv6 Aggregatable Global Unicast Address Format." RFC 2374, July 1998.
 R. Hinden. "Proposed TLA and NLA Assignment Rules." RFC 2450, December 1998.
 Peter Young. "Three Dimensional Information Visualisation." Visualisation Research Group Centre for Software Maintenance,Department of Computer Science, University of Durham, http://www.dur.ac.uk/~dcs3py/pages/work/documents/lit-survey/IV-Survey/index.html, March 1996.
A. Kawai, Y. Kawanishi. "VRML Nyuumon." Gijyutsuhyouronsha;7/97; ISBN: 4774104655.