[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 RFC 3992

Internet Engineering Task Force                            B. Foster
Internet Draft                                          F. Andreasen
Document: <draft-foster-mgcp-lockstep-00.txt>
Category: Informational                                Cisco Systems
                                                       November 2002


                MGCP Lockstep State Reporting Mechanism

Status of this Document

  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 obsoleted 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/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

1. Abstract

  An MGCP endpoint that encountered some adverse failure condition such
  as being involved in a transient call when a Call Agent failover
  occurred could be left in a lockstep state such that events are
  quarantined but not notified. The MGCP LCK 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.

2.0 Conventions used in this document

  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 RFC-2119.












B. Foster, F. Andreasen      Informational                     [Page 1]

             MGCP Lockstep State Reporting Mechanism      November 2002

3. Introduction

  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. Once a response is received, 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 is
  in the lockstep state.

  An endpoint that is in lockstep state cannot perform any event
  processing and hence can also not generate any new Notifys. Endpoints
  should only be in lockstep state for a very short period of time. In
  the event of a Call Agent failure, programming errors, and other
  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 that an endpoint informs it if the endpoint is
  in the lockstep state for a specified period of time.

2.0. Lockstep Package

  Package Name: LCK
  Version: 0

  Package Description: The purpose of this package is to provide a
  mechanism for reporting a condition in which an endpoint has been
  sitting 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. 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.

2.2. Request to Report Lockstep State

  The new "lstime" 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)

  where LSTIME is expressed in seconds, with a value ranging from 1 to
  999. A value of greater than 2*T-HIST (refer to [3]) is recommended.



<author>                     Informational                     [Page 2]

             MGCP Lockstep State Reporting Mechanism      November 2002

  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 cancelled if the endpoint leaves the lockstep
  state before the timeout occurs.

  This parameter can be audited using the audit endpoint command.

2.3. Lockstep restart Method

  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 value for LSTIME and that timer
  has timed out. The syntax of the restart method is as per [3]:

     "RM" ":" 0*(WSP) "LCK/lockstep"

  The "lockstep" RestartMethod does not define a service-state, and
  hence it will never be returned when auditing the RestartMethod.


3.0. IANA Considerations

  The MGCP package title "Lockstep" with the name "LCK" should be
  registered with IANA as indicated in Appendix C.1 in [3].

4.0. Security Considerations

  The MGCP packages contained in this document do not require any
  further security considerations beyond those indicated in the base
  MGCP specification [3].

4.0. References

  [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

  [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

  [3] F. Andreasen, B. Foster "Media Gateway Control Protocol (MGCP)
      Version 1.0", RFC XXXX {editors note - to be put in when RFC
      number is assigned to draft-andreasen-mgcp-rfc2705bis-04.txt)

5.0. Authors' Addresses

  Bill Foster
  Phone: +1 250 758 9418
  EMail: bfoster@cisco.com

  Flemming Andreasen
  Cisco Systems
  499 Thornall Street, 8th Floor
  Edison, NJ 08837


<author>                     Informational                     [Page 3]

             MGCP Lockstep State Reporting Mechanism      November 2002

  Phone: +1 732 452 1667
  EMail: fandreas@cisco.com

6.0. Full Copyright Statement

  Copyright (C) The Internet Society (2002).  All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works.  However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organizations, except as needed for the purpose of
  developing Internet standards in which case the procedures for
  copyrights defined in the Internet Standards process must be
  followed, or as required to translate it into languages other than
  English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS 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.

  Acknowledgement

  Funding for the RFC Editor function is currently provided by the
  Internet Society.




















<author>                     Informational                     [Page 4]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/