[Ns-developers] IEEE80211s development in NS-3

[Mathieu Lacage]

On Tue, 2008-12-09 at 21:17 +0300, kirillano wrote:
> 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);

And how would you implement this method in the wifi case ? How would you
implement this method in the non-wifi case ? If it can't be implemented
in anything but a WifiNetDevice, then, it should not be defined in the
NetDevice base class, but in the WifiNetDevice class.

> 2) Add method SetInterfaces() to specify which interfaces the
> VirtualNetDevice will contain:
> virtual bool SetInterfaces(std::list<L2RoutingNetDevice> interfaces);

This method would be defined on the VirtualNetDevice class, not on the
NetDevice class, right ? What is an L2RoutingNetDevice ?

> 
> 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).

I am afraid but I am missing a higher-level picture of what you are
trying to do: I tried to go back to your previous email on this topic
and looked carefully again at the diagram you included in your previous
email but it is still not clear to me what you are trying to do. Maybe
the issue is that you are not using the right object names consistently:
in your text above, you mention VirtualNetDevice, L2RoutingNetDevice,
L2RoutingVirtualNetDevice but none of these appear in your
previously-sent diagram (which defines yet another, MeshNetDevice)


> 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.

Again, I am a bit confused by all the above. I guess that it will be
easier to see where you are going once we can see a sample header or a
class diagram so, feel free to defer answering me until you have one of
these :)

regards,
Mathieu