[Ns-developers] IEEE80211s development in NS-3

[kirillano]

Hi, 

> Would you mind outline more specifically the changes you have in mind 
> for the NetDevice base class ? i.e., what is the exact signature of the 
> functions you would like to add or modify in the NetDevice base class, 
> how would these be implemented by various NetDevice subclasses ? 

At this moment we see the only modification to NetDevice:
1) Add method Send() with next_hop_address (receiver address) parameter:
virtual bool Send(Ptr<Packet> packet, const Address& dest, const Address& nexthop, uint16_t protocolNumber);
2) Add method SetInterfaces() to specify which interfaces the VirtualNetDevice will contain:
virtual bool SetInterfaces(std::list<L2RoutingNetDevice> interfaces);

The reason for doing that is weak a bit, because the L2Routing can modify all packets going through a given VirtualNetDevice itself and add all required information, like address of retransmitter.
But 802.11 4-address scheme is implemented fully in MAC-802.11, so
when we work only within mesh (without exits to wired networks or infrastructure networks on the edge of mesh), L2Routing should pass the destination address and address of retransmitter to the MAC (MAC knows nothing about L2RoutingTable).
So this is really needed only for HWMP(and maybe toher protocols, which do not use own headers).
Another drawback is that we can't set a L2RoutingVirtualNetDevice as a real NetDevice of any other Layer 2 routing protocol.
This probably isn't good but not very critical (because this isn't really needed for simulations).


Let's now introduce some realization specifics:
1) Implement an L2 routing protocol using methods like those defined in IPv4RoutingProtocol template class with following differences:
    1.1) Add a Packet Manager class above real NetDevice, which should keep the state machine of L2Routing protocol on each real NetDevice.
         This class will be like a bridge between L2Routing and real NetDevice (each real NetDevice contained in the L2RoutingVirtualNetDevice).
         a) From L2Routing class it will receive RouteRequest, which contains the address of destination and initial metric.
            Then the Packet Manager will decide if the state machine of the protocol allows sending request immediately (or with a delay).
            RouteRequest also should contain template class for parameters. (e.g. for DO and RF flags in HWMP).
         b) The request from Packet Manager to real NetDevice should contain a list of addressses with initial metrics to be resolved.
            The reply from NetDevice to Packet Manager should look like a table with destinations, addresses of retransmitter and metrics.
         c) The Packet Manager should return a L2RoutingTabeEntry to L2Routing through callback (when an update for a route is available).
            The L2RoutingEntry should contain retransmitter address, metric, output interface address (this fields must be in all routing tables).
         d) When route error (path error) occurs, the Packet Manager should notify L2Routing this.
            Not all protocols are able to detect route errors, so these methods should not be included to the template class, but they sould be implemented in HWMP.
    1.2) Add a class L2RoutingTable.
         In contrast to the L3Routing table, which is stored in kernel and can be shared between all enabled routing protocols,
         the L2Routing table should be stored within L2RoutingVirtualNetDevice private data.
         The L2Routing table should be created from simulation script and attached to L2RoutingVirtualNetDevice to allow its sharing between L2Routing protocols from different L2RoutingVirualNetDevices.
         So the L2Routing will work like transparent bridge (The same idea is implemented in realization of FLAME protocol for Linux kernel)
    1.3) Add an L2Routing Protocol itself.
         The protocol decides either to send a packet immediately or put it into the routing queue.
         This decision is made by looking to the routing table.
         After resolving a route, data frames go immediately to the real NetDevice.

> If the goal is to integrate your work in the main ns-3 tree, the best 
> way to go forward would be to publish your code as soon as possible to 
> allow early reviews to proceed: "release early, release often". 

Of course, we understand it. 
As soon as we get the minimum working code (or even just some headers and prototypes), we'll publish it. 


> Since you seem to be proposing changes to the NetDevice base class, I 
> believe that you will need to seek approval from the maintainer of that 
> class (that would be Craig) and all ns-3 maintainers who are impacted by 
> that change (that would be everybody else). For the wifi-specific 
> changes, you will need to seek only my approval. 

OK, it's clear now. 

> I hope that the above helps, 

Yes, great thanks to you!

Best regards, Kirill