Message forwarding methods, communication systems and devices

Abstract

This application provides a message forwarding method, communication system, and apparatus, applicable to the field of network communication technology. In this message forwarding method: a first message received by a first node from a second node includes a DA field and an SRH field. The DA field includes a first block identifier and a first C-SID corresponding to the first block identifier. The first block identifier and the first C-SID indicate the first node. The first C-SID is contained in a first segment list field of the SRH field. The first segment list includes at least one C-SID corresponding to a second block identifier and the second block identifier before the first C-SID. If the first C-SID has a first attribute, the first node updates the DA field of the first message. The updated DA field includes at least one C-SID corresponding to the second block identifier and the second block identifier. Then, the first node forwards the first message including the updated DA field based on the updated DA field. Based on this, C-SIDs corresponding to different block identifiers can be encapsulated in the same segment list, thereby improving the utilization rate of the SRH field.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a message forwarding method, communication system and apparatus. Background Technology

[0002] Segment routing (SR) is a protocol designed based on source routing principles for forwarding data packets over a network. When SR is deployed on the Internet Protocol version 6 (IPv6) data plane, it is called SRv6 (segment routing version 6). SRv6 extends the IPv6 packet with a segment routing header (SRH). The SRH can include a stack of SID labels encapsulating the segment identification (SID) of each node on the SRv6 path. During IPv6 packet forwarding, nodes can sequentially update the destination address of the IPv6 packet based on the SID label stack, thereby achieving segment-by-segment forwarding of IPv6 packets.

[0003] Currently, each SID in the SID tag stack of the SRH occupies 128 bits. It should be understood that when there are many SIDs, the length of the SRH will be very long, which will lead to an increase in the network resources used during IPv6 packet forwarding, thereby reducing the transmission efficiency of IPv6 packets.

[0004] To address this issue, existing technologies have proposed a scheme to compress SRH (Search Engine Response) values. According to the SRv6 SID format specification, the block portion of SIDs corresponding to the same network domain is identical. Based on this, node SIDs can be compressed and encapsulated in a SID tag stack. For example, the SID tag stack can encapsulate a common block identifier, as well as the differences between multiple SIDs corresponding to the same block identifier. The differences between the SIDs encapsulated in the SID tag stack can be called compressed SIDs (C-SIDs).

[0005] In the current compression scheme, at least one C-SID encapsulated in each 128-bit segment of the SID tag stack corresponds to the same block. C-SIDs corresponding to different blocks require different 128-bit segments for encapsulation. Obviously, this scheme will result in some 128 bits not being fully used, which leads to low SRH utilization and waste of IPv6 packet resources. Summary of the Invention

[0006] This application provides a message forwarding method, communication system, and apparatus to solve the problem of low utilization of SRH in the prior art, which leads to a waste of IPv6 message resources.

[0007] Firstly, a message forwarding method is provided. This method can be executed by a first node, or by a component of the first node, such as its processor, chip, or chip system, or by a logic module or software capable of implementing all or part of the first node's functions. The method may include: First, the first node can receive a first message from a second node. This first message may include a DA field and an SRH field. The DA field includes a first block identifier and a first C-SID, which are used to indicate the first node. The SRH field includes one or more segment list fields, each of which includes a block identifier and one or more C-SIDs. The first C-SID is contained in a first segment list field within the one or more segment list fields. Before the first C-SID in the first segment list, there is a second block identifier and at least one C-SID corresponding to the second block identifier. Then, if the first C-SID has a first attribute, the first node can update the DA field of the first message. The updated DA field includes the second block identifier and at least one C-SID corresponding to the second block identifier. The first attribute indicates that the first C-SID is followed by a new C-SID corresponding to the block identifier. Furthermore, the first node can forward the first message, which includes the updated DA field, based on the updated DA field.

[0008] Based on this scheme, C-SIDs corresponding to different block identifiers are encapsulated in the same segment list, thereby improving the utilization rate of the SRH field, reducing the waste of SRH field resources, and saving communication resources. Furthermore, the first C-SID can have a first attribute, which can guide the first node to correctly copy the next block identifier and its corresponding C-SID from the segment list. In other words, based on this method of encapsulating C-SIDs corresponding to different block identifiers in the same segment list, nodes can still forward packets correctly. Therefore, compared to existing technologies, the packet forwarding method provided in this application can improve the utilization rate of the SRH field and save communication resources.

[0009] In conjunction with the first aspect described above, in one possible implementation, the DA field may further include a first position identifier, which indicates the bit position of the first C-SID in the first segment list field. Based on this, the first node can determine the bit position of the first C-SID in the first segment list field, so as to further determine the bit position of the second block identifier preceding the first C-SID and the C-SID corresponding to the second block identifier in the first segment list field.

[0010] In conjunction with the first aspect mentioned above, in one possible implementation, the value of the first position identifier is determined based on the number of bits occupied by each C-SID in the SRH field and the number of bits occupied by the block identifier.

[0011] In conjunction with the first aspect described above, in one possible implementation, the first node updates the DA field of the first message. Specifically, this may include: the first node copying the value of the bit position preceding the first C-SID in the first segment list field to the same bit position in the DA field of the first message. Based on this scheme, C-SIDs corresponding to different block identifiers can be encapsulated in the same segment list. After the last C-SID corresponding to the previous block identifier is updated, the node can immediately copy the content of the remaining bit positions in the current segment list to the DA field, thereby continuing to update the C-SID corresponding to the next block identifier. It can be seen that the node can correctly update different C-SIDs encapsulated in the same segment list, thus enabling it to correctly forward the first message using the above encapsulation method provided in this application.

[0012] In conjunction with the first aspect described above, in one possible implementation, the method may further include: the first node determining the bit position of the first C-SID in the first segment list field based on the first position identifier, and determining that the value of the bit position preceding the bit position of the first C-SID in the first segment list field is not 0. It should be understood that if the value of the bit position preceding the bit position of the first C-SID in the first segment list field is 0, then the first segment list field will not include the second block identifier and its corresponding C-SID; therefore, a judgment needs to be made first.

[0013] In conjunction with the first aspect described above, in one possible implementation, at least one C-SID corresponding to the second block identifier includes a second C-SID, the second C-SID and the second block identifier are in consecutive bit positions, and the second block identifier and the second C-SID indicate the third node. The first node forwards a first message including the updated DA field based on the updated DA field, specifically including: the first node forwards the first message including the updated DA field to the third node based on the second block identifier and the second C-SID.

[0014] Secondly, a message forwarding method is provided. This method can be executed by a second node, or by a component of the second node, such as its processor, chip, or chip system, or by a logic module or software capable of implementing all or part of the second node's functions. The method may include: the second node acquiring a first message, which may include a destination address (DA) field and a segment routing header (SRH) field. The DA field includes a first block identifier and a first compressed segment identifier (C-SID), which are used to indicate the first node. The SRH field includes one or more segment list fields, each of which includes a block identifier and one or more C-SIDs. The first C-SID is contained in a first segment list field within the one or more segment list fields. The first C-SID has a first attribute indicating that a new block identifier corresponding to the first C-SID follows the first C-SID. The first segment list also includes a second block identifier and at least one C-SID corresponding to the second block identifier before the first C-SID. Then, the second node sends the first message to the first node.

[0015] Based on this scheme, C-SIDs corresponding to different block identifiers are encapsulated in the same segment list, thereby improving the utilization rate of the SRH field, reducing the waste of SRH field resources, and saving communication resources. Furthermore, the first C-SID can have a first attribute, which can guide the first node to correctly copy the next block identifier and its corresponding C-SID from the segment list. In other words, based on this method of encapsulating C-SIDs corresponding to different block identifiers in the same segment list, nodes can still forward packets correctly. Therefore, compared to existing technologies, the packet forwarding method provided in this application can improve the utilization rate of the SRH field and save communication resources.

[0016] In conjunction with the second aspect above, in one possible implementation, the DA field also includes a first position identifier, which is used to indicate the bit position of the first C-SID in the first segment list field.

[0017] In conjunction with the second aspect above, in one possible implementation, the value of the first position identifier is determined based on the number of bits occupied by each C-SID in the SRH field and the number of bits occupied by the block identifier.

[0018] Thirdly, a communication system is provided, comprising at least one of the following: a first node performing the message forwarding method described in the first aspect above, and a second node performing the message forwarding method described in the second aspect above.

[0019] Fourthly, a communication device is provided, comprising: a processor; the processor being coupled to a memory and, after reading computer instructions stored in the memory, executing the method described in the first or second aspect above according to the instructions.

[0020] In one possible implementation, the communication device further includes a memory for storing computer instructions.

[0021] In one possible implementation, the communication device further includes a communication interface for communicating with other devices. For example, the communication interface may be a transceiver, an input or output interface, an interface circuit, an output circuit, an input circuit, a pin, or related circuitry.

[0022] In one possible implementation, the communication device can be a chip or a chip system. When the communication device is a chip system, it can be composed of chips or may include chips and other discrete components.

[0023] In one possible implementation, when the communication device is a chip or chip system, the aforementioned communication interface can be an input or output interface, interface circuit, output circuit, input circuit, pin, or related circuit on the chip or chip system. The aforementioned processor can also be embodied as a processing circuit or logic circuit.

[0024] Fifthly, a computer-readable storage medium is provided that stores instructions which, when executed on a computer, enable the computer to perform the methods described in the first or second aspect above.

[0025] In a sixth aspect, a computer program product containing instructions is provided, which, when run on a computer, enables the computer to perform the methods described in the first or second aspect above.

[0026] The technical effects of any of the possible implementations of aspects three through six can be found in the technical effects of different implementations of aspects one or two above, and will not be repeated here. Attached Figure Description

[0027] Figure 1 A schematic diagram illustrating an IPv6 packet applied in SRv6, provided as an embodiment of this application;

[0028] Figure 2 A schematic diagram illustrating an IPv6 packet encapsulating an explicit path, provided as an embodiment of this application;

[0029] Figure 3 A schematic diagram of an SRv6 SID format provided for an embodiment of this application;

[0030] Figure 4 A schematic diagram illustrating another SRv6 SID format provided for an embodiment of this application;

[0031] Figure 5 A schematic diagram of yet another IPv6 packet provided in an embodiment of this application;

[0032] Figure 6 This application provides a schematic diagram illustrating the changes in the DA field during IPv6 packet forwarding.

[0033] Figure 7 A schematic diagram of yet another IPv6 packet provided in an embodiment of this application;

[0034] Figure 8 This application provides another schematic diagram illustrating the changes in the DA field during IPv6 packet forwarding.

[0035] Figure 9 A schematic diagram of yet another IPv6 packet provided in an embodiment of this application;

[0036] Figure 10 This application provides another schematic diagram illustrating the changes in the DA field during IPv6 packet forwarding.

[0037] Figure 11 A schematic diagram of a communication system provided in this application;

[0038] Figure 12 A schematic diagram of the structure of a communication device provided in this application;

[0039] Figure 13 A flowchart illustrating a message forwarding method provided in an embodiment of this application;

[0040] Figure 14 A schematic diagram illustrating the format of a first message provided for an embodiment of this application;

[0041] Figure 15 A schematic diagram illustrating the updating of the DA field in a first message, as provided in an embodiment of this application;

[0042] Figure 16 A schematic diagram of another communication system provided in the embodiments of this application;

[0043] Figure 17 A schematic diagram illustrating the format of an SRH field provided in an embodiment of this application;

[0044] Figure 18 This application provides a schematic diagram illustrating the changes in the DA field during IPv6 packet forwarding.

[0045] Figure 19 This application provides a schematic diagram illustrating the changes in the DA field during IPv6 packet forwarding.

[0046] Figure 20 A schematic diagram of another communication device provided in this application. Detailed Implementation

[0047] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can represent A or B. "And / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Meanwhile, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0048] Before introducing the embodiments of this application, the technical terms and related technologies involved in this application will be explained. It should be noted that the following explanations are for the purpose of making the embodiments of this application easier to understand, and should not be regarded as a limitation on the scope of protection claimed by the embodiments of this application.

[0049] SRv6: SRv6 is the application of the SR concept in IPv6 technology. Specifically, SRv6 adds an SRH (Signal Header) to the header of an IPv6 packet and encapsulates the explicit path as a SID within the SRH, thereby guiding the forwarding of IPv6 packets in the network.

[0050] Figure 1 This diagram illustrates an IPv6 packet used in SRv6. The IPv6 packet may include an IPv6 base header, an SRH (Short Message Header), and a payload. The IPv6 base header may include, in sequence, a version field, a traffic class field, a flow label field, a payload length field, a next header field, a hop limit field, a source address (SA) field, and a destination address (DA) field. The meanings of each field in the IPv6 base header can be found in the explanation in Request for Comments (RFC) 8200, and will not be repeated here. The SRH may include, in sequence, a next header field, an extension header length (Hdr Ext Len) field, a routing type field, remaining segments (Segments Left (SL)) field, a last entry field, flags fields, a tag field, and at least one segment list (e.g., ...). Figure 1 The segmentslist[0] to segment list[n] shown are used to illustrate the meaning of each field in the SRH. The meaning of each field can be found in RFC 8754, and will not be repeated here. The SL field, also known as the SL pointer, points sequentially to each segment list during IPv6 packet forwarding. The value of SL is related to the number of segments in the list.

[0051] In the IPv6 packet diagram shown in this application, the fields on the right follow the fields on the left, and the fields below follow the fields above. This is a consistent explanation in this application.

[0052] It should be noted that, Figure 1 The segment list in the SRH shown is encoded from back to front. That is, in Figure 1In the segment list[0] to segment list[n] shown, segment list[0] is the last segment of the path; segment list[1] is the second to last segment of the path; ...; segment list[n-1] is the second segment of the path; and segment list[n] is the first segment of the path. Correspondingly, when a node reads the SRH, it also reads from back to front. For example, the node first reads segment list[n], then segment list[n-1], ..., until it reads segment list[0].

[0053] based on Figure 1 The IPv6 packet format shown allows the source node to encapsulate the explicit path of the IPv6 packet as a SID in at least one segment list, thereby enabling SR forwarding. For example, the SIDs of the explicit path in an IPv6 packet are: A1::1, A2::1, A3::1, A4::1, A5::1, A6::1, A7::1. Therefore, an IPv6 packet carrying this path can be forwarded as follows: Figure 2 As shown, A1::1, A2::1, A3::1, A4::1, A5::1, A6::1, and A7::1 are sequentially encapsulated in segment lists from right to left, with each segment list carrying a SID. Optionally, refer to [link to relevant documentation]. Figure 2 Before the list of segments carrying the forwarding path, IPv6 packets may also include a list of segments carrying a Virtual Private Network (VPN) SID, which indicates the VPN on which the IPv6 packet is forwarded.

[0054] As described above, each SID in the SRH occupies 128 bits. Therefore, when there are many SIDs in the segment list, the SRH will be very long. This will increase the network resources used during IPv6 packet forwarding, thereby reducing the efficiency of IPv6 packet transmission.

[0055] To avoid the problem of excessively long SRHs, existing technologies propose a scheme to compress SIDs to achieve SRH compression. Existing technologies re-divide the format of SRv6 SIDs, so that the SRH only carries the varying parts of the SIDs (i.e., the parts that differ between different SIDs). This reduces the space occupied by the SID information carried in the SRH, thus achieving SRH compression.

[0056] For example, Figure 3The diagram illustrates the format of an SRv6 SID, which can include the following fields in sequence: locator, function, and arguments. The locator identifies the network segment to which the SID belongs and is unique within the SR domain. The function identifies the local operation command bound to the SID; after a specified node within the SR domain receives an IPv6 packet, it performs the relevant operation based on the function field of the SRv6 SID. The arguments define information such as the flow and service of the IPv6 packet; arguments are optional. The SRv6 SID is 128 bits long. When the sum of the number of bits in the locator, function, and arguments is less than 128 bits, the remaining bits of the SRv6 SID are padded with 0s.

[0057] To compress SRH, existing technologies further divide the SRv6 SID. For example, such as... Figure 4 As shown, the locator field in an SRv6 SID can further include a prefix and a node ID. The prefix is ​​typically assigned by the network operator to the subnet where the node resides, identifying the entire subnet. A subnet can also be called a network segment. All nodes within the subnet share the same prefix, meaning their SIDs constitute a SID block. The prefix identifies the SID block, hence it can also be called a block. The node ID distinguishes nodes within the subnet; different nodes within the same subnet have different node IDs.

[0058] In the forwarding path of IPv6 packets, multiple adjacent nodes are located in the same subnet, resulting in their SIDs having the same common prefix, causing redundancy. Therefore, this redundancy can be optimized by removing the prefix and other redundant parts from the SID, retaining the Node ID and function as the C-SID, and encapsulating the C-SID within an SRH (Segment Redirecting Buffer) to compress the SRH. In some compression scenarios, the C-SID can also be called the G-SID (Generalized SID), which will be used consistently here.

[0059] In SRv6, each node's SID is pre-configured. Nodes can report their SID information, along with compression capability information, to the controller. The controller can compress the SIDs of each node according to the SRv6 path sequence and encapsulate them in a SID label stack. This SID label stack sequentially includes the C-SID corresponding to each node. The controller then sends the SID label stack, including the C-SID, to the head node of the SRv6 path. The head node then encapsulates the SID label stack, including the C-SID, in the SRH of the IPv6 packet, and each node on the SRv6 path forwards the packet according to the SID label stack.

[0060] Optionally, the SID tag stack can consist of at least one segment list, with multiple C-SIDs encapsulated in at least one segment list. Typically, each segment list is 128 bits long.

[0061] It is understandable that the C-SID encapsulation method and the IPv6 packet forwarding method are used together. Only when the C-SID encapsulation method and the IPv6 packet forwarding method match can the IPv6 packet be forwarded correctly.

[0062] Optionally, the encapsulation of C-SID and the corresponding forwarding method of IPv6 packets can include the following three schemes:

[0063] In the first implementation, each segment list in the SID tag stack issued by the controller can include a block identifier and at least one C-SID corresponding to that block identifier. C-SIDs corresponding to the same block are encapsulated in the same segment list. If there are multiple C-SIDs corresponding to the same block, then multiple consecutive segment lists can be used for encapsulation. C-SIDs corresponding to different blocks are encapsulated in different segment lists. During the sequential encapsulation of C-SIDs, if the C-SID to be encapsulated is different from the block corresponding to a previous C-SID, then a new segment list needs to be used for encapsulation. The unused portion of the segment list is padded with zeros.

[0064] Alternatively, in the first implementation, the block in the segment list can occupy 32 bits, and the C-SID can occupy 16 bits.

[0065] For example, Figure 5 The diagram illustrates an IPv6 packet. The SID tag stack in the SRH of this IPv6 packet can include three segment lists, namely... Figure 5The segment list[0], segment list[1], and segment list[2] are in the SRH. The SID tag stack is encapsulated from back to front. For example, segment list[2] can include block1, C-SID1, C-SID2, C-SID3, C-SID4, C-SID5, and C-SID6. Segment list[1] can include block1 and C-SID7, with the remaining part being 0. Segment list[0] can include block2, C-SID1, C-SID2, C-SID3, and C-SID4, with the remaining part padded with 0.

[0066] When a node forwards an IPv6 packet based on the SID label stack, it can copy information from the SID label stack to the DA field in units of segment lists (the complete 128 bits). Therefore, the DA field of an IPv6 packet can sequentially include a block identifier and at least one C-SID. A node can consider the block identifier and the first C-SID following it in the DA field as the locator+function part of the SRv6 SID, and the other SIDs after this first C-SID as the arguments part. Thus, the DA field can still present the complete SRv6 SID. In other words, a node can reconstruct the complete SRv6 SID based on the block identifier and C-SID. Furthermore, the node can forward the IPv6 packet to the next-hop node (i.e., the node corresponding to the reconstructed SRv6 SID) based on the reconstructed complete SRv6 SID. Then, the next-hop node can sequentially overwrite the other C-SIDs after the current first C-SID to update the DA field, and then continue forwarding based on the updated DA field. It is understandable that after the C-SIDs are sequentially overwritten, the second C-SID after the block identifier in the DA field before the update becomes the first C-SID after the block identifier in the updated DA field. Therefore, the updated DA field can reconstruct the complete SRv6 SID, and packets can be forwarded accordingly. This process is the same as the process and principle of the node forwarding packets based on the block identifier and the first C-SID after the block identifier, and will not be elaborated here. It is also understandable that when the DA field includes C-SIDs, subsequent nodes update the C-SIDs in the DA field by overwriting the previous C-SIDs with the later C-SIDs. Furthermore, after all the C-SIDs in the DA field have been reconstructed into complete SRv6 SIDs, that is, when the IPv6 packet is forwarded to the node corresponding to the last C-SID in the current DA field, that node can copy the complete content of the next segment list to the DA field to update the DA field. Afterwards, the IPv6 packet continues to be forwarded according to the updated DA field. It should be understood that after copying the new segment list and updating the DA field, the process of the node forwarding IPv6 packets based on the DA field is the same as before, and will not be described again.

[0067] Optionally, the operation of a node to overwrite an earlier C-SID in the DA field with a later C-SID can be called a NEXT operation.

[0068] For example, Figure 5The DA field of the IPv6 packet shown currently contains information from the segment list [2], namely block1, C-SID1, C-SID2, C-SID3, C-SID4, C-SID5, and C-SID6. Figure 5 Taking the IPv6 packet shown as an example, the diagram illustrating the changes in the DA field during IPv6 packet forwarding can be seen as follows: Figure 6 As shown. First, block1+C-SID1 can reconstruct the complete SRv6 SID. Therefore, the IPv6 packet can be forwarded by the header node to the node corresponding to block1+C-SID1. Then, the node corresponding to block1+C-SID1 can sequentially overwrite the C-SIDs after C-SID1 (e.g., C-SID2 overwrites C-SID1), padding with 0s at the end, to obtain the IPv6 packet with the updated DA field. After the DA field is updated, block1+C-SID2 can again reconstruct the complete SRv6 SID. Therefore, the node corresponding to block1+C-SID2 can forward the IPv6 packet with the updated DA field to the node corresponding to block1+C-SID2. This process continues, with subsequent nodes repeating the NEXT operation until the DA field is updated to block1+C-SID6. Since there are no other C-SIDs after C-SID6 in the DA field, the node corresponding to block1+C-SID6 can copy the information from segment list[1] to the DA field, thus determining that the next node for IPv6 packet forwarding is the node corresponding to block1+C-SID7. Since there are no other C-SIDs after C-SID7 in segment list[1], the node corresponding to block1+C-SID7 can continue to copy the information from segment list[0] to the DA field, thus determining that the next node for IPv6 packet forwarding is the node corresponding to block2+C-SID1. Segment list[0] includes multiple C-SIDs. Subsequent nodes can continue to perform NEXT operations on the information copied from segment list[0] in the DA field until the DA field is updated to block2+C-SID4. The update process of the information in segment list[0] in the DA field is similar to the update process of the information in segment list[2] in the DA field, and will not be described in detail here.

[0069] In the second implementation, the segment list of the SID label stack issued by the controller may not encapsulate the block identifier, only the C-SID. The block identifier can be configured by the node in the DA field of the packet. The node can copy the C-SIDs to be processed one by one from the SID label stack in the SRH to the block in the DA field. Thus, the block and C-SID in the DA field can be used to reconstruct the complete SRv6 SID, thereby enabling the forwarding of IPv6 packets. In this implementation, C-SIDs corresponding to the same block in the SID label stack can be encapsulated in the same segment list. If there are many C-SIDs belonging to the same block, multiple consecutive segment lists can be used for encapsulation. It should be noted that when multiple C-SIDs corresponding to the same block are encapsulated in multiple consecutive segment lists, the multiple C-SIDs corresponding to the same block are consecutive in the field. For example, if multiple C-SIDs corresponding to the same block are not fully encapsulated in one segment list, they can continue to be encapsulated in the next segment list. Furthermore, C-SIDs in the next segment list can be encapsulated from right to left, ensuring that the first C-SID in the next segment list is consecutive to the last C-SID in the previous segment list in terms of field. Additionally, any unencapsulated C-SID portions in the segment list are padded with zeros.

[0070] In the second implementation, C-SIDs other than the last C-SID corresponding to a block can have a continuation of compression (COC) attribute. This COC attribute (COC flavor) can be used to indicate that other C-SIDs corresponding to the same block are included after this C-SID. The last C-SID corresponding to each block may not include attribute information and can be called no flavor.

[0071] Alternatively, in the second implementation, each C-SID in the SID tag stack can occupy 32 bits.

[0072] For example, Figure 7 The diagram illustrates an IPv6 packet. The SID tag stack in the SRH of this IPv6 packet can include three segment lists, namely... Figure 7The segment list[0], segment list[1], and segment list[2] are defined in the SRH. Segment list[2] may include C-SID1, C-SID2, C-SID3, and C-SID4; segment list[1] may include C-SID5, C-SID6, and C-SID7, with the remainder being 0; segment list[0] may include C-SID1, C-SID2, and C-SID3. Among them, the C-SIDs in segment list[1] (such as C-SID5 and C-SID6) are encapsulated from right to left (i.e., from back to front), so C-SID5 to C-SID7 in segment list[1] and C-SID1 to C-SID4 in segment list[2] are consecutive in terms of fields. It should be understood that the SID tag stack in SRH is encapsulated from back to front. Therefore, C-SID1 to C-SID4 in segment list [2] and C-SID5 to C-SID7 in segment list [1] correspond to the same block, and C-SID1 to C-SID3 in segment list [0] correspond to the same block.

[0073] Continue to refer to Figure 7 C-SID1 to C-SID4 in segment list [2] can carry the COC attribute ( Figure 7 In the segment list [1], C-SID5 and C-SID6 can carry the COC attribute, while SID7 does not carry attribute information. Figure 7 (NO flavor is used to indicate this). C-SID1 to C-SID3 in segment list[0] carry the COC attribute, while C-SID4 does not. It should be understood that C-SID4 in segment list[2] is the last C-SID in that segment list, and the COC attribute of C-SID4 indicates that the C-SID in segment list[1] and the C-SID in segment list[2] belong to the same block. Therefore, Figure 7 The C-SIDs in segment list [1] and segment list [2] are numbered consecutively to indicate that they are C-SIDs corresponding to the same block. C-SID7 in segment list [1] does not carry the COC attribute, which can indicate that there are no other C-SIDs corresponding to the same block after C-SID7 in segment list [1]. Figure 7The C-SIDs in segment list[0] are renumbered starting from 1 to reflect that they are C-SIDs in the new block.

[0074] When a node forwards IPv6 packets based on the DA field, the block and C-SID in the DA can be used to reconstruct the complete SRv6 SID, which enables IPv6 packet forwarding. The process of reconstructing the complete SRv6 SID from the block and C-SID and implementing IPv6 packet forwarding can be found in the description of the first implementation method, and will not be repeated here. After forwarding IPv6 packets based on the reconstructed complete SRv6 SID, if the C-SID in the current DA field carries the COC attribute, the node can determine that the next C-SID to be processed corresponds to the same block as the C-SID in the DA field. Therefore, the node can copy the next C-SID from the segment list, overwriting the current C-SID in the DA field. If the C-SID in the current DA field does not contain attribute information, the node can determine that the next C-SID to be processed corresponds to a different block than the C-SID in the DA field. Therefore, a node can update the block in the DA field and copy the C-SID from the next segment list (because C-SIDs corresponding to different blocks are not encapsulated in the same segment list) to overwrite the current C-SID. It can be understood that for multiple consecutive C-SIDs corresponding to the same block, the node can copy them one by one from the segment list to the DA field, until it reaches the last C-SID corresponding to the same block. The last C-SID corresponding to the same block does not include attribute information. The node can switch the block in the DA field and copy the C-SID from the next segment list. After switching blocks, the node can still update the C-SID corresponding to the new block to the DA field one by one according to the COC attribute, as before, which will not be elaborated further.

[0075] The operation of a node copying the next C-SID after the current C-SID from the segment list to the DA field based on the COC attribute of the current C-SID can be called a COC operation.

[0076] For example, Figure 7 The IPv6 packet shown has its DA field currently configured with block information as block1, and the copied C-SID is C-SID1 in segment list [2]. Figure 7 Taking the IPv6 packet shown as an example, the diagram illustrating the changes in the DA field during IPv6 packet forwarding can be seen as follows: Figure 8As shown. First, block1+C-SID1 can restore the complete SRv6 SID corresponding to C-SID1. Thus, the IPv6 packet can be forwarded to the node corresponding to block1+C-SID1. Since C-SID1 carries the COC attribute, the node corresponding to block1+C-SID1 can perform the COC operation to copy C-SID2 to the DA field, overwriting the current C-SID1. In this way, subsequent nodes can repeat the COC operation until it is copied to C-SID7 in segment list[1]. Since C-SID7 in segment list[1] does not include attribute information (NO flavor), the node corresponding to block1+SID7 can switch the block value in the DA field to block2 and copy the first C-SID in the next segment list (i.e., C-SID1 in segment list[0]) to the DA field. Subsequently, each node can repeat the COC operation until it is copied to C-SID3 in segment list[0].

[0077] In the third implementation, within the SID tag stack issued by the controller, the block information can be encapsulated before the C-SID corresponding to the same block, and then continuously encapsulated with at least one C-SID corresponding to that block. If a single segment list cannot encapsulate all the C-SIDs corresponding to the same block, multiple consecutive segment lists can be used. When multiple consecutive segment lists encapsulate the C-SID corresponding to the same block, only the first segment list needs to encapsulate the block; subsequent segment lists only need to encapsulate the subsequent C-SIDs. C-SIDs corresponding to different blocks need to be encapsulated in different segment lists; that is, a new segment list is needed to encapsulate the C-SID corresponding to a new block.

[0078] In the third implementation, among the multiple C-SIDs corresponding to the same block, all C-SIDs except the last one can carry the COC attribute. The last C-SID corresponding to each block has no attribute.

[0079] It can be seen that the third implementation scheme's C-SID encapsulation method is a combination of the C-SID encapsulation methods in the first two implementation schemes.

[0080] For example, Figure 9 The diagram illustrates an IPv6 packet. The SID tag stack in the SRH of this IPv6 packet can include three segment lists, namely... Figure 9The segment list[0], segment list[1], and segment list[2] are defined in the document. Segment list[2] includes block1, C-SID1, C-SID2, C-SID3, C-SID4, C-SID5, and C-SID6, all of which include the COC attribute. Segment list[1] includes C-SID7, C-SID8, and C-SID9, with the remaining part being 0. C-SID7 and C-SID8 include the COC attribute, while C-SID9 does not include attribute information. C-SID7, C-SID8, and C-SID9 are encapsulated from back to front, thus, C-SID7 to C-SID9 are consecutive to C-SID1 to C-SID6 in terms of fields. Segment list[0] includes C-SID1, C-SID2, and C-SID3. C-SID1 and C-SID2 include the COC attribute, while C-SID3 does not include attribute information.

[0081] During IPv6 packet forwarding, firstly, the head node on the forwarding path can completely copy the segment list [2] to the DA field. The node's operation on the DA field can refer to the operation in the first implementation method (such as the NEXT operation mentioned above). If the last C-SID in the segment list [2] includes the COC attribute, then after processing the last C-SID in the DA field, the node can determine that the next C-SID to be updated in the DA field corresponds to the same block as the previous C-SID. Thus, the node can subsequently copy C-SIDs from the segment list [1] one by one to update the DA field. The operation of copying C-SIDs one by one from the segment list can refer to the operation on the DA field in the second implementation method (the COC operation mentioned above). When the next C-SID to be updated corresponds to a different block than the previous C-SID (i.e., when a block needs to be switched), the node can completely copy the contents of the next segment list of the segment list where the current C-SID is located in the DA field. This operation can be exactly the same as the operation of the head node. In summary, for a new block's C-SID, the node first completely updates the DA field with the first segment list containing the C-SID corresponding to the new block. If subsequent segment lists contain other C-SIDs corresponding to the same block, then each C-SID can be updated in the DA field. This third implementation combines the DA field handling methods from the first and second implementations.

[0082] For example, Figure 9The DA field of the IPv6 packet shown currently contains information from the segment list [2], namely block1, C-SID1, C-SID2, C-SID3, C-SID4, C-SID5, and C-SID6. Figure 9 Taking the IPv6 packet shown as an example, the diagram illustrating the changes in the DA field during IPv6 packet forwarding can be seen as follows: Figure 10 As shown. First, the node can perform a NEXT operation on the DA field until it is updated to block1+C-SID6. Then, since C-SID6 includes the COC attribute, the node can perform a COC operation to copy C-SID7 from the segment list [1] to overwrite C-SID6 in the DA field. Subsequently, the node can continue to perform the COC operation until the DA field is updated to block1+C-SID9. Since C-SID9 does not include attribute information, the node can completely copy the segment list [0] information (i.e., block2, C-SID1, C-SID2, C-SID3) to the DA field. In the subsequent IPv6 packet forwarding process, the subsequent node can perform a NEXT operation on the DA field that copies the segment list [0] information until it is updated to block2+C-SID3. This C-SID3 has no attribute information and there is no subsequent segment list in the SRH label stack, so the IPv6 packet has reached the destination node of the SRv6 path.

[0083] Understandably, during the forwarding of IPv6 packets, nodes copy C-SID information from the SID label stack to the DA field, thereby enabling IPv6 packet forwarding. Optionally, after the information in the segment list of the SID label stack has been completely updated to the DA field, the node can pop / discard the updated segment list. The SL field in the IP header of the IPv6 packet can be used to indicate the number of segments remaining in the SID label stack besides the segment list copied from the DA field. When the C-SID has no attribute information and the value of the SL field is 0, the IPv6 packet has reached the destination node of the SRv6 path.

[0084] All three implementation methods described above encapsulate C-SIDs based on the same block. Each segment list in the SID tag stack can only contain C-SIDs corresponding to the same block; C-SIDs corresponding to different blocks need to be encapsulated in different segment lists. Any unused segment lists need to be padded with zeros. This encapsulation method can lead to wasted SRH field resources, resulting in low SRH utilization and consequently wasted communication resources.

[0085] To further improve the utilization rate of SRH and save communication resources, this application proposes a new SRH format and message forwarding method, which can improve the utilization rate of fields in the segment list and reduce the waste of SRH field resources.

[0086] First, the communication scenario (or communication system) in which the message forwarding method of this application is applied will be introduced. Figure 11 A schematic diagram of a communication system provided in this application, such as Figure 11 As shown, the communication system may include a first node 1101 and a second node 1102, with the first node 1101 connected to the second node 1102. The first node 1101 and the second node 1102 may be directly connected or indirectly connected through an intermediate node; this application does not impose any limitation on this.

[0087] Optionally, the message forwarding method provided in this application can be applied to an SRv6 scenario. The first node 1101 and the second node 1102 can be nodes on an SRv6 path, and the first node and the second node can perform SRv6 forwarding.

[0088] Optionally, the message forwarding method provided in this application can be applied to SRv6 scenarios across block domains, where the first node can be the last node in its respective block domain. On the SRv6 path, the next node after the first node belongs to a different block domain than the first node.

[0089] It should be noted that the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. Figure 11 or Figure 12 The architecture of the communication system and the connection relationships between the nodes shown are merely illustrative. For example, Figure 11 The communication system shown may also include more nodes. As will be apparent to those skilled in the art, with the evolution of network architecture and the emergence of new service scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0090] Optionally, in the embodiments of this application, the first node and the second node can be a communication device, and the first node and the second node can be adopted. Figure 12 The shown composition or includes Figure 12 The components shown. Figure 12 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application, such as... Figure 12 As shown, the communication device 120 includes one or more processors 1201, a communication line 1202, and at least one communication interface. Figure 12(This is merely an example illustration, using a communication interface 1203 and a processor 1201 as examples.) Optionally, a memory 1204 may also be included.

[0091] The processor 1201 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0092] The communication line 1202 may include a path for communication between different components.

[0093] The communication interface 1203 can be a transceiver module used to communicate with other devices or communication networks, such as Ethernet, RAN, wireless local area networks (WLAN), etc. For example, the transceiver module can be a transceiver or a similar device. Optionally, the communication interface 1203 can also be a transceiver circuit located within the processor 1201, used to implement the processor's signal input and signal output.

[0094] The memory 1204 can be a device with storage functionality. For example, it can be read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions; random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions; electrically erasable programmable read-only memory (EEPROM); compact disc read-only memory (CD-ROM) or other optical disc storage; optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.); magnetic disk storage media or other magnetic storage devices; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory can exist independently and be connected to the processor via communication line 1202. The memory can also be integrated with the processor.

[0095] The memory 1204 stores computer execution instructions for implementing the scheme of this application, and its execution is controlled by the processor 1201. The processor 1201 executes the computer execution instructions stored in the memory 1204, thereby implementing the message forwarding method provided in the embodiments of this application.

[0096] Alternatively, in this embodiment, the processor 1201 may execute the processing-related functions in the message forwarding method provided in the following embodiments of this application, and the communication interface 1203 may be responsible for communicating with other devices or communication networks. This embodiment does not specifically limit this.

[0097] Optionally, the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0098] In a specific implementation, as one embodiment, the processor 1201 may include one or more CPUs, for example... Figure 12 CPU0 and CPU1 in the CPU.

[0099] In a specific implementation, as one example, the communication device 120 may include multiple processors, for example... Figure 12 The processors 1201 and 1207 are described herein. Each of these processors may be a single-core processor or a multi-core processor. The processors herein may include, but are not limited to, at least one of the following: a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a microcontroller unit (MCU), or an artificial intelligence processor, and other computing devices that run software. Each computing device may include one or more cores for executing software instructions to perform calculations or processing.

[0100] In a specific implementation, as one embodiment, the communication device 120 may further include an output device 1205 and an input device 1206. The output device 1205 communicates with the processor 1201 and can display information in various ways. For example, the output device 1205 may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device 1206 communicates with the processor 1201 and can receive user input in various ways. For example, the input device 1206 may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0101] The aforementioned communication device 120 may sometimes be referred to as a communication equipment, which can be a general-purpose device or a special-purpose device. For example, the communication device 120 may be a network device such as a router, switch, or gateway, or a terminal device, or a controller in a network, or have... Figure 12 Devices with similar structures. This application does not limit the type of communication device 120 to any particular embodiment.

[0102] Next, the message forwarding method provided in the embodiments of this application will be described. The nodes / devices in the following embodiments may have… Figure 12 The components are shown. The actions, terminology, etc., involved in the various embodiments of this application can be referenced interchangeably without limitation. The message names or parameter names in the messages in the embodiments of this application are merely examples; other names may be used in specific implementations without limitation.

[0103] It should be understood that the block identifier in the following embodiments refers to the block identifier, which will be explained uniformly here and will not be repeated below.

[0104] Figure 13 The illustration shows a flowchart of a message forwarding method provided in an embodiment of this application. The message forwarding method may include the following steps:

[0105] Step 1301: The second node sends a first message to the first node, and correspondingly, the first node receives the first message from the second node.

[0106] In this embodiment of the application, the first message may include a DA field and an SRH field. The DA field may include a first block identifier and a first C-SID corresponding to the first block identifier. The first block identifier and the first C-SID can be used to indicate a first node. The SRH field may include one or more segment list fields. Each segment list field may include a block identifier and one or more C-SIDs.

[0107] Optionally, the first node and the second node can be nodes on the SRv6 path, and the first packet can be an IPv6 packet used for SRv6 forwarding, which will be explained uniformly here.

[0108] Optionally, the DA field can be located in the IPv6 basic header of the first packet, and the SRH field can be located after the IPv6 basic header. The SRH field belongs to the extended header.

[0109] Optionally, the first C-SID in the DA field can immediately follow the first block identifier, thus allowing the DA field to present a complete SRv6 SID structure. The first block identifier and the first C-SID can be used to reconstruct the SRv6 SID of the first node. For example, the first block identifier and the first C-SID can be considered as the locator+function part of the first node's SRv6 SID. It should be understood that since the first block identifier and the first C-SID can be used to reconstruct the first node's SRv6 SID, they can be used to indicate the first node. Based on this, the second node will send the first packet to the first node according to the DA field.

[0110] Understandably, the list of segments carrying block identifiers and one or more C-SIDs in the SRH field belongs to the SID label stack of the first packet, and the SID label stack can include the aforementioned list of one or more segments. The SID label stack sequentially encapsulates the C-SIDs corresponding to each node on the SRv6 path. Based on this, the SID label stack can be used to guide the SRv6 forwarding of the first packet.

[0111] In this embodiment, the first C-SID can be updated from the SID tag stack of the SRH (i.e., the one or more segment lists mentioned above) to the DA field. One possible implementation is that the first C-SID can be included in the first segment list field of the one or more segment list fields mentioned above. In the first segment list, at least one C-SID corresponding to a second block identifier and a second block identifier can be included before the first C-SID, where the second block identifier is different from the first block identifier. That is, in the first message provided in this embodiment, C-SIDs corresponding to different second block identifiers can be encapsulated in the same segment list. Based on this, the number of segment lists required for encapsulating C-SIDs can be reduced, thereby shortening the length of the SRH field and saving communication resources.

[0112] For example, a schematic diagram of the format of a first message can be as follows: Figure 14 As shown. The first message may include an IPv6 basic header and an SRH field. The DA field is located in the IPv6 basic header, and the first segment list is one of at least one segment from the SRH field. The DA field may include, from left to right, the first block identifier and the first C-SID; the remaining parts are not limited in this application. Other fields in the IPv6 basic header besides the DA field can be found in [reference needed]. Figure 1 The description of the IPv6 basic header is provided. Additionally, the first segment list, from beginning to end, may include the second block identifier, at least one C-SID corresponding to the second block identifier, and the aforementioned first C-SID; the remaining parts are not limited in this application. Furthermore, the fields preceding the segment list in the SRH field can be found in [reference needed]. Figure 1 The description of the IPv6 basic header.

[0113] Optionally, in the SRH field, the C-SIDs corresponding to the nodes on the SRv6 path are encapsulated sequentially from the end of the field backwards, and the list of segments containing the first block identifier corresponding to the first C-SID can be located after the list of first segments. For example, using... Figure 14 Taking the first message as an example, a segment list can be included after the first segment list. Figure 14 (Not shown), this segment list can carry the first block identifier.

[0114] Optionally, in the first segment list to which the first C-SID belongs, the first C-SID and the C-SIDs following the first C-SID correspond to the first block identifier, and the first C-SID is the last C-SID corresponding to the first block identifier. For example... Figure 14 As shown, all C-SIDs preceding the first C-SID are the C-SIDs corresponding to the second identifier.

[0115] Step 1302: If the first C-SID has the first attribute, the first node updates the DA field of the first message. The updated DA field includes the second block identifier and at least one C-SID corresponding to the second block identifier.

[0116] In this embodiment, the first C-SID may have a first attribute, which can be used to indicate that a new block identifier corresponds to the first C-SID. As one possible implementation, this first attribute can be called the continuation of new block (CNB) attribute. The CNB attribute can indicate that continuation begins from a new block after the current SID, meaning that the next SID after the current SID corresponds to a different block than the current SID.

[0117] Furthermore, the first attribute can also be used to guide the first node's processing behavior of the first message (e.g., the action in step 1302 above). It can be understood that the first C-SID is the last C-SID corresponding to the first block identifier, and C-SIDs following the first C-SID correspond to new block identifiers. Having the first attribute on the first C-SID allows the first node to recognize that the first C-SID is followed by the C-SID corresponding to the new block identifier.

[0118] Optionally, in this embodiment of the application, if a block's C-SID is followed by other blocks' C-SIDs, then the last C-SID corresponding to that block can carry the first attribute.

[0119] It is understandable that, since there are no other C-SIDs after the last C-SID in the SRH, the last C-SID encapsulated in the SRH does not need to have the first attribute.

[0120] Optionally, if the first C-SID has a first attribute, the first node updates the DA field of the first packet. Specifically, this may include: if the first C-SID has a first attribute, the first node can copy the content before the first C-SID in the first segment list to the DA field to obtain the updated DA field. Therefore, the updated DA field may include at least one C-SID corresponding to the second block identifier and the second block identifier. For example, using... Figure 14 Taking the first message shown as an example, as Figure 15 As shown, the first node can copy the content before the first list segment to the DA field.

[0121] Optionally, the DA field of the first message may include a first position identifier, which may indicate the bit position of the first C-SID in the first segment list field. As one possible implementation, the first position identifier may be located at the very end of the DA field of the first message. For example, as... Figure 14 As shown, the end of the DA field can be the first position identifier.

[0122] Optionally, when a node determines that the first C-SID has a first attribute, it can further determine the bit position of the first C-SID in the first segment list based on the first position identifier, and then determine whether the content of the bits before the first C-SID in the first segment list is 0. If the content of the bits before the first C-SID is not 0, and the first C-SID also has the first attribute, then the first node can determine that the first C-SID in the first segment list includes the C-SID corresponding to the new block identifier. Then, the first node can copy the content before the first C-SID to the DA field, and the remaining part of the DA field can be padded with 0s. If the content of the bits before the first C-SID is 0, and the first C-SID also has the first attribute, then the first node can determine that the C-SID corresponding to the new block identifier is encapsulated in the next segment list of the first segment list. Then, the first node can copy the content of the next segment list of the first segment list to the DA field.

[0123] Optionally, the value of the first position identifier can be determined based on the number of bits occupied by each C-SID. For example, such as Figure 14As shown, the first segment of the list is 128 bits long, the second block of identifiers can occupy 32 bits, and each C-SID can occupy 16 bits. The first C-SID can occupy bits 97 to 112 of the first segment of the list. Therefore, the value of the first position identifier can be 7, indicating that the first C-SID occupies the 7th 16-bit segment of the first segment of the list.

[0124] As one possible implementation, the first position identifier can be called the compression left (CL) identifier.

[0125] Step 1303: The first node forwards the first packet, which includes the updated DA field, based on the updated DA field.

[0126] Optionally, the second block identifier in the updated DA field and the first C-SID following the second block identifier can be used to reconstruct a complete SRv6 SID. The first node can then determine the next-hop node based on this reconstructed complete SRv6 SID. Subsequently, the first node can forward the first message including the updated DA field to the determined next-hop node.

[0127] As one possible implementation, the second C-SID in at least one C-SID corresponding to the second block identifier is the first C-SID after the second block identifier; in other words, the bit positions of the second C-SID and the second block identifier are consecutive. This second block identifier and the second C-SID can be used to reconstruct the complete SRv6 SID of the third node; that is, the second block identifier and the second C-SID can indicate the third node. Based on this, the first node can forward a first message, including the updated DA field, to the third node according to the second block identifier and the second C-SID.

[0128] In summary, in this embodiment, C-SIDs corresponding to different block identifiers are encapsulated in the same segment list, thereby improving the utilization rate of the SRH field, reducing the waste of SRH field resources, and saving communication resources. Furthermore, the last C-SID corresponding to a block identifier can have a first attribute, which guides the node to correctly copy the next block identifier and its corresponding C-SID from the segment list. In other words, based on this method of encapsulating C-SIDs corresponding to different block identifiers in the same segment list, the node can still forward the message correctly. Therefore, compared to the prior art, the message forwarding method provided in this application can improve the utilization rate of the SRH field and save communication resources.

[0129] Optionally, the encapsulation method of the SRH field in the first message can be the same as... Figure 9 The SRH fields shown are similar, the only difference being that C-SIDs corresponding to different blocks can be encapsulated in the same segment list. Figure 9 Taking the SRH field in the message shown as an example, if the encapsulation method provided in this application is followed, block2, C-SID1, C-SID2 and C-SID3 in segment list[0] can be encapsulated in the free part of segment list[1].

[0130] In the SRH of the first message provided in this application embodiment, the segment list can first encapsulate block information, and then sequentially encapsulate multiple C-SIDs corresponding to that block. If multiple C-SIDs corresponding to a block cannot be completely encapsulated by a single segment list, a new segment list can be used for encapsulation. When encapsulating C-SIDs corresponding to the same block in a segment list following the block's segment list, the encapsulation should proceed from the end of the segment list to the beginning, ensuring that multiple C-SIDs are consecutive in terms of fields. If, after the last C-SID corresponding to a block is encapsulated, the C-SID corresponding to the next block still needs to be encapsulated, the remaining part of the segment list containing the last C-SID can be used to continue encapsulating the C-SID corresponding to the next block, without starting encapsulation from a new segment list. The remaining part of the segment list containing the next block and its corresponding C-SID can be encapsulated from the beginning to the end, ensuring that the block is encapsulated at the beginning of the segment list. If multiple C-SIDs corresponding to the next block cannot be completely encapsulated in the remaining part, a new segment list is then used for encapsulation. The subsequent C-SID encapsulation principle is similar to the previous one, and can be referred to the preceding description, so it will not be repeated here.

[0131] Optionally, all C-SIDs preceding the last C-SID corresponding to a block can have the COC attribute to indicate that the C-SIDs corresponding to that block have not yet ended. If a block's C-SIDs are followed by C-SIDs corresponding to other blocks, then the last C-SID corresponding to that block can carry the first attribute (i.e., the CNB attribute). Additionally, the last C-SID among all C-SIDs encapsulated in the SRH field does not include the COC and CNB attributes and can be without attributes (NOflavor).

[0132] It is understandable that the above message forwarding method is applied in scenarios involving cross-block domain forwarding, where the first node can be the last node in the block domain. Figure 4 The communication system shown only includes a part of the SRv6 forwarding path, and the above message forwarding method is only a part of the forwarding process in SRv6 forwarding.

[0133] Optionally, this application also provides a communication system that can, as Figure 16As shown, the communication system may include host 1 and host 2, which can be connected sequentially through 14 nodes, R1 to R14. Among them, nodes R1, R2, R3, R5, R6, R7, R8, R9, R10, R11, R13, and R14 support SRv6 capability, while nodes R4 and R12 do not support SRv6 capability.

[0134] This application uses the example of host 1 sending an IPv6 packet to host 2. First, host 1 can send the IPv6 packet to node R1, thus SRv6 programming can be performed at node R1. Node R1 can encapsulate the explicit path for subsequent SRv6 forwarding of the IPv6 packet in the SRH (Signal Buffer Header). This explicit path is: Node R1 → Node R2 → Node R3 → Node R5 → Node R6 → Node R7 → Node R8 → Node R9 → Node R10 → Node R11 → Node R13 → Node R14. As one implementation, the SRH of the IPv6 packet can sequentially encapsulate the SRv6 SID information of each node along the explicit path.

[0135] Understandably, nodes that do not support SRv6 capabilities (such as nodes R4 and R12) will forward packets according to existing IPv6 technology and will not be aware of SRH. Nodes that do not support SRv6 capabilities are not considered to be nodes on SRv6 paths, even if they are on the forwarding path of IPv6 packets.

[0136] It is understandable that when host 1 sends an IPv6 packet to host 2, node 1 is the header node for sending the IPv6 packet, and SRv6 programming is performed at node R1. Therefore, the SRv6 path information encapsulated in the SRH may not include the SRv6 SID information of node R1, but rather include the SRv6 SID information of nodes R2, R3, R5, R6, R7, R8, R9, R10, R11, R13, and R14.

[0137] Optionally, nodes R2, R3, R5, R6, R7, R8, and R9 can belong to block domain 1, while nodes R10, R11, R13, and R14 can belong to block domain 2. As a possible implementation, the SRv6 SID of the nodes can be compressed based on the block identifier to obtain the C-SID, which is then encapsulated in the SRH. For example, the SRv6 SID of node R2 can be compressed to C-SID1 corresponding to block1, the SRv6 SID of node R3 can be compressed to C-SID2 corresponding to block1, the SRv6 SID of node R5 can be compressed to C-SID3 corresponding to block1, the SRv6 SID of node R6 can be compressed to C-SID4 corresponding to block1, the SRv6 SID of node R7 can be compressed to C-SID5 corresponding to block1, the SRv6 SID of node R8 can be compressed to C-SID6 corresponding to block1, the SRv6 SID of node R9 can be compressed to C-SID7 corresponding to block1, the SRv6 SID of node R10 can be compressed to C-SID1 corresponding to block2, the SRv6 SID of node R11 can be compressed to C-SID2 corresponding to block2, the SRv6 SID of node R13 can be compressed to C-SID3 corresponding to block2, and the SRv6 SID of node R14 can be compressed to C-SID4 corresponding to block2.

[0138] Based on the C-SID described in the previous paragraph, the SRH field in the IPv6 packet encapsulated by node R1 can be as follows: Figure 17 As shown, the SID tag stack of this SRH can be encapsulated from back to front, sequentially containing the block identifier and the corresponding C-SID of the block. Figure 16 The C-SID of the node on the SRv6 path shown can be encapsulated in two segment lists (i.e. Figure 17 The segment list [0] and segment list [1] are defined in the code. Segment list [1] can include block1 and the corresponding C-SID1, C-SID2, C-SID3, C-SID4, C-SID5 and C-SID6. The end of segment list [0] can include the corresponding C-SID7 of block1, and the beginning of segment list [0] can include block2 and the corresponding C-SID1, C-SID2, C-SID3 and C-SID4 of block2. Each block identifier (such as block1 and block2) can occupy 32 bits, and each C-SID can occupy 16 bits.

[0139] Optionally, such as Figure 18 As shown, C-SID1, C-SID2, C-SID3, C-SID4, C-SID5, and C-SID6 in segment list [1] can have the COC attribute to indicate that the C-SID is followed by the C-SID corresponding to block1. C-SID7 in segment list [0] can have the CNB attribute to indicate that the C-SID is followed by the C-SID corresponding to block1. C-SID1, C-SID2, and C-SID3 in segment list [0] can have the COC attribute to indicate that the C-SID is followed by the C-SID corresponding to block2. C-SID4 in segment list [0] can have no attribute to indicate that there are no other C-SIDs after C-SID4.

[0140] It is understood that the application provides Figure 13 The corresponding message forwarding method is applied in cross-block domain forwarding scenarios, where the first node is the last node in the block domain. Therefore, in Figure 16 In the communication system shown, node R9 can be the first node mentioned above, and node R9 can perform the above... Figure 13 The corresponding message forwarding method.

[0141] Next, combined Figure 16 The communication system shown and Figure 17 The SRH field encapsulated in node R1, as shown, provides a detailed description of the forwarding process of IPv6 packets sent from host 1 to host 2.

[0142] First, node R1 encapsulates the SRH (such as...) in the message. Figure 17 After the SRH shown, node R1 can copy the contents of segmentlist[1] to the DA field. Then, node R1 can determine the next-hop node of the IPv6 packet based on the DA field. For example, the IPv6 packet that node R1 wants to send can be as follows: Figure 18 As shown in (a) above. It can be understood that block1 and C-SID1 in the DA field can be used to reconstruct the SRv6 SID of node R2, so node R1 can forward IPv6 packets to node R2.

[0143] Subsequently, node R2 receives an IPv6 packet from node R1. The DA field of this IPv6 packet matches the SRv6 SID table on node R2's local machine, allowing node R2 to determine whether to forward it as an SRv6 packet. Node R2 can then perform a NEXT operation to update the DA field in the IPv6 packet. Afterward, node R2 forwards the IPv6 packet to node R3 based on the updated DA field. Subsequently, nodes R3, R5, R6, and R7 will also perform NEXT operations, thereby forwarding IPv6 packets. The process of nodes performing NEXT operations and forwarding IPv6 packets can be understood by referring to the above text. Figure 6 The relevant descriptions of the NEXT operation in the corresponding embodiments will not be repeated here. Additionally, it should be noted that the route determined by node R3 for forwarding to node R5 will pass through node R4, but node R4 only performs a normal forwarding process.

[0144] After node R7 performs the NEXT operation, it forwards the IPv6 packet to node R8. For example, the IPv6 packet received by node R8 can be... Figure 18 As shown in (b) above. The DA field in the IPv6 packet received by node R8 includes block1 and C-SID6. There are no other C-SIDs after C-SID6. Since C-SID6 has the COC attribute, node R8 can perform a COC operation to copy C-SID7 from the end of segment list[0] to the DA field, overwriting the original C-SID6, thereby updating the DA field. In addition, the end of the updated DA field may include a CL identifier, which can indicate the position of the copied C-SID7 in segment list[0]. For example, the packet after node R8 updates the DA field can be as follows. Figure 19 As shown in (a), C-SID7 can occupy the 8th 16-bit segment in segment list [0], so the value of the CL identifier in the updated DA field can be 8. In the IPv6 packet after updating the DA field, block1 and C-SID7 can restore the SRv6 SID of node R9, so node R8 can forward the updated IPv6 packet to node R9.

[0145] Afterwards, node R9 can receive an IPv6 packet from node R8. The DA field of this IPv6 packet can match the SRv6 SID table on node R9's local machine, thus node R9 can determine to perform SRv6 forwarding. Since C-SID7 has the CNB attribute and the content of the field before C-SID in segment list[0] is not 0, node R9 can copy the content of the field before C-SID7 in segment list[0] to the DA field, padding the unused portion at the end with 0, thereby updating the DA field. For example, the IPv6 packet after node R9 updates the DA field can be as follows: Figure 19 As shown in (b) above. It is understandable that the updated DA field's block2 and C-SID1 can reconstruct the SRv6 SID of node R10, allowing node R9 to forward IPv6 packets to node R10. Afterwards, upon receiving the IPv6 packet from node R9, node R10 can perform a NEXT operation, thus forwarding the IPv6 packet to node R11. Node R11, upon receiving the IPv6 packet from node R10, also performs a NEXT operation, forwarding the IPv6 packet to node R13. Node R13, upon receiving the IPv6 packet from node R11, also performs a NEXT operation, forwarding the IPv6 packet to node R14. The process of nodes performing the NEXT operation and forwarding IPv6 packets can be understood by referring to the above. Figure 6 The relevant descriptions of the NEXT operation in the corresponding embodiments will not be repeated here. Additionally, it should be noted that the route determined by node R11 for forwarding to node R13 will pass through node R12, but node R12 only performs a normal forwarding process.

[0146] Ultimately, node R14 will receive IPv6 packets from node R13. For example, the IPv6 packets received by node R14 may be as follows: Figure 19 As shown in (c), the DA field can match the SRv6 SID table on node R14. Since C-SID4 has no attributes, node R14 can determine that SRv6 forwarding has ended. Subsequently, node R14 can decapsulate the IPv6 packet, look up the IP routing table, and then forward the IPv6 packet to host 2.

[0147] As can be seen from the detailed description above of the forwarding process of IPv6 packets sent from host 1 to host 2, in this embodiment, the SRH field of the IPv6 packet allows C-SIDs corresponding to different block identifiers to be encapsulated in the same segment list, and SRv6 forwarding can still be performed correctly. Therefore, the packet encapsulation method and forwarding method provided in this application can improve the utilization rate of the SRH field and save communication resources.

[0148] Optionally, in this embodiment of the application, the head node that performs SRv6 forwarding (e.g., Figure 16 The SID label stack (carrying SRv6 path information) of node R1 in the packet encapsulated in the SRH can be issued by the controller to the head node. Before IPv6 packet forwarding, each node on the SRv6 path can report its own SRv6 SID information, SID compression capability information, etc., to the controller. The controller can compress and encapsulate the SRv6 SID based on the information reported by each node, and then issue a label stack carrying C-SID (i.e., at least one segment list mentioned above) to the head node of the SRv6 forwarding path.

[0149] Optionally, the first attribute newly defined in this application may be reported to the controller by the node having the first attribute through protocols including but not limited to intermediate system to intermediate system (ISIS), open shortest path first (OSPF), pathcomputation element communication protocol (PCEP), bordergate protocol-link-state (BGP-LS), etc. This application does not impose any restrictions on this.

[0150] Optionally, the SRH of the IPv6 packet may also encapsulate label stacks for other purposes, such as label stacks carrying VPN SIDs, and this application does not impose any restrictions on this.

[0151] Optionally, in the message forwarding process provided in this application embodiment, the segment list that has been fully updated in the SID tag stack can be discarded, and correspondingly, the value of the SL field can also be changed adaptively, which will be explained uniformly here. For example, Figure 19 In (a), (b), and (c), the segment list[1] may not be included in the SRH, and the value of the SL field can be 0. It is understandable that when a node copies the contents of the new segment list to update the DA field, it can decrement the value of the SL field by 1.

[0152] It should be noted that, in the above method embodiments, the action of the first node can be determined by... Figure 12 The processor 1201 in the communication device 120 shown calls the application code stored in the memory 1204 to instruct the first node to execute, and the action of the second node can be performed by... Figure 12 The processor 1201 in the communication device 120 shown calls the application code stored in the memory 1204 to instruct the second node to execute.

[0153] It is understood that, in the above embodiments, the methods and / or steps implemented by the first node can also be implemented by components (e.g., chips or circuits) that can be used by the first node, and the methods and / or steps implemented by the second node can also be implemented by components (e.g., chips or circuits) that can be used by the second node.

[0154] Optionally, embodiments of this application also provide a communication device for implementing the various methods described above. This communication device can be a first node in the above method embodiments, a device including the first node, or a component usable in the first node. The communication device can also be a second node in the above method embodiments, a device including the second node, or a component usable in the second node. It is understood that, in order to implement the above functions, the communication device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0155] This application embodiment can divide the communication device into functional modules according to the above method embodiment. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0156] Figure 20 A schematic diagram of another communication device is shown. This communication device 200 may include a transceiver module 2001 and a processing module 2002. The transceiver module 2001, also known as a transceiver unit, is used to implement transceiver functions; for example, it may be a transceiver circuit, transceiver, transceiver interface, or communication interface.

[0157] In this example, the communication device 200 is taken as the first node in the above method embodiment:

[0158] The transceiver module 2001 can be used to receive a first message from a second node. The first message includes a destination address (DA) field and a segment routing header (SRH) field. The DA field includes a first block identifier and a first compressed segment identifier (C-SID) corresponding to the first block identifier. The first block identifier and the first C-SID are used to indicate the first node. The SRH field includes one or more segment list fields. Each segment list field includes a block identifier and one or more C-SIDs. The first C-SID is contained in a first segment list field within the one or more segment list fields. The first segment list includes a second block identifier and at least one C-SID corresponding to the second block identifier before the first C-SID. The processing module 2002 can be used to update the DA field of the first message if the first C-SID has a first attribute. The updated DA field includes a second block identifier and at least one C-SID corresponding to the second block identifier. The first attribute indicates that a new block identifier's corresponding C-SID follows the first C-SID. The transceiver module 2001 can also be used to forward the first message including the updated DA field based on the updated DA field.

[0159] Optionally, the processing module 2002 is used to update the DA field of the first message, which may specifically include: the processing module 2002 is used to copy the value of the bit position before the bit position where the first C-SID is located in the first segment list field to the same bit position in the DA field of the first message.

[0160] Optionally, the processing module 2002 can also be used to determine the bit position of the first C-SID in the first segment list field based on the first position identifier, and to determine that the value of the bit position before the bit position of the first C-SID in the first segment list field is not 0.

[0161] Optionally, at least one C-SID corresponding to the second block identifier includes a second C-SID, the second C-SID and the second block identifier are in consecutive bit positions, and the second block identifier and the second C-SID indicate the third node. The transceiver module 2001 is used to forward a first message including the updated DA field according to the updated DA field, specifically including: the transceiver module 2001 is used to forward the first message including the updated DA field to the third node according to the second block identifier and the second C-SID.

[0162] Taking the communication device 200 as the second node in the above method embodiment as an example:

[0163] Processing module 2002 can be used to acquire a first message. The first message includes a destination address (DA) field and a segment routing header (SRH) field. The DA field includes a first block identifier and a first compressed segment identifier (C-SID) corresponding to the first block identifier. The first block identifier and the first C-SID are used to indicate a first node. The SRH field includes one or more segment list fields. Each segment list field includes a block identifier and one or more C-SIDs. The first C-SID is contained in the first segment list field of the one or more segment list fields. The first C-SID has a first attribute indicating that a new block identifier's corresponding C-SID follows the first C-SID. The first segment list also includes a second block identifier and at least one C-SID corresponding to the second block identifier before the first C-SID. Transceiver module 2001 can be used to send the first message to the first node.

[0164] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here. Since the communication device 200 provided in this embodiment can execute the above message transmission method, the technical effects it can obtain can be referred to the above method embodiments, and will not be repeated here.

[0165] In this embodiment, the communication device 200 is presented in an integrated manner, divided into various functional modules. Here, "module" can refer to a specific ASIC, circuitry, a processor and memory executing one or more software or firmware programs, integrated logic circuitry, and / or other devices that can provide the aforementioned functions. In a simplified embodiment, those skilled in the art will recognize that the communication device 200 can employ... Figure 12 The communication device 120 shown is in the form of [example device].

[0166] for example, Figure 12 The processor 1201 in the communication device 120 shown can call computer execution instructions stored in the memory 1204 to cause the communication device 120 to execute the message transmission method in the above method embodiment.

[0167] Specifically, Figure 20 The functions / implementation process of the transceiver module 2001 and the processing module 2002 can be obtained through... Figure 12 The processor 1201 in the communication device 120 shown calls computer execution instructions stored in memory 1204 to implement the function. Alternatively, Figure 20 The function / implementation process of the transceiver module 2001 can be obtained through Figure 12 This is achieved through the communication interface 1203 in the communication device 120 shown. Figure 20 The function / implementation process of the processing module 2002 can be obtained through Figure 12 The processor 1201 in the communication device 120 shown calls computer execution instructions stored in memory 1204 to implement the function.

[0168] Since the communication device 200 provided in this embodiment can execute the above-described message transmission method, the technical effects it can achieve can be referred to the above-described method embodiments, and will not be repeated here.

[0169] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0170] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0171] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0172] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0173] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0174] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0175] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-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. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0176] As used herein, the terms “component,” “module,” “system,” etc., are intended to refer to a computer-related entity, which may be hardware, firmware, a combination of hardware and software, software, or running software. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a running thread, a program, and / or a computer. As an example, an application running on a computing device and the computing device itself can both be components. One or more components may reside in a running process and / or thread, and components may be located in a single computer and / or distributed among two or more computers. Furthermore, these components are capable of execution from various computer-readable media having various data structures thereon. These components may communicate locally and / or remotely via signals, such as based on one or more data packets (e.g., data from a component that interacts with a local system, another component in a distributed system, and / or signals that interact with other systems via a network such as the Internet).

[0177] This application presents various aspects, embodiments, or features relating to systems that may include multiple devices, components, modules, etc. It should be understood and appreciated that individual systems may include additional devices, components, modules, etc., and / or may not include all the devices, components, modules, etc. discussed in conjunction with the accompanying drawings. Furthermore, combinations of these approaches are also possible.

[0178] Additionally, in the embodiments of this application, the term "exemplary" is used to indicate that it is an example, illustration, or illustration. Any embodiment or design scheme described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Rather, the use of the term "exemplary" is intended to present the concept in a specific manner.

[0179] In the embodiments of this application, the terms "information," "signal," "message," and "channel" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction, their intended meanings are consistent. Similarly, "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction, their intended meanings are consistent. "System" and "network" may sometimes be used interchangeably. Without emphasizing the distinction, their intended meanings are consistent; for example, "communication network" also refers to "communication system."

[0180] The network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0181] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A message forwarding method, characterized in that, The method includes: The first node receives a first message from the second node, wherein the first message includes a destination address (DA) field and a segment routing header (SRH) field. The DA field includes a first block identifier and a first compressed segment identifier (C-SID) corresponding to the first block identifier. The first block identifier and the first C-SID are used to indicate the first node. The SRH field includes one or more segment list fields. Each segment list field includes a block identifier and one or more C-SIDs. The first C-SID is contained in a first segment list field of the one or more segment list fields. The first segment list field includes a second block identifier and at least one C-SID corresponding to the second block identifier before the first C-SID. When the first C-SID has a first attribute, the first node updates the DA field of the first message. The updated DA field includes the second block identifier and at least one C-SID corresponding to the second block identifier. The first attribute is used to indicate that the first C-SID is followed by a C-SID corresponding to a new block identifier. The first node forwards a first message including the updated DA field based on the updated DA field.

2. The method according to claim 1, characterized in that, The DA field also includes a first position identifier, which is used to indicate the bit position of the first C-SID in the first segment list field.

3. The method according to claim 2, characterized in that, The value of the first location identifier is determined based on the number of bits occupied by each C-SID in the SRH field and the number of bits occupied by the block identifier.

4. The method according to claim 3, characterized in that, The first node updates the DA field of the first message, including: The first node copies the value of the bit position before the first C-SID in the first segment list field to the same bit position in the DA field of the first message.

5. The method according to claim 4, characterized in that, The method further includes: The first node determines the bit position of the first C-SID in the first segment list field based on the first position identifier, and determines that the value of the bit position before the bit position of the first C-SID in the first segment list field is not 0.

6. The method according to any one of claims 1-5, characterized in that, The second block identifier includes at least one C-SID, which is a second C-SID. The second C-SID and the second block identifier are in consecutive bit positions. The second block identifier and the second C-SID indicate a third node. The first node forwards a first packet including the updated DA field based on the updated DA field, including: The first node forwards the first message, including the updated DA field, to the third node based on the second block identifier and the second C-SID.

7. A message forwarding method, characterized in that, The method includes: The second node acquires a first packet, which includes a Destination Address (DA) field and a Segment Routing Header (SRH) field. The DA field includes a first block identifier and a first compressed segment identifier (C-SID) corresponding to the first block identifier. The first block identifier and the first C-SID are used to indicate the first node. The SRH field includes one or more segment list fields. Each segment list field includes a block identifier and one or more C-SIDs. The first C-SID is included in a first segment list field of the one or more segment list fields. The first C-SID has a first attribute, which indicates that a new block identifier corresponding to a C-SID is included after the first C-SID. The first segment list also includes a second block identifier and at least one C-SID corresponding to the second block identifier before the first C-SID. The second node sends the first message to the first node.

8. The method according to claim 7, characterized in that, The DA field also includes a first position identifier, which is used to indicate the bit position of the first C-SID in the first segment list field.

9. The method according to claim 8, characterized in that, The value of the first location identifier is determined based on the number of bits occupied by each C-SID in the SRH field and the number of bits occupied by the block identifier.

10. A communication system, characterized in that, The communication system includes a first node and a second node; The second node is used to send a first message to the first node; wherein, the first message includes a destination address (DA) field and a segment routing header (SRH) field, the DA field including a first block identifier and a first compressed segment identifier (C-SID) corresponding to the first block identifier, the first block identifier and the first C-SID being used to indicate the first node; the SRH field includes one or more segment list fields, each of the one or more segment list fields including a block identifier and one or more C-SIDs; the first C-SID is included in a first segment list field in the one or more segment list fields, and the first segment list includes a second block identifier and at least one C-SID corresponding to the second block identifier before the first C-SID; The first node is configured to update the DA field of the first message when the first C-SID has a first attribute; wherein, the first attribute is configured to indicate that the first C-SID is followed by a C-SID corresponding to a new block identifier, and the updated DA field includes the second block identifier and at least one C-SID corresponding to the second block identifier; The first node is also configured to forward a first message including the updated DA field based on the updated DA field.

11. A communication device, characterized in that, The communication device includes: a processor and a memory; The memory is used to store computer execution instructions, which, when executed by the processor, cause the communication device to perform the method as described in any one of claims 1-6 or 7-9.

12. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a computer, causes the computer to perform the method as described in any one of claims 1-6 or 7-9.

Images