[Ns-developers] IEEE80211s development in NS-3

[Tom Henderson]

Kirill,
I have some questions about your recent post.  My high-level observation 
is that what you are describing seems very similar to the existing 
bridge net device so perhaps you could study that and see whether you 
could pattern your architecture similarly.

In particular, the bridge net device is a virtual device with other real 
devices registered as "ports".  When a bridge net device adds a port, it 
registers with the real device to receive all frames in promiscuous 
mode.  Then, it implements forwarding logic and may send out some 
received frames, with different destinations, on its other ports.

Similarly, it seems to me that 802.11s, in practice, is defined as a 
virtual mesh device, the main difference being that the forwarding logic 
is more complicated and there are levels of header encapsulation to 
realize the mesh.  However, the same general architecture could perhaps 
apply:


   -----mesh -----
  |       |      |
ath0   ath1   ath2  ...

where ath* are Wifi devices and "mesh" is a virtual device that 
registers to receive all of the frames from ath* devices.

kirillano wrote:
> Hi, 
> In this mail I have included schemes of class hierarchy and more detailed structure of L2Routing.
> 
> First, I would like to tell about class hierarchy.
> Two additional base classes for NetDevice should be added:
> 1. L2RoutingNetDevice - is a real NetDevice, where a MAC should be attached to, and the following additions should be implemented:

in general, for the real devices, it would be nice to be able to reuse 
the existing WifiNetDevice without modification.  Is that not possible?

>     1a. virtual bool Send (Ptr<Packet> packet, const Address& destination, const Address& retransmitter, u_int16_t protocolNumber)

The above method looks a lot like NetDevice::SendFrom(), which was 
introduced to support bridging use case in which a device may want to 
send a packet with a source address that is not its own.  Is the above 
method analogous to the existing SendFrom()?

> Doing this is really necessary only for wifi case, because all addresses needed for implementing mesh exist in normal MAC-frame, but doing this in all other cases, as I think, should simplify a realization of protocol.
>     1b. Added one more receive callback: Callback<bool, Ptr<NetDevice>,Ptr<Packet>,const Address&, const Address&>
> The same situation (like in Send method)is in Receive method: we have to know sometimes both source address and address of last retansmitter (by this way, for example, FLAME fills its routing table)

I'm not sure you strictly need the above-- you get the whole frame when 
you use the existing callback.

>     1c. Add request/response methods as shown in L2Routing diagram
> Request primitive should consist of list of destinations to be resolved and list of initial metrics (the list of addresses rather tan address is needed for HWMP, because it has limitations of sending Requests, and it can make a multiple-destination-request). Response primitives should contain the same list, but with retransmitter addresses. In both this classes should be a field, contains parameters, which are specified in each protocol (for example, list of retransmitters, if needed).
> 2. L2RoutingVirtualNetDevie - is a virtual net device, and each L2Routing protocol has its own L2RoutingVirtualNetDevice class (rather than setting a routing protocol like it is made in IPv4).
> The following methods should be added:
>     2a. Method virtual bool SetInterfaces(std::list<L2RoutingNetDevice> interfaces)

The above seems analogous to BridgeNetDevice::AddBridgePort()

>     2b. Method  virtual bool SetRoutingTable(Ptr<L2RoutingTable>); if we want to share L2Routng table between two protocols, the routing table must be set from network-simulation script (in IPv4 routing table is stored in 'kernel', L2routing table is a part of net device private data, so, if we want to share routing table - this method is needed)
> L2RoutingTable base class should contain the following:
>     - Destination
>     - Retransmitter (next-hop)
>     - Previous-hop
>     - Interface ID
>     - Metric (double or u_int32 value)
>     - Time when created (Time)
> 
> 3. Now I would like to say some words about realization of HWMP (maybe this scheme should be a template for other L2-routing protocols) (represented in L2Routing diagram)
> The following classes should be implemented in HWMP:
>     3a. Routing queue - should store packets, which can not be sent at the moment
>     3b. Protocol's MgtPacketManager - which is attached to real net device and stores all timeouts for sending requests, retry counters, etc. 
> Should be like a bridge between L2Routing and real net device: takes a request form L2routing and transforms it to request, which contains a list of addresses (HWMP-adaptated), and takes a response (list of addresses(destinations), metrics and retransmitters)and gives a L2routngTableEntry to L2RoutingProtocol.
>     3c. Routing table (see above)
>     3d. Routing protocol - should be an internal part of L2RoutingVirtualNetDevice and it has an interface similar to IPv4 routing protocol
> 
> 
> The main purpose of making base classes (like net device) is to make the most structured model of L2 routing for all possible protocols, so I would like make as many virtual methods, as possible - so any ideas are welcome.
> 

I would suggest to focus first on making a clean implementation of mesh 
net device and then later look at what to factor out as a base class if 
you an envision future extensions that could reuse pieces of the mesh 
device.

Also, it seems to me that if you could make the public API of the device 
map well to the way that people configure these mesh devices in actual 
implementations, it will help users.  For example:
http://www.open80211s.org/trac/wiki/HOWTO

Regards,
Tom