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