WO2021212424A1 - Method and apparatus for load balancing for route reflector - Google Patents

Method and apparatus for load balancing for route reflector Download PDF

Info

Publication number
WO2021212424A1
WO2021212424A1 PCT/CN2020/086463 CN2020086463W WO2021212424A1 WO 2021212424 A1 WO2021212424 A1 WO 2021212424A1 CN 2020086463 W CN2020086463 W CN 2020086463W WO 2021212424 A1 WO2021212424 A1 WO 2021212424A1
Authority
WO
WIPO (PCT)
Prior art keywords
clients
client
network node
route reflector
group
Prior art date
Application number
PCT/CN2020/086463
Other languages
French (fr)
Inventor
Xu Wu
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/CN2020/086463 priority Critical patent/WO2021212424A1/en
Publication of WO2021212424A1 publication Critical patent/WO2021212424A1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • H04L45/247Multipath using M:N active or standby paths
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/122Avoiding congestion; Recovering from congestion by diverting traffic away from congested entities

Definitions

  • the present disclosure generally relates to network technologies, and more specifically, to a method and apparatus for load balancing for a route reflector (RR) .
  • RR route reflector
  • Border Gateway Protocol is a standardized routing protocol which is designed to exchange routing and reachability information for TCP/IP (Transport Control Protocol /Internet Protocol) networks.
  • AS Autonomous System
  • Fig. 1 illustrates a full mesh connection for the routers within the AS, e.g. four routers R1, R2, R3, and R4. As shown in Fig. 1, each of the routers is connected to other three routers, and exchanges the routing and reachability information with other routers over BGP sessions therebetween. This requirement for complete internal BGP exchange is necessary to re-distribute external routing information to all other routers within the AS, but the AS with full mesh connection does not scale well.
  • FIG. 2 illustrates BGP connections between a RR (denoted as R1 in Fig. 2) and other routers (which are also referred to as client or RR client, denoted as R2, R3, and R4 in Fig. 2) .
  • the main task for the RR is to keep the BGP sessions between the RR and the RR clients alive, receive routes from each RR client that the RR serves, parse and determine the best-path route, and reflect the received routes to other RR clients that the RR serves.
  • the RR acts as a focal point for the BGP sessions. As shown in Fig. 2, multiple RR clients can peer with the RR rather than peer with every other RR client in a full mesh.
  • N routers within the AS total N* (N-1) /2 BGP sessions have to be set up in full mesh, but when one of N routers is selected as the RR and all the other routers become RR clients, (N-1) BGP sessions are needed.
  • N-1 BGP sessions are needed.
  • FIG. 3 illustrates a deployment of multiple RRs (RR1, RR2, RR3 and RR4) within a network.
  • each RR serves a group of clients to handle a reasonable number of BGP sessions, and the multiple RRs are connected in full mesh. Since it is similarly mandatory to have full-mesh connections among the RRs, it also becomes difficult for scalability of the network. So a hierarchical structure of RRs is introduced as Fig. 4. In Fig.
  • the RR at level 1 (denoted as RR1) is connected to all the RRs at level 2 (denoted as RR2, RR3, and RR4) , and each RR at level 2 serves a group of RR clients. In this case, there is no necessary to establish BGP connections between the RRs at level 2.
  • each RR serves a specific group of RR clients, as described above.
  • the handling of these routes is a key factor that consumes processing resources of the RR, e.g. CPU power and memory capacity.
  • Various embodiments of the present disclosure provide load balancing solutions for the RR, which can automatically optimize the load (e.g. the clients or the received routes) on the RR in real time without traffic disruption.
  • a method performed by a network node which is a master route reflector for a first group of clients comprises monitoring resource usage of the network node, obtaining, in response to the resource usage satisfying a load condition, available resource information of at least one slave route reflector associated with at least one client of the first group of clients, and transferring, based on the available resource information, one or more clients of the first group of clients to one or more slave route reflectors associated with the one or more clients which have available resources.
  • obtaining available resource information of at least one slave route reflector associated with at least one client of the first group of clients may comprises transmitting a first client transfer request to the at least one slave route reflector associated with the at least one client of the first group of clients, and receiving a first client transfer response comprising the available resource information indicating available resources for accepting an additional client.
  • the first client transfer response may further comprise an indication indicating whether the first client transfer request is accepted or not.
  • the available resource information may comprise at least one of an amount of additional clients that the slave route reflector can accept and an amount of additional routes that the slave route reflector can accept.
  • transferring one or more clients of the first group of clients to one or more slave route reflectors associated with the one or more clients which have available resources may comprise selecting, from the first group of clients, one or more clients to be transferred at least based on the available resource information, determining one or more slave route reflectors associated with the selected one or more clients which have available resources to accept the selected one or more clients, transmitting a respective client identification of the selected one or more clients to the determined one or more slave route reflectors, and suspending, in response to receiving an acknowledgement for the client transfer from the determined one or more slave route reflectors, the respective Border Gateway Protocol, BGP, session with the selected one or more clients.
  • BGP Border Gateway Protocol
  • the one or more clients to be transferred may be selected further based on an amount of routes that the client can support.
  • obtaining available resource information of at least one slave route reflector associated with at least one client of the first group of clients may comprise transmitting a second client transfer request to the at least one slave route reflector associated with the at least one client of the first group of clients, the second client transfer request indicating one or more clients of the first group of clients to be transferred, and receiving a second client transfer response comprising the available resource information indicating which of the one or more clients to be transferred can be accepted.
  • the second client transfer response further comprises an indication indicating whether client transfer is accepted or not.
  • transferring one or more clients of the first group of clients to one or more slave route reflectors associated with the one or more clients which have available resources may comprise determining, based on the available resource information, one or more slave route reflectors associated with the one or more clients which have available resources to accept the one or more clients to be transferred, and suspending, in response to receiving an acknowledgement for the client transfer from the determined one or more slave route reflectors, the respective BGP session with the one or more clients.
  • the resource usage may comprise at least one of a CPU usage and a memory usage.
  • the load condition may be that the resource usage exceeds a threshold, or may be that the resource usage exceeds a threshold for a predetermined time period.
  • the method may further comprise changing, after the client transferring, a role of the network node from the master route reflector to the slave route reflector for the transferred one or more clients.
  • the method may further comprise notifying the change of the role of the network node.
  • the method may further comprise transmitting capability information of the network node, the capability information indicating a capability of supporting client transfer.
  • the method may further comprise receiving capability information of another route reflector, the capability information indicating a capability of supporting client transfer.
  • the method may further comprise receiving client information of another route reflector, the client information indicating a group of clients that the another route reflector serves as a slave route reflector and a role attribute of the another router reflector for the group of clients, and storing the client information in association with the another route reflector.
  • the client information of the another route reflector may further indicate another group of clients that the another route reflector serves as a master route reflector and the role attribute for the another group of clients.
  • the method may further comprise receiving update information for the client information of the another route reflector.
  • a method performed by a network node which is a slave route reflector for a second group of clients comprises providing, in response to receiving a client transfer request from another network node which is a master route reflector of at least one client of the second group of clients, available resource information to the another network node, and receiving, in response to the available resource information indicating that the network node has available resources, one or more clients of the second group of clients transferred by the another network node.
  • the method may further comprise transmitting client information of the network node, the client information indicating the second group of clients and a role attribute of the network node for the second group of clients.
  • the client information of the network node may further indicate another group of clients that the network node serves as a master route reflector and the role attribute for the another group of clients.
  • the client transfer request may be a first client transfer request.
  • providing available resource information may comprise receiving the first client transfer request from the another network node, determining whether there are available resources in the network node, and transmitting a first client transfer response comprising the available resource information indicating the available resources for accepting an additional client.
  • the first client transfer response may further comprise an indication indicating whether client transfer is accepted or not.
  • the available resource information may comprise at least one of an amount of additional clients that the network node can accept and an amount of additional routes that the network node can accept.
  • the client transfer request may be a second client transfer request indicating one or more clients of the second group of clients to be transferred.
  • providing available resource information may comprise receiving the second client transfer request from the another network node, determining whether there are available resources in the network node, determining, in response to the network node having the available resources, which of the one or more clients to be transferred can be accepted, and transmitting a second client transfer response comprising the available resource information indicating which of the one or more clients to be transferred can be accepted.
  • the second client transfer response may further comprise an indication indicating whether client transfer is accepted or not.
  • determining whether there are available resources in the network node may comprise obtaining resource usage of the network node, determining, in response to the resource usage satisfying a load condition, that the network node has no available resources, and determining, in response to the resource usage not satisfying the load condition, that the network node has the available resources.
  • receiving one or more clients of the second group of clients transferred by the another network node may comprise receiving a respective client identification of the one or more clients of the second group of clients from the another network node, establishing the respective BGP session with the one or more clients of the second group of clients, and transmitting an acknowledgement for the client transfer to the another network node.
  • the method may further comprise updating the client information of the network node by changing the role attribute of the network node from the slave route reflector to the master route reflector for the one or more clients transferred from the another network node, and transmitting the updated client information.
  • the method may further comprise transmitting capability information of the network node, the capability information indicating a capability of supporting client transfer.
  • the method may further comprise receiving capability information of another route reflector, the capability information indicating a capability of supporting client transfer.
  • a method performed by a controller comprises designating a master route reflector and at least one slave route reflector to a client, transmitting route reflector information to the client, the route reflector information indicating the master route reflector and the at least one slave route reflector, and configuring each route reflector of the master route reflector and the at least one slave route reflector with client information, the client information indicating a group of clients that the route reflector serves as a master and/or a slave route reflector and a role attribute of the route reflector for the group of clients.
  • the master route reflector establishes a BGP session with the client, and the at least one route reflector does not establish a BGP session with the client.
  • the client can be transferred from the master route reflector to one of the at least one slave route reflector.
  • a network node which is configured to act as a master route reflector for a first group of clients.
  • the network node may comprise one or more processors and one or more memories comprising computer program codes.
  • the one or more memories and the computer program codes may be configured to, with the one or more processors, cause the network node at least to perform any step of the method according to the first aspect of the present disclosure.
  • a network node which is configured to act as a slave route reflector for a second group of clients.
  • the network node may comprise one or more processors and one or more memories comprising computer program codes.
  • the one or more memories and the computer program codes may be configured to, with the one or more processors, cause the second network entity at least to perform any step of the method according to the second aspect of the present disclosure.
  • a controller may comprise one or more processors and one or more memories comprising computer program codes.
  • the one or more memories and the computer program codes may be configured to, with the one or more processors, cause the controller at least to perform any step of the method according to the third aspect of the present disclosure.
  • a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the first aspect of the present disclosure.
  • a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the second aspect of the present disclosure.
  • a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the third aspect of the present disclosure.
  • Fig. 1 is a diagram illustrating a full mesh connection for the routers within the AS
  • Fig. 2 is a diagram illustrating BGP connections between the RR and RR clients
  • Fig. 3 is a diagram illustrating a deployment of multiple RRs within a network
  • Fig. 4 is a diagram illustrating a hierarchical structure of RRs
  • Fig. 5 is a flowchart illustrating a method performed by a network node which is a master RR for a first group of clients according to some embodiments of the present disclosure
  • Fig. 6 is a flowchart illustrating a method performed by a network node which is a slave RR for a second group of clients according to some embodiments of the present disclosure
  • Figs. 7A, 7B, and 7C are diagrams illustrating an exemplary load balancing process for RRs in which the methods as shown in Figs. 5-6 can be implemented;
  • Fig. 8 is a diagram showing that each client has multiple slave RRs
  • Fig. 9 is a flowchart illustrating a method performed by a controller according to some embodiments of the present disclosure.
  • Fig. 10 is a block diagram illustrating an apparatus according to some embodiments of the present disclosure.
  • Fig. 11 is a block diagram illustrating a network node according to some embodiments of the present disclosure.
  • Fig. 12 is a diagram illustrating a client transfer workflow between the master RR and the slave RR.
  • Fig. 13 is a block diagram illustrating a controller according to some embodiments of the present disclosure.
  • the terms “first” , “second” and so forth refer to different elements.
  • the singular forms “a” and “an” are intended to include the plural forms as well, unless the context clearly indicates otherwise.
  • the term “based on” is to be read as “based at least in part on”.
  • the term “one embodiment” and “an embodiment” are to be read as “at least one embodiment” .
  • the term “another embodiment” is to be read as “at least one other embodiment” .
  • Other definitions, explicit and implicit, may be included below.
  • Various exemplary embodiments of the present disclosure provide improved load balancing solutions for the RR. These solutions may be applied to a network node in the AS. With the improved solutions, the automatic load balancing can be achieved and the operating expense of the network can be reduced.
  • Fig. 5 is a flowchart illustrating a method 500 according to some embodiments of the present disclosure.
  • the method 500 illustrated in Fig. 5 may be performed by a network node, e.g. a RR, in an autonomous system.
  • the autonomous system may comprise a plurality of RRs including the network node and a plurality of clients including at least a first group of clients.
  • the network node is a master RR for the first group of clients.
  • each client usually peers with one RR. But in some embodiments of the present disclosure, each client may be designated with a master RR and at least one slave RR in advance.
  • the master RR works like the traditional RR, e.g. receives the routes from the client and reflects to the client the routes received from other clients.
  • the master RR will establish a BGP session with the client.
  • the slave RR just stays in standby for the client and will take no action.
  • the network node monitors resource usage of the network node, as shown in block 502.
  • the resource usage may include at least one of a CPU usage and a memory usage.
  • the CPU usage may be the CPU power consumed by the network node handling BGP sessions or the CPU power consumption in total.
  • the memory usage may be the memory space consumed by the BGP sessions or the memory space consumption in total.
  • the network node may monitor the resource usage via an internal monitoring process.
  • the network node may determine whether the network node is overloaded or is about to be overloaded based on the resource usage. In some embodiments, the network node may determine whether the resource usage satisfies a load condition. In some embodiments, the load condition may be that the resource usage exceeds a predetermined threshold. In the case that the resource usage includes the CPU usage and/or the memory usage, the threshold may be set separately for the CPU usage and the memory usage. In some embodiments, the load condition may be that the resource exceeds the predetermined threshold for a predetermined time period.
  • the network node If it is determined that the resource usage of the network node does not satisfy the load condition, which means that the network node is not overloaded or about to be overloaded, the network node will continue monitoring the resource usage.
  • the network node obtains available resource information of at least one slave RR associated with at least one client of the first group of clients, as shown in block 504.
  • each client of the first group of clients is designated with the network node as the master RR and one or more slave RRs.
  • the slave RRs for the first group of clients may be the same RR or different RRs.
  • the network node may obtain the available resource information of a part of or all the slave RRs associated with the first group of clients.
  • one slave RR is taken as an example. Those skilled in the art will appreciate that it is applicable to multiple slave RRs.
  • the network node may transmit a first client transfer request to the slave RR associated with the first group of clients.
  • the first client transfer request may indicate that the client transfer is requested and requires the slave RR to provide its available resource information.
  • the network node may receive a first client transfer response from the slave RR.
  • the first client transfer response may comprise the available resource information of the slave RR indicating the available resources for accepting an additional client.
  • the available resources may be represented by an amount of additional clients that the slave RR can accept and/or an amount of additional routes that the salve RR can accept.
  • the first client transfer response may further comprise an indication indicating whether the client transfer is accepted or not.
  • the available resource information may comprise the amount of additional clients or routes to be accepted, and the indication may indicate acceptance of the client transfer. If the slave RR has no available resource, the amount of additional clients or routes may be set to zero, and the indication may indicate rejections of the client transfer.
  • the network node may transmit a second client transfer request to the slave RR associated with the first group of clients.
  • the second client transfer request may indicate one or more clients of the first group of clients to be transferred to the slave RR.
  • the network node may receive a second transfer response from the slave RR.
  • the second client transfer response may comprise the available resource information indicating which client (s) of the one or more clients to be transferred can be accepted by the slave RR. Further the second client transfer response may comprise an indication which indicates whether the client transfer is accepted or not. If the slave RR has the available resources to accept some of the one or more clients to be transferred, the available resource information may indicate the specific client (s) to be accepted, and the indication may indicate the acceptance of the client transfer. If the slave RR has no available resource to accept any of the one or more clients to be transferred, the available resource information may indicate no client to be accepted, and the indication may indicate the rejection of the client transfer.
  • the network node may transmit the first or second client transfer request to the slave RRs concurrently, and thus the network node can obtain the available resource information of the slave RRs at one time for subsequent operations.
  • the network node may transmit the first or second client transfer request to the slave RRs sequentially. In this case, if the indication of first or second client transfer response from a slave RR indicates the rejection of the client transfer, the network node may transmit the first or second client transfer request to the next slave RR.
  • the network node may transfer one or more clients of the at least one client of the first group of clients to one or more slave RRs associated with the one or more clients which have available resources, based on the obtained available resource information.
  • the network node may select, at least based on the amount of the additional clients and/or routes, one or more clients to be transferred from the first group of clients.
  • the network node as the master RR can establish the BGP sessions with the first group of clients, and receive, process and reflect the routes among the first group of clients.
  • the network node can obtain route statistics information of each of the first group of clients.
  • the route statistics information of the client may indicate the amount of the routes that the client can support. Then based on the available resource information and the route statistics information of the first group of clients, the network node may select one or more clients to be transferred.
  • the network node may determine one or more slave RRs associated with the selected one or more clients which have available resources to accept the selected one or more clients.
  • one slave RR may be determined for the one or more clients to be transferred.
  • more than one slave RR may be determined for more than one client. Accordingly, the network node may determine which slave RR to accept which client (s) , so that the more than one client to be transferred are distributed over the determined slave RRs.
  • the network node may initiate the client transfer by transmitting a respective client identification of the one or more clients to be transferred to the determined one or more slave RRs.
  • the client identification may be an IP address of the client.
  • the network node will transmit the client identification (s) of the one or more clients to be transferred to the slave RR. In the case that more than one slave RR are determined, the network node will transmit the client identifications of the clients to be transferred to the respective slave RRs. After receiving an acknowledgement for the client transfer from the one or more slave RRs which receive the transferred one or more clients, the network node may suspend the BGP session (s) with the transferred client (s) .
  • the network node may determine, based on the available resource information, one or more slave RRs associated with the one or more clients to be transferred which have available resources to accept the one or more clients. In some embodiments, the network node may determine the slave RR to accept the client (s) indicated in the available resource information of the slave RR. In some embodiments, one salve RR may be determined for the one or more clients to be transferred. In some embodiments, more than one slave RR may be determined for more than one client.
  • the network node may determine which slave RR to accept which client (s) based on the available resource information of the more than one slave RR, so that the more than one client to be transferred are distributed over the more than one slave RR. Then the network node may initiate the client transfer by transmitting the respective client identification (e.g. the IP address) of the one or more clients to be transferred to the determined one or more slave RRs. In the case that only one slave RR is determined, the network node will transmit the client identification (s) of the one or more clients to be transferred to the slave RR. In the case that more than one slave RR are determined, the network node will transmit the client identifications of the clients to be transferred to the respective slave RRs. After receiving an acknowledgement for the client transfer from the one or more slave RRs which receive the transferred one or more clients, the network node may suspend the BGP session (s) with the transferred client (s) .
  • the network node may suspend the BGP session (s) with the transferred client (s) .
  • the network node may keep monitoring the resource usage and repeat the operations as described above in blocks 504 and 506 if the resource usage satisfies the loading condition.
  • the network node After the client transfer from the network node is completed, the network node becomes the slave RR for the transferred one or more clients.
  • the network node may change its role from the master RR to the slave RR for the transferred client (s) , e.g. after receiving the acknowledgement for the client transfer.
  • the network node may be configured with client information.
  • the client information may be defined to indicate a group of clients that a RR serves as a master RR and/or a slave RR and a role attribute of the RR for the group of clients. Initially the client information of the network node comprises the client identifications of the first group of clients, and the role attribute for each client of the first group of clients is set to “Master” .
  • the client information of the network node may be configured by a controller initially and may be exchanged with other RR (s) in the AS network so that the network node can know the slave RR (s) for the first group of clients.
  • the client information is updated by changing the role attribute (s) for the transferred one or more clients of the first group of clients from “Master” to “Slave” .
  • the network node may notify other RR (s) in the autonomous system of the change of its role.
  • the network node may transmit the updated client information to other RR (s) .
  • the network node may transmit the changed role attribute (s) and corresponding client identifications as update information of the client information. The description with respect to the operations of the network node as the slave RR will be provided later with reference to Fig. 6.
  • the network node may receive the client information of another RR.
  • the client information of the another RR may comprise a group of clients that the another RR serves as a slave RR and/or a master and the respective role attribute for each client of the group of clients indicating “Master” or “Slave” .
  • the network node can know which client (s) has another RR as the slave router and which client (s) has another RR as the master RR. If the another RR is the slave RR for at least one client of the first group of clients, the network node can negotiate for the client transfer with the another RR. Then the network node may store the client information of the another RR.
  • the network node or the RR may not transmit its client information if the network node or the RR is the master RR only.
  • the network node or the RR becomes a slave RR for at least one client due to the client transfer, it needs to transmit the client information with the change of the role attribute.
  • the network node may receive the update information for the client information of the another RR.
  • the update information may be either the whole updated client information or only the changed role attribute (s) and corresponding client identification (s) .
  • a Notification message may be used for the client transfer, e.g. for transmitting the client information, the first and second client transfer requests, the first and second clients transfer responses, the client identification (s) of the client (s) to be transferred, and the acknowledge for the client transfer.
  • the Notification message has been defined with error codes 0-7. New code/subcode/data needs to be defined for the client transfer as follows. Code Subcode Data
  • a new type of message may be defined for the client transfer.
  • the network node may be configured with capability information.
  • the capability information may indicate a RR’s capability of supporting client transfer. With the capability information, the RR may know if a peer RR supports the client transfer.
  • the network node may transmit and receive the capability information to and from another RR.
  • the capability information may be transmitted or received in a BGP protocol message, e.g. Open message, as a new parameter. This new parameter may be defined as Optional Parameter, and thus there is no impact to legacy RR functions if a RR does not have such capability.
  • the network node is the master RR for the first group of clients, those skilled in the art will appreciate that the network node may also act as the slave RR for another group of clients simultaneously.
  • Fig. 6 is a flowchart illustrating a method 600 according to some embodiments of the present disclosure.
  • the method 600 illustrated in Fig. 6 may be performed by a network node, e.g. a RR, in the autonomous system.
  • the network node is a slave RR for a second group of clients in the autonomous system.
  • each of the second group of clients may have its own master RR and has established a BGP session with the master RR.
  • the network node stays in standby for the second group of clients.
  • the network node in response to receiving a client transfer request from another network node (hereinafter referred to as “second network node” ) which is the master RR of at least one client of the second group of clients, the network node provides the available resource information to the second network node, as shown in block 602.
  • second network node another network node which is the master RR of at least one client of the second group of clients
  • the client transfer request may be the first client transfer request.
  • the first client transfer request may indicate that the client transfer is requested and requires the slave RR to provide its available resource information.
  • the network node may determine whether there are available resources in the network node. Then the network node may transmit the first client transfer response to the second network node.
  • the first transfer response may comprise the available resource information indicating the available resources for accepting an additional client. In some embodiments, the available resources may be represented by the amount of additional clients and/or routes that the network node can accept. Further, the first client transfer response may comprise the indication indicating whether the client transfer is accepted or not, i.e. acceptance or rejection of the client transfer.
  • the client transfer request may be the second client transfer request which indicates one or more clients of the second group of clients to be transferred.
  • the network node may determine whether there are available resources in the network node. If it is determined that there are the available resources, the network node may determine which client (s) of the one or more clients indicated in the second client transfer request can be accepted. The determination of the client (s) to be accepted may be based on the available resources and the amount of routes that the client can support. Then the network node may transmit the second client transfer response to the second network.
  • the second client transfer response may comprise the available resource information indicating which client (s) of the one or more clients to be transferred can be accepted.
  • the second client transfer response may also comprise the indication indicating whether the client transfer is accepted or not. If it is determined that there is no available resource in the network node, the network node may transmit the second client transfer response indicating none of the one or more clients to be transferred can be accepted and the rejection of the client transfer.
  • the determination of the available resources may be based on the resource usage of the network node.
  • the resource usage may comprise the CPU usage and/or the memory usage.
  • the CPU usage may be represented by the CPU power consumed by the BGP sessions in the network node or the CPU power consumption in total
  • the memory usage may be represented by the memory space consumed by the BGP sessions or the memory space consumption in total.
  • the network node may monitor the CPU usage and/or the memory usage to obtain the resource usage. Then the network node may determine whether the resource usage satisfies the load condition.
  • the load condition may be that the resource usage exceeds a predetermined threshold or that the resource usage exceeds the predetermined threshold for a predetermined time period.
  • the threshold may comprise a first threshold for the CPU usage and a second threshold for the memory usage. If it is determined that the resource usage satisfies the load condition, the network node may determine that it has no available resource. If it is determined that the resource usage does not satisfy the load condition, the network node may determine that it has the available resources.
  • the network node may receive one or more clients of the second group of clients transferred by the second network node.
  • the network node may receive the respective client identification of the one or more clients from the second network node.
  • the client identification may be an IP address of the client.
  • the network node may then establish the respective BGP session with the one or more clients and transmit an acknowledgement for the client transfer to the second network node.
  • the acknowledgement may be transmitted per client identification or may be transmitted for an aggregation of the established BGP sessions. After the acknowledgement is transmitted, the network node becomes the master RR for the transferred client (s) .
  • the network node may be configured with the client information.
  • the client information may be defined to indicate a group of clients that a RR serves as a master RR and/or a slave RR and a role attribute of the RR for the group of clients.
  • the client information of the network node comprises the client identifications of the second group of clients, and the role attribute for each client of the second group of clients is set to “Slave” .
  • the client information is updated by changing the role attribute (s) for the transferred one or more clients of the second group of clients from “Slave” to “Master” .
  • the network node may transmit the updated client information.
  • the updated client information may include the changed role attribute (s) and corresponding client identifications.
  • the network node may be configured with the capability information.
  • the capability information may indicate the capability of supporting client transfer. Further, the network node may transmit and receive the capability information to and from another RR.
  • the capability information may be transmitted or received in a BGP protocol message, e.g. Open message, as a new parameter.
  • the network node is the slave RR for the second group of clients, those skilled in the art will appreciate that the network node may also act as the master RR for another group of clients simultaneously.
  • the load balancing for the RRs can be performed automatically and in real time without disruption of live traffic. Moreover, the resources of the RRs can be efficiently used.
  • the RR having the capability of supporting client transfer can seamlessly work with the RR having no such capability, and there is no impact on the client.
  • the methods of the embodiments described above is applicable to not only a dedicated-hardware based router in a traditional network, e.g. mobile backhaul network, but also a virtual software based router, e.g. running on a virtual machine (VM) in a data center network.
  • VM virtual machine
  • Figs. 7A, 7B and 7C illustrate an exemplary load balancing process for RRs in which the methods as shown in Figs. 5-6 can be implemented.
  • RR1 acts as the master RR for clients 1, 2, 3 and 4, and acts as the slave RR for clients 5, 6, 7 and 8.
  • RR2 acts as the master RR for clients 5, 6, 7 and 8, and acts as the slave RR for clients 1, 2, 3 and 4.
  • each client 1, 2, 3, and 4 has RR1 as the master RR and RR2 has the slave RR
  • each client 5, 6, 7, and 8 has RR2 as the master RR and RR1 as the slave RR.
  • RR1 establishes normal BGP sessions with clients 1, 2, 3 and 4 respectively, and suspends for clients 5, 6, 7 and 8.
  • RR2 establishes normal BGP sessions with clients 5, 6, 7 and 8 respectively, and suspends for clients 1, 2, 3, and 4.
  • solid line represents the master RR
  • the dashed line represents the slave RR.
  • the role attribute is added to existing RR configuration to specify the role of the RR for a specific client.
  • RR1 acts as the master RR for client 1 and the slave RR for client 5:
  • the client can set up normal BGP sessions with both the master RR and the slave RR, but is unaware of the role attribute.
  • client 1 which has RR1 as the master RR and RR2 as the slave RR:
  • Client1 (config-bgp) #neighbor m. m. m. m (RR1-ip-address)
  • Each of RR1 and RR2 monitors its resource usage, and determines whether the resource usage satisfies the load condition to determine whether it is overloaded or is about to be overloaded. Assume in this example that RR1 is overloaded, RR1 will negotiate with RR2 to transfer some clients from RR1 to RR2, as shown in Fig. 7B. RR1 may transmit the client transfer request (e.g. the first or second client transfer request) to RR2 to obtain the available resource information of RR2. In response to receiving the client transfer request, RR2 may determine its available resources and respond with the client transfer response.
  • client transfer request e.g. the first or second client transfer request
  • RR2 may determine its available resources and respond with the client transfer response.
  • RR1 When the available resource information of RR2 in the client transfer response indicates that RR2 has the available resources, RR1 will select one or more clients to be transferred, for example, clients 3 and 4, based on the available resource information. Then RR1 may transmit the client identifications of clients 3 and 4, e.g. the IP address. Upon receipt of the client identifications of clients 3 and 4, RR2 can establish the BGP sessions with clients 3 and 4, and transmit the acknowledgement to RR1. After receiving the acknowledgement, RR1 suspends the BGP sessions with clients 3 and 4. After the client transfer is completed, RR1 becomes the slave RR for clients 3 and 4, and RR2 becomes the master RR for clients 3 and 4, as shown in Fig. 7C. Table 1 shows the routes received on RR1 and sent from RR1 before and after the client transfer.
  • Table 1 shows the routes received on RR1 and sent from RR1 before and after the client transfer.
  • Routes received on RR1 Routes sent from RR1 Before client transfer From clients 1/2/3/4 and RR2 To clients 1/2/3/4 and RR2 After client transfer From clients 1/2 and RR2 To clients 1/2 and RR2
  • RR1 After clients 3 and 4 are transferred from RR1 to RR2, RR1 will still receive the routes of clients 3 and 4 reflected by RR2, but RR2 will just reflect the best path routes instead of original routes. Thus, the amount of the routes received by RR1 can be reduced. On the other hand, the amount of the routes sent from RR1 can also be reduced and the load on RR1 can be dramatically eased.
  • clients 1, 2, 3 and 4 each has only one slave RR, i.e. RR2.
  • each client may have more than one slave RR, as shown in Fig. 8.
  • clients 1, 2, 3 and 4 in addition to RR2, clients 1, 2, 3 and 4 each has another slave RR, i.e. RR3.
  • the BGP sessions are established among RR1, RR2 and RR3.
  • the load balancing process for the RRs in Fig. 8 is similar to that for the RRs in Fig. 7.
  • Fig. 9 is a flowchart illustrating a method 900 according to some embodiments of the present disclosure.
  • the method 900 as shown in Fig. 9 may be performed by a controller or a controlling node.
  • the controller designates a master RR and at least one slave RR to a client, as shown in block 902.
  • the designation may be based on a network design.
  • the master RR can establish the BGP session with the client, and the slave RR will not establish the BGP session with the client.
  • the controller may transmit RR information to the client, as shown in block 904.
  • the RR information may indicate the master RR and the at least one slave RR to the client.
  • the RR information may comprise an identification of the RR, e.g. IP address.
  • the client can know its serving RRs.
  • the client can establish the BGP session with the master RR and the slave RR (s) , but only the BGP session with the master RR can be established successfully.
  • the RR information does not indicate the role attribute of the RR, the client will not know which is the master RR and which is the slave RR. Thus, the existing configuration for the client would not change.
  • the controller configures each RR of the master RR and the at least one slave RR with the client information.
  • the client information may indicate a group of clients that the RR serves as a master RR and/or a slave RR and the role attribute of the RR for the group of clients.
  • the client information may comprise the client identification of each of the group of clients and the respective role attribute indicating “Master” or “Slave” for the client.
  • the role attribute of the RR for the client can be changed after the client is transferred from the master RR to the slave RR.
  • Figs. 5-6 and 9 may be viewed as method steps, and/or as operations that result from operation of computer program code, and/or as a plurality of coupled logic circuit elements constructed to carry out the associated function (s) .
  • the schematic flow chart diagrams described above are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of specific embodiments of the presented methods. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated methods. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.
  • Fig. 10 is a block diagram illustrating an apparatus 1000 according to various embodiments of the present disclosure.
  • the apparatus 1000 may comprise one or more processors such as processor 1001 and one or more memories such as memory 1002 storing computer program codes 1003.
  • the memory 1102 may be non-transitory machine/processor/computer readable storage medium.
  • the apparatus 1000 may be implemented as an integrated circuit chip or module that can be plugged or installed into the network node as described with respect to Fig. 5 or Fig. 6, or the controller as described with respect to Fig. 9.
  • the one or more memories 1002 and the computer program codes 1003 may be configured to, with the one or more processors 1001, cause the apparatus 1000 at least to perform any operation of the method as described in connection with Fig. 5 or Fig. 6.
  • the apparatus 1000 may be implemented as at least part of or communicatively coupled to the network node as described above.
  • the apparatus 1000 may be implemented as the network node.
  • the one or more memories 1002 and the computer program codes 1003 may be configured to, with the one or more processors 1001, cause the apparatus 1000 at least to perform any operation of the method as described in connection with Fig. 9.
  • the apparatus 1000 may be implemented as at least part of or communicatively coupled to the controller as described above.
  • the apparatus 1000 may be implemented as the controller.
  • the one or more memories 1002 and the computer program codes 1003 may be configured to, with the one or more processors 1001, cause the apparatus 1000 at least to perform more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.
  • Fig. 11 is a block diagram illustrating a network node 1100 according to some embodiments of the present disclosure.
  • the network node 1100 may comprise a monitor unit 1101, a negotiation unit 1102, and a client transfer unit 1103.
  • the network node 1100 may be implemented as a master RR.
  • the monitor unit 1101 may be configured to carry out the operation in block 502.
  • the negotiation unit 1102 may be configured to carry out the operation in block 504.
  • the client transfer unit 1103 may be configured to carry out the operation in block 506.
  • the network node 1100 may comprise a route handling unit 1104 which is configured to receive routes from a client, process the routes and reflect the routes to other clients.
  • the network node 1100 may be implemented as a slave RR.
  • the negotiation unit 1102 may be configured to cooperate with the monitor unit 1101 to carry out the operation in block 602.
  • the client transfer unit 1103 may be configured to carry out the operation in block 604.
  • the monitor unit 1101, the negotiation unit 1102 and/or the client transfer unit 1103 may be configured to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.
  • Fig. 12 illustrates the client transfer workflow between the master RR, RR1, and the slave RR, RR2.
  • the structure of the master RR and the structure of the slave RR are as shown in Fig. 11. If the monitor unit of RR1 determines that RR1 is overloaded, the negotiation unit of RR1 transmits a client transfer request to the negotiation unit of RR2. Then the monitor unit of RR2 checks if there are available resources to accept the additional client (s) . If there is no available resource, the negotiation unit of RR2 responds with a client transfer response indicating the rejection of the client transfer. Then the negotiation unit of RR1 terminates the client transfer or requests for the client transfer from another slave RR.
  • the negotiation unit of RR2 responds with a client transfer response indicating the acceptance of the client transfer and the amount of the clients and/or routes that can be accepted. Then the client transfer unit of RR1 selects the client (s) to be transferred and transmits the client identification (s) of the client (s) to be transferred to the client transfer unit of RR2. The client transfer unit of RR2 establishes the BGP session (s) with the client (s) to be transferred, and returns acknowledgement to the client transfer unit of RR1. Then the client transfer unit of RR1 suspends the BGP session (s) with the transferred client (s) .
  • Fig. 13 is a block diagram illustrating a controller 1300 according to some embodiments of the present disclosure.
  • the controller 1300 may comprise a designating unit 1301, a transmitting unit 1302, and a configuring unit 1303.
  • the designating unit 1301 may be configured to carry out the operation in block 902.
  • the transmitting unit 1302 may be configured to carry out the operation in block 904.
  • the configuring unit 1303 may be configured to carry out the operation in block 906.
  • the designating unit 1301, the transmitting unit 1302 and/or the configuring unit 1303 may be configured to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.
  • the various exemplary embodiments may be implemented in hardware or special purpose chips, circuits, software, logic or any combination thereof.
  • some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto.
  • firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto.
  • While various aspects of the exemplary embodiments of this disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
  • the exemplary embodiments of the disclosure may be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of this disclosure may be realized in an apparatus that is embodied as an integrated circuit, where the integrated circuit may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this disclosure.
  • exemplary embodiments of the disclosure may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device.
  • the computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, random access memory (RAM) , etc.
  • RAM random access memory
  • the function of the program modules may be combined or distributed as desired in various embodiments.
  • the function may be embodied in whole or partly in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA) , and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Various embodiments of the present disclosure provide methods and apparatuses for load balancing for a route reflector. A method performed by a network node which is a master route reflector for a first group of clients comprises: monitoring resource usage of the network node, obtaining, in response to the resource usage satisfying a load condition, available resource information of at least one slave route reflector associated with at least one client of the first group of clients; and transferring, based on the available resource information, one or more clients of the first group of clients to one or more slave route reflectors associated with the one or more clients which have available resources.

Description

METHOD AND APPARATUS FOR LOAD BALANCING FOR ROUTE REFLECTOR FIELD OF THE INVENTION
The present disclosure generally relates to network technologies, and more specifically, to a method and apparatus for load balancing for a route reflector (RR) .
BACKGROUND
This section introduces aspects that may facilitate a better understanding of the disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.
Border Gateway Protocol (BGP) is a standardized routing protocol which is designed to exchange routing and reachability information for TCP/IP (Transport Control Protocol /Internet Protocol) networks. In RFC4271, a rule of deployment specifies that all routers running BGP within a single Autonomous System (AS) must be fully meshed. Fig. 1 illustrates a full mesh connection for the routers within the AS, e.g. four routers R1, R2, R3, and R4. As shown in Fig. 1, each of the routers is connected to other three routers, and exchanges the routing and reachability information with other routers over BGP sessions therebetween. This requirement for complete internal BGP exchange is necessary to re-distribute external routing information to all other routers within the AS, but the AS with full mesh connection does not scale well.
Route Reflector (RR) was introduced to address the above scaling issue. Fig. 2 illustrates BGP connections between a RR (denoted as R1 in Fig. 2) and other routers (which are also referred to as client or RR client, denoted as R2, R3, and R4 in Fig. 2) . The main task for the RR is to keep the BGP sessions between the RR and the RR clients alive, receive routes from each RR client that the RR serves, parse and determine the best-path route, and reflect the received routes to other RR clients that the RR serves. The RR acts as a focal point for the BGP sessions. As shown in Fig. 2, multiple RR clients can peer with the RR rather than peer with every other RR client in a full mesh. Thus, the full-mesh requirement within the AS can be eliminated. For N routers within the AS, total  N* (N-1) /2 BGP sessions have to be set up in full mesh, but when one of N routers is selected as the RR and all the other routers become RR clients, (N-1) BGP sessions are needed. Moreover, there will always be a finite number of BGP sessions (or RR clients) that a RR can serve, which depends on many factors such as the number of routes per BGP session, CPU power and/or memory space of the RR.
In a large-scale network, there are always two or more RRs. Fig. 3 illustrates a deployment of multiple RRs (RR1, RR2, RR3 and RR4) within a network. In Fig. 3, each RR serves a group of clients to handle a reasonable number of BGP sessions, and the multiple RRs are connected in full mesh. Since it is similarly mandatory to have full-mesh connections among the RRs, it also becomes difficult for scalability of the network. So a hierarchical structure of RRs is introduced as Fig. 4. In Fig. 4, the RR at level 1 (denoted as RR1) is connected to all the RRs at level 2 (denoted as RR2, RR3, and RR4) , and each RR at level 2 serves a group of RR clients. In this case, there is no necessary to establish BGP connections between the RRs at level 2.
In the existing network with the RRs, each RR serves a specific group of RR clients, as described above. However, it is difficult to determine the actual number of RR clients that one RR can serve, because the number of routes received from each client is uncertain. The handling of these routes is a key factor that consumes processing resources of the RR, e.g. CPU power and memory capacity.
SUMMARY
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Various embodiments of the present disclosure provide load balancing solutions for the RR, which can automatically optimize the load (e.g. the clients or the received routes) on the RR in real time without traffic disruption.
According to a first aspect of the present disclosure, there is provided a method  performed by a network node which is a master route reflector for a first group of clients. The method comprises monitoring resource usage of the network node, obtaining, in response to the resource usage satisfying a load condition, available resource information of at least one slave route reflector associated with at least one client of the first group of clients, and transferring, based on the available resource information, one or more clients of the first group of clients to one or more slave route reflectors associated with the one or more clients which have available resources.
In accordance with an exemplary embodiment, obtaining available resource information of at least one slave route reflector associated with at least one client of the first group of clients may comprises transmitting a first client transfer request to the at least one slave route reflector associated with the at least one client of the first group of clients, and receiving a first client transfer response comprising the available resource information indicating available resources for accepting an additional client.
In accordance with an exemplary embodiment, the first client transfer response may further comprise an indication indicating whether the first client transfer request is accepted or not.
In accordance with an exemplary embodiment, the available resource information may comprise at least one of an amount of additional clients that the slave route reflector can accept and an amount of additional routes that the slave route reflector can accept.
In accordance with an exemplary embodiment, transferring one or more clients of the first group of clients to one or more slave route reflectors associated with the one or more clients which have available resources may comprise selecting, from the first group of clients, one or more clients to be transferred at least based on the available resource information, determining one or more slave route reflectors associated with the selected one or more clients which have available resources to accept the selected one or more clients, transmitting a respective client identification of the selected one or more clients to the determined one or more slave route reflectors, and suspending, in response to receiving an acknowledgement for the client transfer from the determined one or more slave route reflectors, the respective Border Gateway Protocol, BGP, session with the selected one or more clients.
In accordance with an exemplary embodiment, the one or more clients to be transferred may be selected further based on an amount of routes that the client can support.
In accordance with an exemplary embodiment, obtaining available resource information of at least one slave route reflector associated with at least one client of the first group of clients may comprise transmitting a second client transfer request to the at least one slave route reflector associated with the at least one client of the first group of clients, the second client transfer request indicating one or more clients of the first group of clients to be transferred, and receiving a second client transfer response comprising the available resource information indicating which of the one or more clients to be transferred can be accepted.
In accordance with an exemplary embodiment, the second client transfer response further comprises an indication indicating whether client transfer is accepted or not.
In accordance with an exemplary embodiment, transferring one or more clients of the first group of clients to one or more slave route reflectors associated with the one or more clients which have available resources may comprise determining, based on the available resource information, one or more slave route reflectors associated with the one or more clients which have available resources to accept the one or more clients to be transferred, and suspending, in response to receiving an acknowledgement for the client transfer from the determined one or more slave route reflectors, the respective BGP session with the one or more clients.
In accordance with an exemplary embodiment, the resource usage may comprise at least one of a CPU usage and a memory usage.
In accordance with an exemplary embodiment, the load condition may be that the resource usage exceeds a threshold, or may be that the resource usage exceeds a threshold for a predetermined time period.
In accordance with an exemplary embodiment, the method may further comprise changing, after the client transferring, a role of the network node from the master route reflector to the slave route reflector for the transferred one or more clients.
In accordance with an exemplary embodiment, the method may further comprise notifying the change of the role of the network node.
In accordance with an exemplary embodiment, the method may further comprise transmitting capability information of the network node, the capability information indicating a  capability of supporting client transfer.
In accordance with an exemplary embodiment, the method may further comprise receiving capability information of another route reflector, the capability information indicating a capability of supporting client transfer.
In accordance with an exemplary embodiment, the method may further comprise receiving client information of another route reflector, the client information indicating a group of clients that the another route reflector serves as a slave route reflector and a role attribute of the another router reflector for the group of clients, and storing the client information in association with the another route reflector.
In accordance with an exemplary embodiment, the client information of the another route reflector may further indicate another group of clients that the another route reflector serves as a master route reflector and the role attribute for the another group of clients.
In accordance with an exemplary embodiment, the method may further comprise receiving update information for the client information of the another route reflector.
According to a second aspect of the present disclosure, there is provided a method performed by a network node which is a slave route reflector for a second group of clients. The method comprises providing, in response to receiving a client transfer request from another network node which is a master route reflector of at least one client of the second group of clients, available resource information to the another network node, and receiving, in response to the available resource information indicating that the network node has available resources, one or more clients of the second group of clients transferred by the another network node.
In accordance with an exemplary embodiment, the method may further comprise transmitting client information of the network node, the client information indicating the second group of clients and a role attribute of the network node for the second group of clients.
In accordance with an exemplary embodiment, the client information of the network node may further indicate another group of clients that the network node serves as a master route reflector and the role attribute for the another group of clients.
In accordance with an exemplary embodiment, the client transfer request may be a first  client transfer request. In the embodiment, providing available resource information may comprise receiving the first client transfer request from the another network node, determining whether there are available resources in the network node, and transmitting a first client transfer response comprising the available resource information indicating the available resources for accepting an additional client.
In accordance with an exemplary embodiment, the first client transfer response may further comprise an indication indicating whether client transfer is accepted or not.
In accordance with an exemplary embodiment, the available resource information may comprise at least one of an amount of additional clients that the network node can accept and an amount of additional routes that the network node can accept.
In accordance with an exemplary embodiment, the client transfer request may be a second client transfer request indicating one or more clients of the second group of clients to be transferred. In the embodiment, providing available resource information may comprise receiving the second client transfer request from the another network node, determining whether there are available resources in the network node, determining, in response to the network node having the available resources, which of the one or more clients to be transferred can be accepted, and transmitting a second client transfer response comprising the available resource information indicating which of the one or more clients to be transferred can be accepted.
In accordance with an exemplary embodiment, the second client transfer response may further comprise an indication indicating whether client transfer is accepted or not.
In accordance with an exemplary embodiment, determining whether there are available resources in the network node may comprise obtaining resource usage of the network node, determining, in response to the resource usage satisfying a load condition, that the network node has no available resources, and determining, in response to the resource usage not satisfying the load condition, that the network node has the available resources.
In accordance with an exemplary embodiment, receiving one or more clients of the second group of clients transferred by the another network node may comprise receiving a respective client identification of the one or more clients of the second group of clients from the another network  node, establishing the respective BGP session with the one or more clients of the second group of clients, and transmitting an acknowledgement for the client transfer to the another network node.
In accordance with an exemplary embodiment, the method may further comprise updating the client information of the network node by changing the role attribute of the network node from the slave route reflector to the master route reflector for the one or more clients transferred from the another network node, and transmitting the updated client information.
In accordance with an exemplary embodiment, the method may further comprise transmitting capability information of the network node, the capability information indicating a capability of supporting client transfer.
In accordance with an exemplary embodiment, the method may further comprise receiving capability information of another route reflector, the capability information indicating a capability of supporting client transfer.
According to a third aspect of the present disclosure, there is provided a method performed by a controller. The method comprises designating a master route reflector and at least one slave route reflector to a client, transmitting route reflector information to the client, the route reflector information indicating the master route reflector and the at least one slave route reflector, and configuring each route reflector of the master route reflector and the at least one slave route reflector with client information, the client information indicating a group of clients that the route reflector serves as a master and/or a slave route reflector and a role attribute of the route reflector for the group of clients. The master route reflector establishes a BGP session with the client, and the at least one route reflector does not establish a BGP session with the client. The client can be transferred from the master route reflector to one of the at least one slave route reflector.
According to a fourth aspect of the present disclosure, there is provided a network node which is configured to act as a master route reflector for a first group of clients. The network node may comprise one or more processors and one or more memories comprising computer program codes. The one or more memories and the computer program codes may be configured to, with the one or more processors, cause the network node at least to perform any step of the method according to the first aspect of the present disclosure.
According to a fifth aspect of the present disclosure, there is provided a network node which is configured to act as a slave route reflector for a second group of clients. The network node may comprise one or more processors and one or more memories comprising computer program codes. The one or more memories and the computer program codes may be configured to, with the one or more processors, cause the second network entity at least to perform any step of the method according to the second aspect of the present disclosure.
According to a sixth aspect of the present disclosure, there is provided a controller. The controller may comprise one or more processors and one or more memories comprising computer program codes. The one or more memories and the computer program codes may be configured to, with the one or more processors, cause the controller at least to perform any step of the method according to the third aspect of the present disclosure.
According to a seventh aspect of the present disclosure, there is provided a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the first aspect of the present disclosure.
According to an eighth aspect of the present disclosure, there is provided a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the second aspect of the present disclosure.
According to a ninth aspect of the present disclosure, there is provided a computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform any step of the method according to the third aspect of the present disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
The disclosure itself, the preferable mode of use and further objectives are best understood by reference to the following detailed description of the embodiments when read in conjunction with the accompanying drawings, in which:
Fig. 1 is a diagram illustrating a full mesh connection for the routers within the AS;
Fig. 2 is a diagram illustrating BGP connections between the RR and RR clients;
Fig. 3 is a diagram illustrating a deployment of multiple RRs within a network;
Fig. 4 is a diagram illustrating a hierarchical structure of RRs;
Fig. 5 is a flowchart illustrating a method performed by a network node which is a master RR for a first group of clients according to some embodiments of the present disclosure;
Fig. 6 is a flowchart illustrating a method performed by a network node which is a slave RR for a second group of clients according to some embodiments of the present disclosure;
Figs. 7A, 7B, and 7C are diagrams illustrating an exemplary load balancing process for RRs in which the methods as shown in Figs. 5-6 can be implemented;
Fig. 8 is a diagram showing that each client has multiple slave RRs;
Fig. 9 is a flowchart illustrating a method performed by a controller according to some embodiments of the present disclosure;
Fig. 10 is a block diagram illustrating an apparatus according to some embodiments of the present disclosure;
Fig. 11 is a block diagram illustrating a network node according to some embodiments of the present disclosure;
Fig. 12 is a diagram illustrating a client transfer workflow between the master RR and the slave RR; and
Fig. 13 is a block diagram illustrating a controller according to some embodiments of the present disclosure.
DETAILED DESCRIPTION
The embodiments of the present disclosure are described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for the purpose of enabling those skilled persons in the art to better understand and thus implement the present disclosure, rather than suggesting any limitations on the scope of the present disclosure. Reference throughout this specification to features, advantages, or similar language does not imply  that all of the features and advantages that may be realized with the present disclosure should be or are in any single embodiment of the disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the disclosure.
As used herein, the terms “first” , “second” and so forth refer to different elements. The singular forms “a” and “an” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” as used herein, specify the presence of stated features, elements, and/or components and the like, but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof. The term “based on” is to be read as “based at least in part on”. The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment” . The term “another embodiment” is to be read as “at least one other embodiment” . Other definitions, explicit and implicit, may be included below.
As described above, in the existing network with multiple RRs, since the number of the routes received per client is dynamically changing, it usually happens that some RRs are overloaded for CPU or memory consumption, while other RRs have quite a bit available resources. The overload of the RR will trigger very slow route convergence or route lost. Currently a network operator can keep monitoring the load on each RR. When an overloaded RR is found, the operator will have to manually optimize the network via e.g. re-assigning the clients among the RRs or introducing more RRs at the same level in the network. Such the optimization will definitely lead to the traffic disruption in the network and cost much operating expense.
Therefore, it is desirable to provide an improved load balancing solution to automatically and timely optimize the load on the RR without manual intervention and traffic  disruption, thereby increasing the efficient usage of the resources of the RR.
Various exemplary embodiments of the present disclosure provide improved load balancing solutions for the RR. These solutions may be applied to a network node in the AS. With the improved solutions, the automatic load balancing can be achieved and the operating expense of the network can be reduced.
It is noted that some embodiments of the present disclosure are mainly described in relation to BGP RRs. As such, the description of exemplary embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples and embodiments, and does not limit the present disclosure naturally in any way.
Fig. 5 is a flowchart illustrating a method 500 according to some embodiments of the present disclosure. The method 500 illustrated in Fig. 5 may be performed by a network node, e.g. a RR, in an autonomous system. In some embodiments, the autonomous system may comprise a plurality of RRs including the network node and a plurality of clients including at least a first group of clients. The network node is a master RR for the first group of clients.
In existing RR solutions, each client usually peers with one RR. But in some embodiments of the present disclosure, each client may be designated with a master RR and at least one slave RR in advance. For each client, the master RR works like the traditional RR, e.g. receives the routes from the client and reflects to the client the routes received from other clients. The master RR will establish a BGP session with the client. The slave RR just stays in standby for the client and will take no action.
According to the exemplary method 500 illustrated in Fig. 5, the network node monitors resource usage of the network node, as shown in block 502. In some embodiments, the resource usage may include at least one of a CPU usage and a memory usage. The CPU usage may be the CPU power consumed by the network node handling BGP sessions or the CPU power consumption in total. The memory usage may be the memory space consumed by the BGP sessions or the memory space consumption in total. In some embodiments, the network node may monitor the resource usage via an internal monitoring process.
Then the network node may determine whether the network node is overloaded or is about to be overloaded based on the resource usage. In some embodiments, the network node may determine whether the resource usage satisfies a load condition. In some embodiments, the load condition may be that the resource usage exceeds a predetermined threshold. In the case that the resource usage includes the CPU usage and/or the memory usage, the threshold may be set separately for the CPU usage and the memory usage. In some embodiments, the load condition may be that the resource exceeds the predetermined threshold for a predetermined time period.
If it is determined that the resource usage of the network node does not satisfy the load condition, which means that the network node is not overloaded or about to be overloaded, the network node will continue monitoring the resource usage.
If it is determined that the resource usage satisfies the load condition, which means that the network node is overloaded or about to be overloaded, the network node obtains available resource information of at least one slave RR associated with at least one client of the first group of clients, as shown in block 504. As described above, each client of the first group of clients is designated with the network node as the master RR and one or more slave RRs. The slave RRs for the first group of clients may be the same RR or different RRs. The network node may obtain the available resource information of a part of or all the slave RRs associated with the first group of clients.
For simplicity, in the following description with respect to the obtaining of the available resource information, one slave RR is taken as an example. Those skilled in the art will appreciate that it is applicable to multiple slave RRs.
In some embodiments, the network node may transmit a first client transfer request to the slave RR associated with the first group of clients. The first client transfer request may indicate that the client transfer is requested and requires the slave RR to provide its available resource information. In response to the first client transfer request, the network node may receive a first client transfer response from the slave RR. The first client transfer response may comprise the available resource information of the slave RR indicating the available resources for accepting an additional client. In some embodiments, the available resources may be represented by an amount of additional  clients that the slave RR can accept and/or an amount of additional routes that the salve RR can accept. In addition, the first client transfer response may further comprise an indication indicating whether the client transfer is accepted or not. Therefore, if the slave RR has the available resources, the available resource information may comprise the amount of additional clients or routes to be accepted, and the indication may indicate acceptance of the client transfer. If the slave RR has no available resource, the amount of additional clients or routes may be set to zero, and the indication may indicate rejections of the client transfer.
Alternatively, in some embodiments, the network node may transmit a second client transfer request to the slave RR associated with the first group of clients. The second client transfer request may indicate one or more clients of the first group of clients to be transferred to the slave RR. In response to the second client transfer request, the network node may receive a second transfer response from the slave RR. The second client transfer response may comprise the available resource information indicating which client (s) of the one or more clients to be transferred can be accepted by the slave RR. Further the second client transfer response may comprise an indication which indicates whether the client transfer is accepted or not. If the slave RR has the available resources to accept some of the one or more clients to be transferred, the available resource information may indicate the specific client (s) to be accepted, and the indication may indicate the acceptance of the client transfer. If the slave RR has no available resource to accept any of the one or more clients to be transferred, the available resource information may indicate no client to be accepted, and the indication may indicate the rejection of the client transfer.
In some embodiments, the network node may transmit the first or second client transfer request to the slave RRs concurrently, and thus the network node can obtain the available resource information of the slave RRs at one time for subsequent operations. Alternatively, the network node may transmit the first or second client transfer request to the slave RRs sequentially. In this case, if the indication of first or second client transfer response from a slave RR indicates the rejection of the client transfer, the network node may transmit the first or second client transfer request to the next slave RR.
Referring to Fig. 5 again, at block 506, the network node may transfer one or more  clients of the at least one client of the first group of clients to one or more slave RRs associated with the one or more clients which have available resources, based on the obtained available resource information.
In some embodiments, in the case that the available resource information comprises the amount of the additional clients and/or routes that the slave RR can accept, the network node may select, at least based on the amount of the additional clients and/or routes, one or more clients to be transferred from the first group of clients. As described above, the network node as the master RR can establish the BGP sessions with the first group of clients, and receive, process and reflect the routes among the first group of clients. Thus, the network node can obtain route statistics information of each of the first group of clients. The route statistics information of the client may indicate the amount of the routes that the client can support. Then based on the available resource information and the route statistics information of the first group of clients, the network node may select one or more clients to be transferred. Then the network node may determine one or more slave RRs associated with the selected one or more clients which have available resources to accept the selected one or more clients. In some embodiments, one slave RR may be determined for the one or more clients to be transferred. In some embodiments, more than one slave RR may be determined for more than one client. Accordingly, the network node may determine which slave RR to accept which client (s) , so that the more than one client to be transferred are distributed over the determined slave RRs. Next, the network node may initiate the client transfer by transmitting a respective client identification of the one or more clients to be transferred to the determined one or more slave RRs. In some embodiments, the client identification may be an IP address of the client. In the case that only one slave RR is determined, the network node will transmit the client identification (s) of the one or more clients to be transferred to the slave RR. In the case that more than one slave RR are determined, the network node will transmit the client identifications of the clients to be transferred to the respective slave RRs. After receiving an acknowledgement for the client transfer from the one or more slave RRs which receive the transferred one or more clients, the network node may suspend the BGP session (s) with the transferred client (s) .
Alternatively, in some embodiments, in the case that the available resource information  indicates which client (s) of the one or more clients to be transferred can be accepted by the slave RR, the network node may determine, based on the available resource information, one or more slave RRs associated with the one or more clients to be transferred which have available resources to accept the one or more clients. In some embodiments, the network node may determine the slave RR to accept the client (s) indicated in the available resource information of the slave RR. In some embodiments, one salve RR may be determined for the one or more clients to be transferred. In some embodiments, more than one slave RR may be determined for more than one client. Accordingly, the network node may determine which slave RR to accept which client (s) based on the available resource information of the more than one slave RR, so that the more than one client to be transferred are distributed over the more than one slave RR. Then the network node may initiate the client transfer by transmitting the respective client identification (e.g. the IP address) of the one or more clients to be transferred to the determined one or more slave RRs. In the case that only one slave RR is determined, the network node will transmit the client identification (s) of the one or more clients to be transferred to the slave RR.In the case that more than one slave RR are determined, the network node will transmit the client identifications of the clients to be transferred to the respective slave RRs. After receiving an acknowledgement for the client transfer from the one or more slave RRs which receive the transferred one or more clients, the network node may suspend the BGP session (s) with the transferred client (s) .
It should be noted that the network node may keep monitoring the resource usage and repeat the operations as described above in  blocks  504 and 506 if the resource usage satisfies the loading condition.
After the client transfer from the network node is completed, the network node becomes the slave RR for the transferred one or more clients. The network node may change its role from the master RR to the slave RR for the transferred client (s) , e.g. after receiving the acknowledgement for the client transfer. In some embodiments, the network node may be configured with client information. The client information may be defined to indicate a group of clients that a RR serves as a master RR and/or a slave RR and a role attribute of the RR for the group of clients. Initially the client information of the network node comprises the client identifications of the first group of clients, and the role attribute for each client of the first group of clients is set to “Master” . The client information of the  network node may be configured by a controller initially and may be exchanged with other RR (s) in the AS network so that the network node can know the slave RR (s) for the first group of clients. After the client transferring, the client information is updated by changing the role attribute (s) for the transferred one or more clients of the first group of clients from “Master” to “Slave” . Further, the network node may notify other RR (s) in the autonomous system of the change of its role. In some embodiments, the network node may transmit the updated client information to other RR (s) . In some embodiments, the network node may transmit the changed role attribute (s) and corresponding client identifications as update information of the client information. The description with respect to the operations of the network node as the slave RR will be provided later with reference to Fig. 6.
Additionally, in some embodiments, the network node may receive the client information of another RR. The client information of the another RR may comprise a group of clients that the another RR serves as a slave RR and/or a master and the respective role attribute for each client of the group of clients indicating “Master” or “Slave” . According to the client information of the another RR, the network node can know which client (s) has another RR as the slave router and which client (s) has another RR as the master RR. If the another RR is the slave RR for at least one client of the first group of clients, the network node can negotiate for the client transfer with the another RR. Then the network node may store the client information of the another RR.
It will be appreciated that the network node or the RR may not transmit its client information if the network node or the RR is the master RR only. When the network node or the RR becomes a slave RR for at least one client due to the client transfer, it needs to transmit the client information with the change of the role attribute.
In some embodiments, when the client information of the another RR is updated, the network node may receive the update information for the client information of the another RR. The update information may be either the whole updated client information or only the changed role attribute (s) and corresponding client identification (s) .
In some embodiments, a Notification message may be used for the client transfer, e.g. for transmitting the client information, the first and second client transfer requests, the first and second clients transfer responses, the client identification (s) of the client (s) to be transferred, and the  acknowledge for the client transfer. In the BGP protocol, the Notification message has been defined with error codes 0-7. New code/subcode/data needs to be defined for the client transfer as follows. Code                Subcode                          Data
Figure PCTCN2020086463-appb-000001
In some embodiments, a new type of message may be defined for the client transfer.
Additionally, in some embodiments, the network node may be configured with capability information. The capability information may indicate a RR’s capability of supporting client transfer. With the capability information, the RR may know if a peer RR supports the client transfer. In some embodiments, the network node may transmit and receive the capability information to and from another RR. The capability information may be transmitted or received in a BGP protocol message, e.g. Open message, as a new parameter. This new parameter may be defined as Optional Parameter, and thus there is no impact to legacy RR functions if a RR does not have such capability.
Although in the embodiments described above with reference to Fig. 5, the network node is the master RR for the first group of clients, those skilled in the art will appreciate that the network node may also act as the slave RR for another group of clients simultaneously.
Fig. 6 is a flowchart illustrating a method 600 according to some embodiments of the present disclosure. The method 600 illustrated in Fig. 6 may be performed by a network node, e.g. a RR, in the autonomous system. The network node is a slave RR for a second group of clients in the autonomous system.
As described above, in addition to the network node as the slave RR, each of the second group of clients may have its own master RR and has established a BGP session with the master RR.  The network node stays in standby for the second group of clients.
According to the exemplary method 600 illustrated in Fig. 6, in response to receiving a client transfer request from another network node (hereinafter referred to as “second network node” ) which is the master RR of at least one client of the second group of clients, the network node provides the available resource information to the second network node, as shown in block 602.
In some embodiments, the client transfer request may be the first client transfer request. As described above, the first client transfer request may indicate that the client transfer is requested and requires the slave RR to provide its available resource information. Upon receipt of the first client transfer request from the second network node, the network node may determine whether there are available resources in the network node. Then the network node may transmit the first client transfer response to the second network node. The first transfer response may comprise the available resource information indicating the available resources for accepting an additional client. In some embodiments, the available resources may be represented by the amount of additional clients and/or routes that the network node can accept. Further, the first client transfer response may comprise the indication indicating whether the client transfer is accepted or not, i.e. acceptance or rejection of the client transfer.
In some embodiments, the client transfer request may be the second client transfer request which indicates one or more clients of the second group of clients to be transferred. Upon receipt of the second client transfer request from the second network node, the network node may determine whether there are available resources in the network node. If it is determined that there are the available resources, the network node may determine which client (s) of the one or more clients indicated in the second client transfer request can be accepted. The determination of the client (s) to be accepted may be based on the available resources and the amount of routes that the client can support. Then the network node may transmit the second client transfer response to the second network. As described above, the second client transfer response may comprise the available resource information indicating which client (s) of the one or more clients to be transferred can be accepted. Further, the second client transfer response may also comprise the indication indicating whether the client transfer is accepted or not. If it is determined that there is no available resource in the network  node, the network node may transmit the second client transfer response indicating none of the one or more clients to be transferred can be accepted and the rejection of the client transfer.
In some embodiments, the determination of the available resources may be based on the resource usage of the network node. The resource usage may comprise the CPU usage and/or the memory usage. The CPU usage may be represented by the CPU power consumed by the BGP sessions in the network node or the CPU power consumption in total, and the memory usage may be represented by the memory space consumed by the BGP sessions or the memory space consumption in total. The network node may monitor the CPU usage and/or the memory usage to obtain the resource usage. Then the network node may determine whether the resource usage satisfies the load condition. As described above, the load condition may be that the resource usage exceeds a predetermined threshold or that the resource usage exceeds the predetermined threshold for a predetermined time period. The threshold may comprise a first threshold for the CPU usage and a second threshold for the memory usage. If it is determined that the resource usage satisfies the load condition, the network node may determine that it has no available resource. If it is determined that the resource usage does not satisfy the load condition, the network node may determine that it has the available resources.
Referring to Fig. 6 again, at block 604, in the event that the available resource information indicates that the network node has the available resources, the network node may receive one or more clients of the second group of clients transferred by the second network node. In some embodiment, the network node may receive the respective client identification of the one or more clients from the second network node. The client identification may be an IP address of the client. The network node may then establish the respective BGP session with the one or more clients and transmit an acknowledgement for the client transfer to the second network node. The acknowledgement may be transmitted per client identification or may be transmitted for an aggregation of the established BGP sessions. After the acknowledgement is transmitted, the network node becomes the master RR for the transferred client (s) .
In some embodiments, the network node may be configured with the client information. As described above, the client information may be defined to indicate a group of clients that a RR  serves as a master RR and/or a slave RR and a role attribute of the RR for the group of clients. Initially, the client information of the network node comprises the client identifications of the second group of clients, and the role attribute for each client of the second group of clients is set to “Slave” . After the client transferring, the client information is updated by changing the role attribute (s) for the transferred one or more clients of the second group of clients from “Slave” to “Master” . Further, the network node may transmit the updated client information. In some embodiments, the updated client information may include the changed role attribute (s) and corresponding client identifications. The description with respect to the operations of the network node as the master RR has been provided above with reference to Fig. 5, and thus is omitted here.
Additionally, in some embodiments, the network node may be configured with the capability information. As described above, the capability information may indicate the capability of supporting client transfer. Further, the network node may transmit and receive the capability information to and from another RR. In some embodiments, the capability information may be transmitted or received in a BGP protocol message, e.g. Open message, as a new parameter.
Although in the embodiments described above with reference to Fig. 6, the network node is the slave RR for the second group of clients, those skilled in the art will appreciate that the network node may also act as the master RR for another group of clients simultaneously.
It can be therefore seen from the above description that, with the methods of the illustrated embodiments of the present disclosure, the load balancing for the RRs can be performed automatically and in real time without disruption of live traffic. Moreover, the resources of the RRs can be efficiently used. The RR having the capability of supporting client transfer can seamlessly work with the RR having no such capability, and there is no impact on the client. In addition, the methods of the embodiments described above is applicable to not only a dedicated-hardware based router in a traditional network, e.g. mobile backhaul network, but also a virtual software based router, e.g. running on a virtual machine (VM) in a data center network.
Figs. 7A, 7B and 7C illustrate an exemplary load balancing process for RRs in which the methods as shown in Figs. 5-6 can be implemented. In this example, there are two RRs, RR1 and RR2 and eight clients. As shown in Fig. 7A, RR1 acts as the master RR for  clients  1, 2, 3 and 4, and  acts as the slave RR for clients 5, 6, 7 and 8. RR2 acts as the master RR for clients 5, 6, 7 and 8, and acts as the slave RR for  clients  1, 2, 3 and 4. Thus each  client  1, 2, 3, and 4 has RR1 as the master RR and RR2 has the slave RR, while each client 5, 6, 7, and 8 has RR2 as the master RR and RR1 as the slave RR. Moreover, RR1 establishes normal BGP sessions with  clients  1, 2, 3 and 4 respectively, and suspends for clients 5, 6, 7 and 8. RR2 establishes normal BGP sessions with clients 5, 6, 7 and 8 respectively, and suspends for  clients  1, 2, 3, and 4. In addition, there is a BGP session between RR1 and RR2. In the figures, solid line represents the master RR, and the dashed line represents the slave RR.
For each RR, the role attribute is added to existing RR configuration to specify the role of the RR for a specific client. Following is an example configuration for RR1, and RR1 acts as the master RR for client 1 and the slave RR for client 5:
RR1 (config-bgp) #neighbor x. x. x. x (client1-ip-address)
RR1 (config-bgp-neighbor) #address-family ipv4 unicast
RR1 (config-bgp-peer-af) #route-reflector-client master
RR1 (config-bgp) #neighbor y. y. y. y (client5-ip-address)
RR1 (config-bgp-neighbor) #address-family ipv4 unicast
RR1 (config-bgp-peer-af) #route-reflector-client slave
For each client, there is no change compared with existing client configuration. The client can set up normal BGP sessions with both the master RR and the slave RR, but is unaware of the role attribute. Following is an example configuration for client 1 which has RR1 as the master RR and RR2 as the slave RR:
Client1 (config-bgp) #neighbor m. m. m. m (RR1-ip-address)
Client1 (config-bgp-neighbor) #address-family ipv4 unicast
Client1 (config-bgp) #neighbor n. n. n. n (RR2-ip-address)
Client1 (config-bgp-neighbor) #address-family ipv4 unicast
Each of RR1 and RR2 monitors its resource usage, and determines whether the resource usage satisfies the load condition to determine whether it is overloaded or is about to be overloaded. Assume in this example that RR1 is overloaded, RR1 will negotiate with RR2 to transfer some clients from RR1 to RR2, as shown in Fig. 7B. RR1 may transmit the client transfer request (e.g. the first or second client transfer request) to RR2 to obtain the available resource information of RR2. In response to receiving the client transfer request, RR2 may determine its available resources and  respond with the client transfer response. When the available resource information of RR2 in the client transfer response indicates that RR2 has the available resources, RR1 will select one or more clients to be transferred, for example, clients 3 and 4, based on the available resource information. Then RR1 may transmit the client identifications of clients 3 and 4, e.g. the IP address. Upon receipt of the client identifications of clients 3 and 4, RR2 can establish the BGP sessions with clients 3 and 4, and transmit the acknowledgement to RR1. After receiving the acknowledgement, RR1 suspends the BGP sessions with clients 3 and 4. After the client transfer is completed, RR1 becomes the slave RR for clients 3 and 4, and RR2 becomes the master RR for clients 3 and 4, as shown in Fig. 7C. Table 1 shows the routes received on RR1 and sent from RR1 before and after the client transfer.
Table 1
  Routes received on RR1 Routes sent from RR1
Before client transfer From clients 1/2/3/4 and RR2 To clients 1/2/3/4 and RR2
After client transfer From clients 1/2 and RR2 To clients 1/2 and RR2
After clients 3 and 4 are transferred from RR1 to RR2, RR1 will still receive the routes of clients 3 and 4 reflected by RR2, but RR2 will just reflect the best path routes instead of original routes. Thus, the amount of the routes received by RR1 can be reduced. On the other hand, the amount of the routes sent from RR1 can also be reduced and the load on RR1 can be dramatically eased.
In the example as shown in Figs. 7A, 7B and 7C, for the sake of simplicity,  clients  1, 2, 3 and 4 each has only one slave RR, i.e. RR2. But those skilled in the art will appreciate that each client may have more than one slave RR, as shown in Fig. 8. In Fig. 8, in addition to RR2,  clients  1, 2, 3 and 4 each has another slave RR, i.e. RR3. The BGP sessions are established among RR1, RR2 and RR3. The load balancing process for the RRs in Fig. 8 is similar to that for the RRs in Fig. 7.
Fig. 9 is a flowchart illustrating a method 900 according to some embodiments of the present disclosure. The method 900 as shown in Fig. 9 may be performed by a controller or a controlling node.
According to the exemplary method 900 illustrated in Fig. 9, the controller designates a master RR and at least one slave RR to a client, as shown in block 902. The designation may be based on a network design. The master RR can establish the BGP session with the client, and the slave RR  will not establish the BGP session with the client.
Then the controller may transmit RR information to the client, as shown in block 904. The RR information may indicate the master RR and the at least one slave RR to the client. In some embodiments, the RR information may comprise an identification of the RR, e.g. IP address. After receiving the RR information, the client can know its serving RRs. The client can establish the BGP session with the master RR and the slave RR (s) , but only the BGP session with the master RR can be established successfully. As the RR information does not indicate the role attribute of the RR, the client will not know which is the master RR and which is the slave RR. Thus, the existing configuration for the client would not change.
At block 906, the controller configures each RR of the master RR and the at least one slave RR with the client information. The client information may indicate a group of clients that the RR serves as a master RR and/or a slave RR and the role attribute of the RR for the group of clients. In some embodiments, the client information may comprise the client identification of each of the group of clients and the respective role attribute indicating “Master” or “Slave” for the client. The role attribute of the RR for the client can be changed after the client is transferred from the master RR to the slave RR.
It can be seen therefore from the above description that the method performed by the controller of the embodiments is applicable to the initial configuration of the RRs and the clients.
The various blocks shown in Figs. 5-6 and 9 may be viewed as method steps, and/or as operations that result from operation of computer program code, and/or as a plurality of coupled logic circuit elements constructed to carry out the associated function (s) . The schematic flow chart diagrams described above are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of specific embodiments of the presented methods. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated methods. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.
Fig. 10 is a block diagram illustrating an apparatus 1000 according to various embodiments of the present disclosure. As shown in Fig. 10, the apparatus 1000 may comprise one  or more processors such as processor 1001 and one or more memories such as memory 1002 storing computer program codes 1003. The memory 1102 may be non-transitory machine/processor/computer readable storage medium. In accordance with some exemplary embodiments, the apparatus 1000 may be implemented as an integrated circuit chip or module that can be plugged or installed into the network node as described with respect to Fig. 5 or Fig. 6, or the controller as described with respect to Fig. 9.
In some implementations, the one or more memories 1002 and the computer program codes 1003 may be configured to, with the one or more processors 1001, cause the apparatus 1000 at least to perform any operation of the method as described in connection with Fig. 5 or Fig. 6. In such embodiments, the apparatus 1000 may be implemented as at least part of or communicatively coupled to the network node as described above. As a particular example, the apparatus 1000 may be implemented as the network node.
In other implementations, the one or more memories 1002 and the computer program codes 1003 may be configured to, with the one or more processors 1001, cause the apparatus 1000 at least to perform any operation of the method as described in connection with Fig. 9. In such embodiments, the apparatus 1000 may be implemented as at least part of or communicatively coupled to the controller as described above. As a particular example, the apparatus 1000 may be implemented as the controller.
Alternatively or additionally, the one or more memories 1002 and the computer program codes 1003 may be configured to, with the one or more processors 1001, cause the apparatus 1000 at least to perform more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.
Fig. 11 is a block diagram illustrating a network node 1100 according to some embodiments of the present disclosure. As shown in Fig. 11, the network node 1100 may comprise a monitor unit 1101, a negotiation unit 1102, and a client transfer unit 1103. In an exemplary embodiment, the network node 1100 may be implemented as a master RR. The monitor unit 1101 may be configured to carry out the operation in block 502. The negotiation unit 1102 may be configured to carry out the operation in block 504. The client transfer unit 1103 may be configured  to carry out the operation in block 506. Further the network node 1100 may comprise a route handling unit 1104 which is configured to receive routes from a client, process the routes and reflect the routes to other clients. Alternatively or additionally, in an exemplary embodiment, the network node 1100 may be implemented as a slave RR. The negotiation unit 1102 may be configured to cooperate with the monitor unit 1101 to carry out the operation in block 602. The client transfer unit 1103 may be configured to carry out the operation in block 604. Optionally, the monitor unit 1101, the negotiation unit 1102 and/or the client transfer unit 1103 may be configured to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.
Fig. 12 illustrates the client transfer workflow between the master RR, RR1, and the slave RR, RR2. The structure of the master RR and the structure of the slave RR are as shown in Fig. 11. If the monitor unit of RR1 determines that RR1 is overloaded, the negotiation unit of RR1 transmits a client transfer request to the negotiation unit of RR2. Then the monitor unit of RR2 checks if there are available resources to accept the additional client (s) . If there is no available resource, the negotiation unit of RR2 responds with a client transfer response indicating the rejection of the client transfer. Then the negotiation unit of RR1 terminates the client transfer or requests for the client transfer from another slave RR. If there are the available resources, the negotiation unit of RR2 responds with a client transfer response indicating the acceptance of the client transfer and the amount of the clients and/or routes that can be accepted. Then the client transfer unit of RR1 selects the client (s) to be transferred and transmits the client identification (s) of the client (s) to be transferred to the client transfer unit of RR2. The client transfer unit of RR2 establishes the BGP session (s) with the client (s) to be transferred, and returns acknowledgement to the client transfer unit of RR1. Then the client transfer unit of RR1 suspends the BGP session (s) with the transferred client (s) .
Fig. 13 is a block diagram illustrating a controller 1300 according to some embodiments of the present disclosure. As shown in Fig. 13, the controller 1300 may comprise a designating unit 1301, a transmitting unit 1302, and a configuring unit 1303. The designating unit 1301 may be configured to carry out the operation in block 902. The transmitting unit 1302 may be configured to carry out the operation in block 904. The configuring unit 1303 may be configured to carry out the  operation in block 906. Optionally, the designating unit 1301, the transmitting unit 1302 and/or the configuring unit 1303 may be configured to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.
In general, the various exemplary embodiments may be implemented in hardware or special purpose chips, circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto. While various aspects of the exemplary embodiments of this disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
As such, it should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of this disclosure may be realized in an apparatus that is embodied as an integrated circuit, where the integrated circuit may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this disclosure.
It should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, random access memory (RAM) , etc. As will be appreciated by one of skill in the art, the function of the program modules may be combined  or distributed as desired in various embodiments. In addition, the function may be embodied in whole or partly in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA) , and the like.
The present disclosure includes any novel feature or combination of features disclosed herein either explicitly or any generalization thereof. Various modifications and adaptations to the foregoing exemplary embodiments of this disclosure may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of this disclosure.

Claims (42)

  1. A method (500) performed by a network node which is a master route reflector for a first group of clients, the method comprising:
    monitoring (502) resource usage of the network node;
    obtaining (504) , in response to the resource usage satisfying a load condition, available resource information of at least one slave route reflector associated with at least one client of the first group of clients; and
    transferring (506) , based on the available resource information, one or more clients of the first group of clients to one or more slave route reflectors associated with the one or more clients which have available resources.
  2. The method according to claim 1, wherein obtaining available resource information of at least one slave route reflector associated with at least one client of the first group of clients comprises:
    transmitting a first client transfer request to the at least one slave route reflector associated with the at least one client of the first group of clients; and
    receiving a first client transfer response comprising the available resource information indicating available resources for accepting an additional client.
  3. The method according to claim 2, wherein the first client transfer response further comprises an indication indicating whether client transfer is accepted or not.
  4. The method according to any one of claims 1 to 3, wherein the available resource information comprises at least one of an amount of additional clients that the slave route reflector can accept and an amount of additional routes that the slave route reflector can accept.
  5. The method according to any one of claims 2 to 4, wherein transferring one or more clients of  the first group of clients to one or more slave route reflectors associated with the one or more clients which have available resources comprises:
    selecting, from the first group of clients, one or more clients to be transferred at least based on the available resource information;
    determining one or more slave route reflectors associated with the selected one or more clients which have available resources to accept the selected one or more clients;
    transmitting a respective client identification of the selected one or more clients to the determined one or more slave route reflectors; and
    suspending, in response to receiving an acknowledgement for the client transfer from the determined one or more slave route reflectors, the respective Border Gateway Protocol, BGP, session with the selected one or more clients.
  6. The method according to claim 5, wherein the one or more clients to be transferred is selected further based on an amount of routes that the client can support.
  7. The method according to claim 1, wherein obtaining available resource information of at least one slave route reflector associated with at least one client of the first group of clients comprises:
    transmitting a second client transfer request to the at least one slave route reflector associated with the at least one client of the first group of clients, the second client transfer request indicating one or more clients of the first group of clients to be transferred; and
    receiving a second client transfer response comprising the available resource information indicating which of the one or more clients to be transferred can be accepted.
  8. The method according to claim 7, wherein the second client transfer response further comprises an indication indicating whether client transfer is accepted or not.
  9. The method according to claim 7 or 8, wherein transferring one or more clients of the first group of clients to one or more slave route reflectors associated with the one or more clients which have  available resources comprises:
    determining, based on the available resource information, one or more slave route reflectors associated with the one or more clients which have available resources to accept the one or more clients to be transferred;
    transmitting a respective client identification of the one or more clients to the determined one or more slave route reflectors; and
    suspending, in response to receiving an acknowledgement for the client transfer from the determined one or more slave route reflectors, the respective BGP session with the one or more clients.
  10. The method according to any one of claims 1 to 9, wherein the resource usage comprises at least one of a CPU usage and a memory usage.
  11. The method according to any one of claims 1 to 10, wherein the load condition is one of:
    that the resource usage exceeds a threshold, and
    that the resource usage exceeds a threshold for a predetermined time period.
  12. The method according to any one of claims 1 to 11, further comprising:
    changing, after the client transferring, a role of the network node from the master route reflector to the slave route reflector for the transferred one or more clients.
  13. The method according to claim 12, further comprising:
    notifying the change of the role of the network node.
  14. The method according to any one of claims 1 to 11, further comprising:
    transmitting capability information of the network node, the capability information indicating a capability of supporting client transfer.
  15. The method according to any one of claims 1 to 14, further comprising:
    receiving capability information of another route reflector, the capability information indicating a capability of supporting client transfer.
  16. The method according to any one of claims 1 to 15, further comprising:
    receiving client information of another route reflector, the client information indicating a group of clients that the another route reflector serves as a slave route reflector and a role attribute of the another router reflector for the group of clients; and
    storing the client information in association with the another route reflector.
  17. The method according to claim 16, wherein the client information of the another route reflector further indicates another group of clients that the another route reflector serves as a master route reflector and the role attribute for the another group of clients.
  18. The method according to claim 16 or 17, further comprising:
    receiving update information for the client information of the another route reflector.
  19. A method (600) performed by a network node which is a slave route reflector for a second group of clients, comprising:
    providing (602) , in response to receiving a client transfer request from another network node which is a master route reflector of at least one client of the second group of clients, available resource information to the another network node; and
    receiving (604) , in response to the available resource information indicating that the network node has available resources, one or more clients of the second group of clients transferred by the another network node.
  20. The method according to claim 19, further comprising:
    transmitting client information of the network node, the client information indicating the second group of clients and a role attribute of the network node for the second group of clients.
  21. The method according to claim 20, wherein the client information of the network node further indicates another group of clients that the network node serves as a master route reflector and the role attribute for the another group of clients.
  22. The method according to any one of claims 19 to 21, wherein the client transfer request is a first client transfer request, and
    wherein providing available resource information comprises:
    receiving the first client transfer request from the another network node;
    determining whether there are available resources in the network node; and
    transmitting a first client transfer response comprising the available resource information indicating the available resources for accepting an additional client.
  23. The method according to claim 22, wherein the first client transfer response further comprises an indication indicating whether client transfer is accepted or not.
  24. The method according to claim 22 or 23, wherein the available resource information comprises at least one of an amount of additional clients that the network node can accept and an amount of additional routes that the network node can accept.
  25. The method according to any one of claims 19 to 21, wherein the client transfer request is a second client transfer request indicating one or more clients of the second group of clients to be transferred, and
    wherein providing available resource information comprises:
    receiving the second client transfer request from the another network node;
    determining whether there are available resources in the network node;
    determining, in response to the network node having the available resources, which of the one or more clients to be transferred can be accepted; and
    transmitting a second client transfer response comprising the available resource information indicating which of the one or more clients to be transferred can be accepted.
  26. The method according to claim 25, wherein the second client transfer response further comprises an indication indicating whether client transfer is accepted or not.
  27. The method according to claim 22 or 25, wherein determining whether there are available resources in the network node comprises:
    obtaining resource usage of the network node;
    determining, in response to the resource usage satisfying a load condition, that the network node has no available resources; and
    determining, in response to the resource usage not satisfying the load condition, that the network node has the available resources.
  28. The method according to claim 27, wherein the resource usage comprises at least one of a CPU usage and a memory usage.
  29. The method according to claim 27 or 28, wherein the load condition is one of:
    that the resource usage exceeds a threshold; and
    that the resource usage exceeds a threshold for a predetermined time period.
  30. The method according to any one of claims 19 to 29, wherein receiving one or more clients of the second group of clients transferred by the another network node comprises:
    receiving a respective client identification of the one or more clients of the second group of clients from the another network node;
    establishing the respective BGP session with the one or more clients of the second group of clients; and
    transmitting an acknowledgement for the client transfer to the another network node.
  31. The method according to claim 30, further comprising:
    updating the client information of the network node by changing the role attribute of the network node from the slave route reflector to the master route reflector for the one or more clients transferred from the another network node; and
    transmitting the updated client information.
  32. The method according to any one of claims 19 to 31, further comprising:
    transmitting capability information of the network node, the capability information indicating a capability of supporting client transfer.
  33. The method according to any one of claims 19 to 32, further comprising:
    receiving capability information of another route reflector, the capability information indicating a capability of supporting client transfer.
  34. A method (900) performed by a controller comprising:
    designating (902) a master route reflector and at least one slave route reflector to a client;
    transmitting (904) route reflector information to the client, the route reflector information indicating the master route reflector and the at least one slave route reflector; and
    configuring (906) each route reflector of the master route reflector and the at least one slave route reflector with client information, the client information indicating a group of clients that the route reflector serves as a master and/or a slave route reflector and a role attribute of the route reflector for the group of clients;
    wherein the master route reflector establishes a BGP session with the client, and the at least one route reflector does not establish a BGP session with the client; and
    wherein the client can be transferred from the master route reflector to one of the at least one slave route reflector.
  35. A network node (1000) which is configured to act as a master route reflector for a first group of clients, the network node (1000) comprising:
    one or more processors (1001) ; and
    one or more memories (1002) comprising computer program codes (1003) ,
    the one or more memories (1002) and the computer program codes (1003) configured to, with the one or more processors (1001) , cause the network node (1000) to:
    monitor resource usage of the network node (1000) ;
    obtain, in response to the resource usage satisfying a load condition, available resource information of at least one slave route reflector associated with at least one client of the first group of clients; and
    transfer, based on the available resource information, one or more clients of the first group of clients to one or more slave route reflectors associated with the one or more clients which have available resources.
  36. The network node (1000) according to claim 35, wherein the one or more memories (1002) and the computer program codes (1003) are further configured to, with the one or more processors (1001) , cause the network node (1000) to perform the method according to any one of claims 2-18.
  37. A network node (1000) which is configured to act as a slave route reflector for a second group of clients, the network node (1000) comprising:
    one or more processors (1001) ; and
    one or more memories (1002) comprising computer program codes (1003) ,
    the one or more memories (1002) and the computer program codes (1003) configured to, with the one or more processors (1001) , cause the network node (1000) to:
    provide, in response to receiving a client transfer request from another network node which is a master route reflector of at least one client of the second group of clients, available resource information to the another network node; and
    receive, in response to the available resource information indicating that the network node (1000)  has available resources, one or more clients of the second group of clients transferred by the another network node.
  38. The network node (1000) according to claim 37, wherein the one or more memories (1002) and the computer program codes (1003) are further configured to, with the one or more processors (1001) , cause the network node (1000) to perform the method according to any one of claims 20-33.
  39. A computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform the method according to any one of claims 1-18.
  40. A computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform the method according to any one of claims 19-33.
  41. A controller (1000) comprising:
    one or more processors (1001) ; and
    one or more memories (1002) comprising computer program codes (1003) ,
    the one or more memories (1002) and the computer program codes (1003) configured to, with the one or more processors (1001) , cause the controller (1000) to:
    designating a master route reflector and at least one slave route reflector to a client;
    transmitting route reflector information to the client, the route reflector information indicating the master route reflector and the at least one slave route reflector; and
    configuring each route reflector of the master route reflector and the at least one slave route reflector with client information, the client information indicating a group of clients that the route reflector serves as a master and/or a slave route reflector and a role attribute of the route reflector for the group of clients;
    wherein the master route reflector establishes a BGP session with the client, and the at least one  route reflector does not establish a BGP session with the client; and
    wherein the client can be transferred from the master route reflector to one of the at least one slave route reflector.
  42. A computer-readable medium having computer program codes embodied thereon which, when executed on a computer, cause the computer to perform the method according to claim 34.
PCT/CN2020/086463 2020-04-23 2020-04-23 Method and apparatus for load balancing for route reflector WO2021212424A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/086463 WO2021212424A1 (en) 2020-04-23 2020-04-23 Method and apparatus for load balancing for route reflector

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/086463 WO2021212424A1 (en) 2020-04-23 2020-04-23 Method and apparatus for load balancing for route reflector

Publications (1)

Publication Number Publication Date
WO2021212424A1 true WO2021212424A1 (en) 2021-10-28

Family

ID=78270815

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/086463 WO2021212424A1 (en) 2020-04-23 2020-04-23 Method and apparatus for load balancing for route reflector

Country Status (1)

Country Link
WO (1) WO2021212424A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101500271A (en) * 2008-02-01 2009-08-05 华为技术有限公司 Method and equipment for implementing core network equipment load balance
US20100115604A1 (en) * 2008-10-31 2010-05-06 Alexandre Gerber Methods and apparatus to dynamically control access from virtual private networks to network-based shared resources
CN106411727A (en) * 2016-09-22 2017-02-15 杭州华三通信技术有限公司 Message processing method and device and autonomous system
CN106911549A (en) * 2017-02-28 2017-06-30 新华三技术有限公司 A kind of data message processing method and device

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101500271A (en) * 2008-02-01 2009-08-05 华为技术有限公司 Method and equipment for implementing core network equipment load balance
US20100115604A1 (en) * 2008-10-31 2010-05-06 Alexandre Gerber Methods and apparatus to dynamically control access from virtual private networks to network-based shared resources
CN106411727A (en) * 2016-09-22 2017-02-15 杭州华三通信技术有限公司 Message processing method and device and autonomous system
CN106911549A (en) * 2017-02-28 2017-06-30 新华三技术有限公司 A kind of data message processing method and device

Similar Documents

Publication Publication Date Title
US10917351B2 (en) Reliable load-balancer using segment routing and real-time application monitoring
US20200366562A1 (en) Method and system of connecting to a multipath hub in a cluster
JP5113684B2 (en) Access gateway device control method and communication system
US10904335B2 (en) Reducing distributed storage operation latency using segment routing techniques
US9548965B2 (en) Proxy methods for suppressing broadcast traffic in a network
US10511542B2 (en) Multi-interface power-aware networking
JP5978313B2 (en) Method and apparatus for energy efficient distributed elastic load balancing
US20040260745A1 (en) Load balancer performance using affinity modification
US20110029659A1 (en) Method and System for Network Proxy Services for Energy Efficient Networking
JP2003281008A (en) Device, method and program for distributing server computer load, and server computer system
CN103368840A (en) Reduced traffic loss for border gateway protocol session in multi-homed network connection
EP3410752B1 (en) Mobility management method, apparatus and system
WO2019184455A1 (en) Information transmission method and apparatus, device and storage medium
US20140047260A1 (en) Network management system, network management computer and network management method
WO2020214469A1 (en) Efficient message transmission and loop avoidance in an rpl network
CN111371866A (en) Method and device for processing service request
WO2021212424A1 (en) Method and apparatus for load balancing for route reflector
WO2022083281A1 (en) Message transmission method and system, electronic device, and storage medium
CN107736002B (en) Proximity-based service information distributed caching method and device and communication network
US9746899B2 (en) At least one message to announce entry into relatively lower power state
WO2019242459A1 (en) Node switching method, network node, network system, and storage medium
US12015521B2 (en) Using an application programming interface (API) gateway to manage communications in a distributed system
US20230336631A1 (en) Method, apparatus, and system for capability negotiation, and storage medium
US11928376B2 (en) Recommended print job delivery paths
EP4195621A1 (en) Message forwarding method, apparatus and system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20932488

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20932488

Country of ref document: EP

Kind code of ref document: A1