idnits 2.17.1 draft-ietf-issll-isslow-rtf-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-26) 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. ** 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 184: '... to 7, the R bit MUST never be set to ...' RFC 2119 keyword, line 241: '... formats SHOULD be used consistently...' RFC 2119 keyword, line 244: '...iated, receivers MAY keep 10-bit seque...' RFC 2119 keyword, line 474: '...n implementation MUST either transmit ...' RFC 2119 keyword, line 487: '...n implementation MUST NOT request a co...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 306 has weird spacing: '... occurs in c...' == Line 307 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 (July 1997) is 9782 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 512, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-02 ** 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-02 ** Obsolete normative reference: RFC 1548 (ref. '6') (Obsoleted by RFC 1661) ** Obsolete normative reference: RFC 1549 (ref. '7') (Obsoleted by RFC 1662) Summary: 16 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: January 1998 Universitaet Bremen 4 July 1997 6 PPP in a real-time oriented HDLC-like framing 7 draft-ietf-issll-isslow-rtf-01.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 This document is a product of the IETF ISSLL working group. 48 Comments are solicited and should be addressed to the two working 49 groups' mailing lists at issll@mercury.lcs.mit.edu and ietf- 50 ppp@merit.edu and/or the author. 52 1. Introduction 54 As an extension to the ``best-effort'' services the Internet is well- 55 known for, additional types of services (``integrated services'') 56 that support the transport of real-time multimedia information are 57 being developed for and deployed in the Internet. 59 A companion document describes an architecture for providing 60 integrated services over low-bitrate links, such as modem lines, ISDN 61 B-channels, and sub-T1 links [1]. The main components of the 62 architecture are: a real-time encapsulation format for asynchronous 63 and synchronous low-bitrate links, a header compression architecture 64 optimized for real-time flows, elements of negotiation protocols used 65 between routers (or between hosts and routers), and announcement 66 protocols used by applications to allow this negotiation to take 67 place. 69 The present document defines the suspend/resume-oriented solution for 70 the real-time encapsulation format part of the architecture. As 71 described in more detail in the architecture document, a real-time 72 encapsulation format is required as, e.g., a 1500 byte packet on a 73 28.8 kbit/s modem link makes this link unavailable for the 74 transmission of real-time information for about 400 ms. This adds a 75 worst-case delay that causes real-time applications to operate with 76 round-trip delays on the order of at least a second -- unacceptable 77 for real-time conversation. 79 A true suspend/resume-oriented approach can only be implemented on a 80 type-1 sender [1], but provides the best possible delay performance 81 to this type of senders. The format defined in this document may 82 also be of interest to certain type-2-senders that want to exploit 83 the better bit-efficiency of this format as compared to [5]. It can 84 be implemented by both type-1 and type-2 receivers. 86 2. Requirements 88 The requirements for this document are similar to those listed in 89 [5]. 91 A suspend/resume-oriented solution can provide better worst-case 92 latency than the pre-fragmenting-oriented solution defined in [5]. 93 Also, as this solution requires a new encapsulation scheme, there is 94 an opportunity to provide a slightly more efficient format. 96 Predictability, robustness, and cooperation with PPP and existing 97 hard- and firmware installations are as important with suspend/resume 98 as with pre-fragmenting. A good suspend/resume solution achieves 99 good performance even with type-2 receivers [1] and is able to work 100 with PPP hardware such as async-to-sync converters. 102 Finally, a partial non-requirement: While the format defined in this 103 draft is based on the PPP multilink protocol ([2], also abbreviated 104 as MP), operation over multiple links is in many cases not required. 106 3. General Approach 108 As in [5], the general approach is to start out from PPP multilink 109 and add multiple classes to obtain multiple levels of suspension. 110 However, in contrast to [5], more significant changes are required to 111 be able to suspend the transmission of a packet at any point and 112 inject a higher priority packet. 114 The applicability of the multilink header for suspend/resume type 115 implementations is limited, as the ``end'' bit is in the multilink 116 header, which is the wrong place for suspend/resume operation. To 117 make a big packet suspendable, it must be sent with the ``end'' bit 118 off, and (unless the packet was suspended a small number of bytes 119 before its end) an empty fragment has to be sent afterwards to 120 ``close'' the packet. The minimum overhead for sending a suspendable 121 packet thus is twice the multilink header size (six bytes, including 122 a compressed multilink protocol field) plus one PPP framing (three 123 bytes). Each suspension costs another six bytes (not counting the 124 overhead of the framing for the intervening packet). 126 Also, the existing multi-link header is relatively large; as the 127 frequency of small high-priority packets increases, the overhead 128 becomes significant. 130 The general approach of this document is to start from PPP Multilink 131 with classes and provide a number of extensions to add functionality 132 and reduce the overhead of using PPP Multilink for real-time 133 transmission. 135 This document introduces two new features: 137 1) A compact fragment format and header, and 139 2) a real-time frame format. 141 4. The Compact Fragment Format 143 This section describes an optional multilink fragment format that is 144 more optimized towards single-link operation and frequent suspension 145 (type 1 senders)/a small fragment size (type 2 senders), with 146 optional support for multiple links. 148 When operating over a single link, the Multilink sequence number is 149 used only for loss detection. Even a 12-bit sequence number clearly 150 is larger than required for this application on most kinds of links. 151 We therefore define the following compact multilink header format 152 option with a three-bit sequence number. 154 As, with a compact header, there is little need for sending packets 155 outside the the multilink, we can provide an additional compression 156 mechanism for this format: the MP protocol identifier is not sent 157 with the compact fragment header. This obviously requires prior 158 negotiation (similar to the way address and control field compression 159 are negotiated), as well as a method for avoiding the bit combination 160 0xFF, as the start of a new LCP negotiation could otherwise not be 161 reliably detected. 163 Figure 1: Compact Fragment Format 165 0 1 2 3 4 5 6 7 166 +---+---+---+---+---+---+---+---+ 167 | R | sequence | class | 1 | 168 +---+---+---+---+---+---+---+---+ 169 | data | 170 : : 171 +---+---+---+---+---+---+---+---+ 173 Having the least significant bit always be 1 helps with HDLC chips 174 that operate specially on least significant bits in HDLC addresses. 175 Headers with the least significant bit set to zero are reserved for 176 future extensions. 178 The R bit is the inverted equivalent of the B bit in the other 179 multilink fragment formats, i.e. R = 1 means that this fragment 180 resumes a packet previous fragments of which have been sent already. 182 The following trick avoids the case of a header byte of 0xFF (which 183 would mean R=1, sequence=7, and class=7): If the class field is set 184 to 7, the R bit MUST never be set to one. I.e., class 7 frames by 185 design cannot be suspended/resumed. (This is also the reason the 186 sense of the B bit is inverted to an R bit in the compact fragment 187 format -- class 7 would be useless otherwise, as a new packet could 188 never be begun.) 190 As the sequence number is not particularly useful with the class 191 field set to 7, it is used to distinguish eight more classes -- for 192 some minor additional complexity, the applicability of prefix elision 193 is significantly increased by providing more classes with possibly 194 different elided prefixes. 196 For purposes of prefix elision, the actual class number of a fragment 197 is computed as follows: 199 - If the class field is 0 to 6, the class number is 0 to 6, 201 - if the class field is 7 and the sequence field is 0 to 7, the 202 class number is 7 to 14. 204 As a result of this scheme, the classes 0 to 6 can be used for 205 suspendable packets, and classes 7 to 14 (where the class field is 7 206 and the R bit must always be off) can be used for non-suspendable 207 high-priority classes, e.g., eight highly compressed voice streams. 209 5. The Extended Compact Fragment Format 211 For operation over multiple links, a three-bit sequence number will 212 rarely be sufficient. Therefore, we define an optional extended 213 compact fragment format. The option, when negotiated, allows both 214 the basic compact fragment format and the extended compact fragment 215 format to be used; each fragment indicates which format it is in. 217 Figure 1: Extended Compact Fragment Format 219 0 1 2 3 4 5 6 7 220 +---+---+---+---+---+---+---+---+ 221 | R | seq LSB | class | 0 | 222 +---+---+---+---+---+---+---+---+ 223 | sequence -- MSB | 1 | 224 +---+---+---+---+---+---+---+---+ 225 | data | 226 : : 227 +---+---+---+---+---+---+---+---+ 229 In the extended compact fragment format, the sequence number is 230 composed of three least significant bits from the first octet of the 231 fragment header and seven most significant bits from the second 232 octet. 234 For prefix elision purposes, fragments with a class field of 7 can 235 use the basic format to indicate classes 7 to 14 and the extended 236 format to indicate classes 7 to 1030. Different classes may use 237 different formats concurrently without problems. (This allows some 238 classes to be spread over a multi-link and other classes to be 239 confined to a single link with greater efficiency.) For class fields 240 0 to 6, i.e. suspendable classes, one of the two compact fragment 241 formats SHOULD be used consistently within each class. 243 If the use of the extended compact fragment format has been 244 negotiated, receivers MAY keep 10-bit sequence numbers for all 245 classes to facilitate senders switching formats in a class. When a 246 sender starts sending basic format fragments in a class that was 247 using extended format fragments, the 3-bit sequence number can be 248 taken as a modulo-8 version of the 10-bit sequence number, and no 249 discontinuity need result. In the inverse case, if a 10-bit sequence 250 number has been kept throughout and no major slips of the sequence 251 number have occurred, no discontinuity will result, although this 252 cannot be guaranteed in the presence of errors. (Discontinuity, in 253 this context, means that a receiver has to resynchronize sequence 254 numbers by discarding fragments until a fragment with R=0 has been 255 seen.) 257 6. Real-Time Frame Format 259 This section defines how fragments with compact fragment headers are 260 mapped into real-time frames. This format has been designed to 261 retain the overall HDLC based format of frames, so that existing 262 synchronous HDLC chips and async to sync converters can be used on 263 the link. Note that if the design could be optimized for async only 264 operation, more design alternatives would be available [4]; with the 265 advent of V.80 style modems, asynchronous communications is likely to 266 decrease in importance, though. 268 The compact fragment format provides a compact rendition of the PPP 269 multilink header with classes and a reduced sequence number space. 270 However, it does not encode the E-bit of the PPP multilink header, 271 which indicates whether the fragment at hand is the last fragment of 272 a packet. 274 For a solution where packets can be suspended at any point in time, 275 the E-bit needs to be encoded near the end of each fragment. The 276 real-time frame format, to ensure maximum compatibility with type 2 277 receivers, encodes the E-bit in the following way: Any normal frame 278 ending also ends the current fragment with E implicitly set to one. 279 This ensures that packets that are ready for delivery to the upper 280 layers immediately trigger a receive interrupt even at type-2 281 receivers. 283 Fragments of packets that are to be suspended are terminated within 284 the HDLC frame by a special ``fragment suspend escape'' byte (FSE). 285 The overall structure of the HDLC frame does not change; the 286 detection and handling of FSE bytes is done at a layer above HDLC 287 framing. 289 The suspend/resume format with FSE detection is an alternative to 290 address/control field compression (ACFC, LCP option 8). It does not 291 apply to frames that start with 0xFF, the standard PPP-in-HDLC 292 address field; these frames are handled as defined in [6] and [7]. 293 (This provision ensures that attempts to renegotiate LCP do not cause 294 ambiguities.) 296 For frames that do not start with 0xFF, suspend/resume processing 297 performs a scan of every HDLC frame received. The FCS of the HDLC 298 frame is checked and stripped. Compact fragment format headers (both 299 basic and extended) are handled without further FSE processing*. 300 Within the remaining bytes of the HDLC frame, an FSE byte is used to 301 indicate the end of the current fragment, with an E bit implicitly 302 cleared. All fragments up to the last FSE are considered suspended; 303 the final fragment is terminated, or, if it is empty, ignored (i.e., 304 the data part of an HDLC frame can end in an FSE to indicate that the 305 _________________________ 306 * As the FSE byte was chosen such that it never occurs in com- 307 pact fragment format headers, this does not require any specific 308 code. 310 last fragment has E = 0). 312 Each fragment begins with a normal header, so the structure of a 313 frame could be: 315 Figure 2: Example frame with FSE delimiter 317 0 1 2 3 4 5 6 7 318 +---+---+---+---+---+---+---+---+ 319 | R | sequence | class | 1 | 320 +---+---+---+---+---+---+---+---+ 321 | data | 322 : : 323 +---+---+---+---+---+---+---+---+ 324 + FSE + previous fragment implicitly E = 0 325 +---+---+---+---+---+---+---+---+ 326 | R | sequence | class | 1 | 327 +---+---+---+---+---+---+---+---+ 328 | data | 329 : : 330 +---+---+---+---+---+---+---+---+ 331 | Frame | previous fragment implicitly E = 1 332 | CRC | 333 +---+---+---+---+---+---+---+---+ 335 The value chosen for FSE is 0xDE (this is a relatively unlikely byte 336 to occur in today's data streams, it does not trigger octet stuffing 337 and triggers bit stuffing only for 1/8 of the possible preceding 338 bytes). 340 The remaining problem is that of data transparency. In the scheme 341 described so far, an FSE is always followed by a compact fragment 342 header. In these headers, the combination of a class field set to 7 343 with R=1 is reserved. Data transparency is achieved by making the 344 occurrence of an FSE byte followed by one of 0x8F, 0x9F to 0xFF 345 special. 347 Figure 3: Data transparency with FSE bytes present 349 0 1 2 3 4 5 6 7 350 +---+---+---+---+---+---+---+---+ 351 | R | sequence | class | 1 | 352 +---+---+---+---+---+---+---+---+ 353 | data | 354 : : 355 +---+---+---+---+---+---+---+---+ 356 + FSE + fragment NOT terminated 357 +---+---+---+---+---+---+---+---+ 358 | R | S | T | U | 1 | 1 | 1 | 1 | R always is 1 359 +---+---+---+---+---+---+---+---+ 360 | data | fragment continues 361 : : 363 In a combination of FSE/0xnF (where n is the first four-bit field in 364 the second byte, RSTU in Figure 3), the n field gives a sequence of 365 four bits indicating where in the received data stream FSE bytes, 366 which cannot simply be transmitted in the data stream, are to be 367 added by the receiver: 369 0x8F: insert one FSE, back to data 370 0x9F: insert one FSE, copy two data bytes, insert one FSE, back to data 371 0xAF: insert one FSE, copy one data byte, insert one FSE, back to data 372 0xBF: insert one FSE, copy one data byte, insert two FSE bytes, back to data 373 0xCF: insert two FSE bytes, back to data 374 0xDF: insert two FSE bytes, copy one data byte, insert one FSE, back to data 375 0xEF: insert three FSE bytes, back to data 376 0xFF: insert four FSE bytes, back to data 378 The data bytes following the FSE/0xnF combinations and corresponding 379 to the zero bits in the N field may not be FSE bytes. 381 This scheme limits the worst case expansion factor by FSE processing 382 to about 25 %. Also, it is designed such that a single data stream 383 can either trigger worst-case expansion by octet stuffing (or by bit 384 stuffing) or worst-case FSE processing, but never both. Figure 4 385 illustrates the scheme in a few examples; FSE/0xnF pairs are written 386 in lower case. 388 Figure 4: Data transparency examples 390 Data stream FSE-stuffed stream 392 DD DE DF E0 DD de 8f DF E0 393 01 DE 02 DE 03 01 de af 02 03 394 DE DA DE DE DB de bf DA DB 396 In summary, the real-time frame format is a HDLC-like frame delimited 397 by flags and containing a final FCS as defined in [7], but without 398 address and control fields, containing as data a sequence of FSE- 399 stuffed fragments in compact fragment format, delimited by FSE bytes. 400 As a special case, the final FSE may occur as the last byte of the 401 data content (i.e. immediately before the FCS bytes) of the HDLC-like 402 frame, to indicate that the last fragment in the frame is suspended 403 and no final fragment is in the frame (e.g., because the desirable 404 maximum size of the frame has been reached). 406 7. Implementation notes 408 7.1. MRU Issues 410 The LCP parameter MRU defines the maximum size of the packets sent on 411 the link. Async-to-sync converters that are monitoring the LCP 412 negotiations on the link may interpret the MRU value as the maximum 413 HDLC frame size to be expected. 415 Implementations of this specification should preferably negotiate a 416 sufficiently large MRU to cover the worst-case 25 % increase in frame 417 size plus the increase caused by suspended fragments. If that is not 418 possible, the HDLC frame size should be limited by monitoring the 419 HDLC frame sizes and possibly suspending the current fragment by 420 sending an FSE with an empty final fragment (FSE immediately followed 421 by the end of the information field, i.e. by CRC bytes and a flag) to 422 be able to continue in a new HDLC frame. This strategy also helps 423 minimizing the impact of lengthening the HDLC frame on the safety of 424 the 16-bit FCS at the end of the HDLC frame. 426 7.2. Implementing octet-stuffing and FSE processing in one automaton 428 The simplest way to add real-time framing to an implementation may be 429 to perform HDLC processing as usual and then, on the result, to 430 perform FSE processing. A more advanced implementation may want to 431 combine the two levels of escape character processing. Note, 432 however, that FSE processing needs to wait until two bytes from the 433 HDLC frame are available and followed by a third to ensure that the 434 bytes are not the final HDLC FCS bytes, which are not subject to FSE 435 processing. I.e., on the reception of normal data byte, look for an 436 FSE in the second-to-previous byte, and, on the reception of a frame- 437 end, look for an FSE as the last data byte. 439 8. Negotiable options 441 The following options are already defined by MP [2]: 443 o Multilink Maximum Received Reconstructed Unit 445 o Multilink Short Sequence Number Header Format 447 o Endpoint Discriminator 449 The following options is already defined by MCML [5]: 451 o Multilink Header Format 453 o Prefix Elision 455 This document defines two new code points for the Multilink Header 456 Format option. 458 8.1. Multilink header format option 460 The multilink header format option is defined in [5]. A summary of 461 the Multilink Header Format Option format is shown below. The fields 462 are transmitted from left to right. 464 Figure 5: Multilink header format option 466 0 1 2 467 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type = TBD | Length = 3 | Code | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 This option advises the peer that the implementation wishes to 473 receive fragments with a format given by the code number. When this 474 option is received, an implementation MUST either transmit all 475 subsequent multilink packets on all links of the bundle with the 476 multilink header format given or configure-NAK or configure-Reject 477 the option. This specification defines one additional value for 478 Code, in addition to those defined in [5]: 480 - This option present with code = 11: basic and extended compact 481 real-time fragment format with classes, in FSE-encoded HDLC 482 frame 484 - This option present with code = 15: basic compact real-time 485 fragment format with classes, in FSE-encoded HDLC frame 487 An implementation MUST NOT request a combination of both the Short 488 Sequence Number Header Format Option and this option, or of both LCP 489 Address-and-Control-Field-Compression (ACFC) and the code values 11 490 or 15 for this option. 492 9. Acknowledgements 494 The participants in a lunch BOF at the Montreal IETF 1996 gave useful 495 input on the design tradeoffs in various environments. Richard 496 Andrades, Fred Burg, and Murali Aravamudan insisted that there should 497 be a suspend/resume solution in addition to the pre-fragmenting one 498 defined in [5]. The members of the ISSLL subgroup on low bitrate 499 links (ISSLOW) have helped in coming up with a set of requirements 500 that shaped this solution. 502 10. References 504 [1] C. Bormann, ``Providing integrated services over low-bitrate 505 links'', Work in Progress (draft-ietf-issll-isslow-02.txt), May 506 1997. 508 [2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 509 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 510 RFC1717). 512 [3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. 514 [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', Work 515 in Progress (draft-andrades-framing-ext-00.txt), September 1996. 517 [5] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'', 518 Work in Progress (draft-ietf-issll-isslow-mcml-02.txt), March 519 1997. 521 [6] W. Simpson, Editor. ``The Point-to-Point Protocol (PPP)'', RFC 522 1661, July 1994 (Obsoletes RFC1548, also STD0051). 524 [7] W. Simpson, Editor. ``PPP in HDLC-like Framing'', RFC 1662, July 525 1994 (Obsoletes RFC1549, also STD0051) 527 11. Addresses 529 11.1. Working Group 531 The ISSLL working group can be contacted via the co-chairs, Eric 532 Crawley and John Wroclawski , 533 or via its WG mailing list . 535 11.2. Author's address 537 Carsten Bormann 538 Universitaet Bremen FB3 TZI 539 Postfach 330440 540 D-28334 Bremen, GERMANY 541 cabo@tzi.uni-bremen.de 542 phone +49.421.218-7024 543 fax +49.421.218-7000