[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
                                                            Pat R. Calhoun
Internet Draft                                    US Robotics Access Corp.
expires in six months                                            July 1996

                        Virtual Tunnel Protocol
                       Layer 2 Protocol Extension
                    <draft-calhoun-vtp-ext-l2-00.txt>


Status of this Memo

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Any comments may be forwarded to the sdtp@elroy.usr.com mailing list.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).


Abstract

   The VTP Protocol specification defines a generic tunneling mechanism,
   as well as extensions for IP and IPX protocols. This specification
   will detail a method to establish Level 2 (PPP and SLIP) tunnels
   between two peers.

   This strawman proposal is intended as a recommendation for using VTP
   as a generic all-purpose tunnel scheme, as opposed to having multiple
   tunneling mechanism for layer 2 and 3 protocols.





Calhoun                                                           [Page 1]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


1. Introduction

   The Secure Dynamic Tunneling Protocol was designed with flexibility in
   mind. However, the protocol only defines a method for tunneling IP and
   IPX. It is envisioned that further specification would be published
   which would describe the method for tunneling additional protocols.

   This is one such document. This specification will detail the method
   required for tunneling Layer 2 (PPP and SLIP) protocols within VTP.

   It is assumed that the reader has existing knowledge of the PPTP [1]
   and L2F [2] proposals. However there is a significant difference in the
   terminology used in this document. This document does not differenciate
   the PAC (PPTP Access Concentrator) and PNS (PPTP Network Server). The
   terms Mobile Node as used as the device which initiates the tunnel and
   the term Home Agent is used as the Tunnel termininator.


2. Protocol Overview

   In the existing VTP specification extensions for IP and IPX have been
   defined. This specification details the extensions necessary for
   tunneling Layer 2 protocols (i.e. PPP, SLIP).

   As stated earlier, the PPTP concept of the PAC and the PNS are no
   longer used, but have been replaced by the terms Mobile Node and Home
   Agent which are consistent with the existing VTP specification.

   In the case where a NAS receives an incoming PPP or SLIP call, it acts
   as a proxy Mobile Node by issuing a Registration Request to the Home
   Agent in behalf of the dial-up user. However, an issue remains where
   the Mobile Node must get the IP address of the Home Agent in order to
   establish the tunnel.

   In the existing PPTP specification, there is no method defined for
   learning the IP address of the Home Agent. There are two methods of
   determining the address of the Home Agent, they are:

        - The Mobile Node receives the DNIS for the call and passes this
          on to some central registry (i.e. RADIUS) which returns the IP
          address of the Home Agent. Although this method does work, it
          does not scale in large networks.

        - The Mobile Node negotiates LCP and enters the authentication
          phase. Once the user name/password pair is received it passes
          this on to a central registry (i.e. RADIUS) which will return
          the IP address of the Home Agent.


Calhoun                                                           [Page 2]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


          In order to support this, it is assumed that the RADIUS Server
          has the ability to authenticate the realm only (meaning the
          user name is a fully qualified name, user@realm). Another less
          elegant method is to predefine all users in the RADIUS server,
          but this means that the user information must be duplicated
          both in the RADIUS server and in the Home Agent.

          Once the tunnel has been established, the Home Agent must
          re-open LCP and restart the authentication phase. Although
          technically feasible, this solution causes many problems with
          certain existing PPP stacks.

   In the L2F specification, there is an option where the Mobile Node
   performs the authentication phase with the PPP client and passes the
   result to the Home Agent for user authentication.
   Agent.

   The Layer 2 Forwarding extension to VTP supports all of the approaches
   defined above. Note that in order for a Home Agent to conform to this
   specification, it must have the ability to authentication the user
   locally.


2.1.  Dynamic Tunnel Establishment

2.1.1.  Incoming Call Tunnel Establishment

   Once a PPP session has been identified by the Mobile Node as a
   candidate for Layer 2 tunneling and the IP address of the Home Agent
   is known, a Registration Request is forwarded to the Home Agent. The
   message MUST include the VTP Tunnel-Identifier Extension, the L2TP
   Extension and the Incoming-Call-Request Extension.

   If the Mobile Node has already answered the incoming call the
   Incoming-Call-Established Extension must be present. The Home Agent is
   then responsible for reponding with a Registration Response which
   includes the VTP Tunnel-Identifier Extension and the
   Incoming-Call-Confirm Extension and begin PPP negotiation.

   In the case where the Mobile Node wishes to perform the authentication
   with the client and pass the result to the Home Agent for
   authentication the User-Identification Extension and the
   Link-Control-Protocol Extension must be present. In this case, the Home
   Agent must authenticate the user and if successful respond with a
   Registration Response.

   In the case where the Mobile Node wishes to receive confirmation that
   it should accept the call from the Home Agent, the Registration Request

Calhoun                                                           [Page 3]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


   should only contain the VTP Tunnel-Identifier Extension and the
   L2TP Extension. If the Home Agent wishes the Mobile Node to answer the
   call, a successful Registration Response must be returned which
   includes the Incoming-Call-Request Extension. Once the Mobile Node has
   accepted the call, a Refresh Refresh message is sent to the Home Agent
   which includes the Incoming-Call-Established Extension.


2.1.2.  Outgoing Call Tunnel Establishment

   If a Mobile Node wishes to establish an outgoing call with a Home
   Agent, a Registration Request must be sent which includes the VTP
   Tunnel-Identifier Extension and the L2TP Extension and the
   Outgoing-Call-Request Extension (which includes dialing information).

   If the Home Agent has the ability of dialing the requested number on
   the specified bearer type, it must return a Registration Response with
   the VTP Tunnel-Identifier extension and the Outgoing-Call-Pending
   extension.

   Once the outgoing call has been completed, the Home Agent must send
   a Refresh Request with the VTP Tunnel-Identifier extension as well as
   the Outgoing-Call-Established Extension.


2.2.  Dynamic Tunnel Refresh

   As described in [3], the tunnel refresh mechanism is used as a keep
   alive to inform each peer that the tunnel is still valid. However, this
   specification makes use of the tunnel refresh messages to pass along
   additional information.

   In [3], the tunnel refreshes are typically initiated by the Mobile
   Node, however this specification does require that both the Mobile Node
   and the Home Agent be able to initiate the message.

   As described above, the Refresh Request may be used by the Mobile Node
   in the case where it is requesting permission to accept an incoming
   call from the Home Agent. A successful Registration Response will
   cause the Mobile Node to initiate a Refresh Request with the
   VTP Tunnel-Identifier Extension and the Incoming-Call-Established
   Extension.

   In the case of an outgoing call, a Refresh Request is sent by the
   Home Agent in order to notify the Mobile Node that the call either
   failed or was successfully completed.

   The Mobile Node may send the WAN-Error Extension in the tunnel refresh

Calhoun                                                           [Page 4]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


   if any errors had occurred since the last refresh. Note that the
   counters are cumulative and are never reset while the connection is
   established.

   If a request to change the ACCM has been received by the Home Agent
   from the PPP client, the Home Agent may send a refresh message to the
   Mobile Node with the VTP Tunnel-Identifier Extension and the
   Set-Link-Info Extension. This extension will inform the Mobile Node of
   the new character mapping table. The Home Agent may include this
   extension in a Refresh Response if necessary.


2.3.  Dynamic Tunnel Shutdown

   As described in [3], the Deregistration Request is sent by the Mobile
   Node to the Home Agent to inform of a session disconnect. However,
   since the PPP session is terminated on the Home Agent, the Mobile Node
   may not know that it must terminate the connection (unless it is
   examining each LCP packets from the PPP client and the Home Agent).

   In this extension, the Deregistration Request must be able to be
   initiated by either peer.

   If the initiator of the Deregistration Request is the Mobile Node, the
   message must include the VTP Tunnel-Identifier Extension and the
   Disconnect-Information Extension. If the initiator is the Home Agent,
   the L2TP-Disconnect-Request Extension must be present.

   If the Mobile Node is to respond with a Deregistration Response it must
   include the VTP Tunnel-Identifier Extension and the
   Disconnect-Information Extension.


2.4.  Security Implications

   Since [3] proposes the use of the Mobile-Home Authentication Extension,
   it is possible to use this authentication scheme as well with the L2TP
   extension. However, since the user authentication is performed by the
   Home Agent, it becomes a challenge to retrieve a session key for the
   tunnel.

   Since the user is not authenticated, the session key distribution
   center will have to generate keys for unauthenticated users. This may
   not be a problem since the key is not of much use if the username and
   password pair are invalid.

   Therefore the issue of whether the authentication is necessary or not

Calhoun                                                           [Page 5]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


   is a point which must be addressed. One way of thinking would be to
   abolish the extension and use the AH [4] header instead.


3. Protocol Extensions

   The following sections will define the extensions to the protocol which
   are necessary for Layer 2 tunneling.

   Note that this document only contains extensions which are not already
   defined in [3]. It is mandatory that all messages contain the
   Foreign-Home Authentication Extension.

   Although the underlying protocol used for tunnel management is the
   same for both Layer 2 and Layer 3 [3], a tunnel between two peers
   MUST not contain both layers. This means that if a layer 2 tunnel is to
   be established between two endpoints and a layer 3 tunnel already
   exists, the Mobile Node MUST establish a NEW tunnel.


3.1.  Registration Request

   This section will define the protocol extensions which are necessary
   during the tunnel registration process.

   The Registration Request message must always include the VTP
   Tunnel-Identifier extension as defined in [3]. In addition, if
   a secure tunnel is required the Mobile-Home Authentication Extension
   as defined in [3] should also be used.


3.1.1.  L2TP Extension

   This extension should be added to a Registration Request message when
   a Layer 2 tunnel is to be initiated. This extension defines local
   configuration information.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |        Protocol Version       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Call ID            |      Call Serial Number       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Framing Capabilities                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Bearer Capabilities                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Calhoun                                                           [Page 6]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Max Channels          |      Firmware Revision        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Vendor String                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Sub-Type                15 (VTP L2TP Extension)

        Sub-Length              10

        Flag                    Bit 1 MUST be set (mandatory support)

        Protocol Version        This field defines the local version of
                                the L2TP protocol stack.

        Call ID                 A unique identifier, unique to a tunnel
                                assigned by the Mobile Node. It is used
                                to multiplex and demultiplex data sent
                                over the tunnel.

        Call Serial Number      An identfier assigned by the Mobile Node
                                to this session for the purposes of
                                identifying this particular session in
                                logged session information. Unlike the
                                Call ID, both the Mobile Node and the
                                Hom Agent associate the same Call
                                Serial Number with a given session. The
                                combination of IP address and call serial
                                number SHOULD be unique.

        Framing Capabilities    This bitmask defines the framing support
                                of the Mobile Node. The following values
                                are currently supported:

                                VTP_FRAMING_ASYNC               0x0001
                                VTP_FRAMING_SYNC                0x0002

        Bearer Capabilities     This bitmask defines the bearer
                                capabilities of the Mobile Node. The
                                following values are currently supported:

                                VTP_BEARER_ANALOG               0x0001
                                VTP_BEARER_DIGITAL              0x0002

        Maximum Channels        This field contains the maximum number of
                                sessions the Mobile Node can support. A
                                zero value indicates that the Mobile Node

Calhoun                                                           [Page 7]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


                                does not support incoming calls.

        Firmware Revisions      This field contains the firmware revision
                                of the Mobile Node.

        Vendor Name             A 64 octet field which contains a vendor
                                specific string describing the type of
                                Mobile Node. This field should be padded
                                with zeros (0).


3.1.2.  Incoming-Call-Request Extension

   This extension is present when the Mobile Node has answered an incoming
   call and wishes the Home Agent to handle the session. The extension
   format is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      | Dialed Length |Dialing Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Call Bearer Type                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Physical Channel ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Dialed Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Dialing Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Subaddress                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                16 (Incoming-Call-Request Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Dialed Length           Contains the length of the Dialed Number
                                Field.

        Dialing Length          Contains the length of the Dialing Number
                                Field.

        Call Bearer Type        This field contains the bearer type used
                                for the incoming call. The following
                                values have been defined:
Calhoun                                                           [Page 8]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


                                VTP_BEARER_ANALOG               0x0001
                                VTP_BEARER_DIGITAL              0x0002

        Physical Channel ID     This field contains the Mobile Node's
                                Channel Identifier for this call. The
                                format of this field is vendor specific.

        Dialed Number           The number which was dialed by the
                                caller, represented as an ASCII string.

        Dialing Number          The number from which the call was
                                initiated, represented as an ASCII string.

        Subaddress              This field contains a zero padded string
                                of octet which contain additional dialing
                                information.


3.1.3.  User-Identification Extension

   This extension is present when the Mobile Node initiated user
   authentication by collecting the username and password and is now
   passing the information along to the Home Agent for final
   authentication.

   When present, the Mobile Node has already initiated LCP and is
   passing along the LCP negotiated parameters. However, the LCP
   information is present in the Link Control Protocol Extension.

   Note that for SLIP, all of the LCP and CHAP specific lengths are
   to be set to zero(0).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |      Authentication Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |UserName Length|Password Length| Challenge Len |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           User Name                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Password                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        CHAP Challenge                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                17 (User-Identification Extension)

Calhoun                                                           [Page 9]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Autentication Type      This bitmask field represents the
                                authentication protocol used with the
                                PPP client. The following values have
                                been reserved:

                                VTP_AUTH_CHAP                   0x0001
                                VTP_AUTH_PAP                    0x0002
                                VTP_AUTH_EAP                    0x0003


                                (Note: This models breaks with EAP since
                                 EAP should ideally simply be forwarded
                                 by the Mobile Node to the authenticating
                                 server).

        UserName Length         Length of the User Name Field

        Password Length         Length of the Password Field

        Challenge Length        Length of the CHAP Challenge Field

        UserName                String representing the User Name. This
                                field may be up to 63 characters.

        Password                String representing the User's Password.
                                If Authentication Type was set to CHAP,
                                then this field contains the CHAP Response.
                                This field may be up to 128 octets.

        CHAP Challenge          Set to the challenge sent to the client by
                                the NAS.


3.1.4.  Link-Control-Protocol Extension

   This extension is present when the Mobile Node initiated user
   authentication by collecting the username and password and the
   layer protocol has been identified as PPP (since LCP was
   negotiated).

   Note that for SLIP connections, this extension is not present.




Calhoun                                                          [Page 10]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  LCP1 Length  |  LCP2 Length  |  LCP3 Length  |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Client LCP ConfAck Packet                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      MN LCP ConfAck Packet                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Client LCP ConfReq Packet                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                18 (Link-Control-Protocol Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        LCP1 Length             Length of the Client LCP ConfAck Field

        LCP2 Length             Length of the MN LCP ConfAck Field

        LCP3 Length             Length of the Client LCP ConfReq Field

        Client LCP ConfAck      Contains a copy of the closing ConfAck
                                received from the client.

        MN LCP ConfAck          Contains a copy of the closing ConfAck
                                sent to the client by the Mobile Node.

        Client LCP ConfReq      This may be used by the Home Agent to
                                detect capabilities of the client which
                                were negotiated away while starting LCP
                                with the Mobile Node.  Detection of such
                                options may be used by the Home Agent to
                                decide to renegotiate LCP.


3.1.4.  Incoming-Call-Established Extension

   This extension is present in the Registration Request ONLY if the call
   has already been accepted by the Mobile Node. The absence of this
   extension in the message indicates to the Home Agent that the
   Registration Response will result in the call being accepted.


Calhoun                                                          [Page 11]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


   This is especially useful in cases where the Home Agent is to accept
   the call based on the DNIS/ANI (which is available on Digital calls),
   or when the Home Agent has been placed into an adminitrative mode
   whereby it cannot accept new calls.

   The format of the extension is as follow:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       Peer's Call ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Connect Speed                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Packet Recv. Window Size    |     Packet Transmit Delay     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Framing Type                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                19 (Incoming-Call-Established Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Call ID                 This field is set to the

        Connect Speed           This field contains the speed at which
                                the connection was established.

        Recv. Window Size       This field may optionally be set if
                                flow control is used at the GRE layer. If
                                set, this field contains the number of
                                packets the Mobile Node will buffer for
                                this session.

        Packet Transmit Delay   A measure of the packet processing delay
                                that might be imposed on data sent to the
                                Mobile Node from the Home Agent.  This
                                value is specified in units of 1/10
                                seconds.  See Appendix A for a description
                                of how this value is determined and used.

        Framing Type            A value indicating the type of PPP
                                framing being used by this incoming call.
                                   1 - Call uses asynchronous framing
                                   2 - Call uses synchronous framing

Calhoun                                                          [Page 12]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


3.1.5.  Outgoing-Call-Request Extension

   The Outgoing-Call-Request Extension is added to the Registration
   Request if the Mobile Node wishes to establish an outgoing call with
   the Home Agent. This extension contains information required in order
   to for the Home Agent to make the call.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |      Phone Number Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Minimum BPS                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Maximum BPS                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Bearer Type                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Framing Type                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Packet Recv. Window Size    |    Packet Processing Delay    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                   Phone Number (64 octets)                    +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Subaddress (64 octets)                     +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                20 (Outgoing-Call-Request Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Minimum BPS             The lowest acceptable line speed (in
                                bits/second) for this session.

        Maximum BPS             The highest acceptable line speed (in
                                bits/second) for this session.

        Call Bearer Type        This field contains the bearer type used
                                for the incoming call. The following
                                values have been defined:


Calhoun                                                          [Page 13]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


                                VTP_BEARER_ANALOG               0x0001
                                VTP_BEARER_DIGITAL              0x0002
                                VTP_BEARER_ANY                  0x0003

        Framing Type            A value indicating the type of PPP
                                framing being used by this incoming call.

                                VTP_FRAMING_ASYNC               0x0001
                                VTP_FRAMING_SYNC                0x0002
                                VTP_FRAMING_ANY                 0x0003

        Recv. Window Size       This field may optionally be set if
                                flow control is used at the GRE layer. If
                                set, this field contains the number of
                                packets the Mobile Node will buffer for
                                this session.

        Packet Processing Delay A measure of the packet processing delay
                                that might be imposed on data sent to the
                                Mobile Node from the Home Agent.  This
                                value is specified in units of 1/10
                                seconds.  See Appendix A for a description
                                of how this value is determined and used.

        Phone Number Length     The actual number of valid digits in the
                                Phone Number field.

        Reserved1               This field MUST be 0.

        Phone Number            The number to be dialed to establish the
                                outgoing session.  For ISDN and analog
                                calls this field is an ASCII string.

        Subaddress              A 64 octet field used to specify
                                additional dialing information.  If the
                                subaddress is less than 64 octets long,
                                the remainder of this field is filled
                                with octets of value 0.


3.2.  Registration Response

   This section will define the protocol extensions which are necessary
   during the Registration Response process.

   The Registration Response message must always include the VTP
   Tunnel-Identifier extension as defined in [3]. In addition, if
   a secure tunnel is required the Mobile-Home Authentication Extension

Calhoun                                                          [Page 14]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


   as defined in [3] should also be used.


3.2.1.  Incoming-Call-Confirm Extension

   This extension is present in the Registration Response to inform the
   Mobile Node of Home Agent specific configuration.

   The format of the extension is as follow:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |   Reserved    |   Error Code  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Call ID            |       Peer's Call ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Packet Recv. Window Size    |     Packet Transmit Delay     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                21 (Incoming-Call-Confirm Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Error Code              This field is set to a non-zero value if
                                a L2TP specific error occurred. If this
                                field is set to a value, the VTP header
                                will have the Code field set to reason
                                unspecified (32).

                                Refer to section 5 for the complete list
                                of L2TP error codes.

        Call ID                 A unique identifier, unique to a tunnel
                                assigned by the Home Agent. It is used
                                to multiplex and demultiplex data sent
                                over the tunnel.

        Peer's Call ID          This field is set to the value received
                                in the Call ID field of the corresponding
                                Incoming-Call-Request message. It is used
                                by the Mobile Node to match the
                                Incoming-Call-Reply with the
                                Incoming-Call-Request it issued. This
                                value is included in the GRE header of

Calhoun                                                          [Page 15]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


                                transmitted data packets for this session.

        Connect Speed           This field contains the speed at which
                                the connection was established.

        Recv. Window Size       This field may optionally be set if
                                flow control is used at the GRE layer. If
                                set, this field contains the number of
                                packets the Mobile Node will buffer for
                                this session.

        Packet Transmit Delay   A measure of the packet processing delay
                                that might be imposed on data sent to the
                                Mobile Node from the Home Agent.  This
                                value is specified in units of 1/10
                                seconds.  See Appendix A for a description
                                of how this value is determined and used.

3.2.2.  Outgoing-Call-Pending Extension

   The Outgoing-Call-Pending extension is sent by the Home Agent to the
   Mobile Node in order to acknowledge the Outgoing-Call-Request. It must
   be followed by a Refresh Request message with the
   Outgoing-Call-Established before the tunnel expires. This means that
   in this case, the Home Agent is responsible for sending the Refresh
   Request to the Mobile Node before the number of seconds which were
   specified in the lifetime field of the Registration Request.

   The format of the extension is as follow:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |   Reserved    |   Error Code  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Call ID            |       Peer's Call ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                28 (Outgoing-Call-Pending Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Error Code              This field is set to a non-zero value if
                                a L2TP specific error occurred. If this
                                field is set to a value, the VTP header

Calhoun                                                          [Page 16]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


                                will have the Code field set to reason
                                unspecified (32).

                                Refer to section 5 for the complete list
                                of L2TP error codes.

        Call ID                 A unique identifier, unique to a tunnel
                                assigned by the Home Agent. It is used
                                to multiplex and demultiplex data sent
                                over the tunnel.

        Peer's Call ID          This field is set to the value received
                                in the Call ID field of the corresponding
                                Incoming-Call-Request message. It is used
                                by the Mobile Node to match the
                                Incoming-Call-Reply with the
                                Incoming-Call-Request it issued. This
                                value is included in the GRE header of
                                transmitted data packets for this session.


3.3.  Refresh Request

   This section will define the protocol extensions which may be present
   in the tunnel refresh process.

   The Refresh Request message must always include the VTP
   Tunnel-Identifier extension as defined in [3]. In addition, if a secure
   tunnel is required the Mobile-Home Authentication Extension as defined
   in [3] should also be used.


3.3.1.  Incoming-Call-Established Extension

   This extension is present in the Refresh Request if the Registration
   Request did not contain this extension. This SHOULD only occur if the
   Registration Request from the Mobile Node was an indication that an
   incoming was present and was requesting confirmation from the Home
   Agent to answer the call.

   Once the call has been answered, a refresh request will be sent from the
   Mobile Node with this extension present.

   The format of the extension is as follow:





Calhoun                                                          [Page 17]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |   Reserved    |   Error Code  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Call ID            |       Peer's Call ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Connect Speed                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Packet Recv. Window Size    |     Packet Transmit Delay     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Framing Type                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                23 (Incoming-Call-Established Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Error Code              This field is set to a non-zero value if
                                a L2TP specific error occurred. If this
                                field is set to a value, the VTP header
                                will have the Code field set to reason
                                unspecified (32).

                                Refer to section 5 for the complete list
                                of L2TP error codes.

        Call ID                 A unique identifier, unique to a tunnel
                                assigned by the Home Agent. It is used
                                to multiplex and demultiplex data sent
                                over the tunnel.

        Peer's Call ID          This field is set to the value received
                                in the Call ID field of the corresponding
                                Incoming-Call-Request message. It is used
                                by the Mobile Node to match the
                                Incoming-Call-Reply with the
                                Incoming-Call-Request it issued. This
                                value is included in the GRE header of
                                transmitted data packets for this session.

        Connect Speed           This field contains the speed at which
                                the connection was established.



Calhoun                                                          [Page 18]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


        Recv. Window Size       This field may optionally be set if
                                flow control is used at the GRE layer. If
                                set, this field contains the number of
                                packets the Mobile Node will buffer for
                                this session.

        Packet Transmit Delay   A measure of the packet processing delay
                                that might be imposed on data sent to the
                                Mobile Node from the Home Agent.  This
                                value is specified in units of 1/10
                                seconds.  See Appendix A for a description
                                of how this value is determined and used.

        Framing Type            A value indicating the type of PPP
                                framing being used by this incoming call.

                                VTP_FRAMING_ASYNC               0x0001
                                VTP_FRAMING_SYNC                0x0002


3.3.2.  Outgoing-Call-Established Extension

   The Outgoing-Call-Established Extension is sent by the Home Agent to
   the Mobile Node once the outgoing call was either successfully
   completed or failed. It provides information to the Mobile Node about
   particular parameters used for the call.  It provides information to
   allow the Mobile Node to regulate the transmission of data to the Home
   Agent for this session.

   The format of the extension is as follow:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |   Reserved    |   Error Code  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Call ID            |       Peer's Call ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Connect Speed                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Packet Recv. Window Size    |    Packet Processing Delay    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Physical Channel ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                22 (Outgoing-Call-Established Extension)


Calhoun                                                          [Page 19]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Call ID                 A unique identifier, unique to a tunnel
                                assigned by the Home Agent. It is used
                                to multiplex and demultiplex data sent
                                over the tunnel.

        Peer's Call ID          This field is set to the value received
                                in the Call ID field of the corresponding
                                Incoming-Call-Request message. It is used
                                by the Mobile Node to match the
                                Incoming-Call-Reply with the
                                Incoming-Call-Request it issued. This
                                value is included in the GRE header of
                                transmitted data packets for this session.

        Error Code              This field is set to a non-zero value if
                                a L2TP specific error occurred. If this
                                field is set to a value, the VTP header
                                will have the Code field set to reason
                                unspecified (32).

                                Refer to section 5 for the complete list
                                of L2TP error codes.

        Cause Code              This field gives additional failure
                                information.  Its value can vary
                                depending upon the type of call
                                attempted.  For ISDN call attempts it is
                                the Q.931 cause code.

        Connect Speed           This field contains the speed at which
                                the connection was established.

        Recv. Window Size       This field may optionally be set if
                                flow control is used at the GRE layer. If
                                set, this field contains the number of
                                packets the Mobile Node will buffer for
                                this session.

        Packet Transmit Delay   A measure of the packet processing delay
                                that might be imposed on data sent to the
                                Mobile Node from the Home Agent.  This
                                value is specified in units of 1/10
                                seconds.  See Appendix A for a description
                                of how this value is determined and used.

Calhoun                                                          [Page 20]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


                                This value should be set to the maximum
                                delay that can normally occur between the
                                time a packet arrives at the Mobile Node
                                and is delivered to the client. See
                                Appendix A for an example of how this
                                value is determined and used.

        Framing Type            A value indicating the type of PPP
                                framing being used by this incoming call.

                                VTP_FRAMING_ASYNC               0x0001
                                VTP_FRAMING_SYNC                0x0002

        Physical Channel ID     This field contains the Mobile Node's
                                Channel Identifier for this call. The
                                format of this field is vendor specific.

3.3.3.  WAN-Error Extension

   This extension MAY be present in the Refresh Request message from the
   Mobile Node if any errors had occured since the last refresh request
   message.

   The counters are cumulative and are never cleared while the connection
   is established.

   The format of the message is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |        Peer's Call ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          CRC Errors                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Framing Errors                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Hardware Overruns                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Buffer Overruns                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Time-out Errors                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Alignment Errors                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                24 (WAN-Error Extension)

Calhoun                                                          [Page 21]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Peer's Call ID          This field is set to the Call ID which was
                                assigned by the receiver of this message.

        CRC Errors              Number of PPP frames received with CRC
                                errors since session was established.

        Framing Errors          Number of improperly framed PPP packets
                                received.

        Hardware Overruns       Number of receive buffer over-runs since
                                session was established.

        Buffer Overruns         Number of buffer over-runs detected since
                                session was established.

        Time-out Errors         Number of time-outs since call was
                                established.

        Alignment Errors        Number of alignment errors since call was
                                established.

3.3.3.  Set-Link-Info Extension

   The Set Link Info Extension may be added to the VTP Refresh Request
   Message if the sender wishes to change PPP-negotiated options.
   Because these options may be changed at any time during the call, this
   message is used in order to inform the peer of the change in options.


   The format of the message is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |        Peer's Call ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Send ACCM                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Receive ACCM                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                25 (Set-Link-Info Extension)


Calhoun                                                          [Page 22]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)


        Peer's Call ID          This field is set to the Call ID which was
                                assigned by the receiver of this message.

        Send ACCM               The send ACCM value the client should use
                                to process outgoing PPP packets.  The
                                default value used by the client until
                                this message is received is 0XFFFFFFFF.

        Receive ACCM            The receive ACCM value the client should
                                use to process incoming PPP packets. The
                                default value used by the client until
                                this message is received is 0XFFFFFFFF.


3.4.  Refresh Response

   The following is the extension which may be present in the tunnel
   refresh response.

   The Refresh Response message must always include the VTP
   Tunnel-Identifier extension as defined in [3]. In addition, if a secure
   tunnel is required the Mobile-Home Authentication Extension as defined
   in [3] should also be used.


3.4.1.  Set-Link-Info Extension

   The Set Link Info Extension may be added to the VTP Refresh Response
   Message if the sender wishes to change PPP-negotiated options. Because
   these options may be changed at any time during the call, this message
   is used in order to inform the peer of the change in options.

   The format of the message is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |        Peer's Call ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Send ACCM                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Receive ACCM                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun                                                          [Page 23]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996

        Sub-Type                25 (Set-Link-Info Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Peer's Call ID          This field is set to the Call ID which was
                                assigned by the receiver of this message.

        Send ACCM               The send ACCM value the client should use
                                to process outgoing PPP packets.  The
                                default value used by the client until
                                this message is received is 0XFFFFFFFF.

        Receive ACCM            The receive ACCM value the client should
                                use to process incoming PPP packets. The
                                default value used by the client until
                                this message is received is 0XFFFFFFFF.


3.5.  Deregistration Request

   This section will define the protocol extensions which are necessary
   during the tunnel deregistration process.

   The Deregistration Request message must always include the VTP
   Tunnel-Identifier Extension as defined in [3]. In addition, if a secure
   tunnel is required the Mobile-Home Authentication Extension as defined
   in [3] should also be used.


3.5.2.  L2TP Disconnect-Request Extension

   This extension must be present in the Deregistration Request if the
   initiator of the deregistration is the Home Agent. This message
   includes the Call ID which is necessary for the Mobile Node in order
   to determine the call to disconnect.

   The format of the extension is as follow:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                26 (L2TP Disconnect-Request Extension)


Calhoun                                                          [Page 24]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Call ID                 The Call ID assigned by the receiver of
                                this message. This value is used instead
                                of the Peer's Call ID because the latter
                                may not be known to the peer if the call
                                must be aborted during call establishment.


3.5.1.  Disconnect-Info Extension

   This extension is present in the Deregistration Request if the Mobile
   Node is the initiator of this message.

   The format of the extension is as follow:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |   Reserved    |   Error Code  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Call ID            |          Cause Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +              Call Statistics (128 octets)                     +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                27 (Disconnect-Info Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Error Code              This field is set to a non-zero value if
                                a L2TP specific error occurred. If this
                                field is set to a value, the VTP header
                                will have the Code field set to reason
                                unspecified (32).

                                Refer to section 5 for the complete list
                                of L2TP error codes.

        Call ID                 The Call ID assigned by the receiver of
                                this message. This value is used instead

Calhoun                                                          [Page 25]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


                                of the Peer's Call ID because the latter
                                may not be known to the peer if the call
                                must be aborted during call establishment.

        Cause Code              This field contains disconnection
                                specific information. The value is
                                specific to the Bearer Type (for Digital
                                calls, the value should contain the Q.931
                                cause code).

        Call Statistics         This field contains a vendor specific
                                string of 128 octets representing the
                                call statistics. This field MUST be
                                padded with zero (0).

3.6.  Deregistration Response

   This section will define the protocol extensions which are necessary
   during the tunnel deregistration process.

3.6.1.  Disconnect-Info Extension

   This extension is present in the Deregistration Response if the Mobile
   Node is the initiator of this message.

   The format of the extension is as follow:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |   Reserved    |   Error Code  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Call ID            |          Cause Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +              Call Statistics (128 octets)                     +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                27 (Disconnect-Info Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Error Code              This field is set to a non-zero value if
                                a L2TP specific error occurred. If this

Calhoun                                                          [Page 26]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


                                field is set to a value, the VTP header
                                will have the Code field set to reason
                                unspecified (32).

                                Refer to section 5 for the complete list
                                of L2TP error codes.

        Call ID                 The Call ID assigned by the receiver of
                                this message. This value is used instead
                                of the Peer's Call ID because the latter
                                may not be known to the peer if the call
                                must be aborted during call establishment.

        Cause Code              This field contains disconnection
                                specific information. The value is
                                specific to the Bearer Type (for Digital
                                calls, the value should contain the Q.931
                                cause code).

        Call Statistics         This field contains a vendor specific
                                string of 128 octets representing the
                                call statistics. This field MUST be
                                padded with zero (0).

5. Error Codes

   The Error Code field in the L2TP extensions are defined in this
   appendix. The field should be set to a non-zero value when the Code
   field of the VTP header is set to 32 (reason unspecified). The
   following values have been defined:

        VTP_NOT_CONNECTED                       0x01
                No control connection exists yet for this Mobile Node-Home
                Agent pair.

        VTP_BAD_FORMAT                          0x02
                Length is wrong.

        VTP_BAD_VALUE                           0x03
                One of the field values was out of range or reserved
                field was non-zero.

        VTP_NO_RESOURCES                        0x04
                Insufficient resources to handle this command now.

        VTP_BAD_CALL_ID                         0x05
                The Call ID is invalid in this context.


Calhoun                                                          [Page 27]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


        VTP_NO_CARRIER                          0x06
                Outgoing Call failed due to no carrier detected or call
                lost due to lost of carrier.

        VTP_BUSY                                0x07
                Outgoing Call failed due to detection of a busy signal.

        VTP_NO_DIAL_TONE                        0x08
                Outgoing Call failed due to lack of a dial tone.

        VTP_CALL_PROHIBITED                     0x09
                Outgoing Call administratively prohibited or the Mobile
                Node should not accept the incoming call.  It should
                hang up or issue a busy indication.

        VTP_ADMIN_SHUTDOWN                      0x0a
                Call disconnecte for administrative reasons.

        VTP_DISC_REQUESTED                      0x0b
                Call disconnected due to received L2TP Disconnect-Request.


5. Data Encapsulation

   Once a "tunnel" has been established via a success Registration
   Request, all data is encapsulated within a GRE header.

   This section defines the encapsulation header which is required for the
   VTP and L2TP extension.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|R|K|S|s|Recur|A|T|L|Flg| Ver |        Protocol Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          CheckSum (Opt)       |          Offset(Opt)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Key (Opt)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number (Opt)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Routing (Opt)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Tunnel Identifier (Opt)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   L2TP (HW) Payload Length    |       L2TP (LW) Call ID       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Acknowledgment Number (Optional)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun                                                          [Page 28]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


        C                       Checksum Present. Set to zero (0).

        R                       Routing Present. Set to zero (0).

        K                       Key Present.  Set to zero (1) if the
                                packet is authenticated.

        S                       Sequence Number Present.  Set to one
                                (1) if a payload (data) packet is present.
                                Set to zero (0) if payload is not present
                                (GRE packet is an Acknowledgment only).

        S                       Sequence Number Present. Set to one (1).

        s                       Strict Source Route Present. Set to
                                zero (0).

        A                       Acknowledgment sequence number present.
                                Set to one (1) if packet contains
                                Acknowledgment Number to be used for
                                acknowledging previously transmitted
                                data.

        T                       Tunnel Identifier. Set to one (1).

        L                       L2TP Tunnel Information. Set to one (1)
                                for L2TP tunnels.

        Recur                   Recursion control. set to zero (0).

        Flg (Flags)             Must be set to zero.

        Ver                     Must contain 0.

        Protocol Type           Contains the Assigned Protocol ID
                                (see assigned numbers RFC).

        Key                     Key field is zero if each packet is not
                                authenticated.

        Sequence Number         Contains the sequence number of the
                                payload.  Present if 'S' bit is set.

        Tunnel Identifier       Contains the Tunnel Identifier which was
                                negotiated during the Registration
                                process. Present if the 'T' bit is set.



Calhoun                                                          [Page 29]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


                                This field is used in order to identify
                                which tunnel the data belongs to.

        L2TP                    The L2TP field contains two fields and
                                is present if the 'L' bit is set. The
                                sub-fields are:

                                Payload Length
                                        (High 2 octets of Key) Size of the
                                        payload, not including the GRE
                                        header.

                                Call ID
                                        (Low 2 octets) Contains the Peer's
                                        Call ID for the session to which
                                        this packet belongs.

        Acknowledgment Number   Contains the sequence number of the
                                highest numbered GRE packet received by
                                the sending peer for this user session.
                                Present if 'A' bit is set.

   Note that an encapsulated packet which contains an invalid tunnel
   identifier in the Sequence Number field MUST be dropped.


Acknowledgements

   I would like to thank the following people for their help and support:
   Andy Valencia, Kory Hamzeh, Gurdeep Singh Pall, Tim Mortsolf, Tom
   Stoner


References

   [1] Valencia, Littlewood, Kolar,
       "Layer Two Forwarding (Protocol) "L2F"", Internet-Draft,
       draft-ietf-pppext-l2f-02.txt, April 1996.

   [2] Hamzeh, et al, "Point-to-Point Tunneling Protocol--PPTP",
       Internet-Draft, draft-ietf-pppext-pptp-00.txt,  July 1996.

   [3] Pat R. Calhoun, "Virtual Tunneling Protocol (VTP)",
       Internet-Draft, draft-calhoun-vtp-protocol-00.txt,  July 1996.

   [4] R. Atkinson, "Security Architecture for the Internet Protocol",
       RFC-1825, August 1995


Calhoun                                                          [Page 30]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


<Appendix A and B were literally pulled out from [2]>

Appendix A. Acknowledgment Time-Outs

   L2TP uses sliding windows and time-outs to provide both user session
   flow-control across the internetwork and to perform efficient data
   buffering to keep the Mobile Node-Home Agent data channels full without
   causing receive buffer overflow.  L2TP requires that a time-out be used
   to recover from dropped data or acknowledgment packets.  The exact
   implementation of the time-out is vendor-specific.  It is suggested
   that an adaptive time-out be implemented with backoff for congestion
   control.  The time-out mechanism proposed here has the following
   properties:

      Independent time-outs for each session. A VTP device (Mobile Node or
      Home Agent) will have to maintain and calculate time-outs for every
      active session. An administrator-adjustable maximum time-out,
      MaxTimeOut, unique to each device.

      An adaptive time-out mechanism that compensates for changing
      throughput.  To reduce packet processing overhead, vendors may
      choose not to recompute the adaptive time-out for every received
      acknowledgment.  The result of this overhead reduction is that the
      time-out will not respond as quickly to rapid network changes.
      Timer backoff on time-out to reduce congestion. The backed-off
      timer value is limited by the configurable maximum time-out value.
      Timer backoff is done every time an acknowledgment time-out
      occurs.

   In general, this mechanism has the desirable behavior of quickly
   backing off upon a time-out and of slowly decreasing the time-out
   value as packets are delivered without time-outs.
   Some definitions:

      Packet Processing Delay (PPD) is the amount of time required for
      each side to process the maximum amount of data buffered in their
      receive packet sliding window. The PPD is the value exchanged
      between the Mobile Node and Home Agent when a call is established.
      For the Home Agent, this number should be small.  For a Mobile Node
      making modem connections, this number could be significant.

      Sample is the actual amount of time incurred receiving an
      acknowledgment for a packet. The Sample is measured, not
      calculated.

      Round-Trip Time (RTT) is the estimated round-trip time for an
      Acknowledgment to be received for a given transmitted packet. When
      the network link is a local network, this delay will be minimal

Calhoun                                                          [Page 31]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


      (if not zero). When the network link is the Internet, this delay
      could be substantial and vary widely. RTT is adaptive: it will
      adjust to include the PPD and whatever shifting network delays
      contribute to the time between a packet being transmitted and
      receiving its acknowledgment.

      Adaptive Time-Out (ATO) is the time that must elapse before an
      acknowledgment is considered lost.  After a time-out, the sliding
      window is partially closed and the ATO is backed off.


   Packet Processing Delay (PPD)

   The PPD parameter is a 16-bit word exchanged during the Call Control
   phase that represents tenths of a second (64 means 6.4 seconds). The
   protocol only specifies that the parameter is exchanged, it does not
   specify how it is calculated. The way values for PPD are calculated
   is implementation-dependent and need not be variable (static time-
   outs are allowed). The PPD must be exchanged in the call connect
   sequences, even if it remains constant in an implementation. One
   possible way to calculate the PPD is:

    PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
    PPD = PPD' + MobileNodeFudge

   Header is the total size of the IP and GRE headers, which is 36. The
   MTU is the overall MTU for the internetwork link between the Mobile
   Node and Home Agent. WindowSize represents the number of packets in
   the sliding window, and is implementation-dependent. The latency of the
   internetwork could be used to pick a window size sufficient to keep
   the current session's pipe full. The constant 8 converts octets to
   bits (assuming ConnectRate is in bits per second).  If ConnectRate is
   in bytes per second, omit the 8. MobileNodeFudge is not required but
   can be used to take overall processing overhead of the Mobile Node into
   account. The value of PPD is used to seed the adaptive algorithm with
   the initial RTT[n-1] value.

   Sample

   Sample is the actual measured time for a returned acknowledgment.

   Round-Trip Time (RTT)

   The RTT value represents an estimate of the average time it takes for
   an acknowledgment to be received after a packet is sent to the remote
   end of the tunnel.



Calhoun                                                          [Page 32]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


A.1 Calculating Adaptive Acknowledgment Time-Out

   We still must decide how much time to allow for acknowledgments to
   return. If the time-out is set too high, we may wait an unnecessarily
   long time for dropped packets. If the time-out is too short, we may
   time out just before the acknowledgment arrives. The acknowledgment
   time-out should also be reasonable and responsive to changing network
   conditions.

   The suggested adaptive algorithm detailed below is based on the TCP
   1989 implementation and is explained in Richard Steven's book TCP/IP
   Illustrated, Volume 1 (page 300). 'n' means this iteration of the
   calculation, and 'n-1' refers to values from the last calculation.

      DIFF[n] = SAMPLE[n] - RTT[n-1]
      DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
      RTT[n] = RTT[n-1] + (alpha * DIFF[n])
      ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)
      DIFF represents the error between the last estimated round-trip
      time and the measured time. DIFF is calculated on each iteration.
      DEV is the estimated mean deviation. This approximates the
      standard deviation.  DEV is calculated on each iteration and
      stored for use in the next iteration. Initially, it is set to 0.
      RTT is the estimated round-trip time of an average packet. RTT is
      calculated on each iteration and stored for use in the next
      iteration.  Initially, it is set to PPD.

      ATO is the adaptive time-out for the next transmitted packet. ATO
      is calculated on each iteration.  Its value is limited, by the MIN
      function, to be a maximum of the configured MaxTimeOut value.
      Alpha is the gain for the average and is typically 1/8 (0.125).
      Beta is the gain for the deviation and is typically 1/4 (0.250).
      Chi is the gain for the time-out and is typically set to 4.

   To eliminate division operations for fractional gain elements, the
   entire set of equations can be scaled. With the suggested gain
   constants, they should be scaled by 8 to eliminate all division.  To
   simplify calculations, all gain values are kept to powers of two so
   that shift operations can be used in place of multiplication or
   division.


A.2 Congestion Control: Adjusting for Time-Out

   This section describes how the calculation of ATO is modified in the
   case where a time-out does occur.  When a time-out occurs, the time-
   out value should be adjusted rapidly upward.  Although the GRE
   packets are not retransmitted when a time-out occurs, the time-out

Calhoun                                                          [Page 33]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


   should be adjusted up toward a maximum limit.  To compensate for
   shifting internetwork time delays, a strategy must be employed to
   increase the time-out when it expires.  A simple formula called
   Karn's Algorithm is used in TCP implementations and may be used in
   implementing the backoff timers for the Mobile Node or the Home Agent.
   Notice that in addition to increasing the time-out, we are also
   shrinking the size of the window as described in the next section.
   Karn's timer backoff algorithm, as used in TCP, is:

      NewTIMEOUT = delta * TIMEOUT

   Adapted to our time-out calculations, for an interval in which a
   time-out occurs, the new ATO is calculated as:

      RTT[n] = delta * RTT[n-1]
      DEV[n] = DEV[n-1]
      ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)

   In this modified calculation of ATO, only the two values that
   contribute to ATO and that are stored for the next iteration are
   calculated. RTT is scaled by chi, and DEV is unmodified. DIFF is not
   carried forward and is not used in this scenario. A value of 2 for
   Delta, the time-out gain factor for RTT, is suggested.


Appendix B. Acknowledgment Time-Out and Window Adjustment

B.1 Initial Window Size

   Although each side has indicated the maximum size of its receive
   window, it is recommended that a slow start method be used to begin
   transmitting data.  The initial window size on the transmitter is set
   to half the maximum size the receiver requested, with a minimum size
   of one packet.  The transmitter stops sending packets when the number
   of packets awaiting acknowledgment is equal to the current window
   size.  As the receiver successfully digests each window, the window
   size on the transmitter is bumped up by one packet until the maximum
   is reached. This method prevents a system from flooding an already
   congested network because no history has been established.


B.2 Closing the Window

   When a time-out does occur on a packet, the sender adjusts the size
   of the transmit window down to one half its value when it failed.
   Fractions are rounded up, and the minimum window size is one.



Calhoun                                                          [Page 34]


DRAFT            VTP Layer 2 Protocol Tunnel Extension          July 1996


B.3 Opening the Window

   With every successful transmission of a window's worth of packets
   without a time-out, the transmit window size is increased by one
   packet until it reaches the maximum window size that was sent by the
   other side when the call was connected.  As stated earlier, no
   retransmission is done on a time-out. After a time-out, the
   transmission resumes with the window starting at one half the size of
   the transmit window when the time-out occurred and adjusting upward
   by one each time the transmit window is filled with packets that are
   all acknowledged without time-outs.


B.4 Window Overflow

   When a receiver's window overflows with too many incoming packets,
   excess packets are thrown away.  This situation should not arise if
   the sliding window procedures are being properly followed by the
   transmitter and receiver. It is assumed that, on the transmit side,
   packets are buffered for transmission and are no longer accepted from
   the packet source when the transmit buffer fills.




























Calhoun                                                          [Page 35]