Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism
RFC 3992

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.

1.  Introduction

   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.

1.1.  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 BCP 14, RFC 2119 [1].

2.  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 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.

2.1.  Request to Report Lockstep State

   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]
quot; elements SHOULD be provided.

4.1.2.  Expiry Time on Location-Related Measurement Data

   A Device is able to indicate an expiry time in the location
   measurement using the "expires" attribute.  Nominally, this attribute
   indicates how long information is expected to be valid for, but it
   can also indicate a time limit on the retention and use of the
   measurement data.  A Device can use this attribute to prevent the LIS
   from retaining measurement data or limit the time that a LIS retains
   this information.

   Note:  Movement of a Device might result in the measurement data
      being invalidated before the expiry time.

   The LIS MUST NOT keep location-related measurement data beyond the
   time indicated in the "expires" attribute.

Thomson & Winterbottom   Expires April 30, 2012                 [Page 9]
Internet-Draft            Location Measurements             October 2011

4.2.  RMS Error and Number of Samples

   Often a measurement is taken more than once over a period of time.
   Reporting the average of a number of measurement results mitigates
   the effects of random errors that occur in the measurement process.

   Reporting each measurement individually can be the most effective
   method of reporting multiple measurements.  This is achieved by
   providing multiple "measurement" elements for different times.

   The alternative is to aggregate multiple measurements and report a
   mean value across the set of measurements.  Additional information
   about the distribution of the results can be useful in determining
   location uncertainty.

   Two optional attributes are provided for certain measurement values:

   rmsError:  The root-mean-squared (RMS) error of the set of
      measurement values used in calculating the result.  RMS error is
      expressed in the same units as the measurement, unless otherwise
      stated.  If an accurate value for RMS error is not known, this
      value can be used to indicate an upper bound or estimate for the
      RMS error.

   samples:  The number of samples that were taken in determining the
      measurement value.  If omitted, this value can be assumed to be a
      very large value, so that the RMS error is an indication of the
      standard deviation of the sample set.

   For some measurement techniques, measurement error is largely
   dependent on the measurement technique employed.  In these cases,
   measurement error is largely a product of the measurement technique
   and not the specific circumstances, so RMS error does not need to be
   actively measured.  A fixed value MAY be provided for RMS error where
   appropriate.

   The "rmsError" and "samples" elements are added as attributes of
   specific measurement data types.

4.2.1.  Time RMS Error

   Measurement of time can be significant in certain circumstances.  The
   GNSS measurements included in this document are one such case where a
   small error in time can result in a large error in location.  Factors
   such as clock drift and errors in time sychronization can result in
   small, but significant, time errors.  Including an indication of the
   quality of the time can be helpful.

Thomson & Winterbottom   Expires April 30, 2012                [Page 10]
Internet-Draft            Location Measurements             October 2011

   An optional "timeError" attribute can be added to the "measurement"
   element to indicate the RMS error in time. "timeError" indicates an
   upper bound on the time RMS error in seconds.

   The "timeError" attribute does not apply where multiple samples of a
   measurement is taken over time.  If multiple samples are taken, each
   SHOULD be included in a different "measurement" element.

4.3.  Measurement Request

   A measurement request is used by a protocol peer to describe a set of
   measurement data that it desires.  A "measurementRequest" element is
   defined that can be included in a protocol exchange.

   For instance, a LIS can use a measurement request in HELD responses.
   If the LIS is unable to provide location information, but it believes
   that a particular measurement type would enable it to provide a
   location, it can include a measurement request in an error response.

   The "measurement" element of the measurement request identifies the
   type of measurement that is requested.  The "type" attribute of this
   element indicates the type of measurement, as identified by an XML
   qualified name.  An optional "samples" attribute indicates how many
   samples of the identified measurement are requested.

   The "measurement" element can be repeated to request multiple (or
   alternative) measurement types.

   Additional XML content might be defined for a particular measurement
   type that is used to further refine a request.  These elements either
   constrain what is requested or specify optional components of the
   measurement data that are needed.  These are defined along with the
   specific measurement type.

   In the HELD protocol, the inclusion of a measurement request in a
   error response with a code of "locationUnknown" indicates that the
   LIS believes that providing the indicated measurements would increase
   the likelihood of a subsequent request being successful.

Thomson & Winterbottom   Expires April 30, 2012                [Page 11]
Internet-Draft            Location Measurements             October 2011

   The following example shows a HELD error response that indicates that
   WiFi measurement data would be useful if a later request were made.
   Additional elements indicate that received signal strength for an
   802.11n access point is requested.

     <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
            code="locationUnknown">
       <message xml:lang="en">Insufficient measurement data</message>
       <measurementRequest
           xmlns="urn:ietf:params:xml:ns:geopriv:lm"
           xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi">
         <measurement type="wifi:wifi">
           <wifi:type>n</wifi:type>
           <wifi:parameter context="ap">wifi:rcpi</wifi:parameter>
         </measurement>
       </measurementRequest>
     </error>

             Figure 3: HELD Error Requesting Measurement Data

   A measurement request that is included in other HELD messages has
   undefined semantics and can be safely ignored.  Other specifications
   might define semantics for measurement requests under other
   conditions.

4.4.  Identifying Location Provenance

   An extension is made to the PIDF-LO [RFC4119] that allows a location
   recipient to identify the source (or sources) of location information
   and the measurement data that was used to determine that location
   information.

   The "source" element is added to the "geopriv" element of the
   PIDF-LO.  This element does not identify specific entities.  Instead,
   it identifies the type of source.

   The following types of measurement source are identified:

   lis:  Location information is based on measurement data that the LIS
      or sources that it trusts have acquired.  This label might be used
      if measurement data provided by the Device has been completely
      validated by the LIS.

   device:  Location information is based on measurement data that the
      Device has provided to the LIS.

Thomson & Winterbottom   Expires April 30, 2012                [Page 12]
Internet-Draft            Location Measurements             October 2011

   other:  Location information is based on measurement data that a
      third party has provided.  This might be an authorized third party
      that uses identity parameters
      [I-D.ietf-geopriv-held-identity-extensions] or any other entity.

   No assertion is made about the veracity of the measurement data from
   sources other than the LIS.  A combination of tags MAY be included to
   indicate that measurement data from both sources was used.

Thomson & Winterbottom   Expires April 30, 2012                [Page 13]
Internet-Draft            Location Measurements             October 2011

   For example, the first tuple of the following PIDF-LO indicates that
   measurement data from a LIS and a device was combined to produce the
   result, the second tuple was produced by the LIS alone.

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0"
               xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
               entity="pres:lm@example.com">
       <tuple id="deviceLoc">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>7.34324 134.47162</gml:pos>
                 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                   850.24
                 </gs:radius>
               </gs:Circle>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>OTDOA</gp:method>
             <lmsrc:source>lis device</lmsrc:source>
           </gp:geopriv>
         </status>
       </tuple>
       <tuple id="lisLoc">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>7.34379 134.46484</gml:pos>
                 &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.

2.2.  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 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.

3.  IANA Considerations

   The MGCP package title "Lockstep" with the name "LCK" and version
   number zero has been registered with IANA as indicated in Appendix
   C.1 in [2].

4.  Security Considerations

   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.

5.  Normative References

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

   [2]  Andreasen, F. and B. Foster, "Media Gateway Control Protocol
        (MGCP) Version 1.0", RFC 3435, January 2003.

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

   EMail: fandreas@cisco.com

Foster & Andreasen           Informational                      [Page 4]
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.

Foster & Andreasen           Informational                      [Page 5]