CN100344105C - Smooth restart method of carrier control level - Google Patents

Abstract

The invention discloses a smooth restart method of a bearer control layer. The method comprises: the restarted bearer network resource manager sends a resource synchronization request to a network device directly connected to it; if the network device cannot recognize the received resource synchronization request, then Send a synchronization rejection response to the currently restarted bearer network resource manager, and end the synchronization process; if it can be identified, send all the information related to the currently restarted bearer network resource manager in the network device to the currently restarted bearer network resource manager Connection information, the currently restarted bearer network resource manager saves the received connection information. The solution of the present invention enables the restarted bearer network resource manager to obtain lost connection information from adjacent devices, thus ensuring that the bearer network resource manager can continue the work before restarting after restarting, thereby improving the robustness of the bearer control layer. Stickiness, and enhance the stability of network operation.

Description

Graceful Restart Method for Bearer Control Plane

technical field

The invention relates to a device restart technology, more specifically, to a smooth restart method of a bearer control layer.

Background technique

With the continuous increase of the scale of the Internet network, various network services emerge one after another, and various advanced multimedia systems emerge in an endless stream, which leads to the need for the Internet network to frequently send high-burst File Transfer Protocol (FTP) or images containing images. Hypertext Transfer Protocol (HTTP) and other multimedia services for files. For real-time services on the network, since they are sensitive to characteristics such as network transmission delay and delay jitter, when the network sends services such as FTP or HTTP, it has a relatively large impact on real-time services. Moreover, multimedia services also occupy a large amount of network bandwidth, making it difficult to reliably transmit key services that require guaranteed bandwidth in existing networks.

In response to the above problems, various quality of service (QoS) technologies have been proposed in the industry. For example, the Internet Engineering Task Force (IETF) has established many service models and mechanisms to meet the requirements of the network. Among these QoS technologies, the technical scheme proposed by the IETF to use the integrated service model (Int-Serv) at the access and edge of the network and the differentiated service model (Diff-Serv) at the core of the network is more recognized by the industry. Since Diff-Serv in this scheme only sets priority registration guarantee QoS, although the network using this scheme has the characteristics of high line utilization, it is difficult to guarantee the transmission reliability and transmission effect of the entire network. To solve this problem, the industry proposes a solution to introduce an independent bearer control layer for Diff-Serv, that is, a Diff-Serv model with an independent bearer control layer is proposed on the basis of the original Diff-Serv. The solution is to set a bearer control layer between the service control layer and the bearer network layer of Diff-Serv. The set bearer control layer is composed of a plurality of bearer network resource managers, and the bearer network resource managers can be bandwidth agents ( BB, Bandwidth Broker), or it can be a QoS server, a bearer network resource manager (CM) or other network devices. Each bearer network in Diff-Serv corresponds to a bearer network resource manager, which is configured by the bearer network resource manager. The management rules and network topology of the bearer network, and allocate bandwidth resources for the services applied by users. Each bearer network resource manager transmits the request and result of the user's application for service bandwidth through signaling, and the bearer network resource manager provides the service for the user. Path information for the application assignment.

The Diff-Serv model with an independent bearer control layer will be described below with reference to the accompanying drawings.

Each bearer network resource manager in the Diff-Serv model manages a part of the bearer network, which is its management domain. In the Diff-Serv model shown in Figure 1, the management domain 101 corresponds to the bearer network resource manager 102, and the bearer network resource manager 102 is connected to the edge router (ER) 103 in the management domain 101, and the bearer network resource manager 102 Perform network resources and topology management on the management domain 101; similarly, the management domain 112 corresponds to the bearer network resource manager 111, and the bearer network resource manager 111 is connected to the router 113 in the management domain 112; the management domain 109 corresponds to the bearer network resources The manager 108, the bearer network resource manager 108 is connected with the ER 110 in the management domain 109. The bearer network resource manager 102 and the bearer network resource manager 108 are connected through a bearer network resource manager 111 . User (UE) 104 is connected with call agent (CA) 105, and this CA 105 is connected with bearer network resource manager 102, and the request sent by user UE104 enters this bearer network through management domain 101 corresponding to bearer network resource manager 102, Therefore, if UE 104 is the calling user, then bearer network resource manager 102 is the source bearer network resource manager of UE 104; UE 106 is connected with CA 107, and this CA 107 is connected with bearer network resource manager 108, and the user UE 106 The request sent enters the bearer network through the management domain 109 corresponding to the bearer network resource manager 108. Therefore, if the UE 106 is the calling user, the bearer network resource manager 108 is the source bearer network resource manager of the UE 106.

The bearer control layer can allocate resources for the service requests of users, CAs or network maintenance personnel. If UE 104 in FIG. 1 is the calling UE and UE 106 is the called UE, the bearer network resource manager 102 is the source bearer network resource manager of UE 104, and the bearer network resource manager 108 is the destination bearer network resource manager. device.

If the bearer network resource manager in the bearer control layer is a CM, then the bearer control layer allocates resources for service requests by establishing a connection between the source CM and the destination CM. When establishing a connection, the source CM sends a resource request to the downstream CM hop by hop until the destination CM; the destination CM returns a resource response until the source CM. After the connection is established at the bearer control layer, the source CM sends the call information, QoS parameters of this call, and the path information determined during the connection establishment process to the ingress ER of this service request. In the above establishment process, each CM allocates an inter-domain path within its own management domain and the management domain corresponding to the downstream CM for the service request, and reserves bandwidth information for the service request.

The above-mentioned source CM can be directly determined by the CA, or can be determined through a proxy in the bearer control layer. If it is the latter, the source CM should also return the proxy resource response through the path that sends the proxy resource request, until it is directly connected to the CA. The CM returns the connection resource response to the CA after receiving the proxy resource response.

No matter what kind of equipment the bearer network resource manager in the bearer control layer is, after the current connection is established, the bearer network resource manager needs to maintain and manage the established connection according to the connection information saved by itself. For example, the resource manager of the bearer network maintains the state of the current connection, or modifies the set bandwidth information.

Therefore, during the above connection establishment process, each bearer network resource manager needs to save connection-related information during this connection process. If a bearer network resource manager suddenly loses power or other failures occur, all the connection information saved by it will be lost due to the failure, and currently there is no way to retrieve the connection information saved by the bearer network resource manager after recovery In this way, even if the bearer network resource manager returns to normal, it cannot continue to establish the current connection, and cannot maintain and manage the established connection, and the new resource request cannot be allocated accurately due to the loss of the existing resource usage. resources, which will inevitably affect the stability of bearer network resource managers and network operations.

Contents of the invention

In view of this, the main purpose of the present invention is to provide a method for the resource manager of the bearer network to obtain current network information after restarting, so that the resource manager of the bearer network can try its best to restore the original information after restarting, and can better Handle new resource requests efficiently.

In order to achieve the above object, the technical solution of the present invention is implemented in the following way: a method for smooth restart of the bearer control layer, the method includes the following steps:

a. The restarted bearer network resource manager sends a resource synchronization request to the network device directly connected to it;

b. After the network device receives the resource synchronization request, it judges whether it can recognize the resource synchronization request. If it can recognize it, it sends all the current restarted bearer network resource managers in this network device to the currently restarted bearer network resource manager. Relevant connection information, and enter step c, otherwise, send a synchronization rejection response to the currently restarted bearer network resource manager, and end the synchronization process;

c. The currently restarted bearer network resource manager saves the connection information sent in step b.

In the step a, the restarted bearer network resource manager sets a request identifier for identifying the client type in the resource synchronization request sent;

Then in the step b, the network device judges whether it can recognize the request identifier in the resource synchronization request.

After sending all the connection information, the network device in step b may further include returning a synchronization completion response to the currently restarted bearer network resource manager.

In the step b, the network device sets an identification bit for identifying whether this message is the last connection information message in the sent connection information.

The method may further include: the network device judging whether the sent connection information is the last connection information message, if yes, setting the identification bit in the retransmission message to a specific value, otherwise, setting The flag for is set to a value different from that specific value.

The network device directly connected to the restarted bearer network resource manager is an edge router in the management domain corresponding to the restarted bearer network resource manager, and the sending connection information is: sending call information, QoS parameters and established connections path information.

The device directly connected to the restarted bearer network resource manager is a bearer network resource manager, and the sending connection information is: sending a resource request, or a proxy resource request, or path information of an established connection, or the three random combination.

The sending connection information may further include: sending a resource response, and/or a proxy resource response.

The network device directly connected to the restarted bearer network resource manager is a call proxy, and the sending of the connection information is: sending the connection resource request that it once sent to the currently restarted bearer network resource manager.

In the step c, when the restarted bearer network resource manager saves the connection information for each call, it first judges whether the received connection information conflicts with the currently received connection information, and if there is , then delete all connection information corresponding to this call, otherwise, save the currently received connection information.

The method may further include: when the restarted bearer network resource manager deletes all the connection information corresponding to the current call, send a request message for reacquiring the connection information of the current call to the network device related to the current call , the network device receiving the request message resends the connection information stored by itself and corresponding to this call.

The scheme of the present invention sends a resource synchronization request to other network devices directly connected to it through the restarted bearer network resource manager, and saves the connection information fed back by other network devices after receiving the resource synchronization request, so that the bearer network resource manager After restarting due to power or other faults, the connection information before restarting can be obtained from adjacent network devices, thus ensuring that the resource manager of the bearer network can continue the connection establishment, maintenance and management work before the fault after restarting. Moreover, since the restarted bearer network resource manager obtains the existing resource allocation situation, it can accurately allocate resources for new resource requests. It can be seen that the solution of the present invention improves the robustness of the bearer control layer and enhances the stability of network operation, and the solution of the present invention is simple to implement and easy to maintain and manage.

Description of drawings

FIG. 1 is a schematic diagram of a current Diff-Serv model with an independent bearer control layer;

Fig. 2 is a message flow sequence diagram for implementing resource synchronization in the scheme of the present invention;

Fig. 3 is a flow chart of resource synchronization implemented by the solution of the present invention.

Detailed ways

The scheme of the present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

If a bearer network resource manager restarts after power failure or failure, it will send a resource synchronization request for obtaining connection information to the network device directly connected to itself, and the network device that receives the resource synchronization request will save the The connection-related information is sent to the bearer network resource manager, and the bearer network resource manager restores its own connection information according to the received connection-related information.

Refer to Figure 2 for the message flow sequence to realize resource synchronization, and refer to Figure 3 for the corresponding process, which is realized through the following steps:

Step 301, after the bearer network resource manager restarts, it sends a resource synchronization request for obtaining connection information to the network device directly connected to it, and the resource synchronization request sent should include a request identifier for identifying the client type.

If the restarted bearer network resource manager is only directly connected to ERs and some bearer network resource managers in its own management domain, the restarted bearer network resource manager sends resource synchronization ask. If the restarted bearer network resource manager is still connected to the CA, it should also send a resource synchronization request to the CA.

Steps 302-304, the network device receiving the resource synchronization request judges whether it can recognize the request identifier in the resource synchronization request, and if it can recognize it, sends the resource manager of the currently restarted bearer network to the resource manager of the restarted network device. connection information related to the bearer network resource manager, and go to step 305; otherwise, return a synchronization rejection response to the currently restarted bearer network resource manager, and end the current synchronization process.

The network device directly connected to the currently restarted bearer network resource manager may be ER, bearer network resource manager or CA, so the connection information resent by various network devices is different.

Taking the bearer control layer composed of CMs as an example, the restarted bearer network resource manager is the CM. For the ER, the connection information it sends is the call information saved by itself, QoS parameters, and the path information of the established connection. These connection information are sent to the ER by the currently restarted CM. If it has received the path information delivered by the currently restarted CM, it will also send the path information to the currently restarted CM. For the CM, it sends all the connection information related to the currently restarted CM saved by itself to the currently restarted CM. The connection information may be the resource request and response it has received, or it may be a proxy resource request. and response, and may also be established path information, etc. For the CA, the connection information it sends is all the connection resource requests it has sent to the restarted CM.

After the network device in this step has sent all the connection information saved by itself, it should also send a synchronization completion response indicating that all connection information in the network device has been resent. In order to simplify the process, these network devices may not send a synchronization completion response, but add an identification bit to identify whether this message is the last connection information message in the connection information message sent above, for example, if this message is the last If it is a connection information message, the identification bit in the message is set to a specific value, and if it is not the last connection information message, the identification bit in the message is set to a value different from the previous specific value. For example, set the identification bit in the last message to 1, and set the identification bits in other messages to 0; or, set the identification bit in the last message to 0, and set the identification bits in other messages to 1; Or, only set the identification bit of the last message to a specific value, such as 0xFF, and the identification bits in other messages can be set arbitrarily.

Step 305, the restarted bearer network resource manager saves the received connection information.

The restarted bearer network resource manager often obtains the connection information for a certain call from the connection information sent by multiple devices. If there is a conflict between the connection information for the same call sent by different devices, the restarted bearer network The resource manager needs to delete all connection information related to this call. In order to reacquire the connection information corresponding to the call, the restarted bearer network resource manager can also send a request message containing the call identifier of the call to all network devices related to the call, requesting the network device to resend the connection information related to the call. The connection information corresponding to the call. The network device that receives the request message sends the connection information corresponding to the call to the restarted bearer network resource manager again. Through the above process, the restarted bearer network resource manager can recover to the state before the failure.

The above descriptions are only preferred embodiments of the solutions of the present invention, and are not intended to limit the protection scope of the present invention.

Claims (11)

1, a kind of smooth restarting method of bearer control layer is characterized in that this method may further comprise the steps:

The load network resource manager of a. restarting sends the source synchronous request to the network equipment direct-connected with it;

B. after the network equipment is received the source synchronous request, judge whether self can discern this source synchronous request, if can discern, then send all and the relevant link information of current load network resource manager of restarting in the present networks equipment to current load network resource manager of restarting, and enter step c, otherwise, send refusal response synchronously to current load network resource manager of restarting, and finish Synchronous Processing;

C. the link information that each network equipment sends among the current load network resource manager receiving step b of restarting, and at per call link information is preserved.

2, method according to claim 1 is characterized in that among the described step a, and the load network resource manager of restarting is provided for identifying the request mark of client type in the source synchronous request that sends; Among the then described step b, the network equipment is judged the request mark in self whether can the recognition resource synchronization request.

3, method according to claim 1 is characterized in that, the described network equipment of step b further comprises: return to current load network resource manager of restarting and finish response synchronously after sending all link informations.

4, method according to claim 1 is characterized in that, among the described step b, whether the described network equipment is provided for identifying this message in the link information that sends be the sign position of the last item link information message.

5, method according to claim 4, it is characterized in that, this method further comprises: the described network equipment judges whether the link information that sends is the last item link information message, if, then the sign position in this link information message is set to particular value, otherwise the sign position in this link information message is set to the value different with this particular value.

6, method according to claim 1, it is characterized in that, described is the interior edge router of the corresponding management domain of current load network resource manager of restarting with the direct-connected network equipment of the load network resource manager of restarting, and then described transmission link information is: send call information, qos parameter and the routing information of having set up that is connected.

7, method according to claim 1, it is characterized in that, described and the direct-connected network equipment of load network resource manager that restart is a load network resource manager, then described transmission link information is: send resource request or proxy resources request or established path information, or three's combination in any.

8, method according to claim 7 is characterized in that, described transmission link information further comprises: send resource response, and/or the proxy resources response.

9, method according to claim 1, it is characterized in that, with the direct-connected network equipment of the load network resource manager of restarting be Call Agent, then described transmission link information is: send the connection resource request that it once sent to current load network resource manager of restarting.

10, method according to claim 1, it is characterized in that among the described step c, when described load network resource manager of restarting is preserved link information at per call, judge at first whether paid-in link information conflicts with the current link information of receiving, if have, then deletion is called out all corresponding link informations with this, otherwise, preserve the current link information of receiving.

11, method according to claim 10, it is characterized in that this method further comprises: when described load network resource manager of restarting is called out all corresponding link informations in deletion with this, to calling out the request message that the relevant network equipment sends the link information of obtaining this calling again, receive that the network equipment of this request message is retransmitted that self preserves and corresponding with this calling link information with this.

Images