Method and device for processing binding segment identifier

Abstract

The embodiment of the application provides a processing method and device for binding segment identification, the method comprises the following steps: a network device receives a message sent by a controller, the message comprises type information and segment identification, the type information is used for indicating that the segment identification is a binding segment identification BSID; the network device performs a processing action on the BSID according to the type information. By adopting the embodiment of the application, the network device can identify the BSID, and the technical problem that an error processing result is caused when the segment identification list of the network device comprises the BSID can be solved.

Description

[0001] This application is a divisional application of the application filed with the China National Intellectual Property Administration on May 28, 2020, with application number 202010470237.1 and invention title "Processing Method and Device for Binding Segment Identifier". Technical Field

[0002] This invention relates to the field of communication technology, and in particular to a method and device for processing segment identifiers bound in a segment routing strategy. Background Technology

[0003] Segment routing (SR) is a protocol designed based on the concept of source routing to control the forwarding of data packets in a network. SR divides the network path into segments, assigns segment identifiers to these segments or nodes, and allows data packets to be transmitted along the forwarding path indicated by the segment identifiers by carrying sequentially arranged segment identifiers in the data packets. In an SR network, the forwarding path of the data packet is explicitly specified by inserting a set of ordered segment identifiers into the data packet through the ingress device of the segment routing network; this ingress device can also be called the head node. When SR is applied to the Internet Protocol Version 6 (IPv6) data plane, it is called IPv6-based segment routing (SRv6). When SR is applied to the Multi-Protocol Label Switching (MPLS) data plane, it is called MPLS-based segment routing (SR-MPLS).

[0004] A segment ID (SID) represents a service provided by a node, a link, or a network device. In SRv6, the SID is a 128-bit value; in SR-MPLS, it is a label value. An SRv6 segment ID may include a functional part that instructs the network device that issued the segment ID to perform a corresponding action. For any node in an SR network, it may include an Endpoint Layer 3 Cross-Connect SID (End.X SID, where End stands for endpoint and X stands for crossing, and SID stands for segment ID) or at least one corresponding node endpoint segment ID (End SID, where End stands for endpoint and SID stands for segment ID). The End.X SID identifies a directly connected IP layer link to the node, while the End SID identifies the node itself.

[0005] Segment ID List (SID list): This is a list containing a set of segment IDs. After receiving a packet, the header node can explicitly indicate a forwarding path by inserting one SID from the SID list into the packet.

[0006] A binding segment ID (BSID) is a special type of SID. A BSID can correspond to a list of SIDs, indicating a forwarding path. This list of SIDs includes one or more SIDs. A BSID can be included in a list of SIDs.

[0007] In some cases, when a network device's segment identifier list includes a BSID, the network device may be unable to identify which SID in the list is the BSID, leading to incorrect or unreasonable processing of the BSID and resulting in erroneous results.

[0008] In summary, how to avoid errors that may occur when the segment identifier list of a network device includes a BSID is a technical problem that urgently needs to be addressed by those skilled in the art. Summary of the Invention

[0009] This application discloses a method and device for processing bound segment identifiers, which solves the technical problem of incorrect processing results caused when the segment identifier list of a network device includes a BSID.

[0010] Firstly, this application provides a method for processing a binding segment identifier, the method comprising:

[0011] The network device receives a message sent by the controller, which includes type information and a segment identifier. The type information indicates that the segment identifier is a bound segment identifier (BSID). The network device then performs processing actions on the BSID based on the type information. Optionally, the message can be a border gateway protocol (BGP) message or a path computation element protocol (PCEP) message, etc.

[0012] In this application, by specifying the type of BSID in the message, the network device can identify the BSID and then process the BSID according to the corresponding processing action, thereby avoiding erroneous processing results caused by incorrect or unreasonable processing due to the inability to identify the BSID.

[0013] In one possible implementation, the message includes type information, specifically: the Type field in the message includes the type information.

[0014] By defining a new type for BSID and directly including this type information in the type field of the transmitted message, network devices can quickly determine whether the segment identifier is a bound segment identifier.

[0015] In one possible implementation, the message includes type information, specifically: the Flags field in the message includes the type information.

[0016] In one possible implementation, this type of information occupies at least one bit in the Flags field.

[0017] By using at least one bit from the Flags field already included in the message to identify this type of information, the utilization rate of message fields can be improved.

[0018] In one possible implementation, the network device performs processing actions on the BSID based on this type of information, including:

[0019] The network device verifies whether a route to the device indicated by the BSID exists based on this type of information, but does not verify whether the BSID exists in the topology to which the network device belongs;

[0020] Alternatively, the network device may not perform fault verification on the BSID based on this type of information.

[0021] To avoid data forwarding failures due to faults in the forwarding path indicated by the segment identifier list, fault verification can be performed on the segment identifier list. For example, reachability tests can be performed on each SID in the segment identifier list. However, since BSIDs are not flooded in the network, the network device's topology information does not contain BSID-related information. This may cause the network device to consider the SID invalid during fault verification (including verifying the existence of the BSID in the topology), leading to false alarms. Therefore, in this application, by identifying the type of BSID, topology verification or fault verification is not performed for that type of BSID, thereby avoiding such false alarms and enabling rapid data forwarding.

[0022] In one possible implementation, the message further includes a segment identifier (SID), which is a segment identifier of a type other than the BSID, and the method further includes:

[0023] The network device verifies whether a route to the device indicated by the SID exists based on the type of the SID, and also verifies whether the SID exists in the topology to which the network device belongs.

[0024] In this application, the forwarding path indicated by the verification segment identifier list is checked for failure. If there is no failure, the data is forwarded successfully; if there is a failure, the backup forwarding path is switched, thereby ensuring the smooth forwarding of data.

[0025] Secondly, this application provides a method for processing a binding segment identifier, the method comprising:

[0026] The controller generates a message including type information and a segment identifier. The type information indicates that the segment identifier is a bound segment identifier (BSID). The controller sends this message to the network device, instructing the network device to perform a processing action on the BSID based on the type information. Optionally, this message can be a Border Gateway Protocol (BGP) message or a Path Calculation Unit Protocol (PCEP) message, etc.

[0027] In this application, the controller specifies the type of BSID in the sent message, enabling the network device to identify the BSID in the segment routing policy. The device can then process the BSID according to the corresponding processing action, thereby avoiding erroneous processing results caused by incorrect or unreasonable processing due to the inability to identify the BSID.

[0028] In one possible implementation, the message includes type information, specifically: the Type field in the message includes the type information.

[0029] In one possible implementation, the message includes type information, specifically: the Flags field in the message includes the type information.

[0030] In one possible implementation, this type of information occupies at least one bit in the Flags field.

[0031] Thirdly, this application provides a network device, the device comprising:

[0032] The receiving unit is used to receive messages sent by the controller, the messages including type information and segment identifier, the type information being used to indicate that the segment identifier is a bound segment identifier (BSID); the processing unit is used to perform processing actions on the BSID according to the type information.

[0033] Optionally, the message can be a Border Gateway Protocol (BGP) message or a Path Calculation Unit Communication Protocol (PCEP) message, etc.

[0034] In one possible implementation, the message includes type information, specifically: the Type field in the message includes the type information.

[0035] In one possible implementation, the message includes type information, specifically: the Flags field in the message includes the type information.

[0036] In one possible implementation, this type of information occupies at least one bit in the Flags field.

[0037] In one possible implementation, the processing unit is specifically used for:

[0038] Based on this type of information, verify whether a route to the device indicated by the BSID exists, but do not verify whether the BSID exists in the topology to which the network device belongs; or, based on this type of information, do not perform fault verification on the BSID.

[0039] In one possible implementation, the message further includes a segment identifier (SID), which is a segment identifier of a type other than the BSID. The device further includes a verification unit, configured to verify whether a route to the device indicated by the SID exists based on the type of the SID, and to verify whether the SID exists in the topology to which the network device belongs.

[0040] Fourthly, this application provides a controller, the controller comprising:

[0041] The generation unit is used to generate a message, which includes type information and a segment identifier. The type information is used to indicate that the segment identifier is a bound segment identifier (BSID). The sending unit is used to send the message to the network device, which is used to instruct the network device to perform a processing action on the BSID according to the type information.

[0042] Optionally, the message can be a Border Gateway Protocol (BGP) message or a Path Calculation Unit Communication Protocol (PCEP) message, etc.

[0043] In one possible implementation, the message includes type information, specifically: the Type field in the message includes the type information.

[0044] In one possible implementation, the message includes type information, specifically: the Flags field in the message includes the type information.

[0045] In one possible implementation, this type of information occupies at least one bit in the Flags field.

[0046] Fifthly, this application provides a network device, which includes a processor, a communication interface, and a memory, wherein the memory is used to store computer programs and / or data, and the processor is used to execute the computer programs stored in the memory to perform the following operations:

[0047] The communication interface receives messages sent by the controller, which include type information and a segment identifier. The type information indicates that the segment identifier is a bound segment identifier (BSID). Based on this type information, processing actions are performed on the BSID. Optionally, the message can be a Border Gateway Protocol (BGP) message or a Path Calculation Unit Communication Protocol (PCEP) message, etc.

[0048] In one possible implementation, the message includes type information, specifically: the Type field in the message includes the type information.

[0049] In one possible implementation, the message includes type information, specifically: the Flags field in the message includes the type information.

[0050] In one possible implementation, this type of information occupies at least one bit in the Flags field.

[0051] In one possible implementation, the processing action performed on the BSID based on the type information specifically includes:

[0052] Based on this type of information, verify whether a route to the device indicated by the BSID exists, but do not verify whether the BSID exists in the topology to which the network device belongs; or, based on this type of information, do not perform fault verification on the BSID.

[0053] In one possible implementation, the message also includes a segment identifier (SID), which is a segment identifier of a type other than the BSID. The processor is further configured to perform the following operations:

[0054] The system checks whether a route to the device indicated by the SID exists based on the SID type, and also checks whether the SID exists in the topology to which the network device belongs.

[0055] Sixthly, this application provides a controller including a processor, a communication interface, and a memory, the memory for storing computer programs and / or data, and the processor for executing the computer programs stored in the memory to perform the following operations:

[0056] A message is generated, including type information and a segment identifier. The type information indicates that the segment identifier is a bound segment identifier (BSID). This message is then sent to the network device through the communication interface, instructing the network device to perform processing actions on the BSID based on the type information. Optionally, this message can be a Border Gateway Protocol (BGP) message or a Path Calculation Unit Protocol (PCEP) message, etc.

[0057] In one possible implementation, the message includes type information, specifically: the Type field in the message includes the type information.

[0058] In one possible implementation, the message includes type information, specifically: the Flags field in the message includes the type information.

[0059] In one possible implementation, this type of information occupies at least one bit in the Flags field.

[0060] In a seventh aspect, this application provides a computer-readable storage medium storing a computer program that is executed by a processor to implement the method described in any of the first aspects above; or, the computer program is executed by a processor to implement the method described in any of the second aspects above.

[0061] Eighthly, this application provides a computer program product that, when read and executed by a computer, executes the method described in any of the first aspects above; or, when read and executed by a computer, executes the method described in any of the second aspects above.

[0062] Ninthly, this application provides a computer program that, when executed on a computer, causes the computer to implement the method described in any of the first aspects above; or, when executed on a computer, causes the computer to implement the method described in any of the second aspects above.

[0063] In a tenth aspect, this application provides a processing system for binding segment identifiers, the system comprising a network device and a controller, wherein the network device is the network device described in any of the third aspects above, and the controller is the controller described in any of the fourth aspects above; or, the network device is the network device described in any of the fifth aspects above, and the controller is the controller described in any of the sixth aspects above.

[0064] In summary, this application enables network devices to identify the BSID in segment routing policies by specifying the BSID type in the sent message. This allows them to process the BSID according to the corresponding type, thereby avoiding erroneous or unreasonable processing results caused by the inability to identify the BSID. Attached Figure Description

[0065] The accompanying drawings used in the embodiments of this application will be described below.

[0066] Figure 1 The image shown is a schematic diagram of a scenario provided by an embodiment of this application;

[0067] Figure 2The diagram shown is a flowchart illustrating a method for processing a binding segment identifier according to an embodiment of this application.

[0068] Figure 3 The diagram shows a structure for encapsulating data in a message.

[0069] Figure 4 The diagram shows a different structure for encapsulating data in a message.

[0070] Figure 5 The diagram shown illustrates another type of data encapsulation structure in a message.

[0071] Figure 6 The diagram shows a different structure for encapsulating data in a message.

[0072] Figure 7 The diagram shows a different structure for encapsulating data in a message.

[0073] Figure 8 The diagram shows a different structure for encapsulating data in a message.

[0074] Figure 9 The diagram shows a different structure for encapsulating data in a message.

[0075] Figure 10 The image shows a schematic diagram of the structure of a tag field in a message;

[0076] Figure 11 The diagram shown is a structural schematic of another marker field in a message provided in an embodiment of this application;

[0077] Figure 12 A schematic diagram of an SR network structure provided in an embodiment of this application;

[0078] Figure 13 This is a schematic diagram of the logical structure of the network device provided in this embodiment of the solution;

[0079] Figure 14 A schematic diagram of the logic structure of the controller provided in this embodiment of the solution;

[0080] Figure 15 This is a schematic diagram of the hardware structure of the network device provided in this embodiment of the solution;

[0081] Figure 16 This is a schematic diagram of the hardware structure of the controller provided in this embodiment of the solution. Detailed Implementation

[0082] The embodiments of this application will now be described with reference to the accompanying drawings.

[0083] Figure 1The illustration shows a possible application scenario of the binding segment identifier processing method provided in this application embodiment, which is a scenario of forwarding data across autonomous systems (AS).

[0084] Figure 1 The scenario shown can be a segment routing (SR) network, which may include a controller 110, an autonomous system 120, and an autonomous system 130. Autonomous system 120 includes multiple network devices, such as network devices 121, 122, and 123. Autonomous system 130 also includes multiple network devices, such as network devices 131, 132, 133, 134, and 135. Network device 123 in autonomous system 120 and network device 131 in autonomous system 130 are boundary devices, such as autonomous system boundary routers (ASBRs).

[0085] The controller 110 can communicate with network devices via the Border Gateway Protocol (BGP) or the Path Computation Element Protocol (PCEP). Then, the controller 110 can use the PCEP to calculate data forwarding paths for the network devices in the autonomous system and send the calculated paths to the network devices.

[0086] Network devices in an autonomous system can forward packets based on the forwarding path provided by controller 110. Optionally, the network devices can be switches or routers, etc. These network devices can also be called path computation clients (PCCs).

[0087] Figure 1 The illustration shows a communication connection established between controller 110 and network device 121 in autonomous system 120, and a communication connection established between controller 110 and network device 131 in autonomous system 130. Assuming network device 121 is the head node for data forwarding, controller 110 sends the data forwarding path to network device 121.

[0088] It should be noted that the data forwarding path sent by controller 110 can be represented by a segment ID list (SID list). The segment ID list can include multiple segment IDs. These SIDs can include identifiers for various segment types, such as SIDs based on Multiprotocol Label Switching (MPLS), Internet Protocol version 4 (IPv4), or Internet Protocol version 6 (IPv6), etc.

[0089] because Figure 1 The diagram illustrates a cross-AS scenario. To ensure successful packet forwarding to Autonomous System 130, the controller sends a segment identifier list to network device 121 that includes a bound segment identifier (BSID). This BSID is bound to the segment identifier list of the forwarding path in Autonomous System 130. When network device 123 forwards data to network device 131, network device 131 can find the bound segment identifier list based on the bound segment identifier BSID, thus enabling it to continue forwarding data. The bound segment identifier can also be referred to as a binding tag, etc.

[0090] The possible application scenarios of the binding segment identifier processing method provided in this application embodiment can also include scenarios where the forwarding path is too long within the same AS. In this case, the forwarding path can be divided into several parts, and a BSID is used to connect the paths of the two adjacent parts. For example, assuming the forwarding path is divided into a first part and a second part, there is a BSID between the forwarding paths of these two parts. This BSID can be bound to the forwarding path of the second part. When data is forwarded to the first network device on the second part path, the network device can find the forwarding path of the second part based on the BSID and then continue to forward the packet.

[0091] The application scenarios of the binding segment identifier processing method provided in this application are not limited to the above scenarios. All scenarios in which the binding segment identifier processing method provided in this application can be applied are within the protection scope of this application.

[0092] The following describes a method for processing a binding segment identifier according to an embodiment of this application. This method can be applied to any of the scenarios described above. See also Figure 2 This method may include, but is not limited to, the following steps:

[0093] S201. The controller generates a message that includes type information and a segment identifier. The type information is used to indicate that the segment identifier is a bound segment identifier (BSID).

[0094] Optionally, the messages generated by the controller can be Border Gateway Protocol (BGP) messages or Path Calculation Unit Communication Protocol (PCEP) messages, etc.

[0095] Specifically, the aforementioned BSID is used to bind a segment identifier list corresponding to a forwarding path. This design reduces the length of the label stack, thus solving the problem in cross-AS scenarios or when the forwarding path is long, where the depth of the segment identifier list exceeds the list depth supported by the network device, resulting in a single segment identifier list being unable to carry all identifiers. In other words, through the BSID, data packets can be successfully forwarded according to the planned forwarding path in cross-AS scenarios or scenarios with long forwarding paths. For example, in cross-AS scenarios, the BSID is used to connect the forwarding paths between two ASs; that is, the BSID can hide the specific content of each SID in a segment identifier list. As another example, in scenarios with long forwarding paths, where the forwarding path is divided into two segments, the BSID is used to represent the segment identifier list corresponding to a certain segment of the forwarding path.

[0096] The planned forwarding path includes the aforementioned segment identifier list or segment-routing policy (SR Policy). For scenarios spanning multiple ASs (or with long forwarding paths), assuming the scenario includes a first AS (or the first forwarding path) and a second AS (or the second forwarding path), the forwarding path within the first AS (or the first forwarding path) is the first path, and the forwarding path within the second AS (or the second forwarding path) is the second path. A BSID can be configured for the second path. The controller can send an SR Policy to the head node in the first AS, which includes the BSID. Within the SR Policy, the BSID can be considered the SID of a network device. In the second AS, this BSID corresponds to a specific forwarding path. When the head node of the first AS receives the relevant data packet, it will include a segment identifier list in the data packet according to the aforementioned SRPolicy. This segment identifier list includes the BSID. When the BSID is forwarded with the data to the second AS (or the second forwarding path), the second forwarding path can be found through this BSID, and then the data can be forwarded according to this second forwarding path. It should be noted that when forwarding data, the head node of the data forwarding path will encapsulate the BSID into the data packet header and forward it along with the data. In SRv6, this data packet header can be called the segment routing header (SRH).

[0097] In a specific embodiment, the controller can obtain the network topology of the forwarding plane composed of network devices and plan the data forwarding path based on the information of this network topology.

[0098] In one possible implementation, the controller / PCE calculates the forwarding path for data packets based on a path calculation request sent by the network device. This path calculation request may include information such as the destination address for data forwarding. After calculating the forwarding path, the controller can send the calculated forwarding path or path selection policy information to the network device in the form of an SR Policy or a segment identifier list. Specifically, the controller encapsulates these SR Policies or segment identifier lists into a message and then sends this message to the network device. The message encapsulated by the controller may be a BGP message or a PCEP message.

[0099] Alternatively, in another possible implementation, the controller can plan and calculate the forwarding paths from network devices to each destination address based on existing network topology information. These forwarding paths are then represented by a segment identifier list, which is encapsulated into a packet and sent to the network device.

[0100] The aforementioned segment identifier list includes one or more segment identifiers (SIDs). SIDs can include SIDs used to identify network devices and SIDs used to identify links between two network devices. For scenarios involving cross-AS or long forwarding paths, the segment identifier list may also include bound segment identifiers (BSIDs).

[0101] In another possible implementation, for scenarios involving long cross-AS or forwarding paths, the controller can generate a separate message to send the BSID when sending it to the network device. This message contains a segment identifier list that only includes the BSID. Alternatively, the BSID can be sent in a message along with other SIDs, but the segment identifier list in that message may not be a complete SR Policy; instead, it may contain only a subset of the SIDs included in the SR Policy.

[0102] Specifically, when the controller sends a message containing a list of segment identifiers to the network device, it encapsulates the message according to a preset format, such as the TLV format. A TLV is a structure consisting of a data type (Tag), a data length (Length), and a data value (Value), which can describe almost any data type.

[0103] The value of a TLV can also be a TLV structure. Because of this nested nature, it can be used to wrap protocol implementations. Therefore, the SID value included in the segment identifier list of a message generated by the controller can be a nested TLV structure (a nested TLV can also be called a sub-TLV). It should be noted that SID values ​​of the same type can be encapsulated in one sub-TLV structure, while SID values ​​of different types can be encapsulated in different sub-TLV structures.

[0104] For example, suppose the identifier list includes two SIDs of different types. The message encapsulating this identifier list is a TLV structure. For the values ​​of the two SIDs, each value can be encapsulated as a sub-TLV structure. Therefore, the message with this TLV structure contains two nested sub-TLV structures.

[0105] For example, suppose the identifier list includes two SIDs of the same type and one BSID of a different type. The message encapsulating this identifier list is a TLV structure. The values ​​of the two SIDs of the same type can be encapsulated in a sub-TLV structure. The BSID can be encapsulated in a separate sub-TLV. Therefore, the message containing the three identifiers in the TLV structure has two nested sub-TLV structures.

[0106] To facilitate understanding the structure of the sub-TLV, the following will combine... Figure 3 , Figure 4 , Figure 5 , Figure 6 and Figure 7 Exemplary introduction.

[0107] Figure 3 The diagram shows the structure of a sub-TLV encapsulating an MPLS-based SID. This MPLS-based SID can be... As you can see, the sub-TLV structure consists of the following parts:

[0108] Type: Here, "Type" refers to the segment type of the SID. The draft segment routing policy published by the Internet Engineering Task Force (IETF) defines 11 segment types. These 11 segment types are represented by 1, 2, 3, 4, 5, 6, 7, 9, 10, 11, and 12, meaning each of these 11 values ​​represents a segment type. Alternatively, these 11 segment types are represented by A, B, C, D, E, F, G, H, I, J, and K, meaning each of these 11 letters represents a segment type. Segment types 1, 2, 3, 4, 5, 6, 7, 9, 10, 11, and 12 correspond one-to-one with segment types A, B, C, D, E, F, G, H, I, J, and K, respectively; that is, type A is type 1, type B is type 2, and so on. For this MPLS label format SID, its segment type is A. So, when encapsulating the SID in this MPLS tag format, the Figure 3 The value of the Type field in the sub-TLV shown is 1.

[0109] Length: This refers to the number of bytes occupied by the value of the label in the sub-TLV, which can be 6 bytes.

[0110] Flags: Flags are used to define necessary operations or restrictions, etc.

[0111] Reserved RESERVED: RESERVED is a reserved field. It is set to 0 when sending and can be ignored when receiving.

[0112] Label: The value of the Label field is the specific MPLS label value, and this field can occupy 20 characters.

[0113] Traffic control (TC): TC can be used to define traffic types and can occupy 3 bits.

[0114] Stack bottom identifier S: The stack bottom identifier occupies 1 bit.

[0115] Time-to-Live (TTL): Defines the number of network devices through which this sub-TLV can be forwarded, and can occupy 1 byte.

[0116] Figure 4 The diagram shows the structure of a sub-TLV that encapsulates an IPv6 address formatted SID. As can be seen, this sub-TLV consists of the following parts:

[0117] Type: Similarly, here Type refers to the segment type of the SID. For this IPv6 address format SID, its segment type is B. Therefore, when encapsulating this IPv6 address format SID, the... Figure 4 The value of the Type field in the sub-TLV shown is 2.

[0118] Length: Here, Length refers to the number of bytes occupied by the SID value in the IPv6 address format in the sub-TLV, which can be 18 bytes.

[0119] Flags: Flags are used to define necessary operations or restrictions, etc.

[0120] Reserved RESERVED: RESERVED is a reserved field. It is set to 0 when sending and can be ignored when receiving.

[0121] In IPv6-based SR networks, the segment route identifier SRv6 SID is a field containing the specific IPv6-based SID value, which can occupy 16 bytes.

[0122] Figure 5 The diagram shows the structure of a sub-TLV that encapsulates an IPv4 address format SID with an optional MPLS label format SID. As can be seen, this sub-TLV consists of the following parts:

[0123] Type: Similarly, Type here refers to the segment type of the SID. For an IPv4 address format SID with an optional MPLS label format SID, its segment type is C. Therefore, when encapsulating this IPv4 address format SID with an optional MPLS label format SID, the... Figure 5 The value of the Type field in the sub-TLV shown is 3.

[0124] Length: Length refers to the number of bytes occupied by the SID value in the sub-TLV, which can be 6 bytes or 10 bytes.

[0125] Flags: Flags are used to define necessary operations or restrictions, etc.

[0126] Segment routing algorithm (SR Algorithm): The algorithm used to indicate the association of SIDs.

[0127] IPv4 Node Address: Used to identify a node (i.e., a network device).

[0128] SR-MPLS SID: This is an optional field with a length of 4 bytes. The format of this SID is the same as the tag format of segment type A.

[0129] Figure 6 The diagram shows the structure of a sub-TLV that encapsulates an IPv6 address format SID with an optional MPLS label format SID. As can be seen, this sub-TLV consists of the following parts:

[0130] Type: Here, Type refers to the segment type of the SID. For an IPv6 address format SID with an optional MPLS label format SID, its segment type is D. Therefore, when encapsulating this IPv6 address format SID with an optional MPLS label format SID, the... Figure 6 The value of the Type field in the sub-TLV shown is 4.

[0131] Length: Here, Length refers to the number of bytes occupied by the SID value in the sub-TLV, which can be 18 bytes or 22 bytes.

[0132] Flags: Flags are used to define necessary operations or restrictions, etc.

[0133] Segment routing algorithm (SR Algorithm): The algorithm used to indicate the association of SIDs.

[0134] IPv4 Node Address: Used to identify a node (i.e., a network device).

[0135] SR-MPLS SID: This is an optional field with a length of 4 bytes. The format of this SID is the same as the tag format of segment type A.

[0136] Figure 7 The diagram shows the structure of a sub-TLV that encapsulates an IPv6 address format SID plus an optional SRv6 SID. As can be seen, this sub-TLV consists of the following parts:

[0137] Type: Similarly, Type here refers to the segment type of the SID. For an IPv6 address format SID with an optional SRv6 SID, its segment type is I. Therefore, when encapsulating this IPv6 address format SID with an optional SRv6 SID, the... Figure 7 The value of the Type field in the sub-TLV shown is 10.

[0138] Length: Here, Length refers to the number of bytes occupied by the SID value in the sub-TLV, which can be 18 bytes or 34 bytes.

[0139] Flags: Flags are used to define necessary operations or restrictions, etc.

[0140] Segment routing algorithm (SR Algorithm): The algorithm used to indicate the association of SIDs.

[0141] IPv4 Node Address: Used to identify a node (i.e., a network device).

[0142] SRv6 SID: Optional field, IPv6 address format, can be used to identify a node or link, with a length of 16 bytes.

[0143] It should be noted that the above structure is mainly an example of a BGP message. The sub-TLV structure encapsulating the SID in the message is not limited to the structure described above. Other sub-TLV structures also exist. For example, it can also be a sub-TLV structure for encapsulating the SID generated based on the PCEP protocol. Please refer to [link to relevant documentation]. Figure 8 and Figure 9 .

[0144] Figure 8 The diagram shows the structure of an explicit route object (ERO) or a route record object (SR-RRO) defined in the PCEP protocol. The explicit route object can be called an SR-ERO sub-object, and the route record object can be called an SR-RRO sub-object. These SR-ERO and SR-RRO sub-objects can be used to carry path information related to subsection routing traffic engineering (SR-TE) or SR Policy. Figure 8 As can be seen, the structure of the SR-ERO sub-object or SR-RRO sub-object is actually the structure of a sub-TLV. The meaning of each field in the sub-TLV structure can be found in Table 1.

[0145] Table 1

[0146]

[0147]

[0148] Figure 9 The image shows an SRv6-ERO or SRv6-RRO sub-object defined in the PCEP protocol, used to carry SRv6 path information. Figure 9As can be seen, the structure of the SRv6-ERO sub-object or the SRv6-RRO sub-object is actually the structure of a sub-TLV. The meaning of each field in the sub-TLV structure can be found in Table 2.

[0149] Table 2

[0150]

[0151] In specific embodiments, the sub-TLV structure encapsulating the SID in the above message is not limited to the structure described above. The specific sub-TLV structure used is determined according to actual needs, and this solution does not impose any restrictions on it.

[0152] As described above, the messages sent by the controller to the network device carry the segment type of the SID. The network device can identify the SID through the segment type to perform different processing on SIDs of different segment types. However, when the message includes the BSID, since the segment type of the BSID is not defined in the prior art, the network device may fail to identify the BSID in some cases, resulting in incorrect processing of the BSID.

[0153] For example, to prevent data from failing to forward due to a fault in the forwarding path indicated by the segment identifier list, network devices can perform fault verification using the identifiers in the received segment identifier list. If the segment identifier list includes a BSID, since the BSID is not explicitly defined and is not flooded in the SR network topology (meaning it does not exist in other network devices within the SR network topology), the network device may mistakenly identify the BSID as invalid during fault verification, leading to a false fault report.

[0154] To address the aforementioned issues, in this embodiment of the application, when the controller sends a message to the network device, if the segment identifier list of the message includes a BSID, the type of the BSID is explicitly indicated in the message. That is, the message includes specific type information and a segment identifier. The specific type information is used to indicate that the segment identifier is a bound segment identifier BSID. This can be implemented through a nested sub-TLV structure.

[0155] In one possible implementation, the sub-TLV structure encapsulating the BSID can be Figure 3 , Figure 4 , Figure 5 , Figure 6 or Figure 7 The structure shown in this example primarily represents a BGP protocol message. The sub-TLV encapsulating the BSID can also be a sub-TLV structure generated based on the PCEP protocol for encapsulating the BSID, such as the one described above. Figure 8 and Figure 9The structure shown, etc. However, the value in the Type field of the sub-TLV structure is a value indicating the type of the BSID.

[0156] For example, for Figure 3 , Figure 4 , Figure 5 , Figure 6 or Figure 7 The structure shown allows the BSID type value to be any type other than the 11 segment types defined in the IETF's draft segment routing policy, such as 13, 14, or 15. In this case, the segment types corresponding to 13, 14, and 15 could be segment type L, segment type M, and segment type N, respectively.

[0157] For example, for Figure 8 and Figure 9 As shown in the structure, the value of the BSID type can be any type value other than the segment types currently defined in the PCEP protocol.

[0158] This is just an example showing the types of BSIDs and their corresponding values. However, the types of BSIDs and their corresponding values ​​are not limited to those listed here; other types and values ​​are also possible. It should be noted that network devices in an SR network can recognize the type of this BSID and process the corresponding BSID according to preset rules.

[0159] In another possible implementation, the sub-TLV structure encapsulating the BSID can be Figure 3 , Figure 4 , Figure 5 , Figure 6 or Figure 7 The structure shown in this example primarily represents a BGP protocol message. The sub-TLV encapsulating the BSID can also be a sub-TLV structure generated based on the PCEP protocol for encapsulating the BSID, such as the one described above. Figure 8 and Figure 9 The structure shown is as follows. However, in this embodiment, the type of BSID is not indicated by the Type field in the sub-TLV structure, but rather by occupying a preset number of bits in the Flags field of the sub-TLV structure.

[0160] for Figure 3 , Figure 4 , Figure 5 , Figure 6 or Figure 7 The structure shown illustrates how the type of BSID is defined by occupying a preset number of bits in the Flags field of the sub-TLV structure. For a detailed description, please refer to [link to relevant documentation]. Figure 10 and Figure 11 .

[0161] See Figure 10 , Figure 10 The image shows the prior art. Figure 3 , Figure 4 , Figure 5 , Figure 6 or Figure 7 The structure shown is the Flags field in the sub-TLV structure. As you can see, the Flags field occupies 1 byte (8 bits). Figure 10 The `Flags` field only occupies two bits to define two flags. The first flag, `V`, indicates whether the identifier in this sub-TLV structure undergoes local verification. For example, if this bit is 1, local verification is performed; if it is 0, local verification is not performed. The second flag, `A`, is used to mark the algorithm. Some SIDs have built-in algorithms, and this bit can be used to mark the algorithm associated with the SID.

[0162] See Figure 11 , Figure 11 The structure of the Flags field in the sub-TLV structure provided in this application embodiment is illustrated by way of example. Figure 11 exist Figure 10 The third bit is used to identify the BSID type, and this bit can be represented by the character "B". Optionally, the BSID type identifier is not limited to one bit; it can occupy more than one bit. Furthermore, the BSID type identifier is not limited to the character "B"; other characters can be used, such as "BS" or "BSID". When the BSID type identifier is set to 1, it indicates that the value in this sub-TLV structure is a BSID. It should be noted that network devices in an SR network can recognize the BSID type value and process the corresponding BSID according to preset rules based on this type.

[0163] for Figure 8 or Figure 9 The structure shown is in Figure 8 As can be seen, the existing Flags field includes F, S, C, and M flags; Figure 9 As can be seen, the existing Flags field includes F and S flags. Therefore, in this embodiment, the occupancy can be configured. Figure 8 or Figure 9In the Flags field of the structure shown, one or more undefined bits are used to indicate the type of BSID, which can be represented by the character B. The BSID type identifier is not limited to the character B; other characters can also be used, such as BS or BSID. When the BSID type identifier is set to 1, it indicates that the value in this sub-TLV structure is a BSID. It should be noted that network devices in the SR network can recognize the value of this BSID type and process the corresponding BSID according to preset rules.

[0164] Optionally, the BSID type can also be defined in other fields of the sub-TLV structure encapsulating the BSID, such as RESERVED or NT, or in a specific field of the message.

[0165] Furthermore, the sub-TLV structure encapsulating the BSID is not limited to Figure 3 , Figure 4 , Figure 5 , Figure 6 , Figure 7 , Figure 8 and Figure 9 The structure shown may also contain other sub-TLV structures, in which the type of BSID can also be indicated. This scheme does not impose any restrictions on this.

[0166] It should be noted that the above definition of the type of binding segment identifier BSID and the related processing of BSID can be formulated into a standard through relevant protocols (such as the IETF draft protocol on segment routing policy or the PCEP protocol). Then, devices in the SR network can identify the BSID based on the protocol and process the BSID based on the protocol.

[0167] To facilitate understanding of the above list of segment identifiers, the following section will combine... Figure 12 For example.

[0168] Figure 12 The diagram shows an SR network spanning multiple autonomous systems. Figure 12 The network shown is Figure 1 The network shown is the same as the one described above. Figure 1 The description applies to Figure 12 In this SR network, assuming network device 121 is the head node for data forwarding and network device 134 is the destination node for data forwarding, the data forwarding path calculated by controller 110 based on the head node and destination node is: network device 121-network device 122-network device 123-network device 131-network device 135-network device 134.

[0169] in addition, Figure 12The example below illustrates an IPv6-based SR network (SRv6). Figure 12 As can be seen, each network device is configured with an SRv6-based SID. These SIDs can be the addresses of the corresponding network devices, serving a location function. Each SID can typically uniquely identify a network device within the SR network. Each network device's SID can be configured by the controller and sent to the corresponding network device. The network device then floods its own SID to other network devices. Upon receiving the flooded SID, other network devices store it for subsequent processing, such as redirecting traffic during data forwarding.

[0170] It should be noted that network devices continuously flood their own SIDs within the SR network, and other network devices in the SR network update the received SIDs after each flood. However, when a network device becomes unreachable, for example, due to a failure, other network devices will no longer receive the flooded SIDs of that particular network device. Therefore, after updating the received SIDs, the other network devices will no longer store the SID of that particular network device.

[0171] After the controller 110 calculates the data forwarding path, it can use the SIDs of the network devices in that forwarding path to represent the path. The SIDs of the network devices in that forwarding path form a segment identifier list. Because... Figure 12 The diagram shows a cross-autonomous system (AS) SR network. Therefore, the forwarding path can be divided into two segments: the first segment is the forwarding path within AS 120, i.e., network device 121-network device 122-network device 123; the second segment is the forwarding path within AS 130, i.e., network device 131-network device 135-network device 134. To connect these two forwarding paths, the second segment can be bound by a segment identifier (BSID), and the BSID in the first segment can be used as the SID of a network device.

[0172] Based on the above description and combination Figure 12The SIDs of the network devices shown can be used to obtain the segment identifier list of the first forwarding path as {2::100, 3::200, 4::400}, and the segment identifier list of the second forwarding path as {4::800, 5::300, 6::500}. Then, controller 110 encapsulates the segment identifier list {2::100, 3::200, 4::400} into a message and sends this message to the head node of the first forwarding path, i.e., network device 121. Controller 110 encapsulates the segment identifier list {4::800, 5::300, 6::500} into a message and sends this message to the head node of the second forwarding path, i.e., network device 131. Of course, these two messages include information about the types of each SID and BSID. The specific message encapsulation structure can be found in the preceding description and will not be repeated here.

[0173] S202, The controller sends the above message to the network device.

[0174] Based on the above description, after the controller generates a message including the BSID and the type information of the BSID, it sends the message to the corresponding network device.

[0175] The controller can send messages to network devices via the PCEP or BGP protocols.

[0176] S203. The network device receives the message.

[0177] S204. The network device performs processing actions on the BSID based on the type information in the message.

[0178] The network device performs processing actions on the BSID based on the type information of the message. This can be understood as the network device performing corresponding processing actions after obtaining the segment identifier as a BSID based on the type information.

[0179] Optionally, the processing action is the action obtained from the type mapping of the BSID.

[0180] Optionally, this processing action can also be the default action executed when a segment identifier is confirmed to be a bound segment identifier. This default action can be an action determined at the factory of the network device, or an action configured in advance by the network device from the controller or network management device, or by the administrator through the management interface.

[0181] Based on the above description, the network device receives the aforementioned message sent by the controller. This network device can be a head node in a forwarding path, for example, it could be... Figure 12The network device 121, etc., described above. Then, the network device parses the packet to obtain the segment identifier list in the packet, as well as the type information of each SID and BSID in the segment identifier list. The network device can identify the specific type of each SID and BSID through this type information. Since different types of identifiers have their own associated mappings and corresponding processing actions, after identifying the different types of identifiers, the network device processes each type of identifier according to the processing actions corresponding to its type mapping.

[0182] For example, if the type information of a SID is 1, it indicates that the SID is an MPLS-based label; or, if the type information of a SID is 2, it indicates that the SID is an IPv6-based address; or, if the type information of a SID is 12, it indicates that the SID is a Binding Segment Identifier (BSID). This is just an example; the specific type information of the SID in the message and the corresponding content are determined according to the specific circumstances, and this scheme does not impose any restrictions on this.

[0183] The following example illustrates how a network device performs fault verification using segment identifiers to prevent data from failing to forward due to a fault in the forwarding path indicated by the segment identifier list. This example demonstrates how the network device, after identifying the types of SID and BSID in the above message, processes the SID and BSID according to the processing actions obtained by mapping the types of the SID and BSID.

[0184] The aforementioned network devices can perform fault verification using segment identifiers from the received segment identifier list. This fault verification can be divided into two parts:

[0185] Topology verification: The verification segment indicates whether the network device exists in the network topology.

[0186] Route verification: Verifies whether a route exists from this network device to the device indicated by the segment identifier.

[0187] In this embodiment, since BSIDs are not flooded in the network, they do not exist in the network topology. However, this does not affect normal data forwarding in the network. Therefore, during fault verification, if the existence of the BSID in the topology is checked, a false alarm will be triggered because the BSID does not exist in the topology. Therefore, to avoid false alarms, the processing action for BSID type association mapping is: only route verification is performed on the BSID type identifier, without topology verification. Alternatively, the processing action for BSID type association mapping is: no fault verification is performed on the BSID type identifier. The processing action for non-BSID type association mapping is: route verification and topology verification are performed on the non-BSID type identifier.

[0188] The aforementioned BSID does not exist in the network topology, including cases where the network device obtains the network topology based on BGP or Interior Gateway Protocol (IGP) and the BSID is not included in the network topology. This network topology includes a Layer 3 network topology.

[0189] Therefore, after identifying the BSID and other types of SIDs included in the segment identifier list, the network device only performs the aforementioned route verification on the BSID, omitting the aforementioned topology verification or fault verification. For the other types of SIDs, both topology and route verification are performed. In this example, by identifying the type of BSID and omitting topology or fault verification for that type of BSID, false alarms are avoided, and data forwarding is quickly achieved.

[0190] For ease of understanding, let's combine the above... Figure 12 Example Explanation. Based on the foregoing description, network device 121 receives a message from controller 110 containing a segment identifier list {2::100, 3::200, 4::400}. Network device 121 identifies identifiers 2::100 and 3::200 as IPv6-based address type identifiers, and 4::400 as a binding segment identifier (BSID), based on the type information of each identifier in the message. Then, network device 121 verifies whether identifiers 2::100 and 3::200 exist in the network topology to which network device 121 belongs, and verifies whether routes from network device 121 to network device 122 indicated by identifier 2::100 and to network device 123 indicated by identifier 3::200 exist. However, since 4::400 is a binding segment identifier (BSID), network device 121 only verifies whether a route to the network device indicated by 4::400 exists, and does not verify whether 4::400 exists in the network topology to which network device 121 belongs.

[0191] Since identifiers 2::100 and 3::200 are flooded in the network topology in real time, all network devices in the topology store these identifiers when no fault occurs. Therefore, during topology verification, network device 121 only needs to check its own memory for the locations where these flooded identifiers are stored. If they are found, it means that the identifiers 2::100 and 3::200 exist in the network topology, thus confirming that the forwarding path corresponding to the segment identifier list {2::100, 3::200, 4::400} is not faulty. If network device 121 does not find a particular identifier, such as 3::200, it indicates that the forwarding path corresponding to the segment identifier list {2::100, 3::200, 4::400} is faulty. In this case, network device 121 will notify the service to perform a failover, switching to an alternative forwarding path for data forwarding.

[0192] For route verification, it can be performed using the prefix of the identifier (the prefix for identifier 2::100 is 2::, the prefix for identifier 3::200 is 3::, and the prefix for identifier 4::400 is 4::). This embodiment uses the prefix obtained by converting a subnet mask with a length of 64 bits as an example. Figure 12 As can be seen, each network device has a different prefix for its SID, and these prefixes can uniquely identify a network device in an SR network.

[0193] Furthermore, the prefix of any identifier derived or published by a network device is the prefix of the address identifier of that network device. For example, BSID 4::400 is used to bind the segment identifier list of the second forwarding path in the head node network device 131 of the second forwarding path (i.e., the forwarding path in the autonomous system 130 mentioned above). That is, the segment identifier list corresponding to BSID 4::400 can be {8::700, 7::600, 6::500}. For the first forwarding path, BSID 4::400 is the address identifier of network device 131. Therefore, BSID 4::400 can be regarded as an identifier derived from network device 131. Thus, the prefix of BSID 4::400 is the prefix of the address identifier 4::800 of network device 131.

[0194] The address identifier of network device 131 is flooded in real time across the network topology. Therefore, under normal circumstances, other network devices in the network topology store the prefix 4:: of the address identifier of network device 131. Thus, when performing route verification for 4::400, network device 121 only needs to check its own memory for the identifier prefix 4:: in the locations where these IGP or BGP flooded identifiers are stored. If it is found, it means that a route exists from network device 121 to network device 131 indicated by BSID 4::400. If it is not found, it means that a route does not exist from network device 121 to network device 131 indicated by BSID 4::400, indicating a failure in the forwarding path corresponding to segment identifier list {2::100, 3::200, 4::400}. In this case, network device 121 will notify the service to perform a failover, switching to an alternative forwarding path for data forwarding, thereby ensuring successful data forwarding. The route verification process for 2::100 and 3::200 is the same as that for 4::400, and will not be repeated here.

[0195] It should be noted that the BSID type is associated with certain processing actions, so that the network device can perform these processing actions after recognizing the BSID type. This process is not limited to the above-mentioned fault verification scenario, but can also be applied to other scenarios. This solution does not restrict this.

[0196] It should be noted that the above examples are mainly illustrated using IPv6-based SR networks, but the binding segment identifier processing method provided in this application embodiment is also applicable to MPLS-based SR networks.

[0197] In summary, this application enables network devices to identify the BSID in segment routing policies by specifying the BSID type in the sent message. This allows them to process the BSID according to the corresponding type, thereby avoiding erroneous or unreasonable processing results caused by the inability to identify the BSID.

[0198] The foregoing mainly describes the processing method for the binding segment identifier provided in the embodiments of this application. It is understood that each device, in order to achieve the corresponding functions, includes the corresponding hardware structure and / or software module for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the 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 by 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.

[0199] This application embodiment can divide the device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one 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.

[0200] When dividing each function into modules according to its corresponding function. Figure 13 A schematic diagram of a possible logical structure of the device is shown, which can be the network device described above. The network device 1300 includes a receiving unit 1301 and a processing unit 1302. Wherein:

[0201] The receiving unit 1301 is used to receive a message sent by the controller, the message including type information and segment identifier, the type information being used to indicate that the segment identifier is a bound segment identifier BSID;

[0202] The processing unit 1302 is used to perform processing actions on the BSID based on the type information.

[0203] In one possible implementation, the processing unit 1302 is specifically used for:

[0204] Based on this type of information, verify whether a route to the device indicated by the BSID exists, but do not verify whether the BSID exists in the topology to which the network device belongs; or, based on this type of information, do not perform fault verification on the BSID.

[0205] In one possible implementation, the message also includes a segment identifier (SID), which is a segment identifier of a type other than the BSID. The network device 1300 further includes:

[0206] The verification unit is used to verify whether a route to the device indicated by the SID exists based on the type of the SID, and to verify whether the SID exists in the topology to which the network device belongs.

[0207] When dividing each function into modules according to its corresponding function. Figure 14 A schematic diagram of a possible logical structure of the device is shown, which may be the controller described above. The controller 1400 includes a generation unit 1401 and a transmission unit 1402.

[0208] in:

[0209] The generation unit 1401 is used to generate a message, which includes type information and segment identifier. The type information is used to indicate that the segment identifier is a bound segment identifier BSID.

[0210] The sending unit 1402 is used to send the message to the network device.

[0211] Figure 13 and Figure 14 For details on the operation and beneficial effects of each unit in the device shown, please refer to the above. Figure 2 The description of the method embodiment shown will not be repeated here.

[0212] Figure 15 The diagram illustrates a possible hardware structure of the device provided in this application, which can be the network device described in the above method embodiments. The network device 1500 includes a processor 1501, a memory 1502, and a communication interface 1503. The processor 1501, communication interface 1503, and memory 1502 can be interconnected or connected to each other via a bus 1504.

[0213] For example, memory 1502 is used to store computer programs and data of device 1500. Memory 1502 may include, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM). Communication interface 1503 is used to support network device 1500 in communication, such as receiving or sending data.

[0214] For example, processor 1501 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The processor may also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, etc. Processor 1501 can be used to read the program stored in the aforementioned memory 1502 and execute the above-mentioned... Figure 2 And the operations performed by the network device in the method described in possible implementations.

[0215] Figure 16The diagram shows a possible hardware structure of the device provided in this application, which can be the controller described in the above method embodiments. The controller 1600 includes a processor 1601, a memory 1602, and a communication interface 1603. The processor 1601, the communication interface 1603, and the memory 1602 can be interconnected or interconnected via a bus 1604.

[0216] For example, memory 1602 is used to store computer programs and data of device 1600. Memory 1602 may include, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM). Communication interface 1603 is used to support controller 1600 in communication, such as receiving or sending data.

[0217] For example, processor 1601 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The processor may also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, etc. Processor 1601 can be used to read the program stored in the aforementioned memory 1602 and execute the operations performed by the controller in the aforementioned method.

[0218] This application also provides a processing system for binding segment identifiers, the system including a network device and a controller, wherein the network device is as described above. Figure 2 The network device in the method embodiment, wherein the controller is as described above. Figure 2 The controller described in the method embodiments; or, the network device is the one described above. Figure 13 The network device, wherein the controller is as described above. Figure 14 The controller described above; or, the network device is the aforementioned Figure 15 The network device, wherein the controller is as described above. Figure 16 The aforementioned controller.

[0219] This application also discloses a computer-readable storage medium storing a computer program, which is executed by a processor to implement the above-described embodiments. Figure 2 And the method described in possible implementations.

[0220] This application also discloses a computer program product, which, when read and executed by a computer, [the following...] Figure 2 The method described in possible implementations will be executed.

[0221] This application also discloses a computer program that, when executed on a computer, will cause the computer to perform the above-described functions. Figure 2 And the method described in possible implementations.

[0222] In summary, this application enables network devices to identify the BSID in segment routing policies by specifying the BSID type in the sent message. This allows them to process the BSID according to the corresponding type, thereby avoiding erroneous or unreasonable processing results caused by the inability to identify the BSID.

[0223] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for binding segment identifier announcements, characterized in that, The method includes: The network device receives a message sent by the controller. The message includes a segment identifier list, which includes multiple segment identifiers (SIDs). One or more of the multiple SIDs are carried in a sub-TLV. The sub-TLV contains indication information, which indicates that the one or more SIDs are bound segment identifiers (BSIDs). The segment identifier list is used to display an indication of the forwarding path. The network device stores the segment identifier list and forwards packets according to the segment identifier list.

2. The method according to claim 1, characterized in that, The type of the sub-TLV indicates that the SID is an IPv6-based segmented routing SRv6 SID.

3. The method according to claim 1 or 2, characterized in that, The method further includes: The network device determines, based on the sub-TLV, that it does not need to perform fault verification on the BSID.

4. The method according to claim 1 or 2, characterized in that, The method further includes: The network device verifies whether a route to the BSID exists based on the sub-TLV.

5. The method according to claim 1, characterized in that, The Type field in the message includes indication information.

6. The method according to claim 1, characterized in that, The Flags field in the message includes the indication information.

7. The method according to claim 6, characterized in that, The indication information occupies at least one bit in the Flags field.

8. The method according to claim 1 or 2, characterized in that, The message includes either a Border Gateway Protocol (BGP) message or a Path Calculation Unit Communication Protocol (PCEP) message.

9. A method for processing a bound segment identifier, characterized in that, The method includes: The controller generates a message including a segment identifier list, which includes multiple segment identifiers (SIDs). One or more of the multiple segment identifiers (SIDs) are carried in a sub-TLV. The sub-TLV contains indication information, which indicates that the one or more SIDs are bound segment identifiers (BSIDs). The segment identifier list is used to display an indication of the forwarding path. The controller sends the message to the network device, the message being used to instruct the network device to forward the message according to the segment identifier list.

10. The method according to claim 9, characterized in that, The type of the sub-TLV indicates that the SID is an IPv6-based segmented routing SRv6 SID.

11. The method according to claim 9 or 10, characterized in that, The method further includes: The network device determines, based on the sub-TLV, that it does not need to perform fault verification on the BSID.

12. The method according to claim 9 or 10, characterized in that, The method further includes: The network device verifies whether a route to the BSID exists based on the sub-TLV.

13. A network device, characterized in that, The device includes: A receiving unit is configured to receive a message sent by the controller. The message includes a segment identifier list, which includes multiple segment identifiers (SIDs). One or more of the multiple SIDs are carried in a sub-TLV. The sub-TLV contains indication information, which indicates that the one or more SIDs are bound segment identifiers (BSIDs). The segment identifier list is used to display an indication forwarding path. The processing unit is used to store the segment identifier list and forward packets according to the segment identifier list.

14. The network device according to claim 13, characterized in that, The type of the sub-TLV indicates that the SID is an IPv6-based segmented routing SRv6 SID.

15. The network device according to claim 13 or 14, characterized in that, The processing unit is also used for, Based on the sub-TLV, it is determined that no fault verification is required for the SID.

16. The network device according to claim 13 or 14, characterized in that, The processing unit is also used for, The existence of a route to the BSID is verified based on the sub-TLV.

17. The network device according to claim 13, characterized in that, The Type field in the message includes indication information.

18. The network device according to claim 13, characterized in that, The Flags field in the message includes the indication information.

19. The network device according to claim 18, characterized in that, The indication information occupies at least one bit in the Flags field.

20. The network device according to claim 13 or 14, characterized in that, The message includes either a Border Gateway Protocol (BGP) message or a Path Calculation Unit Communication Protocol (PCEP) message.

21. A controller, characterized in that, The controller includes: A generation unit is used to generate a packet, the packet including a segment identifier list, the segment identifier list including multiple segment identifiers (SIDs), one or more of the multiple segment identifiers (SIDs) being carried in a sub-TLV, the sub-TLV containing indication information, the indication information being used to indicate that the one or more SIDs are bound segment identifiers (BSIDs); the segment identifier list is used to display an indication forwarding path. The sending unit is configured to send the message to the network device, the message being used to instruct the network device to forward the message according to the segment identifier list.

22. The controller according to claim 21, characterized in that, The type of the sub-TLV indicates that the SID is an IPv6-based segmented routing SRv6 SID.

23. The controller according to claim 21 or 22, characterized in that, The controller also includes: The network device determines, based on the sub-TLV, that it does not need to perform fault verification on the SID.

24. The controller according to claim 21 or 22, characterized in that, The controller also includes: The network device verifies whether a route to the BSID exists based on the sub-TLV.

25. A processing system for binding segment identifiers, characterized in that, The system includes a network device and a controller, wherein the network device is the network device according to any one of claims 13 to 20, and the controller is the controller according to any one of claims 21 to 24.

Images