Internet Draft Vikas Bajaj Document:draft-hss-megaco-control-association- Vivek Bansal state-machine-00.txt Expires: February 2002 Shiv Kumar Prashant Jain MEGACO Control Association State Machine draft-hss-megaco-control-association-state-machine-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ôwork in progress.ö The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document captures the description and interpretation of all the functional procedures and the related procedural parameters, pertaining to MG-MGC control association, as described in the MEGACO protocol. It suggests the various states, the MG and MGC state machines goes through, during the life cycle of such an association. It goes on to Vikas, Vivek, Shiv, Prashant 1 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 describe the various inputs each association state of an MG/MGC may deal with and how the MG/MGC may react towards them. This document should be read as the supplement to the base protocol. Table of Contents Status of this Memo 1 Abstract 1 1. Scope 4 2. References 4 3. Abbreviations 4 4. Conventions 4 5. Control Association Overview 5 6. Assumptions 5 7. Definitions related to Control Association 6 8. The Service Change Command 8 8.1. Usage of Service Change Method 9 9. Overview of Protocol Control Association Procedures 13 9.1. Phases in a Control Association Life Cycle 14 9.2. Control Association States Description 17 10. MG State Machine 18 10.1. INACTIVE STATE 20 10.1.1. Cold Start from MG application 21 10.1.2. Redundant Takeover at standby MG 21 10.2. RIP (RESTART IN PROGRESS) 21 10.2.1. Registration Response from Peer 22 10.2.2. Forced Shutdown from MG application 23 10.2.3. Graceful Shutdown from MG application 23 10.2.4. Failover at active MG 23 10.2.5. Peer Failure Detection at MG 23 10.2.6. Transport Parameters Change at MG 24 10.2.7. Restart from MGC 24 10.2.8. Handoff at current controlling MGC 25 10.2.9. Forced Shutdown at MGC 25 10.2.10. Protocol message from Peer 26 10.2.11. Local Activity at MG application 26 10.3. AIS (ASSOCIATION IN SERVICE) 26 10.3.1. Forced Shutdown at MG 26 10.3.2. Graceful Shutdown at MG 27 10.3.3. Failover at active MG 27 10.3.4. Peer Failure Detection at MG 28 10.3.5. Transport Parameters Change at MG 28 10.3.6. Restart from MGC 29 10.3.7. Handoff at current controlling MGC 29 10.3.8. Forced Shutdown at MGC 30 10.4. SIP (SHUTDOWN_IN_PRGS) 30 10.4.1. Forced Shutdown at MG 30 10.4.2. Graceful Shutdown At MG 30 10.4.3. Peer Failure Detection at MG 31 Vikas, Vivek, Shiv, Prashant 2 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 10.4.4. Restart from MGC 32 10.4.5. Handoff from MGC 32 10.4.6. Forced Shutdown from MGC 33 10.5. SWIP (SWITCHOVER_IN_PRGS) 33 10.5.1. Forced Shutdown At MG 33 10.5.2. Graceful Shutdown At MG 34 10.5.3. Failover at active MG 34 10.5.4. Transport Parameters Change at MG 35 11. MGC State Machine 35 11.1. RIP (RESTART_IN_PROGRESS) 37 11.1.1. Cold Start At MG 38 11.1.2. Forced Shutdown At MG 38 11.1.3. Graceful Shutdown At MG 39 11.1.4. Failover at active MG 39 11.1.5. Redundant Takeover at standby MG 39 11.1.6. Peer Failure Detection at MGC 40 11.1.7. Handoff at Active MGC 40 11.1.8. Forced Shutdown at MGC 40 11.2. AIS (ASSOCIATION IN SERVICE) 41 11.2.1. Forced Shutdown at MG 41 11.2.2. Graceful Shutdown at MG 41 11.2.3. Failover at active MG 42 11.2.4. Transport Parameters Change at MG 42 11.2.5. Transport Parameters Change at MGC 42 11.2.6. Peer Failure Detection at MG 43 11.2.7. Handoff at Active MGC 43 11.2.8. Restart From MGC 44 11.2.9. Forced shutdown At MGC 44 11.3. SWIP (SWITCHOVER_IN_PROGRESS) 44 11.3.1. Forced Shutdown at MG 45 11.3.2. Graceful shutdown request from MG 45 11.3.3. Failover at active MG 46 11.3.4. Redundant Takeover at standby MG 46 11.3.5. Forced Shutdown at MGC 46 11.3.6. Restart From MGC 46 11.3.7. Handoff at Active MGC 47 11.3.8. Re-registration request from active or standby MG 47 11.4. SIP (SHUTDOWN_IN_PROGRESS) 48 11.4.1. Forced Shutdown at MG 48 11.4.2. Graceful Shutdown at MG 48 11.4.3. Failover at active MG 49 11.4.4. Redundant Takeover at standby MG 49 11.4.5. Forced Shutdown At MGC 49 AuthorÆs Addresses 49 Vikas, Vivek, Shiv, Prashant 3 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 1. Scope This document puts into words, the interpretation the authors have, after studying the MEGACO RFC, Implementation Guides and discussions in the MEGACO mailing list, Annex L and the manner in which the control association state machine of MG and MGC work while executing the respective control association procedures. There is still a certain amount of lack of clarity regarding the topic of control associations in MEGACO perspective as a whole. So to help arrive at some kind of conclusion, the authors have made some assumptions about these unclear aspects of the protocol. Changes in these assumptions may affect the overall interpretation of this topic. Nevertheless the authors have tried their utmost to preserve the existing description of the protocol. The authors have also taken into account various converging assumptions, which were discussed, extensively on the mailing list. 2. References [1] F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers, ôMedia Gateway Control Protocol Version 1.0ö, RFC 3015, November 2000. [2] H.248 Annex L û Error Codes and Service Change Reason Description for Approval. [3] H.248 Series ImplementersÆ Guide (09/05/2001) Ver. 7. 3. Abbreviations This recommendation defines the following terms. GW GateWay IANA Internet Assigned Numbers Authority IP Internet Protocol MG Media Gateway MGC Media Gateway Controller NM Network Management 4. Conventions The key words ôMUSTö, ôMUST NOTö, ôREQUIREDö, ôSHALLö, ôSHALL NOTö,öSHOULDö, ôSHOULD NOTö, ôRECOMMENDEDö, ôMAYö, and ôOPTIONALö in this document are to be interpreted as described in RFC2119. Vikas, Vivek, Shiv, Prashant 4 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 5. Control Association Overview A control association can be defined as the logical session between two key entities of the decomposed gateway architecture viz., MG and MGC. MEGACO protocol has defined a set of control association procedures between these two entities to achieve the distributed call control functionality. The control association functionality has been visualized as a disjoint set of procedures independent of the call processing/management activity. However any change (permanent or transient) in the state of the control association between MG and MGC may or may not affect the call-related aspects both at MG and MGC. +--------------------------+ +--------------------------+ | +------------------+ | | +------------------+ | | |Call Management | | | |Call Processing | | | |Entity | | | |Entity | | | +------------------+ | | +------------------+ | | | | | | +------------------+ | | +------------------+ | | |Association | | | |Association | | | |Management Entity | <------------> |Management Entity | | | +------------------+ | | +------------------+ | | | | | +--------------------------+ +--------------------------+ MGC MG 6. Assumptions (1) Peer Entities shall be identified based on the MID field in the message header field of the protocol message. (2) Primary and secondary MGCs may be supporting different versions and gateway service profiles. (3) Service Change command with method as ôRESTARTö on ROOT terminations indicates that all terminations are in service, by default. (4) Synchronization between redundant MGs and that between redundant MGCs is outside the scope of the MEGACO protocol. (5) Since the Mid should not change during the course of the control association, MGs running in redundant configuration must have same MIDs. Vikas, Vivek, Shiv, Prashant 5 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 (6) MGCs running in redundant configuration may or may not have same MIDs. (7) Secondary MGCs being provisioned at MG may or may not be running in the redundant configuration. (8) ôService Change Reasonö parameter can be understood as the qualifier to the information that the ômethod field conveys while indicating the change in the control association through the service change command. (9) The ôService Change Addressö and ôMGCIdToTryö parameters are only applicable on ROOT termination. When sent in a service change command would convey the transport address to which future communication should be made. (10) A MG is pre-provisioned by a management mechanism outside the scope of this protocol with a Primary and (optionally) an ordered list of Secondary MGCs. The pre-provisioning of MGCs at MG reveals all the transport parameters of the specified MGCs, at which MG would initially try to create the logical session with one of them. The MIDs of the respective MGCs may or may not be configured along with the transport parameters. However, MGC need not be provisioned with the list of MGs, from which the control associationsÆ request can be received during the start up phase. The controlled MGs would be identified by their MIDs, retrieved from the first service change command being received from each of them. The MID of the respective MGs must not change during the life cycle of the control association. Vikas, Vivek, Shiv, Prashant 6 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 7. Definitions related to Control Association The terms mentioned below are important and are to be kept in mind while reading the document. These should be referred to as and when required. A. Cold Start: It is defined as the fresh start of the Media Gateway. All the terminations would be assumed to be in-service by default. All the terminations would be present in the NULL context. In other words, no active calls would be running over any of the associated terminations present in the specified control association. B. Planned Switchover: It is defined as a planned activity being initiated either by MG or MGC application or the NM entity, which triggers the generation of Service Change command from the entity which is going out-of-service and informs about the switchover to a redundant entity. C. Transparent Switchover: It is defined as an activity wherein the MGC or MG does not come to know about the redundant takeover that happened on the other entity involved in the control association, as the transport parameters of the affected entity (MG or MGC) have been retained. D. Unplanned Switchover: It is defined as an unplanned activity occurring at MG, which caused it to go abruptly out-of-service. Moreover due this activity, redundant MG has taken over the control and it sends the Service Change command. Here there would not be any protocol message that was generated from the MG that went down. E. Warm Redundancy: It is defined as the switchover operation from an active to a standby entity, wherein all the existing calls on the failed entity have been lost, although a new entity (standby) has taken over the control association. Both MG and MGC can have this kind of implementation. F. Hot Redundancy: It is defined as the switchover operation between an active and a standby entity, wherein all the existing calls have survived over the standby one, even though the new entity (standby) has taken over the control association. All the call states were preserved. Both MG and MGC can have this kind of implementation. G. Cold Boot: It is defined as the boot operation in which MG was able to preserve the statically provisioned data by NM as well as Vikas, Vivek, Shiv, Prashant 7 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 the dynamic configuration data provided in NULL context by MGC, however all the active contexts or calls were lost due to some internal failure. H. Warm Boot: It is defined as the boot operation in which MG was able to preserve the static provisioned data by NM as well as the dynamic configuration data provided by MGC in NULL context. In Warm Boot, all the active contexts or calls were survived at the MG, however some of the transient transactions are lost. I. Message Identifier (MID): This field is an identifier (either the transport address or just a logical identifier) that reveals the identity of the entity, which is originating the protocol message. It is the mandatory part of the every protocol message that is exchanged between MG and MGC. 8. The Service Change Command MEGACO protocol defines all the control association procedures using a Service Change command on ROOT termination. Each such command would encapsulate a set of control parameters that would be utilized while executing the related procedures. A service change command on ROOT governs the change in the state of the control association in terms of the change in either the communication status between MG- MGC or the change in the existing call states. It is worth noting that a Service Change with termination ID as ALL or ô*ö just means that terminations in the originating entity have undergone a state change in the ôservice-stateö. This may impact the existing calls that are active over the specified terminations. However there is no change in the state of the control association. The control parameters pertaining to a service change command are listed below. A. Service Change Method. B. Service Change Reason. C. Service Change Profile. D. Service Change Version. E. Service Change Address. F. Service Change MGCIdToTry. G. Service Change Delay. H. Service Change Timestamp. Vikas, Vivek, Shiv, Prashant 8 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 Of all the above parameters, the ôservice change methodö is the main attribute that primarily dictates the behavioral change in the state of a control association. The other parameters, which are the part of the service change command, help the remote entity to execute the relevant protocol-defined procedures with respect to the state change in the control association. For instance, in case of command issued with ôDISCONNECTEDö method from MG, it is conveyed to MGC that the MG was temporarily disconnected with MGC. Here MGC may infer that there may be some synchronization problem between the two and an AUDIT command may be issued. The ôservice change reasonö, if specified, should be looked into to determine the severity of change in the states of the calls being realized by MG and then act accordingly. The ôservice change timestampö, if specified, conveys the exact time when the service change command was issued. This would help the receiving entity in making decisions irrespective of the transport delay. 8.1. Usage of Service Change Method The ôService Change Methodö parameter on ROOT specifies the change in the control association between MG and MGC. The change in service may be because of either of the following functional changes. Note that the Service Change Reason conveys the gravity of the change in call states, as and when required. These two aspects can be understood more clearly as one goes through the interpretation of different methods defined in the protocol. a. Graceful: 1. This method can only be sent from MG to MGC. It indicates that the MG will be taken out of service after the specified Service Change Delay. 2. The established connections or calls over the individual terminations are not yet affected. 3. After the specified delay, all the calls would be terminated abruptly, and all the terminations would be moved into the null Vikas, Vivek, Shiv, Prashant 9 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 context at MG. The controlling MGC will not send any SUBTRACT command to MG and clear all the call contexts at its end. 4. The ôgracefulö with delay NULL means that MG would terminate the control association AFTER all the call contexts are cleared. 5. In either of the above cases, the MGC should refrain from establishing new calls during the course of the graceful shutdown and should try to clear the existing call contexts gracefully. b. Forced: 1. This method can either be sent from MG to MGC or vice versa. 2. It indicates that the originating entity (MG/MGC) was taken abruptly out of service and any established connections or calls active over the associated terminations were lost, consequently all the terminations at its end were moved to null context. 3. The receiving entity (MGC/MG) is responsible for cleaning up the call contexts at its end. c. Restart: 1. This method can be sent from MG to MGC or vice versa. When sent from the MG to the MGC, 2. At COLD start, it indicates that the MG has already come into service afresh. All the terminations are assumed to be in service. 3. If non-zero delay is specified, it signifies that although the MG is capable of communicating with the controlling MGC, the service or the call-carrying capability would be restored on the physical terminations, associated with ôROOTö termination, AFTER the specified delay. When sent from the MGC to the MG, 4. It indicates the MGC wants MG to restart. Vikas, Vivek, Shiv, Prashant 10 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 5. If non-zero delay is specified, it signifies that the service or the call-carrying capability would be restored on the physical terminations, associated with ôROOTö termination, AFTER the specified delay. 6. In case of warm boot or cold boot, it indicates change in the protocol version supported by the remote. In this case, the already existing calls at MG may or may not be retained. d. Disconnected: 1. This method can only be sent from MG to MGC. 2. This method indicates that the MG lost communication with the controlling MGC either because of its transient failure, which was subsequently restored or MG detects failure of its controlling MGC and tries to contact it again. 3. The transient failure may be because of: - Failures of the underlying transport or there was some change in the transport parameters of MG. - If there is some call-state loss at MG. - Switchover (either planned or unplanned) to standby MG. Here the standby MG generates this method. 4. In either of the above scenarios, the MGC may audit the MG to synchronize its state. e. Handoff: 1. This method can either be sent from MG to MGC or vice versa. When sent from the MGC to the MG, 2. This method indicates that the MGC is going out of service and a control association must be established with the new MGC. However sent from the MG to the MGC, Vikas, Vivek, Shiv, Prashant 11 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 3. This indicates that the MG is attempting to establish a new control association in accordance with a Handoff received from the MGC with which it was previously associated. 4. The above operation should be transparent to the MG application. 5. In this case, MGC must audit the requesting MG to resynchronize its state, in the absence of which MG assumes that MGC has failed and start trying secondary ones. f. Failover: 1. This method can only be sent from MG to MGC. 2. When sent from the MG, which is going down, this method indicate the primary MG is out of service and a secondary MG would be taking over. 3. Otherwise, this method reveals that MG detects the failure of its controlling MGC and is now trying the secondary MGC to re- establish the control association. 4. In either of the above cases, the already existing calls at MG may or may not be retained. Vikas, Vivek, Shiv, Prashant 12 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 The valid combinations of the Method vis-€-vis other Service change parameters have been captured in the following table: +--------+-------+--------+--------+--------+--------+------------+ |Method/ | DELAY |DIRECTION|VERSION |PROFILE |SVC ADDR| MGCIdToTry| |Parameters | | | | | | +--------+-------+--------+--------+--------+--------+------------+ |RESTART | A | MG->MGC| A | A | A | NA | | | | | | | | | +--------+-------+--------+--------+--------+--------+------------+ |FORCED | NA | MG->MGC| NA | NA | NA | NA | | | | MGC->MG| | | | | +--------+-------+--------+--------+--------+--------+------------+ |GRACEFUL| A | MG->MGC| NA | NA | NA | NA | | | | | | | | | +--------+-------+--------+--------+--------+--------+------------+ |DIS- | | | | | | | |CONNECTED NA | MG->MGC| NA | NA | A | NA | | | | | | | | | +--------+-------+--------+--------+--------+--------+------------+ |FAILOVER| NA | MG->MGC| A | A | NA | NA | | | | | | | | | +--------+-------+--------+--------+--------+--------+------------+ |HANDOFF | NA | MGC->MG| A | A | NA | A | | | | MG->MGC| | | | | +--------+-------+--------+--------+--------+--------+------------+ A - Allowed NA- Not Allowed 9. Overview of Protocol Control Association Procedures As already mentioned, protocol has defined a set of procedures to address the various aspects of control association between MG and MGC. Apart from this, some guidelines have been laid for initial provisioning of MG before the actual control association is established between MG and MGC. All the control association procedures that have been discussed in the protocol cater to a set of scenarios. Hence the relevant procedures have been categorized into different phases, depending on the behavioral changes the control association undergoes during its life cycle, for all the respective scenarios. This categorization would form the basis on which the complete state machine design of the MG-MGC control association would rely upon. Vikas, Vivek, Shiv, Prashant 13 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 9.1. Phases in a Control Association Life Cycle Further based on whatever protocol has defined, the life cycle of a control association can be divided into the following phases. 1. Association Inactive Phase. 2. Association Restart Phase. 3. Association Active Phase. 4. Association Shutdown Phase. 5. Association Switchover Phase. 1) Inactive Phase: During this phase of operation, both MG and MGC would just have the necessary pre-provisioned data (specifically the transport parameters) and they are waiting for a trigger from the application to initiate the control association related procedures. 2) Restart Phase: During this phase of operation, the control association between MG and MGC is restarted between the concerned MG and the MGC. The following scenarios and the corresponding procedures can be addressed in this phase of operation. . A control association between the concerned MG and MGC is initiated from MG at its Cold start. No calls are present at the moment. Method: RESTART from MG. Reason: Cold Boot or Service Restored. . MG wants to change its protocol version. The calls may or may not get affected (call states change would be decided by ôService Change Reasonö, if present). Method: RESTART from MG. Reason: Warm Boot, Cold Boot or Service Restored. . MGC wants to change its protocol version. The calls may or may not get affected (call states change would be conveyed to by ôService Change Reasonö, if present). Method: RESTART from MGC. Reason: Warm Boot, Cold Boot or Service Restored. Vikas, Vivek, Shiv, Prashant 14 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 . MGC wants to initiate a reboot operation at MG due to its own failure or in case of version change at its end. The corresponding service change request from MGC may be generated only if the MG was already registered with the former. Method: RESTART from MGC. Reason: Warm Boot, Cold Boot. 3) Active Phase: During this phase of operation, MG-MGC control association is alive and normal protocol commands get exchanged across the two entities as defined in the protocol. In this phase of operation, MG may exchange the control association command (service change on ROOT) intending to resynchronize the states of the terminations engaged in the association or to convey about the future behavior of the control association. Note that the ôservice change command on ROOTö is not allowed from MGC for the state synchronization with the peer. The following two possibilities may arise in this phase of operation. The following control association scenarios and the corresponding procedures can be addressed in this phase of operation. . If there is a transient failure at MG, either due to a problem in the underlying transport layer, or there was a transparent switchover at MG but it was recovered subsequently. Method: DISCONNECTED from MG. Reason: Cold Boot or Warm Boot. . If there is going to be a service shutdown at MG after some planned duration, MG may initiate a service change command to the peer MGC to convey the same information so that the latter may act accordingly. However, the existing association is not affected at all. Method: GRACEFUL from MG. Reason: None. . If there is a planned switchover at MG to a standby entity and the new entity was realizing either Warm or Hot Redundancy. Method: DISCONNECTED from MG. Reason: Cold Boot or Warm Boot. Vikas, Vivek, Shiv, Prashant 15 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 4) Association Switchover Phase: This phase can be visualized as the activity involved in bringing the control association back to the active phase by switching over to a different entity. This switchover to a different remote may occur either implicitly (peer failure detection locally) or explicitly (through failure notification from remote) The following control association scenarios and the corresponding procedures can be addressed in this phase of operation. . MGC detects the failure of its controlled MG and it waits for a service change request from MG (either it may be active or the standby), to re-establish the control association. Method: MGC expects either RESTART or DISCONNECTED. Reason: Cold Boot or Warm Boot. . MGC receives the failure indication from its controlled MG and it waits for a re-registration request from either the active or the standby MG afterwards. From active MG Method: FAILOVER. Reason: MG Impending Failure. Subsequently from standby MG Method: RESTART or DISCONNECTED. Reason: Cold Boot or Warm Boot. . MG detects the failure of its controlling MGC and it tries the secondary MGCs in order, to re-establish the control association. Method: FAILOVER from MG. Reason: MGC Impending Failure. . MG detects the failure of its controlling MGC and the control association is also not established with secondary MGCs and the failed one is attempted again. Method: DISCONNECTED from MG. Reason: MGC Impending Failure. Vikas, Vivek, Shiv, Prashant 16 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 . MG tries to register with the handed-off MGC as redirected by its controlling MGC to re-establish the control association with the newly specified MGC. Method: HANDOFF from MG. Reason: MGC Directed Change. 5) Association Shutdown Phase: This phase can be visualized as the period during which the originating entity conveys to the remote entity (MG or MGC) about its own failure. Additionally, the sending entity may indicate that another entity would come up to take up the control of the specified association. The following control association scenarios and the corresponding procedures can be addressed in this phase of operation. - There is a planned switchover activity being initiated at MG due to a local failure or for maintenance reasons and the same is conveyed to MGC. Method: FAILOVER from MG. Reason: MG Impending Failure. - There is a planned switchover activity being initiated at MGC due to a local failure or for maintenance reasons and the same is conveyed to MG. Method: HANDOFF from MGC. Reason: MGC Impending Failure. - There is a forced shutdown at MG or MGC and the specified entity wishes to convey this information to its peer. Both MG and MGC would terminate all the active calls at their ends. Method: FORCED from MGC or MG. Reason: None. 9.2. Control Association States Description The input triggers to the state machine would be extracted from the identified scenarios in the above section and the different states inside the state machine are determined from the identified phases. Vikas, Vivek, Shiv, Prashant 17 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 The states, which have been designed in both MG and MGC state machines, maps one-to-one on the phases explained earlier and are listed as follows: 1. Restart In Progress. 2. Association In Service. 3. Switchover In Progress. 4. Shutdown In Progress. 5. Inactive. The list of various inputs to the state machine is as follows. 1. Cold Start at MG. 2. Registration Response from MGC. 3. Forced Shutdown at MG. 4. Graceful Shutdown at MG. 5. Failover at active MG. 6. Redundant Takeover at standby MG. 7. Peer Failure Detection at MG. 8. Transport Parameters Change at MG. 9. Restart From MGC. 10. Handoff at Active MGC. 11. Peer Failure Detection at MGC. 12. Forced Shutdown at MGC. 10. MG State Machine This section gives the actual protocol procedures that must me followed or the actual protocol commands that must be exchanged when the expected input triggered in either of the defined states. With every call flow we will also identify, what are the possible inputs that can be triggered in these states. Vikas, Vivek, Shiv, Prashant 18 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 This table maps the service change method received from peer to the control association states of MG. +------------+--------+--------+-----------+----------+----------+ |Method/ | |Restart |Association|Switchover|Shutdown | | States |Inactive|In |In |In |In | | | |Progress|Service |Progress |Progress | +------------+--------+--------+-----------+----------+----------+ |RESTART | NA | A | A | A | A | | | | | | | | +------------+--------+--------+-----------+----------+----------+ |FORCED | NA | A | A | A | A | | | | | | | | +------------+--------+--------+-----------+----------+----------+ |GRACEFUL | | | | | | | | NA | NA | NA | NA | NA | +------------+--------+--------+-----------+----------+----------+ |DISCONNECTED| NA | NA | NA | NA | NA | | | | | | | | +------------+--------+--------+-----------+----------+----------+ |FAILOVER | NA | NA | NA | NA | NA | | | | | | | | +------------+--------+--------+-----------+----------+----------+ |HANDOFF | NA | A | A | NA | A | | | | | | | | +------------+--------+--------+-----------+----------+----------+ A û Allowed NA- Not Allowed Vikas, Vivek, Shiv, Prashant 19 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 +-------------------+ | INACTIVE | | | +-----+----+--+--+--+ | | | | | | | +------------<<-----------+ Cold Start| | | of MG | +-------<<--------+ | | +--------------+ | | | Redundant Take-| | | over at Standby| | +-----V--------------+ | | | | RESTART IN | | | | | PROGRESS | | | | | | | | | +--+----+---------+--+ | | | | | | | | | | | Registration | | | +->>-------------+ | Completion and | | | MGC Forced +>>-----------+ Restart Delay | | | Shutdown | Timeout | | | | | | +---------+ | | | Failover | | | Graceful| | | | Completion | Restart Trigger | Shutdown| V | | | | from MG/MGC V | V V | | | | +---V---------+---+--+ V | | | | | ASSOCIATION IN +----+ | | | +-----+ SERVICE | | | +-----<<------+ | MG Forced Shutdown/ | +-+---+--------+---+-+ Graceful Timeout | | | | V | | +----<<-----V | | V------------+ | | | +----------+ | MGC Failure| | MG Failover | | Detected/ | +-->>------+ | | Handoff | | New Association | | V | is established +----V------------+ | +----------V----+--+ | | | | SWITCHOVER IN | | SHUTDOWN IN | | | PROGRESS | | PROGRESS | | +------------------+ +--------------+--+ | V | V------+ Figure 1: MG State Machine Transition Diagram The procedures given below show the behavior of the state machine when the expected input is given to it. Vikas, Vivek, Shiv, Prashant 20 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 10.1. INACTIVE STATE 10.1.1. Cold Start from MG application Input parameters: - Service change delay. - Service Change Address. - Service Change Version. - Service Change Profile. 10.1.1.1. Steps 1) Start the restart avalanche timer. 2) On expiry of the restart avalanche timer, send the service change request command with method as RESTART, reason as SERVICE RESTORED and the other specified parameters. 3) In addition to the generation of Service Change command, start the Restart Delay timer, if present. 10.1.1.1. New State RIP (RESTART IN PROGRESS) 10.1.2. Redundant Takeover at standby MG Input parameters: - Service Change Address. - Service Change Reason. 10.1.2.1. Steps 1) Send the service change request command with method as DISCONNECTED and the other specified parameters. 10.1.2.1. New State AIS (ASSOCIATION IN SERVICE) 10.2. RIP (RESTART IN PROGRESS) Vikas, Vivek, Shiv, Prashant 21 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 10.2.1. Registration Response from Peer Input parameters: None 10.2.1.1. Steps 1) During the registration, if all the parameters were accepted by MGC, it replies back with the successful response. a) If the delay was specified in the service change delay, then the state remains same. On expiry of the restart delay, the state is changed to AIS (ASSOCIATION IN SERVICE). b) If the delay was not specified, the state is immediately changed to (AIS) ASSOCIATION IN SERVICE. 2) If Service change address present in the service change command response from peer, modify the address of the MGC to send all the subsequent requests to MGC on the newly specified address. Association State in this case again depends upon the service change delay parameter sent in the request as described in step 1. 3) If the ServiceChangeMgcId is present in the service change command response from peer. Then, a) MG sends the service change command to MGC specified in the ServiceChangeMgcId with the same parameters. b) This procedure continues till the registration request is accepted by the new MGC. 4) If the Protocol Version is present in the Service change response. a) If MG complies with the version received in the service change response, state changes would be as described in step 1. b) If the MG is not able to comply with the version received in the service change response, it tries the secondary MGCs with the same service change Vikas, Vivek, Shiv, Prashant 22 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 parameters till the registration request is accepted by any of the configured MGCs. 10.2.2. Forced Shutdown from MG application Input parameters: None 10.2.2.1. Steps 1) Clear all the call contexts forcefully. 2) Send Service Change command to the controlling MGC with method as FORCED. 10.2.2.2. New State INACTIVE 10.2.3. Graceful Shutdown from MG application Input parameters: - Service Change Delay 10.2.3.1. Steps 1) If the Graceful delay is less than the Restart delay, then stop the Restart delay timer, then send the service change request to MGC with method as FORCED. The new state becomes INACTIVE. 2) If the Graceful delay is more that the Restart delay, send the service change request to MGC with method as GRACEFUL and delay as specified in the input parameters. The state remains unchanged. 10.2.4. Failover at active MG The MG Failover is not expected in this state. It is assumed that since there has been no call-related activity in this state. 10.2.5. Peer Failure Detection at MG Vikas, Vivek, Shiv, Prashant 23 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 If MG detects the Failure of the MGC to which it had sent the service change request. 10.2.5.1. Steps 1) Send the service change command to secondary MGCs, with the same set of parameters as sent in the initial registration message to primary MGC until registration is completed. 10.2.5.2. New State The state remains unchanged. 10.2.6. Transport Parameters Change at MG Input parameters: - Service Change Address 10.2.6.1. Steps 1) Send the service change command with method as RESTART and the specified Service Change Address. 10.2.6.2. New State State remains same. 10.2.7. Restart from MGC Input parameters: - Service Change Reason 10.2.7.1. Steps 1) Stop the Restart Delay timer if running. 2) Give the indication to the MG application to restart MG, along with the received service change reason from MGC. Vikas, Vivek, Shiv, Prashant 24 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 3) Once the restart operation is finished, MG generates the registration command to the same controlling MGC. 10.2.7.2. New State State remains unchanged. 10.2.8. Handoff at current controlling MGC Input parameters: - Service Change MGCIdToTry This input trigger could be received from MGC if the control is transferred to a new MGC. 10.2.8.1. Steps 1) Start the restart avalanche timer to prevent the avalanche at MGC. 2) Send the service change request to Handed-off MGC with method as HANDOFF and reason as MGC Impending Failure. 10.2.8.2. New State State remains unchanged. 10.2.9. Forced Shutdown at MGC This input trigger could be received when the Restart Delay timer is running. 10.2.9.1. Steps 1) MG attempts to contact the next MGC on its pre-provisioned list. Implementation may start its attempts at the beginning (that was the MGC that failed), or it attempts the next remote in the configured list. 10.2.9.2. New State RIP (RESTART_IN_PROGRESS) Vikas, Vivek, Shiv, Prashant 25 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 10.2.10. Protocol message from Peer Input parameters: None 10.2.10.1. Steps 1) If before receiving the response from MGC, MG received the protocol commands from MGC, it should reply back with the error code ôCommand received before restart responseö. 2) If after receiving the response from MGC, and if the delay timer is still running, and during this time a protocol command from MGC is received, that command should be Audit capability only. For any call related protocol commands like Add, Modify, it should return back an error ôService Unavailableö. 10.2.11. Local Activity at MG application Input parameters: None 10.2.11.1. Steps 1) If during the execution of the restart avalanche timer, a local activity is detected, then stop the restart avalanche timer 2) Send the service change request command with method as RESTART and reason as SERVICE RESTORED. 10.2.11.2. New State State remains same. 10.3. AIS (ASSOCIATION IN SERVICE) 10.3.1. Forced Shutdown at MG Input parameters: None 10.3.1.1. Steps Vikas, Vivek, Shiv, Prashant 26 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 1) Terminate all the active calls contexts on its own. 2) Send the Service Change command to the MGC with method as FORCED. 10.3.1.2. New State INACTIVE 10.3.2. Graceful Shutdown at MG Input parameters: - Service change delay 10.3.2.1. Steps 1) Start the delay timer for value specified in Service change delay. 2) Send the request to MGC with GRACEFUL method and with the specified service change delay. 3) Till the expiry of the service change delay, the state of MG control association remains ASSOCIATION IN SERVICE (AIS). 4) Delete all the call contexts abruptly after the completion of the graceful period. 5) If the NULL delay was specified, the control association must last for the duration of the time until all the active call contexts are cleared by MGC. 10.3.3. Failover at active MG Input parameters: None 10.3.3.1. Steps 1) Send the service change request to MGC with FAILOVER method. Vikas, Vivek, Shiv, Prashant 27 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 2) Since the protocol mandates that the response should go to the source address, the control association must wait for the respective replies for all pending transaction requests. 10.3.3.2. New State SIP (SHUTDOWN_IN_PRGS) 10.3.4. Peer Failure Detection at MG Input parameters: None 10.3.4.1. Steps 1) If the MG detects a failure of its controlling MGC, it attempts to contact the next MGC on its pre-provisioned list. It starts its attempts at the beginning (Primary MGC), unless that was the MGC that failed, in which case it starts at its first Secondary MGC. It sends a Service Change message with a ôFailoverö method and reason as MGC Impending Failure. 2) All new transaction requests and the outstanding transaction responses must be queued till the MGC replies back with the transaction accept. 10.3.4.2. New state SWIP (SWITCHOVER_IN_PRGS) 10.3.5. Transport Parameters Change at MG Input parameters: - Service Change Address 10.3.5.1. Steps 1) Send the service change command with method as DISCONNECTED and specify the new local address in the Service Change Address field of the command. New State Vikas, Vivek, Shiv, Prashant 28 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 State remains unchanged 10.3.6. Restart from MGC Input parameters: - Service Change Reason. - Service Change Address. 10.3.6.1. Steps 1) Give the indication to the MG application to restart MG, along with the received service change reason from MGC. 2) Once the restart operation is finished, MG generates the registration command to the same controlling MGC on the newly specified service change address. 10.3.6.2. New State RIP (RESTART IN PROGRESS). 10.3.7. Handoff at current controlling MGC Input parameters: - Service Change MGCIdToTry 10.3.7.1. Steps 1) Start the restart avalanche timer to prevent the avalanche at MGC. 2) Send the service change request to Handed-off MGC with method as HANDOFF and reason as MGC Impending Failure. 3) Since this procedure must be transparent to the MG application, all new transaction requests and the outstanding transaction responses must be queued until the re-registration is complete. 10.3.7.2. New State SWIP (SWITCHOVER_IN_PRGS) Vikas, Vivek, Shiv, Prashant 29 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 10.3.8. Forced Shutdown at MGC Input parameters: None 10.3.8.1. Steps 1) Give the indication to the MG application to clear all the call contexts. 2) Once the cleanup operation is finished at MG, it generates the registration command to either primary or secondary MGC with method as RESTART û Implementation specific. 10.3.8.2. New State RIP (RESTART_IN_PROGRESS) 10.4. SIP (SHUTDOWN_IN_PRGS) 10.4.1. Forced Shutdown at MG If during the Failover operation, the primary MG feels that the redundant MG entity is unable to take over the control, it can ask the primary MG to send Forced Shutdown towards its peer. 10.4.1.1. Steps 1) Terminate all the active calls contexts on its own. 2) Send the Service Change command to the MGC with method as FORCED. 10.4.1.2. New State INACTIVE 10.4.2. Graceful Shutdown At MG Vikas, Vivek, Shiv, Prashant 30 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 If during the Failover operation, the primary MG feels that the redundant MG entity is unable to take over the control, it can ask the primary MG to send Graceful shutdown towards its peer, to clear all the existing calls gracefully. Input parameters: - Service Change Delay 10.4.2.1. Steps 1) Start the delay timer for value specified in Service change delay. 2) Send the request to MGC with GRACEFUL method and with the specified service change delay. 3) Till the expiry of the service change delay, the state of MG control association becomes ASSOCIATION IN SERVICE (AIS). 4) Delete all the call contexts abruptly after the completion of the graceful period. 5) If the NULL delay was specified, the control association must last for the duration of the time until all the active call contexts are cleared by MGC. 10.4.2.2. New State AIS (ASSOCIATION IN SERVICE). 10.4.3. Peer Failure Detection at MG Input parameters: None 10.4.3.1. Steps 1) If during the Failover phase, if MG detects the failure of controlling MGC, this information should be conveyed to the standby entity (outside the scope of the protocol) so that any further recovery action (trying secondary MGCs) would be taken via the redundant MG. Vikas, Vivek, Shiv, Prashant 31 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 10.4.3.2. New State INACTIVE 10.4.4. Restart from MGC Input parameters: - Service Change Reason. - Service Change Address. 10.4.4.1. Steps 1) Give the indication to the MG application to restart MG, along with the received service change reason from MGC. Henceforth, the standby MG would initiate the re- registration request to the same MGC on behalf of the failed one. 2) Once the restart operation is finished, standby MG generates the registration command to the same controlling MGC on the newly specified service change address. 10.4.4.2. New State INACTIVE 10.4.5. Handoff from MGC Input parameters: - Service Change MGCIdToTry. 10.4.5.1. Steps 1) Convey this information to the standby entity (outside the scope of the protocol) so that any further recovery action (trying handed-off MGCs) would be taken via the redundant MG. 2) Send the service change request to Handed-off MGC with method as HANDOFF and reason as MGC Impending Failure. Vikas, Vivek, Shiv, Prashant 32 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 10.4.5.2. New State INACTIVE 10.4.6. Forced Shutdown from MGC Input parameters: None 10.4.6.1. Steps 1) Give the indication to the MG application to clear all the call contexts. Further any recovery action would be taken via the redundant MG. 2) Once the cleanup operation is finished at MG, the standby MG generates the registration command to either primary or secondary MGC with method as RESTART û Implementation specific. 8.4.4.2. New State INACTIVE 10.5. SWIP (SWITCHOVER_IN_PRGS) 10.5.1. Forced Shutdown At MG Input parameters: None 10.5.1.1. Steps 1) The implementation may either send the service change command to the MGC, which is being contacted at present, immediately with method as FORCED or MG may defer this message until the service change reply from the MGC is received for the current pending service change request. 2) All the call contexts would be cleared at MG without waiting for a SUBTRACT command from MGC. Vikas, Vivek, Shiv, Prashant 33 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 10.5.1.2. New State INACTIVE 10.5.2. Graceful Shutdown At MG Input parameters: - Service Change Delay. 10.5.2.1. Steps 1) Buffer the Graceful Shutdown request until the MGC, which is being contacted, accepts the registration request. 2) Once the registration is complete, send the service change command with GRACEFUL method to the same MGC. If the delay was specified in the input, then the delay in the command should be the left-out time. New state in this case would be AIS (ASSOCIATION_IN_SERVICE). 3) If Handoff/Failover takes more time than the Graceful delay period, then the implementation will terminate the control association abruptly and all the call contexts would get cleared. New state in this case would be INACTIVE. 10.5.3. Failover at active MG Input parameters: None 10.5.3.1. Steps 1) Buffer the Failover request until the MGC, which is being contacted, accepts the re-registration request. 2) Once the re-registration is complete, send the service change command with FAILOVER method to the same MGC. 10.5.3.2. New State Vikas, Vivek, Shiv, Prashant 34 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 SIP (SHUTDOWN_IN_PRGS) 10.5.4. Transport Parameters Change at MG Input parameters: - Service Change Address. 10.5.4.1. Steps 1) Buffer the new transport parameters, until the MGC, which is being contacted, accepts the re-registration request. 2) Once the re-registration is complete, send the service change command with DISCONNECTED method to the same MGC with the new transport parameters in the service change address parameter. 10.5.4.2. New State AIS (ASSOCIATION IN SERVICE) 11. MGC State Machine The procedures given below show the behavior of the state machine when given valid triggers: Vikas, Vivek, Shiv, Prashant 35 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 This table maps the service change method received from peer to the control association states of MGC. +------------+--------+--------+-----------+----------+--------+ |Method/ | |Restart |Association|Switchover|Shutdown| | States |Inactive|In |In |In |In | | | |Progress|Service |Progress |Progress| +------------+--------+--------+-----------+----------+--------+ |RESTART | NA | A | A | A | A | | | | | | | | +------------+--------+--------+-----------+----------+--------+ |FORCED | NA | A | A | A | A | | | | | | | | +------------+--------+--------+-----------+----------+--------+ |GRACEFUL | | | | | | | | NA | NA | A | A | A | +------------+--------+--------+-----------+----------+--------+ |DISCONNECTED| NA | NA | A | A | A | | | | | | | | +------------+--------+--------+-----------+----------+--------+ |FAILOVER | NA | A | A | A | A | | | | | | | | +------------+--------+--------+-----------+----------+--------+ |HANDOFF | NA | A | A | A | A | | | | | | | | +------------+--------+--------+-----------+----------+--------+ A û Allowed NA- Not Allowed Vikas, Vivek, Shiv, Prashant 36 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 +-------------------+ | | | INACTIVE +----------->>-------------+ | | | +-----+-------+--+--+ | | | | | | | +------------<<-----------+ | Awaiting Restart | | | from MG | +-------<<--------+ | | | | | | | | | | | | | | +-----V--------------+ | | | | RESTART IN | | | | | PROGRESS | | | | | | | | | +--+----+---------+--+ | | | | | | | | | | | Registration | | | +->>-------------+ | Completion and | | | MG Forced +>>-----------+ Restart Delay Timeout| | | Shutdown / | +---------+ | | Handoff | Graceful Timeout | | Graceful| | | Completion| | Restart Trigger | Shutdown| V | | | | from MG/MGC V | V | | | | | +---V---------+---+--+ | | | | | | ASSOCIATION IN + | | | | +-----+ SERVICE | | | | +-----<<------+ | MGC Forced | | +-+---+--------+---+-+ Shutdown | V | | | V | | V +----<<-----V | | V------------+ | | | | +----------+ | | MG Failure | | Handoff at | | | Detected/ | +-->>------+ active MGC | | | MG Failover| | Re-registration | | | V | from MG +----V------------+ | | +----------V----+--+ | | | | | SWITCHOVER IN | SHUTDOWN IN | | | | PROGRESS | | PROGRESS | | | | | | | | | +---------^--------+ +--------------+--+ | | | Redundant takeover V | | | at Handed-off MGC V------+ | | | | | +--------------------<<-----------------------------------+ Figure 2: MGC State Machine Transition Diagram Vikas, Vivek, Shiv, Prashant 37 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 11.1. RIP (RESTART_IN_PROGRESS) 11.1.1. Cold Start At MG Input parameters: - Service change delay. - Service Change Address. - Service Change Version. - Service Change Profile. 11.1.1.1. Steps: 1) Examine the service change version of the received message. 2) If the MGC is unable to comply with the suggested version then send a Service Change Response to the MG with error ô406 Version not supportedö. State remains same. 3) If the MGC supports the suggested or lower version, send a Service Change Response to the MG the negotiated Service Change Version. Start Delay Timer and the state changes to RIP (RESTART_IN_PROGRESS). After Restart Delay expiry, state would become ASSOCIATION_IN_SERVICE. 4) If the MGC wishes to handoff the MG to another MGC, send a Service Change Response to the MG with Service Change MGCIdToTry [transport address of the new MGC]. State remains same If the MGC wishes to change the Transport Address for further correspondence to be used by the MG, send a Service Change Response to the MG with Service Change Address [containing the new transport address] along with the other parameters. Change the state as per bullet 3. 11.1.2. Forced Shutdown At MG Input parameters: None 11.1.2.1. Steps 1) Here there should not be any call running at MG. 2) After this, MGC shall wait for the next registration request from the MG going down. Vikas, Vivek, Shiv, Prashant 38 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 11.1.2.2. New State RIP (RESTART IN PROGRESS) 11.1.3. Graceful Shutdown At MG Input parameters: - Service change delay. 11.1.3.1. Steps 1) Start the delay timer for value specified in Service change delay. 2) Till the expiry of the service change delay, the state of MGC control association remains RESTART IN PROGRESS. 3) If MG specifies null delay or the graceful period is shorter than the restart period earlier specified in the restart delay, the control association would get terminated immediately. 11.1.3.2. New State State remains same. 11.1.4. Failover at active MG Input parameters: None. If the registered MG, wants to transfer the control of the specified association to the redundant MG. 11.1.4.1. Steps 1) Simply stop restart delay timer and start waiting for a new service change command from the standby MG with method as DISCONNECTED and reason as SERVICE RESTORED. 11.1.4.2. New State State remains same. 11.1.5. Redundant Takeover at standby MG 11.1.5.1. Steps 1) MGC may just do an audit if required. Vikas, Vivek, Shiv, Prashant 39 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 11.1.5.2. New State ASSOCIATION_IN_SERVICE 11.1.6. Peer Failure Detection at MGC Input parameters: None In this state, MGC may detect the failure of its MG while doing periodic audits during the restart phase. 11.1.6.1. Steps 1) Stop restart delay timer if running. 2) After this, MGC shall wait for the next registration request from the MG, whose failure was detected. 11.1.6.2. New State RIP (RESTART IN PROGRESS) 11.1.7. Handoff at Active MGC Input parameters: - Service Change MGCIdToTry. 11.1.7.1. Steps 1) Stop restart delay timer if running. 2) Send Service Change Request to the MG with Method as Handoff and MGCIdToTry set to the new MGC. 11.1.7.2. New State RIP (RESTART IN PROGRESS) 11.1.8. Forced Shutdown at MGC Input parameters: None Vikas, Vivek, Shiv, Prashant 40 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 11.1.8.1. Steps 1) Stop restart delay timer if running. 2) Send Service Change Request to the MG Method as FORCED. 11.1.8.2. New State INACTIVE 11.2. AIS (ASSOCIATION IN SERVICE) 11.2.1. Forced Shutdown at MG Input parameters: None 11.2.1.1. Steps 1) All the call contexts would be cleared at MGC without sending SUBTRACT commands to MG. 2) After this, MGC shall wait for the next registration request from the MG going down. 11.2.1.2. New State RIP (RESTART_IN_PROGRESS) 11.2.2. Graceful Shutdown at MG Input parameters: - Service change delay. 11.2.2.1. Steps 1) Start the delay timer for value specified in Service change delay. 2) Till the expiry of the service change delay, the state of MG control association becomes ASSOCIATION IN SERVICE (AIS). 3) Delete all the call contexts abruptly after the completion of the graceful period. Vikas, Vivek, Shiv, Prashant 41 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 4) If the NULL delay was specified, the control association must last for the duration of the time until all the active call contexts are cleared from MGC. 11.2.2.2. New State State remains same. 11.2.3. Failover at active MG Input parameters: None 11.2.3.1. Steps 1) The existing calls are not affected assuming that the standby MG would come up and take over the control of the specified association. 2) Start waiting for a new service change command from the standby MG with method as DISCONNECTED and reason as COLD Boot or Warm Boot. 11.2.3.2. New State SWIP (SWITCHOVER_IN_PROGRESS) 11.2.4. Transport Parameters Change at MG Input parameters: - Service Change Address. 11.2.4.1. Steps 1) The existing calls are not affected. MGC may do an audit. 2) Starts sending the new protocol command request on the new address, as specified in the service change address parameter. 11.2.4.2. New State State remains same. 11.2.5. Transport Parameters Change at MGC Input parameters: - New Transport Address. Vikas, Vivek, Shiv, Prashant 42 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 11.2.5.1. Steps 1) The existing calls are not affected. 2) Send Service Change Request to the MG Method as Handoff and MGCIdToTry set to the new transport parameters. 11.2.5.2. New State SWIP (SWITCHOVER IN PROGRESS) 11.2.6. Peer Failure Detection at MG Input parameters: None 11.2.6.1. Steps 1) The existing calls are not affected assuming that the standby MG may come up and take over the control of the specified association. 2) Start waiting for a new service change command from the standby MG with method as DISCONNECTED and reason as COLD Boot or Warm Boot. 11.2.6.2. New State SWIP (SWITCHOVER_IN_PROGRESS) 11.2.7. Handoff at Active MGC Input parameters: - Service Change MGCIdToTry. 11.2.7.1. Steps 1) Send Service Change Request to the MG Method as Handoff and MGCIdToTry set to the new MGC. 11.2.7.2. New State SIP (SHUTDOWN_IN_PROGRESS) Vikas, Vivek, Shiv, Prashant 43 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 11.2.8. Restart From MGC Input parameters: - Service Change Address. - Service Change Reason. 11.2.8.1. Steps 1) Depending on the service change reason field (Cold Boot or Warm Boot or Service Restored), call contexts would be cleared at MGC as well as at MG. 2) Send Service Change Request to the MG with method as RESTART and the other relevant parameters. 11.2.8.2. New State RIP (RESTART_IN_PROGRESS) 11.2.9. Forced shutdown At MGC Input parameters: None 11.2.9.1. Steps 1) All the call contexts would be cleared at MGC without sending SUBTRACT commands to MG. 2) Send Service Change Request to the MG with method as FORCED. 11.2.9.2. New State INACTIVE_ 11.3. SWIP (SWITCHOVER_IN_PROGRESS) In this state: - Either the active MGC is waiting for a service change command from the standby MG in case of MG Failover that was received earlier. Vikas, Vivek, Shiv, Prashant 44 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 - Or the handed-off MGC is waiting for a service change command from the active or the standby MG in case control association was re-directed by the active MGC. 11.3.1. Forced Shutdown at MG Input parameters: None 11.3.1.1. Steps 1) All the call contexts would be cleared at MGC without sending SUBTRACT commands to MG. 2) After this, MGC shall wait for the next registration request from the MG going down. 11.3.1.2. New State RIP (RESTART_IN_PROGRESS) 11.3.2. Graceful shutdown request from MG 11.3.2.1. Steps 1) Start the delay timer for value specified in Service change delay. 2) Till the expiry of the service change delay, the state of MG control association becomes ASSOCIATION IN SERVICE (AIS). 3) Delete all the call contexts abruptly after the completion of the graceful period. 4) If the NULL delay was specified, the control association must last for the duration of the time until all the active call contexts are cleared from MGC. 11.3.2.2. New State ASSOCIATION_IN_SERVICE Vikas, Vivek, Shiv, Prashant 45 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 11.3.3. Failover at active MG 11.3.3.1. Steps 1) Do nothing. 11.3.3.2. New State State remains same. 11.3.4. Redundant Takeover at standby MG 11.3.4.1. Steps 2) Depending on the service change reason field (Cold Boot or Warm Boot or Service Restored), call contexts would be cleared at MGC. 3) MGC may do an audit. 11.3.4.2. New State ASSOCIATION_IN_SERVICE 11.3.5. Forced Shutdown at MGC 11.3.5.1. Steps 1) All the call contexts would be cleared at MGC without sending SUBTRACT commands to MG. 2) Buffer the Forced shutdown request until the MG sends a service change request to re-establish the control association. 3) Once the association is re-established, send the service change command with FORCED method to the same MG so that MG could clear the call contexts at its end. 11.3.5.2. New State INACTIVE 11.3.6. Restart From MGC Vikas, Vivek, Shiv, Prashant 46 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 11.3.6.1. Steps 1) All the call contexts would be cleared at MGC without sending SUBTRACT commands to MG. 2) Buffer the Forced shutdown request until the MG sends a service change request to re-establish the control association. 3) Once the association is re-established, send the service change command with FORCED method to the same MG so that MG could clear the call contexts at its end. 11.3.6.2. New State RIP (RESTART_IN_PROGRESS) 11.3.7. Handoff at Active MGC 11.3.7.1. Steps 1) Buffer the MGCIdToTry parameter until the MG sends a service change request to re-establish the control association. 2) Once the association is re-established, send the reply to the MG with the MGCIdToTry field set to the Handed off MGC except the case that the MG is forcefully going down. 11.3.7.2. New State SIP (SHUTDOWN_IN_PROGRESS). 11.3.8. Re-registration request from active or standby MG Input parameters: - Service Change Version. 11.3.8.1. Steps: 1) Examine the service change version of the received message, if present. Vikas, Vivek, Shiv, Prashant 47 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 2) If the MGC is unable to comply with the suggested version then send a Service Change Response to the MG with error ô406 Version not supportedö. State remains same. 3) If the MGC supports the suggested or lower version, send a Service Change Response to the MG the negotiated Service Change Version. The state would become ASSOCIATION_IN_SERVICE. 4) Depending on the service change reason field (Cold Boot or Warm Boot or Service Restored), call contexts would be cleared at MGC. MGC should do an audit here as per the protocol. 11.4. SIP (SHUTDOWN_IN_PROGRESS) 11.4.1. Forced Shutdown at MG 11.4.1.1. Steps 1) All the call contexts would be cleared at MGC without sending SUBTRACT commands to MG. 11.4.1.2. New State INACTIVE 11.4.2. Graceful Shutdown at MG 11.4.2.1. Steps 1) The MGC going down may convey this information to the Handed-off MGC, outside the scope of the protocol. 2) Send the reply to the MG with the MGCIdToTry field set to the Handed-off MGC. 11.4.2.2. New State State remains same. Vikas, Vivek, Shiv, Prashant 48 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 11.4.3. Failover at active MG 11.4.3.1. Steps 1) Send the reply to the MG with the MGCIdToTry field set to the Handed off MGC. 11.4.3.2. New State State remains same. 11.4.4. Redundant Takeover at standby MG 11.4.4.1. Steps 1) Send the reply to the MG with the MGCIdToTry field set to the Handed off MGC. 11.4.4.2. New State State remains same. 11.4.5. Forced Shutdown At MGC 11.4.5.1. Steps 1) Send Service Change Request to the MG with method as FORCED. 11.4.5.2. New State INACTIVE Vikas, Vivek, Shiv, Prashant 49 INTERNET-DRAFT MEGACO Control Association Procedures and State Machine August 2001 AuthorÆs Addresses Vikas Bajaj Hughes Software Systems, Ltd. Gurgaon,Haryana,India. 122015. Phone: (91)-11-346666.Ex-3270 Email: vbajaj@hss.hns.com Vivek Bansal Hughes Software Systems, Ltd. Gurgaon, Haryana, India. 122015. Phone: (91)-11-346666.Ex-3616 Email: vibansal@hss.hns.com Shiv Kumar Hughes Software Systems, Ltd. Gurgaon,Haryana,India. 122015. Phone: (91)-11-346666.Ex-3281 Email: svkumar@hss.hns.com Prashant Jain Hughes Software Systems, Ltd. Gurgaon,Haryana,India. 122015. Phone: (91)-11-346666.Ex-3616 Email: prjain@hss.hns.com Vikas, Vivek, Shiv, Prashant 50