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

IPSuite Summary of changes

RSVP-TE refactoring again

• OSPF-TE: renamings to enforce naming convention on variables & types

• LDP, RSVP-TE hand-coded message classes migrated to .msg files

• LDP rewritten for new TCP model

• LIBTable public interface revised, table contents made inspectable in Tkenv

• MPLS model and MPLSPacket extensive refactoring & dead code removal

• MPLS simulation examples revised, e.g. removed tons of empty LIB & PRT table files for clarity

Fourth round: New features (August 2004-)

• Ethernet model integrated; new example simulation ARPTest

• TCP connections made inspectable in Tkenv

• TCP application models replaced with ones belonging to the new TCP, and using TCPSocket, TCPSocketMap and IPAddressResolver.

• added simple IP address autoassignment and autorouting, to eliminate need for writing routing tables by hand. Esp. useful for large scale simulations. This currently supports a simple case ("flat" routing, i.e. everything is a single network without subnets). You only need to put a simple module called FlatNetworkConfigurator into the network, and it'll auto-assign IP addresses to all interfaces, and set up static routes. NO NEED TO WRITE A SINGLE IRT FILE! For more sophisticated cases (hierarchial routing i.e. subnetting) someone (or I) can write a different configurator module. Example model (FlatNet) can be just run with a minimal omnetpp.ini and without any .irt file or any other config file. Addresses and routing tables are set up automatically.

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

Sepearated old code which will no longer be maintained

• created Unsupported/ directory, and moved old TCP model, Socket, their example models and applications in there.

All-in-one IP

• created a new, all-in-one IP model instead of very modular IPProcessing. (It consisted of separate PreRouting, Routing, IPSend, IPMulticast, ... modules). Using too many modules was a memory and CPU hog, and also made code understanding/maintenance more difficult. (Old IPProcessing also retained for experimentation with IP internals).

IP revision

• fragmentation reassembly buffer from the old code (LocalDeliver) rewritten (both in the all-in-one IP and in LocalDeliver) rewritten

• RoutingTable completely revised. New class interface provides better support for future routing protocols to modify the routing table. Network interface entries in RoutingTable are no longer created based on the .irt file (which could easily be inconsistent with what L2 modules were actually present in the router/host compound module), but they're dynamically registered by L2 modules such as PPPModule. .irt file entries only configure them. (Configuration is not always necessary though, e.g. PPPModule can register the interface with good defaults for MTU and metric.)

• made interface tables and routing tables inspectable in Tkenv

RSVP-TE

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

Motivation:

• existing tcpmodule.cc was written before message definitions (.msg files) got introduced into OMNeT++. It uses cPars, C structs carried by pointer-valued cPars and other tricks which have been suppressed by .msg files by now. This would have to be updated anyway.
• current tcpmodule.cc contains TCP flavours (congestion control, fast retransmit/recovery, selective acknowledgement etc) hardcoded. I would be much better to get these incorporated in a much more flexible way (e.g. as separate objects)
• different simulation scenarios require different approaches regarding transmitted data (see below), and this is also difficult to do with tcpmodule.cc. For example:
  • in one model one might want to transmit a "real" bytes (especially if the application which uses TCP is a ported version of a real socket application)
  • In other scenarios, "dummy" transmission will do, that is, simulated TCP segments contain do not need to contain any real data (only the number of bytes they represent suffices) -- you'll want to do this when the app is there solely as a traffic generator (e.g. simulated file transfer or telnet session), but actual data is unimportant.
  • Yet again in other models you need to transmit a sequence of cMessage objects, and you want exactly the same cMessage sequence to be reproduced on the receiver side. (Here every cMessage would map onto a sequence number range in the TCP stream, and the object is passed up to the application when its last byte has arrived on the simulated connection.)

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

• TCP congestion control, fast retransmit/recovery etc. algorithms are encapsulated into a separate object, subclassed from TCPAlgorithm (an abstract base class). Thus one can create several classes, all subclassed from TCPAlgorithm which provide various TCP behaviours, and choose one of them for any particular simulation. Examples of such classes can be e.g. Reno, NewReno, LinuxTCP, etc. The particular class to be used is selected at runtime (via a module parameter, e.g. from omnetpp.ini). This feature should make it easier to experiment with various flavours of TCP, test experimental congestion control schemes etc.
• Second, transmission method ("real" bytes, dummy, cMessage sequence) is encapsulated in the classes derived from the TCPSendQueue/TCPReceiveQueue abstract base classes. The choice of transmission method (class names) can be specified in module parameters, but it is also possible for apps to specify it individually for each connection (in the active/passive open commands).

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 omnetpp.org download area.

Blackboard

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
{
    fields:
        IPAddress srcAddress; // optional
        IPAddress destAddress;
        short protocol  enum(IPProtocolFieldId);
        ...
}

// IP routing attaches this info to IP datagram:
class IProutingDecision
{
    fields:
        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
{
    fields:
        MACAddress src; // optional
        MACAddress dest;
        ...
};

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

• void setControlInfo(cPolymorphic *p); -- attaches a "control info" structure (object) to the message. The "control info" object will be deleted when the message is deleted. Only one "control info" structure can be attached (a second call to setControlInfo() will throw an error).
• cPolymorphic *removeControlInfo(); -- removes the "control info" structure (object) from the message and returns its pointer. Returns NULL if there was no control info in the message.
• cPolymorphic *controlInfo() const; -- returns pointer to the attached "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();
   controlInfo->setProtocol(IP_PROT_TCP);
   controlInfo->setDestAddr(destIPAddress);
   packet->setControlInfo(controlInfo);

   send(msg,"to_ip");

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:

• write a new, more structured and more flexible TCP model, and change everything to use that one
• add network interfaces (L2 protocols): PPP, Ethernet, 802.11, possibly others
• replace rest of handcoded message classes and cPars with generated message classes (.msg files)
• change activity() to handleMessage() at the rest of places
• break up very long functions (mostly in MPLS code) and perform some more refactoring
• add regression tests
• IP address auto-assign, and auto-routing capability (it shouldn't be necessary to hand-write all routing tables)

-- AndrasVarga - 27 Feb 2004