WO2006094671A1 - Providing high availability with dqos - Google Patents
Providing high availability with dqos Download PDFInfo
- Publication number
- WO2006094671A1 WO2006094671A1 PCT/EP2006/001789 EP2006001789W WO2006094671A1 WO 2006094671 A1 WO2006094671 A1 WO 2006094671A1 EP 2006001789 W EP2006001789 W EP 2006001789W WO 2006094671 A1 WO2006094671 A1 WO 2006094671A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- dqos
- nodes
- calls
- address
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/58—Association of routers
- H04L45/586—Association of routers of virtual routers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
In current cable network systems, high availability in case of node shutdowns cannot be maintained for DQoS calls. The proposed method and a system for providing high availability with DQoS comprise two nodes (Nl, N2) of the CMS using their own virtual IP address; storing the gate information relating the first node DQoS calls both nodes (Nl, N2); when said first node (Nl) is shutdown (205; 305), notifying (206; 306) the second node (N2); by the second node (N2), taking over the first node virtual IP address, after the closure of its IP connections (205a, 205b; 305a, 305b); and, by the second node (N2), assuming (207, 208, 209, 210, 211, 212) all first node IP connections, on behalf of the first node (Nl), by using the first node virtual IP address and by using the stored gate information.
Description
Providing high availability with DQoS
The present invention relates to a method according the preamble of claim 1 and a system according the preamble of claim 10.
DQoS, as defined by the PacketCable and Euro PacketCable standards, is a protocol that describes a method for authorizing, reserving and committing bandwidth over a data- over cable network.
Since a data-over cable network is a shared resource between several cable modems and several customer services, bandwidth is a scarce resource that has to be selectively assigned to customers engaged in calls.
Thus, for the purpose of efficiently managing bandwidth, DQoS protocol was introduced.
In fact, DQoS enables service providers to maintain a certain quality of service, to minimize bandwidth waste and to avoid frauds from abusive customers .
On a cable network compliant with PacketCable and Euro PacketCable standards, a Call Management Server (CMS) is the network entity responsible for providing calls and services to telephone or multimedia subscribers that are customers of cable TV operators or of other operators that provide services through the existing cable TV network.
A CMS may be a VoIP telephony switch, a video server or any other type of multimedia server.
A VoIP switch may support voice over cable platforms .
Services and calls may include VoIP telephone conversations, video calls or any other type of multimedia calls .
The authorized, reserved and committed bandwidth via DQoS is used by end-terminals at customer sites to achieve high quality calls over an IP connection established on a cable network. DQoS protocol allows the CMS to authorize bandwidth at the cable modem termination systems (CMTSs) on a need basis, ensuring that the bandwidth is not wasted or stolen by abusive customers.
The connectivity of a device within the network may be disrupted due to outages or maintenance operations causing the interruption of subscriber calls.
In order to ensure high service availability, service providers require network connections and systems to be as reliable as possible and as failure-safe as possible.
Since the failure of a network entity is an event impossible to be avoided, the CMSs may be made redundant in order to render network systems failure-safer.
A redundant CMS is a multi-node CMS which includes at least two nodes so that in case on node is not operational, another node may take over the operations of the non-operational node.
A multi-node CMS may be able to support DQoS protocol but problems arise in maintaining high availability in case of node shutdowns . Nodes may be shutdown during planned maintenance operations or in case of node failures.
A solution consists in temporarily turning off the DQoS protocol during node shutdowns and thus maintaining high availability. This solution has the drawback that quality of service is not guaranteed and this fact may cause many problems. In fact, without DQoS protocol, emergency calls may be unable to get the necessary bandwidth. In addition,
customers that do not get their usual QoS may issue complaints .
Therefore, when DQoS is not performed during a partial node shutdown, calls are no longer monitored for DQoS activity and this may result in degraded quality of service for regular calls and it may pose serious risks for emergency calls placed without quality control.
Another solution consists in supporting DQoS protocol without implementing high availability. This other solution has the drawback that, during shutdowns, calls cannot be controlled and that already placed calls cannot be served.
Moreover, another drawback is that load balance is not guaranteed.
In fact, without implementing high availability, DQoS calls are permanently associated with the surviving backup node, even after the temporarily shutdown node is recovered.
Thus, if no high availability is implemented, after the non- operational node comes back to service, the DQoS calls that were supposed to be placed on that node, while it was out of service, are not carried over to it.
Hence, as above explained, even in the case that new DQoS calls may be made possible, due to the switch IP- address/subscriber relationship, the CMTS receiving DQoS messages would mis-associate the subscriber with the temporary backup node, thus causing the subscriber to stay in even after the recovery of the shutdown node.
It is therefore the aim of the present invention to overcome the above mentioned drawbacks, in particular by providing a method and a system for allowing DQoS protocol to co-exist with high-availability implementations in a cable network system.
The afore mentioned aim is achieved by a method and by a system for providing high-availability with DQoS, in a cable network system; the system comprising a CMS and a plurality of CMTSs; the CMS comprising at least two nodes interconnected with each other and connectable with the plurality of CMTSs ; a first node of the at least two nodes being an active node and having, with the plurality of CMTSs, a plurality of IP connections running DQoS calls; a second node of the at least two nodes acting as a backup node of the first node; the proposed method and system comprising:
- by each of the at least two nodes, using a virtual IP address so that the plurality of CMTSs, when connected with the at least two nodes, sees the at least two nodes of the CMS as at least two separate CMSs ;
- storing gate information relating to the first node DQoS calls in both the first and second nodes; and wherein, when the first node is shutdown, the method further comprises the steps of:
- notifying the second node about the shutdown of the first node;
- by the second node, taking over the virtual IP address of the first node, after the closure of the first node IP connections; and
- by the second node, assuming the first node IP connections, on behalf of the first node, by using the first node virtual IP address and by using the stored gate information.
In the proposed invention, when the first node is shutdown in a controlled way, the IP connection closure may preferably be performed by the first node and the notifying may be performed by the first node.
Alternatively, in the proposed invention, when the first node is shutdown in an uncontrolled way, the IP connection closure may happen because of a failure.
In accordance with a preferred embodiment of the present invention, the second node, acting as a backup node of the first node, may be itself an active node having, with the CMTSs, its own plurality of IP connections running DQoS calls . Further advantageous embodiments of the present invention are given below (each alone or in any possible combination) :
- the DQoS calls may comprise active and/or transient calls;
- the CMS may be a VoIP switch; - the DQoS may be a protocol defined in PacketCable or in Euro PacketCable industry specifications;
- the plurality of IP connections carry Common Open Policy Server messages .
In a further advantageous embodiment of the present invention, when the shutdown first node is ready to be put back into service, the invention may further comprise:
- by the first node, requesting from the second node the gate information relating to the DQoS calls run on behalf of the first node;
- by the second node, sending to the first node the requested gate information;
- by the second node, closing the plurality of IP connections opened on behalf of the first node; - by the second node, removing the first node virtual IP address and notifying the first node;
- by the first node, assuming its own plurality of IP connections, by using its own virtual IP address and by using the requested gate information.
The proposed invention allows the redundant CMS to complete existing and/or newly placed DQoS calls both during partial node shutdowns and after the recovering of such shutdowns.
Thus, with the proposed invention, when a node of a redundant CMS fails or is taken out of service, the calling subscribers do not experience degraded QoS but continue to have the same QoS they received under normal conditions .
With the proposed invention, the concerned CMTSs see a shutdown of a CMS node as a simple glitch in the network.
Moreover, the proposed invention allows the load balance of the system to be maintained upon recovery of the failed node.
The proposed invention allows, even in case of node shutdowns, service providers to be able to continue to run the DQoS protocol, to monitor the network against bandwidth related violations or theft and to ensure the service of emergency calls.
The invention will now be described in preferred but not exclusive embodiments with reference to the accompanying drawings , wherein:
Figure 1 message sequence diagram which schematically illustrates a connection establishing between CMTSs and an active-active dual node CMS, in accordance with an example embodiment of the present invention;
Figure 2 message sequence diagram which schematically illustrates the case of a graceful shutdown;
Figure 3 message sequence diagram which schematically illustrates the case of an uncontrolled shutdown;
Figure 4 message sequence diagram which schematically illustrates a shutdown node recovery, in accordance with an example embodiment of the present invention.
In the sequences of Figures 1 to 4, blocks Nl, N2 represent two nodes of a redundant CMS and blocks Tl, .., Tn represent n CMTSs that provide DQoS services to subscribers, according to an example embodiment of the present invention.
The skilled in the art easily understands that, in further embodiments of the present invention the redundant CMS may be any type of multi-node CMS having, thus, two or more nodes Nl , N2.
The CMS may preferably be a VoIP switch. In further embodiments according to the present invention, the CMS may be any other type of multimedia server.
The two nodes Nl, N2 are interconnected between each other via a communication mechanism that allows them to process telephony and/or multimedia calls on a cable network platform.
Under normal conditions, the two nodes Nl, N2 may share the call-processing load of the entire system.
To achieve bandwidth management via DQoS protocol, the CMS opens a protocol connection over IP from each of its active nodes Nl, N2 to each CMTS Tl, Tn on the network and starts a policy protocol sessions.
The policy protocol session carries the DQoS messages to perform bandwidth management .
Example of policy protocol may be COPS protocol. Under the standards defined by PacketCable and by Euro PacketCable, TCP is chosen as the connection oriented protocol to carry the COPS messages .
According to the present invention, a virtual IP address is used on each CMS node Nl, N2, thus making the dual-node CMS look like two separate entities to the outside network elements, e.g the CMTSs Tl, Tn, regardless of whether these entities are physically separate or one, but acting as two to the outside world.
In the context of redundant network elements, the term virtual IP address is typically used to denote those IP addresses that are used to handle failover operations .
Generally, IP addresses are assigned to network interfaces on a permanent basis. By adding the term virtual to the term IP address it is typically meant that such virtual IP address may get assigned to different network interfaces during run time to achieve goals such as redundancy.
Thus the term virtual is used to denote that the virtual IP address is independent from the network device is associated to.
In case of a network shutdown, e.g. the first node Nl is taken out of service for maintenance operations or it crashes due to software or hardware failures, the second node N2 that is still healthy assumes the duties of the shutdown node Nl.
According to the present invention, the virtual IP address of the shutdown node Nl gets created on the node that is still running .
As soon as the virtual IP address is ready on the surviving node N2, a connection to each CMTSs Tl, Tn on the cable platform is established on behalf of the shutdown node Nl.
Advantageously, to the CMTSs Tl, Tn, the shutdown looks like a glitch in the network, because the they do not realize that it is another network entity, e.g. the surviving node N2, that is establishing the connection, since the used virtual IP address is still the same.
To execute bandwidth management, objects called gates are created per call on each CMTS Tl, Tn by the CMS.
The gate objects are created by sending DQoS gate messages over the policy session, e.g. a COPS session, established between the CMS . and the CMTS .
The gate is a reference to the authorized bandwidth having certain attributes . .
It represents the bandwidth quality of a connection between two voice or multimedia entities, such as two voice or multimedia subscribers. A gate identification (ID) is assigned by the CMTS Tl, Tn for each created gate.
The gate information is stored at the CMS for later use.
The CMS has to refer to the gate it created by its ID when it sends additional commands to manipulate or utilize the gate.
A high available CMS comprises at least two nodes Nl, N2 that are interconnected in configurations which may be all active configurations or some active and some backup configurations .
When all nodes Nl, N2 are active, meaning they are all actively processing calls, they may also all or partially act as backups to each other.
In the example embodiment according to the present, invention of Figures 1 to 4, an active-active configuration is shown in
which the first active node Nl is shutdown and the second active node N2 acts a backup of the first one.
In a further embodiment according to the present invention, some nodes may be active only and the remaining nodes my be backup only, the active nodes are actively processing calls and the backup nodes are waiting idle to take over the duties of the active nodes in case any of the active nodes fail .
On an active-active node configuration, each node Nl, N2 on the system connects to each CMTS on the network from its own virtual IP address . A virtual IP address is used on each node Nl, N2 to allow portability of the virtual IP address.
On an active-backup node configuration, only the nodes that are active establish connections to the CMTSs Tl, Tn, while the backup nodes, when idle, don't establish any connection to any of the CMTSs Tl, Tn.
In either active-active or active-backup system, the DQoS gate information relating to either active or transient calls, i.e. calls that are already set-up or calls in progress of being set-up, has to be stored on the active and the backup nodes Nl, N2 to assure the survival of the call if the active nodes failed.
During normal operation, the active node Nl use its local gate storage area pool, also referred as gate context pool.
At each DQoS related transaction, the gate context relating to a call is retrieved, used and updated.
Every time a transaction is completed, the gate context is sent over to the backup node N2 over an inter-node connection, which then triggers the backup node N2 to store the same information locally.
This stored information is not used by the backup node N2 as long as the active node Nl remains healthy throughout the life of the call associated with the gate object.
Figure 1 is a diagram of a CMS to CMTS connection sequence, showing an example embodiment of the steps performed in establishing the connections from the two-nodes Nl, N2 of the CMS, configured in an active-active mode, to all the possible n CMTSs Tl, Tn configured on the cable network.
In steps 101 and 102, the first node Nl of the CMS sends a connection request to all the n CMTSs configured on the system, starting from the first CMTS Tl to the last one Tn. Messages Connection_Request (From: Nl_IP, To: Tl_IP) and Connection_Request (From: Nl-IP, To: Tn_IP) are sent.
In steps 103 and 104, the n CMTSs that receive the connection requests may reply with connection acceptance and the TCP connection is then ready to start a policy session, e.g. a COPS session. Messages Connection_Accept (From: Tl_IP, To: N1_IP) and Connection_Accept (From: Tn_IP, To: Nl_IP) are sent.
In steps 105 and 106, the second node N2 of the CMS sends a connection request to all the n CMTSs configured on the system, starting from the first CMTS to the last one Tl, Tn. Messages Connection_Request (From: N2_IP, To: Tl_IP) and Connection_Request (From: N2_IP, To: Tn_IP) are sent.
In steps 107 and 108, the n CMTSs that receive the connection requests reply with connection acceptance and the TCP connection is then ready to start a COPS session. Messages Connection_Accept (From: Tl_IP, To: N2_IP) and Connection_Accept (From: Tn_IP, To: N2_IP) are sent.
As above said, nodes may be shutdown for maintenance reasons, in a controlled shutdown, or in case of node outages, in an uncontrolled shutdown.
During a controlled or graceful shutdown, an active node Nl of a redundant CMS may have to be taken out from service in order to replace a faulty hardware or in order to check and upgrade existing hardware or software.
In a graceful shutdown event, the synchronization of events may be controlled much faster than in event of uncontrolled shutdown.
In fact, in case of an uncontrolled shutdown event, e.g. a crash event, the CMS relies on the operating system to determine if there is a node failure or not.
Thus, in an uncontrolled shutdown, the CMS may have to wait a longer time to act than in a graceful shutdown. In fact, methods of determining node failures usually depend on heartbeats that run across nodes Nl, N2, based on timeouts of grace periods. The grace periods are utilized in order to avoid determining false node failures in case only temporary glitches are present.
Figure 2 shows a diagram of a controlled shutdown case in which the first node Nl of the CMS is gracefully taken out of service and the second node N2 acts as a backup node.
In steps 201 to steps 204, it is shown that the nodes Nl, N2 of the CMS are connected in an active-active configuration and are thus actively exchanging messages with all CMTSs Tl, Tn on the cable network. Messages Estabilished_Connection(From: Nl_IP, To: Tl_IP) , Estabilished__Connection(From: Nl_IP, To: Tn_IP) ,
Estabilished_Connection(From: N2_IP, To: Tl_IP) and
Estabilished_Connection(From: N2_IP, To: Tn_IP) are exchanged.
In step 205, the first node Nl of the CMS is shutdown in a controlled way.
The sequence for DQoS traffic handling begins with gracefully closing all connections from the shutting down node Nl to all CMTSs Tl, Tn on the network, as shown in steps 205a and 205b. Messages Connection_Close(From: Nl-IP, To: Tl_IP) and Connection_Close(From: Nl_IP, To: Tn_IP) are sent.
In step 206, the shutting-down node Nl removes its virtual IP address from its network interface and sends a message to the backup node N2 to takeover its own duties. Message Takeover (Nl) is sent.
In step 207 and 208, upon receipt of the takeover message, the backup node N2 assumes the first node's virtual IP address by creating it on its own network interface and then it connects to all CMTSs Tl, Tn on the network on behalf of the first node Nl. Messages Connection_Request (From: N1_IP, To: Tl_IP) and Connection_Request (From: Nl_IP, To: Tn_IP) are sent.
The CMTSs Tl, Tn getting the new connection requests may be unaware that a shut-down occurred. They may assume that the node Nl was shutting down for a moment by closing its connections and by immediately reopening them. The DQoS call signaling continues as if node Nl were never shutdown.
Advantageously, since the connections are reopened on behalf of the same virtual IP address, the association of gates to CMSs at the CMTSs Tl, Tn is preserved and the active calls are maintained.
Since all gate information are saved over to the backup node N2 during the first node Nl regular operations, additional transactions are possible on existing gates through the backup node N2.
In steps 209 and 210, messages of connection accept indications arrive from the CMTSs Tl, Tn at the virtual IP address used by the backup node N2 on behalf of the first node Nl. Messages Connection_Accept (From: Tl_IP, To: Nl_IP) and Connection_Accept (From: Tn_IP, To: Nl_IP) are sent.
In steps 211 to 212, the new connections opened from the backup node N2 on behalf of the first node Nl are becoming active and exchange policy messages, eg. COPS messages, as if they were coming from and/or going to the first node Nl.
Messages Estabilished_Connection(From: Nl_IP, To: T1_IP) and Estabilished_Connection(From: Nl_IP, To: Tn_IP) are exchanged.
In steps 213 and 214, it is showed that, being the shown embodiment according to the present invention is an active- active configuration, the existing active connections of the second node N2 are still active and are exchanging COPS messages. Messages Estabilished_Connection(From: N2_IP, To: T1_IP) and Estabilished_Connection(From: N2_IP, To: Tn_lP) are exchanged.
Figure 3 shows a diagram that illustrates how the DQoS sessions are handled in case of an uncontrolled shutdown case.
In step 305, the first node Nl crashes and, in steps 305a and 305b, the communications from the failed node Nl to all the CMTSs Tl7 Tn are lost.
In step 306, the backup node N2 is notified by the operating system about the failure of the active node Nl. Message Node_Failure(Nl) is sent.
Upon notification, the backup node N2 assumes the duties of the failed active node Nl. It takes over the virtual IP address of the failed node Nl by creating it on its own system.
In steps 207 and 208, after taking over this additional virtual IP address, the backup node N2 establishes, on behalf of the first node Nl, to all CMTSs Tl, Tn on the network.
The connection establishing process in case of uncontrolled shutdown is similar to the one of the controlled shutdown, as shown in steps 207 to 214.
Whether these additional transactions are performed on existing gates or on newly created gates, the CMTSs Tl, Tn assume that it is still the first node Nl that is requesting such transactions .
Figure 4 shows a diagram with a recovery sequence in which the shutdown node Nl is put back into service and resumes its DQoS sessions according to an example embodiment of the present invention.
In step 401 to 402 it is shown that, until the shutdown node Nl is still out of service, the back up node N2 is connected and actively exchanging message with all CMTSs Tl, Tn on behalf of the shutdown node Nl. Messages Estabilished_Connection(From: N1_IP, To: Tl_IP) and Estabilished_Connection(From: N1_IP, To: Tn_IP) are exchanged.
At the same time, being the shown example embodiment an active-active configuration, in steps 403 and 404, the back
up node N2 may be connected and may be actively exchanging message with all CMTSs Tl, Tn on the network on behalf of itself. Messages Estabilished_Connection(From: N2_IP, To: T1_IP) and Estabilished_Connection(From: N2_IP, To: Tn_IP) are exchanged.
In step 405, the node Nl that was previously shutdown in a graceful or uncontrolled manner is now ready to be put back into service.
In step 406, the recovered node Nl sends a message to the backup node Nl through its interconnects, requesting all the relevant DQoS gates in order to take over back to service. Message Get_Context_Data is sent.
Accordingly, in steps 407, the backup node N2 sends to the recovered node Nl all gate context data. The backup node N2 sends also an indication of the completion of the information transferal process, thus enabling the recovered node Nl to carry over its original virtual IP address. Messages Context Data, ... , Context Data and Context Data Complete are sent.
In order to take back its original virtual IP address from the backup node N2, the active node Nl sends, in step 408, a message to the backup node N2 to close the connections to all CMTSs Tl, Tn that were established on behalf of the first node Nl and to remove the first node virtual IP address from its system. Message Remove__IP_Address (Nodel) is sent.
Accordingly, in steps 409 and 410, the backup node N2 gracefully closes the connections to the CMTSs Tl, Tn that were established for the first node N2 and removes the first node's virtual IP address from its network interface. Messages Connection_Close(From: Nl_IP, To: Tl__IP) and Connection_Close(From: Nl_IP, To: Tn_IP) are sent.
As the backup node N2 removes the first node virtual IP address from its system, it notifies, in step 411, the recovered node Nl to take over its duties . Message IP_Address_Removed(Nl) is sent.
In steps 412 and 413, upon receipt of the above notification, the active node creates the virtual IP address for itself, node where the virtual IP address actually belongs and, from its recovered virtual IP address, initiates connections to all CMTSs Tl, Tn configured on the system to establish the relevant policy sessions. Messages Connection_Request (From: Nl_IP, To: T1_IP) and Connection_Request (From: Nl_IP, To: Tn_IP) are sent.
In steps 414 and 415, when the CMTSs Tl, Tn that receive the connection requests may reply with connection acceptance. Messages Connection_Accept (From: Tl__IP, To: Nl_IP) and Connection_Accept (From: Tn_IP, To: Nl_IP) are sent.
In steps 416 and 417, the new TCP connections opened from first node Nl become active and are actively exchanging policy messages as if the shutdown never took place. The recovered node Nl is now ready to service existing DQoS flows and to create new ones . Messages Estabilished_Connection(From: Nl_IP, To: Tl_IP) and Estabilished_Connection(From: Nl_IP, To: Tn_IP) are exchanged.
In step 418 and 419, the existing active connections of the second node N2 may remain active and may be exchanging policy messages. Messages Estabilished_Connection(From: N2_IP, To: T1_IP) and Estabilished_Connection(From: N2_IP, To: Tn_IP) are exchanged.
Similarly, just as when the shutdown took place, the CMTSs Tl, Tn may only see that a connection is re-established, but
my not be aware that the re-estabilishment is now coining from a different entity.
Once the policy sessions are established, from the CMTS perspective, call control is carried on as usual, as it did before or after the active node shutdown.
17
As the backup node N2 removes the first node virtual IP address from its system, it notifies, in step 411, the recovered node Nl to take over its duties . Message IP_Address_Removed(Nl) is sent.
In steps 412 and 413, upon receipt of the above notification, the active node creates the virtual IP address for itself, node where the virtual IP address actually belongs and, from its recovered virtual IP address, initiates connections to all CMTSs Tl, Tn configured on the system to establish the relevant policy sessions. Messages Connection_Request (From: Nl_IP, To: Tl_IP) and Connection_Request (From: Nl_IP, To: Tn_IP) are sent.
In steps 414 and 415, when the CMTSs Tl, Tn that receive the connection requests may reply with connection acceptance. Messages Connection_Accept (From: Tl_IP, To: Nl_IP) and Connection_Accept (From: Tn_IP, To: Nl_IP) are sent.
In steps 416 and 417, the new TCP connections opened from first node Nl become active and are actively exchanging policy messages as if the shutdown never took place. The recovered node Nl is now ready to service existing DQoS flows and to create new ones . Messages Estabilished_Connection(From: Nl_IP, To: Tl_IP) and Estabilished_Connection(From: Nl_IP, To: Tn_IP) are exchanged.
In step 418 and 419, the existing active connections of the second node N2 may remain active and may be exchanging policy messages. Messages Estabilished_Connection(From: N2_IP, To: T1_IP) and Estabilished_Connection(From: N2_IP, To: Tn_IP) are exchanged.
Similarly, just as when the shutdown took place, the CMTSs Tl, Tn may only see that a connection is re-established, but
18
my not be aware that the re-establishment is now coming from a different entity.
Once the policy sessions are established, from the CMTS perspective, call control is carried on as usual, as it did before or after the active node shutdown.
19
List of reference signs
101 Connection_Request (From: Nl_IP, To: Tl_IP)
102 ConnectionJRequest (From: Nl-IP, To: Tn_IP)
103 Connection_Accept(From: Tl_IP, To: Nl_IP) 104 Connection_Accept (From: Tn_IP, To: Nl_IP)
105 Connection_Request (From: N2_IP, To: Tl_IP)
106 Connection_Request (From: N2_IP, To: Tn_IP)
107 Connection_Accept (From: Tl__IP, To: N2_IP)
108 Connection_Accept (From: Tn_IP, To: N2_IP) 201 Estabilished_Connection(From: Nl_IP, To: Tl_IP)
202 Estabilished_Connection(From: Nl_IP, To: Tn_IP)
203 Estabilished_Connection(From: N2_IP, To: Tl_IP)
204 Estabilished_Connection(From: N2_IP, To: Tn_IP)
205 Node Nl is gracefully taken out of service 205a Connection_Close (From: Nl_IP, To: Tl_IP)
205b Connection_Close (From: Nl_IP, To: Tn_IP)
206 Takeover (Nl)
207 Connection_Request(From: Nl_IP, To: Tl_IP)
208 Connection_Request (From: N1_IP, To: Tn_IP) 209 Connection_Accept (From: Tl_IP, To: Nl_IP)
210 Connection_Accept (From: Tn_IP, To: Nl_IP)
211 Estabilished_Connection(From: Nl_IP, To: Tl_IP)
212 Estabilished_Connection(From: Nl_IP, To: Tn_IP)
213 Estabilished_Connection(From: N2_IP, To: Tl_IP) 214 Estabilished_Connection(From: N2_IP, To: Tn_IP)
305 Node Nl crashes
305a Loss of node Nl connections
305b Loss of node Nl connections
306 Node_Failure(Nl) 401 Estabilished_Connection(From: Nl_IP, To: Tl_IP)
402 Estabilished_Connection(From: Nl_IP, To: Tn_IP)
403 Estabilished_Connection(From: N2_IP, To: Tl_IP)
404 Estabilished_Connection(From: N2_IP, To: Tn_IP)
405 Node Nl is put back in service 406 Get_Context_Data
407 Context Data,..., Context Data Complete
408 Remove_IP_Address (Nl )
20
409 Connection_Close(From: Nl_IP, To: Tl_IP)
410 Connection_Close(From: Nl_IP, To: Tn_IP)
411 IP_Address_Removed (Nl)
412 Connection_Request (From: Nl__IP, To: Tl_IP) 413 Connection_Request (From: Nl_IP, To: Tn_IP)
414 Connection_Accept (From: Tl_IP, To: N1_IP)
415 Connection_Accept (From: Tn_IP, To: Nl_IP)
416 Estabilished_Connection(From: Nl_IP, To: Tl_IP)
417 Estabilished_Connection(From: Nl_IP, To: Tn_IP) 418 Estabilished_Connection(From: Nl_IP, To: Tl_IP)
419 Estabilished_Connection(From: Nl_IP, To: Tn_IP)
Nl, N2 nodes of a CMS
Tl , .. , Tn n CMTSs
List of Acronyms
CMS call management server
CMTS cable modem termination system
COPS common open policy server DQoS dynamic quality of service
IP internet protocol
PSTN public switched telephone network
QoS quality of service
TCP transmission control protocol
List of cited industry specifications and standards
PacketCable developed by CableLabs
Euro-PacketCable consists of PacketCable and of additional European specifications (ETSI)
Claims
1. A method for providing high-availability with Dynamic Quality of Service, hereinafter referred as DQoS, in a cable network system; said system comprising a call management server, hereinafter referred as CMS, and a plurality of cable modem terminating systems (Tl, Tn) , hereinafter referred as CMTSs, providing DQoS calls to subscribers; said CMS comprising at least two nodes (Nl, N2) interconnected with each other and connectable with said plurality of CMTSs; a first node (Nl) of said at least two nodes (Nl, N2) being an active node and having, with said plurality of CMTSs (Tl, Tn) , a plurality of IP connections running DQoS calls; a second node (N2) of said at least two nodes (Nl, N2) acting as a backup node of said first node (Nl) ; said method characterized in that it comprises the steps of: a) by each of said at least two nodes (Nl, N2), using a virtual IP address so that said plurality of CMTSs (Tl, Tn), when connected with said at least two nodes (Nl, N2), sees said at least two nodes (Nl, N2) of said CMS as at least two separate CMSs; b) storing gate information relating to said first node DQoS calls in both said first and second nodes (Nl, N2); and wherein, when said first node (Nl) is shutdown (205; 305), said method further comprises the steps of: c) notifying (206; 306) said second node (N2) about the shutdown of said first node; d) by aaid second node (N2) , taking over said virtual IP address of said first node (Nl), after the closure of said first node IP connections (205a, 205b; 305a, 305b) ; and e) by said second node (N2), assuming (207, 208, 209, 210, 211, 212) said first node IP connections, on behalf of said first node (Nl) , by using said first node virtual IP address and by using said stored gate information. 22
2. The method according to claim 1, wherein, when said first node (Nl) is shutdown in a controlled way, said IP connection closure (205a, 205b) is • performed by said first node (Nl) ; and wherein said step c) is performed by said first node (Nl) .
3. The method according to claim 1 , wherein, when said first node (Nl) is shutdown in an uncontrolled way, said IP connection closure (305a, 305b) happens because of a failure.
4. The method according to any of the preceding claims, wherein said second node (N2) , acting as a backup node of said first node (Nl) , is itself an active node having, with said CMTSs (Tl, Tn), its own plurality of IP connections running DQoS calls .
5. The method according to any of the preceding claims , wherein said DQoS calls comprise active and/or transient calls.
6. The method according to any of the preceding claims, wherein said CMS is a VoIP switch.
7. The method according to any of the preceding claims, wherein said DQoS is a protocol defined in PacketCable or in Euro PacketCable standard.
8. The method according to any of the preceding claims, wherein said plurality of IP connections carry Common Open Policy Server messages . 23
9. The method according to any of the preceding claims, wherein, when said shutdown first node (Nl) is ready to be put back into service (405), said method further comprises:
- by said first node (Nl) , requesting (406) from said second node (N2) the gate information relating to the DQoS calls run on behalf of said first node (Nl) ;
- by said second node (N2), sending (407) to said first node
(Nl) said requested gate information;
- by said second node (N2), closing (409, 410) the plurality of IP connections opened on behalf of said first node
(Nl);
- by said second node (N2) , removing said first node virtual IP address and notifying (411) said first node (Nl) ;
- by said first node (Nl), assuming (412, 413, 414, 415, 416, 417) its own plurality of IP connections, by using its own virtual IP address and by using said requested gate information.
10. A system for providing high-availability with Dynamic Quality of Service, hereinafter referred as DQoS, in a cable network system; said cable network system comprising a call management server, hereinafter referred as CMS, and a plurality of cable modem terminating systems (Tl, Tn) , hereinafter referred as CMTSs7 providing DQoS calls to subscribers ; said CMS comprising at least two nodes (Nl, N2) interconnected with each other and connectable with said plurality of CMTSs; a first node (Nl) of said at least two nodes (Nl, N2) being an active node and having, with said plurality of CMTSs (Tl, Tn), a plurality of IP connections running DQoS calls,- a second node (N2) of said at least two nodes (Nl, N2) acting as a backup node of said first node (Nl) ; said system for providing high-availability with DQoS characterized in that it comprises: f) in each of said at least two nodes (Nl, N2) , means for using a virtual IP address so that said plurality of CMTSs 24
(Tl, Tn), when connected with said at least two nodes (Nl, N2) , sees said at least two nodes (Nl, N2) of said CMS as at least two separate CMSs; g) means for storing gate information relating to said first node DQoS calls in both said first and second nodes (Nl, N2 ) ; and wherein, when said first node (Nl) is shutdown (205; 305), said system for providing high-availability with DQoS further comprises : h) means for notifying (206; 306) said second node (N2) about the shutdown of said first node; i) in said second node (N2) means for taking over said virtual IP address of said first node (Nl) , after the closure of said first node IP connections (205a, 205b; 305a, 305b) ; and j) in said second node (N2) , means for assuming (207, 208, 209, 210, 211, 212) said first node IP connections, on behalf of said first node (Nl) , using said first node virtual IP address and by using said stored gate information.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US65872005P | 2005-03-04 | 2005-03-04 | |
| US60/658.720 | 2005-03-04 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2006094671A1 true WO2006094671A1 (en) | 2006-09-14 |
Family
ID=36282651
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/EP2006/001789 WO2006094671A1 (en) | 2005-03-04 | 2006-02-27 | Providing high availability with dqos |
Country Status (1)
| Country | Link |
|---|---|
| WO (1) | WO2006094671A1 (en) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5473599A (en) * | 1994-04-22 | 1995-12-05 | Cisco Systems, Incorporated | Standby router protocol |
-
2006
- 2006-02-27 WO PCT/EP2006/001789 patent/WO2006094671A1/en not_active Application Discontinuation
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5473599A (en) * | 1994-04-22 | 1995-12-05 | Cisco Systems, Incorporated | Standby router protocol |
Non-Patent Citations (4)
| Title |
|---|
| "Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 24: MTA Basic Access ISDN Interface (MTA-ISDN); ETSI TS 101 909-24", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. AT-Digital, no. V111, May 2004 (2004-05-01), pages 1 - 41, XP014016113, ISSN: 0000-0001 * |
| CABLELABS: "Dynamic Quality-of-Service", CABLELABS, 28 January 2005 (2005-01-28), pages I-VIII,1,20,54-84, XP002381530, Retrieved from the Internet <URL:http://www.cablelabs.com/specifications/archives/PKT-SP-DQOS1.5-I01-050128-Superseded.pdf> [retrieved on 20060517] * |
| CISCO: "Cisco PacketCable Primer", INTERNET ARTICLE, 2003, pages 1 - 26, XP002381723, Retrieved from the Internet <URL:http://www.cisco.com/warp/public/cc/so/neso/ns320/voip_wp.pdf> [retrieved on 20060517] * |
| LI T ET AL: "Cisco Hot Standby Router Protocol (HSRP)", IETF RFC, March 1998 (1998-03-01), pages 1 - 17, XP002269653 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5974114A (en) | Method and apparatus for fault tolerant call processing | |
| US6600735B1 (en) | Internet telephone connection method, bandwidth controller and gate keeper | |
| EP1532799B1 (en) | High availability software based contact centre | |
| US9332037B2 (en) | Method and apparatus for redundant signaling links | |
| US7539127B1 (en) | System and method for recovering from endpoint failure in a communication session | |
| US20030149735A1 (en) | Network and method for coordinating high availability system services | |
| US8345840B2 (en) | Fast detection and reliable recovery on link and server failures in a dual link telephony server architecture | |
| US8055765B2 (en) | Service take-over method based on apparatus disaster recovery, service transfer apparatus and backup machine | |
| US6002665A (en) | Technique for realizing fault-tolerant ISDN PBX | |
| EP2587774B1 (en) | A method for sip proxy failover | |
| US5077730A (en) | Method of auditing primary and secondary node communication sessions | |
| EP2774323B1 (en) | Method, communication system and non-transitory computer readable medium for optimizing network performance after a temporary loss of connection | |
| WO2013164917A1 (en) | Mobile communication system, call processing node, and communication control method | |
| EP1040684A1 (en) | Method for maintaining reliability in a service network | |
| EP2456163B1 (en) | Registering an internet protocol phone in a dual-link architecture | |
| WO2006094671A1 (en) | Providing high availability with dqos | |
| US20050182763A1 (en) | Apparatus and method for on-line upgrade using proxy objects in server nodes | |
| KR20200072941A (en) | Method and apparatus for handling VRRP(Virtual Router Redundancy Protocol)-based network failure using real-time fault detection | |
| JP2003078567A (en) | Distributed reliable communication system and its controller and failure detecting method and its program and recording medium | |
| US7675850B2 (en) | Apparatus for realizing soft-switch allopatric disaster recovery based on packet network | |
| KR100713072B1 (en) | Duplexed softswitch system and method thereof | |
| Cisco | Taking Corrective Action on Events and Alarms | |
| KR100871953B1 (en) | Media gateway and method for processing calls in a media gateway | |
| CN103138998B (en) | A kind of detection of proxy-state, device and system | |
| JP2007258791A (en) | System and method for processing call |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| NENP | Non-entry into the national phase |
Ref country code: RU |
|
| WWW | Wipo information: withdrawn in national office |
Country of ref document: RU |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 06707300 Country of ref document: EP Kind code of ref document: A1 |
|
| WWW | Wipo information: withdrawn in national office |
Ref document number: 6707300 Country of ref document: EP |