idnits 2.17.1 draft-ietf-pppext-l2tpdwin-01.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-04-16) 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 82: '... o MUST, SHALL, or MANDATORY --...' RFC 2119 keyword, line 85: '... o SHOULD or RECOMMEND -- This ...' RFC 2119 keyword, line 88: '... o MAY or OPTIONAL -- This item...' RFC 2119 keyword, line 216: '...atory. This AVP MUST be present in an...' RFC 2119 keyword, line 217: '...e LNS. This AVP MUST NOT be present i...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (November 1998) is 9284 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) -- Looks like a reference, but probably isn't: 'TBD' on line 215 == Unused Reference: '2' is defined on line 291, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Normative reference to a draft: ref. '4' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group Richard Shea 2 INTERNET DRAFT Nortel Networks 3 Category: Internet Draft 4 Title: draft-ietf-pppext-l2tpdwin-01.txt 5 Date: November 1998 7 L2TP Dynamic Data Window Adjustment 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ftp.ietf.org, nic.nordu.net, ftp.nisc.sri.com, or 25 munnari.oz.au. 27 Abstract 29 The Layer Two Tunneling Protocol (L2TP) defines the specification 30 of congestion window sizes for data sessions. In addition, an LNS 31 is given the capability to turn off sequence number processing for 32 a data session, provided the LAC did not include the Sequencing 33 Required AVP during session setup. This document specifies a 34 mechanism whereby an L2TP peer can dynamically change the maximum 35 window size values being used for a data session, in order to 36 provide the flexibility to operate with smaller window sizes when 37 history-bound protocols are operating over a session, and larger 38 window sizes when no history-bound protocols are operating over a 39 session. 41 1. Introduction 43 In the L2TP protocol sequence numbers are used for preserving 44 packet order, detecting packet loss, rate pacing, and congestion 46 Shea expires May 1999 [Page 1] 47 control. An effective window size value for congestion control is 48 influenced in opposite directions by two things. First, in the 49 case where protocols with history are being carried, the window 50 size must be small enough so that forced packet loss is not 51 excessive in the case of a real packet drop where resynchronization 52 is necessary. At the same time, the larger the delay between the 53 LAC and LNS, the larger the window size should be so that the 54 available bandwidth between the LAC and LNS is not underutilized 55 due to rate pacing and congestion control. 57 Unfortunately, the L2TP protocol specifies that the window sizes 58 for a session are determined when the session is established, at a 59 time before it is known whether or not protocol with history will 60 be operating over the session. 62 It is important for L2TP to provide the flexibility to maximize 63 performance for the cases where history-bound protocols are 64 operating over a data session for a tunnel which is operating over 65 a lossy network and where no history-bound protocols are operating 66 over a data session being tunneled over a high-delay path. Because 67 the knowledge of whether history-bound protocols will be operating 68 over a data session is not known at the time of session setup, a 69 mechanism for dynamically updating the data session window sizes is 70 needed. 72 It is also not possible in all cases for the LAC to detect when a 73 history-bound protocol is being used or not. A mechanism is also 74 included so the LNS can inform the LAC as to whether or not 75 history-bound protocols are being run over the link. 77 1.1 Conventions 79 The following language conventions are used in the items of 80 specification in this document: 82 o MUST, SHALL, or MANDATORY -- This item is an absolute 83 requirement of the specification. 85 o SHOULD or RECOMMEND -- This item should generally be followed 86 for all but exceptional circumstances. 88 o MAY or OPTIONAL -- This item is truly optional and may be 89 followed or ignored according to the needs of the implementor. 91 1.2 Terminology 93 This draft assumes the reader is knowledgable about terms found in 94 [1]. In addition, the following terms are used in this document: 96 Shea expires May 1999 [Page 2] 97 History 99 Application information that is transferred between peers that 100 spans the information conveyed in more than one datagram. 102 History-Bound Protocol 104 A protocol that uses a history during its operation. The 105 canonical example of such protocols in the context of PPP is 106 compression protocols. While compression protocols can be run 107 in a mode where history is not kept between packets, there are 108 some implementations that do not support such a mode; nor is 109 such a mode always the most desirable mode of operation. 111 2. Protocol overview 113 The current practice for L2TP is for data session maximum window 114 sizes to be indicated at the time of session setup, and for these 115 maximum window sizes to remain the same for the life of the 116 session. 118 This document describes an operational addition to L2TP to allow 119 data session maximum window sizes to change during the life of a 120 data session. 122 There are several factors that an implementation can use when 123 deciding on a value for its maximum receive window size: 125 o Rate Pacing - Based on the access speed of the physical 126 connection of the client to the LAC, the LAC may desire to rate 127 pace the data to stay at the rate that the physical connection 128 can handle. 130 o Congestion Control - Based on the load on the box or relative 131 priority of the tunneled user identity. 133 o Operation of history-bound protocols on the link - In order 134 to get reasonable performance on a link using history-bound 135 protocols in the face of packet loss, the maximum window size 136 should be kept small (4 packets or so). 138 Furthermore, the detection of whether or not a history-bound 139 protocol is running over the link is not always possible for an 140 L2TP endpoint. Specifically, a LAC implementation generally does 141 not (and perhaps for performance reasons should not) inspect PPP 142 traffic being forwarded between the LNS and the client being 144 Shea expires May 1999 [Page 3] 145 tunneled. 147 The additions to the protocol suggested here are therefore to: 149 1. Provide a method for the LNS to indicate to the LAC whether 150 or not any history-bound protocols are operating over the link. 152 2. Provide a method for the LNS and LAC to communicate changes 153 in their maximum receive window sizes to each other. 155 To provide both of these mechanisms a new message is specified. 156 When this message is sent from the LNS to the LAC it includes the 157 current state of history-bound protocol operation and a new maximum 158 receive window size. When this new message is sent from the LAC to 159 the LNS it includes a new maximum receive window size. 161 3. Protocol additions 163 This document specifies that the protocol be extended with a new 164 message type: Session-Update (SU). This new message is used during 165 the life of a session to communicate session update information for 166 a data session. 168 This document further specifies two AVPs that can optionally be 169 included in the SU message. For SU messages sent from the LNS to 170 the LAC a new AVP indicating the current state of history protocol 171 operation over the tunneled session can be included. Both the LNS 172 and the LAC can send the SU with the Receive Window Size AVP 173 included to change the maximum receive window size for the data 174 session. 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | L2TP Control Message Header | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Session-Update | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | History Operation State | 182 | (LNS->LAC only) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Receive Window Size | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 The format of the L2TP control message header is given in [1]. 189 The Message Type AVP for this message contains the value [TBD] 190 indicating that this message is a Session-Update message. 192 Shea expires May 1999 [Page 4] 193 History Operation State 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |1|0|0|0|0|0| 8 | 0 | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | [TBD] | 0 |V|H| 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 History Operation State encodes the state of history-bound protocol 204 operation using two bits. The V (VJ) bit indicates whether or not 205 VJ TCP/IP header compression [3] is operating over the link. If 206 the V bit is one (1) this indicates that VJ packets are being sent 207 over the tunneled data session be the LNS. This informs the LAC 208 that upon detection of lost data packets, an indication should be 209 sent over the physical connection to the client that a packet was 210 lost (e.g. the LAC can force a CRC error on the physical connection 211 to the client). If the V bit is zero (0) this indicates that VJ 212 packets are not being sent over the tunneled data session by the 213 LNS. The H (History) bit is set if any other history-bound 214 protocol (other than VJ compression) is being run over the tunneled 215 session. Attribute is [TBD], indicating History Operation Status, 216 and is marked mandatory. This AVP MUST be present in an SU sent by 217 the LNS. This AVP MUST NOT be present in an SU sent by the LAC. 219 Receive Window Size 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |1|0|0|0|0|0| 8 | 0 | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | 10 | Size | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Receive Window Size AVP encodes the window size being advertised 230 for this call. Attribute is 10, indicating Receive Window Size, 231 and is marked mandatory. This AVP itself is optional. The Size 232 value indicates the number of received data packets the sender of 233 the SU will buffer for this call, which is also the maximum number 234 of data packets the receiver of the SU should send before waiting 235 for an acknowledgment. 237 4. Protocol Operation 239 Shea expires May 1999 [Page 5] 240 This extension MUST only be used if both L2TP peers have signaled 241 support of this extension during tunnel establishment using the 242 Extensions AVP defined in [4]. 244 When a session is first started it is not known if a history-bound 245 protocol will be negotiated. An implementation should therefore 246 pick a maximum receive window size based on the assumption that a 247 history-bound protocol will be negotiated. If the tunnel is 248 operating over a reliable medium this is not a factor. If the 249 tunnel is not operating over a reliable medium then an 250 appropriately small window size should be chosen (recommend 4?). 252 When an LNS detects a change in the state of operation of 253 history-bound protocols over the tunneled session it MUST send an 254 SU to the LAC. This allows the LAC to make adjustments to its 255 maximum receive window size, even if the LNS does not make a change 256 itself. 258 Upon reception of the SU with Receive Window Size AVP, the receiver 259 of the SU MUST begin operating under the rules for Receive Window 260 Size AVP values received during data session setup. 262 If the value of the Receive Window Size AVP in the SU is greater 263 than the value of the last Receive Window Size AVP received, there 264 is no further action required by the receiver of the SU other than 265 changing its maximum send window accordingly. 267 If the value of the Receive Window Size AVP in the SU is less than 268 the value of the last Receive Window Size AVP received, then the 269 receveiver of the SU must take special action. In this case, the 270 receiver of the SU must change its maximum send window accordingly, 271 consider any currently unacknowledged packets as acknowledged, and 272 send an R Bit in the next data packet sent to the peer. This 273 prevents the data session from unnecessarily hanging when the 274 window size is adjusted down. 276 If for a particular data session a peer does not send the Receive 277 Window AVP during session establishment, the Receive Window AVP 278 MUST NOT be sent in a subsequent SU message. 280 5. Security Considerations 282 Security is not addressed in this document. 284 References 286 [1] A. Valencia, et al, "Layer Two Tunneling Protocol", Work In 288 Shea expires May 1999 [Page 6] 289 Progress: draft-ietf-pppext-l2tp-12.txt, October 1998 291 [2] D. Rand, "PPP Reliable Transmission". RFC 1663 293 [3] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial 294 Links", RFC 1144, February 1990 296 [4] R. Shea, "Framework for L2TP Message Extensions", Work In 297 Progress: draft-ietf-pppext-l2tpmsgext-00.txt, November 1998 299 Author's Address 301 Richard Shea 302 Nortel Networks 303 125 Nagog Park 304 Acton, Massachusetts 01720 305 rshea@BayNetworks.com 307 Shea expires May 1999 [Page 7]