[要約] RFC 2637は、Point-to-Point Tunneling Protocol（PPTP）に関する仕様を定義しています。PPTPは、異なるネットワーク間でセキュアな通信トンネルを確立するためのプロトコルです。このRFCの目的は、PPTPの機能と動作を明確にすることです。
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)
ポイントツーポイントトンネルプロトコル（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.
Copyright（c）The Internet Society（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.
このドキュメントは、Point to Pointプロトコル（PPP）をIPネットワークを介してトンネル化できるプロトコルを指定します。PPTPは、PPPプロトコルの変更を指定するのではなく、PPPを運ぶための新しい車両について説明しています。クライアントサーバーアーキテクチャは、現在のネットワークアクセスサーバー（NAS）に存在する機能を切り離し、仮想プライベートネットワーク（VPN）をサポートするために定義されています。PPTPネットワークサーバー（PNS）は、汎用オペレーティングシステムで実行されると想定されており、PPTP Access Concencorator（PAC）と呼ばれるクライアントは、ダイヤルアクセスプラットフォームで動作します。PPTPは、サーバーがPSTNまたはISDNから発信されたダイヤルイン回路スイッチドコールのアクセスを制御するか、アウトバウンド回路スイッチ付き接続を開始できるコールコントロールおよび管理プロトコルを指定します。PPTPは、強化されたGRE（汎用ルーティングカプセル化）メカニズムを使用して、PPPパケットを運ぶためにフローおよび渋滞制御されたカプセル化されたデータグラムサービスを提供します。
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].
このドキュメントでは、キーワードは「可能性があります」、「必要はありません」、「オプション」、「推奨」、「は」、「必要」、および「すべきではありません」は、[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.
1) PSTNまたはISDNへの物理的なネイティブインターフェースと外部モデムまたは端子アダプターの制御。
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は、Telcoアナログまたはデジタル回路に直接インターフェイスするか、外部モデムまたは端子アダプターを介して接続できます。回路で切り替えられた接続の制御は、モデム制御または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].
3) PPP認証プロトコルへの参加[3,9,10]。
4) Channel aggregation and bundle management for PPP Multilink Protocol.
4) PPPマルチリンクプロトコルのチャネル集約とバンドル管理。
5) Logical termination of various PPP network control protocols (NCP).
5) さまざまなPPPネットワーク制御プロトコル（NCP）の論理終了。
6) Multiprotocol routing and bridging between NAS interfaces.
6) NASインターフェイス間のマルチプロトコルルーティングとブリッジング。
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、および6に責任があります。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クライアントソフトウェアは、Tunneled 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セッションは同じ2つのマシン間で実行され、発信者はPNSとして機能します。
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は、多くのPACSに関連して、地理的に多様なサイトの多数のサイトからトラフィックを集中させる場合があります。
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は、拡張バージョンのGREを使用してユーザーPPPパケットを運びます。これらの拡張により、PACとPNSの間でユーザーデータを運ぶために使用されるトンネルで低レベルの混雑とフロー制御を提供することができます。このメカニズムにより、トンネルで利用可能な帯域幅を効率的に使用することができ、不必要な再送信とバッファオーバーランを回避できます。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つの端子エンドポイント間の接続または試行された接続 - たとえば、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.
PPP操作が可能な1つ以上のPSTNまたはISDNラインに接続され、PPTPプロトコルを処理できるデバイス。PACは、トラフィックを1つ以上の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に接続されている各ユーザーの状態を維持します。セッションは、ダイヤルユーザーとPNSの間でエンドツーエンドのPPP接続が試行されるときに作成されます。セッションに関連するデータグラムは、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.
PPTPには2つの並列コンポーネントがあります。1）TCPで動作する各PAC-PNSペア間の制御接続と2）ユーザーセッションのためにカプセル化されたPPPパケットを輸送するために使用される同じPAC-PNSペア間で動作するIPトンネル。ペア。
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.
PACとPNSの間でPPPトンネリングが発生する前に、それらの間に制御接続を確立する必要があります。制御接続は、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は、Start-Connection-Requestおよび-Replyメッセージを使用して制御接続を確立します。これらのメッセージは、PACおよびPNSの基本的な動作能力に関する情報を交換するためにも使用されます。制御接続が確立されると、PACまたはPNSは、アウトバウンドコールを要求したり、インバウンドリクエストに応答したりすることでセッションを開始する場合があります。コントロール接続は、セットリンクINFOメッセージを使用して、個々のユーザーセッションの操作特性の変更を通知する場合があります。個々のセッションは、制御接続メッセージを介して、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.
制御接続に関するWan-error-notifyメッセージ。
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 [6]へのTCP接続を開始することにより確立されます。ソースポートは、未使用のポート番号に割り当てられます。
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:
2つの制御接続メッセージタイプは、PPTPメッセージタイプフィールドで示されています。
1 - Control Message 2 - Management Message
1-コントロールメッセージ2-管理メッセージ
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
(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
(Error Reporting)
（エラー報告）
WAN-Error-Notify 14
wan-error-notify 14
(PPP Session Control)
（PPPセッションコントロール）
Set-Link-Info 15
Set-Link-INFO 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.
Start-Control-Connection-Requestおよび-Replyメッセージは、制御接続プロトコルのバージョンを決定します。これらのメッセージに掲載されているバージョン番号フィールドは、高オクテットのバージョン番号と低オクテットのリビジョン番号で構成されています。バージョンの処理については、セクション2で説明されています。バージョン番号フィールドの現在の値は、バージョン1の場合は0x0100です。
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は1532オクテットで、IPおよびGREヘッダーは含まれません。
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.
Start-Control-Connection-Requestは、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.
Start-Control-Connection-Requestのコントロールメッセージタイプ1。
Reserved0 This field MUST be 0.
予約済み0このフィールドは0でなければなりません。
Protocol Version The version of the PPTP protocol that the sender wishes to use.
プロトコルバージョン送信者が使用したいPPTPプロトコルのバージョン。
Reserved1 This field MUST be 0.
予約1このフィールドは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によって発行された開始コントロール接続要求では、この値は0に設定する必要があります。PACで無視する必要があります。
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.
ファームウェアリビジョンこのフィールドには、PACが発行した場合、発行中のPACのファームウェアリビジョン番号、またはPNSが発行した場合は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名を含む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のタイプを説明するベンダー固有の文字列を含む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.
Start-Control-Connection-Replyは、受信したStart-Connol-Connection-Requestメッセージに返信された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.
Start-Control-Connection-Replyのコントロールメッセージタイプ2。
Reserved0 This field MUST be 0.
予約済み0このフィールドは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:
結果コードは、コマンドチャネルの確立の試みの結果を示します。現在の有効な結果コード値は次のとおりです。
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.
エラーコード「一般的なエラー」が存在しない限り、このフィールドは0に設定されています。この場合、結果コードは2に設定され、このフィールドはセクション2.2で指定されている一般的なエラー条件に対応する値に設定されます。
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名を含む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のタイプを説明するベンダー固有の文字列を含む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.
Stop-Control-Connection-Requestは、PAC-PNS制御接続の1人のピアによって送信された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.
STOP-Control-Connection-Requestのコントロールメッセージタイプ3。
Reserved0 This field MUST be 0.
予約済み0このフィールドは0でなければなりません。
Reason Indicates the reason for the control connection being closed. Current valid Reason values are:
理由は、制御接続が閉じられている理由を示します。現在の正当な理由値は次のとおりです。
1 (None) - General request to clear control connection
1（なし） - 制御接続をクリアするための一般的な要求
2 (Stop-Protocol) - Can't support peer's version of the protocol
2（Stop -Protocol）-Peerのバージョンのプロトコルをサポートできません
3 (Stop-Local-Shutdown) - Requester is being shut down
3（Stop-Local-Shutdown） - リクエスターがシャットダウンされています
Reserved1, Reserved2 These fields MUST be 0.
予約1、予約2これらのフィールドは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.
STOP-Control-Connection-Replyは、PAC-PNSコントロール接続の1人が他のピアからストップコントロール接続要求を受信したときに送信される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.
STOP-Control-Connection-Replyのコントロールメッセージタイプ4。
Reserved0 This field MUST be 0.
予約済み0このフィールドは0でなければなりません。
Result Code Indicates the result of the attempt to close the control connection. Current valid Result Code values are:
結果コードは、制御接続を閉じようとする試みの結果を示します。現在の有効な結果コード値は次のとおりです。
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.
エラーコード「一般的なエラー」が存在しない限り、このフィールドは0に設定されています。この場合、結果コードは2に設定され、このフィールドはセクション2.2で指定されている一般的なエラー条件に対応する値に設定されます。
Reserved1 This field MUST be 0.
予約1このフィールドは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.
Echo-Requestは、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.
予約済み0このフィールドは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.
Echo Replyは、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.
Echo-Replyのコントロールメッセージタイプ6。
Reserved0 This field MUST be 0.
予約済み0このフィールドは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:
結果コードは、Echo-Requestの受領の結果を示します。現在の有効な結果コード値は次のとおりです。
1 (OK) - The Echo-Reply is valid
1（OK） - エコーリピュリーは有効です
2 (General Error) - Echo-Request not accepted for the reason indicated in Error Code
2（一般的なエラー）-Echo -Requestは、エラーコードに示されている理由で受け入れられていません
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.
エラーコード「一般的なエラー」条件が存在しない限り、このフィールドは0に設定されています。この場合、結果コードが2に設定され、このフィールドはセクション2.2で指定されている一般的なエラー条件に対応する値に設定されます。
Reserved1 This field MUST be 0.
予約1このフィールドは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.
発信-Call-Requestは、PACにPNSからPACに送信されたPPTP制御メッセージであり、PACからのアウトバウンドコールが確立されることを示します。このリクエストは、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.
発信-Call-Requestのコントロールメッセージタイプ7。
Reserved0 This field MUST be 0.
予約済み0このフィールドは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に呼びます。これは、このセッションに関係するPNSとPACの間のトンネル上に送信される多重データとDemultiplexデータに使用されます。
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の両方が同じコールシリアル番号を特定のセッションに関連付けます。IPアドレスと通話シリアル番号の組み合わせは一意でなければなりません。
Minimum BPS The lowest acceptable line speed (in bits/second) for this session.
最小BPSこのセッションの最低容認可能なライン速度（ビット/秒）。
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
1-アナログチャネルに配置する呼び出し
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フレーミングのタイプを示すフレーミングタイプA値。
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.
予約1このフィールドは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.
SubAddress追加のダイヤル情報を指定するために使用される64 Octetフィールド。サブアドレスの長さが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.
発信-Call-Replyは、受信した発信コールリクエストメッセージに応じて、PACからPNSに送信された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.
予約済み0このフィールドは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に呼びます。これは、このセッションに関係するPNSとPACの間のトンネル上に送信される多重データとDemultiplexデータに使用されます。
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このフィールドは、対応する発信コールリクエストメッセージのコールIDフィールドで受信された値に設定されます。これは、発信コールの繰り返しと発行された発信コールリケストを一致させるためにPNSによって使用されます。また、GREヘッダーでMUX/デンキングのために送信される値として使用されます。
Result Code This value indicates the result of the Outgoing-Call-Request attempt. Currently valid values are:
結果コードこの値は、発信コールリクエストの試みの結果を示します。現在有効な値は次のとおりです。
1 (Connected) - Call established with no errors
1（接続） - エラーなしで確立されたコール
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.
エラーコード「一般的なエラー」条件が存在しない限り、このフィールドは0に設定されています。この場合、結果コードが2に設定され、このフィールドはセクション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に送信されたPPTP制御メッセージであり、PACからインバウンドコールが確立されることを示します。このリクエストは、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.
予約済み0このフィールドは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に呼びます。これは、このセッションに関係するPNSとPACの間のトンネル上に送信される多重データとDemultiplexデータに使用されます。
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の両方が同じコールシリアル番号を特定のセッションに関連付けます。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.
SubAddress追加のダイヤル情報を指定するために使用される64 Octetフィールド。サブアドレスの長さが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.
受信コールの繰り返しは、受信した受信コール要求メッセージに応じて、PNSからPACに送信された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方向の握手の2番目です。それは、通話に応答するべきかどうかを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.
予約済み0このフィールドは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に呼びます。これは、このセッションに関係するPNSとPACの間のトンネル上に送信される多重データとDemultiplexデータに使用されます。
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:
結果コードこの値は、着信後のリクエストの試みの結果を示します。現在の有効な結果コード値は次のとおりです。
1 (Connect) - The PAC should answer the incoming call
1（connect） - PACは着信コールに答える必要があります
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.
エラーコード「一般的なエラー」条件が存在しない限り、このフィールドは0に設定されています。この場合、結果コードが2に設定され、このフィールドはセクション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.
予約1このフィールドは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.
着信コール接続のメッセージは、受信した受信コール復帰に応じてPACからPNSに送信された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が使用する3方向の握手の3番目です。これは、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.
予約済み0このフィールドは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フレーミングのタイプを示すフレーミングタイプA値。
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.
Call-Clear-Requestは、PNSからPACに送信されたPPTPコントロールメッセージであり、特定の呼び出しが切断されることを示しています。クリアされる呼び出しは、どの州でも着信または発信のいずれかのコールである可能性があります。PACは、Call-Disconnect-Notifyメッセージでこのメッセージに応答します。
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.
予約済み0このフィールドは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を呼び出します。この値は、後者がコール設定中に呼び出しを中止する必要がある場合、後者がPNSに対して知られていない可能性があるため、ピアの呼び出しIDの代わりに使用されます。
Reserved1 This field MUST be 0.
予約1このフィールドは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.
Call-Disconnect-Notifyメッセージは、PACからPNSに送信された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.
Call-Disconnect-notifyのコントロールメッセージタイプ13。
Reserved0 This field MUST be 0.
予約済み0このフィールドは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.
CALL IDこの呼び出しにPACによって割り当てられたコールIDの値。この値は、後者がコール設定中に呼び出しを中止する必要がある場合、後者がPNSに対して知られていない可能性があるため、ピアの呼び出しIDの代わりに使用されます。
Result Code This value indicates the reason for the disconnect. Current valid Result Code values are:
結果コードこの値は、切断の理由を示します。現在の有効な結果コード値は次のとおりです。
1 (Lost Carrier) - Call disconnected due to loss of carrier
1（失われたキャリア） - キャリアの損失のために切断されたコール
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（リクエスト） - CALLE-CELEL-REQUESTを受信したために切断されたコール
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.
エラーコード「一般的なエラー」条件が存在しない限り、このフィールドは0に設定されています。この場合、結果コードは2に設定され、このフィールドはセクション2.2で指定されている一般的なエラー条件に対応する値に設定されます。
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-ERROR-NOTIFYメッセージは、PACからPNSに送信されたPPTP制御メッセージであり、WANエラー条件（PPPをサポートするインターフェイスで発生する条件）を示します。このメッセージのカウンターは累積的です。このメッセージは、エラーが発生したときにのみ送信され、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-error-notifyのコントロールメッセージタイプ14。
Reserved0 This field MUST be 0.
予約済み0このフィールドは0でなければなりません。
Peer's Call ID Th Call ID assigned by the PNS to this call.
この呼び出しにPNSによって割り当てられたピアの呼び出しID THコールID。
CRC Errors Number of PPP frames received with CRC errors since session was established.
CRCエラーセッションが確立されてからCRCエラーで受信したPPPフレームの数。
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.
Set-Link-INFOメッセージは、PNSからPACに送信されたPPTPコントロールメッセージで、PPP関連オプションを設定します。これらのオプションは、コールの存続期間中いつでも変更できるため、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.
Set-Link-INFOのコントロールメッセージタイプ15。
Reserved0 This field MUST be 0.
予約済み0このフィールドは0でなければなりません。
Peer's Call ID The value of the Call ID assigned by the PAC to this call.
PACによってこの呼び出しに割り当てられたコールIDの値をピアの呼び出しID。
Reserved1 This field MUST be 0.
予約1このフィールドは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（悪い形） - 長さが間違っているか、魔法のクッキー値が正しくない
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-Error） - 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接続が開いている場合、OriginatorはSend Start-Control-Connection-Requestを送信し、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.
WAIT_CTL_REPLY Originatorは、同じピアから別のTCP接続が要求されているかどうかを確認し、もしそうなら、セクション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.
開始コントロール接続の繰り返しを受信すると、互換性のあるバージョンについて調べられます。返信のバージョンがリクエストで送信されたバージョンよりも低い場合、サポートされている場合、古い（低い）バージョンを使用する必要があります。返信のバージョンが早くてサポートされている場合、オリジネーターは確立された状態に移動します。バージョンが早くサポートされていない場合は、STOP-Control-Connection-Requestをピアに送信し、Originatorが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.
確立された確立された接続は、ローカルな状態またはストップコントロール接続の再クエストの受領によって終了する場合があります。ローカル終了が発生した場合、オリジネーターはストップコントロール接続リクエストを送信し、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 STOP-CONTOL-CONNECTION-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.
コントロール接続のレシーバーは、ポート1723でTCPオープン試行を待機します。オープンTCP接続が通知されれば、PPTPメッセージを受信する準備をする必要があります。スタートコントロール接続のリクエストを受信すると、バージョンフィールドを調べる必要があります。バージョンがレシーバーのバージョンよりも早く、以前のバージョンがレシーバーによってサポートできる場合、受信者はStart-Control-Connection-Replyを送信する必要があります。バージョンがレシーバーのバージョンよりも早く、バージョンをサポートできない場合、受信者はStart-Connection-Replyメッセージを送信し、TCP接続を閉じてアイドル状態のままです。受信者のバージョンがピアのバージョンと同じである場合、受信者はレシーバーのバージョンとStart-Control-Connection-Replyを送信し、確立された状態を入力する必要があります。
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 STOP-CONTOL-CONNECTION-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には、それらの間に1つの制御接続のみが必要です。ただし、PNSとPACが同時に互いに制御接続を確立しようとすることが可能です。1つのTCP接続で開始コントロール接続リクエストが受信され、別のスタートコントロール接続-Requestが同じピアへの別の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.
開始レースの「勝者」は、IPアドレスが高いピアです（32ビットの符号なしの値と比較され、ネットワーク数はより重要です）。たとえば、ピア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. コントロール接続が確立された状態にない場合（つまり、開始コントロール接続再クエストとスタートコントロール接続対価が交換されていない場合）-Control-Connection-RequestまたはStart-Control-Connection-Replyメッセージ。
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秒間コントロールメッセージを受信していない場合、エコーレクエストメッセージを送信する必要があります。Echo-Requestメッセージ送信の60秒後にEchoReplyが受信されない場合、コントロール接続を閉じる必要があります。
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の間の輸送遅延は、1秒を超えてはなりません。コールと接続の状態の数字は、タイマーによって引き起こされる例外を指定していません。暗黙の仮定は、TCPベースの制御接続がKeep-Alivesで検証されているため、コール制御メッセージの厳格なタイマーを維持する必要性が少ないということです。
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の間のトンネルにとって一意でなければなりません。他のピアへのトンネルは同じコール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.
関連する電話回線が鳴ると、着信コールリクエストメッセージが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が着信コールレクエストを送信すると、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
- Bearerサービスは許可またはサポートされていません
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が発信コールの繰り返しを受け取ると、呼び出しの当事者が切れていないと仮定して、コールを接続しようとします。PACからPNSへの最後のコール接続メッセージは、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が通話のクリアを希望する場合、Call-Clear-Requestメッセージを送信してから、Call-Disconnect-Notifyを待ちます。
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.
IDLE The PACは、電話会社インターフェイスの1つで着信コールを検出します。通常、これはアナログラインが鳴っているか、ISDN TEが着信Q.931セットアップメッセージを検出したことを意味します。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
Telco接続に関するイベント。PACは、call-disconnect-notifyメッセージを送信します
Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect-Notify message
Call-Clear-Requestの受領。PACは、call-disconnect-notifyメッセージを送信します
A local reason. The PAC sends a Call-Disconnect-Notify message.
地元の理由。PACは、call-disconnect-notifyメッセージを送信します。
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.
IDLE入ってくるコールリクエストメッセージが受信されます。リクエストが受け入れられない場合、着信コールリプリーが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は着信コールConnectメッセージをPNSに送信し、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からのCall-Disconnect-Notifyメッセージを受信するか、Call-Clear-Requestを送信することによって終了します。Call-Clear-Requestが送信されると、セッションはWait_Disconnect Stateに入ります。
wait_disconnect Once a Call-Disconnect-Notify is received the session moves back to the idle state.
wait_disconnect call-disconnect-notifyが受信されると、セッションがアイドル状態に戻ります。
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に指示するように指示するようにPACに指示します。発信コールのメッセージは2つしかありません：発信-Call-Requestと発信コールリプリー。PNSは、ダイヤルされたパーティーの電話番号とサブアドレス、およびスピードとウィンドウのパラメーターを指定する発信コールリケストを送信します。PACは、PACがそれを決定した場合、発信コールリクエストメッセージを使用して発信コールリクエストメッセージに応答する必要があります。
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.
アイドルが発信コールリクエストを受け取りました。これがエラーで受信された場合は、エラー条件セットを使用して発信コールの繰り返しで応答します。それ以外の場合は、物理チャネルを割り当ててダイヤルします。アウトバウンドコールを配置し、接続を待ち、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通話が不完全な場合は、ゼロ以外のエラーコードを使用して送信コール返済を送信します。アウトバウンドコールでタイマーが期限切れになった場合は、ゼロ以外のエラーコードを使用して発信コールの繰り返しを送り返します。回路の切り替えされた接続が確立されている場合は、成功を示す発信コールの繰り返しを送信します。
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.
Call-Clear-Requestが受信された場合に確立された場合、適切なメカニズムを介してTelco呼び出しをリリースする必要があり、Call-Disconnect-NotifyメッセージをPNSに送信する必要があります。通話がクライアントまたはTelcoインターフェイスによって切断されている場合、Call-Disconnect-Notifyメッセージを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.
アイドル発信コールリクエストメッセージが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エラーを示す発信-call-replyが受信されます。セッションはアイドル状態に戻ります。電話コールはアクティブではありません。発信-Call-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がセッションを終了することを選択した場合、Call-Clear-RequestをPACに送信し、Wait_Disconnect Stateに入ります。
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がcall-disconnect-notifyメッセージを受信すると、セッションはアイドル状態になります。
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パケットは、PACとPNSの間に配置され、GREパケットにカプセル化され、IPに掲載されます。カプセル化された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).
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つに設定します。ペイロードが存在しない場合はゼロ（0）に設定されています（GREパケットは確認のみです）。
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.
a（ビット8）承認シーケンス番号が表示されます。パケットが以前に送信されたデータを確認するために使用される確認番号が含まれている場合、1つに設定します。
Flags (Bits 9-12) Must be set to zero (0).
フラグ（ビット9-12）はゼロ（0）に設定する必要があります。
Ver (Bits 13-15) Must contain 1 (enhanced GRE).
Ver（ビット13-15）には、1（拡張GRE）が含まれている必要があります。
Protocol Type Set to hex 880B [8].
Hex 880bに設定されたプロトコルタイプ[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は次のように使用します：ペイロード長（キーの2オクテット）のペイロードのサイズ、GREヘッダーは含まれません
Call ID (Low 2 octets) Contains the Peer's Call ID for the session to which this packet belongs.
コールID（低2オクテット）には、このパケットが属するセッションのピアの呼び出しIDが含まれています。
Sequence Number Contains the sequence number of the payload. Present if S bit (Bit 3) is one (1).
シーケンス番号には、ペイロードのシーケンス番号が含まれています。sビット（ビット3）が1（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).
謝辞番号には、このユーザーセッションの送信ピアが受け取った最高の数字のGREパケットのシーケンス番号が含まれています。少し（ビット8）が1つ（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つのパケットです。確認を待っているパケットの数が現在のウィンドウサイズに等しい場合、送信機はパケットの送信を停止します。受信機が各ウィンドウの消化に成功すると、送信機のウィンドウサイズは、最大に達するまで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つのパケットによって増加します。前述のように、タイムアウト時に再送信は行われません。タイムアウト後、タイムアウトが発生したときに送信ウィンドウの半分のサイズから始まり、送信ウィンドウがすべてタイムアウトなしで認められているパケットで満たされるたびに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がパケットを0〜5にPACに送信するとします。インターネットワークの再ルーティングのため、パケット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の場合、この数は小さくなければなりません。Modem接続を作成する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.
Adaptive Time-Out（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）パラメーターは、コールコントロールフェーズ中に交換される16ビットワードで、10分の1秒を表します（64は6.4秒を平均します）。プロトコルは、パラメーターが交換されることを指定するだけであり、計算方法を指定しません。PPDの値が計算される方法は実装依存であり、可変である必要はありません（静的タイムアウトは許可されています）。PPDは、実装で一定のままであっても、コールコネクトシーケンスで交換する必要があります。PPDを計算する可能性のある方法の1つは、次のとおりです。
PPD' = ((PPP_MAX_DATA_MTU - Header) * 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歳のIPおよびGREヘッダーの合計サイズです。MTUは、PACとPNSの間のインターネットワークリンクの全体的なMTUです。Windowsizeは、スライドウィンドウ内のパケットの数を表し、実装依存です。インターネットワークの遅延を使用して、現在のセッションのパイプをいっぱいに保つのに十分なウィンドウサイズを選択できます。定数8はオクテットをビットに変換します（Connectrateが1秒あたりビットであると仮定します）。Connectrateが1秒あたりのバイトである場合、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 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は各反復で計算され、次の反復で使用するために保存されます。最初は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は各反復で計算されます。その値は、最小関数によって制限され、構成された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.
Chiはタイムアウトの利益であり、通常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))
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はDeltaによって拡大され、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.
Tunneled 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 Ascend Communications 1275 Harbor Bay Parkway Alameda、CA 94502
EMail: kory@ascend.com
Gurdeep Singh Pall Microsoft Corporation Redmond, WA
Gurdeep Singh Pall Microsoft Corporation Redmond、WA
EMail: gurdeep@microsoft.com
William Verthein U.S. Robotics/3Com
William Verthein U.S. Robotics/3com
Jeff Taarud Copper Mountain Networks
Jeff Taarud Copper Mountain Networks
W. Andrew Little ECI Telematics
W.アンドリューリトルECIテレマティクス
Glen Zorn Microsoft Corporation Redmond, WA
グレンゾーンマイクロソフトコーポレーションレドモンド、ワシントン州
EMail: glennz@microsoft.com
[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[1] Hanks、S.、Li、T.、Farinacci、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] Hanks、S.、Li、T.、Farinacci、D。およびP. Traina、「IPv4ネットワーク上の一般的なルーティングカプセル化（GRE）」、RFC 1702、1994年10月。
[3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.
[3] Lloyd、B。and W. Simpson、「PPP認証プロトコル」、RFC 1334、1992年10月。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[4] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.
[5] Postel、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] Reynolds、J。and J. Postel、「割り当てられた番号」、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] Xerox Corporationで予約されている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] Blunk、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 Illustrated、Volume 1」、p。 300、Addison-Wesley、1994。
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[12] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。