1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563
|
Network Working Group K. Schneider
Request for Comments: 1976 S. Venters
Category: Informational ADTRAN, Inc.
August 1996
PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)
Status of This Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol, and proposes a family of
Network Control Protocols for establishing and configuring different
network-layer protocols.
The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a
standard method for encapsulating and transporting serial data over a
PPP link. The PPP Compression Control Protocol [3] provides a
standard method for selecting and using a compression protocol to
provide for data compression on a PPP link.
This document defines a specific set of parameters for these
protocols and an LCP extension to define a standard way of using PPP
for data compression of serial data in Data Circuit-Terminating
Equipment (DCE).
Table of Contents
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 3
2. Modes of Operation .................................... 3
3. PPP Link Control Protocol Extension ................... 4
4. Required PPP Elements ................................. 4
4.1 Required Configuration Options and Parameters ... 5
5. Mode-1 Requirements ................................... 6
5.1 Detailed Mode-1 Example ......................... 7
6. Initial Handshake Operation ........................... 8
7. Security .............................................. 9
8. References ............................................ 9
CHAIR'S ADDRESS .............................................. 9
Schneider & Venters Informational [Page 1]
RFC 1976 PPP DCE August 1996
AUTHORS' ADDRESSES ........................................... 10
1. Introduction
This document is a product of the TR30.1 ad hoc committee on
compression of synchronous data. It represents a component of a
proposal to use PPP to provide compression of synchronous serial data
in DSU/CSUs.
PPP [1] has three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
3. A family of Network Control Protocols for establishing and
configuring different network-layer protocols.
In addition to providing support for multi-protocol datagrams, the
Point-to-Point Protocol (PPP) [1] has defined an effective and robust
negotiating mechanism that can be used on point to point links. When
used in conjunction with the PPP Compression Control Protocol [3] and
one of the PPP Compression Protocols [4], PPP provides an
interoperable method of employing data compression on a point-to-
point link.
The PPP Serial Data Transport Protocol (PPP-SDTP) and the PPP Serial
Data Control Protocol (PPP-SDCP) [2] have been developed to allow
serial data to be carried within a PPP packet. PPP-SDTP uses a
terminal adaption header based on that of ITU-T Recommendation V.120
[5].
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications must be
understood and carefully weighed before choosing a
Schneider & Venters Informational [Page 2]
RFC 1976 PPP DCE August 1996
different course.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST be
prepared to interoperate with another implementation which
does include the option.
1.2. Terminology
This document frequently uses the following terms:
datagram The unit of transmission in the network layer (such as IP).
A datagram may be encapsulated in one or more packets
passed to the data link layer.
frame The unit of transmission at the data link layer. A frame
may include a header and/or a trailer, along with some
number of units of data.
packet The basic unit of encapsulation, which is passed across the
interface between the network layer and the data link
layer. A packet is usually mapped to a frame; the
exceptions are when data link layer fragmentation is being
performed, or when multiple packets are incorporated into a
single frame.
peer The other end of the point-to-point link.
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.
2. Modes of Operation
This document provides for three modes of operation for DCE devices:
Mode-0 represents transparent operation; Mode-1 a simplified,
predefined compression format; and Mode-2, a full PPP implementation
providing compression of serial data.
Mode-0 represents the operating mode of currently deployed DCEs that
operate in transparent mode, without any DCE-to-DCE protocols.
Mode-1 devices implement data compression upon detecting an initial
handshake, which is implemented via an newly defined LCP
Configuration Option called the DCE-Identifier. The DCE-Identifier
Schneider & Venters Informational [Page 3]
RFC 1976 PPP DCE August 1996
is used both to distinguish DCE devices from PPP bridges and routers,
and to all Mode-1 and Mode-2 DCE devices to interoperate, via its
Mode parameter. In Mode-1, the parameters of operation are not
negotiable. Mode-2 devices implement the full LCP state machine and
are therefore capable of negotiating alternatives to the default set
of paramaters and options. Mode-2 devices must also support Mode-1
operation, and fall-back to such operation when connected to a Mode-1
device. The mechanism of the Mode-1/Mode-2 handshake is given in
Section 7.
3. PPP Link Control Protocol Extension
The use of PPP in Compression DCE requires the use of an additional
LCP Configuration Option:
25 DCE-Identifier
DCE-Identifier
The presence of this option indicates that the system sending it
is Data Circuit-Terminating Equipment (DCE) that desires to
establish a serial data compression link.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
25
Length
3
Mode
1 Mode-1 (No Additional Negotiation)
2 Mode-2 (Full PPP Negotiation and State Machine)
4. Required PPP Elements
Unlike PPP's native bridge/router environment, the minimum
requirement for use of PPP in DCE equipment is not simply
interoperability, but rather interoperability with effective data
Schneider & Venters Informational [Page 4]
RFC 1976 PPP DCE August 1996
compression. With this in mind, it is desirable to specify a minimum
PPP feature set, that is somewhat different than that of a normal PPP
bridge/router requirement.
This different feature set includes: support for compression, support
of a single default compression algorithm, support of Protocol-Field
compression, support of Address-and-Control-Field-Compression,
support of PPP-SDTP, etc.
The minimum feature set includes the following protocols:
PPP Link Control Protocol (Mode-1 must include a subset) [1]
PPP in HDLC-like Framing [6]
PPP Compression Control Protocol (Mode-2 only) [3]
PPP LZS-DCP Compression Protocol [4]
PPP Serial Data Transport Protocol [2]
PPP Serial Data Control Protocol (Mode-2 only) [2]
The Stacker-LZS algorithm from Stac Electronics was chosen as the
default compression algorithm for DCE devices. This decision was
made by the TR30.1 ad hoc based on licensing issues (agreeing to
non-discriminatory and reasonable terms), compression ratios, its
efficient use of processor and memory resources, and speed
scalability. A compression protocol incorporating in-band
synchronization signaling was defined for the Stacker algorithm and
selected for the default compression protocol. This protocol is
known as the PPP LZS-DCP Compression Protocol [4]. Although the PPP
LZS-DCP Compression Protocol specifies a number of formats and
history management options, only the default format with a single
history must be implemented.
4.1. Required Configuration Options and Parameters
To ensure that implementations are able to interoperate with
effective data compression, a required set of Configuration Options
are specified. These Options are assumed in Mode-1, and are
negotiated in Mode-2, using the standard PPP negotiation state
machine. (Mode-1 uses a fixed packet format with a predetermined set
of values for LCP, LZS-DCP, and SDTP Configuration
Options/parameters. The required values listed in this section are
the predefined values.)
The following LCP Configuration Options [7] MUST be supported:
Maximum-Receive-Unit 1550
Address/Control-Field-Compression Yes
Protocol-Field-Compression Yes
Schneider & Venters Informational [Page 5]
RFC 1976 PPP DCE August 1996
The following CCP Configuration Option MUST be supported:
Compression-Type 23 (LZS-DCP)
The following default LZS-DCP Configuration Options MUST be
supported:
Check-Mode 3 (sequence + LCB)
History-Count 1 (single history)
Process-Mode 0 (None)
The default SDTP/SDCP Configuration Options MUST be supported. They
are:
Packet-Format: Header-Last
Header-Type: H-Only
Multiple-Packets: Off
Multi-Port: Off
Transport-Mode: HDLC-Synchronous
Maximum-Frame-Size: 10,000 bytes
Allow-Odd-Frames: Off
FCS-Type: Transparent-Transport
Flow-Expiration-Time: 100
5. Mode-1 Requirements
DSUs that use only Mode-1 (non-negotiate mode) use only a
predetermined set of PPP packets. In addition to a fixed data packet
format, two fixed formats are used to differentiate between Mode-1
devices and Mode-0 (transparent) devices. Mode-1 devices are
designed to operate using compression if a peer has the same
capability, or revert to transparent operation (Mode-0) if the peer
does not support standard compression.
Mode-1 devices use LZS-DCP Compression Packets as specified in [4].
These packets include the capabilities of DCP: Reset-Request and
Acknowledge, Compressed/Transparent, etc. Since the packets include
signalling, these packets can be sent with an empty data field to
signal a reset request if no data packets are ready for piggy-backed
signalling.
Exactly one LZS-DCP packet is encapsulated in the PPP Information
field, where the PPP Protocol field indicates type 00FD (Compression
Protocol). Exactly one SDTP packet is transported by each LZS-DCP
data packet.
Schneider & Venters Informational [Page 6]
RFC 1976 PPP DCE August 1996
Operation in Mode-1 implies a set of predetermined values for LCP,
LZS-DCP, and SDTP configuration options and parameters, using the
values listed in the preceding section.
The following PPP packets are permitted and recognized:
LCP Configure-Request with DCE Mode-1 Configuration Option
LCP Configure-Ack with DCE Mode-1 Configuration Option
LZS-DCP Packet with the data field containing an SDTP packet
LZS-DCP Packet with an empty data field
Protocol-Field-Compression and Address-and-Control-Field-Compression
is used on all packets except the handshake packets (LCP packets).
Any Mode-1 or Mode-2 DCE that receives a Mode-1 request MUST
Acknowledge the request.
5.1. Detailed Mode-1 Example
Detailed Example when using Mode-1 on a point-to-point leased or
circuit switched link (using PPP in HDLC-like Framing [6]) (data
shown is after flags and inserted 0s are removed; lower case letters
and numbers represent actual values, uppercase represent data fields
whose values may vary from packet to packet; parentheses surrounding
a field indicate that the field may not be present in all packets of
that type):
LCP Configure-Request:
Config. Opt.
Addr. Ctl. PID Code ID Length Type Lngth Mode
+----+----+-------+----+----+-------+----+----+----+-----+
| ff | 03 | c0 21 | 01 | 00 | 00 07 | 21 | 03 | 01 | FCS |
+----+----+-------+----+----+-------+----+----+----+-----+
LCP Configure-Ack:
Config. Opt.
Addr. Ctl. PID Code ID Length Type Lngth Mode
+----+----+-------+----+----+-------+----+----+----+-----+
| ff | 03 | c0 21 | 02 | 00 | 00 07 | 21 | 03 | 01 | FCS |
+----+----+-------+----+----+-------+----+----+----+-----+
LZS-DCP Packet:
PID DCP
+----+----+------+------ -+-------+-----+
| fd | HD | (SQ) | (DATA) | (LCB) | FCS |
+----+----+------+--------+-------+-----+
Schneider & Venters Informational [Page 7]
RFC 1976 PPP DCE August 1996
The DATA field contains a compressed or uncompressed SDTP-PDU.
The LCB field is only present on a packet containing compressed
data. The Sequence Number and Data fields are only present on
packets that contain data.
+----+------+----+
SDTP-PDU: | 49 | DATA | HD |
+----+------+----+
6. Initial Handshake Operation
When a unit is powered up, or when the lower layer signals that the
peer has gone out of service and returned, the handshake procedure is
initiated. The handshake procedure for Mode-1 and Mode-2 devices is
described below.
Mode-1:
When starting Mode-1, each DCE sends out an LCP Configure-Request
packet containing only the DCE-Identifier LCP Configuration Option
described in Section 3, with the with the Mode Field set to a
value of 1. When a DCE device receives such a packet, it must
answer with an LCP Configure-Ack packet. In each of these
packets, the identifier field is set to 0. If the originator of
the Configure-Request packet does not receive a Configure-Ack
response within a user configurable time T1, the unit MUST revert
to transparent (Mode-0) operation.
Mode-2:
A Mode-2 device will first try to operate in Mode-2 by starting
PPP normally, following the state machine described in [1]. The
LCP Configure-Request MUST include the DCE-Identifier
Configuration Option with the Mode Field set to 2. If the unit
receives a Configure-Reject Packet Containing the DCE-Identifier,
the unit MUST revert immediately to transparent (Mode-0)
operation. If the LCP state machine times out because a response
was not received in user configurable time T2, or if a Mode-1
Configuration-Request packet is received, the unit attempts to
operate in Mode-1 by following the procedure listed above,
ultimately reverting to Mode-0 operation if the Mode-1 procedure
times out.
In either case, the unit is not prohibited from sending multiple
Configuration-Request packets before the applicable timer (T1, T2)
expires. A unit may also initiate the handshake procedure at any
time.
Schneider & Venters Informational [Page 8]
RFC 1976 PPP DCE August 1996
7. Security Considerations
Security issues are not discussed in this memo.
8. References
[1] Simpson, W., ed., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[2] Schneider, K., and S. Venters, "PPP Serial Data Transport
Protocol (PPP-SDTP)", RFC 1963, August 1996.
[3] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
[4] Lutz, R., "PPP LZS-DCP Compression Protocol", RFC 1967
August 1996.
[5] CCITT Recommendation V.120, "Support by an ISDN of Data
Terminal Equipment with V-Series Type Interfaces with
Provision for Statistical Multiplexing (revised 1992)", ITU-T,
1993.
[6] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
January 1994.
[7] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.
Chair's Address
The working group can be contacted via the current chair:
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.com
Schneider & Venters Informational [Page 9]
RFC 1976 PPP DCE August 1996
Authors' Addresses
Questions about this memo can also be directed to:
Kevin Schneider
Adtran, Inc.
901 Explorer Blvd.
Huntsville, AL 35806-2807
Phone: (205) 971-8000
EMail: kevin@adtran.com
Stuart Venters
Adtran, Inc.
901 Explorer Blvd.
Huntsville, AL 35806-2807
Phone: (205) 971-8000
EMail: sventers@adtran.com
Schneider & Venters Informational [Page 10]
|