Network Working Group B. Foster Request for Comments: 3992 F. Andreasen Category: Informational Cisco Systems February 2005
Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
IESG Note
This document is being published for the information of the community. It describes a non-IETF protocol that is currently being deployed in a number of products. Implementers should be aware of RFC 3015, which was developed in the IETF Megaco Working Group and the ITU-T SG16, and which is considered the standards-based (including reviewed security considerations) way to meet the needs that MGCP was designed to address by the IETF and the ITU-T.
Abstract
A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures.
In the Media Gateway Control Protocol (MGCP) [2], when an endpoint operating in "step" mode generates a Notify, it will enter the notification state, where it waits for a response to the Notify. Furthermore, the endpoint must wait for a new NotificationRequest before it can resume event processing. As long as the endpoint is waiting for this NotificationRequest, we say that it is in the lockstep state.
Foster & Andreasen Informational [Page 1]
RFC 3992 MGCP Lockstep State Reporting Mechanism February 2005
An endpoint that is in the lockstep state cannot perform any event processing and therefore also cannot generate a new Notify. Endpoints should only be in the lockstep state for a very short time. However, in adverse conditions, an endpoint could potentially end in the lockstep state without the Call Agent realizing it. Clearly, this could have very negative consequences in terms of the service provided.
The Lockstep package defined in this document defines extensions to the EndpointConfiguration and RestartInProgress commands that allow a Call Agent to request an endpoint to inform it when the endpoint is in the lockstep state for a specified period of time.
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 BCP 14, RFC 2119 [1].
Package Description: The purpose of this package is to provide a mechanism for reporting a condition in which an endpoint has been in the "lockstep state" for a specified period of time.
There are two aspects of this package:
* The ability for a Call Agent to request endpoints to report if they are in lockstep state for a specified period of time. This is done with the EndpointConfiguration command, as described in section 2.1.
* The reporting mechanism itself, which is done with a new "lockstep" RestartMethod for the RSIP command as described in section 2.2.
The new "LCK/LST" EndpointConfiguration parameter is used by the Call Agent to request the reporting of "lockstep" state. It uses the following ABNF:
"LCK/LST:" 0*WSP LSTIME
LSTIME = 1*(4DIGIT)
Foster & Andreasen Informational [Page 2]
RFC 3992 MGCP Lockstep State Reporting Mechanism February 2005
where LSTIME is expressed in seconds, with a value ranging from 0 to 9999. A value greater than 2*T-HIST (refer to [2]) is RECOMMENDED.
LSTIME is the amount of time the endpoint is in the lockstep state before reporting. The timer starts when the endpoint enters the lockstep state and is canceled if the endpoint leaves the lockstep state before the timeout occurs. The value provided remains in effect until explicitly changed (or a restart occurs). If the endpoint is already in the lockstep state when a non-zero timer value is provided, the lockstep timer is simply started with the value provided; any existing lockstep timer is cancelled. The value zero is used to turn off reporting.
This parameter can be audited by using the AuditEndpoint command. The value returned is the last configured value, or the value zero when no value was configured.
A new "lockstep" restart method is defined in the "LCK" package. A RestartInProgress (RSIP) will be sent with this RestartMethod if the endpoint has been configured with a non-zero value for LSTIME and that timer has expired. Note that once the lockstep timer has been set, it can fire only once per Notify command; however it is possible to set the timer more than once while an endpoint is in lockstep state (and hence rearm it for that particular Notify). The syntax of the restart method is as per [2]:
"RM" ":" 0*(WSP) "LCK/lockstep"
RestartDelay (see [2]) is not used with the "lockstep" RestartMethod. Also, the "lockstep" RestartMethod does not define a service-state, and thus it will never be returned when auditing the RestartMethod.
Section 5 of the base MGCP specification [2] discusses security requirements for the base MGCP protocol that apply equally to the package defined in this document. Use of a security Protocol such as IPsec (RFC 2401, RFC 2406) that provides per message authentication and integrity services is required to ensure that requests and responses are obtained from authenticated sources and that messages
Foster & Andreasen Informational [Page 3]
RFC 3992 MGCP Lockstep State Reporting Mechanism February 2005
have not been modified. Without these services, gateways and Call Agents are open to attacks.
RFC 3992 MGCP Lockstep State Reporting Mechanism February 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.