CN101166176B - Method for Realizing Dynamic Load Balancing in Session Initiation Protocol Distributed System - Google Patents

Abstract

A method for implementing dynamic load balancing in a session initiation protocol distributed system. A SIP entity initiates a SIP request message, and the ILBU receives the SIP message and sends the message to a certain PLBU processing node according to the message address or port number; The SIP message is decoded, and it is judged whether it is an internal or external request or a response, and different processing is performed respectively. By adopting the method of the invention, the defect of the existing fixed HASH algorithm can be improved, and at the same time, the stateless characteristic of the distribution process itself can be maintained. Whether the number of nodes in the system increases or decreases or the distribution strategy of the system is adjusted will not affect the message processing of the session, thus greatly improving the reliability and scalability of the system.

Description

Method for Realizing Dynamic Load Balancing in Session Initiation Protocol Distributed System

technical field

The invention relates to load balancing in a SIP (SESSION INITIATION PROTOCOL, session initiation protocol) distributed system.

Background technique

SIP is a kind of multimedia communication control protocol, which has been widely used in networks such as softswitch and IMS (IP MULTIMEDIASUBSYSTEM, IP Multimedia Subsystem). SIP adopts text encoding method and uses tracking analysis, but at the same time, it also causes the message volume to be too large, which brings a heavy burden to the SIP server at the core.

Large-scale systems generally use distributed system processing. For servers without call status, the load balancing is relatively simple, but for SIP servers with call status, such as SoftSwitch and CSCF (CALL SESSION CONTROL FUNCTION, call session control function), the load Equilibrium is a complex issue. Before analyzing SIP distributed processing, we can divide SIP distributed processing nodes into three logical entities according to the function of distributed load balancing: 1) ILBU (ILBU: IP Load-Balance Unit, IP Load-Balance Unit), 2) PLBU (PROTOCOL LOAD BALANCE UNIT, protocol load balancing unit), 3) PPU (PROTOCOL PROCESS UNIT, protocol processing unit).

Generally speaking, there are three types of distributed schemes:

One is user-based distributed processing, that is, user IDs are used as keywords for load balancing. Its disadvantage is that the system load balancing components must store user status. When the system capacity is large, the entrance load balancing components often Multiple nodes are required, and the overhead of synchronizing state among multiple nodes is too large.

The second is to use different IP addresses or transport layer ports to identify different processing node numbers. For example, port 5060 is used as the well-known port of the SIP node, and each node is assigned a unique port. When the SIP message passes through the node, according to The internal complex balance algorithm allocates a node for it, and then the node performs the Record-Route operation to record the port number of the node, and the other network element will send the request according to the new port after receiving 200 OK. The disadvantage of this method is that when using the connection During transmission, the upstream SIP network element must re-establish the connection with the local end, which increases the overhead of the bottom layer.

The third is to adopt the necessary header fields or parameters in each SIP message as the keyword (such as Call-ID) of the load balancing HASH. Its implementation is as shown in Figure 2, including the following steps:

Step 201, the external SIP entity initiates an INVITE request, and the ILBU receives the request;

Step 202, the ILBU obtains a node number of a PLBU according to the source, destination IP address or port number and the implemented load balancing strategy;

Step 203, ILBU sends the request to the PLBU node;

Step 204, PLBU carries out HASH processing according to the calling identification (Call-ID) of SIP request, in conjunction with this

to obtain the available PPU node number.

Step 205, the PLBU sends the message to the PPU;

Step 206, the PPU forwards the message after processing the SIP INVITE request message;

Steps 207-208, the called user responds to the request, and the response message arrives at the PLBU via the ILBU;

Step 209, the PLBU obtains the PPU node number according to the call identification HASH;

Step 210-211, the response message is forwarded to the calling user through PPU and ILBU;

Steps 212-213, the user initiates a message in the dialogue and reaches the PLBU via the ILBU;

Step 214, PLBU carries out HASH according to call identification number, obtains PPU node number;

Step 215, PLBU forwards the message to PPU.

The above steps describe a basic process of using a fixed HASH algorithm in the SIP distributed system. All SIP messages must first go through ILBU->PLBU for message pre-decoding to obtain the constant components of each call (such as Call-ID) Perform HASH modulus to obtain the node number that should be processed. The modulus is the total number of nodes in the system. In this way, the load balancing component can realize stateless work, and the system throughput and reliability are greatly improved. At the same time, the disadvantages of this solution are also obvious. Since the call processing is stateful, the same call must be processed in one node. When a node is added to the system or a node is reduced due to a failure, the HASH modulus changes, and the established call Subsequent SIP messages cannot be guaranteed to be distributed to the same node for processing, nor can dynamic load balancing be achieved. Such as a call Call-ID=C1, HASH(C1)=18, and the total number of nodes in the system is 5, then the processing node of the call is 18Mod 5+1=4, and the system adds a node in the call holding phase, the total The number of nodes becomes 6, then the follow-up message is wrongly sent to node 1 (18Mod 6+1) (because it is assumed that the node number starts from 1, and 1 needs to be added after taking the modulus, 18mod 6 = 0), which makes the call abnormal Continue or release. In the actual system, the distributor may adopt a certain load balancing strategy, but the above defects still exist under the condition of not storing the state of each call.

Contents of the invention

The technical problem to be solved by the present invention is to provide a method for realizing dynamic load balancing in a distributed SIP system, which does not need to store any state locally, and can adapt to the requirements of adding and deleting nodes and dynamic load balancing.

A method for realizing dynamic load balancing in a session initiation protocol distributed system of the present invention comprises the following steps:

1.1, the external Session Initiation Protocol (SIP) entity initiates the Session Initiation Protocol (SIP) request message, and the IP Load Balancing Unit (ILBU) receives the Session Initiation Protocol (SIP) message and sends the message to Protocol Load Balancing Unit (PLBU);

1.2. The Protocol Load Balancing Unit (PLBU) decodes the Session Initiation Protocol (SIP) message, judges whether the message is an internal or external request or response to the dialogue, and performs different processing respectively;

1.2.1. If it is an out-of-dialog request, perform hash calculation (HASH) on the value (A1) that must be carried in the Session Initiation Protocol (SIP) call and remain unchanged to obtain the protocol processing unit (PPU) node number and send it to the corresponding The node performs processing; after the node is processed, an extended parameter (B1) is added to the specific value returned in the header of the called party's response. The parameter includes the code for the node number and is identified as being added by the node; protocol processing The request forwarded or initiated by the unit (PPU) records its node number in the same identification (C1) in the response message and the request message;

1.2.2. If it is not an out-of-dialogue request, proceed to the next step;

1.3 If it is a request within the dialogue, distribute it according to the node number determined by the extended parameter (B1). If the node is unavailable, the request fails; if it is not a request within the dialogue, proceed to the next step;

1.4 For the response message, take the identification (C1) that must be the same in the response message and the request message to decode to obtain the node number, and distribute according to the decoded node number. If the node is unavailable, the request fails.

When the system bears UDP, the protocol load balancing unit (PLBU) and protocol processing unit (PPU) of the system can be combined and set, and the initial distribution is limited to this node.

In the above solution, the value that must be carried and remains unchanged in the session initiation protocol (SIP) call may be the call identification (Call-ID); the specific value returned in the header of the called party response may be the route Record (Record-Route) the route (Route) field of the request; the identification that must be the same in the response message and the request message may be part of the parameters in the Via (Via) header.

In a more specific scheme, the present invention comprises the following steps:

Step 301, an external session initiation protocol (SIP) entity initiates an invitation (INVITE) request, and the IP load balancing unit (ILBU) receives the request;

Step 302, the IP load balancing unit (ILBU) obtains the node number of a protocol load balancing unit (PLBU) according to the source, destination IP address or port number and the load balancing strategy realized;

Step 303, the IP load balancing unit (ILBU) sends the request to the protocol load balancing unit (PLBU);

Step 304, the protocol load balancing unit (PLBU) judges the INVITE message type, if it is an initial INVITE, then request a uniform resource identifier according to the call identification (Call-ID) requested by the session initiation protocol (SIP) or the session initiation protocol (SIP) message The user ID carried in the Request-URI is subjected to HASH processing, combined with the local node information, to obtain the available protocol processing unit (PPU) node number; otherwise, the protocol processing unit node number is obtained by decoding the distribution parameters in the Route header;

Step 305, the protocol load balancing unit (PLBU) sends the message to the protocol processing unit (PPU);

Step 306, after the protocol processing unit (PPU) has processed the session initiation protocol (SIP) INVITE request message and before forwarding the message, there are two extended parameters in the VIA of the forwarding request and in the inserted route record (Record-Route). Mark your own node number, the former is to facilitate the distribution and processing of response messages, and the latter is to solve the distribution of request messages

Step 307: the protocol processing unit (PPU) forwards the message;

Steps 308-309, the called user responds to the request, and the response message arrives at the protocol load balancing unit (PLBU) via the IP load balancing unit (ILBU);

Step 310, the protocol load balancing unit (PLBU) obtains the protocol processing unit (PPU) node number according to the content decoding of the VIA header field in the response message;

Steps 311-312, the response message is forwarded to the calling user through the protocol processing unit (PPU) and the IP load balancing unit (ILBU);

Steps 313-314, the user initiates a message in the dialogue and reaches the protocol load balancing unit (PLBU) via the IP load balancing unit (ILBU);

Step 315, the protocol load balancing unit (PLBU) is converted from the first route (TOP Route) header field in the request (this field is the route record (Record-Route) field inserted by the protocol processing unit (PPU) in the initial INVITE) ) in the extended parameter obtains the protocol processing unit (PPU) node number;

Step 316, the protocol load balancing unit (PLBU) forwards the message to the protocol processing unit (PPU).

Adopting the method of the present invention can improve the defects of the existing fixed HASH algorithm while maintaining the stateless characteristics of the distribution process itself. If other nodes exit the service due to failure, or need to manually add nodes, the total number of nodes in the system will change, resulting in changes in the node number obtained by the fixed HASH algorithm, which will cause confusion in the subsequent message distribution of established sessions. However, using the present invention is actually equivalent to treating a session-related message as a task, allocating processing resources from the first message according to a certain feature, once a processing node is allocated, labeling the session, and subsequent messages according to the label distribution, instead of distribution according to the initial task assignment keywords, so that once the session is established (the processing node has been assigned), as long as the node does not shut down, no matter whether the nodes in the system increase or decrease or the distribution strategy of the system is adjusted The message processing of the session is not affected, thereby greatly improving the reliability and scalability of the system.

Description of drawings

Fig. 1 is a logical frame diagram of a distributed SIP system;

Fig. 2 is the load balancing algorithm flowchart in the distributed SIP system that adopts fixed HASH algorithm in the prior art;

FIG. 3 is a flowchart of a load balancing algorithm in a distributed SIP system according to an embodiment of the present invention.

Detailed ways

Fig. 1 is a logical frame diagram of a distributed SIP system, showing logical nodes such as ILBU (IP load balancing unit), PLBU (protocol load balancing unit), PPU (protocol processing unit) and their connections. In the actual system design, the above three logical functions can be combined and merged according to the number of system nodes, the load balancing algorithm adopted or the characteristics of the components, and deployed in two or one physical node for implementation. If ILBU is implemented by a general-purpose network processor, it is difficult to decode SIP messages, then ILBU must be set independently; when the system scale is small, in order to save costs, PLBU and PPPU can be combined and set.

FIG. 2 is a flowchart of a load balancing algorithm in a distributed SIP system using a fixed HASH algorithm in the prior art, which has been introduced in detail in the background technology section.

The present invention utilizes three characteristics of the SIP protocol: a) there are certain values that must be carried and remain unchanged in a SIP call, such as Call-ID; Return a specific value, and this value must be brought back unchanged by the other party in a certain field of the subsequent message, such as the Route field of the Record-Route request in the response; c) In a SIP transaction, certain identifiers in the response message Must be the same as in the request message, such as some parameters in the Via header.

The steps of the present invention are:

1. The external SIP entity initiates a SIP request message, and the ILBU receives the message.

2. ILBU receives the SIP message and sends the message to PLBU according to the message address or port number.

3. The PLBU decodes the SIP message, and judges whether the message is an internal or external request or response to the dialogue and performs different processing:

If it is an out-of-dialogue request, perform HASH according to the SIP message component A1 that meets the characteristic a) to obtain the PPU node number and send it to the corresponding node for processing. After the SIP processing of the node, an extended parameter is added to the header with characteristic b). B1 (any form, as long as it conforms to the coding and syntax requirements of the SIP protocol, such as did=?), the parameter includes the coding of the node number, and is marked as added by the node. The request forwarded or initiated by the PPU records its node number in a certain identifier C1 (such as branch of Via or other private parameters) conforming to characteristic c).

If it is not an out-of-dialogue request, proceed to the next step.

4. If it is an intra-dialog request, distribute according to the node number determined by the B1 distribution parameter. If the node is unavailable, the request fails. If it is not requested in the dialog, go to the next step.

5. For the response message, take C1 to decode to obtain the node number, and distribute according to the decoded node number. If the node is unavailable, the request fails.

The present invention can bring following advantage:

a) Dynamic load balancing. Use the characteristics of the SIP protocol to record the node number actually assigned by the system in the initial request, ensuring that the established SIP call is no longer affected by the change of the load balancing function, and the initial call SIP message is assigned a processing with the hash value of A1 Node k, the subsequent message distribution uses the node k information carried in the message. At this time, modifying the HASH distribution table with A1 as the key will only affect the newly arrived call, and have no adverse effect on the established call. The system using this algorithm can dynamically modify the system distribution table according to the current performance measurement results of the system, thus realizing the dynamic load balancing of the system.

b) Fault tolerance: once the session is established, the processing node is determined by the returned parameters in the present invention, and the subsequent message must carry node information, so the subsequent message of the session can use this information to find the original session processing node, and will not increase or decrease due to the node Causes distribution errors, so it has the following fault-tolerant characteristics: the n-node distributed system detects that node k fails, and at this time, all the modulus values of A1 that should be distributed to this node are evenly distributed to other n-1 nodes. The SIP message in the dialogue carrying the information of node k is correctly discarded, and the initial SIP message is distributed to other nodes; after the fault recovers, the system readjusts the A1 distribution table, and the new call can reach node k, while the call follow-up message remains Processed on the original node.

Fig. 3 is a flowchart of a specific embodiment of the present invention.

Step 301, the external SIP entity initiates an INVITE request, and the ILBU receives the request;

Step 302, the ILBU obtains a node number of a PLBU according to the source, destination IP address or port number and the implemented load balancing strategy;

Step 303, the ILBU sends the request to the PLBU;

Step 304, PLBU judges the INVITE message type, if it is initial INVITE then carries out HASH processing according to the call identification (Call-ID) of SIP request, in conjunction with local node information, obtains available PPU node number (also can according to Request-ID in the initial SIP message The user identification HASH carried in the URI obtains the node number). Otherwise, the node number of the protocol processing unit is obtained by decoding the distribution parameter in the Route header.

Step 305, the PLBU sends the message to the PPU;

Step 306, after the PPU has processed the SIP INVITE request message, before forwarding the message, in the VIA of the forwarding request and an extended parameter in the inserted Record-Route (route record), there are two places to mark the node number of oneself, the former is for convenience The distribution processing of the response message, the latter is to solve the distribution of the request message

Step 307PPU forwards the message;

Steps 308-309, the called user responds to the request, and the response message arrives at the PLBU via the ILBU;

Step 310, the PLBU obtains the call processing PPU node number according to the content decoding of the VIA header field in the response message;

Steps 311-312, the response message is forwarded to the calling user via PPU and ILBU;

Steps 313-314, the user initiates a message in the dialogue and reaches the PLBU via the ILBU;

Step 315, the PLBU obtains the PPU node number according to the extended parameter in the TOP Route header field (this field is converted from the Record-Route field inserted by the PPU in the initial INVITE) in the request;

In step 316, the PLBU forwards the message to the PPU.

Claims (4)

1. method that realizes dynamic load leveling in the Session initiation Protocol distributed system may further comprise the steps:

1.1, external session initiation protocol entity initiation session initiation protocol request message, the IP Load Balance Unit is received the Session initiation Protocol message and according to message address or port numbers message is sent to the agreement Load Balance Unit;

1.2, the agreement Load Balance Unit decodes to conversation launch protocol message, judges that this message is inside and outside request of dialogue or response, carries out different processing respectively;

1.2.1 if the outer request of dialogue, the value that must carry and remain unchanged in the session initiation protocol call is carried out hash calculates the protocol processing unit node number and send to respective nodes and handle; This node processing finishes and add a spreading parameter in the particular value that the back returns in the head of callee response, comprises the coding to this node number in the parameter, and is designated this node and adds; Write down its node number in the sign that the request that protocol processing unit is transmitted or initiatively initiated must be identical in response message and request message;

1.2.2 if non-dialogue is asked, change next step processing outward;

1.3 if ask in the dialogue, distribute according to the node number that described spreading parameter is determined, unavailable as this node, then request failure; If next step processing is changeed in request in the non-dialogue;

1.4, then get described must identical sign in response message and request message the decoding to obtain node number for response message, distribute according to decoded node number, unavailable as this node, then request failure.

2. the method for dynamic load leveling in the described realization Session initiation Protocol of claim 1 distributed system is characterized in that, the agreement Load Balance Unit of system, protocol processing unit merge setting, and initial distribution is limited to this node.

3. the method for dynamic load leveling in claim 1 or the 2 described realization Session initiation Protocol distributed systems is characterized in that the value that must carry and remain unchanged in the described session initiation protocol call is a call identification; The particular value that returns in the head of described callee's response is the route field of route record request; Described must be identical in response message and request message be designated via the partial parameters in the head.

4. the method for dynamic load leveling in the described realization Session initiation Protocol of claim 3 distributed system is characterized in that step is:

Step 301, external session initiation protocol entity are initiated to invite request, and the IP Load Balance Unit is received this request;

Step 302, IP Load Balance Unit obtain the node number of an agreement Load Balance Unit according to the load balancing strategy of source, purpose IP address or port numbers and realization;

Step 303, the IP Load Balance Unit sends to this agreement Load Balance Unit with this request;

Step 304, the agreement Load Balance Unit is judged the invitation message type, if initial invitation, then carry out the hash computing according to the user ID of carrying in the unified resource identifier of asking in the call identification of Session initiation Protocol request or the conversation launch protocol message, in conjunction with local node information, obtain available protocol processing unit node number; Otherwise the distribution parameters decoding according to route header obtains the protocol processing unit node number;

Step 305, the agreement Load Balance Unit mails to this protocol processing unit with message;

Step 306, after protocol processing unit is handled the Session initiation Protocol invite request message, transmit before the message, transmit ask clearly via in and a spreading parameter in the route record that the inserts node number of totally two place's marks oneself, the former is the distribution processor for convenience of response message, and the latter then is the distribution that solves request message

Step 307 protocol processing unit is gone out forwards;

Step 308～309, the called subscriber is to request-reply, and response message arrives the agreement Load Balance Unit through the IP Load Balance Unit;

Step 310, the agreement Load Balance Unit obtains the protocol processing unit node number according to the content decoding via header fields in the response message;

Step 311～312, response message is transmitted to the calling subscriber through protocol processing unit, IP Load Balance Unit;

Step 313～314, message arrived the agreement Load Balance Unit through the IP Load Balance Unit in the user initiated to talk with;

Step 315, the agreement Load Balance Unit obtains the protocol processing unit node number according to the spreading parameter in the first route header field in the request;

Step 316, the agreement Load Balance Unit is given protocol processing unit with forwards.

Images