Ethernet: Communication between LLC and Higher Layers

Higher layers (applications or protocols) talk to the EtherLLC module.

When a higher layer wants to send a packet via Ethernet, it just passes the data packet (a cMessage or any subclass) to EtherLLC. The message kind has to be set to IEEE802CTRL_DATA.

In general, if EtherLLC receives a packet from the higher layers, it interprets the message kind as a command. The commands include IEEE802CTRL_DATA (send a frame), IEEE802CTRL_REGISTER_DSAP (register highher layer) IEEE802CTRL_DEREGISTER_DSAP (deregister higher layer) and IEEE802CTRL_SENDPAUSE (send PAUSE frame) -- see EtherLLC for a more complete list.

The arguments to the command are NOT inside the data packet but in a "control info" data structure of class Ieee802Ctrl, attached to the packet. See controlInfo() method of cMessage (OMNeT++ 3.0).

For example, to send a packet to a given MAC address and protocol identifier, the application sets the data packet's message kind to ETH_DATA ("please send this data packet" command), fills in the Ieee802Ctrl structure with the destination MAC address and the protocol identifier, adds the control info to the message, then sends the packet to EtherLLC.

When the command doesn't involve a data packet (e.g. IEEE802CTRL_(DE)REGISTER_DSAP, IEEE802CTRL_SENDPAUSE), a dummy packet (empty cMessage) is used.

Rationale

The alternative of the above communications would be:

adding the parameters such as destination address into the data packet. This would be a poor solution since it would make the higher layers specific to the Ethernet model.
encapsulating a data packet into an interface packet which contains the destination address and other parameters. The disadvantages of this approach is the overhead associated with creating and destroying the interface packets.

Using a control structure is more efficient than the interface packet approach, because the control structure can be created once inside the higher layer and be reused for every packet.

It may also appear to be more intuitive in Tkenv because one can observe data packets travelling between the higher layer and Ethernet modules -- as opposed to "interface" packets.