TOGETHER: TOpology GEneration THrough HEuRistics

School of Electronic
Engineering and
Computer Science
MSc FT Wireless
Networks (Networks
Pathway)
Final Report
TOGETHER:
TOpology
GEneration
THrough
HEuRistics
Subin Abraham
Mathew
Date: 28th August 2012
1

Disclaimer
This report, with any accompanying documentation and/or implementation, is
submitted as part requirement for the degree of MSc FT Wireless Networks
(Networks Pathway) at the University of London.
It is the product of my own labour except where indicated in the text.
The report may be freely copied and distributed provided the source is
acknowledged.

Acknowledgement
I take this opportunity to sincerely show my gratitude to a number of indi-
viduals who have surrounded and encouraged me during this period:
Firstly my supervisor Prof. Steve Uhlig, who has keenly looked upon me
and my work providing ample motivation right from the start and constant
feedbacks and helped me understand the nature of this project and its appli-
cations in details. His comments and ideas have been highly valuable to the
slightest detail. I am very grateful for the openness he showed me and by the
manner which he trusted me to complete the project and bring out new idea.
I am so glad that encouraged me to setting my targets high and bring out
the best in me. Dr.Vindya Wijeratne who stood alongside, motivating and
getting the timely help that I needed to complete this project. She has been
there from the start to guide me to using the right tools and giving me the
right contacts to get through all roadblocks that this project encountered.
Mr Tim Kay with whom it was a pleasure discussing the topic and
progress of the project at each phase. He was able to help me time and
again to deal with the issues and bugs that occurred to JUNOS.
My Dad, Mum and Linta without whose encouragement i would not
have made it this far.They have been constantly upholding me in prayer
and strengthening me with hope. I thank my sister for helping me sort out
the report in time and in a presentable manner. I owe this work and my MSc
to them entirely.
To Mervin and Roshen who like brothers, helped me in compiling the
report.
My colleagues Chi Qing and Syed Haider who also worked the same
project and had helped in the evaluation of TOGETHER.
And above all to My Lord and saviour Jesus, my God who has been there
throughout, through every tear and smile, giving me wisdom and patience
to complete this project with conﬁdence. He has been my constant light and
strength and i give Him all the glory and honour for all my achievements and
success.

Nomenclature
TOGETHER TOpologies GEneration THrough HEuRistics
ANK AutoNetkit
AS(s) Autonomous System(s)
BA Barabasi-Albert Model
BGP Border Gateway Protocol
CAIDA The Cooperative Association for Internet Data Analysis
CPU Central Processing Unit (Computer)
GML Graph Modelling Language
GraphML XML based Graph Modelling Language
IGen IGen Topology Generator
IGP Interior Gateway Protocol
IS-IS Intermediate System To Intermediate System Routing Protocol
ISP Internet Service Provider
IXP Internet exchange point
JUNOS Juniper’s Network Operating System
Nec Network cartographer
Olive An identical model of JUNOS
OSPF Open Shortest Path First
PoP Points of Presence
yEd yEd, a software from yWorks

Abstract
Network Virtualization is a growing technological process that combines the
hardware and software elements in the physical networks and brings it to-
gether on a software level. The aim of this project is to develop the process of
deploying virtual networks easily. The project involves a software developed
by us called “TOGETHER: TOpology GEneration THrough HEuRistics"
written in Perl in its simplest form without dependencies so that it could be
deployed on any environment. TOGETHER is an isomorphic graph mod-
elling solution used to allow users to make use of topology generators and
software like AutoNetkit to make topologies that work on virtual systems.
TOGETHER is designed to work in Juniper Networks Virtual Private Cloud
architecture and has possibilities for supporting much more. TOGETHER
also manages how multiple topologies are interconnected and aims to help
researchers work with network virtualization.

Contents
1 Introduction 1
1.1 Context for studying the internet . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 State of the Art 4
2.1 Obtaining Topology Models . . . . . . . . . . . . . . . . . . . 4
2.1.1 Using Known Maps . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Using Traceroute . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Using Topology Generators . . . . . . . . . . . . . . . 6
2.2 IGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Emulations . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3 Virtualization . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 AutoNetkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 So where does this lead us? . . . . . . . . . . . . . . . . . . . 13
2.6 Junos, Junosphere and Juniper . . . . . . . . . . . . . . . . . 14
3 TOGETHER 15
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Need of TOGETHER . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Understanding Isomorphic Graphs . . . . . . . . . . . . . . . . 16
3.3.1 Isomorphic Graphs . . . . . . . . . . . . . . . . . . . . 16
3.3.2 Generating Isomorphic models . . . . . . . . . . . . . . 17
4 Program Design 19
4.1 Connecting Diﬀerent AS Together . . . . . . . . . . . . . . . . 21
4.1.1 Implementing Inter-domain Connectivity in TOGETHER 23
5 Evaluation of TOGETHER 24
5.1 Working with Isomorphic Graph Generation . . . . . . . . . . 24
1

5.1.1 Using IGen . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Working with Multiple Topologies . . . . . . . . . . . . . . . . 27
5.2.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 27
6 Discussion and Future Work 30
7 Conclusion 32

Chapter 1
Introduction
The Internet today has brought the world closer and plays a prime contribut-
ing factor to human development, knowledge transfer and globalisation. To-
day, there are more products that work on the internet cloud than elsewhere.
This vast internet in real is typically a huge collection of networking hard-
ware elements and databases located across the globe. As the demand of
internet increases the network providers are faced with challenges to main-
tain the network service with high expectations. To alleviate the challenge,
a thorough understanding of the network is required by network providers.
Also, as the networks multiplies, the demand for future applications further
increases.This has drawn the attention from the telecommunication industry
and researchers to further study the internet.
1.1 Context for studying the internet
Haddadi [10]states that the need for research in the structural properties of
internet is essential to prevent failures, correct faulty connections, improve
the routing between nodes, analyse the growth of the networks and thereby
assisting in future network planning. However, its actual practise is more
diﬃcult .Researchers classify the entire network to be made of either one of
the two kinds of networked links, namely, transit domain and stub domain.
The stubs are groups of network routers or devices that belong to a certain
organisation while the transit resembles more or less the backbone that con-
nects the stubs one to another. Now, designing such a model without a clear
picture is exhausting.
One must have means and methods that tell what the internet is and how
it can be studied eﬀectively. The issue does not end in understanding the
overall picture of the internet, but furthered by the individual areas or points
1

of interests of the network. This confirms that its understanding can be
limited as and when represented by a mathematical formula. This emphasis
the means to individually inspect the network elements and further modify
them in a closed environment .This translates into developing a duplicate
model of the internet handy which is not feasible due to the costs involved.
And ultimately the alternative is to have means to design a network that
represents the real internet. This will enable it to be workable with the
ability to amend in a safe manner without any effect to the real network.
The predicted results would otherwise represent the actual results from the
real network.
The internet has been studied on various aspects but it is still unclear how
does the internet functions as overall. In many studies that concentrated on
the core, the edges of the internet were not considered. Also in many studies
that took intra Autonomous System (AS) routing into consideration did not
concentrate on the impact of core networks. But this may not be the case
for the real internet.
In a study conducted by Mühlbauer, Wolfgang et al [17], to study the
structure of internet, they discussed that the routing in the internet is a result
of policies that are decided locally by different Autonomous Systems (ASs)
and the effect of router level topologies inside the Internet and structure or
size of ASs. This was done by running multiple simulations using C-BGP
simulators. In their study, they had to restrict the complexities of the network
because of the time constraints and the size of individual configuration files.
This shows one of the main constraints of network simulators. Another key
element the study described that was a road block to obtaining more accurate
results was the generation of complex network topologies. To be able to do
this, they had to reduce the number of ASs and had to keep rebuilding the
topologies over and over again.
From Mühlbauer, Wolfgang et al [17] it is understood that the internet
is more dependent on the stubs than the transit nodes. Also, in a related
paper by Mühlbauer, Wolfgang et al [18], they discussed the presence of
quasi-routers which need not make routes based on how a certain transit
node sees the network, but also depend on the path taken by adjoining AS
nodes. This shows that the core properties are not as simple as they were
thought to be. This is an important aspect in networks. These properties
would affect the time the packet takes to travel between ASs and also, impact
business policies that require a specific routing of packets.
Another factor that was assumed in the study of internet was the pres-
ence of Internet Exchange Points (IXP). IXPs are sometimes assumed to be
dormant in data transit, but from a study by Ager, Bernhard et al [1] in
2011, showed the active presence of IXPs. This research, showed that IXPs
2

play an important role in changing the path taken by data packets. This
also is an important element that was overlooked for years the internet has
been studies. In order to study this, we cannot rely on simulations as the
nature of IXPs are dependent on the nature of the ISPs and also on the very
equipments that IXPs are build on.
1.2 Motivation
From recent studies, it is clear that to study the internet we have to consider
the overall picture of the internet. It is essential to consider the core nodes,
the transit nodes, the gateway , area and the stub nodes which is a really
complex architecture to be simulated.
But as with any technology, there is a need means to connect the model
of the internet to the platform we wish to work on. So there is a need of a
platform converter. The need of this converter is so that any topology maps
could be run on any system.
Herein lies the potential of the software TOGETHER which can be tapped.
The software TOGETHER manages to ensure that topologies that are gen-
erated would work on virtual networks. TOGETHER relies on AutoNetkit
to make desirable ﬁles that could be portable to virtual systems. Thus,
TOGETHER enables to provide means for multiple topologies from various
sources to be deployed on virtual systems easily.
3

Chapter 2
State of the Art
2.1 Obtaining Topology Models
In order to study the internet, it is understandable that a model of the inter-
net is required. There have been various researches done in this field to map
the entire internet. This would have been easy in 1980’s when the internet
was less than 100,000 nodes. The internet has grown over the period of time
and now after just 3 decades the internet is prodigious and the overall archi-
tecture is uncertain. However, because internet is more or less transparent at
core than at stubs, researchers have been able to predict and develop approx-
imate graphs that describe the internet. There are different means to obtain
the model of the internet, but this paper concentrates on three methods that
could be viable to obtaining the models accurately. One of the most obvious
questions a layman would ask when discussing the architecture of internet is
“ Why not ask the makers?”. The internet is a product that almost everyone
who have lived or living in the 21st century have contributed. Some have
played very significant roles while others have answered surveys. So, there is
no one who has the sole ownership.
2.1.1 Using Known Maps
The best alternative is to ask the ISPs and network management companies
to share their information about the network under their control. From those
who contributed to providing this knowledge, collections of topologies have
been added on to various public and research schools.
One such collection is the Internet Topology Zoo, [12]. This is main-
tained by the University of Adelaide. The Intenet Topology Zoo has many
topology maps that are downloadable as GRAPHML or GML files . The
Internet Topology Zoo also maintains links to various other sources that do
4

similar work like The Internet Topology Collection [27] which is maintained
by the University of California, Los Angeles and CAIDA. Although there
are other websites, that offer similar results, the paper concentrates more on
the models that have been generated by the Internet Topology Zoo, because
of AutoNetkit, a product described in the section 2.4 developed by Simon
Knight, who is one of the “ zoo keepers". The software TOGETHER is not
limited to the topology zoo, but has been exhaustively tested with various
graph representation from the zoo.
2.1.2 Using Traceroute
The next method is a hack or a work around model. The method to get
a network information if not available is to test it exhaustively. This could
be easily done by using the networking tool available on most consumer
computers called traceroute.
One could run traceroute for number of days from various sources to
a single IP locations and generate traceroute dumps. Most of the time,
traceroute dumps that have been done from an ISP end are not very reliable
as the visibility of the entire network is often limited. However, there have
been some researches that have stood out and have produced good results.
To understand this, a knowledge of traceroute is required. Traceroute is
a network diagnostic tool that sends multiple Internet Control Message Pro-
tocol (ICMP) packets to a destination with increasing Time To Live (TTL).
The first time, the TTL is set as one and it reaches the first hop to the
destination. The TTL is reduced and an ICMP time exceeded message in a
IP packet is sent to the source. Then the source increments the TTL by one
and sends it to the destination. The packet reaches the first hop in the route
to the destination and the TTL is reduced by one. Then it goes to the next
hop, the TTL is reduced by one again. In this manner, the ICMP packet
proceeds in the route selected by the routers till the TTL is zero. Once it is
zero, it an ICMP time exceeded packet is sent to the source. In this manner,
over multiple increments of TTL, the path is discovered.
One of the most earliest tool as described by Haddadi [10] is the Mercator
introduced by Govindan et al [8]. A few models that are considered notewor-
thy was the network cartographer [14] (nec) and rocketfuel [22] models. Both
these models have adequate results. Nec and rocket fuel uses traceroute b
servers to run the traceroutes.
Rocketfuel outputs could now be converted to GML or the Graph Mod-
elling language model with the use of tools provided by Topology Zoo toolsets
[12]. Rocketfuel also has a graphical plot of the traceroutes that map to ge-
ographic location. They use “Geoplot”,a Java web applet developed by the
5

Cooperative Association for Internet Data Analysis or the CAIDA to do this.
2.1.3 Using Topology Generators
There have been number of software solutions for modelling network topolo-
gies. Some key software solutions that have shown significant results in re-
search in generating topologies are GT-ITM [24] from Georgia Tech, Inet [11]
topology Generator from University of Michigan, BRITE [16] from Boston
University and IGen [11] from University of Louvain-la-Neuve and Université
de Mons.In order to better understand the generality of TOGETHER and
that of IGen, an understanding of network topology modelling is important.
Most researchers [25] consider the first software solution widely used to
making network topology automatically was build by Waxman, [26]. The
Waxman model uses Erdos-Renyi model to generate graphs, but as Medina,
Alberto et al [16] describes in their paper, the Waxman model selects the
interconnections based on the location of nodes on a reference plane that is
created by the Waxman by using probability theorems. This is not considered
as an efficient modelling.
Another topology generator that was of interest was the GT-ITM model.
This model is also called Transit-Stub model of network. In this at first some
random graph is generated and nodes are made. Every node is considered
as a separate transit domain, and so they are replaced with a predefined
topology of the domain. This is effective in order to see the whole network
picture, but when elements of interest like managing between AS is concerned
the visibility of network is limited.
Tiers [5] by Doar,Matthew was another model that was similar to the
Waxman model. In the Tiers topology generators, the nodes were placed on
a plane and initially WAN networks were created and connected by using
minimum spanning tree theory and the edges were connected based on the
Euclidean distances. Then MAN networks were created and then LAN net-
works were created. This model does not capture the core features of the
internet.
Inet 1.0 had been build to generate topologies randomly for research
purposes that satisfied real network scenarios. It relied on power law to
select nodes and determine edges. The newer model Inet 2.0 based is more
selective in choosing nodes.In the paper introducing Inet 2.0 , it is argued
that the Waxman, Tiers and GT-ITM did not follow the power law stating
that the models generated by those models were obsolete when compared to
real networks [11] as the networks keep increasing.
BRITE is a network topology generating tool from Boston University
that generates topologies based on Waxman’s model in some cases and Barabasi-
6

Albert’s model in other cases trying to implement power law model thus re-
lating it to growing internet topologies [16]. The Barabasi-Albert’s model
connects new nodes to older nodes that heavily linked than nearby nodes
that are loosely linked.
Although the above two models (Inet and BRITE) propose means to
generate random topologies, they rely on probabilistic algorithms to link
nodes. Tangmunarunkit, Hongsuda [23] et al argues that topologies like
BRITE that follow power law, though may be good in capturing large scale
networks with over 1000 nodes better than structural generators like Tiers,
they tend to be meaningless in case of small topologies consisting around 50
nodes. They stated that it was better in cases where study of small networks
were required that structural generators were to be used.
In Highly Optimised Tolerance (HOT) [3] the generation of topologies
are said to rely on various factors such as efficiency, robustness, performance
and incorporates specialized and structured configuration. A related study
by Alderson, David et al [2] say that over the use of Highly Optimised Tol-
erance models (HOT), Heuristically Optimized Trade Off (HOTo) models
proposed by Fabrikant, Alex, et al [6] is more efficient in producing an ac-
curate network representation. They state that the Heuristically Optimized
Trade Off (HOTo) model could generate various topologies from star to from
tree by modifying the relative importance between connectivity distance and
node centrality . Also, on fine tuning these parameters, they claim that the
degree of node distribution could be changed to represent more classic means
of representations like exponential and power law.
Haddadi, Hamed et al [10] state that topology generators need to capture
the dynamic nature of today’s internet such as “ peering relationships, inter-
nal AS topology and routing policies ”. They state that the internet should
not be seen as wholly dependant on power law modelling of the network with
transit-stub models.
From the paper it is clear that on deciding a software solution to represent
Internet topology, some elements should be kept in mind. The first thing is
that the internet today, although had exponential growth, the architecture is
not random but a result of careful design, with some limitations like geogra-
phy, technical and business constraints. The second advice is that the focus
should be given both on core nodes as well as the Points of Presence (PoP).
This indicates a need to have an end-to-end topology generator, that unlike
Tiers, Waxman or GT-ITM does not rely on placing nodes in random but
does that with reason and joins the edges to the nodes with an understand-
ing. Also, that this topology generator unlike BRITE or Inet, do not rely on
power law to generate topologies as these laws do not account for the nature
the networks were made and connected.
7

Other studies from Tangmunarunkit state that there is a need for struc-
tural generators, but as said by Fabrikant, Alderson, Haddadi et al, the
topology generator must have some heuristic understanding of the real net-
work, the location of routers, an idea of their location, interconnectivity and
point of presence.
Quoitin, Bruno’s [21] topology generator is called IGen. Haddadi, Hamed
et al [10] state that “IGen aims to realistic ISP topologies, and allows those
topologies to be interconnected like real AS might be”, however the choice
of connecting different ASs together is not solved.
For these reasons, this paper have chosen IGen as an apt candidate for
generating topologies that could be used to work with virtual systems and
would be beneficial to work with it in helping researchers understand the
networks better.
2.2 IGen
So, what is IGen? In a nutshell, IGen [20] allows the user to select a location,
generate N number of nodes in the area and in a heuristic manner, connect
these nodes. This is done in the following manner. Quoitin states that in
designing a network to study characteristics of the internet, the four most
fundamental elements are network design, geographical location, network
provisioning and selection of paths. IGen is a structural topology like that of
Waxman and GT-ITM or Tiers. However, IGen is different as it is a router-
level topology and takes into consideration the four parameters that Quoitin
states that are viable to real internet topology.
Let us examine those four parameters and understand the generality of
IGen. The first parameter is location. IGen could import nodes that have
been mapped to real locations on the earth like geographic coordinate sys-
tems. Another means is to generate random nodes in selective polygons that
represent the world in a mercator projection like manner. Another proposed
model is using IP geolocation databases to get the approximate locations.
Due to the scope of this project, I would consider the second case only. IGen
selects nodes and places them on the world map. The figure below a screen-
shot of the polygonal world map.
Then, IGen, selects nodes to represent PoPs and from them IGen selects
the nodes that are to be part of the backbone network. It builds the PoPs
and then the backbone network. All these could be said to be part of network
provisioning and network design. Also IGen has methods to introduce link
capacities from 34Mbps to over 10Gbps. Once this is done, it also allows
provision for iBGP links. Usually, PoPs are selected in order to avoid link
8

Figure 2.1: IGen Polygons
failures and provide redundancy. The backbone network is the could be
selected to be designed by the user on the basis of some heuristic models.
The available models are shown in the table below 2.2 with models graphically
represented in the figure 2.3 below.
Figure 2.2: Table showing various models IGen uses
A very interesting example is shown in the figure 2.4. A 10 router
model in Africa and a 20 router model in the Eurasian region we created by
IGen. Then both of these separate domains were connected internally using
minimum spanning tree model and then they were connected to each other.
From the figure 2.4, it is seen that 10G backbone network has been made to
connect Eurasia internally, and the African continent internally. Then the
Eurasian network was connected to the African network by IGen and found
that IGen chooses the most obvious connection that is commonly used in
today’s network, the Mediterranean region.
9

Figure 2.3: IGen Models [20] Page 5
Figure 2.4: Working of IGen
10

IGen is a Perl based program and uses the Tk module for GUI. It was
funded by the Waloon Government and is a part of TOTEM project. The
TOTEM project was initiated to build TOols for Traﬃc Engineering Meth-
ods. IGen saves its output in various formats, but in this project the chosen
format is GML or the Graph Modelling language model.
To summarise this chapter, it is understood that although the internet as
whole, grows exponentially, it is a result of careful planning. To study the in-
ternet, we need models that follow this understanding. These are compelling
reasons to select IGen, as a suitable candidate for this project in order to
generate topologies.
2.3 Platforms
2.3.1 Simulation
Once the topologies have been mapped, to study the topologies we have to
use some kind of system. Today there is a large source of software that is
useful in understanding network modelling and network function. These are
called network simulators. In a network simulator, the entire network could
be modelled in the software. These models can be tested on various elements
like routing, performance and traﬃc analysis. Some of the well-known simu-
lators are Network Simulator (NS), OPNET, NetSim. Software like OPNET
allow users to study the devices like routers, protocols and understand their
applications. Another well-known network simulator is NS or Network Simu-
lator. NS has a large number of modules that are commercially developed for
wired and wireless network and has shown considerable interest in researches.
However, there are many reasons why this is not apt for real networks.
The simulation environment is often a closed environment and therefore there
is no possibility of introducing changes that the provider has not thought of.
This is not ideal in cases where users want to study more than routes or path
but work with injecting data and working with interfaces and hardware. This
is what researchers are interested in, ie to work with data planes. From the
study with C-BGP conducted by Mühlbauer, Wolfgang et al [17], it is clear
that to make a model of the internet, with at least 30000 nodes, there are
limitations. Therefore using simulations are not advantageous when detailed
understanding is required.
11

2.3.2 Emulations
Network emulators are more better than network simulators. They contain
an image of the real Operating system that runs on the routers, switches and
bridges and produce better results. Some common ones are Netkit, GNS3
with Dynamips. GNS3 could run Cisco IOS, Juniper JUNOS and produce
better results. They allow the better use of hardware and software. Most
emulators however, do not have direct access to the hardware resources of the
host system. They mimic the hardware and run the using software simulate
hardware. Also, emulations depend heavily on the emulation platform to
compute data and so may slow down the process and may give erroneous
data.
2.3.3 Virtualization
In virtualization the system is dedicated to run virtual machines that have
access to the core processors and perform tasks that a real machine would do.
In a virtualization environment, every virtual machine is given access to the
system resources and monitored by the hypervisor. In this manner, not only
the hypervisor allows the VMs to run the operating systems that run on the
real routers, but also provide ways to have them work with all the resources
like network connections,CPU handling, data handling independently. Since
each VM is given independent control to the CPU, it could be said that
it less likely that if a VM crashed, it would aﬀect the entire machine. In
some virtualization environments that run network connections, the routing
is done by using VLAN tagging between each VM that is connected so that it
replicates how the actual LAN works. There may be VRF labels on interfaces
so that the VLAN are properly mapped. One drawback is that since all the
virtual systems are really close, delay between networks cannot be calculated.
From these reasons, it can concluded that in order to understand the net-
work characteristics properly, the best alternative is to build a mock model
of the network. However, owing to the limitations in time, eﬀort, and money
involved, the best alternative is to run Virtual Machine on a dedicated sys-
tem.
2.4 AutoNetkit
It is seen from the previous sections 2.1 that various network topologies
could be generated. In the section 2.3 it is seen that in order to study the
internet, there is a need to process the network models in some network imita-
tion software like simulators, emulators or virtualization platforms. Network
12

imitation software needs the files that specify the overall model rather than
the topology maps. To make such files is time consuming and the user must
take extreme care to know the nitty-gritty of the software that they wish to
deploy their network model to study on.
AutoNetkit by the University of Adelaide and the University of Loughbor-
ough is a novel concept that manages this transition. In the paper by Knight,
Simon et al [19] describing how AutoNetkit works, they tell about the plans
to have the AutoNetkit tool (ANK) to support many network emulators and
simulators.
ANK was initially built to support Netkit in order to produce the resul-
tant files that could be used on Netkit to setup a network. This was later
improved to work with Juniper platform and they plan to develop for Cisco’s
IOS platforms.
The current version of AutoNetkit supports [13] C-BGP, Dynagen/GNS3,
Junosphere and Netkit and does make the relevant models and also plots
them in HTML format using the python package "networkx". Since ANK
does this job with ease, we have used this to generate the required configura-
tion files for the Junosphere emulator. AutoNetkit is written in the python
language and is available on the python package index.
2.5 So where does this lead us?
From the previous sections, it is understood that there are various sources
that allow us to get a map of the internet and also have seen a number of
software solutions that hack the system or generate topologies based on re-
searches. Once this topology is selected, it could be processed on a simulated
system by either drawing this topology if it is a GUI based software or with
the help of configuration files in case of emulators and virtual machines. An
example of this is WinNet [4]. It uses GT-ITM and connects the models to
NS with an independently developed module called Wave. However, due to
several limitations in GT-ITM models and NS this model does not satisfy
the need we addressed. So, TOGETHER tries to combine some of the bet-
ter resources, in producing results that would benefit both researchers and
enterprises in generating topologies and thereby enable better results.
So, in this project IGen is chosen as the topology generator, and the soft-
ware TOGETHER is used to bridge the models from IGen to AutoNetkit
with some parameters introduced. These parameters have utilised the intel-
ligence of AutoNetkit in generating topologies that work with Junosphere.
The system that was used to test TOGETHER is described below. The
working of TOGETHER is described in later chapters.
13

2.6 Junos, Junosphere and Juniper
At QMUL we have worked on a Junosphere machine that could host various
Juniper VMs. The system allows users to host up to 75 routers with ease, but
this ﬁgure could be tweaked. This is similar in the manner of design to the
Juniper online product called the Juniper Classroom, which is hosted in the
cloud that enables users to setup, study, modify, and run various topologies.
A main feature is that the virtual machines could run multiple operating
systems and so, we were able to run VMs that work accurately. Since this
was an experimental model from Juniper, it was slightly diﬀerent from the
commercial cloud versions. We were able to test and work with the system
after understanding some glitches and manually overriding them.
All VMs ran the JUNOS Operating system which is a network operating
system. This way every VM represented a router. The images of these
routers were similar to the Olive based models. All the LAN connections
were connected with VLAN tags.
14

Chapter 3
TOGETHER
3.1 Introduction
It is understood that in order to have an understanding of the internet there is
a need to have adequate research methods. We have discussed various means
researchers have tried to generate models of the internet and how different
methods of obtaining these models are relevant. We have discussed that the
key element in understanding the internet is the availability of graphs.
3.2 Need of TOGETHER
The elements that have seen discussed so far are the IGen to generate graph,
Virtual Systems, and AutoNetkit to make configuration files. The need of
this project is to bridge software solutions so that they work with each other,
providing researchers a tool that could be used without them having to work
with the intricacies of managing various files or worrying about the need
to convert files or amend files to have more functionality. This matter is of
concern as some times the user would like to use topologies that are generated
by IGen, other times the user may want to study the network performance
and so may have got the models from topology zoo. Both these models are
very different and usually in order to have them work with ANK, either the
user has to manually convert line by line the files between formats or at
other times modify the files to a large extend by either adding details that
are irrelevant in real networks like size or shape of the node so that programs
like yEd accept the models. This is the key feature of TOGETHER. It is
used to generate isomorphic models of the network. This method is described
in the following chapter.
15

Figure 3.1: Graph A and Graph B
3.3 Understanding Isomorphic Graphs
3.3.1 Isomorphic Graphs
In graph theory, two graphs are said to be isomorphic if they have nodes
that preserve their edges. This is called “edge-preserving bijection” where
the edges between nodes are kept unchanged. This is shown in the figure
below.
In the figure 3.1 below, (drawn in yEd), we represent two graphs. Graph
A is the one on the left with alphabetical notations for nodes. Graph B is
the one the right with numerical notations. Now, both graphs look different,
but on looking closely, we find that they have the same number of links and
similar nodes are connected to each other.
Let’s observe node-1 and node-a. Node-1 is connected to node-2, node-4
and node-6. Node-a is connected to nodes "b","d" and "f". So, If we were
to plot a relationship between both models, we could state that node-a is
similar to node-1. This is shown in the table 3.2 below. Now since the two
models are said to be Isomorphic they could be represented as A B.
This is done by not considering some features that were in Graph A
and Graph B. When TOGETHER is executing the generation of isomorphic
16

Figure 3.2: Isomorphic Mapping
graphs, some features are not considered. This is explained in the following
section.
3.3.2 Generating Isomorphic models
In the previous section we defined what isomorphic graphs are. TOGETHER
tries to generate similar models. We have decided to make isomorphic models
of the GML files they contain network topologies because the graphs could
have been generated from various sources and may contain a lot of relevant
and irrelevant data. A certain form of intelligence is required to separate the
files into relevant and irrelevant contents.
We have taken the nodes and edges as relevant information and discard
the rest as irrelevant. This considerably reduces the size of the topology file
while keeping the basis for Isomorphic models strictly followed.
In the generation of plots say using IGen we have used spatial notations.
This was useful in placing the nodes apart do that they could be made
into PoPs and then connected to the backbone network. But now this is
generated, do we really need spatial locations? This decision depends on
factors such as what we are going to do with the GML file. In our case, we
are trying to study the network properties by running virtual routers. So, in
running virtual routers, the element of location would not play a major role
as virtual systems cannot at present take into consideration latency due to
geographic location. Also IGen adds value like the delay and edge properties
like bandwidth which cannot be used in VMs at present because they do not
support.
Most models have nodes shaped as circles, squares or ellipses. This is not
considered to be relevant as this does not impact ANK in developing good
graphs. So, for the sake of simplicity, we have avoided these parameters.
Now, the question that would arise is if such selectiveness is done, would
the outputs represent faithful topology representation models that were given
at the input? We conducted a number of tests and we have taken some of
the results and explained them in the section 5.1.
17

In Summary, we have tried to generate Isomorphic models of the real net-
work topologies that are obtained. We have considered the basic elements
such as the nodes and their respective edges as important information. De-
tails introduced by various software that make GML ﬁles, like shape of nodes,
etc have been overlooked as they do not impact the manner in which ANK
would generate the output. More importantly a virtual machine server that
could run router VMs do not care about such data.
18

Chapter 4
Program Design
In this chapter we would like to explain the challenges faced in the creation
of TOGETHER and the flow diagram of TOGETHER. In this section, we
would like to introduce the overall picture and explain why some choices were
made and also dive into the user support documentation of TOGETHER.
In the end we also discuss some means has been used to connect multiple
networks and the reasons behind it.
TOGETHER has also provision to run AutoNetkit automatically, based
on some commands, and currently supports the JUNOS system. TOGETHER
allows users to have selective outputs to help with researchers at QMUL pro-
cess the topologies, which could be expanded. Finally TOGETHER allows
user to view the plot if they had decided to plot with ANK.
The following diagram shows the above-mentioned process. The process
is explained more in the following sections.
Figure 4.1: Overview Of TOGETHER
Formats and Choices
A simple understanding of GML and GRAPHML is intended in this sec-
tion. GML files are better structured graph modelling file. They are easily
readable by any novice user. However GRAPHML is an XML based model.
ANK uses a module from python called "networkx" to read and interpret the
19

models. GML is a chosen because of legacy and the fact it does not confuse
someone who has no idea of XML if the file is opened. Another reason, is that
rocketfuel, IGen, yEd and Topology Zoo could provide outputs in GML. This
gives TOGETHER an advantage in working with different types of models.
Another choice in programming that has been made is that TOGETHER
was manually coded without the use of any modules as the program should be
adaptable to any system. Some systems may not be able to support CPAN
libraries or may have physical constraints like memory, connectivity, etc.
Another reason why CPAN libraries were not considered is that sometimes
some libraries become part of other libraries or are removed. This was the
case with IGen at the time of writing this report. Because of these reasons,
we opt not to work with libraries.
Running TOGETHER
In this section I would like to describe the software running and the requisites
for running the software. Firstly, the software was build to fit all Operating
systems, so the code is adaptable. However, we have tested TOGETHER
exhaustively on various Linux platforms. If using Windows, the program
may have to be edited to set the path where perl is installed. The program
is written in Perl and has no dependencies.
Some functions like switch, file controllers, etc are used. This is available
in the perl 5.14.2 by default. Another thing to notice is integrating TO-
GETHER with ANK has never been tested on any other operating system,
so this is still experimental. Since the present version of TOGETHER has
no GUI interface, it is expected of the user to know how to run the program.
TOGETHER has help and version command created on it and the current
version is the TOGETHER 2.0.
The following is an extract of the program running help.
$ ./together -h
HELP How to Use TOGETHER
INFO Acceptable Commands are
HELP perl together -f <filename1.gml> .... <filenameN.gml> -t [auto/manual]
-ank [--junosphere/--junosolive/--cbgp/ (any ANK Command)]
[--ospf/--isis] --plot
INFO together -h, --help -> displays help
INFO together --version -> displays version
INPUT Want Info about AutoNetkit (ANK) [Y/n]:n
$
There are 3 delimiters that the program takes as arguments. The first
one is “-f”. This is used to show that the GML files are added after this.
20

The second delimiter is “-t” where the user can select if he wishes to process
the handling of topologies automatically or manually. The last delimiter is
“-ank”. This is to take in the commands for ANK. This is similar to the com-
mands that ANK can accept. Now the first two delimiters are compulsory,
the “-ank” part can be omitted. In that case, the user needs to go to the
directory and run ANK.
Once more than one GML files are run, TOGETHER analyses the input
files and starts to make the GRAPHML files that is suited for ANK. Then,
if more than one topology file, TOGETHER has two means of connecting
them. One is manual connection and other is automated connection. The
manual connection is selected by entering “-t manual” and the automatic
connection is done by the command “-t auto” . The user in case of manual
is presented a list of all nodes in the different files and allowed to select the
nodes the user wants to work with.
In case of automated connection, there are four scenarios presented. We
hope to increase the numbers of models based on further researches. Two
of them can form multiple inter domain links between each topology. The
other two are used to provide single peering with a designated router. In
one such single peer a router from any of the topology could be selected as
the designated router, and in the second case, a new router is created as a
designated router.
In the section 4.1 we explain the other two means to connect different
topologies. .
After the models have been saved and set, ANK is run and the required
data is obtained. JUNOS olive-based models could be generated by using “-
-junosolive” in the parameters to ANK if using TOGETHER. In the JUNOS
system that was available at QMUL, we faced some errors with installing the
models, so TOGETHER has been used to provide work around solutions.
Note, this command “--junosolive" is a command that works only for the
software TOGETHER. The outputs are saved to a zip file and the program
has options to allow users to view the final topologies.
4.1 Connecting Different AS Together
In the section 4, it is seen that TOGETHER provides various means to
connect between different Autonomous Systems(ASs). The main feature that
helps AutoNetKit (ANK) to differentiate between AS in the GRAPHML
file is the data type key that AutoNetKit identifies as “asn" [19]. This is
automatically set differently for different domains by ANK, thus separating
them.
21

One of the challenges that have been highlighted in this paper was the
fact that the topologies must be able to show a representation of the real
networks. This is a very difficult task. Although TOGETHER is a software
manages the creation of isomorphic models of the internet topologies, there
may rise some situations when the user wants to connect two or more domains
in a manner.
A challenge in modelling this is the fact that since the sources that these
models are obtained are not predictable, some elements like location or spatial
may not be formatted to a common standard. IGen, connects the domains
based on the proximity of the domains from one network to the other. In
IGen, the nearest domains are connected. This is seen in the figure 2.4.
We had generated 10 nodes in the African continent and 20 nodes in the
Eurasian area, and as we had described the spatial information was chosen.
Elements like location or names of the nodes or the Euclidean distance
between nodes cannot be considered as these models may be different. There
is a need of some elements that work with the selection that was done to make
the isomorphic models. So, our models have two elements, nodes and edges.
From the above mentioned reason, it is clear that using methods such as
Waxmann, dK-Seriess [15] and Inet models cannot be considered to connect
between two domains.
This is a huge field of study and we would like to express a few models that
we considered suitable are used. One model that interests us is the Barabasi-
Albert (BA) model [9], where the new nodes are connected to nodes that have
a good interconnectivity. This in some sense would be the case of today’s
network where a new service would be linked to well-established connection.
Another model is the PFP or the Positive Feedback Preference [9]. In this
nodes are connected to both the well-connected older nodes as well as to
newer nodes.
Another model is the rich club model. This was introduced by Zhou
and Mondragón [28]. In this model, they select the interconnectivity by two
factors. The first factor is the rich club connectivity. In this every node is
sorted by the number of edges it has. If there is more than one node that
has similar number of edges, then those nodes are given an arbitrary position
among them. The next factor is node distribution factor. This means, rich
nodes in one AS is connected to rich nodes in other AS.
22

4.1.1 Implementing Inter-domain Connectivity in TO-
GETHER
We have two models that have been used to connect networks automatically.
In the first model, every domain is considered as a node. So, if there are
5 domains, they are represented as 5 nodes. If there are five nodes, the
minimum number of edges required to connect them together is given by the
formula n-1. But this would not mean that all nodes are connected with
each other. So, the nodes need to be deterministically selected in a manner
that all the routers would connect to each other. So, if there are 5 nodes,
namely n1,n2,n3,n4 and n5. The output would be in a form like n1-n2-n3-
n4-n5. It could also be a closed model as n1-n2-n3-n4-n5-n1. Then a single
node is selected randomly from each of the 5 topologies and the nodes are
replaced with the real nodes from the maps. This could be mapped as then
as a1-b3-c4-d8-e3 where the topologies are named as a,b,c,d,e.
The other model is an intermediate between the BA and the rich club
model. In this all topologies are mapped as individual nodes. If there are n
nodes, at the least n-1 connections are required to map them together. The
user could enter the number of inter domain connections they wish to deploy
between these topologies. If the number is less than n-1, the system in order
to connect the nodes by n-1 to avoid unconnected links.
In the first part, a connection is created between all the domains. This is
done in a manner that the system selects nodes from each topology making
sure this node is not selected again in this process.
So, let us say 5 domains are represented as n1,n2,n3,n4,n5. In the first
step, one of the five nodes is selected in a randomised manner and this selected
node is connected to a node in another domain. If the domains are a,b,c,d,e.
After the first round, the output would be of the form a4-b2, b2-e8, e1-d2,
d5-c2.
It is known that it’s best to connect to a more interconnected domain
and so we set this topology as a main hub and connect other networks to
this topology. Let’s say the topology ”e" was a fully meshed model, and then
the remaining links would most likely be e2-a5, e7-b3, e4-d3. In this manner
we try to establish some heuristic design.
In future, this model could be built to replicate rich club, but this is
beyond the scope of this project.
23

Chapter 5
Evaluation of TOGETHER
As they say, the proof of the pudding is in the eating, in this section we would
like to highlight some of the key features we claimed that TOGETHER could
do. One feature of TOGETHER is to generate isomorphic files of network
topology and represent them in an appropriate manner. For representing
the figures, we have used ANK and so have saved the isomorphic files in
GRAPHML format.
It was also claimed that TOGETHER has ability to handle multiple files
and add them together to form multi domain network. This is shown in the
next section.
5.1 Working with Isomorphic Graph Gener-
ation
In this section, I would like to take two examples. One drawn in yEd and
another one generated from IGen. Both are 5 nodes each. For the sake of
making this report simple, the input graphs and the output graphs are only
discussed. The first file is called 5nodeyEd.gml, while the second is called
5nodeIGen.gml. Since yEd could also generate GRAPHML formats, this is
used as a reference for comparison.
Drawing with yEd
In this section 5 nodes (refer 5.1), (coloured yellow) are drawn by hand, and
they are given a mesh topology, meaning that all nodes are connected to each
other and the network are fully meshed. This although may not be ideal in
networking scenarios, is used here as to show the way TOGETHER handles
complexity. Since this is the same output if we saved it as a GRAPHML, it
24

is understood that the figure is the same. We use the GRAPHML file to be
directly used by ANK, to generate an expected output.
Converting with TOGETHER and Processing with ANK
The GRAPHML file is processed by ANK separately and the output is dis-
played in the figure 5.1.However, ANK cannot read the GML files. In this
case TOGETHER is used to convert 5nodeyEd.gml the GML files to the
GRAPHML format
Figure 5.1: 5 node model developed by yEd - 5nodeyEd.GML
5.1.1 Using IGen
The 5nodeIGen.gml file is generated from IGen. This is selected in geographic
locations in random. The IGen image is shown in figure 5.2.This is exported
to a GML format. This is converted by TOGETHER to GRAPHML and
Figure 5.2: 5 node model generated by IGen 5nodeIGen.GML
25

Figure 5.3: 5 node model drawn by yEd processed by TOGETHER and ANK
Figure 5.4: 5 node model drawn by the yEd 5 node model drawn from IGen
processed by TOGETHER
this is processed by ANK. The output of TOGETHER is given below and
the output is given in 5.4
From these ﬁles we could see that TOGETHER is faithful in translating
the topologies and making isomorphic models.
5.1.2 Discussion
We have presented three ﬁgures at the start. All these have been converted
and the outputs are displayed above. We can see their similarity and un-
derstand the adaptability of TOGETHER. We have tested TOGETHER to
handle the manufacturing of isomorphic models of over 7000 nodes that is
26

fully meshed. This took only 2 minutes to generate this and this is consider-
ably fast. However, there are limitations of ANK that makes the generation
of larger topologies difficult to implement on the Junosphere. This proves
that TOGETHER handles the manufacturing of Isomorphic graphs in an
excellent manner.
5.2 Working with Multiple Topologies
yEd by yWorks is a very good application for drawing single and multiple
topologies. The multiple topologies is done by changing a data field of each
node to "asn" and assigning different number to them. But this is time
consuming.
TOGETHER provides topology handling means for AutoNetKit (ANK).
This is shown in the examples below. For this example, I have chosen to use
3 different topologies calling them 1st.gml,2nd.gml,3rd.gml. This is shown in
the figures below. The first one is 1st.gml is a five node fully meshed topology
as in the figure 5.1 as in page 25. The output was seen earlier in the figure
5.3. The second topology is 2nd.gml is a 10 node delaunay triangulation
method which is as in figure 5.5 as in page 27 and the output from ANK is in
the figure 5.7 in page 28. The third is 6 node topology described in 3rd.gml
as shown as in figure 5.6 in page 28 and the output from ANK is as in the
figure 5.8 in page 28.
Figure 5.5: The second figure -2nd.GML
5.2.1 Discussion
The following are the outputs of the models that were read and processed by
TOGETHER. The first figure 5.9 was generated manually, while the second
27

Figure 5.6: Abilene Topology -3rd.GML
Figure 5.7: Individual Output of 2nd.GML
Figure 5.8: Individual Output of 3rd.GML
28

ﬁgure 5.10 was generated automatically.
Figure 5.9: Type 1 Final Output
Figure 5.10: Type 2 Final Output
29

Chapter 6
Discussion and Future Work
From the outputs in 5.1, we could see that all the three topologies are con-
nected together. This shows how efficiently TOGETHER manages to handle
multiple topologies too.This is a huge advantage in working with large scale
networks. We were able to test this and much more on the Junosphere. In
the future, as the support of ANK increases to Cisco and other providers, we
expect TOGETHER to be able to bridge these worlds too.
We had shown that TOGETHER could generate topologies that are faith-
fully translated and the network model preserved. These files were used in
Junosphere and we were able to run networks that were based on heuristics
to study the nature of the internet. The project is a success.
We had worked in generating a large number of different topologies and
complex models and have found that under a minute TOGETHER could
model network topology graph models got from various sources and combine
them to form complex models that represent the internet.
Another feature of TOGETHER we discussed was that since it was build
to work well with AutoNetkit, and so as the features increases, the program
TOGETHER could efficiently add capabilities to using AutoNetkit too.
We would like to however bring in more work to TOGETHER in improv-
ing its output quality.TOGETHER is currently command line based software.
If there was time, we could have added features like a GUI based display and
may be even GUI based topology handling. Some aspects of TOGETHER
is that in making isomorphic models, some elements were discarded as irrel-
evant. One such is the name the user gives to the node. One reason this was
discarded was this was dependent on the user and so many models that had
GML files gave different means to naming nodes. This could be included in
future models. Another feature is the current version of TOGETHER cannot
read a directory as in all. We would like to add this feature and also enable
more GUI and non-GUI arguments so that the user could let TOGETHER
30

models without any intervention.
In this project it is seen TOGETHER handling topologies and enabling
this to work on multiple systems. We would like to better the research on this
and have TOGETHER handle topologies using more researched methods.
One such is to implement the rich club model into the program so that users
could select this model and perform studies on it. Another element that could
be considered is weighted spectral distribution [7] so that the topologies could
be tuned better and inter AS connections could be made with more care and
ease.
31

Chapter 7
Conclusion
In today’s economy, the Internet is a very valuable asset. The growth and the
influence of the internet in the socio-economic lives of billions in the world
are unmatched. Therefore there is an urgent need to finding ways to keep
the network running, making it more efficient and resilient to attacks. We
have discussed in our paper discussed that because of this need, there has
been a drive to model networks and study them.
Over the course of time, there have been many models that lay the foun-
dations of good study. This project has made aware that in order to study
networks, there is a need to work on virtual environments than working with
simulations or emulations. This would bring results that are more compara-
ble to the ones that would be obtained in the real networks. Keeping this
in mind, we had introduced some studies in network topology generators
like IGen, Topology Zoo, etc., that was efficient in plotting the model of the
internet.
Now since all these were products of different institutes and research facil-
ities, we discussed the need for a solution to unify the issues in managing net-
work topologies. This is the basis of this project. TOGETHER reads GML
files representing network topologies and exports isomorphic GRAPHML files
.It was then explained in this report how AutoNetkit,could make models for
virtual network hosts. Another feature of TOGETHER was that it could
handle multiple topologies and even use some heuristics to connect them
and present them to be used as reference models for future studies. We had
finally discussed that the output from AutoNetkit have been used and have
been able to be deployed in Junosphere environment for research.
In this manner, TOpology GEneration THrough HEuRistics has added
another stone towards working with models that represent Internet as a
whole.
32

Bibliography
[1] Bernhard Ager, Nikolaos Chatzis, Anja Feldmann, Nadi Sarrar, Steve
Uhlig, and Walter Willinger. Anatomy of a large european ixp. In
Proceedings of the ACM SIGCOMM 2012 conference on Applications,
technologies, architectures, and protocols for computer communication,
SIGCOMM ’12, pages 163–174, New York, NY, USA, 2012. ACM.
[2] David Alderson and John Doyle. Toward an optimization-driven frame-
work for designing and generating realistic internet topologies. In In
ACM HotNets-I, pages 41–46, 2002.
[3] J. M. Carlson and John Doyle. Highly optimized tolerance: a mecha-
nism for power laws in designed systems. Phys. Rev. E, 60:1412–1427,
Aug 1999.
[4] Sanda D and Radu D. Winnet - a network tool. In ICCCC.
[5] M.B. Doar. A better model for generating test networks. In Global
Telecommunications Conference, 1996. GLOBECOM ’96. ’Communi-
cations: The Key to Global Prosperity, pages 86 –93, nov 1996.
[6] Alex Fabrikant, Elias Koutsoupias, and Christos H. Papadimitriou.
Heuristically optimized trade-oﬀs: a new paradigm for power laws in
the internet. pages 110–122, 2002.
[7] Damien Fay, Hamed Haddadi, Andrew Thomason, Andrew W. Moore,
Richard Mortier, Almerima Jamakovic, Steve Uhlig, and Miguel Rio.
Weighted spectral distribution for internet topology analysis: theory
and applications. IEEE/ACM Trans. Netw., 18(1):164–176, 2010.
[8] R. Govindan and H. Tangmunarunkit. Heuristics for internet map dis-
covery. In INFOCOM 2000. Nineteenth Annual Joint Conference of
the IEEE Computer and Communications Societies. Proceedings. IEEE,
volume 3, pages 1371 –1380 vol.3, mar 2000.
33

[9] Hamed Haddadi, Damien Fay, Almerima Jamakovic, Olaf Maennel, An-
drew W. Moore, Richard Mortier, Miguel Rio, and Steve Uhlig. Beyond
node degree: Evaluating as topology models. CoRR, abs/0807.2023,
2008.
[10] Hamed Haddadi, Steve Uhlig, Andrew Moore, Richard Mortier, and
Miguel Rio. Modeling internet topology dynamics. SIGCOMM Com-
puter Communication Review, 2008.
[11] Cheng Jin, Qian Chen, and Sugih Jamin. Inet: Internet topology gen-
erator. Technical report, University of Michigan, 2000.
[12] S. Knight, H.X. Nguyen, N. Falkner, R. Bowden, and M. Roughan. The
internet topology zoo. Selected Areas in Communications, IEEE Journal
on, 29(9):1765 –1775, october 2011.
[13] Simon Knight, Askar Jaboldinov, Olaf Maennel, Iain Phillips, and
Matthew Roughan. Autonetkit: simplifying large scale, open-source
network experimentation. In Proceedings of the ACM SIGCOMM 2012
conference on Applications, technologies, architectures, and protocols for
computer communication, SIGCOMM ’12, pages 97–98, New York, NY,
USA, 2012. ACM.
[14] Damien Magoni and Mickaël Hoerdt. Internet core topology mapping
and analysis. Computer Communications, 28:494–506, 2005.
[15] Priya Mahadevan, Dmitri Krioukov, Kevin Fall, and Amin Vahdat. Sys-
tematic topology analysis and generation using degree correlations. SIG-
COMM Comput. Commun. Rev., 36(4):135–146, August 2006.
[16] A. Medina, A. Lakhina, I. Matta, and J. Byers. Brite: an approach
to universal topology generation. In Modeling, Analysis and Simulation
of Computer and Telecommunication Systems, 2001. Proceedings. Ninth
International Symposium on, pages 346 –353, 2001.
[17] Wolfgang Mühlbauer, Steve Uhlig, Anja Feldmann, Olaf Maennel,
Bruno Quoitin, and Bingjie Fu. Impact of routing parameters on route
diversity and path inﬂation. Comput. Netw., 54(14):2506–2518, October
2010.
[18] Wolfgang Mühlbauer, Steve Uhlig, Bingjie Fu, Mickael Meulle, and Olaf
Maennel. In search for an appropriate granularity to model routing
policies. SIGCOMM Comput. Commun. Rev., 37(4):145–156, August
2007.
34

[19] Hung Nguyen, Matthew Roughan, Nickolas John Gowland Knight, Si-
mon Charlesand Falkner, Olaf Manuel Maennel, and R. Bush. How to
build complex, large-scale emulated networks. In Proceedings of 6th In-
ternational ICST Conference on Testbeds and Research Infrastructures
for the Development of Networks and Communities, held in Berlin Ger-
many.
[20] B. Quoitin, V. Van den Schrieck, P. Francois, and O. Bonaventure. Igen:
Generation of router-level internet topologies through network design
heuristics. In Teletraﬃc Congress, 2009. ITC 21 2009. 21st Interna-
tional, pages 1 –8, sept. 2009.
[21] Bruno Quoitin. Towards more representative internet topologies. Tech-
nical report, Université Catholique de Louvain, 2010.
[22] N. Spring, R. Mahajan, D. Wetherall, and T. Anderson. Measuring isp
topologies with rocketfuel. Networking, IEEE/ACM Transactions on,
12(1):2 – 16, feb. 2004.
[23] Hongsuda Tangmunarunkit, Ramesh Govindan, Sugih Jamin, and Scott
Shenker. Network topology generators: Degree-based vs. structural,
2002.
[24] Megan Thomas and Ellen W. Zegura. Generation and analysis of random
graphs to model internetworks. Technical report, College of Computing,
1994.
[25] P. van Mieghem, J.M. Hernandez, T. Kleiberg, and H. Wang. A quali-
tative comparison of power law generators. 2006.
[26] B.M. Waxman. Routing of multipoint connections. Selected Areas in
Communications, IEEE Journal on, 6(9):1617 –1622, dec 1988.
[27] Beichuan Zhang, Raymond Liu, Daniel Massey, and Lixia Zhang. Col-
lecting the internet as-level topology. SIGCOMM Comput. Commun.
Rev., 35(1):53–61, January 2005.
[28] Shi Zhou and R.J. Mondragón. The rich-club phenomenon in the in-
ternet topology. Communications Letters, IEEE, 8(3):180 – 182, march
2004.
35

TOGETHER: TOpology GEneration THrough HEuRistics

Recommended

Recommended

More Related Content

Similar to TOGETHER: TOpology GEneration THrough HEuRistics

Similar to TOGETHER: TOpology GEneration THrough HEuRistics (20)

Recently uploaded

Recently uploaded (20)

TOGETHER: TOpology GEneration THrough HEuRistics