Network Working Group K. Hamzeh
Request for Comments: 2637 Ascend Communications
Category: Informational G. Pall
Microsoft Corporation
W. Verthein
3Com
J. Taarud
Copper Mountain Networks
W. Little
ECI Telematics
G. Zorn
Microsoft Corporation
July 1999
Point-to-Point Tunneling Protocol (PPTP)
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
IESG Note
IESG注意
The PPTP protocol was developed by a vendor consortium. The documentation of PPTP is provided as information to the Internet community. The PPP WG is currently defining a Standards Track protocol (L2TP) for tunneling PPP across packet-switched networks.
PPTPプロトコルは、ベンダーのコンソーシアムによって開発されました。 PPTPのドキュメントは、インターネットコミュニティに情報として提供されます。 PPP WGは現在、パケット交換ネットワークを介してPPPをトンネリングするための標準化過程プロトコル（L2TP）を定義します。
Abstract
抽象
This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network Access Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP Network Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP Access Concentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit- switched connections. PPTP uses an enhanced GRE (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets.
この文書では、IPネットワークを介してトンネリングするためにポイントプロトコル（PPP）をポイントすることができますプロトコルを指定します。 PPTPは、PPPプロトコルへの変更を指定するのではなく、PPPを運ぶための新しい車両を説明していません。クライアント・サーバ・アーキテクチャは、現在のネットワークアクセスサーバー（NAS）に存在する機能を分離し、仮想プライベートネットワーク（VPN）をサポートするために定義されています。 PPTPネットワークサーバー（PNS）は、PPTPアクセスコンセントレータ（PAC）と呼ばれる、クライアントながら、汎用オペレーティングシステム上で実行することが想定されるダイヤルアクセスプラットフォーム上で動作します。 PPTPは、ダイヤルインサーキットへのアクセスを制御するサーバは、PSTNまたはISDNから発信コールを交換または送信回路 - を開始するための接続を切り替え可能にする呼制御および管理プロトコルを指定します。 PPTPは、PPPパケットを運ぶためのflow-および輻輳制御のカプセル化されたデータグラムサービスを提供するように拡張GRE（総称ルーティングカプセル化）メカニズムを使用します。
Specification of Requirements
要件の仕様
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [12].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" [12]に記載されるように解釈されるべきではありません。
The words "silently discard", when used in reference to the behavior of an implementation upon receipt of an incoming packet, are to be interpreted as follows: the implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.
実装は、さらなる処理なしにデータグラムを破棄し、送信者にエラーを示すことなく、次のように入ってくるパケットを受信すると、実装の振舞いに関連して使用される場合、「静かに破棄」の言葉は、解釈されるべきです。実装は、廃棄されたデータグラムの内容を含め、エラーをログに記録する機能を提供すべきである、と統計カウンターにイベントを記録する必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Protocol Goals and Assumptions . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Control Connection Overview . . . . . . . . . . . . . . 7
1.3.2. Tunnel Protocol Overview . . . . . . . . . . . . . . . . 7
1.4. Message Format and Protocol Extensibility . . . . . . . . 8
2. Control Connection Protocol Specification . . . . . . . . . 10
2.1. Start-Control-Connection-Request . . . . . . . . . . . . . 10
2.2. Start-Control-Connection-Reply . . . . . . . . . . . . . . 12
2.3. Stop-Control-Connection-Request . . . . . . . . . . . . . 15
2.4. Stop-Control-Connection-Reply . . . . . . . . . . . . . . 16
2.5. Echo-Request . . . . . . . . . . . . . . . . . . . . . . . 17
2.6. Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7. Outgoing-Call-Request . . . . . . . . . . . . . . . . . . 19
2.8. Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . 22
2.9. Incoming-Call-Request . . . . . . . . . . . . . . . . . . 25
2.10. Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 28
2.11. Incoming-Call-Connected . . . . . . . . . . . . . . . . . 29
2.12. Call-Clear-Request . . . . . . . . . . . . . . . . . . . 31
2.13. Call-Disconnect-Notify . . . . . . . . . . . . . . . . . 32
2.14. WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . 33
2.15. Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 35
2.16. General Error Codes . . . . . . . . . . . . . . . . . . . 36
3. Control Connection Protocol Operation . . . . . . . . . . . 36
3.1. Control Connection States . . . . . . . . . . . . . . . . 37
3.1.1. Control Connection Originator (may be PAC or PNS) . . . 37
3.1.2. Control connection Receiver (may be PAC or PNS) . . . . 39
3.1.3. Start Control Connection Initiation Request Collision . 40
3.1.4. Keep Alives and Timers . . . . . . . . . . . . . . . . . 40
3.2. Call States . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.1. Timing considerations . . . . . . . . . . . . . . . . . 41
3.2.2. Call ID Values . . . . . . . . . . . . . . . . . . . . . 41
3.2.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 41
3.2.3.1. PAC Incoming Call States . . . . . . . . . . . . . . . 42
3.2.3.2. PNS Incoming Call States . . . . . . . . . . . . . . . 43
3.2.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 44
3.2.4.1. PAC Outgoing Call States . . . . . . . . . . . . . . . 45
3.2.4.2. PNS Outgoing Call States . . . . . . . . . . . . . . . 46
4. Tunnel Protocol Operation . . . . . . . . . . . . . . . . . 47
4.1. Enhanced GRE header . . . . . . . . . . . . . . . . . . . 47
4.2. Sliding Window Protocol . . . . . . . . . . . . . . . . . 49
4.2.1. Initial Window Size . . . . . . . . . . . . . . . . . . 49
4.2.2. Closing the Window . . . . . . . . . . . . . . . . . . . 49
4.2.3. Opening the Window . . . . . . . . . . . . . . . . . . . 50
4.2.4. Window Overflow . . . . . . . . . . . . . . . . . . . . 50
4.2.5. Multi-packet Acknowledgment . . . . . . . . . . . . . . 50
4.3. Out-of-sequence Packets . . . . . . . . . . . . . . . . . 50
4.4. Acknowledgment Time-Outs . . . . . . . . . . . . . . . . . 51
4.4.1. Calculating Adaptive Acknowledgment Time-Out . . . . . . 53
4.4.2. Congestion Control: Adjusting for Time-Out . . . . . . . 54
5. Security Considerations . . . . . . . . . . . . . . . . . . 54
6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . 57
PPTP allows existing Network Access Server (NAS) functions to be separated using a client-server architecture. Traditionally, the following functions are implemented by a NAS:
PPTPは、既存のネットワーク・アクセス・サーバ（NAS）関数は、クライアント・サーバ・アーキテクチャを用いて分離することができます。伝統的に、以下の機能がNASによって実装されています。
1) Physical native interfacing to PSTN or ISDN and control of external modems or terminal adapters.
PSTNまたはISDN、および外部モデムやターミナルアダプタの制御とのインタフェース1）物理ネイティブ。
A NAS may interface directly to a telco analog or digital circuit or attach via an external modem or terminal adapter. Control of a circuit-switched connection is accomplished with either modem control or DSS1 ISDN call control protocols.
NASは、電話会社のアナログまたはデジタル回路に直接インターフェースまたは外部モデムやターミナルアダプタを介して取り付けることができます。回線交換接続の制御は、モデム制御またはDSS1 ISDN呼制御プロトコルのいずれかを用いて達成されます。
The NAS, in conjunction with the modem or terminal adapters, may perform rate adaption, analog to digital conversion, sync to async conversion or a number of other alterations of data streams.
NASは、モデムやターミナルアダプタと一緒に、レート適応、アナログ - デジタル変換、非同期変換やデータストリームの他の変化の数に同期を実行することができます。
2) Logical termination of a Point-to-Point-Protocol (PPP) Link Control Protocol (LCP) session.
2）ポイントツーポイント・プロトコル（PPP）リンク制御プロトコル（LCP）セッションの論理終了。
3) Participation in PPP authentication protocols [3,9,10].
PPP認証プロトコル3）参加[3,9,10]。
4) Channel aggregation and bundle management for PPP Multilink Protocol.
PPPマルチリンクプロトコルのための4）チャンネルの集約とバンドル管理。
5) Logical termination of various PPP network control protocols (NCP).
種々のPPPネットワーク制御プロトコル（NCP）の5）論理終了。
6) Multiprotocol routing and bridging between NAS interfaces.
NASインターフェイス間6）マルチプロトコル・ルーティングおよびブリッジ。
PPTP divides these functions between the PAC and PNS. The PAC is responsible for functions 1, 2, and possibly 3. The PNS may be responsible for function 3 and is responsible for functions 4, 5, and 6. The protocol used to carry PPP protocol data units (PDUs) between the PAC and PNS, as well as call control and management is addressed by PPTP.
PPTPは、PACとPNSの間でこれらの機能を分割します。 PACは機能1,2を担当して、そしておそらく3 PNSは、機能3の責任であってもよく、機能4,5を担当し、前記プロトコルはPACとの間でPPPプロトコルデータユニット（PDU）を運ぶために使用しましたPNSと同様に、呼制御管理はPPTPによって対処されます。
The decoupling of NAS functions offers these benefits:
NAS機能のデカップリングは、これらの利点があります。
Flexible IP address management. Dial-in users may maintain a single IP address as they dial into different PACs as long as they are served from a common PNS. If an enterprise network uses unregistered addresses, a PNS associated with the enterprise assigns addresses meaningful to the private network.
柔軟なIPアドレス管理。彼らがいる限り、彼らは共通PNSから提供されているように異なるのPACにダイヤルするようダイヤルインユーザーが単一のIPアドレスを維持することができます。企業ネットワークは、未登録のアドレスを使用する場合は、企業に関連したPNSは、プライベートネットワークへの意味のあるアドレスを割り当てます。
Support of non-IP protocols for dial networks behind IP networks. This allows Appletalk and IPX, for example to be tunneled through an IP-only provider. The PAC need not be capable of processing these protocols.
IPネットワークの背後にあるダイヤルネットワークのための非IPプロトコルのサポート。これは、AppleTalkやIPXはIPのみのプロバイダーを介してトンネリングするたとえば、ことができます。 PACは、これらのプロトコルを処理することが可能である必要はありません。
A solution to the "multilink hunt-group splitting" problem. Multilink PPP, typically used to aggregate ISDN B channels, requires that all of the channels composing a multilink bundle be grouped at a single NAS. Since a multilink PPP bundle can be handled by a single PNS, the channels comprising the bundle may be spread across multiple PACs.
「マルチリンクハントグループの分割」問題への解決策。典型的には、ISDNのBチャネルを集約するために使用されるマルチリンクPPPは、マルチリンクバンドルを構成するチャネルのすべてが単一のNASにグループ化されることを要求します。マルチリンクPPPバンドルが単一PNSによって処理することができるので、バンドルを含むチャネルは、複数のPACに分散されてもよいです。
The PPTP protocol is implemented only by the PAC and PNS. No other systems need to be aware of PPTP. Dial networks may be connected to a PAC without being aware of PPTP. Standard PPP client software should continue to operate on tunneled PPP links.
PPTPプロトコルのみPACとPNSによって実現されます。他のシステムでは、PPTPを認識する必要がありません。ダイヤルネットワークは、PPTPを意識することなく、PACに接続することができます。標準のPPPクライアントソフトウェアは、トンネルPPPリンク上で動作し続けなければなりません。
PPTP can also be used to tunnel a PPP session over an IP network. In this configuration the PPTP tunnel and the PPP session runs between the same two machines with the caller acting as a PNS.
PPTPは、IPネットワークを介してトンネルにPPPセッションを使用することができます。この構成でPPTPトンネルとPPPセッションは、発信者がPNSとして作用する同じ2台のマシン間で実行されます。
It is envisioned that there will be a many-to-many relationship between PACs and PNSs. A PAC may provide service to many PNSs. For example, an Internet service provider may choose to support PPTP for a number of private network clients and create VPNs for them. Each private network may operate one or more PNSs. A single PNS may associate with many PACs to concentrate traffic from a large number of geographically diverse sites.
のPACとPNSs間の多対多の関係があることが想定されます。 PACは、多くのPNSsにサービスを提供することができます。例えば、インターネット・サービス・プロバイダは、プライベートネットワーククライアントの数のためにPPTPをサポートし、彼らのためにVPNを作成することもできます。各プライベートネットワークは、1つまたは複数のPNSsを動作させることができます。単一PNSは、地理的に多様な多数のサイトからのトラフィックを集中させる多くのPACを関連付けることがあります。
PPTP uses an extended version of GRE to carry user PPP packets. These enhancements allow for low-level congestion and flow control to be provided on the tunnels used to carry user data between PAC and PNS. This mechanism allows for efficient use of the bandwidth available for the tunnels and avoids unnecessary retransmisions and buffer overruns. PPTP does not dictate the particular algorithms to be used for this low level control but it does define the parameters that must be communicated in order to allow such algorithms to work. Suggested algorithms are included in section 4.
PPTPは、ユーザPPPパケットを運ぶためにGREの拡張版を使用しています。これらの拡張機能は、低レベルの輻輳を可能にし、PACとPNSの間でユーザデータを運ぶために使用されるトンネルに設けられる制御フロー。このメカニズムは、トンネルに利用可能な帯域幅の効率的な利用を可能にし、不要なretransmisionsと、バッファオーバーランを回避することができます。 PPTPは、このローレベルの制御に使用される特定のアルゴリズムを規定しないが、それはそのようなアルゴリズムが機能することを可能にするために通信されなければならないパラメータを定義しません。提案アルゴリズムはセクション4に含まれています。
Analog Channel
アナログチャネル
A circuit-switched communication path which is intended to carry 3.1 Khz audio in each direction.
各方向に3.1 kHzオーディオを搬送することが意図されている回線交換通信路。
Digital Channel
デジタルチャンネル
A circuit-switched communication path which is intended to carry digital information in each direction.
各方向のデジタル情報を搬送することが意図されている回線交換通信路。
Call
コール
A connection or attempted connection between two terminal endpoints on a PSTN or ISDN -- for example, a telephone call between two modems.
例えば、二つのモデム間の電話コール - 接続またはPSTNまたはISDN上の2つの末端のエンドポイント間の接続試行。
Control Connection
制御接続
A control connection is created for each PAC, PNS pair and operates over TCP [4]. The control connection governs aspects of the tunnel and of sessions assigned to the tunnel.
制御接続は、各PAC、PNSペアに対して作成され、TCPで動作している[4]。制御接続は、トンネルのトンネルに割り当てられたセッションの側面を支配します。
Dial User
ユーザーダイヤル
An end-system or router attached to an on-demand PSTN or ISDN which is either the initiator or recipient of a call.
エンドシステムまたはルータは、イニシエータまたはコールの受信者のいずれかである、オンデマンドPSTNまたはISDNに取り付けられます。
Network Access Server (NAS)
ネットワークアクセスサーバー（NAS）
A device providing temporary, on-demand network access to users. This access is point-to-point using PSTN or ISDN lines.
ユーザーに一時的に、オンデマンドのネットワークアクセスを提供するデバイス。このアクセスは、ポイントツーポイントは、PSTNまたはISDN回線を使用しています。
PPTP Access Concentrator (PAC)
PPTPアクセスコンセントレータ（PAC）
A device attached to one or more PSTN or ISDN lines capable of PPP operation and of handling the PPTP protocol. The PAC need only implement TCP/IP to pass traffic to one or more PNSs. It may also tunnel non-IP protocols.
装置は、1つの以上のPSTNまたはPPP動作のとPPTPプロトコルを扱うことができるISDNラインに取り付けられました。 PACは、一つ以上のPNSsにトラフィックを渡すためにTCP / IPを実装するだけです。これは、トンネルの非IPプロトコルもよいです。
PPTP Network Server (PNS)
PPTPネットワークサーバー（PNS）
A PNS is envisioned to operate on general-purpose computing/server platforms. The PNS handles the server side of the PPTP protocol. Since PPTP relies completely on TCP/IP and is independent of the interface hardware, the PNS may use any combination of IP interface hardware including LAN and WAN devices.
PNSは、汎用コンピューティング/サーバプラットフォーム上で動作するように想定されています。 PNSはPPTPプロトコルのサーバー側を処理します。 PPTPは、TCP / IPに完全に依存し、インターフェイスハードウェアとは独立しているため、PNSは、LANおよびWANデバイスを含むIPインタフェースハードウェアの任意の組み合わせを使用することができます。
Session
セッション
PPTP is connection-oriented. The PNS and PAC maintain state for each user that is attached to a PAC. A session is created when end-to-end PPP connection is attempted between a dial user and the PNS. The datagrams related to a session are sent over the tunnel between the PAC and PNS.
PPTPはコネクション指向です。 PNSとPACは、PACに取り付けられている各ユーザの状態を維持します。エンドツーエンドのPPP接続はダイヤルユーザとPNSの間で試行されると、セッションが作成されます。セッションに関連するデータグラムは、PACとPNSの間のトンネルを介して送信されます。
Tunnel
トンネル
A tunnel is defined by a PNS-PAC pair. The tunnel protocol is defined by a modified version of GRE [1,2]. The tunnel carries PPP datagrams between the PAC and the PNS. Many sessions are multiplexed on a single tunnel. A control connection operating over TCP controls the establishment, release, and maintenance of sessions and of the tunnel itself.
トンネルは、PNS-PACのペアによって定義されます。トンネルプロトコルは、GRE [1,2]の修正バージョンによって定義されます。トンネルは、PACとPNSの間でPPPデータグラムを運びます。多くのセッションは、単一のトンネルに多重化されています。 TCP上で動作する制御接続が確立、解放、およびセッションとトンネル自体のメンテナンスを制御します。
There are two parallel components of PPTP: 1) a Control Connection between each PAC-PNS pair operating over TCP and 2) an IP tunnel operating between the same PAC-PNS pair which is used to transport GRE encapsulated PPP packets for user sessions between the pair.
1）各PAC-PNSペア間の制御接続がTCP上で動作し、2）GREを輸送するために使用されるのと同じPAC-PNSペア間で動作するIPトンネルが間のユーザセッションのPPPパケットをカプセル化：PPTPの二つの平行な成分がありますペア。
Before PPP tunneling can occur between a PAC and PNS, a control connection must be established between them. The control connection is a standard TCP session over which PPTP call control and management information is passed. The control session is logically associated with, but separate from, the sessions being tunneled through a PPTP tunnel. For each PAC-PNS pair both a tunnel and a control connection exist. The control connection is responsible for establishment, management, and release of sessions carried through the tunnel. It is the means by which a PNS is notified of an incoming call at an associated PAC, as well as the means by which a PAC is instructed to place an outgoing dial call.
PPPトンネリングがPACとPNSの間で発生する可能性があります前に、制御接続は、それらの間に確立されなければなりません。制御接続は、PPTPの呼制御管理情報が渡され、その上標準のTCPセッションです。セッションは、PPTPトンネルを介してトンネリングされる、からの制御セッションは、論理的に関連付けられているが、分離されています。各PAC-PNSペアのトンネルおよび制御接続の両方が存在します。制御接続は、トンネルを通って運ばセッションの確立、管理、および解放を担っています。これは、PNSは、関連するPACでの着信と同様に、PACは、発信ダイヤル電話をかけるように指示される手段が通知される手段です。
A control connection can be established by either the PNS or the PAC. Following the establishment of the required TCP connection, the PNS and PAC establish the control connection using the Start-Control-Connection-Request and -Reply messages. These messages are also used to exchange information about basic operating capabilities of the PAC and PNS. Once the control connection is established, the PAC or PNS may initiate sessions by requesting outbound calls or responding to inbound requests. The control connection may communicate changes in operating characteristics of an individual user session with a Set-Link-Info message. Individual sessions may be released by either the PAC or PNS, also through Control Connection messages.
制御接続は、PNS又はPACのいずれかによって確立することができます。必要なTCPコネクションの確立に続いて、PNSとPACは、スタートコントロール接続要求と-replyメッセージを使用して制御接続を確立します。これらのメッセージは、PACとPNSの基本的な操作機能に関する情報を交換するために使用されています。制御接続が確立されると、PACかPNSは、アウトバウンドコールを要求するか、インバウンド要求に応答することによってセッションを開始することができます。制御接続は、Set-リンク情報メッセージを個々のユーザ・セッションの動作特性の変化を通信することができます。個々のセッションはまた、制御接続メッセージを介して、PACかPNSのいずれかによって放出されてもよいです。
The control connection itself is maintained by keep-alive echo messages. This ensures that a connectivity failure between the PNS and the PAC can be detected in a timely manner. Other failures can be reported via the
コントロール接続自体は、キープアライブエコーメッセージによって維持されています。これは、PNSとPACとの間の接続障害を適時に検出することができることを確実にします。その他の障害を経由して報告することができます
Wan-Error-Notify message, also on the control connection.
また、制御接続上のメッセージを、ワン誤り通知。
It is intended that the control connection will also carry management related messages in the future, such as a message allowing the PNS to request the status of a given PAC; these message types have not yet been defined.
制御接続はまた、PNSは、与えられたPACの状態を要求することを可能にするメッセージとして、将来的に管理に関連するメッセージを伝送することが意図されています。これらのメッセージタイプはまだ定義されていません。
PPTP requires the establishment of a tunnel for each communicating PNS-PAC pair. This tunnel is used to carry all user session PPP packets for sessions involving a given PNS-PAC pair. A key which is present in the GRE header indicates which session a particular PPP packet belongs to.
PPTPは、各通信PNS-PACのペアのためのトンネルの確立を必要とします。このトンネルは、所定のPNS-PACのペアを含むセッションのすべてのユーザセッションPPPパケットを運ぶために使用されます。 GREヘッダーに存在しているキーは、特定のPPPパケットが属するセッションを示しています。
In this manner, PPP packets are multiplexed and demultiplexed over a single tunnel between a given PNS-PAC pair. The value to use in the key field is established by the call establishment procedure which takes place on the control connection.
このように、PPPパケットを多重化し、所与のPNS-PACのペア間の単一のトンネルを介して分離されます。キーフィールドに使用する値は、制御接続上で行われ、コール確立手順によって確立されます。
The GRE header also contains acknowledgment and sequencing information that is used to perform some level of congestion-control and error detection over the tunnel. Again the control connection is used to determine rate and buffering parameters that are used to regulate the flow of PPP packets for a particular session over the tunnel. PPTP does not specify the particular algorithms to use for congestion-control and flow-control. Suggested algorithms for the determination of adaptive time-outs to recover from dropped data or acknowledgments on the tunnel are included in section 4.4 of this document.
GREヘッダは、トンネル上の輻輳制御及びエラー検出のいくつかのレベルを実行するために使用される確認応答およびシーケンス情報を含んでいます。再び制御接続は、トンネルを介して特定のセッションのためのPPPパケットの流れを調節するために使用されるレートとバッファリングパラメータを決定するために使用されます。 PPTPは、輻輳制御およびフロー制御のために使用する特定のアルゴリズムを指定していません。トンネル上でドロップされたデータ又は確認応答から回復する適応タイムアウトの決意の推奨アルゴリズムは、本書のセクション4.4に含まれています。
PPTP defines a set of messages sent as TCP data on the control connection between a PNS and a given PAC. The TCP session for the control connection is established by initiating a TCP connection to port 1723 [6]. The source port is assigned to any unused port number.
PPTPは、PNSと、所与のPACとの間の制御接続上のTCPデータとして送信されるメッセージのセットを定義します。制御接続のためのTCPセッションは、ポート1723へのTCP接続を開始することによって確立されている[6]。ソースポートは、未使用のポート番号に割り当てられています。
Each PPTP Control Connection message begins with an 8 octet fixed header portion. This fixed header contains the following: the total length of the message, the PPTP Message Type indicator, and a "Magic Cookie".
各PPTP制御接続メッセージは、8オクテットの固定ヘッダ部分から始まります。この固定ヘッダは以下を含んでいます：メッセージ、PPTPメッセージタイプインジケータの全長、及び「マジッククッキー」。
Two Control Connection message types are indicated by the PPTP Message Type field:
二つの制御接続のメッセージタイプは、PPTPメッセージタイプフィールドで示されています。
1 - Control Message
2 - Management Message
Management messages are currently not defined.
管理メッセージは、現在定義されていません。
The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its basic purpose is to allow the receiver to ensure that it is properly synchronized with the TCP data stream. It should not be used as a means for resynchronizing the TCP data stream in the event that a transmitter issues an improperly formatted message. Loss of synchronization must result in immediate closing of the control connection's TCP session.
マジッククッキーは常に一定0x1A2B3C4Dとして送信されます。その基本的な目的は、受信機は、それが適切にTCPデータストリームと同期していることを確認できるようにすることです。これは、送信機が不適切にフォーマットされたメッセージを出した場合に、TCPデータストリームを再同期するための手段として使用すべきではありません。同期の損失は、制御接続のTCPセッションの即時終了につながる必要があります。
For clarity, all Control Connection message templates in the next section include the entire PPTP Control Connection message header. Numbers preceded by 0x are hexadecimal values.
明確にするために、次のセクションのすべてのコントロール接続メッセージテンプレートは、全体PPTP制御接続メッセージヘッダーを含みます。 0xで始まる数字は、16進値です。
The currently defined Control Messages, grouped by function, are:
機能ごとにグループ化され、現在定義された制御メッセージは、以下のとおりです。
Control Message Message Code
制御メッセージのメッセージコード
(Control Connection Management)
（コントロール接続管理）
Start-Control-Connection-Request 1 Start-Control-Connection-Reply 2 Stop-Control-Connection-Request 3 Stop-Control-Connection-Reply 4 Echo-Request 5 Echo-Reply 6
コントロール接続要求の開始1スタートコントロール接続返信2停止制御、接続要求3を停止コントロール接続返信4エコー要求5エコー応答6
(Call Management)
（通話管理）
Outgoing-Call-Request 7 Outgoing-Call-Reply 8 Incoming-Call-Request 9 Incoming-Call-Reply 10 Incoming-Call-Connected 11 Call-Clear-Request 12 Call-Disconnect-Notify 13
発信コールリクエスト7出射コール返信8着信リクエスト9着信リプライ10着信接続11コールクリア要求12コール切断、通知13
(Error Reporting)
（エラーレポート）
WAN-Error-Notify 14
14 WAN誤り通知
(PPP Session Control)
（PPPセッション制御）
Set-Link-Info 15
セットリンク情報15
The Start-Control-Connection-Request and -Reply messages determine which version of the Control Connection protocol will be used. The version number field carried in these messages consists of a version number in the high octet and a revision number in the low octet. Version handling is described in section 2. The current value of the version number field is 0x0100 for version 1, revision 0.
スタートコントロール接続要求と-replyメッセージが使用される制御接続プロトコルのバージョンを確認。これらのメッセージで運ばれたバージョン番号フィールドは、高いオクテットのバージョン番号と低オクテットのリビジョン番号から構成されています。バージョン処理はバージョン番号フィールドの現在の値は、バージョン1、リビジョン0は0x0100であり、セクション2に記載されています。
The use of the GRE-like header for the encapsulation of PPP user packets is specified in section 4.1.
PPPユーザパケットのカプセル化のためのGREのようなヘッダの使用はセクション4.1で指定されています。
The MTU for the user data packets encapsulated in GRE is 1532 octets, not including the IP and GRE headers.
GREでカプセル化されたユーザ・データ・パケットのMTUはIPとGREヘッダーを含まない1532オクテットです。
Control Connection messages are used to establish and clear user sessions. The first set of Control Connection messages are used to maintain the control connection itself. The control connection is initiated by either the PNS or PAC after they establish the underlying TCP connection. The procedure and configuration information required to determine which TCP connections are established is not covered by this protocol.
制御接続メッセージは、ユーザーセッションを確立し、明確にするために使用されています。制御接続メッセージの最初のセットは、コントロール接続自体を維持するために使用されています。彼らは基本的なTCP接続を確立した後、制御接続はPNSかPACのいずれかによって開始されます。 TCP接続が確立されているかを決定するために必要な手順および構成情報は、このプロトコルによって覆われていません。
The following Control Connection messages are all sent as user data on the established TCP connection between a given PNS-PAC pair. Note that care has been taken to ensure that all word (2 octet) and longword (4 octet) values begin on appropriate boundaries. All data is sent in network order (high order octets first). Any "reserved" fields MUST be sent as 0 values to allow for protocol extensibility.
次制御接続のメッセージはすべて与えられたPNS-PACのペアの間に確立されたTCP接続上のユーザデータとして送信されます。そのケアは、すべての単語（2オクテット）とロングワード（4オクテット）の値が適切な境界で始まることを保証するためにとられている注意してください。すべてのデータは、（最初の上位オクテット）ネットワーク順に送信されます。任意の「予約」フィールドは、プロトコルの拡張を可能にするために0値として送信されなければなりません。
The Start-Control-Connection-Request is a PPTP control message used to establish the control connection between a PNS and a PAC. Each PNS-PAC pair requires a dedicated control connection to be established. A control connection must be established before any other PPTP messages can be issued. The establishment of the control connection can be initiated by either the PNS or PAC. A procedure which handles the occurrence of a collision between PNS and PAC Start-Control-Connection-Requests is described in section 3.1.3.
スタートコントロール接続要求は、PNSとPACとの間の制御接続を確立するために使用PPTP制御メッセージです。各PNS-PACのペアが確立される専用の制御接続が必要です。他のPPTPメッセージが発行される前に、制御接続が確立されなければなりません。制御コネクションの確立は、PNSかPACのいずれかによって開始することができます。 PNSとPACスタートコントロール接続要求間の衝突の発生を処理する手順は、セクション3.1.3に記載されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Channels | Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Name (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Vendor String (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D. This constant value is used as a sanity check on received messages (see section 1.4).
マジッククッキー0x1A2B3C4D。この定数値は、受信されたメッセージの健全性チェックとして使用される（セクション1.4参照）。
Control Message Type 1 for Start-Control-Connection-Request.
スタートコントロール接続要求のための制御メッセージ・タイプ1。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Protocol Version The version of the PPTP protocol that the sender wishes to use.
プロトコルバージョン送信者が使用したいPPTPプロトコルのバージョン。
Reserved1 This field MUST be 0.
Reserved1このフィールドは0でなければなりません。
Framing Capabilities A set of bits indicating the type of framing that the sender of this message can provide. The currently defined bit settings are:
機能にこのメッセージの送信者が提供できることをフレーミングのタイプを示すビットのセットをフレーミング。現在定義されているビットの設定は次のとおりです。
1 - Asynchronous Framing supported
1 - 非同期フレーミングをサポート
2 - Synchronous Framing supported
2 - 同期フレーミングをサポート
Bearer Capabilities A set of bits indicating the bearer capabilities that the sender of this message can provide. The currently defined bit settings are:
ベアラ能力このメッセージの送信者が提供できるベアラ能力を示すビットのセット。現在定義されているビットの設定は次のとおりです。
1 - Analog access supported
1 - アナログアクセスがサポート
2 - Digital access supported
2 - デジタルアクセスサポート
Maximum Channels The total number of individual PPP sessions this PAC can support. In Start-Control-Connection-Requests issued by the PNS, this value SHOULD be set to 0. It MUST be ignored by the PAC.
最大チャンネルこのPACをサポートすることができ、個々のPPPセッションの合計数。 PNSによって発行されたスタートコントロール接続要求では、この値は、それはPACによって無視されなければならない0に設定する必要があります。
Firmware Revision This field contains the firmware revision number of the issuing PAC, when issued by the PAC, or the version of the PNS PPTP driver if issued by the PNS.
PNSによって発行された場合は、ファームウェアのリビジョンこのフィールドは、PACによって発行された発行PACのファームウェアのリビジョン番号、またはPNS PPTPドライバのバージョンが含まれています。
Host Name A 64 octet field containing the DNS name of the issuing PAC or PNS. If less than 64 octets in length, the remainder of this field SHOULD be filled with octets of value 0.
発行PACかPNSのDNS名を含む名前A 64オクテットフィールドをホストします。長さが64オクテット未満の場合、このフィールドの残りの部分は、値0のオクテットで充填されるべきです。
Vendor Name A 64 octet field containing a vendor specific string describing the type of PAC being used, or the type of PNS software being used if this request is issued by the PNS. If less than 64 octets in length, the remainder of this field SHOULD be filled with octets of value 0.
PACのタイプを記述するベンダー固有の文字列を含むベンダ名A 64オクテットフィールドが使用されている、またはこの要求はPNSによって発行された場合PNSソフトウェアの種類が使用されています。長さが64オクテット未満の場合、このフィールドの残りの部分は、値0のオクテットで充填されるべきです。
The Start-Control-Connection-Reply is a PPTP control message sent in reply to a received Start-Control-Connection-Request message. This message contains a result code indicating the result of the control connection establishment attempt.
スタートコントロール接続返信受信スタートコントロール接続要求メッセージに対する応答で送信されたPPTP制御メッセージです。このメッセージは、制御接続確立の試みの結果を示す結果コードを含みます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Channels | Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Name (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Vendor String (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 2 for Start-Control-Connection-Reply.
スタートコントロール接続返信用制御メッセージタイプ2。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Protocol Version The version of the PPTP protocol that the sender wishes to use.
プロトコルバージョン送信者が使用したいPPTPプロトコルのバージョン。
Result Code Indicates the result of the command channel establishment attempt. Current valid Result Code values are:
結果コードは、コマンドチャネル確立の試みの結果を示します。現在の有効なResult Code値は以下のとおりです。
1 - Successful channel establishment
1 - 成功したチャネル確立
2 - General error -- Error Code indicates the problem
2 - 一般的なエラー - エラーコードは、問題があることを示して
3 - Command channel already exists;
3 - コマンドチャネルがすでに存在しています。
4 - Requester is not authorized to establish a command channel
4 - リクエスタは、コマンドチャネルを確立することを許可されていません
5 - The protocol version of the requester is not supported
5 - リクエスタのプロトコルバージョンはサポートされていません
Error Code This field is set to 0 unless a "General Error" exists, in which case Result Code is set to 2 and this field is set to the value corresponding to the general error condition as specified in section 2.2.
「一般的なエラーは、」結果コードが2に設定され、セクション2.2で指定されるように、このフィールドは、一般的なエラー状態に対応する値に設定されている場合には、存在しない限り、エラーコードは、このフィールドは0に設定されています。
Framing Capabilities A set of bits indicating the type of framing that the sender of this message can provide. The currently defined bit settings are:
機能にこのメッセージの送信者が提供できることをフレーミングのタイプを示すビットのセットをフレーミング。現在定義されているビットの設定は次のとおりです。
1 - Asynchronous Framing supported
1 - 非同期フレーミングをサポート
2 - Synchronous Framing supported.
2 - 同期フレーミングをサポート。
Bearer Capabilities A set of bits indicating the bearer capabilities that the sender of this message can provide. The currently defined bit settings are:
ベアラ能力このメッセージの送信者が提供できるベアラ能力を示すビットのセット。現在定義されているビットの設定は次のとおりです。
1 - Analog access supported
1 - アナログアクセスがサポート
2 - Digital access supported
2 - デジタルアクセスサポート
Maximum Channels The total number of individual PPP sessions this PAC can support. In a Start-Control-Connection-Reply issued by the PNS, this value SHOULD be set to 0 and it must be ignored by the PAC. The PNS MUST NOT use this value to try to track the remaining number of PPP sessions that the PAC will allow.
最大チャンネルこのPACをサポートすることができ、個々のPPPセッションの合計数。 PNSによって発行されたスタートコントロール接続返信では、この値は0に設定されるべきであり、それはPACによって無視されなければなりません。 PNSは、PACが許容するPPPセッションの残りの数を追跡しようとするために、この値を使用してはなりません。
Firmware Revision This field contains the firmware revision number of the issuing PAC, or the version of the PNS PPTP driver if issued by the PNS.
PNSによって発行された場合は、ファームウェアのリビジョンこのフィールドは、発行PACのファームウェアのリビジョン番号、またはPNS PPTPドライバのバージョンが含まれています。
Host Name A 64 octet field containing the DNS name of the issuing PAC or PNS. If less than 64 octets in length, the remainder of this field SHOULD be filled with octets of value 0.
発行PACかPNSのDNS名を含む名前A 64オクテットフィールドをホストします。長さが64オクテット未満の場合、このフィールドの残りの部分は、値0のオクテットで充填されるべきです。
Vendor Name A 64 octet field containing a vendor specific string describing the type of PAC being used, or the type of PNS software being used if this request is issued by the PNS. If less than 64 octets in length, the remainder of this field SHOULD be filled with octets of value 0.
PACのタイプを記述するベンダー固有の文字列を含むベンダ名A 64オクテットフィールドが使用されている、またはこの要求はPNSによって発行された場合PNSソフトウェアの種類が使用されています。長さが64オクテット未満の場合、このフィールドの残りの部分は、値0のオクテットで充填されるべきです。
The Stop-Control-Connection-Request is a PPTP control message sent by one peer of a PAC-PNS control connection to inform the other peer that the control connection should be closed. In addition to closing the control connection, all active user calls are implicitly cleared. The reason for issuing this request is indicated in the Reason field.
停止制御、接続要求は、制御接続を閉じなければならない他のピアに通知するPAC-PNSコントロール接続のピアによって送信されたPPTP制御メッセージです。コントロール接続をクローズすることに加えて、すべてのアクティブなユーザー・コールは、暗黙的にクリアされます。この要求を発行する理由は、理由フィールドに示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 3 for Stop-Control-Connection-Request.
停止コントロール接続要求のための制御メッセージタイプ3。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Reason Indicates the reason for the control connection being closed. Current valid Reason values are:
その理由は、制御接続の理由が閉鎖されていることを示します。現在有効な理由値は次のとおりです。
1 (None) - General request to clear
control connection
2 (Stop-Protocol) - Can't support peer's version of the protocol
2（ストッププロトコル） - プロトコルのピアのバージョンをサポートすることはできません
3 (Stop-Local-Shutdown) - Requester is being shut down
3（ストップローカル・シャットダウン） - リクエスタがシャットダウンされます
Reserved1, Reserved2 These fields MUST be 0.
Reserved1、Reserved2は、これらのフィールドは0でなければなりません。
The Stop-Control-Connection-Reply is a PPTP control message sent by one peer of a PAC-PNS control connection upon receipt of a Stop-Control-Connection-Request from the other peer.
停止コントロール接続応答は、他のピアからの停止制御、接続要求を受信するとPAC-PNSコントロール接続のピアによって送信されたPPTP制御メッセージです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 4 for Stop-Control-Connection-Reply.
停止コントロール接続返信用制御メッセージタイプ4。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Result Code Indicates the result of the attempt to close the control connection. Current valid Result Code values are:
結果コードは、制御接続をクローズしようとする試みの結果を示します。現在の有効なResult Code値は以下のとおりです。
1 (OK) - Control connection closed
1（OK） - 制御接続を閉じ
2 (General Error) - Control connection not closed for reason indicated in Error Code
2（一般エラー） - エラーコードで示された理由で閉じられていないコントロールの接続
Error Code This field is set to 0 unless a "General Error" exists, in which case Result Code is set to 2 and this field is set to the value corresponding to the general error condition as specified in section 2.2.
「一般的なエラーは、」結果コードが2に設定され、セクション2.2で指定されるように、このフィールドは、一般的なエラー状態に対応する値に設定されている場合には、存在しない限り、エラーコードは、このフィールドは0に設定されています。
Reserved1 This field MUST be 0.
Reserved1このフィールドは0でなければなりません。
The Echo-Request is a PPTP control message sent by either peer of a PAC-PNS control connection. This control message is used as a "keep-alive" for the control connection. The receiving peer issues an Echo-Reply to each Echo-Request received. As specified in section 3.1.4, if the sender does not receive an Echo-Reply in response to an Echo-Request, it will eventually clear the control connection.
エコー要求は、PAC-PNSコントロール接続のどちらかのピアによって送信されたPPTP制御メッセージです。この制御メッセージは、制御接続のための「キープアライブ」として使用されています。受信ピアは、受信した各エコー要求にエコー応答を発行します。送信者がエコー要求に応答したエコー応答を受信しない場合は、セクション3.1.4で指定されているように、それは最終的に制御接続をクリアします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 5 for Echo-Request.
エコー要求のための制御メッセージの種類5。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Identifier A value set by the sender of the Echo-Request that is used to match the reply with the corresponding request.
対応する要求と応答を一致させるために使用されるエコー要求の送信者によって設定された値を識別子。
The Echo-Reply is a PPTP control message sent by either peer of a PAC-PNS control connection in response to the receipt of an Echo-Request.
エコー応答は、エコー要求の受信に応答してPAC-PNSコントロール接続のどちらかのピアによって送信されたPPTP制御メッセージです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 6 for Echo-Reply.
エコー応答の制御メッセージタイプ6。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Identifier The contents of the identify field from the received Echo-Request is copied to this field.
受信されたエコー要求から識別フィールドの内容は、このフィールドにコピーされた識別子。
Result Code Indicates the result of the receipt of the Echo-Request. Current valid Result Code values are:
結果コードは、エコー要求の受信の結果を示します。現在の有効なResult Code値は以下のとおりです。
1 (OK) - The Echo-Reply is valid
1（ON） - エコー応答が有効です
2 (General Error) - Echo-Request not accepted for the reason indicated in Error Code
2（一般エラー） - エコー要求はエラーコードで示された理由で受け入れられません
Error Code This field is set to 0 unless a "General Error" condition exists, in which case Result Code is set to 2 and this field is set to the value corresponding to the general error condition as specified in section 2.2.
「一般的なエラー」状態は、その場合には、結果コードが2に設定され、存在しない限りエラーコードこのフィールドは0に設定され、セクション2.2で指定されるように、このフィールドは、一般的なエラー状態に対応する値に設定されています。
Reserved1 This field MUST be 0.
Reserved1このフィールドは0でなければなりません。
The Outgoing-Call-Request is a PPTP control message sent by the PNS to the PAC to indicate that an outbound call from the PAC is to be established. This request provides the PAC with information required to make the call. It also provides information to the PAC that is used to regulate the transmission of data to the PNS for this session once it is established.
発信コールリクエストは、PACからの発信コールが確立されるべきであることを示すために、PACにPNSによって送られたPPTPコントロールメッセージです。この要求は、呼び出しを行うために必要な情報とPACを提供します。それはまた、それが確立されると、このセッションのためのPNSへのデータの送信を調節するために使用されたPACに情報を提供します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Processing Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Phone Number Length | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Phone Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subaddress (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 7 for Outgoing-Call-Request.
発信コールリクエストのための制御メッセージタイプ7。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Call ID A unique identifier, unique to a particular PAC-PNS pair assigned by the PNS to this session. It is used to multiplex and demultiplex data sent over the tunnel between the PNS and PAC involved in this session.
このセッションにPNSによって割り当てられた特定のPAC-PNS対に一意のID A一意の識別子を呼び出します。なお、このセッションに関係PNSとPACとの間のトンネルを介して送信されたデータを多重化及び逆多重化するために使用されます。
Call Serial Number An identifier assigned by the PNS to this session for the purpose of identifying this particular session in logged session information. Unlike the Call ID, both the PNS and PAC associate the same Call Serial Number with a given session. The combination of IP address and call serial number SHOULD be unique.
ログインセッション情報は、この特定のセッションを識別するために、このセッションにPNSによって割り当てられた識別子とシリアル番号を呼び出します。コールIDとは異なり、PNSとPACの両方が与えられたセッションと同じCallシリアル番号を関連付けます。 IPアドレスの組み合わせとシリアル番号を呼び出すには、一意である必要があります。
Minimum BPS The lowest acceptable line speed (in bits/second) for this session.
このセッションの最小BPS（第2のビット/インチ）最小許容される回線速度。
Maximum BPS The highest acceptable line speed (in bits/second) for this session.
このセッションの最大BPS（ビット/秒で）最高許容される回線速度。
Bearer Type A value indicating the bearer capability required for this outgoing call. The currently defined values are:
ベアラこの発呼に必要なベアラ能力を示す値を入力します。現在定義されている値は次のとおりです。
1 - Call to be placed on an analog
channel
2 - Call to be placed on a digital channel
2 - デジタルチャンネル上に配置するために電話
3 - Call can be placed on any type of channel
3 - コールは、チャネルの任意の型に配置することができます
Framing Type A value indicating the type of PPP framing to be used for this outgoing call.
フレーミングは、この発呼のために使用されるフレーミングPPPの種類を示す値を入力します。
1 - Call to use Asynchronous framing
1 - 非同期フレーミングを使用することを呼び出します
2 - Call to use Synchronous framing
2 - 同期フレーミングを使用することを呼び出します
3 - Call can use either type of framing
3 - コールは、フレーミングのどちらかのタイプを使用することができます
Packet Recv. Window Size The number of received data packets the PNS will buffer for this session.
パケットのRecv。ウィンドウサイズPNSがこのセッションのためにバッファリングする受信したデータパケットの数。
Packet Processing Delay A measure of the packet processing delay that might be imposed on data sent to the PNS from the PAC. This value is specified in units of 1/10 seconds. For the PNS this number should be very small. See section 4.4 for a description of how this value is determined and used.
パケット処理遅延PACからPNSに送られたデータに課されるかもしれないパケット処理遅延の尺度。この値は1/10秒単位で指定します。 PNSのために、この数が非常に小さくする必要があります。この値が決定され、使用方法の説明についてはセクション4.4を参照。
Phone Number Length The actual number of valid digits in the Phone Number field.
電話番号の長さの電話番号フィールドに有効桁数の実際の数。
Reserved1 This field MUST be 0.
Reserved1このフィールドは0でなければなりません。
Phone Number The number to be dialed to establish the outgoing session. For ISDN and analog calls this field is an ASCII string. If the Phone Number is less than 64 octets in length, the remainder of this field is filled with octets of value 0.
電話番号の発信セッションを確立するためにダイヤルする番号。 ISDNやアナログコールの場合、このフィールドには、ASCII文字列です。電話番号は、長さが64オクテット未満である場合、このフィールドの残りは値0のオクテットが充填されています。
Subaddress A 64 octet field used to specify additional dialing information. If the subaddress is less than 64 octets long, the remainder of this field is filled with octets of value 0.
追加のダイヤル情報を指定するために使用するサブアドレス64オクテットフィールド。サブアドレスが64オクテット未満の長さである場合、このフィールドの残りは値0のオクテットが充填されています。
The Outgoing-Call-Reply is a PPTP control message sent by the PAC to the PNS in response to a received Outgoing-Call-Request message. The reply indicates the result of the outgoing call attempt. It also provides information to the PNS about particular parameters used for the call. It provides information to allow the PNS to regulate the transmission of data to the PAC for this session.
発信コール-返信受信出射コール要求メッセージに応答して、PNSへPACによって送信されたPPTP制御メッセージです。回答は発信しようとした結果を示しています。また、通話のために使用される特定のパラメータについてのPNSに情報を提供します。それはPNSがこのセッションのためPACへのデータの送信を規制することを可能にする情報を提供します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Peer's Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Cause Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Processing Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 8 for Outgoing-Call-Reply.
発信コール・返信用制御メッセージタイプ8。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Call ID A unique identifier for the tunnel, assigned by the PAC to this session. It is used to multiplex and demultiplex data sent over the tunnel between the PNS and PAC involved in this session.
このセッションにPACによって割り当てられたトンネルのID A一意の識別子を呼び出します。なお、このセッションに関係PNSとPACとの間のトンネルを介して送信されたデータを多重化及び逆多重化するために使用されます。
Peer's Call ID This field is set to the value received in the Call ID field of the corresponding Outgoing-Call-Request message. It is used by the PNS to match the Outgoing-Call-Reply with the Outgoing-Call-Request it issued. It also is used as the value sent in the GRE header for mux/demuxing.
ピアの呼び出しIDこのフィールドは、対応するOutgoing-Call-RequestメッセージのコールIDフィールドに受信した値に設定されています。それが発行した発信コールリクエストでの発信・コール返信を一致させるためにPNSによって使用されます。また、MUX /するDemuxためのGREヘッダーに送信された値として使用されます。
Result Code This value indicates the result of the Outgoing-Call-Request attempt. Currently valid values are:
結果コードは、この値は、発信コールリクエスト試行の結果を示しています。現在、有効な値は次のとおりです。
1 (Connected) - Call established with
no errors
2 (General Error) - Outgoing Call not established for the reason indicated in Error Code
2（一般エラー） - 発信コールのエラーコードで示された理由のために確立されていません
3 (No Carrier) - Outgoing Call failed due to no carrier detected
3（ノーキャリア） - 発信コールが原因ノーキャリア検出に失敗しました
4 (Busy) - Outgoing Call failed due to detection of a busy signal
4（ビジー） - 発信コールがビジー信号の検出に失敗しました
5 (No Dial Tone) - Outgoing Call failed due to lack of a dial tone
5（ノーダイヤルトーン） - 発信コールが原因ダイヤルトーンの欠如のために失敗しました
6 (Time-out) - Outgoing Call was not established within time allotted by PAC
6（タイムアウト） - 発信コールはPACによって割り当てられた時間内に確立されませんでした
7 (Do Not Accept) - Outgoing Call administratively prohibited
7（受諾しない） - 発信コールは、管理上禁止します
Error Code This field is set to 0 unless a "General Error" condition exists, in which case Result Code is set to 2 and this field is set to the value corresponding to the general error condition as specified in section 2.2.
「一般的なエラー」状態は、その場合には、結果コードが2に設定され、存在しない限りエラーコードこのフィールドは0に設定され、セクション2.2で指定されるように、このフィールドは、一般的なエラー状態に対応する値に設定されています。
Cause Code This field gives additional failure information. Its value can vary depending upon the type of call attempted. For ISDN call attempts it is the Q.931 cause code.
コード原因このフィールドには、追加の障害情報を提供します。その値は、未遂の呼び出しの種類に応じて変えることができます。 ISDNコールの試みのために、それはQ.931原因コードです。
Connect Speed The actual connection speed used, in bits/second.
速度をビット/秒で、使用される実際の接続速度を接続します。
Packet Recv. Window Size The number of received data packets the PAC will buffer for this session.
パケットのRecv。ウィンドウサイズは、受信したデータパケットの数PACがこのセッションのためにバッファリングされます。
Packet Processing Delay A measure of the packet processing delay that might be imposed on data sent to the PAC from the PNS. This value is specified in units of 1/10 seconds. For the PAC, this number is related to the size of the buffer used to hold packets to be sent to the client and to the speed of the link to the client. This value should be set to the maximum delay that can normally occur between the time a packet arrives at the PAC and is delivered to the client. See section 4.4 for an example of how this value is determined and used.
パケット処理遅延PNSからPACに送信されたデータに課されるかもしれないパケット処理遅延の尺度。この値は1/10秒単位で指定します。 PACのために、この数は、クライアントおよびクライアントのリンクの速度に送信されるパケットを保持するために使用されるバッファのサイズに関連しています。この値は、通常、パケットがPACに到着し、クライアントに配信されるまでの間に発生する可能性が最大遅延に設定する必要があります。この値が決定され、使用されている方法の例についてはセクション4.4を参照。
Physical Channel ID This field is set by the PAC in a vendor-specific manner to the physical channel number used to place this call. It is used for logging purposes only.
物理チャネルIDは、このフィールドは、この呼び出しを配置するために使用される物理チャンネル番号にベンダー固有の方法でPACによって設定されています。それは、ロギング目的のみに使用されます。
The Incoming-Call-Request is a PPTP control message sent by the PAC to the PNS to indicate that an inbound call is to be established from the PAC. This request provides the PNS with parameter information for the incoming call.
着信リクエストは、インバウンドコールはPACから確立されることを示すために、PNSにPACによって送られたPPTPコントロールメッセージです。この要求は、着信呼のためのパラメータ情報をPNSを提供します。
This message is the first in the "three-way handshake" used by PPTP for establishing incoming calls. The PAC may defer answering the call until it has received an Incoming-Call-Reply from the PNS indicating that the call should be established. This mechanism allows the PNS to obtain sufficient information about the call before it is answered to determine whether the call should be answered or not.
このメッセージは、着信コールを確立するためにPPTPで使用される「3ウェイハンドシェイク」で初めてです。 PACは、呼が確立されるべきであることを示すPNSから着信・応答を受信するまで、コールに応答延期することができます。このメカニズムは、コールに応答するかどうかを判断するために応答される前に、PNSが呼び出しについての十分な情報を得ることができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Bearer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dialed Number Length | Dialing Number Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialed Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialing Number (64 octets) +
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subaddress (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 9 for Incoming-Call-Request.
着信リクエストのための制御メッセージタイプ9。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Call ID A unique identifier for this tunnel, assigned by the PAC to this session. It is used to multiplex and demultiplex data sent over the tunnel between the PNS and PAC involved in this session.
このセッションにPACによって割り当てられ、このトンネルのID A一意の識別子を呼び出します。なお、このセッションに関係PNSとPACとの間のトンネルを介して送信されたデータを多重化及び逆多重化するために使用されます。
Call Serial Number An identifier assigned by the PAC to this session for the purpose of identifying this particular session in logged session information. Unlike the Call ID, both the PNS and PAC associate the same Call Serial Number to a given session. The combination of IP address and call serial number should be unique.
ログインセッション情報は、この特定のセッションを識別するために、このセッションにPACによって割り当てられた識別子とシリアル番号を呼び出します。コールIDとは異なり、PNSとPACの両方が与えられたセッションに同じCallシリアル番号を関連付けます。 IPアドレスの組み合わせとシリアル番号を呼び出すには、一意である必要があります。
Bearer Type A value indicating the bearer capability used for this incoming call. Currently defined values are:
ベアラこの着信呼のために使用さベアラ能力を示す値を入力します。現在、定義された値は次のとおりです。
1 - Call is on an analog channel
1 - コールは、アナログチャネルであります
2 - Call is on a digital channel
2 - コールがデジタルチャネルであります
Physical Channel ID This field is set by the PAC in a vendor-specific manner to the number of the physical channel this call arrived on.
物理チャネルIDは、このフィールドは、このコールが到着した物理チャンネルの数にベンダー固有の方法でPACによって設定されています。
Dialed Number Length The actual number of valid digits in the Dialed Number field.
ダイヤル番号の長さダイヤル番号フィールドの有効桁数の実際の数。
Dialing Number Length The actual number of valid digits in the Dialing Number field.
ダイヤル番号の長さダイヤル番号]フィールドに有効桁数の実際の数。
Dialed Number The number that was dialed by the caller. For ISDN and analog calls this field is an ASCII string. If the Dialed Number is less than 64 octets in length, the remainder of this field is filled with octets of value 0.
ダイヤル番号、発信者がダイヤルした番号。 ISDNやアナログコールの場合、このフィールドには、ASCII文字列です。ダイヤルされた番号が、長さが64オクテット未満である場合、このフィールドの残りは値0のオクテットが充填されています。
Dialing Number The number from which the call was placed. For ISDN and analog calls this field is an ASCII string. If the Dialing Number is less than 64 octets in length, the remainder of this field is filled with octets of value 0.
ダイヤル番号のコールが置かれた数。 ISDNやアナログコールの場合、このフィールドには、ASCII文字列です。ダイヤル番号の長さが64オクテット未満である場合、このフィールドの残りは値0のオクテットが充填されています。
Subaddress A 64 octet field used to specify additional dialing information. If the subaddress is less than 64 octets long, the remainder of this field is filled with octets of value 0.
追加のダイヤル情報を指定するために使用するサブアドレス64オクテットフィールド。サブアドレスが64オクテット未満の長さである場合、このフィールドの残りは値0のオクテットが充填されています。
The Incoming-Call-Reply is a PPTP control message sent by the PNS to the PAC in response to a received Incoming-Call-Request message. The reply indicates the result of the incoming call attempt. It also provides information to allow the PAC to regulate the transmission of data to the PNS for this session.
着信-返信受信着信要求メッセージに応答して、PACにPNSによって送信されたPPTP制御メッセージです。回答は、着信コール試行の結果を示しています。また、PACは、このセッションのPNSへのデータの送信を規制することを可能にする情報を提供します。
This message is the second in the three-way handshake used by PPTP for establishing incoming calls. It indicates to the PAC whether the call should be answered or not.
このメッセージは、着信コールを確立するためにPPTPによって使用される3ウェイハンドシェイクに秒です。これは、呼が応答するかどうかをPACに示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Peer's Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Packet Recv. Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Transmit Delay | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 10 for Incoming-Call-Reply.
着信-返信用制御メッセージタイプ10。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Call ID A unique identifier for this tunnel assigned by the PNS to this session. It is used to multiplex and demultiplex data sent over the tunnel between the PNS and PAC involved in this session.
このセッションにPNSによって割り当てられ、このトンネルのID A一意の識別子を呼び出します。なお、このセッションに関係PNSとPACとの間のトンネルを介して送信されたデータを多重化及び逆多重化するために使用されます。
Peer's Call ID This field is set to the value received in the Call ID field of the corresponding Incoming-Call-Request message. It is used by the PAC to match the Incoming-Call-Reply with the Incoming-Call-Request it issued. This value is included in the GRE header of transmitted data packets for this session.
ピアの呼び出しIDこのフィールドは、対応する着信要求メッセージのコールIDフィールドに受信した値に設定されています。それが発行され、着信リクエストで着信-返信を一致させるためにPACで使用されています。この値は、このセッションのために送信されるデータパケットのGREヘッダに含まれています。
Result Code This value indicates the result of the Incoming-Call-Request attempt. Current valid Result Code values are:
結果コードは、この値は、着信リクエストの試みの結果を示しています。現在の有効なResult Code値は以下のとおりです。
1 (Connect) - The PAC should answer
the incoming call
2 (General Error) - The Incoming Call should not be established due to the reason indicated in Error Code
2（一般エラー） - 着信が原因エラーコードで示された理由に確立すべきではありません
3 (Do Not Accept) - The PAC should not accept the incoming call. It should hang up or issue a busy indication
3（受諾しない） - PACは、着信コールを受け入れるべきではありません。これは、ハングアップまたはビジー表示を発行する必要があります
Error Code This field is set to 0 unless a "General Error" condition exists, in which case Result Code is set to 2 and this field is set to the value corresponding to the general error condition as specified in section 2.2.
「一般的なエラー」状態は、その場合には、結果コードが2に設定され、存在しない限りエラーコードこのフィールドは0に設定され、セクション2.2で指定されるように、このフィールドは、一般的なエラー状態に対応する値に設定されています。
Packet Recv. Window Size The number of received data packets the PAC will buffer for this session.
パケットのRecv。ウィンドウサイズは、受信したデータパケットの数PACがこのセッションのためにバッファリングされます。
Packet Transmit Delay A measure of the packet processing delay that might be imposed on data sent to the PAC from the PNS. This value is specified in units of 1/10 seconds.
パケット送信遅延PNSからPACに送信されたデータに課されるかもしれないパケットの処理遅延の尺度。この値は1/10秒単位で指定します。
Reserved1 This field MUST be 0.
Reserved1このフィールドは0でなければなりません。
The Incoming-Call-Connected message is a PPTP control message sent by the PAC to the PNS in response to a received Incoming-Call-Reply. It provides information to the PNS about particular parameters used for the call. It also provides information to allow the PNS to regulate the transmission of data to the PAC for this session.
着信接続メッセージを受信した着信-返信に応答しPNSにPACによって送信されたPPTP制御メッセージです。これは、呼び出しのために使用される特定のパラメータについてのPNSに情報を提供します。それはまた、PNSがこのセッションのためPACへのデータの送信を規制することを可能にする情報を提供します。
This message is the third in the three-way handshake used by PPTP for establishing incoming calls. It provides a mechanism for providing the PNS with additional information about the call that cannot, in general, be obtained at the time the Incoming-Call-Request is issued by the PAC.
このメッセージは、着信コールを確立するためにPPTPで使用スリーウェイハンドシェイクで第です。これは、一般的には、着信リクエストがPACによって発行された時点で取得することができないコールに関する追加情報をPNSを提供するためのメカニズムを提供します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Transmit Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 11 for Incoming-Call-Connected.
着信接続のための制御メッセージタイプ11。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Peer's Call ID This field is set to the value received in the Call ID field of the corresponding Incoming-Call-Reply message. It is used by the PNS to match the Incoming-Call-Connected with the Incoming-Call-Reply it issued.
ピアの呼び出しIDこのフィールドは、対応する着信応答メッセージのコールIDフィールドに受信した値に設定されています。それが発行され、着信-返信で着信接続と一致するPNSによって使用されます。
Connect Speed The actual connection speed used, in bits/second.
速度をビット/秒で、使用される実際の接続速度を接続します。
Packet Recv. Window Size The number of received data packets the PAC will buffer for this session.
パケットのRecv。ウィンドウサイズは、受信したデータパケットの数PACがこのセッションのためにバッファリングされます。
Packet Transmit Delay A measure of the packet processing delay that might be imposed on data sent to the PAC from the PNS. This value is specified in units of 1/10 seconds.
パケット送信遅延PNSからPACに送信されたデータに課されるかもしれないパケットの処理遅延の尺度。この値は1/10秒単位で指定します。
Framing Type A value indicating the type of PPP framing being used by this incoming call.
フレーミングは、この着信呼によって使用されているPPPフレーミングのタイプを示す値を入力します。
1 - Call uses asynchronous framing
1 - コールは非同期フレーミングを使用しています
2 - Call uses synchronous framing
2 - コールは、同期フレーミングを使用しています
The Call-Clear-Request is a PPTP control message sent by the PNS to the PAC indicating that a particular call is to be disconnected. The call being cleared can be either an incoming or outgoing call, in any state. The PAC responds to this message with a Call-Disconnect-Notify message.
コールクリア要求は、特定の呼が切断されることを示すPACとPNSによって送信されたPPTP制御メッセージです。クリアされたコールは、どのような状態で、いずれかの着信または発信コールすることができます。 PACは、コールを外し、通知メッセージを表示して、このメッセージに応答します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 12 for Call-Clear-Request.
コール・クリア・リクエストのための制御メッセージタイプ12。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Call ID The Call ID assigned by the PNS to this call. This value is used instead of the Peer's Call ID because the latter may not be known to the PNS if the call must be aborted during call establishment.
このコールにPNSによって割り当てられたIDザ・コールIDを呼び出します。コールはコール確立中に中止されなければならない場合には後者がPNSには知られていない可能性があるため、この値ではなく、ピアの呼び出しIDの使用されています。
Reserved1 This field MUST be 0.
Reserved1このフィールドは0でなければなりません。
The Call-Disconnect-Notify message is a PPTP control message sent by the PAC to the PNS. It is issued whenever a call is disconnected, due to the receipt by the PAC of a Call-Clear-Request or for any other reason. Its purpose is to inform the PNS of both the disconnection and the reason for it.
コールを切断-通知メッセージは、PNSにPACによって送られたPPTPコントロールメッセージです。通話が切断された場合はいつでもによるコール・クリア・リクエストのPACによる受信またはその他の理由のために、発行されます。その目的は、断線やその理由の両方のPNSに知らせることです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Call Statistics (128 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 13 for Call-Disconnect-Notify.
コールを外し、通知のための制御メッセージの種類13。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Call ID The value of the Call ID assigned by the PAC to this call. This value is used instead of the Peer's Call ID because the latter may not be known to the PNS if the call must be aborted during call establishment.
このコールにPACによって割り当てられたコールIDの値IDを呼び出します。コールはコール確立中に中止されなければならない場合には後者がPNSには知られていない可能性があるため、この値ではなく、ピアの呼び出しIDの使用されています。
Result Code This value indicates the reason for the disconnect. Current valid Result Code values are:
結果コードは、この値は、接続解除の理由を示しています。現在の有効なResult Code値は以下のとおりです。
1 (Lost Carrier) - Call disconnected
due to loss of carrier
2 (General Error) - Call disconnected for the reason indicated in Error Code
2（一般エラー） - エラーコードで示された理由で通話が切断
3 (Admin Shutdown) - Call disconnected for administrative reasons
3（管理シャットダウン） - 管理上の理由で通話が切断
4 (Request) - Call disconnected due to received Call-Clear-Request
4（要求） - 呼び出しによる着信-クリア要求に切断
Error Code This field is set to 0 unless a "General Error" condition exists, in which case the Result Code is set to 2 and this field is set to the value corresponding to the general error condition as specified in section 2.2.
「一般的なエラー」状態は、結果コードが2に設定され、セクション2.2で指定されるように、このフィールドは、一般的なエラー状態に対応する値に設定されている場合には、存在しない限り、エラーコードは、このフィールドは0に設定されています。
Cause Code This field gives additional disconnect information. Its value varies depending on the type of call being disconnected. For ISDN calls it is the Q.931 cause code.
コード原因このフィールドには、追加の切断情報を提供します。その値は切断されるコールのタイプに応じて変化します。 ISDNの場合、それはQ.931原因コードで呼び出します。
Call Statistics This field is an ASCII string containing vendor-specific call statistics that can be logged for diagnostic purposes. If the length of the string is less than 128, the remainder of the field is filled with octets of value 0.
このフィールドは、診断目的のために記録することができ、ベンダー固有のコール統計情報を含むASCII文字列で統計を呼び出します。文字列の長さが128未満の場合、フィールドの残りは値0のオクテットが充填されています。
The WAN-Error-Notify message is a PPTP control message sent by the PAC to the PNS to indicate WAN error conditions (conditions that occur on the interface supporting PPP). The counters in this message are cumulative. This message should only be sent when an error occurs, and not more than once every 60 seconds. The counters are reset when a new call is established.
WAN誤り通知メッセージは、（PPPをサポートするインタフェースで発生条件）WANエラー条件を示すために、PNSにPACによって送信されたPPTP制御メッセージです。このメッセージのカウンタは累積されます。このメッセージは60秒ごとに1回以上のエラーが発生した場合に送信され、そしてませんする必要があります。新しいコールが確立されたときにカウンタがリセットされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 14 for WAN-Error-Notify.
WAN誤り通知のための制御メッセージタイプ14。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Peer's Call ID Th Call ID assigned by the PNS to this call.
ピアの呼び出しIDのThコールIDがこのコールにPNSによって割り当てられます。
CRC Errors Number of PPP frames received with CRC errors since session was established.
セッションが確立されてからPPPフレームのCRCエラー数は、CRCエラー付きで受信しました。
Framing Errors Number of improperly framed PPP packets received.
フレーミング・エラー不適切フレームPPPパケットの受信数。
Hardware Overruns Number of receive buffer over-runs since session was established.
ハードウェアは、セッションが確立されてからかけラン受信バッファの数をオーバーラン。
Buffer Overruns Number of buffer over-runs detected since session was established.
バッファオーバーランセッションが確立されてから検出されたバッファの数をオーバーラン。
Time-out Errors Number of time-outs since call was established.
コールが確立されてからのタイムアウトのタイムアウトエラーの数。
Alignment Errors Number of alignment errors since call was established.
コールが確立されましたので、アライメントエラーのアラインメントエラー数。
The Set-Link-Info message is a PPTP control message sent by the PNS to the PAC to set PPP-negotiated options. Because these options can change at any time during the life of the call, the PAC must be able to update its internal call information dynamically and perform PPP negotiation on an active PPP session.
セットリンク-Infoメッセージは、PPPネゴシエーションオプションを設定するには、PACにPNSによって送られたPPTPコントロールメッセージです。これらのオプションは、コールの生活中にいつでも変更することができますので、PACは動的に内部の呼び出し情報を更新し、アクティブなPPPセッション上のPPPネゴシエーションを行うことができなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message, including the entire PPTP header.
全体PPTPヘッダを含むこのPPTPメッセージのオクテットの長さの合計の長さ。
PPTP Message Type 1 for Control Message.
制御メッセージのためのPPTPメッセージ・タイプ1。
Magic Cookie 0x1A2B3C4D.
マジッククッキー0x1A2B3C4D。
Control Message Type 15 for Set-Link-Info.
セットリンク情報のための制御メッセージの種類15。
Reserved0 This field MUST be 0.
Reserved0このフィールドは0でなければなりません。
Peer's Call ID The value of the Call ID assigned by the PAC to this call.
ピアの呼び出しIDこのコールにPACによって割り当てられたコールIDの値。
Reserved1 This field MUST be 0.
Reserved1このフィールドは0でなければなりません。
Send ACCM The send ACCM value the client should use to process outgoing PPP packets. The default value used by the client until this message is received is 0XFFFFFFFF. See [7].
ACCMにクライアントが発信PPPパケットを処理するために使用すべき送信ACCM値を送信します。このメッセージが受信されるまで、クライアントで使用されるデフォルト値は0XFFFFFFFFです。 [7]を参照してください。
Receive ACCM The receive ACCM value the client should use to process incoming PPP packets. The default value used by the client until this message is received is 0XFFFFFFFF. See [7].
ACCMザ・クライアントは、着信PPPパケットを処理するために使用すべきACCM値を受け取る受信。このメッセージが受信されるまで、クライアントで使用されるデフォルト値は0XFFFFFFFFです。 [7]を参照してください。
General error codes pertain to types of errors which are not specific to any particular PPTP request, but rather to protocol or message format errors. If a PPTP reply indicates in its Result Code that a general error occurred, the General Error value should be examined to determined what the error was. The currently defined General Error codes and their meanings are:
一般的なエラーコードは、任意の特定のPPTP要求に固有ではなく、プロトコルまたはメッセージフォーマットのエラーではないエラーの種類に関係します。 PPTPの回答が一般的なエラーが発生し、その結果コードに示されている場合、一般的なエラー値は、エラーが何であったか判断に検討する必要があります。現在定義されている一般的なエラーコードとその意味は以下のとおりです。
0 (None) - No general error
0（なし） - 無一般的なエラー
1 (Not-Connected) - No control connection exists yet for this PAC-PNS pair
1（非接続） - 無制御接続はこのPAC-PNS対に対してまだ存在しません
2 (Bad-Format) - Length is wrong or Magic Cookie value is incorrect
2（バート・フォーマット） - 長さが間違っているか、マジックCookie値が正しくありません
3 (Bad-Value) - One of the field values was out of range or reserved field was non-zero
3（不正値） - フィールドの値の1つが範囲外であった、または予約済みフィールドが非ゼロでした
4 (No-Resource) - Insufficient resources to handle this command now
4（無資源） - 今、このコマンドを処理するためのリソースが不足
5 (Bad-Call ID) - The Call ID is invalid in this context
5（バート・コールID） - コールIDは、このコンテキストでは無効です。
6 (PAC-Error) - A generic vendor-specific error occurred in the PAC
6（PAC-エラー） - ジェネリックベンダー固有のエラーがPACで発生
This section describes the operation of various PPTP control connection functions and the Control Connection messages which are used to support them. The protocol operation of the control connection is simplified because TCP is used to provide a reliable transport mechanism. Ordering and retransmission of messages is not a concern at this level. The TCP connection itself, however, can close at any time and an appropriate error recovery mechanism must be provided to handle this case.
このセクションでは、それらをサポートするために使用される各種のPPTP制御接続機能と制御接続メッセージの動作を説明します。 TCPは信頼性の高いトランスポート機構を提供するために使用されているため、制御接続のプロトコル動作が簡略化されます。メッセージの順序付け及び再送信は、このレベルでは問題ではありません。 TCP接続自体は、しかし、いつでも閉じることができ、適切なエラー回復メカニズムは、このケースを処理するために提供されなければなりません。
Some error recovery procedures are common to all states of the control connection. If an expected reply does not arrive within 60 seconds, the control connection is closed, unless otherwise specified. Appropriate logging should be implemented for easy determination of the problems and the reasons for closing the control connection.
いくつかのエラー回復手順は、制御接続のすべての状態に共通しています。予想される回答が60秒以内に到着しない場合は、特に断りのない限り、制御接続は、閉じられています。適切なロギングが容易な問題の決意と制御接続を閉じるための理由のために実装する必要があります。
Receipt of an invalid or malformed Control Connection message should be logged appropriately, and the control connection should be closed and restarted to ensure recovery into a known state.
無効または不正な形式の制御接続メッセージの受信を適切にログインする必要があり、制御接続を閉じて既知の状態への回復を確実にするために再起動しなければなりません。
The control connection relies on a standard TCP connection for its service. The PPTP control connection protocol is not distinguishable between the PNS and PAC, but is distinguishable between the originator and receiver. The originating peer is the one which first attempts the TCP open. Since either PAC or PNS may originate a connection, it is possible for a TCP collision to occur. See section 3.1.3 for a description of this situation.
コントロール接続は、そのサービスのための標準的なTCP接続に依存しています。 PPTP制御接続プロトコルは、PNSとPACとの間の区別可能ではなく、発信者と受信機の間で区別されます。発信元ピアは最初のオープンTCPを試みるものです。 PACかPNSのどちらかが接続を生じ得るので、TCPの衝突が発生する可能性があります。このような状況の説明については、セクション3.1.3を参照してください。
TCP Open Indication
/Send Start Control
Connection Request +-----------------+
+------------------------------------>| wait_ctl_reply |
| +-----------------+
| Collision/See (4.1.3) Close TCP V V V Receive Start Ctl
| +-------------------------------+ | | Connection Reply
| | | | Version OK
^ V | V
+-----------------+ Receive Start Ctl | +-----------------+
| idle | Connection Reply | | established |
+-----------------+ Version Not OK | +-----------------+
^ | V Local Terminate
| Receive Stop Control | | /Send Stop
| Connection Request | | Control Request
| /Send Stop Control Reply V V
| Close TCP +-----------------+
+-------------------------------------| wait_stop_reply |
+-----------------+
idle The control connection originator attempts to open a TCP connection to the peer during idle state. When the TCP connection is open, the originator transmits a send Start-Control-Connection-Request and then enters the wait_ctl_reply state.
アイドル状態中にピアへのTCP接続を開くために制御接続発信試行アイドル。 TCP接続が開いている場合、発信者は送信スタートコントロール接続要求を送信し、その後wait_ctl_reply状態に入ります。
wait_ctl_reply The originator checks to see if another TCP connection has been requested from the same peer, and if so, handles the collision situation described in section 3.1.3.
別のTCP接続が同じピアから要求されたかどうかを確認するために、発信チェックをwait_ctl_reply、もしそうなら、セクション3.1.3で説明した衝突状況を処理します。
When a Start-Control-Connection-Reply is received, it is examined for a compatible version. If the version of the reply is lower than the version sent in the request, the older (lower) version should be used provided it is supported. If the version in the reply is earlier and supported, the originator moves to the established state. If the version is earlier and not supported, a Stop-Control-Connection-Request SHOULD be sent to the peer and the originator moves into the wait_stop_reply state.
スタートコントロール接続応答を受信したときには、互換性のあるバージョンのために検査されます。応答のバージョンが要求で送信されたバージョンよりも低い場合、使用されるべき古い（下）バージョンは、それがサポートされていました。応答内のバージョンが古いとサポートされている場合、発信者は確立状態に移行します。バージョンは以前とサポートされていない場合には、停止コントロール接続要求がピアに送信され、発信者はwait_stop_replyの状態に移行するべきです。
established An established connection may be terminated by either a local condition or the receipt of a Stop-Control-Connection-Request. In the event of a local termination, the originator MUST send a Stop-Control-Connection-Request and enter the wait_stop_reply state.
確立し、確立された接続は、ローカル状態またはStopコントロール接続要求の受信のいずれかによって終了することができます。ローカル終了の場合には、発信元は、ストップコントロール接続要求を送信し、wait_stop_reply状態を入力する必要があります。
If the originator receives a Stop-Control-Connection-Request it SHOULD send a Stop-Control-Connection-Reply and close the TCP connection making sure that the final TCP information has been "pushed" properly.
発信者が受信した場合の停止コントロール接続要求には、ストップコントロール接続返信を送信し、TCPコネクション最終TCP情報を適切に「プッシュ」されていることを確認することを閉じる必要があります。
wait_stop_reply If a Stop-Control-Connection-Reply is received, the TCP connection SHOULD be closed and the control connection becomes idle.
停止コントロール接続応答が受信された場合wait_stop_reply、TCP接続が閉じられるべきと制御接続がアイドル状態になります。
Receive Start Control Connection Request
Version Not OK/Send Start Control Connection
Reply with Error
+--------+
| | Receive Control Connection Request Version OK
| | /Send Start Control Connection Reply
| | +----------------------------------------+
^ V ^ V
+-----------------+ Receive Start Ctl +-----------------+
| Idle | Connection Request | Established |
+-----------------+ /Send Stop Reply +-----------------+
^ ^ Close TCP V V Local Terminate
| +-------------------------------------+ | /Send Stop
| | Control Conn.
| V Request
| +-----------------+
+-------------------------------------| Wait-Stop-Reply |
Receive Stop Control +-----------------+
Connection Reply
/Close TCP
idle The control connection receiver waits for a TCP open attempt on port 1723. When notified of an open TCP connection, it should prepare to receive PPTP messages. When a Start-Control-Connection-Request is received its version field should be examined. If the version is earlier than the receiver's version and the earlier version can be supported by the receiver, the receiver SHOULD send a Start-Control-Connection-Reply. If the version is earlier than the receiver's version and the version cannot be supported, the receiver SHOULD send a Start-Connection-Reply message, close the TCP connection and remain in the idle state. If the receiver's version is the same as earlier than the peer's, the receiver SHOULD send a Start-Control-Connection-Reply with the receiver's version and enter the established state.
オープンTCP接続の通知をポート1723上のTCPオープンの試みのための制御接続受信待機アイドル、それはPPTPメッセージを受信するために準備する必要があります。スタートコントロール接続要求を受信した場合、そのバージョンフィールドを検討する必要があります。バージョンは、受信側のバージョンよりも前であるとそれ以前のバージョンは、受信機によってサポートできる場合、受信機は、スタートコントロール接続返信を送るべきです。バージョンは、受信側のバージョンより前のバージョンはサポートできない場合は、[スタート] - 接続応答メッセージを送るべき受信機は、TCPコネクションを閉じ、アイドル状態のまま。レシーバのバージョンがピアのより早いと同じである場合、受信機は、受信機のバージョンでスタートコントロール接続返信を送信し、確立状態を入力する必要があります。
established An established connection may be terminated by either a local condition or the reception of a Stop-Control-Connection-Request. In the event of a local termination, the originator MUST send a Stop-Control-Connection-Request and enter the wait_stop_reply state.
確立された確立された接続は、ローカル状態または停止制御、接続要求の受信のいずれかによって終了することができます。ローカル終了の場合には、発信元は、ストップコントロール接続要求を送信し、wait_stop_reply状態を入力する必要があります。
If the originator receives a Stop-Control-Connection-Request it SHOULD send a Stop-Control-Connection-Reply and close the TCP connection, making sure that the final TCP information has been "pushed" properly.
発信元が停止コントロール接続要求を受信した場合には、最終的なTCP情報を適切に「プッシュ」されていることを確認して、停止コントロール接続返信を送信し、TCP接続を閉じる必要があります。
wait_stop_reply If a Stop-Control-Connection-Reply is received, the TCP connection SHOULD be closed and the control connection becomes idle.
停止コントロール接続応答が受信された場合wait_stop_reply、TCP接続が閉じられるべきと制御接続がアイドル状態になります。
A PAC and PNS must have only one control connection between them. It is possible, however, for a PNS and a PAC to simultaneously attempt to establish a control connection to each other. When a Start-Control-Connection-Request is received on one TCP connection and another Start-Control-Connection-Request has already been sent on another TCP connection to the same peer, a collision has occurred.
PACとPNSは、それらの間の唯一の制御接続を持っている必要があります。 PNSとPACが同時に相互に制御接続を確立しようとすることは、しかし、可能です。スタートコントロール接続要求が1つのTCP接続で受信され、別のスタートコントロール接続要求がすでに同じピアへの別のTCP接続で送信された場合には、衝突が発生しています。
The "winner" of the initiation race is the peer with the higher IP address (compared as 32 bit unsigned values, network number more significant). For example, if the peers 192.33.45.17 and 192.33.45.89 collide, the latter will be declared the winner. The loser will immediately close the TCP connection it initiated, without sending any further PPTP control messages on it and will respond to the winner's request with a Start-Control-Connection-Reply message. The winner will wait for the Start-Control-Connection-Reply on the connection it initiated and also wait for a TCP termination indication on the connection the loser opened. The winner MUST NOT send any messages on the connection the loser initiated.
開始レースの「勝者」は、（32ビットの符号なしの値、ネットワークの数より有意と比較して）より高いIPアドレスを持つピアです。ピア192.33.45.17と192.33.45.89が衝突した場合、後者が勝者と宣言されるであろう。敗者はすぐ上の任意の更なるPPTP制御メッセージを送信せず、それが開始されたTCPコネクションを閉じ、スタートコントロール接続応答メッセージと勝者の要求に応答します。勝者は、それが開始された接続上のスタートコントロール接続応答を待つとも敗者が開かれ、接続のTCP終了指示を待ちます。勝者は敗者が開始された接続上の任意のメッセージを送ってはいけません。
A control connection SHOULD be closed by closing the underlying TCP connection under the following circumstances:
制御接続は、以下の状況下では、基礎となるTCP接続を閉じることによって閉鎖されるべきです。
1. If a control connection is not in the established state (i.e., Start-Control-Connection-Request and Start-Control-Connection-Reply have not been exchanged), a control connection SHOULD be closed after 60 seconds by a peer waiting for a Start-Control-Connection-Request or Start-Control-Connection-Reply message.
制御接続が確立状態でない場合1（すなわち、コントロール接続要求を起動し、[スタートコントロール接続返信交換されていない）、コントロール接続が閉じられるべきであるのを待っているピアでは60秒後にスタートコントロール接続要求またはメッセージコントロール接続返信起動します。
2. If a peer's control connection is in the established state and has not received a control message for 60 seconds, it SHOULD send a Echo-Request message. If an Echo-Reply is not received 60 seconds after the Echo-Request message transmission, the control connection SHOULD be closed.
2.ピアのコントロール接続を確立した状態にあり、60秒のための制御メッセージを受信していない場合は、エコー要求メッセージを送信する必要があります。エコー応答がエコー要求メッセージを送信した後に60秒受信されない場合、制御接続は閉じられるべきです。
Because of the real-time nature of telephone signaling, both the PNS and PAC should be implemented with multi-threaded architectures such that messages related to multiple calls are not serialized and blocked. The transit delay between the PAC and PNS should not exceed one second. The call and connection state figures do not specify exceptions caused by timers. The implicit assumption is that since the TCP-based control connection is being verified with keep-alives, there is less need to maintain strict timers for call control messages.
なぜなら電話シグナリングのリアルタイムの性質のため、PNSとPACの両方が複数の呼び出しに関連するメッセージをシリアライズとブロックされないようなマルチスレッドアーキテクチャで実装されるべきです。 PACとPNSとの間の伝送遅延は、一秒を超えてはなりません。コールや接続状態の数字は、タイマーによって引き起こされる例外を指定しないでください。暗黙の前提は、TCPベースの制御接続がキープアライブで確認されているため、呼制御メッセージのための厳格なタイマーを維持するために、より少ない必要があるということです。
Establishing outbound international calls, including the modem training and negotiation sequences, may take in excess of 1 minute so the use of short timers is discouraged.
短いタイマーの使用が推奨されてモデムトレーニングと交渉配列を含むアウトバウンド国際電話を、確立、1分以上かかることがあります。
If a state transition does not occur within 1 minute (except for connections in the idle or established states), the integrity of the protocol processing between the peers is suspect and the ENTIRE CONTROL CONNECTION should be closed and restarted. All Call IDs are logically released whenever a control connection is started. This presumably also helps in preventing toll calls from being "lost" and never cleared.
状態遷移が（アイドル又は確立された状態で接続を除く）1分以内に発生しない場合、ピア間のプロトコル処理の完全性が疑わしいと全体の制御接続が閉じて再起動しなければなりません。制御接続が開始されるたびにすべてのコールIDが論理的に解放されています。これは、おそらくまた、「失われない」と決してクリアさからの有料通話を防ぐのに役立ちます。
Each peer assigns a Call ID value to each user session it requests or accepts. This Call ID value MUST be unique for the tunnel between the PNS and PAC to which it belongs. Tunnels to other peers can use the same Call ID number so the receiver of a packet on a tunnel needs to associate a user session with a particular tunnel and Call ID. It is suggested that the number of potential Call ID values for each tunnel be at least twice as large as the maximum number of calls expected on a given tunnel.
各ピアは、それが要求したり受け入れ、各ユーザーセッションにコールID値を割り当てます。このコールID値は、それが属するPNSとPACとの間のトンネルで一意である必要があります。トンネル上のパケットの受信機は、特定のトンネルおよびCall IDとユーザセッションを関連付ける必要があるので、他のピアへのトンネルが同一のコールID番号を使用することができます。各トンネルのための潜在的なコールID値の数が所定のトンネルの期待コールの最大数の少なくとも2倍の大きさであることが示唆されます。
A session is defined by the triple (PAC, PNS, Call ID).
セッションはトリプル（PAC、PNS、コールID）によって定義されます。
An Incoming-Call-Request message is generated by the PAC when an associated telephone line rings. The PAC selects a Call ID and serial number and indicates the call bearer type. Modems should always indicate analog call type. ISDN calls should indicate digital when unrestricted digital service or rate adaption is used and analog if digital modems are involved. Dialing number, dialed number, and subaddress may be included in the message if they are available from the telephone network.
着信-Requestメッセージは、PACに関連する電話回線リングによって生成されます。 PACは、コールIDとシリアル番号を選択して呼のベアラタイプを示します。モデムは必ずアナログコールタイプを示す必要があります。 ISDNコールは非制限デジタルサービスまたはレート適応を使用する場合、デジタル示し、デジタルモデムが関与する場合アナログべきです。彼らが電話網から利用可能である場合ダイヤル番号、ダイヤルされた番号、及びサブアドレスは、メッセージに含まれてもよいです。
Once the PAC sends the Incoming-Call-Request, it waits for a response from the PNS but does not answer the call from the telephone network. The PNS may choose not to accept the call if:
PACは、着信-Requestを送信すると、それはPNSからの応答を待つが、電話網からのコールに応答しません。 PNSは、以下の場合に、コールを受け入れないのを選ぶかもしれません。
- No resources are available to handle more sessions
- いいえ、リソースが複数のセッションを処理するために用意されていません
- The dialed, dialing, or subaddress fields are not indicative of an authorized user
- ダイヤルし、ダイヤル、またはサブアドレスフィールドが許可されたユーザを示すものではありません
- The bearer service is not authorized or supported
- ベアラサービスは、許可またはサポートされていません。
If the PNS chooses to accept the call, it responds with an Incoming-Call-Reply which also indicates window sizes (see section 4.2). When the PAC receives the Outgoing-Call-Reply, it attempts to connect the call, assuming the calling party has not hung up. A final call connected message from the PAC to the PNS indicates that the call states for both the PAC and the PNS should enter the established state.
PNSがコールを受け入れることを選択した場合、それはまた、ウィンドウサイズ（セクション4.2を参照）を示し、着信-返信で応答します。 PACは、発信コール-返信を受信すると、発呼者がハングアップしていないと仮定すると、通話を接続しようとします。 PNSへのPACから最終的なコール接続メッセージは、PACとPNSの両方のためのコール状態が確立された状態に入るべきであることを示します。
When the dialed-in client hangs up, the call is cleared normally and the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to clear a call, it sends a Call-Clear-Request message and then waits for a Call-Disconnect-Notify.
ダイヤルインクライアントが電話を切ると、通話が正常にクリアされ、PACは、コールの切断 - 通知メッセージを送信します。 PNSが呼び出しをクリアしたい場合は、コール・クリア-Requestメッセージを送信し、コールを切断-通知を待ちます。
Ring/Send Incoming Call Request +-----------------+
+----------------------------------------->| wait_reply |
| +-----------------+
| Receive Incoming Call Reply V V V
| Not Accepting | | | Receive Incoming
| +--------------------------------+ | | Call Reply Accept-
| | +------------------------------+ | ing/Answer call;
| | | Abort/Send Call | Send Call
^ V V Disconnect Notify V Connected
+-----------------+ +-----------------+
| idle |<-----------------------------| established |
+-----------------+ Receive Clear Call Request +-----------------+
or telco call dropped
or local disconnect
/Send Call Disconnect Notify
The states associated with the PAC for incoming calls are:
着信コールに対してPACと関連する状態は以下のとおりです。
idle The PAC detects an incoming call on one of its telco interfaces. Typically this means an analog line is ringing or an ISDN TE has detected an incoming Q.931 SETUP message. The PAC sends an Incoming-Call-Request message and moves to the wait_reply state.
PACは、その電話会社のインターフェイスのいずれかで着信を検出するアイドル。典型的には、これはアナログラインが鳴っているか、ISDN TE着信Q.931 SETUPメッセージを検出したことを意味します。 PACは、着信要求メッセージを送信し、wait_reply状態に移行します。
wait_reply The PAC receives an Incoming-Call-Reply message indicating non-willingness to accept the call (general error or don't accept) and moves back into the idle state. If the reply message indicates that the call is accepted, the PAC sends an Incoming-Call-Connected message and enters the established state.
wait_reply PACは、呼受諾する（一般的なエラーまたは受け入れない）非意欲を示す着信応答メッセージを受信し、アイドル状態に戻ります。応答メッセージは、コールが受け入れられることを示している場合、PACは、着信接続メッセージを送信し、確立状態に入ります。
established Data is exchanged over the tunnel. The call may be cleared following:
確立されたデータは、トンネルを介して交換されます。 ：呼び出しは、次のようにクリアすることができます
An event on the telco connection. The PAC sends a
Call-Disconnect-Notify message
Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect-Notify message
コールクリア要求の受信。 PACは、コールの切断 - 通知メッセージを送信します
A local reason. The PAC sends a Call-Disconnect-Notify message.
地元の理由。 PACは、コールの切断 - 通知メッセージを送信します。
Receive Incoming Call Request
/Send Incoming Call Reply +-----------------+
Not Accepting if Error | Wait-Connect |
+-----+ +-----------------+
| | Receive Incoming Call Req. ^ V V
| | /Send Incoming Call Reply OK | | | Receive Incoming
| | +--------------------------------+ | | Call Connect
^ V ^ V------------------------------+ V
+-----------------+ Receive Call Disconnect +-----------------+
| Idle | Notify +- | Established |
+-----------------+ | +-----------------+
^ ^ | V Local Terminate
| +----------------------------+ | /Send Call Clear
| Receive Call Disconnect | Request
| Notify V
| +-----------------+
+--------------------------------------| Wait-Disconnect |
Receive Call Disconnect +-----------------+
Notify
The states associated with the PNS for incoming calls are:
着信コールのためのPNSに関連した状態は、次のとおりです。
idle An Incoming-Call-Request message is received. If the request is not acceptable, an Incoming-Call-Reply is sent back to the PAC and the PNS remains in the idle state. If the Incoming-Call-Request message is acceptable, an Incoming-Call-Reply is sent indicating accept in the result code. The session moves to the wait_connect state.
着信-Requestメッセージを受信したアイドル。要求が受け入れられない場合は、着信-返信バックPACに送信され、PNSは、アイドル状態のまま。着信要求メッセージが受け入れ可能である場合、着信リプライは、結果コードに受け入れる示す送られます。セッションはWAIT_CONNECTステートに移行します。
wait_connect If the session is connected on the PAC, the PAC sends an incoming call connect message to the PNS which then moves into established state. The PAC may send a Call-Disconnect-Notify to indicate that the incoming caller could not be connected. This could happen, for example, if a telephone user accidently places a standard voice call to a PAC resulting in a handshake failure on the called modem.
WAIT_CONNECTセッションをPACに接続されている場合、PACは、次いで確立状態に移行PNSへの着信接続メッセージを送信します。 PACは、着信呼び出し側は接続できなかったことを示すためにコールの切断は、通知送信してもよいです。電話ユーザが誤って呼ばれるモデムのハンドシェイク障害の原因となるPACに標準の音声通話を置く場合、これは、例えば、発生する可能性があります。
established The session is terminated either by receipt of a Call-Disconnect-Notify message from the PAC or by sending a Call-Clear-Request. Once a Call-Clear-Request has been sent, the session enters the wait_disconnect state.
確立されたセッションは、領収書のいずれかによって終了したコールの切断が-通知PACから、あるいはコール・クリア・リクエストを送信することにより、メッセージを。コール・クリア・リクエストが送信されると、セッションはwait_disconnect状態になります。
wait_disconnect Once a Call-Disconnect-Notify is received the session moves back to the idle state.
一度コールを切断-通知wait_disconnectバックアイドル状態にセッション移行を受けています。
Outgoing messages are initiated by a PNS and instruct a PAC to place a call on a telco interface. There are only two messages for outgoing calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends an Outgoing-Call-Request specifying the dialed party phone number and subaddress as well as speed and window parameters. The PAC MUST respond to the Outgoing-Call-Request message with an Outgoing-Call-Reply message once the PAC determines that:
送信メッセージは、PNSによって開始され、電話会社のインタフェース上で電話をかけるためにPACを指示しています。発信・コール要求と発信コール-返信：発信通話のための唯一の2つのメッセージがあります。 PNSは、ダイヤルした相手の電話番号とサブアドレスだけでなく、速度や窓のパラメータを指定して発信コール-Requestを送信します。 PACはそれを決定したら、PACは、発信-CALL-ReplyメッセージでOutgoing-Call-Requestメッセージに反応しなければなりません。
The call has been successfully connected
呼び出しが正常に接続されています
A call failure has occurred for reasons such as: no interfaces are available for dial-out, the called party is busy or does not answer, or no dial tone is detected on the interface chosen for dialing
何のインタフェースがダイヤルアウトのために用意されていない、着信側が通話中または応答しない、またはまったくダイヤルトーンがダイヤルに選択したインターフェイス上で検出されない：コールの失敗は、次のような理由により、発生しました
Receive Outgoing Call Request in Error
/Send Outgoing Call Reply with Error
|--------+
| | Receive Outgoing Call Request No Error
| | /Off Hook; Dial
| | +-----------------------------------------
^ V ^ V
+-----------------+ Incomplete Call +-----------------+
| idle | /Send Outgoing Call | wait_cs_ans |
+-----------------+ Reply with Error +-----------------+
^ ^ or Recv. Call Clear Req. V V Telco Answer
| | /Send Disconnect Notify| | /Send Outgoing
| +-------------------------------------+ | Call Reply.
| V
| +-----------------+
+-------------------------------------| established |
Receive Call Clear Request +-----------------+
or local terminate
or telco disconnect
/Hangup call and send
Call Disconnect Notify
The states associated with the PAC for outgoing calls are:
発信コールのためにPACと関連する状態は以下のとおりです。
idle Received Outgoing-Call-Request. If this is received in error, respond with an Outgoing-Call-Reply with error condition set. Otherwise, allocate physical channel to dial on. Place the outbound call, wait for a connection, and move to the wait_cs_ans state.
受信した発信コール-Requestをアイドル。これはエラーで受信された場合、エラー条件が設定された発信コール-返信で応答します。それ以外の場合は、上のダイヤルする物理チャネルを割り当てます。 、アウトバウンドコールを発信接続を待ち、そしてwait_cs_ans状態に移行します。
wait_cs_ans If the call is incomplete, send an Outgoing-Call-Reply with a non-zero Error Code. If a timer expires on an outbound call, send back an Outgoing-Call-Reply with a non-zero Error Code. If a circuit switched connection is established, send an Outgoing-Call-Reply indicating success.
コールが不完全な場合wait_cs_ans、非ゼロのエラーコードを発信-CALL-返信を送ります。タイマーが発信コールで期限切れになった場合、非ゼロのエラーコードでの発信・コール返信を送り返します。回路が確立され、接続を切り替えた場合、成功を示す発信コール-返信を送ります。
established If a Call-Clear-Request is received, the telco call SHOULD be released via appropriate mechanisms and a Call-Disconnect-Notify message SHOULD BE sent to the PNS. If the call is disconnected by the client or by the telco interface, a Call-Disconnect-Notify message SHOULD be sent to the PNS.
コール・クリア・リクエストを受信した場合に確立、電話会社の通話は、適切なメカニズムを介して放出されるべきであり、コールの切断-通知メッセージは、PNSに送信する必要があります。コールがクライアントによってまたはTelcoインターフェイスによって切断された場合、コールを切断-通知メッセージは、PNSに送信する必要があります。
Open Indication Abort/Send
/Send Outgoing Call Call Clear
Request +-----------------+Request
+-------------------------------->| Wait-Reply |----------+
| +-----------------+ |
| Receive Outgoing Call Reply V V Receive Outgoing |
| with Error | | Call Reply |
| +-------------------------------+ | No Error |
^ V V |
+-----------------+ +-----------------+ |
| Idle |<-----------------------------| Established | |
+-----------------+ Receive Call Disconnect +-----------------+ |
^ Notify V Local Terminate |
| | /Send Call Clear |
| | Request |
| Receive Call Disconnect V |
| Notify +-----------------+ |
+---------------------------------| Wait-Disconnect |<---------+
+-----------------+
The states associated with the PNS for outgoing calls are:
発信コールのためのPNSに関連した状態は、次のとおりです。
idle An Outgoing-Call-Request message is sent to the PAC and the session moves into the wait_reply state.
アイドルOutgoing-Call-Requestメッセージは、PACとwait_reply状態にセッションを移動するに送信されます。
wait_reply An Outgoing-Call-Reply is received which indicates an error. The session returns to idle state. No telco call is active. If the Outgoing-Call-Reply does not indicate an error, the telco call is connected and the session moves to the established state.
wait_reply発信コール-返信がエラーを示している受け取られます。セッションがアイドル状態に戻ります。いいえ電話会社の通話がアクティブではありません。発信コール-返信がエラーを示していない場合、電話会社の通話が接続され、確立された状態へのセッション移動しています。
established If a Call-Disconnect-Notify is received, the telco call has been terminated for the reason indicated in the Result and Cause Codes. The session moves back to the idle state. If the PNS chooses to terminate the session, it sends a Call-Clear-Request to the PAC and then enters the wait_disconnect state.
コールを切断-通知した場合に確立された受信、電話会社の通話が結果に示されている理由で終了とコードが原因となっていました。セッションがアイドル状態に戻ります。 PNSは、セッションを終了することを選択した場合、それはPACへのコール・クリア・リクエストを送信し、wait_disconnect状態に入ります。
wait_disconnect A session disconnection is waiting to be confirmed by the PAC. Once the PNS receives the Call-Disconnect-Notify message, the session enters idle state.
wait_disconnectセッション切断はPACによって確認されるのを待っています。 PNSは、コールを切断-通知メッセージを受信すると、セッションがアイドル状態に入ります。
The user data carried by the PPTP protocol are PPP data packets. PPP packets are carried between the PAC and PNS, encapsulated in GRE packets which in turn are carried over IP. The encapsulated PPP packets are essentially PPP data packets less any media specific framing elements. No HDLC flags, bit insertion, control characters, or control character escapes are included. No CRCs are sent through the tunnel. The IP packets transmitted over the tunnels between a PAC and PNS has the following general structure:
PPTPプロトコルによって運ばれるユーザデータは、PPPデータパケットです。 PPPパケットは順番にIP上で搬送されるGREパケットにカプセル化PACとPNSの間に搬送されます。カプセル化されたPPPパケットは、以下本質的に任意のメディアの特定のフレーム要素PPPデータパケットです。いいえHDLCフラグ、ビット挿入、制御文字、または制御文字のエスケープが含まれていません。何のCRCは、トンネルを介して送信されていません。 PACとPNSの間のトンネルを介して送信されるIPパケットは、以下の一般構造を有します：
+--------------------------------+
| Media Header |
+--------------------------------+
| IP Header |
+--------------------------------+
| GRE Header |
+--------------------------------+
| PPP Packet |
+--------------------------------+
The GRE header used in PPTP is enhanced slightly from that specified in the current GRE protocol specification [1,2]. The main difference involves the definition of a new Acknowledgment Number field, used to determine if a particular GRE packet or set of packets has arrived at the remote end of the tunnel. This Acknowledgment capability is not used in conjunction with any retransmission of user data packets. It is used instead to determine the rate at which user data packets are to be transmitted over the tunnel for a given user session. The format of the enhanced GRE header is as follows:
PPTPで使用されるGREヘッダーは現在のGREプロトコル仕様[1,2]で指定されたものからわずかに増強されます。主な違いは、特定のGREパケットまたはパケットのセットがトンネルのリモートエンドに到達したかどうかを決定するために使用される新しい確認応答番号フィールドの定義を含みます。この承認機能は、ユーザデータパケットのいずれかの再送信に関連して使用されていません。ユーザ・データ・パケットが所与のユーザセッションのためのトンネルを介して送信される速度を決定するために代わりに使用されています。次のように拡張GREヘッダーのフォーマットは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (HW) Payload Length | Key (LW) Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C (Bit 0) Checksum Present. Set to zero (0).
C（ビット0）チェックサム現状。ゼロ（0）に設定します。
R (Bit 1) Routing Present. Set to zero (0).
R（ビット1）は、本ルーティング。ゼロ（0）に設定します。
K (Bit 2) Key Present. Set to one (1). S (Bit 3) Sequence Number Present. Set to one (1) if a payload (data) packet is present. Set to zero (0) if payload is not present (GRE packet is an Acknowledgment only).
K（ビット2）主要なプレゼント。 1（1）に設定します。 S（ビット3）シーケンス番号プレゼント。いずれかに設定（1）のペイロード（データ）パケットが存在する場合。ペイロードが存在しない場合（GREパケットのみ肯定応答である）がゼロ（0）に設定します。
s (Bit 4) Strict source route present. Set to zero (0).
S（ビット4）厳密なソースルート存在します。ゼロ（0）に設定します。
Recur (Bits 5-7) Recursion control. Set to zero (0).
（ビット5-7）再帰制御を再発します。ゼロ（0）に設定します。
A (Bit 8) Acknowledgment sequence number present. Set to one (1) if packet contains Acknowledgment Number to be used for acknowledging previously transmitted data.
（8ビット）が存在確認応答シーケンス番号。パケットは、以前に送信されたデータを肯定応答するために使用される確認応答番号が含まれている場合は、1つ（1）に設定されます。
Flags (Bits 9-12) Must be set to zero (0).
フラグ（ビット9-12）は、ゼロ（0）に設定する必要があります。
Ver (Bits 13-15) Must contain 1 (enhanced GRE).
版（ビット13-15）1（拡張GRE）が含まれている必要があります。
Protocol Type Set to hex 880B [8].
880BをHexに設定するプロトコルタイプ[8]。
Key Use of the Key field is up to the implementation. PPTP uses it as follows: Payload Length (High 2 octets of Key) Size of the payload, not including the GRE header
キーフィールドの主な用途は実装次第です。次のようにPPTPは、それを使用する：GREヘッダーを含まないペイロード長（キーの上位2つのオクテット）ペイロードのサイズを、
Call ID
(Low 2 octets) Contains the Peer's Call ID for the session
to which this packet belongs.
Sequence Number Contains the sequence number of the payload. Present if S bit (Bit 3) is one (1).
シーケンス番号は、ペイロードのシーケンス番号が含まれています。 Sビット（ビット3）が一つである場合、本（1）。
Acknowledgment Number Contains the sequence number of the highest numbered GRE packet received by the sending peer for this user session. Present if A bit (Bit 8) is one (1).
謝辞Numberこのユーザーセッションの送信ピアで受信された最も高い番号GREパケットのシーケンス番号が含まれています。本ビット（ビット8）は、一つ（1）の場合。
The payload section contains a PPP data packet without any media specific framing elements.
ペイロード部は、任意のメディアの特定のフレーム要素なしPPPデータパケットを含んでいます。
The sequence numbers involved are per packet sequence numbers. The sequence number for each user session is set to zero at session startup. Each packet sent for a given user session which contains a payload (and has the S bit (Bit 3) set to one) is assigned the next consecutive sequence number for that session.
関連するシーケンス番号は、パケットシーケンス番号ごとです。各ユーザセッションのシーケンス番号は、セッション起動時にゼロに設定されています。ペイロードが含まれている特定のユーザーセッションのために送られた各パケットは、（およびSビット（ビット3）が1に設定されている）、そのセッションの次の連続するシーケンス番号を割り当てられています。
This protocol allows acknowledgments to be carried with the data and makes the overall protocol more efficient, which in turn requires less buffering of packets.
このプロトコルは、確認応答がデータを行うことを可能にし、全体的なプロトコルをより効率的になり、今度はパケットの少ないバッファリングを必要とします。
The sliding window protocol used on the PPTP data path is used for flow control by each side of the data exchange. The enhanced GRE protocol allows packet acknowledgments to be piggybacked on data packets. Acknowledgments can also be sent separately from data packets. Again, the main purpose of the sliding window protocol is for flow control--retransmissions are not performed by the tunnel peers.
PPTPデータパスで使用されるスライディング・ウィンドウ・プロトコルは、データ交換の各側がフロー制御のために使用されます。強化GREプロトコルは、パケットの確認応答がデータパケットに便乗することができます。謝辞は、データパケットとは別に送信することができます。再び、スライディング・ウィンドウ・プロトコルの主な目的は、フロー制御のためのものである - 再送信は、トンネルピアによって実行されません。
Although each side has indicated the maximum size of its receive window, it is recommended that a conservative approach be taken when beginning to transmit data. The initial window size on the transmitter is set to half the maximum size the receiver requested, with a minimum size of one packet. The transmitter stops sending packets when the number of packets awaiting acknowledgment is equal to the current window size. As the receiver successfully digests each window, the window size on the transmitter is bumped up by one packet until the maximum is reached. This method prevents a system from flooding an already congested network because no history has been established.
各側は、その受信ウィンドウの最大サイズを示しているが、データを送信し始めたときに保守的なアプローチが取られることが推奨されます。送信機での初期ウィンドウサイズは受信機が一つのパケットの最小サイズと、要求された半分の最大サイズに設定されています。送信機は、肯定応答を待っているパケットの数が現在のウィンドウサイズに等しい場合、パケットの送信を停止します。受信機が正常に各ウィンドウを消化するように最大に到達するまで、送信機上のウィンドウサイズが1個のパケット分までぶつけています。このメソッドは歴史が確立されていないため、すでに混雑したネットワークをフラッディングからシステムを防ぎます。
When a time-out does occur on a packet, the sender adjusts the size of the transmit window down to one half its value when it failed. Fractions are rounded up, and the minimum window size is one.
タイムアウトは、パケットに発生しない場合、それが失敗した場合、送信者は半分の値まで送信ウィンドウのサイズを調整します。画分を切り上げされ、最小ウィンドウサイズは1です。
With every successful transmission of a window's worth of packets without a time-out, the transmit window size is increased by one packet until it reaches the maximum window size that was sent by the other side when the call was connected. As stated earlier, no retransmission is done on a time-out. After a time-out, the transmission resumes with the window starting at one half the size of the transmit window when the time-out occurred and adjusting upward by one each time the transmit window is filled with packets that are all acknowledged without time-outs.
それはコールが接続されたときに、他の側で送信された最大ウィンドウサイズに到達するまで、タイムアウトなしのパケットのウィンドウの価値のすべての送信に成功すると、送信ウィンドウサイズは1つのパケット増加しています。先に述べたように、再送がタイムアウトに行われません。タイムアウト後、送信がタイムアウトが発生した送信ウィンドウの半分のサイズで開始し、いずれかによって上方送信ウィンドウがすべてタイムアウトせずに認められているパケットで満たされるたびに調整窓を再開する。
When a receiver's window overflows with too many incoming packets, excess packets are thrown away. This situation should not arise if the sliding window procedures are being properly followed by the transmitter and receiver. It is assumed that, on the transmit side, packets are buffered for transmission and are no longer accepted from the packet source when the transmit buffer fills.
受信側のウィンドウは、あまりにも多くの着信パケットとオーバーフローした場合、超過パケットは捨てられます。スライディングウィンドウ手順が正しく送信機と受信機が続いている場合には、このような状況が生じてはなりません。送信側で、パケットが送信のためにバッファされ、送信バッファがいっぱいになると、もはやパケットソースから受け入れていない、と仮定する。
One feature of the PPTP sliding window protocol is that it allows the acknowledgment of multiple packets with a single acknowledgment. All outstanding packets with a sequence number lower or equal to the acknowledgment number are considered acknowledged. Time-out calculations are performed using the time the packet corresponding to the highest sequence number being acknowledged was transmitted.
PPTPスライディング・ウィンドウ・プロトコルの1つの特徴は、単一の肯定応答を有する複数のパケットの確認応答を可能にすることです。考慮されるシーケンス番号が小さいか等しい確認番号を持つすべての未処理パケットを認めました。タイムアウト計算は最高のシーケンス番号に対応するパケットが送信された認知されている時間を利用して実行されます。
Adaptive time-out calculations are only performed when an Acknowledgment is received. When multi-packet acknowledgments are used, the overhead of the adaptive time-out algorithm is reduced. The PAC is not required to transmit multi-packet acknowledgments; it can instead acknowledge each packet individually as it is delivered to the PPP client.
肯定応答が受信されたときに適応タイムアウトの計算にのみ実行されます。マルチパケット肯定応答が使用される場合、適応タイムアウトアルゴリズムのオーバーヘッドが低減されます。 PACは、マルチパケット肯定応答を送信するために必要とされません。それはPPPクライアントに配信されるようではなく、個別に各パケットを確認することができます。
Occasionally packets lose their sequencing across a complicated internetwork. Say, for example that a PNS sends packets 0 to 5 to a PAC. Because of rerouting in the internetwork, packet 4 arrives at the PAC before packet 3. The PAC acknowledges packet 4, and may assume packet 3 is lost. This acknowledgment grants window credit beyond packet 4.
時折、複雑なインターネットワーク全体で彼らのシーケンシングを失うパケット。 PNSは、PACに5にパケット0を送信していること、たとえば、と言います。インターネットに再ルーティングを、パケット4はパケット3の前にPACに到着したのでPACは、パケット4を認識し、パケット3が失われたと仮定して。パケット4を超えたこの承認助成ウィンドウクレジット。
When the PAC does receive packet 3, it MUST not attempt to transmit it to the corresponding PPP client. To do so could cause problems, as proper PPP protocol operation is premised upon receiving packets in sequence. PPP does properly deal with the loss of packets, but not with reordering so out of sequence packets between the PNS and PAC MUST be silently discarded, or they may be reordered by the receiver. When packet 5 comes in, it is acknowledged by the PAC since it has a higher sequence number than 4, which was the last highest packet acknowledged by the PAC. Packets with duplicate sequence numbers should never occur since the PAC and PNS never retransmit GRE packets. A robust implementation will silently discard duplicate GRE packets, should it receive any.
PACは、パケット3を受信した場合、それは、対応するPPPクライアントに送信しようとしないしなければなりません。適切なPPPプロトコルの動作が連続してパケットを受信したときに前提としているとして、問題を引き起こす可能性があり、そうするには。 PPPは、適切にパケットの損失に対処しないが、リオーダリングとPNSとPACの間の配列のパケットのうちには、黙って破棄しなければならないではない、またはそれらは受信機によって並べ替えられてもよいです。パケット5が入ってくると、PACによって確認最後に最高のパケットだった、それは4よりも高いシーケンス番号を持っているので、PACによって認められています。 PACとPNSは、GREパケットを再送したことがないので、重複したシーケンス番号を持つパケットは発生しません。堅牢な実装は静かにそれがいずれかを受け取る必要があり、重複したGREパケットを破棄します。
PPTP uses sliding windows and time-outs to provide both user session flow-control across the internetwork and to perform efficient data buffering to keep the PAC-PNS data channels full without causing receive buffer overflow. PPTP requires that a time-out be used to recover from dropped data or acknowledgment packets. The exact implementation of the time-out is vendor-specific. It is suggested that an adaptive time-out be implemented with backoff for congestion control. The time-out mechanism proposed here has the following properties:
PPTPは、インターネットを横切ってユーザセッションフロー制御の両方を提供するために、バッファオーバーフローを受信引き起こすことなく、完全なPAC-PNSデータチャネルを維持するために効率的なデータバッファリングを実行するためにスライディングウインドウおよびタイムアウトを使用します。 PPTPは、タイムアウトがドロップされたデータや受信確認パケットから回復するために使用されている必要があります。タイム・アウトの正確な実装は、ベンダー固有です。適応型タイムアウトが輻輳制御のためのバックオフで実装することが示唆されました。ここで提案タイムアウトメカニズムは、次のプロパティがあります。
Independent time-outs for each session. A device (PAC or PNS) will have to maintain and calculate time-outs for every active session.
各セッションのための独立したタイムアウト。デバイス（PAC又はPNS）を維持し、すべてのアクティブなセッションのためのタイムアウトを計算しなければなりません。
An administrator-adjustable maximum time-out, MaxTimeOut, unique to each device.
管理者が調整可能な最大タイムアウト、MAXTIMEOUT、各デバイスに固有。
An adaptive time-out mechanism that compensates for changing throughput. To reduce packet processing overhead, vendors may choose not to recompute the adaptive time-out for every received acknowledgment. The result of this overhead reduction is that the time-out will not respond as quickly to rapid network changes.
スループットを変更するに補償適応タイムアウトメカニズム。パケット処理のオーバーヘッドを削減するために、ベンダーがすべての受信確認のための適応タイムアウトを再計算しないこともできます。このオーバーヘッド削減の結果、タイムアウトが急速なネットワークの変化に早く応答しないことです。
Timer backoff on time-out to reduce congestion. The backed-off timer value is limited by the configurable maximum time-out value. Timer backoff is done every time an acknowledgment time-out occurs.
輻輳を軽減するために、タイムアウトのタイマーバックオフ。バックオフタイマー値が設定可能な最大タイムアウト値によって制限されています。タイマーバックオフは確認タイムアウトが発生するたびに実行されます。
In general, this mechanism has the desirable behavior of quickly backing off upon a time-out and of slowly decreasing the time-out value as packets are delivered without time-outs.
一般に、このメカニズムはすぐタイムアウト時にパケットがタイムアウトせずに送達されるようにゆっくりとタイムアウト値を減少させるバックオフの望ましい挙動を有します。
Some definitions:
いくつかの定義：
Packet Processing Delay (PPD) is the amount of time required for each side to process the maximum amount of data buffered in their receive packet sliding window. The PPD is the value exchanged between the PAC and PNS when a call is established. For the PNS, this number should be small. For a PAC making modem connections, this number could be significant.
パケット処理遅延（PPD）は、その受信パケットスライディングウィンドウにバッファリングされたデータの最大量を処理するためにそれぞれの側に必要な時間の量です。 PPDは、呼が確立されPACとPNSの間で交換された値です。 PNSの場合、この数は小さいはずです。 PAC作りモデム接続の場合、この数は重要である可能性があります。
Sample is the actual amount of time incurred receiving an acknowledgment for a packet. The Sample is measured, not calculated.
サンプルは、パケットのための承認を受けて被った実際の時間です。サンプルは計算されていない、測定されます。
Round-Trip Time (RTT) is the estimated round-trip time for an Acknowledgment to be received for a given transmitted packet. When the network link is a local network, this delay will be minimal (if not zero). When the network link is the Internet, this delay could be substantial and vary widely. RTT is adaptive: it will adjust to include the PPD and whatever shifting network delays contribute to the time between a packet being transmitted and receiving its acknowledgment.
ラウンドトリップ時間（RTT）が謝辞が与えられた送信パケットのために受信されるために、推定往復時間です。ネットワークリンクはローカルネットワークである場合（ゼロでない場合）、この遅延は最小になります。ネットワークリンクがインターネットである場合には、この遅延はかなりのものと大きく異なる可能性があります。 RTTは、適応である：それはどんなシフトネットワーク遅延がパケットを送信し、その承認を受けされている間の時間に貢献PPDとが含まれるように調整されます。
Adaptive Time-Out (ATO) is the time that must elapse before an acknowledgment is considered lost. After a time-out, the sliding window is partially closed and the ATO is backed off.
アダプティブタイムアウト（ATO）は、肯定応答が失われたと見なされる前に経過しなければならない時間です。タイムアウト後、スライディングウィンドウが部分的に閉じられ、ATOが後退されます。
The Packet Processing Delay (PPD) parameter is a 16-bit word exchanged during the Call Control phase that represents tenths of a second (64 means 6.4 seconds). The protocol only specifies that the parameter is exchanged, it does not specify how it is calculated. The way values for PPD are calculated is implementation-dependent and need not be variable (static time-outs are allowed). The PPD must be exchanged in the call connect sequences, even if it remains constant in an implementation. One possible way to calculate the PPD is:
パケット処理遅延（PPD）パラメータは、10分の1秒を表す呼制御フェーズ中に交換する16ビット・ワードである（64は、6.4秒を意味します）。プロトコルは、唯一のパラメータが交換され、それがどのように計算されるかを指定していないことを指定します。 PPDの値が計算される方法は実装依存であり、（静的タイムアウトが許可されている）は、可変である必要はありません。 PPDは、通話中に交換しなければならないが、実装に一定のまま場合でも、シーケンスを接続してください。 PPDを計算するための1つの可能な方法は以下のとおりです。
PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate PPD = PPD' + PACFudge
PPD '=（（PPP_MAX_DATA_MTU - ヘッダ）* WindowSize * 8）/ ConnectRate PPD = PPD' + PACFudge
Header is the total size of the IP and GRE headers, which is 36. The MTU is the overall MTU for the internetwork link between the PAC and PNS. WindowSize represents the number of packets in the sliding window, and is implementation-dependent. The latency of the internetwork could be used to pick a window size sufficient to keep the current session's pipe full. The constant 8 converts octets to bits (assuming ConnectRate is in bits per second). If ConnectRate is in bytes per second, omit the 8. PACFudge is not required but can be used to take overall processing overhead of the PAC into account.
ヘッダは36 MTUであるIPとGREヘッダの合計サイズは、PACとPNSとの間のインターネットリンクの全体的なMTUです。 WindowSizeは、スライディングウィンドウ内のパケットの数を表し、実装依存です。インターネットの待ち時間は、完全な現在のセッションのパイプを維持するのに十分なウィンドウサイズを選択するために使用することができます。定数8（ConnectRate毎秒ビットであると仮定して）ビットのオクテットに変換します。 ConnectRateは、秒あたりのバイト数である場合、8 PACFudgeが必要とされず、アカウントにPACの全体的な処理オーバーヘッドを取るために使用することができる省きます。
The value of PPD is used to seed the adaptive algorithm with the initial RTT[n-1] value.
PPDの値は、初期RTT [N-1]の値と適応アルゴリズムをシードするために使用されます。
We still must decide how much time to allow for acknowledgments to return. If the time-out is set too high, we may wait an unnecessarily long time for dropped packets. If the time-out is too short, we may time out just before the acknowledgment arrives. The acknowledgment time-out should also be reasonable and responsive to changing network conditions.
我々はまだ確認応答を返すことを可能にするためにどのくらいの時間を決定する必要があります。タイムアウトの設定が高すぎる場合は、ドロップされたパケットのために不必要に長い時間を待つことがあります。タイムアウトが短すぎると、私たちは確認応答が到着する直前にタイムアウトする場合があります。確認応答のタイムアウトも合理的と変化するネットワークの状態に応答する必要があります。
The suggested adaptive algorithm detailed below is based on the TCP 1989 implementation and is explained in [11]. 'n' means this iteration of the calculation, and 'n-1' refers to values from the last calculation.
以下に詳細を示唆適応アルゴリズムは、TCP 1989の実装に基づいており、[11]で説明されています。 「N」の計算のこの反復を意味し、「N-1」の最後の計算からの値を指します。
DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n]) ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut))
DIFF [N] = SAMPLE [N] - RTT [N-1] DEV [N] = DEV [N-1] +（ベータ*（| DIFF [N] | - DEV [N-1]））RTT [N ] = RTT [N-1] +（アルファ* DIFF [N]）ATO [N] = MAX（MinTimeOut、MIN（RTT [N] +（カイ*のDEV [N]）、MAXTIMEOUT））
DIFF represents the error between the last estimated round-trip time and the measured time. DIFF is calculated on each iteration.
DIFFは、最後の推定ラウンドトリップ時間と測定時間との誤差を表しています。 DIFFは、各反復で計算されます。
DEV is the estimated mean deviation. This approximates the standard deviation. DEV is calculated on each iteration and stored for use in the next iteration. Initially, it is set to 0.
DEVは、推定平均偏差です。これは、標準偏差を近似します。 DEVは、各反復で計算され、次の反復で使用するために格納されます。最初は、それが0に設定されています。
RTT is the estimated round-trip time of an average packet. RTT is ycalculated on each iteration and stored for use in the next iteration. Initially, it is set to PPD.
RTTは平均パケットの推定往復時間です。 RTTは、各反復でycalculatedと次の反復で使用するために格納されます。最初は、それはPPDに設定されています。
ATO is the adaptive time-out for the next transmitted packet. ATO is calculated on each iteration. Its value is limited, by the MIN function, to be a maximum of the configured MaxTimeOut value.
ATOは、次の送信パケットのための適応タイムアウトです。 ATOは、各反復で計算されます。その値は、MIN関数によって、構成MAXTIMEOUT値の最大値であると、制限されています。
Alpha is the gain for the average and is typically 1/8 (0.125).
アルファは、平均のゲインであり、典型的に1/8（0.125）です。
Beta is the gain for the deviation and is typically 1/4 (0.250).
ベータ偏差のゲインであり、典型的に1/4（0.250）です。
Chi is the gain for the time-out and is typically set to 4.
カイは、タイムアウトのためのゲインであり、通常は4に設定されています。
To eliminate division operations for fractional gain elements, the entire set of equations can be scaled. With the suggested gain constants, they should be scaled by 8 to eliminate all division. To simplify calculations, all gain values are kept to powers of two so that shift operations can be used in place of multiplication or division.
フラクショナル利得要素の除算を排除するために、方程式のセット全体をスケーリングすることができます。提案ゲイン定数を使用すると、彼らはすべての部門を排除するために8でスケーリングする必要があります。計算を簡単にするために、すべてのゲイン値は2の累乗に保持されるように、シフト操作が乗算または除算の代わりに使用することができます。
This section describes how the calculation of ATO is modified in the case where a time-out does occur. When a time-out occurs, the time-out value should be adjusted rapidly upward. Although the GRE packets are not retransmitted when a time-out occurs, the time-out should be adjusted up toward a maximum limit. To compensate for shifting internetwork time delays, a strategy must be employed to increase the time-out when it expires (notice that in addition to increasing the time-out, we are also shrinking the size of the window as described in the next section). For an interval in which a time-out occurs, the new ATO is calculated as:
このセクションでは、ATOの計算は、タイムアウトが発生した場合に変更される方法を記載しています。タイムアウトが発生すると、タイムアウト値が急激に上方に調整されるべきです。タイムアウトが発生したときにGREパケットが再送されないが、タイムアウトが上限に向かって調整されるべきです。インターネットの時間遅延をシフトを補償するために、戦略は、タイムアウトが期限切れに増加させるために使用されなければならない（次のセクションで説明したようにタイムアウトを増加させることに加えて、我々はまた、ウィンドウのサイズを縮小していることに注意してください） 。タイムアウトが発生する間隔のために、新しいATOは以下のように計算されます。
RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut))
RTT [n]はRTT [N-1] DEV [n]がDEV [N-1] ATO [N] = MAX（MinTimeOut、MIN（RTT [N] +（カイ* DEV [N]）、MAXTIMEOUTを= *デルタ= ））
In this calculation of ATO, only the two values that both contribute to ATO and are stored for the next iteration are calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is not carried forward and is not used in this scenario. A value of 2 for Delta, the time-out gain factor for RTT, is suggested.
ATOのこの計算では、両方がATOに寄与し、次の反復のために保存されているだけ2つの値が計算されます。 RTTは、デルタによってスケーリングされ、DEVは、未修飾です。 DIFFは引き継がれず、このシナリオで使用されていません。デルタRTTのタイムアウト利得係数2の値は、提案されています。
The security of user data passed over the tunneled PPP connection is addressed by PPP, as is authentication of the PPP peers.
PPPピアの認証があるとしてトンネル化PPP接続を介して渡されたユーザデータのセキュリティは、PPPによって対処されます。
Because the PPTP control channel messages are neither authenticated nor integrity protected, it might be possible for an attacker to hijack the underlying TCP connection. It is also possible to manufacture false control channel messages and alter genuine messages in transit without detection.
PPTP制御チャネルメッセージはどちらも認証されていないにも整合性が保護されているため、攻撃者は、基礎となるTCP接続をハイジャックすることが可能かもしれません。偽の制御チャネルメッセージを製造して検出することなく、輸送中に本物のメッセージを変更することも可能です。
The GRE packets forming the tunnel itself are not cryptographically protected. Because the PPP negotiations are carried out over the tunnel, it may be possible for an attacker to eavesdrop on and modify those negotiations.
トンネル自体を形成するGREパケットは暗号で保護されていません。 PPPネゴシエーションは、トンネルを介して行われるため、攻撃者が上の盗聴およびそれらの交渉を変更することが可能であってもよいです。
Unless the PPP payload data is cryptographically protected, it can be captured and read or modified.
PPPペイロードデータが暗号で保護されていない限り、それは捕捉され、読み取りまたは変更することができます。
Kory Hamzeh Ascend Communications 1275 Harbor Bay Parkway Alameda, CA 94502
Kory Hamzehアセンドコミュニケーションズ1275ハーバー・ベイ・パークウェイアラメダ、CA 94502
EMail: kory@ascend.com
メールアドレス：kory@ascend.com
Gurdeep Singh Pall Microsoft Corporation Redmond, WA
ガーディープ・シンポール、米国Microsoft Corporationレドモンド、WA
EMail: gurdeep@microsoft.com
メールアドレス：gurdeep@microsoft.com
William Verthein U.S. Robotics/3Com
ウィリアムVerthein米国ロボティクス/ 3Com社
Jeff Taarud Copper Mountain Networks
ジェフTaarudカッパーマウンテンネットワーク
W. Andrew Little ECI Telematics
W.アンドリュー・リトルECIテレマティクス
Glen Zorn Microsoft Corporation Redmond, WA
グレンソーン、米国Microsoft Corporationレドモンド、WA
EMail: glennz@microsoft.com
メールアドレス：glennz@microsoft.com
[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[1]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 1701、1994年10月。
[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
[2]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "IPv4ネットワーク上総称ルーティングカプセル化（GRE）"、RFC 1702、1994年10月。
[3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.
[3]ロイド、B.とW.シンプソン、 "PPP認証プロトコル"、RFC 1334、1992年10月。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[4]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.
[5]ポステル、J.、 "ユーザデータプロトコル"、STD 6、RFC 768、1980年8月。
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[6]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月を見る：http://www.iana.org/numbers.html
[7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[7]シンプソン、W.、エディタ、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[8] Ethertype for PPP, Reserved with Xerox Corporation.
[8] PPP、ゼロックス社と予約のためのEthertypeを。
[9] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[9]シンプソン、W.、 "PPPチャレンジハンドシェイク認証プロトコル（CHAP）"、RFC 1994、1996年8月。
[10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[10]ブルンク、L.及びJ Vollbrecht、 "PPP拡張認証プロトコル（EAP）"、RFC 2284、1998年3月。
[11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-Wesley, 1994.
[11]スティーブンス、R.、 "TCP / IPイラスト、第1巻"、P。 300、アディソン・ウェズリー、1994。
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[12]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。