File: rfc1663.txt

package info (click to toggle)
doc-rfc 1999.08-1
  • links: PTS
  • area: main
  • in suites: potato
  • size: 68,428 kB
  • ctags: 6
  • sloc: sh: 2,491; perl: 390; makefile: 44
file content (451 lines) | stat: -rw-r--r-- 17,281 bytes parent folder | download | duplicates (9)
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






Network Working Group                                           D. Rand
Request for Comments: 1663                                       Novell
Category: Standards Track                                     July 1994


                       PPP Reliable Transmission

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  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.

   This document defines a method for negotiating and using Numbered-
   Mode, as defined by ISO 7776 [2], to provide a reliable serial link.

   This document is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the ietf-ppp@ucdavis.edu mailing list.

Table of Contents

   1.     Introduction ..........................................    1
   2.     Physical Layer Requirements ...........................    2
   3.     The Data Link Layer ...................................    2
   3.1       Frame Format .......................................    2
   4.     Configuration Option Format ...........................    4
   5.     Numbered-Mode Operation ...............................    5
   5.1       Single Link ........................................    6
   5.2       Inverse Multiplexing ...............................    6
   5.3       Using Multi-Link Procedure... ......................    7
   5.4       LAPB Parameter defaults ............................    8
   SECURITY CONSIDERATIONS ......................................    9
   REFERENCES ...................................................    9
   ACKNOWLEDGEMENTS .............................................    9
   CHAIR'S ADDRESS ..............................................   10
   AUTHOR'S ADDRESS .............................................   10







Rand                                                            [Page 1]

RFC 1663               PPP Reliable Transmission               July 1994


1.  Introduction

   By default, PPP packets over HDLC framed links consist of
   "connectionless" datagrams.  If reliable transmission over the HDLC
   link is desired, the implementation MUST specify the Numbered-Mode
   Configuration Option during Link Establishment phase.

   Generally, serial link reliability is not a major issue.  The
   architecture of protocols used in datagram networking presume
   best-effort non-sequential delivery.  When errors are detected,
   datagrams
   are discarded.

   However, in certain circumstances, it is advisable to provide a
   reliable link, at least for a subset of the messages.  The most
   obvious case is when the link is compressed.  Since the dictionary is
   recovered from the compressed data stream, and a lost datagram
   corrupts the dictionary, datagrams must not be lost.  Not all
   compression types will require a reliable data stream, since the cost
   to detect and reset a corrupt dictionary is small.

   The ISO 7776 LAPB can be used guarantee delivery.  This is referred
   to in this document as "Numbered Mode" to distinguish it from the use
   of "Unnumbered Information", which is standard PPP framing practice.

   Where multiple parallel links are used to emulate a single link of
   higher speed, Bridged traffic, Source Routed traffic, and traffic
   subjected to Van Jacobsen TCP/IP header compression must be delivered
   to the higher layer in a certain sequence.  However, the fact of the
   links being relatively asynchronous makes traffic ordering uncertain.

   The ISO 7776 Multi-Link Procedure MAY be used to restore order.
   Implementation of the ISO Multi-Link Procedure is deprecated.  It is
   recommended that the PPP multilink procedure [4] be used instead.

2.  Physical Layer Requirements

   PPP Reliable Transmission imposes the same requirements that are
   described in "PPP in HDLC Framing" [3], with the following
   exceptions.

   Control Signals

      While PPP does not normally require the use of control signals,
      implementation of Numbered-Mode LAPB or LAPD requires the
      provision of control signals, which indicate when the link has
      become connected or disconnected.  These in turn provide the Up
      and Down events to the LCP state machine.



Rand                                                            [Page 2]

RFC 1663               PPP Reliable Transmission               July 1994


3.  The Data Link Layer

   Numbered-Mode affects only the Address and Control fields.  The
   remainder of the frame conforms to the framing in use for PPP.

   The Address Field of the frame MUST take the value announced in the
   Numbered-Mode Configuration Option, and the Control Field MAY take
   any value valid in ISO 7776.

   Once the link enters Numbered-Mode, Numbered-Mode MUST be used on all
   frames, as some implementations do not support the use of the
   Unnumbered-Information control field or the use of the All-Stations
   address intermixed with Numbered-Mode frames.

3.1.  Frame Format

   The following frame format is valid under Numbered-Mode.  The fields
   are transmitted from left to right.

   Numbered Mode
           +----------+----------+----------+
           |   Flag   | Address  | Control  |
           | 01111110 |1-2 octets|1-2 octets|
           +----------+----------+----------+
           +----------+-------------+---------+
           | Protocol | Information | Padding |
           |1-2 octets|      *      |    *    |
           +----------+-------------+---------+
           +----------+----------+-----------------
           |   FCS    |   Flag   | Inter-frame Fill
           | 16 bits  | 01111110 | or next Address
           +----------+----------+-----------------

   The Protocol, Information and Padding fields are described in the
   Point-to-Point Protocol Encapsulation [1].  The FCS and Flag Sequence
   fields are described in "PPP in HDLC Framing" [3].

4.  Configuration Option Format

   Description

      The LCP Numbered-Mode Configuration Option negotiates the use of
      Numbered-Mode on the link.  By default or ultimate disagreement,
      Unnumbered-Mode is used.

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




Rand                                                            [Page 3]

RFC 1663               PPP Reliable Transmission               July 1994


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |    Window     |   Address...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      11

   Length

      >= 4

   Window

      A value between 1 and 127.  This indicates the number of frames
      the receiver will buffer, which is the maximum number that the
      sender should send without receiving an acknowledgement.  If
      window < 8, then modulo 8 sequencing is used on the link.
      Otherwise, modulo 128 sequencing is used.

      It is conceivable and legal that differing window values might be
      announced.  However, it is not permitted for one system to use
      modulo 8 sequencing and the other to use modulo 128.  Therefore,
      the rule is: a Configure-Nak may reduce the window but may not
      increase it.

   Address

      An HDLC Address as specified in ISO 3309.  ISO 7776 specifies four
      of the possible values: 1 and 3 for single link operation, 7 and
      15 for the Multi-Link Procedure.  Other values consistent with ISO
      3309 are considered legal.

      Implementation of the Multi-Link Procedure is optional; A

      Configure-Nak may therefore force a change from MLP to single link
      mode, but not the reverse.

      Should the address be zero upon receipt, the receiver MUST
      Configure-Nak with an appropriate address.  If both peers send
      address zero, the system advertising the numerically smaller
      window will select the smaller address.  If both windows are the
      same size, a random choice MUST be made; when good sources of
      randomness are used, the link will converge in a reasonable time.





Rand                                                            [Page 4]

RFC 1663               PPP Reliable Transmission               July 1994


      If magic numbers have been negotiated on the link, the system with
      the numerically smaller magic number SHOULD specify the smaller
      address.

5.  Numbered-Mode Operation

   When using the Numbered-Mode, each link is established in the usual
   manner for the type of link.  The Numbered-Mode Configuration Option
   is negotiated, the Magic-Number Configuration Option MUST also be
   negotiated, and the Address-and-Control-Field-Compression
   Configuration Option MUST NOT be negotiated.

   Following the successful negotiation of the Numbered-Mode
   Configuration Option during LCP Link Establishment phase, the system
   with the numerically smaller Magic-Number will send a SABM or
   SABM(E), and the other will respond with a UA.  In the event that
   either the SABM or UA is lost, this exchange may be repeated
   according to the same parameters as the configuration exchange
   itself, using the Restart Timer and counter values.  Authentication,
   Link Quality Determination, and NCP Configuration follow this step.

   Once the link has been established with Numbered-Mode, when re-
   negotiation of link configuration occurs, the entire re-negotiation
   MUST be conducted in Numbered-Mode.  If the Numbered-Mode
   Configuration Option is not successfully re-negotiated, the link
   reverts to Unnumbered-Information operation prior to Authentication,
   Link Quality Determination, and NCP Configuration.

   When an implementation which is capable of Numbered-Mode, and is not
   currently configured for Numbered-Mode operation, detects a frame
   which has a correct FCS but does not have a UI Control octet, the
   implementation MUST send a DM message, immediately followed by a LCP
   Configure-Request.

   When an implementation which is currently configured for Numbered-
   Mode operation receives a DM message, it MUST revert to Unnumbered-
   Information operation, and immediately send a LCP Configure-Request.

5.1.  Single Link

   When Network-Layer packets are sent over a single link, the packets
   are encapsulated in the following order:

    +----------+   +----------+   +----------+
    |          |   |          |   | Numbered |
    | Header   |-->| Data     |-->| Mode     |--> link
    | Compress |   | Compress |   | Header   |
    +----------+   +----------+   +----------+



Rand                                                            [Page 5]

RFC 1663               PPP Reliable Transmission               July 1994


5.2.  Inverse Multiplexing

   Since sending several connections over a single link is often called
   "multiplexing", sending packets from a single connection over
   multiple parallel links is sometimes called "inverse-multiplexing".
   By default, PPP performs no special processing for such links.  Each
   link is established and terminated independently, negotiates its own
   configuration options, and may have different combinations of such
   options as ACCM, Protocol Field Compression and IP-Address.  This
   facilitates using the links simultaneously over dissimilar media,
   such as 56K sync with async backup.

   Every link in a single machine MUST have different Magic Numbers, and
   each end of every link between two peers SHOULD have Magic Numbers
   which are unique to those peers.  This protects against patch-panel
   errors in addition to looped-back links.

   The distribution to each link is controlled by higher level routing
   mechanisms.  When Network-Layer specific compression techniques (such
   as Van Jacobsen Compression) rely on sequential delivery, without
   Multi-Link Procedure support such compression MUST be applied on a
   link by link basis.

                    +----------+   +----------+   +----------+
                    |          |   |          |   | Numbered |
               +--->| Header   |-->| Data     |-->| Mode     |--> link 1
               |    | Compress |   | Compress |   | Header   |
  +--------------+  +----------+   +----------+   +----------+
  | Distribution |
  +--------------+  +----------+   +----------+   +----------+
               |    |          |   |          |   | Numbered |
               +--->| Header   |-->| Data     |-->| Mode     |--> link 2
                    | Compress |   | Compress |   | Header   |
                    +----------+   +----------+   +----------+

5.3.  Using Multi-Link Procedure

   This document does not offer a standard for ISO Multi-Link, but does
   offer a method for agreeing on the addressing scheme usable with
   Multi-Link.  A sample implementation is shown below.  Implementation
   of Multi-Link is not required.

   When using the ISO 7776 Multi-Link Procedure, each link is
   established as described above.  In addition, the Numbered-Mode
   Configuration Option is negotiated with appropriate addresses for the
   Multi-Link Procedure.  The distribution to each link is controlled by
   the Multi-Link Procedure, as is the recovery of sequence in the
   receiving system.



Rand                                                            [Page 6]

RFC 1663               PPP Reliable Transmission               July 1994


                                                            +---> link 1
  +----------+   +----------+   +----------+                |
  |          |   |          |   | Multi    |   +--------------+
  | Header   |-->| Data     |-->| Link     |-->| Distribution |
  | Compress |   | Compress |   | Procedure|   +--------------+
  +----------+   +----------+   +----------+                |
                                                            +---> link 2

5.4.  LAPB Parameter defaults

   The following guidelines specify the default values of LAPB
   configurable parameters.

      Timer T1

         Timer T1 is the maximum time permitted before a retransmission
         is started, as a result of no response to a transmitted I
         frame.  This value must be greater than the time required for a
         maximum sized frame to be received by the other side of the
         link, and for a response to be generated for the frame.  This
         SHOULD be determined dynamically, based on the measured round
         trip time delay of the link at the LAPB level.  In the event
         that the system cannot determine the round trip time of the
         link, this value SHOULD be set to twice the bit rate of the
         link, divided by the maximum number of bits per frame, plus 100
         milliseconds processing time.  For example, on a 14,400 bps
         link, with a maximum frame size of 8000 bits (1000 octects),
         the T1 value would be set to 3.7 seconds.

      Timer T3

         Timer T3 gives an indication of the idle state of the link.
         Its value must be greater than the T1 value.

      Maximum number of attempts to complete a transmission, N2

         Parameter N2 gives the maximum number of retransmission
         attempts for a given frame.  If this value is exceeded, the
         link SHOULD be terminated.  The default value for parameter N2
         SHOULD be 3.

Security Considerations

   Security issues are not discussed in this memo.







Rand                                                            [Page 7]

RFC 1663               PPP Reliable Transmission               July 1994


References

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

   [2] ISO 7776, Information Processing Systems - Data Communication -
       High Level Data Link Control Procedures - Description of the X.25
       LAPB-Compatible DTE Data Link Procedures

   [3] Simpson, W., Editor, "PPP in HDLC Framing", STD 51, RFC 1662,
       Daydreamer, July 1994.

   [4] Sklower, K., "PPP MultiLink Procedure", Work in Progress.

Acknowledgments

   Fred Baker was the original author of this document.

   Bill Simpson contributed materially to the document.

Chair's Address

   The working group can be contacted via the current chair:

   Fred Baker
   Advanced Computer Communications
   315 Bollay Drive
   Santa Barbara, California  93117

   EMail: fbaker@acc.com

Author's Address

   Questions about this memo can also be directed to:

   Dave Rand
   2180 Fortune Drive
   San Jose, CA  95131

   Phone: +1 408 321-1259
   EMail: dave_rand@novell.com










Rand                                                            [Page 8]