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).
著作権(C)インターネット協会(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.
この文書は、コミュニティの情報については公表されています。これは、現在の製品の数に展開されている非IETFプロトコルを記述しています。実装者は、IETFのMegaco作業部会とITU-T SG16で開発されたRFC 3015、を知っておく必要があり、そしてそれはMGCPがで対処するように設計されたことのニーズを満たすために、標準ベース(見直しのセキュリティの考慮事項を含む)方法を考えられています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を待たなければなりません。限り、エンドポイントは、この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.
堅苦しい状態にあるエンドポイントは、任意のイベント処理を行うことができず、従って、通知新たに生成することができません。エンドポイントは、ごく短い時間堅苦しい状態にする必要があります。しかし、不利な条件では、エンドポイントは、潜在的にコール・エージェントは、それを実現することなく堅苦しい状態で終わることができました。明らかに、これは、提供するサービスの面で非常にマイナスの影響を与える可能性があります。
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.
この文書で定義されたロックステップパッケージは、コールエージェントは、エンドポイントは、指定された期間のため堅苦しい状態にあるときにそれを知らせるためにエンドポイントを要求することを可能にするEndpointConfigurationとRestartInProgressコマンドへの拡張を定義します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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)
LSTIME = 1 *(4桁)
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は、([2]参照)T-HIST * 0から9999まで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で送信されます。ロックステップタイマーが設定されていたら、それは一度だけ通知するコマンドごとに発射できることに注意してください。しかし、エンドポイントは、ロックステップ状態にある間に回タイマー詳細設定(ひいては通知その特定のためにそれを再武装)させることができます。再開方法の構文は、[2]の通りであります:
"RM" ":" 0*(WSP) "LCK/lockstep"
"RM" ":" 0 *(WSP) "LCK /ロックステップ"
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は "ロックステップ" RestartMethodで使用されていない([2]参照します)。また、「ロックステップ」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].
付録C.1に示すように名前「LCK」とバージョン番号ゼロのMGCPパッケージタイトル「ロックステップ」は、IANAに登録されている[2]。
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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[2]アンドレア、F.およびB.フォスター、 "メディアゲートウェイコントロールプロトコル(MGCP)バージョン1.0"、RFC 3435、2003年1月。
Authors' Addresses
著者のアドレス
Bill Foster
ビル・フォスター
Phone: +1 250 758 9418 EMail: bfoster@cisco.com
電話:+1 250 758 9418 Eメール:bfoster@cisco.com
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
フレミングAndreasenのシスコシステムズ499 Thornallストリート、8階エジソン、NJ 08837
EMail: fandreas@cisco.com
メールアドレス:fandreas@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権(C)インターネット協会(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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。