Packet forwarding method, apparatus, communication system, and related product

Abstract

Embodiments of the present application relate to the technical field of communications, and disclosed are a packet forwarding method, an apparatus, a communication system, and a related product. In the embodiments of the present application, a second device actively advertises an extension packet header support capability of the second device to a first device, such that the first device can forward a packet on the basis of the extension packet header support capability advertised by the second device, thereby matching a first packet sent by the first device to the second device and the extension packet header support capability advertised by the second device. Therefore, service flow interruption caused by the second device receiving an extension packet header not supported thereby is avoided. Such a method does not require manual configuration of an extension packet header support capability, thereby avoiding the problem brought by manual configuration of the extension packet header support capability.

Description

Message forwarding method, device, communication system and related products

[0001] This application claims priority to Chinese patent application number 202410313577.1 filed on March 18, 2024, entitled “Message forwarding method, device, communication system and related products”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of communication technology, and in particular to a message forwarding method, device, communication system and related products. Background Art

[0003] To implement functions such as network quality measurement, extended headers can be added to messages transmitted over the network. These extended headers instruct network devices to collect the corresponding data. Before sending a message containing an extended header to another network device, a network device must first confirm whether the other network device supports the extended header. If not, the extended header is removed and the message is then sent to the other network device without the extended header, avoiding traffic interruption at the other network device.

[0004] In the related art, the operation and maintenance personnel pre-configure the extended message header support capability of other network devices on the network devices. This configuration method is highly complex and inefficient. Summary of the Invention

[0005] The present invention provides a message forwarding method, apparatus, communication system, and related products, enabling a network device to proactively notify other network devices of its extended message header support capability, enabling other network devices to forward messages to the network device based on the announced extended message header support capability. This approach eliminates the need for manual configuration of extended message header support capability. The technical solution is as follows:

[0006] In a first aspect, a message forwarding method is provided, in which a first device receives a first notification message from a second device, the first notification message being used to notify the second device of its extended message header support capability; the first device obtains a first message based on the extended message header support capability of the second device notified by the first notification message; and the first device sends the first message to the second device.

[0007] In this embodiment of the present application, a device proactively notifies other devices of its extended header support capability, enabling them to forward messages based on the notified extended header support capability. This prevents service interruptions caused by a device receiving an unsupported extended header. This approach eliminates the need for manual configuration of extended header support, thus avoiding the problems associated with such configuration.

[0008] Based on the method provided in the first aspect, in one possible implementation, a first device receives a second message. Accordingly, the first device obtains the first message based on the extended message header support capability of the second device notified in the first notification message. This may be achieved by the first device processing the second message based on the extended message header support capability of the second device notified in the first notification message to obtain the first message.

[0009] In an embodiment of the present application, the first device can process the message from the upstream node according to the extended message header support capability of the second device announced in the first notification message to obtain the first message, thereby avoiding the downstream second device receiving an unsupported extended message header and causing service flow interruption.

[0010] Based on the method provided in the first aspect, in one possible implementation, a first notification message carries one or more extended message header types not supported by the second device, and the second message includes the first extended message header. In this scenario, the first device processes the second message based on the extended message header support capability of the second device announced in the first notification message, and obtains the first message in an implementation manner that may include: based on the fact that the first extended message header type is an extended message header type not supported by the second device, the first device deletes the first extended message header from the second message to obtain the first message.

[0011] In a scenario where the first notification message carries one or more extended message header types not supported by the second device, for the extended message header in the second message, when the type of the extended message header is consistent with the extended message header type announced by the first notification message, the first device will not carry the extended message header in the first message and send it to the second device, thereby avoiding service flow interruption at the second device due to reception of an unsupported extended message header type.

[0012] Based on the method provided in the first aspect, in one possible implementation, the first notification message carries one or more extended message header types not supported by the second device, and the first notification message also carries one or more versions of extended message header types not supported by the second device, and the second message includes the first extended message header. In this scenario, the first device processes the second message based on the extended message header support capability of the second device announced in the first notification message, and the implementation method for obtaining the first message may be: the first device deletes the first extended message header from the second message based on the fact that the type of the first extended message header is an extended message header type not supported by the second device and the version of the first extended message header is a version not supported by the second device, to obtain the first message.

[0013] In a scenario where the first notification message carries one or more extended message header types and versions of the unsupported extended message header types that are not supported by the second device, for the extended message header in the second message, when the type and version of the extended message header are consistent with the extended message header type and version announced by the first notification message, the first device will not send the extended message header to the second device, thereby avoiding service flow interruption at the second device due to receiving an unsupported extended message header type or an unsupported extended message header type version.

[0014] Based on the method provided in the first aspect, in one possible implementation, the first notification message carries one or more extended message header types supported by the second device, and the second message includes the first extended message header. In this scenario, the first device processes the second message based on the extended message header support capability of the second device announced in the first notification message, and the implementation method for obtaining the first message may be: the first device obtains the first message based on the first extended message header type being an extended message header type supported by the second device, and the first message includes the first extended message header.

[0015] In a scenario where the first notification message carries one or more extended message header types supported by the second device, for the extended message header in the second message, when the type of the extended message header is consistent with the extended message header type announced by the first notification message, the first device sends the extended message header to the second device, thereby avoiding service flow interruption at the second device due to receiving an unsupported extended message header type.

[0016] Based on the method provided in the first aspect, in one possible implementation, the first notification message carries one or more extended message header types supported by the second device, and the first notification message also carries one or more versions of the extended message header types supported by the second device, and the second message includes the first extended message header. In this scenario, the first device processes the second message based on the extended message header support capability of the second device announced in the first notification message, and the implementation method for obtaining the first message can be: the first device deletes the first extended message header from the second message based on the fact that the type of the first extended message header is an extended message header type supported by the second device, but the version of the first extended message header is not a version supported by the second device, to obtain the first message.

[0017] In a scenario where the first notification message carries both one or more extended message header types and versions of the supported extended message header types supported by the second device, the first device will carry the extended message header in the first message and send it to the second device only if the type and version of the extended message header are consistent with the type and version of the extended message header announced in the first notification message. If either the type or version of the extended message header is inconsistent with the type and version of the extended message header announced in the first notification message, the first device will not carry the extended message header in the first message and send it to the second device, thereby avoiding service flow interruption at the second device due to receiving an unsupported extended message header type or an unsupported extended message header type version.

[0018] Based on the method provided in the first aspect, in a possible implementation manner, the first notification message is an LLDP message, the LLDP message includes a type-length-value TLV, and the TLV is used to notify the second device of an extended message header support capability.

[0019] In the embodiment of the present application, a TLV may be extended in the LLDP message, and the extended message header support capability of the second device may be announced through the extended TLV.

[0020] Based on the method provided in the first aspect, in one possible implementation, after the first device receives a first notification message from the second device, the first device receives a second notification message from the second device, where the second notification message is used to notify the second device of a change in the extended message header support capability.

[0021] In addition, in an embodiment of the present application, after the second device notifies the first device of its own extended message header support capability through a first notification message, in scenarios such as network expansion, device replacement, and network topology changes, when the second device's own extended message header support capability changes, it can also send a second notification message to the first device. The second notification message is used to notify the second device of changes in the extended message header support capability.

[0022] Based on the method provided in the first aspect, in one possible implementation, after the first device receives the second notification message from the second device, the first device sends a second notification confirmation message to the second device, and the second notification confirmation message is used to notify the first device that the extended message header support capability of the second device has changed.

[0023] In an embodiment of the present application, if the extended header support capability of the second device announced in the second notification message changes, including: the second device no longer supports the target extended header after the second device supports the target extended header, the second device may disable the target extended header parsing function on its own end after receiving the second notification confirmation message. This can prevent the second device from receiving messages containing the target extended header due to premature disabling of the target extended header parsing function, thereby preventing the second device from continuing to receive messages containing the target extended header and thus causing service flow interruption.

[0024] Based on the method provided in the first aspect, in one possible implementation, after a first device receives a first notification message from a second device, the first device configures the second device's extended header support capability on its own end based on the first notification message. Accordingly, the first device may obtain the first message based on the second device's extended header support capability announced in the first notification message by: the first device obtains the first message based on the second device's configured extended header support capability on its own end.

[0025] In an embodiment of the present application, after receiving the first notification message, the first device can configure the extended message header support capability of the second device on its own end based on the first notification message, so as to facilitate subsequent processing of the message based on the extended message header support capability of the second device configured on its own end.

[0026] Based on the method provided in the first aspect, in a possible implementation, the implementation method for the first device to receive the first notification message from the second device may be: the first device receives the first notification message from the second device through the first port. Accordingly, the implementation method for the first device to configure the extended message header support capability of the second device on its own end based on the first notification message may be: the first device establishes a mapping relationship between the first port and the extended message header support capability of the second device. Accordingly, the implementation method for the first device to obtain the first message based on the extended message header support capability of the second device configured on its own end may be: the first device determines that the outgoing port for forwarding the first message is the first port; the first device searches for the extended message header support capability of the second device from the mapping relationship based on the first port; the first device obtains the first message based on the found extended message header support capability of the second device.

[0027] This implementation can be applied in scenarios where a first device and a second device are directly connected. In this case, the first device establishes a mapping in its routing table between the port identifier of the first port and the extended header support capabilities of the second device. When forwarding packets, the routing table can be used to quickly identify the extended header support capabilities of the second device.

[0028] Based on the method provided in the first aspect, in one possible implementation, the extended message header includes at least one of an in-flow information telemetry IFIT header, an in-band flow analysis IFA header, an in-band operation management and maintenance IOAM header, a segment routing SR header, a segment routing SRv6 header based on the sixth-generation network protocol, and an application-aware network APN header.

[0029] In the embodiment of the present application, the extended message header can be understood as all message headers in the message except the basic IPv4 header or IPv6 header. For example, the extended message header includes at least one of the IFIT header, IFA header, IOAM header, SR header, SRv6 header and APN header.

[0030] In the second aspect, another message forwarding method is provided. The technical effect of the message forwarding method provided in the second aspect is the same as the technical effect of the message forwarding method provided in the first aspect, and will not be described in detail later.

[0031] In the method provided in the second aspect, the second device sends a first notification message to the first device, and the first notification message is used to notify the second device of the extended message header support capability; the second device receives a first message from the first device, and the first message is obtained by the first device based on the extended message header support capability of the second device.

[0032] Based on the method provided in the second aspect, in one possible implementation, the first notification message carries one or more extended message header types not supported by the second device; wherein, the first message does not include a first extended message header, and the type of the first extended message header is one or more extended message header types not supported by the second device.

[0033] Based on the method provided in the second aspect, in one possible implementation, the first notification message carries one or more extended message header types supported by the second device; wherein, the first message includes a first extended message header, and the type of the first extended message header is one or more extended message header types supported by the second device.

[0034] Based on the method provided in the second aspect, in one possible implementation, the first notification message also carries a version of one or more extended message header types supported by the second device; wherein, the first message includes a first extended message header, the type of the first extended message header is one or more extended message header types supported by the second device, and the version of the first extended message header is a version of one or more extended message header types supported by the second device.

[0035] Based on the method provided in the second aspect, in one possible implementation, after the second device sends a first notification message to the first device, the second device sends a second notification message to the first device, where the second notification message is used to notify the second device of a change in its extended message header support capability.

[0036] Based on the method provided in the second aspect, in one possible implementation, a change in the second device's extended header support capability includes: the second device's support for a target extended header changes to the second device's non-support of the target extended header. In this scenario, after the second device sends a second notification message to the first device, the second device receives a second notification confirmation message from the first device, where the second notification confirmation message is used to notify the first device of the change in the second device's extended header support capability; and the second device disables its own target extended header parsing function.

[0037] Based on the method provided in the second aspect, in one possible implementation, the extended message header includes at least one of an in-flow information telemetry IFIT header, an in-band flow analysis IFA header, an in-band operation management and maintenance IOAM header, a segment routing SR header, and a segment routing SRv6 header based on the sixth-generation network protocol.

[0038] In a third aspect, a message forwarding device is provided, which is applied to a first device and has the function of implementing the message forwarding method described in the first aspect. The message forwarding device includes at least one module, which is used to implement the message forwarding method described in the first aspect.

[0039] In a fourth aspect, another message forwarding device is provided, which is applied to a second device and has the function of implementing the message forwarding method described in the second aspect. The message forwarding device includes at least one module, which is used to implement the message forwarding method described in the second aspect.

[0040] In a fifth aspect, a message forwarding device is provided, comprising a memory and a processor; the memory is used to store a computer program; the processor is used to execute the computer program stored in the memory so that the message forwarding device executes the method provided in the first aspect or any optional manner of the first aspect, or executes the method provided in the second aspect or any optional manner of the second aspect.

[0041] In the sixth aspect, a message forwarding device is provided, including a main control board and an interface board, which are used to implement the method provided by the above-mentioned first aspect or any optional method of the first aspect, or to implement the method provided by the above-mentioned second aspect or any optional method of the second aspect.

[0042] In the seventh aspect, a communication system is provided, comprising a first device and a second device, wherein the first device comprises an apparatus as provided in the third aspect or any optional manner of the third aspect, and the second device comprises an apparatus as provided in the fourth aspect or any optional manner of the fourth aspect; or, at least one of the first device and the second device comprises an apparatus as provided in the fifth aspect or the sixth aspect.

[0043] In an eighth aspect, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed, the method provided in the first aspect or any optional manner of the first aspect is implemented, or the method provided in the second aspect or any optional manner of the second aspect is implemented.

[0044] In the ninth aspect, a computer program product is provided, which includes a program or code, and when the program or code is executed, it implements the method provided by the first aspect or any optional method of the first aspect, or implements the method provided by the second aspect or any optional method of the second aspect.

[0045] In the tenth aspect, a chip is provided, which, when running, implements the method provided in the first aspect or any optional manner of the first aspect, or implements the method provided in the second aspect or any optional manner of the second aspect.

[0046] Optionally, the chip includes programmable logic circuits and / or program instructions.

[0047] Optionally, the chip is a network processor (NP) chip.

[0048] The technical effects of the above-mentioned third to tenth aspects can refer to the technical effects of the above-mentioned first aspect and any optional implementation method of the first aspect, as well as the technical effects of the above-mentioned second aspect and any optional implementation method of the second aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] FIG1 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

[0050] FIG2 is a schematic diagram of the architecture of another communication system provided in an embodiment of the present application;

[0051] FIG3 is a schematic diagram of the architecture of another communication system provided in an embodiment of the present application;

[0052] FIG4 is a schematic diagram of the architecture of another communication system provided in an embodiment of the present application;

[0053] FIG5 is a flow chart of a message forwarding method provided in an embodiment of the present application;

[0054] FIG6 is a flow chart of another message forwarding method provided in an embodiment of the present application;

[0055] FIG7 is a flow chart of another message forwarding method provided in an embodiment of the present application;

[0056] FIG8 is a schematic diagram of a notification process provided in an embodiment of the present application;

[0057] FIG9 is a schematic diagram of another notification process provided in an embodiment of the present application;

[0058] FIG10 is a schematic diagram of another message forwarding process provided in an embodiment of the present application;

[0059] FIG11 is a schematic diagram of a message forwarding device 1100 provided in an embodiment of the present application;

[0060] FIG12 is a schematic diagram of another message forwarding device 1200 provided in an embodiment of the present application;

[0061] FIG13 is a schematic diagram of another message forwarding device 1300 provided in an embodiment of the present application. DETAILED DESCRIPTION

[0062] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0063] Before explaining the embodiments of the present application, the application scenarios of the embodiments of the present application are first explained.

[0064] When forwarding packets, devices on the network may add some extended headers to received packets to achieve purposes such as network quality measurement and forwarding path control. For example, when performing network quality measurement, a device may add extended headers such as the in-situ flow information telemetry (IFIT) header, the in-band flow analyzer (IFA) header, and the in-band operation, administration, and maintenance (IOAM) header. For another example, when performing path control, a device may add extended headers such as the segment routing (SR) or segment routing over IPv6 (SRv6) header. For another example, when performing application / service awareness, a device may add extended headers such as the application-aware networking (APN) header.

[0065] For example, IFIT is an in-band detection technology (i.e., it tags real service packets with features or embeds detection information within real service packets). It implements in-band detection by inserting IFIT headers into real service packets. Compared to out-of-band detection technologies that indirectly simulate service data packets and periodically report them, IFIT can accurately reflect network performance indicators such as latency, packet loss, and jitter in real time, and proactively detect service failures.

[0066] When network administrators deploy the function of adding extended message headers in the network, they need to manually collect the interconnection topology between devices in the network, the on / off status of the extended message header parsing function, and the extended message header support capabilities through the network management system. Then, based on actual business requirements and based on the device port configuration, they need to manually determine whether to carry certain extended message headers when forwarding messages. This ensures that downstream devices can correctly process these extended message headers and avoids failures such as service flow interruption caused by downstream devices' inability to recognize extended message headers.

[0067] For example, if port 1 on device 1 is connected to device 2, and manual data collection indicates that device 2 supports the IFIT header but not other extended headers, device 2's extended header support capability is manually configured on port 1. In this way, when device 1 receives a packet and sends it through port 1, if the packet carries the IFIT header, it will send the packet to device 2. If the packet carries other extended headers, such as the IFA header, it will remove the IFA header and send the packet to device 2.

[0068] This configuration method is complex and inefficient. Furthermore, in scenarios such as network expansion, device replacement, and network topology changes, this method is prone to mismatches or omissions. This can cause packets carrying extension headers to be sent to devices that don't support them, disrupting service flows.

[0069] Based on this, embodiments of the present application provide a message forwarding method in which a device proactively notifies other devices of its extended header support capability, enabling other devices to forward messages based on the notified extended header support capability. This prevents service flow interruptions caused by a device receiving an unsupported extended header. This approach eliminates the need for manual configuration of extended header support capability, thus avoiding the problems associated with such configuration.

[0070] The following explains the message forwarding system, message forwarding method and related products provided in the embodiments of the present application.

[0071] Figure 1 is a schematic diagram of the architecture of a communication system provided by an embodiment of the present application. As shown in Figure 1 , the communication system includes a first device 01 and a second device 02. A transmission channel, which can be a wired or wireless transmission channel, is established between the first device 01 and the second device 02. The second device 02 notifies the first device 01 of its extended header support capability via a notification message. The first device 01 then forwards the message to the second device 02 based on the extended header support capability notified by the second device 02.

[0072] The first device 01 and the second device 02 are intended to distinguish between two transmission devices that announce their own extended header support capabilities, rather than to limit the operations performed by the transmission devices. In some cases, the first device 01 can act as the second device 02 to perform operations related to the second device 02, and the second device 02 can act as the first device 01 to perform operations related to the first device 01. For example, the first device 01 can act as the second device 02 to announce its own extended header support capabilities to the second device 02 at the other end, and the second device 02 can act as the first device 01 to forward messages to the first device 01 at the other end based on the extended header support capabilities announced by the other end. For another example, the first device 01 is also connected to other devices. The first device 01 can act as the second device 02 to announce its own extended header support capabilities to the other devices, and the other devices can act as the first device 01 to forward messages to the first device 01 at the other end based on the extended header support capabilities announced by the other end.

[0073] Figure 2 is a schematic diagram of the architecture of another communication system provided by an embodiment of the present application. The communication system includes transmission devices 1 to n, where a transmission channel is established between adjacent transmission devices in the transmission devices 1 to n. Any two transmission devices in the transmission devices 1 to n notify the other end of their extended message header support capabilities through notification messages, that is, any two transmission devices in the transmission devices 1 to n are the first device 01 and the second device 02. For example, transmission device 1 is the second device 02, and transmission device 2 is the first device 01. For another example, transmission device 1 is the second device 02, and transmission device 3 is the first device 01.

[0074] In some embodiments, the communication system further includes a network management system. Figure 3 is a schematic diagram of the architecture of another communication system provided by an embodiment of the present application. As shown in Figure 3, based on the communication system shown in Figure 2, the communication system further includes a network management system. A transmission channel is established between the network management system and each transmission device.

[0075] The network administrator can configure the extended header support capability of any transmission device through the network management system, such as configuring which extended headers the transmission device supports or which extended headers the transmission device does not support. Any transmission device can, based on the extended header support capability configured by the network administrator, notify other devices of its extended header support capability through a notification message, enabling other devices to forward messages to the device based on the notified extended header support capability.

[0076] In the embodiments of the present application, the transmission device may be any device with data transmission capabilities. For example, the transmission device may be a network device such as a switch, a router, a gateway (GW), a load balancer (LB), a virtual switch (vSwitch), a virtual router (vRouter), or a virtual load balancer (vLB), or may be a terminal device or a server.

[0077] In addition, in some embodiments, the transmission device's local extended packet header support capability notification function is integrated into a chip or network card within the transmission device. For example, if the transmission device is a network device such as a switch, router, or gateway, the transmission device includes a network processor (NP) chip, and the transmission device's local extended packet header support capability notification function is integrated into the NP chip within the transmission device. For another example, if the transmission device is a terminal device or a server, the transmission device includes a network card, and the transmission device's local extended packet header support capability notification function is integrated into the network card within the transmission device.

[0078] The following uses the first device 01 and the second device 02 as network devices as an example to illustrate the communication system involved in the embodiment of the present application. Figure 4 is a schematic diagram of the architecture of another communication system provided by the embodiment of the present application. As shown in Figure 4, the communication system includes multiple network devices and a network management system. Figure 4 uses three network devices as an example for illustration, and Figure 4 respectively labels these three network devices as network device 1, network device 2, and network device 3. The first device 01 and the second device 02 in Figure 1 can be any two network devices in Figure 4.

[0079] A network administrator can configure the extended header support capability of any network device through a network management system, such as configuring which extended headers the network device supports or which extended headers the network device does not support. Based on the extended header support capability configured by the network administrator, any network device can advertise its extended header support capability to other network devices via a notification message, enabling other network devices to send messages to the network device based on the advertised extended header support capability.

[0080] For example, network device 2 can notify network device 1 and network device 3 of its extended header support capability. Subsequently, when network device 1 and network device 3 send messages to network device 2, they only send extended headers supported by network device 2 and do not send extended headers not supported by network device 2, thereby avoiding service interruption at network device 2.

[0081] In addition, as shown in Figure 4, the communication system also includes multiple terminal devices. Figure 4 uses two terminal devices as an example for illustration, and these two terminal devices are labeled terminal device 1 and terminal device 2, respectively. Terminal device 1 and terminal device 2 are two terminal devices used for communication, and the terminal devices are exemplified by mobile phones, computers, and other devices. The data flow between terminal device 1 and terminal device 2 is transmitted via a communication link composed of network devices 1, 2, and 3. When any network device receives a message in the data flow, it can forward the message to the other end based on the extended message header support capability announced by the other end, thereby preventing the other end from receiving unsupported extended message headers.

[0082] In addition, in the embodiment of the present application, the extended message header can be understood as all message headers in the message except the basic IPv4 header or IPv6 header. For example, the extended message header includes at least one of the IFIT header, IFA header, IOAM header, SR header, SRv6 header and APN header.

[0083] In addition, the message forwarding method of the embodiments of the present application can be implemented by software, hardware, or a combination of software and hardware in the transmission device. The network management system can be a controller or a third-party network element. The network management system can integrate network management, service control, and network analysis functions. The controller is a functional module deployed in a server, which can be a single server, a server cluster consisting of several servers, a cloud computing service center, or other devices or modules with network control functions. The embodiments of the present application are not limited to this.

[0084] FIG5 is a flow chart of a message forwarding method provided in an embodiment of the present application. The method is exemplarily applied to the communication system shown in FIG1-4. As shown in FIG5, the method includes the following steps.

[0085] Step 501: A first device receives a first notification message from a second device, where the first notification message is used to notify the second device of its extended message header support capability.

[0086] In which, the first device and the second device in the embodiment shown in Figure 5 can be two devices in the communication system shown in Figures 1-4. By way of example, the first device is the first device 01 in the communication system shown in Figure 1, and the second device is the second device 02 in the communication system shown in Figure 1. By way of another example, the first device is any transmission device in the communication system shown in Figure 2 or Figure 3, and the second device is a transmission device other than the first device. For example, the first device is transmission device 1, the second device is transmission device 2, or the first device is transmission device 1, the second device is transmission device 3, etc. By way of another example, the first device is any network device or any terminal device in the communication system shown in Figure 4, and the second device is a device other than the first device. For example, the first device is network device 1, the second device is network device 2, or the first device is terminal device 1, the second device is network device 1, etc.

[0087] In addition, the implementation of step 501 may refer to step 702 in the embodiment of FIG. 7 , which will be described in detail here.

[0088] Step 502: The first device obtains a first message according to the extended message header support capability of the second device notified by the first notification message.

[0089] The implementation of step 502 may refer to step 703 in the embodiment of FIG. 7 , which will be described in detail here.

[0090] Step 503: The first device sends a first message to the second device.

[0091] The implementation of step 503 may refer to step 704 in the embodiment of FIG. 7 , which will be described in detail here.

[0092] In this embodiment of the present application, the second device proactively notifies the first device of its extended header support capability. This allows the first device to forward messages based on the extended header support capability announced by the second device, thereby preventing service interruptions caused by the second device receiving an unsupported extended header. This approach eliminates the need for manual configuration of extended header support, thus avoiding the problems associated with such configuration.

[0093] FIG6 is a flow chart of another message forwarding method provided in an embodiment of the present application. The method is exemplarily applied to the communication system shown in FIG1-4. As shown in FIG6, the method includes the following steps.

[0094] Step 601: The second device sends a first notification message to the first device, where the first notification message is used to notify the second device of its extended message header support capability.

[0095] In which, the second device and the first device in the embodiment shown in Figure 6 can be two devices in the communication system shown in Figures 1-4. By way of example, the second device is the second device 02 in the communication system shown in Figure 1, and the corresponding first device is the first device 01 in the communication system shown in Figure 1. By way of another example, the second device is any transmission device in the communication system shown in Figure 2 or Figure 3, and the corresponding first device is any transmission device other than the second device. For example, the second device is transmission device 1, and the first device is transmission device 2, or the second device is transmission device 1, and the first device is transmission device 3, etc. By way of another example, the second device is any network device or any terminal device in the communication system shown in Figure 4, and the corresponding first device is any device other than the second device. For example, the second device is network device 2, and the first device is network device 1, or the second device is network device 1, and the first device is terminal device 1, etc.

[0096] In addition, the implementation of step 601 may refer to step 701 in the embodiment of FIG. 7 , which will be described in detail here.

[0097] Step 602: The second device receives a first message from the first device, where the first device obtains the first message based on the extended message header support capability of the second device.

[0098] The implementation of step 602 may refer to step 705 in the embodiment of FIG. 7 , which will be described in detail here.

[0099] In this embodiment of the present application, the second device proactively notifies the first device of its extended header support capabilities, enabling the first device to forward messages based on the extended header support capabilities announced by the second device. This ensures that the first message sent by the first device to the second device matches the extended header support capabilities announced by the second device. This prevents service flow interruptions caused by the second device receiving an unsupported extended header. This approach eliminates the need for manual configuration of extended header support capabilities, thus avoiding the problems associated with such configuration.

[0100] FIG7 is a flow chart of a message forwarding method provided in an embodiment of the present application. The method is exemplarily applied to the communication system shown in FIG1-4. As shown in FIG7, the method includes the following steps.

[0101] Step 701: The second device sends a first notification message to the first device, where the first notification message is used to notify the second device of its extended message header support capability.

[0102] In the embodiment shown in FIG7 , the first device and the second device can be two devices in the communication system shown in FIG1-4 . By way of example, the first device and the second device are respectively the first device 01 and the second device 02 in the communication system shown in FIG1 . By way of another example, the first device and the second device are any two transmission devices in the communication system shown in FIG2 or FIG3 . For example, the first device is transmission device 1 and the second device is transmission device 2, or the first device is transmission device 1 and the second device is transmission device 3, etc. By way of another example, the first device and the second device are any two devices in the communication system shown in FIG4 . For example, the first device is network device 1 and the second device is network device 2, or the first device is terminal device 1 and the second device is network device 1, etc.

[0103] In some embodiments, after the network administrator configures the extended message header support capability of the second device on the second device, the second device can automatically generate a first notification message in response to the extended message header support capability of the local end configured by the network administrator, and actively notify the first device of the first notification message to notify the extended message header support capability of the local end.

[0104] Among them, after the network administrator configures the extended message header support capability of the second device on the second device, if it is determined that the second device supports a certain extended message header based on the configured extended message header support capability of the second device, the second device can also enable the extended message header parsing function of this end so that the message including the extended message header can be parsed normally in the future.

[0105] In an embodiment of the present application, when notifying the extended header support capability of the local end, the second device may notify the extended headers supported by the local end, or may notify the extended headers not supported by the local end, or may simultaneously notify the extended headers supported by the local end and the extended headers not supported by the local end. That is, the extended header support capability of the second device includes the extended headers that the second device can support, or includes the extended headers that the second device cannot support, or includes both the extended headers that the second device can support and the extended headers that the second device cannot support.

[0106] The following explains step 701 in three scenarios.

[0107] Scenario 1: The first notification message is used to notify the second device of the extended message header supported.

[0108] For example, the first notification message carries one or more extended message header types supported by the second device. For example, the first notification message carries the following extended message header types supported by the second device: IFIT header, APN header, IFA header, and IOAM header. This method can be called an extended message header whitelist notification.

[0109] Furthermore, the first notification message may also carry one or more versions of the extended message header type supported by the second device. That is, the first notification message not only notifies the extended message header types supported by the second device, but also notifies the versions of the supported extended message header types.

[0110] For example, in addition to carrying the extended message header types supported by the second device, including: IFIT header, APN header, IFA header, and IOAM header, the first notification message also carries the versions of one or more extended message header types supported by the second device, including: IFIT header version V1, APN header version V3, IFA header version V2, and IOAM header version V1. The embodiments of the present application do not limit the specific format of the versions of the extended message header types.

[0111] In addition, in a scenario where the first notification message announces an extended message header supported by the second device, the second device does not support other extended message headers except the extended message header announced by the first notification message.

[0112] For example, the first notification message carries the extended message header types supported by the second device, including: IFIT header, APN header, IFA header, IOAM header. In this case, the second device does not support other extended message headers except IFIT header, APN header, IFA header, IOAM header, such as SR header and SRv6 header. For another example, the first notification message carries not only the extended message header types supported by the second device, including: IFIT header, APN header, IFA header, IOAM header, but also the versions of one or more extended message header types supported by the second device, including: IFIT header version V1, APN header version V3, IFA header version V2, IOAM header version V1. In this case, the second device not only does not support other extended message headers except IFIT header, APN header, IFA header, IOAM header, but also does not support IFIT headers of other versions except V1, APN headers of other versions except V3, IFA headers of other versions except V2, and IOAM headers of other versions except V1.

[0113] As another example, in scenario one, the first notification message may also carry protocols such as the network quality measurement protocol and / or path control protocol that the second device can support. When the second device supports a certain protocol, the second device supports the extended message header type specified in the protocol. For example, if the first notification message carries that the second device supports version V1 of the IFIT protocol, the extended message header types supported by the second device include the IFIT header, and the supported IFIT header version is version V1.

[0114] As another example, in scenario one, the first notification message may also carry information that the second device supports certain network quality measurement features and / or path control features, which may also be referred to as functions. When the second device supports certain network quality measurement features and / or path control features, the second device supports extended header types that enable the implementation of those network quality measurement features and / or path control features. For example, if the first notification message carries information that the second device supports the IFIT feature, the extended header types supported by the second device include the IFIT header.

[0115] In addition, in a scenario where a first notification message notifies a second device of supported extended message headers, the first notification message can be used to notify the second device that it supports all extended message headers. For example, the first notification message carries first indication information, which can indicate that the second device supports all extended message headers. For example, the first indication information is a specified string or other specified bit sequence.

[0116] In some embodiments, the second device supporting all extended message headers can be understood as: the second device supporting all message headers defined in the current network standard except the IPv4 header or the IPv6 header.

[0117] Scenario 2: The first notification message is used to notify the second device of an extended message header that is not supported.

[0118] For example, the first notification message carries one or more extended message header types that the second device does not support. For example, the first notification message carries extended message header types that the second device does not support, including: SR header and SRv6 header. This method can be called extended message header blacklist notification.

[0119] Furthermore, the first notification message may also carry one or more versions of the extended message header type not supported by the second device. That is, the first notification message not only notifies the extended message header type not supported by the second device, but also notifies the versions of the unsupported extended message header type.

[0120] For example, in addition to carrying the extended message header types not supported by the second device, including: SR header and SRv6 header, the first notification message also carries the versions of one or more extended message header types not supported by the second device, including: SR header version V3 and SRv6 header version V4.

[0121] In addition, in a scenario where the first notification message announces an extended message header that is not supported by the second device, the second device supports other extended message headers in addition to the extended message header announced by the first notification message.

[0122] For example, the first notification message carries extended message header types that the second device does not support, including: SR header and SRv6 header. In this case, the second device supports extended message headers other than SR header and SRv6 header, such as IFIT header, APN header, IFA header, IOAM header, etc. For another example, the first notification message carries extended message header types that the second device does not support, including: SR header and SRv6 header, and also carries one or more extended message header types that the second device does not support, including: SR header version V3 and SRv6 header version V4. In this case, the second device not only supports extended message headers other than SR header and SRv6 header, but also supports SR header versions other than version V3 and SRv6 versions other than version V4.

[0123] In addition, in scenario two, the second device can also carry in the first notification message protocols such as network quality measurement protocols and / or path control protocols that the second device cannot support, or carry network quality measurement characteristics and / or path control characteristics that the second device cannot support, so as to implement notification of an extended message header that the second device does not support.

[0124] In addition, in a scenario where the first notification message notifies the second device of unsupported extended message headers, the first notification message can be used to notify the second device that it does not support all extended message headers. For example, the first notification message carries second indication information, which can indicate that the second device does not support all extended message headers. The second indication information can be, for example, a specified string or other specified bit sequence.

[0125] In some embodiments, the second device not supporting all extended message headers can be understood as: the second device not supporting all message headers except the IPv4 header or the IPv6 header defined in the current network standard.

[0126] Scenario 3: The first notification message is used to notify the second device of the extended message headers supported and the extended message headers not supported by the second device.

[0127] The implementation method for implementing the first notification message to simultaneously notify the second device of both the extended message headers supported by the second device and the extended message headers not supported by the second device can be referred to in the aforementioned embodiment. For example, the first notification message carries both the extended message header types supported by the second device and the extended message header types not supported by the second device. This will not be further described here.

[0128] In addition, in an embodiment of the present application, the first notification message may be a Link Layer Discovery Protocol (LLDP) message, wherein the LLDP message includes a type-length-value (TLV) for notifying the second device of its extended message header support capability.

[0129] That is, in the embodiment of the present application, a TLV may be extended in the LLDP message, and the extended message header support capability of the second device may be announced through the extended TLV.

[0130] Table 1 is a schematic diagram of the format of an extended TLV in an LLDP message provided in an embodiment of the present application. As shown in Table 1, the extended TLV includes a TLV type (Type) field, a subtype (subtype) field, a TLV length (length) field, and a custom format for the subtype (subtype) field, and the custom format is used as the value (value) of the TLV. Among them, the information carried by the TLV type (Type) field and the subtype (subtype) field is used together to identify the TLV for announcing the extended message header support capability of this end. Among them, the custom format of the subtype field includes a type (Type) field and a version (Version) field, the type (Type) field is used to carry the extended message header type supported by the sender of the notification message, and the version (Version) field is used to carry the version of the extended message header type supported by the sender of the notification message.

[0131] Table 1

[0132] Optionally, in the embodiment of the present application, the first notification message may also adopt other protocols, which will not be described one by one here. In other words, the embodiment of the present application does not limit the format of the first notification message.

[0133] Step 702: The first device receives a first notification message from the second device.

[0134] In some embodiments, after receiving the first notification message, the first device can configure the extended message header support capability of the second device on its own end according to the first notification message, so as to facilitate subsequent processing of the message according to the extended message header support capability of the second device configured on its own end.

[0135] For example, in a scenario where a first device and a second device are directly connected, the first device receives a first notification message from the second device via a first port. In this scenario, the first device may configure the second device's extended header support capability on its own end based on the first notification message by establishing a mapping between the first port and the extended header support capability of the second device.

[0136] For example, the first device creates a mapping relationship between the port identifier of the first port and the extended header support capability of the second device in its routing table. When forwarding a message later, the extended header support capability of the second device can be quickly found through the routing table.

[0137] As another example, the first device may configure the second device's extended header support capability on its own end based on the first notification message by establishing a mapping relationship between the second network device and the extended header support capability of the second device. This implementation method can be applied not only in scenarios where the first device and the second device are directly connected, but also in scenarios where the first device and the second device are not directly connected.

[0138] For example, the first device establishes a mapping relationship between the device identifier of the second device and the extended packet header support capability of the second device in its routing table. The device identifier of the second device is used to uniquely identify the second device. For example, the device identifier of the second device includes the MAC address of the second device.

[0139] In this embodiment of the present application, after the first device receives the first notification message, the first device may also send a first notification confirmation message to the second device. The first notification confirmation message is used to notify the first device that it has acquired the second device's extended message header support capability. Correspondingly, the second device receives the first notification confirmation message from the first device.

[0140] The first notification confirmation message may, for example, be an acknowledgment character (ACK) message for the first notification message. Optionally, the payload of the first notification confirmation message may be consistent with the payload of the first notification message. In other words, the first notification confirmation message also carries the extended header support capability of the second device. Thus, when the second device receives the first notification confirmation message from the first device, since the first notification confirmation message carries the extended header support capability of the second device, the second device can determine that the first device has acquired the extended header support capability of the local end.

[0141] In addition, the first device can send the first notification confirmation message to the second device after configuring the second device's extended message header support capability on its own end. Optionally, the first device can also send the first notification confirmation message to the second device immediately after receiving the first notification message, which is not limited in this embodiment of the present application.

[0142] FIG8 is a schematic diagram of a notification process provided by an embodiment of the present application. FIG8 is an example of the communication system shown in FIG4. As shown in FIG8, in some scenarios, after the network administrator configures the extended message header support capability of network device 1 on network device 1 through the network management system, network device 1, as the second device in the embodiment shown in FIG7, turns on the parsing function of the extended message header supported by the local end, and sends a first notification message to network device 2 to realize the notification of the extended message header support capability of the local end. After receiving the first notification message, network device 2, as the first device in the embodiment shown in FIG7, can also return a first notification confirmation message to network device 1 to notify the other end that the local end has obtained the extended message header support capability of the other end.

[0143] Optionally, in other scenarios, after the network administrator configures the extended header support capability of network device 2 on network device 2 through the network management system, network device 2, as the second device in the embodiment shown in Figure 7, enables the parsing function of the extended header supported by this end, and sends a first notification message to network device 1 to implement the notification of the extended header support capability of this end. After receiving the first notification message, network device 1, as the first device in the embodiment shown in Figure 7, can also return a first notification confirmation message to network device 2 to confirm the extended header support capability of the other end.

[0144] In addition, in an embodiment of the present application, after the second device notifies the first device of its extended header support capability via a first notification message, if the second device's extended header support capability changes due to network expansion, device replacement, or network topology change, the second device may also send a second notification message to the first device. The second notification message is used to notify the second device of the change in its extended header support capability. Correspondingly, the first device receives the second notification message from the second device.

[0145] The format of the first notification message may be consistent with the format of the second notification message. Alternatively, the format of the first notification message may be inconsistent with the format of the second notification message, which is not limited in this embodiment of the present application.

[0146] In some embodiments, in a scenario where the first notification message carries one or more extended message header types supported by the second device, the second notification message carries one or more extended message header types not supported by the second device, and the extended message header types carried by the second notification message are one or more of the extended message header types carried by the first notification message.

[0147] For example, if the first notification message carries the extended message header types supported by the second device, including the IFIT header, APN header, IFA header, and IOAM header, and the second notification message carries the extended message header types not supported by the second device, including the IFIT header, this indicates that the second device has changed from supporting the IOAM header to not supporting the IOAM header.

[0148] Optionally, in other embodiments, in a scenario where the first notification message carries one or more extended message header types not supported by the second device, the second notification message carries one or more extended message header types supported by the second device, and the extended message header types carried by the second notification message are one or more of the extended message header types carried by the first notification message.

[0149] For example, if the first notification message carries the SR header and SRv6 header extensions that the second device does not support, and the second notification message carries the SR header extensions that the second device does support, this indicates that the second device has changed from not supporting the SR header to supporting it.

[0150] Optionally, in other embodiments, in a scenario where the first notification message carries one or more extended message header types supported by the second device, the second notification message also carries one or more extended message header types supported by the second device, and the extended message header types carried by the two notification messages are not exactly the same.

[0151] For example, if the first notification message carries the following extended message header types supported by the second device: IFIT header, APN header, IFA header, and IOAM header, and the second notification message carries the following extended message header types supported by the second device: IFIT header, APN header, and IFA header, this indicates that the second device has changed from supporting IOAM headers to not supporting IOAM headers.

[0152] For another example, if the first notification message carries the following extended message header types supported by the second device: IFIT header, APN header, IFA header, and the second notification message carries the following extended message header types supported by the second device: IFIT header, APN header, IFA header, and IOAM header, this indicates that the second device has changed from not supporting the IOAM header to supporting it.

[0153] Optionally, in other embodiments, in a scenario where the first notification message carries one or more extended message header types not supported by the second device, the second notification message also carries one or more extended message header types not supported by the second device, and the extended message header types carried by the two notification messages are not exactly the same.

[0154] For example, if the first notification message carries the following extended message header types that the second device does not support: SR header and SRv6 header, and the second notification message carries the following extended message header types that the second device does not support: SR header, SRv6 header, and IFIT header, this indicates that the second device has changed from supporting the IFIT header to not supporting the IFIT header.

[0155] For another example, if the first notification message carries the following extended message header types that the second device does not support: SR header, SRv6 header, and IFIT header, and the second notification message carries the following extended message header types that the second device does not support: SR header and SRv6 header, this indicates that the second device has changed from not supporting IFIT header to supporting IFIT header.

[0156] In addition, the second notification message may also carry the version of the extended message header supported or not supported by the second device, so as to notify the second device through the second notification message that the version of the extended message header type supported by the second device has changed. Examples will not be given one by one here.

[0157] Furthermore, after receiving the second notification message, the first device may also send a second notification confirmation message to the second device. The second notification confirmation message is used to notify the first device that the second device's extended message header support capability has changed. Accordingly, the second device receives the second notification confirmation message from the first device.

[0158] In an embodiment of the present application, if the extended header support capability of the second device announced in the second notification message changes, including: the second device no longer supports the target extended header after the second device supports the target extended header, the second device may disable the target extended header parsing function on its own end after receiving the second notification confirmation message. This can prevent the second device from receiving messages containing the target extended header due to premature disabling of the target extended header parsing function, thereby preventing the second device from continuing to receive messages containing the target extended header and thus causing service flow interruption.

[0159] The target extended message header may be any type of extended message header, which will not be illustrated one by one here.

[0160] Figure 9 is another notification process diagram provided by an embodiment of the present application. Figure 9 is an example of the communication system shown in Figure 4. As shown in Figure 9, after the network administrator configures the extended message header support capability of network device 1 on network device 1 through the network management system, assuming that the extended message header support capability is to support the target extended message header, network device 1, as the second device in the embodiment shown in Figure 7, turns on the parsing function of the target extended message header and sends a first notification message to network device 2. Network device 2, as the first device in the embodiment shown in Figure 7, the first notification message is used to notify network device 1 that it supports the target extended message header. Afterwards, when the network changes, the network administrator reconfigures the extended message header support capability of network device 1 on network device 1 through the network management system. The changed extended message header support capability is: network device 1 does not support the target extended message header. At this point, network device 1, as the second device in the embodiment shown in FIG7 , does not first disable the target extension header parsing function. Instead, it sends a second notification message to network device 2. The second notification message is used to notify network device 1 that it does not support the target extension header. After receiving the second notification message, network device 2, as the first device in the embodiment shown in FIG7 , sends a second notification confirmation message to network device 1 to notify the other end that the local end has obtained that the other end no longer supports the target extension header. Only after receiving the second notification confirmation message does network device 1 disable its target extension header parsing function.

[0161] If network device 1 immediately disables the target extended header parsing function when the network administrator reconfigures network device 1's extended header support capability on network device 1, network device 2 will still send messages including the target extended header to network device 1 because network device 2 has not yet been informed of the change in network device 1's extended header support capability. However, network device 2 has currently disabled the target extended header parsing function, so traffic will be interrupted at network device 2. In the embodiment of the present application, network device 1 will not disable the target extended header parsing function until it receives the second notification confirmation message sent by the peer end, that is, after confirming that the peer end has obtained the change in network device 1's extended header support capability, thereby avoiding traffic interruption caused by asynchrony between network device 1 and network device 2.

[0162] In addition, the second notification confirmation message can be, for example, an ACK message for the second notification message. Optionally, the payload of the second notification confirmation message can be consistent with the payload of the second notification message. In other words, the second notification confirmation message also carries the extended message header support capability change information of the second device. In this way, when the second device receives the second notification confirmation message from the first device, since the second notification confirmation message carries the extended message header support capability change information of the second device, the second device can determine that the first device has obtained the change in the extended message header support capability of the local end.

[0163] Step 703: The first device obtains the first message according to the extended message header support capability of the second device notified by the first notification message.

[0164] In some embodiments, in a scenario where the first device configures the extended message header support capability of the second device notified by the first notification message on its own end, step 703 may be implemented as follows: the first device obtains the first message based on the extended message header support capability of the second device configured on its own end.

[0165] For example, the extended header support capability of the second device configured locally can be implemented by establishing a mapping relationship between the first port for receiving the first notification message and the extended header support capability of the second device. In this scenario, the first device can obtain the first message based on the extended header support capability of the second device configured locally by: the first device determines that the outbound port for forwarding the first message is the first port; the first device searches the mapping relationship for the extended header support capability of the second device based on the first port; and the first device obtains the first message based on the found extended header support capability of the second device.

[0166] That is, before obtaining the first message, the extended message header support capability of the second device is searched according to the first port for forwarding the first message, and then the first message is obtained according to the extended message header support capability of the second device.

[0167] As another example, the extended header support capability of the second device configured locally can be implemented by establishing a mapping relationship between the device identifier of the second device and the extended header support capability of the second device. In this scenario, the first device can obtain the first message based on the extended header support capability of the second device configured locally by: the first device determines that the first message needs to be forwarded to the second device; the first device searches the mapping relationship for the extended header support capability of the second device based on the device identifier of the second device; and the first device obtains the first message based on the found extended header support capability of the second device.

[0168] That is, before obtaining the first message, first determine that the device receiving the first message is the second device, and then search the extended message header support capability of the second device according to the device identifier of the second device, and then obtain the first message according to the extended message header support capability of the second device.

[0169] In addition, in the embodiment of the present application, the first device may process the message from the upstream node to obtain the first message, and then send the first message. Based on this, the first device may obtain the first message by, for example, the following two steps.

[0170] Step 1: The first device receives the second message.

[0171] The second message carries a destination address, and the first device can determine that the second message needs to be sent to the second device based on the destination address.

[0172] For example, in a scenario where the first device and the second device are directly connected through the first port, the first device can find the first port by searching the routing table according to the destination address of the second message, that is, it needs to send the second message to the second device through the first port.

[0173] Step 2: The first device processes the second message according to the extended message header support capability of the second device notified in the first notification message to obtain the first message.

[0174] In some embodiments, in a scenario where the first device configures the extended message header support capability of the second device notified by the first notification message on its own end, the first device processes the second message according to the extended message header support capability of the second device notified by the first notification message. The implementation method is as follows: the first device processes the second message according to the extended message header support capability of the second device configured on its own end.

[0175] For example, in a scenario where the first device and the second device are directly connected through a first port, if the first device configures the mapping relationship between the extended message header support capability of the second device announced in the first notification message and the first port on the local end, the first device processes the second message according to the extended message header support capability of the second device configured on the local end. The implementation method can be: the first device determines that the port for forwarding the second message is the first port according to the destination address of the first message; the first device searches for the extended message header support capability of the second device from the mapping relationship according to the first port; and the first device processes the second message according to the found extended message header support capability of the second device.

[0176] Optionally, when the first device is configured with a mapping relationship between the device identifier of the second device and the extended message header support capability of the second device, the first device may process the second message based on the extended message header support capability of the second device configured on the local end in the following manner: the first device determines that the second message needs to be sent to the second device based on the destination address of the first message; the first device searches for the extended message header support capability of the second device from the mapping relationship based on the device identifier of the second device; and the first device processes the second message based on the extended message header support capability of the second device.

[0177] Since the first notification message can notify the second device of supported and / or unsupported extended message headers, the following also divides the process of processing the second message in step 2 into three scenarios for explanation.

[0178] Scenario 1: The first notification message is used to notify the second device of the extended message header supported.

[0179] For example, in a scenario where the first notification message carries one or more extended message header types supported by the second device and the second message includes the first extended message header, the first device processes the second message based on the extended message header support capability of the second device announced in the first notification message, and the implementation method for obtaining the first message can be: the first device obtains the first message based on the fact that the type of the first extended message header is an extended message header type supported by the second device, and the first message includes the first extended message header.

[0180] That is, if the type of the first extended message header is one of one or more extended message header types supported by the second device announced by the first notification message, that is, the type of the first extended message header is the extended message header type supported by the second device, then the first extended message header is retained, and the first message is obtained, and the first message includes the first extended message header.

[0181] Accordingly, the first device deletes the first extended message header in the second message based on the fact that the type of the first extended message header is not an extended message header type supported by the second device, and obtains the first message, which does not include the first extended message header.

[0182] That is, if the type of the first extended message header is not one of the one or more extended message header types supported by the second device announced by the first notification message, that is, the type of the first extended message header is not the extended message header type supported by the second device, then the first extended message header in the second message is deleted to obtain the first message.

[0183] In this case, if the first message includes a first extended message header, the type of the first extended message header is one of the one or more extended message header types supported by the second device announced in the first notification message. In other words, the type of any extended message header included in the first message after processing by the first device is an extended message header type supported by the second device.

[0184] In a scenario where the first notification message carries only one or more extended header types supported by the second device, the first device will send the extended header in the second message to the second device only if the extended header type is consistent with the extended header type announced in the first notification message. If the extended header type is inconsistent with the extended header type announced in the first notification message, the first device will not send the extended header to the second device, thereby avoiding service flow interruption caused by the second device receiving an unsupported extended header type.

[0185] Furthermore, in a scenario where the first notification message also carries the versions of one or more extended message header types supported by the second device, the first device processes the second message based on the extended message header support capability of the second device announced in the first notification message to obtain the first message. This can be achieved by: the first device deletes the first extended message header from the second message based on the fact that the type of the first extended message header is not an extended message header type supported by the second device, thereby obtaining the first message. Alternatively, the first device deletes the first extended message header from the second message based on the fact that the type of the first extended message header is an extended message header type supported by the second device, but the version of the first extended message header is not a version supported by the second device, thereby obtaining the first message.

[0186] That is, if the type of the first extended message header is not one of the one or more extended message header types supported by the second device announced in the first notification message, that is, the type of the first extended message header is not the extended message header type supported by the second device, then the first extended message header in the second message is deleted to obtain the first message, or if the type of the first extended message header is one of the one or more extended message header types supported by the second device, that is, the type of the first extended message header is the extended message header type supported by the second device, but the version of the first extended message header is not the version supported by the second device, then the first extended message header in the second message is deleted to obtain the first message.

[0187] Accordingly, the first device obtains a first message including the first extended message header based on the fact that the type of the first extended message header is an extended message header type supported by the second device and the version of the first extended message header is a version supported by the second device.

[0188] That is, if the type of the first extended message header is one or more extended message header types supported by the second device, and the version of the first extended message header is also a version supported by the second device, the first extended message header in the second message is retained to obtain the first message.

[0189] For the extended header in the second message, the first device will only send the extended header in the first message to the second device if the type and version of the extended header are consistent with the type and version of the extended header announced in the first notification message. If either the type or version of the extended header is inconsistent with the type and version of the extended header announced in the first notification message, the first device will not send the extended header in the first message to the second device, thereby avoiding service flow interruption caused by the second device receiving an unsupported extended header type or version.

[0190] In this case, if the first message includes a first extended message header, the type of the first extended message header is one of one or more extended message header types supported by the second device, and the version of the first extended message header is one of one or more extended message header types supported by the second device. In other words, after being processed by the first device, any extended message header included in the first message is of a type supported by the second device, and the version of the extended message header is a version supported by the second device.

[0191] Scenario 2: The first notification message is used to notify the second device of an extended message header that is not supported.

[0192] For example, in a scenario where the first notification message carries one or more extended message header types not supported by the second device, and the second message includes the first extended message header, the first device processes the second message based on the extended message header support capability of the second device announced in the first notification message, and the implementation method for obtaining the first message may be: the first device deletes the first extended message header in the second message based on the fact that the type of the first extended message header is an extended message header type not supported by the second device, and obtains the first message.

[0193] That is, if the type of the first extended message header is one of one or more extended message header types not supported by the second device announced in the first announcement message, the first extended message header in the second message is deleted to obtain the first message.

[0194] Accordingly, the first device obtains the first message according to the fact that the type of the first extended message header is not an extended message header type that is not supported by the second device. The first message includes the first extended message header.

[0195] That is, if the type of the first extended message header is not one of the one or more extended message header types not supported by the second device announced by the first announcement message, the first extended message header is retained to obtain the first message.

[0196] In this case, if the type of the first extended message header is one or more extended message header types not supported by the second device, the first message does not include the first extended message header.

[0197] Accordingly, if the first message includes a second extended message header, the type of the second extended message header is not one of the one or more extended message header types not supported by the second device announced in the first notification message. In other words, the type of any extended message header included in the first message after processing by the first device is not an extended message header type not supported by the second device.

[0198] In a scenario where the first notification message carries only one or more extended header types not supported by the second device, the first device will send the extended header in the first message to the second device only if the type of the extended header is inconsistent with the type of the extended header announced in the first notification message. If the type of the extended header is consistent with the type of the extended header announced in the first notification message, the first device will not send the extended header in the first message to the second device, thereby avoiding service flow interruption at the second device due to receiving an unsupported extended header type.

[0199] Furthermore, in a scenario where the first notification message also carries one or more versions of an extended message header type that is not supported by the second device, the first device deletes the first extended message header in the second message based on the fact that the type of the first extended message header is an extended message header type that is not supported by the second device, and the implementation method for obtaining the first message may be: the first device deletes the first extended message header in the second message based on the fact that the type of the first extended message header is an extended message header type that is not supported by the second device and the version of the first extended message header is a version that is not supported by the second device, and obtains the first message.

[0200] That is, if the type of the first extended message header is one of one or more extended message header types not supported by the second device announced by the first notification message, and the version of the first extended message header is not supported by the second device, the first extended message header is deleted.

[0201] Accordingly, the first device obtains the first message based on the fact that the type of the first extended message header is not an extended message header type not supported by the second device, and the first message includes the first extended message header. Alternatively, the first device obtains the first message based on the fact that the type of the first extended message header is an extended message header type not supported by the second device, but the version of the first extended message header is not a version not supported by the second device, and the first message includes the first extended message header.

[0202] That is, if the type of the first extended message header is not one of the one or more extended message header types not supported by the second device, the extended message header is retained and the first message is obtained. Alternatively, if the type of the first extended message header is one of the one or more extended message header types not supported by the second device, but the version of the first extended message header is not a version not supported by the second device, the first extended message header is retained and the first message is obtained.

[0203] In this case, if the type of the first extended message header is one or more extended message header types not supported by the second device, and the version of the first extended message header is a version of one or more extended message header types not supported by the second device, the first message does not include the first extended message header.

[0204] Accordingly, if the first message includes a second extended message header, the type of the second extended message header is not one of the one or more extended message header types not supported by the second device, or the type of the second extended message header is one of the one or more extended message header types not supported by the second device, but the version of the second extended message header is not a version not supported by the second device. In other words, the type of any extended message header included in the first message after processing by the first device is not an extended message header type not supported by the second device, or the type of any extended message header included in the first message after processing by the first device is an extended message header type not supported by the second device, but the version of the extended message header is not a version not supported by the second device.

[0205] That is, for the extended header in the second message, if either the type or version of the extended header is inconsistent with the extended header type and version announced in the first notification message, the first device will send the extended header to the second device. However, if both the type and version of the extended header are consistent with the extended header type and version announced in the first notification message, the first device will not send the extended header to the second device, thereby avoiding service flow interruption caused by the second device receiving an unsupported extended header type or version.

[0206] Scenario 3: The first notification message is used to notify the second device of the extended message headers supported and the extended message headers not supported by the second device.

[0207] In which, in a scenario where the first notification message simultaneously announces an extended message header supported by the second device and an extended message header not supported by the second device, for the first extended message header included in the second message, if the first extended message header matches the extended message header supported by the second device announced in the first notification message, the first extended message header in the second message is retained to obtain the first message.

[0208] Optionally, if the first extended message header matches an extended message header that is not supported by the second device announced in the first notification message, the first extended message header in the second message is deleted to obtain the first message.

[0209] Optionally, if the first extended message header does not match an extended message header supported by the second device announced in the first notification message, and also does not match an extended message header not supported by the second device announced in the first notification message, that is, the first device is currently unable to determine whether the second device supports the first extended message header. In this scenario, to avoid interruption of the service flow at the second device, the first device can also delete the first extended message header in the second message and obtain the first message.

[0210] In addition, in step 2, when the first device needs to add an extended message header to the second message according to current service requirements, the first device can also determine whether the extended message header can be added to the second message according to the extended message header support capability of the second device.

[0211] For example, when it is determined based on the extended header support capability of the second device that the second device does not support the extended header, the extended header is not added to the second message to avoid traffic interruption at the second device. When it is determined based on the extended header support capability of the second device that the second device supports the extended header, the extended header is added to the second message.

[0212] In addition, in the implementation of this application, the first message may also be generated by the first device itself, that is, the source of the first message is the first device, and the first message needs to be sent to the second device. In this scenario, when the first device determines that the first message needs to include a certain extended message header based on business requirements, the first device can also determine whether to add the extended message header to the first message based on the extended message header support capabilities of the second device. This will not be described in detail here.

[0213] Step 704: The first device sends a first message to the second device.

[0214] In some embodiments, in a scenario where a first device and a second device are connected via a first port, the first device sends a first message to the second device via the first port.

[0215] Step 705: The second device receives a first message from the first device, where the first device obtains the first message based on the extended message header support capability of the second device.

[0216] The process of the first device obtaining the first message according to the extended message header support capability of the second device can refer to the relevant explanation of the first message in step 703, which will not be repeated here.

[0217] Since the first message is obtained by the first device based on the extended message header support capability of the second device, if the first message carries an extended message header, the extended message header carried by the first message matches the extended message header support capability of the second device announced by the first notification message, thereby avoiding the second device receiving an unsupported extended message header and causing service flow interruption.

[0218] The embodiment shown in FIG7 is described below using FIG10 as an example. It should be noted that FIG10 is an example of an embodiment of the present application and does not limit the embodiment shown in FIG7. In the embodiment shown in FIG10, the extended message header is any extended message header, and the related processes of other extended message headers can also refer to FIG10.

[0219] Before the network administrator configures the support capability of the extended message header through the network management system, the message forwarding process illustratively includes the following steps.

[0220] 1. Network device 1 receives a message carrying the extended message header from an upstream device.

[0221] 2. Since network device 1 does not know the support capability of network device 2 for the extended message header at this time, the extended message header is deleted by default and the message without the extended message header is forwarded to network device 2; if network device 2 does not support the extended message header, network device 1 always sends the message without the extended message header to network device 2.

[0222] 3. Network device 2 receives a message carrying the extended message header from an upstream device.

[0223] 4. Since network device 2 does not know the support capability of network device 1 for the extended message header at this time, it deletes the extended message header and forwards the message without the extended message header to network device 1; if network device 1 does not support the extended message header, network device 2 always sends the message without the extended message header to network device 1.

[0224] After the network administrator configures the extended message header support capability through the network management system, the message forwarding process illustratively includes the following steps.

[0225] 5. The network administrator configures network device 1 to enable support for the extended message header.

[0226] 6. Network device 1, as the second device in the embodiment shown in Figure 7, periodically notifies network device 2 that it supports the extended message header, and carries information such as the supported extended message header type and version in the notification message; network device 2, as the first device in the embodiment shown in Figure 7, parses the notification message and knows that network device 1 supports the extended message header.

[0227] 7. Network device 2 receives the message carrying the extended message header.

[0228] 8. Since it is known in step 6 that network device 1 supports the extended message header, the message carrying the extended message header is forwarded to network device 1.

[0229] 9. The network administrator configures network device 2 to enable support for the extended message header.

[0230] 10. Network device 2, as the second device in the embodiment shown in Figure 7, periodically notifies network device 1 that it supports the extended message header, and at the same time carries information such as the supported extended message header type and version in the notification message; network device 1, as the first device in the embodiment shown in Figure 7, parses the notification message and knows that network device 2 supports the extended message header.

[0231] 11. Network device 1 receives the message carrying the extended message header.

[0232] 12. Since network device 1 knows in step 10 that network device 2 supports the extended message header, it forwards the message carrying the extended message header to network device 2.

[0233] 13. The network administrator configures network device 2 to disable the extended message header support capability.

[0234] 14. Network device 2, as the second device in the embodiment shown in FIG. 7 , sends a notification message to network device 1, notifying network device 1 that the local end no longer supports the extended message header.

[0235] 15. Network device 1, as the first device in the embodiment shown in Figure 7, sends a notification confirmation message to network device 2, confirming that it knows that network device 2 does not support the extended message header; network device 2 receives the notification confirmation message from network device 1 and turns off the extended message header parsing function.

[0236] 16. Network device 1 receives the message carrying the extended message header.

[0237] 17. Since network device 1 has learned in step 15 that network device 2 does not support the extended message header, it forwards the message without the extended message header to network device 2.

[0238] In summary, in this embodiment of the present application, a device proactively notifies other devices of its extended header support capability, enabling them to forward messages based on the notified extended header support capability. This prevents service interruptions caused by a device receiving an unsupported extended header. This approach eliminates the need for manual configuration of extended header support capabilities, thus avoiding the problems associated with such configuration.

[0239] The message forwarding device and related products provided in the embodiments of the present application are explained below.

[0240] Figure 11 is a message forwarding device 1100 provided in an embodiment of the present application. The message forwarding device 1100 is applied to a transmission device, and the transmission device is the first device or the second device in the above embodiment. For example, the message forwarding device 1100 is the first device or a functional component in the first device, or the message forwarding device 1100 is the second device or a functional component in the second device. As shown in Figure 11, the message forwarding device 1100 includes a transceiver module 1101 and a processing module 1102. The transceiver module 1101 is used to perform the transceiver operations in the message forwarding method provided in the above embodiment. For specific implementation methods, please refer to the embodiment shown in Figure 7. The processing module 1102 is used to perform operations other than the transceiver operations in the message forwarding method provided in the above embodiment. For specific implementation methods, please refer to the embodiment shown in Figure 7.

[0241] In some embodiments, the message forwarding apparatus shown in Figure 11 may be applied to the first device. In this scenario, the functions of the transceiver module 1101 and the processing module 1102 are as follows.

[0242] The transceiver module 1101 is used to receive a first notification message from the second device, where the first notification message is used to notify the second device of its extended message header support capability. For specific implementation methods, please refer to steps 701 and 702 in the embodiment of Figure 7.

[0243] The processing module 1102 is configured to obtain a first message according to the extended message header support capability of the second device announced in the first notification message; for specific implementation, reference may be made to step 703 in the embodiment of FIG. 7 .

[0244] The transceiver module 1101 is further configured to send the first message to the second device. For specific implementation, please refer to step 704 in the embodiment of FIG7 .

[0245] Optionally, the transceiver module 1101 is further configured to receive a second message. Accordingly, the processing module 1102 is configured to process the second message according to the extended message header support capability of the second device announced in the first announcement message to obtain the first message.

[0246] Optionally, the first notification message carries one or more extended message header types not supported by the second device, and the second message includes the first extended message header. The processing module 1102 is configured to: based on the first extended message header being a type not supported by the second device, delete the first extended message header from the second message to obtain the first message.

[0247] Optionally, the first notification message carries one or more extended message header types supported by the second device, and the second message includes the first extended message header. The processing module 1102 is configured to: obtain the first message based on the first extended message header type being an extended message header type supported by the second device, the first message including the first extended message header.

[0248] Optionally, the first notification message carries one or more extended message header types supported by the second device, and the first notification message also carries one or more versions of the extended message header types supported by the second device, and the second message includes the first extended message header. Processing module 1102 is configured to: based on the fact that the type of the first extended message header is an extended message header type supported by the second device, but the version of the first extended message header is not a version supported by the second device, delete the first extended message header from the second message to obtain the first message.

[0249] Optionally, the first notification message is an LLDP message, the LLDP message includes a type-length-value TLV, and the TLV is used to notify the second device of an extended message header support capability.

[0250] Optionally, the transceiver module 1101 is further configured to: receive a second notification message from a second device, where the second notification message is used to notify the second device of a change in its extended message header support capability.

[0251] Optionally, the transceiver module 1101 is further configured to send a second notification confirmation message to the second device, where the second notification confirmation message is used to notify the first device that a change in the extended message header support capability of the second device has been obtained.

[0252] Optionally, the processing module 1102 is further configured to: configure the extended message header support capability of the second device on the first device according to the first notification message; and obtain the first message according to the extended message header support capability of the second device configured on the first device.

[0253] Optionally, the transceiver module 1101 is configured to receive a first notification message from the second device via the first port. Accordingly, the processing module 1102 is configured to establish a mapping relationship between the first port and the extended header support capability of the second device, determine that the first port is the outgoing port for forwarding the first message; search the mapping relationship for the extended header support capability of the second device based on the first port; and obtain the first message based on the found extended header support capability of the second device.

[0254] Optionally, the extended message header includes at least one of an IFIT header, an IFA header, an IOAM header, an SR header, an SRv6 header, and an APN header.

[0255] In other embodiments, the message forwarding apparatus shown in Figure 11 may be applied to the second device. In this scenario, the functions of the transceiver module 1101 and the processing module 1102 are as follows.

[0256] The transceiver module 1101 is configured to send a first notification message to the first device, where the first notification message is used to notify the second device of its extended message header support capability. For specific implementation, refer to step 701 in the embodiment of FIG. 7 .

[0257] The transceiver module 1101 is further configured to receive a first message from the first device, where the first message is obtained by the first network device based on the extended message header support capability of the second device. For specific implementation, refer to steps 703 to 705 in the embodiment of FIG.

[0258] Optionally, the first notification message carries one or more extended message header types not supported by the second device; wherein, the first message does not include a first extended message header, and the type of the first extended message header is one or more extended message header types not supported by the second device.

[0259] Optionally, the first notification message carries one or more extended message header types supported by the second device; wherein, the first message includes a first extended message header, and the type of the first extended message header is one or more extended message header types supported by the second device.

[0260] Optionally, the first notification message also carries a version of one or more extended message header types supported by the second device; wherein, the first message includes a first extended message header, the type of the first extended message header is one or more extended message header types supported by the second device, and the version of the first extended message header is a version of one or more extended message header types supported by the second device.

[0261] Optionally, the transceiver module 1101 is further configured to send a second notification message to the first device, where the second notification message is used to notify the second device of a change in the extended message header support capability.

[0262] Optionally, the change in the extended header support capability of the second device includes: the second device supporting the target extended header changing to the second device not supporting the target extended header. The transceiver module 1101 is further configured to: receive a second notification confirmation message from the first device, the second notification confirmation message being used to notify the first device of the change in the extended header support capability of the second device; and the processing module 1102 is configured to: disable a target extended header parsing function on the second device.

[0263] Optionally, the extended message header includes at least one of an IFIT header, an IFA header, an IOAM header, an SR header, an SRv6 header, and an APN header.

[0264] The message forwarding device provided in the embodiments of the present application may also be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The message forwarding method provided in the above method embodiment may also be implemented using software. When the message forwarding method provided in the above method embodiment is implemented using software, each module in the message forwarding device may also be a software module.

[0265] In addition, it should be noted that the message forwarding device provided in the above embodiment only uses the division of the above functional modules as an example to illustrate the forwarding of messages. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the message forwarding device provided in the above embodiment and the message forwarding method embodiment are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0266] In addition, embodiments of the present application also provide another message forwarding device, which is applied to a transmission device, which is the first device or the second device in the above-described embodiments. For example, the message forwarding device is the transmission device or a functional component within the transmission device. The message forwarding device includes a memory and a processor. The memory is configured to store a computer program. The processor is configured to execute the computer program stored in the memory to cause the message forwarding device to perform all or part of the steps of the message forwarding method provided in the above-described method embodiments.

[0267] As an example, please refer to Figure 12, which shows a schematic diagram of another message forwarding device 1200 provided in an embodiment of the present application. The message forwarding device 1200 is a transmission device or a functional component in a transmission device. The transmission device is the first device or the second device in the above embodiment. The transmission device can be a network device such as a switch or a router. The message forwarding device 1200 can implement the method embodiment shown in Figure 7. The message forwarding device 1200 includes a main control board 1210, an interface board 1230 and an interface board 1240. In the case of multiple interface boards, a switching network board (not shown in Figure 12) is also included. The switching network board is used to complete data exchange between interface boards (interface boards are also called line cards or service boards).

[0268] The main control board 1210 performs functions such as system management, device maintenance, and protocol processing. The interface boards 1230 and 1240 provide various service interfaces and implement service forwarding. These service interfaces include POS interfaces, Gigabit Ethernet (GE) interfaces, and Asynchronous Transfer Mode (ATM) interfaces. The main control board 1210 primarily includes three functional units: a system management and control unit, a system clock unit, and a system maintenance unit. The main control board 1210, interface boards 1230, and interface boards 1240 are interconnected via a system bus and the system backplane. The interface board 1230 includes one or more processors 1231. Processors 1231 control and manage the interface board 1230 and communicate with the central processing unit 1212 on the main control board 1210. The memory 1232 on the interface board 1230 stores forwarding table entries. The interface board 1230 also includes one or more network interfaces 1233 for transmitting and receiving. The main control board 1210 also includes a memory 1214, which is used to store system management information, protocols, etc., which is not limited in this embodiment of the present application.

[0269] As shown in FIG12 , this embodiment includes multiple interface boards and employs a distributed forwarding mechanism. Under this mechanism, operations on interface board 1240 are substantially similar to those on interface board 1230. For example, interface board 1240 includes one or more network interfaces 1243 for transmitting and receiving packets, includes a memory 1242 for storing forwarding table entries, and includes a processor 1241 for controlling and managing interface board 1240 and communicating with a central processing unit 1212 on main control board 1210.

[0270] In FIG12 , the processor 1231 in interface board 1230 and / or the processor 1241 in interface board 1240 can be dedicated hardware or chips, such as a network processor or an application-specific integrated circuit, to implement the aforementioned functions. This implementation is commonly referred to as utilizing dedicated hardware or chips for forwarding plane processing. In other embodiments, the processor 1231 in interface board 1230 and / or the processor 1241 in interface board 1240 can also be a general-purpose processor, such as a general-purpose central processing unit (CPU).

[0271] There may be one or more main control boards, and when there are multiple boards, they may include a primary main control board and a backup main control board. There may be one or more interface boards. The stronger the data processing capability of the transmission equipment (such as network equipment), the more interface boards are provided. In the case of multiple interface boards, the multiple interface boards can communicate with each other through one or more switching network boards. When there are multiple boards, they can jointly achieve load sharing and redundant backup. In a centralized forwarding architecture, the transmission equipment may not require switching network boards, and the interface boards are responsible for processing the service data of the entire system. In a distributed forwarding architecture, the transmission equipment includes multiple interface boards, and data exchange between multiple interface boards can be achieved through switching network boards, providing large-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of the transmission equipment with a distributed architecture are greater than those of the transmission equipment with a centralized architecture. The specific architecture to be adopted depends on the network deployment scenario and is not limited here.

[0272] In an optional embodiment, the memory 1232 and / or the memory 1242 is a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these. The memory 1232 can exist independently and be connected to the processor 1231 via a communication bus, or it can be integrated with the processor 1231. The memory 1242 can exist independently and be connected to the processor 1241 via a communication bus, or it can be integrated with the processor 1241.

[0273] The memory 1232 is used to store program code (i.e., computer program) and is controlled by the processor 1231 to execute some or all of the steps of the message forwarding method provided in the above embodiment. The processor 1231 is used to execute the program code stored in the memory 1232. The program code may include one or more software modules. These one or more software modules may be the functional modules provided in the embodiment shown in Figure 11 above. The memory 1242 may also be used to store program code and is controlled by the processor 1241 to execute some or all of the steps of the message forwarding method provided in the above embodiment. Similarly, the memory 1214 may also be used to store program code and is controlled by the central processing unit 1212 to execute some or all of the steps of the message forwarding method provided in the above embodiment.

[0274] Optionally, the network interfaces 1233 and 1243 are devices such as transceivers for communicating with other devices or networks, such as Ethernet, radio access networks (RAN), wireless local area networks (WLAN), etc.

[0275] In addition, embodiments of the present application also provide another message forwarding device. Figure 13 is a schematic diagram of another message forwarding device 1300 provided in an embodiment of the present application. Message forwarding device 1300 is a transmission device or a functional component within a transmission device, where the transmission device is the first device or the second device in the above-described embodiments. Message forwarding device 1300 can implement the method embodiment shown in Figure 7.

[0276] As shown in FIG13 , the message forwarding device 1300 includes a processor 1302, a memory 1304, a communication interface 1306, and a bus 1308. The processor 1302, the memory 1304, and the communication interface 1306 are communicatively connected via the bus 1308. The connection method between the processor 1302, the memory 1304, and the communication interface 1306 shown in FIG13 is merely exemplary. During implementation, the processor 1302, the memory 1304, and the communication interface 1306 may also be connected using a connection method other than the bus 1308, and this embodiment of the present application is not limited thereto.

[0277] Memory 1304 is used to store computer program 13042, which may include instructions and data. Memory 1304 may be various types of storage media, such as RAM, ROM, non-volatile RAM (NVRAM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, optical storage, and registers.

[0278] Among them, the processor 1302 can be a general-purpose processor or a special-purpose processor. A general-purpose processor is a processor that performs specific steps and / or operations by reading and executing a computer program (e.g., computer program 13042) stored in a memory (e.g., memory 1304). The general-purpose processor may use data stored in the memory (e.g., memory 1304) in the process of performing the above steps and / or operations. The stored computer program can be executed to implement the relevant functions of the aforementioned processing module 1102. The general-purpose processor can be a CPU. A special-purpose processor is a processor specially designed to perform specific steps and / or operations. The special-purpose processor can be a digital signal processor (DSP), ASIC or FPGA, etc. The processor 1302 can also be a combination of multiple processors, such as a multi-core processor. The processor 1302 includes at least one circuit to perform all or part of the steps of the above-mentioned method embodiment.

[0279] The communication interface 1306 includes input / output (I / O) interfaces, physical interfaces, and logical interfaces, etc., which are used to interconnect components within the message forwarding device 1300, as well as interfaces for interconnecting the message forwarding device 1300 with other devices (e.g., transmission equipment). The physical interface can be a GE interface, which is used to interconnect the message forwarding device 1300 with other devices. The logical interface is an interface within the message forwarding device 1300, which is used to interconnect components within the message forwarding device 1300. The communication interface 1306 can be used for the message forwarding device 1300 to communicate with other devices, and the communication interface 1306 can implement the related functions of the aforementioned transceiver module 1101. The communication interface 1306 can also include a transceiver for transceiver transmission and reception, and the transceiver can also implement the related functions of the transceiver module 1101.

[0280] Bus 1308 is any type of communication bus used to interconnect processor 1302, memory 1304, and communication interface 1306. Bus 1308 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, for example. Bus 1308 may be classified as an address bus, a data bus, a control bus, or the like. For ease of illustration, FIG13 shows a single thick line, but this does not necessarily indicate that there is only one bus or only one type of bus.

[0281] The above-mentioned devices can be provided on separate chips, or at least partially or entirely on the same chip. Whether to provide each device independently on different chips or to integrate them on one or more chips often depends on the product design requirements. The embodiments of this application do not limit the specific implementation of the above-mentioned devices.

[0282] The message forwarding device 1300 shown in FIG13 is merely exemplary. During implementation, the message forwarding device 1300 may further include other components, which are not listed one by one herein.

[0283] Based on the same inventive concept, an embodiment of the present application provides a communication system, which includes a first device and a second device, at least one of which includes a message forwarding apparatus as shown in any one of Figures 11 to 13. For example, the communication system is shown in Figures 1 to 4.

[0284] Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed (for example, executed by a message forwarding device, a transmission device, one or more processors, etc.), it implements all or part of the steps of the method provided in the above method embodiment.

[0285] Based on the same inventive concept, an embodiment of the present application provides a computer program product, which includes a program or code. When the program or code is executed (for example, executed by a message forwarding device, a transmission device, one or more processors, etc.), it implements all or part of the steps of the method provided in the above method embodiment.

[0286] Based on the same inventive concept, an embodiment of the present application provides a chip, which includes a programmable logic circuit and / or program instructions. When the chip is running, it is used to implement all or part of the steps of the method provided in the above method embodiment.

[0287] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product, which includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium, or a semiconductor medium (e.g., a solid-state hard disk).

[0288] In this application, the term "at least one" refers to one or more, and "plurality" refers to two or more. In this application, unless otherwise specified, the symbol " / " generally means or, for example, A / B can mean A or B. The term "and / or" in this application is merely a description of the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, for the sake of clarity of description, in this application, words such as "first", "second", and "third" are used to distinguish between identical or similar items with basically the same functions and effects. Those skilled in the art will understand that words such as "first", "second", and "third" do not limit the quantity and execution order.

[0289] The different types of embodiments, such as method embodiments and device embodiments, provided in the embodiments of this application can be referenced with each other. The order of operations in the method embodiments provided in the embodiments of this application can be appropriately adjusted, and operations can be increased or decreased in response to circumstances. Any method that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be covered by the scope of protection of this application.

[0290] In the corresponding embodiments provided in the present application, it should be understood that the disclosed devices and the like can be implemented by other structural methods. For example, the device embodiments described above are merely schematic. For example, the division of units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. The units described as separate components may or may not be physically separated, and the components described as units may or may not be physical units, and may be located in one place or distributed on multiple transmission devices. Some or all of the units may be selected according to actual needs to achieve the purpose of the scheme of this embodiment.

[0291] The above description is merely an exemplary embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included within the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A message forwarding method, characterized in that: The method comprises: The first device receives a first notification message from the second device, where the first notification message is used to notify the second device of an extended header support capability; The first device obtains the first message according to the extended message header support capability of the second device announced in the first notification message; The first device sends the first message to the second device.

2. The method according to claim 1, wherein The method further comprises: The first device receives a second message; The first device obtains a first message according to the extended message header support capability of the second device announced in the first notification message, including: The first device processes the second message according to the extended message header support capability of the second device announced in the first notification message to obtain the first message.

3. The method according to claim 2, wherein The first notification message carries one or more extended message header types not supported by the second device, and the second message includes the first extended message header; The first device processes the second message according to the extended message header support capability of the second device announced in the first notification message to obtain the first message, including: The first device deletes the first extended message header in the second message based on the fact that the type of the first extended message header is an extended message header type not supported by the second device, and obtains the first message.

4. The method according to claim 2, wherein The first notification message carries one or more extended message header types supported by the second device, and the second message includes the first extended message header; The first device processes the second message according to the extended message header support capability of the second device announced in the first notification message to obtain the first message, including: The first device obtains the first message based on the fact that the type of the first extended message header is an extended message header type supported by the second device, where the first message includes the first extended message header.

5. The method according to claim 2, wherein The first notification message carries one or more extended message header types supported by the second device, the first notification message further carries versions of one or more extended message header types supported by the second device, and the second message includes the first extended message header; The first device processes the second message according to the extended message header support capability of the second device announced in the first notification message to obtain the first message, including: The first device deletes the first extended message header in the second message based on the fact that the type of the first extended message header is the extended message header type supported by the second device, but the version of the first extended message header is not the version supported by the second device, and obtains the first message.

6. The method according to any one of claims 1 to 5, characterized in that: The first notification message is a Link Layer Discovery Protocol (LLDP) message, and the LLDP message includes a type-length-value (TLV) message, where the TLV is used to notify the second device of an extended message header support capability.

7. The method according to any one of claims 1 to 6, wherein: After the first device receives the first notification message from the second device, the method further includes: The first device receives a second notification message from the second device, where the second notification message is used to notify the second device of a change in an extended message header support capability.

8. The method according to claim 7, wherein After the first device receives the second notification message from the second device, the method further includes: The first device sends a second notification confirmation message to the second device, where the second notification confirmation message is used to notify the first device of a change in an extended message header support capability of the second device.

9. The method according to any one of claims 1 to 8, wherein: After the first device receives the first notification message from the second device, the method further includes: The first device configures, on its own end, a capability of supporting extended message headers for the second device according to the first notification message; The first device obtains a first message according to the extended message header support capability of the second device announced in the first notification message, including: The first device obtains the first message according to the extended message header support capability of the second device configured on the local end.

10. The method according to claim 9, wherein The first device receives a first notification message from the second device, including: The first device receives a first notification message from the second device through the first port; The first device configures, on its own end, a capability of supporting an extended message header of the second device according to the first notification message, including: The first device establishes a mapping relationship between the first port and the extended header support capability of the second device; The first device obtains the first message according to the extended message header support capability of the second device configured on the local end, including: The first device determines that the egress port for forwarding the first message is the first port; The first device searches, according to the first port, for the extended packet header support capability of the second device from the mapping relationship; The first device obtains the first message according to the found extended message header support capability of the second device.

11. The method according to any one of claims 1 to 10, wherein: The extended message header includes at least one of an in-flow information telemetry IFIT header, an in-band flow analysis IFA header, an in-band operation management and maintenance IOAM header, a segment routing SR header, a segment routing SRv6 header based on the sixth generation network protocol, and an application-aware network APN header.

12. A message forwarding method, characterized in that: The method comprises: The second device sends a first notification message to the first device, where the first notification message is used to notify the second device of its extended header support capability; The second device receives a first message from the first device, where the first message is obtained by the first device according to an extended message header support capability of the second device.

13. The method according to claim 12, wherein: The first notification message carries one or more extended message header types not supported by the second device; The first message does not include a first extended message header, and the type of the first extended message header is one or more extended message header types not supported by the second device.

14. The method according to claim 12, wherein: The first notification message carries one or more extended message header types supported by the second device; The first message includes a first extended message header, and the type of the first extended message header is one or more extended message header types supported by the second device.

15. The method according to claim 14, wherein The first notification message further carries versions of one or more extended message header types supported by the second device; The first message includes a first extended message header, the type of the first extended message header is one or more extended message header types supported by the second device, and the version of the first extended message header is one or more extended message header types supported by the second device.

16. The method according to any one of claims 12 to 15, wherein: After the second device sends the first notification message to the first device, the method further includes: The second device sends a second notification message to the first device, where the second notification message is used to notify the second device of a change in an extended message header support capability.

17. The method according to claim 16, wherein The change in the extended message header support capability of the second device includes: the second device supporting the target extended message header is changed to the second device not supporting the target extended message header; After the second device sends the second notification message to the first device, the method further includes: The second device receives a second notification confirmation message from the first device, where the second notification confirmation message is used to notify the first device of a change in the extended message header support capability of the second device; The second device disables the target extension message header parsing function of the local end.

18. The method according to any one of claims 12 to 17, wherein: The extended message header includes at least one of an in-flow information telemetry IFIT header, an in-band flow analysis IFA header, an in-band operation management and maintenance IOAM header, a segment routing SR header, a segment routing SRv6 header based on the sixth generation network protocol, and an application-aware network APN header.

19. A message forwarding device, characterized in that: Applied to a first device, the apparatus includes: A transceiver module, configured to perform the transceiver operation in the method according to any one of claims 1 to 11; A processing module, configured to perform operations other than the sending and receiving operations in the method according to any one of claims 1 to 11.

20. A message forwarding device, characterized in that: Applied to the second device, the apparatus includes: A transceiver module, configured to perform the transceiver operation in the method according to any one of claims 12 to 18; A processing module, configured to perform operations other than the sending and receiving operations in the method according to any one of claims 12 to 18.

21. A message forwarding device, characterized in that: including memory and processor; The memory is used to store computer programs; The processor is configured to execute the computer program stored in the memory so that the message forwarding device executes the method according to any one of claims 1 to 18.

22. A communication system, characterized in that: The method comprises a first device and a second device, wherein the first device comprises the message forwarding apparatus as claimed in claim 19, and the second device comprises the message forwarding apparatus as claimed in claim 20.

23. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed, the method according to any one of claims 1 to 18 is implemented.

24. A computer program product, characterized in that The computer program product comprises a program or code, and when the program or code is executed, the method according to any one of claims 1 to 18 is implemented.

25. A chip, characterized in that: The chip implements the method according to any one of claims 1 to 18 when running.

Images