Classes | |
| class | ns3::InetTopologyReader |
| Topology file reader (Inet-format type). More... | |
| class | ns3::OrbisTopologyReader |
| Topology file reader (Orbis-format type). More... | |
| class | ns3::RocketfuelTopologyReader |
| Topology file reader (Rocketfuel-format type). More... | |
| class | ns3::TopologyReader |
| Interface for input file readers management. More... | |
| class | ns3::TopologyReader::Link |
| Inner class holding the details about a link between two nodes. More... | |
| class | ns3::TopologyReaderHelper |
| Helper class which makes it easier to configure and use a generic TopologyReader. More... | |
The topology modules aim at reading a topology file generated by an automatic topology generator.
The process is divided in two steps:
Hence, model is focused on being able to read correctly the various topology formats.
Currently there are two models:
A good source for topology data is also Archipelago (http://www.caida.org/projects/ark/)
The current Archipelago Measurements, monthly updated, are stored here: http://data.caida.org/datasets/topology/ipv4.allpref24-aslinks/ (complete notation and triple data source, one for each working group)
A different and more compact notation that signs only the AS-relationships is here: http://www.caida.org/data/active/as-relationships/index.xml (a sort of more Orbis-like format)
The compact notation can be easily stripped down to a pure Orbis format, just removing the double relationships (the compact format use one-way links, while Orbis use two-way links) and pruning the 3rd parameter. Note that with the compact data Orbis can then be used create a rescaled version of the topology, thus being the most effective way (to my best knowledge) to make an internet-like topology.
1.7.1