[要約] RFC 3992は、MGCPのロックステップ状態報告メカニズムに関する規格です。このRFCの目的は、MGCPゲートウェイがロックステップ状態を報告するための方法を提供することです。
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
メディアゲートウェイ制御プロトコル（MGCP）ロックステップ状態レポートメカニズム
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).
Copyright（c）The Internet Society（2005）。
IESG Note
IESGノート
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.
このドキュメントは、コミュニティの情報のために公開されています。現在、多くの製品に展開されている非ITFプロトコルについて説明しています。実装者は、IETF Megaco Working GroupおよびITU-T SG16で開発されたRFC 3015に注意する必要があります。IETFと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.
有害な故障状態に遭遇したメディアゲートウェイコントロールプロトコル（MGCP）エンドポイント（コールエージェントフェールオーバーが発生したときに一時的なコールに関与するなど）は、イベントが隔離されているが通知されないロックステップ状態に残る可能性があります。このドキュメントで説明されているMGCPパッケージは、新しいコールエージェントが必要な障害回復手順をとることができるように、これらの状況を報告するためのメカニズムを提供します。
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.
メディアゲートウェイ制御プロトコル（MGCP）[2]では、「ステップ」モードで動作するエンドポイントが通知を生成すると、通知状態に入り、通知への応答が待機されます。さらに、エンドポイントは、イベント処理を再開する前に、新しいNotificationRequestを待つ必要があります。エンドポイントがこの通知リケストを待っている限り、それはロックステップ状態にあると言います。
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.
ロックステップ状態にあるエンドポイントは、どのイベント処理を実行できないため、新しいNotifyを生成することもできません。エンドポイントは、非常に短い間ロックステップ状態にある必要があります。ただし、不利な条件では、コールエージェントがそれを実現することなく、エンドポイントがロックステップ状態で終わる可能性があります。明らかに、これは提供されるサービスに関して非常に否定的な結果をもたらす可能性があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
Package Name: LCK Version: 0
パッケージ名：LCKバージョン：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:
このパッケージには2つの側面があります。
* 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.
* コールエージェントが指定された期間ロックステップ状態にあるかどうかを報告するためにエンドポイントを要求する機能。これは、セクション2.1で説明されているように、EndPointConfigurationコマンドで行われます。
* The reporting mechanism itself, which is done with a new "lockstep" RestartMethod for the RSIP command as described in section 2.2.
* セクション2.2で説明されているように、RSIPコマンドの新しい「ロックステップ」RestArtMethodで行われるレポートメカニズム自体。
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」EndPointConfigurationパラメーターは、「ロックステップ」状態のレポートを要求するためにコールエージェントによって使用されます。次のABNFを使用します。
"LCK/LST:" 0*WSP LSTIME
"lck/lst：" 0*wsp lstime
LSTIME = 1*(4DIGIT)
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は0から9999の範囲の値で秒単位で表されます。2*t-Hist（[2]を参照）を超える値が推奨されます。
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.
LSTIMEは、報告する前のエンドポイントがロックステップ状態にある時間です。エンドポイントがロックステップ状態に入るとタイマーが起動し、タイムアウトが発生する前にエンドポイントがロックステップ状態を離れるとキャンセルされます。提供された値は、明示的に変更されるまで有効です（または再起動が発生します）。ゼロ以外のタイマー値が提供されているときにエンドポイントがロックステップ状態にある場合、ロックステップタイマーは、提供された値から始まります。既存のロックステップタイマーはキャンセルされます。値ゼロは、レポートをオフにするために使用されます。
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.
このパラメーターは、auditendpointコマンドを使用して監査できます。返される値は、最後に構成された値、または値が構成されていない場合の値ゼロです。
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]:
新しい「ロックステップ」再起動メソッドは、「LCK」パッケージで定義されています。エンドポイントがLSTIMEの非ゼロ値で構成されており、そのタイマーが期限切れになった場合、RestArtInProgress（RSIP）がこのRestArtMethodで送信されます。ロックステップタイマーが設定されたら、通知コマンドごとに1回だけ発射できることに注意してください。ただし、エンドポイントがロックステップ状態にある間に、タイマーを複数回設定することができます（したがって、その特定の通知のためにそれを再生します）。再起動メソッドの構文は[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.
RestArtDelay（[2]を参照）は、「ロックステップ」RestArtMethodで使用されません。また、「ロックステップ」RestArtMethodはサービスステートを定義していないため、RestArtMethodを監査するときに返されることはありません。
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].
「LCK」という名前のMGCPパッケージタイトル「ロックステップ」とバージョン番号ゼロは、[2]の付録C.1に示すように、IANAに登録されています。
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 have not been modified. Without these services, gateways and Call Agents are open to attacks.
ベースMGCP仕様[2]のセクション5では、このドキュメントで定義されているパッケージに等しく適用されるベースMGCPプロトコルのセキュリティ要件について説明します。メッセージごとの認証と整合性サービスを提供するIPSEC（RFC 2401、RFC 2406）などのセキュリティプロトコルの使用は、認証されたソースからリクエストと応答が取得され、メッセージが変更されていないことを確認するために必要です。これらのサービスがなければ、ゲートウェイとコールエージェントは攻撃に対して開かれています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[2] Andreasen、F。およびB. Foster、「Media Gateway Control Protocol（MGCP）バージョン1.0」、RFC 3435、2003年1月。
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
フレミングアンドレアセンシスコシステム499 Thornall Street、8階エジソン、ニュージャージー08837
EMail: fandreas@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
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.
この文書は、BCP 78およびwww.rfc-editor.orgに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
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.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。ISOCドキュメントの権利に関するISOCの手順に関する情報は、BCP 78および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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。