File: rfc1973.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 (578 lines) | stat: -rw-r--r-- 14,780 bytes parent folder | download | duplicates (8)
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
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578


Network Working Group                                         W. Simpson
Request for Comments: 1973                                    Daydreamer
Category: Standards Track                                      June 1996


                           PPP in Frame Relay



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 describes the use of Frame Relay for framing PPP
   encapsulated packets.


Applicability

   This specification is intended for those implementations which desire
   to use facilities which are defined for PPP, such as the Link Control






















Simpson                      Standards Track                    [Page i]

RFC 1973                     PPP in Frame Relay                June 1996


   Protocol, Network-layer Control Protocols, authentication, and
   compression.  These capabilities require a point-to-point
   relationship between peers, and are not designed for multi-point or
   multi-access environments.


Table of Contents


     1.     Introduction ..........................................    1

     2.     Physical Layer Requirements ...........................    1

     3.     The Data Link Layer ...................................    2
        3.1       Frame Format ....................................    2
        3.2       Modification of the Basic Frame .................    3

     4.     In-Band Protocol Demultiplexing .......................    4

     5.     Out-of-Band signaling .................................    5

     6.     Configuration Details .................................    5

     SECURITY CONSIDERATIONS ......................................    7

     REFERENCES ...................................................    7

     ACKNOWLEDGEMENTS .............................................    7

     CHAIR'S ADDRESS ..............................................    8

     AUTHOR'S ADDRESS .............................................    8



















Simpson                      Standards Track                   [Page ii]

RFC 1973                     PPP in Frame Relay                June 1996



1.  Introduction

   Frame Relay [2] is a relative newcomer to the serial link community.
   Like X.25, the protocol was designed to provide virtual circuits for
   connections between stations attached to the same Frame Relay
   network.  The improvement over X.25 is that Q.922 is restricted to
   delivery of packets, and dispenses with sequencing and flow control,
   simplifying the service immensely.

   PPP uses ISO 3309 HDLC as a basis for its framing [3].

   When Frame Relay is configured as a point-to-point circuit, PPP can
   use Frame Relay as a framing mechanism, ignoring its other features.
   This is equivalent to the technique used to carry SNAP headers over
   Frame Relay [4].

   At one time, it had been hoped that PPP in HDLC-like frames and Frame
   Relay would co-exist on the same links.  Unfortunately, the Q.922
   method for expanding the address from 1 to 2 to 4 octets is not
   indistinguishable from the ISO 3309 method, due to the structure of
   its Data Link Connection Identifier (DLCI) subfields.  Co-existance
   is precluded.



2.  Physical Layer Requirements

   PPP treats Frame Relay framing as a bit-synchronous link.  The link
   MUST be full-duplex, but MAY be either dedicated (permanent) or
   switched.

   Interface Format

      PPP presents an octet interface to the physical layer.  There is
      no provision for sub-octets to be supplied or accepted.

   Transmission Rate

      PPP does not impose any restrictions regarding transmission rate,
      other than that of the particular Frame Relay interface.

   Control Signals

      Implementation of Frame Relay 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.



Simpson                      Standards Track                    [Page 1]

RFC 1973                     PPP in Frame Relay                June 1996


      Because PPP does not normally require the use of control signals,
      the failure of such signals MUST NOT affect correct operation of
      PPP.  Implications are discussed in [2].

   Encoding

      The definition of various encodings is the responsibility of the
      DTE/DCE equipment in use, and is outside the scope of this
      specification.

      While PPP will operate without regard to the underlying
      representation of the bit stream, Frame Relay requires NRZ
      encoding.



3.  The Data Link Layer

   This specification uses the principles, terminology, and frame
   structure described in "Multiprotocol Interconnect over Frame Relay"
   [4].

   The purpose of this specification is not to document what is already
   standardized in [4].  Instead, this document attempts to give a
   concise summary and point out specific options and features used by
   PPP.



3.1.  Frame Format

   As described in [4], Q.922 header address and control fields are
   combined with the Network Layer Protocol Identifier (NLPID), which
   identifies the encapsulation which follows.  The fields are
   transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+
   |  Flag (0x7e)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Q.922 Address         |    Control    |  NLPID(0xcf)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PPP Protocol          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The PPP Protocol field and the following Information and Padding
   fields are described in the Point-to-Point Protocol Encapsulation



Simpson                      Standards Track                    [Page 2]

RFC 1973                     PPP in Frame Relay                June 1996


   [1].



3.2.  Modification of the Basic Frame

   The Link Control Protocol can negotiate modifications to the basic
   frame structure.  However, modified frames will always be clearly
   distinguishable from standard frames.

   Address-and-Control-Field-Compression

      Because the Address and Control field values are not constant, and
      are modified as the frame is transported by the network switching
      fabric, Address-and-Control-Field-Compression MUST NOT be
      negotiated.

   Protocol-Field-Compression

      Note that unlike PPP in HDLC-like framing, the Frame Relay framing
      does not align the Information field on a 32-bit boundary.
      Alignment to a 32-bit boundary occurs when the NLPID is removed
      and the Protocol field is compressed to a single octet.  When this
      improves throughput, Protocol-Field-Compression SHOULD be
      negotiated.


























Simpson                      Standards Track                    [Page 3]

RFC 1973                     PPP in Frame Relay                June 1996


4.  In-Band Protocol Demultiplexing

   The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish the
   PPP encapsulation from the other NLPID encapsulations described in
   [4].

   The joining of the PPP and NLPID number space has an added advantage,
   in that the LCP Protocol-Reject can be used to indicate NLPIDs that
   are not recognized.  This can eliminate "black-holes" that occur when
   traffic is not supported.

   For those network-layer protocols which have no PPP Protocol
   assignment, or which have not yet been implemented under the PPP
   encapsulation, or which have not been successfully negotiated by a
   PPP NCP, another method of encapsulation defined under [4] SHOULD be
   used.

   Currently, there are no conflicts between NLPID and PPP Protocol
   values.  If a future implementation is configured to send a NLPID
   value which is the same as a compressed Protocol field, that Protocol
   field MUST NOT be sent compressed.

   On reception, the first octet following the header is examined.  If
   the octet is zero, it MUST be assumed that the packet is formatted
   according to [4].

   PPP encapsulated packets always have a non-zero octet following the
   header.  If the octet is not the PPP NLPID value (CF hex), and
   Protocol-Field-Compression is enabled, and the associated NCP has
   been negotiated, then it is expected to be a compressed PPP Protocol
   value.  Otherwise, it MUST be assumed that the packet is formatted
   according to [4].

   The Protocol field value 0x00cf is not allowed (reserved) to avoid
   ambiguity when Protocol-Field-Compression is enabled.  The value MAY
   be treated as a PPP Protocol that indicates that another PPP Protocol
   packet follows.

   Initial LCP packets contain the sequence cf-c0-21 following the
   header.  When a LCP Configure-Request packet is received and
   recognized, the PPP link enters Link Establishment phase.

   The accidental connection of a link to feed a multipoint network (or
   multicast group) SHOULD result in a misconfiguration indication.
   This can be detected by multiple responses to the LCP Configure-
   Request with the same Identifier, coming from different framing
   addresses.  Some implementations might be physically unable to either
   log or report such information.



Simpson                      Standards Track                    [Page 4]

RFC 1973                     PPP in Frame Relay                June 1996


   Once PPP has entered the Link Establishment phase, packets with other
   NLPID values MUST NOT be sent, and on receipt such packets MUST be
   silently discarded, until the PPP link enters the Network-Layer
   Protocol phase.

   Once PPP has entered the Network-Layer Protocol phase, and
   successfully negotiated a particular NCP for a PPP Protocol, if a
   frame arrives using another equivalent data encapsulation defined in
   [4], the PPP Link MUST re-enter Link Establishment phase and send a
   new LCP Configure-Request.  This prevents "black-holes" that occur
   when the peer loses state.

   An implementation which requires PPP link configuration, and other
   PPP negotiated features (such as authentication), MAY enter
   Termination phase when configuration fails.  Otherwise, when the
   Configure-Request sender reaches the Max-Configure limit, it MUST
   fall back to send only frames encapsulated according to [4].



5.  Out-of-Band signaling

   There is no generally agreed method of out-of-band signalling.  Until
   such a method is universally available, an implementation MUST use
   In-Band Protocol Demultiplexing for both Permanent and Switched
   Virtual Circuits.



6.  Configuration Details

   The following Configuration Options are recommended:

      Magic Number
      Protocol Field Compression

   The standard LCP configuration defaults apply to Frame Relay links,
   except Maximum-Receive-Unit (MRU).

   To ensure interoperability with existing Frame Relay implementations,
   the initial MRU is 1600 octets [4].  This only affects the minimum
   required buffer space available for receiving packets, not the size
   of packets sent.

   The typical network feeding the link is likely to have a MRU of
   either 1500, or 2048 or greater.  To avoid fragmentation, the
   Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
   exceed 1500, unless a peer MRU of 2048 or greater is specifically



Simpson                      Standards Track                    [Page 5]

RFC 1973                     PPP in Frame Relay                June 1996


   negotiated.

   Some Frame Relay switches are only capable of 262 octet frames.  It
   is not recommended that anyone deploy or use a switch which is
   capable of less than 1600 octet frames.  However, PPP implementations
   MUST be configurable to limit the size of LCP packets which are sent
   to 259 octets (which leaves room for the NLPID and Protocol fields),
   until LCP negotiation is complete.

   XID negotiation is not required to be supported for links which are
   capable of PPP negotiation.

   Inverse ARP is not required to be supported for PPP links.  That
   function is provided by PPP NCP negotiation.





































Simpson                      Standards Track                    [Page 6]

RFC 1973                     PPP in Frame Relay                June 1996


Security Considerations

   Security issues are not discussed in this memo.



References

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

   [2]   CCITT Recommendation Q.922, "ISDN Data Link Layer Specification
         for Frame Mode Bearer Services", International Telegraph and
         Telephone Consultative Committee, 1992.

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

   [4]   Bradley, T.,  Brown, C., and A. Malis, "Multiprotocol
         Interconnect over Frame Relay", RFC 1490, July 1993.

   [5]   ISO/IEC TR 9577:1990(E), "Information technology -
         Telecommunications and Information exchange between systems -
         Protocol Identification in the network layer", 1990-10-15.



Acknowledgments

   This design was inspired by the paper "Parameter Negotiation for the
   Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
   University of California, Berkeley, 1992, unpublished.



















Simpson                      Standards Track                    [Page 7]

RFC 1973                     PPP in Frame Relay                June 1996


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



Author's Address

   Questions about this memo can also be directed to:

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

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


























Simpson                      Standards Track                    [Page 8]