// // Copyright (C) 2003 CTIE, Monash University // // This program is free software; you can redistribute it and/or // modify it under the terms of the GNU 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 General Public License for more details. // // You should have received a copy of the GNU General Public License // along with this program; if not, write to the Free Software // Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. // //# @-titlepage (would conflict with main titlepage) //# <h1>Ethernet Model Documentation</h1> // // @page eth-index.html, Ethernet Model -- Start Page // //# This documents the Ethernet model created by David Wu and refined by Andras //# Varga at CTIE, Monash University, Melbourne, Australia. // // The Ethernet model contains a MAC model (EtherMAC), LLC model (EtherLLC) as well // as a bus (EtherBus, for modelling coaxial cable) and a hub (EtherHub) model. // A switch model (EtherSwitch) is also provided. // // A few useful topics: // - <a href="ether-overview.html">model overview</a> // - <a href="eth-standards.html">implemented standards</a> // - <a href="llc-app.html">communication between LLC and higher layers</a> // - <a href="appreg.html">application registration</a> // - <a href="physical.html">physical layer messaging</a> // - click <i>selected topics</i> in the navigation frame to see more topics // // If you can't wait to see the model, start here: // - the MixedLAN model contains hosts, switch, hub and bus; // - the <a href="largenet.html">\LargeNet model</a> contains hundreds of // computers, switches and hubs (numbers depend on model configuration in // largenet.ini), and mixes all kinds of Ethernet technologies; // - EtherHost is a sample node with an Ethernet NIC; // - EtherSwitch, EtherBus, EtherHub model switching hub, repeating hub and // the old coxial cable; // - basic compnents of the model: EtherMAC, EtherLLC/EtherEncap module types, // MACRelayUnit (MACRelayUnitNP and MACRelayUnitPP), EtherFrame message type, // MACAddress class // // Related documentation: // - <a href="../doxy/index.html" target="_top">C++ source documentation</a> // // // // @page ether-overview.html, Ethernet Model Overview // // <h3>Data packets and Ethernet frames</h3> // // Ethernet frames carry data packets as encapsulated cMessage objects. // Data packets can be of any message type (cMessage or cMessage subclass). // // The model encapsulates data packets in Ethernet frames using the <tt>encapsulate()</tt> // method of cMessage. Encapsulate() updates the length of the Ethernet frame too, // so the model doesn't have to take care of that. // // The models supports various Ethernet frame types: Ethernet II, 803.2 with // LLC header, and 803.3 with LLC and SNAP headers. The corresponding classes are: // EthernetIIFrame, EtherFrameWithLLC and EtherFrameWithSNAP. They all class // from EtherFrame which only represents the basic MAC frame with source and // destination addresses. EtherMAC only deals with EtherFrames, and does not // care about the specific subclass. // // // <h3>Autoconfiguration</h3> // // In order to facilitate building large models, EtherMAC and other Ethernet model // components provide some degree of auto-configuration. Specifically, transmission // rate and half duplex/full duplex mode can be chosen automatically so that // connecting Ethernet MACs have matching settings. The purpose is similar to // Ethernet Auto-Negotiation; however the mechanism is NOT a model of // Auto-Negotiation (e.g. EtherBus and EtherHub also actively participate, // which obviously does not happen in a real Ethernet.) // // What it does: // - the txrate parameters of EtherMAC represent the highest speed supported // by that station, or 0 for full autoconfiguration. Autoconfig will choose // the largest common denominator (the speed of the slowest station in the // collision domain) for all stations. If all stations are set to auto // txrate, 100Mb will be chosen, or 10Mb if there's a bus (EtherBus) in // the collision domain. // - the duplexEnabled parameter of EtherMAC means whether the station supports // duplex operation. However, duplex operation will actually be chosen only // if it's a DTE-to-DTE direct connection (there's no shared media like // EtherHub or EtherBus) and both sides have duplexEnabled=true set. // // How it works: // // Auto-configuration occurs at the beginning of the simulation, by // Ethernet model components (EtherMAC, EtherHub and EtherBus) exchanging // EtherAutoconfig messages with each other. See description of EtherAutoconfig // for more info. // // <h3>MAC and higher layers</h3> // // MAC and LLC are implemented as separate modules (EtherMAC and // EtherLLC/EtherEncap) because encapsulation/decapsulation functionality // is not always needed. (Switches don't do encapsulation/decapsulation.) // In switches, EtherMAC is used with MACRelayUnit. // // // <h3>EtherLLC and higher layers</h3> // // The EtherLLC module can serve several applications (higher layer protocols), // and dispatch data to them. Higher layers are identified by DSAP. // See <a href="appreg.html">Application registration</a> for more info. // // EtherEncap doesn't have the functionality to dispatch to different // higher layers because in practice it'll always be used with IP. // // // @page eth-standards.html, Ethernet: Implemented Standards // // The Ethernet model operates according to the following standards: // - Gigabit Ethernet: IEEE 802.3z-1998 // - Full-Duplex Ethernet with Flow Control: IEEE 802.3x-1997 // - Fast Ethernet: IEEE 802.3u-1995 // - Ethernet: IEEE 802.3-1998 // // Note: switches don't implement the Spanning Tree Protocol. You need to // avoid cycles in the LAN topology. // // // @page llc-app.html, 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. // // <h3>Rationale</h3> // // 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 <i>interface packet</i> 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. // // // @page appreg.html, EtherLLC: SAP Registration // // The Ethernet model supports multiple applications or higher layer // protocols. // // So that data arriving from the network can be dispatched to the // correct applications (higher layer protocols), applications // have to register themselves in EtherLLC. The registration // is done with the IEEE802CTRL_REGISTER_DSAP command // (see <a href="llc-app.html">communication between LLC and higher layers</a>) // which associates a SAP with the LLC port. Different applications // have to connect to different ports of EtherLLC. // // The ETHERCTRL_REGISTER_DSAP/IEEE802CTRL_DEREGISTER_DSAP commands use only the // dsap field in the Ieee802Ctrl structure. // // // @page physical.html, Ethernet: Messaging on the Physical Layer // // Messages sent by EtherMAC mark the beginning of a transmission. // The end of a transmission is not explicitly represented by a message, // but instead, the EtherMAC calculates it from the frame length and // the transmission rate. Frames are represented by EtherFrame, with // message kind=ETH_FRAME. // // When frames collide, the transmission is aborted -- in this case // EtherMAC makes use of the modelled jam signals to figure out // when colliding transmissions end. // // When a transmitting station senses a collision, it transmits a jam signal. // Jam signals are represented by a message with kind=JAM_SIGNAL. // When EtherMAC received a jam signal, it knows that one transmission // has ended in jamming -- thus when it receives as many jam messages // as colliding frames, it can be sure all transmissions have been aborted. // // Receiving a jam message marks the beginning (and not the end) // of a jam signal, so actually EtherMAC has to wait for the duration // of the jamming before assuming the channel is free again. // // // // @page ether-pause.html, Ethernet: PAUSE handling // // The 802.3x standard supports PAUSE frames as a means of flow // control. The frame contains a timer value, expressed as a multiple // of 512 bit-times, that specifies how long the transmitter should // remain quiet. If the receiver becomes uncongested before the // transmitter's pause timer expires, the receiver may elect to send // another Pause frame to the transmitter with a timer value of zero, // allowing the transmitter to resume immediately. // // EtherMAC will properly respond to PAUSE frames it receives // (EtherPauseFrame class, ETH_PAUSE message kind), // however it will never send a PAUSE frame by itself. (For one thing, // it doesn't have an input buffer that can overflow.) // // EtherMAC, however, transmits PAUSE frames received by higher layers, // and EtherLLC can be instructed by a command to send a PAUSE frame to MAC. // // MACRelayUnit types (and thus EtherSwitch) currently implement a very simple // scheme for sending PAUSE frames -- this can be refined if the need arises. // // For background on PAUSE, see e.g. // http://www.computer.org/proceedings/lcn/0309/03090160abs.htm, // http://www.nwfusion.com/netresources/0913flow.html, and // http://www.nwfusion.com/netresources/0913flow2.html. // // // @page largenet.html, LargeNet model description // // The LargeNet model demonstrates how one can put together models of large // LANs with little effort, making use of MAC auto-configuration. // // LargeNet models a large Ethernet campus backbone. As configured in the // default omnetpp.ini, it contains altogether about 8000 computers // and 900 switches and hubs. This results in about 165MB process size // on my (32-bit) linux box when I run the simulation. // The model mixes all kinds of Ethernet technology: Gigabit Ethernet, // 100Mb full duplex, 100Mb half duplex, 10Mb UTP, 10Mb bus ("thin Ethernet"), // switched hubs, repeating hubs. // // The topology is in LargeNet.ned, and it looks like this: there's chain // of n=15 large "backbone" switches (switchBB[]) as well as four more // large switches (switchA, switchB, switchC, switchD) connected to // somewhere the middle of the backbone (switchBB[4]). These 15+4 switches // make up the backbone; the n=15 number is configurable in omnetpp.ini. // // Then there're several smaller LANs hanging off each backbone switch. // There're three types of LANs: small, medium and large (represented by // compound module types SmallLAN, MediumLAN, LargeLAN). A small LAN // consists of a few computers on a hub (100Mb half duplex); a medium // LAN consists of a smaller switch with a hub on one of its port // (and computers on both); the large one also has a switch and a hub, // plus an Ethernet bus hanging of one port of the hub (there's still hubs // around with one BNC connector besides the UTP ones). // By default there're 5..15 LANs of each type hanging off each backbone // switch. (These numbers are also omnetpp.ini parameters like the length // of the backbone.) // // The application model which generates load on the simulated LAN is // simple yet powerful. It can be used as a rough model for any // request-response based protocol such as SMB/CIFS (the Windows file // sharing protocol), HTTP, or a database client-server protocol. // // Every computer runs a client application (EtherAppCli) which connects // to one of the servers. There's one server attached to switches A, B, // C and D each: serverA, serverB, serverC and serverD -- server selection // is configured in omnetpp.ini). The servers run EtherAppSrv. // Clients periodically send a request to the server, and the request // packet contains how many bytes the client wants the server to send back // (this can mean one or more Ethernet frames, depending on the byte count). // Currently the request and reply lengths are configured in omnetpp.ini // as intuniform(50,1400) and truncnormal(5000,5000). // // The volume of the traffic can most easily be controlled with the // time period between sending requests; this is currently // set in omnetpp.ini to exponential(0.50) (that is, average 2 // requests per second). This already causes frames to be dropped // in some of the backbone switches, so the network is a bit // overloaded with the current settings. // // The model generates extensive statistics. All MACs (and most other // modules too) write statistics into omnetpp.sca at the end // of the simulation: number of frames sent, received, dropped, etc. // These are only basic statistics, however it still makes the // omnetpp.sca file to be about 28 Meg in size. You can use the Scalars // program introduced in OMNeT++ 3.0a4 to analyse this file. // (If the file size is too big, writing statistics can be disabled // per module, with the "writeScalars" bool parameter. The model // can also record output vectors (omnetpp.sca), but this is // currently disabled in omnetpp.ini because the generated file // can easily reach gigabyte sizes. // //