diff options
Diffstat (limited to 'doc/pptp-draft.txt')
| -rw-r--r-- | doc/pptp-draft.txt | 3472 |
1 files changed, 0 insertions, 3472 deletions
diff --git a/doc/pptp-draft.txt b/doc/pptp-draft.txt deleted file mode 100644 index f58701b3..00000000 --- a/doc/pptp-draft.txt +++ /dev/null @@ -1,3472 +0,0 @@ - -Internet Draft Kory Hamzeh - Ascend Communications - Gurdeep Singh Pall - Microsoft Corporation - William Verthein - U.S. Robotics/3Com - Jeff Taarud - Copper Mountain Networks - W. Andrew Little - ECI Telematics -July 1997 -Expire in six months - - - Point-to-Point Tunneling Protocol--PPTP - draft-ietf-pppext-pptp-02.txt - -Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - To learn the current status of any Internet-Draft, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), - munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or - ftp.isi.edu (US West Coast). - -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 - - - -Hamzeh, et al [Page 1] - -Internet Draft PPTP July 1997 - - - 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. - -1. Introduction - - 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: - - 1) Physical native interfacing to PSTN or ISDN and control of - external modems or terminal adapters. - - 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. - - 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. - - 2) Logical termination of a Point-to-Point-Protocol (PPP) Link - Control Protocol (LCP) session. - - 3) Participation in PPP authentication protocols [3]. - - 4) Channel aggregation and bundle management for PPP Multilink - Protocol. - - 5) Logical termination of various PPP network control protocols - (NCP). - - 6) Multiprotocol routing and bridging between NAS interfaces. - - 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. - - The decoupling of NAS functions offers these benefits: - - - - -Hamzeh, et al [Page 2] - -Internet Draft PPTP July 1997 - - - 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. - - 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. - - 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. - - -1.1 Protocol Goals and Assumptions - - 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 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. - - 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. - - 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 Appendix A. - - -1.2 Terminology - - -Hamzeh, et al [Page 3] - -Internet Draft PPTP July 1997 - - - Analog Channel - - A circuit-switched communication path which is intended to - carry 3.1 Khz audio in each direction. - - 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. - - 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. - - 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. - - Network Access Server (NAS) - - A device providing temporary, on-demand network access to - users. This access is point-to-point using PSTN or ISDN lines. - - PPTP Access Concentrator (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. - - PPTP Network Server (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. - - - - -Hamzeh, et al [Page 4] - -Internet Draft PPTP July 1997 - - - 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. - - 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. - -1.3 Protocol Overview - - There are two parallel components of PPTP: 1) a Control Connection - between each PAC-PNS pair operating over TCP and 2) an IP tunnel - operating between the same PAC-PNS pair which is used to transport - GRE encapsulated PPP packets for user sessions between the pair. - -1.3.1 Control Connection Overview - - 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. - - 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 - - - -Hamzeh, et al [Page 5] - -Internet Draft PPTP July 1997 - - - PAC or PNS, also through Control Connection messages. - - 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 Wan-Error-Notify message, also on the control - connection. - - It is intended that the control connection will also carry management - related messages in the future, such as a message allowing the PNS to - request the status of a given PAC; these message types have not yet - been defined. - -1.3.2 Tunnel Protocol Overview - - 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. 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. - - 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 Appendix A of this - document. - -1.4 Specification Language - - In this document, several words are used to signify the requirements - of the specification. These words are often capitalized. - - MUST This word, or the adjective "required", means - that the definition is an absolute requirement - of the specification. - - MUST NOT This phrase means that the definition is an - absolute prohibition of the specification. - - SHOULD This word, or the adjective "recommended", - - - -Hamzeh, et al [Page 6] - -Internet Draft PPTP July 1997 - - - means that, in some circumstances, valid - reasons may exist to ignore this item, but the - full implications must be understood and - carefully weighed before choosing a different - course. Unexpected results may result - otherwise. - - MAY This word, or the adjective "optional", means - that this item is one of an allowed set of - alternatives. An implementation which does - not include this option MUST be prepared to - interoperate with another implementation which - does include the option. - - silently discard 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. - - -1.5 Message Format and Protocol Extensibility - - 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. - - 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". - - Two Control Connection message types are indicated by the PPTP - Message Type field: - - 1 - Control Message - 2 - Management Message - - Management messages are currently not defined. - - The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its - basic purpose is to allow the receiver to ensure that it is properly - synchronized with the TCP data stream. It should not be used as a - means for resynchronizing the TCP data stream in the event that a - transmitter issues an improperly formatted message. Loss of - - - -Hamzeh, et al [Page 7] - -Internet Draft PPTP July 1997 - - - synchronization must result in immediate closing of the control - connection's TCP session. - - 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. - - 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 - - (PPP Session Control) - - 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 3. The current value of the - version number field is 0x0100 for version 1, revision 0. - - The use of the GRE-like header for the encapsulation of PPP user - packets is specified in Section 4. - - - -Hamzeh, et al [Page 8] - -Internet Draft PPTP July 1997 - - - The MTU for the user data packets encapsulated in GRE is 1532 octets, - not including the IP and GRE headers. - -2.0 Control Connection Protocol Specification - - - 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. - - 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. - - The TCP header is followed by the PPTP fields shown in the following: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 9] - -Internet Draft PPTP July 1997 - - -2.1 Start-Control-Connection-Request - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. This constant value is used - as a sanity check on received messages - (see Section 1.5). - - - -Hamzeh, et al [Page 10] - -Internet Draft PPTP July 1997 - - - Control Message Type 1 for Start-Control-Connection-Request. - - Reserved0 This field MUST be 0. - - Protocol Version The version of the PPTP protocol that the - sender wishes to use. - - Reserved1 This field MUST be 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 - - 2 - Synchronous Framing supported - - 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 - - 2 - Digital access supported - - 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. - - 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. - - 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. - - 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 - - - -Hamzeh, et al [Page 11] - -Internet Draft PPTP July 1997 - - - issued by the PNS. If less than 64 - octets in length, the remainder of this - field SHOULD be filled with octets of - value 0. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 12] - -Internet Draft PPTP July 1997 - - -2.2 Start-Control-Connection-Reply - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 2 for Start-Control-Connection-Reply. - - Reserved0 This field MUST be 0. - - Protocol Version The version of the PPTP protocol that the - - - -Hamzeh, et al [Page 13] - -Internet Draft PPTP July 1997 - - - sender wishes to use. - - Result Code Indicates the result of the command - channel establishment attempt. Current - valid Result Code values are: - - 1 - Successful channel establishment - - 2 - General error -- Error Code - indicates the problem - - 3 - Command channel already exists; - - 4 - Requester is not authorized to - establish a command channel - - 5 - The protocol version of the - requester is not supported - - 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.16. - - 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 - - 2 - Synchronous Framing supported. - - 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 - - 2 - Digital access supported - - 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 - - - -Hamzeh, et al [Page 14] - -Internet Draft PPTP July 1997 - - - PNS MUST NOT use this value to try to - track the remaining number of PPP - sessions that the PAC will allow. - - 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. - - 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. - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 15] - -Internet Draft PPTP July 1997 - - -2.3 Stop-Control-Connection-Request - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 3 for Stop-Control-Connection-Request. - - Reserved0 This field MUST be 0. - - Reason Indicates the reason for the control - connection being closed. Current valid - Reason values are: - - 1 (None) - General request to clear - control connection - - 2 (Stop-Protocol) - Can't support - peer's version of the protocol - - 3 (Stop-Local-Shutdown) - Requester is - being shut down - - Reserved1, Reserved2 These fields MUST be 0. - - - -Hamzeh, et al [Page 16] - -Internet Draft PPTP July 1997 - - -2.4 Stop-Control-Connection-Reply - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 4 for Stop-Control-Connection-Reply. - - Reserved0 This field MUST be 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 - - 2 (General Error) - Control connection - not closed for reason indicated in - Error Code - - 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.16. - - Reserved1 This field MUST be 0. - - - -Hamzeh, et al [Page 17] - -Internet Draft PPTP July 1997 - - -2.5 Echo-Request - - 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, - if the sender does not receive an Echo Reply in response to an Echo- - Request, it will eventually clear the control connection. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 5 for Echo-Request. - - Reserved0 This field MUST be 0. - - Identifier A value set by the sender of the Echo- - Request that is used to match the reply - with the corresponding request. - - - - - - - - - - - - - - -Hamzeh, et al [Page 18] - -Internet Draft PPTP July 1997 - - -2.6 Echo-Reply - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 6 for Echo-Reply. - - Reserved0 This field MUST be 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: - - 1 (OK) - The Echo-Reply is valid - - 2 (General Error) - Echo-Request not - accepted for the reason indicated in - Error Code - - Error Code This field is set to 0 unless a "General - - - -Hamzeh, et al [Page 19] - -Internet Draft PPTP July 1997 - - - 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.16. - - Reserved1 This field MUST be 0. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 20] - -Internet Draft PPTP July 1997 - - -2.7 Outgoing-Call-Request - - 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. - - 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 Message Type 1 for Control Message. - - - - -Hamzeh, et al [Page 21] - -Internet Draft PPTP July 1997 - - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 7 for Outgoing-Call-Request. - - Reserved0 This field MUST be 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. - - 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. - - Minimum BPS The lowest acceptable line speed (in - bits/second) for this session. - - Maximum BPS The highest acceptable line speed (in - bits/second) for this session. - - Bearer Type A value indicating the bearer capability - required for this outgoing call. The - currently defined values are: - - 1 - Call to be placed on an analog - channel - - 2 - Call to be placed on a digital - channel - - 3 - Call can be placed on any type of - channel - - Framing Type A value indicating the type of PPP - framing to be used for this outgoing - call. - - 1 - Call to use Asynchronous framing - - 2 - Call to use Synchronous framing - - - -Hamzeh, et al [Page 22] - -Internet Draft PPTP July 1997 - - - 3 - Call can use either type of - framing - - Packet Recv. Window Size The number of received data packets the - PNS will buffer for this session. - - 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 appendix A for a description of how - this value is determined and used. - - Phone Number Length The actual number of valid digits in the - Phone Number field. - - Reserved1 This field MUST be 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. - - 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. - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 23] - -Internet Draft PPTP July 1997 - - -2.8 Outgoing-Call-Reply - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 8 for Outgoing-Call-Reply. - - Reserved0 This field MUST be 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. - - - - -Hamzeh, et al [Page 24] - -Internet Draft PPTP July 1997 - - - 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. - - Result Code This value indicates the result of the - Outgoing-Call-Request attempt. Currently - valid values are: - - 1 (Connected) - Call established with - no errors - - 2 (General Error) - Outgoing Call not - established for the reason indicated - in Error Code - - 3 (No Carrier) - Outgoing Call failed - due to no carrier detected - - 4 (Busy) - Outgoing Call failed due to - detection of a busy signal - - 5 (No Dial Tone) - Outgoing Call - failed due to lack of a dial tone - - 6 (Time-out) - Outgoing Call was not - established within time allotted by - PAC - - 7 (Do Not Accept) - Outgoing Call - administratively prohibited - - 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.16. - - 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. - - - - -Hamzeh, et al [Page 25] - -Internet Draft PPTP July 1997 - - - 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. - - 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 Appendix A - for an example of how this value is - determined and used. - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 26] - -Internet Draft PPTP July 1997 - - -2.9 Incoming-Call-Request - - 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. - - 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. - - 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. - - - -Hamzeh, et al [Page 27] - -Internet Draft PPTP July 1997 - - - PPTP Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 9 for Incoming-Call-Request. - - Reserved0 This field MUST be 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. - - 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. - - Bearer Type A value indicating the bearer capability - used for this incoming call. Currently - defined values are: - - 1 - Call is on an analog channel - - 2 - Call is on a digital channel - - 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. - - 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. - - - -Hamzeh, et al [Page 28] - -Internet Draft PPTP July 1997 - - - 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. - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 29] - -Internet Draft PPTP July 1997 - - -2.10 Incoming-Call-Reply - - 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. - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 10 for Incoming-Call-Reply. - - Reserved0 This field MUST be 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. - - Peer's Call ID This field is set to the value received - - - -Hamzeh, et al [Page 30] - -Internet Draft PPTP July 1997 - - - 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. - - 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 - - 2 (General Error) - The Incoming Call - should not be established due to the - reason indicated in Error Code - - 3 (Do Not Accept) - The PAC should not - accept the incoming call. It should - hang up or issue a busy indication - - 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.16. - - Packet Recv. Window Size The number of received data packets the - PAC will buffer for this session. - - 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. See - Appendix A for a description of how this - value is determined and used. - - Reserved1 This field MUST be 0. - - - - - - - - - - -Hamzeh, et al [Page 31] - -Internet Draft PPTP July 1997 - - -2.11 Incoming-Call-Connected - - 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. - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 11 for Incoming-Call-Connected. - - Reserved0 This field MUST be 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 - - - -Hamzeh, et al [Page 32] - -Internet Draft PPTP July 1997 - - - by the PNS to match the Incoming-Call- - Connected with the Incoming-Call-Reply it - issued. - - 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. - - 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. See - Appendix A for a description of how this - value is determined and used. - - Framing Type A value indicating the type of PPP - framing being used by this incoming call. - - 1 - Call uses asynchronous framing - - 2 - Call uses synchronous framing - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 33] - -Internet Draft PPTP July 1997 - - -2.12 Call-Clear-Request - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 12 for Call-Clear-Request. - - Reserved0 This field MUST be 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. - - Reserved1 This field MUST be 0. - - - - - - - - - - - -Hamzeh, et al [Page 34] - -Internet Draft PPTP July 1997 - - -2.13 Call-Disconnect-Notify - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 13 for Call-Disconnect-Notify. - - Reserved0 This field MUST be 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. - - Result Code This value indicates the reason for the - disconnect. Current valid Result Code - - - -Hamzeh, et al [Page 35] - -Internet Draft PPTP July 1997 - - - values are: - - 1 (Lost Carrier) - Call disconnected - due to loss of carrier - - 2 (General Error) - Call disconnected - for the reason indicated in Error - Code - - 3 (Admin Shutdown) - Call disconnected - for administrative reasons - - 4 (Request) - Call disconnected due to - received Call-Clear-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.16. - - 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. - - 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. - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 36] - -Internet Draft PPTP July 1997 - - -2.14 WAN-Error-Notify - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 14 for WAN-Error-Notify. - - Reserved0 This field MUST be 0. - - Peer's Call ID Th Call ID assigned by the PNS to this - call. - - - -Hamzeh, et al [Page 37] - -Internet Draft PPTP July 1997 - - - CRC Errors Number of PPP frames received with CRC - errors since session was established. - - Framing Errors Number of improperly framed PPP packets - received. - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 38] - -Internet Draft PPTP July 1997 - - -2.15 Set-Link-Info - - 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. - - 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 Message Type 1 for Control Message. - - Magic Cookie 0x1A2B3C4D. - - Control Message Type 15 for Set-Link-Info. - - Reserved0 This field MUST be 0. - - Peer's Call ID The value of the Call ID assigned by the - PAC to this call. - - Reserved1 This field MUST be 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]. - - - - -Hamzeh, et al [Page 39] - -Internet Draft PPTP July 1997 - - - 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]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 40] - -Internet Draft PPTP July 1997 - - -2.16 General Error Codes - - 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: - - 0 (None) - No general error - - 1 (Not-Connected) - No control connection exists yet for this - PAC-PNS pair - - 2 (Bad-Format) - Length is wrong or Magic Cookie value is - incorrect - - 3 (Bad-Value) - One of the field values was out of range or - reserved field was non-zero - - 4 (No-Resource) - Insufficient resources to handle this command - now - - 5 (Bad-Call ID) - The Call ID is invalid in this context - - 6 (PAC-Error) - A generic vendor-specific error occurred in - the PAC - - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 41] - -Internet Draft PPTP July 1997 - - -3.0 Control Connection Protocol Operation - - 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. - - 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. - - 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. - - -3.1 Control Connection States - - 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. - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 42] - -Internet Draft PPTP July 1997 - - -3.1.1 Control Connection Originator (may be PAC or PNS) - - TCP Open Indication - /Send Start Control - Connection Request +-----------------+ - +------------------------------------>| wait_ctl_reply | - | +-----------------+ - | Collision/See (3.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. - - 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. - - 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. - - - - - - -Hamzeh, et al [Page 43] - -Internet Draft PPTP July 1997 - - - 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. - - 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. - - wait_stop_reply - - If a Stop-Control-Connection-Reply is received, the TCP connection - SHOULD be closed and the control connection becomes idle. - -3.1.2 Control connection Receiver (may be PAC or PNS) - - - 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 - - - -Hamzeh, et al [Page 44] - -Internet Draft PPTP July 1997 - - - 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. - - 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. - - 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. - - wait_stop_reply - - If a Stop-Control-Connection-Reply is received, the TCP connection - SHOULD be closed and the control connection becomes idle. - -3.1.3 Start Control Connection Initiation Request Collision - - 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. - - 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. - - - - -Hamzeh, et al [Page 45] - -Internet Draft PPTP July 1997 - - -3.1.3 Keep Alives and Timers - - A control connection SHOULD be closed by closing the underlying TCP - connection under the following circumstances: - - 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. - - 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. - -3.2 Call States - -3.2.1 Timing considerations - - 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. - - 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. - - 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. - -3.2.2 Call ID values - - 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 - - - -Hamzeh, et al [Page 46] - -Internet Draft PPTP July 1997 - - - 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. - - A session is defined by the triple (PAC, PNS, Call ID). - -3.2.3 Incoming calls - - 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. - - 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: - - - No resources are available to handle more sessions - - - The dialed, dialing, or subaddress fields are not indicative of - an authorized user - - - The bearer service is not authorized or supported - - If the PNS chooses to accept the call, it responds with an Outgoing- - Call-Reply which also indicates window sizes (see Appendix B). 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. - - 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. - - - - - - - - - -Hamzeh, et al [Page 47] - -Internet Draft PPTP July 1997 - - -3.2.3.1 PAC Incoming Call States - - - Ring/Send Incoming Call Request +-----------------+ - +----------------------------------------->| wait_reply | - | +-----------------+ - | Receive Incoming Call Reply V V V - | Not Accepting | | | Receive Incoming - | +--------------------------------+ | | Call Reply Accepting - | | +------------------------------+ | /Answer call; Send - | | | Abort/Send Call | Call Connected - ^ V V Disconnect Notify V - +-----------------+ +-----------------+ - | 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: - - 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. - - 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. - - established - - Data is exchanged over the tunnel. The call may be cleared following: - - An event on the telco connection. The PAC sends a Call- - Disconnect-Notify message - - Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect- - Notify message - - - - -Hamzeh, et al [Page 48] - -Internet Draft PPTP July 1997 - - - A local reason. The PAC sends a Call-Disconnect-Notify message. - -3.2.3.2 PNS Incoming Call States - - - - 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: - - 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. - - 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. - - - - - -Hamzeh, et al [Page 49] - -Internet Draft PPTP July 1997 - - - 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. - - wait_disconnect - - Once a Call-Disconnect-Notify is received the session moves back to - the idle state. - -3.2.4 Outgoing calls - - 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: - - 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 - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 50] - -Internet Draft PPTP July 1997 - - -3.2.4.1 PAC Outgoing Call States - - - - 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: - - 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 - - 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. - - established - - If a Call-Clear-Request is received, the telco call SHOULD be - - - -Hamzeh, et al [Page 51] - -Internet Draft PPTP July 1997 - - - 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. - -3.2.4.2 PNS Outgoing Call States - - - 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: - - idle - - An Outgoing-Call-Request message is sent to the PAC and the session - moves into the wait_reply state. - - 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. - - 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 - - - -Hamzeh, et al [Page 52] - -Internet Draft PPTP July 1997 - - - terminate the session, it sends a Call-Clear-Request to the PAC and - then enters the 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. - -4.0 Tunnel Protocol Operation - - 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: - - +--------------------------------+ - | Media Header | - +--------------------------------+ - | IP Header | - +--------------------------------+ - | GRE Header | - +--------------------------------+ - | PPP Packet | - +--------------------------------+ - - -4.1 Enhanced GRE header - - 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: - - - - - - - - -Hamzeh, et al [Page 53] - -Internet Draft PPTP July 1997 - - - - 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). - - 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). - - s (Bit 4) Strict source route present. Set - to zero (0). - - Recur (Bits 5-7) Recursion control. Set to - zero (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. - - Flags (Bits 9-12) Must be set to zero (0). - - Ver (Bits 13-15) Must contain 1 (enhanced - GRE). - - Protocol Type Set to hex 880B [8]. - - Key Use of the Key field is up to the - - - -Hamzeh, et al [Page 54] - -Internet Draft PPTP July 1997 - - - implementation. - PPTP uses it as follows: - - Payload Length - (High 2 octets of Key) Size of the - payload, not including the GRE header - - Call ID - (Low 2 octets) Contains the Peer's - Call ID for the session to which this - packet belongs. - - Sequence Number Contains the sequence number of the - payload. Present if S bit (Bit 3) is one - (1). - - 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). - - The payload section contains a PPP data packet without any media - specific framing elements. - - 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. - - 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. - - -4.2 Sliding Window Protocol - - 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. - - - - - - - -Hamzeh, et al [Page 55] - -Internet Draft PPTP July 1997 - - -4.3 Multi Packet Acknowledgment - - 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. - - - 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. - -4.4 Out-of-Sequence Packets - - 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. - - 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. - -5.0 Security Considerations - - Security issues are not addressed in this document. End to end - security is addressed by PPP. Further security considerations will be - addressed by the next version of PPTP. - - - - - - - -Hamzeh, et al [Page 56] - -Internet Draft PPTP July 1997 - - -6.0 Authors' Addresses - - - Kory Hamzeh - Ascend Communications - 1275 Harbor Bay Parkway - Alameda, CA 94502 - Email: kory@ascend.com - - Gurdeep Singh Pall - Microsoft Corporation - Redmond, WA - Email: gurdeep@microsoft.com - - William Verthein - U.S. Robotics/3Com - - Jeff Taarud - Copper Mountain Networks - - W. Andrew Little - ECI Telematics - -7.0 References - - [1] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing - Encapsulation (GRE)", RFC 1701, October 1994. - - [2] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing - Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994. - - [3] Lloyd, B. Simpson, W., "PPP Authentication Protocols", RFC 1334, - October 1992. - - [4] Postel, J. B., "Transmission Control Protocol", RFC 791, - September 1981 - - [5] Postel, J. B., "User Data Protocol", RFC 768, August 1980. - - [6] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October, - 1994. - - [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", RFC - 1661, July 1994. - - [8] Ethertype for PPP, Reserved with Xerox Corporation. - - - - - -Hamzeh, et al [Page 57] - -Internet Draft PPTP July 1997 - - -Appendix A. Acknowledgment Time-Outs - - - 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: - - Independent time-outs for each session. A device (PAC or PNS) will - have to maintain and calculate time-outs for every active session. - - An administrator-adjustable maximum time-out, MaxTimeOut, unique - to each device. - - 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. - - 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 - - - -Hamzeh, et al [Page 58] - -Internet Draft PPTP July 1997 - - - 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. - - 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. - - -Packet Processing Delay (PPD) - - The 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' = ((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. - - The value of PPD is used to seed the adaptive algorithm with the - initial RTT[n-1] value. - -Sample - - Sample is the actual measured time for a returned acknowledgment. - -Round-Trip Time (RTT) - - The RTT value represents an estimate of the average time it takes for - an acknowledgment to be received after a packet is sent to the remote - - - -Hamzeh, et al [Page 59] - -Internet Draft PPTP July 1997 - - - end of the tunnel. - - -A.1 Calculating Adaptive Acknowledgment Time-Out - - 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 Richard Steven's book TCP/IP - Illustrated, Volume 1 (page 300). 'n' means this iteration of the - calculation, and 'n-1' refers to values from the last calculation. - - 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] = 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. - - 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. - - RTT is the estimated round-trip time of an average packet. RTT is - calculated on each iteration and stored for use in the next - iteration. Initially, it is set to 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. - - Alpha is the gain for the average and is typically 1/8 (0.125). - - Beta is the gain for the deviation and is typically 1/4 (0.250). - - Chi is the gain for the time-out and is typically set to 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 - - - -Hamzeh, et al [Page 60] - -Internet Draft PPTP July 1997 - - - division. - - -A.2 Congestion Control: Adjusting for Time-Out - - 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. A simple formula called - Karn's Algorithm is used in TCP implementations and may be used in - implementing the backoff timers for the PNS or the PAC. Notice that - in addition to increasing the time-out, we are also shrinking the - size of the window as described in the next section. - - Karn's timer backoff algorithm, as used in TCP, is: - - - NewTIMEOUT = delta * TIMEOUT - - Adapted to our time-out calculations, for an interval in which a - time-out occurs, the new ATO is calculated as: - - RTT[n] = delta * RTT[n-1] - DEV[n] = DEV[n-1] - ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) - - In this modified calculation of ATO, only the two values that - contribute to ATO and that are stored for the next iteration are - calculated. RTT is scaled by chi, 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. - -Appendix B. Acknowledgment Time-Out and Window Adjustment - -B.1 Initial Window Size - - Although each side has indicated the maximum size of its receive - window, it is recommended that a slow start method be used to begin - transmitting 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 - - - -Hamzeh, et al [Page 61] - -Internet Draft PPTP July 1997 - - - congested network because no history has been established. - -B.2 Closing the Window - - 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. - -B.3 Opening the Window - - 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. - -B.4 Window Overflow - - 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. - - - - - - - - - - - - - - - - - - - - - - - -Hamzeh, et al [Page 62] - - |