idnits 2.17.1 draft-ietf-issll-isslow-rtf-02.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-19) 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. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 299 has weird spacing: '... occurs in c...' == Line 300 has weird spacing: '...pact fragment...' -- 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 (March 1998) is 9532 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) == Unused Reference: '3' is defined on line 495, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-03 ** Downref: Normative reference to an Informational draft: draft-ietf-issll-isslow (ref. '1') ** Obsolete normative reference: RFC 1717 (ref. '2') (Obsoleted by RFC 1990) -- No information found for draft-andrades-framing-ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-mcml-03 ** Obsolete normative reference: RFC 1548 (ref. '6') (Obsoleted by RFC 1661) ** Obsolete normative reference: RFC 1549 (ref. '7') (Obsoleted by RFC 1662) Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Carsten Bormann 3 Expires: September 1998 Universitaet Bremen 4 March 1998 6 PPP in a real-time oriented HDLC-like framing 7 draft-ietf-issll-isslow-rtf-02.txt 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 months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Abstract 31 A companion document describes an architecture for providing 32 integrated services over low-bitrate links, such as modem lines, ISDN 33 B-channels, and sub-T1 links [1]. The main components of the 34 architecture are: a real-time encapsulation format for asynchronous 35 and synchronous low-bitrate links, a header compression architecture 36 optimized for real-time flows, elements of negotiation protocols used 37 between routers (or between hosts and routers), and announcement 38 protocols used by applications to allow this negotiation to take 39 place. 41 This document proposes the suspend/resume-oriented solution for the 42 real-time encapsulation format part of the architecture. The general 43 approach is to start from the PPP Multilink fragmentation protocol 44 [2] and its multi-class extension [5] and add suspend/resume in a way 45 that is as compatible to existing hard- and firmware as possible. 47 1. Introduction 49 As an extension to the ``best-effort'' services the Internet is well- 50 known for, additional types of services (``integrated services'') 51 that support the transport of real-time multimedia information are 52 being developed for, and deployed in the Internet. 54 The present document defines the suspend/resume-oriented solution for 55 the real-time encapsulation format part of the architecture. As 56 described in more detail in the architecture document, a real-time 57 encapsulation format is required as, e.g., a 1500 byte packet on a 58 28.8 kbit/s modem link makes this link unavailable for the 59 transmission of real-time information for about 400 ms. This adds a 60 worst-case delay that causes real-time applications to operate with 61 round-trip delays on the order of at least a second -- unacceptable 62 for real-time conversation. 64 A true suspend/resume-oriented approach can only be implemented on a 65 type-1 sender [1], but provides the best possible delay performance 66 to this type of senders. The format defined in this document may 67 also be of interest to certain type-2-senders that want to exploit 68 the better bit-efficiency of this format as compared to [5]. The 69 format was designed so that it can be implemented by both type-1 and 70 type-2 receivers. 72 1.1. Specification Language 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119. 78 2. Requirements 80 The requirements for this document are similar to those listed in 81 [5]. 83 A suspend/resume-oriented solution can provide better worst-case 84 latency than the pre-fragmenting-oriented solution defined in [5]. 85 Also, as this solution requires a new encapsulation scheme, there is 86 an opportunity to provide a slightly more efficient format. 88 Predictability, robustness, and cooperation with PPP and existing 89 hard- and firmware installations are as important with suspend/resume 90 as with pre-fragmenting. A good suspend/resume solution achieves 91 good performance even with type-2 receivers [1] and is able to work 92 with PPP hardware such as async-to-sync converters. 94 Finally, a partial non-requirement: While the format defined in this 95 draft is based on the PPP multilink protocol ([2], also abbreviated 96 as MP), operation over multiple links is in many cases not required. 98 3. General Approach 100 As in [5], the general approach is to start out from PPP multilink 101 and add multiple classes to obtain multiple levels of suspension. 102 However, in contrast to [5], more significant changes are required to 103 be able to suspend the transmission of a packet at any point and 104 inject a higher priority packet. 106 The applicability of the multilink header for suspend/resume type 107 implementations is limited, as the ``end'' bit is in the multilink 108 header, which is the wrong place for suspend/resume operation. To 109 make a big packet suspendable, it must be sent with the ``end'' bit 110 off, and (unless the packet was suspended a small number of bytes 111 before its end) an empty fragment has to be sent afterwards to 112 ``close'' the packet. The minimum overhead for sending a suspendable 113 packet thus is twice the multilink header size (six bytes, including 114 a compressed multilink protocol field) plus one PPP framing (three 115 bytes). Each suspension costs another six bytes (not counting the 116 overhead of the framing for the intervening packet). 118 Also, the existing multi-link header is relatively large; as the 119 frequency of small high-priority packets increases, the overhead 120 becomes significant. 122 The general approach of this document is to start from PPP Multilink 123 with classes and provide a number of extensions to add functionality 124 and reduce the overhead of using PPP Multilink for real-time 125 transmission. 127 This document introduces two new features: 129 1) A compact fragment format and header, and 131 2) a real-time frame format. 133 4. The Compact Fragment Format 135 This section describes an optional multilink fragment format that is 136 more optimized towards single-link operation and frequent suspension 137 (type 1 senders)/a small fragment size (type 2 senders), with 138 optional support for multiple links. 140 When operating over a single link, the Multilink sequence number is 141 used only for loss detection. Even a 12-bit sequence number clearly 142 is larger than required for this application on most kinds of links. 143 We therefore define the following compact multilink header format 144 option with a three-bit sequence number. 146 As, with a compact header, there is little need for sending packets 147 outside the the multilink, we can provide an additional compression 148 mechanism for this format: the MP protocol identifier is not sent 149 with the compact fragment header. This obviously requires prior 150 negotiation (similar to the way address and control field compression 151 are negotiated), as well as a method for avoiding the bit combination 152 0xFF, as the start of a new LCP negotiation could otherwise not be 153 reliably detected. 155 Figure 1: Compact Fragment Format 157 0 1 2 3 4 5 6 7 158 +---+---+---+---+---+---+---+---+ 159 | R | sequence | class | 1 | 160 +---+---+---+---+---+---+---+---+ 161 | data | 162 : : 163 +---+---+---+---+---+---+---+---+ 165 Having the least significant bit always be 1 helps with HDLC chips 166 that operate specially on least significant bits in HDLC addresses. 167 (Initial bytes with the least significant bit set to zero are used 168 for the extended compact fragment format, see next section.) 170 The R bit is the inverted equivalent of the B bit in the other 171 multilink fragment formats, i.e. R = 1 means that this fragment 172 resumes a packet previous fragments of which have been sent already. 174 The following trick avoids the case of a header byte of 0xFF (which 175 would mean R=1, sequence=7, and class=7): If the class field is set 176 to 7, the R bit MUST never be set to one. I.e., class 7 frames by 177 design cannot be suspended/resumed. (This is also the reason the 178 sense of the B bit is inverted to an R bit in the compact fragment 179 format -- class 7 would be useless otherwise, as a new packet could 180 never be begun.) 182 As the sequence number is not particularly useful with the class 183 field set to 7, it is used to distinguish eight more classes -- for 184 some minor additional complexity, the applicability of prefix elision 185 is significantly increased by providing more classes with possibly 186 different elided prefixes. 188 For purposes of prefix elision, the actual class number of a fragment 189 is computed as follows: 191 - If the class field is 0 to 6, the class number is 0 to 6, 193 - if the class field is 7 and the sequence field is 0 to 7, the 194 class number is 7 to 14. 196 As a result of this scheme, the classes 0 to 6 can be used for 197 suspendable packets, and classes 7 to 14 (where the class field is 7 198 and the R bit must always be off) can be used for non-suspendable 199 high-priority classes, e.g., eight highly compressed voice streams. 201 5. The Extended Compact Fragment Format 203 For operation over multiple links, a three-bit sequence number will 204 rarely be sufficient. Therefore, we define an optional extended 205 compact fragment format. The option, when negotiated, allows both 206 the basic compact fragment format and the extended compact fragment 207 format to be used; each fragment indicates which format it is in. 209 Figure 1: Extended Compact Fragment Format 211 0 1 2 3 4 5 6 7 212 +---+---+---+---+---+---+---+---+ 213 | R | seq LSB | class | 0 | 214 +---+---+---+---+---+---+---+---+ 215 | sequence -- MSB | 1 | 216 +---+---+---+---+---+---+---+---+ 217 | data | 218 : : 219 +---+---+---+---+---+---+---+---+ 221 In the extended compact fragment format, the sequence number is 222 composed of three least significant bits from the first octet of the 223 fragment header and seven most significant bits from the second 224 octet. (Again, the least significant bit of the second octet is 225 always set to one for compatibility with certain HDLC chips.) 227 For prefix elision purposes, fragments with a class field of 7 can 228 use the basic format to indicate classes 7 to 14 and the extended 229 format to indicate classes 7 to 1030. Different classes may use 230 different formats concurrently without problems. (This allows some 231 classes to be spread over a multi-link and other classes to be 232 confined to a single link with greater efficiency.) For class fields 233 0 to 6, i.e. suspendable classes, one of the two compact fragment 234 formats SHOULD be used consistently within each class. 236 If the use of the extended compact fragment format has been 237 negotiated, receivers MAY keep 10-bit sequence numbers for all 238 classes to facilitate senders switching formats in a class. When a 239 sender starts sending basic format fragments in a class that was 240 using extended format fragments, the 3-bit sequence number can be 241 taken as a modulo-8 version of the 10-bit sequence number, and no 242 discontinuity need result. In the inverse case, if a 10-bit sequence 243 number has been kept throughout and no major slips of the sequence 244 number have occurred, no discontinuity will result, although this 245 cannot be guaranteed in the presence of errors. (Discontinuity, in 246 this context, means that a receiver has to resynchronize sequence 247 numbers by discarding fragments until a fragment with R=0 has been 248 seen.) 250 6. Real-Time Frame Format 252 This section defines how fragments with compact fragment headers are 253 mapped into real-time frames. This format has been designed to 254 retain the overall HDLC based format of frames, so that existing 255 synchronous HDLC chips and async to sync converters can be used on 256 the link. Note that if the design could be optimized for async only 257 operation, more design alternatives would be available [4]; with the 258 advent of V.80 style modems, asynchronous communications is likely to 259 decrease in importance, though. 261 The compact fragment format provides a compact rendition of the PPP 262 multilink header with classes and a reduced sequence number space. 263 However, it does not encode the E-bit of the PPP multilink header, 264 which indicates whether the fragment at hand is the last fragment of 265 a packet. 267 For a solution where packets can be suspended at any point in time, 268 the E-bit needs to be encoded near the end of each fragment. The 269 real-time frame format, to ensure maximum compatibility with type 2 270 receivers, encodes the E-bit in the following way: Any normal frame 271 ending also ends the current fragment with E implicitly set to one. 272 This ensures that packets that are ready for delivery to the upper 273 layers immediately trigger a receive interrupt even at type-2 274 receivers. 276 Fragments of packets that are to be suspended are terminated within 277 the HDLC frame by a special ``fragment suspend escape'' byte (FSE). 278 The overall structure of the HDLC frame does not change; the 279 detection and handling of FSE bytes is done at a layer above HDLC 280 framing. 282 The suspend/resume format with FSE detection is an alternative to 283 address/control field compression (ACFC, LCP option 8). It does not 284 apply to frames that start with 0xFF, the standard PPP-in-HDLC 285 address field; these frames are handled as defined in [6] and [7]. 286 (This provision ensures that attempts to renegotiate LCP do not cause 287 ambiguities.) 289 For frames that do not start with 0xFF, suspend/resume processing 290 performs a scan of every HDLC frame received. The FCS of the HDLC 291 frame is checked and stripped. Compact fragment format headers (both 292 basic and extended) are handled without further FSE processing*. 293 Within the remaining bytes of the HDLC frame (``data part''), an FSE 294 byte is used to indicate the end of the current fragment, with an E 295 bit implicitly cleared. All fragments up to the last FSE are 296 considered suspended (E = 0); the final fragment is terminated (E = 297 1), or, if it is empty, ignored (i.e., the data part of an HDLC frame 298 _________________________ 299 * As the FSE byte was chosen such that it never occurs in com- 300 pact fragment format headers, this does not require any specific 301 code. 303 can end in an FSE to indicate that the last fragment has E = 0). 305 Each fragment begins with a normal header, so the structure of a 306 frame could be: 308 Figure 2: Example frame with FSE delimiter 310 0 1 2 3 4 5 6 7 311 +---+---+---+---+---+---+---+---+ 312 | R | sequence | class | 1 | 313 +---+---+---+---+---+---+---+---+ 314 | data | 315 : : 316 +---+---+---+---+---+---+---+---+ 317 + FSE + previous fragment implicitly E = 0 318 +---+---+---+---+---+---+---+---+ 319 | R | sequence | class | 1 | 320 +---+---+---+---+---+---+---+---+ 321 | data | 322 : : 323 +---+---+---+---+---+---+---+---+ 324 | Frame | previous fragment implicitly E = 1 325 | CRC | 326 +---+---+---+---+---+---+---+---+ 328 The value chosen for FSE is 0xDE (this is a relatively unlikely byte 329 to occur in today's data streams, it does not trigger octet stuffing 330 and triggers bit stuffing only for 1/8 of the possible preceding 331 bytes). 333 The remaining problem is that of data transparency. In the scheme 334 described so far, an FSE is always followed by a compact fragment 335 header. In these headers, the combination of a class field set to 7 336 with R=1 is reserved. Data transparency is achieved by making the 337 occurrence of an FSE byte followed by one of 0x8F, 0x9F, ... to 0xFF 338 special. 340 Figure 3: Data transparency with FSE bytes present 342 0 1 2 3 4 5 6 7 343 +---+---+---+---+---+---+---+---+ 344 | R | sequence | class | 1 | 345 +---+---+---+---+---+---+---+---+ 346 | data | 347 : : 348 +---+---+---+---+---+---+---+---+ 349 + FSE + fragment NOT terminated 350 +---+---+---+---+---+---+---+---+ 351 | R | S | T | U | 1 | 1 | 1 | 1 | R always is 1 352 +---+---+---+---+---+---+---+---+ 353 | data | fragment continues 354 : : 356 In a combination of FSE/0xnF (where n is the first four-bit field in 357 the second byte, RSTU in Figure 3), the n field gives a sequence of 358 four bits indicating where in the received data stream FSE bytes, 359 which cannot simply be transmitted in the data stream, are to be 360 added by the receiver: 362 0x8F: insert one FSE, back to data 363 0x9F: insert one FSE, copy two data bytes, insert one FSE, back to data 364 0xAF: insert one FSE, copy one data byte, insert one FSE, back to data 365 0xBF: insert one FSE, copy one data byte, insert two FSE bytes, back to data 366 0xCF: insert two FSE bytes, back to data 367 0xDF: insert two FSE bytes, copy one data byte, insert one FSE, back to data 368 0xEF: insert three FSE bytes, back to data 369 0xFF: insert four FSE bytes, back to data 371 The data bytes following the FSE/0xnF combinations and corresponding 372 to the zero bits in the N field may not be FSE bytes. 374 This scheme limits the worst case expansion factor by FSE processing 375 to about 25 %. Also, it is designed such that a single data stream 376 can either trigger worst-case expansion by octet stuffing (or by bit 377 stuffing) or worst-case FSE processing, but never both. Figure 4 378 illustrates the scheme in a few examples; FSE/0xnF pairs are written 379 in lower case. 381 Figure 4: Data transparency examples 383 Data stream FSE-stuffed stream 385 DD DE DF E0 DD de 8f DF E0 386 01 DE 02 DE 03 01 de af 02 03 387 DE DA DE DE DB de bf DA DB 389 In summary, the real-time frame format is a HDLC-like frame delimited 390 by flags and containing a final FCS as defined in [7], but without 391 address and control fields, containing as data a sequence of FSE- 392 stuffed fragments in compact fragment format, delimited by FSE bytes. 393 As a special case, the final FSE may occur as the last byte of the 394 data content (i.e. immediately before the FCS bytes) of the HDLC-like 395 frame, to indicate that the last fragment in the frame is suspended 396 and no final fragment is in the frame (e.g., because the desirable 397 maximum size of the frame has been reached). 399 7. Implementation notes 401 7.1. MRU Issues 403 The LCP parameter MRU defines the maximum size of the packets sent on 404 the link. Async-to-sync converters that are monitoring the LCP 405 negotiations on the link may interpret the MRU value as the maximum 406 HDLC frame size to be expected. 408 Implementations of this specification should preferably negotiate a 409 sufficiently large MRU to cover the worst-case 25 % increase in frame 410 size plus the increase caused by suspended fragments. If that is not 411 possible, the HDLC frame size should be limited by monitoring the 412 HDLC frame sizes and possibly suspending the current fragment by 413 sending an FSE with an empty final fragment (FSE immediately followed 414 by the end of the information field, i.e. by CRC bytes and a flag) to 415 be able to continue in a new HDLC frame. This strategy also helps 416 minimizing the impact of lengthening the HDLC frame on the safety of 417 the 16-bit FCS at the end of the HDLC frame. 419 7.2. Implementing octet-stuffing and FSE processing in one automaton 421 The simplest way to add real-time framing to an implementation may be 422 to perform HDLC processing as usual and then, on the result, to 423 perform FSE processing. A more advanced implementation may want to 424 combine the two levels of escape character processing. Note, 425 however, that FSE processing needs to wait until two bytes from the 426 HDLC frame are available and followed by a third to ensure that the 427 bytes are not the final HDLC FCS bytes, which are not subject to FSE 428 processing. I.e., on the reception of normal data byte, look for an 429 FSE in the second-to-previous byte, and, on the reception of a frame- 430 end, look for an FSE as the last data byte. 432 8. Negotiable options 434 The following options are already defined by MP [2]: 436 o Multilink Maximum Received Reconstructed Unit 438 o Multilink Short Sequence Number Header Format 440 o Endpoint Discriminator 442 The following options are already defined by MCML [5]: 444 o Multilink Header Format 446 o Prefix Elision 448 This document defines two new code points for the Multilink Header 449 Format option. 451 8.1. Multilink header format option 453 The multilink header format option is defined in [5]. A summary of 454 the Multilink Header Format Option format is shown below. The fields 455 are transmitted from left to right. 457 Figure 5: Multilink header format option 459 0 1 2 460 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type = 18 | Length = 3 | Code | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 This option advises the peer that the implementation wishes to 466 receive fragments with a format given by the code number. When this 467 option is received, an implementation MUST either transmit all 468 subsequent multilink packets on all links of the bundle with the 469 multilink header format given or configure-NAK or configure-Reject 470 the option. This specification defines one additional value for 471 Code, in addition to those defined in [5]: 473 - This option present with code = 11: basic and extended compact 474 real-time fragment format with classes, in FSE-encoded HDLC 475 frame 477 - This option present with code = 15: basic compact real-time 478 fragment format with classes, in FSE-encoded HDLC frame 480 An implementation MUST NOT request a combination of both the Short 481 Sequence Number Header Format Option and this option, or of both LCP 482 Address-and-Control-Field-Compression (ACFC) and the code values 11 483 or 15 for this option. 485 9. References 487 [1] C. Bormann, ``Providing integrated services over low-bitrate 488 links'', Work in Progress (draft-ietf-issll-isslow-03.txt), 489 March 1998. 491 [2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 492 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 493 RFC1717). 495 [3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. 497 [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', Work 498 in Progress (draft-andrades-framing-ext-00.txt), September 1996. 500 [5] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'', 501 Work in Progress (draft-ietf-issll-isslow-mcml-03.txt), March 502 1998. 504 [6] W. Simpson, Editor. ``The Point-to-Point Protocol (PPP)'', RFC 505 1661, July 1994 (Obsoletes RFC1548, also STD0051). 507 [7] W. Simpson, Editor. ``PPP in HDLC-like Framing'', RFC 1662, July 508 1994 (Obsoletes RFC1549, also STD0051) 510 10. Author's address 512 Carsten Bormann 513 Universitaet Bremen FB3 TZI 514 Postfach 330440 515 D-28334 Bremen, GERMANY 516 cabo@tzi.uni-bremen.de 517 phone +49.421.218-7024 518 fax +49.421.218-7000 520 Acknowledgements 522 The participants in a lunch BOF at the Montreal IETF 1996 gave useful 523 input on the design tradeoffs in various environments. Richard 524 Andrades, Fred Burg, and Murali Aravamudan insisted that there should 525 be a suspend/resume solution in addition to the pre-fragmenting one 526 defined in [5]. The members of the ISSLL subgroup on low bitrate 527 links (ISSLOW) have helped in coming up with a set of requirements 528 that shaped this solution.