This documentation is released under the Creative Commons license// // Copyright (C) 2003 Andras Varga // // This program is free software; you can redistribute it and/or // modify it under the terms of the GNU Lesser General Public License // as published by the Free Software Foundation; either version 2 // of the License, or (at your option) any later version. // // This program is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the // GNU Lesser General Public License for more details. // // You should have received a copy of the GNU Lesser General Public License // along with this program; if not, see <http://www.gnu.org/licenses/>. // // @page whatsnew.html, What's New // // <pre> // <nohtml> // @include ../../WHATSNEW // </nohtml> // </pre> // // @page inet-architecture.html, Architecture of the INET Framework // // The INET Framework builds upon OMNeT++, and uses the same concept: // modules communicating by message passing. // // <h3>Modules and protocols</h3> // // Protocols are represented by simple modules. A simple module's external // interface (gates [connectors] and parameters) is described in a NED file, // and the implementation is contained in a C++ class with the same name. // Some examples: ~TCP, ~IPv4. // // These modules can be freely combined to form hosts and other network devices // with the NED language (no C++ code and no recompilation required). // Various pre-assembled host, router, switch, access point, etc. models can // be found in the <code>Nodes/</code> subdirectory (for example: ~StandardHost, // ~Router), but you can also create your own ones for tailored to your particular // simulation scenarios. // // Network interfaces (Ethernet, 802.11, etc) are usually compound modules (i.e. // assembled from simple modules) themselves, and are being composed of a queue, // a MAC, and possibly other simple modules. See ~EthernetInterface as an example. // // Not all modules implement protocols though. There are modules which hold // data (for example ~IPv4RoutingTable), perform autoconfiguration of a network // (~FlatNetworkConfigurator), move a mobile node around (for example // ~ConstSpeedMobility), and perform housekeeping associated with radio channels // in wireless simulations (~IRadioMedium). // // Protocol headers and packet formats are described in message definition // files (msg files), which are translated into C++ classes by OMNeT++'s // <i>opp_msgc</i> tool. The generated message classes subclass from OMNeT++'s // <code>cMessage</code> class. // // <h3>About the documentation</h3> // // The INET Framework documentation itself is also comprised of two bodies of HTML pages: // <i>neddoc</i> generated from NED and MSG files using OMNeT++'s <i>opp_neddoc</i> tool, // and the documentation of the underlying C++ classes, generated from the source files // using Doxygen. // The C++ doc is generated in a way that it contains <b>the full C++ source code</b> // as HTML pages. It is syntax highlighted, and variable and class names are hyperlinked // and cross-referenced, which makes it convenient for exploring the code. // // // <h3>Common modules in hosts and routers</h3> // // There are some common modules that appear in all (or many) host, router and device // models. // // - ~InterfaceTable. This module contains the table of network interfaces // (eth0, wlan0, etc) in the host. This module does not send or receive messages: // it is accessed by other modules using standard C++ member function calls. // Other modules rely on the interface table submodule within the host to be called // <code>interfaceTable</code> to be able to find it. (They obtain a <code>cModule *</code> // pointer to it, then cast it to <code>InterfaceTable *</code> to be able to call its // functions). Network interfaces get dynamically registered (added to the table) // by simple modules implementing the network interface, for example ~EtherMAC. // // - ~IPv4RoutingTable. This module contains the IP (v4) routing table, and heavily relies // on ~InterfaceTable for its operation. This module is also accessed from other // modules (typically ~IPv4) by calling the public member functions of its C++ class. // There are member functions for querying, adding, deleting routes, and // finding the best matching route for a given destination IP address. // The routing table submodule within the host (router) must be called // <code>routingTable</code> for other modules to find it. // // - ~IPv6RoutingTable. This is like ~IPv4RoutingTable, but for IPv6. // // <h3>Common modules at network level</h3> // // Some modules have only one instance, at global network level: // // - ~FlatNetworkConfigurator assigns IP addresses to hosts and routers, // and sets up static routing. // // - ~ScenarioManager makes simulations scriptable. Modules can be made to support // scripting by implementing the <code>IScriptable</code> C++ interface. // // - ~IRadioMedium is required for wireless simulations. It keeps track of which // nodes are within interference distance of other nodes. // // <h3>Communication between protocol layers</h3> // // In the INET Framework, when an upper-layer protocol wants to send a data // packet over a lower-layer protocol, the upper-layer module just sends the // message object representing the packet to the lower-layer module, which // will in turn encapsulate it and send it. The reverse process takes place // when a lower layer protocol receives a packet and sends it up after // decapsulation. // // It is often necessary to convey extra information with the packet. For // example, when an application-layer module wants to send data over TCP, some // connection identifier needs to be specified for TCP. When TCP sends a // segment over IP, IP will need a destination address and possibly other // parameters like TTL. When IP sends a datagram to an Ethernet interface for // transmission, a destination MAC address must be specified. This extra // information is attached to the message object to as <i>control info</i>. // // Control info are small value objects, which are attached to packets // (message objects) with its <code>setControlInfo()</code> member function. // Control info only holds auxiliary information for the next protocol layer, // and is not supposed to be sent over the network to other hosts and routers. // // @page ipaddresses.html, Specifying IP (IPv6) addresses in module parameters // // In INET, ~TCP, ~UDP and all application layer modules work with // both IPv4 and IPv6. Internally they use the Address C++ class, which // can represent both IPv4 and IPv6 addresses. // // Most modules use the L3AddressResolver C++ class to resolve addresses // specified in module parameters in omnetpp.ini. // L3AddressResolver accepts the following syntax: // // - literal IPv4 address: "186.54.66.2" // - literal IPv6 address: "3011:7cd6:750b:5fd6:aba3:c231:e9f9:6a43" // - module name: "server", "subnet.server[3]" // - interface of a host or router: "server/eth0", "subnet.server[3]/eth0" // - IPv4 or IPv6 address of a host or router: "server(ipv4)", // "subnet.server[3](ipv6)" // - IPv4 or IPv6 address of an interface of a host or router: // "server/eth0(ipv4)", "subnet.server[3]/eth0(ipv6)" // // @page irt.html, The IP routing files // // Routing files are files with <tt>.irt</tt> or <tt>.mrt</tt> extension, // and their names are passed in the routingFileName parameter // to ~IPv4RoutingTable modules. RoutingTables are present in all // IP nodes (hosts and routers). // // Routing files may contain network interface configuration and static // routes. Both are optional. Network interface entries in the file // configure existing interfaces; static routes are added to the route table. // // Interfaces themselves are represented in the simulation by modules // (such as the ~PPP module). Modules automatically register themselves // with appropriate defaults in the ~IPv4RoutingTable, and entries in the // routing file refine (overwrite) these settings. // Interfaces are identified by names (e.g. ppp0, ppp1, eth0) which // are normally derived from the module's name: a module called // <tt>"ppp[2]"</tt> in the NED file registers itself as interface ppp2. // // An example routing file (copied here from one of the example simulations): // // <pre> // ifconfig: // // # ethernet card 0 to router // name: eth0 inet_addr: 172.0.0.3 MTU: 1500 Metric: 1 BROADCAST MULTICAST // Groups: 225.0.0.1:225.0.1.2:225.0.2.1 // // # Point to Point link 1 to Host 1 // name: ppp0 inet_addr: 172.0.0.4 MTU: 576 Metric: 1 // // ifconfigend. // // route: // 172.0.0.2 * 255.255.255.255 H 0 ppp0 // 172.0.0.4 * 255.255.255.255 H 0 ppp0 // default: 10.0.0.13 0.0.0.0 G 0 eth0 // // 225.0.0.1 * 255.255.255.255 H 0 ppp0 // 225.0.1.2 * 255.255.255.255 H 0 ppp0 // 225.0.2.1 * 255.255.255.255 H 0 ppp0 // // 225.0.0.0 10.0.0.13 255.0.0.0 G 0 eth0 // // routeend. // </pre> // // The <tt>ifconfig...ifconfigend.</tt> part configures interfaces, // and <tt>route..routeend.</tt> part contains static routes. // The format of these sections roughly corresponds to the output // of the <tt>ifconfig</tt> and <tt>netstat -rn</tt> Unix commands. // // An interface entry begins with a <tt>name:</tt> field, and lasts until // the next <tt>name:</tt> (or until <tt>ifconfigend.</tt>). It may // be broken into several lines. // // Accepted interface fields are: // - <tt>name:</tt> - arbitrary interface name (e.g. eth0, ppp0) // - <tt>inet_addr:</tt> - IP address // - <tt>Mask:</tt> - netmask // - <tt>Groups:</tt> Multicast groups. 224.0.0.1 is added automatically, // and 224.0.0.2 also if the node is a router (forwarding==true). // - <tt>MTU:</tt> - MTU on the link (e.g. Ethernet: 1500) // - <tt>Metric:</tt> - integer route metric // - flags: <tt>BROADCAST</tt>, <tt>MULTICAST</tt>, <tt>POINTTOPOINT</tt> // // The following fields are parsed but ignored: <tt>Bcast</tt>,<tt>encap</tt>, // <tt>HWaddr</tt>. // // Interface modules set a good default for MTU, Metric (as 2e9/bitrate) and // flags, but leave inet_addr and Mask empty. inet_addr and mask should // be set either from the routing file or by a dynamic network configuration // module. // // The route fields are: // // <pre> // Destination Gateway Netmask Flags Metric Interface // </pre> // // <i>Destination, Gateway</i> and <i>Netmask</i> have the usual meaning. // The <i>Destination</i> field should either be an IP address or "default:" // (to designate the default route). For <i>Gateway</i>, <tt>*</tt> is also // accepted with the meaning <tt>0.0.0.0</tt>. // // <i>Flags</i> denotes route type: // - <i>H</i> "host": direct route (directly attached to the router), and // - <i>G</i> "gateway": remote route (reached through another router) // // <i>Interface</i> is the interface name, e.g. <tt>eth0</tt>. // // // // @page ipv6overview.html, IPv6 model overview // // IPv6 support is implemented by several cooperating modules. The ~IPv6 module // implements IPv6 datagram handling (sending, forwarding etc). It relies on // ~IPv6RoutingTable to get access to the routes. ~IPv6RoutingTable also contains the // neighbour discovery data structures (destination cache, neighbour cache, // prefix list -- the latter effectively merged into the route table). Interface // configuration (address, state, timeouts etc) is held in the ~InterfaceTable, // in <tt>IPv6InterfaceData</tt> objects attached to <tt>InterfaceEntry</tt> // as its <tt>ipv6()</tt> member. // // The ~IPv6NeighbourDiscovery module implements all tasks associated with // neighbour discovery and stateless address autoconfiguration. The data // structures themselves (destination cache, neighbour cache, prefix list) // are kept in ~IPv6RoutingTable, and are accessed via public C++ methods. // Neighbour discovery packets are only sent and processed by this module -- // when ~IPv6 receives one, it forwards the packet to ~IPv6NeighbourDiscovery. // // The rest of ICMPv6 (ICMP errors, echo request/reply etc) is implemented in // the ~ICMPv6 module, just like with IPv4. ICMP errors are sent to // ~IPv6ErrorHandling, which the user can extend or replace to have errors // handled in the way she likes. // package inet;
This documentation is released under the Creative Commons license