idnits 2.17.1 draft-calhoun-vtp-ext-l2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 126 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 119: '... message MUST include the VTP Tunnel...' RFC 2119 keyword, line 242: '... MUST not contain both layers. This ...' RFC 2119 keyword, line 244: '... the Mobile Node MUST establish a NEW ...' RFC 2119 keyword, line 284: '... Bit 1 MUST be set (mandator...' RFC 2119 keyword, line 302: '... number SHOULD be unique....' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1996) is 10118 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-pppext-l2f - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-10) exists of draft-ietf-pppext-pptp-00 ** Downref: Normative reference to an Informational draft: draft-ietf-pppext-pptp (ref. '2') -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 1825 (ref. '4') (Obsoleted by RFC 2401) Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Pat R. Calhoun 3 Internet Draft US Robotics Access Corp. 4 expires in six months July 1996 6 Virtual Tunnel Protocol 7 Layer 2 Protocol Extension 8 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Any comments may be forwarded to the sdtp@elroy.usr.com mailing list. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 30 Rim). 32 Abstract 34 The VTP Protocol specification defines a generic tunneling mechanism, 35 as well as extensions for IP and IPX protocols. This specification 36 will detail a method to establish Level 2 (PPP and SLIP) tunnels 37 between two peers. 39 This strawman proposal is intended as a recommendation for using VTP 40 as a generic all-purpose tunnel scheme, as opposed to having multiple 41 tunneling mechanism for layer 2 and 3 protocols. 43 1. Introduction 45 The Secure Dynamic Tunneling Protocol was designed with flexibility in 46 mind. However, the protocol only defines a method for tunneling IP and 47 IPX. It is envisioned that further specification would be published 48 which would describe the method for tunneling additional protocols. 50 This is one such document. This specification will detail the method 51 required for tunneling Layer 2 (PPP and SLIP) protocols within VTP. 53 It is assumed that the reader has existing knowledge of the PPTP [1] 54 and L2F [2] proposals. However there is a significant difference in the 55 terminology used in this document. This document does not differenciate 56 the PAC (PPTP Access Concentrator) and PNS (PPTP Network Server). The 57 terms Mobile Node as used as the device which initiates the tunnel and 58 the term Home Agent is used as the Tunnel termininator. 60 2. Protocol Overview 62 In the existing VTP specification extensions for IP and IPX have been 63 defined. This specification details the extensions necessary for 64 tunneling Layer 2 protocols (i.e. PPP, SLIP). 66 As stated earlier, the PPTP concept of the PAC and the PNS are no 67 longer used, but have been replaced by the terms Mobile Node and Home 68 Agent which are consistent with the existing VTP specification. 70 In the case where a NAS receives an incoming PPP or SLIP call, it acts 71 as a proxy Mobile Node by issuing a Registration Request to the Home 72 Agent in behalf of the dial-up user. However, an issue remains where 73 the Mobile Node must get the IP address of the Home Agent in order to 74 establish the tunnel. 76 In the existing PPTP specification, there is no method defined for 77 learning the IP address of the Home Agent. There are two methods of 78 determining the address of the Home Agent, they are: 80 - The Mobile Node receives the DNIS for the call and passes this 81 on to some central registry (i.e. RADIUS) which returns the IP 82 address of the Home Agent. Although this method does work, it 83 does not scale in large networks. 85 - The Mobile Node negotiates LCP and enters the authentication 86 phase. Once the user name/password pair is received it passes 87 this on to a central registry (i.e. RADIUS) which will return 88 the IP address of the Home Agent. 90 In order to support this, it is assumed that the RADIUS Server 91 has the ability to authenticate the realm only (meaning the 92 user name is a fully qualified name, user@realm). Another less 93 elegant method is to predefine all users in the RADIUS server, 94 but this means that the user information must be duplicated 95 both in the RADIUS server and in the Home Agent. 97 Once the tunnel has been established, the Home Agent must 98 re-open LCP and restart the authentication phase. Although 99 technically feasible, this solution causes many problems with 100 certain existing PPP stacks. 102 In the L2F specification, there is an option where the Mobile Node 103 performs the authentication phase with the PPP client and passes the 104 result to the Home Agent for user authentication. 105 Agent. 107 The Layer 2 Forwarding extension to VTP supports all of the approaches 108 defined above. Note that in order for a Home Agent to conform to this 109 specification, it must have the ability to authentication the user 110 locally. 112 2.1. Dynamic Tunnel Establishment 114 2.1.1. Incoming Call Tunnel Establishment 116 Once a PPP session has been identified by the Mobile Node as a 117 candidate for Layer 2 tunneling and the IP address of the Home Agent 118 is known, a Registration Request is forwarded to the Home Agent. The 119 message MUST include the VTP Tunnel-Identifier Extension, the L2TP 120 Extension and the Incoming-Call-Request Extension. 122 If the Mobile Node has already answered the incoming call the 123 Incoming-Call-Established Extension must be present. The Home Agent is 124 then responsible for reponding with a Registration Response which 125 includes the VTP Tunnel-Identifier Extension and the 126 Incoming-Call-Confirm Extension and begin PPP negotiation. 128 In the case where the Mobile Node wishes to perform the authentication 129 with the client and pass the result to the Home Agent for 130 authentication the User-Identification Extension and the 131 Link-Control-Protocol Extension must be present. In this case, the Home 132 Agent must authenticate the user and if successful respond with a 133 Registration Response. 135 In the case where the Mobile Node wishes to receive confirmation that 136 it should accept the call from the Home Agent, the Registration Request 137 should only contain the VTP Tunnel-Identifier Extension and the 138 L2TP Extension. If the Home Agent wishes the Mobile Node to answer the 139 call, a successful Registration Response must be returned which 140 includes the Incoming-Call-Request Extension. Once the Mobile Node has 141 accepted the call, a Refresh Refresh message is sent to the Home Agent 142 which includes the Incoming-Call-Established Extension. 144 2.1.2. Outgoing Call Tunnel Establishment 146 If a Mobile Node wishes to establish an outgoing call with a Home 147 Agent, a Registration Request must be sent which includes the VTP 148 Tunnel-Identifier Extension and the L2TP Extension and the 149 Outgoing-Call-Request Extension (which includes dialing information). 151 If the Home Agent has the ability of dialing the requested number on 152 the specified bearer type, it must return a Registration Response with 153 the VTP Tunnel-Identifier extension and the Outgoing-Call-Pending 154 extension. 156 Once the outgoing call has been completed, the Home Agent must send 157 a Refresh Request with the VTP Tunnel-Identifier extension as well as 158 the Outgoing-Call-Established Extension. 160 2.2. Dynamic Tunnel Refresh 162 As described in [3], the tunnel refresh mechanism is used as a keep 163 alive to inform each peer that the tunnel is still valid. However, this 164 specification makes use of the tunnel refresh messages to pass along 165 additional information. 167 In [3], the tunnel refreshes are typically initiated by the Mobile 168 Node, however this specification does require that both the Mobile Node 169 and the Home Agent be able to initiate the message. 171 As described above, the Refresh Request may be used by the Mobile Node 172 in the case where it is requesting permission to accept an incoming 173 call from the Home Agent. A successful Registration Response will 174 cause the Mobile Node to initiate a Refresh Request with the 175 VTP Tunnel-Identifier Extension and the Incoming-Call-Established 176 Extension. 178 In the case of an outgoing call, a Refresh Request is sent by the 179 Home Agent in order to notify the Mobile Node that the call either 180 failed or was successfully completed. 182 The Mobile Node may send the WAN-Error Extension in the tunnel refresh 183 if any errors had occurred since the last refresh. Note that the 184 counters are cumulative and are never reset while the connection is 185 established. 187 If a request to change the ACCM has been received by the Home Agent 188 from the PPP client, the Home Agent may send a refresh message to the 189 Mobile Node with the VTP Tunnel-Identifier Extension and the 190 Set-Link-Info Extension. This extension will inform the Mobile Node of 191 the new character mapping table. The Home Agent may include this 192 extension in a Refresh Response if necessary. 194 2.3. Dynamic Tunnel Shutdown 196 As described in [3], the Deregistration Request is sent by the Mobile 197 Node to the Home Agent to inform of a session disconnect. However, 198 since the PPP session is terminated on the Home Agent, the Mobile Node 199 may not know that it must terminate the connection (unless it is 200 examining each LCP packets from the PPP client and the Home Agent). 202 In this extension, the Deregistration Request must be able to be 203 initiated by either peer. 205 If the initiator of the Deregistration Request is the Mobile Node, the 206 message must include the VTP Tunnel-Identifier Extension and the 207 Disconnect-Information Extension. If the initiator is the Home Agent, 208 the L2TP-Disconnect-Request Extension must be present. 210 If the Mobile Node is to respond with a Deregistration Response it must 211 include the VTP Tunnel-Identifier Extension and the 212 Disconnect-Information Extension. 214 2.4. Security Implications 216 Since [3] proposes the use of the Mobile-Home Authentication Extension, 217 it is possible to use this authentication scheme as well with the L2TP 218 extension. However, since the user authentication is performed by the 219 Home Agent, it becomes a challenge to retrieve a session key for the 220 tunnel. 222 Since the user is not authenticated, the session key distribution 223 center will have to generate keys for unauthenticated users. This may 224 not be a problem since the key is not of much use if the username and 225 password pair are invalid. 227 Therefore the issue of whether the authentication is necessary or not 228 is a point which must be addressed. One way of thinking would be to 229 abolish the extension and use the AH [4] header instead. 231 3. Protocol Extensions 233 The following sections will define the extensions to the protocol which 234 are necessary for Layer 2 tunneling. 236 Note that this document only contains extensions which are not already 237 defined in [3]. It is mandatory that all messages contain the 238 Foreign-Home Authentication Extension. 240 Although the underlying protocol used for tunnel management is the 241 same for both Layer 2 and Layer 3 [3], a tunnel between two peers 242 MUST not contain both layers. This means that if a layer 2 tunnel is to 243 be established between two endpoints and a layer 3 tunnel already 244 exists, the Mobile Node MUST establish a NEW tunnel. 246 3.1. Registration Request 248 This section will define the protocol extensions which are necessary 249 during the tunnel registration process. 251 The Registration Request message must always include the VTP 252 Tunnel-Identifier extension as defined in [3]. In addition, if 253 a secure tunnel is required the Mobile-Home Authentication Extension 254 as defined in [3] should also be used. 256 3.1.1. L2TP Extension 258 This extension should be added to a Registration Request message when 259 a Layer 2 tunnel is to be initiated. This extension defines local 260 configuration information. 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | Sub-Type | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Sub-Length | flag | Protocol Version | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Call ID | Call Serial Number | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Framing Capabilities | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Bearer Capabilities | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Max Channels | Firmware Revision | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Vendor String | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Sub-Type 15 (VTP L2TP Extension) 282 Sub-Length 10 284 Flag Bit 1 MUST be set (mandatory support) 286 Protocol Version This field defines the local version of 287 the L2TP protocol stack. 289 Call ID A unique identifier, unique to a tunnel 290 assigned by the Mobile Node. It is used 291 to multiplex and demultiplex data sent 292 over the tunnel. 294 Call Serial Number An identfier assigned by the Mobile Node 295 to this session for the purposes of 296 identifying this particular session in 297 logged session information. Unlike the 298 Call ID, both the Mobile Node and the 299 Hom Agent associate the same Call 300 Serial Number with a given session. The 301 combination of IP address and call serial 302 number SHOULD be unique. 304 Framing Capabilities This bitmask defines the framing support 305 of the Mobile Node. The following values 306 are currently supported: 308 VTP_FRAMING_ASYNC 0x0001 309 VTP_FRAMING_SYNC 0x0002 311 Bearer Capabilities This bitmask defines the bearer 312 capabilities of the Mobile Node. The 313 following values are currently supported: 315 VTP_BEARER_ANALOG 0x0001 316 VTP_BEARER_DIGITAL 0x0002 318 Maximum Channels This field contains the maximum number of 319 sessions the Mobile Node can support. A 320 zero value indicates that the Mobile Node 321 does not support incoming calls. 323 Firmware Revisions This field contains the firmware revision 324 of the Mobile Node. 326 Vendor Name A 64 octet field which contains a vendor 327 specific string describing the type of 328 Mobile Node. This field should be padded 329 with zeros (0). 331 3.1.2. Incoming-Call-Request Extension 333 This extension is present when the Mobile Node has answered an incoming 334 call and wishes the Home Agent to handle the session. The extension 335 format is as follows: 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | Sub-Type | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Sub-Length | flag | Dialed Length |Dialing Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Call Bearer Type | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Physical Channel ID | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Dialed Number | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Dialing Number | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Subaddress | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Sub-Type 16 (Incoming-Call-Request Extension) 356 Sub-Length Variable 358 Flag Bit 1 MUST be set (mandatory support) 360 Dialed Length Contains the length of the Dialed Number 361 Field. 363 Dialing Length Contains the length of the Dialing Number 364 Field. 366 Call Bearer Type This field contains the bearer type used 367 for the incoming call. The following 368 values have been defined: 370 VTP_BEARER_ANALOG 0x0001 371 VTP_BEARER_DIGITAL 0x0002 373 Physical Channel ID This field contains the Mobile Node's 374 Channel Identifier for this call. The 375 format of this field is vendor specific. 377 Dialed Number The number which was dialed by the 378 caller, represented as an ASCII string. 380 Dialing Number The number from which the call was 381 initiated, represented as an ASCII string. 383 Subaddress This field contains a zero padded string 384 of octet which contain additional dialing 385 information. 387 3.1.3. User-Identification Extension 389 This extension is present when the Mobile Node initiated user 390 authentication by collecting the username and password and is now 391 passing the information along to the Home Agent for final 392 authentication. 394 When present, the Mobile Node has already initiated LCP and is 395 passing along the LCP negotiated parameters. However, the LCP 396 information is present in the Link Control Protocol Extension. 398 Note that for SLIP, all of the LCP and CHAP specific lengths are 399 to be set to zero(0). 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type | Length | Sub-Type | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Sub-Length | flag | Authentication Type | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |UserName Length|Password Length| Challenge Len | Reserved | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | User Name | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Password | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | CHAP Challenge | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Sub-Type 17 (User-Identification Extension) 417 Sub-Length Variable 419 Flag Bit 1 MUST be set (mandatory support) 421 Autentication Type This bitmask field represents the 422 authentication protocol used with the 423 PPP client. The following values have 424 been reserved: 426 VTP_AUTH_CHAP 0x0001 427 VTP_AUTH_PAP 0x0002 428 VTP_AUTH_EAP 0x0003 430 (Note: This models breaks with EAP since 431 EAP should ideally simply be forwarded 432 by the Mobile Node to the authenticating 433 server). 435 UserName Length Length of the User Name Field 437 Password Length Length of the Password Field 439 Challenge Length Length of the CHAP Challenge Field 441 UserName String representing the User Name. This 442 field may be up to 63 characters. 444 Password String representing the User's Password. 445 If Authentication Type was set to CHAP, 446 then this field contains the CHAP Response. 447 This field may be up to 128 octets. 449 CHAP Challenge Set to the challenge sent to the client by 450 the NAS. 452 3.1.4. Link-Control-Protocol Extension 454 This extension is present when the Mobile Node initiated user 455 authentication by collecting the username and password and the 456 layer protocol has been identified as PPP (since LCP was 457 negotiated). 459 Note that for SLIP connections, this extension is not present. 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type | Length | Sub-Type | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Sub-Length | flag | Reserved | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | LCP1 Length | LCP2 Length | LCP3 Length | Reserved | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Client LCP ConfAck Packet | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | MN LCP ConfAck Packet | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Client LCP ConfReq Packet | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 Sub-Type 18 (Link-Control-Protocol Extension) 478 Sub-Length Variable 480 Flag Bit 1 MUST be set (mandatory support) 482 LCP1 Length Length of the Client LCP ConfAck Field 484 LCP2 Length Length of the MN LCP ConfAck Field 486 LCP3 Length Length of the Client LCP ConfReq Field 488 Client LCP ConfAck Contains a copy of the closing ConfAck 489 received from the client. 491 MN LCP ConfAck Contains a copy of the closing ConfAck 492 sent to the client by the Mobile Node. 494 Client LCP ConfReq This may be used by the Home Agent to 495 detect capabilities of the client which 496 were negotiated away while starting LCP 497 with the Mobile Node. Detection of such 498 options may be used by the Home Agent to 499 decide to renegotiate LCP. 501 3.1.4. Incoming-Call-Established Extension 503 This extension is present in the Registration Request ONLY if the call 504 has already been accepted by the Mobile Node. The absence of this 505 extension in the message indicates to the Home Agent that the 506 Registration Response will result in the call being accepted. 508 This is especially useful in cases where the Home Agent is to accept 509 the call based on the DNIS/ANI (which is available on Digital calls), 510 or when the Home Agent has been placed into an adminitrative mode 511 whereby it cannot accept new calls. 513 The format of the extension is as follow: 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type | Length | Sub-Type | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Sub-Length | flag | Peer's Call ID | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Connect Speed | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Packet Recv. Window Size | Packet Transmit Delay | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Framing Type | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Sub-Type 19 (Incoming-Call-Established Extension) 530 Sub-Length Variable 532 Flag Bit 1 MUST be set (mandatory support) 534 Call ID This field is set to the 536 Connect Speed This field contains the speed at which 537 the connection was established. 539 Recv. Window Size This field may optionally be set if 540 flow control is used at the GRE layer. If 541 set, this field contains the number of 542 packets the Mobile Node will buffer for 543 this session. 545 Packet Transmit Delay A measure of the packet processing delay 546 that might be imposed on data sent to the 547 Mobile Node from the Home Agent. This 548 value is specified in units of 1/10 549 seconds. See Appendix A for a description 550 of how this value is determined and used. 552 Framing Type A value indicating the type of PPP 553 framing being used by this incoming call. 554 1 - Call uses asynchronous framing 555 2 - Call uses synchronous framing 557 3.1.5. Outgoing-Call-Request Extension 559 The Outgoing-Call-Request Extension is added to the Registration 560 Request if the Mobile Node wishes to establish an outgoing call with 561 the Home Agent. This extension contains information required in order 562 to for the Home Agent to make the call. 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Type | Length | Sub-Type | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Sub-Length | flag | Phone Number Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Minimum BPS | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Maximum BPS | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Bearer Type | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Framing Type | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Packet Recv. Window Size | Packet Processing Delay | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | | 581 + Phone Number (64 octets) + 582 | | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | | 585 + Subaddress (64 octets) + 586 | | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 Sub-Type 20 (Outgoing-Call-Request Extension) 591 Sub-Length Variable 593 Flag Bit 1 MUST be set (mandatory support) 595 Minimum BPS The lowest acceptable line speed (in 596 bits/second) for this session. 598 Maximum BPS The highest acceptable line speed (in 599 bits/second) for this session. 601 Call Bearer Type This field contains the bearer type used 602 for the incoming call. The following 603 values have been defined: 605 VTP_BEARER_ANALOG 0x0001 606 VTP_BEARER_DIGITAL 0x0002 607 VTP_BEARER_ANY 0x0003 609 Framing Type A value indicating the type of PPP 610 framing being used by this incoming call. 612 VTP_FRAMING_ASYNC 0x0001 613 VTP_FRAMING_SYNC 0x0002 614 VTP_FRAMING_ANY 0x0003 616 Recv. Window Size This field may optionally be set if 617 flow control is used at the GRE layer. If 618 set, this field contains the number of 619 packets the Mobile Node will buffer for 620 this session. 622 Packet Processing Delay A measure of the packet processing delay 623 that might be imposed on data sent to the 624 Mobile Node from the Home Agent. This 625 value is specified in units of 1/10 626 seconds. See Appendix A for a description 627 of how this value is determined and used. 629 Phone Number Length The actual number of valid digits in the 630 Phone Number field. 632 Reserved1 This field MUST be 0. 634 Phone Number The number to be dialed to establish the 635 outgoing session. For ISDN and analog 636 calls this field is an ASCII string. 638 Subaddress A 64 octet field used to specify 639 additional dialing information. If the 640 subaddress is less than 64 octets long, 641 the remainder of this field is filled 642 with octets of value 0. 644 3.2. Registration Response 646 This section will define the protocol extensions which are necessary 647 during the Registration Response process. 649 The Registration Response message must always include the VTP 650 Tunnel-Identifier extension as defined in [3]. In addition, if 651 a secure tunnel is required the Mobile-Home Authentication Extension 652 as defined in [3] should also be used. 654 3.2.1. Incoming-Call-Confirm Extension 656 This extension is present in the Registration Response to inform the 657 Mobile Node of Home Agent specific configuration. 659 The format of the extension is as follow: 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Type | Length | Sub-Type | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Sub-Length | flag | Reserved | Error Code | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Call ID | Peer's Call ID | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Packet Recv. Window Size | Packet Transmit Delay | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 Sub-Type 21 (Incoming-Call-Confirm Extension) 674 Sub-Length Variable 676 Flag Bit 1 MUST be set (mandatory support) 678 Error Code This field is set to a non-zero value if 679 a L2TP specific error occurred. If this 680 field is set to a value, the VTP header 681 will have the Code field set to reason 682 unspecified (32). 684 Refer to section 5 for the complete list 685 of L2TP error codes. 687 Call ID A unique identifier, unique to a tunnel 688 assigned by the Home Agent. It is used 689 to multiplex and demultiplex data sent 690 over the tunnel. 692 Peer's Call ID This field is set to the value received 693 in the Call ID field of the corresponding 694 Incoming-Call-Request message. It is used 695 by the Mobile Node to match the 696 Incoming-Call-Reply with the 697 Incoming-Call-Request it issued. This 698 value is included in the GRE header of 699 transmitted data packets for this session. 701 Connect Speed This field contains the speed at which 702 the connection was established. 704 Recv. Window Size This field may optionally be set if 705 flow control is used at the GRE layer. If 706 set, this field contains the number of 707 packets the Mobile Node will buffer for 708 this session. 710 Packet Transmit Delay A measure of the packet processing delay 711 that might be imposed on data sent to the 712 Mobile Node from the Home Agent. This 713 value is specified in units of 1/10 714 seconds. See Appendix A for a description 715 of how this value is determined and used. 717 3.2.2. Outgoing-Call-Pending Extension 719 The Outgoing-Call-Pending extension is sent by the Home Agent to the 720 Mobile Node in order to acknowledge the Outgoing-Call-Request. It must 721 be followed by a Refresh Request message with the 722 Outgoing-Call-Established before the tunnel expires. This means that 723 in this case, the Home Agent is responsible for sending the Refresh 724 Request to the Mobile Node before the number of seconds which were 725 specified in the lifetime field of the Registration Request. 727 The format of the extension is as follow: 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Type | Length | Sub-Type | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Sub-Length | flag | Reserved | Error Code | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Call ID | Peer's Call ID | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Sub-Type 28 (Outgoing-Call-Pending Extension) 740 Sub-Length Variable 742 Flag Bit 1 MUST be set (mandatory support) 744 Error Code This field is set to a non-zero value if 745 a L2TP specific error occurred. If this 746 field is set to a value, the VTP header 747 will have the Code field set to reason 748 unspecified (32). 750 Refer to section 5 for the complete list 751 of L2TP error codes. 753 Call ID A unique identifier, unique to a tunnel 754 assigned by the Home Agent. It is used 755 to multiplex and demultiplex data sent 756 over the tunnel. 758 Peer's Call ID This field is set to the value received 759 in the Call ID field of the corresponding 760 Incoming-Call-Request message. It is used 761 by the Mobile Node to match the 762 Incoming-Call-Reply with the 763 Incoming-Call-Request it issued. This 764 value is included in the GRE header of 765 transmitted data packets for this session. 767 3.3. Refresh Request 769 This section will define the protocol extensions which may be present 770 in the tunnel refresh process. 772 The Refresh Request message must always include the VTP 773 Tunnel-Identifier extension as defined in [3]. In addition, if a secure 774 tunnel is required the Mobile-Home Authentication Extension as defined 775 in [3] should also be used. 777 3.3.1. Incoming-Call-Established Extension 779 This extension is present in the Refresh Request if the Registration 780 Request did not contain this extension. This SHOULD only occur if the 781 Registration Request from the Mobile Node was an indication that an 782 incoming was present and was requesting confirmation from the Home 783 Agent to answer the call. 785 Once the call has been answered, a refresh request will be sent from the 786 Mobile Node with this extension present. 788 The format of the extension is as follow: 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Type | Length | Sub-Type | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Sub-Length | flag | Reserved | Error Code | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Call ID | Peer's Call ID | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Connect Speed | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Packet Recv. Window Size | Packet Transmit Delay | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Framing Type | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Sub-Type 23 (Incoming-Call-Established Extension) 807 Sub-Length Variable 809 Flag Bit 1 MUST be set (mandatory support) 811 Error Code This field is set to a non-zero value if 812 a L2TP specific error occurred. If this 813 field is set to a value, the VTP header 814 will have the Code field set to reason 815 unspecified (32). 817 Refer to section 5 for the complete list 818 of L2TP error codes. 820 Call ID A unique identifier, unique to a tunnel 821 assigned by the Home Agent. It is used 822 to multiplex and demultiplex data sent 823 over the tunnel. 825 Peer's Call ID This field is set to the value received 826 in the Call ID field of the corresponding 827 Incoming-Call-Request message. It is used 828 by the Mobile Node to match the 829 Incoming-Call-Reply with the 830 Incoming-Call-Request it issued. This 831 value is included in the GRE header of 832 transmitted data packets for this session. 834 Connect Speed This field contains the speed at which 835 the connection was established. 837 Recv. Window Size This field may optionally be set if 838 flow control is used at the GRE layer. If 839 set, this field contains the number of 840 packets the Mobile Node will buffer for 841 this session. 843 Packet Transmit Delay A measure of the packet processing delay 844 that might be imposed on data sent to the 845 Mobile Node from the Home Agent. This 846 value is specified in units of 1/10 847 seconds. See Appendix A for a description 848 of how this value is determined and used. 850 Framing Type A value indicating the type of PPP 851 framing being used by this incoming call. 853 VTP_FRAMING_ASYNC 0x0001 854 VTP_FRAMING_SYNC 0x0002 856 3.3.2. Outgoing-Call-Established Extension 858 The Outgoing-Call-Established Extension is sent by the Home Agent to 859 the Mobile Node once the outgoing call was either successfully 860 completed or failed. It provides information to the Mobile Node about 861 particular parameters used for the call. It provides information to 862 allow the Mobile Node to regulate the transmission of data to the Home 863 Agent for this session. 865 The format of the extension is as follow: 867 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 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Type | Length | Sub-Type | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Sub-Length | flag | Reserved | Error Code | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Call ID | Peer's Call ID | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Connect Speed | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Packet Recv. Window Size | Packet Processing Delay | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Physical Channel ID | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Sub-Type 22 (Outgoing-Call-Established Extension) 883 Sub-Length Variable 885 Flag Bit 1 MUST be set (mandatory support) 887 Call ID A unique identifier, unique to a tunnel 888 assigned by the Home Agent. It is used 889 to multiplex and demultiplex data sent 890 over the tunnel. 892 Peer's Call ID This field is set to the value received 893 in the Call ID field of the corresponding 894 Incoming-Call-Request message. It is used 895 by the Mobile Node to match the 896 Incoming-Call-Reply with the 897 Incoming-Call-Request it issued. This 898 value is included in the GRE header of 899 transmitted data packets for this session. 901 Error Code This field is set to a non-zero value if 902 a L2TP specific error occurred. If this 903 field is set to a value, the VTP header 904 will have the Code field set to reason 905 unspecified (32). 907 Refer to section 5 for the complete list 908 of L2TP error codes. 910 Cause Code This field gives additional failure 911 information. Its value can vary 912 depending upon the type of call 913 attempted. For ISDN call attempts it is 914 the Q.931 cause code. 916 Connect Speed This field contains the speed at which 917 the connection was established. 919 Recv. Window Size This field may optionally be set if 920 flow control is used at the GRE layer. If 921 set, this field contains the number of 922 packets the Mobile Node will buffer for 923 this session. 925 Packet Transmit Delay A measure of the packet processing delay 926 that might be imposed on data sent to the 927 Mobile Node from the Home Agent. This 928 value is specified in units of 1/10 929 seconds. See Appendix A for a description 930 of how this value is determined and used. 932 This value should be set to the maximum 933 delay that can normally occur between the 934 time a packet arrives at the Mobile Node 935 and is delivered to the client. See 936 Appendix A for an example of how this 937 value is determined and used. 939 Framing Type A value indicating the type of PPP 940 framing being used by this incoming call. 942 VTP_FRAMING_ASYNC 0x0001 943 VTP_FRAMING_SYNC 0x0002 945 Physical Channel ID This field contains the Mobile Node's 946 Channel Identifier for this call. The 947 format of this field is vendor specific. 949 3.3.3. WAN-Error Extension 951 This extension MAY be present in the Refresh Request message from the 952 Mobile Node if any errors had occured since the last refresh request 953 message. 955 The counters are cumulative and are never cleared while the connection 956 is established. 958 The format of the message is as follows: 960 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 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Type | Length | Sub-Type | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Sub-Length | flag | Peer's Call ID | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | CRC Errors | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Framing Errors | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Hardware Overruns | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Buffer Overruns | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Time-out Errors | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Alignment Errors | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 Sub-Type 24 (WAN-Error Extension) 980 Sub-Length Variable 982 Flag Bit 1 MUST be set (mandatory support) 984 Peer's Call ID This field is set to the Call ID which was 985 assigned by the receiver of this message. 987 CRC Errors Number of PPP frames received with CRC 988 errors since session was established. 990 Framing Errors Number of improperly framed PPP packets 991 received. 993 Hardware Overruns Number of receive buffer over-runs since 994 session was established. 996 Buffer Overruns Number of buffer over-runs detected since 997 session was established. 999 Time-out Errors Number of time-outs since call was 1000 established. 1002 Alignment Errors Number of alignment errors since call was 1003 established. 1005 3.3.3. Set-Link-Info Extension 1007 The Set Link Info Extension may be added to the VTP Refresh Request 1008 Message if the sender wishes to change PPP-negotiated options. 1009 Because these options may be changed at any time during the call, this 1010 message is used in order to inform the peer of the change in options. 1012 The format of the message is as follows: 1014 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 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Type | Length | Sub-Type | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Sub-Length | flag | Peer's Call ID | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Send ACCM | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Receive ACCM | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 Sub-Type 25 (Set-Link-Info Extension) 1026 Sub-Length Variable 1028 Flag Bit 1 MUST be set (mandatory support) 1030 Peer's Call ID This field is set to the Call ID which was 1031 assigned by the receiver of this message. 1033 Send ACCM The send ACCM value the client should use 1034 to process outgoing PPP packets. The 1035 default value used by the client until 1036 this message is received is 0XFFFFFFFF. 1038 Receive ACCM The receive ACCM value the client should 1039 use to process incoming PPP packets. The 1040 default value used by the client until 1041 this message is received is 0XFFFFFFFF. 1043 3.4. Refresh Response 1045 The following is the extension which may be present in the tunnel 1046 refresh response. 1048 The Refresh Response message must always include the VTP 1049 Tunnel-Identifier extension as defined in [3]. In addition, if a secure 1050 tunnel is required the Mobile-Home Authentication Extension as defined 1051 in [3] should also be used. 1053 3.4.1. Set-Link-Info Extension 1055 The Set Link Info Extension may be added to the VTP Refresh Response 1056 Message if the sender wishes to change PPP-negotiated options. Because 1057 these options may be changed at any time during the call, this message 1058 is used in order to inform the peer of the change in options. 1060 The format of the message is as follows: 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Type | Length | Sub-Type | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Sub-Length | flag | Peer's Call ID | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Send ACCM | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Receive ACCM | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 Sub-Type 25 (Set-Link-Info Extension) 1074 Sub-Length Variable 1076 Flag Bit 1 MUST be set (mandatory support) 1078 Peer's Call ID This field is set to the Call ID which was 1079 assigned by the receiver of this message. 1081 Send ACCM The send ACCM value the client should use 1082 to process outgoing PPP packets. The 1083 default value used by the client until 1084 this message is received is 0XFFFFFFFF. 1086 Receive ACCM The receive ACCM value the client should 1087 use to process incoming PPP packets. The 1088 default value used by the client until 1089 this message is received is 0XFFFFFFFF. 1091 3.5. Deregistration Request 1093 This section will define the protocol extensions which are necessary 1094 during the tunnel deregistration process. 1096 The Deregistration Request message must always include the VTP 1097 Tunnel-Identifier Extension as defined in [3]. In addition, if a secure 1098 tunnel is required the Mobile-Home Authentication Extension as defined 1099 in [3] should also be used. 1101 3.5.2. L2TP Disconnect-Request Extension 1103 This extension must be present in the Deregistration Request if the 1104 initiator of the deregistration is the Home Agent. This message 1105 includes the Call ID which is necessary for the Mobile Node in order 1106 to determine the call to disconnect. 1108 The format of the extension is as follow: 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | Type | Length | Sub-Type | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Sub-Length | flag | Call ID | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 Sub-Type 26 (L2TP Disconnect-Request Extension) 1118 Sub-Length Variable 1120 Flag Bit 1 MUST be set (mandatory support) 1122 Call ID The Call ID assigned by the receiver of 1123 this message. This value is used instead 1124 of the Peer's Call ID because the latter 1125 may not be known to the peer if the call 1126 must be aborted during call establishment. 1128 3.5.1. Disconnect-Info Extension 1130 This extension is present in the Deregistration Request if the Mobile 1131 Node is the initiator of this message. 1133 The format of the extension is as follow: 1135 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 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Type | Length | Sub-Type | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Sub-Length | flag | Reserved | Error Code | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Call ID | Cause Code | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | | 1144 + Call Statistics (128 octets) + 1145 | | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 Sub-Type 27 (Disconnect-Info Extension) 1150 Sub-Length Variable 1152 Flag Bit 1 MUST be set (mandatory support) 1154 Error Code This field is set to a non-zero value if 1155 a L2TP specific error occurred. If this 1156 field is set to a value, the VTP header 1157 will have the Code field set to reason 1158 unspecified (32). 1160 Refer to section 5 for the complete list 1161 of L2TP error codes. 1163 Call ID The Call ID assigned by the receiver of 1164 this message. This value is used instead 1165 of the Peer's Call ID because the latter 1166 may not be known to the peer if the call 1167 must be aborted during call establishment. 1169 Cause Code This field contains disconnection 1170 specific information. The value is 1171 specific to the Bearer Type (for Digital 1172 calls, the value should contain the Q.931 1173 cause code). 1175 Call Statistics This field contains a vendor specific 1176 string of 128 octets representing the 1177 call statistics. This field MUST be 1178 padded with zero (0). 1180 3.6. Deregistration Response 1182 This section will define the protocol extensions which are necessary 1183 during the tunnel deregistration process. 1185 3.6.1. Disconnect-Info Extension 1187 This extension is present in the Deregistration Response if the Mobile 1188 Node is the initiator of this message. 1190 The format of the extension is as follow: 1192 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 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Type | Length | Sub-Type | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Sub-Length | flag | Reserved | Error Code | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Call ID | Cause Code | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | | 1201 + Call Statistics (128 octets) + 1202 | | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 Sub-Type 27 (Disconnect-Info Extension) 1207 Sub-Length Variable 1209 Flag Bit 1 MUST be set (mandatory support) 1211 Error Code This field is set to a non-zero value if 1212 a L2TP specific error occurred. If this 1213 field is set to a value, the VTP header 1214 will have the Code field set to reason 1215 unspecified (32). 1217 Refer to section 5 for the complete list 1218 of L2TP error codes. 1220 Call ID The Call ID assigned by the receiver of 1221 this message. This value is used instead 1222 of the Peer's Call ID because the latter 1223 may not be known to the peer if the call 1224 must be aborted during call establishment. 1226 Cause Code This field contains disconnection 1227 specific information. The value is 1228 specific to the Bearer Type (for Digital 1229 calls, the value should contain the Q.931 1230 cause code). 1232 Call Statistics This field contains a vendor specific 1233 string of 128 octets representing the 1234 call statistics. This field MUST be 1235 padded with zero (0). 1237 5. Error Codes 1239 The Error Code field in the L2TP extensions are defined in this 1240 appendix. The field should be set to a non-zero value when the Code 1241 field of the VTP header is set to 32 (reason unspecified). The 1242 following values have been defined: 1244 VTP_NOT_CONNECTED 0x01 1245 No control connection exists yet for this Mobile Node-Home 1246 Agent pair. 1248 VTP_BAD_FORMAT 0x02 1249 Length is wrong. 1251 VTP_BAD_VALUE 0x03 1252 One of the field values was out of range or reserved 1253 field was non-zero. 1255 VTP_NO_RESOURCES 0x04 1256 Insufficient resources to handle this command now. 1258 VTP_BAD_CALL_ID 0x05 1259 The Call ID is invalid in this context. 1261 VTP_NO_CARRIER 0x06 1262 Outgoing Call failed due to no carrier detected or call 1263 lost due to lost of carrier. 1265 VTP_BUSY 0x07 1266 Outgoing Call failed due to detection of a busy signal. 1268 VTP_NO_DIAL_TONE 0x08 1269 Outgoing Call failed due to lack of a dial tone. 1271 VTP_CALL_PROHIBITED 0x09 1272 Outgoing Call administratively prohibited or the Mobile 1273 Node should not accept the incoming call. It should 1274 hang up or issue a busy indication. 1276 VTP_ADMIN_SHUTDOWN 0x0a 1277 Call disconnecte for administrative reasons. 1279 VTP_DISC_REQUESTED 0x0b 1280 Call disconnected due to received L2TP Disconnect-Request. 1282 5. Data Encapsulation 1284 Once a "tunnel" has been established via a success Registration 1285 Request, all data is encapsulated within a GRE header. 1287 This section defines the encapsulation header which is required for the 1288 VTP and L2TP extension. 1290 0 1 2 3 1291 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 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 |C|R|K|S|s|Recur|A|T|L|Flg| Ver | Protocol Type | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | CheckSum (Opt) | Offset(Opt) | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | Key (Opt) | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Sequence Number (Opt) | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Routing (Opt) | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Tunnel Identifier (Opt) | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | L2TP (HW) Payload Length | L2TP (LW) Call ID | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Acknowledgment Number (Optional) | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 C Checksum Present. Set to zero (0). 1311 R Routing Present. Set to zero (0). 1313 K Key Present. Set to zero (1) if the 1314 packet is authenticated. 1316 S Sequence Number Present. Set to one 1317 (1) if a payload (data) packet is present. 1318 Set to zero (0) if payload is not present 1319 (GRE packet is an Acknowledgment only). 1321 S Sequence Number Present. Set to one (1). 1323 s Strict Source Route Present. Set to 1324 zero (0). 1326 A Acknowledgment sequence number present. 1327 Set to one (1) if packet contains 1328 Acknowledgment Number to be used for 1329 acknowledging previously transmitted 1330 data. 1332 T Tunnel Identifier. Set to one (1). 1334 L L2TP Tunnel Information. Set to one (1) 1335 for L2TP tunnels. 1337 Recur Recursion control. set to zero (0). 1339 Flg (Flags) Must be set to zero. 1341 Ver Must contain 0. 1343 Protocol Type Contains the Assigned Protocol ID 1344 (see assigned numbers RFC). 1346 Key Key field is zero if each packet is not 1347 authenticated. 1349 Sequence Number Contains the sequence number of the 1350 payload. Present if 'S' bit is set. 1352 Tunnel Identifier Contains the Tunnel Identifier which was 1353 negotiated during the Registration 1354 process. Present if the 'T' bit is set. 1356 This field is used in order to identify 1357 which tunnel the data belongs to. 1359 L2TP The L2TP field contains two fields and 1360 is present if the 'L' bit is set. The 1361 sub-fields are: 1363 Payload Length 1364 (High 2 octets of Key) Size of the 1365 payload, not including the GRE 1366 header. 1368 Call ID 1369 (Low 2 octets) Contains the Peer's 1370 Call ID for the session to which 1371 this packet belongs. 1373 Acknowledgment Number Contains the sequence number of the 1374 highest numbered GRE packet received by 1375 the sending peer for this user session. 1376 Present if 'A' bit is set. 1378 Note that an encapsulated packet which contains an invalid tunnel 1379 identifier in the Sequence Number field MUST be dropped. 1381 Acknowledgements 1383 I would like to thank the following people for their help and support: 1384 Andy Valencia, Kory Hamzeh, Gurdeep Singh Pall, Tim Mortsolf, Tom 1385 Stoner 1387 References 1389 [1] Valencia, Littlewood, Kolar, 1390 "Layer Two Forwarding (Protocol) "L2F"", Internet-Draft, 1391 draft-ietf-pppext-l2f-02.txt, April 1996. 1393 [2] Hamzeh, et al, "Point-to-Point Tunneling Protocol--PPTP", 1394 Internet-Draft, draft-ietf-pppext-pptp-00.txt, July 1996. 1396 [3] Pat R. Calhoun, "Virtual Tunneling Protocol (VTP)", 1397 Internet-Draft, draft-calhoun-vtp-protocol-00.txt, July 1996. 1399 [4] R. Atkinson, "Security Architecture for the Internet Protocol", 1400 RFC-1825, August 1995 1402 1404 Appendix A. Acknowledgment Time-Outs 1406 L2TP uses sliding windows and time-outs to provide both user session 1407 flow-control across the internetwork and to perform efficient data 1408 buffering to keep the Mobile Node-Home Agent data channels full without 1409 causing receive buffer overflow. L2TP requires that a time-out be used 1410 to recover from dropped data or acknowledgment packets. The exact 1411 implementation of the time-out is vendor-specific. It is suggested 1412 that an adaptive time-out be implemented with backoff for congestion 1413 control. The time-out mechanism proposed here has the following 1414 properties: 1416 Independent time-outs for each session. A VTP device (Mobile Node or 1417 Home Agent) will have to maintain and calculate time-outs for every 1418 active session. An administrator-adjustable maximum time-out, 1419 MaxTimeOut, unique to each device. 1421 An adaptive time-out mechanism that compensates for changing 1422 throughput. To reduce packet processing overhead, vendors may 1423 choose not to recompute the adaptive time-out for every received 1424 acknowledgment. The result of this overhead reduction is that the 1425 time-out will not respond as quickly to rapid network changes. 1426 Timer backoff on time-out to reduce congestion. The backed-off 1427 timer value is limited by the configurable maximum time-out value. 1428 Timer backoff is done every time an acknowledgment time-out 1429 occurs. 1431 In general, this mechanism has the desirable behavior of quickly 1432 backing off upon a time-out and of slowly decreasing the time-out 1433 value as packets are delivered without time-outs. 1434 Some definitions: 1436 Packet Processing Delay (PPD) is the amount of time required for 1437 each side to process the maximum amount of data buffered in their 1438 receive packet sliding window. The PPD is the value exchanged 1439 between the Mobile Node and Home Agent when a call is established. 1440 For the Home Agent, this number should be small. For a Mobile Node 1441 making modem connections, this number could be significant. 1443 Sample is the actual amount of time incurred receiving an 1444 acknowledgment for a packet. The Sample is measured, not 1445 calculated. 1447 Round-Trip Time (RTT) is the estimated round-trip time for an 1448 Acknowledgment to be received for a given transmitted packet. When 1449 the network link is a local network, this delay will be minimal 1450 (if not zero). When the network link is the Internet, this delay 1451 could be substantial and vary widely. RTT is adaptive: it will 1452 adjust to include the PPD and whatever shifting network delays 1453 contribute to the time between a packet being transmitted and 1454 receiving its acknowledgment. 1456 Adaptive Time-Out (ATO) is the time that must elapse before an 1457 acknowledgment is considered lost. After a time-out, the sliding 1458 window is partially closed and the ATO is backed off. 1460 Packet Processing Delay (PPD) 1462 The PPD parameter is a 16-bit word exchanged during the Call Control 1463 phase that represents tenths of a second (64 means 6.4 seconds). The 1464 protocol only specifies that the parameter is exchanged, it does not 1465 specify how it is calculated. The way values for PPD are calculated 1466 is implementation-dependent and need not be variable (static time- 1467 outs are allowed). The PPD must be exchanged in the call connect 1468 sequences, even if it remains constant in an implementation. One 1469 possible way to calculate the PPD is: 1471 PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 1472 PPD = PPD' + MobileNodeFudge 1474 Header is the total size of the IP and GRE headers, which is 36. The 1475 MTU is the overall MTU for the internetwork link between the Mobile 1476 Node and Home Agent. WindowSize represents the number of packets in 1477 the sliding window, and is implementation-dependent. The latency of the 1478 internetwork could be used to pick a window size sufficient to keep 1479 the current session's pipe full. The constant 8 converts octets to 1480 bits (assuming ConnectRate is in bits per second). If ConnectRate is 1481 in bytes per second, omit the 8. MobileNodeFudge is not required but 1482 can be used to take overall processing overhead of the Mobile Node into 1483 account. The value of PPD is used to seed the adaptive algorithm with 1484 the initial RTT[n-1] value. 1486 Sample 1488 Sample is the actual measured time for a returned acknowledgment. 1490 Round-Trip Time (RTT) 1492 The RTT value represents an estimate of the average time it takes for 1493 an acknowledgment to be received after a packet is sent to the remote 1494 end of the tunnel. 1496 A.1 Calculating Adaptive Acknowledgment Time-Out 1498 We still must decide how much time to allow for acknowledgments to 1499 return. If the time-out is set too high, we may wait an unnecessarily 1500 long time for dropped packets. If the time-out is too short, we may 1501 time out just before the acknowledgment arrives. The acknowledgment 1502 time-out should also be reasonable and responsive to changing network 1503 conditions. 1505 The suggested adaptive algorithm detailed below is based on the TCP 1506 1989 implementation and is explained in Richard Steven's book TCP/IP 1507 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 1508 calculation, and 'n-1' refers to values from the last calculation. 1510 DIFF[n] = SAMPLE[n] - RTT[n-1] 1511 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 1512 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 1513 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 1514 DIFF represents the error between the last estimated round-trip 1515 time and the measured time. DIFF is calculated on each iteration. 1516 DEV is the estimated mean deviation. This approximates the 1517 standard deviation. DEV is calculated on each iteration and 1518 stored for use in the next iteration. Initially, it is set to 0. 1519 RTT is the estimated round-trip time of an average packet. RTT is 1520 calculated on each iteration and stored for use in the next 1521 iteration. Initially, it is set to PPD. 1523 ATO is the adaptive time-out for the next transmitted packet. ATO 1524 is calculated on each iteration. Its value is limited, by the MIN 1525 function, to be a maximum of the configured MaxTimeOut value. 1526 Alpha is the gain for the average and is typically 1/8 (0.125). 1527 Beta is the gain for the deviation and is typically 1/4 (0.250). 1528 Chi is the gain for the time-out and is typically set to 4. 1530 To eliminate division operations for fractional gain elements, the 1531 entire set of equations can be scaled. With the suggested gain 1532 constants, they should be scaled by 8 to eliminate all division. To 1533 simplify calculations, all gain values are kept to powers of two so 1534 that shift operations can be used in place of multiplication or 1535 division. 1537 A.2 Congestion Control: Adjusting for Time-Out 1539 This section describes how the calculation of ATO is modified in the 1540 case where a time-out does occur. When a time-out occurs, the time- 1541 out value should be adjusted rapidly upward. Although the GRE 1542 packets are not retransmitted when a time-out occurs, the time-out 1543 should be adjusted up toward a maximum limit. To compensate for 1544 shifting internetwork time delays, a strategy must be employed to 1545 increase the time-out when it expires. A simple formula called 1546 Karn's Algorithm is used in TCP implementations and may be used in 1547 implementing the backoff timers for the Mobile Node or the Home Agent. 1548 Notice that in addition to increasing the time-out, we are also 1549 shrinking the size of the window as described in the next section. 1550 Karn's timer backoff algorithm, as used in TCP, is: 1552 NewTIMEOUT = delta * TIMEOUT 1554 Adapted to our time-out calculations, for an interval in which a 1555 time-out occurs, the new ATO is calculated as: 1557 RTT[n] = delta * RTT[n-1] 1558 DEV[n] = DEV[n-1] 1559 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 1561 In this modified calculation of ATO, only the two values that 1562 contribute to ATO and that are stored for the next iteration are 1563 calculated. RTT is scaled by chi, and DEV is unmodified. DIFF is not 1564 carried forward and is not used in this scenario. A value of 2 for 1565 Delta, the time-out gain factor for RTT, is suggested. 1567 Appendix B. Acknowledgment Time-Out and Window Adjustment 1569 B.1 Initial Window Size 1571 Although each side has indicated the maximum size of its receive 1572 window, it is recommended that a slow start method be used to begin 1573 transmitting data. The initial window size on the transmitter is set 1574 to half the maximum size the receiver requested, with a minimum size 1575 of one packet. The transmitter stops sending packets when the number 1576 of packets awaiting acknowledgment is equal to the current window 1577 size. As the receiver successfully digests each window, the window 1578 size on the transmitter is bumped up by one packet until the maximum 1579 is reached. This method prevents a system from flooding an already 1580 congested network because no history has been established. 1582 B.2 Closing the Window 1584 When a time-out does occur on a packet, the sender adjusts the size 1585 of the transmit window down to one half its value when it failed. 1586 Fractions are rounded up, and the minimum window size is one. 1588 B.3 Opening the Window 1590 With every successful transmission of a window's worth of packets 1591 without a time-out, the transmit window size is increased by one 1592 packet until it reaches the maximum window size that was sent by the 1593 other side when the call was connected. As stated earlier, no 1594 retransmission is done on a time-out. After a time-out, the 1595 transmission resumes with the window starting at one half the size of 1596 the transmit window when the time-out occurred and adjusting upward 1597 by one each time the transmit window is filled with packets that are 1598 all acknowledged without time-outs. 1600 B.4 Window Overflow 1602 When a receiver's window overflows with too many incoming packets, 1603 excess packets are thrown away. This situation should not arise if 1604 the sliding window procedures are being properly followed by the 1605 transmitter and receiver. It is assumed that, on the transmit side, 1606 packets are buffered for transmission and are no longer accepted from 1607 the packet source when the transmit buffer fills.