Changes between Initial Version and Version 1 of Old/OTG/ArchitectureDesign


Ignore:
Timestamp:
Sep 26, 2005, 2:34:22 AM (19 years ago)
Author:
zhibinwu
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Old/OTG/ArchitectureDesign

    v1 v1  
     1= OTG Software Architecture Design =
     2''Zhibin Wu''
     3== Introduction ==
     4The ORBIT Traffic Generator software is designed for the sole purpose of using on NSF ORBIT Testbed. It is a typical application of ORBIT Testbed. ORBIT Traffic Generator is a special tool for experimenters to generate traffic for testing network performance.  Its primary focus is to generate bulk data of various characteristics and use either TCP or UCP protocol to transport data. ORBIT Traffic Generator Software consists of two components. One is the OTG (ORBIT Traffic Generator); the other is OTR (Orbit Traffic Receiver). They are used in pair to transmit and receive data respectively. The OTG software has a flexible design to support various configuration of generators such as CBR and exponential on/off traffic.
     5 
     6=== Summary of Major Design Requirements ===
     7ORBIT Traffic Generator Software consists of two components. One is the OTG (ORBIT Traffic Generator); the other is OTR (Orbit Traffic Receiver). The OTG is running on a sender node and OTR is running on a receiver node.
     8The Hardware platform for the software is ORBIT nodes. Each ORBIT node is a micro-computer with Linux Operation system. Nodes are connected like a grid with wired or wireless communication links.
     9
     10The OTG software must support various '''TG''' (Traffic Generator). TG is regarded as a replaceable sub-component of OTG. TG Structure should be kept as simple as possible to let the user design custom TG conveniently.
     11
     12=== General Approach ===
     13==== Design Diagram ====
     14http://www.winlab.rutgers.edu/~zhibinwu/image/OtgDesign.gif [[BR]]
     15Figure 1. Design Diagram
     16
     17A very important motivation and feature of ORBIT Traffic Generator design is its integration with the [http://svn.orbit-lab.org/projects/oml OML] (''ORBIT Measurement Library'') framework.  The properties of each packet generated or received such as packet size, packet deliver time are all reported to OML by OTG and OTR. Users can calculate certain measurements like throughput, delay by either applying special OML filters or querying the OML database directly. There also exists an interface to use LIBMAC to correlate each packet with corresponding physical layer parameters. 
     18The design complies with modular principle and different modules are kept loosely coupled.  The interface to the [http://svn.orbit-lab.org/projects/oml OML], the interface to the user are supposed to be dynamically generated from an ORBIT application definition file. Both of them should be independent with the core module of application.
     19TG and OTG are integrated through a simple standard interface.
     20The whole software is designed by OOP (Object-Oriented Programming) Method with C++ language.
     21
     22== Overall Design ==
     23=== Software Architecture Diagram ===
     24http://www.winlab.rutgers.edu/~zhibinwu/image/SoftArc.gif [[BR]]
     25Figure 2. Software Architecture Diagram
     26
     27The OTG and OTR program are implemented in the user space. To support point-to-multipoint communication, each port in OTG could associate more than one stream object. Based on different source and destinations, packets are classified to several streams. A port in OTG could deliver several streams to different OTR program through a common UDP or TCP port. Also, the OTR could receive several streams from different OTG program.
     28To let the receiver software OTR have the capability to extract PHY measurements from the driver, we need a custom driver which is compatible with LibMac library.
     29The abovementioned architecture allows us to extend the OTG-OTR application to support multiple sending streams and multiple receiving applications. However, the baseline requirement for the OTG/OTR design is the very simple one-sender-one-receive point-to-point communication. Therefore, the baseline application will only include a communication path and components in the shaded region. And this case will also satisfy the test and measurement demands of most users.
     30
     31'''Note that in OTG and OTR, "Stream" and "Gate" are master components respectively. They control the sending and receiving thread respectively.There also exists an OMLObject pointer in Gate and Stream to enable control of OML measurements reporting.'''
     32
     33=== Design of OTG ===
     34The OTG is a multi-thread application. The main thread is used to handle run-time user-input. For each stream, a separate thread is created for sending a stream to the corresponding application of another node. 
     35Each stream thread performs a while loop to conduct following operations:
     36 1. Load a packet from the "TG"
     37 1. Wait till the "time to send" of this packet
     38 1. Send the packet through the "Port".
     39Each "stream object" is uniquely bound to a TG object and Port object. That is to say, one Port is only used for sending one stream. But one OTG application could have multiple streams, thereby using multiple ports and multiple TGs.  From above we can see that the Stream object is the master object controlling other two objects: TG and Port, which both are passive and would be only used when the interface functions are called.
     40Note that this architecture design allows one OTG Application having multiple streams. ''In practice, however, the user is now limited to start only one stream with one OTG application.''
     41
     42=== Design of OTR ===
     43
     44The OTR is a multi-thread application too. The main thread is to handle user input. And for each Gate object, a separate thread is going to create to receive packets from this gate. Each Gate object is the master object to control other objects in the OTR program Whenever an OTR application is started, at least one Gate has to be started as default. However, a gate is not limited to receiving homogenous packets from the same source.  If multiple sources or connections are communicating with one socket port, the Gate will de-multiplex the traffic and give each packet a flow identifier to show its source address. However, all packets are still passed to the same Sink object.
     45When an OTR application is started, a default gate will be created.  A default sink object is also created to bind to this gate. In the case of UDP, whenever a packet from a new address, it will generate a new flow for all packets from this address. In the case of TCP, whenever accept a new connection; a new flow is created to accommodate the packets in this direction.
     46Note that this architecture design allows one OTG Application having multiple Gates.  ''But in practice, the user is now limited to start only one Gate with one OTR application.''
     47
     48== Component Design ==
     49
     50Stream, Port, TG, Gate and Sink are key components of the core module of OTG and OTR.
     51
     52=== TG ===
     53
     54TG (Traffic Generator) is the entity which supplies packets to be transmitted. The OTG software support multiple types of traffic generators. TG is the source of packet. TG is designed as a complete passive object which is driven by the request of Stream Object. The TG generates a packet stream with a certain packet size distribution and a certain packet interval distribution.  The contents of the packet are usually unimportant and would be randomly filled. Also, the TG object has a function to fill the payload with certain content which is suitable for extending the OTG program as an FTP application.
     55
     56The standard interface between TG and OTG is a member function of the Generator class called “nextPacket (Packet *p)”. Whenever the main thread of OTG uses this function, a packet object is passed as the input parameter. And in the instantiation of this function, the generator should fill the packet size and timestamp of this packet object.
     57
     58=== Port ===
     59Port object is designed as a sending communication interface of the application. Port only functions a sender. Each port is controlled by a Stream object.  A variety of Port objects are supported based on the supporting protocol. Currently, we have three protocols supported: UDP, TCP, Ethernet RAW sockets.
     60=== Stream ===
     61The introduction of the “stream” object is to use a common class to control different type of TG and Ports. Each Stream is designed like a packet queue which connects the TG and Port. But it only holds one packet.  It generates one empty packet structure for TG. Once TG feed this packet with payload and other packet-delivery information, the packet is stored in the stream. This packet will be given to '''Port''' for transmission according to the deliver time property of this packet.
     62=== Gate ===
     63Gate object is designed as a receiving communication interface of the OTR application. The name Gate is named as a counterpart of "Port". In other words, Gate is "receiving Port" to handling reception. Basically, we have two working modes for a Gate: w or w/o libmac support. With Libmac support, the OTR program cold extract some PHY layer parameters. A variety of Gate objects are supported based on the supporting  protocol. Currently, we have three  protocols supported: UDP, TCP, Ethernet RAW sockets. [[BR]]
     64In General, the gate conduct following operations for each incoming packet.
     65 1. receive through socket interface.
     66 1. demultiplex (getting the source information)
     67 1. post-process (set some properties)
     68 1. sink report measurements and dump the packet.
     69 1. pass to sink object for dumping
     70
     71The demultiplex part of UDP Gate and TCP Gate is slightly different:
     72 * UDP Socket create a new flow based on the received packet's source address if necessary. therefore, we use simple consecutive numerical numbers as flow id.
     73 * TCP Socket would create a new flow when acceptNewConnnection() funciton is called. This occured before a single TCP packet is receivd. We use socket file descriptor as flow id.
     74[[BR]]
     75''Note: We did not support demultiplexing for raw sockets now''
     76
     77=== Flow ===
     78Each gate holds a flow table to record the demultiplex information. It says which packet is from which source IP and port.
     79Unlike previous design, the packet is no longer passed to the flow object, but from gate to sink directly.
     80Flow table is just an index table to checking the packet's srouce information and set the "flow id" measurement for theis packet.
     81The information in the table should include:
     82 * flow identifier
     83 * sender IP address
     84 * sender port (if applicable)
     85 * sneder MAC address (if applicable)
     86=== Sink ===
     87Sink is dummy. Just dump every received packets to nowhere.
     88
     89== User Interface ==
     90
     91The ideal design goal for user interface is to let this part should be automatically generated by an application interpretation engine. When this engine is feed with the application definition file, C source codes will be generated and compiled with other parts of this program.
     92
     93Currently, the interface is handled by an extension of [http://directory.fsf.org/libs/popt.html POPT] utility.
     94
     95=== Command-line Input to start the program ===
     96
     97The basic format for user to specify  an option is “--option [arg]” format. Because we have multiple kind of protocols and generators to support, the commands to configure the OTG program and OTR program need to first figure out those type information. After that, further commad-line optons about that specific generator and protocol-port could be parsed further. However, the user only need to give all options in one command line. The program will automatically parse them in this 2-tier manner.
     98
     99==== Select Protocol and Generator Type ====
     100The “parseOptionsPhase1” functon in the main program (otg.cpp & otr.cpp) is in charge of parsing the necessary protocol and generator types. After parsing that, a specific generator and port will be created.
     101====    Get 2nd Tier Option ====
     102The “parseOptionsPhase2” functon in the main program (otg.cpp & otr.cpp) is in charge of getting and parsing the protocol and generator optons.
     103
     104=== Run-time Commands ===
     105==== Program Termination ====
     106The OTG and OTR program is not controlled by pre-defined test duration. Instead, it has to be terminated by the “exit” command.  As long as the command is not given, the OTG will keep pumping traffic and OTR program will keep receiveing incoming packets.
     107
     108==== Pause & Resume ====
     109The design for user run-time pause and resume is to be handled by the [source:trunk/src/cpp/stream.h#latest Stream] object. The Stream will pause its clock and stop loading packets from generator whenever a "pause" command is given by user.
     110==== Change TG Parameters in Run-time ====
     111=== Help information ===
     112Usually, --help should list all available options. But with current POPT package we cannot produce “help” information for unknown port type and generator types. So, simply type “--help” wll not give all possible options, but only the [protocol][generator] options.
     113
     114== Measurements ==
     115Measurement are generated within the OTG and OTR software and reported to a library server in ORBIT testbed throughput the “OML” architecture. In brief, the measurements are collected by each OML client in every running node and sent to a collection server. If an application wants to use OML, the application has to first call a “init_oml” function. Then add different measurement-points in the application where a measurement is triggered, anther OML function has to be called. Finally, those measuremts will appear as records in an OML databases.
     116
     117=== Per-Packet Measurement ===
     118There are a lot of measurements are associated with a single packet.
     119 * Packet Generation Time
     120 * Packet Transmit Time
     121 * Packet Receive Time
     122 * Packet Size
     123Measurement are generated within the OTG and OTR software and reported to a library server in ORBIT testbed throughput the “OML” architecture. In brief, the measurements are collected by each OML client in every running nodes and sent to a collection server.
     124
     125 === Per-Stream Measurement  ===
     126For each stream generated by OTG, a stream id and  pkt number is stamped in the payload of the packet. And those information could be retrieved by OTR. Also, the OTR could demultoplex all receiving pakets  and put them in different flows. So, there are 4 measurements corresponding to this:
     127 * packet sequence number from sender side
     128 * Flow id from receiver side
     129 * Flow packet number
     130=== Physical layer measurements ===
     131With the help of LibMAC, two physical layer parameters could be extracted from a custom driver:
     132 * '''RSSI''': Received  Singal Streangth Index
     133 * TxRate: Xmit rate indicated in the Signal Field of PLCP header of received packet. for example 55 indicates 5.5Mbps, 540 indicates 54Mbps.
     134=== Measurement Reporting Triggers ===
     135The OTG has one measurement reporting trigger and OTR has two measurement reporting triggers. In OTG, measurement will report when the Stream is going to call Port->sendPacket()function). It will trigger reporting of four measurements:
     136 * pkt_seqno
     137 * pkt_size
     138 * gen_timestamp
     139 * tx_timestamp
     140In OTR, measurements will report by the Gate object whenever a packet is processed. Six measuremts are triggered:
     141 * pkt_seqno (stamped in sender side)
     142 * flow_no:id of the flow
     143 * rcvd_packet_size: Received Payload size of the packet
     144 * rx_timestamp: Time when packet is being received
     145 * rssi:
     146 * xmit_rate
     147Another measurement table is also created by OTR using oml_newflow() call for demultiplexing receiving packets.
     148 * flow id
     149 * sender ip
     150 * sender port
     151
     152== Fault Management and Exception Handling ==
     153
     154Basically, information of every critical exception is put into ''stdout'' if the program is going to abort.  The information is outputed by an "throw" operation. and the main program will eventually output it in STDOUT. However, it seems only the function in the first-tier of main program could throw it correctly and the main program will output it into STDOUT, for those functions referred deeper, we see
     155{{{
     156terminate called after throwing an instance of 'char const*'
     157Aborted
     158}}}
     159This part needs to be discussed further.
     160
     161----
     162== See Also ==
     163 * [wiki:OtgMainProgram Understanding OTG Main Program]
     164 * [wiki:OtrMainProgram Understanding OTR Main Program]
     165 * [wiki:WritingTrafficGenerators Function Specification: Writing New Traffic Generators]
     166 * [wiki:FuncSpecOmlIntegration Function Specification: OTG/OTR with OML Integration]
     167 * [wiki:FuncSpecUserInterface Function Specification: User Interface Design]
     168 * [wiki:FuncSpecUseLibmac Function Specification: Interfacing LIBMAC]
     169 * [wiki:FuncSpecPort Function Specification: Port]
     170 * [wiki:FuncSpecGate Function Specification: Gate]
     171 * [wiki:FuncSpecStream Function Specification: Stream]
     172 * [wiki:FuncSpecTiming Function Specification: Timing Control]
     173
     174