Message processing method and device

Abstract

The embodiment of the invention provides a message processing method and device, and the method is applied to a first UP device included in a UP backup group, and comprises the steps: receiving a first DHCP request message sent by a first client; if a first DHCP response message sent by the 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; and if the first DHCP response message is not received and the second DHCP request message is received, discarding the second DHCP request message. According to the scheme, redundant messages between the UP equipment and the CP equipment can be reduced, and the IPoE online performance during load sharing is improved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a message processing method and device. Background Art

[0002] In load-sharing scenarios with separate forwarding and control functions for virtual broadband remote access servers (vBRAS), user plane (UP) backup is a key technology for improving system reliability. In UP backup, load balancing between UP devices improves UP load balancing and increases device utilization.

[0003] However, when an Internet Protocol Over Ethernet (IPoE) user goes online, the client where the IPoE user is located broadcasts or multicasts a Dynamic Host Configuration Protocol (DHCP) request message, and the multiple UP devices that perform load balancing will all receive the DHCP request message sent by the client and forward the DHCP request message to the control plane (CP) device. The CP device determines a UP device (such as the first UP device) based on load balancing, and then discards the DHCP request message forwarded by other UP devices, and constructs a DHCP response message based on the DHCP request message forwarded by the first UP device. Subsequently, the client where the IPoE user is located broadcasts or multicasts a DHCP request message again, and the multiple UP devices that perform load balancing will still receive the DHCP request message sent by the client and forward the DHCP request message to the CP device for processing.

[0004] This situation will lead to the following problems:

[0005] (1) Redundant DHCP request messages are sent from the UP device to the CP device through the protocol channel between the UP device and the CP device, affecting 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 balancing results and discard redundant DHCP request messages, which affects the performance of the CP device. Summary of the Invention

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

[0009] In a first aspect, an embodiment of the present application provides a message processing method, applied to a first UP device included in a UP backup group, the method comprising:

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

[0011] If a first DHCP response message is received from the CP device in response to the first DHCP request message, and a second DHCP request message is received from the first client, forwarding the second DHCP request message to the CP device;

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

[0013] In some embodiments, the first UP device stores a temporary entry, where the temporary entry includes identification information and a selected status of the client; and the method further includes:

[0014] After receiving a first DHCP request message sent by a first client, recording identification information of the first client in a first temporary entry, and setting a selected state included in the first temporary entry to an unselected state;

[0015] When receiving the first DHCP response message sent by the CP device, setting the selected state included in the first temporary entry to the selected state;

[0016] The method of forwarding the second DHCP request message to the CP device if a first DHCP response message is received from the CP device in response to the first DHCP request message and a second DHCP request message is received from the first client includes:

[0017] If the selected state included in the first temporary entry is set to the selected state and a second DHCP request message sent by the first client is received, forwarding the second DHCP request message to the CP device;

[0018] If the first DHCP response message is not received and the second DHCP request message is received, discarding the second DHCP request message includes:

[0019] If the selected state included in the first temporary entry is set to the unselected state, or the first UP device does not store the first temporary entry, and the first UP device receives the second DHCP request message, 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, the inbound 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 inbound 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 comprises:

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

[0024] In some embodiments, the second DHCP request message includes a first user plane identifier (UPID);

[0025] The method of forwarding the second DHCP request message to the CP device if a first DHCP response message is received from the CP device in response to the first DHCP request message and a second DHCP request message is received from the first client includes:

[0026] If a second DHCP request message sent by the first client is received, and the first UPID is the same as the UPID of the first UP device, forwarding the second DHCP request message to the CP device;

[0027] The step of discarding the second DHCP request message if the first DHCP response message sent by the CP is not received and the second DHCP request message sent by the first client is received includes:

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

[0029] In some embodiments, the second DHCP request message includes a custom option, and the custom option carries the first UPID; or

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

[0031] In a second aspect, an embodiment of the present application provides a message processing method, applied to a first client, the method comprising:

[0032] Sending 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;

[0033] When receiving the first DHCP response message, 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 devices not selected by the CP device discard the second DHCP request message.

[0034] 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 receives the first DHCP response message.

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

[0036] receiving the first DHCP response message sent by the first UP device, where the first DHCP response message includes a target option, where the target option is a custom option or a server DUID option, where the custom option carries the first UPID, and where the server DUID option includes a UPID option, where the UPID option carries the first UPID;

[0037] A second DHCP request message is sent to each UP device, where the second DHCP request message includes the target option.

[0038] In a third aspect, an embodiment of the present application provides a message processing method, applied to a CP device, the method comprising:

[0039] receiving a first DHCP request message sent by each UP device included in the UP backup group, where the first DHCP request message is sent by a first client;

[0040] A first DHCP response message is sent to a first UP device selected from each of the UP devices, 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, the first UP device forwards the second DHCP request message to the CP device. After receiving the second DHCP request message, the unselected UP devices from each of the UP devices discard the second DHCP request message.

[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 a custom option or a server DUID option. The custom option carries the UPID of the first UP device. The server DUID option includes a UPID option, which carries the UPID of the first UP device.

[0043] In a fourth aspect, an embodiment of the present application provides a message processing apparatus, applied to a first UP device included in a UP backup group, the apparatus comprising:

[0044] A receiving module, configured to receive a first DHCP request message sent by a first client;

[0045] a processing module configured to forward the second DHCP request message to the CP device if a first DHCP response message sent by the CP device in response to the first DHCP request message is received and a second DHCP request message sent by the first client is received; and discard the second DHCP request message if the first DHCP response message is not received and the second DHCP request message is received.

[0046] In some embodiments, the first UP device stores a temporary entry, where the temporary entry includes identification information and a selected status of the client; and the processing module is further configured to:

[0047] After receiving a first DHCP request message sent by a first client, recording identification information of the first client in a first temporary entry, and setting a selected state included in the first temporary entry to an unselected state;

[0048] When receiving the first DHCP response message sent by the CP device, setting the selected state included in the first temporary entry to the selected state;

[0049] If the selected state included in the first temporary entry is set to the selected state and a second DHCP request message sent by the first client is received, forwarding the second DHCP request message to the CP device;

[0050] If the selected state included in the first temporary entry is set to the unselected state, or the first UP device does not store the first temporary entry, and the first UP device receives the second DHCP request message, 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, the inbound 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 inbound 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 comprises:

[0054] An aging module is configured to delete the first temporary entry when an aging timer corresponding to the first temporary entry times out.

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

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

[0057] In some embodiments, the second DHCP request message includes a custom option, and the custom option carries the first UPID; or

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

[0059] In a fifth aspect, an embodiment of the present application further provides a message processing device, applied to a first client, the device comprising:

[0060] a first sending module, configured 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 receiving the first DHCP response message, so that the first UP device forwards the second DHCP request message to the CP device, and the UP devices not selected by the CP device discard the second DHCP request message.

[0062] 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 receives the first DHCP response message.

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

[0064] In a sixth aspect, an embodiment of the present application further provides a message processing apparatus, applied to a CP device, the apparatus comprising:

[0065] a receiving module, configured to receive a first DHCP request message sent by a plurality of UP devices included in the UP backup group, where the first DHCP request message is sent by a first client;

[0066] a sending module, configured to send a first DHCP response message to a first UP device selected from each of the UP devices, 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; and after receiving the second DHCP request message, the unselected UP devices from each of the UP devices discard the second DHCP request message.

[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 a custom option or a server DUID option. The custom option carries the UPID of the first UP device. The server DUID option includes a UPID option, which carries the UPID of the first UP device.

[0069] The embodiment of the present application further 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 via the communication bus;

[0070] Memory for storing computer programs;

[0071] The processor is configured to implement any one of the methods provided in the first aspect above when executing a program stored in the memory.

[0072] The embodiment of the present application further provides a client, comprising a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0073] Memory for storing computer programs;

[0074] The processor is configured to implement any one of the methods provided in the second aspect when executing a program stored in the memory.

[0075] The embodiment of the present application further 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 via the communication bus;

[0076] Memory for storing computer programs;

[0077] The processor is configured to implement any one of the methods provided in the third aspect when executing a program stored in the memory.

[0078] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements any method provided in the first aspect, or any method provided in the second aspect, or any method provided in the third aspect.

[0079] An embodiment of the present application also provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute any one of the methods provided in the first aspect, or any one of the methods provided in the second aspect, or any one of the methods provided in the third aspect.

[0080] Beneficial effects of the embodiments of the present application:

[0081] In the technical solution provided by the embodiment of the present application, after the UP device receives the first DHCP request message from the client where the IPoE user is located, if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is load-shared to the UP device; if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is not load-shared to the UP device. When the client is load-shared to the UP device, the UP device receives the 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-shared to the UP device, that is, the client is load-shared to other UP devices included in the UP backup group, then the UP device receives the second DHCP request message sent by the client, discards the second DHCP request message, and does not forward the second DHCP request message to the CP device. It can be seen that in the embodiment of the present application, when the client is not load-shared 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, thereby reducing the busyness of the protocol channel between the UP device and the CP device, reducing the load of the CP device, and improving the IPoE online performance during load balancing.

[0082] Of course, it is not necessary to achieve all the advantages described above at the same time when implementing any product or method of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0083] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other embodiments can also be obtained based on these drawings.

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

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

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

[0087] Figure 4 A schematic diagram of a first flow chart of a message processing method provided in an embodiment of the present application;

[0088] Figure 5A second flow chart of the message processing method provided in an embodiment of the present application;

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

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

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

[0092] Figure 7 A third flow chart of the message processing method provided in an embodiment of the present application;

[0093] Figure 8 A fourth flow chart of the message processing method provided in an embodiment of the present application;

[0094] Figure 9 A fifth flow chart of the message processing method provided in an embodiment of the present application;

[0095] Figure 10 This is a first interactive signaling diagram between the client, UP device, and CP device provided in an embodiment of the present application;

[0096] Figure 11 A second interactive signaling diagram between the client, UP device, and CP device provided in an embodiment of the present application;

[0097] Figure 12 A third interactive signaling diagram between the client, UP device, and CP device provided in an embodiment of the present application;

[0098] Figure 13 A schematic diagram of the first structure of the message processing device provided in an embodiment of the present application;

[0099] Figure 14 A second structural diagram of the message processing device provided in an embodiment of the present application;

[0100] Figure 15 A third structural diagram of the message processing device provided in an embodiment of the present application;

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

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

[0103] Figure 18 A schematic diagram of the structure of the CP device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0104] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field based on this application are within the scope of protection of this application.

[0105] To facilitate understanding, the terms appearing in the embodiments of the present application are explained below.

[0106] Virtual Broadband Remote Access Server (vBRAS) Control Plane and User Plane Separation (CUPS) system: The control plane (CP) and user plane (UP) are decoupled, and standard x86 servers are used to replace the physical hardware of traditional Broadband Remote Access Servers (BRAS). The network functions of traditional BRASs are abstracted into a single software entity (vBRAS), freeing network device functions from reliance on dedicated hardware. This enables rapid development and deployment of new services, as well as automated deployment, elastic scaling, fault isolation, and self-healing based on service needs. The vBRAS CUPS system architecture includes functional components such as CP devices, UP devices, service systems, element management systems (EMS), and management and orchestration systems (MANO).

[0107] 1) CP equipment (such as Figure 1 The vBRAS-CP resource pool in the vBRAS CUPS system architecture shown in the figure is responsible for control plane functions such as user authentication, address allocation, and management. The CP device is deployed in a resource pooling model, leveraging the powerful computing capabilities of the vBRAS-CP resource pool. The CP device includes 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: The virtualization layer is responsible for fully virtualizing computing, storage, and network hardware resources and mapping them into virtual resources. In the vBRAS CUPS system architecture, the Cloud Automation System (CAS) can play the NFVI role.

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

[0111] In actual applications, vBRAS-CP is positioned as a user control and management component, mainly including: User 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 to implement user access control.

[0113] User Management Module: This module includes user entry management and user policy management. The user entry management module generates user session entries and sends them to the vBRAS-UP to guide user-side traffic forwarding. The user policy management module manages user authentication, billing, authorization, address allocation, Quality of Service (QoS), and other related policies.

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

[0115] Unified configuration management module: The vBRAS-CP completes the relevant configuration of BRAS services and automatically distributes the relevant configuration to all vBRAS-UPs managed by the vBRAS-CP.

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

[0117] UPMGR module: manages the joining and exiting of vBRAS-UP and 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 in the figure is responsible for forwarding plane functions such as user data traffic forwarding and flow control. The vBRAS-UP can be positioned as a Layer 3 network edge component and user policy enforcement component. Based on the physical form factor of the device, the vBRAS-UP is divided into the following two types:

[0119] vBRAS-pUP (pUP for short): A physical device, such as a network processor (NP), acts as a UP device. The pUP offers high forwarding performance and can handle high-traffic services such as broadband Internet access and Internet Protocol Television (IPTV).

[0120] vBRAS-vUP (vUP for short): Virtualized devices such as x86 serve as UP devices. With its strong computing capabilities, vUP can handle services with high-volume conversations and low-volume traffic, such as the Integrated Terminal Management System (ITMS) and Voice over Internet Protocol (VoIP). Based on their device form factors, vUPs can be categorized as follows:

[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): the Main Processing Unit-Virtual Machine (MPU-VM) and the Line Processing Unit-Virtual Machine (LPU-VM).

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

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

[0125] Control channel: Used to implement functions such as service entry delivery and query, and interface resource information reporting. When a router or vBRAS functions as an Up device, a Control- / User-Plane Separation Protocol (CUSP) channel can be used as the control channel between the CP and Up devices. When a Layer 3 switch functions as an Up device, an OpenFlow channel can be used as the control channel between the CP and Up devices.

[0126] Protocol channel: This is used to implement protocol message exchange for protocols 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 and UP devices can be a Generic Protocol Extension (GPE) type Virtual Extensible Local Area Network (VXLAN) tunnel.

[0127] 3) Business system: It is composed of various business type servers such as Authentication Authorization Accounting (AAA) server, DHCP server, portal server, and other servers, providing users with business functions such as authentication, authorization, billing, address allocation, and security policy control.

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

[0129] 5) MANO: Responsible for the lifecycle management and orchestration of NFVI software and hardware 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 unified management, monitoring, and optimization of physical hardware virtualization resources. In the vBRAS CUPS system architecture, the Cloud Operating System (CloudOS) can serve as the VIM.

[0131] Virtualized Network Function Manager (VNFM): Responsible for VNF lifecycle management. In the vBRAS CUPS system architecture, the VNF Manager can serve as the VNFM.

[0132] Network Function Virtualization Orchestrator (NFVO): Responsible for orchestrating and managing infrastructure resources and upper-layer software resources to deliver network services. In the vBRAS CUPS system architecture, VNFM-vBRAS can serve as the NFVO.

[0133] UP backup: In the control-forwarding separation scenario, the CP device determines the primary and backup status of the UP device or its interface based on the UP device's interface status and the CUSP channel status. This ensures that when the primary UP device or primary interface fails, user services can be quickly switched from the primary UP device or primary interface to the backup UP device or backup interface. When the primary UP device or primary interface recovers from the failure, user services can be switched back from the backup UP device or backup interface to the primary UP device or primary interface, ensuring uninterrupted user services.

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

[0135] UP backup group: Multiple UP devices are added to 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 devices.

[0136] UP backup policy template: Create UP backup policy templates with different UP backup modes based on different service requirements. Specify the primary and backup interfaces in the UP backup policy templates. Different interfaces on an UP device are placed in different UP backup policy templates.

[0137] Primary interface: The interface that carries user services. The UP device where the primary interface is located is the master UP device for the corresponding UP backup policy template.

[0138] Backup interface: An interface that backs up the primary interface. The backup interface is located on the same device as the backup device in the corresponding UP backup policy template. If the primary interface fails, the backup interface takes over and forwards 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 an extended period.

[0139] Virtual Media Access Control (MAC) address: The primary and backup interfaces included in an UP backup policy template use a unique virtual MAC address to ensure that the MAC addresses of the interfaces do not change after the primary and backup interfaces switch. The UP device uses the virtual MAC address to respond to user online requests.

[0140] UP backup modes include 1:1 hot standby mode, N:1 warm standby mode, and 1:N warm standby load sharing mode. For different UP backup modes, the virtual MAC address is configured as follows:

[0141] In 1:1 hot standby mode, the primary interface and the backup interface correspond one to one, and each pair of primary and backup interfaces corresponds to a unique virtual MAC address.

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

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

[0144] like Figure 2 In the vBRAS CUPS system shown, a CP device is connected to multiple UP devices through a switching device, and the UP devices can access the network through the switching device. Figure 2 In this example, 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, while 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 (such as PC1 and PC2).

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

[0146] Load sharing mode: The interfaces of multiple UP devices included in the UP backup group are all used as primary interfaces to perform load balancing. Figure 3 In the vBRAS CUPS network architecture shown, the CP device is connected to UP 1024, UP 1025, and UP 1026 through switches (SWs). Interface Ge1024 / 1 / 0 / 1 on UP 1024, interface Ge1025 / 1 / 0 / 1 on UP 1025, and interface Ge1026 / 1 / 0 / 1 on UP 1026 are added to UP backup policy template 1. In the load balancing mode based on UP backup policy template 1, Ge1024 / 1 / 0 / 1, Ge1025 / 1 / 0 / 1, and Ge1026 / 1 / 0 / 1 all serve as master interfaces, and load balancing is performed among these three master interfaces at the interface level.

[0147] N:1 warm standby load sharing mode: Among the N+1 UP device interfaces included in the UP backup group, N UP device interfaces serve as primary interfaces, and 1 UP device interface serves as a backup interface, and load sharing is performed between the N primary interfaces. Figure 3 In the network architecture shown, interface Ge1024 / 1 / 0 / 1 on UP 1024, interface Ge1025 / 1 / 0 / 1 on UP 1025, and interface Ge1026 / 1 / 0 / 1 on UP 1026 are added to UP backup policy template 1. In 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 the primary interfaces, and Ge1026 / 1 / 0 / 1 serves as the backup interface. Traffic from user devices 1 to 4 is load balanced between these two primary interfaces, at the interface level.

[0148] 1: N warm standby load sharing mode: The interfaces of the N+1 UP devices included in the UP backup group are all used as primary interfaces, and the load is shared between the virtual MAC addresses corresponding to the N*(N+1) primary and secondary backup relationships formed between the N+1 primary interfaces. Figure 3 In the network architecture shown, in 1:N warm standby load balancing mode based on UP backup policy template 1, Ge1024 / 1 / 0 / 1, Ge1025 / 1 / 0 / 1, and Ge1026 / 1 / 0 / 1 form 2*3=6 active / standby relationships. These six active / standby relationships correspond to six virtual MAC addresses. Traffic from user devices 1 to 4 is load balanced among these six virtual MAC addresses. The load sharing granularity is the virtual MAC address.

[0149] IPoE authentication authenticates and charges users based on their physical location, eliminating the need for users to enter usernames and passwords. In IPoE applications, the client and BRAS are connected via a Layer 2 switch.

[0150] When an IPoE user (i.e., client) dynamically obtains an IP address through 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 load balancing scenario with vBRAS forwarding and control separation, when a client dynamically obtains an IP address through DHCP, multiple UP devices performing load balancing will all receive the DHCP request message sent by the client and forward the DHCP request message to the CP device. The CP device will determine the UP device (such as the first UP device) based on the load balancing decision, and then discard the DHCP request message forwarded by other UP devices. Based on the DHCP request message forwarded by the first UP device, it will construct a DHCP response message. For example, the DHCP server will assign an IP address to the client and construct a DHCP response message and send it to the CP device. Alternatively, the address management module on the CP device will assign an IP address to the client and construct a DHCP response message.

[0152] For example, UP1024, UP1025, and UP1026 are added to the same UP backup group, and load balancing is performed between interface A on UP1024, interface B on UP1025, and interface C on UP1026. In a network based on the Dynamic Host Configuration Protocol over Internet Protocol version 4 (DHCPv4), IPoE users are IPoE4 users. In a load balancing scenario with vBRAS forwarding and control separation, the process for IPoE4 users to dynamically obtain IP addresses through DHCP is as follows:

[0153] Step 1: The client of the IPoE4 user broadcasts a Discover message.

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

[0155] In step 3, the CP device selects a UP device (such as interface A of UP1024) based on load balancing, forwards the Discover message from UP1024 to the DHCPv4 server, and discards the Discover messages from UP1025 and UP1026.

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

[0157] The DHCPv4 server can be integrated into the CP device. In this case, the DHCPv4 server can be implemented by the address management module. The CP device is the DHCPv4 server. The DHCPv4 server can also be an independent physical device. In this case, the CP device is the DHCPv4 relay.

[0158] Step 5: The CP device forwards the Offer message to the UP1024 device, which then 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 all receive the Request message and forward it to the CP device.

[0161] In step 8, the CP device queries the load balancing result in step 3, forwards the Request message from UP1024 to the DHCPv4 server, and discards the Request messages from UP1025 and UP1026.

[0162] Step 9: The DHCPv4 server constructs an acknowledgment (Ack) message and sends it 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 goes online successfully.

[0165] For example, UP1024, UP1025, and UP1026 are added to the same UP backup group, and load balancing is performed between interface A on UP1024, interface B on UP1025, and interface C on UP1026. In a network based on the Dynamic Host Configuration Protocol over Internet Protocol version 6 (DHCPv6), IPoE users are IPoE6 users. In a load balancing scenario with vBRAS forwarding and control separation, the process for IPoE6 users to dynamically obtain IP addresses through DHCP is as follows:

[0166] Step 1: The client of the IPoE6 user sends a multicast solicitation message.

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

[0168] In step 3, the CP device selects a UP device (such as interface A of UP1024) based on load balancing, forwards the Solicit message from UP1024 to the DHCPv6 server, and discards the Solicit messages from UP1025 and UP1026.

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

[0170] The DHCPv6 server can be integrated into the CP device. In this case, the DHCPv6 server can be implemented by the above-mentioned address management module, and the CP device is the DHCPv6 server. The DHCPv6 server can also be an independent physical device. In this case, the CP device is the DHCPv6 relay.

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

[0172] Step 6: The client of the IPoE6 user sends a multicast request message.

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

[0174] In step 8, the CP device queries the load balancing result in step 3, forwards the Request message from UP1024 to the DHCPv6 server, and discards the Request messages from UP1025 and UP1026.

[0175] Step 9: The DHCPv6 server constructs a reply message and sends it 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 goes online successfully.

[0178] In load balancing scenarios with vBRAS forwarding and control separation, UP backup is a key technology for improving system reliability. In UP backup, load balancing between UP devices improves UP load balancing and increases device utilization.

[0179] However, when an IPoE user goes online, a copy of 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 problems:

[0180] (1) Redundant DHCP request messages are sent from the UP device to the CP device through the protocol channel between the UP device and the CP device, affecting 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 balancing results and discard redundant DHCP request messages, which affects the performance of the CP device.

[0183] To solve the above problems, the present invention provides a method for processing a message. Figure 4 As shown, the method is applied to the first UP device included in the UP backup group, and includes the following steps:

[0184] Step S401: receiving a first DHCP request message sent by a first client;

[0185] Step S402: If a first DHCP response message sent by the CP device in response to the first DHCP request message is received, and a second DHCP request message sent by the first client is received, 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, the second DHCP request message is discarded.

[0187] In the technical solution provided by the embodiment of the present application, after the UP device receives the first DHCP request message from the client where the IPoE user is located, if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is load-shared to the UP device; if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is not load-shared to the UP device. When the client is load-shared to the UP device, the UP device receives the 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-shared to the UP device, that is, the client is load-shared to other UP devices included in the UP backup group, then the UP device receives the second DHCP request message sent by the client, discards the second DHCP request message, and does not forward the second DHCP request message to the CP device. It can be seen that in the embodiment of the present application, when the client is not load-shared 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, thereby reducing the busyness of the protocol channel between the UP device and the CP device, reducing the load of the CP device, and improving the IPoE online performance during load balancing.

[0188] In the embodiment of the present 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 load with each other. The first UP device may be any UP device included in the UP backup group.

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

[0190] When an IPoE user goes online, a first client where the IPoE user is located broadcasts or multicasts a first DHCP request message, and then a first UP device receives the first DHCP request message.

[0191] After receiving the first DHCP request message, the first UP device may process the second DHCP request message received from the first client according to the subsequently received DHCP response message.

[0192] Specifically, the CP device selects the first UP device according to load balancing, that is, it shares the load of the first client to the first UP device, and then sends a first DHCP response message to the first UP device based on the first DHCP request message; subsequently, if the first UP device receives a second DHCP request message sent by the first client, the first UP device executes step S402 to forward the second DHCP request message to the CP device.

[0193] The CP device selects other UP devices (such as the second UP device) according to load balancing, that is, it shares the load of the first client to the second UP device, and then sends a first DHCP response message to the second UP device based on the first DHCP request message. Subsequently, if the first UP device receives the second DHCP request message sent by the first client, step S403 is executed to discard the second DHCP request message. The second DHCP request message is a 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-balanced to one UP device, and then only one UP device will forward the second DHCP request message to the CP device, reducing redundant messages between the UP device and the CP device, thereby reducing the busyness 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 balancing.

[0195] In the embodiment of the present application, the UP device may adopt the following two methods to determine whether the first client is load-shared to the first UP device, that is, to determine how to process the second DHCP request message.

[0196] Method 1: Stateful solution.

[0197] In this embodiment of the present application, the first UP device stores a temporary entry, which includes the client's identification information and a selected (bSelect) status. The bSelect status can be either a selected state or an unselected state. The selected state indicates that the first UP device received the first DHCP response message, i.e., the client is load-balanced to the UP device; the unselected state indicates that the first UP device did not receive the first DHCP response message, i.e., the client is not load-balanced to the UP device.

[0198] In the embodiments of the present application, the identification information of the client may vary depending on the networking type. For example, in a DHCPv4 network, the identification information of the client may include the MAC address of the client and the inbound interface on the UP device (i.e., the interface of the UP device when load balancing is performed, that is, the interface through which the UP device receives the DHCP request message); in a DHCPv6 network, the identification information of the client may include the DHCPv6 unique identifier (DHCPv6 Unique Identifier, DUID) of the client and the inbound interface on the UP device.

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

[0200] Before receiving the first DHCP response message sent by the CP device in response to the first DHCP request message, the first UP device maintains the bSelect state included in the first temporary entry as the unselected state. Upon receiving the first DHCP response message sent by the CP device, the first UP device sets the bSelect state included in the first temporary entry to the selected state (e.g., the True state).

[0201] Subsequently, when the first UP device receives the second DHCP request message sent by the first client, the first client identification information can be obtained according to the second DHCP request message, and the obtained identification information of the first client can be matched with each temporary table entry stored by the first UP device to obtain a matching temporary table entry, that is, the first temporary table entry mentioned above; if the bSelect state included in the first temporary table entry is set to the selected state, it indicates 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 indicates 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 may also indicate that the first UP device has not received the first DHCP response message.

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

[0203] Step S501: receiving a first DHCP request message sent by a first client;

[0204] In the embodiment of the present application, the first DHCP request message can be the first DHCP request message sent by the first client in the process of dynamically obtaining an IP address, such as a Discover message in a DHCPv4 network or a Solicit message in a DHCPv6 network. The first DHCP request message can also be any DHCP request message sent before the second DHCP request message, without limitation.

[0205] When an IPoE user goes online, a first client where the IPoE user is located broadcasts or multicasts a first DHCP request message, and then a first UP device receives the first DHCP request message.

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

[0207] After receiving the first DHCP request message, the first UP device determines the identification information of the first client according to 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 the unselected state (such as the 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 inbound 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 inbound 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, i.e., 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 inbound 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 inbound interface of the first DHCP request message (i.e., the first interface), and records the correspondence between the first DUID and the first interface, i.e., records the first DUID and the first interface in the first temporary table entry.

[0210] The first UP device may forward the first DHCP request message to the CP device while recording the identification information of the first client. After receiving the first DHCP request message, the CP device selects a UP device in the UP backup group according to load balancing. The CP device may construct a first DHCP response message corresponding to the first DHCP request message on its own, or construct a first DHCP response message corresponding to the first DHCP request message through a DHCP server, and then 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 a first temporary entry times out, it indicates that the identification information of the first client included in the first temporary entry is invalid. The first UP device deletes the first temporary entry, that is, deletes the identification information of the first client. This can effectively conserve storage resources on 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 receiving the first DHCP response message sent by the CP device, the selected state included in the first temporary 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 and the first client is load-balanced to the first UP device. The first UP device then sets the bSelect state included in the first temporary entry to the selected state (e.g., the True state) and 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-balanced to other UP devices. The bSelect state included in the first temporary entry is not processed, that is, the bSelect state included in the first temporary entry remains in the False state.

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

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

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

[0217] With the technical solution provided by the embodiments of the present application, after the multiple UP devices in the UP backup group send a DHCP request message to the CP device, each UP device determines whether it should process the client's traffic, that is, whether the client is load-shared to the device. Consequently, only the first client load-shared to the UP device subsequently sends a DHCP request message to the CP device, reducing redundant messages between the UP and CP devices and improving the automation, efficiency, and flexibility of message processing.

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

[0219] The following describes the stateful solution provided by the embodiments of the present application, using DHCPv4 and DHCPv6 networking as examples. The UP backup group includes UP device 1024, UP device 1025, and UP device 1026. Load balancing 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 each receive the Discover message, construct a temporary entry (e.g., a MAC-Port entry), set the bSelect status of the temporary entry to False, and start the corresponding aging timer. For example, the aging timer has a duration of 10 seconds. Specifically, UP device 1024 constructs temporary entry 1, which includes MAC1 and interface A. The bSelect status of temporary entry 1 is set to False. UP device 1025 constructs temporary entry 2, which includes MAC1 and interface B. The bSelect status of temporary entry 2 is set to False. UP device 1026 constructs temporary entry 3, which includes MAC1 and interface C. The bSelect status of temporary entry 3 is set to False.

[0222] UP devices 1024, 1025, and 1026 each send a Discover message to the CP device. The CP device determines that client 1 is load-balanced to a device (such as UP device 1024). In this way, the subsequent CP device receives the Offer message and sends the Offer message to UP device 1024.

[0223] After receiving the Offer message, the UP device 1024 sets the bSelect state included in the temporary entry 1 to the True state, and sends the Offer message to the client 1. The bSelect states included in the temporary entries 2 and 3 remain in the False state.

[0224] Client 1 broadcasts a Request message. UP devices 1024, 1025, and 1026 each receive the Request message. UP device 1024 determines from the Request message that Client 1's MAC address is MAC1 and that the incoming interface of the Request message is Interface A. Furthermore, UP device 1024 determines that temporary entry 1 includes MAC1 and Interface A, and that the bSelect state of temporary entry 1 is True. UP device 1024 then sends the Request message to the CP device for processing.

[0225] Based on the Request message, UP device 1025 determines that client 1's MAC address is MAC1 and that the incoming interface of the Request message is interface B. Furthermore, it determines that temporary entry 2 includes MAC1 and interface B, and that the bSelect status 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 client 1's MAC address is MAC1 and that the incoming interface of the Request message is interface C. Furthermore, it determines that temporary entry 3 includes MAC1 and interface C, and that the bSelect status of temporary entry 3 is False. UP device 1026 then discards the Request message.

[0226] In an embodiment of the present application, if the UP device does not record the temporary table entry including MAC1 and the input interface of the Request message, such as the UP device does not receive the first DHCP request message, or the temporary table entry is aged and deleted, it may also indicate that the first UP device has not received the first DHCP response message, the client is not load-shared to the UP device, and the UP device discards the Request message.

[0227] (2)DHCPv6 networking.

[0228] In a DHCPv6 network, client 1 multicasts a Solicit message. UP devices 1024, 1025, and 1026 each receive the Solicit message, construct a temporary entry (e.g., a DUID entry), set the bSelect status of the temporary entry to False, and start the corresponding aging timer. For example, the aging timer has a duration of 10 seconds. Specifically, UP device 1024 constructs temporary entry 1, which includes DUID 1 and interface A. The bSelect status of temporary entry 1 is set to False. UP device 1025 constructs temporary entry 2, which includes DUID 1 and interface B. The bSelect status of temporary entry 2 is set to False. UP device 1026 constructs temporary entry 3, which includes DUID 1 and interface C. The bSelect status of temporary entry 3 is set 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-balanced to a device (such as UP device 1024). In this way, the CP device subsequently receives the Advertise message and sends the Advertise message to UP device 1024.

[0230] After receiving the Advertise message, the UP device 1024 sets the bSelect state included in the temporary entry 1 to True, and sends the Advertise message to the client 1. The bSelect states included in the temporary entries 2 and 3 remain False.

[0231] Client 1 multicasts a Request message. UP devices 1024, 1025, and 1026 receive the Request message. UP device 1024 determines from the Request message that the DUID of client 1 is DUID1 and that the incoming interface of the Request message is interface A. Furthermore, UP device 1024 determines that temporary entry 1 includes DUID1 and interface A, and that the bSelect status of temporary entry 1 is True. UP device 1024 then sends the Request message to the CP device for processing.

[0232] Based on the Request message, UP device 1025 determines that the DUID of client 1 is DUID1, and that the incoming interface of the Request message is interface B. Furthermore, it determines that temporary entry 2 includes DUID1 and interface B, and that the bSelect status included in temporary entry 2 is False. UP device 1025 then discards the Request message. Based on the Request message, UP device 1026 determines that the DUID of client 1 is DUID1, and that the incoming interface of the Request message is interface C. Furthermore, it determines that temporary entry 3 includes DUID1 and interface C, and that the bSelect status included in temporary entry 3 is False. UP device 1026 then discards the Request message.

[0233] In an embodiment of the present application, if the UP device does not record the temporary table entry including DUID1 and the input interface of the Request message, such as the UP device does not receive the first DHCP request message, or the temporary table entry is aged and deleted, it may also indicate that the first UP device has not received the first DHCP response message, the client is not load-shared to the UP device, and the UP device discards the Request message.

[0234] In the technical solution provided by the embodiment of the present application, the UP device uses a temporary table entry to ensure that only the UP device selected for load sharing sends a DHCP request message to the CP device, without the need for client cooperation, thereby reducing the impact on the client.

[0235] Method 2: stateless solution.

[0236] In an embodiment of the present application, 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 is load-shared to the first UP device, and the first UP device has received the first DHCP request message and 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 is not load-shared to the first UP device, the first UP device has received the first DHCP request message but has not received the first DHCP response message, or the first UP device has not received the first DHCP request message and the first DHCP response message.

[0237] In this embodiment of the present application, a UPID can uniquely identify a UP device. After receiving the second DHCP request message, the first UP device can obtain the first UPID included in the second DHCP request message and 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 indicates that the first client is load-shared to the first UP device, and the second DHCP request message is forwarded to the CP device; if the first UPID is different from the UPID of the first UP device, it indicates that the first client is not load-shared to the first UP device, and the second DHCP request message is discarded.

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

[0239] In mode a, the second DHCP request message includes a custom option, and the custom option carries the first UPID.

[0240] In DHCPv4 networking, the custom option can be option 254. The structure of option 254 can be found in Figure 6a shown. Figure 6a The numbers above represent bytes. Figure 6a In the option 254 shown, the length of the value field is 2 bytes, which is not a limitation. The value field carries the UPID.

[0241] In DHCPv6 networking, the custom option can be option 65534. The structure of option 65534 can be found in Figure 6b shown. Figure 6b The numbers above represent bytes. Figure 6b In option 65534 shown, the length of the value field is 2 bytes, which is not a limitation. The value field carries the UPID.

[0242] In this embodiment of the present application, the client needs to cooperate with the processing and add a custom option in the second DHCP request message. Using this custom option, only the UP device to which the client is load-shared will report the second DHCP request message to the CP device, and each UP device does not need to maintain a temporary table entry, making the implementation process relatively simple.

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

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

[0245] For example, option 2 may include two sub-options, 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 a UPID option. In this case, the structures of the two sub-options are shown in Table 1.

[0246] Table 1

[0247] Field meaning length Value 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 the server DUID variable variable sub option 2 type UPID 2 2 Sub option 2 length Length of UPID 2 2 sub option 2 value The value of UPID 2 variable

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

[0249] In existing standards, the client needs to add the server DUID option to the second DHCP request message when sending it. In the embodiments of the present application, the client does not need to cooperate with the processing. It only needs to add the server DUID option to the second DHCP request message in accordance with the existing standards. This can ensure that only the UP device to which the client is load-shared reports the first DHCP request message to the CP device. Each UP device does not need to maintain a temporary table entry, and the implementation process is relatively simple.

[0250] Corresponding to the above-mentioned message processing method applied to the first UP device included in the UP backup group, the embodiment of the present application 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 receiving the first DHCP response message, 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.

[0253] In the embodiment of the present application, the specific operations performed by each UP device included in the UP backup group can be found in Figure 4 The description of some first UP devices is not repeated here.

[0254] In the technical solution provided by the embodiment of the present application, after the UP device receives the first DHCP request message from the client where the IPoE user is located, if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is load-shared to the UP device; if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is not load-shared to the UP device. When the client is load-shared to the UP device, the UP device receives the 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-shared to the UP device, that is, the client is load-shared to other UP devices included in the UP backup group, then the UP device receives the second DHCP request message sent by the client, discards the second DHCP request message, and does not forward the second DHCP request message to the CP device. It can be seen that in the embodiment of the present application, when the client is not load-shared 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, thereby reducing the busyness of the protocol channel between the UP device and the CP device, reducing the load of the CP device, and improving the IPoE online performance during load balancing.

[0255] In this embodiment of the present application, when the UP device uses a stateful solution, the first client does not need to cooperate in the processing. When the UP device uses a stateless solution, the second DHCP request message may include the first UPID. The UP device corresponding to the first UPID is the UP device that received the first DHCP response message. In other words, if the first UPID is the same as the UPID of the UP device, it indicates that the first client is load-shared 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 indicates that the first client is not load-shared 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, which is applied to a first client and 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 an embodiment of the present application, the first client broadcasts or multicasts a first DHCP request message. The multiple UP devices included in the UP backup group can all receive the first DHCP request message. Afterwards, the multiple UP devices will all send 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) in the UP backup group based on load balancing. It can construct a first DHCP response message corresponding to the first DHCP request message by itself, or construct a first DHCP response message corresponding to the 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 can include a target option, which is a custom option or a server DUID option. The custom option carries the first UPID. The server DUID option includes a UPID option, and the UPID option carries the first UPID. The meaning of the custom option or the server DUID option can be found in the relevant description above and will not be repeated here.

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

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

[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, and can directly encapsulate the target option in the second DHCP request message, and then broadcast or multicast the second DHCP request message.

[0262] In the embodiment of the present application, by adding a target option in the second DHCP request message, only the UP device to which the client is load-shared reports the second DHCP request message to the CP device. Each UP device does not need to maintain a temporary table entry, and the implementation process is relatively simple.

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

[0264] Step S901: receiving a first DHCP request message sent by each UP device included in the UP backup group, where the first DHCP request message is sent by a first client;

[0265] Step S902: Send a first DHCP response message to a 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. After receiving the second DHCP request message, the unselected UP devices in each UP device discard the second DHCP request message.

[0266] In the embodiment of the present application, the specific operations performed by each UP device included in the UP backup group can be found in Figure 4 The description of some first UP devices is not repeated here.

[0267] In the technical solution provided by the embodiment of the present application, after the UP device receives the first DHCP request message from the client where the IPoE user is located, if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is load-shared to the UP device; if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is not load-shared to the UP device. When the client is load-shared to the UP device, the UP device receives the 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-shared to the UP device, that is, the client is load-shared to other UP devices included in the UP backup group, then the UP device receives the second DHCP request message sent by the client, discards the second DHCP request message, and does not forward the second DHCP request message to the CP device. It can be seen that in the embodiment of the present application, when the client is not load-shared 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, thereby reducing the busyness of the protocol channel between the UP device and the CP device, reducing the load of the CP device, and improving the IPoE online performance during load balancing.

[0268] In the embodiment of the present application, when the UP device adopts a stateful solution, the CP device does not need to cooperate in processing. When the UP device adopts a stateless solution, the second DHCP request message may include the 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, the first client is load-shared to the UP device and the UP device is selected by the CP device. If the first UPID is different from the UPID of the UP device, the first client is not load-shared to the UP device and the UP device is not selected by the CP device.

[0269] For the stateless solution, 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. The server DUID option includes a UPID option, which carries the UPID of the first UP device. The meaning of the custom option or server DUID option is described above and is not repeated here.

[0270] In the embodiment of the present application, the first client broadcasts or multicasts the first DHCP request message. The multiple UP devices included in the UP backup group can all receive the first DHCP request message. Afterwards, the multiple UP devices all send the received first DHCP request message to the CP device.

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

[0272] In mode 1, the CP device constructs a first DHCP response message corresponding to the first DHCP request message, where the first DHCP response message includes a target option; and sends the first DHCP response message to the first client through the first UP device.

[0273] In 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 via the first UP device. For example, the CP device adds a target option to the second DHCP response message to obtain the first DHCP response message. The CP device then sends the first DHCP response message to the first client via the first UP device.

[0274] The first client's operation after receiving the first DHCP response message can be seen in Figure 8 The description of the above-mentioned stateless solution will not be repeated here.

[0275] In the embodiment of the present application, the CP device adds a target option in the first DHCP response message, so that only the UP device to which the client is load-shared reports the second DHCP request message to the CP device. Each UP device does not need to maintain a temporary table entry, and the implementation process is relatively simple.

[0276] The following combination Figures 10 to 12 The interactive signaling diagram between the client, UP device and CP device shown in the figure provides a detailed description of the message processing method provided in the embodiment of the present application. Figures 10 to 12 In the UP backup group, load balancing is performed between multiple UP devices.

[0277] Figure 10 In the signaling diagram of the interaction between the client, UP device, and CP device, the UP device uses a stateful solution. DHCPv4 networking is used as an example.

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

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

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

[0281] Step S1004 : UP device 1 sets the bSelect state included in the temporary 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 status included in the temporary entry; other UP devices discard the Request message according to the temporary entry corresponding to the client and the bSelect status included in the temporary entry.

[0284] Step S1007 : The CP device sends an Ack message to the UP device 1 according to the Request message.

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

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

[0287] In a DHCPv6 network, the interactive signaling between the client, UP device, and CP device is the same as above. Figure 10 Similar, except that: 1) the temporary table entry includes different identification information. In DHCPv6 networking, the identification information is the client DUID and input interface, and in DHCPv4 networking, the identification information is the MAC address and input 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 of the interaction between the client, UP device, and CP device, the UP device uses a stateless solution. DHCPv4 networking is used as an example.

[0289] Step S1101: The client broadcasts a Discover message (such as the first DHCP request message mentioned 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 sharing, and sends an Offer message (such as the first DHCP response message) to the selected UP device according to the Discover message. The Offer message includes option 254, which carries UPID1 of UP device 1.

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

[0293] Step S1105 : The client broadcasts a Request message (such as the second DHCP request message mentioned above). The Request message includes option 254 .

[0294] The client encapsulates option 254 included in the Offer message into 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 UPIDs of other UP devices and discard the Request message.

[0296] Step S1107 : The CP device sends an Ack message to the UP device 1 according to the Request message.

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

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

[0299] Figure 12 In the signaling diagram of the interaction between the client, UP device, and CP device, the UP device uses a stateless solution. DHCPv6 networking is used as an example.

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

[0301] 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 load sharing, and sends an Advertise message (such as the first DHCP response message) 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, which carries UPID1 of UP device 1.

[0304] In the embodiment of the present application, Option 65534 and Option 2 can be encapsulated in an Advertise message after the CP device constructs and obtains the Advertise message. Option 65534 and Option 2 can also be encapsulated in an Advertise message after the DHCP server constructs and obtains the Advertise message and sends it to the CP device.

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

[0306] Step S1205: The client sends a Request message (such as the second DHCP request message mentioned above). The Request message includes option 65534 or option 2.

[0307] The client encapsulates option 65534 or option 2 included in the Advertise message into 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 the UPID1 in option 65534 or option 2 is the same as the UPID1 of UP device 1 and forwards the Request message to the CP device; the other UP devices confirm that the UPID1 in option 65534 or option 2 is different from the UPIDs of other UP devices and discard the Request message.

[0309] Step S1207: The CP device sends a Reply message to UP device 1 according to the Request message.

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

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

[0312] The technical solution provided in the embodiment of the present application reduces the number of messages exchanged between the UP device and the CP device when IPoE4 users and IPoE6 users go online when the UP device performs load balancing in a forwarding and control separation scenario, thereby improving the forwarding performance of the UP device and improving the user online performance.

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

[0314] The receiving module 1301 is configured to receive a first DHCP request message sent by a first client;

[0315] Processing module 1302 is configured to forward the second DHCP request message to the CP device if a first DHCP response message sent by the CP device in response to the first DHCP request message is received and a second DHCP request message sent by the first client is received; and discard the second DHCP request message if the first DHCP response message is not received and the second DHCP request message is received.

[0316] In some embodiments, the first UP device stores a temporary table entry, where the temporary table entry includes identification information and a selected state of the client;

[0317] The processing module 1302 may further be configured to: after receiving a first DHCP request message sent by the first client, record identification information of the first client in a first temporary entry, and set a selected state included in the first temporary entry to an unselected state; upon 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 the 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 the unselected state, or the first UP device does not store the first temporary entry and the second DHCP request message is received, discard the second DHCP request message.

[0318] In some embodiments, the first DHCP request message includes the first MAC address of the first client, the inbound 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 inbound 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.

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

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

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

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

[0324] In some embodiments, the second DHCP request message includes a custom option, and the custom option carries the first UPID; or,

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

[0326] In the technical solution provided by the embodiment of the present application, after the UP device receives the first DHCP request message from the client where the IPoE user is located, if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is load-shared to the UP device; if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is not load-shared to the UP device. When the client is load-shared to the UP device, the UP device receives the 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-shared to the UP device, that is, the client is load-shared to other UP devices included in the UP backup group, then the UP device receives the second DHCP request message sent by the client, discards the second DHCP request message, and does not forward the second DHCP request message to the CP device. It can be seen that in the embodiment of the present application, when the client is not load-shared 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, thereby reducing the busyness of the protocol channel between the UP device and the CP device, reducing the load of the CP device, and improving the IPoE online performance during load balancing.

[0327] Corresponding to the above-mentioned message processing method, the embodiment of the present application also provides a message processing device, such as Figure 14 As shown, applied to a first client, the device includes:

[0328] A first sending module 1401 is configured 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;

[0329] The second sending module 1402 is configured to, upon receiving the first DHCP response message, send a second DHCP request message to each UP device included in the UP backup group, so that the first UP device forwards the second DHCP request message to the CP device, and the UP devices not selected by the CP device discard the second DHCP request message.

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

[0331] In some embodiments, the second sending module 1402 may be specifically configured to:

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

[0333] A second DHCP request message is sent to each UP device included in the UP backup group, where the second DHCP request message includes a target option.

[0334] In the technical solution provided by the embodiment of the present application, after the UP device receives the first DHCP request message from the client where the IPoE user is located, if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is load-shared to the UP device; if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is not load-shared to the UP device. When the client is load-shared to the UP device, the UP device receives the 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-shared to the UP device, that is, the client is load-shared to other UP devices included in the UP backup group, then the UP device receives the second DHCP request message sent by the client, discards the second DHCP request message, and does not forward the second DHCP request message to the CP device. It can be seen that in the embodiment of the present application, when the client is not load-shared 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, thereby reducing the busyness of the protocol channel between the UP device and the CP device, reducing the load of the CP device, and improving the IPoE online performance during load balancing.

[0335] Corresponding to the above-mentioned message processing method, the embodiment of the present application also provides a message processing device, such as Figure 15 As shown, it is applied to CP equipment, and the device includes:

[0336] A receiving module 1501 is configured to receive a first DHCP request message sent by each UP device included in the UP backup group, where the first DHCP request message is sent by a first client;

[0337] The sending module 1502 is configured to send a first DHCP response message to a 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. After receiving the second DHCP request message, the unselected UP devices in each UP device discard the second DHCP request message.

[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 a custom option or a server DUID option. The custom option carries the UPID of the first UP device. The server DUID option includes a UPID option. The UPID option carries the UPID of the first UP device.

[0340] In the technical solution provided by the embodiment of the present application, after the UP device receives the first DHCP request message from the client where the IPoE user is located, if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is load-shared to the UP device; if it subsequently receives the first DHCP response message sent by the CP device based on the first DHCP request message, it indicates that the client is not load-shared to the UP device. When the client is load-shared to the UP device, the UP device receives the 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-shared to the UP device, that is, the client is load-shared to other UP devices included in the UP backup group, then the UP device receives the second DHCP request message sent by the client, discards the second DHCP request message, and does not forward the second DHCP request message to the CP device. It can be seen that in the embodiment of the present application, when the client is not load-shared 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, thereby reducing the busyness of the protocol channel between the UP device and the CP device, reducing the load of the CP device, and improving the IPoE online performance during load balancing.

[0341] The present 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 via the communication bus 1604 .

[0342] Memory 1603, used for storing computer programs;

[0343] The processor 1601 is configured to implement any of the above-mentioned message processing methods applied to the first UP device included in the UP backup group when executing the program stored in the memory 1603 .

[0344] The present application embodiment 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 via the communication bus 1704 .

[0345] Memory 1703, used for storing computer programs;

[0346] The processor 1701 is configured to implement any of the above-mentioned message processing methods applied to the first client when executing the program stored in the memory 1703 .

[0347] The present 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 via the communication bus 1804 .

[0348] Memory 1803, used for storing computer programs;

[0349] The processor 1801 is configured to implement any of the above-mentioned message processing methods applied to the CP device when executing the program stored in the memory 1803 .

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

[0351] The communication interface is used for communication between the 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. Alternatively, the memory may be at least one storage device located away from the 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, and discrete hardware components.

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

[0355] In another embodiment provided in the present application, a computer program product comprising instructions is also provided. When the computer is executed on a computer, the computer executes any of the above-mentioned message processing methods applied to the first UP device included in the UP backup group, or executes any of the above-mentioned message processing methods applied to the first client, or executes any of the above-mentioned message processing methods applied to the CP device.

[0356] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part 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, the process or function described in the embodiment of the present application is generated in whole or in part. 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 computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. 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 includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

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

[0358] Each embodiment in this specification is described in a related manner. Similar portions between the various embodiments can be referenced to each other. Each embodiment focuses on the differences between the other embodiments. In particular, the apparatus, UP device, client, CP device, storage medium, and program product embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For related portions, refer to the descriptions of the method embodiments.

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

Claims

1. A message processing method, characterized in that: Applied to a first UP device included in a UP backup group, the method includes: Receive a first DHCP request message sent by a first client; If a first DHCP response message is received from the CP device in response to the first DHCP request message, and a second DHCP request message is received from the first client, 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, the second DHCP request message is discarded.

2. The method according to claim 1, characterized in that The first UP device stores a temporary entry, where the temporary entry includes identification information and a selected state of the client; and the method further includes: After receiving a first DHCP request message sent by a first client, recording identification information of the first client in a first temporary entry, and setting a selected state included in the first temporary entry to an unselected state; When receiving the first DHCP response message sent by the CP device, setting the selected state included in the first temporary entry to the selected state; The method of forwarding the second DHCP request message to the CP device if a first DHCP response message is received from the CP device in response to the first DHCP request message and a second DHCP request message is received from the first client includes: If the selected state included in the first temporary entry is set to the selected state 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 includes: If the selected state included in the first temporary entry is set to the unselected state, or the first UP device does not store the first temporary entry, and the first UP device receives the second DHCP request message, the second DHCP request message is discarded.

3. The method according to claim 2, characterized in that The first DHCP request message includes the first MAC address of the first client, the inbound 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 inbound 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.

4. The method according to claim 2 or 3, characterized in that The method further comprises: When the aging timer corresponding to the first temporary entry times out, the first temporary entry is deleted.

5. The method according to claim 1, characterized in that The second DHCP request message includes the first UPID; The method of forwarding the second DHCP request message to the CP device if a first DHCP response message is received from the CP device in response to the first DHCP request message and a second DHCP request message is received from the first client includes: If a second DHCP request message sent by the first client is received, and the first UPID is the same as the UPID of the first UP device, forwarding the second DHCP request message to the CP device; The step of discarding the second DHCP request message if the first DHCP response message sent by the CP is not received and the second DHCP request message sent by the first client is received includes: If a second DHCP request message sent by the first client is received, and the first UPID is different from the UPID of the first UP device, the second DHCP request message is discarded.

6. The method according to claim 5, characterized in that The second DHCP request message includes a custom option, and the custom option carries the first UPID; or The second DHCP request message includes a server DUID option, the server DUID option includes a UPID option, and the UPID option carries the first UPID.

7. A message processing method, characterized in that: Applied to a first client, the method includes: Sending 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; When receiving the first DHCP response message, 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 devices not selected by the CP device discard the second DHCP request message.

8. The method according to claim 7, characterized in that The second DHCP request message includes a first UPID; the UP device corresponding to the first UPID is the UP device that receives the first DHCP response message.

9. The method according to claim 8, characterized in that The step of sending a second DHCP request message to each UP device upon receiving the first DHCP response message includes: receiving the first DHCP response message sent by the first UP device, where the first DHCP response message includes a target option, where the target option is a custom option or a server DUID option, where the custom option carries the first UPID, and where the server DUID option includes a UPID option, where the UPID option carries the first UPID; A second DHCP request message is sent to each UP device, where the second DHCP request message includes the target option.

10. A message processing method, characterized in that: Applied to a CP device, the method includes: receiving a first DHCP request message sent by each UP device included in the UP backup group, where the first DHCP request message is sent by a first client; A first DHCP response message is sent to a first UP device selected from each of the UP devices, 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, the first UP device forwards the second DHCP request message to the CP device. After receiving the second DHCP request message, the unselected UP devices from each of the UP devices discard the second DHCP request message.

11. The method according to claim 10, characterized in that The second DHCP request message includes the UPID of the first UP device.

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

13. A message processing device, characterized in that: Applied to a first UP device included in a UP backup group, the apparatus includes: A receiving module, configured to receive a first DHCP request message sent by a first client; a processing module configured to forward the second DHCP request message to the CP device if a first DHCP response message sent by the CP device in response to the first DHCP request message is received and a second DHCP request message sent by the first client is received; and discard the second DHCP request message if the first DHCP response message is not received and the second DHCP request message is received.

14. A message processing device, characterized in that: Applied to a first client, the device includes: a first sending module, configured 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 receiving the first DHCP response message, so that the first UP device forwards the second DHCP request message to the CP device, and the UP devices not selected by the CP device discard the second DHCP request message.

15. A message processing device, characterized in that: Applied to CP equipment, the device includes: a receiving module, configured to receive a first DHCP request message sent by each UP device included in the UP backup group, where the first DHCP request message is sent by the first client; a sending module, configured to send a first DHCP response message to a first UP device selected from each of the UP devices, 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; and after receiving the second DHCP request message, the unselected UP devices from each of the UP devices discard the second DHCP request message.

Images