Routing transmission method and device and storage medium

Abstract

The invention provides a route transmission method and device and a storage medium, and the method comprises the steps: receiving a first route from a second communication device, and determining the capability information of the second communication device according to a first stub field corresponding to a first attribute field contained in the first route, so as to execute one of first processing and second processing, the first processing is to send a second route containing a second attribute field to the second communication equipment when the second communication equipment is determined to have the capability of performing specified processing on the second attribute field; the second processing is to trigger an alarm or not send the second route to the second communication equipment when the second communication equipment is determined not to have the specified processing capability according to the capability information. Thus, by expanding the first route to introduce the capability indication information, the specified processing capability for the second attribute field in the networking is determined, and the problem of traffic abnormality caused by inconsistent capabilities of processing the second attribute field between different devices in the actual service networking is solved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a routing transmission method, device and storage medium. Background Art

[0002] Ethernet Virtual Private Network (EVPN) is a Layer 2 virtual professional network. In actual application scenarios, EVPN can implement specific business functions by transmitting routes carrying specific extended community attributes (Extended Community) between node devices. As the volume of business continues to increase, the number of node devices in EVPN is also increasing. However, the support capabilities of each node device for the specific extended community attributes carried by the route may be different. For example, the new node device in EVPN supports the specified processing of specific extended community attributes, while the old node device does not support the specified processing of specific extended community attributes. In this way, when there are both new node devices and old node devices in EVPN, if the source node device still sends routes carrying specific extended community attributes, it will cause abnormal traffic forwarding due to the inconsistent capabilities of different node devices to process specific attribute fields. Summary of the invention

[0003] The embodiments of the present application provide a routing transmission method, device and storage medium, which are intended to solve the problem of forwarding anomalies caused by inconsistent capabilities of different devices to process specific attribute fields in actual business networking.

[0004] In a first aspect, an embodiment of the present application provides a routing transmission method, the method being applied to a first communication device, the method comprising:

[0005] receiving a first route from a second communication device;

[0006] Determining capability information of the second communication device according to a first stub field corresponding to the first attribute field included in the first route;

[0007] According to the capability information, one of a first process and a second process is performed, wherein the first process is to send a second route containing the second attribute field to the second communication device when it is determined according to the capability information that the second communication device has the capability to perform specified processing on the second attribute field; and the second process is to trigger an alarm or not send the second route containing the second attribute field to the second communication device when it is determined according to the capability information that the second communication device does not have the capability to perform specified processing on the second attribute field.

[0008] In a second aspect, a routing transmission method is provided, the method being applied to a second communication device, the method comprising:

[0009] A first route is sent to a first communication device, wherein the first route includes a first stub field corresponding to a first attribute field, and the first stub field corresponding to the first attribute field is used to instruct the first communication device to send a second route including a second attribute field.

[0010] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0011] one or more processors;

[0012] A memory having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement the routing transmission method as described in the first aspect or the second aspect above.

[0013] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the routing transmission method described in the first aspect or the second aspect is implemented.

[0014] In an embodiment of the present application, a first communication device receives a first route from a second communication device, determines the capability information of the second communication device according to the first attribute field contained in the first route and the first stub field corresponding to the first attribute field, and sends a second route containing the second attribute field to the second communication device when it is determined according to the capability information that the second communication device has the capability to perform specified processing on the second attribute field. In this way, by extending the first route, introducing capability indication information in the first route, and determining the specified processing capability for the second attribute field in the network, the problem of multiple packets or packet loss of traffic caused by inconsistent capabilities of processing the second attribute field between different devices in actual business networking is solved. When it is not possible to determine whether the capabilities of processing the second attribute field between the devices are consistent, the function of carrying the second attribute field in the second route can be enabled without causing traffic abnormalities, thereby ensuring the normal forwarding of traffic. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 This is the VPWS service scenario of EVPN.

[0016] Figure 2 EVPN vHub (Virtual Hub) / vSpoke (Virtual Spoke) service scenario;

[0017] Figure 3It is a schematic diagram of the steps of a routing transmission method provided by the present application;

[0018] Figure 4 yes Figure 3 Schematic diagram of sub-steps of step S102;

[0019] Figure 5 This is a schematic diagram of steps in another embodiment of the present application applied to an EVPN vHub / vSpoke scenario;

[0020] Figure 6 yes Figure 3 Schematic diagram of the specific steps in the EVPN VPWS (Virtual Private Wire Service) scenario;

[0021] Figure 7 yes Figure 6 Schematic diagram of sub-steps of step S302;

[0022] Figure 8 yes Figure 6 Schematic diagram of the specific steps in the EVPN vHub / vSpoke scenario;

[0023] Fig. 9 It is a node interaction diagram of the routing transmission method provided in an embodiment of the present application;

[0024] Fig.10 is a schematic diagram of the steps of a routing transmission method provided by another embodiment of the present application;

[0025] Fig.11 is a schematic diagram of the steps of a routing transmission method provided by another embodiment of the present application;

[0026] Fig.12 It is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the technical solution of the present application, the routing document transmission method, device and storage medium provided by the present application are described in detail below in conjunction with the accompanying drawings.

[0028] Hereinafter, example embodiments will be described more fully in conjunction with the accompanying drawings, but the described example embodiments may be embodied in different forms and should not be construed as being limited to the embodiments set forth herein. On the contrary, the purpose of providing these embodiments is to make this application thorough and complete, and will enable those skilled in the art to fully understand the scope of this application.

[0029] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0030] The terms used herein are only used to describe specific embodiments and are not intended to limit the present application. As used herein, the singular forms "a", "an" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, the presence of features, wholes, steps, operations, elements and / or components is specified, but the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof is not excluded.

[0031] In the description of the embodiments of the present application, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it can be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0032] In the description of the embodiments of the present application, any embodiment or design scheme of "exemplary", "for example" or "for example" should not be understood as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.

[0033] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "include", "comprises", "has" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0034] In order to facilitate understanding of the solutions of the embodiments of the present application and to provide a clear and concise description of the following embodiments, a brief introduction to the related technologies is first given:

[0035] (1) EVPN: It is a virtual private network (VPN) technology used for Layer 2 network interconnection. EVPN technology uses a mechanism similar to Border Gateway Protocol (BGP) / Multi-Protocol Label Switching (MPLS) IP VPN. By extending the BGP protocol and using the extended reachability information, the MAC address learning and publishing process between Layer 2 networks at different sites is transferred from the data plane to the control plane.

[0036] (2) Service Carving Time (SCT) is a clock synchronization time relative to the local provider edge router (PE). All PEs connected to a given Ethernet segment are clock synchronized. All PEs in this specific Ethernet segment use network protocols for clock synchronization (such as NTP, PTP, etc.). During the failure recovery of a device PE inserted in this specific Ethernet segment or an existing PE in the Ethernet segment, other PEs communicate the current time to their peer partners and the remaining time of the peer timer. From the perspective of the local PE that communicates the time, this time is called the service carving time.

[0037] (3) Virtual Private Wire Service (VPWS): an Ethernet point-to-point service model defined by IETF.

[0038] (4) EVPN vHub / vSpoke: An EVPN network consisting of vHub nodes and vSpoke nodes. Figure 3 , Figure 3 This is a network structure diagram of the EVPN vHub / vSpoke scenario in the related technology. There are multiple sites in the network, some of which serve as vHub nodes, and another part of which are vSpoke nodes. The sites serving as vHub nodes can deploy server applications, and each user network edge (Customer Edge, CE) device accesses the vHub node through the vSpoke node. The information exchange between the vSpoke nodes also needs to be transferred through the vHub node.

[0039] In actual application scenarios, EVPN can implement specific business functions by transmitting routes carrying specific extended community attributes between node devices. As the volume of business continues to increase, the number of node devices in EVPN is also increasing. However, the support capabilities of each node device for the specific extended community attributes carried by the route may be different. For example, the new node device in EVPN supports the specified processing of specific extended community attributes, while the old node device does not support the specified processing of specific extended community attributes. In this way, if the source node device still sends routes carrying specific extended community attributes when there are both new node devices and old node devices in EVPN, it will cause traffic multi-packet or packet loss problems due to the inconsistent processing capabilities of specific attribute fields between different node devices.

[0040] See also Figure 1 , Figure 1This is the VPWS service scenario of EVPN, including PE1, PE2, PE3, CE1, CE2, CE3, and multi-homed network (MHN) nodes. PE3 is the PE routing device of CE2. PE3 is a BGP neighbor relationship with PE1 and PE2 respectively. PE1 and PE2 are adjacent to the ES (Ethernet Segment) where CE1 and CE3 are located. The ES is dual-homed to PE1 and PE2 through CE1 and CE3. In this network, the following forwarding requirements exist: CE2 needs to forward traffic to one side of CE1 and CE3. In the actual network, the RT-1per EVI route will be advertised between PE1 and PE2, between PE1 and PE3, and between PE2 and PE3. When the AC interface on the PE1 node is down, the PE1 node and the PE2 node re-elect DF, and the PE2 node is promoted to the designated forwarder (Designed Fowarder, DF) role (that is, the backup DF device temporarily becomes the DF role), and the PE1 node is demoted to a non-designated forwarder (Non-Designed Fowarder, NDF) device. After the PE1 node is demoted to NDF, it will send the RT-1per EVI route with the backup mark to the PE3 node. After the PE2 node is promoted to DF, it will send the RT-1per EVI route with the primary mark to the PE3 node. The PE3 node will forward the traffic received from the CE2 node to the PE2 node device with the primary mark according to the backup and primary marks in the received RT-1per EVI route, ensuring normal forwarding of traffic.

[0041] exist Figure 1In the EVPN VPWS scenario, when the AC interface on the PE1 node is restored to UP, DF election can be performed between the PE1 node and the PE2 node. In order to enable the PE3 node to perform scheduled switchback and make the scheduled switchback of the PE3 node consistent with the scheduled switchback rhythm between PE1 and PE2 (the consistency of rhythm includes that the difference in the switchback time of each node is independent of the transmission delay of the RT-1per EVI route), that is, PE1 is promoted to DF and PE2 is downgraded to NDF. The SCT EC field needs to be added to the RT-1per EVI route to reserve the switchback time. However, the PE1 node and the PE2 node cannot know whether the PE3 node supports parsing the SCT EC field. If the PE3 node does not support parsing the SCT EC field, the switchback of the PE1 node and the PE2 node will cause packet loss or multiple packets of the forwarding traffic of the PE3 node. In particular, when the primary DF device (such as PE1) publishes the RT-1per EVI route with the Primary tag and SCT EC before the scheduled switchback time, and the backup DF device (such as PE2) publishes the RT-1per EVI route with the Backup tag and SCT EC before the scheduled switchback time, for the nodes that can identify the SCT EC in the RT-1per EVI, they can switch the corresponding unicast stream forwarding to PE1 after the scheduled switchback time expires. However, for the nodes that cannot identify the SCT EC in the RT-1per EVI, they immediately switch the corresponding unicast stream forwarding to PE1 after receiving the RT-1per EVI route with the Primary tag. Therefore, when there are nodes that can identify the SCT EC in the RT-1per EVI and nodes that cannot identify the SCT EC in the RT-1per EVI in the network, the forwarding behaviors on different nodes are inconsistent, resulting in abnormal forwarding after the unicast traffic on the node that cannot identify the SCT EC in the RT-1per EVI is forwarded to the PE1 / PE2 node.

[0042] See also Figure 2 , Figure 2This is the vHub / vSpoke service scenario of EVPN, including VH1 node (virtual Hub, vHub) node, VS1 node (virtual Spoke, vSpoke) node, VS2 node and CE1 node. The vHub / vSpoke node devices form a network in accordance with the definition in the draft-ietf-bess-evpn-virtual-hub standard. In this scenario, VS nodes do not import each other's RT-1per ES routes and IMET routes, and the RT-1per ES routes carry the Originating PE-TLV protocol (Originating PE TLV, OPE TLV) field. When the VH1 node republishes the RT-1perES route received from the VS1 node to the VS2 node, it needs to rewrite the ESI label of the RT-1per ES route to the locally allocated label. At the same time, when the VH1 node receives the IMET route from the VS1 node, it shall not republish the IMET route to the VS2 node.

[0043] exist Figure 2 In the EVPN vHub / vSpoke scenario, when the VS1 node sends an OPE TLV in the Ethernet auto-discovery route per ES (RT-1per ES route), the VH1 node will rewrite the ESI label of the AD perES route and keep the OPE TLV unchanged in accordance with the requirements of draft-heitz-bess-evpn-option-b-01. This will cause the VS2 node to be unable to encapsulate the rewritten ESI label into the data message forwarded to the VS1 node through the VH node, causing abnormal traffic forwarding from the VS2 node to the VS1 node.

[0044] In order to solve the problem of multiple packets or packet loss caused by inconsistent processing capabilities of specific attribute fields between different node devices, this application provides a routing transmission method, please refer to Figure 3 , Figure 3 A schematic diagram of the steps of a routing transmission method provided by the present application. The embodiments of the present application may include but are not limited to the following steps.

[0045] Step S101: receiving a first route from a second communication device.

[0046] Step S102: determining capability information of the second communication device according to the stub field corresponding to the first attribute field included in the first route.

[0047] Step S103: executing one of the first process and the second process according to the capability information.

[0048] It should be understood that the first communication device and the second communication device here may indicate different devices in different EVPN scenarios.

[0049] It should be understood that the first attribute field here may specifically be a corresponding field carrying the first type of indication information indicating that the route publisher has the ability to publish the second attribute in the specified route, which belongs to the extended field in the route; the first stub field here may specifically represent a field carrying the second type of indication information used to indicate that the second attribute received from the specified route has the specified processing capability, which also belongs to the extended field in the route. Among them, the route used to carry the first attribute field and the route used to carry or receive the second attribute may not be the same type of route. Among them, the second type of indication information may include the fourth type of indication information and the fifth type of indication information, the fourth type of indication information may be a separate indication of the specified processing capability for the second attribute received from the specified route, and the fifth type of indication information may be a common indication with the first attribute field in the same route of the specified processing capability for the second attribute received from the specified route. It can be understood that the first type of indication information does not need to simultaneously indicate that the route publisher has the ability to parse or process the second attribute received in the specified route.

[0050] It should be understood that the first stub field corresponding to the first attribute field may be a field containing second-type indication information for a second attribute of the same category as the first-type indication information contained in the first attribute field. The first attribute field may be carried only in the first route, only in the third route, or in both the first route and the third route. When it is carried in both the first route and the third route, the first route and the third route may have first attribute fields with different values.

[0051] It should be understood that the third route here refers to a route sent from a device having symmetry with the first communication device to the second communication device.

[0052] It should be understood that the first processing in step S103 is to send the second route containing the second attribute field to the second communication device when it is determined according to the capability information that the second communication device has the capability to perform the specified processing on the second attribute field. The second processing is to trigger an alarm or not send the second route containing the second attribute field to the second communication device when it is determined according to the capability information that the second communication device does not have the capability to perform the specified processing on the second attribute field.

[0053] It should be understood that, in the first route, the first attribute field may include multiple specific fields, each specific field corresponds to different information in the DF switchback function or the vHub function; the first stub field may also include multiple specific fields, corresponding one-to-one to the specific fields in the multiple first attribute fields. The technicians in this field can determine the specific number of fields of the first attribute field and the specific number of fields corresponding to the first stub field according to actual conditions, and this application does not limit this.

[0054] For the second communication device, the first route issued by the second communication device is the route issued after being processed by the second communication device; while in the first communication device, if the first communication device finds that the first route does not carry the first attribute field and the corresponding first stub field, or the first route only carries the first attribute field but does not carry the corresponding first stub field, or the first attribute field and the corresponding first stub field carried by the first route do not meet the specified rules, it can be considered that the second communication device lacks the processing capability for specific functions, cannot correctly process the specific information in the route, or lacks the function of processing specific information, thereby determining the capability information of the second communication device.

[0055] It should be understood that the specific forms of determining the capability information of the second communication device according to the first attribute field and the corresponding first stub field are various. For example, the second communication device performs specified processing on the first attribute field in the route received from the same device as the first communication device, generates a first stub field according to the first attribute field, and after the first communication device receives the first route, compares the first stub field in the first route with the first attribute field. If the two are different, it proves that the second device has the specified processing capability; for another example, the second communication device performs specified processing on the first attribute field in the route received from the same device as the first communication device to obtain a first stub field corresponding to the first route, generates a first route according to the first stub field and the first attribute field generated according to the local configuration, and the first communication device performs the same processing on the first attribute field in the first route as the processing performed by the second device when obtaining the first stub field from the first attribute field to obtain a processing result, and compares the processing result with the first stub field. If the two match, it proves that the second device has the relevant capability, etc. Those skilled in the art can determine the specific form of determining the capability information of the second communication device according to the first attribute field and the corresponding first stub field according to actual conditions, and this application does not limit this.

[0056] It should be understood that in the process of the first communication device actually confirming the relevant capabilities of the second communication device, it is necessary to extract information from the relevant positions in the route. When the second communication device does not have the specified processing capability, in the first route sent by the second communication device to the first communication device, the route generated by the second communication device according to the set routing protocol is used as the first route. The first route may only carry the first attribute field, or may not carry any first attribute field and first stub field. When the first communication device extracts information from the first attribute field position and the position corresponding to the first stub field in such a first route, the first communication device cannot extract the first attribute field or the first stub field, or the first communication device extracts the first attribute field and the first stub field that do not meet the specified rules, or the first communication device only extracts the first attribute field. At this time, the first communication device can learn that the second communication device does not have the specified processing capability. The following are some embodiments of steps S101 to S103:

[0057] For example, in Figure 1 In the EVPN VPWS scenario, the PE1 node is set as the main DF device, and the PE2 node is set as the standby DF device. The first communication device in step S101 can be specifically Figure 1 The PE2 node in the second communication device may be Figure 1 PE3 node in the.

[0058] It should be noted that when there are no faults on the given ES on the PE1 node and the PE2 and PE1 nodes, the device that should become the DF role of the ES is called the main DF device, and the other devices are called the backup DF devices of the ES. At this time, the backup DF device is the NDF role of the ES. However, when a given ES fails on the main DF device, the backup DF device can also temporarily become the DF role of the ES. Therefore, the device that currently plays the DF role of a given ES is not necessarily the main DF device of the ES.

[0059] It should be understood that in the EVPN VPWS scenario, the first route in step S101 may refer to one of the RT-1 (Type 1 Route of EVPN, the first type of EVPN route) route and the RT-4 route (Type 4 Route of EVPN, the fourth type of EVPN route), which is determined according to the custom routing protocol method in the scenario, and the second route refers to the RT-1 route. It should be noted that the first route is a route sent by a device symmetrical to the first communication device received by the second communication device, and the received route is processed and parsed according to the receiving and sending processing method set by the second communication device itself, thereby generating a route.

[0060] It should be understood that the first route here includes multiple fields. For example, the RT-1 route may include necessary fields such as the Route Distinguisher (RD) field, the Ethernet Segment Identifier (ESI) field, the Ethernet Tag ID (ETI) field, and the MPLS Label (MPLS Label) field, and may also include multiple extended fields, such as an identification field of a certain function; for example, the RT-4 route field includes necessary fields such as the RD field, the ESI label field, the IP Address Length (IPAL) field, and the Originating Router's IP Address (ORIP) field, and may also include multiple extended fields. A person skilled in the art may determine the specific fields included in the first route based on a customized routing protocol in the scenario, and the present application does not limit this. It should be noted that the first stub field in the first route may be generated by the second communication device based on the first attribute field.

[0061] Exemplarily, when the first route is a per-EVI Ethernet auto-discovery route (RT-1per EVI) route, the first attribute field may specifically be a designated forwarder election extended community attribute (DF Election Extended Community, DF Election EC) field, the first stub field may be a mirrored TLV field corresponding to the first attribute field, the second attribute field may be a service caring time extended community attribute (Service Caring Time Extended Community, SCT EC) field, the specified processing capability may be the first communication device's parsing capability for the SCT EC field, and the second route may be a per-RT-1per EVI route.

[0062] Exemplarily, when the first route is an RT-4 route, the first attribute field may specifically be a DF Election EC, the first stub field may be a mirrored TLV field corresponding to the first attribute field, the second attribute field may be an SCT EC field, the specified processing capability may be the parsing capability of the second communication device for the SCT EC field, and the second route may be an RT-4 route.

[0063] It should be understood that the type of the route sent by the PE1 node in the EVPN network and the first route received by the PE3 node here (corresponding to the second communication device) can be the same. For example, if the route sent by the PE1 node to the second communication device can be an RT-1 route, then the first route actually sent by the PE3 node after processing can be an RT-1 route; for another example, if the route sent by the PE1 node to the PE3 node can be an RT-4 route, then the first route actually sent by the PE3 node after processing can be an RT-1 route; for another example, if the route sent by the PE1 node to the PE3 node can be an RT-1 route, then the first route actually sent by the second communication device after processing can be an RT-4 route, etc. A person skilled in the art can determine the specific types of the route sent by the main DF device in the EVPN network and the first route received by the second communication device according to actual conditions, and this application does not limit this.

[0064] For example, when the embodiments of the present application are applied in Figure 1 In the EVPN VPWS scenario shown, the first route in this example is the RT-1per ES route, and the first attribute field is specifically the DF Election EC field, which is used to carry DF scheduled reversal capability information; the first stub field is a mirror TLV field corresponding to the DF Election EC field; the second attribute field can be the SCT EC field, which carries scheduled reversal information and is used to schedule the reversal time; the specified processing capability can be the PE3 node's parsing capability for the SCT EC field. In the EVPN VPWS networking, according to the custom routing protocol, it is carried out in the RT-1per ES route, and the RT-1per ES route extension carries the DF Election EC field and the corresponding mirror TLV field. The PE1 node can send a route that does not carry the first stub field but only carries the first attribute field to the PE3 node.

[0065] If the PE3 node has the ability to parse the SCT EC field that carries the timed switching back information, it means that the PE3 node can match the traffic forwarding state of the first communication device when the PE1 node switches back to the first communication device at the scheduled time, and there will be no traffic forwarding abnormalities. The PE3 node with parsing capability will process the first attribute field in the route sent by the PE1 node, and generate the corresponding mirror TLV field based on the DF Election EC field, and extend the two fields to send the RT-1per ES route (corresponding to the first route) to the PE2 node. Therefore, the RT-1per ES route received by the PE2 node (corresponding to the first communication device) will be extended to carry the DF Election EC field and the mirror TLV field corresponding to the DF Election EC field, and the capability will be judged based on the DF Election EC field and the mirror TLV field, so as to determine whether the PE3 node has the ability to parse the SCT EC field. When the PE3 node has the ability to parse the SCT EC field, the PE2 node can carry the SCT EC field in the RT-1per EVI route sent to the PE3 node. The PE3 node will parse the SCT EC field carried in the RT-1per EVI route, so that the PE3's own timed switchback for unicast forwarding is synchronized with the DF timed switchback between the PE1 node and the PE2 node.

[0066] It can be understood that, since the main DF device (such as PE1) and the backup DF device (such as PE2) are symmetrical with respect to the second communication device (such as PE3), the second communication device will also perform similar processing on the RT-1per ES route carrying DF Election EC received from the backup DF device and cause it to send a route similar to the first route to the main DF device. The main DF device can also determine in the same way whether the second communication device has the specified processing capability for the SCT EC field received from the RT-1per EVI route based on the route.

[0067] If the PE3 node is unable to parse the DF Election EC field, the PE3 node is unable to parse the DF Election EC field according to its own configuration to generate the corresponding mirror TLV field, nor is it able to generate a DF Election EC field for the first route that conforms to its own configuration. When the first communication device receives the first route, it can extract and judge the DFElection EC field and the relevant position of the mirror TLV field in the first route. When the DFElection EC field (corresponding to the first attribute field) and the corresponding mirror TLV field (corresponding to the first stub field) in the first route meet the relevant conditions, the first communication device determines that the second communication device cannot perform specified functions such as timed switching for unicast message forwarding.

[0068] For example, in Figure 2 In the EVPN vHub / vSpoke scenario, the first communication device in step S101 is Figure 2 Specifically, the VS2 node and the second communication device may be Figure 2 Specifically, it may be a VH1 node.

[0069] Exemplarily, when the embodiment of the present application is applied in an EVPN vHub / vSpoke scenario, the first route may refer to the RT-1per ES route, the first attribute field may include an ESI label field, an OPE TLV field, and a Nexthop field, the first stub field may include an ESI label stub field, an OPE TLV stub field, and a Nexthop stub field corresponding to the first attribute field, the second attribute field may be the OPE TLV field in the second route, the specified processing capability may be the VH1 node's ability to rewrite the OPE TLV field, and the VS2 node may also be set to trigger an alarm when the VH1 node is determined to not have the ability to rewrite the OPE TLV field.

[0070] Exemplarily, the VS1 node (which is symmetrical with the first communication device) may send a message carrying an ESI label field, an OPE TLV field, a Nexthop field, a corresponding ESI label stub field, a corresponding OPE TLV stub field, and a corresponding Nexthop stub field to the VH1 node.

[0071] It should be understood that in Figure 2In the EVPN vHub / vSpoke scenario, for data packets sent between VS1 and VS2 nodes, according to the definition of networking in draft-ietf-bess-evpn-virtual-hub, the originating node (such as VS2 node) of the data packet needs to be transferred through the vHub (such as VH1) node, and then transferred by the VH1 node to the receiving node (such as VS1 node).

[0072] When the VH1 node can rewrite the original OPE TLV field, it means that the VH1 node can enable the VS2 node (corresponding to the first communication device) to encapsulate the ESI label field rewritten by the VH1 node into the data message that needs to be transferred by the VH1 node, and send the encapsulated data message to the VS1 node, thereby ensuring the normal forwarding of traffic. The VH1 node will rewrite the original ESI label field, OPE TLV field, and Nexthop field according to its own configuration, and will not rewrite the first stub field corresponding to the original first attribute field, and carry the rewritten ESI label field, OPE TLV field, and Nexthop field in the RT-1per ES routing. Since the ESI label field, OPE TLV field and Nexthop field have all changed compared to the corresponding information in the first stub field after passing through the VH1 node, when the VS2 node receives the RT-1per ES route, VS2 knows that the ESI label field, OPE TLV field and Nexthop field in the RT-1perES route have been modified as a set by the VH1 node, and the modification satisfies that the modified ESI label is allocated by the node identified by the modified OPE TLV, thereby determining that the VH1 node has the ability to perform specified rewrites on the original OPE TLV field.

[0073] When the VH1 node cannot rewrite the original OPE TLV field, it means that the VH1 node cannot make the VS2 node encapsulate the rewritten ESI label into the data message sent to the VS1 node, and an ES inner loop will occur. The VH1 node will rewrite the original ESI label field and Nexthop field according to its own configuration, but will not rewrite the OPE TLV field and the first stub field corresponding to the original first attribute field. The VS2 node receives the RT-1per ES route, but in this route, the ESI label field is allocated by the VH1 node, and the OPE TLV field identifies the VS1 node, which proves that the VH1 node is abnormal. If the VS2 node sends the RT-1per ES route with the OPE TLV field to the VH1 node, it will cause similar traffic forwarding anomalies. At this time, the VS2 node will trigger an alarm and notify the network management to handle the situation of the VH1 node.

[0074] The embodiment of the present application expands the first route, introduces capability indication information into the first route, determines the designated processing capability for the second attribute field in the network, and solves the problem of abnormal traffic caused by inconsistent capabilities of processing the second attribute field between different devices in the actual business network. When it is determined that the capabilities of processing the second attribute field between the devices are inconsistent, the function of not carrying the second attribute field in the second route prevents the abnormal traffic from being caused, thereby ensuring the normal forwarding of the traffic. When it is determined that a specific device will cause an abnormality due to its lack of designated capability to process the second attribute field, an alarm can also be triggered to notify the network management to perform corresponding processing, thereby ensuring the normal operation of the actual business network.

[0075] See also Figure 4 , Figure 4 for Figure 3 Schematic diagram of sub-steps of step 102 in FIG. In some possible embodiments of the present application, step S102 may include but is not limited to the following sub-steps.

[0076] Step S201: When the first attribute field in the first route matches the corresponding first stub field, it is determined that the second communication device has the ability to perform specified processing on the second attribute field.

[0077] Step S202: When the first route does not include the first stub field corresponding to the first attribute field, it is determined that the second communication device does not have the ability to perform specified processing on the second attribute field.

[0078] Exemplarily, step S201 may specifically be:

[0079] Step S201: When a first stub field corresponding to a first attribute field exists in a first route, it is determined that the second communication device has the capability of performing specified processing on a second attribute field.

[0080] For example, for Figure 1In the EVPN VPWS scenario shown, when the first stub field corresponds to the first attribute field in the first route, and the first stub field is a field that the PE3 node adds to the first route when it can perform specified processing on the first attribute field of the route sent by the PE1 node. If the first route sent by the PE3 node cannot carry the first stub field, the inability to carry the first stub field indicates that the PE3 node cannot perform specified processing on the DF Election EC field of the route sent by the PE1 node, and further indicates that regardless of whether the second route sent by the first communication device carries the SCT EC field, the PE3 node will not forward unicast traffic through the first communication device until the first communication device is upgraded to the DF role according to the time reserved by the second attribute field. Therefore, when the first communication device sends the second route to the second communication device, it does not carry the SCT EC field.

[0081] Exemplarily, the first route in this example is the RT-1per ES route, the first attribute field is specifically the DFElection EC field, and the DF Election EC field is used to carry the timed re-switching capability information; the first stub field is the mirror TLV field corresponding to the DFElection EC field; the second attribute field can be the SCT EC field, and the SCT EC field carries the timed re-switching information and is used to reserve the re-switching time; the specified processing capability can be the PE3 node's ability to parse the SCT EC field corresponding to the ES received from the PE that is not adjacent to the specific ES. In the EVPN VPWS networking, according to the custom routing protocol, the DF Election EC field and the corresponding mirror TLV field are extended to carry in the RT-1per ES route. In the RT-1per ES route sent by the PE3 node, the mirror TLV field is a mirror of the DF ElectionEC field information in the route sent by the PE1 node. When the second communication device needs to send the first route, the second communication device needs to first generate a mirror TLV field based on the DF Election EC field in the RT-1per ES route sent by the PE1 node, and then parse the DF Election EC field according to its own configuration to generate a DF Election EC field that conforms to its own configuration to generate the first route.

[0082] The corresponding mirror TLV field is filled in by the PE3 node according to the DF Election EC field in the route sent by the PE1 node. When the first stub field (corresponding to the mirror TLV) does not exist in the RT-1per ES route (corresponding to the first route) sent by the PE3 node, it indicates that the PE3 node does not have the ability to parse the SCT EC field. Such a PE3 node cannot process the SCT EC field, and thus cannot perform a scheduled switchback according to the SCT EC field of the RT-1per EVI route sent by the PE2 node.

[0083] See also Figure 5 , Figure 5 This is a schematic diagram of steps in another embodiment of the present application applied to an EVPN vHub / vSpoke scenario. In some possible embodiments of the present application, step S102 may include but is not limited to the following sub-steps.

[0084] Step S202: When the first route does not include a first stub field corresponding to the first attribute field, it is determined that the second communication device does not have the ability to perform designated processing on the second attribute field.

[0085] For example, in Figure 2 In the EVPN vHub / vSpoke scenario, in the RT-1per ES route sent by the VH1 node, the first attribute field may include an ESI label, a Nexthop field, and an OPE TLV field, and the first stub field may include the corresponding ESI label stub field, the Nexthop stub field, and the OPE TLV stub field. Here, "the first route does not include a first stub field that satisfies the specified rule with the first attribute field" may include two situations, one is that the first route does not include any first stub field, and the other is that the first stub field included in the first route is the same as its corresponding first attribute field.

[0086] For the former of the above two situations, the first stub field belongs to the basis for judging the rewriting of the first attribute field. If the first stub field is missing, regardless of whether the VH1 node has the ability to rewrite the OPE TLV, the VS2 node cannot judge the OPE TLV field rewriting ability of the VH1 node in the absence of the first stub field. In order to avoid abnormal traffic forwarding, the VS2 node will adopt the conservative strategy of "assuming that the VH1 node does not have the ability to rewrite the OPE TLV field" to trigger an alarm or not carry the second attribute field in the second route sent to the VH1 node. When the RT-1per ES route received by the VS2 node does not contain the first stub field, the VS2 node cannot determine whether the OPE TLV field has been rewritten. The VS2 node can assume that the sending node of the RT-1per ES route does not have the specified rewriting ability for the OPE TLV field according to the above conservative strategy, so as to avoid the rewritten ESI label field cannot be encapsulated by the first communication device into the data message sent to the VS1 node, thereby causing abnormal forwarding of the corresponding traffic.

[0087] In the specific implementation process of the example given in step S202, for the former case, the IP value can be used to judge the rewriting of the OPE TLV in the first route. Exemplarily, in addition to receiving the RT-1per ES route from the VH1 node, the VS2 node can also receive the IMET route from the VH1 node, and the IMET route will also include the Nexthop field. When the VS2 node receives the RT-1per ES route and finds that the route does not contain the first stub field, the VS2 node will obtain the IP value of the OPE TLV field in the first attribute field, and obtain the ORIP value of the IMET route with the same Nexthop as the RT-1per ES route. When the ORIP value is different from the IP value of the OPE TLV field, the VS2 node considers that the VH1 node does not have the ability to rewrite the OPE TLV.

[0088] For the latter of the above two situations, according to the networking definition, the VH1 node needs to rewrite the ESI label field and Nexthop field contained in the route sent to the VH1 node. When the VH1 node does not have the ability to rewrite the OPE TLV, after receiving it, the VS2 node can know through the ESI label field, Nexthop field, OPE TLV field and the corresponding stub fields of the first route that the ESI label field and Nexthop field in the first route have changed relative to the original ESI label field and Nexthop field, while the OPE TLV field in the first route has not changed relative to the original OPE TLV field, and the OPE TLV field has not changed, which means that the first attribute field and the first stub field cannot meet the following specific specified rules: the ESI label field, Nexthop field, and OPE TLV field of the first route have all changed relative to the corresponding fields in the first field. Therefore, the VH1 node cannot enable the VS2 node to encapsulate the rewritten ESI label field into the data message sent to the node that is symmetrical with the VS2 node (such as the VS1 node), so that the relevant data cannot be forwarded normally through this route. Therefore, when this VS2 node sends the second route (corresponding to the RT-1per ES route) to the second communication device, it does not carry the OPE TLV field that identifies the VS2 node itself.

[0089] For example, for Figure 2 In the EVPN vHub / vSpoke scenario shown, the second route may be an RT-1per ES route, the second attribute field is an OPE TLV field in an RT-1per ES route that is not adjacent to an ES of a second communication device (such as a VH1 node), the first route may not have a first attribute field, the first attribute field is included in a specific route, the ES to which the specific route belongs is not adjacent to a second communication device (such as a VH1 node), the specific route may be an RT-1per ES route sent from a second communication device (such as a VH1 node) to a first communication device (such as a VS2 node), and the first attribute field may be an OPE TLV field. The first route is an IMET route, the first attribute field may include an ESI label field, a Nexthop field, and an OPE TLV field, and the first stub field is an "R" flag carried in the IMET route.

[0090] Exemplarily, the "R" flag is defined to indicate that the vHub node has both the standard processing capability of OPE TLV (the capability defined by "draft-heitz-bess-evpn-option-b-01") and the flag of the ability to rewrite the OPE TLV in the RT-1perES route corresponding to the non-adjacent ES. At this time, if the "R" flag is carried in the IMET route, the first route can be the IMET route (corresponding to the first route), and the first stub field is the "R" flag (corresponding to the first stub field). At this time, the receiving end of the IMET route (corresponding to the VS2 node) will determine whether the second communication device has the ability to rewrite the OPE TLV field, that is, when the "R" flag exists in the IMET route, it is determined that the second communication device has the ability to rewrite the OPE TLV field. It can be understood that at this time, the first stub field contains the fourth type of indication information, the first attribute field is the field in the third route, and the first stub field corresponding to the first attribute refers to the indication information used to indicate the ability to rewrite the OPE TLV.

[0091] Figure 4 The embodiments are applied to Figure 3 In the EVPN vHub / vSpoke scenario shown in the figure, Figure 4 Step 201 in the method may specifically be:

[0092] Step S201a: when there is an "R" flag corresponding to the first attribute field included in the third route in the IMET route, it is determined that the second communication device has the ability to perform specified processing on the second attribute field.

[0093] For example, Figure 2 For example, when the VH1 node has the ability to rewrite the OPE TLV field, the VH1 node will add an "R" flag to the IMET route sent to the VS2 node. Correspondingly, the VH1 node will also rewrite the ESI label field, Nexthop field, and OPE TLV field in the RT-1per ES route sent by the VS1 node to generate a route sent to the RT-1per ES.

[0094] It should be understood that for the latter of the above two situations, the specific rules in the above content belong to one of the latter situations. When the VH1 node does not comply with the networking definition to rewrite the original ESI label field or when the VH1 node does not comply with the networking definition to rewrite the original Nexthop field, it is also an abnormal situation. This example only focuses on describing the rewriting capability of the OPE TLV field.

[0095] See also Figure 6 , Figure 6 for Figure 3The following is a diagram of the specific steps in the EVPN VPWS scenario. Figure 1 In the EVPN VPWS scenario shown, the EVPN VPWS scenario is in single-active mode. Figure 1 The steps in include but are not limited to the following sub-steps:

[0096] Step S301: When the first route includes a first stub field corresponding to the DF Election EC field, it is determined that the second communication device has the ability to parse the SCT EC field sent by the first communication device.

[0097] It should be noted that the first stub field is a field that the sending end node of the first route adds to the first route when the sending end node of the first route can perform specified processing on the first attribute field of the specified route sent by the receiving end node of the first route. Among them, the first attribute field is a field that identifies that the sending end of the route has the ability to publish the second attribute.

[0098] Step S302: When it is determined that the second communication device has the ability to parse the SCT EC field, a second route including the SCT EC field is sent to the second communication device.

[0099] Below is Figure 6 Specific embodiments of the embodiments in a specific EVPN scenario may include but are not limited to the following embodiments 1 and 2.

[0100] Embodiment 1:

[0101] In this embodiment, the first route is RT-1per ES route, the first attribute field is DF Election EC field, the second attribute field is SCT EC field, the first stub field is a mirrored TLV field corresponding to the DF Election EC field, and the second route is RT-1per EVI route.

[0102] Embodiment 1 is applied to Figure 1 In the EVPN VPWS networking shown in the figure, Figure 6 The steps in can be specifically as follows:

[0103] Step S301a: When the RT-1per ES route contains the DF Election EC field and the mirror TLV field corresponding to the DF ElectionEC field, it is determined that the second communication device has the ability to parse the SCT EC field in the second route sent by the first communication device.

[0104] Step S302a: When it is determined that the second communication device has the ability to parse the SCT EC field, a second route including the SCT EC field is sent to the second communication device.

[0105] For example, when the first embodiment is applied to Figure 1 When the EVPN VPWS network is used:

[0106] If the PE3 node is able to parse the SCT EC field, after the PE3 node receives the RT-1per ES route sent by the PE1 node, even though the PE3 node is not adjacent to the ES to which the RT-1per ES route belongs, the PE3 node will parse the DF Election EC field and generate a mirror TLV field in the RT-1per ES route sent to the PE2 node. After the PE3 node parses the DFElection EC field, it can generate a DF Election EC field according to its own configuration. This DFElection EC field is different from the DF Election EC field carried in the RT-1per ES route sent by the PE1 node. The PE2 node determines that the PE3 node has the ability to parse the SCT EC field carried in the second route sent by the PE2 node based on the DF Election EC field and the mirror TLV field in the first route. If the PE3 node cannot parse the SCT EC field, the DF Election EC word in the first route and the corresponding mirror TLV field are consistent.

[0107] When the second communication device has the ability to parse and process the SCT EC field corresponding to the non-adjacent ES, after the first communication device determines that it should be upgraded to the DF role and before it actually upgrades to the DF role, the first communication device and the third communication device determine the synchronization switching time, the first communication device generates the SCT EC field according to the determined synchronization switching time, and extends the SCT EC field to the RT-1per EVI route, and sends the RT-1per EVI route with the SCTEC field to the second communication device, and the second communication device obtains the scheduled synchronization switching time after parsing the second route. In the process of the first communication device actually being upgraded to the DF role, the first communication device, the second communication device and the PE1 node can achieve synchronous switching and routing at the scheduled switching back time.

[0108] In some possible specific embodiments of the first embodiment, the role of the mirrored TLV field corresponding to the DF Election EC field can be replaced by the third indication information corresponding to the third route.

[0109] It should be understood that the third route here may be a route received by the second communication device from the third communication device, and the first communication device and the third communication device are symmetrical devices relative to the second communication device.

[0110] For example, in Figure 1 In the EVPN VPWS networking in the example, the third communication device can be a device of the same type as the PE1 node. The PE1 node and the PE2 node are symmetrical to each other, and this symmetry is Figure 1 In the EVPN VPWS scenario shown, the ES where the CE1 node is located is dually owned by the PE1 node and the PE2 node. The third indication information here is the value of the DF Election EC field in the third route or indication information used to indicate that the DF Election EC exists in the third route.

[0111] It can be understood that when the third indication information is the indication information used to indicate in the first route that there is a DF Election EC in the third route, the third indication information can independently indicate that the second communication device has the ability to process the DF Election EC in the third route, so that the third indication information can independently indicate that the second communication device has the ability to process the SCT EC field in routes of the same type as the second route, such as the RT-1per EVI route that has the same ESI as the third route and comes from the same node, so that the third indication information can independently indicate that the second communication device has the ability to process the SCT EC field in the second route (regardless of whether the second route and the third route have the same ESI). Therefore, the third indication information is the fourth type of indication information at this time.

[0112] See also Figure 7 , Figure 7 for Figure 6 In some specific embodiments of the first embodiment, for multiple second communication devices, step S302 includes but is not limited to the following sub-steps:

[0113] Step S3021: When it is determined that all second communication devices have the capability of processing the second attribute field, a second route including the second attribute field is sent to one of the second communication devices.

[0114] Step S3022: When it is determined that at least one second communication device does not have the ability to process the second attribute field, a second route that does not include the second attribute field is sent to any second communication device.

[0115] In such Figure 1 In the embodiment shown, exemplary:

[0116] Step S3021: When it is determined that the PE3 node and the devices of the same type as the PE3 node are capable of processing the SCT EC field, an RT-1per EVI route containing the SCT EC field is sent to one of the devices of the same type as the PE3 node.

[0117] When the PE3 node and the devices similar to the PE3 node have the ability to process the SCT EC field, it indicates that the PE3 node and the devices similar to the PE3 node can be matched with the PE2 node and the PE1 node for forwarding, and each of the PE3 node and the devices similar to the PE3 node can select a route and implement switching at the scheduled switching back time, and the switching back time is synchronized, so that all second communication devices can transmit traffic through the first communication device without interfering with each other.

[0118] Step S3022: When it is determined that at least one of the PE3 node and the devices of the same type as the PE3 node does not have the ability to process the SCTEC field, an RT-1per EVI route that does not include the SCT EC field is sent to the PE3 node and any one of the devices of the same type as the PE3 node.

[0119] If one of the devices of the same type as the PE3 node does not have the ability to process the SCT EC field, it indicates that the device is not compatible with the forwarding of the PE2 node and the PE1 node. The device cannot implement switching at the scheduled switching time, and the switching time is not synchronized, which may even lead to traffic interruption.

[0120] Embodiment 2:

[0121] In this embodiment, Figure 1 The second embodiment is described.

[0122] In the second embodiment, the first route may be RT-4 route. The RT-4 route protocol is Figure 1 The networking is customized so that the RT-4 route can include a DF Election EC field (corresponding to the first attribute field), an ES-Import RT field, and an RT set in the RT-1per ES route corresponding to the RT-4 route (corresponding to the first stub field), and the DF Election EC field can include a "T" flag bit with a value of 1. Compared with the first embodiment, the DF Election EC field is carried by the RT-4 route. The ES-Import RT field can enable the first communication device and the third communication device to match the local ESI instance, and the RT set can enable the first communication device and the second communication device to match the local EVI instance. The second route can be a RT-1perEVI route.

[0123] Embodiment 2 is applied to Figure 1 In the EVPN VPWS networking shown in the figure, Figure 6 The steps in can be specifically as follows:

[0124] Step S301c: When the DF Election EC field in the RT-4 route carries a "T" flag with a value of 1 and the RT set of the RT-4 route contains an exported route target that matches the EVPN instance to which the second route belongs, it is determined that the second communication device has the ability to parse the SCT EC field in the second route issued by the first communication device.

[0125] Step S302c: when it is determined that the second communication device has the ability to parse the SCT EC field, a second route including the SCT EC field is sent to the second communication device.

[0126] For example, when the second embodiment is applied to Figure 1 When the EVPN VPWS network is used:

[0127] The RT-4 route sent by the PE1 node to the PE3 node includes the DF Election EC field and the RT set, where the RT set includes the export route target RT of the EVPN instance to which the second route belongs, and the DF Election EC field includes a "T" flag bit with a value of 1.

[0128] It should be understood that the RT set here may be a set of export route targets of all EVPN instances to which a given ES of the PE1 node and the PE2 node is attached, and the export route target corresponding to each EVPN instance is included in this RT set.

[0129] If the PE3 node has the ability to process the SCT EC field corresponding to the non-adjacent ES, when the PE3 node receives the RT-4 route sent by the PE1 node, the PE3 node adds a DF Election EC field containing a "T" flag with a value of 1 to another RT-4 route issued by the PE3 node itself, and adds an export route target that can match the EVPN instance to which the second route belongs to the included RT set. The PE2 node determines the SCT EC field parsing capability of the second communication device based on whether the DF Election EC field in the RT-4 route contains a "T" flag with a value of 1 and whether the RT set contains the export route target RT of the EVPN instance to which the second route belongs.

[0130] It should be understood that here the first communication device can determine whether the second communication device has the ability to parse the SCT EC field in the RT-1per EVI route based on the RT set in the RT-1per ES route corresponding to the RT-4 route, the first attribute field, and the corresponding "T" flag with a value of 1. If the PE3 node cannot parse the SCT EC field, the "T" flag in the generated DF Election EC field is not 1. If the SCT EC field can be parsed but the SCT EC field corresponding to the non-adjacent ES is not processed, the RT set is not included in the issued RT-4 route.

[0131] The PE2 node determines that the PE3 node has the ability to parse the SCT EC field based on the DF Election EC field containing the "T" flag with a value of 1 in the RT-4 route, and completes the local ESI instance matching based on the ES-Import RT field in the RT-4 route and the local EVI instance matching based on the RT set in the RT-4 route. When the PE2 node is actually promoted to the DF role, the PE2 node sends the RT-1per EVI route with the SCT EC field to the PE3 node.

[0132] Based on this, the above fields are carried on the RT-4 route, and the first communication device can be informed of the situation related to the second communication device before the DF election is performed. After receiving the RT-4 route, the first communication device determines the capability of the second communication device according to the DF Election EC field with the "T" flag bit of 1 on the RT-4, the first stub field corresponding to the DF Election EC field, and the RT set in the RT-1per ES route corresponding to the RT-4 route. When the DF switching back time needs to be scheduled between the first communication device and the PE1 node, the first communication device publishes the RT-1per EVI route carrying the SCT EC to the second communication device. The second communication device performs DF switching back according to the scheduled time based on the parsing capability of the SCT EC field, thereby ensuring that the switching back timing of the first communication device and the device symmetrical with the first communication device matches the capability of the second communication device, and ensuring normal forwarding of traffic.

[0133] The embodiment of the present application carries in the RT-4 route, for a given ES, each exported route target in the RT set that should be carried in the RT-1perES route corresponding to the ES, so that the PE that is not adjacent to the ES can also pay attention to the DF Election EC information carried by the RT-4 route, and the PE that is not adjacent to the ES can also negotiate the reservation switchback time capability.

[0134] See also Figure 8 , Figure 8 for Figure 3 Schematic diagram of the steps of step S102 sub-steps in the embodiment of the present invention. In some possible embodiments of the present application, the first attribute field may include an ESI label field, an OPE TLV field, and a Nexthop field, the first stub field corresponding to the first attribute field may include an ESI label stub field, an OPE TLV stub field, and a Nexthop stub field, the second attribute field may be an OPE TLV field, and both the first route and the second route may be RT-1per ES routes. Step S102 includes but is not limited to the following sub-steps.

[0135] Step S401, when the ESI tag field does not match the ESI tag stub field, the OPE TLV field matches the OPE TLV stub field, and the Nexthop field does not match the Nexthop stub field, it is determined that the second communication device does not have the ability to rewrite the OPE TLV field.

[0136] Step S402: When the ESI tag field does not match the ESI tag stub field, the OPE TLV field does not match the OPE TLV stub field, and the Nexthop field does not match the Nexthop stub field, it is determined that the second communication device has the ability to rewrite the OPE TLV field so that the ESI tag field and the OPE TLV field satisfy a preset correspondence.

[0137] Below is Figure 8 The specific embodiments of the embodiment applied to the EVPN vHub / vSpoke scenario may include but not be limited to the following embodiment 3. Embodiment 3:

[0138] by Figure 2 The EVPN vHub / vSpoke networking in the embodiment 3 is described.

[0139] Exemplarily, when the third embodiment is applied to the EVPN vHub / vSpoke scenario: the route sent by the VS1 node to the VH1 node carries the ESI label field, OPE TLV field, Nexthop field, ESI label stub field, OPE TLV stub field and Nexthop stub field corresponding to the VS1 node. VH1 processes (such as rewrites) the ESI label field, OPE TLV field and Nexthop field in the route sent by the VS1 node according to its own capabilities, and carries the processed ESI label field, OPE TLV field, Nexthop field, original ESI label stub field, original OPE TLV stub field and original Nexthop stub field in the RT-1per ES route to form a first route, and sends it to the VS2 node. The ESI label field and Nexthop field in the first route are obtained by the VH1 node rewriting the ESI label field and Nexthop field in the route sent by the VS1 node to the VH1 node, and whether the OPE TLV field is rewritten depends on whether the VH1 node has the ability to rewrite the OPE TLV field.

[0140] It should be understood that, in step S401, the ESI label stub field, OPE TLV stub field and Nexthop stub field in the route sent by the VS1 node to the VH1 node may have certain optional and transitional attributes in BGP, which allow the VH1 node to not rewrite or even not recognize these first stub fields, so that the first stub field can remain unchanged in the first route through transparent transmission, so that the VS2 node compares the relevant fields in the first route to determine the VH1 node's ability to rewrite the OPE TLV field.

[0141] If the VH1 node does not have the ability to rewrite the OPE TLV field, the OPE TLV field in the first route will remain the same as the original OPE TLV field, which will result in the VS2 node being unable to encapsulate the rewritten ESI label into the data message transferred to the VS1 node via the VH1 node, thereby causing the corresponding ES internal loop.

[0142] In this embodiment, if the VH1 node does not have the ability to rewrite the OPE TLV field, at this time, the VS2 node can report an alarm to inform the network management node of the abnormality of the VH1 node, and the OPE TLV field is not carried in the second route sent to the VH1 node to prevent traffic abnormalities. Therefore, according to symmetry, the VS2 node and the nodes that are symmetrical with VS2 relative to VH1 (such as the VS1 node) do not include the OPE TLV field in the RT-1per ES route (corresponding to the second route) sent to the VH1 node, avoiding the generation of the above-mentioned ES inner loop.

[0143] It should be understood that for the entire EVPN vHub / vSpoke scenario, when the IMET route published by the VH node in the network carries the "o" flag, it indicates that the vHUb node can parse the OPE TLV field. At this time, the RT-1per ES routes sent by all vSpoke nodes to the vHUb node can carry the OPE TLV field. It should be noted that the "o" flag indicates that the vHUb node has the ability to parse the field, but may not indicate the ability to rewrite the field.

[0144] It should be understood that the corresponding relationship here may be that the ESI label represented by the ESI label field is allocated by the node identified by the OPE TLV field in the first route.

[0145] When the VH1 node has the ability to rewrite the OPE TLV field, the OPE TLV field rewritten by the VH1 node will identify the VH1 node itself, and after the ESI label field is rewritten by the VH1 node, the ESI label represented by the rewritten ESI label field is allocated by the VH1 node. That is to say, when the VH1 node has the ability to rewrite the OPE TLV field, the ESI label field and the OPE TLV field in the first route are both determined by the VH1 node; when the VH1 node does not have the ability to rewrite the OPE TLV field, the ESI label field in the first route can be determined by the VH1 node, but the OPE TLV field cannot be determined by the VH1 node, but identifies the VS1 node and is determined by the VS1 node.

[0146] When the rewritten ESI tag field and the rewritten OPE TLV field meet the preset correspondence, the second route published by the VS2 node may carry the OPE TLV field. It should be noted that the value of the OPE TLV field carried in the second route may be the identification information of the VS2 node as the second route publishing end.

[0147] The embodiment of the present application matches or compares the first attribute field and the first stub field to avoid the impact of traffic forwarding anomalies when there are some VH nodes in the network that do not support rewriting the OPE TLV field. The first attribute field and the first stub field match can be that the first attribute field and the first stub field meet the specified rules.

[0148] See also Fig. 9 , Fig. 9 A schematic diagram of node interaction of a routing transmission method provided in an embodiment of the present application. In this embodiment, the routing transmission method is applied to a second communication device, and the routing transmission method in the embodiment of the present application includes but is not limited to the following steps:

[0149] Step S501: Send a first route to a first communication device.

[0150] It should be understood that the first route includes a first stub field corresponding to the first attribute field, and the first attribute field and the first stub field corresponding to the first attribute field are used to instruct the first communication device to send a second route including a second attribute field.

[0151] Exemplarily, in the first embodiment provided above, the second communication device sends the first route to the first communication device, and determines the second communication device's designated parsing capability for the second attribute field through the first attribute field and the first stub field corresponding to the first attribute field. When the first communication device determines that the second communication device has this capability, the second route sent by the first communication device will carry the second attribute field to synchronize the switching back between the first communication device, the second communication device, and the device that is symmetrical with the first communication device, thereby avoiding the problem of mismatched forwarding states on different devices when there is a device that does not support processing the second attribute field carried in the second route at the second communication device or at a position symmetrical to the second communication device.

[0152] See also Fig. 9 and Fig.10 , Fig.10 A schematic diagram of the steps of a route transmission method provided by another embodiment of the present application. The embodiment of the present application is applied to an EVPN VPWS scenario. Before step S501, the route transmission method further includes the following steps:

[0153] Step S601: receiving a third route sent by a third communication device.

[0154] Step S602: Generate a corresponding first stub field according to the first attribute field included in the third route.

[0155] Step S603: Include the DF Election EC field and the first stub field corresponding to the second communication device in the first route.

[0156] It should be understood that the third communication device here, as described in the above-mentioned embodiments 1 to 2, may refer to Figure 1 The PE1 node and other devices in the EVPN VPWS network shown are symmetrical with the first communication device, and the third route here includes the first attribute field.

[0157] It should be understood that the third route here is represented differently in different EVPN VPWS scenarios, as described in the above-mentioned embodiments 1 to 2. When the second communication device has the ability to process the second attribute field, the second communication device will parse the first attribute field in the third route, and add the information in the first attribute field of the third route in the first stub field, or, add indication information for indicating that the first attribute field is carried in the third route in the first stub field.

[0158] It should be understood that the key value of the first route in step S603 and the key value of the third route in step S601 may be different.

[0159] Exemplarily, in the above-mentioned specific different EVPN VPWS scenarios, when the second communication device has the ability to process the second attribute field in the second route, it can also have the ability to parse the first attribute field in the first route. After the second communication device parses the first attribute, it adds the corresponding first stub field to the first route, and adds the first attribute field corresponding to the local configuration of the second communication device in the specific scenario to the first route according to the local configuration of the second communication device, so as to inform the first communication device of the information that the local end has the ability to process the second attribute field in the second route, so that the second route sent by the first communication device to the local end carries the second attribute field (corresponding to the second attribute field).

[0160] It can be understood that, in this embodiment, the first stub field in the first route is not actually the stub information of the first attribute field in the first route (it can be considered as the stub information of the first attribute field in the third route), because the first route is set according to the first attribute field in the third route, rather than the first attribute field in the first route, but for the receiving end node of the first route such as the second communication device, it does not perceive how the first stub field is set.

[0161] Because the first attribute field can indicate that the corresponding sending end node has the ability to publish the second attribute field, and the sending end node of the third route and the sending end node of the second route are symmetrical with respect to the second communication device, when the receiving end node of the first route finds that the first attribute field and the first stub field exist in the first route at the same time, regardless of whether the first stub field in the first route is consistent with the first attribute field, the first communication device can determine that the sending end node of the first route has the ability to process the first attribute field in the third route, thereby inferring that the sending end node of the first route also has the ability to process the second attribute field in the second route.

[0162] In some possible embodiments of the present application, the first attribute field may be a DF Election EC field, and the second attribute field may be a SCT EC field. For example, as in the above-mentioned embodiments 1 to 2 in the EVPN VPWS scenario, the DF Election EC field and the first stub field are used to determine whether the second communication device itself has the ability to parse the SCTEC field, thereby determining whether the second route carries the SCT EC field.

[0163] See also Fig.11 , Fig.11 A schematic diagram of the steps of a routing transmission method provided in another embodiment of the present application. Fig.11 The embodiments are applied to EVPN vHub / vSpoke scenarios.

[0164] Exemplarily, when the embodiment of the present application is applied to the EVPN vHub / vSpoke scenario, the first attribute field may include an ESI label field, an OPE TLV field, and a Nexthop field, the first stub field corresponding to the first attribute field may include an ESI label stub field, an OPE TLV stub field, and a Nexthop stub field, the second attribute field may be an OPETLV field, and before step S501, the routing transmission method may further include the following steps:

[0165] Step S701: Receive a third route sent by a third communication device, and use a first stub field of the third route as a first stub field of a first route.

[0166] It should be understood that, in this embodiment, the third communication device refers to Figure 4 For the VS1 node type device shown in the figure, the third route here may include a first attribute field and a first stub field corresponding to the first attribute field, the first attribute field may include an ESI label field, an OPE TLV field and a Nexthop field, and the first stub field corresponding to the first attribute field may include an ESI label stub field, an OPE TLV stub field and a Nexthop stub field.

[0167] It should be understood that the second communication device rewrites the ESI label field, OPE TLV field, and Nexthop field in the third route accordingly. When the second communication device has the ability to rewrite the OPE TLV field, the first route output by the second communication device may include the same ESI label stub field, OPE TLV stub field, and Nexthop stub field as the third route, as well as the rewritten ESI label field, OPE TLV field, and Nexthop field. It can be understood that the first route obtained in this way has the same key value as the third route, wherein the first stub field needs to be combined with the first attribute field in the same route to indicate that the second attribute received from the specified route has a specified processing capability. Therefore, the first stub field contains the fifth type of indication information, and the first stub field corresponding to the first attribute field is a field containing the value of the first attribute field before it is modified.

[0168] Exemplarily, in an embodiment of an EVPN vHub / vSpoke scenario, when the IMET route published by a vHub node carries an "R" flag or an "o" flag, the vSpoke node can publish an RT-1per ES route with an OPE TLV field, and when the VH1 node has the ability to rewrite the OPE TLV field, the VH1 node will simultaneously rewrite the ESI label field, the Nexthop field, and the OPE TLV field to generate an OPE TLV field that is different from the third route, and the generated OPE TLV field identifies the node that allocates the rewritten ESI label.

[0169] Exemplarily, when a type of indication information is both the first type of indication information and the fourth type of indication information, it can be named as the sixth type of indication information, and when the first stub field contains the sixth type of indication information, it can be processed in the same way as when the first stub field contains the fourth type of indication information.

[0170] It should be noted that when the first stub field contains the fourth type of indication information or the sixth type of indication information, the first route can also be published before receiving the third route, because even if the second communication device does not receive the third route, the second communication device knows that it has the corresponding processing capability when it receives the third route.

[0171] See also Fig.12 , is an electronic device provided in an embodiment of the present application, and the electronic device 900 includes but is not limited to:

[0172] at least one processor 910;

[0173] At least one memory 920, used to store at least one program;

[0174] When at least one program is executed by at least one processor 910 , the routing transmission method described in any of the above embodiments is performed.

[0175] It should be understood that the processor 910 and the memory 920 may be connected via a bus or other means.

[0176] It should be understood that the processor 910 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc. Alternatively, the processor 910 may be one or more integrated circuits for executing related programs to implement the technical solutions provided in the embodiments of the present application.

[0177] The memory 920 is a non-transitory computer-readable storage medium that can be used to store non-transitory software programs and non-transitory computer executable programs, such as the routing transmission method described in any embodiment of the present application. The processor 910 implements the above-mentioned routing transmission method by running the non-transitory software programs and instructions stored in the memory 920.

[0178] The memory 920 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function; the data storage area may store and execute the above-mentioned routing transmission method. In addition, the memory 920 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 920 may optionally include a memory remotely arranged relative to the processor 910, and these remote memories may be connected to the processor 910 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0179] The non-transient software programs and instructions required to implement the above-mentioned routing transmission method are stored in the memory 920, and when executed by one or more processors 910, the routing transmission method provided by any embodiment of the present application is executed.

[0180] An embodiment of the present application further provides a computer-readable storage medium, which stores a program executable by a processor. When the program executable by the processor is executed by the processor, it is used to implement the routing transmission method described in any of the above embodiments.

[0181] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media. Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above. More specific examples (non-exhaustive lists) of computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this document, computer-readable storage media can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0182] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0183] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0184] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0185] The present invention extends RT-1per ES routing or RT-4 routing, introduces SCT capability indication information into the RT-1per ES routing protocol, or carries the RT carried in the RT-1per ES routing of the same ESI in the RT-4 routing, so that the RT-4 routing or RT-1per ES routing has both SCT capability indication information and BD-RT identifying the BD. The SCT comprehensive capability of the BD can be determined by combining the capability indication information and the BD-RT information, solving the problem of multiple packets or packet loss caused by inconsistent SCT capabilities between different devices in actual business networking. When it is not possible to determine whether the SCT capabilities between the devices are consistent, the function of carrying SCT-EC in the RT-1per EVI routing can be enabled without causing abnormal traffic, thereby ensuring normal forwarding of traffic. Similarly, it is also possible to insert a node that cannot recognize SCT-EC into a network that has enabled the function of carrying SCT-EC in the RT-1per EVI routing. It can be understood that enabling the function of carrying SCT-EC in RT-1perEVI routing here only means trying to add SCT-EC to RT-1per EVI routing, but does not mean that SCT-EC must be added to RT-1per EVI routing in the end. Whether SCT-EC will be added to RT-1per EVI routing in the end is determined by the SCT capability of the receiving end of RT-1per EVI routing.

[0186] It effectively solves the traffic anomaly problem caused by inconsistent routing between devices due to uncertainty as to whether all devices receiving RT-1per EVI routing can process SCT-EC time information, thereby increasing network stability;

[0187] This effectively solves the problem of unicast traffic forwarding anomalies caused by inconsistent routing between the newly added node and other nodes when a device that cannot recognize SCT-EC in RT-1per EVI routing is inserted into a network that has enabled the SCT-EC function in RT-1per EVI routing. This simplifies network planning and management, reduces the problem of traffic forwarding anomalies caused by capability differences between devices, reduces the risk of traffic forwarding anomalies, and reduces network management costs.

[0188] In addition, through similar solutions, the present invention also solves the problem that the ESI label rewritten by the Virtual Hub node that does not support rewriting OPE TLV cannot be used by the Vritual Spoke node due to uncertainty as to whether all devices can rewrite the OPE TLV when relaying the received RT-1per ES route; it effectively solves the problem that when a device that cannot recognize the OPE TLV in the RT-1per ES route is inserted into a network that has enabled the function of carrying OPE TLV in the RT-1per ES route, the BUM message forwarded by the newly added node will have a loop on the corresponding ES. This simplifies the planning and management of the network, reduces the problem of abnormal traffic forwarding caused by capability differences between devices, reduces the risk of abnormal traffic forwarding, and reduces network management costs.

[0189] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the above implementation. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present application. These equivalent modifications or substitutions are all included in the scope defined by the present application.

Claims

1. A routing transmission method, characterized in that: The method is applied to a first communication device, and the method includes: receiving a first route from a second communication device; Determining capability information of the second communication device according to a first stub field corresponding to the first attribute field included in the first route; According to the capability information, one of a first process and a second process is performed, wherein the first process is to send a second route containing the second attribute field to the second communication device when it is determined according to the capability information that the second communication device has the capability to perform specified processing on the second attribute field; and the second process is to trigger an alarm or not send the second route containing the second attribute field to the second communication device when it is determined according to the capability information that the second communication device does not have the capability to perform specified processing on the second attribute field.

2. The method according to claim 1, characterized in that The determining, according to the first attribute field included in the first route and the first stub field corresponding to the first attribute field, the capability information of the second communication device comprises one of the following: When the first attribute field in the first route matches the corresponding first stub field, determining that the second communication device has the capability of performing specified processing on the second attribute field; or, When the first route does not include the first stub field corresponding to the first attribute field, it is determined that the second communication device does not have the ability to perform specified processing on the second attribute field.

3. The method according to claim 1, characterized in that The first attribute field is a designated forwarder election extended community attribute DF Election EC field, and the second attribute field is a service characterization time extended community attribute SCT EC field; The determining, according to the first attribute field included in the first route and the first stub field corresponding to the first attribute field, the capability information of the second communication device includes: When the first route includes a first stub field corresponding to the DF Election EC field, it is determined that the second communication device has the ability to parse the SCT EC field; When it is determined according to the capability information that the second communication device has the capability of performing a specified process on the second attribute field, sending a second route including the second attribute field to the second communication device includes: When it is determined that the second communication device has the ability to parse the SCT EC field, the second route including the SCT EC field is sent to the second communication device.

4. The method according to claim 3, characterized in that The first stub field corresponding to the DF Election EC field includes: third indication information corresponding to a third route, wherein the third route is a route received by the second communication device from a third communication device, the first communication device and the third communication device are symmetrical devices relative to the second communication device, and the third indication information is the value of the DF Election EC field in the third route, or the third indication information is indication information used to indicate the existence of the DF Election EC in the third route.

5. The method according to claim 1, characterized in that The first attribute field includes an Ethernet segment identifier ESI label field, an OPE TLV field, and a Nexthop field; the first stub field corresponding to the first attribute field includes an ESI label stub field, an OPE TLV stub field, and a Nexthop stub field; the second attribute field is the OPETLV field; The determining, according to the first attribute field included in the first route and the first stub field corresponding to the first attribute field, the capability information of the second communication device includes: When the ESI label field does not match the ESI label stub field, the OPE TLV field matches the OPE TLV stub field, and the Nexthop field does not match the Nexthop stub field, determining that the second communication device does not have the ability to rewrite the OPE TLV field; or, When the ESI tag field does not match the ESI tag stub field, the OPE TLV field does not match the OPE TLV stub field, and the Nexthop field does not match the Nexthop stub field, it is determined that the second communication device has the ability to rewrite the OPE TLV field so that the ESI tag field and the OPE TLV field satisfy a preset correspondence.

6. The method according to claim 1, characterized in that There are multiple second communication devices, and when it is determined that the second communication device has the ability to perform specified processing on the second attribute field, sending the second route containing the second attribute field to the second communication device includes: When it is determined that all the second communication devices have the capability of performing designated processing on the second attribute field, a second route including the second attribute field is sent to one of the second communication devices.

7. The method according to claim 6, characterized in that The method further comprises: When it is determined that at least one of the second communication devices does not have the ability to perform designated processing on the second attribute field, a second route that does not include the second attribute field is sent to any one of the second communication devices.

8. The method according to claim 2, characterized in that: The first route is a per-ES Ethernet automatic discovery route, and the first attribute field includes an OPE TLV field and a Nexthop field; The determining that the second communication device does not have the ability to perform specified processing on the second attribute field when the first route does not include the first stub field corresponding to the first attribute field includes: If the received per-ES Ethernet automatic discovery route does not have the first stub field, and the IP value of the OPE TLV field in the per-ES Ethernet automatic discovery route is different from the ORIP in the inclusive multicast Ethernet tag IMET route having the same Nexthop field as the first route, it is determined that the second communication device does not have the specified rewrite capability for OPETLV.

9. A routing transmission method, characterized in that: The method is applied to a second communication device, and the method includes: A first route is sent to a first communication device, wherein the first route includes a first stub field corresponding to a first attribute field, and the first stub field corresponding to the first attribute field is used to indicate whether the first communication device sends a second route including a second attribute field.

10. The method according to claim 9, characterized in that Before sending the first route to the first communication device, the method further includes: receiving a third route sent by a third communication device, wherein the third route includes the first attribute field; Generate the corresponding first stub field according to the first attribute field included in the third route; The first attribute field and the first stub field corresponding to the second communication device are included in the first route, wherein the first communication device and the third communication device are symmetrical devices relative to the second communication device.

11. The method according to claim 10, characterized in that The first attribute field is a DF Election EC field, and the second attribute field is a SCT EC field.

12. The method according to claim 9, characterized in that The first attribute field includes an ESI label field, an OPE TLV field and a Nexthop field; the first stub field corresponding to the first attribute field includes an ESI label stub field, an OPE TLV stub field and a Nexthop stub field; the second attribute field is the OPE TLV field.

13. The method according to claim 12, characterized in that Before sending the first route to the first communication device, the method further includes: receiving a third route sent by a third communication device, wherein the third route includes the ESI label field, the OPE TLV field, the Nexthop field, an ESI label stub field corresponding to the ESI label field, an OPE TLV stub field corresponding to the OPE TLV field, and the Nexthop stub field corresponding to the Nexthop field; The second communication device obtains the first route including the ESI label stub field, the OPE TLV stub field and the Nexthop stub field by modifying the third route.

14. An electronic device, characterized in that: include: one or more processors; A memory having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement: The routing transmission method according to any one of claims 1 to 8; or, A routing transmission method as described in any one of claims 9 to 13.

15. A computer readable medium, characterized in that The computer readable medium stores a computer program, which, when executed by a processor, implements: The routing transmission method according to any one of claims 1 to 8; or, A routing transmission method as described in any one of claims 9 to 13.

Images