L2VPN data transmission method, device and equipment capable of being used for FTTR

Abstract

The invention discloses an L2VPN data transmission method, device and equipment capable of being used for FTTR, and the method comprises the steps: receiving a service packet through a physical port, and transmitting the service packet to an SRv6 virtual interface which is created in a Linux kernel in advance according to a network bridge forwarding rule; according to the configuration of the SRv6 virtual interface, packaging the service packet into a first SRv6 BE L2VPN packet, and sending the first SRv6 BE L2VPN packet through an underlay link; a second SRv6 BE L2VPN packet is received, a de-encapsulation function registered in the Linux native function is called, and de-encapsulation is carried out on the second SRv6 BE L2VPN packet; and transmitting the service packet after the de-encapsulation operation from a corresponding physical port through the SRv6 virtual interface. Therefore, the problem that the existing Linux kernel only supports the L3VPN of the SRv6 BE mode and the SRv6 TE mode and does not support the L2VPN data transmission which can be used for the FTTR is solved.

Description

Technical Field

[0001] This application relates to the field of Internet Protocol data transmission technology, and in particular to an L2VPN data transmission method, apparatus and device that can be used for FTTR. Background Technology

[0002] With the development of IPv6 (Internet Protocol Version 6) and VPN (Virtual Private Network) technologies, more and more scenarios require IPv6-based L2VPN and L3VPN. One possible scenario is FTTR (Fiber to the Room), a communication network solution that transmits fiber optic signals indoors, enabling high-speed wireless network coverage throughout the house without dead zones. FTTR offers significant advantages and has a wide range of applications.

[0003] Currently, IPv6-based SRv6 (Segment Routing over IPv6) VPN technology has emerged as a leader, including L2VPN and L3VPN technologies such as SRv6 BE (Best-Effort) mode and SRv6 TE (Traffic Engineering) mode.

[0004] Currently, SRv6 BE and SRv6 TE L2VPN and L3VPN technologies are mostly used on high-performance devices, often employing self-developed protocol stacks or open-source protocol stacks such as VPP. The Linux kernel currently only supports SRv6 BE and SRv6 TE L3VPNs, not L2VPNs. Considering the limited functionality and low cost of edge devices, developing an SRv6 BE L2VPN based on the Linux kernel network protocol stack is still quite necessary. Summary of the Invention

[0005] The purpose of this application is to provide an L2VPN data transmission method, apparatus, and device that can be used for FTTR, in order to solve the problem that the current Linux kernel only supports L3VPN in SRv6 BE mode and SRv6 TE mode, and does not support L2VPN data transmission that can be used for FTTR.

[0006] In a first aspect, embodiments of this application provide an L2VPN data transmission method that can be used for FTTR, the method comprising: The service packets are received through the physical port and sent to the SRv6 virtual interface pre-created in the Linux kernel according to the pre-configured bridge forwarding rules. Based on the configuration information of the SRv6 virtual interface, the service packet is encapsulated into a first SRv6 BE L2VPN packet and then sent out through the physical network infrastructure layer underlay link; The second SRv6 BE L2VPN packet is received via the underlay link, and the decapsulation function registered in the Linux native function is called to perform decapsulation operation on the second SRv6 BE L2VPN packet; According to the bridge forwarding rules, the SRv6 virtual interface forwards the decapsulated service packets from the corresponding physical port.

[0007] In some possible embodiments, the method further includes: After receiving service packets through the physical port, determine whether the network card driver layer has matching message encapsulation rules; If it exists, the service packet is encapsulated into a first SRv6 BE L2VPN packet according to the matching message encapsulation rules and then sent; otherwise, the first message information of the service packet is recorded. After sending the first SRv6 BE L2VPN packet through the underlay link, record the second message information of the first SRv6 BE L2VPN packet; By comparing the first message information and the second message information, a corresponding message encapsulation rule is generated, and the message encapsulation rule is sent to the network card driver layer.

[0008] In some possible embodiments, the method further includes: After receiving the second SRv6 BE L2VPN packet through the underlay link, determine whether there are matching packet decapsulation rules in the network card driver layer; If present, the second SRv6 BE L2VPN packet is decapsulated according to the matching message decapsulation rules and sent out from the corresponding physical port; Otherwise, record the third message information of the second SRv6 BE L2VPN packet; after the service packet after decapsulation is sent from the corresponding physical port, record the fourth message information of the sent service packet. The third and fourth message information are compared to generate corresponding message decapsulation rules, and the message decapsulation rules are sent to the network card driver layer.

[0009] In some possible embodiments, the first message information includes the receiving interface and the five-tuple information of the service packet; The second message information includes the sending interface and outer encapsulation information, wherein the outer encapsulation information includes the local address and the peer address; The message encapsulation rules include the five-tuple information recorded in the table entries: local address, peer address, receiving interface, sending interface, and service packet.

[0010] In some possible embodiments, the third message information includes a receiving interface and outer encapsulation information, wherein the outer encapsulation information includes the local address and the peer address; The fourth message information includes the sending interface and the five-tuple information of the service packet; The message decapsulation rules include using the five-tuple information recorded in the table entries: local address, peer address, receiving interface, sending interface, and service packet.

[0011] In some possible embodiments, the configuration information of the SRv6 virtual interface includes the local address and the peer address; The bridge forwarding rules include the correspondence between physical ports and SRv6 virtual interfaces.

[0012] In some possible embodiments, the method further includes: When the table entry is generated, the timeout period of the table entry is initialized, and the timeout period is also initialized when the table entry is used for matching. If the timeout period is not initialized before the set time threshold is exceeded, the entry is deleted.

[0013] Secondly, embodiments of this application provide an L2VPN data transmission apparatus that can be used for FTTR, the apparatus comprising: The service packet receiving module is used to receive service packets through the physical port and send the service packets to the SRv6 virtual interface pre-created in the Linux kernel according to the pre-configured bridge forwarding rules. The service packet encapsulation module is used to encapsulate the service packet into a first SRv6 BE L2VPN packet according to the configuration information of the SRv6 virtual interface, and then send it out through the physical network infrastructure layer underlay link; The service packet decapsulation module is used to receive the second SRv6 BE L2VPN packet through the underlay link, call the decapsulation function registered in the Linux native function, and perform decapsulation operation on the second SRv6 BE L2VPN packet; The service packet sending module is used to forward the decapsulated service packets from the corresponding physical port through the SRv6 virtual interface according to the bridge forwarding rules.

[0014] Thirdly, another embodiment of this application also provides an L2VPN data transmission device that can be used for FTTR, including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute any L2VPN data transmission method that can be used for FTTR provided in the embodiments of this application.

[0015] Fourthly, another embodiment of this application also provides a computer storage medium storing a computer program for causing a computer to execute any L2VPN data transmission method applicable to FTTR provided in the embodiments of this application.

[0016] This application provides an L2VPN data transmission method, apparatus, and device for FTTR, offering an SRv6 virtual interface concept and designing a fusion scheme of virtual interface bridging architecture and kernel module programmable hooks. By implementing a dedicated SRv6 BE virtual interface in the Linux kernel and combining it with existing Linux bridging functions, L2VPN functionality based on the SRv6 virtual interface is achieved. This addresses the current issue that the Linux kernel only supports L3VPN in SRv6 BE and SRv6 TE modes and does not support L2VPN data transmission for FTTR.

[0017] 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. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. Obviously, the drawings introduced below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart of an L2VPN data transmission method for use in FTTR provided in this application embodiment; Figure 2 A schematic diagram of a hybrid architecture of fast and slow paths provided in an embodiment of this application; Figure 3 A schematic diagram of an L2VPN data transmission scenario that can be used for FTTR provided in the embodiments of this application; Figure 4 This is a schematic diagram illustrating virtual interface configuration based on the Linux kernel protocol stack, provided as an embodiment of this application. Figure 5 A flowchart illustrating the data transmission process combining fast and slow paths as provided in this application embodiment; Figure 6 A structural diagram of an L2VPN data transmission device that can be used for FTTR is provided for embodiments of this application; Figure 7 This is a structural diagram of an L2VPN data transmission device that can be used for FTTR, provided as an embodiment of this application. Detailed Implementation

[0020] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, more or fewer operation steps may be included in the method based on conventional or non-inventive effort. For steps that do not logically have a necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the control device executes the method, it may be executed sequentially or in parallel according to the method shown in the embodiments or drawings.

[0021] Currently, most L2VPN and L3VPN technologies in SRv6 BE and SRv6 TE modes are used on high-performance devices, often employing self-developed protocol stacks or open-source protocol stacks such as VPP. The Linux kernel currently only supports L3VPN in SRv6 BE and SRv6 TE modes, not L2VPN. Considering the limited functionality and low cost of edge devices, developing an L2VPN based on the Linux kernel network protocol stack in SRv6 BE mode is still necessary. Therefore, this application proposes an L2VPN data transmission method, apparatus, and device for FTTR.

[0022] 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. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings.

[0023] The L2VPN data transmission method applicable to FTTR in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0024] See Figure 1 This application provides an L2VPN data transmission method that can be used for FTTR, the method comprising: Step 101: Receive service packets through the physical port and send the service packets to the SRv6 virtual interface pre-created in the Linux kernel according to the pre-configured bridge forwarding rules. In this embodiment, based on the upper-layer network plan, the corresponding physical network infrastructure layer underlay information is configured beforehand. After establishing the underlay link, an SRv6 virtual interface srv6tun0 is created in the Linux kernel. This interface implements SRv6 BE encapsulation when sending packets. Utilizing existing Linux bridging capabilities, bridge forwarding rules are configured by creating the bvi0 interface. These rules include the correspondence between physical ports and SRv6 virtual interfaces. Specifically, the bridge forwarding rules are configured by adding srv6tun0 and the device's physical port lan1 to the bvi0 interface.

[0025] Step 102: Based on the configuration information of the SRv6 virtual interface, the service packet is encapsulated into a first SRv6 BE L2VPN packet and sent out through the physical network infrastructure layer underlay link; In this embodiment of the application, when the Linux kernel creates the SRv6 virtual interface srv6tun0, the virtual interface srv6tun0 is configured. The configuration information of the SRv6 virtual interface includes key information such as the local address local_sid and the remote address remote_sid. Then, after the SRv6 virtual interface srv6tun0 encapsulates the inner service packet into the first SRv6 BE L2VPN packet based on the configuration information, it is sent out through the physical network infrastructure layer underlay link.

[0026] Step 103: Receive the second SRv6 BE L2VPN packet through the underlay link, call the decapsulation function registered in the Linux native function, and perform decapsulation operation on the second SRv6 BE L2VPN packet; In this embodiment, the corresponding decapsulation function IPPROTO_ETHERNET(143) is pre-registered in the Linux native function inet6_add_protocol(&srv6be_protocol,IPPROTO_ETHERNET) to implement the SRv6 BE decapsulation operation.

[0027] Step 104: According to the bridge forwarding rules, the service packets after decapsulation are forwarded from the corresponding physical interface through the SRv6 virtual interface.

[0028] SRv6 BE (Best Effort) mode is an implementation of SRv6 technology that achieves SRv6 functionality through a best-effort approach, making it particularly suitable for branch scenarios such as small and medium-sized terminals. This application proposes an SRv6 virtual interface concept, designing a fusion scheme of virtual interface bridging architecture and kernel module programmable hooks. This scheme implements a dedicated SRv6 BE virtual network interface in the Linux kernel, combining it with existing Linux bridging functionality to achieve L2VPN functionality based on the SRv6 virtual interface. In this embodiment, the path implemented by creating an SRv6 virtual interface in the Linux kernel using the above method is a slow path. To improve performance, an accelerated fast path based on XDP (XML Data Package) is adopted. The XDP-accelerated fast path implements SRv6 BE encapsulation / decapsulation logic at the network card driver layer. It directly processes L2 frames through a custom XDP program, bypassing the kernel network stack. It learns packet encapsulation and decapsulation rules through the slow path and distributes the rules to the XDP-based fast path to achieve accelerated forwarding.

[0029] The method used in this application embodiment to learn packet encapsulation rules through a slow path is as follows: After receiving a service packet through the physical port, it is determined whether a matching packet encapsulation rule exists in the network interface card (NIC) driver layer. If it exists, the service packet is encapsulated into a first SRv6 BE L2VPN packet according to the matching packet encapsulation rule and then sent out. Otherwise, the first packet information of the service packet is recorded. After sending the first SRv6 BE L2VPN packet through the underlay link, the second packet information of the first SRv6 BE L2VPN packet is recorded. The first packet information and the second packet information are compared to generate a corresponding packet encapsulation rule, and the packet encapsulation rule is sent down to the NIC driver layer.

[0030] like Figure 2As shown, in this embodiment of the application, an XDP acceleration program is pre-developed at the network card driver layer. Service packets are received through the Intel network card receiver NIC_RX, where NIC_RX can be the physical port VLAN1. The first packet information info1 of the service packet is recorded. The XDP acceleration program is used to match the first packet information info with the packet encapsulation rules. If no matching packet encapsulation rules are found, the service packet is forwarded to the srv6tun0 virtual interface according to the Linux bridge forwarding rules. At the srv6tun0 virtual interface, the service packet is encapsulated with an SRv6 BE header according to the corresponding configuration information and sent out from the device underlay link. At the same time, the second packet information info2 after the service packet is sent out is recorded. Based on the comparison of info1 and info2 information, packet encapsulation rules are generated when the device sends packets. These rules are then sent to the network card driver layer. An XDP fast path is established through the XDP acceleration program, generating XDP acceleration information. Subsequently, service packets conforming to these encapsulation rules implement SRv6 BE encapsulation logic at the network card driver layer. L2 frames are directly processed through a custom XDP acceleration program, bypassing the kernel network stack to achieve a fast path.

[0031] In some possible embodiments, the first message information includes the receiving interface and the five-tuple information of the service packet; the second message information includes the sending interface and outer encapsulation information, the outer encapsulation information including the local address and the peer address; the message encapsulation rule includes using the local address, peer address, receiving interface, sending interface, and the five-tuple information of the service packet recorded in the table entry. Thus, when the network interface card driver layer receives a service packet, it extracts the five-tuple information and the receiving interface of the service packet, matches the extracted five-tuple information and the receiving interface with the table entries, finds a matching entry, adds an SRv6 BE header to the service packet according to the local address and peer address in the table entry, and simultaneously sends it out from the sending interface recorded in the table entry.

[0032] The method of learning packet decapsulation rules through slow path in this embodiment is as follows: After receiving the second SRv6 BE L2VPN packet through the underlay link, it is determined whether there is a matching packet decapsulation rule in the network card driver layer; if there is, the second SRv6 BE L2VPN packet is decapsulated according to the matching packet decapsulation rule and sent out from the corresponding physical port; otherwise, the third packet information of the second SRv6 BE L2VPN packet is recorded, the decapsulated service packet is forwarded from the corresponding physical port, and the fourth packet information of the sent service packet is recorded; the third packet information and the fourth packet information are compared to generate the corresponding packet decapsulation rule, and the packet decapsulation rule is sent down to the network card driver layer.

[0033] like Figure 2As shown, in this embodiment of the application, an XDP acceleration program is developed in advance at the network card driver layer. The second SRv6 BE L2VPN packet is received through the Intel network card receiver NIC_RX. NIC_RX can be the physical port of the underlay link. The third message information info3 of the second SRv6 BE L2VPN packet is recorded. The XDP acceleration program is used to match the second SRv6 BE L2VPN packet with the message decapsulation rules. If no matching message decapsulation rule is found, the SRv6BE protocol encapsulation header is stripped through the corresponding protocol processing function of the registered IPPROTO_ETHERNET (143). The resulting service packet is then sent to the srv6tun0 interface. The srv6tun0 virtual interface receives the service packet and then sends it out from NIC_TX according to the bridge forwarding rules. NIC_TX can be the physical port lan1. The fourth message information info4 is recorded.

[0034] Based on the comparison of info3 and info4 information, corresponding packet decapsulation rules are generated when the device sends packets. These rules are then distributed to the network interface card (NIC) driver layer. At the NIC driver layer, an XDP fast path is established using an XDP acceleration program, generating XDP acceleration information. Subsequent SRv6 BE L2VPN packets conforming to this decapsulation rule implement SRv6 BE decapsulation logic at the NIC driver layer. This allows for direct processing of L2 frames via a custom XDP acceleration program, bypassing the kernel network stack and achieving a fast path.

[0035] In some possible embodiments, the third message information mentioned above includes the receiving interface and outer encapsulation information, the outer encapsulation information including the local address and the peer address; the fourth message information includes the sending interface and the five-tuple information of the service packet; the message decapsulation rules include using the five-tuple information of the local address, peer address, receiving interface, sending interface, and service packet recorded in the table entries. Thus, after the network interface card driver layer receives the SRv6 BE L2VPN packet, it extracts the outer information of the SRv6 BE L2VPN packet to obtain the local address, peer address, and receiving interface. It then uses the inner five-tuple information to perform table entry matching. After obtaining a matching table entry, it uses the receiving interface and sending interface information to remove the outer SRv6 BE header and forwards the remaining inner service packet to the corresponding sending interface for transmission.

[0036] In some possible embodiments, in order to age up entries that have not been used for a long time, the timeout period of the entries is initialized when the entries are generated and when the entries are matched. If the timeout period is not initialized after a set time threshold is exceeded, the entries are deleted. This ensures that the entries stored in the network card driver layer are those with high usage frequency.

[0037] The following provides a specific embodiment of the L2VPN data transmission method that can be used in FTTR.

[0038] Example 1

[0039] The L2VPN data transmission method for FTTR provided in this application is a slow path forwarding scheme for SRv6 BE L2VPN implemented based on the Linux kernel, such as... Figure 3 The diagram illustrates an L2VPN data transmission service scenario that can be used for FTTR. The CPE (Customer Premises Equipment) uses the local address `local_sid`, and the SGW (Signaling Gateway) uses the remote address `remote_sid`. The CPE connects to two PCs (PC1). The specific steps are as follows: 1) Configuring Netlink interfaces via extended network connections: The creation, configuration, and deletion of SRv6 BE virtual interfaces are achieved through the extended RTM_NEWLINK and RTM_DELLINK message types of the Linux system.

[0040] 2) Create an SRv6 virtual interface srv6tun0 in the Linux kernel. This virtual interface contains local_sid and remote_sid information, which correspond to the local address and the remote address, respectively. This virtual interface implements the SRv6 BE encapsulation function. By registering the corresponding protocol processing function IPPROTO_ETHERNET(143), the SRv6 BE decapsulation operation is implemented.

[0041] like Figure 4 As shown, users can communicate with the SRv6 process via inter-process communication methods such as Web and command line. The SRv6 process configures the SRv6 BE module in the Linux kernel. The Linux kernel also includes other software modules, such as the Access Control List (ACL) module, the Quality of Service (QoS) module, the routing module, and the bridging module. The SRv6 BE module implements the creation, configuration, and deletion of SRv6 BE virtual interfaces, and further implements SRv6 BE decapsulation operations. The bridging module is used to configure bridge forwarding rules.

[0042] 3) Based on the corresponding underlay information, configure the corresponding SRv6 BE L2VPN related content to establish the underlay link. Utilize the existing Linux bridge function, create the bvi0 interface, add srv6tun0 and the device's physical port lan1 to the bvi0 interface, and realize the L2VPN service of the device connected to the lan1 port.

[0043] 4) Business logic and L2VPN forwarding rule learning: The service is connected through the lan1 port. After the lan1 port receives the service packet, it records the first message information info1 of the service packet. According to the Linux bridge forwarding rules, it forwards the packet to the srv6tun0 interface. According to the configuration of the srv6tun0 interface, the service packet is encapsulated with an SRv6 BE header and sent out from the device underlay link. At the same time, the second message information info2 after the service packet is sent is recorded.

[0044] The info1 definition is the information before SRv6 BE L2VPN encapsulation, which includes: the ingress interface and the five-tuple information of the inner service packet.

[0045] The info2 definition specifies that the information encapsulated by SRv6 BE L2VPN includes: the outgoing interface, outer encapsulation information, and the outer encapsulation information includes local_sid and remote_sid.

[0046] 5) Based on the comparison of info1 and info2 information, a corresponding packet encapsulation rule is generated when the device sends packets. This packet encapsulation rule is used as acceleration information and sent to the XDP program in the network card driver layer. The XDP program generates an XDP fast path based on the acceleration information. Subsequent packets that conform to this packet encapsulation rule implement SRv6 BE encapsulation logic in the network card driver layer. L2 frames are directly processed by a custom XDP program, bypassing the kernel network stack.

[0047] 6) In the packet receiving logic, when an SRv6 BE L2VPN packet is received on the underlay link, the acceleration rules are searched through the XDP program. At this time, the first SRv6 BE L2VPN packet does not have an XDP acceleration rule. Therefore, the service packet enters the slow path of the Linux kernel and records the third packet information info3 of the service packet. After the SRv6 BE protocol encapsulation header is stripped by the corresponding protocol processing function of IPPROTO_ETHERNET(143) registered when the SRv6 virtual interface is created, the srv6tun0 virtual interface receives the service packet and then sends out the fourth packet information info4 from the lan1 service port according to the bridge forwarding rules.

[0048] The info3 definition specifies that the information before the SRv6 BE L2VPN decapsulation includes: the ingress interface and the outer encapsulation information, which includes local_sid and remote_sid. The info4 definition specifies that the information after decapsulation of SRv6 BE L2VPN includes: the outgoing interface and the five-tuple information of the inner service packet.

[0049] 7) Based on the comparison of info3 and info4 information, the corresponding packet decapsulation rules are generated when the device sends packets. These packet decapsulation rules are used as acceleration information and sent to the XDP program in the network card driver layer. The XDP program generates the XDP fast path based on the acceleration information. Subsequently, packets that conform to the rules are decapsulated using the SRv6 BE decapsulation logic implemented in the network card driver layer. The L2 frames are processed directly by the custom XDP program, bypassing the kernel network stack and being sent directly from the corresponding interface.

[0050] The L2VPN data transmission method for FTTR provided in the embodiments of this application can support software forwarding of SRv6 BE L2VPN under the Linux framework.

[0051] Example 2

[0052] The L2VPN data transmission method for FTTR provided in this application embodiment can implement an XDP acceleration path for SRv6 BE L2VPN based on a combination of Linux's XDP and kernel network protocol stack, such as... Figure 5 As shown, the network card driver receives packets and extracts packet information using the XDP program. This packet information is then matched against entries used for acceleration. If a matching entry is found, the acceleration process is performed using that entry, and the network card driver then sends packets using the matching entry. If no matching entry is found, the packet is sent to the Linux kernel protocol stack for kernel SRv6 BE L2VPN slow path processing. After slow path processing, entries for acceleration are obtained. These entries are then sent back to the network card driver for subsequent packet sending. The specific process is as follows: 1) By using the built-in XDP program, the system receives and analyzes the info1 and info2 information carried by the Linux kernel protocol stack when sending SRv6 packets, and generates SRv6 BE L2VPN acceleration rules and corresponding entries. The key information is the five-tuple information of local_sid, remote_sid, receiving interface, sending interface, and inner service packet. The five-tuple information specifically includes source IP, destination IP, protocol, source port, and destination port.

[0053] 2) Decapsulation and packet reception direction: The outer information uses the five-tuple information of local_sid, remote_sid, receiving interface, and inner service packet to match the table entries. When searching for matching table entries, the outer SRv6 BE header is stripped through the receiving interface and sending interface information in the key information, and the remaining inner service packet is forwarded to the corresponding sending interface.

[0054] 3) Packet encapsulation direction: Match the inner service packet's five-tuple and receiving interface with the table entries. If a match is successful, add an SRv6 BE header to the service packet. This SRv6 BE header contains necessary information such as local_sid and remote_sid. Simultaneously, send the packet out from the sending interface recorded in the matching table entries. The specific process is shown in the table below:

[0055] The above entries in this application embodiment all include a timeout period. The timeout period is updated after business matching. If no business package is matched for a long time and the timeout period is not initialized, a timeout action will be performed to delete the entry.

[0056] 4) After all service packets are successfully matched, they are forwarded directly in the XDP program of the network card without going through the Linux kernel protocol stack, thus greatly improving performance.

[0057] 5) When a service packet fails to match, all service packets are sent to the Linux kernel protocol stack for software forwarding; if it is an SRv6 BE L2VPN related service, the information recorded by the software will be sent to XDP when the software sends the packet to generate an acceleration rule table.

[0058] This application embodiment utilizes Linux's XDP technology to achieve a fast forwarding path for SRv6 BE L2VPN, enabling rapid forwarding. Simultaneously, XDP is processed at the driver layer, avoiding kernel protocol stack overhead, making it particularly suitable for scenarios requiring high performance and low latency.

[0059] This application embodiment achieves functional support and performance acceleration of SRv6 BE L2VPN services on ordinary Linux devices by introducing a hybrid architecture that combines SRv6 virtual interfaces and XDP fast paths into the Linux kernel, thus solving the problems of Linux kernel's native lack of support for SRv6 BE L2VPN and insufficient performance of pure software forwarding.

[0060] Based on the same inventive concept, this application also provides an L2VPN data transmission device that can be used for FTTR, such as... Figure 6 As shown, the device includes: The service packet receiving module 601 is used to receive service packets through the physical port and send the service packets to the SRv6 virtual interface pre-created in the Linux kernel according to the pre-configured bridge forwarding rules. The service packet encapsulation module 602 is used to encapsulate the service packet into a first SRv6 BE L2VPN packet according to the configuration information of the SRv6 virtual interface, and then send it out through the physical network infrastructure layer underlay link; The service packet decapsulation module 603 is used to receive the second SRv6 BE L2VPN packet through the underlay link, call the decapsulation function registered in the Linux native function, and perform decapsulation operation on the second SRv6 BE L2VPN packet; The service packet sending module 604 is used to forward the decapsulated service packets from the corresponding physical port through the SRv6 virtual interface according to the bridge forwarding rules.

[0061] Having introduced the L2VPN data transmission method and apparatus for FTTR according to exemplary embodiments of this application, the following describes another exemplary embodiment of an L2VPN data transmission device for FTTR according to this application.

[0062] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0063] In some possible implementations, the L2VPN data transmission device for FTTR according to this application may include at least one processor and at least one memory. The memory stores program code that, when executed by the processor, causes the processor to perform the steps of the L2VPN data transmission method for FTTR according to the various exemplary embodiments of this application described above.

[0064] The following reference Figure 7 This application describes an L2VPN data transmission device 170 that can be used for FTTR according to this embodiment. Figure 7 The L2VPN data transmission device 170 shown for use with FTTR is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0065] like Figure 7 As shown, the L2VPN data transmission device 170 for FTTR is presented in the form of a general-purpose electronic device. Components of the L2VPN data transmission device 170 for FTTR may include, but are not limited to: at least one processor 171, at least one memory 172, and a bus 173 connecting different system components (including memory 172 and processor 171).

[0066] Bus 173 represents one or more of several bus architectures, including a memory bus or memory controller, peripheral bus, processor, or local bus using any of the various bus architectures.

[0067] The memory 172 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 1721 and / or cache memory 1722, and may further include read-only memory (ROM) 1723.

[0068] The memory 172 may also include a program / utility 1725 having a set (at least one) of program modules 1724, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0069] The L2VPN data transmission device 170 for FTTR can also communicate with one or more external devices 174 (e.g., keyboard, pointing device, etc.), one or more devices that enable users to interact with the L2VPN data transmission device 170 for FTTR, and / or any device that enables the L2VPN data transmission device 170 for FTTR to communicate with one or more other electronic devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 175. Furthermore, the L2VPN data transmission device 170 for FTTR can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 176. As shown, network adapter 176 communicates with other modules of the L2VPN data transmission device 170 for FTTR via bus 173. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the L2VPN data transmission device 170 that can be used for FTTR, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0070] In some possible implementations, various aspects of the L2VPN data transmission method for FTTR provided in this application can also be implemented as a program product comprising program code that, when run on a computer device, causes the computer device to perform the steps in the L2VPN data transmission method for FTTR according to the various exemplary embodiments of this application described above.

[0071] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0072] The program product for L2VPN data transmission that can be used for FTTR according to the embodiments of this application can be a portable compact disc read-only memory (CD-ROM) and include program code, and can run on an electronic device. However, the program product of this application is not limited thereto. In this document, the readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0073] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0074] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0075] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's electronic device, partially on the user's device, as a standalone software package, partially on the user's electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server. In cases involving remote electronic devices, the remote electronic device can be connected to the user's electronic device via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external electronic device (e.g., via the Internet using an Internet service provider).

[0076] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0077] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0078] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0079] This application is described with reference to flowchart illustrations and block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block and / or segment of the flowchart illustrations and block diagrams, as well as combinations of blocks and segments in the flowchart illustrations and block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart. Figure 1 One or more processes and boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0080] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and boxes Figure 1 The function specified in one or more boxes.

[0081] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and boxes Figure 1 The steps of the function specified in one or more boxes.

[0082] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0083] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An L2VPN data transmission method that can be used for FTTR, characterized in that, The method includes: The service packets are received through the physical port and sent to the SRv6 virtual interface pre-created in the Linux kernel according to the pre-configured bridge forwarding rules. Based on the configuration information of the SRv6 virtual interface, the service packet is encapsulated into a first SRv6 BE L2VPN packet and then sent out through the physical network infrastructure layer underlay link; The second SRv6 BE L2VPN packet is received via the underlay link, and the decapsulation function registered in the Linux native function is called to perform decapsulation operation on the second SRv6 BE L2VPN packet; According to the bridge forwarding rules, the SRv6 virtual interface forwards the decapsulated service packets from the corresponding physical port.

2. The method according to claim 1, characterized in that, Also includes: After receiving service packets through the physical port, determine whether the network card driver layer has matching message encapsulation rules; If it exists, the service packet is encapsulated into a first SRv6 BE L2VPN packet according to the matching message encapsulation rules and then sent; otherwise, the first message information of the service packet is recorded. After sending the first SRv6 BE L2VPN packet through the underlay link, record the second message information of the first SRv6 BE L2VPN packet; By comparing the first message information and the second message information, a corresponding message encapsulation rule is generated, and the message encapsulation rule is sent to the network card driver layer.

3. The method according to claim 1, characterized in that, Also includes: After receiving the second SRv6 BE L2VPN packet through the underlay link, determine whether there are matching packet decapsulation rules in the network card driver layer; If present, the second SRv6 BE L2VPN packet is decapsulated according to the matching message decapsulation rules and sent out from the corresponding physical port; Otherwise, record the third message information of the second SRv6 BE L2VPN packet; after the service packet after decapsulation is sent from the corresponding physical port, record the fourth message information of the sent service packet. The third and fourth message information are compared to generate corresponding message decapsulation rules, and the message decapsulation rules are sent to the network card driver layer.

4. The method according to claim 2, characterized in that, The first message information includes the receiving interface and the five-tuple information of the service packet; The second message information includes the sending interface and outer encapsulation information, wherein the outer encapsulation information includes the local address and the peer address; The message encapsulation rules include the five-tuple information recorded in the table entries: local address, peer address, receiving interface, sending interface, and service packet.

5. The method according to claim 3, characterized in that, The third message information includes the receiving interface and outer encapsulation information, and the outer encapsulation information includes the local address and the peer address; The fourth message information includes the sending interface and the five-tuple information of the service packet; The message decapsulation rules include using the five-tuple information recorded in the table entries: local address, peer address, receiving interface, sending interface, and service packet.

6. The method according to claim 1, characterized in that, The configuration information of the SRv6 virtual interface includes the local address and the peer address; The bridge forwarding rules include the correspondence between physical ports and SRv6 virtual interfaces.

7. The method according to claim 4 or 5, characterized in that, Also includes: When the table entry is generated, the timeout period of the table entry is initialized, and the timeout period is also initialized when the table entry is used for matching. If the timeout period is not initialized before the set time threshold is exceeded, the entry is deleted.

8. An L2VPN data transmission device that can be used for FTTR, characterized in that, The device includes: The service packet receiving module is used to receive service packets through the physical port and send the service packets to the SRv6 virtual interface pre-created in the Linux kernel according to the pre-configured bridge forwarding rules. The service packet encapsulation module is used to encapsulate the service packet into a first SRv6 BE L2VPN packet according to the configuration information of the SRv6 virtual interface, and then send it out through the physical network infrastructure layer underlay link; The service packet decapsulation module is used to receive the second SRv6 BE L2VPN packet through the underlay link, call the decapsulation function registered in the Linux native function, and perform decapsulation operation on the second SRv6 BE L2VPN packet; The service packet sending module is used to forward the decapsulated service packets from the corresponding physical port through the SRv6 virtual interface according to the bridge forwarding rules.

9. An L2VPN data transmission device that can be used for FTTR, characterized in that, The method includes at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-7.

10. A computer storage medium, characterized in that, The computer storage medium stores a computer program that enables the computer to perform the method as described in any one of claims 1-7.

Images