[要約] RFC 3573は、L2TPでのモデムオンホールド状態のシグナリングに関する仕様です。このRFCの目的は、L2TPセッション中にモデムオンホールド状態を通知するためのメカニズムを提供することです。
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)
レイヤー2トンネルプロトコル（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.
Copyright（c）The Internet Society（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.
モデム操作を管理する標準の1つは、クライアントモデムがコールを保留し、後で最小限の遅延でモデムリンクを再確立できるようにする手順を定義します。モデムコールは保留中ですが、クライアントの電話回線を使用して他の通話を配置または受信できます。
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ベースプロトコルは、Modemが物理的に接続されているL2TP Access Controller（LAC）から、PPPセッションが処理されるL2TPネットワークサーバー（LNS）にこれらのイベントを信号する手段を提供しません。
This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold.
このドキュメントでは、LACに接続されたクライアントモデムが電話を保留したことをLNSに知らせる方法について説明します。
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]は、モデム操作を管理する標準の1つであり、クライアントモデムがコールを保留し、後でモデムリンクを再確立できるようにする手順を定義します。モデムコールは保留中ですが、クライアントの電話回線は別の電話に使用できます。
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ベースプロトコルは、Modemが物理的に接続されているL2TP Access Controller（LAC）から、PPPセッションが処理されるL2TPネットワークサーバー（LNS）にこれらのイベントを信号する手段を提供しません。この情報（LACでのみ利用可能）がLNSに提供されることが望ましい場合があります。
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.
このドキュメントは、LACからLNSへのモデム情報を通信するために使用できる追加の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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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に通話をオンに合わせて配置するように信号を送信できます（通常、フラッシュフック）。リモートシステムのユーザーは、クライアントモデムが接続されているのと同じポットラインを使用して、別の呼び出しを作成または受信できます。
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が考慮する可能性のあるアクションのサンプルは、セクション5にリストされています。ただし、LNSは、モデムオンホールド表示の現在の状態に関係なく、LACから到着する有効なデータパケットの処理を停止してはなりません。
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）制御メッセージを送信してはなりません。この機能は、トンネルが育てられたときにLACに送信されたSCCRQまたはSCCRPに「モデムオンホールド対応可能な」AVPを追加することによって示されます。
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はH（hold）フィールドが1に設定され、最大オンホールド時間を変更したMDMSTコントロールメッセージをLNSに送信する必要があります。
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はMDMSTコントロールメッセージをH（Hold）フィールドを0に設定してLNSに送信する必要があります。H（hold）フィールドが1に設定されています。
The following control messages MUST be sent with the M-bit in the Message Type AVP set to 0 to prevent interoperability issues.
次のコントロールメッセージは、相互運用性の問題を防ぐために、メッセージタイプAVPを0に設定してM-Bitで送信する必要があります。
Messages with unknown values in the Message Type AVP with the M-bit set to 0 should be ignored by compliant L2TP peers [RFC2661].
メッセージタイプのAVPに未知の値を持つメッセージは、Mビットを0に設定していることを、準拠した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.
Modem-Status（MDMST）コントロールメッセージは、Client Modemのオンホールドステータスが変更されたときに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コントロールメッセージは、開始コントロール接続-Request（SCCRQ）またはStart-Control-Connection-Reply（SCCRP）コントロールメッセージに「モデムオンホールド能力がある」AVPを含めていないピアに送信してはなりません。
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).
さらに、MDMSTコントロールメッセージは、セッションの確立が成功した後にのみ送信できます（つまり、LACが着信コール接続（ICCN）または発信コール接続（OCCN）コントロールメッセージのいずれかを送信した後、セッションは、LACの視点から終了します（つまり、LACがCall-Disconnect-Notify（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コントロールメッセージを送信できることに注意してください。LNSは、CDNを送信した後に受信したMDMSTコントロールメッセージを無視する必要があります。
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ビットは0に設定する必要があります。長さは6です。
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の属性値フィールドには、次の形式があります。
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は16ビットの数量で、クライアントモデムがコールをオンにして配置したかどうか、コールの最大時間を維持することが許可されている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（hold）フィールドは、クライアントモデムがコールをオンホールドに配置したかどうかを示す単一のビットです。h（hold）フィールドが1の場合、クライアントモデムはオンになります。H（hold）フィールドが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:
タイムアウトフィールドは4ビットの数量で、通話が耐えられたままになる可能性があるネゴシエートされた最大時間を示しています。H（hold）フィールドが1の場合にのみ有効であり、H（hold）フィールドが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ビットは0に設定する必要があります。長さは8です。
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.
* LCPエコーリクエスト、リンク品質監視（LQM）、マルチリンクPPP（MP）などのポーリングプロトコルを一時的に停止します。
*現在オンホールドのリモートクライアントに向けられたデータパケットをドロップします。
*新しい会計セッションを開始して、オンホールド時間を説明します。
*モデムが再びオンラインに戻るまで、会計を停止または保持します。
*モデムが保留中の時間のために、別の時間を考慮して開始します。
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 Keepalivesに答えます。理由：クライアントがオンラインで戻ると、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によって割り当てられる新しいL2TP「メッセージタイプ」番号が1つ必要です。
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によって割り当てられた一連の予約ビット（ビット1〜11）が含まれています。
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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。およびB. Peter、「レイヤー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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
[STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[Std51] Simpson、W。、「ポイントツーポイントプロトコル（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.
Lucent TechnologiesのJosh Bailey、Emmanuel Hislen、Marc Bongartzは、このドキュメントとその実装をレビューする際に非常に貴重な助けを提供しました。
Mark Townsley of Cisco Systems provided helpful guidance.
Cisco SystemsのMark Townsleyは、有益なガイダンスを提供しました。
Thomas Narten of IBM Corporation provided invaluable insights and suggestions.
IBM CorporationのThomas 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
Ignacio Goyret Lucent Technologies 1801 Harbor Bay Parkway Alameda、CA 94502
EMail: igoyret@lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。