idnits 2.17.1 draft-ietf-pppext-dce-compress-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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 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 abstract seems to contain references ([2], [3], [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 88: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 91: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 94: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 100: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 102: '...h does not include this option MUST be...' (10 more instances...) 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 (November 1994) is 10726 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kevin Schneider 2 Internet Draft Stuart Venters 3 ADTRAN, Inc. 4 expires May 1995 November 1994 6 PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) 7 draft-ietf-pppext-dce-compress-00.txt 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the ietf-ppp@merit.edu mailing list. 15 Distribution of this memo is unlimited. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its Areas, and its Working Groups. Note that 19 other groups may also distribute working documents as Internet 20 Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 Please check the 1id-abstracts.txt listing contained in the 29 internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net, 30 venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current 31 status of any Internet Draft. 33 Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method for 36 transporting multi-protocol datagrams over point-to-point links. PPP 37 defines an extensible Link Control Protocol, and proposes a family of 38 Network Control Protocols for establishing and configuring different 39 network-layer protocols. 41 The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a 42 standard method for encapsulating and transporting serial data over a 43 PPP link. The PPP Compression Control Protocol [3] provides a 44 standard method for selecting and using a compression protocol to 45 provide for data compression on a PPP link. 47 This document defines a specific set of parameters for these 48 protocols and an LCP extension to define a standard way of using PPP 49 for data compression of serial data in Data Circuit-Terminating 50 Equipment (DCE). 52 1. Introduction 54 This document is a product of the TR30.1 ad hoc committee on 55 compression of synchronous data. It represents a component of a 56 proposal to use PPP to provide compression of synchronous serial data 57 in DSU/CSUs. 59 PPP [1] has three main components: 61 1. A method for encapsulating multi-protocol datagrams. 63 2. A Link Control Protocol (LCP) for establishing, configuring, 64 and testing the data-link connection. 66 3. A family of Network Control Protocols for establishing and 67 configuring different network-layer protocols. 69 In addition to providing support for multi-protocol datagrams, the 70 Point-to-Point Protocol (PPP) [1] has defined an effective and robust 71 negotiating mechanism that can be used on point to point links. When 72 used in conjunction with the PPP Compression Control Protocol [3] and 73 one of the PPP Compression Protocols [4], PPP provides an 74 interoperable method of employing data compression on a point-to- 75 point link. 77 The PPP Serial Data Transport Protocol (PPP-SDTP) and the PPP Serial 78 Data Control Protocol (PPP-SDCP) [2] have been developed to allow 79 serial data to be carried within a PPP packet. PPP-SDTP uses a 80 terminal adaption header based on that of ITU-T Recommendation V.120 81 [5]. 83 1.1. Specification of Requirements 85 In this document, several words are used to signify the requirements 86 of the specification. These words are often capitalized. 88 MUST This word, or the adjective "required", means that the 89 definition is an absolute requirement of the specification. 91 MUST NOT This phrase means that the definition is an absolute 92 prohibition of the specification. 94 SHOULD This word, or the adjective "recommended", means that there 95 may exist valid reasons in particular circumstances to 96 ignore this item, but the full implications must be 97 understood and carefully weighed before choosing a 98 different course. 100 MAY This word, or the adjective "optional", means that this 101 item is one of an allowed set of alternatives. An 102 implementation which does not include this option MUST be 103 prepared to interoperate with another implementation which 104 does include the option. 106 1.2. Terminology 108 This document frequently uses the following terms: 110 datagram The unit of transmission in the network layer (such as IP). 111 A datagram may be encapsulated in one or more packets 112 passed to the data link layer. 114 frame The unit of transmission at the data link layer. A frame 115 may include a header and/or a trailer, along with some 116 number of units of data. 118 packet The basic unit of encapsulation, which is passed across the 119 interface between the network layer and the data link 120 layer. A packet is usually mapped to a frame; the 121 exceptions are when data link layer fragmentation is being 122 performed, or when multiple packets are incorporated into a 123 single frame. 125 peer The other end of the point-to-point link. 127 silently discard 128 This means the implementation discards the packet without 129 further processing. The implementation SHOULD provide the 130 capability of logging the error, including the contents of 131 the silently discarded packet, and SHOULD record the event 132 in a statistics counter. 134 2. Modes of Operation 136 This document provides for three modes of operation for DCE devices: 137 Mode-0 represents transparent operation; Mode-1 a simplified, 138 predefined compression format; and Mode-2, a full PPP implementation 139 providing compression of serial data. 141 Mode-0 represents the operating mode of currently deployed DCEs that 142 operate in transparent mode, without any DCE-to-DCE protocols. 143 Mode-1 devices implement data compression upon detecting an initial 144 handshake, which is implemented via an newly defined LCP 145 Configuration Option called the DCE-Identifier. The DCE-Identifier 146 is used both to distinguish DCE devices from PPP bridges and routers, 147 and to all Mode-1 and Mode-2 DCE devices to interoperate, via its 148 Mode parameter. In Mode-1, the parameters of operation are not 149 negotiable. Mode-2 devices implement the full LCP state machine and 150 are therefore capable of negotiating alternatives to the default set 151 of paramaters and options. Mode-2 devices must also support Mode-1 152 operation, and fall-back to such operation when connected to a Mode-1 153 device. The mechanism of the Mode-1/Mode-2 handshake is given in 154 Section 7. 156 3. PPP Link Control Protocol Extension 158 The use of PPP in Compression DCE requires the use of an additional 159 LCP Configuration Option: 161 21 DCE-Identifier 163 DCE-Identifier 165 The presence of this option indicates that the system sending it 166 is Data Circuit-Terminating Equipment (DCE) that desires to 167 establish a serial data compression link. 169 0 1 2 170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Length | Mode | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Type 177 21 179 Length 181 3 183 Mode 185 1 Mode-1 (No Additional Negotiation) 186 2 Mode-2 (Full PPP Negotiation and State Machine) 188 4. Required PPP Elements 190 Unlike PPP's native bridge/router environment, the minimum 191 requirement for use of PPP in DCE equipment is not simply 192 interoperability, but rather interoperability with effective data 193 compression. With this in mind, it is desirable to specify a minimum 194 PPP feature set, that is somewhat different than that of a normal PPP 195 bridge/router requirement. 197 This different feature set includes: support for compression, 198 support of a single default compression algorithm, support of 199 Protocol-Field compression, support of Address-and-Control-Field- 200 Compression, support of PPP-SDTP, etc. 202 The minimum feature set includes the following protocols: 204 PPP Link Control Protocol (Mode-1 must include a subset) [1] 205 PPP in HDLC-like Framing [6] 206 PPP Compression Control Protocol (Mode-2 only) [3] 207 PPP LZS-DCP Compression Protocol [4] 208 PPP Serial Data Transport Protocol [2] 209 PPP Serial Data Control Protocol (Mode-2 only) [2] 211 The Stacker-LZS algorithm from Stac Electronics was chosen as the 212 default compression algorithm for DCE devices. This decision was 213 made by the TR30.1 ad hoc based on licensing issues (agreeing to 214 non-discriminatory and reasonable terms), compression ratios, its 215 efficient use of processor and memory resources, and speed 216 scalability. A compression protocol incorporating in-band 217 synchronization signaling was defined for the Stacker algorithm and 218 selected for the default compression protocol. This protocol is 219 known as the PPP LZS-DCP Compression Protocol [4]. Although the PPP 220 LZS-DCP Compression Protocol specifies a number of formats and 221 history management options, only the default format with a single 222 history must be implemented. 224 4.1. Required Configuration Options and Parameters 226 To ensure that implementations are able to interoperate with 227 effective data compression, a required set of Configuration Options 228 are specified. These Options are assumed in Mode-1, and are 229 negotiated in Mode-2, using the standard PPP negotiation state 230 machine. (Mode-1 uses a fixed packet format with a predetermined set 231 of values for LCP, LZS-DCP, and SDTP Configuration 232 Options/parameters. The required values listed in this section are 233 the predefined values.) 235 The following LCP Configuration Options [7] MUST be supported: 237 Maximum-Receive-Unit 1550 238 Address/Control-Field-Compression Yes 239 Protocol-Field-Compression Yes 241 The following CCP Configuration Option MUST be supported: 243 Compression-Type 23 (LZS-DCP) 245 The following default LZS-DCP Configuration Options MUST be 246 supported: 248 Check-Mode 3 (sequence + LCB) 249 History-Count 1 (single history) 250 Process-Mode 0 (None) 252 The default SDTP/SDCP Configuration Options MUST be supported. They 253 are: 255 Packet-Format: Header-Last 256 Header-Type: H-Only 257 Multiple-Packets: Off 258 Multi-Port: Off 259 Transport-Mode: HDLC-Synchronous 260 Maximum-Frame-Size: 10,000 bytes 261 Allow-Odd-Frames: Off 262 FCS-Type: Transparent-Transport 263 Flow-Expiration-Time: 100 265 5. Mode-1 Requirements 267 DSUs that use only Mode-1 (non-negotiate mode) use only a 268 predetermined set of PPP packets. In addition to a fixed data packet 269 format, two fixed formats are used to differentiate between Mode-1 270 devices and Mode-0 (transparent) devices. Mode-1 devices are 271 designed to operate using compression if a peer has the same 272 capability, or revert to transparent operation (Mode-0) if the peer 273 does not support standard compression. 275 Mode-1 devices use LZS-DCP Compression Packets as specified in [4]. 276 These packets include the capabilities of DCP: Reset-Request and 277 Acknowledge, Compressed/Transparent, etc. Since the packets include 278 signalling, these packets can be sent with an empty data field to 279 signal a reset request if no data packets are ready for piggy-backed 280 signalling. 282 Exactly one LZS-DCP packet is encapsulated in the PPP Information 283 field, where the PPP Protocol field indicates type 00FD (Compression 284 Protocol). Exactly one SDTP packet is transported by each LZS-DCP 285 data packet. 287 Operation in Mode-1 implies a set of predetermined values for LCP, 288 LZS-DCP, and SDTP configuration options and parameters, using the 289 values listed in the preceding section. 291 The following PPP packets are permitted and recognized: 293 LCP Configure-Request with DCE Mode-1 Configuration Option 294 LCP Configure-Ack with DCE Mode-1 Configuration Option 295 LZS-DCP Packet with the data field containing an SDTP packet 296 LZS-DCP Packet with an empty data field 298 Protocol-Field-Compression and Address-and-Control-Field- Compression 299 is used on all packets except the handshake packets (LCP packets). 301 Any Mode-1 or Mode-2 DCE that receives a Mode-1 request MUST 302 Acknowledge the request. 304 5.1. Detailed Mode-1 Example 306 Detailed Example when using Mode-1 on a point-to-point leased or 307 circuit switched link (using PPP in HDLC-like Framing [6]) (data 308 shown is after flags and inserted 0s are removed; lower case letters 309 and numbers represent actual values, uppercase represent data fields 310 whose values may vary from packet to packet; parentheses surrounding 311 a field indicate that the field may not be present in all packets of 312 that type): 314 LCP Configure-Request: 315 Config. Opt. 316 Addr. Ctl. PID Code ID Length Type Lngth Mode 317 +----+----+-------+----+----+-------+----+----+----+-----+ 318 | ff | 03 | c0 21 | 01 | 00 | 00 07 | 21 | 03 | 01 | FCS | 319 +----+----+-------+----+----+-------+----+----+----+-----+ 321 LCP Configure-Ack: 323 Config. Opt. 324 Addr. Ctl. PID Code ID Length Type Lngth Mode 325 +----+----+-------+----+----+-------+----+----+----+-----+ 326 | ff | 03 | c0 21 | 02 | 00 | 00 07 | 21 | 03 | 01 | FCS | 327 +----+----+-------+----+----+-------+----+----+----+-----+ 329 LZS-DCP Packet: 331 PID DCP 332 +----+----+------+------ -+-------+-----+ 333 | fd | HD | (SQ) | (DATA) | (LCB) | FCS | 334 +----+----+------+--------+-------+-----+ 336 The DATA field contains a compressed or uncompressed SDTP- PDU. 337 The LCB field is only present on a packet containing compressed 338 data. The Sequence Number and Data fields are only present on 339 packets that contain data. 341 +----+------+----+ 342 SDTP-PDU: | 49 | DATA | HD | 343 +----+------+----+ 345 6. Initial Handshake Operation 347 When a unit is powered up, or when the lower layer signals that the 348 peer has gone out of service and returned, the handshake procedure is 349 initiated. The handshake procedure for Mode-1 and Mode-2 devices is 350 described below. 352 Mode-1: 354 When starting Mode-1, each DCE sends out an LCP Configure-Request 355 packet containing only the DCE-Identifier LCP Configuration Option 356 described in Section 3, with the with the Mode Field set to a 357 value of 1. When a DCE device receives such a packet, it must 358 answer with an LCP Configure-Ack packet. In each of these 359 packets, the identifier field is set to 0. If the originator of 360 the Configure-Request packet does not receive a Configure-Ack 361 response within a user configurable time T1, the unit MUST revert 362 to transparent (Mode-0) operation. 364 Mode-2: 366 A Mode-2 device will first try to operate in Mode-2 by starting 367 PPP normally, following the state machine described in [1]. The 368 LCP Configure-Request MUST include the DCE-Identifier 369 Configuration Option with the Mode Field set to 2. If the unit 370 receives a Configure-Reject Packet Containing the DCE-Identifier, 371 the unit MUST revert immediately to transparent (Mode-0) 372 operation. If the LCP state machine times out because a response 373 was not received in user configurable time T2, or if a Mode-1 374 Configuration-Request packet is received, the unit attempts to 375 operate in Mode-1 by following the procedure listed above, 376 ultimately reverting to Mode-0 operation if the Mode-1 procedure 377 times out. 379 In either case, the unit is not prohibited from sending multiple 380 Configuration-Request packets before the applicable timer (T1, T2) 381 expires. A unit may also initiate the handshake procedure at any 382 time. 384 7. Security 386 Security issues are not addressed in this memo. 388 8. References 390 [1] Simpson, W.A., ed., "The Point-to-Point Protocol (PPP)", RFC 391 1661 (STD 51), July 1994. 393 [2] Schneider, K. and Venters, S., "PPP Serial Data Transport 394 Protocol (PPP-SDTP)", work in progress. 396 [3] Rand, D., "The PPP Compression Control Protocol (CCP)", work 397 in progress. 399 [4] Lutz, R., "PPP LZS-DCP Compression Protocol", work in 400 progress. 402 [5] CCITT Recommendation V.120, "Support by an ISDN of Data 403 Terminal Equipment with V-Series Type Interfaces with 404 Provision for Statistical Multiplexing (revised 1992)", ITU-T, 405 1993. 407 [6] Simpson, W.A., "PPP in HDLC-like Framing", RFC 1662 (STD 51), 408 January 1994. 410 [7] Simpson, W.A., "PPP LCP Extensions", RFC 1570, January 1994. 412 Chair's Address 414 The working group can be contacted via the current chair: 416 Fred Baker 417 Senior Software Engineer 418 Cisco Systems 419 519 Lado Drive 420 Santa Barbara, California 93111 421 (805) 681-0115 423 EMail: fred@cisco.com 425 Author's Address 427 Questions about this memo can also be directed to: 429 Kevin Schneider 430 Stuart Venters 432 Adtran, Inc. 433 901 Explorer Blvd. 434 Huntsville, AL 35806-2807 436 (205) 971-8000 438 Email: kevin@adtran.com 439 sventers@adtran.com 440 Table of Contents 442 1. Introduction .......................................... 1 443 1.1 Specification of Requirements ................... 1 444 1.2 Terminology ..................................... 2 446 2. Modes of Operation .................................... 3 448 3. PPP Link Control Protocol Extension ................... 3 450 4. Required PPP Elements ................................. 4 451 4.1 Required Configuration Options and Parameters 453 5. Mode-1 Requirements ................................... 5 454 5.1 Detailed Mode-1 Example ......................... 6 456 6. Initial Handshake Operation ........................... 7 458 7. Security .............................................. 8 460 8. References ............................................ 8 462 CHAIR'S ADDRESS .............................................. 9 464 AUTHOR'S ADDRESS ............................................. 9