Implementation of OBS core node control system

Optical Burst Switching (OBS) network is based on existing technical conditions, combining the advantages of optical line switching and optical packet switching, to effectively implement IP over WDM solutions. OBS network includes core nodes and edge nodes. The main function of the core node is to perform routing and channel resource scheduling, set up the optical switching matrix, and reserve all-optical channels for burst data packets (BDP) according to the information provided by the burst control packet (BCP: Burst Control Packet).

Considering the simplicity of the JIT protocol scheduling algorithm and the fast scheduling processing speed, it is not necessary to implement the scheduling algorithm in an independent module. On the contrary, the addition of modules will bring additional delays and consume more processing time. This paper proposes a core node controller structure for the JIT protocol, which integrates the network layer routing function and the OBS layer channel scheduling function into the same module for processing. On the one hand, the integration of modules can shorten the processing time of BCP; on the other hand, in this structure, forwarding is performed after scheduling, so that routing selection can select other feasible output ports when there is no available channel at the optimal output port, and then schedule the channel, thereby reducing the probability of packet loss.

1. Design and implementation of controller

The implementation uses the JIT (Just-In-Time) signaling protocol with explicit setup and estimated teardown. This protocol only has SETUP messages but no REALEASE messages. After the core node receives and completes the processing of the SETUP message, it immediately reserves resources for it and estimates the time to release resources based on the offset time and data packet length contained in the SETUP message.

1.1 System composition

Figure 1 is a block diagram of the OBS core controller system, which is divided into a receiving module, a frame analysis module, a cross matrix, a sending module, and a routing and scheduling module. A cache structure is set between each functional module so that each module can work independently, thereby realizing a pipelined working mode between the modules. The main functions of each module are as follows:

The receiving module receives the data on the control channel, restores it into Ethernet frames, and writes it into the receiving buffer.

The frame parsing module reads the Ethernet frame from the receiving buffer, parses the corresponding protocol field information, and performs corresponding processing. If it is not a BCP packet, it directly forwards it; if it is a BCP packet, it sends the scheduling related information to the routing and scheduling module, and forwards or discards it according to the message returned by the routing and scheduling module.

The routing and scheduling module is responsible for implementing the routing selection function of the network layer and the channel scheduling function of the OBS layer. It contains a forwarding routing table and a channel resource library. The forwarding routing table stores the routing table information of this node for routing query; the channel resource library records the data channel resource occupancy of each output port of this node and is responsible for controlling the optical switch matrix.

The crossbar matrix switches the packets in the input buffer to the output buffer. The sending module updates the offset time of the BCP packet and then assembles it into an Ethernet frame and sends it to the control channel.

1.2 Design and implementation of main modules

1.2.1 Frame parsing module

The frame parsing module is responsible for parsing the frame type and content, and processing some network layer protocols and OBS layer protocols, while controlling the work of the routing and scheduling modules. Its main work can be divided into the following parts: 1. Read the received data packets from the receiving buffer and record the receiving time to update the offset time of the BCP packet; 2. Processing of the network layer protocol, including type information, packet length, acquisition of the destination network address and update of TTL; 3. Processing of the OBS layer protocol, including calculation and update of the offset time, control of the routing and scheduling modules, etc.; 4. For the processed data packets, the local packet is uploaded to the network management module of this node, and those that need to be forwarded are sent to the output buffer.

The state transition diagram of the frame parsing module is shown in Figure 2. After power-on, it first enters the Idle state. In the Idle state, it checks whether there are new data packets in the receiving cache. If there are, it enters the ReadMAC state, reads the MAC header information, and determines the MAC frame type. If it is not an IP data packet, it will be discarded. Otherwise, it enters the ReadIP state. In this state, the length, type, TTL and other information of the IP data packet are read. If it is not a BCP packet, it enters the Route state to select the route. If it is a local packet, it is uploaded to the network management module. Otherwise, it enters the Update state; if it is a BCP packet, it enters the Route&Schedule state to start the work of the routing and scheduling module. If the scheduling is unsuccessful, the BCP packet will be discarded. If it is successful, it also enters the Update state; in the Update state, the TTL is updated. If the wavelength number scheduled changes, the corresponding information must also be updated. After that, it enters the Forward state, sends the updated data packet to the output cache, and processes the next frame.

1.2.2 Routing and Scheduling Module

FIG3 is a schematic diagram of the structure of the routing table and the channel resource library. The routing table contains multiple routing entries, each of which includes two parts of information: the destination network address and the output port number. The process of searching for a route is: starting from the first entry, the destination network address is matched with the network address in each entry in turn, and the output port number is obtained if the match is successful. Ptr is used to point to the current matching entry. If a second search is required, just continue the search from the entry pointed to by Ptr.

The channel resource library contains the channel allocation information of all ports. Each port is a group, including a control unit CU and a group of timers, and each timer corresponds to a channel. When the channel is idle, the timer is also idle. Each time a channel is successfully allocated to BCP, the optical switch control signal needs to be turned on, and the corresponding timer is started at the same time. The time is set to the offset time + reserved time. When the timing ends, the optical switch control signal is turned off. The control unit can determine the usage status of each channel according to the working status of each timer and perform channel allocation.

Figure 3 Structural diagram of routing table and channel resource library The implementation process of routing and scheduling function is as follows: First, detect the scheduling request signal of each frame parsing module. If it is valid, read the destination network address and start the routing and scheduling process at the same time. First, find the first routing table item that matches the destination network address in the routing table to get the output port; then check the channel resource library to see if there is an idle data channel at the port. If so, reserve the channel, set the optical switch matrix, start the corresponding timer, and if the scheduling is successful, return the information of the output port and data channel to the frame parsing module; if there is no idle channel, it is necessary to continue to search for matching items in the routing table, and search for idle channels in the channel resource library again after finding them, and continue in this way; if no idle channel can be found after searching all the items in the routing table, a scheduling failure signal is returned to the frame parsing module.

2 Experimental tests

We have implemented this design in hardware. Figure 4 is a circuit timing simulation diagram obtained using the QuartusII tool. In the figure, 1, 2, 3, 4, and 5 are status indication signals, corresponding to the frame reception completion signal, the reading status signal, the protocol processing status signal, the routing and scheduling status signal, and the forwarding status signal; 6 and 7 are output signals, corresponding to the scheduling completion signal and the optical switch setting signal, respectively.

Figure 2 Working sequence of BCP packet receiving and processing process (see the end) As can be seen from Figure 4, in the process of processing an OBS packet, it goes through multiple states such as frame data reading, protocol processing, routing and scheduling, and forwarding. It only takes 100ns from the completion of BCP packet reception to the issuance of the optical switch setting signal, which is a great improvement compared to the existing implementation scheme. It can fully meet the requirements of the existing OBS network for the core node switching speed.

3 Conclusion

The test results show that the shortest time from receiving the BCP packet to sending the optical switch setting signal is 100ns, which significantly shortens the processing time of the control packet in the core node.