KR100287910B1 - Board-to-board communication method of switching device - Google Patents

Abstract

According to the present invention, when the subboard is controlled by the main board, the packet is safely controlled, the packet is transmitted to a desired subboard so that packet loss does not occur, and when there is no response from the subboard, the upper application can be notified of this. It relates to a communication method between boards of a switching device. According to such a board-to-board communication method of the switching device of the present invention, the steps of initializing an interprocessor communication (IPC) function, executing a command for sending an IPC to a designated slot, waiting for an event message, and When a message is received in the reception queue, removing the packet from the queue and calling the IPC function, and the IPC transmission task sends an event to the stored task identifier according to the result of the IPC function, and waits for the event again. Return to step is made.

Description

Board-to-board communication method of switching device

The present invention relates to a board-to-board communication method of a switching device, and more particularly to a board-to-board communication method of the switching device that can improve the reliability by improving the conventional method.

In general, the backplane of a switching device is implemented with a specific network such as Ethernet, and the main board controls each subboard and performs board-to-board communication through this path. However, when the main board controls each subboard, the conventional technology has its limitations in reliability.

An object of the present invention is to devise to improve such a prior art, when controlling the subboard from the main board, the packet is safely controlled, the packet is transmitted to the desired subboard so that no packet loss occurs, and the response from the subboard is If not, it is to provide a communication method between the board of the switching device that can inform the upper application (application).

Another object of the present invention is to provide a convenience to the upper application (application), the upper application (application) is a communication method between the boards of the switching device to enable the communication only by the slot ID (slot ID) of the other board desired to communicate It is to provide.

According to an aspect of the present invention for achieving the above object, the communication method between the board of the switching device, the step of initializing the inter-processor communication (IPC) function, executing the command to send the IPC to the designated slot, the event Waiting for a message, fetching a packet from the queue when the message comes in an IPC reception queue, calling the IPC function, and the IPC transmission task sends an event to a stored task identifier according to the result of the IPC function. And returning to the state of waiting for an event again.

According to another aspect of the present invention, a method for board-to-board communication of a switching device includes the steps of waiting for an event message by an IPC receiving task and reading the message from an IPC receiving queue when the IPC receiving task receives an event message. Updating the arrival time of the message; determining the type of command format for processing the message; according to the determination result, sending an EV_IPC_SUCCESS signal to the IPC transmission task and returning to a standby state, or transmitting an ACK packet to the packet. Recognizing a stored command type and a command number, determining whether a task identifier and an event are registered in a corresponding IPC signal house, and sending an event to the receiving task according to a result of the registration determining step, If the function is registered by determining whether the function is registered in the signal house It calls the function and when the call completes, it goes back to the initial wait state.

1A-1E illustrate the format of a packet and its various fields according to the present invention.

2 to 3 are flowcharts for explaining the operation of the transmission task of the switching device according to the present invention.

4 is a flow chart for explaining the operation of the reception task of the switching device according to the present invention.

Hereinafter, a configuration and an operation according to an exemplary embodiment of the present invention will be described with reference to the accompanying drawings.

Hereinafter, a communication method between boards of a switching device according to an exemplary embodiment will be described with reference to the accompanying drawings.

In the present invention, the commands that can be used in communication between the main board and the sub board can be divided as follows.

First, the system is booted and allows upper applications to use Inter Process Communication (IPC) and is used for management of the system.

Secondly, it is used to set the system operating environment.

Third, it is used to inform the change of the interface port.

Fourth, it is used for SNMP processing.

Fifth, it is used for the duplication of the motherboard.

Sixth, it is used for Hot Swap.

Seventh, it is used to upgrade software on board.

Eighth, it is used in case of reset.

Ninth, it is used in the case for ACK.

In an embodiment of the present invention, a packet used for IPC has a format as shown in FIG. 1A. The MAC address field shown in FIG. 1A has a format as shown in FIG. 1B. Basically, during the IPC, the MAC address is used as a field indicating the information of the system rather than the actual MAC address. Here, B0 represents a slot identifier (SLOT ID), B1 represents a board type (Board Type). For example, if B is displayed after 1, the main switch board is displayed, if 2 is displayed, the sub switch board is displayed, and if 3 is displayed, the Ethernet board is selected. If 4 is displayed, it means OC3 board. In addition, the addresses of B5 to B2 can be displayed as 00: 40: 5a: 00. Therefore, the MAC addresses of the main switch board and the sub switch board are always constant.

Also, as shown in FIG. 1A, the length field is always used only as a length and does not indicate a type.

The field for sending IPC data to the IPC header (ie, the part after the Mac header) has the format as shown in FIG. 1C.

In FIG. 1C, a sequence number is a field for packet loss and increases by 1 for each transmission. The transmitting board itself has a sequence number for each of the counterpart boards. That is, when the switch board IPCs the Ethernet board # 1 and when the switch board IPCs the Ethernet board # 2, they have different sequence numbers.

The receiving party may remember the sequence number for each other board and request retransmission if something is missing. However, it is not necessary in the current structure (structure requiring an ACK for each packet). In other words, the current structure may not be a big need or may be used in the future.

Each board must manage a table for storing sequence numbers as shown in FIG. 1D. The commands for such management are as follows.

Struct {

MAC slot_mac;

UINT tx_seq_num;

UINT rx_seq_num;

UINT alive_time;

UINT dead_or_alive

} IpcSeqNumTbl [MAX_SLOTS];

At this time, the index value in IpcSeqNumTbl [] becomes a slot identifier immediately, and all records whose slot identifier is an index must be initialized to zero.

The sequence number becomes 0 after the maximum value (2 ^ 32-1 = 4294967295). There is no packet indicating that the sequence number is skipped to zero. The receiving side should expect 0 after each maximum, and the sending side sends 0 after the maximum.

The live time is when the most recent packet was received from the board. This number represents the seconds after the IPC is initialized.

Dead_or_alive indicates whether the board is currently doing IPC.

#define BOARD_UNCONFIGURED 0 No Boards Recognized

#define BOARD_DEAD 1 Once recognized but not currently

#define BOARD_UNKNOWN 2 Unknown board recognized

#define BOARD_ALIVE 3 Boards Currently Recognized

BOARD_DEAD or BOARD_ALIVE knows the type of the board by reading the second byte of slot_mac.

IPC to be used by system can be divided into 9 types as follows. By using this, a command type of the IPC is determined and the defined command type is shown in FIG. 1E.

There is a separate command number for each command type, and the command types and meanings of 1,7, A IPC are as follows.

Command numbers of IPCs required during booting and their meanings are shown in Table 1 below.

Command type Command number meaning One 0 Each I / O board informs the main switch board of its presence (operation). The main switch board, which has received this IPC, can see the configuration of the system and the operation status of each input / output board. (1 second). One One The main board sends to each I / O board every 1 second. The main board announces its existence (operation) Command Specific Field: 4 Byte: Slot ID One 2 Among the switch boards, the sub board informs itself that it is a sub board. The remaining boards which have received this IPC can know the existence of the sub board. Command Specific field. 4 Byte: Slot ID of slot ID sub switch board One 3 The main board informs the I / O board that system environmental awareness has been completed and the board configuration information transmission starts. One 4 Packet that the main board notifies other boards of system configuration Command Specific Field 4 Byte: SLOT ID 6 Byte: MAC One 5 The main board informs the other boards that all initialization is complete.

Subsequently, the IPC commands for software upgrade are shown in Table 2 below. This command is used to control the download of the software upgrade and the execution of the I / O board. Each I / O board stores the downloaded image sequentially from 0x410 address.

Kinds Number direction meaning 7 0 SW-> IO Start Packet CSF: 4 bytes-The starting address to store in the image. 0x410) 4 bytes-The length of the image in bytes. 7 One SW-> IO Data packet CSF: bytes-Save address offset from start address 1 ~ 1486 Bytes-Data 7 2 SW-> IO End of download CSF: 4 bytes-Check the sum of the images transferred. 7 3 IO-> SW Checksum is correct 7 4 IO-> SW Checking the sum (Chechsum) The job after the switch board receives the IPC is not defined. The current indicates that the download failed and ends. 7 5 IO-> SW Incorrect file size (not used) 7 6 SW-> IO Run the image in DRAM. CSF: 4 bytes-starting address 7 7 SW-> IO Write the image on the flash to the flash. CSF: 4 bytes-starting address 7 8 IO-> SW Notifies Flash that the image on the DRAM has been written to. 7 9 SW-> IO Run the image in Flash by moving it to DRAM. CSF: 4 bytes-starting address

Here, the ACK packet is command type = 11, command number = 0, and in the following embodiment, IPC (x, y) means IPC with command type = x and command number = y.

2 to 3, the operation of the task in IPC transmission according to the present invention will be described.

In addition, the functions wait_for_ipc1 () and wait_for_ipc2 () that wait until the specified IPC arrives are described. This function registers itself to send a specific signal when an IPC comes in as an IPC receive task, and executes ev_receive. In other words, the task is suspended until the IPC that you specify comes in. wait_for_ipc1 () registers its task identifier and EV_IPC_COME1 as a type of event in the Signal House, which is a kind of database according to the designated command type and command number, and waits for the event EV_IPC_COME1 to be received. Execution ends when the event EV_IPC_COME1 is received.

It also describes the register_ipc () function, which sends an event to a specified task or calls a specified function when a specified IPC arrives. This function registers a called function or registers a task and a signal when the specified IPC is received, and finishes executing the function, so it does not wait for the IPC to arrive. Once registered, it stays in effect until remove_register_ipc () is called. register_ipc () registers the task identifier, event, and function specified in the signal house according to the specified command type and command number and terminates execution.

Here, remove_register_ipc () is a function used to delete an event to a function or task registered with register_ipc ().

Meanwhile, the data structure used in the IPC will be described below. Data used in IPC is divided into signal house, IPC receive queue and transmit queue.

First, the signal house is where you define what actions to take based on the packets you receive. That is, when ipc (x, y) comes in, it stores which task should send the event or call the function. The structure is as follows:

Typedef struct __signal_house

{

char in_use;

int duration

int taskId;

int signal;

IPC_MBUF * mbuf;

Void * (* func) ();

} SIGNAL_HOUSE;

SIGNAL_HOUSE IpcSignalHouse [MAX_COM_TYPE] {MAX_COM_NUM};

In order to access this data structure, a semaphore must be obtained. In other words, interoperability is implemented using semaphores. AddSignalHouse () and RemoveSignalHouse () are provided for this purpose.

int AddSignalHouse (int com_type, int com_num, int tid, int event, void * (* func) (), IPC_MBUF * mbuf);

This function registers tid, event, function, etc. in IpcSignalHouse [com_type] [com_num].

Int RemoveSignalHouse (int com_type, int com_num)

This function deletes the contents stored in IpcSignalHouse [com_type] [com_num].

Next, the structures of the IPC transmission queue and the IPC reception queue will be described.

The transmission queue is used to send IPC packets. An application that wants to send an IPC puts a packet to send to this queue, and the IPC sending task reads the data from the queue and sends the packet.

On the other hand, a receive queue is a queue for receiving a received packet from the Ethernet driver. When the NIC driver receives a packet, it puts the packet in this queue. The IPC Receive task then reads the packet and sends an event or call a function from the signal house to the scheduled task.

Next, an IPC reception task will be described when an IPC packet is received with reference to FIG. 4.

Referring to FIG. 4, the IPC reception task is always waiting for EV_MESSAGE (S21). This message is generated when a message arrives in the IPC reception queue. When the NIC driver receives a normal packet, it inserts a message in the IPC receive queue.

Upon receiving EV_MESSAGE, the IPC Receive task reads a message from the IPC Receive Queue (this message is an actual IPC packet), makes the status of the board that sent the packet alive, and updates the arrival time (S22). Next, it is determined whether the command format is 11 (S23). If the result of the determination step is that the packet is an ACK, it sends an EV_IPC_SUCCESS signal to the IPC transmission task (S24) and returns to the standby state.

However, if the result of the determination step (S23) is not an ACK to the received packet, an ACK packet is transmitted (S25), the command type and the command number stored in the packet are recognized, and the task identifier and the event are transmitted to the corresponding Ipc signal house. It is determined whether is registered (S26). If, the determination result sends an event to the task (S27). However, if it is not registered, it is determined whether a function is registered in the IPC signal house (S28). If the function is registered, the function is called (S29), and when the call is completed, it returns to the initial waiting state again.

Therefore, in the overall structure of the IPC software, various applications and (including pNA + on a switch board) are executed at the top layer. Each application can perform IPC related tasks through IPC interface routines. IPC interface routines are already described IPC APIs. IPC interface routines can insert packets into the IPC transmission queue (make_ipc (), where IpcTxSigFn () is used) or write to the signal house (register_ipc (), wait_for_ipc ()).

At this time, semaphores are required to access the signal house. This semaphore is created when the IPC is initialized and prevents multiple tasks from accessing the signal house at the same time, making it interoperable.

When a message is inserted into the IPC transmission queue, the IPC transmission task wakes up and performs the work already described in the description of the IPC transmission task. The IPC transfer task uses the de_write () system call to actually send the packet, which in turn calls the NIC driver's transfer routine.

When an interrupt occurs in the NIC chip, NIC ISR is performed, and the NIC ISR reads the interrupt status and sends EV_IPC_SEND_FAIL to the IPC transfer task if the transmitted packet is an error. The IPC transport task that receives the event sends the same event back to the IPC interface routine, which returns EV_IPC_SEND_FAIL to the application.

If the interrupt status is that a packet has been received, the received packet is inserted into the IPC receive queue using IpcRxSigFn (). When a message is inserted into this queue, an event is sent to the IPC Receive task, and by receiving this event, the IPC Receive task is operated.

According to the present invention as described above, in using IPC in a system using Ethernet as a backplane, the type of command is duplicated by the command type and the command number, and the packet is prevented from being duplicated by using the sequence number. By requiring ACK, stable and reliable communication is possible in switching equipment. In addition, the source MAC field has a slot identifier and a type of board to reduce the amount of communication.

Claims (3)

Initializing an interprocessor communication (IPC) function; Executing a command to send an IPC to a designated slot, waiting for an event message, When a message enters an IPC receive queue, removing the packet from the queue and calling the IPC function; And transmitting the event to the stored task identifier according to a result value of the IPC function, and returning to the waiting state for the event. The method of claim 1, wherein the IPC function is called Sending the packet to the NIC driver and determining the type of current mode; Returning EV_IPC_SUCCESS if the determination result is an async mode, and waiting for an event if the determination result is a synchronization mode; Determining whether the time has been exceeded and counting the number of timed out, retransmitting the packet only up to the preset number of times, and returning EV_IPC_ACK_NOT_RECEIVED if the timeout continues, And if the period is not exceeded, determining the type of signal and returning EV_IPC_SEND_FAIL or EV_IPC_SUCCESS according to the determination result. The IPC Receive task is waiting for an event message, When the IPC receiving task receives an event message, reading the message from an IPC receiving queue and updating the arrival time of the message; Determine the type of command format for processing the message and send EV_IPC_SUCCESS signal to the IPC transmission task according to the determination result and return to standby state, send an ACK packet and recognize the command type and command number stored in the packet. Determining whether a task identifier and an event are registered in a corresponding IPC signal house; Sending an event to the receiving task according to the result of the registration determining step, or determining whether a function is registered in the signal house, calling the function if the function is registered, and returning to the initial waiting state again when the function is completed. Communication method between the board of the switching device, characterized in that consisting of.