Load topology from file

119 views
Skip to first unread message

Matt Anonyme

unread,
Jul 19, 2014, 11:52:17 AM7/19/14
to ns-3-...@googlegroups.com
Hi,

I would like to load a topology from a file, ie being able to define the Netdevices for 2 nodes and configuration for links (datarate,type:wifi/ethernet) for a test suite. How can I do that ?
The topology readers seem to rely on obsolete programs (such as Brite) or programs that generate random topologies.

Any help appreciated

Cheers,
Matt

Tommaso Pecorella

unread,
Jul 19, 2014, 2:12:46 PM7/19/14
to ns-3-...@googlegroups.com
Hi,

there are 2 topology reading system, as you have noticed. The first one is BRITE, which is still useful despite some oldness.
The other one is the TopologyRead module. Here is what you have misunderstood. TopologyRead simply reads a text file with a specific format.
The supported file formats are the ones used by popular random topology creators, but that's another point. Once you have your topology description file, you can read it over and over, or modify it manually.

The problem may be that the topology description only stores some of the informations you mention. E.g., INET topology format is:
- Nnodes NLinks
-- NodeId xCoord Ycoord (repeated Nnodes times)
-- SrcNodeId DstNodeId LinkWeight (repeated NLinks times)

You could use two topology descriptions (one for csma and one for WiFi) and use the LinkWeight attribute to store a parameter, e.g., the link bandwidth.

An alternative is to extend TopologyRead with your own format parser.

Cheers,

T.

Teto

unread,
Jul 19, 2014, 4:15:28 PM7/19/14
to ns-3-...@googlegroups.com
I was unsure about the different topology readers you do well
explaining the Inet format: I had a look at INET_toposample.txt and it
was not that clear (would be nice to have your format explanation in
the doxygen doc ).
I read somewhere in the ConfigStore API, I could refer to nodes by
"/NodeList/[i]/DeviceList/[i]" so maybe from a ConfigStore I can
define my nodes & links ?

> An alternative is to extend TopologyRead with your own format parser.
Was afraid you were going to say that xD
I can do without I guess but if I had to I guess it would be like:
<Ns3NodeType> <SerializedNs3DescriptionOfTheObject>

Matt
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ns-3-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ns-3-users/YujKxm5OEzg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> ns-3-users+...@googlegroups.com.
> To post to this group, send email to ns-3-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ns-3-users.
> For more options, visit https://groups.google.com/d/optout.

Tommaso Pecorella

unread,
Jul 19, 2014, 5:26:20 PM7/19/14
to ns-3-...@googlegroups.com, matt...@gmail.com
Hi,


On Saturday, July 19, 2014 10:15:28 PM UTC+2, Matt Anonyme wrote:
I was unsure about the different topology readers you do well
explaining the Inet format: I had a look at INET_toposample.txt and it
was not that  clear  (would be nice to have your format explanation in
the doxygen doc ).

Indeed, I should expand the docs.
 
I read somewhere in the ConfigStore API, I could refer to nodes by
"/NodeList/[i]/DeviceList/[i]" so maybe from a ConfigStore I can
define my nodes & links ?

Yes, no, maybe.
ConfigStore is used to store global configurations and to connect traces. As far as I know it's not meant to be used for node creation.
It could be expanded, of course.
 
> An alternative is to extend TopologyRead with your own format parser.
Was afraid you were going to say that xD
I can do without I guess but if I had to I guess it would be like:
<Ns3NodeType> <SerializedNs3DescriptionOfTheObject>

It depends on what you need to do with it. The format you outlined is a full node serialization. Probably it could be needed to store a whole simulation setup in a text file, but I'd avoid such a general approach.
It would be useful and it has been discussed many times. The problem is that such a system is really difficult to implement, and no matter how you do it, it will always miss something.
There are some papers about it... check the past WNS3 workshops.

if you try to do it more specific (i.e., just listing WiFi and CSMA/P2P links, it can be manageable.
Btw, this is exactly why ToplogyReaders do NOT do the links creation. They return a NodeContainer (that's easy), but then it provides a list of links to be created. It's the caller responsibility to decide the link type (WiFi, CSMA, P2P, whatever) and create them...

Cheers,

T.
Reply all
Reply to author
Forward
0 new messages