Network Working Group I. Goyret
Request for Comments: 3573 Lucent Technologies
Category: Standards Track July 2003
Signaling of Modem-On-Hold status
in Layer 2 Tunneling Protocol (L2TP)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network.
レイヤ2トンネリングプロトコル（L2TP）がトンネリングポイントツーポイントプロトコル（PPP）セッションのためのメカニズムを定義します。これらのPPPセッションは、公衆交換電話網を介して接続されたモデムを使用して確立されることが一般的です。
One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls.
モデムの操作を管理する基準の一つは、保留に電話を入れて、後で、最小限の遅延でリダイヤルすることなく、モデムリンクを再確立するためのクライアントモデムを有効にする手順を定義します。モデムコールが保留されますが、クライアント電話回線は、他の電話をかけるまたは受信するために使用することができます。
The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled.
L2TPベースのプロトコルは、モデムがPPPセッションが処理されるL2TPネットワークサーバー（LNS）に、物理的に接続されているL2TPアクセスコントローラ（LAC）からこれらのイベントを通知するための任意の手段を提供しません。
This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold.
この文書では、LNSは、LACに接続されたクライアントモデムが保留に電話を置いたときに知らせる方法を説明しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Typical Modem on Hold Usage Scenario . . . . . . . . . . 4
2.2. Capability Negotiation . . . . . . . . . . . . . . . . . 4
2.3. Modem On-Hold. . . . . . . . . . . . . . . . . . . . . . 5
2.4. Modem Online . . . . . . . . . . . . . . . . . . . . . . 5
3. New Control Messages . . . . . . . . . . . . . . . . . . . . . 5
3.1. Modem-Status (MDMST) . . . . . . . . . . . . . . . . . . 5
4. New Attribute Value Pairs. . . . . . . . . . . . . . . . . . . 6
4.1. Modem On-Hold Capable AVP. . . . . . . . . . . . . . . . 6
4.2. Modem On-Hold Status AVP . . . . . . . . . . . . . . . . 6
5. Sample LNS Actions . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A: Vendor Specific Assignments. . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a general purpose mechanism for tunneling Point-to-Point Protocol (PPP) [STD51] sessions over various media. By design, the operation of L2TP is insulated from the details of the media from which the PPP session originated.
レイヤ2トンネリングプロトコル（L2TP）[RFC2661]は、様々なメディア上のトンネルポイントツーポイントプロトコル（PPP）[STD51]セッションのための汎用メカニズムを定義します。設計によって、L2TPの動作は、PPPセッションが開始されたメディアの詳細から絶縁されています。
It is common for PPP sessions to be established using modems connected over the public switched telephone network. The ITU-T Recommendation V.92 [V92] is one of the standards governing modem operation and it defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link without having to redial. While the modem call is on hold, the client phone line can be used for another phone call.
PPPセッションは、公衆交換電話網を介して接続されたモデムを使用して確立されることが一般的です。 ITU-T勧告V.92 [V92]は、モデムの動作を管理する規格の一つである、それは保留に電話を入れて、後で、リダイヤルしなくても、モデムリンクを再確立するためのクライアントモデムを有効にする手順を定義します。モデムコールが保留されますが、クライアント電話回線は別の電話番号に使用することができます。
The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. It may be desirable for this information (which is available only on the LAC) to be provided to the LNS.
L2TPベースのプロトコルは、モデムがPPPセッションが処理されるL2TPネットワークサーバー（LNS）に、物理的に接続されているL2TPアクセスコントローラ（LAC）からこれらのイベントを通知するための任意の手段を提供しません。これは、LNSに提供する（LACのみで利用可能である）、この情報のために望ましいかもしれません。
This document provides additional L2TP AVPs and control messages that may be used to communicate some modem information from the LAC to the LNS. However, it does not define what, if anything, the LNS should do with this information. A sample of the possible actions that an LNS may consider are listed in section 5.
この文書では、LNSにLACからいくつかのモデム情報を通信するために使用することができる追加のL2TPのAVP及び制御メッセージを提供します。しかし、それはどちらかと言えば、LNSはこの情報で何をすべきか、定義されていません。 LNSは考えるかもしれ可能なアクションのサンプルは、セクション5に記載されています。
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 [BCP14].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [BCP14]で説明されるように解釈されます。
Definition of terms used in this document may be found in the L2TP Protocol document [L2TP].
このドキュメントで使用される用語の定義は、L2TPプロトコルドキュメント[L2TP]で見つけられるかもしれません。
The typical dial in topology looks like this:
トポロジ内の典型的な文字盤には次のようになります。
+-----+ { } +----------+ [ IP ]
| |-[M]-----{ PSTN }-----[SM] |.....[ network ]
+-----+ { } +----------+ [ ]
Remote NAS
System
M is the client modem and may be an integral part of the Remote System. If this modem implements V.92, it can ask the server modem SM (a part of the NAS) whether the call can be placed on-hold for some period of time.
Mは、クライアントモデムであり、リモートシステムの不可欠な一部であってもよいです。このモデムがV.92を実装している場合、それは、コールがしばらくの間保留に置くことができるかどうか、サーバーのモデムSM（NASの一部）を求めることができます。
If the server modem agrees, the client modem can signal the PSTN to place the call on-hold (usually, a flash hook). The user at the remote system can then use the same POTS line where the client modem is connected to make or receive another call.
サーバーのモデムが同意した場合、クライアントモデムは保留コール（通常は、フラッシュフック）を配置するPSTNに信号を送ることができます。リモートシステムのユーザは、クライアントモデムが作るか、または別のコールを受信するように接続されているのと同じPOTSラインを使用することができます。
In the above scenario, the server modem module can notify the rest of the NAS of these events via its usual signaling mechanism. The NAS layers can then act on this information as desired. See section 5. for a sample list of possible actions.
上記のシナリオでは、サーバモデムモジュールは、その通常のシグナル伝達機構を介してこれらのイベントのNASの残りの部分に通知することができます。所望に応じてNAS層は、この情報に基づいて行動することができます。可能なアクションのサンプルリストのセクション5を参照してください。
In the case of L2TP, this document looks at this particular topology:
L2TPの場合には、この文書では、この特定のトポロジになります。
+-----+ { } +-----+ [ packet ] +-----+ [ home ]
| |-[M]---{ PSTN }---[SM] |...[ network ]...| |...[ network ]
+-----+ { } +-----+ [ ] +-----+ [ ]
Remote LAC LNS
System
If the LAC implements the functionality described here, it can signal to the LNS when the client modem has gone on-hold and when it comes back online.
LACは、ここで説明した機能を実装している場合、クライアントモデムが保留になったとき、それがオンラインに戻ったとき、それはLNSに知らせることができます。
This document does not define what, if anything, the LNS should do with this information. A sample of the possible actions that an LNS MAY consider are listed in section 5. However, the LNS MUST NOT stop processing otherwise valid data packets arriving from the LAC, regardless of the current state of the modem on-hold indications.
この文書では、どちらかといえば、LNSはこの情報で何をすべきか、定義されていません。 LNSは考えるかもしれない可能なアクションのサンプルは、表示を保持する上で、LNSは、モデムの現在の状態にかかわらず、LACから到着するそうでない場合は、有効なデータ・パケットの処理を停止してはならない。しかし、セクション5に記載されています。
A user connects to his Internet service provider with a V.92-capable modem. He then starts downloading a big file which will take several minutes to complete.
ユーザーは、V.92対応モデムと彼のインターネットサービスプロバイダに接続します。彼はその後、完了するまでに数分かかります大きなファイルのダウンロードを開始します。
While the file is being downloaded, a friend calls him. If the user has call waiting enabled, his modem can let him know of the incoming call and he can choose to either pick up the incoming call or reject it. Let's say he chooses to pick up the phone to talk to his friend, for example because he recognized the caller's phone number.
ファイルがダウンロードされている間、友人は彼を呼び出します。ユーザーがコールウェイティングを有効にしている場合は、彼のモデムは彼が着信を知らせることができ、彼は、着信コールをピックアップまたはそれを拒否するかを選択することができます。のは、彼が彼が発信者の電話番号を認識しているため、たとえば、彼の友人に話すために電話を拾うことを選択したとしましょう。
Before the user picks up his phone, he tells his modem to go on hold and switch to the incoming call (usually signaled with a "flash-hook"). His modem will then notify the server modem (attached to the LAC) that it is about to go on hold. If the server modem agrees, the client performs a flash hook so the user can talk to his friend.
ユーザーが自分の携帯電話を拾う前に、彼は保留に行くと（通常は「フラッシュ・フック」と合図）着信に切り替えるために彼のモデムに指示します。彼のモデムは、保留に行くとしている（LACに添付）サーバーモデムを通知します。サーバーのモデムが同意した場合、ユーザーが自分の友人に話すことができるように、クライアントは、フラッシュフックを実行します。
After talking to his friend, the user let's his modem know that it can return to the original call (where the server modem has been patiently waiting). After another flash hook, the modems are connected again and the download can continue.
彼の友人と話をした後、ユーザーは自分のモデムが、それは（サーバモデムは辛抱強く待っていた）元の通話に戻ることができることを知ってみましょう。別のフラッシュフックした後、モデムが再び接続され、ダウンロードを続行することができます。
A LAC MUST NOT send a Modem Status (MDMST) control message to an LNS that has not indicated the capability of processing such control messages. This capability is indicated by adding a "Modem On-Hold Capable" AVP on the SCCRQ or SCCRP sent to the LAC when the tunnel is brought up.
LACは、制御メッセージを処理する能力を示していないLNSにモデムステータス（MDMST）制御メッセージを送ってはいけません。この機能は、SCCRQかSCCRPの「モデムオンホールドが可能な」AVPを追加することによって示されているトンネルが育っているときLACに送られます。
When the client modem requests the LAC to go on-hold, the LAC SHOULD send a MDMST control message to the LNS with the H (Hold) field set to 1 and the negotiated maximum on-hold time.
クライアントモデムが保留行くためにLACを要求すると、LACは1に設定さH（ホールド）フィールドと交渉し、最大保留時間とLNSにMDMST制御メッセージを送信する必要があります。
When the client modem returns back online after having gone on-hold, the LAC SHOULD send a MDMST control message to the LNS with the H (Hold) field set to 0. The LAC MUST send this message if it has previously sent a MDMST message with the H (Hold) field set to 1.
クライアントモデムが保留行った後、再びオンラインに戻った場合、LACは、H（ホールド）とLNSにMDMST制御メッセージを送信する必要がありますフィールドセット0に、それは以前にMDMSTメッセージを送信した場合LACは、このメッセージを送らなければなりません1に設定さH（ホールド）フィールドを持ちます。
The following control messages MUST be sent with the M-bit in the Message Type AVP set to 0 to prevent interoperability issues.
次の制御メッセージは、相互運用性の問題を防ぐために、0にメッセージタイプAVPセットでMビットを送らなければなりません。
Messages with unknown values in the Message Type AVP with the M-bit set to 0 should be ignored by compliant L2TP peers [RFC2661].
0に設定するMビットを有するメッセージタイプAVPにおける未知の値を持つメッセージは、対応L2TPピア[RFC2661]によって無視されるべきです。
The Modem-Status (MDMST) control message is used by the LAC to notify the LNS when the client modem on-hold status changes.
モデムステータス（MDMST）制御メッセージをLNSクライアントモデムが保留状態の変更を通知するためにLACによって使用されます。
The MDMST control message MUST NOT be sent to peers that have not included the "Modem On-Hold Capable" AVP in their Start-Control-Connection-Request (SCCRQ) or Start-Control-Connection-Reply (SCCRP) control messages.
MDMST制御メッセージは、そのスタートコントロール接続要求（SCCRQ）に「モデムオンホールドが可能な」AVPを含めるか（SCCRP）制御メッセージコントロール接続返信を起動していないピアに送ってはいけません。
Furthermore, the MDMST control message can only be sent after session establishment is successful (i.e., after the LAC has sent either an Incoming-Call-Connected (ICCN) or an Outgoing-Call-Connected (OCCN) control message), and before the session ends from the LAC's point of view (i.e., before the LAC has sent or received a Call-Disconnect-Notify (CDN) control message).
セッションの確立が成功した後（LACは（ICCN）を呼び出して接続され、着信または発信コール接続（OCCN）制御メッセージのいずれかを送信した後、すなわち）、および前にさらに、MDMST制御メッセージのみを送信することができますセッションは、ビューのLACのポイント（すなわち、LACが送信またはコールを切断-通知（CDN）制御メッセージを受信する前）から終了します。
Note that due to protocol race conditions, it is possible for a LAC to send a MDMST control message about the same time that the LNS is sending a CDN. An LNS MUST ignore MDMST control messages received after sending a CDN.
LACは、LNSは、CDNを送信しているのと同じ時間程度MDMST制御メッセージを送信するために起因するプロトコルの競合状態に、それが可能であることに注意してください。 MDMST制御メッセージを無視しなければなりませんLNSは、CDNを送信した後に受け取りました。
An LNS MUST ignore redundant modem status reports.
LNSは、冗長モデムステータスレポートを無視しなければなりません。
This control message is encoded as follows:
これは次のように制御メッセージが符号化されます。
Vendor ID = 0 (IETF) Attribute Type = 17
ベンダーID = 0（IETF）属性タイプ= 17
The following AVPs MUST be present in the MDMST control message:
以下のAVPはMDMST制御メッセージ内に存在していなければなりません。
Message Type Modem On-Hold Status
メッセージタイプモデムオンホールドステータス
The M-bit on the Message Type AVP for this control message MUST be set to 0.
この制御メッセージのメッセージタイプAVPにMビットが0に設定しなければなりません。
The following sections contain a list of the new L2TP AVPs defined in this document.
次のセクションでは、この文書で定義された新しいL2TPののAVPのリストが含まれています。
The Modem On-Hold Capable AVP, Attribute Type 53, indicates that the sender (an LNS) is capable of receiving MDMST control messages. This AVP MUST be included on the SCCRQ or SCCRP control messages to indicate that the sender implements this specification.
保留できるAVPモデム、53属性タイプは、送信者（LNS）はMDMST制御メッセージを受信することが可能であることを示しています。このAVPは、送信者がこの仕様を実装していることを示すために、SCCRQかSCCRP制御メッセージに含まれなければなりません。
This AVP has no Attribute Value field.
このAVPには属性値のフィールドを持っていません。
This AVP MAY be hidden (the H-bit on the AVP header MAY be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length is 6.
このAVPは、（AVPヘッダ上のHビットは、0または1でもよい）隠すことができます。このAVPのためのMビットは、長さが6である0に設定しなければなりません。
The Modem On-Hold Status AVP, Attribute Type 54, indicates the current on-hold status of the client modem. This AVP MUST be present on the MDMST control message.
モデムオンホールド状態AVP、属性タイプ54、クライアント側のモデムの現在の保留状態を示します。このAVPはMDMST制御メッセージに存在しなければなりません。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| reserved |Timeout|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Modem On-Hold Status AVP is a 16-bit quantity, containing two fields that indicate whether the client modem has placed the call on-hold and the maximum amount of time that the call is allowed to remain on-hold.
モデムオンホールド状態AVPは、クライアントモデムが保留呼及び呼が保留のままに許可される最大時間を置いているかどうかを示す2つのフィールドを含む、16ビット量です。
The H (Hold) field is a single bit that indicates whether the client modem has placed the call on-hold. If the H (Hold) field is 1, the client modem is on-hold. If the H (Hold) field is 0, the client modem is back online.
H（ホールド）フィールドは、クライアントモデムが保留呼を置いているかどうかを示す単一ビットです。 H（ホールド）フィールドが1の場合は、クライアントモデムは保留です。 H（ホールド）フィールドが0の場合、クライアントモデムがオンラインに戻りました。
The Timeout field is a 4 bits quantity that indicates the negotiated maximum amount of time that the call can remain on-hold. It is valid only if the H (Hold) field is 1 and MUST be ignored if the H (Hold) field is 0. The values for the Timeout field are defined in [V92] and they are reproduced here for easy reference:
Timeoutフィールドは、コールが保留のままことができる時間のネゴシエートされた最大量を示す4ビットの量です。 H（ホールド）フィールドが1であり、無視されなければならない場合にのみ、H（ホールド）フィールドがタイムアウトフィールドの0の値は、[V92]で定義されていると、彼らは簡単に参照のためにここに再現されている場合には有効です。
Bits Decimal Meaning
---- ------- -------
0000 0 Reserved
0001 1 10 seconds
0010 2 20 seconds
0011 3 30 seconds
0100 4 40 seconds
0101 5 1 minute
0110 6 2 minutes
0111 7 3 minutes
1000 8 4 minutes
1001 9 6 minutes
1010 10 8 minutes
1011 11 12 minutes
1100 12 16 minutes
1101 13 No limit
1110 14 Reserved
1111 15 Reserved
Bits 1 through 11 are reserved. These bits MUST be set to 0 when sending this AVP and MUST be ignored on reception.
ビット1〜11は予約されています。このAVPを送信し、受信時には無視しなければならない場合、これらのビットを0に設定しなければなりません。
This AVP MAY be hidden (the H-bit on the AVP header MAY be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length is 8.
このAVPは、（AVPヘッダ上のHビットは、0または1でもよい）隠すことができます。このAVPのためのMビットは、長さが8である0に設定しなければなりません。
The specific actions taken by an LNS upon receipt of a Modem On-Hold Status AVP are implementation dependent. This document does not mandate what, if anything, the LNS should do with this information.
モデムオンホールド状態AVPを受信すると、LNSで撮影した具体的なアクションは実装に依存しています。この文書では、どちらかといえば、LNSはこの情報で何をすべきか、強制しません。
The choice of actions taken by the LNS may have an impact on higher layer protocols. For example, TCP connections and other connection-oriented applications may timeout or disconnect during the on-hold time. The impact that those choices may have on these or other protocols is not addressed by this document.
LNSによって取られた行動の選択は、上位層プロトコルに影響を及ぼす可能性があります。例えば、TCP接続および他の接続指向のアプリケーションは、保留時間中にタイムアウトまたは切断してもよいです。これらの選択肢は、これらまたは他のプロトコルに与える影響は、本文書によって対処されていません。
The following list is a sample of possible actions that an LNS implementation might consider. Note that some of these actions are not really alternatives, as some of the possibilities preclude others.
以下のリストは、LNSの実装が検討するかもしれない可能なアクションのサンプルです。いくつかの可能性が他のものを排除するよう、これらのアクションのいくつかは、実際に選択肢はないことに注意してください。
* Temporarily stop polling protocols such as LCP Echo Requests, Link Quality Monitoring (LQM), Multilink PPP (MP), etc. * Drop data packets directed to the now on-hold remote client. * Start a new accounting session, to account for the on-hold time. * Stop or hold accounting until the modem returns online again. * Start a separate time accounting for the time that the modem is on hold.
*一時的に、リンク品質等、（LQM）、マルチリンクPPP（MP）*ドロップデータパケットは、現在保留のリモートクライアントに向けモニタリングなどLCPエコー要求としてポーリングプロトコルを停止します。 *保留時間を考慮して、新会計セッションを開始します。 *停止またはモデムが再びオンラインに戻るまで占めて開催。 *モデムが保留されている時間を占めて別々の時間を開始します。
Here are a few things that an LNS should probably NOT do:
ここではLNSは、おそらくすべきではないいくつかのことがあります：
* Buffer data packets directed to the now on-hold remote client. Reason: How many data packets should be buffered? What would be the impact on higher layer protocols such as TCP? What would be the impact caused by the delay introduced when the client returns online again?
今保留のリモートクライアントに向け*バッファのデータパケット。理由：どのように多くのデータパケットをバッファリングする必要がありますか？ TCPのような上位層プロトコルへの影響は何でしょうか？何は、クライアントが再びオンラインに戻ったときに導入された遅延による影響でしょうか？
* Answer TCP keepalives in lieu of the client. Reason: It may interfere with TCP's recovery once the client returns online.
*クライアントの代わりに回答TCPキープアライブ。理由：クライアントがオンライン返したら、それはTCPの回復を妨げる可能性があります。
* Stop processing otherwise valid data packets from the client. Reason: There is a race condition between the notification of the modem returning online and the first packet from the client because they are delivered on independent channels. Dropping valid client packets may lead to a slower recovery after returning online due to the forced retries.
*クライアントからそうでない場合は、有効なデータパケットの処理を停止。理由：彼らは独立したチャネルで配信されているため、オンラインでの復帰モデムの通知と、クライアントからの最初のパケット間の競合状態があります。有効なクライアントパケットをドロップすることは、強制的に再試行するオンライン戻った後に遅い回復につながる可能性があります。
This document requires one new L2TP "Message Type" number to be assigned by IANA:
この文書は、IANAによって割り当てられる1新しいL2TP「メッセージタイプ」番号が必要です。
17, Section 3.1., Modem Status
17、セクション3.1。、モデムステータス
It also requires two new "AVP Attributes" to be assigned by IANA:
また、IANAによって割り当てられることには、2つの新しい「AVP属性」が必要です。
53, Section 4.1., Modem On-Hold Capable AVP 54, Section 4.2., Modem On-Hold Status AVP
53、セクション4.1。、モデムオンホールドできるAVP 54、セクション4.2。、モデムオンホールド状態AVP
The Modem On-Hold Status AVP contains a set of reserved bits (bits 1 through 11) that are assigned by IANA through IETF Consensus [BCP26].
モデムオンホールド状態AVPは、IETFコンセンサス[BCP26]を通してIANAによって割り当てられた予約済みビット（ビット11を介して、1）のセットを含みます。
The integrity and confidentiality of the method described in this document relies on the underlying L2TP security mechanisms. The new control message and AVPs are intended to indicate when a client modem has gone on-hold and cannot receive data. It does not define what, if anything, the LNS should do with this information. A sample of possible actions that an LNS may consider are listed in section 5.
この文書に記載された方法の完全性と機密性は、基礎となるL2TPセキュリティメカニズムに依存しています。新しい制御メッセージとのAVPは、クライアントモデムが保留になったとのデータを受信できないことを示すために意図されています。それはどちらかといえば、LNSはこの情報で何をすべきか、定義されていません。 LNSは考えるかもしれ可能なアクションのサンプルは、セクション5に記載されています。
It is believed that the defined extension does not provide information that would be useful to an attacker, and as such, it should not pose a threat to system security.
定義された拡張子が攻撃者に有用であろう情報を提供しない、そのように、それはシステムのセキュリティに脅威を与えるべきではないと考えられています。
If desired, the new AVPs MAY be hidden as described in section 4.3 of [RFC2661].
所望であれば、[RFC2661]のセクション4.3に記載されているように、新規のAVPを隠すことができます。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Peter, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999.
[RFC2661] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、G。およびB.ピーター、 "レイヤ2トンネリングプロトコル（L2TP）"、RFC 2661、1999年8月。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[BCP26] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[V92] ITU-T Recommendation V.92, "Enhancements to Recommendation V.90", November 2000
[V92] ITU-T勧告V.92、 "勧告V.90の強化"、2000年11月
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[BCP9]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
WITH [STD 51]シンプソン、。、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
Josh Bailey, Emmanuel Hislen and Marc Bongartz of Lucent Technologies provided invaluable help in reviewing this document and its implementation.
ジョシュ・ベイリー、エマニュエルHislenとルーセント・テクノロジーズのマークBongartzは、このドキュメントとその実装を検討中で非常に貴重な支援を提供します。
Mark Townsley of Cisco Systems provided helpful guidance.
シスコシステムズのマークTownsleyは有用なガイダンスを提供します。
Thomas Narten of IBM Corporation provided invaluable insights and suggestions.
IBM社のトーマスNarten氏は、非常に貴重な洞察とアドバイスを提供しました。
Appendix A: Vendor Specific Assignments
付録A：ベンダー固有の割り当て
THIS SECTION IS NOT NORMATIVE
このセクションでは、規範的ではありません
Early implementations of this specification used vendor-specific values for the new control message and AVPs. This appendix describes those initial vendor-specific assignments for historical reference only.
この仕様の初期の実装では、新たな制御メッセージとのAVPのベンダー固有の値を使用します。この付録では、唯一の歴史的な参照のために、これらの初期のベンダー固有の割り当てについて説明します。
The following table shows the vendor-specific assignments:
次の表は、ベンダー固有の割り当てを示しています。
Vendor Attr Attr
ID Type Value Equivalent to
------ ---- ----- -------------
Control message:
Modem-Status 529 0 2 Section 3.1.
AVP: Modem On-Hold Capable 529 2 none Section 4.1. Modem On-Hold Status 529 3 [..] Section 4.2.
AVP：モデムオンホールドできる529 2なしセクション4.1。モデムオンホールドステータス529 3 [..]セクション4.2。
Author's Address
著者のアドレス
Ignacio Goyret Lucent Technologies 1801 Harbor Bay Parkway Alameda, CA 94502
イグナシオGoyretルーセント・テクノロジーズ1801ハーバー・ベイ・パークウェイアラメダ、CA 94502
EMail: igoyret@lucent.com
メールアドレス：igoyret@lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。