The Ophy Module

Ophy module has three main parameters. One is “ProgaDelay” which records the propagation delay of the optical fiber, another is “bw” which contains the bandwidth of the channel, and the rest is “BitErr” which

represents the bit error rate of the optical link.

The ophy module has 4 main functions: sending packets and receiving packets, simulating propagation delay, bandwidth and bit error, recording the packet trace file for playing traffic flow animation, and logging the

accumulation data of the packet flow.

I. Sending and receiving packets

It is the basic function of a module which simulates the physical line of the networks. After executing the member function “init()” (its job is the initialization of the module), the ophy module gets the IDs of nodes connecting to this node, and it keeps the pointer of these nodes in the variable “ConnNode_”. When the packets are ready, the ophy module calls the “get()” function of the ophy module in the connected node to grab the outgoing packets to the destined ophy.

II. Simulating the bandwidth

The ophy module has a variable named “txState” to show whether the ophy module is “sending” the packet or not. We can not let another incoming packet pass if there is a packet in transmission. The variable

“txState” is a lock to lock or unlock the outgoing port. When a packet from upper module reaches the “send()” function in the ophy module, the ophy module will check the variable “txState”. If it is false, it means that the ophy module is idle. The ophy module allows the packet to pass when the sending status is idle. Once the ophy module puts a packet on transmission, it changes the value of “txState” to true (locked). Then other packets can not pass until the txState is unlocked again.

At the time the ophy module locks the variable “txState”, it also triggers a timer to simulate the transmission time. The length of the time is

“packet length / bandwidth of the ophy module”. When the timer expires, the ophy module calls a function named “TxHandler()”. The function

“TxHandler()” unlocks the variable “txState” and do several post-processing.

The method of simulating the bandwidth of the receiving side is similar.

The packet is passed to upper module or not according to the variable named “rxState”. The packet can pass if the variable “rxState” is false, otherwise the packet can not. The function named “RxHandle()” controls the status of the variable “rxState” and it is called when the receiving timer is expired.

III. Simulating the propagation delay

Actually, the ophy module do not “send” the packet to the connected ophy module, but it calls the function “get()” of the connected ophy module to grab the packets. It is the main consideration of simulating the propagation delay. When the packet passes the function which simulates bandwidth, it goes to the function of simulating propagation delay. This function will trigger a timer, and the expiration time is the propagation delay of this ophy module. When the timer expires, the ophy module calls the get() function of the connected ophy module to grab the packet. The ophy module of the other side will get the packet after the propagation

IV. Simulating the bit error

The variable named “BitErr” represents the bit error of the ophy module. We set the bit error rate before the simulation starts. When the packet comes to the ophy module, we add packet information to the packet.

The packet information contains the bit error rate recorded in the variable

“BitErr”.

When the packet is received by the destination ophy module, the bit error information is extracted. The packet is dropped or not according to the bit error information.

V. Simulation of store-and-forward and non-store-and-forward scheme We know that the all-optical networks are buffer-less and the transmission scheme is non-store-and-forward. We treat the light path which passes through several optical switches as a straight optical fiber.

The inside structure of the all-optical switches are matrices of lens. The incoming optical signal will be reflected to the outgoing port by the lens in switch. From the point of view of all-optical switches, when the first bit is received by the incoming port of the switch, the first bit is sent to the outgoing port at the same time. If the switch uses store-and-forward scheme, the first bit of the packet will not be sent to the outgoing port until the last bit of the packet is received.

For simulating this scheme, we have to know what type this node is at first. Only the traditional all-optical switches and optical burst switching

switches have non-store-and-forward characteristic. If the node is a router, the ophy module inside the node should follow store-and-forward scheme.

Even if it is an optical burst switch, the control packet needs to be transformed to digital signals (OEO process) to configure the switch and obviously it follows the store-and-forward scheme. Therefore we have such conclusion: 1. the ophy modules in the router should follow store-and-forward scheme. 2. The ophy modules which transmit control packets should follow the store-and-forward scheme.

Now we explain how the ophy module simulates the store-and-forward and none-store-and-forward behaviors. When the ophy module receives a packet from the source another ophy module, it triggers a timer and calls the function “RxHandler()” when the timer expires. If the packet needs to follow store-and-forward scheme, the ophy module passes the packet to the upper module in the function “RxHandler()”. If the packet needs to follow none-store-and-forward scheme, the ophy module passes the packet right now. We pass the packet to the upper module not waiting the last bit of the packet is received in the non-store-and-forward scheme.

The pictures below illustrate these schemes. The doted line represents the edge between receiving and sending. The left side of the dotted line represents the time before receiving / sending. The right side of the dotted line represents the time after receiving / sending.

Incoming port

Figure 5.1: The illustration of none-store-and forward.

Figure 5.2: the illustration of store-and-forward

In figure 5.1, we can see that when the first bit of the packet comes into the incoming port, the first bit of the packet goes out of the outgoing port. This is the non-store-and-forward scheme. From the view point of optical devices, we treat the non-store-and-forward switches as “a coupler

time

time Incoming port

Outgoing port

Incoming port

Outgoing port time Outgoing port

time

that switches”. The incoming optical fiber and the outgoing optical fiber can be seen as one optical fiber composed by these two.

In figure 5.2, it illustrates the store-and-forward scheme. The packet will not be sent to outgoing port until the whole packet is received by the incoming port. In our simulation environment, the optical burst switch has a parameter named “packet processing time” which represents the sum of the OEO time, the routing computation time, and the switching

computation time. In optical burst switching networks, this factor is very important. The switch need to transform the control packet from optical domain to electronic domain so that it can compute the burst reservation and change some control information in the packet, and therefore the control packet needs to follow store-and-forward rules. The time that store-and-forward scheme takes is a critical factor to the optical burst switching networks [5]. We have to simulate this feature to make sure that our system is correct.

VI. The packet-trace file logging and accumulation data logging

In the NCTUns, we need to log the packet-trace file in order to provide the GUI the packet streams and behaviors record so that the GUI can draw the play-back animation. The packet-trace printing function in the GUI shows the packet-trace log in detail, and we can inspect the behaviors of the networks. The other log data is performance and accumulation log.

This data contains the performance and accumulation information such as number of packet drop, number of packet collision, number of incoming or

use this data to draw graphs to show the variation of the data.

For packet-trace logging, we have to record the packets at 4 points: the point of starting transmission, the point of finishing transmission, the point of starting receiving, and the point of finishing receiving, to complete a packet-trace entry. The ophy module calls the function named “sslog()”

(sending start log) at the function “send()”, selog() (sending end log) at function “TxHandler()”, rslog (receiving start log) at the function “recv()”, and relog() (receiving end log) at function “RxHandler()”.

For logging the performance data, the ophy module records the number of incoming packets, the number of outgoing packets, and the number of packets that all pass this ophy module. It not only records the number of packets, but also the throughput. For logging the accumulation data, the ophy module records the number of bit-error drop, and number of collision drop.

The picture below shows the finite state machine of the ophy module.

Figure 5.3: The finite state machine of the ophy module