idnits 2.17.1 draft-ietf-issll-isslow-rtf-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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. ** There are 2 instances of too long lines in the document, the longest one being 4 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: ---------------------------------------------------------------------------- -- 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 (June 1999) is 9072 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 510, but no explicit reference was found in the text ** 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' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Carsten Bormann 2 Expires: December 1999 Universitaet Bremen TZI 3 June 1999 5 PPP in a real-time oriented HDLC-like framing 6 draft-ietf-issll-isslow-rtf-05.txt 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 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 [8]. 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 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 (the first octet in an LCP frame before any LCP options have 153 been negotiated), as the start of a new LCP negotiation could 154 otherwise not be reliably detected. 156 Figure 1: Compact Fragment Format 158 0 1 2 3 4 5 6 7 159 +---+---+---+---+---+---+---+---+ 160 | R | sequence | class | 1 | 161 +---+---+---+---+---+---+---+---+ 162 | data | 163 : : 164 +---+---+---+---+---+---+---+---+ 166 Having the least significant bit always be 1 helps with HDLC chips 167 that operate specially on least significant bits in HDLC addresses. 168 (Initial bytes with the least significant bit set to zero are used 169 for the extended compact fragment format, see next section.) 171 The R bit is the inverted equivalent of the B bit in the other 172 multilink fragment formats, i.e. R = 1 means that this fragment 173 resumes a packet previous fragments of which have been sent already. 175 The following trick avoids the case of a header byte of 0xFF (which 176 would mean R=1, sequence=7, and class=7): If the class field is set 177 to 7, the R bit MUST never be set to one. I.e., class 7 frames by 178 design cannot be suspended/resumed. (This is also the reason the 179 sense of the B bit is inverted to an R bit in the compact fragment 180 format -- class 7 would be useless otherwise, as a new packet could 181 never be begun.) 183 As the sequence number is not particularly useful with the class 184 field set to 7, it is used to distinguish eight more classes -- for 185 some minor additional complexity, the applicability of prefix elision 186 is significantly increased by providing more classes with possibly 187 different elided prefixes. 189 For purposes of prefix elision, the actual class number of a fragment 190 is computed as follows: 192 - If the class field is 0 to 6, the class number is 0 to 6, 194 - if the class field is 7 and the sequence field is 0 to 7, the 195 class number is 7 to 14. 197 As a result of this scheme, the classes 0 to 6 can be used for 198 suspendable packets, and classes 7 to 14 (where the class field is 7 199 and the R bit must always be off) can be used for non-suspendable 200 high-priority classes, e.g., eight highly compressed voice streams. 202 5. The Extended Compact Fragment Format 204 For operation over multiple links, a three-bit sequence number will 205 rarely be sufficient. Therefore, we define an optional extended 206 compact fragment format. The option, when negotiated, allows both 207 the basic compact fragment format and the extended compact fragment 208 format to be used; each fragment indicates which format it is in. 210 Figure 1: Extended Compact Fragment Format 212 0 1 2 3 4 5 6 7 213 +---+---+---+---+---+---+---+---+ 214 | R | seq LSB | class | 0 | 215 +---+---+---+---+---+---+---+---+ 216 | sequence -- MSB | 1 | 217 +---+---+---+---+---+---+---+---+ 218 | data | 219 : : 220 +---+---+---+---+---+---+---+---+ 222 In the extended compact fragment format, the sequence number is 223 composed of three least significant bits from the first octet of the 224 fragment header and seven most significant bits from the second 225 octet. (Again, the least significant bit of the second octet is 226 always set to one for compatibility with certain HDLC chips.) 228 For prefix elision purposes, fragments with a class field of 7 can 229 use the basic format to indicate classes 7 to 14 and the extended 230 format to indicate classes 7 to 1030. Different classes may use 231 different formats concurrently without problems. (This allows some 232 classes to be spread over a multi-link and other classes to be 233 confined to a single link with greater efficiency.) For class fields 234 0 to 6, i.e. suspendable classes, one of the two compact fragment 235 formats SHOULD be used consistently within each class. 237 If the use of the extended compact fragment format has been 238 negotiated, receivers MAY keep 10-bit sequence numbers for all 239 classes to facilitate senders switching formats in a class. When a 240 sender starts sending basic format fragments in a class that was 241 using extended format fragments, the 3-bit sequence number can be 242 taken as a modulo-8 version of the 10-bit sequence number, and no 243 discontinuity need result. In the inverse case, if a 10-bit sequence 244 number has been kept throughout by the receiver (and no major slips 245 of the sequence number have occurred), no discontinuity will result, 246 although this cannot be guaranteed in the presence of errors. 247 (Discontinuity, in this context, means that a receiver has to 248 resynchronize sequence numbers by discarding fragments until a 249 fragment with R=0 has been seen.) 251 6. Real-Time Frame Format 253 This section defines how fragments with compact fragment headers are 254 mapped into real-time frames. This format has been designed to 255 retain the overall HDLC based format of frames, so that existing 256 synchronous HDLC chips and async to sync converters can be used on 257 the link. Note that if the design could be optimized for async only 258 operation, more design alternatives would be available [4]; with the 259 advent of V.80 style modems, asynchronous communications is likely to 260 decrease in importance, though. 262 The compact fragment format provides a compact rendition of the PPP 263 multilink header with classes and a reduced sequence number space. 264 However, it does not encode the E-bit of the PPP multilink header, 265 which indicates whether the fragment at hand is the last fragment of 266 a packet. 268 For a solution where packets can be suspended at any point in time, 269 the E-bit needs to be encoded near the end of each fragment. The 270 real-time frame format, to ensure maximum compatibility with type 2 271 receivers, encodes the E-bit in the following way: Any normal frame 272 ending also ends the current fragment with E implicitly set to one. 273 This ensures that packets that are ready for delivery to the upper 274 layers immediately trigger a receive interrupt even at type-2 275 receivers. 277 Fragments of packets that are to be suspended are terminated within 278 the HDLC frame by a special ``fragment suspend escape'' byte (FSE). 279 The overall structure of the HDLC frame does not change; the 280 detection and handling of FSE bytes is done at a layer above HDLC 281 framing. 283 The suspend/resume format with FSE detection is an alternative to 284 address/control field compression (ACFC, LCP option 8). It does not 285 apply to frames that start with 0xFF, the standard PPP-in-HDLC 286 address field; these frames are handled as defined in [6] and [7]. 287 (This provision ensures that attempts to renegotiate LCP do not cause 288 ambiguities.) 290 For frames that do not start with 0xFF, suspend/resume processing 291 performs a scan of every HDLC frame received. The FCS of the HDLC 292 frame is checked and stripped. Compact fragment format headers (both 293 basic and extended) are handled without further FSE processing. 294 (Note that, as the FSE byte was chosen such that it never occurs in 295 compact fragment format headers, this does not require any specific 296 code.) 297 Within the remaining bytes of the HDLC frame (``data part''), an FSE 298 byte is used to indicate the end of the current fragment, with an E bit 299 implicitly cleared. All fragments up to the last FSE are considered 300 suspended (E = 0); the final fragment is terminated (E = 1), or, if it 301 is empty, ignored (i.e., the data part of an HDLC frame can end in an 302 FSE to indicate that the last fragment has E = 0). 304 Each fragment begins with a normal header, so the structure of a frame 305 could be: 307 Figure 2: Example frame with FSE delimiter 309 0 1 2 3 4 5 6 7 310 +---+---+---+---+---+---+---+---+ 311 | R | sequence | class | 1 | 312 +---+---+---+---+---+---+---+---+ 313 | data | 314 : : 315 +---+---+---+---+---+---+---+---+ 316 + FSE + previous fragment implicitly E = 0 317 +---+---+---+---+---+---+---+---+ 318 | R | sequence | class | 1 | 319 +---+---+---+---+---+---+---+---+ 320 | data | 321 : : 322 +---+---+---+---+---+---+---+---+ 323 | Frame | previous fragment implicitly E = 1 324 | CRC | 325 +---+---+---+---+---+---+---+---+ 327 The value chosen for FSE is 0xDE (this is a relatively unlikely byte to 328 occur in today's data streams, it does not trigger octet stuffing and 329 triggers bit stuffing only for 1/8 of the possible preceding bytes). 331 The remaining problem is that of data transparency. In the scheme 332 described so far, an FSE is always followed by a compact fragment 333 header. In these headers, the combination of a class field set to 7 334 with R=1 is reserved. Data transparency is achieved by making the 335 occurrence of an FSE byte followed by one of 0x8F, 0x9F, ... to 0xFF 336 special. 338 Figure 3: Data transparency with FSE bytes present 340 0 1 2 3 4 5 6 7 341 +---+---+---+---+---+---+---+---+ 342 | R | sequence | class | 1 | 343 +---+---+---+---+---+---+---+---+ 344 | data | 345 : : 346 +---+---+---+---+---+---+---+---+ 347 + FSE + fragment NOT terminated 348 +---+---+---+---+---+---+---+---+ 349 | R | S | T | U | 1 | 1 | 1 | 1 | R always is 1 350 +---+---+---+---+---+---+---+---+ 351 | data | fragment continues 352 : : 354 In a combination of FSE/0xnF (where n is the first four-bit field in the 355 second byte, RSTU in Figure 3), the n field gives a sequence of four 356 bits indicating where in the received data stream FSE bytes, which 357 cannot simply be transmitted in the data stream, are to be added by the 358 receiver: 360 0x8F: insert one FSE, back to data 361 0x9F: insert one FSE, copy two data bytes, insert one FSE, back to data 362 0xAF: insert one FSE, copy one data byte, insert one FSE, back to data 363 0xBF: insert one FSE, copy one data byte, insert two FSE bytes, back to data 364 0xCF: insert two FSE bytes, back to data 365 0xDF: insert two FSE bytes, copy one data byte, insert one FSE, back to data 366 0xEF: insert three FSE bytes, back to data 367 0xFF: insert four FSE bytes, back to data 369 The data bytes following the FSE/0xnF combinations and corresponding to 370 the zero bits in the N field may not be FSE bytes. 372 This scheme limits the worst case expansion factor by FSE processing to 373 about 25 %. Also, it is designed such that a single data stream can 374 either trigger worst-case expansion by octet stuffing (or by bit 375 stuffing) or worst-case FSE processing, but never both. Figure 4 376 illustrates the scheme in a few examples; FSE/0xnF pairs are written in 377 lower case. 379 Figure 4: Data transparency examples 381 Data stream FSE-stuffed stream 383 DD DE DF E0 DD de 8f DF E0 384 01 DE 02 DE 03 01 de af 02 03 385 DE DA DE DE DB de bf DA DB 386 DE DE DE DE DE DA de ff de 8f DA 388 In summary, the real-time frame format is a HDLC-like frame delimited by 389 flags and containing a final FCS as defined in [7], but without address 390 and control fields, containing as data a sequence of FSE-stuffed 391 fragments in compact fragment format, delimited by FSE bytes. As a 392 special case, the final FSE may occur as the last byte of the data 393 content (i.e. immediately before the FCS bytes) of the HDLC-like frame, 394 to indicate that the last fragment in the frame is suspended and no 395 final fragment is in the frame (e.g., because the desirable maximum size 396 of the frame has been reached). 398 7. Implementation notes 400 7.1. MRU Issues 402 The LCP parameter MRU defines the maximum size of the packets sent on 403 the link. Async-to-sync converters that are monitoring the LCP 404 negotiations on the link may interpret the MRU value as the maximum 405 HDLC frame size to be expected. 407 Implementations of this specification should preferably negotiate a 408 sufficiently large MRU to cover the worst-case 25 % increase in frame 409 size plus the increase caused by suspended fragments. If that is not 410 possible, the HDLC frame size should be limited by monitoring the 411 HDLC frame sizes and possibly suspending the current fragment by 412 sending an FSE with an empty final fragment (FSE immediately followed 413 by the end of the information field, i.e. by CRC bytes and a flag) to 414 be able to continue in a new HDLC frame. This strategy also helps 415 minimizing the impact of lengthening the HDLC frame on the safety of 416 the 16-bit FCS at the end of the HDLC frame. 418 7.2. Implementing octet-stuffing and FSE processing in one automaton 420 The simplest way to add real-time framing to an implementation may be 421 to perform HDLC processing as usual and then, on the result, to 422 perform FSE processing. A more advanced implementation may want to 423 combine the two levels of escape character processing. Note, 424 however, that FSE processing needs to wait until two bytes from the 425 HDLC frame are available and followed by a third to ensure that the 426 bytes are not the final HDLC FCS bytes, which are not subject to FSE 427 processing. I.e., on the reception of normal data byte, look for an 428 FSE in the second-to-previous byte, and, on the reception of a frame- 429 end, look for an FSE as the last data byte. 431 8. Negotiable options 433 The following options are already defined by MP [2]: 435 o Multilink Maximum Received Reconstructed Unit 437 o Multilink Short Sequence Number Header Format 439 o Endpoint Discriminator 441 The following options are already defined by MCML [5]: 443 o Multilink Header Format 445 o Prefix Elision 447 This document defines two new code points for the Multilink Header 448 Format option. 450 8.1. Multilink header format option 452 The multilink header format option is defined in [5]. A summary of 453 the Multilink Header Format Option format is shown below. The fields 454 are transmitted from left to right. 456 Figure 5: Multilink header format option 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type = 27 | Length = 4 | Code | # Susp Clses | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 As defined in [5], this LCP option advises the peer that the 465 implementation wishes to receive fragments with a format given by the 466 code number, with the maximum number of suspendable classes (see 467 below) given. This specification defines two additional values for 468 Code, in addition to those defined in [5]: 470 - Code = 11: basic and extended compact real-time fragment format 471 with classes, in FSE-encoded HDLC frame 473 - Code = 15: basic compact real-time fragment format with classes, 474 in FSE-encoded HDLC frame 476 An implementation MUST NOT request a combination of both LCP Address- 477 and-Control-Field-Compression (ACFC) and the code values 11 or 15 for 478 this option. 480 The number of suspendable classes negotiated for the compact real- 481 time fragment format only limits the use of class numbers that allow 482 suspending. As class numbers of 7 and higher do not require 483 additional reassembly space, they are not subject to the class number 484 limit negotiated. 486 9. Security Considerations 488 Operation of this protocol is believed to be no more and no less 489 secure than operation of the PPP multilink protocol [2]. Operation 490 with a small sequence number range increases the likelihood that 491 fragments from different packets could be incorrectly reassembled 492 into one packet. While most such packets will be discarded by the 493 receiver because of higher-layer checksum failures or other 494 inconsistencies, there is an increase in likelihood that contents of 495 packets destined for one host could be delivered to another host. 496 Links that carry packets where this raises security considerations 497 SHOULD use the extended sequence number range for multi-fragment 498 packets. 500 10. References 502 [1] C. Bormann, ``Providing integrated services over low-bitrate 503 links'', Work in Progress (draft-ietf-issll-isslow-06.txt), 504 April 1999. 506 [2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 507 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 508 RFC 1717). 510 [3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. 512 [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', Work 513 in Progress (draft-andrades-framing-ext-00.txt), September 1996. 515 [5] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'', 516 Work in Progress (draft-ietf-issll-isslow-mcml-06.txt), April 517 1999. 519 [6] W. Simpson, Editor, ``The Point-to-Point Protocol (PPP)'', RFC 520 1661, July 1994. 522 [7] W. Simpson, Editor, ``PPP in HDLC-like Framing'', RFC 1662, July 523 1994. 525 [8] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 526 Levels'', RFC 2119, March 1997. 528 11. Author's address 530 Carsten Bormann 531 Universitaet Bremen FB3 TZI 532 Postfach 330440 533 D-28334 Bremen, GERMANY 534 cabo@tzi.org 535 phone +49.421.218-7024 536 fax +49.421.218-7000 538 Acknowledgements 540 The participants in a lunch BOF at the Montreal IETF 1996 gave useful 541 input on the design tradeoffs in various environments. Richard 542 Andrades, Fred Burg, and Murali Aravamudan insisted that there should 543 be a suspend/resume solution in addition to the pre-fragmenting one 544 defined in [5]. The members of the ISSLL subgroup on low bitrate 545 links (ISSLOW) have helped in coming up with a set of requirements 546 that shaped this solution.