home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pppext-pptp-02.txt < prev    next >
Text File  |  1997-07-25  |  130KB  |  3,471 lines
  1. Internet Draft                    Kory Hamzeh
  2.                         Ascend Communications
  3.                         Gurdeep Singh Pall
  4.                         Microsoft Corporation
  5.                         William Verthein
  6.                         U.S. Robotics/3Com
  7.                         Jeff Taarud
  8.                         Copper Mountain Networks
  9.                         W. Andrew Little
  10.                         ECI Telematics
  11. July 1997
  12. Expire in six months
  13.  
  14.  
  15.                   Point-to-Point Tunneling Protocol--PPTP
  16.                draft-ietf-pppext-pptp-02.txt
  17.  
  18. Status of this Memo
  19.  
  20.    This document is an Internet-Draft.  Internet-Drafts are working
  21.    documents of the Internet Engineering Task Force (IETF), its areas,
  22.    and its working groups.  Note that other groups may also distribute
  23.    working documents as Internet-Drafts.
  24.  
  25.    Internet-Drafts are draft documents valid for a maximum of six months
  26.    and may be updated, replaced, or obsoleted by other documents at any
  27.    time.  It is inappropriate to use Internet-Drafts as reference
  28.    material or to cite them other than as "work in progress."
  29.  
  30.    To learn the current status of any Internet-Draft, please check the
  31.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  32.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  33.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  34.    ftp.isi.edu (US West Coast).
  35.  
  36. Abstract
  37.  
  38.         This document specifies a protocol which allows the Point
  39.         to Point Protocol (PPP) to be tunneled through an IP
  40.         network. PPTP does not specify any changes to the PPP
  41.         protocol but rather describes a new vehicle for carrying
  42.         PPP. A client-server architecture is defined in order to
  43.         decouple functions which exist in current Network Access
  44.         Servers (NAS) and support Virtual Private Networks (VPNs).
  45.         The PPTP Network Server (PNS) is envisioned to run on a
  46.         general purpose operating system while the client, referred
  47.         to as a PPTP Access Concentrator (PAC) operates on a dial
  48.         access platform. PPTP specifies a call-control and
  49.  
  50.  
  51.  
  52. Hamzeh, et al                                                   [Page 1]
  53.  
  54. Internet Draft              PPTP                   July 1997
  55.  
  56.  
  57.         management protocol which allows the server to control
  58.         access for dial-in circuit switched calls originating from
  59.         a PSTN or ISDN or to initiate outbound circuit-switched
  60.     connections. PPTP uses an enhanced GRE (Generic Routing
  61.         Encapsulation) mechanism to provide a flow- and
  62.         congestion-controlled encapsulated datagram service for
  63.         carrying PPP packets.
  64.  
  65. 1. Introduction
  66.  
  67.    PPTP allows existing Network Access Server (NAS) functions to be
  68.    separated using a client-server architecture. Traditionally, the
  69.    following functions are implemented by a NAS:
  70.  
  71.    1) Physical native interfacing to PSTN or ISDN and control of
  72.       external modems or terminal adapters.
  73.  
  74.       A NAS may interface directly to a telco analog or digital circuit
  75.       or attach via an external modem or terminal adapter. Control of a
  76.       circuit-switched connection is accomplished with either modem
  77.       control or DSS1 ISDN call control protocols.
  78.  
  79.       The NAS, in conjunction with the modem or terminal adapters, may
  80.       perform rate adaption, analog to digital conversion, sync to async
  81.       conversion or a number of other alterations of data streams.
  82.  
  83.    2) Logical termination of a Point-to-Point-Protocol (PPP) Link
  84.       Control Protocol (LCP) session.
  85.  
  86.    3) Participation in PPP authentication protocols [3].
  87.  
  88.    4) Channel aggregation and bundle management for PPP Multilink
  89.       Protocol.
  90.  
  91.    5) Logical termination of various PPP network control protocols
  92.       (NCP).
  93.  
  94.    6) Multiprotocol routing and bridging between NAS interfaces.
  95.  
  96.    PPTP divides these functions between the PAC and PNS. The PAC is
  97.    responsible for functions 1, 2, and possibly 3. The PNS may be
  98.    responsible for function 3 and is responsible for functions 4, 5, and
  99.    6. The protocol used to carry PPP protocol data units (PDUs) between
  100.    the PAC and PNS, as well as call control and management is addressed
  101.    by PPTP.
  102.  
  103.    The decoupling of NAS functions offers these benefits:
  104.  
  105.  
  106.  
  107.  
  108. Hamzeh, et al                                                   [Page 2]
  109.  
  110. Internet Draft              PPTP                   July 1997
  111.  
  112.  
  113.       Flexible IP address management. Dial-in users may maintain a
  114.       single IP address as they dial into different PACs as long as they
  115.       are served from a common PNS. If an enterprise network uses
  116.       unregistered addresses, a PNS associated with the enterprise
  117.       assigns addresses meaningful to the private network.
  118.  
  119.       Support of non-IP protocols for dial networks behind IP networks.
  120.       This allows Appletalk and IPX, for example to be tunneled through
  121.       an IP-only provider. The PAC need not be capable of processing
  122.       these protocols.
  123.  
  124.       A solution to the "multilink  hunt-group splitting" problem.
  125.       Multilink PPP, typically used to aggregate ISDN B channels,
  126.       requires that all of the channels composing a multilink bundle be
  127.       grouped at a single NAS. Since a multilink PPP bundle can be
  128.       handled by a single PNS, the channels comprising the bundle may be
  129.       spread across multiple PACs.
  130.  
  131.  
  132. 1.1 Protocol Goals and Assumptions
  133.  
  134.    The PPTP protocol is implemented only by the PAC and PNS. No other
  135.    systems need to be aware of PPTP. Dial networks may be connected to a
  136.    PAC without being aware of PPTP. Standard PPP client software should
  137.    continue to operate on tunneled PPP links.
  138.  
  139.    PPTP can also be used to tunnel a PPP session over an IP network. In
  140.    this configuration the PPTP tunnel and the PPP session runs between
  141.    the same two machines with the caller acting as a PNS.
  142.  
  143.    It is envisioned that there will be a many-to-many relationship
  144.    between PACs and PNSs.  A PAC may provide service to many PNSs. For
  145.    example, an Internet service provider may choose to support PPTP for
  146.    a number of private network clients and create VPNs for them. Each
  147.    private network may operate one or more PNSs. A single PNS may
  148.    associate with many PACs to concentrate traffic from a large number
  149.    of geographically diverse sites.
  150.  
  151.    PPTP uses an extended version of GRE to carry user PPP packets. These
  152.    enhancements allow for low-level congestion and flow control to be
  153.    provided on the tunnels used to carry user data between PAC and PNS.
  154.    This mechanism allows for efficient use of the bandwidth available
  155.    for the tunnels and avoids unnecessary retransmisions and buffer
  156.    overruns.  PPTP does not dictate the particular algorithms to be used
  157.    for this low level control but it does define the parameters that
  158.    must be communicated in order to allow such algorithms to work.
  159.    Suggested algorithms are included in Appendix A.
  160.  
  161.  
  162. 1.2 Terminology
  163.  
  164.  
  165. Hamzeh, et al                                                   [Page 3]
  166.  
  167. Internet Draft              PPTP                   July 1997
  168.  
  169.  
  170.       Analog Channel
  171.  
  172.          A circuit-switched communication path which is intended to
  173.          carry 3.1 Khz audio in each direction.
  174.  
  175.       Digital Channel
  176.  
  177.          A circuit-switched communication path which is intended to
  178.          carry digital information in each direction.
  179.  
  180.       Call
  181.  
  182.          A connection or attempted connection between two terminal
  183.          endpoints on a PSTN or ISDN--for example, a telephone call
  184.          between two modems.
  185.  
  186.       Control Connection
  187.  
  188.          A control connection is created for each PAC, PNS pair and
  189.          operates over TCP [4]. The control connection governs aspects
  190.          of the tunnel and of sessions assigned to the tunnel.
  191.  
  192.       Dial User
  193.  
  194.          An end-system or router attached to an on-demand PSTN or ISDN
  195.          which is either the initiator or recipient of a call.
  196.  
  197.       Network Access Server (NAS)
  198.  
  199.          A device providing temporary, on-demand network access to
  200.          users.  This access is point-to-point using PSTN or ISDN lines.
  201.  
  202.       PPTP Access Concentrator (PAC)
  203.  
  204.          A device attached to one or more PSTN or ISDN lines capable of
  205.          PPP operation and of handling the PPTP protocol. The PAC need
  206.          only implement TCP/IP to pass traffic to one or more PNSs. It
  207.          may also tunnel non-IP protocols.
  208.  
  209.       PPTP Network Server (PNS)
  210.  
  211.          A PNS is envisioned to operate on general-purpose
  212.          computing/server platforms. The PNS handles the server side of
  213.          the PPTP protocol. Since PPTP relies completely on TCP/IP and
  214.          is independent of the interface hardware, the PNS may use any
  215.          combination of IP interface hardware including LAN and WAN
  216.          devices.
  217.  
  218.  
  219.  
  220.  
  221. Hamzeh, et al                                                   [Page 4]
  222.  
  223. Internet Draft              PPTP                   July 1997
  224.  
  225.  
  226.       Session
  227.  
  228.          PPTP is connection-oriented. The PNS and PAC maintain state for
  229.          each user that is attached to a PAC. A session is created when
  230.          end-to-end PPP connection is attempted between a dial user and
  231.          the PNS. The datagrams related to a session are sent over the
  232.          tunnel between the PAC and PNS.
  233.  
  234.       Tunnel
  235.  
  236.          A tunnel is defined by a PNS-PAC pair. The tunnel protocol is
  237.          defined by a modified version of GRE [1,2]. The tunnel carries
  238.          PPP datagrams between the PAC and the PNS.  Many sessions are
  239.          multiplexed on a single tunnel. A control connection operating
  240.          over TCP controls the establishment, release, and maintenance
  241.          of sessions and of the tunnel itself.
  242.  
  243. 1.3 Protocol Overview
  244.  
  245.    There are two parallel components of PPTP: 1) a Control Connection
  246.    between each PAC-PNS pair operating over TCP and 2) an IP tunnel
  247.    operating between the same PAC-PNS pair which is used to transport
  248.    GRE encapsulated PPP packets for user sessions between the pair.
  249.  
  250. 1.3.1 Control Connection Overview
  251.  
  252.    Before PPP tunneling can occur between a PAC and PNS, a control
  253.    connection must be established between them. The control connection
  254.    is a standard TCP session over which PPTP call control and management
  255.    information is passed. The control session is logically associated
  256.    with, but separate from, the sessions being tunneled through a PPTP
  257.    tunnel. For each PAC-PNS pair both a tunnel and a control connection
  258.    exist. The control connection is responsible for establishment,
  259.    management, and release of sessions carried through the tunnel. It is
  260.    the means by which a PNS is notified of an incoming call at an
  261.    associated PAC, as well as the means by which a PAC is instructed to
  262.    place an outgoing dial call.
  263.  
  264.    A control connection can be established by either the PNS or the PAC.
  265.    Following the establishment of the required TCP connection, the PNS
  266.    and PAC establish the control connection using the Start-Control-
  267.    Connection-Request and -Reply messages.  These messages are also used
  268.    to exchange information about basic operating capabilities of the PAC
  269.    and PNS.  Once the control connection is established, the PAC or PNS
  270.    may initiate sessions by requesting outbound calls or responding to
  271.    inbound requests. The control connection may communicate changes in
  272.    operating characteristics of an individual user session with a Set-
  273.    Link-Info message.  Individual sessions may be released by either the
  274.  
  275.  
  276.  
  277. Hamzeh, et al                                                   [Page 5]
  278.  
  279. Internet Draft              PPTP                   July 1997
  280.  
  281.  
  282.    PAC or PNS, also through Control Connection messages.
  283.  
  284.    The control connection itself is maintained by keep-alive echo
  285.    messages. This ensures that a connectivity failure between the PNS
  286.    and the PAC can be detected in a timely manner. Other failures can be
  287.    reported via the Wan-Error-Notify message, also on the control
  288.    connection.
  289.  
  290.    It is intended that the control connection will also carry management
  291.    related messages in the future, such as a message allowing the PNS to
  292.    request the status of a given PAC; these message types have not yet
  293.    been defined.
  294.  
  295. 1.3.2 Tunnel Protocol Overview
  296.  
  297.    PPTP requires the establishment of a tunnel for each communicating
  298.    PNS-PAC pair.  This tunnel is used to carry all user session PPP
  299.    packets for sessions involving a given PNS-PAC pair.  A key which is
  300.    present in the GRE header indicates which session a particular PPP
  301.    packet belongs to.  In this manner, PPP packets are multiplexed and
  302.    demultiplexed over a single tunnel between a given PNS-PAC pair.  The
  303.    value to use in the key field is established by the call
  304.    establishment procedure which takes place on the control connection.
  305.  
  306.    The GRE header also contains acknowledgment and sequencing
  307.    information that is used to perform some level of congestion-control
  308.    and error detection over the tunnel.  Again the control connection is
  309.    used to determine rate and buffering parameters that are used to
  310.    regulate the flow of PPP packets for a particular session over the
  311.    tunnel.  PPTP does not specify the particular algorithms to use for
  312.    congestion-control and flow-control.  Suggested algorithms for the
  313.    determination of adaptive time-outs to recover from dropped data or
  314.    acknowledgments on the tunnel are included in Appendix A of this
  315.    document.
  316.  
  317. 1.4 Specification Language
  318.  
  319.    In this document, several words are used to signify the requirements
  320.    of the specification.  These words are often capitalized.
  321.  
  322.       MUST                This word, or the adjective "required", means
  323.                           that the definition is an absolute requirement
  324.                           of the specification.
  325.  
  326.       MUST NOT            This phrase means that the definition is an
  327.                           absolute prohibition of the specification.
  328.  
  329.       SHOULD              This word, or the adjective "recommended",
  330.  
  331.  
  332.  
  333. Hamzeh, et al                                                   [Page 6]
  334.  
  335. Internet Draft              PPTP                   July 1997
  336.  
  337.  
  338.                           means that, in some circumstances, valid
  339.                           reasons may exist to ignore this item, but the
  340.                           full implications must be understood and
  341.                           carefully weighed before choosing a different
  342.                           course. Unexpected results may result
  343.                           otherwise.
  344.  
  345.       MAY                 This word, or the adjective "optional", means
  346.                           that this item is one of an allowed set of
  347.                           alternatives.  An implementation which does
  348.                           not include this option MUST be prepared to
  349.                           interoperate with another implementation which
  350.                           does include the option.
  351.  
  352.       silently discard    The implementation discards the datagram
  353.                           without further processing, and without
  354.                           indicating an error to the sender.  The
  355.                           implementation SHOULD provide the capability
  356.                           of logging the error, including the contents
  357.                           of the discarded datagram, and SHOULD record
  358.                           the event in a statistics counter.
  359.  
  360.  
  361. 1.5 Message Format and Protocol Extensibility
  362.  
  363.    PPTP defines a set of messages sent as TCP data on the control
  364.    connection between a PNS and a given PAC.  The TCP session for the
  365.    control connection is established by initiating a TCP connection to
  366.    port 1723 [6]. The source port is assigned to any unused port number.
  367.  
  368.    Each PPTP Control Connection message begins with an 8 octet fixed
  369.    header portion.  This fixed header contains the following: the total
  370.    length of the message, the PPTP Message Type indicator, and a "Magic
  371.    Cookie".
  372.  
  373.    Two Control Connection message types are indicated by the PPTP
  374.    Message Type field:
  375.  
  376.       1 - Control Message
  377.       2 - Management Message
  378.  
  379.    Management messages are currently not defined.
  380.  
  381.    The Magic Cookie is always sent as the constant 0x1A2B3C4D.  Its
  382.    basic purpose is to allow the receiver to ensure that it is properly
  383.    synchronized with the TCP data stream.  It should not be used as a
  384.    means for resynchronizing the TCP data stream in the event that a
  385.    transmitter issues an improperly formatted message.  Loss of
  386.  
  387.  
  388.  
  389. Hamzeh, et al                                                   [Page 7]
  390.  
  391. Internet Draft              PPTP                   July 1997
  392.  
  393.  
  394.    synchronization must result in immediate closing of the control
  395.    connection's TCP session.
  396.  
  397.    For clarity, all Control Connection message templates in the next
  398.    section include the entire PPTP Control Connection message header.
  399.    Numbers preceded by 0x are hexadecimal values.
  400.  
  401.    The currently defined Control Messages, grouped by function, are:
  402.  
  403.            Control Message                        Message Code
  404.  
  405.            (Control Connection Management)
  406.  
  407.            Start-Control-Connection-Request            1
  408.            Start-Control-Connection-Reply              2
  409.            Stop-Control-Connection-Request             3
  410.            Stop-Control-Connection-Reply               4
  411.            Echo-Request                                5
  412.            Echo-Reply                                  6
  413.  
  414.            (Call Management)
  415.  
  416.            Outgoing-Call-Request                       7
  417.            Outgoing-Call-Reply                         8
  418.            Incoming-Call-Request                       9
  419.            Incoming-Call-Reply                        10
  420.            Incoming-Call-Connected                    11
  421.            Call-Clear-Request                         12
  422.            Call-Disconnect-Notify                     13
  423.  
  424.            (Error Reporting)
  425.  
  426.            WAN-Error-Notify                           14
  427.  
  428.            (PPP Session Control)
  429.  
  430.            Set-Link-Info                              15
  431.  
  432.  
  433.    The Start-Control-Connection-Request and -Reply messages determine
  434.    which version of the Control Connection protocol will be used.  The
  435.    version number field carried in these messages consists of a version
  436.    number in the high octet and a revision number in the low octet.
  437.    Version handling is described in Section 3. The current value of the
  438.    version number field is 0x0100 for version 1, revision 0.
  439.  
  440.    The use of the GRE-like header for the encapsulation of PPP user
  441.    packets is specified in Section 4.
  442.  
  443.  
  444.  
  445. Hamzeh, et al                                                   [Page 8]
  446.  
  447. Internet Draft              PPTP                   July 1997
  448.  
  449.  
  450.    The MTU for the user data packets encapsulated in GRE is 1532 octets,
  451.    not including the IP and GRE headers.
  452.  
  453. 2.0 Control Connection Protocol Specification
  454.  
  455.  
  456.    Control Connection messages are used to establish and clear user
  457.    sessions.  The first set of Control Connection messages are used to
  458.    maintain the control connection itself.  The control connection is
  459.    initiated by either the PNS or PAC after they establish the
  460.    underlying TCP connection. The procedure and configuration
  461.    information required to determine which TCP connections are
  462.    established is not covered by this protocol.
  463.  
  464.    The following Control Connection messages are all sent as user data
  465.    on the established TCP connection between a given PNS-PAC pair.  Note
  466.    that care has been taken to ensure that all word (2 octet) and
  467.    longword (4 octet) values begin on appropriate boundaries.  All data
  468.    is sent in network order (high order octets first).  Any "reserved"
  469.    fields MUST be sent as 0 values to allow for protocol extensibility.
  470.  
  471.    The TCP header is followed by the PPTP fields shown in the following:
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501. Hamzeh, et al                                                   [Page 9]
  502.  
  503. Internet Draft              PPTP                   July 1997
  504.  
  505.  
  506. 2.1 Start-Control-Connection-Request
  507.  
  508.    The Start-Control-Connection-Request is a PPTP control message used
  509.    to establish the control connection between a PNS and a PAC.  Each
  510.    PNS-PAC pair requires a dedicated control connection to be
  511.    established.  A control connection must be established before any
  512.    other PPTP messages can be issued.  The establishment of the control
  513.    connection can be initiated by either the PNS or PAC.  A procedure
  514.    which handles the occurrence of a collision between PNS and PAC
  515.    Start-Control-Connection-Requests is described in Section 3.
  516.  
  517.        0                   1                   2                   3
  518.        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
  519.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  520.       |        Length          |       PPTP Message Type       |
  521.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  522.       |                         Magic Cookie                          |
  523.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  524.       |     Control Message Type      |           Reserved0           |
  525.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  526.       |       Protocol Version        |           Reserved1           |
  527.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  528.       |                     Framing Capabilities                      |
  529.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  530.       |                      Bearer Capabilities                      |
  531.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  532.       |       Maximum Channels        |       Firmware Revision       |
  533.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  534.       |                                                               |
  535.       +                     Host Name (64 octets)                     +
  536.       |                                                               |
  537.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  538.       |                                                               |
  539.       +                   Vendor String (64 octets)                   +
  540.       |                                                               |
  541.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  542.  
  543.  
  544.  
  545.       Length                   Total length in octets of this PPTP
  546.                                message, including the entire PPTP
  547.                                header.
  548.  
  549.       PPTP Message Type        1 for Control Message.
  550.  
  551.       Magic Cookie             0x1A2B3C4D. This constant value is used
  552.                                as a sanity check on received messages
  553.                                (see Section 1.5).
  554.  
  555.  
  556.  
  557. Hamzeh, et al                                                  [Page 10]
  558.  
  559. Internet Draft              PPTP                   July 1997
  560.  
  561.  
  562.       Control Message Type     1 for Start-Control-Connection-Request.
  563.  
  564.       Reserved0                This field MUST be 0.
  565.  
  566.       Protocol Version         The version of the PPTP protocol that the
  567.                                sender wishes to use.
  568.  
  569.       Reserved1                This field MUST be 0.
  570.  
  571.       Framing Capabilities     A set of bits indicating the type of
  572.                                framing that the sender of this message
  573.                                can provide.  The currently defined bit
  574.                                settings are:
  575.  
  576.                                   1 - Asynchronous Framing supported
  577.  
  578.                                   2 - Synchronous Framing supported
  579.  
  580.       Bearer Capabilities      A set of bits indicating the bearer
  581.                                capabilities that the sender of this
  582.                                message can provide.  The currently
  583.                                defined bit settings are:
  584.  
  585.                                   1 - Analog access supported
  586.  
  587.                                   2 - Digital access supported
  588.  
  589.       Maximum Channels         The total number of individual PPP
  590.                                sessions this PAC can support.  In
  591.                                Start-Control-Connection-Requests issued
  592.                                by the PNS, this value SHOULD be set to
  593.                                0.  It MUST be ignored by the PAC.
  594.  
  595.       Firmware Revision        This field contains the firmware revision
  596.                                number of the issuing PAC, when issued by
  597.                                the PAC, or the version of the PNS PPTP
  598.                                driver if issued by the PNS.
  599.  
  600.       Host Name                A 64 octet field containing the DNS name
  601.                                of the issuing PAC or PNS.  If less than
  602.                                64 octets in length, the remainder of
  603.                                this field SHOULD be filled with octets
  604.                                of value 0.
  605.  
  606.       Vendor Name              A 64 octet field containing a vendor
  607.                                specific string describing the type of
  608.                                PAC being used, or the type of PNS
  609.                                software being used if this request is
  610.  
  611.  
  612.  
  613. Hamzeh, et al                                                  [Page 11]
  614.  
  615. Internet Draft              PPTP                   July 1997
  616.  
  617.  
  618.                                issued by the PNS.  If less than 64
  619.                                octets in length, the remainder of this
  620.                                field SHOULD be filled with octets of
  621.                                value 0.
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669. Hamzeh, et al                                                  [Page 12]
  670.  
  671. Internet Draft              PPTP                   July 1997
  672.  
  673.  
  674. 2.2 Start-Control-Connection-Reply
  675.  
  676.    The Start-Control-Connection-Reply is a PPTP control message sent in
  677.    reply to a received Start-Control-Connection-Request message.  This
  678.    message contains a result code indicating the result of the control
  679.    connection establishment attempt.
  680.  
  681.        0                   1                   2                   3
  682.        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
  683.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  684.       |        Length          |       PPTP Message Type       |
  685.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  686.       |                         Magic Cookie                          |
  687.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  688.       |     Control Message Type      |           Reserved0           |
  689.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  690.       |       Protocol Version        |  Result Code  |  Error Code   |
  691.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  692.       |                      Framing Capability                       |
  693.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  694.       |                       Bearer Capability                       |
  695.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  696.       |       Maximum Channels        |       Firmware Revision       |
  697.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  698.       |                                                               |
  699.       +                     Host Name (64 octets)                     +
  700.       |                                                               |
  701.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  702.       |                                                               |
  703.       +                   Vendor String (64 octets)                   +
  704.       |                                                               |
  705.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  706.  
  707.  
  708.  
  709.       Length                   Total length in octets of this PPTP
  710.                                message, including the entire PPTP
  711.                                header.
  712.  
  713.       PPTP Message Type        1 for Control Message.
  714.  
  715.       Magic Cookie             0x1A2B3C4D.
  716.  
  717.       Control Message Type     2 for Start-Control-Connection-Reply.
  718.  
  719.       Reserved0                This field MUST be 0.
  720.  
  721.       Protocol Version         The version of the PPTP protocol that the
  722.  
  723.  
  724.  
  725. Hamzeh, et al                                                  [Page 13]
  726.  
  727. Internet Draft              PPTP                   July 1997
  728.  
  729.  
  730.                                sender wishes to use.
  731.  
  732.       Result Code              Indicates the result of the command
  733.                                channel establishment attempt.  Current
  734.                                valid Result Code values are:
  735.  
  736.                                   1 - Successful channel establishment
  737.  
  738.                                   2 - General error -- Error Code
  739.                                       indicates the problem
  740.  
  741.                                   3 - Command channel already exists;
  742.  
  743.                                   4 - Requester is not authorized to
  744.                                       establish a command channel
  745.  
  746.                                   5 - The protocol version of the
  747.                                       requester is not supported
  748.  
  749.       Error Code               This field is set to 0 unless a "General
  750.                                Error" exists, in which case Result Code
  751.                                is set to 2 and this field is set to the
  752.                                value corresponding to the general error
  753.                                condition as specified in Section 2.16.
  754.  
  755.       Framing Capabilities     A set of bits indicating the type of
  756.                                framing that the sender of this message
  757.                                can provide.  The currently defined bit
  758.                                settings are:
  759.  
  760.                                   1 - Asynchronous Framing supported
  761.  
  762.                                   2 - Synchronous Framing supported.
  763.  
  764.       Bearer Capabilities      A set of bits indicating the bearer
  765.                                capabilities that the sender of this
  766.                                message can provide.  The currently
  767.                                defined bit settings are:
  768.  
  769.                                   1 - Analog access supported
  770.  
  771.                                   2 - Digital access supported
  772.  
  773.       Maximum Channels         The total number of individual PPP
  774.                                sessions this PAC can support.  In a
  775.                                Start-Control-Connection-Reply issued by
  776.                                the PNS, this value SHOULD be set to 0
  777.                                and it must be ignored by the PAC. The
  778.  
  779.  
  780.  
  781. Hamzeh, et al                                                  [Page 14]
  782.  
  783. Internet Draft              PPTP                   July 1997
  784.  
  785.  
  786.                                PNS MUST NOT use this value to try to
  787.                                track the remaining number of PPP
  788.                                sessions that the PAC will allow.
  789.  
  790.       Firmware Revision        This field contains the firmware revision
  791.                                number of the issuing PAC, or the version
  792.                                of the PNS PPTP driver if issued by the
  793.                                PNS.
  794.  
  795.       Host Name                A 64 octet field containing the DNS name
  796.                                of the issuing PAC or PNS.  If less than
  797.                                64 octets in length, the remainder of
  798.                                this field SHOULD be filled with octets
  799.                                of value 0.
  800.  
  801.       Vendor Name              A 64 octet field containing a vendor
  802.                                specific string describing the type of
  803.                                PAC being used, or the type of PNS
  804.                                software being used if this request is
  805.                                issued by the PNS.  If less than 64
  806.                                octets in length, the remainder of this
  807.                                field SHOULD be filled with octets of
  808.                                value 0.
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837. Hamzeh, et al                                                  [Page 15]
  838.  
  839. Internet Draft              PPTP                   July 1997
  840.  
  841.  
  842. 2.3 Stop-Control-Connection-Request
  843.  
  844.    The Stop-Control-Connection-Request is a PPTP control message sent by
  845.    one peer of a PAC-PNS control connection to inform the other peer
  846.    that the control connection should be closed.  In addition to closing
  847.    the control connection, all active user calls are implicitly cleared.
  848.    The reason for issuing this request is indicated in the Reason field.
  849.  
  850.        0                   1                   2                   3
  851.        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
  852.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  853.       |        Length          |       PPTP Message Type       |
  854.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  855.       |                         Magic Cookie                          |
  856.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  857.       |     Control Message Type      |           Reserved0           |
  858.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  859.       |    Reason     |   Reserved1   |           Reserved2           |
  860.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  861.  
  862.  
  863.  
  864.       Length                   Total length in octets of this PPTP
  865.                                message, including the entire PPTP
  866.                                header.
  867.  
  868.       PPTP Message Type        1 for Control Message.
  869.  
  870.       Magic Cookie             0x1A2B3C4D.
  871.  
  872.       Control Message Type     3 for Stop-Control-Connection-Request.
  873.  
  874.       Reserved0                This field MUST be 0.
  875.  
  876.       Reason                   Indicates the reason for the control
  877.                                connection being closed. Current valid
  878.                                Reason values are:
  879.  
  880.                                   1 (None) - General request to clear
  881.                                     control connection
  882.  
  883.                                   2 (Stop-Protocol) - Can't support
  884.                                     peer's version of the protocol
  885.  
  886.                                   3 (Stop-Local-Shutdown) - Requester is
  887.                                     being shut down
  888.  
  889.       Reserved1, Reserved2     These fields MUST be 0.
  890.  
  891.  
  892.  
  893. Hamzeh, et al                                                  [Page 16]
  894.  
  895. Internet Draft              PPTP                   July 1997
  896.  
  897.  
  898. 2.4 Stop-Control-Connection-Reply
  899.  
  900.    The Stop-Control-Connection-Reply is a PPTP control message sent by
  901.    one peer of a PAC-PNS control connection upon receipt of a Stop-
  902.    Control-Connection-Request from the other peer.
  903.  
  904.        0                   1                   2                   3
  905.        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
  906.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  907.       |            Length             |       PPTP Message Type       |
  908.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  909.       |                         Magic Cookie                          |
  910.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  911.       |     Control Message Type      |           Reserved0           |
  912.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  913.       |  Result Code  |   Error Code  |           Reserved1           |
  914.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  915.  
  916.  
  917.       Length                   Total length in octets of this PPTP
  918.                                message, including the entire PPTP
  919.                                header.
  920.  
  921.       PPTP Message Type        1 for Control Message.
  922.  
  923.       Magic Cookie             0x1A2B3C4D.
  924.  
  925.       Control Message Type     4 for Stop-Control-Connection-Reply.
  926.  
  927.       Reserved0                This field MUST be 0.
  928.  
  929.       Result Code              Indicates the result of the attempt to
  930.                                close the control connection. Current
  931.                                valid Result Code values are:
  932.  
  933.                                   1 (OK) - Control connection closed
  934.  
  935.                                   2 (General Error) - Control connection
  936.                                     not closed for reason indicated in
  937.                                     Error Code
  938.  
  939.       Error Code               This field is set to 0 unless a "General
  940.                                Error" exists, in which case Result Code
  941.                                is set to 2 and this field is set to the
  942.                                value corresponding to the general error
  943.                                condition as specified in Section 2.16.
  944.  
  945.       Reserved1                This field MUST be 0.
  946.  
  947.  
  948.  
  949. Hamzeh, et al                                                  [Page 17]
  950.  
  951. Internet Draft              PPTP                   July 1997
  952.  
  953.  
  954. 2.5 Echo-Request
  955.  
  956.    The Echo-Request is a PPTP control message sent by either peer of a
  957.    PAC-PNS control connection. This control message is used as a "keep-
  958.    Alive" for the control connection.  The receiving peer issues an
  959.    Echo-Reply to each Echo-Request received. As specified in Section 3,
  960.    if the sender does not receive an Echo Reply in response to an Echo-
  961.    Request, it will eventually clear the control connection.
  962.  
  963.        0                   1                   2                   3
  964.        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
  965.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  966.       |            Length             |       PPTP Message Type       |
  967.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  968.       |                         Magic Cookie                          |
  969.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  970.       |     Control Message Type      |           Reserved0           |
  971.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  972.       |                          Identifier                           |
  973.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  974.  
  975.  
  976.       Length                   Total length in octets of this PPTP
  977.                                message, including the entire PPTP
  978.                                header.
  979.  
  980.       PPTP Message Type        1 for Control Message.
  981.  
  982.       Magic Cookie             0x1A2B3C4D.
  983.  
  984.       Control Message Type     5 for Echo-Request.
  985.  
  986.       Reserved0                This field MUST be 0.
  987.  
  988.       Identifier               A value set by the sender of the Echo-
  989.                                Request that is used to match the reply
  990.                                with the corresponding request.
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005. Hamzeh, et al                                                  [Page 18]
  1006.  
  1007. Internet Draft              PPTP                   July 1997
  1008.  
  1009.  
  1010. 2.6 Echo-Reply
  1011.  
  1012.    The Echo-Reply is a PPTP control message sent by either peer of a
  1013.    PAC-PNS control connection in response to the receipt of an Echo-
  1014.    Request.
  1015.  
  1016.        0                   1                   2                   3
  1017.        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
  1018.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1019.       |            Length             |      PPTP Message Type        |
  1020.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1021.       |                         Magic Cookie                          |
  1022.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1023.       |     Control Message Type      |           Reserved0           |
  1024.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1025.       |                          Identifier                           |
  1026.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1027.       |  Result Code  |   Error Code  |           Reserved1           |
  1028.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1029.  
  1030.  
  1031.       Length                   Total length in octets of this PPTP
  1032.                                message, including the entire PPTP
  1033.                                header.
  1034.  
  1035.       PPTP Message Type        1 for Control Message.
  1036.  
  1037.       Magic Cookie             0x1A2B3C4D.
  1038.  
  1039.       Control Message Type     6 for Echo-Reply.
  1040.  
  1041.       Reserved0                This field MUST be 0.
  1042.  
  1043.       Identifier               The contents of the identify field from
  1044.                                the received Echo-Request is copied to
  1045.                                this field.
  1046.  
  1047.       Result Code              Indicates the result of the receipt of
  1048.                                the Echo-Request. Current valid Result
  1049.                                Code values are:
  1050.  
  1051.                                   1 (OK) - The Echo-Reply is valid
  1052.  
  1053.                                   2 (General Error) - Echo-Request not
  1054.                                     accepted for the reason indicated in
  1055.                                     Error Code
  1056.  
  1057.       Error Code               This field is set to 0 unless a "General
  1058.  
  1059.  
  1060.  
  1061. Hamzeh, et al                                                  [Page 19]
  1062.  
  1063. Internet Draft              PPTP                   July 1997
  1064.  
  1065.  
  1066.                                Error" condition exists, in which case
  1067.                                Result Code is set to 2 and this field is
  1068.                                set to the value corresponding to the
  1069.                                general error condition as specified in
  1070.                                Section 2.16.
  1071.  
  1072.       Reserved1                This field MUST be 0.
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117. Hamzeh, et al                                                  [Page 20]
  1118.  
  1119. Internet Draft              PPTP                   July 1997
  1120.  
  1121.  
  1122. 2.7 Outgoing-Call-Request
  1123.  
  1124.    The Outgoing-Call-Request is a PPTP control message sent by the PNS
  1125.    to the PAC to indicate that an outbound call from the PAC is to be
  1126.    established.  This request provides the PAC with information required
  1127.    to make the call. It also provides information to the PAC that is
  1128.    used to regulate the transmission of data to the PNS for this session
  1129.    once it is established.
  1130.  
  1131.        0                   1                   2                   3
  1132.        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
  1133.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1134.       |            Length             |       PPTP Message Type       |
  1135.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1136.       |                         Magic Cookie                          |
  1137.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1138.       |     Control Message Type      |           Reserved0           |
  1139.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1140.       |            Call ID            |      Call Serial Number       |
  1141.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1142.       |                          Minimum BPS                          |
  1143.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1144.       |                          Maximum BPS                          |
  1145.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1146.       |                          Bearer Type                          |
  1147.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1148.       |                         Framing Type                          |
  1149.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1150.       |   Packet Recv. Window Size    |    Packet Processing Delay    |
  1151.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1152.       |      Phone Number Length      |           Reserved1           |
  1153.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1154.       |                                                               |
  1155.       +                   Phone Number (64 octets)                    +
  1156.       |                                                               |
  1157.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1158.       |                                                               |
  1159.       +                    Subaddress (64 octets)                     +
  1160.       |                                                               |
  1161.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1162.  
  1163.  
  1164.       Length                   Total length in octets of this PPTP
  1165.                                message, including the entire PPTP
  1166.                                header.
  1167.  
  1168.       PPTP Message Type        1 for Control Message.
  1169.  
  1170.  
  1171.  
  1172.  
  1173. Hamzeh, et al                                                  [Page 21]
  1174.  
  1175. Internet Draft              PPTP                   July 1997
  1176.  
  1177.  
  1178.       Magic Cookie             0x1A2B3C4D.
  1179.  
  1180.       Control Message Type     7 for Outgoing-Call-Request.
  1181.  
  1182.       Reserved0                This field MUST be 0.
  1183.  
  1184.       Call ID                  A unique identifier, unique to a
  1185.                                particular PAC-PNS pair assigned by the
  1186.                                PNS to this session.  It is used to
  1187.                                multiplex and demultiplex data sent over
  1188.                                the tunnel between the PNS and PAC
  1189.                                involved in this session.
  1190.  
  1191.       Call Serial Number       An identifier assigned by the PNS to this
  1192.                                session for the purpose of identifying
  1193.                                this particular session in logged session
  1194.                                information.  Unlike the Call ID, both
  1195.                                the PNS and PAC associate the same Call
  1196.                                Serial Number with a given session. The
  1197.                                combination of IP address and call serial
  1198.                                number SHOULD be unique.
  1199.  
  1200.       Minimum BPS              The lowest acceptable line speed (in
  1201.                                bits/second) for this session.
  1202.  
  1203.       Maximum BPS              The highest acceptable line speed (in
  1204.                                bits/second) for this session.
  1205.  
  1206.       Bearer Type              A value indicating the bearer capability
  1207.                                required for this outgoing call.  The
  1208.                                currently defined values are:
  1209.  
  1210.                                   1 - Call to be placed on an analog
  1211.                                       channel
  1212.  
  1213.                                   2 - Call to be placed on a digital
  1214.                                       channel
  1215.  
  1216.                                   3 - Call can be placed on any type of
  1217.                                       channel
  1218.  
  1219.       Framing Type             A value indicating the type of PPP
  1220.                                framing to be used for this outgoing
  1221.                                call.
  1222.  
  1223.                                   1 - Call to use Asynchronous framing
  1224.  
  1225.                                   2 - Call to use Synchronous framing
  1226.  
  1227.  
  1228.  
  1229. Hamzeh, et al                                                  [Page 22]
  1230.  
  1231. Internet Draft              PPTP                   July 1997
  1232.  
  1233.  
  1234.                                   3 - Call can use either type of
  1235.                                       framing
  1236.  
  1237.       Packet Recv. Window Size The number of received data packets the
  1238.                                PNS will buffer for this session.
  1239.  
  1240.       Packet Processing Delay  A measure of the packet processing delay
  1241.                                that might be imposed on data sent to the
  1242.                                PNS from the PAC.  This value is
  1243.                                specified in units of 1/10 seconds.  For
  1244.                                the PNS this number should be very small.
  1245.                                See appendix A for a description of how
  1246.                                this value is determined and used.
  1247.  
  1248.       Phone Number Length      The actual number of valid digits in the
  1249.                                Phone Number field.
  1250.  
  1251.       Reserved1                This field MUST be 0.
  1252.  
  1253.       Phone Number             The number to be dialed to establish the
  1254.                                outgoing session.  For ISDN and analog
  1255.                                calls this field is an ASCII string.  If
  1256.                                the Phone Number is less than 64 octets
  1257.                                in length, the remainder of this field is
  1258.                                filled with octets of value 0.
  1259.  
  1260.       Subaddress               A 64 octet field used to specify
  1261.                                additional dialing information.  If the
  1262.                                subaddress is less than 64 octets long,
  1263.                                the remainder of this field is filled
  1264.                                with octets of value 0.
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285. Hamzeh, et al                                                  [Page 23]
  1286.  
  1287. Internet Draft              PPTP                   July 1997
  1288.  
  1289.  
  1290. 2.8 Outgoing-Call-Reply
  1291.  
  1292.    The Outgoing-Call-Reply is a PPTP control message sent by the PAC to
  1293.    the PNS in response to a received Outgoing-Call-Request message.  The
  1294.    reply indicates the result of the outgoing call attempt.  It also
  1295.    provides information to the PNS about particular parameters used for
  1296.    the call.  It provides information to allow the PNS to regulate the
  1297.    transmission of data to the PAC for this session.
  1298.  
  1299.        0                   1                   2                   3
  1300.        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
  1301.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1302.       |            Length             |      PPTP Message Type        |
  1303.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1304.       |                         Magic Cookie                          |
  1305.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1306.       |     Control Message Type      |           Reserved0           |
  1307.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1308.       |            Call ID            |       Peer's Call ID          |
  1309.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1310.       |  Result Code  |  Error Code   |          Cause Code           |
  1311.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1312.       |                         Connect Speed                         |
  1313.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1314.       |   Packet Recv. Window Size    |    Packet Processing Delay    |
  1315.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1316.       |                      Physical Channel ID                      |
  1317.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1318.  
  1319.  
  1320.       Length                   Total length in octets of this PPTP
  1321.                                message, including the entire PPTP
  1322.                                header.
  1323.  
  1324.       PPTP Message Type        1 for Control Message.
  1325.  
  1326.       Magic Cookie             0x1A2B3C4D.
  1327.  
  1328.       Control Message Type     8 for Outgoing-Call-Reply.
  1329.  
  1330.       Reserved0                This field MUST be 0.
  1331.  
  1332.       Call ID                  A unique identifier for the tunnel,
  1333.                                assigned by the PAC to this session.  It
  1334.                                is used to multiplex and demultiplex data
  1335.                                sent over the tunnel between the PNS and
  1336.                                PAC involved in this session.
  1337.  
  1338.  
  1339.  
  1340.  
  1341. Hamzeh, et al                                                  [Page 24]
  1342.  
  1343. Internet Draft              PPTP                   July 1997
  1344.  
  1345.  
  1346.       Peer's Call ID           This field is set to the value received
  1347.                                in the Call ID field of the corresponding
  1348.                                Outgoing-Call-Request message.  It is
  1349.                                used by the PNS to match the Outgoing-
  1350.                                Call-Reply with the Outgoing-Call-Request
  1351.                                it issued. It also is used as the value
  1352.                                sent in the GRE header for mux/demuxing.
  1353.  
  1354.       Result Code              This value indicates the result of the
  1355.                                Outgoing-Call-Request attempt.  Currently
  1356.                                valid values are:
  1357.  
  1358.                                   1 (Connected) - Call established with
  1359.                                     no errors
  1360.  
  1361.                                   2 (General Error) - Outgoing Call not
  1362.                                     established for the reason indicated
  1363.                                     in Error Code
  1364.  
  1365.                                   3 (No Carrier) - Outgoing Call failed
  1366.                                     due to no carrier detected
  1367.  
  1368.                                   4 (Busy) - Outgoing Call failed due to
  1369.                                     detection of a busy signal
  1370.  
  1371.                                   5 (No Dial Tone) - Outgoing Call
  1372.                                     failed due to lack of a dial tone
  1373.  
  1374.                                   6 (Time-out) - Outgoing Call was not
  1375.                                     established within time allotted by
  1376.                                     PAC
  1377.  
  1378.                                   7 (Do Not Accept) - Outgoing Call
  1379.                                     administratively prohibited
  1380.  
  1381.       Error Code               This field is set to 0 unless a "General
  1382.                                Error" condition exists, in which case
  1383.                                Result Code is set to 2 and this field is
  1384.                                set to the value corresponding to the
  1385.                                general error condition as specified in
  1386.                                Section 2.16.
  1387.  
  1388.       Cause Code               This field gives additional failure
  1389.                                information.  Its value can vary
  1390.                                depending upon the type of call
  1391.                                attempted.  For ISDN call attempts it is
  1392.                                the Q.931 cause code.
  1393.  
  1394.  
  1395.  
  1396.  
  1397. Hamzeh, et al                                                  [Page 25]
  1398.  
  1399. Internet Draft              PPTP                   July 1997
  1400.  
  1401.  
  1402.       Connect Speed            The actual connection speed used, in
  1403.                                bits/second.
  1404.  
  1405.       Packet Recv. Window Size The number of received data packets the
  1406.                                PAC will buffer for this session.
  1407.  
  1408.       Packet Processing Delay  A measure of the packet processing delay
  1409.                                that might be imposed on data sent to the
  1410.                                PAC from the PNS.  This value is
  1411.                                specified in units of 1/10 seconds.  For
  1412.                                the PAC, this number is related to the
  1413.                                size of the buffer used to hold packets
  1414.                                to be sent to the client and to the speed
  1415.                                of the link to the client.  This value
  1416.                                should be set to the maximum delay that
  1417.                                can normally occur between the time a
  1418.                                packet arrives at the PAC and is
  1419.                                delivered to the client.  See Appendix A
  1420.                                for an example of how this value is
  1421.                                determined and used.
  1422.  
  1423.       Physical Channel ID      This field is set by the PAC in a
  1424.                                vendor-specific manner to the physical
  1425.                                channel number used to place this call.
  1426.                                It is used for logging purposes only.
  1427.  
  1428.  
  1429.  
  1430.  
  1431.  
  1432.  
  1433.  
  1434.  
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453. Hamzeh, et al                                                  [Page 26]
  1454.  
  1455. Internet Draft              PPTP                   July 1997
  1456.  
  1457.  
  1458. 2.9 Incoming-Call-Request
  1459.  
  1460.    The Incoming-Call-Request is a PPTP control message sent by the PAC
  1461.    to the PNS to indicate that an inbound call is to be established from
  1462.    the PAC.  This request provides the PNS with parameter information
  1463.    for the incoming call.
  1464.  
  1465.    This message is the first in the "three-way handshake" used by PPTP
  1466.    for establishing incoming calls.  The PAC may defer answering the
  1467.    call until it has received an Incoming-Call-Reply from the PNS
  1468.    indicating that the call should be established. This mechanism allows
  1469.    the PNS to obtain sufficient information about the call before it is
  1470.    answered to determine whether the call should be answered or not.
  1471.  
  1472.        0                   1                   2                   3
  1473.        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
  1474.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1475.       |            Length             |       PPTP Message Type       |
  1476.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1477.       |                         Magic Cookie                          |
  1478.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1479.       |     Control Message Type      |           Reserved0           |
  1480.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1481.       |            Call ID            |      Call Serial Number       |
  1482.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1483.       |                       Call Bearer Type                        |
  1484.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1485.       |                      Physical Channel ID                      |
  1486.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1487.       |     Dialed Number Length      |     Dialing Number Length     |
  1488.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1489.       |                                                               |
  1490.       +                   Dialed Number (64 octets)                   +
  1491.       |                                                               |
  1492.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1493.       |                                                               |
  1494.       +                  Dialing Number (64 octets)                   +
  1495.       |                                                               |
  1496.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1497.       |                                                               |
  1498.       +                    Subaddress (64 octets)                     +
  1499.       |                                                               |
  1500.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1501.  
  1502.  
  1503.       Length                   Total length in octets of this PPTP
  1504.                                message, including the entire PPTP
  1505.                                header.
  1506.  
  1507.  
  1508.  
  1509. Hamzeh, et al                                                  [Page 27]
  1510.  
  1511. Internet Draft              PPTP                   July 1997
  1512.  
  1513.  
  1514.       PPTP Message Type        1 for Control Message.
  1515.  
  1516.       Magic Cookie             0x1A2B3C4D.
  1517.  
  1518.       Control Message Type     9 for Incoming-Call-Request.
  1519.  
  1520.       Reserved0                This field MUST be 0.
  1521.  
  1522.       Call ID                  A unique identifier for this tunnel,
  1523.                                assigned by the PAC to this session.  It
  1524.                                is used to multiplex and demultiplex data
  1525.                                sent over the tunnel between the PNS and
  1526.                                PAC involved in this session.
  1527.  
  1528.       Call Serial Number       An identifier assigned by the PAC to this
  1529.                                session for the purpose of identifying
  1530.                                this particular session in logged session
  1531.                                information.  Unlike the Call ID, both
  1532.                                the PNS and PAC associate the same Call
  1533.                                Serial Number to a given session. The
  1534.                                combination of IP address and call serial
  1535.                                number should be unique.
  1536.  
  1537.       Bearer Type              A value indicating the bearer capability
  1538.                                used for this incoming call.  Currently
  1539.                                defined values are:
  1540.  
  1541.                                   1 - Call is on an analog channel
  1542.  
  1543.                                   2 - Call is on a digital channel
  1544.  
  1545.       Physical Channel ID      This field is set by the PAC in a
  1546.                                vendor-specific manner to the number of
  1547.                                the physical channel this call arrived
  1548.                                on.
  1549.  
  1550.       Dialed Number Length     The actual number of valid digits in the
  1551.                                Dialed Number field.
  1552.  
  1553.       Dialing Number Length    The actual number of valid digits in the
  1554.                                Dialing Number field.
  1555.  
  1556.       Dialed Number            The number that was dialed by the caller.
  1557.                                For ISDN and analog calls this field is
  1558.                                an ASCII string.  If the Dialed Number is
  1559.                                less than 64 octets in length, the
  1560.                                remainder of this field is filled with
  1561.                                octets of value 0.
  1562.  
  1563.  
  1564.  
  1565. Hamzeh, et al                                                  [Page 28]
  1566.  
  1567. Internet Draft              PPTP                   July 1997
  1568.  
  1569.  
  1570.       Dialing Number           The number from which the call was
  1571.                                placed.  For ISDN and analog calls this
  1572.                                field is an ASCII string.  If the Dialing
  1573.                                Number is less than 64 octets in length,
  1574.                                the remainder of this field is filled
  1575.                                with octets of value 0.
  1576.  
  1577.       Subaddress               A 64 octet field used to specify
  1578.                                additional dialing information.  If the
  1579.                                subaddress is less than 64 octets long,
  1580.                                the remainder of this field is filled
  1581.                                with octets of value 0.
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592.  
  1593.  
  1594.  
  1595.  
  1596.  
  1597.  
  1598.  
  1599.  
  1600.  
  1601.  
  1602.  
  1603.  
  1604.  
  1605.  
  1606.  
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621. Hamzeh, et al                                                  [Page 29]
  1622.  
  1623. Internet Draft              PPTP                   July 1997
  1624.  
  1625.  
  1626. 2.10 Incoming-Call-Reply
  1627.  
  1628.    The Incoming-Call-Reply is a PPTP control message sent by the PNS to
  1629.    the PAC in response to a received Incoming-Call-Request message.  The
  1630.    reply indicates the result of the incoming call attempt.  It also
  1631.    provides information to allow the PAC to regulate the transmission of
  1632.    data to the PNS for this session.
  1633.  
  1634.    This message is the second in the three-way handshake used by PPTP
  1635.    for establishing incoming calls.  It indicates to the PAC whether the
  1636.    call should be answered or not.
  1637.  
  1638.        0                   1                   2                   3
  1639.        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
  1640.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1641.       |            Length             |       PPTP Message Type       |
  1642.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1643.       |                         Magic Cookie                          |
  1644.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1645.       |     Control Message Type      |           Reserved0           |
  1646.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1647.       |            Call ID            |       Peer's Call ID          |
  1648.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1649.       |  Result Code  |  Error Code   |   Packet Recv. Window Size    |
  1650.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1651.       |     Packet Transmit Delay     |           Reserved1           |
  1652.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1653.  
  1654.  
  1655.       Length                   Total length in octets of this PPTP
  1656.                                message, including the entire PPTP
  1657.                                header.
  1658.  
  1659.       PPTP Message Type        1 for Control Message.
  1660.  
  1661.       Magic Cookie             0x1A2B3C4D.
  1662.  
  1663.       Control Message Type     10 for Incoming-Call-Reply.
  1664.  
  1665.       Reserved0                This field MUST be 0.
  1666.  
  1667.       Call ID                  A unique identifier for this tunnel
  1668.                                assigned by the PAC to this session.  It
  1669.                                is used to multiplex and demultiplex data
  1670.                                sent over the tunnel between the PNS and
  1671.                                PAC involved in this session.
  1672.  
  1673.       Peer's Call ID           This field is set to the value received
  1674.  
  1675.  
  1676.  
  1677. Hamzeh, et al                                                  [Page 30]
  1678.  
  1679. Internet Draft              PPTP                   July 1997
  1680.  
  1681.  
  1682.                                in the Call ID field of the corresponding
  1683.                                Incoming-Call-Request message. It is used
  1684.                                by the PAC to match the Incoming-Call-
  1685.                                Reply with the Incoming-Call-Request it
  1686.                                issued. This value is included in the GRE
  1687.                                header of transmitted data packets for
  1688.                                this session.
  1689.  
  1690.       Result Code              This value indicates the result of the
  1691.                                Incoming-Call-Request attempt.  Current
  1692.                                valid Result Code values are:
  1693.  
  1694.                                   1 (Connect) - The PAC should answer
  1695.                                     the incoming call
  1696.  
  1697.                                   2 (General Error) - The Incoming Call
  1698.                                     should not be established due to the
  1699.                                     reason indicated in Error Code
  1700.  
  1701.                                   3 (Do Not Accept) - The PAC should not
  1702.                                     accept the incoming call.  It should
  1703.                                     hang up or issue a busy indication
  1704.  
  1705.       Error Code               This field is set to 0 unless a "General
  1706.                                Error" condition exists, in which case
  1707.                                Result Code is set to 2 and this field is
  1708.                                set to the value corresponding to the
  1709.                                general error condition as specified in
  1710.                                Section 2.16.
  1711.  
  1712.       Packet Recv. Window Size The number of received data packets the
  1713.                                PAC will buffer for this session.
  1714.  
  1715.       Packet Transmit Delay    A measure of the packet processing delay
  1716.                                that might be imposed on data sent to the
  1717.                                PAC from the PNS.  This value is
  1718.                                specified in units of 1/10 seconds.  See
  1719.                                Appendix A for a description of how this
  1720.                                value is determined and used.
  1721.  
  1722.       Reserved1                This field MUST be 0.
  1723.  
  1724.  
  1725.  
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733. Hamzeh, et al                                                  [Page 31]
  1734.  
  1735. Internet Draft              PPTP                   July 1997
  1736.  
  1737.  
  1738. 2.11 Incoming-Call-Connected
  1739.  
  1740.    The Incoming-Call-Connected message is a PPTP control message sent by
  1741.    the PAC to the PNS in response to a received Incoming-Call-Reply.  It
  1742.    provides information to the PNS about particular parameters used for
  1743.    the call.  It also provides information to allow the PNS to regulate
  1744.    the transmission of data to the PAC for this session.
  1745.  
  1746.    This message is the third in the three-way handshake used by PPTP for
  1747.    establishing incoming calls.  It provides a mechanism for providing
  1748.    the PNS with additional information about the call that cannot, in
  1749.    general, be obtained at the time the Incoming-Call-Request is issued
  1750.    by the PAC.
  1751.  
  1752.        0                   1                   2                   3
  1753.        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
  1754.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1755.       |            Length             |      PPTP Message Type        |
  1756.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1757.       |                         Magic Cookie                          |
  1758.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1759.       |     Control Message Type      |           Reserved0           |
  1760.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1761.       |       Peer's Call ID          |           Reserved1           |
  1762.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1763.       |                         Connect Speed                         |
  1764.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1765.       |   Packet Recv. Window Size    |     Packet Transmit Delay     |
  1766.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1767.       |                         Framing Type                          |
  1768.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1769.  
  1770.  
  1771.       Length                   Total length in octets of this PPTP
  1772.                                message, including the entire PPTP
  1773.                                header.
  1774.  
  1775.       PPTP Message Type        1 for Control Message.
  1776.  
  1777.       Magic Cookie             0x1A2B3C4D.
  1778.  
  1779.       Control Message Type     11 for Incoming-Call-Connected.
  1780.  
  1781.       Reserved0                This field MUST be 0.
  1782.  
  1783.       Peer's Call ID           This field is set to the value received
  1784.                                in the Call ID field of the corresponding
  1785.                                Incoming-Call-Reply message.  It is used
  1786.  
  1787.  
  1788.  
  1789. Hamzeh, et al                                                  [Page 32]
  1790.  
  1791. Internet Draft              PPTP                   July 1997
  1792.  
  1793.  
  1794.                                by the PNS to match the Incoming-Call-
  1795.                                Connected with the Incoming-Call-Reply it
  1796.                                issued.
  1797.  
  1798.       Connect Speed            The actual connection speed used, in
  1799.                                bits/second.
  1800.  
  1801.       Packet Recv. Window Size The number of received data packets the
  1802.                                PAC will buffer for this session.
  1803.  
  1804.       Packet Transmit Delay    A measure of the packet processing delay
  1805.                                that might be imposed on data sent to the
  1806.                                PAC from the PNS.  This value is
  1807.                                specified in units of 1/10 seconds.  See
  1808.                                Appendix A for a description of how this
  1809.                                value is determined and used.
  1810.  
  1811.       Framing Type             A value indicating the type of PPP
  1812.                                framing being used by this incoming call.
  1813.  
  1814.                                   1 - Call uses asynchronous framing
  1815.  
  1816.                                   2 - Call uses synchronous framing
  1817.  
  1818.  
  1819.  
  1820.  
  1821.  
  1822.  
  1823.  
  1824.  
  1825.  
  1826.  
  1827.  
  1828.  
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845. Hamzeh, et al                                                  [Page 33]
  1846.  
  1847. Internet Draft              PPTP                   July 1997
  1848.  
  1849.  
  1850. 2.12 Call-Clear-Request
  1851.  
  1852.    The Call-Clear-Request is a PPTP control message sent by the PNS to
  1853.    the PAC indicating that a particular call is to be disconnected.  The
  1854.    call being cleared can be either an incoming or outgoing call, in any
  1855.    state.  The PAC responds to this message with a Call-Disconnect-
  1856.    Notify message.
  1857.  
  1858.        0                   1                   2                   3
  1859.        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
  1860.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1861.       |            Length             |      PPTP Message Type        |
  1862.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1863.       |                         Magic Cookie                          |
  1864.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1865.       |     Control Message Type      |           Reserved0           |
  1866.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1867.       |            Call ID            |           Reserved1           |
  1868.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1869.  
  1870.  
  1871.       Length                   Total length in octets of this PPTP
  1872.                                message, including the entire PPTP
  1873.                                header.
  1874.  
  1875.       PPTP Message Type        1 for Control Message.
  1876.  
  1877.       Magic Cookie             0x1A2B3C4D.
  1878.  
  1879.       Control Message Type     12 for Call-Clear-Request.
  1880.  
  1881.       Reserved0                This field MUST be 0.
  1882.  
  1883.       Call ID                  The Call ID assigned by the PNS to this
  1884.                                call.  This value is used instead of the
  1885.                                Peer's Call ID because the latter may not
  1886.                                be known to the PNS if the call must be
  1887.                                aborted during call establishment.
  1888.  
  1889.       Reserved1                This field MUST be 0.
  1890.  
  1891.  
  1892.  
  1893.  
  1894.  
  1895.  
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901. Hamzeh, et al                                                  [Page 34]
  1902.  
  1903. Internet Draft              PPTP                   July 1997
  1904.  
  1905.  
  1906. 2.13 Call-Disconnect-Notify
  1907.  
  1908.    The Call-Disconnect-Notify message is a PPTP control message sent by
  1909.    the PAC to the PNS.  It is issued whenever a call is disconnected,
  1910.    due to the receipt by the PAC of a Call-Clear-Request or for any
  1911.    other reason.  Its purpose is to inform the PNS of both the
  1912.    disconnection and the reason for it.
  1913.  
  1914.        0                   1                   2                   3
  1915.        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
  1916.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1917.       |            Length             |      PPTP Message Type        |
  1918.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1919.       |                         Magic Cookie                          |
  1920.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1921.       |     Control Message Type      |           Reserved0           |
  1922.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1923.       |            Call ID            |  Result Code  |  Error Code   |
  1924.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1925.       |          Cause Code           |           Reserved1           |
  1926.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1927.       |                                                               |
  1928.       +              Call Statistics (128 octets)                     +
  1929.       |                                                               |
  1930.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1931.  
  1932.  
  1933.       Length                   Total length in octets of this PPTP
  1934.                                message, including the entire PPTP
  1935.                                header.
  1936.  
  1937.       PPTP Message Type        1 for Control Message.
  1938.  
  1939.       Magic Cookie             0x1A2B3C4D.
  1940.  
  1941.       Control Message Type     13 for Call-Disconnect-Notify.
  1942.  
  1943.       Reserved0                This field MUST be 0.
  1944.  
  1945.       Call ID                  The value of the Call ID assigned by the
  1946.                                PAC to this call.  This value is used
  1947.                                instead of the Peer's Call ID because the
  1948.                                latter may not be known to the PNS if the
  1949.                                call must be aborted during call
  1950.                                establishment.
  1951.  
  1952.       Result Code              This value indicates the reason for the
  1953.                                disconnect. Current valid Result Code
  1954.  
  1955.  
  1956.  
  1957. Hamzeh, et al                                                  [Page 35]
  1958.  
  1959. Internet Draft              PPTP                   July 1997
  1960.  
  1961.  
  1962.                                values are:
  1963.  
  1964.                                   1 (Lost Carrier) - Call disconnected
  1965.                                     due to loss of carrier
  1966.  
  1967.                                   2 (General Error) - Call disconnected
  1968.                                     for the reason indicated in Error
  1969.                                     Code
  1970.  
  1971.                                   3 (Admin Shutdown) - Call disconnected
  1972.                                     for administrative reasons
  1973.  
  1974.                                   4 (Request) - Call disconnected due to
  1975.                                     received Call-Clear-Request
  1976.  
  1977.       Error Code               This field is set to 0 unless a "General
  1978.                                Error" condition exists, in which case
  1979.                                the Result Code is set to 2 and this
  1980.                                field is set to the value corresponding
  1981.                                to the general error condition as
  1982.                                specified in Section 2.16.
  1983.  
  1984.       Cause Code               This field gives additional disconnect
  1985.                                information.  Its value varies depending
  1986.                                on the type of call being disconnected.
  1987.                                For ISDN calls it is the Q.931 cause
  1988.                                code.
  1989.  
  1990.       Call Statistics          This field is an ASCII string containing
  1991.                                vendor-specific call statistics that can
  1992.                                be logged for diagnostic purposes.  If
  1993.                                the length of the string is less than
  1994.                                128, the remainder of the field is filled
  1995.                                with octets of value 0.
  1996.  
  1997.  
  1998.  
  1999.  
  2000.  
  2001.  
  2002.  
  2003.  
  2004.  
  2005.  
  2006.  
  2007.  
  2008.  
  2009.  
  2010.  
  2011.  
  2012.  
  2013. Hamzeh, et al                                                  [Page 36]
  2014.  
  2015. Internet Draft              PPTP                   July 1997
  2016.  
  2017.  
  2018. 2.14 WAN-Error-Notify
  2019.  
  2020.    The WAN-Error-Notify message is a PPTP control message sent by the
  2021.    PAC to the PNS to indicate WAN error conditions (conditions that
  2022.    occur on the interface supporting PPP).  The counters in this message
  2023.    are cumulative.  This message should only be sent when an error
  2024.    occurs, and not more than once every 60 seconds.  The counters are
  2025.    reset when a new call is established.
  2026.  
  2027.        0                   1                   2                   3
  2028.        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
  2029.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2030.       |            Length             |      PPTP Message Type        |
  2031.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2032.       |                         Magic Cookie                          |
  2033.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2034.       |     Control Message type      |           Reserved0           |
  2035.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2036.       |        Peer's Call ID         |           Reserved1           |
  2037.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2038.       |                          CRC Errors                           |
  2039.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2040.       |                        Framing Errors                         |
  2041.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2042.       |                       Hardware Overruns                       |
  2043.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2044.       |                        Buffer Overruns                        |
  2045.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2046.       |                        Time-out Errors                        |
  2047.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2048.       |                       Alignment Errors                        |
  2049.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2050.  
  2051.  
  2052.       Length                   Total length in octets of this PPTP
  2053.                                message, including the entire PPTP
  2054.                                header.
  2055.  
  2056.       PPTP Message Type        1 for Control Message.
  2057.  
  2058.       Magic Cookie             0x1A2B3C4D.
  2059.  
  2060.       Control Message Type     14 for WAN-Error-Notify.
  2061.  
  2062.       Reserved0                This field MUST be 0.
  2063.  
  2064.       Peer's Call ID           Th Call ID assigned by the PNS to this
  2065.                                call.
  2066.  
  2067.  
  2068.  
  2069. Hamzeh, et al                                                  [Page 37]
  2070.  
  2071. Internet Draft              PPTP                   July 1997
  2072.  
  2073.  
  2074.       CRC Errors               Number of PPP frames received with CRC
  2075.                                errors since session was established.
  2076.  
  2077.       Framing Errors           Number of improperly framed PPP packets
  2078.                                received.
  2079.  
  2080.       Hardware Overruns        Number of receive buffer over-runs since
  2081.                                session was established.
  2082.  
  2083.       Buffer Overruns          Number of buffer over-runs detected since
  2084.                                session was established.
  2085.  
  2086.       Time-out Errors          Number of time-outs since call was
  2087.                                established.
  2088.  
  2089.       Alignment Errors         Number of alignment errors since call was
  2090.                                established.
  2091.  
  2092.  
  2093.  
  2094.  
  2095.  
  2096.  
  2097.  
  2098.  
  2099.  
  2100.  
  2101.  
  2102.  
  2103.  
  2104.  
  2105.  
  2106.  
  2107.  
  2108.  
  2109.  
  2110.  
  2111.  
  2112.  
  2113.  
  2114.  
  2115.  
  2116.  
  2117.  
  2118.  
  2119.  
  2120.  
  2121.  
  2122.  
  2123.  
  2124.  
  2125. Hamzeh, et al                                                  [Page 38]
  2126.  
  2127. Internet Draft              PPTP                   July 1997
  2128.  
  2129.  
  2130. 2.15 Set-Link-Info
  2131.  
  2132.    The Set-Link-Info message is a PPTP control message sent by the PNS
  2133.    to the PAC to set PPP-negotiated options.  Because these options can
  2134.    change at any time during the life of the call, the PAC must be able
  2135.    to update its internal call information dynamically and perform PPP
  2136.    negotiation on an active PPP session.
  2137.  
  2138.        0                   1                   2                   3
  2139.        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
  2140.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2141.       |            Length             |      PPTP Message Type        |
  2142.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2143.       |                         Magic Cookie                          |
  2144.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2145.       |     Control Message type      |           Reserved0           |
  2146.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2147.       |        Peer's Call ID         |           Reserved1           |
  2148.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2149.       |                           Send ACCM                           |
  2150.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2151.       |                         Receive ACCM                          |
  2152.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2153.  
  2154.  
  2155.       Length                   Total length in octets of this PPTP
  2156.                                message, including the entire PPTP
  2157.                                header.
  2158.  
  2159.       PPTP Message Type        1 for Control Message.
  2160.  
  2161.       Magic Cookie             0x1A2B3C4D.
  2162.  
  2163.       Control Message Type     15 for Set-Link-Info.
  2164.  
  2165.       Reserved0                This field MUST be 0.
  2166.  
  2167.       Peer's Call ID           The value of the Call ID assigned by the
  2168.                                PAC to this call.
  2169.  
  2170.       Reserved1                This field MUST be 0.
  2171.  
  2172.       Send ACCM                The send ACCM value the client should use
  2173.                                to process outgoing PPP packets.  The
  2174.                                default value used by the client until
  2175.                                this message is received is 0XFFFFFFFF.
  2176.                                See [7].
  2177.  
  2178.  
  2179.  
  2180.  
  2181. Hamzeh, et al                                                  [Page 39]
  2182.  
  2183. Internet Draft              PPTP                   July 1997
  2184.  
  2185.  
  2186.       Receive ACCM             The receive ACCM value the client should
  2187.                                use to process incoming PPP packets. The
  2188.                                default value used by the client until
  2189.                                this message is received is 0XFFFFFFFF.
  2190.                                See [7].
  2191.  
  2192.  
  2193.  
  2194.  
  2195.  
  2196.  
  2197.  
  2198.  
  2199.  
  2200.  
  2201.  
  2202.  
  2203.  
  2204.  
  2205.  
  2206.  
  2207.  
  2208.  
  2209.  
  2210.  
  2211.  
  2212.  
  2213.  
  2214.  
  2215.  
  2216.  
  2217.  
  2218.  
  2219.  
  2220.  
  2221.  
  2222.  
  2223.  
  2224.  
  2225.  
  2226.  
  2227.  
  2228.  
  2229.  
  2230.  
  2231.  
  2232.  
  2233.  
  2234.  
  2235.  
  2236.  
  2237. Hamzeh, et al                                                  [Page 40]
  2238.  
  2239. Internet Draft              PPTP                   July 1997
  2240.  
  2241.  
  2242. 2.16 General Error Codes
  2243.  
  2244.    General error codes pertain to types of errors which are not specific
  2245.    to any particular PPTP request, but rather to protocol or message
  2246.    format errors.  If a PPTP reply indicates in its Result Code that a
  2247.    general error occurred, the General Error value should be examined to
  2248.    determined what the error was.  The currently defined General Error
  2249.    codes and their meanings are:
  2250.  
  2251.       0 (None)          - No general error
  2252.  
  2253.       1 (Not-Connected) - No control connection exists yet for this
  2254.                           PAC-PNS pair
  2255.  
  2256.       2 (Bad-Format)    - Length is wrong or Magic Cookie value is
  2257.                           incorrect
  2258.  
  2259.       3 (Bad-Value)     - One of the field values was out of range or
  2260.                           reserved field was non-zero
  2261.  
  2262.       4 (No-Resource)   - Insufficient resources to handle this command
  2263.                           now
  2264.  
  2265.       5 (Bad-Call ID)    - The Call ID is invalid in this context
  2266.  
  2267.       6 (PAC-Error)     - A generic vendor-specific error occurred in
  2268.                           the PAC
  2269.  
  2270.  
  2271.  
  2272.  
  2273.  
  2274.  
  2275.  
  2276.  
  2277.  
  2278.  
  2279.  
  2280.  
  2281.  
  2282.  
  2283.  
  2284.  
  2285.  
  2286.  
  2287.  
  2288.  
  2289.  
  2290.  
  2291.  
  2292.  
  2293. Hamzeh, et al                                                  [Page 41]
  2294.  
  2295. Internet Draft              PPTP                   July 1997
  2296.  
  2297.  
  2298. 3.0 Control Connection Protocol Operation
  2299.  
  2300.    This section describes the operation of various PPTP control
  2301.    connection functions and the Control Connection messages which are
  2302.    used to support them.  The protocol operation of the control
  2303.    connection is simplified because TCP is used to provide a reliable
  2304.    transport mechanism.
  2305.     Ordering and retransmission of messages is not a concern at this
  2306.    level.  The TCP connection itself, however, can close at any time and
  2307.    an appropriate error recovery mechanism must be provided to handle
  2308.    this case.
  2309.  
  2310.    Some error recovery procedures are common to all states of the
  2311.    control connection.  If an expected reply does not arrive within 60
  2312.    seconds, the control connection is closed, unless otherwise
  2313.    specified.  Appropriate logging should be implemented for easy
  2314.    determination of the problems and the reasons for closing the control
  2315.    connection.
  2316.  
  2317.    Receipt of an invalid or malformed Control Connection message should
  2318.    be logged appropriately, and the control connection should be closed
  2319.    and restarted to ensure recovery into a known state.
  2320.  
  2321.  
  2322. 3.1 Control Connection States
  2323.  
  2324.    The control connection relies on a standard TCP connection for its
  2325.    service.  The PPTP control connection protocol is not distinguishable
  2326.    between the PNS and PAC, but is distinguishable between the
  2327.    originator and receiver. The originating peer is the one which first
  2328.    attempts the TCP open. Since either PAC or PNS may originate a
  2329.    connection, it is possible for a TCP collision to occur.  See Section
  2330.    3.1.3 for a description of this situation.
  2331.  
  2332.  
  2333.  
  2334.  
  2335.  
  2336.  
  2337.  
  2338.  
  2339.  
  2340.  
  2341.  
  2342.  
  2343.  
  2344.  
  2345.  
  2346.  
  2347.  
  2348.  
  2349. Hamzeh, et al                                                  [Page 42]
  2350.  
  2351. Internet Draft              PPTP                   July 1997
  2352.  
  2353.  
  2354. 3.1.1 Control Connection Originator (may be PAC or PNS)
  2355.  
  2356.                       TCP Open Indication
  2357.                       /Send Start Control
  2358.                         Connection Request       +-----------------+
  2359.            +------------------------------------>|  wait_ctl_reply |
  2360.            |                                     +-----------------+
  2361.            |     Collision/See (3.1.3) Close TCP   V  V  V   Receive Start Ctl
  2362.            |       +-------------------------------+  |  |   Connection Reply
  2363.            |       |                                  |  |   Version OK
  2364.            ^       V                                  |  V
  2365.    +-----------------+             Receive Start Ctl  | +-----------------+
  2366.    |      idle       |             Connection Reply   | |   established   |
  2367.    +-----------------+             Version Not OK     | +-----------------+
  2368.            ^                                          |  V   Local Terminate
  2369.            |         Receive Stop Control             |  |   /Send Stop
  2370.            |         Connection Request               |  |    Control Request
  2371.            |         /Send Stop Control Reply         V  V
  2372.            |          Close TCP                  +-----------------+
  2373.            +-------------------------------------| wait_stop_reply |
  2374.                                                  +-----------------+
  2375.  
  2376.  
  2377.  
  2378.    idle
  2379.  
  2380.    The control connection originator attempts to open a TCP connection
  2381.    to the peer during idle state. When the TCP connection is open, the
  2382.    originator transmits a send Start-Control-Connection-Request and then
  2383.    enters the wait_ctl_reply state.
  2384.  
  2385.    wait_ctl_reply
  2386.  
  2387.    The originator checks to see if another TCP connection has been
  2388.    requested from the same peer, and if so, handles the collision
  2389.    situation described in Section 3.1.3.
  2390.  
  2391.    When a Start-Control-Connection-Reply is received, it is examined for
  2392.    a compatible version. If the version of the reply is lower than the
  2393.    version sent in the request, the older (lower) version should be used
  2394.    provided it is supported.  If the version in the reply is earlier and
  2395.    supported, the originator moves to the established state. If the
  2396.    version is earlier and not supported, a Stop-Control-Connection-
  2397.    Request SHOULD be sent to the peer and the originator moves into the
  2398.    wait_stop_reply state.
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405. Hamzeh, et al                                                  [Page 43]
  2406.  
  2407. Internet Draft              PPTP                   July 1997
  2408.  
  2409.  
  2410.    established
  2411.  
  2412.    An established connection may be terminated by either a local
  2413.    condition or the receipt of a Stop-Control-Connection-Request. In the
  2414.    event of a local termination, the originator MUST send a Stop-
  2415.    Control-Connection-Request and enter the wait_stop_reply state.
  2416.  
  2417.    If the originator receives a Stop-Control-Connection-Request it
  2418.    SHOULD send a Stop-Control-Connection-Reply and close the TCP
  2419.    connection making sure that the final TCP information has been
  2420.    "pushed" properly.
  2421.  
  2422.    wait_stop_reply
  2423.  
  2424.    If a Stop-Control-Connection-Reply is received, the TCP connection
  2425.    SHOULD be closed and the control connection becomes idle.
  2426.  
  2427. 3.1.2 Control connection Receiver (may be PAC or PNS)
  2428.  
  2429.  
  2430.    Receive Start Control Connection Request
  2431.    Version Not OK/Send Start Control Connection
  2432.    Reply with Error
  2433.       +--------+
  2434.       |        |         Receive Control Connection Request Version OK
  2435.       |        |         /Send Start Control Connection Reply
  2436.       |        |   +----------------------------------------+
  2437.       ^        V   ^                                        V
  2438.     +-----------------+             Receive Start Ctl    +-----------------+
  2439.     |      Idle       |             Connection Request   |   Established   |
  2440.     +-----------------+             /Send Stop Reply     +-----------------+
  2441.             ^      ^                 Close TCP           V  V Local Terminate
  2442.             |      +-------------------------------------+  | /Send Stop
  2443.             |                                               |  Control Conn.
  2444.             |                                               V  Request
  2445.             |                                     +-----------------+
  2446.             +-------------------------------------| Wait-Stop-Reply |
  2447.                      Receive Stop Control         +-----------------+
  2448.                      Connection Reply
  2449.                      /Close TCP
  2450.  
  2451.    idle
  2452.  
  2453.    The control connection receiver waits for a TCP open attempt on port
  2454.    1723. When notified of an open TCP connection, it should prepare to
  2455.    receive PPTP messages.  When a Start-Control-Connection-Request is
  2456.    received its version field should be examined. If the version is
  2457.    earlier than the receiver's version and the earlier version can be
  2458.  
  2459.  
  2460.  
  2461. Hamzeh, et al                                                  [Page 44]
  2462.  
  2463. Internet Draft              PPTP                   July 1997
  2464.  
  2465.  
  2466.    supported by the receiver, the receiver SHOULD send a Start-Control-
  2467.    Connection-Reply. If the version is earlier than the receiver's
  2468.    version and the version cannot be supported, the receiver SHOULD send
  2469.    a Start- Connection-Reply message, close the TCP connection and
  2470.    remain in the idle state.  If the receiver's version is the same as
  2471.    earlier than the peer's, the receiver SHOULD send a Start-Control-
  2472.    Connection-Reply with the receiver's version and enter the
  2473.    established state.
  2474.  
  2475.    established
  2476.  
  2477.    An established connection may be terminated by either a local
  2478.    condition or the reception of a Stop-Control-Connection-Request. In
  2479.    the event of a local termination, the originator MUST send a Stop-
  2480.    Control-Connection-Request and enter the wait_stop_reply state.
  2481.  
  2482.    If the originator receives a Stop-Control-Connection-Request it
  2483.    SHOULD send a Stop-Control-Connection-Reply and close the TCP
  2484.    connection, making sure that the final TCP information has been
  2485.    "pushed" properly.
  2486.  
  2487.    wait_stop_reply
  2488.  
  2489.    If a Stop-Control-Connection-Reply is received, the TCP connection
  2490.    SHOULD be closed and the control connection becomes idle.
  2491.  
  2492. 3.1.3 Start Control Connection Initiation Request Collision
  2493.  
  2494.    A PAC and PNS must have only one control connection between them. It
  2495.    is possible, however, for a PNS and a PAC to simultaneously attempt
  2496.    to establish a control connection to each other. When a Start-
  2497.    Control-Connection-Request is received on one TCP connection and
  2498.    another Start-Control-Connection-Request has already been sent on
  2499.    another TCP connection to the same peer, a collision has occurred.
  2500.  
  2501.    The "winner" of the initiation race is the peer with the higher IP
  2502.    address (compared as 32 bit unsigned values, network number more
  2503.    significant). For example, if the peers 192.33.45.17 and 192.33.45.89
  2504.    collide, the latter will be declared the winner.
  2505.  
  2506.    The loser will immediately close the TCP connection it initiated,
  2507.    without sending any further PPTP control messages on it and will
  2508.    respond to the winner's request with a Start-Control-Connection-Reply
  2509.    message. The winner will wait for the Start-Control-Connection-Reply
  2510.    on the connection it initiated and also wait for a TCP termination
  2511.    indication on the connection the loser opened.  The winner MUST NOT
  2512.    send any messages on the connection the loser initiated.
  2513.  
  2514.  
  2515.  
  2516.  
  2517. Hamzeh, et al                                                  [Page 45]
  2518.  
  2519. Internet Draft              PPTP                   July 1997
  2520.  
  2521.  
  2522. 3.1.3 Keep Alives and Timers
  2523.  
  2524.    A control connection SHOULD be closed by closing the underlying TCP
  2525.    connection under the following circumstances:
  2526.  
  2527.    1. If a control connection is not in the established state (i.e.,
  2528.       Start-Control-Connection-Request and Start-Control-Connection-
  2529.       Reply have not been exchanged), a control connection SHOULD be
  2530.       closed after 60 seconds by a peer waiting for a Start-Control-
  2531.       Connection-Request or Start-Control-Connection-Reply message.
  2532.  
  2533.    2. If a peer's control connection is in the established state and has
  2534.       not received a control message for 60 seconds, it SHOULD send a
  2535.       Echo-Request message. If an Echo-Reply is not received 60 seconds
  2536.       after the Echo-Request message transmission, the control
  2537.       connection SHOULD be closed.
  2538.  
  2539. 3.2 Call States
  2540.  
  2541. 3.2.1 Timing considerations
  2542.  
  2543.    Because of the real-time nature of telephone signaling, both the PNS
  2544.    and PAC should be implemented with multi-threaded architectures such
  2545.    that messages related to multiple calls are not serialized and
  2546.    blocked. The transit delay between the PAC and PNS should not exceed
  2547.    one second. The call and connection state figures do not specify
  2548.    exceptions caused by timers. The implicit assumption is that since
  2549.    the TCP-based control connection is being verified with keep-alives,
  2550.    there is less need to maintain strict timers for call control
  2551.    messages.
  2552.  
  2553.    Establishing outbound international calls, including the modem
  2554.    training and negotiation sequences, may take in excess of 1 minute so
  2555.    the use of short timers is discouraged.
  2556.  
  2557.    If a state transition does not occur within 1 minute (except for
  2558.    connections in the idle or established states), the integrity of the
  2559.    protocol processing between the peers is suspect and the ENTIRE
  2560.    CONTROL CONNECTION should be closed and restarted. All Call IDs are
  2561.    logically released whenever a control connection is started. This
  2562.    presumably also helps in preventing toll calls from being "lost" and
  2563.    never cleared.
  2564.  
  2565. 3.2.2 Call ID values
  2566.  
  2567.    Each peer assigns a Call ID value to each user session it requests or
  2568.    accepts. This Call ID value MUST be unique for the tunnel between the
  2569.    PNS and PAC to which it belongs. Tunnels to other peers can use the
  2570.  
  2571.  
  2572.  
  2573. Hamzeh, et al                                                  [Page 46]
  2574.  
  2575. Internet Draft              PPTP                   July 1997
  2576.  
  2577.  
  2578.    same Call ID number so the receiver of a packet on a tunnel needs to
  2579.    associate a user session with a particular tunnel and Call ID.  It is
  2580.    suggested that the number of potential Call ID values for each tunnel
  2581.    be at least twice as large as the maximum number of calls expected on
  2582.    a given tunnel.
  2583.  
  2584.    A session is defined by the triple (PAC, PNS, Call ID).
  2585.  
  2586. 3.2.3 Incoming calls
  2587.  
  2588.    An Incoming-Call-Request message is generated by the PAC when an
  2589.    associated telephone line rings. The PAC selects a Call ID and serial
  2590.    number and indicates the call bearer type.  Modems should always
  2591.    indicate analog call type.  ISDN calls should indicate digital when
  2592.    unrestricted digital service or rate adaption is used and analog if
  2593.    digital modems are involved. Dialing number, dialed number, and
  2594.    subaddress may be included in the message if they are available from
  2595.    the telephone network.
  2596.  
  2597.    Once the PAC sends the Incoming-Call-Request, it waits for a response
  2598.    from the PNS but does not answer the call from the telephone network.
  2599.    The PNS may choose not to accept the call if:
  2600.  
  2601.       -  No resources are available to handle more sessions
  2602.  
  2603.       -  The dialed, dialing, or subaddress fields are not indicative of
  2604.          an authorized user
  2605.  
  2606.       -  The bearer service is not authorized or supported
  2607.  
  2608.    If the PNS chooses to accept the call, it responds with an Outgoing-
  2609.    Call-Reply which also indicates window sizes (see Appendix B). When
  2610.    the PAC receives the Outgoing-Call-Reply, it attempts to connect the
  2611.    call, assuming the calling party has not hung up. A final call
  2612.    connected message from the PAC to the PNS indicates that the call
  2613.    states for both the PAC and the PNS should enter the established
  2614.    state.
  2615.  
  2616.    When the dialed-in client hangs up, the call is cleared normally and
  2617.    the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to
  2618.    clear a call, it sends a Call-Clear-Request message and then waits
  2619.    for a Call-Disconnect-Notify.
  2620.  
  2621.  
  2622.  
  2623.  
  2624.  
  2625.  
  2626.  
  2627.  
  2628.  
  2629. Hamzeh, et al                                                  [Page 47]
  2630.  
  2631. Internet Draft              PPTP                   July 1997
  2632.  
  2633.  
  2634. 3.2.3.1 PAC Incoming Call States
  2635.  
  2636.  
  2637.        Ring/Send Incoming Call Request          +-----------------+
  2638.      +----------------------------------------->|    wait_reply   |
  2639.      |                                          +-----------------+
  2640.      |           Receive Incoming Call Reply    V  V  V
  2641.      |           Not Accepting                  |  |  |   Receive Incoming
  2642.      |         +--------------------------------+  |  |   Call Reply Accepting
  2643.      |         |    +------------------------------+  |   /Answer call; Send
  2644.      |         |    |     Abort/Send Call             |    Call Connected
  2645.      ^         V    V     Disconnect Notify           V
  2646.    +-----------------+                              +-----------------+
  2647.    |      idle       |<-----------------------------|   established   |
  2648.    +-----------------+  Receive Clear Call Request  +-----------------+
  2649.                         or telco call dropped
  2650.                         or local disconnect
  2651.                         /Send Call Disconnect Notify
  2652.  
  2653.  
  2654.  
  2655.    The states associated with the PAC for incoming calls are:
  2656.  
  2657.    idle
  2658.  
  2659.    The PAC detects an incoming call on one of its telco interfaces.
  2660.    Typically this means an analog line is ringing or an ISDN TE has
  2661.    detected an incoming Q.931 SETUP message. The PAC sends an Incoming-
  2662.    Call-Request message and moves to the wait_reply state.
  2663.  
  2664.    wait_reply
  2665.  
  2666.    The PAC receives an Incoming-Call-Reply message indicating non-
  2667.    willingness to accept the call (general error or don't accept) and
  2668.    moves back into the idle state. If the reply message indicates that
  2669.    the call is accepted, the PAC sends an Incoming-Call-Connected
  2670.    message and enters the established state.
  2671.  
  2672.    established
  2673.  
  2674.    Data is exchanged over the tunnel. The call may be cleared following:
  2675.  
  2676.       An event on the telco connection. The PAC sends a Call-
  2677.       Disconnect-Notify message
  2678.  
  2679.       Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect-
  2680.       Notify message
  2681.  
  2682.  
  2683.  
  2684.  
  2685. Hamzeh, et al                                                  [Page 48]
  2686.  
  2687. Internet Draft              PPTP                   July 1997
  2688.  
  2689.  
  2690.       A local reason. The PAC sends a Call-Disconnect-Notify message.
  2691.  
  2692. 3.2.3.2 PNS Incoming Call States
  2693.  
  2694.  
  2695.  
  2696.      Receive Incoming Call Request
  2697.      /Send Incoming Call Reply                     +-----------------+
  2698.       Not Accepting if Error                       |   Wait-Connect  |
  2699.      +-----+                                    +-----------------+
  2700.      |     |     Receive Incoming Call Req.     ^  V  V
  2701.      |     |     /Send Incoming Call Reply OK   |  |  |   Receive Incoming
  2702.      |     |   +--------------------------------+  |  |   Call Connect
  2703.      ^     V   ^    V------------------------------+  V
  2704.    +-----------------+  Receive Call Disconnect     +-----------------+
  2705.    |      Idle       |  Notify                   +- |   Established   |
  2706.    +-----------------+                           |  +-----------------+
  2707.            ^        ^                            |   V   Local Terminate
  2708.            |        +----------------------------+   |   /Send Call Clear
  2709.            |            Receive Call Disconnect      |    Request
  2710.            |            Notify                       V
  2711.            |                                      +-----------------+
  2712.            +--------------------------------------| Wait-Disconnect |
  2713.                         Receive Call Disconnect   +-----------------+
  2714.                         Notify
  2715.  
  2716.  
  2717.  
  2718.    The states associated with the PNS for incoming calls are:
  2719.  
  2720.    idle
  2721.  
  2722.    An Incoming-Call-Request message is received. If the request is not
  2723.    acceptable, an Incoming-Call-Reply is sent back to the PAC and the
  2724.    PNS remains in the idle state.  If the Incoming-Call-Request message
  2725.    is acceptable, an Incoming-Call-Reply is sent indicating accept in
  2726.    the result code. The session moves to the wait_connect state.
  2727.  
  2728.    wait_connect
  2729.  
  2730.    If the session is connected on the PAC, the PAC sends an incoming
  2731.    call connect message to the PNS which then moves into established
  2732.    state. The PAC may send a Call-Disconnect-Notify to indicate that the
  2733.    incoming caller could not be connected.  This could happen, for
  2734.    example, if a telephone user accidently places a standard voice call
  2735.    to a PAC resulting in a handshake failure on the called modem.
  2736.  
  2737.  
  2738.  
  2739.  
  2740.  
  2741. Hamzeh, et al                                                  [Page 49]
  2742.  
  2743. Internet Draft              PPTP                   July 1997
  2744.  
  2745.  
  2746.    established
  2747.  
  2748.    The session is terminated either by receipt of a Call-Disconnect-
  2749.    Notify message from the PAC or by sending a Call-Clear-Request. Once
  2750.    a Call-Clear-Request has been sent, the session enters the
  2751.    wait_disconnect state.
  2752.  
  2753.    wait_disconnect
  2754.  
  2755.    Once a Call-Disconnect-Notify is received the session moves back to
  2756.    the idle state.
  2757.  
  2758. 3.2.4 Outgoing calls
  2759.  
  2760.    Outgoing messages are initiated by a PNS and instruct a PAC to place
  2761.    a call on a telco interface. There are only two messages for outgoing
  2762.    calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends
  2763.    an Outgoing-Call-Request specifying the dialed party phone number and
  2764.    subaddress as well as speed and window parameters. The PAC MUST
  2765.    respond to the Outgoing-Call-Request message with an Outgoing-Call-
  2766.    Reply message once the PAC determines that:
  2767.  
  2768.       The call has been successfully connected
  2769.  
  2770.       A call failure has occurred for reasons such as: no interfaces are
  2771.       available for dial-out, the called party is busy or does not
  2772.       answer, or no dial tone is detected on the interface chosen for
  2773.       dialing
  2774.  
  2775.  
  2776.  
  2777.  
  2778.  
  2779.  
  2780.  
  2781.  
  2782.  
  2783.  
  2784.  
  2785.  
  2786.  
  2787.  
  2788.  
  2789.  
  2790.  
  2791.  
  2792.  
  2793.  
  2794.  
  2795.  
  2796.  
  2797. Hamzeh, et al                                                  [Page 50]
  2798.  
  2799. Internet Draft              PPTP                   July 1997
  2800.  
  2801.  
  2802. 3.2.4.1 PAC Outgoing Call States
  2803.  
  2804.  
  2805.  
  2806.    Receive Outgoing Call Request in Error
  2807.    /Send Outgoing Call Reply with Error
  2808.      |--------+
  2809.      |        |         Receive Outgoing Call Request No Error
  2810.      |        |         /Off Hook; Dial
  2811.      |        |   +-----------------------------------------
  2812.      ^        V   ^                                        V
  2813.    +-----------------+           Incomplete Call        +-----------------+
  2814.    |      idle       |           /Send Outgoing Call    |   wait_cs_ans   |
  2815.    +-----------------+            Reply with Error      +-----------------+
  2816.            ^      ^           or Recv. Call Clear Req.  V  V Telco Answer
  2817.            |      |              /Send Disconnect Notify|  | /Send Outgoing
  2818.            |      +-------------------------------------+  |  Call Reply.
  2819.            |                                               V
  2820.            |                                     +-----------------+
  2821.            +-------------------------------------|   established   |
  2822.                     Receive Call Clear Request   +-----------------+
  2823.                     or local terminate
  2824.                     or telco disconnect
  2825.                     /Hangup call and send
  2826.                     Call Disconnect Notify
  2827.  
  2828.  
  2829.  
  2830.    The states associated with the PAC for outgoing calls are:
  2831.  
  2832.    idle
  2833.  
  2834.    Received Outgoing-Call-Request. If this is received in error, respond
  2835.    with an Outgoing-Call-Reply with error condition set. Otherwise,
  2836.    allocate physical channel to dial on. Place the outbound call, wait
  2837.    for a connection, and move to the wait_cs_ans state.
  2838.  
  2839.    wait_cs_ans
  2840.  
  2841.    If the call is incomplete, send an Outgoing-Call-Reply with a non-
  2842.    zero Error Code. If a timer expires on an outbound call, send back an
  2843.    Outgoing-Call-Reply with a non-zero Error Code. If a circuit switched
  2844.    connection is established, send an Outgoing-Call-Reply indicating
  2845.    success.
  2846.  
  2847.    established
  2848.  
  2849.    If a Call-Clear-Request is received, the telco call SHOULD be
  2850.  
  2851.  
  2852.  
  2853. Hamzeh, et al                                                  [Page 51]
  2854.  
  2855. Internet Draft              PPTP                   July 1997
  2856.  
  2857.  
  2858.    released via appropriate mechanisms and a Call-Disconnect-Notify
  2859.    message SHOULD BE sent to the PNS. If the call is disconnected by the
  2860.    client or by the telco interface, a Call-Disconnect-Notify message
  2861.    SHOULD be sent to the PNS.
  2862.  
  2863. 3.2.4.2 PNS Outgoing Call States
  2864.  
  2865.  
  2866.                    Open Indication                                Abort/Send
  2867.                    /Send Outgoing Call                            Call Clear
  2868.                     Request                  +-----------------+  Request
  2869.            +-------------------------------->|    Wait-Reply   |------------+
  2870.            |                                 +-----------------+            |
  2871.            |     Receive Outgoing Call Reply   V     V   Receive Outgoing   |
  2872.            |     with Error                    |     |   Call Reply         |
  2873.            |   +-------------------------------+     |   No Error           |
  2874.            ^   V                                     V                      |
  2875.    +-----------------+                              +-----------------+     |
  2876.    |      Idle       |<-----------------------------|   Established   |     |
  2877.    +-----------------+    Receive Call Disconnect   +-----------------+     |
  2878.            ^              Notify                     V   Local Terminate    |
  2879.            |                                         |   /Send Call Clear   |
  2880.            |                                         |    Request           |
  2881.            |     Receive Call Disconnect             V                      |
  2882.            |     Notify                      +-----------------+            |
  2883.            +---------------------------------| Wait-Disconnect |<-----------+
  2884.                                              +-----------------+
  2885.  
  2886.  
  2887.    The states associated with the PNS for outgoing calls are:
  2888.  
  2889.    idle
  2890.  
  2891.    An Outgoing-Call-Request message is sent to the PAC and the session
  2892.    moves into the wait_reply state.
  2893.  
  2894.    wait_reply
  2895.  
  2896.    An Outgoing-Call-Reply is received which indicates an error. The
  2897.    session returns to idle state. No telco call is active. If the
  2898.    Outgoing-Call-Reply does not indicate an error, the telco call is
  2899.    connected and the session moves to the established state.
  2900.  
  2901.    established
  2902.  
  2903.    If a Call-Disconnect-Notify is received, the telco call has been
  2904.    terminated for the reason indicated in the Result and Cause Codes.
  2905.    The session moves back to the idle state. If the PNS chooses to
  2906.  
  2907.  
  2908.  
  2909. Hamzeh, et al                                                  [Page 52]
  2910.  
  2911. Internet Draft              PPTP                   July 1997
  2912.  
  2913.  
  2914.    terminate the session, it sends a Call-Clear-Request to the PAC and
  2915.    then enters the wait_disconnect state.
  2916.  
  2917.    wait_disconnect
  2918.  
  2919.    A session disconnection is waiting to be confirmed by the PAC. Once
  2920.    the PNS receives the Call-Disconnect-Notify message, the session
  2921.    enters idle state.
  2922.  
  2923. 4.0 Tunnel Protocol Operation
  2924.  
  2925.    The user data carried by the PPTP protocol are PPP data packets.  PPP
  2926.    packets are carried between the PAC and PNS, encapsulated in GRE
  2927.    packets which in turn are carried over IP.  The encapsulated PPP
  2928.    packets are essentially PPP data packets less any media specific
  2929.    framing elements.  No HDLC flags, bit insertion, control characters,
  2930.    or control character escapes are included. No CRCs are sent through
  2931.    the tunnel. The IP packets transmitted over the tunnels between a PAC
  2932.    and PNS has the following general structure:
  2933.  
  2934.            +--------------------------------+
  2935.            |          Media Header          |
  2936.            +--------------------------------+
  2937.            |           IP Header            |
  2938.            +--------------------------------+
  2939.            |           GRE Header           |
  2940.            +--------------------------------+
  2941.            |           PPP Packet           |
  2942.            +--------------------------------+
  2943.  
  2944.  
  2945. 4.1 Enhanced GRE header
  2946.  
  2947.    The GRE header used in PPTP is enhanced slightly from that specified
  2948.    in the current GRE protocol specification [1,2].  The main difference
  2949.    involves the definition of a new Acknowledgment Number field, used to
  2950.    determine if a particular GRE packet or set of packets has arrived at
  2951.    the remote end of the tunnel.  This Acknowledgment capability is not
  2952.    used in conjunction with any retransmission of user data packets.  It
  2953.    is used instead to determine the rate at which user data packets are
  2954.    to be transmitted over the tunnel for a given user session.
  2955.  
  2956.    The format of the enhanced GRE header is as follows:
  2957.  
  2958.  
  2959.  
  2960.  
  2961.  
  2962.  
  2963.  
  2964.  
  2965. Hamzeh, et al                                                  [Page 53]
  2966.  
  2967. Internet Draft              PPTP                   July 1997
  2968.  
  2969.  
  2970.  
  2971.        0                   1                   2                   3
  2972.        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
  2973.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2974.       |C|R|K|S|s|Recur|A| Flags | Ver |         Protocol Type         |
  2975.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2976.       |    Key (HW) Payload Length    |       Key (LW) Call ID        |
  2977.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2978.       |                  Sequence Number (Optional)                   |
  2979.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2980.       |               Acknowledgment Number (Optional)                |
  2981.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2982.  
  2983.  
  2984.       C                        (Bit 0) Checksum Present.  Set to zero
  2985.                                (0).
  2986.  
  2987.       R                        (Bit 1) Routing Present.  Set to zero
  2988.                                (0).
  2989.  
  2990.       K                        (Bit 2) Key Present.  Set to one (1).
  2991.  
  2992.       S                        (Bit 3) Sequence Number Present.  Set to
  2993.                                one (1) if a payload (data) packet is
  2994.                                present.  Set to zero (0) if payload is
  2995.                                not present (GRE packet is an
  2996.                                Acknowledgment only).
  2997.  
  2998.       s                        (Bit 4) Strict source route present.  Set
  2999.                                to zero (0).
  3000.  
  3001.       Recur                    (Bits 5-7) Recursion control.  Set to
  3002.                                zero (0).
  3003.  
  3004.       A                        (Bit 8) Acknowledgment sequence number
  3005.                                present.  Set to one (1) if packet
  3006.                                contains Acknowledgment Number to be used
  3007.                                for acknowledging previously transmitted
  3008.                                data.
  3009.  
  3010.       Flags                    (Bits 9-12) Must be set to zero (0).
  3011.  
  3012.       Ver                      (Bits 13-15) Must contain 1 (enhanced
  3013.                                GRE).
  3014.  
  3015.       Protocol Type           Set to hex 880B [8].
  3016.  
  3017.       Key                      Use of the Key field is up to the
  3018.  
  3019.  
  3020.  
  3021. Hamzeh, et al                                                  [Page 54]
  3022.  
  3023. Internet Draft              PPTP                   July 1997
  3024.  
  3025.  
  3026.                                implementation.
  3027.                                 PPTP uses it as follows:
  3028.  
  3029.                                Payload Length
  3030.                                   (High 2 octets of Key) Size of the
  3031.                                   payload, not including the GRE header
  3032.  
  3033.                                Call ID
  3034.                                   (Low 2 octets) Contains the Peer's
  3035.                                   Call ID for the session to which this
  3036.                                   packet belongs.
  3037.  
  3038.       Sequence Number          Contains the sequence number of the
  3039.                                payload.  Present if S bit (Bit 3) is one
  3040.                                (1).
  3041.  
  3042.       Acknowledgment Number    Contains the sequence number of the
  3043.                                highest numbered GRE packet received by
  3044.                                the sending peer for this user session.
  3045.                                Present if A bit (Bit 8) is one (1).
  3046.  
  3047.    The payload section contains a PPP data packet without any media
  3048.    specific framing elements.
  3049.  
  3050.    The sequence numbers involved are per packet sequence numbers.  The
  3051.    sequence number for each user session is set to zero at session
  3052.    startup.  Each packet sent for a given user session which contains a
  3053.    payload (and has the S bit (Bit 3) set to one) is assigned the next
  3054.    consecutive sequence number for that session.
  3055.  
  3056.    This protocol allows acknowledgments to be carried with the data and
  3057.    makes the overall protocol more efficient, which in turn requires
  3058.    less buffering of packets.
  3059.  
  3060.  
  3061. 4.2 Sliding Window Protocol
  3062.  
  3063.    The sliding window protocol used on the PPTP data path is used for
  3064.    flow control by each side of the data exchange.  The enhanced GRE
  3065.    protocol allows packet acknowledgments to be piggybacked on data
  3066.    packets.  Acknowledgments can also be sent separately from data
  3067.    packets.  Again, the main purpose of the sliding window protocol is
  3068.    for flow control--retransmissions are not performed by the tunnel
  3069.    peers.
  3070.  
  3071.  
  3072.  
  3073.  
  3074.  
  3075.  
  3076.  
  3077. Hamzeh, et al                                                  [Page 55]
  3078.  
  3079. Internet Draft              PPTP                   July 1997
  3080.  
  3081.  
  3082. 4.3 Multi Packet Acknowledgment
  3083.  
  3084.    One feature of the PPTP sliding window protocol is that it allows the
  3085.    acknowledgment of multiple packets with a single acknowledgment. All
  3086.    outstanding packets with a sequence number lower or equal to the
  3087.    acknowledgment number are considered acknowledged. Time-out
  3088.    calculations are performed using the time the packet corresponding to
  3089.    the highest sequence number being acknowledged was transmitted.
  3090.  
  3091.  
  3092.    Adaptive time-out calculations are only performed when an
  3093.    Acknowledgment is received.  When multi-packet acknowledgments are
  3094.    used, the overhead of the adaptive time-out algorithm is reduced. The
  3095.    PAC is not required to transmit multi-packet acknowledgments; it can
  3096.    instead acknowledge each packet individually as it is delivered to
  3097.    the PPP client.
  3098.  
  3099. 4.4 Out-of-Sequence Packets
  3100.  
  3101.    Occasionally packets lose their sequencing across a complicated
  3102.    internetwork.  Say, for example that a PNS sends packets 0 to 5 to a
  3103.    PAC.  Because of rerouting in the internetwork, packet 4 arrives at
  3104.    the PAC before packet 3. The PAC acknowledges packet 4, and may
  3105.    assume packet 3 is lost. This acknowledgment grants window credit
  3106.    beyond packet 4.
  3107.  
  3108.    When the PAC does receive packet 3, it MUST not attempt to transmit
  3109.    it to the corresponding PPP client.  To do so could cause problems,
  3110.    as proper PPP protocol operation is premised upon receiving packets
  3111.    in sequence.  PPP does properly deal with the loss of packets, but
  3112.    not with reordering so out of sequence packets between the PNS and
  3113.    PAC MUST be silently discarded, or they may be reordered by the
  3114.    receiver.  When packet 5 comes in, it is acknowledged by the PAC
  3115.    since it has a higher sequence number than 4, which was the last
  3116.    highest packet acknowledged by the PAC.  Packets with duplicate
  3117.    sequence numbers should never occur since the PAC and PNS never
  3118.    retransmit GRE packets.  A robust implementation will silently
  3119.    discard duplicate GRE packets, should it receive any.
  3120.  
  3121. 5.0 Security Considerations
  3122.  
  3123.    Security issues are not addressed in this document. End to end
  3124.    security is addressed by PPP. Further security considerations will be
  3125.    addressed by the next version of PPTP.
  3126.  
  3127.  
  3128.  
  3129.  
  3130.  
  3131.  
  3132.  
  3133. Hamzeh, et al                                                  [Page 56]
  3134.  
  3135. Internet Draft              PPTP                   July 1997
  3136.  
  3137.  
  3138. 6.0 Authors' Addresses
  3139.  
  3140.  
  3141.       Kory Hamzeh
  3142.       Ascend Communications
  3143.       1275 Harbor Bay Parkway
  3144.       Alameda, CA 94502
  3145.       Email: kory@ascend.com
  3146.  
  3147.       Gurdeep Singh Pall
  3148.       Microsoft Corporation
  3149.       Redmond, WA
  3150.       Email: gurdeep@microsoft.com
  3151.  
  3152.       William Verthein
  3153.       U.S. Robotics/3Com
  3154.  
  3155.       Jeff Taarud
  3156.       Copper Mountain Networks
  3157.  
  3158.       W. Andrew Little
  3159.       ECI Telematics
  3160.  
  3161. 7.0 References
  3162.  
  3163.    [1]  Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing
  3164.         Encapsulation (GRE)", RFC 1701, October 1994.
  3165.  
  3166.    [2]  Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing
  3167.         Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
  3168.  
  3169.    [3]  Lloyd, B. Simpson, W., "PPP Authentication Protocols", RFC 1334,
  3170.         October 1992.
  3171.  
  3172.    [4]  Postel, J. B., "Transmission Control Protocol", RFC 791,
  3173.         September 1981
  3174.  
  3175.    [5]  Postel, J. B., "User Data Protocol", RFC 768, August 1980.
  3176.  
  3177.    [6]    Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October,
  3178.         1994.
  3179.  
  3180.    [7]  Simpson, W., editor, "The Point-to-Point Protocol (PPP)", RFC
  3181.         1661, July 1994.
  3182.  
  3183.    [8]    Ethertype for PPP, Reserved with Xerox Corporation.
  3184.  
  3185.  
  3186.  
  3187.  
  3188.  
  3189. Hamzeh, et al                                                  [Page 57]
  3190.  
  3191. Internet Draft              PPTP                   July 1997
  3192.  
  3193.  
  3194. Appendix A. Acknowledgment Time-Outs
  3195.  
  3196.  
  3197.    PPTP uses sliding windows and time-outs to provide both user session
  3198.    flow-control across the internetwork and to perform efficient data
  3199.    buffering to keep the PAC-PNS data channels full without causing
  3200.    receive buffer overflow.  PPTP requires that a time-out be used to
  3201.    recover from dropped data or acknowledgment packets.  The exact
  3202.    implementation of the time-out is vendor-specific.  It is suggested
  3203.    that an adaptive time-out be implemented with backoff for congestion
  3204.    control.  The time-out mechanism proposed here has the following
  3205.    properties:
  3206.  
  3207.       Independent time-outs for each session. A device (PAC or PNS) will
  3208.       have to maintain and calculate time-outs for every active session.
  3209.  
  3210.       An administrator-adjustable maximum time-out, MaxTimeOut, unique
  3211.       to each device.
  3212.  
  3213.       An adaptive time-out mechanism that compensates for changing
  3214.       throughput.  To reduce packet processing overhead, vendors may
  3215.       choose not to recompute the adaptive time-out for every received
  3216.       acknowledgment.  The result of this overhead reduction is that the
  3217.       time-out will not respond as quickly to rapid network changes.
  3218.  
  3219.       Timer backoff on time-out to reduce congestion. The backed-off
  3220.       timer value is limited by the configurable maximum time-out value.
  3221.       Timer backoff is done every time an acknowledgment time-out
  3222.       occurs.
  3223.  
  3224.    In general, this mechanism has the desirable behavior of quickly
  3225.    backing off upon a time-out and of slowly decreasing the time-out
  3226.    value as packets are delivered without time-outs.
  3227.  
  3228.    Some definitions:
  3229.  
  3230.       Packet Processing Delay (PPD) is the amount of time required for
  3231.       each side to process the maximum amount of data buffered in their
  3232.       receive packet sliding window. The PPD is the value exchanged
  3233.       between the PAC and PNS when a call is established. For the PNS,
  3234.       this number should be small.  For a PAC making modem connections,
  3235.       this number could be significant.
  3236.  
  3237.       Sample is the actual amount of time incurred receiving an
  3238.       acknowledgment for a packet. The Sample is measured, not
  3239.       calculated.
  3240.  
  3241.       Round-Trip Time (RTT) is the estimated round-trip time for an
  3242.  
  3243.  
  3244.  
  3245. Hamzeh, et al                                                  [Page 58]
  3246.  
  3247. Internet Draft              PPTP                   July 1997
  3248.  
  3249.  
  3250.       Acknowledgment to be received for a given transmitted packet. When
  3251.       the network link is a local network, this delay will be minimal
  3252.       (if not zero). When the network link is the Internet, this delay
  3253.       could be substantial and vary widely. RTT is adaptive: it will
  3254.       adjust to include the PPD and whatever shifting network delays
  3255.       contribute to the time between a packet being transmitted and
  3256.       receiving its acknowledgment.
  3257.  
  3258.       Adaptive Time-Out (ATO) is the time that must elapse before an
  3259.       acknowledgment is considered lost.  After a time-out, the sliding
  3260.       window is partially closed and the ATO is backed off.
  3261.  
  3262.  
  3263. Packet Processing Delay (PPD)
  3264.  
  3265.    The PPD parameter is a 16-bit word exchanged during the Call Control
  3266.    phase that represents tenths of a second (64 means 6.4 seconds). The
  3267.    protocol only specifies that the parameter is exchanged, it does not
  3268.    specify how it is calculated. The way values for PPD are calculated
  3269.    is implementation-dependent and need not be variable (static time-
  3270.    outs are allowed). The PPD must be exchanged in the call connect
  3271.    sequences, even if it remains constant in an implementation. One
  3272.    possible way to calculate the PPD is:
  3273.  
  3274.     PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
  3275.     PPD = PPD' + PACFudge
  3276.  
  3277.    Header is the total size of the IP and GRE headers, which is 36. The
  3278.    MTU is the overall MTU for the internetwork link between the PAC and
  3279.    PNS. WindowSize represents the number of packets in the sliding
  3280.    window, and is implementation-dependent. The latency of the
  3281.    internetwork could be used to pick a window size sufficient to keep
  3282.    the current session's pipe full. The constant 8 converts octets to
  3283.    bits (assuming ConnectRate is in bits per second).  If ConnectRate is
  3284.    in bytes per second, omit the 8. PACFudge is not required but can be
  3285.    used to take overall processing overhead of the PAC into account.
  3286.  
  3287.    The value of PPD is used to seed the adaptive algorithm with the
  3288.    initial RTT[n-1] value.
  3289.  
  3290. Sample
  3291.  
  3292.    Sample is the actual measured time for a returned acknowledgment.
  3293.  
  3294. Round-Trip Time (RTT)
  3295.  
  3296.    The RTT value represents an estimate of the average time it takes for
  3297.    an acknowledgment to be received after a packet is sent to the remote
  3298.  
  3299.  
  3300.  
  3301. Hamzeh, et al                                                  [Page 59]
  3302.  
  3303. Internet Draft              PPTP                   July 1997
  3304.  
  3305.  
  3306.    end of the tunnel.
  3307.  
  3308.  
  3309. A.1 Calculating Adaptive Acknowledgment Time-Out
  3310.  
  3311.    We still must decide how much time to allow for acknowledgments to
  3312.    return. If the time-out is set too high, we may wait an unnecessarily
  3313.    long time for dropped packets. If the time-out is too short, we may
  3314.    time out just before the acknowledgment arrives. The acknowledgment
  3315.    time-out should also be reasonable and responsive to changing network
  3316.    conditions.
  3317.  
  3318.    The suggested adaptive algorithm detailed below is based on the TCP
  3319.    1989 implementation and is explained in Richard Steven's book TCP/IP
  3320.    Illustrated, Volume 1 (page 300). 'n' means this iteration of the
  3321.    calculation, and 'n-1' refers to values from the last calculation.
  3322.  
  3323.       DIFF[n] = SAMPLE[n] - RTT[n-1]
  3324.       DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
  3325.       RTT[n] = RTT[n-1] + (alpha * DIFF[n])
  3326.       ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)
  3327.  
  3328.       DIFF represents the error between the last estimated round-trip
  3329.       time and the measured time. DIFF is calculated on each iteration.
  3330.  
  3331.       DEV is the estimated mean deviation. This approximates the
  3332.       standard deviation.  DEV is calculated on each iteration and
  3333.       stored for use in the next iteration. Initially, it is set to 0.
  3334.  
  3335.       RTT is the estimated round-trip time of an average packet. RTT is
  3336.       calculated on each iteration and stored for use in the next
  3337.       iteration.  Initially, it is set to PPD.
  3338.  
  3339.       ATO is the adaptive time-out for the next transmitted packet. ATO
  3340.       is calculated on each iteration.  Its value is limited, by the MIN
  3341.       function, to be a maximum of the configured MaxTimeOut value.
  3342.  
  3343.       Alpha is the gain for the average and is typically 1/8 (0.125).
  3344.  
  3345.       Beta is the gain for the deviation and is typically 1/4 (0.250).
  3346.  
  3347.       Chi is the gain for the time-out and is typically set to 4.
  3348.  
  3349.    To eliminate division operations for fractional gain elements, the
  3350.    entire set of equations can be scaled. With the suggested gain
  3351.    constants, they should be scaled by 8 to eliminate all division.  To
  3352.    simplify calculations, all gain values are kept to powers of two so
  3353.    that shift operations can be used in place of multiplication or
  3354.  
  3355.  
  3356.  
  3357. Hamzeh, et al                                                  [Page 60]
  3358.  
  3359. Internet Draft              PPTP                   July 1997
  3360.  
  3361.  
  3362.    division.
  3363.  
  3364.  
  3365. A.2 Congestion Control: Adjusting for Time-Out
  3366.  
  3367.    This section describes how the calculation of ATO is modified in the
  3368.    case where a time-out does occur.  When a time-out occurs, the time-
  3369.    out value should be adjusted rapidly upward.  Although the GRE
  3370.    packets are not retransmitted when a time-out occurs, the time-out
  3371.    should be adjusted up toward a maximum limit.  To compensate for
  3372.    shifting internetwork time delays, a strategy must be employed to
  3373.    increase the time-out when it expires.  A simple formula called
  3374.    Karn's Algorithm is used in TCP implementations and may be used in
  3375.    implementing the backoff timers for the PNS or the PAC.  Notice that
  3376.    in addition to increasing the time-out, we are also shrinking the
  3377.    size of the window as described in the next section.
  3378.  
  3379.    Karn's timer backoff algorithm, as used in TCP, is:
  3380.  
  3381.  
  3382.       NewTIMEOUT = delta * TIMEOUT
  3383.  
  3384.    Adapted to our time-out calculations, for an interval in which a
  3385.    time-out occurs, the new ATO is calculated as:
  3386.  
  3387.       RTT[n] = delta * RTT[n-1]
  3388.       DEV[n] = DEV[n-1]
  3389.       ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)
  3390.  
  3391.    In this modified calculation of ATO, only the two values that
  3392.    contribute to ATO and that are stored for the next iteration are
  3393.    calculated. RTT is scaled by chi, and DEV is unmodified. DIFF is not
  3394.    carried forward and is not used in this scenario. A value of 2 for
  3395.    Delta, the time-out gain factor for RTT, is suggested.
  3396.  
  3397. Appendix B. Acknowledgment Time-Out and Window Adjustment
  3398.  
  3399. B.1 Initial Window Size
  3400.  
  3401.    Although each side has indicated the maximum size of its receive
  3402.    window, it is recommended that a slow start method be used to begin
  3403.    transmitting data.  The initial window size on the transmitter is set
  3404.    to half the maximum size the receiver requested, with a minimum size
  3405.    of one packet.  The transmitter stops sending packets when the number
  3406.    of packets awaiting acknowledgment is equal to the current window
  3407.    size.  As the receiver successfully digests each window, the window
  3408.    size on the transmitter is bumped up by one packet until the maximum
  3409.    is reached. This method prevents a system from flooding an already
  3410.  
  3411.  
  3412.  
  3413. Hamzeh, et al                                                  [Page 61]
  3414.  
  3415. Internet Draft              PPTP                   July 1997
  3416.  
  3417.  
  3418.    congested network because no history has been established.
  3419.  
  3420. B.2 Closing the Window
  3421.  
  3422.    When a time-out does occur on a packet, the sender adjusts the size
  3423.    of the transmit window down to one half its value when it failed.
  3424.    Fractions are rounded up, and the minimum window size is one.
  3425.  
  3426. B.3 Opening the Window
  3427.  
  3428.    With every successful transmission of a window's worth of packets
  3429.    without a time-out, the transmit window size is increased by one
  3430.    packet until it reaches the maximum window size that was sent by the
  3431.    other side when the call was connected.  As stated earlier, no
  3432.    retransmission is done on a time-out. After a time-out, the
  3433.    transmission resumes with the window starting at one half the size of
  3434.    the transmit window when the time-out occurred and adjusting upward
  3435.    by one each time the transmit window is filled with packets that are
  3436.    all acknowledged without time-outs.
  3437.  
  3438. B.4 Window Overflow
  3439.  
  3440.    When a receiver's window overflows with too many incoming packets,
  3441.    excess packets are thrown away.  This situation should not arise if
  3442.    the sliding window procedures are being properly followed by the
  3443.    transmitter and receiver. It is assumed that, on the transmit side,
  3444.    packets are buffered for transmission and are no longer accepted from
  3445.    the packet source when the transmit buffer fills.
  3446.  
  3447.  
  3448.  
  3449.  
  3450.  
  3451.  
  3452.  
  3453.  
  3454.  
  3455.  
  3456.  
  3457.  
  3458.  
  3459.  
  3460.  
  3461.  
  3462.  
  3463.  
  3464.  
  3465.  
  3466.  
  3467.  
  3468.  
  3469. Hamzeh, et al                                                  [Page 62]
  3470.  
  3471.