A message processing method and device

Abstract

The embodiment of the application provides a message processing method and device, the method is applied to a first UP device included in a UP backup group, and comprises the following steps: receiving a first DHCP request message sent by a first client; if a first DHCP response message sent by a CP device according to the first DHCP request message is received, and a second DHCP request message sent by the first client is received, forwarding the second DHCP request message to the CP device; if the first DHCP response message is not received, and the second DHCP request message is received, discarding the second DHCP request message. The scheme can reduce redundant messages between the UP device and the CP device, and improve IPoE online performance in load sharing.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a message processing method and apparatus. Background Technology

[0002] In load balancing scenarios with separate control and forwarding in Virtual Broadband Remote Access Server (vBRAS), User Plane (UP) backup is an important technology for improving system reliability. In UP backup, load balancing among UP devices improves UP load distribution and increases device utilization.

[0003] However, when an IPoE (Internet Protocol Over Ethernet) user comes online, the client of the IPoE user broadcasts or multicasts a Dynamic Host Configuration Protocol (DHCP) request message. Multiple load-sharing UP devices will receive this DHCP request message and forward it to the Control Plane (CP) device. The CP device, based on load balancing, determines one UP device (e.g., the first UP device), discards DHCP request messages forwarded by other UP devices, and constructs a DHCP response message based on the DHCP request message forwarded by the first UP device. Subsequently, if the client of the IPoE user broadcasts or multicasts a DHCP request message again, the multiple load-sharing UP devices will still receive the DHCP request message and forward it to the CP device for processing.

[0004] In this situation, the following problems will occur:

[0005] (1) Redundant DHCP request messages are sent to the CP device through the protocol channel between the UP device and the CP device on the UP device, which affects the user traffic forwarded by the UP device.

[0006] (2) The protocol channel between the UP device and the CP device is busy, which may affect the operation of other channels such as the management channel and control channel between the UP device and the CP device.

[0007] (3) The CP device needs to query the load sharing results and discard redundant DHCP request messages, which affects the performance of the CP device. Summary of the Invention

[0008] The purpose of this application is to provide a message processing method and apparatus to reduce redundant messages between UP devices and CP devices, and improve IPoE uptime performance during load balancing. The specific technical solution is as follows:

[0009] In a first aspect, embodiments of this application provide a message processing method applied to a first UP device included in a UP backup group, the method comprising:

[0010] Receive the first DHCP request message sent by the first client;

[0011] If a first DHCP response message is received from the CP device based on the first DHCP request message, and a second DHCP request message is received from the first client, then the second DHCP request message is forwarded to the CP device.

[0012] If the first DHCP response message is not received, but the second DHCP request message is received, then the second DHCP request message is discarded.

[0013] In some embodiments, the first UP device stores temporary entries, the temporary entries including client identification information and selection status; the method further includes:

[0014] After receiving the first DHCP request message sent by the first client, the identification information of the first client is recorded in the first temporary table entry, and the selected state included in the first temporary table entry is set to the unselected state.

[0015] When the first DHCP response message sent by the CP device is received, the selected state included in the first temporary table entry is set to the selected state;

[0016] If a first DHCP response message is received from the CP device based on the first DHCP request message, and a second DHCP request message is received from the first client, then forwarding the second DHCP request message to the CP device includes:

[0017] If the selected state of the first temporary table entry is set to the selected state, and a second DHCP request message sent by the first client is received, then the second DHCP request message is forwarded to the CP device.

[0018] The step of discarding the second DHCP request message if the first DHCP response message is not received but the second DHCP request message is received includes:

[0019] If the selected state of the first temporary entry is set to unselected, or if the first UP device does not store the first temporary entry and receives the second DHCP request message, then the second DHCP request message is discarded.

[0020] In some embodiments, the first DHCP request message includes the first MAC address of the first client, and the ingress interface of the first DHCP request message is the first interface; the identification information of the first client includes the first MAC address and the first interface; or...

[0021] The first DHCP request message includes the first DUID of the first client, and the ingress interface of the first DHCP request message is the first interface; the identification information of the first client includes the first DUID of the first client and the first interface.

[0022] In some embodiments, the method further includes:

[0023] When the aging timer corresponding to the first temporary entry expires, the first temporary entry is deleted.

[0024] In some embodiments, the second DHCP request message includes a first User Plane Identifier (UPID);

[0025] If a first DHCP response message is received from the CP device based on the first DHCP request message, and a second DHCP request message is received from the first client, then forwarding the second DHCP request message to the CP device includes:

[0026] If a second DHCP request message is received from the first client, and the first UPID is the same as the UPID of the first UP device, then the second DHCP request message is forwarded to the CP device.

[0027] If the first DHCP response message sent by the CP is not received, but the second DHCP request message sent by the first client is received, then discarding the second DHCP request message includes:

[0028] If a second DHCP request message is received from the first client, and the first UPID is different from the UPID of the first UP device, then the second DHCP request message is discarded.

[0029] In some embodiments, the second DHCP request message includes custom options, the custom options carrying the first UPID; or...

[0030] The second DHCP request message includes a server DUID option, which includes a UPID option, and the UPID option carries the first UPID.

[0031] Secondly, embodiments of this application provide a message processing method applied to a first client, the method comprising:

[0032] A first DHCP request message is sent to each UP device in the UP backup group, so that each UP device sends the first DHCP request message to the CP device, and the first UP device selected by the CP device sends a first DHCP response message to the first client;

[0033] When the first DHCP response message is received, a second DHCP request message is sent to each UP device, so that the first UP device forwards the second DHCP request message to the CP device, and the UP device not selected by the CP device discards the second DHCP request message.

[0034] In some embodiments, the second DHCP request message includes a first UPID; the UP device corresponding to the first UPID is the UP device that received the first DHCP response message.

[0035] In some embodiments, sending a second DHCP request message to each UP device upon receiving the first DHCP response message includes:

[0036] The system receives the first DHCP response message sent by the first UP device. The first DHCP response message includes a target option, which is either a custom option or a server DUID option. The custom option carries the first UPID, and the server DUID option includes a UPID option, which carries the first UPID.

[0037] A second DHCP request message is sent to each of the UP devices, the second DHCP request message including the target option.

[0038] Thirdly, embodiments of this application provide a message processing method applied to a CP device, the method comprising:

[0039] Receive the first DHCP request message sent by each UP device in the UP backup group, wherein the first DHCP request message is sent by the first client;

[0040] A first DHCP response message is sent to the first UP device selected from each UP device, so that the first UP device sends the first DHCP response message to the first client. After receiving the second DHCP request message sent by the first client, the first UP device forwards the second DHCP request message to the CP device. The UP devices that are not selected among the UP devices discard the second DHCP request message after receiving it.

[0041] In some embodiments, the second DHCP request message includes the UPID of the first UP device.

[0042] In some embodiments, the first DHCP response message includes a target option, which is either a custom option or a server DUID option. The custom option carries the UPID of the first UP device, and the server DUID option includes a UPID option, which carries the UPID of the first UP device.

[0043] Fourthly, embodiments of this application provide a message processing apparatus applied to a first UP device included in a UP backup group, the apparatus comprising:

[0044] The receiving module is used to receive the first DHCP request message sent by the first client;

[0045] The processing module is configured to forward the second DHCP request message to the CP device if it receives a first DHCP response message sent by the CP device according to the first DHCP request message and receives a second DHCP request message sent by the first client; and to discard the second DHCP request message if it does not receive the first DHCP response message but receives the second DHCP request message.

[0046] In some embodiments, the first UP device stores temporary entries, the temporary entries including client identification information and selection status; the processing module is further configured to:

[0047] After receiving the first DHCP request message sent by the first client, the identification information of the first client is recorded in the first temporary table entry, and the selected state included in the first temporary table entry is set to the unselected state.

[0048] When the first DHCP response message sent by the CP device is received, the selected state included in the first temporary table entry is set to the selected state;

[0049] If the selected state of the first temporary table entry is set to the selected state, and a second DHCP request message sent by the first client is received, then the second DHCP request message is forwarded to the CP device.

[0050] If the selected state of the first temporary entry is set to unselected, or if the first UP device does not store the first temporary entry and receives the second DHCP request message, then the second DHCP request message is discarded.

[0051] In some embodiments, the first DHCP request message includes the first MAC address of the first client, and the ingress interface of the first DHCP request message is the first interface; the identification information of the first client includes the first MAC address and the first interface; or...

[0052] The first DHCP request message includes the first DUID of the first client, and the ingress interface of the first DHCP request message is the first interface; the identification information of the first client includes the first DUID of the first client and the first interface.

[0053] In some embodiments, the apparatus further includes:

[0054] The aging module is used to delete the first temporary table entry when the aging timer corresponding to the first temporary table entry times out.

[0055] In some embodiments, the second DHCP request message includes a first UPID;

[0056] The processing module is specifically configured to: if it receives a second DHCP request message sent by the first client and the first UPID is the same as the UPID of the first UP device, then forward the second DHCP request message to the CP device; if it receives a second DHCP request message sent by the first client and the first UPID is different from the UPID of the first UP device, then discard the second DHCP request message.

[0057] In some embodiments, the second DHCP request message includes custom options, the custom options carrying the first UPID; or...

[0058] The second DHCP request message includes a server DUID option, which includes a UPID option, and the UPID option carries the first UPID.

[0059] Fifthly, embodiments of this application also provide a message processing apparatus applied to a first client, the apparatus comprising:

[0060] The first sending module is used to send a first DHCP request message to each UP device included in the UP backup group, so that each UP device sends the first DHCP request message to the CP device, and the first UP device selected by the CP device sends a first DHCP response message to the first client.

[0061] The second sending module is configured to send a second DHCP request message to each UP device when it receives the first DHCP response message, so that the first UP device forwards the second DHCP request message to the CP device, and the UP device not selected by the CP device discards the second DHCP request message.

[0062] In some embodiments, the second DHCP request message includes a first UPID; the UP device corresponding to the first UPID is the UP device that received the first DHCP response message.

[0063] In some embodiments, the second sending module is specifically configured to: receive a first DHCP response message sent by the first UP device, the first DHCP response message including a target option, the target option being a custom option or a server DUID option, the custom option carrying the first UPID, the server DUID option including a UPID option, the UPID option carrying the first UPID; and send a second DHCP request message to each UP device, the second DHCP request message including the target option.

[0064] Sixthly, embodiments of this application also provide a message processing apparatus applied to a CP device, the apparatus comprising:

[0065] The receiving module is used to receive a first DHCP request message sent by multiple UP devices included in the UP backup group, wherein the first DHCP request message is sent by a first client;

[0066] The sending module is configured to send a first DHCP response message to the first UP device selected from each UP device, so that the first UP device sends the first DHCP response message to the first client, and after receiving the second DHCP request message sent by the first client, forward the second DHCP request message to the CP device. The UP device that is not selected among the UP devices discards the second DHCP request message after receiving it.

[0067] In some embodiments, the second DHCP request message includes the UPID of the first UP device.

[0068] In some embodiments, the first DHCP response message includes a target option, which is either a custom option or a server DUID option. The custom option carries the UPID of the first UP device, and the server DUID option includes a UPID option, which carries the UPID of the first UP device.

[0069] This application embodiment also provides a UP device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0070] Memory, used to store computer programs;

[0071] When executing a program stored in memory, the processor implements any of the methods provided in the first aspect above.

[0072] This application embodiment also provides a client, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0073] Memory, used to store computer programs;

[0074] When executing a program stored in memory, the processor implements any of the methods provided in the second aspect above.

[0075] This application embodiment also provides a CP device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0076] Memory, used to store computer programs;

[0077] When a processor executes a program stored in memory, it implements any of the methods provided in the third aspect above.

[0078] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the methods provided in the first aspect, the second aspect, or the third aspect.

[0079] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform any of the methods provided in the first aspect, or any of the methods provided in the second aspect, or any of the methods provided in the third aspect.

[0080] Beneficial effects of the embodiments in this application:

[0081] In the technical solution provided in this application embodiment, after the UP device receives a first DHCP request message from the client of the IPoE user, if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has been load-balanced to the UP device; if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has not been load-balanced to the UP device. When the client is load-balanced to the UP device, the UP device receives a second DHCP request message sent by the client and forwards the second DHCP request message to the CP device; if the client is not load-balanced to the UP device, that is, the client is load-balanced to other UP devices included in the UP backup group, the UP device receives a second DHCP request message sent by the client, discards the second DHCP request message, and will not forward the second DHCP request message to the CP device. As can be seen, in this embodiment of the application, when the client is not load-sharing to a UP device, the UP device will not send the DHCP request message sent by the client to the CP device, thereby reducing redundant messages between the UP device and the CP device, thus reducing the busy level of the protocol channel between the UP device and the CP device, reducing the load on the CP device, and improving the IPoE online performance during load sharing.

[0082] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

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

[0084] Figure 1 This is a first schematic diagram of the vBRAS CUPS system architecture;

[0085] Figure 2 This is a second schematic diagram of the vBRAS CUPS system architecture;

[0086] Figure 3 A schematic diagram of a vBRAS CUPS network architecture;

[0087] Figure 4 A schematic diagram of a first type of message processing method provided in an embodiment of this application;

[0088] Figure 5A second flowchart illustrating the message processing method provided in the embodiments of this application;

[0089] Figure 6a A schematic diagram of a custom option in a DHCPv4 network provided in an embodiment of this application;

[0090] Figure 6b A schematic diagram of a custom option in a DHCPv6 network provided in an embodiment of this application;

[0091] Figure 6c A schematic diagram of the server DUID option provided in an embodiment of this application;

[0092] Figure 7 A schematic diagram of a third type of message processing method provided in the embodiments of this application;

[0093] Figure 8 A fourth flowchart illustrating the message processing method provided in this application embodiment;

[0094] Figure 9 A fifth flowchart illustrating the message processing method provided in this application embodiment;

[0095] Figure 10 A first type of interactive signaling diagram between the client, UP device, and CP device provided in the embodiments of this application;

[0096] Figure 11 A second type of interactive signaling diagram between the client, UP device, and CP device provided in the embodiments of this application;

[0097] Figure 12 A third type of interactive signaling diagram between the client, UP device, and CP device provided in the embodiments of this application;

[0098] Figure 13 A schematic diagram of a first structure of a message processing apparatus provided in an embodiment of this application;

[0099] Figure 14 This is a second structural schematic diagram of the message processing apparatus provided in the embodiments of this application;

[0100] Figure 15 A third structural schematic diagram of the message processing apparatus provided in the embodiments of this application;

[0101] Figure 16 A schematic diagram of the structure of a UP device provided in an embodiment of this application;

[0102] Figure 17 A schematic diagram of the structure of a client provided in an embodiment of this application;

[0103] Figure 18 This is a schematic diagram of a CP device provided in an embodiment of this application. Detailed Implementation

[0104] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0105] For ease of understanding, the terms appearing in the embodiments of this application are explained below.

[0106] The Virtual Broadband Remote Access Server (vBRAS) Control Plane and User Plane Separation (CUPS) system decouples the control plane (CP) and user plane (UP). It uses standard x86 servers instead of the traditional Broadband Remote Access Server (BRAS) physical hardware and abstracts the network functions of the traditional BRAS into a single software entity (vBRAS). This eliminates the reliance on dedicated hardware for network device functions, enabling rapid development and deployment of new services, as well as automatic deployment, elastic scaling, fault isolation, and self-healing based on service requirements. The vBRAS CUPS system architecture includes functional components such as CP devices, UP devices, service systems, an Element Management System (EMS), and a Management and Orchestration System (MANO).

[0107] 1) CP equipment (such as Figure 1 The vBRAS-CP resource pool in the vBRAS CUPS system architecture shown is responsible for control plane functions such as user authentication, address allocation, and management. The CP devices adopt a resource pooling deployment mode, fully leveraging the strong computing power of the vBRAS-CP resource pool. The CP devices may include the following components.

[0108] Virtualized Network Function (VNF): A virtualized software entity. VNFs implement various network functions by leveraging virtual resources virtualized by the Network Function Virtualization Infrastructure (NFVI). In the vBRAS CUPS system architecture, the Control Virtual Machine (CTRL-VM), BRAS-VM, Forwarding Virtual Machine (WD-VM), and Database Virtual Machine (DB-VM) can serve as VNFs.

[0109] NFVI: Virtualization Layer, responsible for fully virtualizing computing, storage, and network hardware resources and mapping them to virtual resources. In the vBRAS CUPS system architecture, a Cloud Automation System (CAS) can be used to act as the NFVI.

[0110] x86: Uses standard x86 servers to provide underlying physical hardware resources.

[0111] In practical applications, vBRAS-CP is positioned as a user control and management component, mainly including: Access Control (ACC) module, User Connection Management (UCM) module, Authentication Authorization Accounting (AAA) module, Unified Configuration Management (UNICFG) module, Address Management module, User Plane Management (UPMGR) module, and other functional modules.

[0112] User access control module: Used to process access protocol messages such as Point-to-Point Protocol Over Ethernet (PPPoE) or Internet Protocol Over Ethernet (IPoE) sent by vBRAS-UP, and to complete user access control.

[0113] The user management module includes user entry management and user policy management functions. The user entry management module generates user session entries and distributes them to vBRAS-UP to guide user-side traffic forwarding. The user policy management module manages policies related to user authentication, billing, authorization, address allocation, and Quality of Service (QoS).

[0114] AAA module: The vBRAS-CP and AAA server work together to complete the authentication, authorization and billing of access users.

[0115] Unified Configuration Management Module: vBRAS-CP uniformly completes the relevant configurations for BRAS services and automatically distributes the relevant configurations to all vBRAS-UPs managed by vBRAS-CP.

[0116] Address Management Module: This module manages the IP address resources owned by vBRAS-CP in a unified manner. It includes a Dynamic Host Configuration Protocol (DHCP) module.

[0117] UPMGR module: Includes management of vBRAS-UP joining / leaving and management of the communication channel between vBRAS-CP and vBRAS-UP.

[0118] 2) UP equipment (such as Figure 1 The vBRAS-UP in the vBRAS CUPS system architecture shown is responsible for forwarding plane functions such as user data traffic forwarding and traffic control. vBRAS-UP can be positioned as a Layer 3 network edge and user policy enforcement component. Depending on the physical form of the device, vBRAS-UP is divided into the following two types:

[0119] vBRAS-pUP (pUP for short): Physical devices such as network processors (NPs) act as UP devices. pUPs are characterized by high forwarding performance and can be used to handle high-bandwidth services such as broadband internet access and Internet Protocol Television (IPTV).

[0120] vBRAS-vUP (vUP for short): Virtualization devices such as x86 processors act as UP devices. vUPs are characterized by their strong computing power and can be used to handle services with high session size and low bandwidth requirements, such as Integrated Terminal Management Systems (ITMS) and Voice over Internet Protocol (VoIP). vUPs can be further categorized based on their device form factor:

[0121] Centralized vUP: A centralized virtualization device acts as the UP device.

[0122] Distributed vUP: A distributed virtualization device acts as the UP device. This type of vUP consists of two types of virtual machines (VMs): a virtualization main control board (MPU-VM) and a virtualization interface board (LPU-VM).

[0123] There are three types of communication channels between the CP device and the UP device:

[0124] Management channel: Used to enable the CP device to query data and issue configurations to the UP device. The management channel between the CP device and the UP device can be a Network Configuration Protocol (NETCONF) connection.

[0125] Control Channel: Used for functions such as service entry distribution, querying, and interface resource information reporting. When a router or vBRAS acts as a UP device, the Control- / User-plane Separation Protocol (CUSP) channel can be used as the control channel between the CP device and the UP device; when a Layer 3 switch acts as a UP device, the OpenFlow protocol channel is used as the control channel between the CP device and the UP device.

[0126] Protocol Channel: Used for exchanging protocol messages such as Dynamic Host Configuration Protocol (DHCP), Address Resolution Protocol (ARP), and Point-to-Point Protocol over Ethernet (PPPoE). The protocol channel between the CP device and the UP device can be a Virtual Extensible Local Area Network (VXLAN) tunnel of the Generic Protocol Extension (GPE) type.

[0127] 3) Business System: It consists of servers of various business types, such as Authentication, Authorization, Accounting (AAA) server, DHCP server, portal server, and other servers, to provide users with business functions such as authentication, authorization, accounting, address allocation, and security policy control.

[0128] 4) EMS: Responsible for remote management of various network elements and network maintenance.

[0129] 5) MANO: Responsible for the lifecycle management and orchestration of NFVI hardware and software resources, as well as the lifecycle management and orchestration of VNFs. MANO includes the following types of components:

[0130] Virtualized Infrastructure Manager (VIM): Responsible for the unified management, monitoring, and optimization of physical hardware virtualization resources. In the vBRAS CUPS system architecture, a cloud operating system (CloudOS) can be used to assume the VIM role.

[0131] Virtualized Network Function Manager (VNFM): Responsible for the lifecycle management of VNFs. In the vBRAS CUPS system architecture, the VNF Manager can be used to assume the VNFM role.

[0132] Network Function Virtualization Orchestrator (NFVO): Responsible for orchestrating and managing basic resources and upper-layer software resources to implement network services. In the vBRAS CUPS system architecture, VNFM-vBRAS can be used to assume the NFVO role.

[0133] UP Backup: In the scenario of control-switch separation, the CP device determines the primary / backup status of the UP device or its interface based on the interface status and CUSP channel status of the UP device. This enables user services to quickly switch from the primary UP device or interface to the backup UP device or interface when the primary UP device or interface fails. When the primary UP device or interface recovers from the failure, user services can switch back from the backup UP device or interface to the primary UP device or interface, ensuring uninterrupted user services.

[0134] The UP backup network model includes the following basic concepts:

[0135] UP Backup Group: Multiple UP devices join the same UP backup group. Each UP device includes one or more interfaces, and user service backup is implemented based on the interfaces on the UP device.

[0136] UP Backup Policy Templates: Create UP backup policy templates with different UP backup modes according to different business needs, and specify the primary interface and backup interface in the UP backup policy template. Different interfaces of a UP device are located in different UP backup policy templates.

[0137] Main Interface: The interface that carries user services. The UP device where the main interface is located is the main UP device corresponding to the UP backup policy template.

[0138] Backup Interface: This interface is used to back up the primary interface. The UP device where the backup interface is located is the backup UP device in the corresponding UP backup policy template. When the primary interface fails, the backup interface takes over forwarding user traffic; when the primary interface recovers, traffic is switched back from the backup interface to the primary interface, ensuring that user traffic is not interrupted for a long time.

[0139] Virtual Media Access Control (MAC) Address: A UP backup policy template includes a primary interface and a backup interface using a unique virtual MAC address to ensure that the MAC address of the interface does not change after the primary and backup interfaces are switched. The UP device uses the virtual MAC address to respond to the user's online request.

[0140] UP backup modes include 1:1 hot standby mode, N:1 warm standby mode, and 1:N warm standby load-sharing mode. The virtual MAC address configuration for each UP backup mode is as follows:

[0141] For 1:1 hot standby mode: there is a one-to-one correspondence between the primary interface and the standby interface, and each pair of primary and standby interfaces corresponds to a unique virtual MAC address.

[0142] For the N:1 warm standby mode: N primary interfaces correspond to 1 standby interface. Each primary interface corresponds to a unique virtual MAC address. When a primary interface fails, the virtual MAC address of that primary interface is used by the new primary interface (i.e., the original standby interface) that takes over the failed primary interface.

[0143] For the 1:N warm standby load balancing mode: N+1 interfaces are all primary interfaces (1≤N≤15), with no backup interfaces. Each primary interface forms N pairs of primary and backup relationships with the other N primary interfaces. Each pair of primary and backup relationships corresponds to a unique virtual MAC address.

[0144] like Figure 2 The vBRAS CUPS system shown has CP devices connected to multiple UP devices via switching devices, and the UP devices can access the network via the switching devices. Figure 2 In this setup, UP devices A, B, and C are added to the same UP backup group. User service backup is implemented based on interface A1 on UP device A, interfaces B1 and B2 on UP device B, and interface C1 on UP device C. UP backup policy template 1 and UP backup policy template 2 are configured on the CP device. UP backup policy template 1 includes interfaces A1 and B1, and UP backup policy template 2 includes interfaces B2 and C1. The multiple UP devices in the UP backup group are connected to multiple user devices (e.g., PC1 to PC2).

[0145] In the UP backup network model, there are three load-sharing modes:

[0146] Load sharing mode: The interfaces of multiple UP devices included in the UP backup group all serve as primary interfaces for load sharing. For example... Figure 3 In the vBRAS CUPS network architecture shown, the CP device connects to the UP 1024, UP 1025, and UP 1026 devices via switches (SWs). Interfaces Ge1024 / 1 / 0 / 1 on the UP 1024, UP 1025, and UP 1026 are added to UP backup policy template 1. In the load-sharing mode based on UP backup policy template 1, Ge1024 / 1 / 0 / 1, Ge1025 / 1 / 0 / 1, and Ge1026 / 1 / 0 / 1 all serve as primary interfaces, and load balancing occurs among these three primary interfaces at the interface level.

[0147] N:1 Warm Standby Load Sharing Mode: In the UP backup group, among the N+1 UP device interfaces, N UP device interfaces serve as primary interfaces, and 1 UP device interface serves as a backup interface. Load sharing is performed among the N primary interfaces. For example... Figure 3 In the network architecture shown, interfaces Ge1024 / 1 / 0 / 1 on UP 1024, Ge1025 / 1 / 0 / 1 on UP 1025, and Ge1026 / 1 / 0 / 1 on UP1026 are added to UP backup policy template 1. In the N:1 warm standby load balancing mode based on UP backup policy template 1, Ge1024 / 1 / 0 / 1 and Ge1025 / 1 / 0 / 1 serve as primary interfaces, and Ge1026 / 1 / 0 / 1 serves as a backup interface. Traffic from user equipment 1 to user equipment 4 is load-balanced between these two primary interfaces, Ge1024 / 1 / 0 / 1 and Ge1025 / 1 / 0 / 1, with the load balancing granularity being the interface level.

[0148] 1: N-Warm Backup Load Balancing Mode: The interfaces of the N+1 UP devices in the UP backup group are all used as primary interfaces. Load balancing is achieved among the virtual MAC addresses corresponding to the N*(N+1) primary / backup relationships formed between each of the N+1 primary interfaces. For example... Figure 3 In the network architecture shown, in the 1:N warm standby load balancing mode based on UP backup strategy template 1, Ge1024 / 1 / 0 / 1, Ge1025 / 1 / 0 / 1, and Ge1026 / 1 / 0 / 1 form 2*3=6 primary and backup relationships. These 6 primary and backup relationships correspond to 6 virtual MAC addresses. Among these 6 virtual MAC addresses, the traffic from user equipment 1 to user equipment 4 is load-balanced, and the load balancing granularity is the virtual MAC address.

[0149] IPoE authentication authenticates and bills users based on their physical location, eliminating the need for users to enter a username and password when accessing the internet. In IPoE applications, clients and the BRAS are interconnected via a Layer 2 switch.

[0150] When an IPoE user (i.e., the client) dynamically obtains an IP address via DHCP, the BRAS intercepts the user's DHCP request message and authenticates the IPoE user. If the authentication is successful, the user is allowed to continue applying for a dynamic IP address; otherwise, the IPoE user access process is terminated.

[0151] In a vBRAS load balancing scenario with control and forwarding separation, when a client dynamically obtains an IP address via DHCP, all the UP devices involved in the load balancing will receive the DHCP request message sent by the client and forward it to the CP device. The CP device determines the UP device based on the load balancing (e.g., the first UP device), discards the DHCP request messages forwarded by other UP devices, and constructs a DHCP response message based on the DHCP request message forwarded by the first UP device. For example, the DHCP server may assign an IP address to the client and construct a DHCP response message to send to the CP device; or the address management module on the CP device may assign an IP address to the client and construct a DHCP response message.

[0152] Taking UP1024, UP1025, and UP1026 devices joining the same UP backup group as an example, and performing load balancing between interface A on UP1024, interface B on UP1025, and interface C on UP1026, the process is as follows: In a network based on Dynamic Host Configuration Protocol over Internet Protocol version 4 (DHCPv4), IPoE users are IPoE4 users. In a vBRAS control separation load balancing scenario, the process by which IPoE4 users dynamically obtain IP addresses via DHCP is as follows:

[0153] Step 1: The client where the IPoE4 user is located broadcasts a Discover message;

[0154] Step 2: UP1024, UP1025, and UP1026 devices can all receive the Discover message and forward it to the CP device.

[0155] Step 3: The CP device selects the UP device (such as interface A of the UP1024 device) according to the load sharing, forwards the Discover message from the UP1024 device to the DHCPv4 server, and discards the Discover messages from the UP1025 and UP1026 devices.

[0156] Step 4: The DHCPv4 server assigns an IP address to the client and constructs an Offer message, which is then sent to the CP device.

[0157] The DHCPv4 server can be integrated into the CP device. In this case, the DHCPv4 server can be configured using the address management module described above, and the CP device becomes the DHCPv4 server. Alternatively, the DHCPv4 server can be a standalone physical device; in this case, the CP device becomes the DHCPv4 relay.

[0158] Step 5: The CP device forwards the Offer message to the UP1024 device, and the UP1024 device forwards the Offer message to the client.

[0159] Step 6: The client of the IPoE4 user broadcasts a request message;

[0160] Step 7: UP1024, UP1025, and UP1026 devices can all receive the Request message and forward it to the CP device.

[0161] Step 8: The CP device queries the load balancing result of Step 3, forwards the Request message from the UP1024 device to the DHCPv4 server, and discards the Request messages from the UP1025 and UP1026 devices.

[0162] Step 9: The DHCPv4 server constructs an acknowledgment (Ack) message and sends the Ack message to the CP device.

[0163] Step 10: The CP device forwards the Ack message to the UP1024 device, and the UP1024 device forwards the Ack message to the client.

[0164] Step 11: After the client receives the Ack message, the IPoE4 user successfully goes online.

[0165] Taking UP1024, UP1025, and UP1026 devices joining the same UP backup group as an example, and performing load balancing between interface A on UP1024, interface B on UP1025, and interface C on UP1026, the process is as follows: In a network based on Dynamic Host Configuration Protocol over Internet Protocol version 6 (DHCPv6), IPoE users are IPoE6 users. In a vBRAS control separation load balancing scenario, the process by which IPoE6 users dynamically obtain IP addresses via DHCP is as follows:

[0166] Step 1: The client where the IPoE6 user is located sends a Solicit request message via multicast;

[0167] Step 2: UP1024, UP1025, and UP1026 devices can all receive the Solicit message and forward it to the CP device.

[0168] Step 3: The CP device selects the UP device (such as interface A of the UP1024 device) according to the load balancing, forwards the Solicit message from the UP1024 device to the DHCPv6 server, and discards the Solicit messages from the UP1025 and UP1026 devices.

[0169] Step 4: The DHCPv6 server assigns an IP address to the client and constructs an Advertise message, which is then sent to the CP device.

[0170] The DHCPv6 server can be integrated into the CP device. In this case, the DHCPv6 server configuration can be implemented using the address management module mentioned above, and the CP device becomes the DHCPv6 server. Alternatively, the DHCPv6 server can be a standalone physical device; in this case, the CP device becomes the DHCPv6 relay.

[0171] Step 5: The CP device forwards the Advertise message to the UP1024 device, and the UP1024 device forwards the Advertise message to the client.

[0172] Step 6: The client where the IPoE6 user is located sends a multicast request message;

[0173] Step 7: UP1024, UP1025, and UP1026 devices can all receive the Request message and forward it to the CP device.

[0174] Step 8: The CP device queries the load balancing result of Step 3, forwards the Request message from the UP1024 device to the DHCPv6 server, and discards the Request messages from the UP1025 and UP1026 devices.

[0175] Step 9: The DHCPv6 server constructs a reply message and sends the reply message to the CP device;

[0176] Step 10: The CP device forwards the Reply message to the UP1024 device, and the UP1024 device forwards the Reply message to the client.

[0177] Step 11: After the client receives the Reply message, the IPoE6 user successfully goes online.

[0178] In vBRAS load balancing scenarios with control separation, UP backup is a crucial technology for improving system reliability. In UP backup, load sharing among UP devices enhances UP load balancing and increases device utilization.

[0179] However, when an IPoE user comes online, the DHCP request message broadcast or multicast is received by all UP devices and sent to the CP device for processing. This leads to the following problem:

[0180] (1) Redundant DHCP request messages are sent to the CP device through the protocol channel between the UP device and the CP device on the UP device, which affects the user traffic forwarded by the UP device.

[0181] (2) The protocol channel between the UP device and the CP device is busy, which may affect the operation of other channels such as the management channel and control channel between the UP device and the CP device.

[0182] (3) The CP device needs to query the load sharing results and discard redundant DHCP request messages, which affects the performance of the CP device.

[0183] To address the aforementioned problems, embodiments of this application provide a message processing method, such as... Figure 4 As shown, the method, applied to the first UP device included in the UP backup group, includes the following steps:

[0184] Step S401: Receive the first DHCP request message sent by the first client;

[0185] Step S402: If a first DHCP response message is received from the CP device based on the first DHCP request message, and a second DHCP request message is received from the first client, then the second DHCP request message is forwarded to the CP device.

[0186] Step S403: If the first DHCP response message sent by the CP device according to the first DHCP request message is not received, and the second DHCP request message sent by the first client is received, then the second DHCP request message is discarded.

[0187] In the technical solution provided in this application embodiment, after the UP device receives a first DHCP request message from the client of the IPoE user, if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has been load-balanced to the UP device; if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has not been load-balanced to the UP device. When the client is load-balanced to the UP device, the UP device receives a second DHCP request message sent by the client and forwards the second DHCP request message to the CP device; if the client is not load-balanced to the UP device, that is, the client is load-balanced to other UP devices included in the UP backup group, the UP device receives a second DHCP request message sent by the client, discards the second DHCP request message, and will not forward the second DHCP request message to the CP device. As can be seen, in this embodiment of the application, when the client is not load-sharing to a UP device, the UP device will not send the DHCP request message sent by the client to the CP device, thereby reducing redundant messages between the UP device and the CP device, thus reducing the busy level of the protocol channel between the UP device and the CP device, reducing the load on the CP device, and improving the IPoE online performance during load sharing.

[0188] In this embodiment of the application, the UP backup group may include two or more UP devices. The multiple UP devices included in the UP backup group described below are UP devices that share the load with each other. The first UP device can be any UP device included in the UP backup group.

[0189] In step S401 above, the first client is the client where the IPoE user is located, and the first client can be any client connected to the first UP device. The first DHCP request message is a DHCP request message sent during the IPoE user's online process, such as the Discover and Request messages in DHCPv4 networking, and the Solicit and Request messages in DHCPv6 networking, etc.

[0190] When an IPoE user comes online, the first client of the IPoE user broadcasts or multicasts a first DHCP request message, which is then received by the first UP device.

[0191] After receiving the first DHCP request message, the first UP device can process the second DHCP request message sent by the first client based on the subsequently received DHCP response messages.

[0192] Specifically, the CP device selects the first UP device according to load balancing, that is, the first client load is distributed to the first UP device. Then, according to the first DHCP request message, the CP device sends a first DHCP response message to the first UP device. Subsequently, if the first UP device receives a second DHCP request message sent by the first client, the first UP device executes step S402 and forwards the second DHCP request message to the CP device.

[0193] The CP device selects another UP device (such as a second UP device) based on load balancing. That is, it offloads the load of the first client to the second UP device and sends a first DHCP response message to the second UP device according to the first DHCP request message. Subsequently, if the first UP device receives a second DHCP request message from the first client, it executes step S403 and discards the second DHCP request message. The second DHCP request message is the DHCP request message sent by the first client after sending the first DHCP request message. For example, in a DHCPv4 network, the first DHCP request message is a Discover message, and the second DHCP request message is a Request message; in a DHCPv6 network, the first DHCP request message is a Solicit message, and the second DHCP request message is a Request message.

[0194] In this way, when the UP backup group includes multiple UP devices, a client will only be load-sharing to one UP device. Consequently, only one UP device will forward the second DHCP request message to the CP device, reducing redundant messages between the UP and CP devices. This reduces the busyness of the protocol channel between the UP and CP devices, lowers the load on the CP device, and improves the IPoE online performance during load sharing.

[0195] In this embodiment of the application, the UP device can use the following two methods to determine whether the first client is load-sharing to the first UP device, that is, to determine how to process the second DHCP request message.

[0196] Method 1, a stateful solution.

[0197] In this embodiment, the first UP device stores temporary entries, which include the client's identification information and selected (bSelect) status. The bSelect status can be either selected or unselected. The selected status indicates that the first UP device has received the first DHCP response message, meaning that the client has been load-balanced to the UP device; the unselected status indicates that the first UP device has not received the first DHCP response message, meaning that the client has not been load-balanced to the UP device.

[0198] In this embodiment of the application, the client's identification information may vary depending on the network type. For example, in a DHCPv4 network, the client's identification information may include the client's MAC address and the ingress interface on the UP device (i.e., the interface of the UP device when performing load balancing, that is, the interface on the UP device that receives DHCP request messages); in a DHCPv6 network, the client's identification information may include the client's DHCPv6 Unique Identifier (DUID) and the ingress interface on the UP device.

[0199] After receiving the first DHCP request message sent by the first client, the first UP device can construct the first temporary table entry corresponding to the first client, record the identification information of the first client in the first temporary table entry, and set the bSelect state included in the first temporary table entry to an unselected state (such as a False state).

[0200] Before receiving the first DHCP response message from the CP device based on the first DHCP request message, the first UP device keeps the bSelect state included in the first temporary table entry in an unselected state. When it receives the first DHCP response message from the CP device, the first UP device sets the bSelect state included in the first temporary table entry to a selected state (such as True state).

[0201] Subsequently, when the first UP device receives the second DHCP request message sent by the first client, it can obtain the identification information of the first client based on the second DHCP request message. Then, it matches the obtained identification information of the first client with each temporary table entry stored by the first UP device to obtain the matching temporary table entry, namely the aforementioned first temporary table entry. If the bSelect state included in the first temporary table entry is set to the selected state, it means that the first UP device has received the first DHCP response message. If the bSelect state included in the first temporary table entry is set to the unselected state, it means that the first UP device has not received the first DHCP response message. If the first UP device does not store the first temporary table entry, it can also mean that the first UP device has not received the first DHCP response message.

[0202] In this case, such as Figure 5 As shown, a message processing method is also provided, applied to the first UP device included in the UP backup group, which may include the following steps:

[0203] Step S501: Receive the first DHCP request message sent by the first client;

[0204] In this embodiment, the first DHCP request message can be the first DHCP request message sent by the first client during the process of dynamically obtaining an IP address, such as the Discover message in DHCPv4 networking and the Solicit message in DHCPv6 networking. The first DHCP request message can also be any DHCP request message sent before the second DHCP request message, and there is no limitation on this.

[0205] When an IPoE user comes online, the first client of the IPoE user broadcasts or multicasts a first DHCP request message, which is then received by the first UP device.

[0206] Step S502: Record the identification information of the first client in the first temporary table entry, set the selected state included in the first temporary table entry to the unselected state, and forward the first DHCP request message to the CP device.

[0207] Upon receiving the first DHCP request message, the first UP device determines the identification information of the first client based on the first DHCP request message, and then records the identification information of the first client in the first temporary table entry, and sets the bSelect state included in the first temporary table entry to an unselected state (such as a False state).

[0208] In a DHCPv4 network, the first DHCP request message may include the MAC address of the first client (e.g., the first MAC address), and the incoming interface of the first DHCP request message is the first interface; the identification information of the first client includes the first MAC address and the first interface. That is, after receiving the first DHCP request message, the first UP device obtains the first MAC address of the first client from the first DHCP request message, determines the incoming interface of the first DHCP request message (i.e., the first interface), and records the correspondence between the first MAC address and the first interface, that is, records the first MAC address and the first interface in the first temporary table entry.

[0209] In a DHCPv6 network, the first DHCP request message may include the DUID of the first client (e.g., the first DUID), and the ingress interface of the first DHCP request message is the first interface; the identification information of the first client includes the first DUID and the first interface. That is, after receiving the first DHCP request message, the first UP device obtains the first DUID of the first client from the first DHCP request message, determines the ingress interface (i.e., the first interface) of the first DHCP request message, and records the correspondence between the first DUID and the first interface, that is, records the first DUID and the first interface in the first temporary table entry.

[0210] While recording the identification information of the first client, the first UP device can forward the first DHCP request message to the CP device. After receiving the first DHCP request message, the CP device selects a UP device in the UP backup group according to load balancing. It can construct the first DHCP response message corresponding to the first DHCP request message itself, or construct the first DHCP response message corresponding to the first DHCP request message through the DHCP server, and send the first DHCP response message to the selected UP device.

[0211] In some embodiments, each temporary entry is configured with an aging timer. When the aging timer corresponding to the first temporary entry times out, it indicates that the identification information of the first client included in the first temporary entry is invalid, and the first UP device deletes the first temporary entry, that is, deletes the identification information of the first client. This can effectively save storage resources of the first UP device. The duration of the aging timer can be set according to actual needs, for example, the duration of the aging timer can be 10 seconds, 15 seconds, etc.

[0212] Step S503: When the first DHCP response message sent by the CP device is received, the selected state included in the first temporary table entry is set to the selected state.

[0213] When the first UP device receives the first DHCP response message, it indicates that the first UP device is the selected UP device. The first client is load-sharing to the first UP device, and the bSelect state included in the first temporary table entry is set to the selected state (such as True state), and the first UP device sends the first DHCP response message to the first client. If the first UP device does not receive the first DHCP response message, it indicates that the first UP device is not the selected UP device, and the first client is load-sharing to other UP devices. The bSelect state included in the first temporary table entry is not processed, that is, the bSelect state included in the first temporary table entry remains in the False state.

[0214] Step S504: Receive the second DHCP request message sent by the first client;

[0215] Step S505: If the selected state included in the first temporary table entry is set to the selected state, then forward the second DHCP request message to the CP device.

[0216] Step S506: If the selected state of the first temporary entry is set to unselected state, or the first UP device does not store the first temporary entry, then the second DHCP request message is discarded.

[0217] The technical solution provided in this application embodiment allows each UP device in a UP backup group to determine whether it should process client traffic after sending a DHCP request message to the CP device. This means determining whether the client traffic is load-balanced to the UP device. Consequently, only the first client load-balanced to the UP device sends a DHCP request message to the CP device, reducing redundant messages between the UP and CP devices, improving the automation level of message processing, and enhancing message processing efficiency and flexibility.

[0218] Figure 5 In the illustrated embodiment, the first temporary entry is generated by the first UP device during the process of dynamically obtaining an IP address. In this embodiment, the first temporary entry can also be pre-configured by the user in the first UP device according to actual needs; this is not limited.

[0219] The stateful scheme provided in this application embodiment will be described below using DHCPv4 networking and DHCPv6 networking as examples respectively. The UP backup group includes UP device 1024, UP device 1025, and UP device 1026. Load sharing is performed between interface A of UP device 1024, interface B of UP device 1025, and interface C of UP device 1026. The MAC address of client 1 is MAC1, and the DUID of client 1 is DUID1.

[0220] (1) DHCPv4 networking.

[0221] In a DHCPv4 network, client 1 broadcasts a Discover message. UP devices 1024, 1025, and 1026 receive the Discover message, construct temporary entries (such as MAC-Port entries), set the bSelect state of the temporary entry to False, and start the corresponding aging timer for the temporary entry (e.g., 10s). Specifically, UP device 1024 constructs temporary entry 1, which includes MAC1 and interface A, and sets the bSelect state of temporary entry 1 to False. UP device 1025 constructs temporary entry 2, which also includes MAC1 and interface B, and sets the bSelect state of temporary entry 2 to False. UP device 1026 constructs temporary entry 3, which includes MAC1 and interface C, and sets the bSelect state of temporary entry 3 to False.

[0222] UP devices 1024, 1025, and 1026 each send the Discover message to the CP device; the CP device determines that client 1 is load-sharing to a certain device (such as UP device 1024); in this way, after the CP device obtains the Offer message, it sends the Offer message to UP device 1024.

[0223] After receiving the Offer message, UP device 1024 sets the bSelect state of temporary entry 1 to True and sends the Offer message to client 1. Meanwhile, the bSelect state of temporary entries 2 and 3 remains False.

[0224] Client 1 broadcasts a Request message; UP devices 1024, 1025, and 1026 receive the Request message respectively; UP device 1024 determines that the MAC address of client 1 is MAC1 based on the Request message, and determines that the ingress interface of the Request message is interface A, and further determines that temporary table entry 1 includes MAC1 and interface A, and that the bSelect state included in temporary table entry 1 is True. Then, UP device 1024 sends the Request message to CP device for processing.

[0225] Based on the Request message, UP device 1025 determines that the MAC address of client 1 is MAC1 and that the ingress interface of the Request message is interface B. Therefore, it determines that temporary entry 2 includes MAC1 and interface B, and that the bSelect state of temporary entry 2 is False. UP device 1025 then discards the Request message. Similarly, based on the Request message, UP device 1026 determines that the MAC address of client 1 is MAC1 and that the ingress interface of the Request message is interface C. Therefore, it determines that temporary entry 3 includes MAC1 and interface C, and that the bSelect state of temporary entry 3 is False. UP device 1026 then discards the Request message.

[0226] In this embodiment of the application, if the UP device does not record a temporary entry for the incoming interface including MAC1 and Request messages, such as if the UP device does not receive the first DHCP request message, or if the temporary entry is aged out and deleted, it can also indicate that the first UP device did not receive the first DHCP response message, the client was not load-sharing to the UP device, and the UP device discarded the Request message.

[0227] (2) DHCPv6 networking.

[0228] In a DHCPv6 network, client 1 multicasts a Solicit message. UP devices 1024, 1025, and 1026 receive the Solicit message, construct temporary entries (such as DUID entries), set the bSelect state of the temporary entry to False, and start the corresponding aging timer for the temporary entry. For example, the aging timer duration is 10 seconds. Specifically, UP device 1024 constructs temporary entry 1, which includes DUID1 and interface A, and sets the bSelect state of temporary entry 1 to False. UP device 1025 constructs temporary entry 2, which also includes DUID1 and interface B, and sets the bSelect state of temporary entry 3 to False.

[0229] UP devices 1024, 1025, and 1026 each send a Solicit message to the CP device; the CP device determines that client 1 is load-sharing to a certain device (such as UP device 1024); in this way, after the CP device obtains the Advertise message, it sends the Advertise message to UP device 1024.

[0230] After receiving the Advertise message, UP device 1024 sets the bSelect state of temporary entry 1 to True and sends the Advertise message to client 1. Meanwhile, the bSelect state of temporary entries 2 and 3 remains False.

[0231] Client 1 sends a Request message via multicast; UP devices 1024, 1025, and 1026 receive the Request message respectively; UP device 1024 determines that the DUID of client 1 is DUID1 based on the Request message, and determines that the ingress interface of the Request message is interface A, and further determines that temporary table entry 1 includes DUID1 and interface A, and that the bSelect state included in temporary table entry 1 is True. Then, UP device 1024 sends the Request message to the CP device for processing.

[0232] UP device 1025 determines, based on the Request message, that the DUID of client 1 is DUID1 and that the ingress interface of the Request message is interface B. Therefore, it determines that temporary entry 2 includes DUID1 and interface B, and that the bSelect state of temporary entry 2 is False. UP device 1025 then discards the Request message. UP device 1026 determines, based on the Request message, that the DUID of client 1 is DUID1 and that the ingress interface of the Request message is interface C. Therefore, it determines that temporary entry 3 includes DUID1 and interface C, and that the bSelect state of temporary entry 3 is False. UP device 1026 then discards the Request message.

[0233] In this embodiment of the application, if the UP device does not record a temporary entry for the incoming interface including DUID1 and Request messages, such as the UP device not receiving the first DHCP request message, or the temporary entry being aged out and deleted, it can also indicate that the first UP device did not receive the first DHCP response message, the client was not load-sharing to the UP device, and the UP device discarded the Request message.

[0234] In the technical solution provided in this application embodiment, the UP device uses temporary entries to ensure that only the UP device selected for load sharing sends DHCP request messages to the CP device, without requiring client cooperation, thus reducing the impact on the client.

[0235] Method 2, stateless solution.

[0236] In this embodiment, the second DHCP request message includes a first UPID. The first UPID is the ID of the UP device selected for load balancing by the CP device. When the first UPID is the same as the UPID of the first UP device, it indicates that the first client has been load balanced to the first UP device, the first UP device receives the first DHCP request message, and receives the first DHCP response message; when the first UPID is different from the UPID of the first UP device, it indicates that the first client has not been load balanced to the first UP device, the first UP device receives the first DHCP request message but does not receive the first DHCP response message, or the first UP device does not receive the first DHCP request message and does not receive the first DHCP response message.

[0237] In this embodiment, the UPID uniquely identifies a UP device. Upon receiving the second DHCP request message, the first UP device can obtain the first UPID included in the second DHCP request message and obtain the UPID of the first UP device; compare the first UPID with the UPID of the first UP device; if the first UPID is the same as the UPID of the first UP device, it means that the first client has been load-balanced to the first UP device, and forwards the second DHCP request message to the CP device; if the first UPID is different from the UPID of the first UP device, it means that the first client has not been load-balanced to the first UP device, and discards the second DHCP request message.

[0238] In this embodiment of the application, the second DHCP request message can include the first UPID in the following manner.

[0239] In method a, the second DHCP request message includes custom options, which carry the first UPID.

[0240] In DHCPv4 networking, custom options can be set to option 254. The structure of option 254 can be found in [link to documentation]. Figure 6a As shown. Figure 6a The numbers above represent bytes. Figure 6a In option 254 shown, taking the value field as an example with a length of 2 bytes, it does not serve as a limitation; the value field carries the UPID.

[0241] In DHCPv6 networking, the custom option is option 65534. The structure of option 65534 can be found in [link to documentation]. Figure 6b As shown. Figure 6b The numbers above represent bytes. Figure 6b In option 65534 shown, taking the value field as an example with a length of 2 bytes, it does not play a limiting role; the value field carries the UPID.

[0242] In this embodiment, the client needs to cooperate by adding a custom option to the second DHCP request message. Using this custom option, only the UP devices to which the client's load is distributed will report the second DHCP request message to the CP device. Each UP device does not need to maintain temporary entries, making the implementation process relatively simple.

[0243] In method b, the first DHCP request message includes a server DUID option, which includes a UPID option, and the UPID option carries the first UPID.

[0244] In DHCPv6 networking, the server DUID option is option 2, and in existing standards, option 2 is used to carry the server DUID. In this embodiment, a sub-option (such as the UPID option) is added under option 2, and the UPID option is used to carry the first UPID.

[0245] For example, option 2 can include two sub-options, namely sub-option 1 and sub-option 2. Sub-option 1 is used to carry the server DUID, and sub-option 2 is used to carry the first UPID. That is, sub-option 2 is the UPID option. In this case, the structure of the two sub-options is as shown in Table 1.

[0246] Table 1

[0247] sub option 1 type Server DUID 2 1 Sub option 1 length Length of server DUID 2 variable sub option 1 value The value of server DUID variable variable sub option 2 type UPID 2 2 Sub option 2 length Length of UPID 2 2 sub option 2 value UPID value 2 variable

[0248] At this point, the structure of option 2 is as follows: Figure 6c As shown, Figure 6c The numbers above represent bytes. `len1` indicates the length of the value field of option 2, and its value is variable. The value field of option 2 includes two sub-options: sub-option 1 and sub-option 2. `len2` indicates the length of the value field of sub-option 1, and its value is variable; the value field of sub-option 1 carries the specific value of the server DUID. `len3` indicates the length of the value field of sub-option 2, and its value is 2; the value field of sub-option 2 carries the specific value of the UPID.

[0249] In existing standards, when a client sends a second DHCP request message, it needs to add a server DUID option to the message. In this embodiment, the client does not need to cooperate; it only needs to add the server DUID option to the second DHCP request message according to existing standards. This ensures that only the UP devices to which the client is load-balanced report the first DHCP request message to the CP device. Each UP device does not need to maintain temporary entries, making the implementation process relatively simple.

[0250] Corresponding to the above-described message processing method applied to the first UP device included in the UP backup group, this application embodiment also provides a message processing method, such as... Figure 7 As shown, applied to the first client, the method includes the following steps:

[0251] Step S701: Send a first DHCP request message to each UP device included in the UP backup group, so that each UP device sends a first DHCP request message to the CP device, and the first UP device selected by the CP device sends a first DHCP response message to the first client.

[0252] Step S702: When the first DHCP response message is received, a second DHCP request message is sent to each UP device so that the first UP device forwards the second DHCP request message to the CP device. UP devices not selected by the CP device discard the second DHCP request message.

[0253] In this embodiment, the specific operations performed by each UP device in the UP backup group can be found in [reference needed]. Figure 4 Descriptions of some of the first UP devices are omitted here.

[0254] In the technical solution provided in this application embodiment, after the UP device receives a first DHCP request message from the client of the IPoE user, if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has been load-balanced to the UP device; if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has not been load-balanced to the UP device. When the client is load-balanced to the UP device, the UP device receives a second DHCP request message sent by the client and forwards the second DHCP request message to the CP device; if the client is not load-balanced to the UP device, that is, the client is load-balanced to other UP devices included in the UP backup group, the UP device receives a second DHCP request message sent by the client, discards the second DHCP request message, and will not forward the second DHCP request message to the CP device. As can be seen, in this embodiment of the application, when the client is not load-sharing to a UP device, the UP device will not send the DHCP request message sent by the client to the CP device, thereby reducing redundant messages between the UP device and the CP device, thus reducing the busy level of the protocol channel between the UP device and the CP device, reducing the load on the CP device, and improving the IPoE online performance during load sharing.

[0255] In this embodiment, when the UP device adopts a stateful scheme, the first client does not need to cooperate. When the UP device adopts a stateless scheme, the second DHCP request message may include a first UPID, and the UP device corresponding to the first UPID is the UP device that received the first DHCP response message. That is, if the first UPID is the same as the UP ID of the UP device, it means that the first client has been load-balanced to the UP device, and the UP device is the UP device selected by the CP device; if the first UPID is different from the UP ID of the UP device, it means that the first client has not been load-balanced to the UP device, and the UP device is not the UP device selected by the CP device.

[0256] For stateless solutions, such as Figure 8 As shown, a message processing method is also provided, applied to a first client, which may include the following steps:

[0257] Step S801: Send a first DHCP request message to each UP device included in the UP backup group, so that each UP device sends a first DHCP request message to the CP device, and the first UP device selected by the CP device sends a first DHCP response message to the first client.

[0258] In this embodiment, the first client broadcasts or multicasts a first DHCP request message. Multiple UP devices in the UP backup group can receive the first DHCP request message. Subsequently, each UP device will forward the received first DHCP request message to the CP device. After receiving the first DHCP request message, the CP device selects a UP device (such as the first UP device) from the UP backup group according to load balancing. It can construct a first DHCP response message corresponding to the first DHCP request message itself, or construct a first DHCP response message corresponding to a DHCP request message through a DHCP server, and send the first DHCP response message to the selected UP device (such as the first UP device). The first UP device sends the first DHCP response message to the first client. The first DHCP response message may include a target option, which can be a custom option or a server DUID option. The custom option carries the first UPID, and the server DUID option includes a UPID option, which carries the first UPID. The meaning of the custom option or server DUID option can be found in the above description and will not be repeated here.

[0259] Step S802: Receive a first DHCP response message sent by the first UP device. The first DHCP response message includes a target option, which is either a custom option or a server DUID option. The custom option carries the first UPID, and the server DUID option includes a UPID option, which carries the first UPID.

[0260] Step S803: Send a second DHCP request message to each UP device included in the UP backup group. The second DHCP request message includes target options.

[0261] After receiving the first DHCP response message, the first client does not need to identify the specific content of the target option in the DHCP response message. It can directly encapsulate the target option in the second DHCP request message and then broadcast or multicast the second DHCP request message.

[0262] In this embodiment of the application, by adding a target option to the second DHCP request message, it can be realized that only the UP device to which the client is load-shared will report the second DHCP request message to the CP device. Each UP device does not need to maintain temporary entries, and the implementation process is relatively simple.

[0263] Corresponding to the above-described message processing method applied to the first UP device included in the UP backup group, this application embodiment also provides a message processing method, such as... Figure 9 As shown, applied to CP devices, the method includes the following steps:

[0264] Step S901: Receive the first DHCP request message sent by each UP device in the UP backup group, wherein the first DHCP request message is sent by the first client;

[0265] Step S902: Send a first DHCP response message to the first UP device selected from each UP device, so that the first UP device sends a first DHCP response message to the first client, and after receiving the second DHCP request message sent by the first client, forward the second DHCP request message to the CP device. The UP devices that are not selected among the UP devices discard the second DHCP request message after receiving it.

[0266] In this embodiment, the specific operations performed by each UP device in the UP backup group can be found in [reference needed]. Figure 4 Descriptions of some of the first UP devices are omitted here.

[0267] In the technical solution provided in this application embodiment, after the UP device receives a first DHCP request message from the client of the IPoE user, if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has been load-balanced to the UP device; if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has not been load-balanced to the UP device. When the client is load-balanced to the UP device, the UP device receives a second DHCP request message sent by the client and forwards the second DHCP request message to the CP device; if the client is not load-balanced to the UP device, that is, the client is load-balanced to other UP devices included in the UP backup group, the UP device receives a second DHCP request message sent by the client, discards the second DHCP request message, and will not forward the second DHCP request message to the CP device. As can be seen, in this embodiment of the application, when the client is not load-sharing to a UP device, the UP device will not send the DHCP request message sent by the client to the CP device, thereby reducing redundant messages between the UP device and the CP device, thus reducing the busy level of the protocol channel between the UP device and the CP device, reducing the load on the CP device, and improving the IPoE online performance during load sharing.

[0268] In this embodiment, when the UP device adopts a stateful scheme, the CP device does not need to cooperate in processing. When the UP device adopts a stateless scheme, the second DHCP request message may include a first UPID, and the UP device corresponding to the first UPID is the UP device that received the first DHCP response message. Figure 9 In the illustrated embodiment, the first UP device receives the first DHCP response message. Therefore, the first UPID here is the UPID of the first UP device. If the first UPID is the same as the UPID of the UP device, it means that the first client has been load-balanced to the UP device, and the UP device is the UP device selected by the CP device. If the first UPID is different from the UPID of the UP device, it means that the first client has not been load-balanced to the UP device, and the UP device is not the UP device selected by the CP device.

[0269] For the stateless scheme, the first DHCP response message includes a target option, which can be a custom option or a server DUID option. The custom option carries the UPID of the first UP device, and the server DUID option includes a UPID option, which carries the UPID of the first UP device. The meaning of the custom option or the server DUID option can be found in the relevant descriptions above, and will not be repeated here.

[0270] In this embodiment, the first client broadcasts or multicasts a first DHCP request message. Multiple UP devices in the UP backup group can receive the first DHCP request message. Subsequently, each UP device forwards the received first DHCP request message to the CP device.

[0271] After receiving the first DHCP request message, the CP device selects a UP device (such as the first UP device) from the UP backup group according to load balancing, and then sends the first DHCP response message to the first client using any of the following methods:

[0272] Method 1: The CP device constructs a first DHCP response message corresponding to the first DHCP request message, and the first DHCP response message includes the target options; the first UP device sends the first DHCP response message to the first client.

[0273] Method 2: The CP device forwards the first DHCP request message to the DHCP server. The DHCP server constructs a second DHCP response message corresponding to the first DHCP request message and sends the second DHCP response message to the CP device. Based on the first DHCP response message, the CP device sends a first DHCP response message to the first client through the first UP device. If a target option is added to the second DHCP response message, the first DHCP response message is obtained; the CP device then sends the first DHCP response message to the first client through the first UP device.

[0274] The actions taken by the first client after receiving the first DHCP response message can be found in [reference needed]. Figure 8 The descriptions of the stateless schemes mentioned above will not be repeated here.

[0275] In this embodiment, by adding a target option to the first DHCP response message, the CP device can ensure that only the UP device to which the client is load-shared will report the second DHCP request message to the CP device. Each UP device does not need to maintain temporary entries, making the implementation process relatively simple.

[0276] The following is combined with Figures 10-12 The signaling diagram showing the interaction between the client, UP device, and CP device provides a detailed explanation of the message processing method provided in this application embodiment. Figures 10-12 In this context, the UP backup group involves load balancing among multiple UP devices.

[0277] Figure 10 In the signaling diagram showing the interaction between the client, UP device, and CP device, the UP device uses a stateful scheme. This is illustrated using a DHCPv4 network as an example.

[0278] Step S1001: The client sends a Discover message (as described in the first DHCP request message above).

[0279] In step S1002, after receiving the Discover message, multiple UP devices construct a temporary entry corresponding to the client, set the bSelect state included in the temporary entry to False, and forward the Discover message to the CP device respectively. This temporary entry includes the client's MAC address and the ingress interface of the Discover message.

[0280] In step S1003, the CP device selects a UP device (such as UP device 1) according to the load sharing and sends an Offer message (such as the first DHCP response message mentioned above) to the selected UP device according to the Discover message.

[0281] In step S1004, UP device 1 sets the bSelect status of the temporary table entry corresponding to the client to True and forwards the Offer message to the client.

[0282] Step S1005: The client sends a Request message (such as the second DHCP request message mentioned above).

[0283] In step S1006, after multiple UP devices receive the Request message, UP device 1 forwards the Request message to the CP device according to the temporary entry corresponding to the client and the bSelect state included in the temporary entry; other UP devices discard the Request message according to the temporary entry corresponding to the client and the bSelect state included in the temporary entry.

[0284] In step S1007, the CP device sends an Ack message to the UP device 1 based on the Request message.

[0285] Step S1008: UP device 1 forwards the Ack message to the client.

[0286] In step S1009, after the client receives the Ack message, the IPoE4 user successfully goes online.

[0287] In DHCPv6 networking, the signaling interactions between the client, UP device, and CP device are as described above. Figure 10 Similarities exist, but the differences are: 1) The identification information included in the temporary entries is different. In DHCPv6 networking, the identification information is the client DUID and the incoming interface, while in DHCPv4 networking, the identification information is the MAC address and the incoming interface; 2) In step S1001, the client sends a Solicit message, in step S1003, the CP device replies with an Advertise message, and in step S1007, the CP device replies with a Reply message.

[0288] Figure 11 In the signaling diagram showing the interaction between the client, UP device, and CP device, the UP device adopts a stateless scheme. This is based on a DHCPv4 network as an example.

[0289] Step S1101: The client broadcasts a Discover message (as described in the first DHCP request message above).

[0290] In step S1102, after receiving the Discover message, the multiple UP devices forward the Discover message to the CP device respectively.

[0291] In step S1103, the CP device selects a UP device (such as UP device 1) according to load balancing and sends an Offer message (such as the first DHCP response message mentioned above) to the selected UP device based on the Discover message. The Offer message includes option 254, which carries the UPID1 of UP device 1.

[0292] Step S1104: UP device 1 forwards the Offer message to the client.

[0293] In step S1105, the client broadcasts a Request message (as described in the second DHCP request message above). This Request message includes option 254.

[0294] The client encapsulates the options 254 included in the Offer message in a Request message, and then broadcasts the Request message.

[0295] In step S1106, after multiple UP devices receive the Request message, UP device 1 confirms that the UPID1 in option 254 is the same as the UPID1 of UP device 1, and forwards the Request message to the CP device; other UP devices confirm that the UPID1 in option 254 is different from the UPID of other UP devices, and discard the Request message.

[0296] In step S1107, the CP device sends an Ack message to the UP device 1 based on the Request message.

[0297] Step S1108: UP device 1 forwards the Ack message to the client.

[0298] In step S1109, after the client receives the Ack message, the IPoE4 user successfully goes online.

[0299] Figure 12 In the signaling diagram showing the interaction between the client, UP device, and CP device, the UP device adopts a stateless scheme. This is based on a DHCPv6 network as an example.

[0300] Step S1201: The client sends a Solicit message (as described in the first DHCP request message above).

[0301] In step S1202, after receiving the Solicit message, the multiple UP devices forward the Solicit message to the CP device respectively.

[0302] In step S1203, the CP device selects a UP device according to the load sharing and sends an Advertise message (such as the first DHCP response message mentioned above) to the selected UP device (such as UP device 1) according to the Solicit message.

[0303] The Advertise message includes option 65534, which carries UPID1 of UP device 1. Alternatively, the Advertise message includes option 2, which includes a UPID option carrying UPID1 of UP device 1.

[0304] In this embodiment of the application, options 65534 and 2 can be used to encapsulate the Advertise message after the CP device constructs it. Options 65534 and 2 can also be used to encapsulate the Advertise message in the CP device after the DHCP server constructs and sends it to the CP device.

[0305] Step S1204: UP device 1 forwards the Advertise message to the client.

[0306] In step S1205, the client sends a Request message (as described in the second DHCP request message above). This Request message includes option 65534 or option 2.

[0307] The client encapsulates option 65534 or option 2 included in the Advertise message in a Request message, and then sends the Request message.

[0308] In step S1206, after multiple UP devices receive the Request message, UP device 1 confirms that UPID1 in option 65534 or option 2 is the same as UPID1 of UP device 1, and forwards the Request message to the CP device; other UP devices confirm that UPID1 in option 65534 or option 2 is different from the UPID of other UP devices, and discard the Request message.

[0309] In step S1207, the CP device sends a Reply message to the UP device 1 based on the Request message.

[0310] Step S1208: UP device 1 forwards the Reply message to the client.

[0311] In step S1209, after the client receives the Reply message, the IPoE6 user successfully goes online.

[0312] The technical solution provided in this application reduces the number of packets exchanged between the UP device and the CP device when IPoE4 and IPoE6 users come online during load sharing in the UP device in the control-forwarding separation scenario, thereby improving the forwarding performance of the UP device and enhancing the user online performance.

[0313] Corresponding to the above message processing method, this application also provides a message processing apparatus, such as... Figure 13 As shown, the device is applied to the first UP device included in the UP backup group, and the device includes:

[0314] Receiver module 1301 is used to receive the first DHCP request message sent by the first client;

[0315] The processing module 1302 is configured to forward the second DHCP request message to the CP device if it receives a first DHCP response message sent by the CP device according to the first DHCP request message and receives a second DHCP request message sent by the first client; if it does not receive the first DHCP response message but receives the second DHCP request message, it discards the second DHCP request message.

[0316] In some embodiments, the first UP device stores temporary entries, which include the client's identification information and selection status;

[0317] The processing module 1302 can also be used to: after receiving a first DHCP request message sent by a first client, record the identification information of the first client in a first temporary entry and set the selected state included in the first temporary entry to an unselected state; when receiving a first DHCP response message sent by a CP device, set the selected state included in the first temporary entry to a selected state; if the selected state included in the first temporary entry is set to a selected state and a second DHCP request message sent by the first client is received, forward the second DHCP request message to the CP device; if the selected state included in the first temporary entry is set to an unselected state, or the first UP device does not store the first temporary entry and receives the second DHCP request message, discard the second DHCP request message.

[0318] In some embodiments, the first DHCP request message includes the first MAC address of the first client, and the incoming interface of the first DHCP request message is the first interface; the identification information of the first client includes the first MAC address and the first interface; or,

[0319] The first DHCP request message includes the first DUID of the first client, and the ingress interface of the first DHCP request message is the first interface; the identification information of the first client includes the first DUID and the first interface of the first client.

[0320] In some embodiments, the above-described message processing apparatus may further include:

[0321] The aging module is used to delete the first temporary table entry when the aging timer corresponding to the first temporary table entry times out.

[0322] In some embodiments, the second DHCP request message includes the first UPID;

[0323] The processing module 1302 can be specifically used to: if it receives a second DHCP request message sent by the first client and the first UPID is the same as the UPID of the first UP device, then forward the second DHCP request message to the CP device; if it receives a second DHCP request message sent by the first client and the first UPID is different from the UPID of the first UP device, then discard the second DHCP request message.

[0324] In some embodiments, the second DHCP request message includes custom options, which carry the first UPID; or...

[0325] The second DHCP request message includes a server DUID option, which includes a UPID option, and the UPID option carries the first UPID.

[0326] In the technical solution provided in this application embodiment, after the UP device receives a first DHCP request message from the client of the IPoE user, if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has been load-balanced to the UP device; if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has not been load-balanced to the UP device. When the client is load-balanced to the UP device, the UP device receives a second DHCP request message sent by the client and forwards the second DHCP request message to the CP device; if the client is not load-balanced to the UP device, that is, the client is load-balanced to other UP devices included in the UP backup group, the UP device receives a second DHCP request message sent by the client, discards the second DHCP request message, and will not forward the second DHCP request message to the CP device. As can be seen, in this embodiment of the application, when the client is not load-sharing to a UP device, the UP device will not send the DHCP request message sent by the client to the CP device, thereby reducing redundant messages between the UP device and the CP device, thus reducing the busy level of the protocol channel between the UP device and the CP device, reducing the load on the CP device, and improving the IPoE online performance during load sharing.

[0327] Corresponding to the above message processing method, this application also provides a message processing apparatus, such as... Figure 14 As shown, the device, applied to a first client, includes:

[0328] The first sending module 1401 is used to send a first DHCP request message to each UP device included in the UP backup group, so that each UP device sends a first DHCP request message to the CP device, and the first UP device selected by the CP device sends a first DHCP response message to the first client.

[0329] The second sending module 1402 is used to send a second DHCP request message to each UP device included in the UP backup group when it receives a first DHCP response message, so that the first UP device forwards the second DHCP request message to the CP device, and the UP device not selected by the CP device discards the second DHCP request message.

[0330] In some embodiments, the second DHCP request message includes a first UPID, and the UP device corresponding to the first UPID is the UP device that received the first DHCP response message.

[0331] In some embodiments, the second transmitting module 1402 may be specifically used for:

[0332] Receive the first DHCP response message sent by the first UP device. The first DHCP response message includes a target option, which is either a custom option or a server DUID option. The custom option carries the first UPID, and the server DUID option includes a UPID option, which carries the first UPID.

[0333] A second DHCP request message is sent to each UP device in the UP backup group. The second DHCP request message includes the target options.

[0334] In the technical solution provided in this application embodiment, after the UP device receives a first DHCP request message from the client of the IPoE user, if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has been load-balanced to the UP device; if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has not been load-balanced to the UP device. When the client is load-balanced to the UP device, the UP device receives a second DHCP request message sent by the client and forwards the second DHCP request message to the CP device; if the client is not load-balanced to the UP device, that is, the client is load-balanced to other UP devices included in the UP backup group, the UP device receives a second DHCP request message sent by the client, discards the second DHCP request message, and will not forward the second DHCP request message to the CP device. As can be seen, in this embodiment of the application, when the client is not load-sharing to a UP device, the UP device will not send the DHCP request message sent by the client to the CP device, thereby reducing redundant messages between the UP device and the CP device, thus reducing the busy level of the protocol channel between the UP device and the CP device, reducing the load on the CP device, and improving the IPoE online performance during load sharing.

[0335] Corresponding to the above message processing method, this application also provides a message processing apparatus, such as... Figure 15 As shown, the device is applied to a CP device and includes:

[0336] The receiving module 1501 is used to receive the first DHCP request message sent by each UP device included in the UP backup group, wherein the first DHCP request message is sent by the first client;

[0337] The sending module 1502 is used to send a first DHCP response message to the first UP device selected from each UP device, so that the first UP device sends the first DHCP response message to the first client, and after receiving the second DHCP request message sent by the first client, forwards the second DHCP request message to the CP device. The UP devices that are not selected among the UP devices discard the second DHCP request message after receiving it.

[0338] In some embodiments, the second DHCP request message includes the UPID of the first UP device.

[0339] In some embodiments, the first DHCP response message includes a target option, which is either a custom option or a server DUID option. The custom option carries the UPID of the first UP device, and the server DUID option includes a UPID option, which carries the UPID of the first UP device.

[0340] In the technical solution provided in this application embodiment, after the UP device receives a first DHCP request message from the client of the IPoE user, if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has been load-balanced to the UP device; if it subsequently receives a first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client has not been load-balanced to the UP device. When the client is load-balanced to the UP device, the UP device receives a second DHCP request message sent by the client and forwards the second DHCP request message to the CP device; if the client is not load-balanced to the UP device, that is, the client is load-balanced to other UP devices included in the UP backup group, the UP device receives a second DHCP request message sent by the client, discards the second DHCP request message, and will not forward the second DHCP request message to the CP device. As can be seen, in this embodiment of the application, when the client is not load-sharing to a UP device, the UP device will not send the DHCP request message sent by the client to the CP device, thereby reducing redundant messages between the UP device and the CP device, thus reducing the busy level of the protocol channel between the UP device and the CP device, reducing the load on the CP device, and improving the IPoE online performance during load sharing.

[0341] This application also provides a UP device, such as... Figure 16 As shown, it includes a processor 1601, a communication interface 1602, a memory 1603, and a communication bus 1604, wherein the processor 1601, the communication interface 1602, and the memory 1603 communicate with each other through the communication bus 1604.

[0342] Memory 1603 is used to store computer programs;

[0343] When the processor 1601 executes the program stored in the memory 1603, it implements any of the above-described message processing methods applied to the first UP device included in the UP backup group.

[0344] This application also provides a client, such as... Figure 17 As shown, it includes a processor 1701, a communication interface 1702, a memory 1703, and a communication bus 1704, wherein the processor 1701, the communication interface 1702, and the memory 1703 communicate with each other through the communication bus 1704.

[0345] Memory 1703 is used to store computer programs;

[0346] When the processor 1701 executes the program stored in the memory 1703, it implements any of the message processing methods applied to the first client.

[0347] This application also provides a CP device, such as... Figure 18 As shown, it includes a processor 1801, a communication interface 1802, a memory 1803, and a communication bus 1804, wherein the processor 1801, the communication interface 1802, and the memory 1803 communicate with each other through the communication bus 1804.

[0348] Memory 1803 is used to store computer programs;

[0349] When the processor 1801 executes the program stored in the memory 1803, it implements any of the message processing methods described above for the CP device.

[0350] The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0351] The communication interface is used for communication between the aforementioned UP device, client, or CP device and other devices.

[0352] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0353] The processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0354] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program. When the computer program is executed by a processor, it implements any of the above-described message processing methods applied to the first UP device included in the UP backup group, or any of the above-described message processing methods applied to the first client, or any of the above-described message processing methods applied to the CP device.

[0355] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the above-described message processing methods applied to the first UP device included in the UP backup group, or to execute any of the above-described message processing methods applied to the first client, or to execute any of the above-described message processing methods applied to the CP device.

[0356] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0357] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0358] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for apparatus, UP devices, clients, CP devices, storage media, and program products are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0359] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A message processing method, characterized in that, The method, applied to each first UP device included in the UP backup group, comprises: Receive a first DHCP request message sent by a first client; if a first DHCP response message is received from the CP device based on the first DHCP request message, and a second DHCP request message is received from the first client, then forward the second DHCP request message to the CP device; If the first DHCP response message is not received, but the second DHCP request message is received, then the second DHCP request message is discarded. The first UP device stores temporary entries, which include the client's identification information and selection status; the method further includes: After receiving the first DHCP request message sent by the first client, the identification information of the first client is recorded in the first temporary table entry, and the selected state included in the first temporary table entry is set to the unselected state. When the first DHCP response message sent by the CP device is received, the selected state included in the first temporary table entry is set to the selected state; If a first DHCP response message is received from the CP device based on the first DHCP request message, and a second DHCP request message is received from the first client, then forwarding the second DHCP request message to the CP device includes: If the selected state of the first temporary table entry is set to the selected state, and a second DHCP request message sent by the first client is received, then the second DHCP request message is forwarded to the CP device. The step of discarding the second DHCP request message if the first DHCP response message is not received but the second DHCP request message is received includes: If the selected state of the first temporary entry is set to unselected, or if the first UP device does not store the first temporary entry and receives the second DHCP request message, then the second DHCP request message is discarded. or, The second DHCP request message includes the first UPID; If a first DHCP response message is received from the CP device based on the first DHCP request message, and a second DHCP request message is received from the first client, then forwarding the second DHCP request message to the CP device includes: If a second DHCP request message is received from the first client, and the first UPID is the same as the UPID of the first UP device, then the second DHCP request message is forwarded to the CP device. If the first DHCP response message sent by the CP is not received, but the second DHCP request message sent by the first client is received, then discarding the second DHCP request message includes: If a second DHCP request message is received from the first client, and the first UPID is different from the UPID of the first UP device, then the second DHCP request message is discarded.

2. The method according to claim 1, characterized in that, The first DHCP request message includes the first MAC address of the first client, and the ingress interface of the first DHCP request message is the first interface; the identification information of the first client includes the first MAC address and the first interface; or, The first DHCP request message includes the first DUID of the first client, and the ingress interface of the first DHCP request message is the first interface; the identification information of the first client includes the first DUID of the first client and the first interface.

3. The method according to claim 1 or 2, characterized in that, The method further includes: When the aging timer corresponding to the first temporary entry expires, the first temporary entry is deleted.

4. A message processing method, characterized in that, Applied to a first client, the method includes: A first DHCP request message is sent to each UP device in the UP backup group, so that each UP device sends the first DHCP request message to the CP device, and the first UP device selected by the CP device sends a first DHCP response message to the first client; When the first DHCP response message is received, a second DHCP request message is sent to each UP device, so that the first UP device forwards the second DHCP request message to the CP device, and the UP device not selected by the CP device discards the second DHCP request message; The second DHCP request message includes a first UPID; the UP device corresponding to the first UPID is the UP device that received the first DHCP response message, and the second DHCP request message is used to instruct the UP device that receives the second DHCP request message to forward the second DHCP request message to the CP device when the first UPID is the same as its own UPID, and to discard the second DHCP request message when the first UPID is different from its own UPID.

5. The method according to claim 4, characterized in that, The step of sending a second DHCP request message to each UP device upon receiving the first DHCP response message includes: The system receives the first DHCP response message sent by the first UP device. The first DHCP response message includes a target option, which is either a custom option or a server DUID option. The custom option carries the first UPID, and the server DUID option includes a UPID option, which carries the first UPID. A second DHCP request message is sent to each of the UP devices, the second DHCP request message including the target option.

6. A message processing method, characterized in that, Applied to CP devices, the method includes: Receive the first DHCP request message sent by each UP device in the UP backup group, wherein the first DHCP request message is sent by the first client; A first DHCP response message is sent to the first UP device selected from each UP device, so that the first UP device sends the first DHCP response message to the first client. After receiving the second DHCP request message sent by the first client, the first UP device forwards the second DHCP request message to the CP device. The UP device that is not selected among each UP device discards the second DHCP request message after receiving it. The second DHCP request message includes the UPID of the first UP device, and the second DHCP request message is used to instruct the UP device that receives the second DHCP request message to forward the second DHCP request message to the CP device when the UPID is the same as its own UPID, and to discard the second DHCP request message when the UPID is different from its own UPID.

7. The method according to claim 6, characterized in that, The first DHCP response message includes a target option, which is either a custom option or a server DUID option. The custom option carries the UPID of the first UP device, and the server DUID option includes a UPID option, which carries the UPID of the first UP device.

8. A message processing apparatus, characterized in that, The apparatus is applied to each first UP device included in the UP backup group, the apparatus comprising: The receiving module is used to receive the first DHCP request message sent by the first client; The processing module is configured to forward the second DHCP request message to the CP device if it receives a first DHCP response message sent by the CP device according to the first DHCP request message and receives a second DHCP request message sent by the first client; and to discard the second DHCP request message if it does not receive the first DHCP response message but receives the second DHCP request message. The first UP device stores temporary entries, which include the client's identification information and selection status. The processing module is further configured to: after receiving a first DHCP request message sent by a first client, record the identification information of the first client in a first temporary entry, and set the selected state included in the first temporary entry to an unselected state; when receiving a first DHCP response message sent by the CP device, set the selected state included in the first temporary entry to a selected state; if the selected state included in the first temporary entry is set to a selected state, and a second DHCP request message sent by the first client is received, then forward the second DHCP request message to the CP device; if the selected state included in the first temporary entry is set to an unselected state, or the first UP device does not store the first temporary entry, and a second DHCP request message is received, then discard the second DHCP request message. or, The second DHCP request message includes the first UPID; The processing module is specifically configured to: if it receives the second DHCP request message sent by the first client and the first UPID is the same as the UPID of the first UP device, then forward the second DHCP request message to the CP device; if it receives the second DHCP request message sent by the first client and the first UPID is different from the UPID of the first UP device, then discard the second DHCP request message.

9. A message processing apparatus, characterized in that, Applied to a first client, the device includes: The first sending module is used to send a first DHCP request message to each UP device included in the UP backup group, so that each UP device sends the first DHCP request message to the CP device, and the first UP device selected by the CP device sends a first DHCP response message to the first client. The second sending module is configured to send a second DHCP request message to each UP device when the first DHCP response message is received, so that the first UP device forwards the second DHCP request message to the CP device, and the UP device not selected by the CP device discards the second DHCP request message; The second DHCP request message includes a first UPID; the UP device corresponding to the first UPID is the UP device that received the first DHCP response message, and the second DHCP request message is used to instruct the UP device that receives the second DHCP request message to forward the second DHCP request message to the CP device when the first UPID is the same as its own UPID, and to discard the second DHCP request message when the first UPID is different from its own UPID.

10. A message processing apparatus, characterized in that, Applied to CP devices, the apparatus includes: The receiving module is used to receive a first DHCP request message sent by each UP device included in the UP backup group, wherein the first DHCP request message is sent by a first client; The sending module is configured to send a first DHCP response message to the first UP device selected from each UP device, so that the first UP device sends the first DHCP response message to the first client, and after receiving the second DHCP request message sent by the first client, forward the second DHCP request message to the CP device. The UP device that is not selected among each UP device discards the second DHCP request message after receiving it. The second DHCP request message includes the UPID of the first UP device, and the second DHCP request message is used to instruct the UP device that receives the second DHCP request message to forward the second DHCP request message to the CP device when the UPID is the same as its own UPID, and to discard the second DHCP request message when the UPID is different from its own UPID.

Images