idnits 2.17.1 draft-foster-mgcp-lockstep-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2003) is 7590 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force B. Foster 2 Internet Draft F. Andreasen 3 Document: Cisco Systems 4 Category: Informational July 2003 6 Media Gateway Control Protocol (MGCP) Lockstep State Reporting 7 Mechanism 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 A Media Gateway Control Protocol (MGCP) endpoint that has encountered 32 an adverse failure condition such as being involved in a transient 33 call when a Call Agent failover occurred could be left in a lockstep 34 state such that events are quarantined but not notified. The MGCP 35 package described in this document provides a mechanism for reporting 36 these situations so that the new Call Agent can take the necessary 37 fault recovery procedures. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC-2119 [1]. 45 1. Introduction 47 In the Media Gateway Control Protocol (MGCP) [2], when an endpoint 48 operating in "step" mode generates a Notify, it will enter the 49 "notification state" where it waits for a response to the Notify. 50 Furthermore, the endpoint must wait for a new NotificationRequest 51 before it can resume event processing. As long as the endpoint is 52 waiting for this NotificationRequest, we say that it is in the 53 lockstep state. 55 An endpoint that is in lockstep state cannot perform any event 56 processing and hence can also not generate any new Notifys. 57 Endpoints should only be in lockstep state for a very short time, 58 however in case of adverse conditions, an endpoint could potentially 59 end in the lockstep state without the Call Agent realizing it. 60 Clearly, this could have very negative consequences in terms of the 61 service provided. 63 The Lockstep package defined in this document defines extensions to 64 the EndpointConfiguration and RestartInProgress commands that allow a 65 Call Agent to request an endpoint to inform it if the endpoint is in 66 the lockstep state for a specified period of time. 68 2.0. Lockstep Package 70 Package Name: LCK 71 Version: 0 73 Package Description: The purpose of this package is to provide a 74 mechanism for reporting a condition in which an endpoint has been in 75 the "lockstep state" for a specified period of time. 77 There are two aspects of this package: 79 * The ability for a Call Agent to request endpoints to report if 80 they are in lockstep state. This is done with the 81 EndpointConfiguration command as described in section 2.1. 82 * The reporting mechanism itself, which is done with a new 83 "lockstep" RestartMethod for the RSIP command as described in 84 section 2.2. 86 2.1. Request to Report Lockstep State 88 The new "lstime" EndpointConfiguration parameter is used by the Call 89 Agent to request the reporting of "lockstep" state. It uses the 90 following ABNF: 92 "LCK/LST:" 0*WSP LSTIME 94 LSTIME = 1*(4DIGIT) 96 where LSTIME is expressed in seconds, with a value ranging from 0 to 97 999. A value greater than 2*T-HIST (refer to [2]) is RECOMMENDED. 99 LSTIME is the amount of time the endpoint is in the lockstep state 100 before reporting. The timer starts when the endpoint enters the 101 lockstep state and is cancelled if the endpoint leaves the lockstep 102 state before the timeout occurs. The value zero is used to turn off 103 reporting. 105 This parameter can be audited using the AuditEndpoint command. 107 2.2. Lockstep restart Method 109 A new "lockstep" restart method is defined in the "LCK" package. A 110 RestartInProgress (RSIP) will be sent with this RestartMethod if the 111 endpoint has been configured with a non-zero value for LSTIME and 112 that timer has expired. The syntax of the restart method is as per 113 [2]: 115 "RM" ":" 0*(WSP) "LCK/lockstep" 117 RestartDelay (see [2]) is not used with the "lockstep" RestartMethod. 118 Also, the "lockstep" RestartMethod does not define a service-state, 119 and hence it will never be returned when auditing the RestartMethod. 121 3.0. IANA Considerations 123 The MGCP package title "Lockstep" with the name "LCK" and version 124 number zero should be registered with IANA as indicated in Appendix 125 C.1 in [2]. 127 4.0. Security Considerations 129 Section 5 of the base MGCP specification [2] discusses security 130 requirements for the base MGCP protocol, which apply equally to the 131 package defined in this document. Use of a security Protocol such as 132 IPsec (RFC 2401, RFC 2406) that provides per message authentication 133 and integrity services is required in order to ensure that requests 134 and responses are obtained from authenticated sources and that 135 messages have not been modified. Without such services, gateways and 136 Call Agents are open to attacks. 138 5.0. Normative References 140 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 141 Levels", BCP 14, RFC 2119, March 1997. 142 [2] F. Andreasen, B. Foster "Media Gateway Control Protocol (MGCP) 143 Version 1.0", RFC 3435, January 2003. 145 Authors' Addresses 147 Bill Foster 148 Phone: +1 250 758 9418 149 EMail: bfoster@cisco.com 150 Flemming Andreasen 151 Cisco Systems 152 499 Thornall Street, 8th Floor 153 Edison, NJ 08837 154 EMail: fandreas@cisco.com 156 Intellectual Property Statement 158 The IETF takes no position regarding the validity or scope of any 159 intellectual property or other rights that might be claimed to 160 pertain to the implementation or use of the technology described in 161 this document or the extent to which any license under such rights 162 might or might not be available; neither does it represent that it 163 has made any effort to identify any such rights. Information on the 164 IETF's procedures with respect to rights in standards-track and 165 standards-related documentation can be found in BCP-11. Copies of 166 claims of rights made available for publication and any assurances 167 of licenses to be made available, or the result of an attempt made 168 to obtain a general license or permission for the use of such 169 proprietary rights by implementors or users of this specification 170 can be obtained from the IETF Secretariat. 172 The IETF invites any interested party to bring to its attention any 173 copyrights, patents or patent applications, or other proprietary 174 rights which may cover technology that may be required to practice 175 this standard. Please address the information to the IETF Executive 176 Director. 178 Full Copyright Statement 180 Copyright (C) The Internet Society (2003). All Rights Reserved. 182 This document and translations of it may be copied and furnished to 183 others, and derivative works that comment on or otherwise explain it 184 or assist in its implementation may be prepared, copied, published 185 and distributed, in whole or in part, without restriction of any 186 kind, provided that the above copyright notice and this paragraph are 187 included on all such copies and derivative works. However, this 188 document itself may not be modified in any way, such as by removing 189 the copyright notice or references to the Internet Society or other 190 Internet organizations, except as needed for the purpose of 191 developing Internet standards in which case the procedures for 192 copyrights defined in the Internet Standards process must be 193 followed, or as required to translate it into languages other than 194 English. 196 The limited permissions granted above are perpetual and will not be 197 revoked by the Internet Society or its successors or assigns. 199 This document and the information contained herein is provided on an 200 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 201 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 202 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 203 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 204 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 206 Acknowledgement 208 Funding for the RFC Editor function is currently provided by the 209 Internet Society.