Cross-manufacturer protocol communication method based on controller, medium and equipment

Abstract

The invention provides a cross-manufacturer protocol communication method based on a controller, a medium and equipment, and belongs to the technical field of network communication. According to the invention, network node attributes and SRv6 SID are calculated and managed through the controller, and calculation of a network SRv6 forwarding path and an end-to-end path is realized; the controller calculates the Segment List ID or BSID of the corresponding network element according to the attribute of the network element device passed by each path; and the controller deploys a BSID or a Segment List at a starting point of each section of the same manufacturer path according to a calculation analysis result to form an end-to-end SRv6 complete forwarding path so as to realize cross-manufacturer full-path automatic deployment of the SRv6. According to the method, the forwarding path of the SRv6 can be better deployed in the whole life cycle and the whole process, so that the deployability of the SRv6 protocol is more conveniently supported, and the network evolution based on the SRv6 protocol is promoted.

Description

Technical Field

[0001] This invention belongs to the field of network communication technology, and specifically relates to a method, medium, and device for cross-vendor protocol communication based on a controller. Background Technology

[0002] While the SRv6 protocol is maturing and being deployed more widely, the level of support and versions of SRv6 from different vendors are not entirely synchronized, resulting in poor interoperability and impacting the end-to-end deployment and operation of SRv6 across networks. Furthermore, multiple solutions exist for SRv6 SRH compression, but their compatibility is not high, affecting SRv6 protocol overhead, transmission efficiency, and MTU, making it difficult to effectively address the high hardware requirements at the end-to-end level.

[0003] In many data networks, forwarding equipment from multiple vendors is used, and the support for SRv6 varies among these vendors. In particular, there are various protocols for SRH compression, such as G-SRv6 and uSID, and these protocols lack interoperability. This situation introduces high costs and risks to network operation and maintenance, hindering the deployment and application of SRv6 technology. Summary of the Invention

[0004] This invention addresses the shortcomings of existing technologies by providing a method, medium, and device for cross-vendor protocol communication based on a controller. This method for cross-vendor SRv6 protocol communication based on a controller solves the problem of SRv6 deployment and operation of multi-vendor devices.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a method for cross-vendor protocol communication based on a controller, comprising: Obtain the SRv6 version information of all devices in the network and initialize the SIDSpaceID of the devices. Each SIDSpaceID corresponds to a SID value space and also to the device that applies this SID value space. Based on the SIDSpaceID allocation, BSIDs are uniformly assigned to devices; Calculate the end-to-end path for SRv6 based on the path requirements for SRv6. Based on the forwarding path information in the end-to-end path, organize the end-to-end path and the SegmentList of each forwarding path segment. The SegmentList consists of the SID and BSID of the devices on the path. Based on the end-to-end path and the Segment List of each forwarding path, generate the SRH of the end-to-end path and each forwarding path and distribute it to the corresponding nodes in segments. The device at the corresponding node forwards the SRv6 packets locally based on the obtained SRH.

[0006] Optionally, the SIDSpaceID of the initialization device is specifically: Devices from the same manufacturer that use the same SID allocation rules are grouped together and identified using SIDSpaceID.

[0007] Optionally, different vendor devices supporting different SRv6 protocols correspond to different SIDSpaceIDs.

[0008] Optionally, the calculation of the end-to-end path of SRv6 specifically involves: Based on the network-wide routing information, the end-to-end path of SRv6 is calculated according to business requirements to obtain the complete path of SRv6 from the source node to the destination node, including each logical path of the unified SRv6 policy.

[0009] Optionally, when calculating the path for each logical path, the differences in SRv6 protocol version support among the nodes on the path are not considered, nor are the differences in compression technology protocols for SRv6 SRH.

[0010] Optionally, the Segment List for each forwarding path is organized as follows: Sequentially obtain the SIDSpaceID corresponding to each forwarding path and parse the corresponding SRv6 protocol; Based on the parsed SRv6 protocol, generate a Segment List for this forwarding path.

[0011] Optionally, the generation of the Segment List for this forwarding path specifically includes: For each node on the forwarding path, the Segment List of the forwarding path is formed using the SID of the device corresponding to the node, according to the parsed SRv6 protocol. For nodes that span SIDSpaceID, the BSID assigned to the corresponding device is used to map the Segment List.

[0012] Optionally, the segment list of the end-to-end path is organized as follows: For an end-to-end path, the segment list of the end-to-end path is formed using the segment list of each forwarding path and the BSID used to map the segment list.

[0013] In a second aspect, the present invention provides a computer-readable storage medium storing a computer program, characterized in that the computer program causes a computer to perform a method for controller-based cross-vendor protocol communication as described in the first aspect.

[0014] Thirdly, the present invention provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the method for cross-vendor protocol communication based on a controller as described in the first aspect.

[0015] The beneficial effects of this invention are: 1. This invention uses centralized computing by a controller to be compatible with different versions of SRv6, forming an end-to-end SRv6 forwarding path, and realizing the interoperability of different compression schemes of SRv6 SRH from multiple vendors; 2. This invention is compatible with different manufacturers' compression of SRv6 SRH, improving the end-to-end forwarding efficiency of SRv6 Policy.

[0016] 3. This invention solves the problem of incompatibility between devices from different manufacturers and SRv6 forwarding packets from other manufacturers by using BSID concatenation, thereby improving the flexibility of SRv6 deployment.

[0017] In summary, this invention improves the compatibility of devices from multiple vendors, reduces network system upgrade and maintenance costs; enhances the deployability of SRv6 end-to-end full path, reducing network operating costs; improves the end-to-end forwarding efficiency of SRv6, reducing network forwarding load; and can effectively promote the automated and flexible deployment of networks, facilitating the evolution of SDN (Software Defined Network) network systems. Attached Figure Description

[0018] Figure 1 This is a system framework diagram that supports a controller-based cross-vendor protocol communication method.

[0019] Figure 2 This is a flowchart of the SRv6 cross-vendor protocol processing.

[0020] Figure 3 This is a schematic diagram illustrating the process of calculating the SID of an end-to-end node.

[0021] Figure 4 This is a schematic diagram of SRH for SRv6 forwarding of packets by node A.

[0022] Figure 5 This is a schematic diagram of SRH for forwarding messages in SRv6 on node C.

[0023] Figure 6This is a schematic diagram of SRH for SRv6 forwarding messages on E nodes. Detailed Implementation

[0024] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0025] In one embodiment, this invention proposes a controller-based method for cross-vendor protocol communication, namely a system scheme of IPSDN controller and network forwarding devices, to optimize network deployment and application, improve network system operation and maintenance efficiency, and reduce network forwarding risks. The method includes: the controller calculating and managing network node attributes and SRv6 (Segment Routing IPv6) SIDs; calculating network SRv6 forwarding paths and end-to-end paths; the controller calculating the Segment List ID or BSID (Binding Segment ID) of the corresponding network element based on the attributes of the network element devices traversed by each path; and the controller deploying the BSID or Segment List at the starting point of each same-vendor path according to the calculation and analysis results, forming a complete end-to-end SRv6 forwarding path, thus achieving automatic deployment of SRv6 across all vendor paths.

[0026] The system framework supporting the method of this invention is as follows: Figure 1 As shown, it mainly includes: network element management, network acquisition and control, path calculation, SRH (Segment Routing Header) generation, and device forwarding; specifically as follows: 1. Network Element Management: The controller centrally manages all forwarding network element devices across the entire network, including the network element vendor, supported SRv6 protocols, SRv6 SRH compression technology protocols, and support protocols for SRv6 BSID; the process steps are as follows: Figure 3 As shown.

[0027] a) Different manufacturers have varying levels of support for the SRv6 protocol, and the depth of SRH support may also differ between device models from different manufacturers. Furthermore, the compression methods and schemes used for SRH in the SRv6 protocol, as well as the supported protocol standards, may also vary between manufacturers. For example, some support the uSID carrier scheme, some support the Compress-SRH scheme, some support the Unified-SRH scheme, and others support the G-SRv6 scheme.

[0028] b) The controller first manages and allocates SIDs and BSIDs across the entire network in a unified manner. The specific process is as follows: For devices that use the same SID allocation rules, the controller is grouped into one category and identified by SIDSpaceID. That is, each SIDSpaceID corresponds to a SID value space and also to the device that applies this SID value space. The controller uniformly assigns globally valid BSIDs, which can be regarded as SIDSpaceID being 0; For SID allocation and use within the same SIDSpaceID, the same rules are used to produce SID values; however, for different devices with different SID value spaces identified by different SIDSpaceIDs, such as device A corresponding to SIDSpaceID 1 and device B corresponding to SIDSpaceID 2, the SID published by B to A, that is, the SID used from A to B, uses BSID to identify the SRv6 Segment List starting from device B. Devices that support different SRv6 SRH compression technology protocols can be categorized into different SIDs (SpaceIDs). In special cases, when devices A and B have different SRv6 protocol versions, but device A is compatible with device B's SID value, including but not limited to SRv6 SRH compression, the BSID published from device B to device A does not necessarily have to be a global BSID, but rather a complete Segment List from device B.

[0029] 2. Network Acquisition and Control: Using network protocols, collect network topology, traffic, performance and status information, and collect SRv6 path information; distribute SRv6 path configurations to the controller based on centralized calculations, and obtain configuration result information.

[0030] a) For all network devices and interfaces, the controller uses network protocols (such as BGP, IGP, LLDP, etc.) to collect network topology information and status information.

[0031] b) For all interfaces and links in the network and SRv6, the controller collects network traffic and performance data according to network protocols (such as Telemetry, TWAMP, OAM, etc.).

[0032] c) For the entire network of SRv6, the controller obtains the path information and status information of SRv6 according to the network protocol (such as BGP-LS, BFD, etc.).

[0033] d) For all network devices, the controller distributes the corresponding device configurations and SRv6 path configurations and information through network protocols (such as Netconf / Yang, CLI, BGP, PCEP, etc.).

[0034] 3. Path Calculation: The controller calculates the network forwarding path based on the network-wide SRv6 information and the triplet information of the SRv6 Policy. Based on the calculated SRv6 path, it analyzes the SRv6 forwarding path corresponding to each SIDSpaceID on the forwarding path. This includes the starting point and the ending point.

[0035] a) Based on unified network-wide routing information that eliminates vendor differences, the controller calculates the end-to-end path for SRv6 according to service requirements (such as bandwidth, latency, bit error rate, display path, etc.). This calculation yields the complete SRv6 path from the source node to the destination node, which is each logical path in the Candidate Path of the unified SRv6 Policy. The path is a queue of each node and its port. , This represents the total number of logical paths.

[0036] b) For each logical path, the controller does not consider the differences in SRv6 protocol version support among the nodes on the path, nor does it consider the different technical differences in SRv6 SRH compression when calculating the path.

[0037] 4. SRH generation: Based on the calculation and analysis results of the forwarding path, i.e. the calculated logical path of SRv6, the controller centrally generates the SRH of each SRv6 forwarding path and the end-to-end SRH, and sends them to the corresponding forwarding devices in segments.

[0038] a) For each logical forwarding path, divide it into corresponding forwarding paths according to the SID space corresponding to SIDSpaceID. , m This represents the number of segmented paths corresponding to the logical forwarding path; for each segmented path... For each network element, from the source node to the destination node, a forwarding path is formed using the SRv6 SID corresponding to the SRv6 version supported by the node device, based on the SRv6 protocol version supported by the network element. Segment List.

[0039] b) For nodes that span SIDSpaceID, due to differences in supported SRv6 versions and compression schemes, the Segment List supported by the device's own SRv6 version is no longer used. Instead, the corresponding BSID assigned by the controller is used to map the corresponding Segment List.

[0040] c) Thus, for an end-to-end path, use each segment The Segment List and its corresponding BSID form an end-to-end connection. Segment List.

[0041] 5. Device Forwarding: The network element device receives the SRv6 forwarding path configuration information from the controller and forwards SRv6 packets at the start and end points of each path according to the configuration, based on the SRv6 support of the corresponding manufacturer. Since each router only needs to support the forwarding behavior of the SRv6 version supported by its own node and the compression / decompression behavior of SRH, the reliance on compatibility is reduced, greatly simplifying the device's forwarding processing logic.

[0042] The relevant processing procedures are as follows: Figure 2 As shown.

[0043] In such Figure 3 In the multi-vendor equipment hybrid network shown, a customer service request requires traffic from A to F. The corresponding network path, ABCDEF as shown, requires traffic from three different vendors' network devices, i.e., network repeaters. Repeaters A and B belong to vendor A, repeaters C and D to vendor B, and repeaters E and F to vendor C. However, the details of SRH processing for SRv6 are not entirely the same for each vendor, and the SRH compression also differs. This means that there is an end-to-end SRv6 interoperability issue.

[0044] The controller will then calculate the forwarding path of the SRv6 Policy Candidate Path based on the network topology information, performance data, traffic information, and status information, as well as the service's requirements for path, performance, bandwidth, etc., such as path: ABCDEF.

[0045] Using the method of this invention, the controller will analyze and calculate the SRv6 SRH protocol support status of end-to-end path devices, and analyze the SID values ​​locally supported by all nodes from source A to destination F, as well as the BSIDs from B to C across vendors and from D to E across vendors.

[0046] For the SRH of the continuous repeater path for each vendor, the Segment List can be used directly. For the path from the device of the preceding vendor to the device of other vendors, the global BSID assigned by the controller can be used directly.

[0047] For example, the SID values ​​supported by this device for nodes ABCDEF are SID1, SID2, SID3, SID4, SID5, and SID6, respectively. The BSID from B to C is BSID1, and the BSID from D to E is BSID2.

[0048] Then, at the head node A, the SRH encapsulated in the path information of SRv6 is SID2, BSID1, BSID2; the information is as follows: Figure 4As shown. At this point, Segment List = 2, and forwarding is performed using SID2, which can be handled by node A.

[0049] At intermediate node C, after receiving BSID1, the device performs SRH replacement processing on BSID1, that is, it replaces BSID1 with the SID of the version of SRv6 supported by repeater C, such as uBID or G-SRv6. After the replacement, the path information encapsulated in the SRH on repeater C is: SID4, BSID2; the information is as follows: Figure 5 As shown. At this time, Segment List = 1, and forwarding is performed using SID4, which can be handled by node C.

[0050] At intermediate node E, after receiving BSID2, the device performs SRH replacement processing on BSID2, that is, it replaces BSID2 with the SID of the version of SRv6 supported by repeater E, such as Compress-SRH or Unified-SRH. After the replacement, on repeater C, the path information encapsulated by SRH is: SID6; the information is as follows: Figure 6 As shown. At this time, Segment List = 0, and forwarding is performed using SID6, which can be handled by the E node.

[0051] Therefore, each node on the end-to-end SRv6 path forwards packets according to the segment list of packet forwarding for each switching node calculated and allocated by the controller, and according to the SID forwarding behavior supported by this node. That is, consecutively connected repeaters of each vendor's common version are regarded as a forwarding segment, such as AB, CD, and EF are all a forwarding segment. Except for the head node, other forwarding segments are identified using a network-wide unified BSID allocated by the controller.

[0052] After the controller calculates and organizes the Segment List for each conversion node and the BSID-related configurations for devices across different vendors, it distributes Segment List entries to each conversion node device as needed (source node A, cross-vendor nodes C and E) through the network control protocol.

[0053] After obtaining this organized Segment List information, the forwarding device can forward local SRv6 packets according to the corresponding Segment List and BSID, based on its own support for the SRv6 protocol.

[0054] For more complex network situations, such as multiple paths from B to E, or multiple forwarding devices from different manufacturers to mitigate network issues, the method of this invention can be used for system processing without any essential difference.

[0055] Of course, other detection protocols such as OAM can also be deployed, with the basic approach being similar to BFD.

[0056] Furthermore, for multiple Candidate Paths in SRv6 Policy, the controller can also support path calculation and deployment for all Candidate Paths using the method of this invention. In this case, the Candidate Path itself is not special; it is essentially multiple Segment Lists, and each Segment List can support path forwarding across devices from different vendors.

[0057] Because this invention provides end-to-end full-path deployment, it offers a complete SRv6 path for devices from different vendors with varying levels of SRv6 policy support. This allows for better full-lifecycle, end-to-end deployment of SRv6 forwarding paths, thus facilitating the deployment of the SRv6 protocol and promoting network evolution based on the SRv6 protocol.

[0058] In another embodiment, the present invention provides a computer-readable storage medium storing a computer program that causes a computer to perform the controller-based cross-vendor protocol communication method of the foregoing embodiments.

[0059] In another embodiment, the present invention provides an electronic device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the controller-based cross-vendor protocol communication method of the foregoing embodiments.

[0060] In the embodiments disclosed in this application, a computer storage medium may be a tangible medium that may contain or store programs for use by or in conjunction with an instruction execution system, apparatus, or device. The computer storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of computer storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CDROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

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

[0062] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A method for cross-vendor protocol communication based on a controller, characterized in that, include: Obtain the SRv6 version information of all devices in the network and initialize the SIDSpaceID of the devices. Each SIDSpaceID corresponds to a SID value space and also to the device that applies this SID value space. Based on the SIDSpaceID allocation, BSIDs are uniformly assigned to devices; Calculate the end-to-end path for SRv6 based on the path requirements for SRv6. Based on the forwarding path information in the end-to-end path, organize the end-to-end path and the SegmentList of each forwarding path segment. The SegmentList consists of the SID and BSID of the devices on the path. Based on the end-to-end path and the Segment List of each forwarding path, generate the SRH of the end-to-end path and each forwarding path and distribute it to the corresponding nodes in segments. The device at the corresponding node forwards the SRv6 packets locally based on the obtained SRH.

2. The method for cross-vendor protocol communication based on a controller as described in claim 1, characterized in that: The SIDSpaceID of the initialization device is specifically: Devices from the same manufacturer that use the same SID allocation rules are grouped together and identified using SIDSpaceID.

3. The method for cross-vendor protocol communication based on a controller as described in claim 2, characterized in that: Different vendors' devices that support different SRv6 protocols correspond to different SID SpaceIDs.

4. The method for cross-vendor protocol communication based on a controller as described in claim 1, characterized in that: The calculation of the end-to-end path of SRv6 is specifically as follows: Based on the network-wide routing information, the end-to-end path of SRv6 is calculated according to business requirements to obtain the complete path of SRv6 from the source node to the destination node, including each logical path of the unified SRv6 policy.

5. A method for cross-vendor protocol communication based on a controller as described in claim 4, characterized in that: When calculating the path for each logical path, the differences in SRv6 protocol version support among the nodes on the path are not considered, nor are the differences in compression technology protocols for SRv6 SRH.

6. A method for cross-vendor protocol communication based on a controller as described in claim 1, characterized in that: The Segment List for each forwarding path is organized as follows: Sequentially obtain the SIDSpaceID corresponding to each forwarding path and parse the corresponding SRv6 protocol; Based on the parsed SRv6 protocol, generate a Segment List for this forwarding path.

7. A method for cross-vendor protocol communication based on a controller as described in claim 6, characterized in that: The Segment List for generating this forwarding path is specifically as follows: For each node on the forwarding path, the Segment List of the forwarding path is formed using the SID of the device corresponding to the node, according to the parsed SRv6 protocol. For nodes that span SIDSpaceID, the BSID assigned to the corresponding device is used to map the Segment List.

8. A method for cross-vendor protocol communication based on a controller as described in claim 7, characterized in that: The Segment List of the end-to-end path is organized as follows: For an end-to-end path, the segment list of the end-to-end path is formed using the segment list of each forwarding path and the BSID used to map the segment list.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program causes the computer to perform the controller-based cross-vendor protocol communication method as described in any one of claims 1-8.

10. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the controller-based cross-vendor protocol communication method as described in any one of claims 1-8.

Images