Transfer Path Determination Method and Device
Network devices in segment routing networks autonomously determine transfer paths using BGP routing updates and performance metrics, simplifying control and ensuring optimized packet routing across domains.
Patent Information
- Application Number
- JP2023154200
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2019-09-11
- Filing Date
- 2023-09-21
- Publication Date
- 2025-07-23
- Estimated Expiration
- 2040-07-29
AI Technical Summary
The complexity of packet transfer control in segment routing networks is exacerbated when controllers are unavailable or cannot communicate across domains, making it impossible to determine transfer paths that meet network performance requirements.
A method and apparatus that enable network devices to determine transfer paths independently using Border Gateway Protocol routing update messages, incorporating segment identifiers and performance requirements, allowing devices to generate mapping relationships and forward packets along optimized paths without relying on inter-controller communication.
Simplifies packet transfer control by enabling devices to autonomously determine and manage transfer paths that meet latency, bandwidth, and jitter requirements, even across multiple autonomous system domains.
Smart Images

Figure 0007712334000010 
Figure 0007712334000011 
Figure 0007712334000012
Abstract
Description
Technical Field
[0001] [Technical Field] This application relates to the field of communications and also to a method and apparatus for determining a transfer path.
Background Art
[0002] Segment Routing (SR) is a protocol designed to transfer data packets in a network based on source routing. In an SR network, an ingress node in the network that supports SR inserts a sequential group of segment identifiers into a data packet to explicitly specify the transfer path of the data packet. SR applied to the Multi-Protocol Label Switching (MPLS) data plane is referred to as MPLS-based segment routing (MPLS-SR or SR-MPLS). SR applied to the Internet Protocol Version 6 (IPv6) data plane is referred to as IPv6-based segment routing (SRv6).
[0003] A segment identifier (Segment ID, SID) is an ID that describes a segment and represents, for example, a node or a link. In the case of MPLS-SR, the SID is represented by an MPLS label, while in the case of SRv6, the SID is represented by a 128-bit value.
[0004] A segment identifier list is a list that contains a group of segment identifiers. After receiving a data packet, the ingress node inserts one SID list into the data packet to explicitly indicate the transfer path.
[0005] The segment identifier may be represented by an endpoint layer 3 cross-connect segment identifier (End.X SID, where End indicates the endpoint, X indicates the crossing, and SID indicates the segment identifier). For any node in the SR network, the node may advertise at least one End.X SID, and each End.X SID is used to identify the IP layer link directly connected to that node.
[0006] The binding segment identifier (Binding SID, BSID) is bound to the SID list and indicates the transfer path. When receiving a valid BSID, the ingress node in the SR network performs operations related to the BSID. In an IPv6 Segment Routing (SRv6) network, the operations related to the defined BSID may be to insert a new SRH header (End.B6.Insert) including SRH or a new external IPv6 header (End.B6.Encaps) based on multiple different BSID functions.
[0007] In actual applications, since the segment routing network is based on the source routing technology, the controller usually distributes the BSID or SID list to the ingress node to control data packet transfer.
[0008] That is, in the prior art, the devices in the SR network need to interact with the relevant controller to obtain a transfer path that meets the requirements. When the transfer path is a transfer path that crosses multiple domains, the specified transfer path is further determined by the interaction between multiple controllers. However, when no controller is available, or when two controllers with different responsible domains cannot communicate with each other, it is impossible to obtain a transfer path that meets the requirements.
Summary of the Invention
[0009] This application provides a transfer path determination method and apparatus to solve the problem that the entire packet transfer control process becomes complex because the ingress node for packet transfer between domains depends on interaction with a controller or it is impossible to implement packet transfer between domains without a controller.
[0010] According to a first aspect, a transfer path determination method is provided. The method is applied to a first network device. The first network device operates in a general-purpose server and may be a router, a switch, or a virtual network device having an IP transfer function. This is not particularly limited in this application. The method includes the following steps.
[0011] The first network device receives a first routing update message sent by a second network device. The first routing update message is a Border Gateway Protocol routing update message. The first routing update message carries a first identifier list. The first identifier list indicates a first transfer path from the second network device to a third network device. The first identifier list includes a binding segment identifier. The first transfer path is a transfer path in a segment routing network. The first network device and the third network device do not belong to the same autonomous system AS domain. And the first network device determines a second transfer path based on the first identifier list carried in the first routing update message. The second transfer path is a transfer path from the first network device to the third network device. The second transfer path includes the first transfer path.
[0012] According to the transfer path determination method provided by the first aspect, an identifier list indicating a transfer path from a second network device to a third network device is transmitted to a first network device. The identifier list includes a segment identifier or a binding segment identifier, whereby, in a scenario where there is no controller or where there are multiple controllers but they cannot communicate with each other, a transfer path between domains is determined. This helps to simplify the packet transfer control process.
[0013] In one possible way, the first network device obtains a network performance identifier. For the first network device to determine a second transfer path based on a first identifier list carried in a first routing update message means that the first network device determines the second transfer path based on the network performance identifier and the first identifier list, and the second transfer path satisfies the network performance requirements indicated by the network performance identifier.
[0014] In one possible way, for the first network device to obtain a network performance identifier includes that the network performance identifier is carried in a first routing update message and the first network device obtains the network performance identifier from the first routing update message, or that the first network device receives a control message sent by a controller and the first network device obtains the network performance identifier from the control message.
[0015] In the above selective manner, the network performance identifier is carried in the first routing update message, so that for services with network performance requirements, a transfer path that meets the network performance requirements may be further determined. For example, when a voice service requires a transfer path with a lower latency if possible, this method may be used to determine a second transfer path that meets the performance requirements for the service.
[0016] In one possible manner, after a first network device determines a second transfer path based on a first routing update message, the method further includes the first network device generating a first mapping relationship, where the first mapping relationship is a mapping relationship between a first binding segment identifier corresponding to the first network device and a segment identifier of the first network device, or the first mapping relationship is a mapping relationship between a first binding segment identifier corresponding to the first network device and a set of identifiers, and the set of identifiers includes a segment identifier of the first network device and a first list of identifiers.
[0017] In the above selective manner, at each network device on the transfer path, a mapping relationship is generated for the corresponding binding segment identifier and the path indicated by the binding segment identifier. The mapping relationship may be stored in the routing table or transfer table of the network device. Therefore, after receiving a data packet, the network device on the transfer path can transfer the data packet along a preferred transfer path that meets the performance requirements.
[0018] In one possible approach, the first routing update message further includes an identifier of the destination network device. When the first network device is an ingress node, the method includes the first network device generating a second mapping relationship, where the second mapping relationship is a mapping relationship between a second binding segment identifier corresponding to the first network device and the identifier of the destination network device, and the first network device generating a third mapping relationship, where the third mapping relationship is a mapping relationship between the second binding segment identifier and a set of binding segment identifiers, and the set of binding segment identifiers includes the first binding segment identifier and a first list of identifiers, or the set of binding segment identifiers includes only the first binding segment identifier, and the first network device receiving a data packet, where the data packet carries the identifier of the destination network device, and the first network device forwarding the data packet along a second transfer path based on the second mapping relationship and the third mapping relationship.
[0019] In the above alternative approach, after receiving a data packet, an ingress node in a segment routing network processes the data packet, such that network devices on the determined transfer path can forward the data packet along the determined transfer path. Further, existing techniques are used during the transfer process to reduce the complexity of the solution.
[0020] In one possible approach, network performance requirements include at least one of latency, bandwidth, packet loss, and jitter.
[0021] In the above selective manner, the network administrator defines as many network performance requirements as possible in the network, and further determines a transfer path that meets those network performance requirements, so as to meet the requirements of multiple different services.
[0022] In one possible manner, the first identifier list is carried in the first type length value TLV of the first routing update message.
[0023] The first identifier list indicating the first transfer path is carried in the first routing update message in the form of a TLV, and the TLV is reused. This is helpful for the rapid implementation of this solution and its rapid deployment in the network.
[0024] In one possible manner, when the first network device is a transit node in the segment routing network, after the first network device determines a second transfer path based on the first routing update message, the method further includes the first network device sending a second routing update message to the fourth network device, and the second routing update message carries a second identifier list.
[0025] In one possible manner, the second routing update message further carries a network performance identifier.
[0026] In the above selective manner, the transfer path in the segment routing network may be transmitted by using a routing update message, and the controller does not necessarily use the method that the controller is the ingress node or the ingress node performs automatic calculation, whereby the application of the segment routing technology in the network becomes simpler.
[0027] In one possible manner, when the first mapping relationship is a mapping relationship between the first binding segment identifier and the segment identifier of the first network device, the second identifier list includes the first binding segment identifier and the first identifier list, or when the first mapping relationship is a mapping relationship between the first binding segment identifier and a set of identifiers, the second identifier list includes only the first binding segment identifier.
[0028] In one possible manner, the first network device and the second network device belong to different autonomous system AS domains.
[0029] In the above selective manner, network devices in the segment routing network transmit the transfer path in the segment routing network by using BGP routing update messages, and the transfer path may even be a transfer path that crosses multiple AS domains. It is not necessarily necessary to use a method for determining the transfer path through communication between the network device and the controller or through communication between multiple controllers. This helps to simplify the packet transfer control process.
[0030] According to a second aspect, a transfer path determination method is provided. The method is applied to a second network device. The second network device may operate in a general-purpose server and may be a router, a switch, or a virtual network device having an IP transfer function. This is not particularly limited in this application. The method includes the following steps.
[0031] The second network device determines a first identifier list, the first identifier list indicates a first transfer path from the second network device to a third network device, the first identifier list includes a binding segment identifier, the first transfer path is a transfer path in a segment routing network, the second network device sends a first routing update message to the first network device, the first routing update message is a border gateway protocol routing update message, the first routing update message carries the first identifier list, and the first network device and the third network device do not belong to the same autonomous system (AS) domain.
[0032] In a transfer path determination method according to a second aspect, the routing update message transmits a SID list, a BSID list, or a list including SID and BSID, and these SID list, BSID list, or list including SID and BSID indicate a transfer path, whereby in a scenario where there is no controller or there are multiple controllers but these multiple controllers cannot communicate with each other, and by using this method, it is possible to determine a transfer path between domains. This helps to simplify the packet transfer control process.
[0033] In one possible manner, before the second network device determines the first identifier list, the method further includes the second network device obtaining a network performance identifier and the second network device determining a first transfer path based on the network performance identifier, where the first transfer path meets the network performance requirements indicated by the network performance identifier.
[0034] In one possible approach, for a second network device to obtain a network performance identifier, the second network device receives a second routing update message, and the second network device obtains the network performance identifier from the second routing update message, or the second network device receives a control message sent by a controller, and the second network device obtains the network performance identifier from the control message.
[0035] In one possible approach, network performance requirements include at least one of latency, bandwidth, packet loss, and jitter.
[0036] In the above selective approach, for a service with network performance requirements, a transfer path that meets the network performance requirements may be further determined by using the network performance identifier. For example, when a voice service requires a transfer path with lower latency, a transfer path that meets the performance requirements for the service may be determined by this method.
[0037] In one possible approach, a second network device generates a first mapping relationship between a first binding segment identifier corresponding to the second network device and a set of identifiers, where the set of identifiers includes the segment identifier of the second network device. The second network device receives a data packet that carries the first binding segment identifier, and the second network device transfers the data packet along a first transfer path based on the mapping relationship.
[0038] In one possible approach, the first list of identifiers includes the first binding segment identifier.
[0039] In one possible manner, the first identifier list is carried in the first type length value TLV of the first routing update message.
[0040] In the above selective manner, at each network device on the transfer path, a mapping relationship for the corresponding binding segment identifier and the path indicated by the binding segment identifier is generated. The mapping relationship may be stored in the routing table or transfer table of the network device. Therefore, after receiving a data packet, the network device on the transfer path can transfer the data packet along a preferred transfer path that meets the performance requirements.
[0041] According to a third aspect, a first network device is provided. The first network device has a function of determining a transfer path according to any one of the first aspect or the selective manner of the first aspect. The function may be implemented based on hardware, or may be implemented based on hardware that executes corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The first network device may operate in a general-purpose server and may be a router, switch, or virtual network device having an IP transfer function. This is not particularly limited in this application.
[0042] The first network device is a receiving unit configured to receive a first routing update message transmitted by a second network device, where the first routing update message is a Border Gateway Protocol routing update message, the first routing update message carries a first identifier list, the first identifier list indicates a first transfer path from the second network device to a third network device, the first identifier list includes a binding segment identifier, the first transfer path is a transfer path in a segment routing network, and the first network device and the third network device do not belong to the same autonomous system (AS) domain, and a processing unit configured to determine a second transfer path based on the first identifier list carried in the first routing update message, where the second transfer path is a transfer path from the network device to the third network device, and the second transfer path includes the first transfer path.
[0043] In one possible approach, the first network device further includes an acquisition unit configured to acquire a network performance identifier. Correspondingly, when the processing unit is configured to determine a second transfer path based on the first identifier list carried in the first routing update message, specifically, the processing unit determines the second transfer path based on the network performance identifier and the first identifier list, and the second transfer path satisfies the network performance requirements indicated by the network performance identifier.
[0044] In one possible manner, the acquisition unit being configured to acquire a network performance identifier specifically means that the network performance identifier is carried in a first routing update message and the acquisition unit is configured to acquire the network performance identifier from the first routing update message, or the receiving unit is further configured to receive a control message sent by the controller, and the acquisition unit is configured to acquire the network performance identifier from the control message.
[0045] In one possible manner, after the processing unit is configured to determine a second transfer path based on a first routing update message, the processing unit is further configured to generate a first mapping relationship. The first mapping relationship is a mapping relationship between a first binding segment identifier corresponding to a first network device and a segment identifier of the first network device, or the first mapping relationship is a mapping relationship between a first binding segment identifier corresponding to a first network device and an identifier set, and the identifier set includes a segment identifier of the first network device and a first identifier list.
[0046] In one possible approach, the first network device further includes a transmission unit, and the first routing update message further includes an identifier of the destination network device. When the first network device is an ingress node, the processing unit is further configured to generate a second mapping relationship, where the second mapping relationship is a mapping relationship between a second binding segment identifier corresponding to the first network device and the identifier of the destination network device. The processing unit is further configured to generate a third mapping relationship, where the third mapping relationship is a mapping relationship between the second binding segment identifier and a set of binding segment identifiers. The set of binding segment identifiers includes the first binding segment identifier and the first identifier list, or the set of binding segment identifiers includes only the first binding segment identifier. The receiving unit is further configured to receive a data packet, where the data packet carries the identifier of the destination network device. The transmission unit is further configured to transfer the data packet along a second transfer path based on the second mapping relationship and the third mapping relationship.
[0047] In one possible approach, the network performance requirements include at least one of latency, bandwidth, packet loss, and jitter.
[0048] In one possible approach, the first identifier list is carried in the first type length value TLV of the first routing update message.
[0049] In one possible approach, when the first network device is a transit node in a segment routing network, after the processing unit determines a second transfer path based on the first routing update message, the transmission unit is further configured to send a second routing update message to a fourth network device, where the second routing update message carries a second identifier list.
[0050] In one possible manner, when the first mapping relationship is a mapping relationship between the first binding segment identifier and the segment identifier of the first network device, the second identifier list includes the first binding segment identifier and the first identifier list, or when the first mapping relationship is a mapping relationship between the first binding segment identifier and a set of identifiers, the second identifier list includes only the first binding segment identifier.
[0051] In one possible manner, the first network device and the second network device belong to different autonomous system AS domains.
[0052] According to a fourth aspect, a second network device is provided. The second network device has a function of determining a transfer path according to any one of the second aspect or an alternative manner of the second aspect. The second network device operates in a general-purpose server and is a router, a switch, or a virtual network device having an IP transfer function. This is not particularly limited in this application.
[0053] The second network device is a processing unit configured to determine a first identifier list, where the first identifier list indicates a first transfer path from the second network device to a third network device, the first identifier list includes a binding segment identifier, and the first transfer path is a transfer path in a segment routing network, a processing unit, and a transmission unit configured to send a first routing update message to a first network device, where the first routing update message is a border gateway protocol routing update message, the first routing update message carries the first identifier list, and the first network device and the third network device do not belong to the same autonomous system AS domain, including a transmission unit.
[0054] In one possible way, the second network device further includes an acquisition unit. Before the processing unit is configured to determine the first identifier list, the acquisition unit is configured to acquire a network performance identifier. The processing unit is further configured to determine a first transfer path based on the network performance identifier, and the first transfer path meets the network performance requirements indicated by the network performance identifier.
[0055] In one possible way, the second network device further includes a reception unit. The acquisition unit being configured to acquire a network performance identifier specifically means that the reception unit is configured to receive a second routing update message, and the acquisition unit is configured to acquire a network performance identifier from the second routing update message, or the reception unit is configured to receive a control message sent by a controller, and the acquisition unit is configured to acquire a network performance identifier from the control message.
[0056] In one possible approach, the processing unit is further configured to generate a first mapping relationship between a first binding segment identifier corresponding to a second network device and a set of identifiers, the set of identifiers including the segment identifier of the second network device, the receiving unit is further configured to receive a data packet, the data packet carrying the first binding segment identifier, and the transmitting unit is further configured to transfer the data packet along a first transfer path based on the mapping relationship.
[0057] In one possible approach, the first list of identifiers includes the first binding segment identifier.
[0058] According to a fifth aspect, a first network device is provided, the first network device including a processor, a memory, and a transceiver. The memory stores at least one instruction, and the processor is configured to execute the computer-readable instruction in the memory, whereby the first network device executes a transfer path determination method according to any one of the first aspect and an alternative manner of the first aspect.
[0059] According to a sixth aspect, a second network device is provided, the second network device including a processor, a memory, and a transceiver. The memory stores at least one instruction, and the processor is configured to execute the computer-readable instruction in the memory, whereby the second network device executes a transfer path determination method according to any one of the second aspect and an alternative manner of the second aspect.
[0060] According to a seventh aspect, a computer-readable storage medium is provided. The storage medium stores at least one instruction that, when loaded by a processor, executes a transfer path determination method according to either one of the first aspect and an alternative manner of the first aspect, or a transfer path determination method according to the second aspect.
[0061] According to an eighth aspect, a computer program is provided. The computer program includes a computer program used to execute a method according to either one of the first aspect and an alternative manner of the first aspect.
[0062] According to a ninth aspect, a computer program is provided. The computer program includes a computer program used to execute a method according to either one of the second aspect and an alternative manner of the second aspect.
Brief Description of the Drawings
[0063] To more clearly illustrate the multiple technical solution methods of the present invention, the following description briefly explains the multiple attached drawings used in these multiple embodiments. The multiple attached drawings in the following description only show some of the multiple embodiments of the present invention. It is obvious that those skilled in the art can derive other technical solution methods and attached drawings from these multiple attached drawings without creative efforts. These multiple technical solution methods and multiple attached drawings are also considered to belong to the scope of the present invention.
[0064]
Figure 1
Figure 2A
Figure 2B
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Mode for Carrying Out the Invention
[0065] In order to enable those skilled in the art to better understand multiple solutions of the present invention, the following description will explain multiple embodiments of the present invention in more detail with reference to multiple attached drawings and multiple implementations.
[0066] In those multiple embodiments of this application, terms such as "first" and "second" are used to distinguish multiple identical items or multiple similar items having basically the same function. It should be understood that there is no logical order dependency or temporal order dependency between "first", "second", and "nth", and the number and execution order are not limited.
[0067] It should be understood that the list in this application may contain one element or multiple elements. The number of elements included in the list is not limited in this application.
[0068] It should be understood that the set in this application may contain one element or multiple elements. The number of elements included in the set is not limited in this application. It should be understood that this application may be applicable to MPLS-SR or SRv6. This is not particularly limited in this application.
[0069] The terms in this application are explained as follows.
[0070] Based on Segment Routing Traffic Engineering (SR Policy), the ingress node embeds information about the forwarding path of the data packet in the packet header of the data packet. In this way, the data packet can traverse the network along the specified path. One SR Policy is defined as an optimization goal between the ingress node and the destination node, and it is possible to identify those ingress nodes and destination nodes using tuples (such as ingress node (Head-end), color (Color), destination node (End-point), etc.). One SR Policy corresponds to one or more BSIDs, each BSID corresponds to one or more candidate paths (CPs), and one CP contains one or more segment identifier lists (SID Lists). Each segment identifier list indicates the path from the source to the destination, and instead of the default and shortest path to the destination node calculated based on the Interior Gateway Protocol (IGP), it indicates the forwarding device in the path in the network for performing forwarding along the specified path. Generally, one SR Policy and the corresponding CP are determined by prior configuration or by automatic calculation by the ingress node. Generally, one SR Policy preferentially selects the CP as the forwarding path. A certain specific prior configuration method includes configuring the CP for the device by using the command line, configuring it by the network management system, or configuring it by the SDN controller. After receiving a data packet compliant with the SR Policy and before forwarding the packet, the ingress node analyzes the Binding Segment ID (BSID) corresponding to the SR Policy and the segment identifier list corresponding to the BSID. The corresponding SRH is carried in the data packet, thereby making it possible to forward the packet along the specified path.
[0071] FIG. 1 is a schematic diagram of an application scenario according to one embodiment of this application. In the scenario shown in FIG. 1, network device 101, network device 102, network device 103, and network device 104 belong to one AS domain, that is, they belong to AS domain 1 shown in FIG. 1. Network device 105, network device 106, network device 107, network device 108, network device 109, and network device 110 belong to another AS domain, that is, they belong to AS domain 2 shown in FIG. 1. Network device 101 is individually connected to network device 102, network device 103, and network device 104. Network device 102 is individually connected to network device 101, network device 103, network device 104, network device 105, and network device 107. Network device 103 is individually connected to network device 101, network device 102, and network device 104. Network device 104 is individually connected to network device 101, network device 102, network device 103, network device 105, and network device 107. Network device 105 is individually connected to network device 102, network device 104, network device 106, network device 108, and network device 107. Network device 107 is individually connected to network device 102, network device 104, network device 105, network device 106, and network device 108. Network device 106 is individually connected to network device 105, network device 107, network device 109, and network device 108. Network device 108 is individually connected to network device 105, network device 106, network device 109, and network device 107.Network device 109 is individually connected to network devices 106, 108, and 110. Network device 110 is , network device 109 individually connected to, and network device 110 is connected to CE network device 1. Network devices 110, 105, and 107 are BGP Peers. Network devices 105, 102, and 104 are BGP Peers. Network devices 102, 101, and 103 are BGP Peers. Controller 1 is configured to manage AS domain 1. Controller 2 is configured to manage AS domain 2. For example, when a network device in AS domain 1 such as network device 101 needs to forward a packet to CE network device 1 along a path that meets a certain requirement, network device 110 needs to forward that packet. However, since network devices 101 and 110 are located in multiple different domains, network device 101 does not know the network topology structure of AS domain 2 where the 110 network device is located. Therefore, it is impossible for network device 101 or controller 1 to obtain a path that meets that requirement through calculation. If controllers 1 and 2 can communicate, it is necessary to execute negotiations between controller 1 and controller 2 to obtain such a path. Alternatively, if there is an inter-domain controller, it is possible to obtain such a transfer path through uniform calculation.
[0072] From the above description, in the prior art, in order to implement the transfer between domains of a packet, multiple controllers need to interact with each other to obtain the complete transfer path of the packet, and then it is possible to understand that the transfer of the packet is completed. As a result, the overall packet transfer control process is complex, and if those multiple controllers cannot communicate with each other, it is impossible to implement the transfer between domains of the packet.
[0073] Taking this into consideration, one embodiment of this application provides a transfer path determination method to solve the above problems.
[0074] It should be noted that the above scenario is only shown for ease of understanding. This embodiment of this application may be further applied to other scenarios. Details will not be repeatedly described herein.
[0075] FIG. 2A and FIG. 2B are flowcharts of a transfer path determination method according to one embodiment of this application. As shown in FIG. 2A and FIG. 2B, the interaction in this method mainly includes a first network device, a second network device, a third network device, and a fourth network device. The fourth network device may be an ingress node in the segment routing network. The first network device and the second network device may be transit nodes in the segment routing network. The third network device may be an egress node in the segment routing network. The second network device and the first network device may be located in different AS domains. The fourth network device and the first network device may be located in the same domain.
[0076] Hereinafter, the method shown in FIGS. 2A and 2B will be described in detail. In this embodiment, the method is applied to the application scenario shown in FIG. 1. The network device 110 functions as a third network device, the network device 105 functions as a second network device, the network device 102 functions as a first network device, and the network device 101 functions as a fourth network device.
[0077] It should be understood that this is only one example. A person skilled in the art can also perform similar substitutions and applications with reference to this embodiment. In this application, examples are not shown one by one.
[0078] The method includes the following steps.
[0079] Step S200. The third network device sends a first routing update message to the second network device, and the routing update message carries an identifier of the destination network device.
[0080] In the application scenario shown in FIG. 1, the network device 110 sends a first routing update message to the network device 105, and the routing update message carries an identifier of the destination network device, such as the IP prefix of the network to which CE1 is connected.
[0081] Step S201. The second network device receives the first routing update message sent by the third network device.
[0082] Optionally, the second network device obtains a network performance identifier.
[0083] In this embodiment of this application, the network performance identifier is an identifier of network performance requirements. The network performance requirements may be predefined network performance requirements that can be understood by multiple AS domains, or the network performance requirements may be network performance requirements configured by a management system.
[0084] The method by which the second network device obtains the network performance identifier may include any one of the following Method 1, Method 2, or Method 3, but is not limited thereto.
[0085] Method 1: The second network device receives a control message sent by the controller, and the message carries the network performance identifier and the network performance requirements indicated by the network performance identifier.
[0086] Method 2: The operation and maintenance personnel manually configure the network performance identifier and the network performance requirements indicated by the network performance identifier in the second network device.
[0087] Method 3: The second network device receives a routing update message sent by a third network device (the third network device is a BGP Peer of the second network device), and the routing update message carries the network performance identifier.
[0088] Optionally, the network performance identifier is carried in the color extended community attribute of the routing update message, and the value of the color extended community attribute is the network performance identifier. For the detailed content of the color extended community attribute, reference should be made to the Request for Comments (RFC) draft-ietf-idr-tunnel-encaps-07. In this application, the details are not described.
[0089] Optionally, the network performance requirement is one or more of the network requirements of latency, packet loss, bandwidth, and jitter.
[0090] In one example, when the network performance requirement is a latency requirement, the requirement may be, in particular, a transfer path with low latency, for example. When the network performance requirement is a bandwidth requirement, the requirement may be, in particular, to use a link with a higher bandwidth if possible. The network requirement is expressed as a network performance identifier. For example, color = 80 may indicate that the path used has the minimum total delay metric, and color = 90 may indicate that the minimum available bandwidth of the path used is greater than a preset value such as 1G, for example.
[0091] Step S202. The second network device determines a first transfer path, where the first transfer path is a transfer path from the second network device to the third network device.
[0092] In one possible implementation, the method for the second network device to determine the first transfer path is that the second network device obtains, by calculation, a transfer path to the third network device based on the network performance identifier and the Interior Gateway Protocol (IGP) or the BGP Gateway Protocol.
[0093] In one possible implementation, the method for the second network device to determine the first transfer path is that the second network device requests the first transfer path from a controller that manages the AS domain where the second network device is located based on the received first routing update message.
[0094] Optionally, the first transfer path meets the network performance required by the network performance identifier.
[0095] Optionally, the first transfer path is a transfer path in a segment routing network. In one example shown in FIG. 3, the first transfer path determined by network device 105 is shown in FIG. 3 as the first transfer path 301 of network device 105 → network device 106 → network device 109 → network device 110. In other words, network device 105 transfers data packets to network device 110 along the first transfer path 301. If possible, the first transfer path meets the network performance requirements indicated by the network performance identifier color = 80.
[0096] (Optional) Step S203. The second network device generates a first mapping relationship between the first binding segment identifier corresponding to the second network device and the set of identifiers, and the binding identifier includes the segment identifier of the second network device.
[0097] Optionally, the set identifier includes only the segment identifier of the second network device, and the segment identifier may be an End.X SID. This is not particularly limited in this application.
[0098] Optionally, the set identifier includes the segment identifier of the second network device and some or all of the segment identifiers of a plurality of network device nodes in the first transfer path.
[0099] In one example, the first mapping relationship generated by the second network device 105 is shown in Table 1. A5::B510 is the first binding segment identifier corresponding to the second network device and corresponds to the identifier set (A5::C506, A6::106, A10::D110). The first binding segment identifier indicates the first transfer path from the network device 105 to the network device 110. In that identifier set, A5::C506 is the End.X type segment identifier of the second network device, A6::106 is the segment identifier of the network device 106, and A10::D110 is the segment identifier of the network device 110.
[0100] In this embodiment of this application, it should be understood that, as an example, the naming rules of the binding segment identifier and the segment identifier corresponding to SRv6 are used. In actual applications, for example, A5::B510 may be 10500, A6::106 may be 10506, and so on. Also, MPLS labels may be used as the binding segment identifier or the segment identifier. In the following description of this embodiment of this application, as an example, the method corresponding to SRv6 is used. Multiple examples are not enumerated one by one.
[0101] A particular value of the first binding segment identifier may be a binding segment identifier generated by a second network device, may be a binding segment identifier obtained by the second network device from a control message transmitted by the controller, or may be a binding segment identifier selected by the second network device from an existing local SID list according to rules. It should be understood that this is not particularly limited in this application. In multiple embodiments of this application, the method for obtaining a particular value of the binding segment identifier corresponding to other devices is the same as this method. Details are not described in other parts of the embodiments of this application. [Table 1]
[0102] Step S205. The second network device transmits a second routing update message to the first network device. The second routing update message carries a first identifier list. The first identifier list carries a first binding segment identifier. The first network device and the third network device do not exist in the same AS domain.
[0103] In one example, the first identifier list carried in the second routing update message is A5::B510.
[0104] Optionally, the second routing update message further carries a network performance identifier.
[0105] It should be understood that the second routing update message further carries an identifier of the destination network device.
[0106] In this embodiment of this application, in order to carry the first identifier list in the first routing update message, for example, a new path attribute such as a traffic engineering binding segment identifier attribute (SR BSID Attribute) may be applied, and therefore, a new type corresponding to that attribute needs to be applied. For the definition of BGP routing update messages and related attributes, reference should be made to the standard comment request RFC (Request for Comments, abbreviated as RFC) 4271 defined by the Internet Engineering Task Force (abbreviated as IETF) in English. Details are not repeated in this specification.
[0107] Optionally, the first routing update message includes a first type length value (TLV), and the first TLV includes the first identifier list.
[0108] TLV is an encoding format, mainly defined by three types of information: type, length, and value. The first TLV is a TLV that carries the first identifier list.
[0109] In one possible implementation, the first TLV may be a TLV nested within other TLVs, that is, a sub-TLV of other TLVs. In other possible implementations, the first TLV may alternatively be a sub-TLV of a new top TLV, where the top TLV is a TLV not nested inside other TLVs.
[0110] Optionally, each TLV carries one element in the first identifier list.
[0111] Figure 4 is a schematic diagram of the format of the first TLV. The type of the first TLV may be a newly applied type of the traffic engineering binding segment identifier attribute described above, for example, it may be 50. The value of the first TLV may include the element values in the first identifier list. For example, the first TLV may include an identifier field, which may occupy 128 bits, and the value of the identifier field may be a segment identifier or a binding segment identifier.
[0112] In one possible implementation, the network performance identifier and the above-mentioned first TLV are carried in the second TLV. Figure 5 is a schematic diagram of the format of the second TLV. The second TLV includes two sub-TLVs. One of the TLVs is a color TLV. The color TLV includes a color field, and the value of the color field is a network performance identifier, and the network performance identifier may occupy 32 bits. The second TLV further includes the first TLV. The type of the second TLV may be a newly applied type of the traffic engineering binding segment identifier attribute, for example, it may be 50. This indicates that the second TLV is of the type of the traffic engineering binding segment identifier attribute.
[0113] Of course, the second TLV may alternatively be included in other top TLVs. For the schematic format of the top TLV, reference should be made to the format of the second TLV shown in Figure 5 as well. Details will not be repeated in the specification of this application.
[0114] In one possible implementation, the network performance identifier is carried in the color extended community attribute of the first routing update message. In this embodiment of this application, the method for the second network device to send a BGP routing update message to the first network device is used to transmit a segment list, a binding segment identifier list, or a list including a segment identifier and a binding segment identifier, and the segment list, the binding segment identifier list, or the list including a segment identifier and a binding segment identifier indicates a transfer path from the second network device to the third network device. Thus, in a scenario where there is no controller or there are multiple controllers but the multiple controllers cannot communicate with each other, the transfer path between domains is determined. This helps to simplify the packet transfer control process.
[0115] Step S211. The first network device receives a second routing update message sent by the second network device.
[0116] Referring to the above example, the first identifier list carried in the second routing update message is A5::B510, and the binding segment identifier indicates a transfer path from network device 105 to network device 110.
[0117] Step S212. The first network device determines a second transfer path based on the first identifier list carried in the second routing update message. The second transfer path is a transfer path from the first network device to the third network device, and the second transfer path includes the first transfer path.
[0118] Optionally, determining, by a first network device, a second transfer path based on a first list of identifiers carried in a second routing update message includes: 1. the first network device determines a transfer path from the first network device to the second network device; and 2. the first network determines, as the second transfer path, a transfer path obtained by adding, to the determined transfer path from the first network device to the second network device, a first transfer path indicated by the first list of identifiers.
[0119] Optionally, the first network device further obtains a network performance identifier.
[0120] The method by which the first network device obtains a network performance identifier is the same as the method by which the second network device obtains a network performance identifier. In this embodiment of this application, details are not repeatedly described herein.
[0121] Regarding the method by which the first network device determines a transfer path from the first network device to the second network device, reference should be made to the above method by which the second network device determines a first transfer path. In this embodiment of this application, details are not repeatedly described herein.
[0122] In the example shown in FIG. 6, the second transfer path may be the second transfer path 601: network device 102 → network device 105 → network device 106 → network device 109 → network device 110, as shown in FIG. 6.
[0123] (Optional) Step S213. The first network device generates a first mapping relationship.
[0124] In this embodiment of this application, the first network device may generate the first mapping relationship by the following method 1 or method 2.
[0125] Method 1: The first network device generates a first mapping relationship between the first binding segment identifier corresponding to the first network device and the segment identifier of the first network device.
[0126] Method 2: The first network device generates a mapping relationship between the first binding segment identifier and the identifier set, and the identifier set includes the segment identifier of the first network device and the first identifier list. Referring to the above example, Table 2 shows the first mapping relationship generated by the first network device according to Method 1, and Table 3 shows the first mapping relationship generated by the first network device according to Method 2. The first binding segment identifier corresponding to the first network device is A2::B205, and the segment identifier of the first network device is End.X SID, that is, A2::C205, and A5::B510 is the first identifier list sent by the second network device to the first network device.
Table 2
Table 3
[0127] Step S215. The first network device sends a third routing update message to the fourth network device, and the third routing update message carries the second identifier list.
[0128] Similar to the two methods by which the first network device generates the first mapping relationship, the second identifier list held by the first network device may also include two different specific elements.
[0129] When the first network device generates a first mapping relationship according to Method 1, the second identifier list includes a first binding segment identifier corresponding to the first network device and the first identifier list.
[0130] In one example, when the first mapping relationship corresponds to Table 2, the second identifier list is (A2::B205, A5::B510).
[0131] When the first network device generates a first mapping relationship according to Method 2, the second identifier list includes only the first binding segment identifier corresponding to the first network device.
[0132] In one example, when the first mapping relationship corresponds to Table 3, the second identifier list is (A2::B205).
[0133] It should be understood that within the same AS domain, generally only one mapping method and the corresponding method for determining the identifier list carried in the routing update message are used. On the other hand, within multiple different AS domains, multiple different methods may be configured. For example, in AS domain 1 and AS domain 2, multiple different methods are used. Details are not described in this application.
[0134] Optionally, the third routing update message further carries a network performance identifier.
[0135] It should be understood that the method of carrying the second identifier list in the third routing update message is the same as the method of carrying the first identifier list in the second routing update message. In this application, details are not repeatedly described in this specification.
[0136] Step S221. The fourth network device receives the third routing update message sent by the first network device.
[0137] Referring to the above example, the second identifier list carried in the third routing update message is Expression method 1: (A2::B205,A5::B510); and, Expression method 2: (A2::B205) may be.
[0138] Step S222 . The fourth network device determines a third transfer path based on the second identifier list carried in the third routing update message. The third transfer path is a transfer path from the fourth network device to the third network device, and the third transfer path includes the second transfer path indicated by the second identifier list. It should be understood that the fourth network device is the ingress node in the segment routing network in this embodiment of this application.
[0139] The method by which the fourth network device determines the third transfer path is the same as the method by which the first network device determines the second transfer path. For details, reference should be made to Step S212 and related optional methods. In this embodiment of this application, details are not repeatedly described in this specification.
[0140] In one example, corresponding to the above two expression methods of the second identifier list, Table 4 and Table 5 separately show the first mapping relationship generated by the fourth network device. That is, when the second identifier list is (A2::B205,A5::B510), Table 4 shows the first mapping relationship generated by the fourth network device. When the second identifier list is (A2::B205), Table 5 shows the first mapping relationship generated by the fourth network device.
Table 4
Table 5
[0141] (Optional) Step S224. Since the fourth network device 101 is an ingress node in the segment routing network, the fourth network device further generates a second mapping relationship and a third mapping relationship.
[0142] Optionally, the second mapping relationship is a mapping relationship between a second binding segment identifier corresponding to the first network device and an identifier of a destination network device.
[0143] In one example, Table 6 shows the second mapping relationship. The identifier of the destination network device is the termination prefix identifier 20 / 8 in the third routing update message, and the second binding segment identifier A1::B110 indicates the transfer path from the fourth network device 101 to the first network device 110.
Table 6
[0144] Optionally, the second mapping relationship further includes a network performance identifier. Table 7 shows the second mapping relationship. The network performance identifier is 80, which represents, for example, a network performance requirement of an attribute such as a smaller network latency if possible.
Table 7
[0145] Optionally, the third mapping relationship generated by the fourth network device is a mapping relationship between the second binding segment identifier and the set of binding segment identifiers, and the set of binding segment identifiers includes the first binding segment identifier corresponding to the fourth network device and the second identifier list. Alternatively, the set of binding segment identifiers includes only the first binding segment identifier corresponding to the fourth network device.
[0146] In one example, when the second identifier list is (A2::B205,A5::B510), Table 8 shows the third mapping relationship generated by the fourth network device. When the second identifier list is (A2::B205), Table 9 shows the third mapping relationship generated by the fourth network device.
Table 8
Table 9
[0147] (Optional) Step S225. The fourth network device receives the first data packet, and the data packet carries the identifier of the destination network device.
[0148] Optionally, the first data packet further carries a network performance identifier.
[0149] (Optional) Step S229. The fourth network device transfers the first data packet to the first network device based on the second mapping relationship and the third mapping relationship.
[0150] The fourth network device determines a second binding segment identifier corresponding to the first data packet based on the second mapping relationship in Table 6 or Table 7, and searches for a binding segment identifier set corresponding to the third mapping relationship and the second binding segment identifier based on the determined second binding segment identifier. The second binding segment identifier indicates a transfer path from the fourth network device to the third network device.
[0151] The fourth network device carries a binding segment identifier set in the first data packet, and further queries the first mapping relationship (such as in Table 4 or Table 5) by using the first binding segment identifier corresponding to the fourth network device (such as A1::B102, etc.) among the binding segment identifier sets, and executes related operations. The segment routing network processing method adopted here is a conventional processing method, and in this application, details are not repeatedly described in this specification.
[0152] Optionally, the first network device receives the first data packet sent by the fourth network device, and the data packet carries a binding segment identifier corresponding to the first network device (such as A2::B205, etc.).
[0153] (Optional) Step S239. After executing related operations based on the mapping relationship included in the first network device, the first network device transfers the first data packet to the second network device.
[0154] Optionally, the second network device receives the first data packet sent by the first network device, and the data packet carries a binding segment identifier corresponding to the second network device (such as A5::B510, etc.).
[0155] (Optional) Step S249. After performing related operations based on the first mapping relationship included in the second network device, the second network device transfers the first data packet to the third network device.
[0156] The transfer path determination method according to multiple embodiments of this application has been described above. The following description explains the first network device and the second network device according to those multiple embodiments of this application.
[0157] FIG. 7 is a first network device 700 according to one embodiment of this application. The first network device 700 is capable of executing the method executed by the first network device (passing node) and the fourth network device (ingress node) shown in FIGS. 2A and 2B. The first network device 700 includes a receiving unit 701, a processing unit 702, a transmitting unit 703, and an obtaining unit 704. When the first network device 700 is a passing node in the network, the receiving unit 701 may be configured to execute, for example, step S211 in the embodiments of FIGS. 2A and 2B, and the processing unit 702 may be configured to execute, for example, steps S212 and S213 in the embodiments of FIGS. 2A and 2B, and the transmitting unit 703 may be configured to execute, for example, step S215 in the embodiments of FIGS. 2A and 2B, and the obtaining unit 704 may be configured to execute the step of obtaining a network performance identifier and an optional method in the method shown in FIGS. 2A and 2B when the first network device is a passing node. When the first network device 700 is an ingress node in the network, the receiving unit 701 may be configured to execute, for example, steps S215 and S225 in the embodiments of FIGS. 2A and 2B, and the processing unit 702 may be configured to execute, for example, steps S222, S223, and S224 in the embodiments of FIGS. 2A and 2B, and the transmitting unit 703 may be configured to execute, for example, step S229 in the embodiments of FIGS. 2A and 2B, and the obtaining unit 704 may be configured to execute the step of obtaining a network performance identifier and an optional method in the method shown in FIGS. 2A and 2B when the fourth network device is an ingress node.
[0158] The first network device provided by the embodiment of FIG. 7 700It should be noted that when executing the above determination of the transfer path, the division into the above plurality of functional units is only used as an example for explanation. In actual applications, if necessary, for implementation, the above plurality of functions may be assigned to a plurality of different functional units. In other words, the internal structure of the first network device is divided into a plurality of different functional units to implement all or part of the plurality of functions described above. Alternatively, an integrated functional unit is used to realize the functions of the above plurality of units. It should be understood that the embodiment of the first network device provided by the above embodiment and the embodiment of the above transfer path determination method belong to the same concept. The plurality of steps executed by the units of the first network device are only used as examples for explanation, which does not mean that the plurality of units of the first network device do not execute other steps or optional methods in the above plurality of embodiments. For a specific implementation process, the embodiment of the method should be referred to, and details are not repeatedly described in this specification.
[0159] FIG. 8 is a second network device 800 according to an embodiment of this application. The second network device 800 may execute the methods shown in FIGS. 2A and 2B. The second network device 800 includes a processing unit 802, a transmission unit 803, a reception unit 801, and an acquisition unit 804. The processing unit 802 may be configured to execute steps S202 and S203 in the embodiments of FIGS. 2A and 2B, for example. The transmission unit 803 may be configured to execute steps S215 and S239 in the embodiments of FIGS. 2A and 2B, for example. The reception unit 801 may be configured to execute step S211. The acquisition unit 804 may be configured to execute steps and optional methods for acquiring a network performance identifier in the methods shown in FIGS. 2A and 2B.
[0160] It should be noted that when the second network device provided by the embodiment of FIG. 8 executes the above determination of the transfer path, the division into the above plurality of functional units is only used as an example for illustration. In actual applications, if necessary, for implementation, the above plurality of functions may be assigned to a plurality of different functional units. That is, the internal structure of the second network device is divided into a plurality of different functional units to implement all or part of the plurality of functions described above. Alternatively, an integrated functional unit is used to realize the functions of the above plurality of units. It should be understood that the second network device provided by the above embodiment and the embodiment of the above transfer path determination method belong to the same concept. The plurality of steps executed by the units of the second network device are only used as examples for illustration, which does not mean that the plurality of units of the second network device do not execute other steps or optional methods in the above plurality of embodiments. For a specific implementation process, the embodiment of the method should be referred to, and details are not repeatedly described herein.
[0161] The first network device and the second network device according to multiple embodiments of this application are described above. The following description explains possible product forms of the first network device and the second network device. It should be understood that any product in any form having the characteristics of the first network device in FIG. 7 and any product in any form having the characteristics of the second network device in FIG. 8 belong to the scope of protection of this application. Furthermore, it should be understood that the following description is only an example and does not limit the product forms of the first network device and the second network device according to multiple embodiments of this application.
[0162] In one possible product form, by using a general bus architecture, it is possible to implement a first network device or a second network device according to those multiple embodiments of this application.
[0163] As shown in FIG. 9, one embodiment of this application provides a first network device. 900 The first network device 900 includes a processor 901, a memory 902, and a transceiver 903. The memory 902 stores at least one instruction, and the processor 901 is configured to load the instruction, whereby the first network device 900 executes the above transfer path determination method. The processor 901, the memory 902, and the transceiver 903 may be connected via a bus.
[0164] The processor 901 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to control the execution of a program of multiple solution methods of this application.
[0165] Memory 902 can be, but is not limited to, a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, or a random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other compact disc storage device, an optical disc storage device (including compact discs, laser discs, optical discs, digital versatile discs, or Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or may be used to carry or store program code in the form of instructions or data structures, and may also be other media that can be accessed by a computer.
[0166] As shown in FIG. 10, one embodiment of this application provides a second network device 1000. The second network device 1000 includes a processor 1001, a memory 1002, and a transceiver 1003. The memory 1002 stores at least one instruction, and the processor 1001 is configured to load the instruction, whereby the second network device 1000 executes the above transfer path determination method. The processor 1001, the memory 1002, and the transceiver 1003 may be connected by a bus. The product form of the processor 1001 is the same as the product form of the processor 901, and the product form of the memory 1002 is the same as the product form of the memory 902. Details are not described herein.
[0167] In one possible product form, the first network device or the second network device according to this embodiment of this application may be implemented by a general-purpose processor.
[0168] The general-purpose processor for implementing the first network device includes a processing circuit, an output interface, and an input interface, and their output interface and input interface are internally connected to the processing circuit and communicate with the processing circuit. The processing circuit is configured to execute step S212, step S213, step S222, step S223, and step S224. The processing circuit is configured to control the input interface to execute step S211 or step S221. The processing circuit is further configured to control the output interface to execute step S215 and step S239 or step S229. The general-purpose processor further includes a storage medium, and the storage medium is configured to store instructions executed by the processing circuit.
[0169] The general-purpose processor for implementing the second network device includes a processing circuit, an input interface, and an output interface, and their input interface and output interface are internally connected to the processing circuit and communicate with the processing circuit. The processing circuit is configured to control the output interface to execute step S205 or execute step S249. Optionally, the processing circuit is further configured to control the input interface to execute step S201 and step S249, and the processing circuit further executes step S202 and step S203. Optionally, the general-purpose processor may further include a storage medium, and the storage medium is configured to store instructions executed by the processing circuit.
[0170] In one possible product form, according to this embodiment of this application providedThe first network device or the second network device may alternatively be implemented by using one or more field-programmable gate arrays (English official name: field-programmable gate array, English abbreviation: FPGA), programmable logic devices (English official name: programmable logic device, English abbreviation: PLD), controllers, state machines, gate logic, individual hardware components, any other suitable circuits, or any combination of circuits capable of performing the various functions described by this application.
[0171] It should be understood that the first network device or the second network device in the above product form respectively has the functions of the first network device or the second network device in the embodiment of the above transfer path determination method. Details are not repeatedly described herein.
[0172] Those skilled in the art can recognize that, in combination with the examples described in the multiple embodiments disclosed herein, it is possible to implement the steps and units of the multiple methods by electronic hardware, computer software, or a combination thereof. To clearly explain the compatibility between hardware and software, the above description has generally described the steps and configurations of each embodiment according to functions. Whether those multiple functions are executed by hardware or by software is determined by the specific applications and design constraints of those multiple technical solutions. Those skilled in the art can use multiple different methods to implement the multiple described functions for each specific application, but the implementation should not be construed as exceeding the scope of this application.
[0173] For the purpose of a simple and concise description, those skilled in the art can clearly understand that the detailed operation processes of the systems, devices, and units described above should refer to the corresponding processes in the embodiments of the above methods, and details will not be repeatedly described in this specification.
[0174] In some of the multiple embodiments provided by this application, it should be understood that the disclosed devices and methods may be implemented by other means. For example, the described embodiments of the device are only one example. For example, the division of units is only a logical function division, and other divisions may be used in actual implementation. For example, a plurality of units or components may be combined or integrated into other systems, or some of the plurality of features may be ignored or not executed. In addition, the mutual connections, direct connections, or communication connections shown or described may be implemented by some interfaces. Indirect connections or communication connections between a plurality of devices or units may be implemented in electrical form, mechanical form, or other forms.
[0175] The multiple units described as individual parts may be physically separated. Also, the multiple parts shown as multiple units may or may not be multiple physical units, may be located in one place, or may be distributed across multiple network units. Based on actual requirements, some or all of those multiple units may be selected to achieve the purposes of the multiple solution methods in the multiple embodiments of this application.
[0176] In addition, the processing units in these multiple embodiments of this application may be distributed among multiple functional units or integrated into one processing unit. Each of these multiple units may physically exist independently or two or more units may be consolidated into one unit. The integrated unit may be implemented in the form of hardware or in the form of a software functional unit.
[0177] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, the integrated unit may be stored in a computer-readable storage medium. Based on such understanding, the multiple technical solution methods of this application, in essence, or the parts contributing to the prior art, or all or part of these multiple technical solution methods may be implemented in the form of a software product. The computer software product is stored in a storage medium and includes several instructions, and some of these instructions are used to instruct a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the multiple steps of the methods described in these multiple embodiments of this application. The above storage medium includes any medium capable of storing program code, such as a USB flash drive, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0178] The above description is only a specific embodiment of this application and is not intended to limit the protection scope of this application. Equivalent modifications or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application belong to the protection scope of this application. Therefore, the protection scope of this application shall be subject to the protection scope of the claims.
[0179] All or part of the above - mentioned multiple embodiments may be implemented by using software, hardware, firmware, or any combination thereof. When software is used to implement those multiple embodiments, they may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer program instructions. When the computer program instructions are loaded into and executed by a computer, procedures or functions in accordance with those multiple embodiments of this application are fully or partially generated. The computer may be a general - purpose computer, a special - purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer - readable storage medium, or may be transmitted from one computer - readable storage medium to another computer - readable storage medium. For example, they may be transmitted in a wired or wireless manner from one website, computer, server, or data center to another website, computer, server, or data center. The computer - readable storage medium may be any usable medium accessible by a computer, or a data storage device such as a server or data center integrating one or more usable media. The usable medium may be a magnetic medium (such as a floppy disk, hard disk, or magnetic tape), an optical medium (such as a digital video disc (DVD)), or a semiconductor medium (such as a solid - state drive), etc.
[0180] Those skilled in the art can understand that all or part of the multiple steps of these multiple embodiments can be implemented by using hardware or a program that instructs the related hardware. The program may be stored in a computer-readable storage medium, and the storage medium may include a read-only memory, a magnetic disk, or an optical disk.
[0181] The above description is only an optional embodiment of this application and is not intended to limit this application. Modifications, equivalent substitutions, or improvements made without departing from the spirit and principle of this application shall fall within the scope of protection of this application.
Claims
1. A method for determining a transfer path, comprising: receiving, by a first network device, a first routing update message, wherein the first routing update message is a Border Gateway Protocol (BGP) routing update message, and the first routing update message carries one or more identifiers used to indicate a first transfer path from a second network device to a third network device, and the first network device and the third network device do not belong to the same domain; determining, by the first network device, a second transfer path based on the one or more identifiers carried in the first routing update message, wherein the second transfer path is a transfer path from the first network device to the third network device and the second transfer path includes the first transfer path; and obtaining, by the first network device, a network requirement identifier, wherein the second transfer path corresponds to the network requirement identifier. A method comprising the above steps.
2. The first routing update message further includes the network requirement identifier. The step of obtaining, by the first network device, the network requirement identifier includes obtaining, by the first network device, the network requirement identifier from the first routing update message; or or the step of obtaining, by the first network device, the network requirement identifier includes receiving, by the first network device, a control message sent by a controller, the control message including the network requirement identifier, and obtaining, by the first network device, the network requirement identifier from the control message. The method according to claim 1.
3. The identifier among the one or more identifiers includes a segment identifier or a binding segment identifier. The method according to claim 1.
4. The segment identifier includes a Multiprotocol Label Switching (MPLS) label or an identifier for segment routing by Internet Protocol version 6 (IPv6). The method according to claim 3.
5. The method further includes generating, by the first network device, a first mapping relationship, wherein the first mapping relationship is a mapping relationship between a first binding segment identifier corresponding to the first network device and a segment identifier of the first network device, or the first mapping relationship is a mapping relationship between a first binding segment identifier corresponding to the first network device and a set of identifiers, the set of identifiers including a segment identifier of the first network device and the one or more identifiers. The method according to claim 1.
6. The network requirements corresponding to the network requirement identifier are including at least one of latency, bandwidth, packet loss, and jitter. The method according to claim 1.
7. The one or more identifiers are carried in a first Type-Length-Value (TLV) of the first routing update message. The method according to claim 1 or 2.
8. When the first network device is a transit node in a segment routing network, the method further includes transmitting, by the first network device, a second routing update message to a fourth network device, the second routing update message carrying another identifier or other identifiers. The method according to claim 5.
9. When the first mapping relationship is a mapping relationship between the first binding segment identifier and the segment identifier of the first network device, the another identifier or other identifiers include the first binding segment identifier and the one or more identifiers. The method according to claim 8.
10. The second routing update message further carries a network requirement identifier corresponding to the second transfer path. The method according to claim 9.
11. A first network device, wherein the first network device is A receiving unit configured to receive a first routing update message, wherein the first routing update message is a Border Gateway Protocol (BGP) routing update message, and the first routing update message carries one or more identifiers used to indicate a first transfer path from a second network device to a third network device, and the first network device and the third network device do not belong to the same domain, the receiving unit, A processing unit configured to determine a second transfer path based on the one or more identifiers carried in the first routing update message, wherein the second transfer path is a transfer path from the first network device to the third network device, and the second transfer path includes the first transfer path, the processing unit, including, The processing unit is further configured to obtain a network requirement identifier, and the second transfer path corresponds to the network requirement identifier, A first network device.
12. The first routing update message further includes the network requirement identifier, The processing unit, Is configured to obtain the network requirement identifier and form the first routing update message, or, The receiving unit is configured to receive a control message sent by a controller, and the control message includes the network requirement identifier, and, The processing unit is configured to obtain the network requirement identifier from the control message. The first network device according to claim 11.
13. The identifier among the one or more identifiers includes a segment identifier or a binding segment identifier, The first network device according to claim 11.
14. The segment identifier includes a Multi-Protocol Label Switching (MPLS) label or an identifier for segment routing according to Internet Protocol Version 6 (IPv6), The first network device according to claim 13.
15. The processing unit is further configured to, Generate a first mapping relationship, The first mapping relationship is a mapping relationship between a first binding segment identifier corresponding to the first network device and a segment identifier of the first network device, or the first mapping relationship is a mapping relationship between a first binding segment identifier corresponding to the first network device and a set of identifiers, and the set of identifiers includes a segment identifier of the first network device and the one or more identifiers. The first network device according to claim 11.
16. The network requirements corresponding to the network requirement identifier include at least one of latency, bandwidth, packet loss, and jitter. The first network device according to any one of claims 11 to 15.
17. The one or more identifiers are carried in a first type length value (TLV) of the first routing update message. The first network device according to any one of claims 11 to 15.
18. When the first network device is a transit node in a segment routing network, the first network device further includes a transmission unit configured to transmit a second routing update message to a fourth network device, and the second routing update message carries another identifier or other identifiers. The first network device according to claim 15.
19. When the first mapping relationship is a mapping relationship between the first binding segment identifier and the segment identifier of the first network device, the another identifier or other identifiers include the first binding segment identifier and the one or more identifiers. The first network device according to claim 18.
20. The second routing update message further carries a network requirement identifier corresponding to the second transfer path. The first network device according to claim 19.
Citation Information
Patent Citations
SR information obtainment method and SR network establishment method
US20170317929A1