File: rfc1993.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (396 lines) | stat: -rw-r--r-- 9,811 bytes parent folder | download | duplicates (5)
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






Network Working Group                                          A. Barbir
Request for Comments: 1993                                       Gandalf
Category: Informational                                          D. Carr
                                                               Newbridge
                                                              W. Simpson
                                                              DayDreamer
                                                             August 1996


                  PPP Gandalf FZA Compression Protocol


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  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.

   The PPP Compression Control Protocol [2] provides a method to
   negotiate and utilize compression protocols over PPP encapsulated
   links.

   This document describes the use of the Gandalf FZA data compression
   algorithm [3] for compressing PPP encapsulated packets.

Table of Contents

     1.     Introduction ..........................................    1
        1.1       Licensing .......................................    1
     2.     FZA Packets ...........................................    2
        2.1       Packet Format ...................................    3
     3.     Configuration Option Format ...........................    4
     SECURITY CONSIDERATIONS ......................................    4
     ACKNOWLEDGEMENTS .............................................    5
     REFERENCES ...................................................    5
     CONTACTS .....................................................    5










Barbir, Carr & Simpson                                          [Page i]

RFC 1993                      Gandalf FZA                    August 1996


1.  Introduction

   FZA is a high performance LZ [4] derivative that maximizes
   compression at the expense of memory and CPU.  Compression
   performance can be adjusted based on CPU and memory available.

   Multiple PPP packets can be combined in a single compressed frame, or
   a single PPP packet can be spread across multiple frames.

1.1.  Licensing

   Source and object licenses are available on a non-discriminatory
   basis for either a royalty or fixed price arrangement.  Patent
   indemnity is included with the license.





































Barbir, Carr & Simpson                                          [Page 1]

RFC 1993                      Gandalf FZA                    August 1996


2.  FZA Packets

   Before any FZA packets may be communicated, PPP must reach the
   Network-Layer Protocol phase.

   When the Compression Control Protocol (CCP) has reached the Opened
   state, and FZA is negotiated as the primary compression algorithm,
   the PPP Protocol field indicates type hex 00FB (link compressed
   datagram), or type hex 00FD (compressed datagram).

   The maximum length of the FZA datagram transmitted over a PPP link is
   the same as the maximum length of the Information field of a PPP
   encapsulated packet.

   Padding

      The FZA packets require the negotiation of the Self-Describing-
      Padding Configuration Option [5] at LCP Link Establishment.

   Reliability and Sequencing

      The FZA algorithm expects a reliable link, as described in "PPP
      Reliable Transmission" [6].

      FZA expects the packets to be delivered in sequence.

   Data Expansion

      The maximum expansion of Gandalf FZA is 2:1.  However, typical
      expansion on pre-compressed data is 1.01:1.  Expanded data is sent
      to maintain the integrity of the compression history.

      When the expansion exceeds the size of the peer's Maximum Receive
      Unit for the link, the expanded packet is sent in multiple PPP
      frames.  The compressed data contains an indication of the end of
      the original packet.















Barbir, Carr & Simpson                                          [Page 2]

RFC 1993                      Gandalf FZA                    August 1996


2.1.  Packet Format

   A summary of the Gandalf FZA packet format is shown below.  The
   fields are transmitted from left to right.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PPP Protocol          |     Compressed Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PPP Protocol

      One or two octets.  The PPP Protocol field is described in the
      Point-to-Point Protocol Encapsulation [1].

      Type 00FD is used when the PPP multilink protocol is not used,
      and/or "inside" a multilink bundle.  Type 00FB is used "outside"
      multilink, to compress independently on individual links of a
      multilink bundle.  This value MAY be compressed when LCP
      Protocol-Field-Compression is negotiated.

   Compressed Data

      One or more octets.  The compressed PPP encapsulated packet(s).

      Prior to compression, the uncompressed data begins with the
      original PPP Protocol number.  This value MAY be compressed when
      LCP Protocol-Field-Compression is negotiated.

      The original Protocol number is followed by the original
      Information field.  The length of the original Information field
      before compression MUST NOT exceed the link Maximum Receive Unit
      (MRU).

      PPP Link Control Protocol packets MUST NOT be sent within
      compressed data.
















Barbir, Carr & Simpson                                          [Page 3]

RFC 1993                      Gandalf FZA                    August 1996


3.  Configuration Option Format

   Description

      The CCP Gandalf-FZA Configuration Option negotiates the use of
      Gandalf FZA on the link.  By default or ultimate disagreement, no
      compression is used.

   A summary of the Gandalf-FZA Configuration Option format is shown
   below.  The fields are transmitted from left to right.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   History   |    Version ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      19

   Length

      >= 3

   History

      One octet.  The History field specifies the maximum size of the
      compression history in powers of 2.  Valid values range from 12 to
      15.

      The peer is not required to send as many histories as the
      implementation indicates that it can accept.

   Version

      Zero or more octets of additional configuration information.  Any
      implementation that does not implement this information MUST send
      a Configure-Nak without this field.

      The Version field is not present for FZA.

      The Version field is a single octet containing the value 1 for
      FZA+.


Security Considerations

   Security issues are not discussed in this memo.




Barbir, Carr & Simpson                                          [Page 4]

RFC 1993                      Gandalf FZA                    August 1996


Acknowledgements

   FZA was developed by David Carr while at Gandalf Data Limited.

   FZA+ was an improvement by Abbie Barbir.

   Editting and formatting by William Simpson.


References

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
         51, RFC 1661, DayDreamer, July 1994.

   [2]   Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
         1962, Novell, June 1996.

   [3]   Barbir, A., "A New Fast Approximate Arithmetic Coder",
         Proceedings of IEEE 28th SouthEastern Symposium on Systems
         Theory (SSST), Baton Rouge, Louisiana, pages 482-486, April
         1996.

   [4]   Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential
         Data Compression", IEEE Transactions On Information Theory,
         Vol. IT-23, No. 3, May 1977.

   [5]   Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
         DayDreamer, January 1994.

   [6]   Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
         1994.



Contacts

   Licensing queries should be directed to:

   Michael Williams
   Director of Business Development
   Gandalf Data Limited
   130 Colonnade Road South
   Napean, Ontario, Canada  K2E 7M4
   (613) 274-6500 ext 6575







Barbir, Carr & Simpson                                          [Page 5]

RFC 1993                      Gandalf FZA                    August 1996


   Comments should be submitted to the ietf-ppp@merit.edu mailing list.

   This document was reviewed by the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).

   The working group can be contacted via the current chair:

      Karl Fox
      Ascend Communications
      3518 Riverside Drive, Suite 101
      Columbus, Ohio  43221

          karl@MorningStar.com
          karl@Ascend.com


   Questions about this memo can also be directed to:

      Abdulkader Barbir
      Gandalf Data Limited
      130 Colonnade Road South
      Napean, Ontario, Canada  K2E 7M4
      (613) 274-6500 ext 8550

          abarbir@gandalf.ca


   Questions about this memo should not be directed to:

      Dave Carr
      Newbridge Networks Corporation
      600 March Road
      P.O. Box 13600
      Kanata, Ontario, Canada, K2K 2E6

          dcarr@newbridge.com

      William Allen Simpson
      DayDreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

          wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)







Barbir, Carr & Simpson                                          [Page 6]