RFC3573 日本語訳
3573 Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol(L2TP). I. Goyret. July 2003. (Format: TXT=22758 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group I. Goyret Request for Comments: 3573 Lucent Technologies Category: Standards Track July 2003
Goyretがコメントのために要求するワーキンググループI.をネットワークでつないでください: 3573年のルーセントテクノロジーズカテゴリ: 標準化過程2003年7月
Signaling of Modem-On-Hold status
in Layer 2 Tunneling Protocol (L2TP)
Layer2Tunnelingプロトコルの保持でのModem状態のシグナリング(L2TP)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
Layer2Tunnelingプロトコル(L2TP)はトンネリングPointからポイントへのプロトコル(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ベースプロトコルはL2TP Access Controller(LAC)からこれらの出来事に合図するどんな手段も提供しません、L2TP Network Server(LNS)に。(そこでは、モデムが物理的に接続されます)。そこでは、PPPセッションが扱われます。
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に知らせる方法を説明します。
Goyret Standards Track [Page 1] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[1ページ]RFC3573Signaling
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 要件の仕様。 . . . . . . . . . . . . . 3 1.2. 用語。 . . . . . . . . . . . . . . . . . . . . . . 3 2. 操作. . . . . . . . . . . . . . . . . . . . . . 3 2.1について議定書の中で述べてください。 保持用法シナリオ. . . . . . . . . . 4 2.2の典型的なモデム。 能力交渉. . . . . . . . . . . . . . . . . 4 2.3。 モデム、進行中の保持。 . . . . . . . . . . . . . . . . . . . . . 5 2.4. モデムオンライン. . . . . . . . . . . . . . . . . . . . . . 5 3。 新しいコントロールメッセージ. . . . . . . . . . . . . . . . . . . . . 5 3.1。 モデム状態(MDMST。). . . . . . . . . . . . . . . . . . 5 4 新しい属性値ペア。 . . . . . . . . . . . . . . . . . . 6 4.1. 保持でのモデムのできるAVP。 . . . . . . . . . . . . . . . 6 4.2. モデム保留状態AVP. . . . . . . . . . . . . . . . 6 5 LNS動作. . . . . . . . . . . . . . . . . . . . . . 7 6を抽出してください。 IANA問題。 . . . . . . . . . . . . . . . . . . . . . 8 7. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 9 8. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1。 引用規格. . . . . . . . . . . . . . . . . . 9 8.2。 有益な参照. . . . . . . . . . . . . . . . . 9 9。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 10 付録A: 業者の特定の課題。 . . . . . . . . . . . . . 11作者のアドレスの.12の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
1. 序論
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.
Layer2Tunnelingプロトコル(L2TP)[RFC2661]は様々なメディアの上のトンネリングPointからポイントへのプロトコル(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 Recommendation 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ベースプロトコルはL2TP Access Controller(LAC)からこれらの出来事に合図するどんな手段も提供しません、L2TP Network Server(LNS)に。(そこでは、モデムが物理的に接続されます)。そこでは、PPPセッションが扱われます。 この情報(LACだけで利用可能である)をLNSに提供するのは望ましいかもしれません。
Goyret Standards Track [Page 2] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[2ページ]RFC3573Signaling
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 AVPsとコントロールメッセージを提供します。 LNSはしかしながら、なにかを定義しないか、そして、どちらかと言えば、この情報を処理するはずです。 記載されているLNSがセクション5で考えるかもしれない可能な動作のサンプル。
1.1. Specification of Requirements
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 [BCP14].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[BCP14]で説明されるように本書では解釈されることであるべきです。
1.2. Terminology
1.2. 用語
Definition of terms used in this document may be found in the L2TP Protocol document [L2TP].
本書では使用される用語の定義はL2TPプロトコルドキュメント[L2TP]で見つけられるかもしれません。
2. Protocol Operation
2. プロトコル操作
The typical dial in topology looks like this:
トポロジーの典型的なダイヤルはこれに似ています:
+-----+ { } +----------+ [ IP ]
| |-[M]-----{ PSTN }-----[SM] |.....[ network ]
+-----+ { } +----------+ [ ]
Remote NAS
System
+-----+ { } +----------+ [IP]| |-[M]-----PSTN-----[Sm]|.....[ネットワークでつなぎます] +-----+ { } +----------+ [ ] リモートNASシステム
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は、クライアントモデムであり、Remote Systemの不可欠の部分であるかもしれません。 このモデムが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を見てください。
Goyret Standards Track [Page 3] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[3ページ]RFC3573Signaling
In the case of L2TP, this document looks at this particular topology:
L2TPの場合では、このドキュメントはこの特定のトポロジーを見ます:
+-----+ { } +-----+ [ packet ] +-----+ [ home ]
| |-[M]---{ PSTN }---[SM] |...[ network ]...| |...[ network ]
+-----+ { } +-----+ [ ] +-----+ [ ]
Remote LAC LNS
System
+-----+ { } +-----+ [パケット]+-----+ [家]| |-[M]---PSTN---[Sm]|...[ネットワーク]…| |...[ネットワークでつなぎます] +-----+ { } +-----+ [ ] +-----+ [ ] リモートラックLNSシステム
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 MAYがセクション5で考える可能な動作のサンプル。 しかしながら、LNS MUST NOTは、LACから到着するそうでなければ、有効なデータ・パケットを処理するのを止めます、保持のモデム指摘の現状にかかわらず。
2.1. Typical Modem on Hold Usage Scenario
2.1. 保持用法シナリオの典型的なモデム
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.
彼の友人、ユーザと話した後、彼のモデムは、それがオリジナルの要求(サーバモデムが我慢強く待っているところ)に戻ることができるのを知りましょう。 別のフラッシュフックの後に、モデムは再び接続されます、そして、ダウンロードは続くことができます。
2.2. Capability Negotiation
2.2. 能力交渉
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 MUST NOTはそのようなコントロールメッセージを処理する能力を示していないLNSにModem Status(MDMST)コントロールメッセージを送ります。 トンネルが持って来られるとき、SCCRQかSCCRPの上の「できる保持でモデム」AVPがLACに発信したと言い足すことによって、この能力は示されます。
Goyret Standards Track [Page 4] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[4ページ]RFC3573Signaling
2.3. Modem On-Hold
2.3. モデム、進行中の保持
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 SHOULDは1に設定されたH(保持する)分野と交渉された最大のオン保持時間があるLNSにMDMSTコントロールメッセージを送ります。
2.4. Modem Online
2.4. オンラインモデム
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 SHOULDは0に設定されたH(保持する)分野があるLNSにMDMSTコントロールメッセージを送ります。 それが以前にH(保持する)分野セットがあるMDMSTメッセージを1に送ったなら、LAC MUSTはこのメッセージを送ります。
3. New Control Messages
3. 新しいコントロールメッセージ
The following control messages MUST be sent with the M-bit in the Message Type AVP set to 0 to prevent interoperability issues.
M-ビットでMessage Type AVPセットで以下のコントロールメッセージを0に送って、相互運用性問題を防がなければなりません。
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-ビットがあるMessage Type AVPにあるメッセージは言いなりになっているL2TP同輩[RFC2661]によって無視されるべきです。
3.1. Modem-Status (MDMST)
3.1. モデム状態(MDMST)
The Modem-Status (MDMST) control message is used by the LAC to notify the LNS when the client modem on-hold status changes.
Modem-状態(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.
彼らのStart接続要求(SCCRQ)かStartコントロール接続回答(SCCRP)コントロールを制御しているメッセージに「できる保持でモデム」AVPを含んでいない同輩にMDMSTコントロールメッセージを送ってはいけません。
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が接続されたIncoming要求(ICCN)かOutgoing呼び出しが接続している(OCCN)コントロールメッセージのどちらかを送った後に)後とLACの観点からのセッション終わりまでにMDMSTコントロールメッセージを送ることができるだけです(-すなわち、LACがCall-分離を送るか、または受ける前に(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がほぼ同じ頃MDMSTコントロールメッセージを送るのにおいてLNSがCDNを送るのが、可能であることに注意してください。 LNS MUSTはCDNを送った後に受け取られたMDMSTコントロールメッセージを無視します。
An LNS MUST ignore redundant modem status reports.
LNS MUSTは余分なモデム現状報告を無視します。
Goyret Standards Track [Page 5] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[5ページ]RFC3573Signaling
This control message is encoded as follows:
このコントロールメッセージは以下の通りコード化されます:
Vendor ID = 0 (IETF)
Attribute Type = 17
0(IETF)業者ID=属性タイプ=17
The following AVPs MUST be present in the MDMST control message:
以下のAVPsはMDMSTコントロールメッセージに存在していなければなりません:
Message Type
Modem On-Hold Status
メッセージタイプモデム保留状態
The M-bit on the Message Type AVP for this control message MUST be set to 0.
このコントロールメッセージのためのMessage Type AVPのM-ビットを0に設定しなければなりません。
4. New Attribute Value Pairs
4. 新しい属性値ペア
The following sections contain a list of the new L2TP AVPs defined in this document.
以下のセクションは本書では定義された新しいL2TP AVPsのリストを含みます。
4.1. Modem On-Hold Capable AVP
4.1. 保持でのモデムのできる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.
Modem On-保持Capable AVP(Attribute Type53)は、送付者(LNS)がMDMSTコントロールメッセージを受け取ることができるのを示します。 このAVP MUST、SCCRQか送付者がこの仕様を履行するのを示すSCCRPコントロールメッセージで含められてください。
This AVP has no Attribute Value field.
このAVPには、Attribute Value分野が全くありません。
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 MAY、隠されてください(AVPヘッダーのH-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、0に設定されてください。 Lengthは6歳です。
4.2. Modem On-Hold Status AVP
4.2. モデム保留状態AVP
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.
Modem On-保持Status AVP(Attribute Type54)はクライアントモデムの現在の保留状態を示します。 このAVP MUST、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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H| 予約されます。|タイムアウト| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Modem On-保持Status AVPは16ビットの量です、クライアントモデムが入賞したかどうかを示す2つの分野を含んでいて進行中の保持に電話をしてください、そして、呼び出しが保持していたままで残ることができる最大の時間。
Goyret Standards Track [Page 6] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[6ページ]RFC3573Signaling
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(保持する)分野はクライアントモデムが保持する状態で進行中の電話をしたかどうかを示す1ビットです。 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(保持する)分野が0であるならH(保持する)分野を1であり、無視しなければならない場合にだけ、有効です。 Timeout分野への値は[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
ビットの10進意味---- ------- ------- 0000 0 予約された0001、1000年の40秒0101 0111年の0110年の5 1分6 2分7 3分8 4分の1 10秒の0010 2 20秒の0011 3 30秒の0100 4 1001 9 6分1010 10 8分1011 11 12分1100 12 16分間の1101 13いいえ限界1110 14Reserved1111 15Reserved
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 MAY、隠されてください(AVPヘッダーのH-ビットは、0か1であるかもしれません)。 このAVP MUSTのためのM-ビット、0に設定されてください。 Lengthは8歳です。
5. Sample LNS Actions
5. サンプルLNS動作
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.
Modem On-保持Status 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接続と指向のアプリケーションがそうする他の接続タイムアウトか分離。 それらの選択がこれらか他のプロトコルに持っているかもしれない影響力はこのドキュメントによって記述されません。
Goyret Standards Track [Page 7] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[7ページ]RFC3573Signaling
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 Echo Requestsなどの世論調査プロトコル、Link Quality Monitoring(LQM)、Multilink 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.
* クライアントからそうでなければ、有効なデータ・パケットを処理するのを止めてください。 理由: 独立しているチャンネルでそれらを渡すので、オンラインで戻るモデムの通知とクライアントからの最初のパケットの間には、競合条件があります。 有効なクライアントパケットを落とすのは無理矢理の再試行のためオンラインで戻った後に、より遅い回復に通じるかもしれません。
6. IANA Considerations
6. IANA問題
This document requires one new L2TP "Message Type" number to be assigned by IANA:
このドキュメントは、1新しいL2TP「メッセージタイプ」番号がIANAによって割り当てられるのを必要とします:
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.、保持でのモデムのできるAVP54、セクション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].
Modem On-保持Status AVPはIETF Consensus[BCP26]を通してIANAによって割り当てられる1セットの予約されたビット(ビット1〜11)を含んでいます。
Goyret Standards Track [Page 8] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[8ページ]RFC3573Signaling
7. Security Considerations
7. セキュリティ問題
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セキュリティー対策を当てにします。新しいコントロールメッセージとAVPsは、クライアントモデムがいつ保持しているのに動いて、データを受け取ることができないかを示すつもりです。 それはなにかを定義しないか、そして、どちらかと言えば、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].
望まれているなら、新しいAVPsとして[RFC2661]のセクション4.3で説明されていた状態で隠されるかもしれません。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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.は尽きます、「層Twoはプロトコル(L2TP)にトンネルを堀っ」て、RFC2661、1999年8月。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[V92] ITU-T Recommendation V.92, "Enhancements to Recommendation
V.90", November 2000
[V92]ITU-T推薦V.92、「推薦V.90"、2000年11月までの増進」
8.2. Informative References
8.2. 有益な参照
[BCP9] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[BCP9] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[STD51] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
Goyret Standards Track [Page 9] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[9ページ]RFC3573Signaling
9. Acknowledgments
9. 承認
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は非常に貴重な洞察と提案を提供しました。
Goyret Standards Track [Page 10] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[10ページ]RFC3573Signaling
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.
この仕様の早めの実現は新しいコントロールメッセージとAVPsに業者特有の値を使用しました。 この付録は歴史上の記述だけのためのそれらの初期の業者特有の課題について説明します。
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.
タイプが同等物を評価する業者Attr Attr ID------ ---- ----- ------------- メッセージを制御してください: モデム状態529 0 2部3.1。
AVP:
Modem On-Hold Capable 529 2 none Section 4.1.
Modem On-Hold Status 529 3 [..] Section 4.2.
AVP: モデム、Capable529 2がなにもにOn保持する、セクション4.1 モデム保留状態529 3、[]。 セクション4.2。
Goyret Standards Track [Page 11] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[11ページ]RFC3573Signaling
Author's Address
作者のアドレス
Ignacio Goyret Lucent Technologies 1801 Harbor Bay Parkway Alameda, CA 94502
Parkwayアラメダ、イグナシオGoyretルーセントテクノロジーズ1801港Bayカリフォルニア 94502
EMail: igoyret@lucent.com
メール: igoyret@lucent.com
Goyret Standards Track [Page 12] RFC 3573 Signaling of Modem-On-Hold status in L2TP July 2003
L2TP2003年7月の保持でのModem状態のGoyret Standards Track[12ページ]RFC3573Signaling
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Goyret Standards Track [Page 13]
Goyret標準化過程[13ページ]
一覧
スポンサーリンク
