Management of a bum traffic forwarding table, a forwarding method, a storage medium, and an apparatus

By recording forwarding decision information in the BUM traffic forwarding table, and deciding whether to forward or discard BUM traffic based on the Ethernet segment and forwarding permissions, the problem of invalid traffic occupation in EVPN VPLS over SRv6 networks is solved, achieving efficient BUM traffic forwarding and resource conservation.

CN121644455BActive Publication Date: 2026-07-21RAISECOM TECH +1
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
RAISECOM TECH
Filing Date
2025-12-09
Publication Date
2026-07-21

AI Technical Summary

Technical Problem

In EVPN VPLS over SRv6 networks, the forwarding of BUM traffic results in a waste of network link bandwidth and PE device forwarding processing resources, leading to reduced forwarding efficiency and resource utilization.

Method used

By recording the forwarding decision information of each target PE in the BUM traffic forwarding table, and determining whether to forward or drop BUM traffic to the target PE based on its Ethernet segment and forwarding permissions, an intelligent BUM traffic forwarding table is generated to avoid the generation of invalid traffic.

Benefits of technology

It effectively suppresses BUM traffic copies to invalid target PEs, saves network core link bandwidth and PE device processing resources, and improves the forwarding efficiency and economic benefits of SRv6 networks in complex multi-homed access scenarios.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121644455B_ABST
    Figure CN121644455B_ABST
Patent Text Reader

Abstract

A BUM traffic forwarding table management method, a forwarding method, a storage medium and a device, the method comprising: obtaining target PEs from remote PEs of a local PE, wherein the target PEs are connected to a same CE with another PE in a same EVPN instance; updating a forwarding table entry of each target PE in a BUM traffic forwarding table of the local PE according to an Ethernet segment where the target PE is located and a forwarding right in the Ethernet segment of the target PE; wherein the updated forwarding table entry records forwarding decision information, wherein: if the Ethernet segment where the target PE is located and the forwarding right in the Ethernet segment of the target PE indicate that the target PE performs a forwarding operation on received BUM traffic of the local PE, the forwarding decision information indicates forwarding the BUM traffic to the target PE; otherwise, the forwarding decision information indicates not forwarding the BUM traffic to the target PE, thereby suppressing BUM traffic copies sent to invalid targets in a multi-homing group.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This article relates to network transmission technology, and in particular to a method, storage medium and device for managing and forwarding a BUM traffic forwarding table. Background Technology

[0002] In the EVPN (Ethernet Virtual Private Network) VPLS over SRv6 (Segment Routing over IPv6) network architecture, efficient forwarding of BUM (Broadcast, Unknown-unicast, Multicast) traffic is crucial for ensuring network performance. The process of establishing BUM traffic forwarding paths under this architecture is as follows: First, the various Provider Edge (PE) devices in the network exchange BGPEVPN routing information, enabling each PE to become aware of other neighbors in the EVPN instance, thus initially establishing forwarding paths for BUM traffic. Furthermore, if an ESI (Ethernet Segment Identifier) ​​is configured on the AC (Attachment Circuit) interface connecting the PE and the Customer Edge (CE), the local PE will generate an ARG_FE2 parameter. Subsequently, PEs exchange Type 4 routes, transmitting information such as the ESI and PE source address. The receiving PE compares the received ESI with its local ESI, adding PEs with the same ESI to the member list of the same Ethernet segment and performing Designated Forwarder (DF) election to avoid receiving duplicate BUM traffic on the access side. Simultaneously, the ARG_FE2 parameter is used to prune BUM traffic in the data plane to prevent loops.

[0003] However, the existing mechanisms still result in wasted network link bandwidth and PE device forwarding processing resources, reducing the overall forwarding efficiency and resource utilization of the SRv6 network when carrying EVPN BUM services. Summary of the Invention

[0004] This application provides a method, storage medium, and apparatus for managing and forwarding BUM traffic forwarding tables.

[0005] A method for managing BUM traffic forwarding tables includes: Obtain the target PE from the remote PE of the local provider edge device PE, wherein the target PE and another PE are both connected to the same customer edge device CE within the same EVPN instance; Based on the Ethernet segment where each target PE is located and its forwarding permissions in that Ethernet segment, update the forwarding table entry of each target PE in the BUM traffic forwarding table of the local PE. The updated forwarding entry records include forwarding decision information, including: If the Ethernet segment where the target PE is located and the forwarding authority in its Ethernet segment instruct the target PE to forward the BUM traffic received from the local PE, the forwarding decision information instructs the target PE to forward the BUM traffic. If the Ethernet segment where the target PE is located and the forwarding authority indication in its Ethernet segment determine that the target PE will drop the BUM traffic received from the local PE, the forwarding decision information indicates that the BUM traffic should not be forwarded to the target PE.

[0006] A BUM traffic forwarding method includes: When BUM traffic needs to be sent, the forwarding decision information of each target PE is obtained from the remote PE in the local PE; wherein the target PE and another PE in the same EVPN instance are connected to the same CE; The BUM traffic is sent only to the PEs in the target PEs that are instructed by the forwarding decision information to forward the BUM traffic; wherein the forwarding decision information is determined based on the Ethernet segment where each target PE is located and its forwarding privileges within that Ethernet segment. If the Ethernet segment where the target PE is located and the forwarding authority in its Ethernet segment instruct the target PE to forward the BUM traffic received from the local PE, the forwarding decision information instructs the target PE to forward the BUM traffic. If the Ethernet segment where the target PE is located and the forwarding permission indication in its Ethernet segment determine that the target PE will drop the BUM traffic received from the local PE, the forwarding decision information indicates that the BUM traffic should not be forwarded to the target PE.

[0007] A storage medium storing a computer program, wherein the computer program is configured to execute the method described above when run.

[0008] An electronic device includes a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the methods described above.

[0009] In this embodiment, the source device that initiates BUM traffic forwarding suppresses BUM traffic copies destined for invalid targets within the multi-homing group, thereby maximizing the saving of network core link bandwidth and processing resources of all related PE devices. This greatly improves the overall forwarding efficiency and economic benefits of SRv6 networks carrying EVPN BUM services in complex multi-homing access scenarios.

[0010] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the solutions described in the description and the accompanying drawings. Attached Figure Description

[0011] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0012] Figure 1 A schematic diagram of a networking scenario for an EVPN VPLS over an SRv6 network; Figure 2 A flowchart illustrating the BUM traffic forwarding table management method provided in this application embodiment; Figure 3 A flowchart illustrating the BUM traffic forwarding method provided in this application embodiment; Figure 4 This is a diagram illustrating another networking scenario for an EVPN VPLS over an SRv6 network. Detailed Implementation

[0013] This application describes several embodiments, but these descriptions are exemplary and not restrictive, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0014] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0015] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.

[0016] When a PE device receives BUM traffic from the CE side, it replicates and sends the traffic to all detected remote PE neighbors based on its locally maintained BUM traffic forwarding table. During this process, the following phenomena occur: by Figure 1 The scenario shown is used as an example for explanation. Figure 1 This illustrates a network topology for an EVPN VPLS over SRv6 network. The network includes three provider edge devices: PE1, PE2, and PE3. PE1, PE2, and PE3 all belong to the same EVPN instance. PE1 is connected to the customer edge device CE1; PE2 and PE3 share the same ESI and are connected to CE2 in a multi-homed configuration, providing redundant access protection for CE2. PE2 is a DF (Designated Forwarder), while PE3 is not a DF, meaning it is a Backup Designated Forwarder (BDF).

[0017] exist Figure 1 Application scenario 1 exists in the network shown: According to the existing technology's processing flow, when PE1 receives a BUM traffic (such as an ARP request broadcast message) from CE1, it will copy and send the traffic to all known remote PE neighbors based on its locally maintained BUM traffic forwarding table. Specifically... Figure 1 The scenario shown is that PE1 will send the BUM traffic to both PE2 and PE3 simultaneously.

[0018] After receiving this traffic, PE2 performs SRv6 decapsulation processing. Since it has been elected as the DF on the Ethernet segment connected to CE2, it forwards the BUM traffic to CE2.

[0019] However, after receiving the same BUM traffic from PE1 and completing its decapsulation, PE3, not being a DF on the corresponding Ethernet segment, will not forward the traffic to CE2 according to EVPN rules. Therefore, although PE3 ultimately discards the traffic, this copy of the traffic has already been sent from PE1 to PE3, consuming the link bandwidth between PE1 and PE3 and depleting the processing resources of PE3.

[0020] exist Figure 1 Application scenario 2 exists in the network shown: As the traffic initiator, when PE3 needs to send BUM traffic, it replicates and sends the traffic to all known remote PE neighbors based on its locally maintained BUM traffic forwarding table. Specifically... Figure 1 The scenario shown is that PE3 will send the BUM traffic to both PE1 and PE2 simultaneously.

[0021] After receiving this traffic, PE1 performs SRv6 decapsulation processing and forwards the BUM traffic to CE2.

[0022] However, upon receiving BUM traffic from PE3, PE2 parses the SRv6 encapsulated SID and finds that the ARG_FE2 parameter carried within is identical to its local ARG_FE2 parameter, thus identifying that the traffic originates from the same Ethernet segment. To prevent loops, PE2 discards this BUM traffic.

[0023] Therefore, although the BUM traffic sent from PE3 to PE2 was eventually correctly discarded, avoiding the formation of a loop, this traffic was still transmitted completely to PE2, resulting in the invalid use of the link bandwidth between PE3 and PE2.

[0024] As the above analysis shows, some remote PE devices, upon receiving BUM traffic, may discard the received BUM traffic locally due to their DF role (e.g., application scenario 1) or because they detect that the traffic originates from the same Ethernet segment (e.g., application scenario 2). This BUM traffic discarding operation consumes the transmission capacity of the network core path and the processing capacity of the nodes, resulting in a waste of network link bandwidth and PE device forwarding and processing resources.

[0025] In view of this, embodiments of this application provide a method for generating a BUM traffic forwarding table. The core of this method lies in improving the generation logic of the traditional BUM traffic forwarding table to generate an intelligent BUM traffic forwarding table. This forwarding table no longer simply records all remote PE neighbors, but instead clearly marks each neighbor in a multi-homed access scenario with its own forwarding or dropping decision, so as to achieve selective forwarding of BUM traffic locally.

[0026] The method described in this embodiment is mainly applied to PE devices in SRv6 networks. In this network, multiple PE devices together form an EVPN instance, providing virtual private network services for CE devices connected to different sites.

[0027] See Figure 2 The execution of the above-mentioned BUM traffic forwarding table management method includes steps A11 and A12.

[0028] Step A11: Obtain the target PE from the remote PE of the local PE, wherein the target PE and another PE within the same EVPN instance are both connected to the same CE; In EVPN SRv6 networks, the core issue of BUM traffic forwarding is concentrated in multi-homed access scenarios. A PE device may be aware of multiple remote PEs, but only the remote PEs belonging to a certain multi-homed group are the key nodes that may cause the problem of invalid BUM traffic replication and forwarding.

[0029] For example, in Figure 1 In the multi-homed scenario shown, PE2 and PE3 experience invalid traffic transmission precisely because they share the same ESI and exhibit DF / non-DF role distinctions. For remote PEs with single-homed access or those not involving specific multi-homed ESIs, their forwarding behavior is deterministic, and there is no decision ambiguity.

[0030] Step A12: Based on the Ethernet segment where each target PE is located and its forwarding permissions in the Ethernet segment, update the forwarding table entry of each target PE in the BUM traffic forwarding table of the local PE, wherein the updated forwarding table entry records forwarding decision information.

[0031] In this step, the forwarding decision information is not a simple "reachable" flag, but rather an indication of whether the local PE should forward BUM traffic to the target PE.

[0032] The generation of this forwarding decision information depends on how the target PE processes the local PE's BUM traffic; where: If the Ethernet segment where the target PE is located and its forwarding authority in the Ethernet segment instruct the target PE to forward the received BUM traffic from the local PE, it means that the target PE is a necessary and valid next hop to process this BUM traffic, and the forwarding decision information instructs to forward the BUM traffic to the target PE. If the Ethernet segment where the target PE is located and the forwarding permission indication in its Ethernet segment determine that the target PE will drop the BUM traffic received from the local PE, it means that sending traffic to the target PE is a waste of resources, then the forwarding decision information indicates that the BUM traffic should not be forwarded to the target PE.

[0033] By directly embedding the results of this binary decision into the BUM traffic forwarding table, the data plane does not need to perform any additional complex real-time calculations when forwarding BUM traffic. It only needs to look up the table and execute a simple instruction to forward or not forward, thus achieving a perfect connection between intelligent decision-making in the control plane and efficient execution in the data plane.

[0034] The BUM traffic forwarding table management method described in this embodiment lays a solid foundation for efficient and accurate forwarding of subsequent BUM traffic by accurately locating the management objects (target PEs) and configuring clear action instructions (forwarding decision information) for these objects. This eliminates the path to invalid traffic from the management level, thus providing a fundamental guarantee for ultimately saving network bandwidth and device processing resources.

[0035] Apply the above methods to Figure 1 The operation results in the network shown are as follows: Applied to Figure 1 Application scenario 1: When PE1 generates its BUM traffic forwarding table, PE2 and PE3 are both remote PEs of PE1. Since PE2 and PE3 meet the conditions to be target PEs, the forwarding table entries of PE2 and PE3 are updated in PE1's BUM traffic forwarding table.

[0036] For PE2, the BUM traffic sent by PE1 is forwarded. Therefore, the forwarding decision information of PE2 instructs PE1 to forward the BUM traffic to PE2. For PE3, the BUM traffic sent by PE1 is dropped. Therefore, the forwarding decision information of PE2 instructs PE1 not to forward the BUM traffic to PE2.

[0037] Based on the aforementioned BUM traffic forwarding table, when PE1 receives BUM traffic from CE1, it will only send the traffic to PE2 according to the forwarding decision information, and will not copy and send invalid traffic copies to PE3, thereby completely eliminating the bandwidth waste on the PE1 to PE3 link and the resource consumption of PE3 device in processing the invalid traffic.

[0038] Applied to Figure 1 Application Scenario 2: When PE3 generates its BUM traffic forwarding table, PE1 and PE2 are both remote PEs of PE1. PE1 does not meet the conditions to be a target PE, while PE2 does. Therefore, the forwarding table entry of PE2 is updated in the BUM traffic forwarding table of PE1.

[0039] For PE2, its ESI is the same as the local ESI of PE3, which does not meet the forwarding conditions. Therefore, the forwarding decision information of PE3 in the BUM traffic forwarding table is not to send BUM traffic to PE3 (i.e., discard).

[0040] Therefore, when PE2 sends BUM traffic, it will only send it to PE1 and not to PE3, which belongs to the same ESI. This eliminates invalid traffic sent to PE3 at the source and saves network resources.

[0041] Based on the above explanation, it can be seen that... Figure 1 In the system shown, the sending of invalid BUM traffic copies to non-DF devices and ESI devices is eliminated at the source.

[0042] In one specific embodiment, the process of obtaining the processing method of the target PE for the received BUM traffic of the local PE in step A12 is described.

[0043] This embodiment organically combines two previously independent key factors—forwarding authority (DF state) and Ethernet segment (ESI identity)—through a logical AND relationship, defining a completely new forwarding criterion. The Ethernet segment where the target PE resides is represented by the Ethernet segment identifier (ESI); the forwarding authority of the target PE within its Ethernet segment is represented by the designated forwarder's DF state.

[0044] Step A121: Obtain the ESI where each target PE is located and the DF state on the ESI.

[0045] The purpose of this step is to collect two types of key information necessary for making accurate forwarding decisions: one is the ESI network, which is used to determine the membership relationships in the network topology and to determine which PEs are in a group; the other is the DF status, which is used to determine forwarding responsibility in multi-homed access scenarios to know which PE has forwarding authority.

[0046] Step A122: If the target PE is in DF state and the ESI of the target PE is different from the local ESI of the local PE, then it is determined that the target PE forwards the received BUM traffic of the local PE; otherwise, it is determined that the target PE discards the received BUM traffic of the local PE.

[0047] Being in DF state ensures that only PEs elected to be responsible for forwarding traffic to CE will be considered to receive BUM traffic, thus avoiding sending invalid traffic to non-DF PEs from the source. If the target PE's ESI is different from the local PE's local ESI, it ensures that BUM traffic will not be sent to the target PE, which belongs to the same Ethernet segment as the local PE. This is to prevent traffic from being sent to a PE in the same segment in a multi-homed scenario. This PE might drop the traffic due to the anti-loop mechanism, resulting in wasted bandwidth, or in some cases, causing potential forwarding logic conflicts.

[0048] Combining these two conditions using an AND operation creates a source forwarding criterion, as detailed in Table 1: Table 1

[0049] As shown in Table 1, the above judgment mechanism can clearly determine how each target PE handles the BUM traffic of the local PE.

[0050] In step A12 above, the determination method defined in this embodiment provides an accurate and error-free decision basis for the forwarding of BUM traffic. Due to the simplicity of its logic, the scheme is guaranteed to be executed efficiently and reliably in the data plane.

[0051] In one specific embodiment, in step A121, through a phased and collaborative control plane signaling interaction process, accurate and efficient collection of the ESI affiliation and DF status of the remote PE is achieved, providing a reliable data foundation for generating an accurate BUM traffic forwarding table. The specific implementation includes steps A1211 and A1212.

[0052] Step A1211: Exchange Type 4 routes with multiple remote PEs to complete the election of the designated forwarding device (DF); wherein each PE learns the DF status of all other PEs on each ESI by processing the received Type 4 routes.

[0053] By switching through Type 4 routes, each PE in the network can know the DF status of all other PEs on each ESI, so that subsequent processing can be based on a determined and stable DF election result, avoiding decision confusion or temporary state caused by the undetermined DF role.

[0054] Step A1212: After the DF election is completed, exchange Type 1 routes with multiple remote PEs. The Type 1 routes carry the ESI information of the sending PE. Identify each remote PE that sends the Type 1 route as the target PE.

[0055] This embodiment places the collection and comparison of ESI information after DF election, forming a clear serial processing flow. This ensures that the operation used for ESI comparison is performed under the premise of the known DF role of each PE, so that the PE can immediately make a comprehensive judgment based on the known DF state after receiving the Type 1 route, thereby improving the efficiency and logical clarity of forwarding table construction.

[0056] Furthermore, by leveraging the inherent feature of Type 1 routing that carries ESI information, functional enhancements are achieved while maintaining protocol compatibility, without the need to define new routing types.

[0057] In step A121 above, the control plane signaling interaction method described in this embodiment realizes the efficient and orderly collection and processing of DF state and ESI association information, avoids decision delays or errors caused by information coupling, and ensures that the forwarding decision information in the final generated BUM traffic forwarding table is based on accurate and complete network state cognition, providing a reliable control plane guarantee for precise control of BUM traffic forwarding from the source.

[0058] Although this embodiment can achieve SRv6 packet dropping at the source based on the BUM traffic forwarding table, it is still necessary to ensure that the generated SRv6 packet itself is a legitimate packet that conforms to existing protocol specifications and can be correctly parsed and processed by network devices. ARG_FE2, as a parameter field defined in the SRv6 SID, is a convention agreed upon by existing protocols and hardware. Therefore, when generating the BUM traffic forwarding table, this embodiment not only records forwarding decision information but also records the ARG_FE2 parameter value obtained from the Type1 route of each target PE, so that the ARG_FE2 parameter corresponding to the target PE is filled into the SRv6 SID during the SRv6 encapsulation process.

[0059] By filling each SRv6 message with its corresponding and correct ARG_FE2 parameter during the SRv6 encapsulation process, the encapsulated SRv6 message fully conforms to the existing protocol specifications in terms of SID structure, avoiding message format abnormalities or device processing errors that may be caused by missing or incorrect SID parameters.

[0060] Furthermore, in existing protocols, the data plane relies on ARG_FE2 in the SID for identifying and pruning traffic with the same ESI. While this solution achieves packet dropping at the local PE's network ingress in most cases, filling in the correct ARG_FE2 parameter provides a layer of "redundancy" for packet processing. Even if a packet arrives at the target PE for some special reason (such as diagnostics or mirroring), the target PE can still trigger standard, hardware-accelerated pruning logic by comparing the ARG_FE2 in the SID with the local value, ensuring that the packet is reliably dropped. This allows the new solution to be smoothly integrated into existing networks without changing the existing dropping logic of the end PEs.

[0061] Furthermore, this embodiment also provides a BUM traffic forwarding method, with a typical application scenario being an EVPN VPLS over SRv6 network. In this scenario, multiple PEs connect to the same CE via multihoming, meaning multiple PEs jointly provide access services to the same CE site and are configured with the same ESI. In such multihoming access scenarios, the traditional BUM traffic broadcast forwarding method results in a large amount of invalid traffic, consuming valuable network bandwidth and device processing resources.

[0062] The core of this method lies in a selective traffic forwarding mechanism based on forwarding decision information, which avoids the generation of invalid BUM traffic from the source.

[0063] See Figure 3 The above BUM traffic forwarding method includes steps B11 and B12.

[0064] Step B11: When BUM traffic needs to be sent, obtain the forwarding decision information of each target PE from the local PE and the remote PE.

[0065] This step explicitly defines the operation as targeting PEs, specifically specifying that these target PEs are all connected to the same CE within the same EVPN instance as another PE. This limitation precisely focuses management efforts on PE members within multi-homed access groups most likely to generate invalid traffic. This is because only within multi-homed groups do DF election and ESI pruning issues arise, leading to wasted traffic being dropped at the end. For PEs with single-homed connections, their forwarding behavior is deterministic and not the primary focus of this method.

[0066] By acquiring forwarding decision information for these specific target PEs, the data plane obtains a clear and explicit "target list" and "action instructions," ensuring that every forwarding action of the data plane is precisely guided by the intelligent decision-making of the control plane, so that the high-speed data plane does not need to perform complex real-time calculations.

[0067] Step B12: Send the BUM traffic only to the PEs in the target PEs that are instructed by the forwarding decision information to forward the BUM traffic.

[0068] The forwarding decision information is determined based on the Ethernet segment where each target PE resides and its forwarding permissions within that segment: If the Ethernet segment where the target PE is located and the forwarding authority in its Ethernet segment instruct the target PE to forward the BUM traffic received from the local PE, the forwarding decision information instructs the target PE to forward the BUM traffic. If the Ethernet segment where the target PE is located and the forwarding permission indication in its Ethernet segment determine that the target PE will drop the BUM traffic received from the local PE, the forwarding decision information indicates that the BUM traffic should not be forwarded to the target PE.

[0069] Selective forwarding directly addresses the core issue of BUM traffic forwarding in multi-homed scenarios—namely, sending invalid traffic replicas to non-DF nodes or nodes within the same ESI group. Specifically: For the target PE indicated by the forwarding decision information as "forward", the message copying and SRv6 encapsulation and transmission are performed normally.

[0070] For target PEs that are indicated as "do not forward" by the forwarding decision information (i.e., those PEs that are determined to "not forward the BUM traffic of the local PE", usually including non-DF devices in multiple groups, or devices with the same ESI as the source PE), the system controls not to forward the BUM traffic to the target PE, thereby not occupying the bandwidth resources between the local PE and the target PE.

[0071] The BUM traffic forwarding method described in this embodiment suppresses BUM traffic copies destined for invalid targets within multi-homed groups on the source device initiating BUM traffic forwarding. This maximizes the saving of network core link bandwidth and processing resources of all related PE devices, thereby greatly improving the overall forwarding efficiency and economic benefits of SRv6 networks carrying EVPN BUM services in complex multi-homed access scenarios.

[0072] In one specific embodiment, in step B11, a forwarding decision header is added to the BUM traffic forwarding table. Different values ​​are set in the forwarding decision header for each target PE's forwarding table entry to indicate whether to perform a forwarding operation or a dropping operation on the BUM traffic sent to that target PE, so as to record the forwarding decision information of each target PE.

[0073] In step B11, this embodiment pre-calculates and stores a separate, dedicated value in the BUM traffic forwarding table, and assigns the intelligent decision-making of the control plane to the data plane in the form of concise instructions, thereby greatly optimizing the processing flow of the data plane while maintaining the precise control capability at the source.

[0074] In one specific embodiment, the implementation method of selective forwarding is described in step B12.

[0075] This embodiment aims to find a way to perform source drop with minimal changes to the existing data plane and maximum processing efficiency. This is achieved by reusing existing, highly optimized packet forwarding and dropping logic, rather than creating new, complex drop paths.

[0076] Specifically, the distinction between traffic forwarded by decision instructions and traffic dropped by decision instructions is not based on whether a packet is generated, but rather on generating packets with different lifecycles to achieve unified encapsulation but differentiated labeling.

[0077] For example, SRv6 packets are generated for all target PEs, but the system controls the packet processing behavior by setting different maximum router hop counts (i.e., time to live) within the packets. This ensures the uniformity and compliance of the packet format, while transforming the logic of forwarding and dropping into a simple assignment operation of a single field, which is very easy to implement efficiently in hardware.

[0078] Furthermore, the maximum router hop count can be carried in the IPv6 header field of the SRv6 message.

[0079] In a preferred embodiment, the optional field is the Hop Limit field in the IPv6 header. This is an 8-bit field specifically used to define the maximum number of hops a packet can traverse. A value of 0 indicates the packet will be discarded, which perfectly meets the design requirements of this invention. This is the most standard, efficient, and cost-free implementation.

[0080] In an alternative implementation, another path for achieving control is provided. Compared to directly using the Hop Limit field, it requires parsing the extended header, the processing logic is relatively complex, it may introduce additional processing overhead, and it requires the network device to support the newly defined option. Therefore, it is usually used as a backup technology when the Hop Limit field cannot be utilized.

[0081] Furthermore, the maximum hop count for the router is located in the hop count limit field of the IPv6 header.

[0082] In a preferred embodiment, the Hop Limit is set to 255 (a non-zero value) for traffic indicating forwarding; and to 0 for traffic indicating dropping. A value of 255 is a common initial value for IPv6 packets, ensuring that packets have enough hops to reach any destination within the network. A value of 0 directly triggers the dropping behavior specified by the protocol. This scheme is simple, clear, and fully compliant with protocol specifications.

[0083] In alternative implementations, for traffic indicating forwarding, the Hop Limit can be set to any reasonable non-zero value, such as 128 or 64, as long as the value ensures the packet effectively reaches the target PE. For traffic indicating discarding, the core requirement is to trigger first-hop discarding. Although setting it to 0 is the most direct approach, logically, setting a sufficiently small value (e.g., 1) and ensuring that the number of hops from the source PE to the target PE necessarily exceeds that value can also achieve the effect of "discarding in the transmission path." However, setting it to 0 is the most reliable and economical way to achieve this goal.

[0084] In step B12, through the above-described data plane implementation method, the intelligent decision-making of the control plane is transformed into a simple operation on a single field of the SRv6 message, thereby achieving near-zero-overhead source suppression of invalid BUM traffic. In addition, without modifying the existing message forwarding logic, it makes full use of the widely deployed hardware capabilities, achieving maximum bandwidth and processing resource savings at the lowest cost, thus ensuring the high performance and high feasibility of the solution.

[0085] Figure 4 A more complex EVPN VPLS over SRv6 networking scenario is illustrated. This network includes at least four PEs: PE1, PE2, PE3, and PE4. All four PE devices are bound to the same EVPN VPLS SRv6 instance. On the network access side, PE1 and PE2 connect to CE1 via their AC interfaces and are configured with the same Ethernet segment identifier esi1, forming the first multi-group; PE3 and PE4 connect to CE2 via their AC interfaces and are configured with the same Ethernet segment identifier esi2, forming the second multi-group. In this network, each of the four PE devices acts as a target PE for the other PEs.

[0086] exist Figure 4 The management method and traffic forwarding method of the BUM traffic forwarding table in the network shown are as follows: Taking PE1 as an example, PE1's local ESI is esi1, and it is in DF state on esi1.

[0087] Based on the DF state and ESI comparison results of each target PE, the forwarding decision information of each target PE in PE1 is as follows: When the target PE is PE2, PE2 is in a non-DF state during the DF election of esi1; PE2's ESI (esi1) is the same as PE1's local ESI (esi1). Since PE2 does not meet the condition of "being in a DF state" and its ESI is the same as its local ESI, the forwarding decision information for PE2 is to discard it.

[0088] When the target PE is PE3, PE3 is in the DF state during the DF election of esi2; the ESI (esi2) of PE3 is different from the local ESI (esi1) of PE1. Since PE3 satisfies both the conditions of "being in the DF state" and "ESI being different from the local ESI", the forwarding decision information for PE3 is forwarding.

[0089] When the target PE is PE4, PE4 is in a non-DF state during the DF election of esi2; PE4's ESI (esi2) is different from PE1's local ESI (esi1). Although PE4's ESI is different from its local ESI, it is in a non-DF state and does not meet the forwarding conditions, so PE4's forwarding decision information is to be discarded.

[0090] Taking PE1 as an example, the actual BUM traffic forwarding behavior is as follows: When PE1 receives BUM traffic from its connected CE1 side, PE1, based on the forwarding decision information in the forwarding table, only sends the BUM traffic to the target remote PE, i.e., PE3, whose decision result is "forward". PE1 will not copy or send the BUM traffic to the target remote PEs, i.e., PE2 and PE4, whose decision result is "drop".

[0091] In this way, the BUM traffic forwarding behavior implemented by PE1 is highly accurate and efficient, ensuring that network resources are concentrated on transmitting the truly necessary copies of traffic.

[0092] Similarly, it can be seen that the BUM traffic forwarding table content and forwarding decisions of PE2, PE3 and PE4 are also relevant.

[0093] For PE2: PE2's local ESI is esi1, and it is in a non-DF state on esi1.

[0094] When the target PE is PE1, PE1's ESI is esi1, which is the same as PE2's local ESI; and PE1 is in the DF state on esi1. Since the ESIs are the same, the forwarding condition is not met, so the forwarding decision information for PE1 is to discard it.

[0095] When the target PE is PE3, PE3's ESI is esi2, which is different from PE2's local ESI; and PE3 is in the DF state on esi2. Since both the "DF state" and "different ESI" conditions are met, the forwarding decision information for PE3 is forwarding.

[0096] When the target PE is PE4, PE4's ESI is esi2, which is different from PE2's local ESI; however, PE4 is in a non-DF state on esi2. Since it does not meet the "DF state" condition, the forwarding decision information for PE4 is to discard it.

[0097] Therefore, when PE2 actually forwards BUM traffic, it will only send traffic to PE3.

[0098] For PE3: PE3's local ESI is esi2, and it is in DF state on esi2.

[0099] When the target PE is PE1, PE1's ESI is esi1, which is different from PE3's local ESI; and PE1 is in the DF state on esi1. Since both the "DF state" and "different ESI" conditions are met, the forwarding decision information for PE1 is forwarding.

[0100] When the target PE is PE2, PE2's ESI is esi1, which is different from PE3's local ESI; however, PE2 is in a non-DF state on esi1. Since it does not meet the "DF state" condition, the forwarding decision information for PE2 is to discard it.

[0101] When the target PE is PE4, PE4's ESI is esi2, which is the same as PE3's local ESI; and PE4 is not in a DF state on esi2. Since the ESIs are the same, the forwarding conditions are not met, so PE4's forwarding decision is to discard. Therefore, when PE3 actually forwards BUM traffic, it will only send traffic to PE1.

[0102] For PE4: PE4's local ESI is esi2, and it is in a non-DF state on esi2.

[0103] When the target PE is PE1, PE1's ESI is esi1, which is different from PE4's local ESI; and PE1 is in the DF state on esi1. Since both the "DF state" and "different ESI" conditions are met, the forwarding decision information for PE1 is forwarding.

[0104] When the target PE is PE2, PE2's ESI is esi1, which is different from PE4's local ESI; however, PE2 is in a non-DF state on esi1. Since it does not meet the "DF state" condition, the forwarding decision information for PE2 is to discard it.

[0105] When the target PE is PE3, PE3's ESI is esi2, which is the same as PE4's local ESI; and PE3 is in the DF state on esi2. Since the ESIs are the same, the forwarding condition is not met, so the forwarding decision for PE3 is to discard it.

[0106] Therefore, when PE4 actually forwards BUM traffic, it will only send traffic to PE1.

[0107] In summary, under the control of the solution provided in this embodiment, all PE devices in the network generate BUM traffic forwarding tables according to unified decision rules, thereby ensuring that BUM traffic is forwarded only on the necessary paths and completely avoiding any invalid traffic copying and transmission.

[0108] Furthermore, embodiments of this application also provide a storage medium storing a computer program, wherein the computer program is configured to execute the method described above when running.

[0109] An electronic device includes a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the methods described above.

[0110] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A method for managing BUM traffic forwarding tables, characterized in that, include: Obtain the target PE from the remote PE of the local provider edge device PE, wherein the target PE and another PE are both connected to the same customer edge device CE within the same EVPN instance; Based on the Ethernet segment where each target PE is located and its forwarding permissions in that Ethernet segment, update the forwarding table entry of each target PE in the BUM traffic forwarding table of the local PE. The updated forwarding entry records include forwarding decision information, including: If the Ethernet segment where the target PE is located and the forwarding authority in its Ethernet segment instruct the target PE to forward the BUM traffic received from the local PE, the forwarding decision information instructs the target PE to forward the BUM traffic. If the Ethernet segment where the target PE is located and the forwarding authority indication in its Ethernet segment determine that the target PE will drop the BUM traffic received from the local PE, the forwarding decision information indicates that the BUM traffic should not be forwarded to the target PE.

2. The method according to claim 1, characterized in that: The Ethernet segment where the target PE is located is represented by the Ethernet segment identifier (ESI). The forwarding authority of the target PE in its Ethernet segment is indicated by the specified forwarder DF status. The process of obtaining the processing method of the target PE for the received BUM traffic of the local PE includes: Obtain the Ethernet segment identifier (ESI) of each target PE and the specified forwarder (DF) status on the ESI; If the target PE is in DF state and the target PE's ESI is different from the local PE's local ESI, then it is determined that the target PE will forward the received BUM traffic from the local PE; otherwise, it is determined that the target PE will discard the received BUM traffic from the local PE.

3. The method according to claim 2, characterized in that, The process of obtaining the ESI and DF state of each target PE includes: Exchange Type 4 routes with multiple remote PEs to complete the election of the designated forwarding device (DF); each PE learns the DF status of all other PEs on each ESI by processing the received Type 4 routes. After the DF election is completed, Type 1 routes are exchanged with multiple remote PEs. The Type 1 routes carry the ESI information of the sending PE. Each remote PE that sends the Type 1 route is identified as the target PE.

4. The method according to claim 3, characterized in that: The Type1 route also includes the value of the ARG_FE2 parameter field; Each target PE in the BUM traffic forwarding table records the value of the ARG_FE2 parameter field in its own Type1 route, so that the ARG_FE2 parameter corresponding to the target PE is filled into the SRv6 SID during the SRv6 encapsulation process.

5. A BUM traffic forwarding method, characterized in that, include: When BUM traffic needs to be sent, the forwarding decision information for each target PE is obtained from the remote PE in the local PE. Within the same EVPN instance, the target PE and another PE are both connected to the same CE; The BUM traffic is sent only to the PEs in the target PEs that are instructed by the forwarding decision information to forward the BUM traffic; wherein the forwarding decision information is determined based on the Ethernet segment where each target PE is located and its forwarding privileges within that Ethernet segment. If the Ethernet segment where the target PE is located and the forwarding authority in its Ethernet segment instruct the target PE to forward the BUM traffic received from the local PE, the forwarding decision information instructs the target PE to forward the BUM traffic. If the Ethernet segment where the target PE is located and the forwarding permission indication in its Ethernet segment determine that the target PE will drop the BUM traffic received from the local PE, the forwarding decision information indicates that the BUM traffic should not be forwarded to the target PE.

6. The method according to claim 5, characterized in that, Sending the BUM traffic only to the target PE indicated by the forwarding decision information includes: Send an SRv6 message carrying the maximum router hop count; where: If the forwarding decision information indicates that the target PE is to be forwarded, the maximum router hop count is a non-zero value; If the forwarding decision information indicates that the target PE is to be dropped, the maximum hop count of the router is zero; The maximum router hop count is decremented by 1 for each router the packet passes through, and the SRv6 packet is discarded when the maximum router hop count reaches 0.

7. The method according to claim 6, characterized in that, The maximum router hop count is carried in the IPv6 header field of the SRv6 message.

8. The method according to claim 7, characterized in that, The maximum hop count for the router is located in the Hop Limit field of the IPv6 header.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method described in any one of claims 1 to 8 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method as described in any one of claims 1 to 8.