System, device and data center network system for work mode self-negotiation

Abstract

This application provides a system, device, and data center network system for auto-negotiation of operating modes, belonging to the field of chip technology. The system includes a version identification module positioned between the physical layer and the link layer of the local device's chip, and mode switching modules positioned upstream and downstream of the version identification module. The version identification module is configured to, after establishing a link at the physical layer but before the link layer initialization defined by the protocol, obtain specific messages from adjacent devices and send specific messages including the version information of the local device; parse the specific messages sent by adjacent devices to obtain the version information of the adjacent devices; and, based on the version information of the local device and the version information of the adjacent devices, enable the mode switching module to select the corresponding operating mode. This application, by arranging the version identification module between the physical layer and the link layer and using custom specific messages, can achieve version identification and auto-negotiation functions without the involvement of upper-layer software, and can achieve compatibility between new and old devices.

Description

Technical Field

[0001] This application belongs to the field of chip technology, and specifically relates to a system, device and data center network system for working mode auto-negotiation. Background Technology

[0002] Driven by the continuous pursuit of products with high performance and low latency, the evolution of protocols and the iteration of product designs have become trends. As a result, how to ensure the compatibility of new features brought by new equipment (chips) with old equipment to ensure stability, and how to ensure that different versions of equipment work together in large-scale switching networks, have become issues that must be considered in the equipment upgrade process.

[0003] In large enterprise or data center networks, where there are numerous devices, compatibility between old and new equipment is crucial when replacing older devices with new ones. Relevant technologies rely on hardware identification methods or manual firmware upgrades to ensure chip and firmware version matching. However, these methods have significant limitations: they are inflexible, inefficient, and carry the risk of replacement failure, causing inconvenience in practical use. Summary of the Invention

[0004] The purpose of this application is to provide systems, devices, and data center network systems for auto-negotiation of working modes, aiming to solve the problem of needing to be compatible with old and new devices when replacing them with new ones.

[0005] According to a first aspect of this application, a system for self-negotiation of working modes is provided. The system includes a version identification module disposed between the physical layer and the link layer of a local device; and a mode switching module disposed upstream and downstream of the version identification module. The version identification module is configured to, after establishing a link at the physical layer but before the initialization of the link layer defined by the protocol, acquire a specific message sent by a neighboring device, send a specific message containing version information of the local device to the neighboring device, parse the specific message sent by the neighboring device to obtain the version information of the neighboring device, and, based on the version information of the local device and the version information of the neighboring device, enable the mode switching module to select the corresponding working mode.

[0006] The system for auto-negotiation of working modes provided in this application has a version identification module arranged between the physical layer and the link layer, and uses custom specific messages to achieve version identification and auto-negotiation functions without the participation of upper layer software, and can achieve compatibility between new and old devices.

[0007] In an optional implementation, the specific message is configured to include a reserved field of the protocol, a predefined field for identifying version information.

[0008] The predefined protocol carries reserved fields that are custom fields used to identify version information. Simultaneously, the hardware automatically identifies versions through a version identification module, eliminating the need for software or manual intervention. These predefined fields provide the basis for the hardware's automatic identification mode.

[0009] In an optional implementation, the specific message of the neighboring device also includes the encoding information of the neighboring device. When parsing the specific message sent by the neighboring device, the encoding information of the neighboring device is also obtained. In response to the encoding information of the neighboring device, a specific message including the protocol information and encoding information of the local device is sent to the corresponding neighboring device. The protocol information is used to indicate the negotiated working mode.

[0010] Use encoded information to identify both ends of the device.

[0011] In an optional implementation, the step of enabling the mode switching module to select a corresponding working mode based on the version information of the local device and the version information of the adjacent device includes: if the version information of the adjacent device shows that the version of the adjacent device is lower than the version of the local device, enabling the mode switching module to switch to the working mode corresponding to the version of the adjacent device; and otherwise, enabling the mode switching module not to switch the working mode.

[0012] Higher version devices are automatically backward compatible, and the operating mode is negotiated to be a lower version / specific mode. The operating mode of the local device is determined by hardware logic (i.e., inside the chip), providing a basis for correctly performing flow control initialization.

[0013] In an optional implementation, the system further includes a handshake synchronization module, and the version identification module is further configured to: during the initial handshake using the handshake synchronization module, if the version information of the neighboring device indicates that the version of the neighboring device is lower than the version of the local device, send a specific message including protocol information, and cause the handshake synchronization module to exit the version handshake after receiving a handshake success signal from the neighboring device; otherwise, the handshake synchronization module exits the version handshake. The protocol information is used to indicate the negotiation working mode.

[0014] The handshake process only exits after receiving a successful handshake signal from the adjacent device, ensuring that the lower-version device has confirmed understanding of the protocol information and is ready for operation, preventing premature entry into the communication phase before negotiation is complete. If the adjacent device's version is detected to be at least as high as the local version, the version handshake is terminated directly, avoiding redundant negotiation processes and reducing handshake latency (especially for devices of the same or higher version).

[0015] In an optional implementation, the system further includes a flow control module, and the version identification module is further configured to: if the version information of the adjacent device shows that the version of the adjacent device is lower than the version of the local device, select the working mode corresponding to the version of the adjacent device as the working mode for negotiation; control the system to enter the LinkInit state, perform flow control initialization and flow control negotiation between the local device and the adjacent device.

[0016] After the version handshake is completed, the LinkInit state is entered to ensure that flow control initialization is only executed after the working mode is determined, so as to prevent flow control parameter configuration conflicts due to the undetermined mode.

[0017] In an optional implementation, after sending a specific message including protocol information, the version identification module is further configured to: when the local device and the neighboring device are negotiating flow control, if a specific message including protocol information is received from the neighboring device, switch the mode switching module to the negotiation working mode; and use the handshake synchronization module to complete the handshake action with the neighboring device.

[0018] This eliminates the need for upper-layer software involvement, improving the efficiency of rapid adaptation between devices.

[0019] In an optional implementation, the version identification module is further configured to: after the mode switching module selects the corresponding working mode and completes the relevant hardware initialization configuration according to the working mode, control the system to complete the negotiation, enter the LinkActive state, and start the packet sending action; and enable the flow control module to perform flow control according to the selected working mode.

[0020] High-version devices automatically adapt to low-version flow control rules without manual intervention; hardware-level anomaly detection and security mode rollback meet SIL3 security level requirements.

[0021] According to a second aspect of this application, an apparatus is provided, the apparatus comprising a chip and the aforementioned system disposed on the chip.

[0022] According to a third aspect of this application, a data center network system is provided, the data center network system including a plurality of the above-described devices.

[0023] The system for self-negotiation of working modes provided in this application embodiment, through the above technical solution, includes a version identification module disposed between the physical layer and the link layer of the local device's chip, and a mode switching module disposed upstream and downstream of the version identification module. The version identification module is configured to, after establishing a link at the physical layer and before the initialization of the link layer defined by the protocol, obtain specific messages from adjacent devices and send specific messages including version information of the local device; parse the specific messages sent by adjacent devices to obtain the version information of the adjacent devices; and, based on the version information of the local device and the version information of the adjacent devices, enable the mode switching module to select the corresponding working mode. This application embodiment, by arranging a version identification module between the physical layer and the link layer and using custom specific messages, can achieve version identification and self-negotiation functions without the participation of upper-layer software, and can achieve compatibility between new and old devices.

[0024] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures and processes shown in the description and the accompanying drawings. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of a system architecture for working mode self-negotiation provided by an exemplary embodiment of this application.

[0027] Figure 2 This is a schematic diagram of the structure of a preferred system provided by an exemplary embodiment of this application.

[0028] Figure 3 This is a schematic diagram of the device operation process of an exemplary embodiment of this application.

[0029] Figure 4 This is a schematic diagram of the structure of a data center network system according to an exemplary embodiment of this application.

[0030] Figures 5A-5C This is a schematic diagram of the self-negotiation workflow of the working mode of an exemplary embodiment of this application.

[0031] Among them, 10 is the physical layer, 20 is the version identification module, 30 is the link layer, and 40 is the mode switching module. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0033] As mentioned earlier, in application scenarios such as large enterprises or data center networks, there are many devices, and compatibility between old and new devices is required when replacing them with new ones. Related technologies rely on hardware identification methods or manual methods for firmware upgrades to ensure chip and firmware version matching. However, these methods have significant limitations: they are inflexible, inefficient, and carry the risk of replacement failure, causing inconvenience in practical use. Furthermore, the lack of an effective version rollback mechanism during firmware upgrades can lead to a series of compatibility issues, failing to meet the demands of rapid iteration. To ensure more efficient and secure device replacement due to protocol and hardware upgrades, this application's embodiments address the shortcomings of related technologies through hardware adaptive methods.

[0034] Figure 1 This is a schematic diagram of a system architecture for working mode auto-negotiation provided by an exemplary embodiment of this application. The system may include a version identification module 20 disposed between the physical layer 10 and the link layer 30 of the local device; and a mode switching module 40 disposed upstream and downstream of the version identification module 20. The version identification module 20 may be configured to, after establishing a link at the physical layer 10 and before initializing the link layer 30 as defined by the protocol, acquire specific messages sent by neighboring devices and send specific messages containing version information of the local device to the neighboring devices; parse the specific messages sent by the neighboring devices to obtain the version information of the neighboring devices; and, based on the version information of the local device and the version information of the neighboring devices, enable the mode switching module to select the corresponding working mode.

[0035] The embodiment of this application deploys a version identification module between the physical layer and the link layer, and uses a custom specific message to achieve version identification and self-negotiation functions without the participation of upper-layer software, thus enabling compatibility between new and old devices.

[0036] In a preferred embodiment of this application, a specific message may be configured to include a reserved field of the utilization protocol and a predefined field for identifying version information.

[0037] The predefined protocol carries reserved fields that are custom fields used to identify version information. Simultaneously, the hardware automatically identifies versions through a version identification module, eliminating the need for software or manual intervention. These predefined fields provide the basis for the hardware's automatic identification mode.

[0038] In a preferred embodiment of this application, the specific message from a neighboring device may further include the encoding information of the neighboring device. When parsing the specific message sent by the neighboring device, the encoding information of the neighboring device is also obtained. In response to the encoding information of the neighboring device, a specific message including the local device's protocol information and encoding information is sent to the corresponding neighboring device. The protocol information is used to indicate the negotiated working mode.

[0039] In this embodiment of the application, the coded information can be used to identify the two negotiating devices.

[0040] In this embodiment, the reserved field carried by the predefined protocol is a custom field used to identify version information; at the same time, the hardware (i.e., the chip) achieves automatic identification by cooperating with the version identification function configured by the added version identification module, without the need for software or manual intervention.

[0041] For example, the initial version of the device (e.g., version 1.0) may not include a version identification module, meaning it does not support device version identification. Subsequent versions of the device (e.g., versions 2.0 / 3.0...) may include a version identification module in the hardware.

[0042] After physical layer link establishment (PHY_READY) and before the link initialization defined by the protocol, feature exchange can be completed using specific messages carrying version information and destined for adjacent devices (e.g., InfiniBand link layer FCP messages, PCIe DLLP messages, etc.). That is, specific messages can include version information and the encoding information of adjacent devices (used to uniquely identify the corresponding devices). Taking the IB (InfiniBand) network as an example, the format of the link layer FCP flow control packet is as follows, where Version is a user-defined parameter representing version information.

[0043] Table 1

[0044]

[0045] The Op (Operand) field is 4 bits long. Flow control packets are link packets with one of two Op (operand) values: 0x0 indicates a normal flow control packet (PortStates = LinkArm or LinkActive, the flow control packet sends normal flow control operands 0x0, 0x1 indicates the flow control packet during PortState = LinkInitialize initialization); 2-15: reserved values. This application embodiment preferably utilizes a custom Op Code = Feature, with the endpoint being the link layer message transmission between adjacent devices; the version identification module can be configured as follows: version 1.0 can be left unconfigured; version 2.0 can identify both versions 1.0 and 2.0 during device identification; similarly, version n.0 identifies devices with a total of n versions: 1.0, 2.0, 3.0…n.0, as shown in the table below.

[0046] Table 2

[0047]

[0048] In a preferred embodiment of this application, the mode switching module selects the corresponding working mode based on the version information of the local device and the version information of the adjacent devices. This may include: if the version information of the adjacent device shows that the version of the adjacent device is lower than the version of the local device, the mode switching module switches to the working mode corresponding to the version of the adjacent device; otherwise, the mode switching module does not switch the working mode.

[0049] Taking a device with local version n.0 and a neighboring device with version m.0 as an example (where n is greater than or equal to m), the system obtains a specific message (OPm.0FCP) from the neighboring device and sends a specific message (OPn.0FCP) including the version information of the local device. It then parses the specific message (OP m.0FCP) sent by the neighboring device to obtain the version information (m.0 version) of the neighboring device. Based on the version information of the local device (n.0 version) and the version information of the neighboring device (m.0 version), the mode switching module selects the corresponding working mode. Since the version of the neighboring device (m.0 version) is lower than the version of the local device (n.0 version), it switches to the working mode corresponding to version m.0.

[0050] Taking a device with local version n.0 and a neighboring device with version m.0 as an example (where n is less than m), the system obtains a specific message (OPm.0FCP) from the neighboring device and sends a specific message (OPn.0FCP) including the version information of the local device. It then parses the specific message (OPm.0FCP) sent by the neighboring device to obtain its version information (m.0). Based on the version information of the local device (n.0) and the neighboring device (m.0), the mode switching module selects the corresponding operating mode. Since the version of the local device (n.0) is lower than the version of the neighboring device (m.0), the operating mode is not switched.

[0051] This application's embodiment employs a version identification module positioned between the physical layer and the data link layer. Using a custom-defined message, it achieves version identification and auto-negotiation without upper-layer software intervention, enabling compatibility between new and old devices. Higher-version devices are automatically backward compatible, negotiating their operating mode to a lower version / specific mode. Furthermore, hardware logic (i.e., within the chip) confirms the local device's operating mode, providing a basis for correct flow control initialization.

[0052] The preferred system of this application embodiment may further include a handshake synchronization module. This version identification module may also be configured to: during the initial handshake using the handshake synchronization module, if the version information of a neighboring device indicates that the neighboring device's version is lower than the local device's version, send a specific message including protocol information, and cause the handshake synchronization module to exit the version handshake after receiving a handshake success signal from the neighboring device; otherwise, the handshake synchronization module exits the version handshake. The protocol information is used to indicate the negotiation's working mode.

[0053] In this embodiment, the handshake process is only exited after receiving a successful handshake signal from the adjacent device. This ensures that the lower-version device has confirmed understanding of the protocol information and is ready for operation, preventing premature entry into the communication phase before negotiation is complete. When the version of the adjacent device is detected to be no lower than the local version, the version handshake is exited directly, avoiding redundant negotiation processes and reducing handshake latency (especially for devices of the same or higher version).

[0054] Please refer to Figure 2 Taking a device with a local version of n.0 and a neighboring device with a version of m.0 as an example (where n is greater than or equal to m), during the initial handshake, when the version identification module of the n.0 device receives a specific message (also called an FCP packet) of OPm.0FCP from the neighboring device, it identifies that the neighboring device is working in the low version m.0 mode, and the version identification module of the n.0 device uses the m.0 version mode as the identification result; when the m.0 device receives a specific message of OPn.0FCP from a higher version, it identifies that the neighboring device is working in the low version m.0 mode.

[0055] In a preferred embodiment of this application, after sending a specific message including protocol information, the version identification module is further configured to: when the local device and a neighboring device are negotiating flow control, if a specific message including protocol information is received from the neighboring device, switch the mode switching module to the negotiation working mode; and complete the handshake action with the neighboring device using the handshake synchronization module. The configuration of the version identification module for each version of the device is shown in Table 3.

[0056] Table 3

[0057]

[0058] Please refer to Figure 2 Continuing with the example above, in the next stage, the n.0 version device sends a specific message including the negotiated working mode (the working mode corresponding to the m.0 version) and OPm.0FCP, and receives a specific message of OPm.0FCP from the adjacent device. That is, the m.0 version is identified and the negotiation is successful. Afterwards, the n.0 version device switches to the working mode corresponding to the m.0 version. Based on this, the m.0 version device, upon receiving the specific message including the negotiated working mode (the working mode corresponding to the m.0 version) and OPm.0FCP, also switches to the working mode corresponding to the m.0 version. At this point, both the n.0 version device and the m.0 version device operate according to the working mode corresponding to the m.0 version, and both ends of the device have completed the version identification handshake.

[0059] The preferred system in this application embodiment may further include a flow control module, and the version identification module may be configured to: if the version information of a neighboring device shows that the version of the neighboring device is lower than the version of the local device, select the working mode corresponding to the version of the neighboring device as the working mode for negotiation; control the system to enter the LinkInit state, perform flow control initialization and flow control negotiation between the local device and the neighboring device.

[0060] In a preferred embodiment of this application, the version identification module can also be configured to: after the mode switching module selects the corresponding working mode, the control system enters the LinkActive state after successfully completing the negotiation and starts the packet sending action; and the flow control module performs flow control according to the selected working mode.

[0061] After the version handshake is completed, the LinkInit state is entered to ensure that flow control initialization is only executed after the working mode is determined, so as to prevent flow control parameter configuration conflicts due to the undetermined mode.

[0062] Please refer to Figure 2As mentioned above, the version identification module added between the physical layer and the link layer synchronizes version information based on a custom FCP message. This custom FCP message, like other FCP flow control messages, is detected and transmitted / received upon entering the LinkInit state. It is transmitted and received at both ends of the link layer and is not forwarded to the upper layer, ensuring version identification is completed during link initialization. After completing the custom FCP transmission and reception in the LinkInit state, the chip can automatically perform standard FCP transmission and reception to ensure hardware compatibility with OpenSM behavior. For example, the version identification module of the local device works in conjunction with its upstream and downstream modules. The local device is preset to version n.0 and sends the flow control message OP n.0FCP field to the adjacent device. When it receives the flow control message OPm.0FCP field sent by the adjacent device, the version identification module of the local device parses the OPm.0FCP field and compares the two versions. If m.0 is less than or equal to n.0, the version identification module of the local device determines that the working mode is m.0 and outputs the device version m.0 identifier. At the same time, the state machine jumps to the LinkInit state to perform flow control initialization and flow control negotiation between the local device and the adjacent device. After successful negotiation, it enters the LinkActive state and starts the packet sending action.

[0063] Accordingly, the system for self-negotiation of working modes provided in this application includes a version identification module disposed between the physical layer and the link layer of the local device's chip, and a mode switching module disposed upstream and downstream of the version identification module. The version identification module is configured to, after establishing a link at the physical layer and before the initialization of the link layer defined by the protocol, obtain specific messages from adjacent devices and send specific messages including version information of the local device; parse the specific messages sent by adjacent devices to obtain the version information of the adjacent devices; and, based on the version information of the local device and the version information of the adjacent devices, enable the mode switching module to select the corresponding working mode. This application embodiment, by arranging a version identification module between the physical layer and the link layer and using custom specific messages, can achieve version identification and self-negotiation functions without the participation of upper-layer software, and can achieve compatibility between new and old devices.

[0064] This application also provides an apparatus that may include a chip and the above-described system disposed on the chip.

[0065] Please refer to Figure 3The workflow of this device can be illustrated by the following example: the device powers on and completes a reset release; the physical layer of the chip completes the link establishment process; the link layer initiates initialization; the version identification module automatically identifies the device version; in the default state, the chip automatically completes the working mode switching; the link layer completes all initialization actions; the link layer enters the Active state and begins sending and receiving data. Specifically, the version identification module's automatic device version identification process can include: acquiring specific messages from neighboring devices and sending specific messages including the local device's version information; parsing the specific messages sent by neighboring devices to obtain their version information; based on the local device's version information and the neighboring device's version information, causing the mode switching module to select the corresponding working mode; if the neighboring device's version information indicates that its version is lower than the local device's version, the mode switching module switches to the working mode corresponding to the neighboring device's version; otherwise, the mode switching module does not switch working modes.

[0066] This application also provides a data center network system, which may include multiple of the above-described devices.

[0067] Please refer to Figure 4 In application scenarios such as data center network systems, there are many devices, and compatibility between old and new devices is required when new devices are added or replaced. The data center network system provided in this application embodiment is based on an auto-negotiation system configured for devices to automatically identify their working modes. This ensures that different versions of devices in the entire data center network system are compatible with each other during operation, which is helpful for device management. It is also suitable for multiple hardware upgrades of device chips, supporting iterative product delivery.

[0068] For example, each version of the device includes a version identification module positioned between the physical layer and the link layer of the chip. When upstream and downstream devices interoperate, the version identification module enables both ends to perform a version identification handshake based on a specific message (used as a negotiation message), allowing both ends to switch to a compatible version. Please refer to [reference needed]. Figures 5A-5CTaking a device of version n.0 connecting to a device of version m.0 as an example (where n > m), the n.0 device sends a specific message including OP n.0 FCP, and the m.0 device sends a specific message including OP m.0 FCP. During the initial handshake, when the n.0 device receives the OP m.0 FCP from the peer, it recognizes that the peer is operating in a lower version m.0 state (working mode), and the n.0 device switches to sending a specific message including OP m.0 FCP. When the m.0 device receives a specific message with a higher version OP n.0 FCP, it cannot recognize the peer's version and can discard the FCP packet. In the next phase, the n.0 device sends the OP m.0 FCP and receives the same message from the peer. The m.0 version is successfully recognized, and the n.0 device switches to m.0 operation. Similarly, the m.0 device can also receive the OP m.0 FCP and switches to m.0 operation. At this point, both the n.0 and m.0 versions of the device operate according to the m.0 version, and both ends of the device complete the version identification handshake.

[0069] Furthermore, the version identification module within any device, in cooperation with its upstream and downstream modules, enables the device, which defaults to version n.0, to send the flow control message OP n.0FCP field to the peer device. Upon receiving the flow control message OPm.0FCP field from the peer device, the local identification module parses the OPm.0FCP field and compares the two versions. If m.0 is less than or equal to n.0, the local device will determine that the working mode is m.0 and output an identifier indicating that the device version is m.0. Simultaneously, the state machine will jump to the LinkInit state to initialize flow control and negotiate flow control between the local and peer devices. After successful negotiation, it will finally enter the LinkActive state to start the packet sending action.

[0070] It should be noted that the above-mentioned equipment and data center network system can implement the system for working mode auto-negotiation provided in the above embodiments. For specific implementation methods, please refer to the description of the system for working mode auto-negotiation in the above embodiments, which will not be repeated here.

[0071] It is understood that the circuit structures, names, and parameters described in the above embodiments are merely examples. Those skilled in the art can also make readily conceived combinations and adjustments to the structural features of the above embodiments according to their needs, and the concept of this application should not be limited to the specific details of the above examples.

[0072] Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A system for mode self- negotiation, characterized by, The system includes a version identification module located between the physical layer and the link layer of the local device; and a mode switching module located upstream and downstream of the version identification module. The version identification module is configured to, after the physical layer link is established but before the link layer initialization defined by the protocol, obtain specific messages sent by neighboring devices and send specific messages containing the version information of the local device to the neighboring devices. By parsing specific messages sent by the neighboring devices, the version information of the neighboring devices can be obtained. Based on the version information of the local device and the version information of the adjacent devices, the mode switching module selects the corresponding working mode; The system also includes a handshake synchronization module, and the version identification module is further configured to: During the initial handshake using the handshake synchronization module, if the version information of the neighboring device indicates that the version of the neighboring device is lower than the version of the local device, a specific message including protocol information is sent, and the handshake synchronization module exits the version handshake after receiving a handshake success signal from the neighboring device; otherwise, the handshake synchronization module exits the version handshake. The protocol information is used to indicate the working mode of the negotiation.

2. The system of claim 1, wherein, The specific message is configured to include reserved field fields that utilize the protocol, and predefined fields for identifying version information.

3. The system of claim 1, wherein, The specific message sent by the neighboring device also includes the encoding information of the neighboring device. When parsing the specific message sent by the neighboring device, the encoding information of the neighboring device is also obtained. In response to the encoding information of the neighboring device, a specific message including the protocol information and encoding information of the local device is sent to the corresponding neighboring device, wherein the protocol information is used to indicate the negotiated working mode.

4. The system of claim 1, wherein, The step of enabling the mode switching module to select a corresponding working mode based on the version information of the local device and the version information of the adjacent devices includes: If the version information of the adjacent device indicates that the version of the adjacent device is lower than the version of the local device, the mode switching module switches to the working mode corresponding to the version of the adjacent device; and Otherwise, the mode switching module will not switch its working mode.

5. The system of claim 1, wherein, The system also includes a flow control module, and the version identification module is further configured to: If the version information of the adjacent device shows that the version of the adjacent device is lower than the version of the local device, the working mode corresponding to the version of the adjacent device is selected as the working mode for negotiation. The system is controlled to enter the LinkInit state to perform flow control initialization and flow control negotiation between the local device and the neighboring device.

6. The system of claim 5, wherein, After sending the specific message including protocol information, the version identification module is further configured to: When the local device and the neighboring device are negotiating flow control, if a specific message including protocol information is received from the neighboring device, the mode switching module switches to the working mode of the negotiation. The handshake synchronization module is used to complete the handshake action with the adjacent device.

7. The system of claim 5, wherein, The version identification module is also configured to: After the mode switching module selects the corresponding working mode and completes the relevant hardware initialization configuration according to the working mode, the system is controlled to complete the negotiation, enter the LinkActive state, and start the packet sending action. The flow control module performs flow control according to the selected working mode.

8. An apparatus, comprising: The device includes a chip and a system according to any one of claims 1-7 disposed on the chip.

9. A data center network system, comprising: The data center network system includes multiple devices as described in claim 8.

Images