RFC3992 日本語訳

Network Working Group                                          B. Foster
Request for Comments: 3992                                  F. Andreasen
Category: Informational                                    Cisco Systems
                                                           February 2005

コメントを求めるワーキンググループB.フォスターの要求をネットワークでつないでください: 3992年のF.Andreasenカテゴリ: 情報のシスコシステムズ2005年2月

                 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)インターネット協会(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プロトコルについて説明します。 ImplementersはMGCPがIETFとITU-Tによってアドレスに設計されたのをRFC3015を意識しているべきです。(RFCはIETF Megaco作業部会とITU-T SG16で開発されて、需要を満たす規格ベース(包含はセキュリティ問題を見直した)の方法であると考えられます)。

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.

出来事が検疫されますが、通知されない堅苦しい州で不利な失敗条件(Callエージェントフェイルオーバーが起こったとき、一時的な呼び出しにかかわるように)に遭遇したメディアゲートウェイControlプロトコル(MGCP)終点は出ることができました。 本書では説明されたMGCPパッケージは新しいCallエージェントが必要な欠点リカバリ手順を取ることができるようにこれらの状況を報告するのにメカニズムを提供します。

1.  Introduction

1. 序論

   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.

メディアゲートウェイControlプロトコル(MGCP)[2]では、「ステップ」モードで作動する終点がNotifyを発生させると、それは通知状態に入るでしょう。そこでは、それがNotifyへの応答を待ちます。 その上、イベント処理を再開できる前に終点は新しいNotificationRequestを待たなければなりません。 終点がこのNotificationRequestを待っている限り、私たちは、それが堅苦しい状態にあると言います。

Foster & Andreasen           Informational                      [Page 1]

RFC 3992        MGCP Lockstep State Reporting Mechanism    February 2005

フォスターとAndreasenの情報[1ページ]のRFC3992MGCP型にはまったやり方はメカニズム2005年2月に報告を述べます。

   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を発生させることができません。 終点が非常に短い間堅苦しい状態にあるだけであるべきです。 しかしながら、逆の条件で、Callエージェントがそれがわからないで、終点は潜在的に堅苦しい状態に終わるかもしれません。 明確に、これで、サービスによる非常に否定的な結果を提供するかもしれません。

   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.

本書では定義されたLockstepパッケージはCallエージェントがいつ、終点が指定された期間の間、堅苦しい状態にあるかをそれに知らせるよう終点に要求できるEndpointConfigurationとRestartInProgressコマンドと拡大を定義します。

1.1.  Conventions Used in This Document

1.1. 本書では使用されるコンベンション

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。

2.  Lockstep Package

2. 堅苦しいパッケージ

   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.

* Callエージェントのための報告する終点がそれらであるなら指定された期間の間、堅苦しい状態にあるという要求への能力。 セクション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.

* 報告メカニズム自体。(そのメカニズムがRSIPコマンドのために新しい「堅苦しい」RestartMethodと共にセクション2.2で説明されるように行われます)。

2.1.  Request to Report Lockstep State

2.1. 堅苦しい状態を報告するという要求

   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*(4DIGIT)

Foster & Andreasen           Informational                      [Page 2]

RFC 3992        MGCP Lockstep State Reporting Mechanism    February 2005

フォスターとAndreasenの情報[2ページ]のRFC3992MGCP型にはまったやり方はメカニズム2005年2月に報告を述べます。

   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.

値が0〜9999年まで及んでいてLSTIMEが秒に急送されるところ。 参照してください。2*T-HISTより大きい値、([2])には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.

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コマンドを使用することによって、このパラメタを監査できます。 値でないときに、返された値は最後に構成された値であるか値ゼロは構成されました。

2.2.  Lockstep Restart Method

2.2. 堅苦しい再開方法

   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のために非ゼロ値によって構成されて、そのタイマが期限が切れたなら、このRestartMethodと共にRestartInProgress(RSIP)を送るでしょう。 堅苦しいタイマがいったん設定されると、それがNotifyコマンドに一度だけ発火できることに注意してください。 しかしながら、タイマをさらに設定するのは終点が堅苦しい状態にある間の(したがって、その特定のNotifyのためにそれを再軍備させてください)一度より可能です。 再開方法の構文が[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、([2])が「堅苦しい」RestartMethodと共に使用されないのを確実にしてください。 また、「堅苦しい」RestartMethodはサービス状態を定義しません、そして、RestartMethodを監査するとき、その結果、それを決して返さないでしょう。

3.  IANA Considerations

3. IANA問題

   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に示されました。

4.  Security Considerations

4. セキュリティ問題

   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

ベースMGCP仕様[2]のセクション5はベースMGCPプロトコルのための等しく本書では定義されたパッケージに適用されるセキュリティ要件について論じます。 通報認証単位で提供するIPsec(RFC2401、RFC2406)などのセキュリティプロトコルと保全サービスの使用が、要求と応答が認証されたソースとそのメッセージから得られるのを保証するのに必要です。

Foster & Andreasen           Informational                      [Page 3]

RFC 3992        MGCP Lockstep State Reporting Mechanism    February 2005

フォスターとAndreasenの情報[3ページ]のRFC3992MGCP型にはまったやり方はメカニズム2005年2月に報告を述べます。

   have not been modified.  Without these services, gateways and Call
   Agents are open to attacks.

変更されないでください。 これらのサービスがなければ、ゲートウェイとCallエージェントは攻撃にオープンです。

5.  Normative References

5. 引用規格

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

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[2] Andreasen、F.、およびB.フォスター、「メディアゲートウェイコントロールは2003年1月にバージョン1インチ、(MGCP)RFC3435について議定書の中で述べます」。

Authors' Addresses

作者のアドレス

   Bill Foster

ビル・フォスター

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

以下に電話をしてください。 +1 9418年の250 758メール: bfoster@cisco.com

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

ニュージャージー フレミングAndreasenシスコシステムズ499Thornall通り、第8Floorエディソン、08837

   EMail: fandreas@cisco.com

メール: fandreas@cisco.com

Foster & Andreasen           Informational                      [Page 4]

RFC 3992        MGCP Lockstep State Reporting Mechanism    February 2005

フォスターとAndreasenの情報[4ページ]のRFC3992MGCP型にはまったやり方はメカニズム2005年2月に報告を述べます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78と、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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Foster & Andreasen           Informational                      [Page 5]

フォスターとAndreasen情報です。[5ページ]