TWiki home TWiki > Simulation > SimulationWebHome > IPv4Suite > IPSuiteLogOfChanges TWiki webs:
Main | TWiki | Know | Sandbox
Simulation . { Changes | Index | Search | Go }

IPSuite Summary of changes

RSVP-TE refactoring again

Fourth round: New features (August 2004-)

Third round: Ethernet and other network interfaces, TCP rewrite, architectural changes (April-August 2004)

Sepearated old code which will no longer be maintained

All-in-one IP

IP revision


Removed IPSuite dependency on libXML: RSVPApp was changed to use XML config file support of OMNeT++ 3.0a6 (class cXMLElement).

Ethernet integration

Checked in EtherNet model under NetworkInterfaces/Ethernet. Stuff common to IEEE 802 LANs put in the NetworkInterfaces/_802 directory.

Implemented ARP (NetworkInterfaces/ARP directory).

TCP rewrite

The directory Transport/NewTCP contains completely new TCP implementation (incomplete as of Apr 15 2004).


The new model, in addition to using .msg files, makes two aspects of the TCP model configurable by "plug-in classes":

Convergence with TKN Mobility Framework

The idea of the blackboard comes from the Mobility Framework (MF). The MF will (hopefully) provide mobility and physical channel models.

Current MF code is available from the download area.


Blackboard module added to host and router models. The blackboard (BB) is for sharing information among several protocol layers (simple modules) in a publish-subscribe manner. Change notification is done via direct method calls.

Typical usage pattern looks like this:

  1. items are published on the blackboard, typically in initialize()
  2. several modules may find it on the blackboard and subscribe to it. Typically also in initialize() (multi-stage initalization will be needed to ensure subscriptions follow publishing)
  3. whenever a module (usually but not necessarily the subscriber) modifies the item (or replaces it with another instance), it tells the blackboard about this (changed()), and the blackboard in turn notifies every subscriber (calls blackboardItemChanged() in them). This step will occur very often in the simulation.
  4. during simulation, modules may publish new items on the BB, others may subscribe or unsubscribe, or items can be withdrawn from the BB (which means auto-unsubscribing everyone subscribed to it, because the BB completely forgets the item). However, in typical use there'll be few such runtime publish/withdraw or subscribe/unsubscribe operations (they'll usually occur if there's some big change in the configuration.)

"InterfacePacket" replaced by "Control Info" approach

When packets are sent between protocol layers, usually there's some extra info to be attached to the packet. E.g. when a transpont layer protocol wants to send a transport packet over IP, in addition to sending the transport packet to IP it also has to tell the IP layer the destination IP address. The original approach in IPSuite was the use of "Interface Packets": the transport packet was wrapped (encapsulated) in a control message which contained the extra info (IPInterfacePacket message class).

The current OMNeT++ 3.0 alpha offers a better way: messages can be attached a piece of "control info". Control info is a (typically struct-like) object subclassed from cPolymorphic. Control info classes can be described in a msg file. Examples:

// needs to be attached to packets to be sent over IP; IP modules will use
// this info for encapsulating the packet into an IPDatagram
class IPControlInfo
        IPAddress srcAddress; // optional
        IPAddress destAddress;
        short protocol  enum(IPProtocolFieldId);

// IP routing attaches this info to IP datagram:
class IProutingDecision
        int interfaceNumber;
        IPAddress nextHopAddress; // optional; used e.g. on LANs to find router

// Ethernet expects this to be attached to packets from higher layer:
class _802ControlInfo
        MACAddress src; // optional
        MACAddress dest;

Three new methods have been added to cMessage for attaching, accessing and removing control info:

For sending a packet in an IP datagram, one has to fill in and attach control info to the message, and send the packet to IP. Like this:

   cMessage *msg = ...

   IPControlInfo *controlInfo = new IPControlInfo();


And upon reception, it is possible to obtain the source IP address etc like this:

...::handleMessage(cMessage *msg)
   IPControlInfo *controlInfo = check_and_cast<IPControlInfo *>(msg->removeControlInfo());
   IPAddress srcAddr = controlInfo->srcAddr();
   IPAddress destAddr = controlInfo->destAddr();
   delete controlInfo;

Previous IPSuite changes: IPSuiteChangesOld.

Planned next steps:

-- AndrasVarga - 27 Feb 2004

Topic IPSuiteLogOfChanges . { Edit | Attach | Ref-By | Printable | Diffs | r1.30 | > | r1.29 | > | r1.28 | More }
Revision r1.30 - 11 May 2005 - 12:54 GMT - AhmetSekercioglu
Parents: SimulationWebHome > IPv4Suite
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.