Pat R. Calhoun Internet Draft US Robotics Access Corp. expires in six months July 1996 Virtual Tunnel Protocol Layer 2 Protocol Extension 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. 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]