File: rfc1547.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 (1179 lines) | stat: -rw-r--r-- 49,810 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
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
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179






Network Working Group                                         D. Perkins
Request for Comments: 1547                    Carnegie Mellon University
Category: Informational                                    December 1993


     Requirements for an Internet Standard Point-to-Point Protocol

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

   This document discusses the evaluation criteria for an Internet
   Standard Data Link Layer protocol to be used with point-to-point
   links.  Although many industry standard protocols and ad hoc
   protocols already exist for the data link layer, none are both
   complete and sufficiently versatile to be accepted as an Internet
   Standard.  In preparation to designing such a protocol, the features
   necessary to qualify a point-to-point protocol as an Internet
   Standard are discussed in detail.  An analysis of the strengths and
   weaknesses of several existing protocols on the basis of these
   requirements demonstrates the failure of each to address key issues.

      Historical Note: This was the design requirements document dated
      June 1989, which was followed for RFC-1134 through the present.
      It is now published for completeness and future guidance.






















Perkins                                                         [Page 1]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


Table of Contents

   1.    Introduction ................................................3
   1.1   Definitions of Terms ........................................4
   2.    Required Features ...........................................6
   2.1   Simplicity ..................................................7
   2.2   Transparency ................................................7
   2.3   Packet Framing ..............................................7
   2.4   Bandwidth Efficiency ........................................8
   2.5   Protocol Processing Efficiency ..............................8
   2.6   Protocol Multiplexing .......................................8
   2.7   Multiple Physical and Data Link Layer Protocols..............8
   2.8   Error Detection .............................................9
   2.9   Standardized Maximum Packet Length (MTU) ....................9
   2.10  Switched and Non-Switched Media .............................9
   2.11  Symmetry ....................................................9
   2.12  Connection Liveness .........................................10
   2.13  Loopback Detection ..........................................10
   2.14  Misconfiguration Detection ..................................11
   2.15  Network Layer Address Negotiation ...........................11
   2.16  Data Compression Negotiation ................................11
   2.17  Extensibility and Option Negotiation ........................12
   3.    Features Not Required .......................................12
   3.1   Error Correction ............................................12
   3.2   Flow Control ................................................13
   3.3   Sequencing ..................................................13
   3.4   Backward Compatibility ......................................13
   3.5   Multi-Point Links ...........................................13
   3.6   Half-Duplex or Simplex Links ................................14
   3.7   7-bit Asynchronous RS-232 Links .............................14
   4.    Prior Work On PPP Protocols .................................14
   4.1   Internet Protocols ..........................................14
   4.1.1 RFC 891 - DCN Local-Network Protocols, Appendix A............14
   4.1.2 RFC 914 - Thinwire Protocols ................................14
   4.1.3 RFC 916 - Reliable Asynchronous Transfer Protocol............15
   4.1.4 RFC 935 - Reliable Link Layer Protocols .....................15
   4.1.5 RFC 1009 - Requirements for Internet Gateways ...............15
   4.1.6 RFC 1055 - Serial Line IP ...................................16
   4.2   International Protocols .....................................16
   4.2.1 ISO 3309 - HDLC Frame Structure .............................16
   4.2.2 ISO 6256 - HDLC Balanced Class of Procedures.................16
   4.2.3 CCITT X.25 and X.25 LAPB ....................................17
   4.2.4 CCITT I.441 LAPD ............................................17
   4.3   Other Protocols .............................................17
   4.3.1 Cisco Systems point-to-point protocols ......................17
   4.3.2 MIT PC/IP framing protocol ..................................18
   4.3.3 Proteon p4200 point-to-point protocol .......................18
   4.3.4 Ungermann Bass point-to-point protocol ......................18



Perkins                                                         [Page 2]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


   4.3.5 Wellfleet point-to-point protocol ...........................19
   4.3.6 XNS Synchronous Point-to-Point Protocol .....................19
   REFERENCES ........................................................20
   SECURITY CONSIDERATION.............................................21
   CHAIR'S ADDRESS ...................................................21
   AUTHOR'S ADDRESS ..................................................21
   EDITOR'S ADDRESS ..................................................21

1. Introduction

   The Internet has seen explosive growth in the number of hosts
   supporting IP [1].  The vast majority of these hosts are connected to
   Local Area Networks (LANs) of various types, Ethernet being the most
   common.  Most of the other hosts are connected through Wide Area
   Networks (WANs), such as X.25 style Public Data Networks (PDNs).

   In the past, relatively few of these hosts were connected with simple
   point-to-point links.  Yet, point-to-point serial links are among the
   oldest methods of data communications, and almost every host supports
   point-to-point connections.  For example, asynchronous RS-232
   interfaces are essentially ubiquitous.

   One reason for the small number of point-to-point IP links was the
   lack of a single established encapsulation protocol.  There were
   plenty of non-standard (and at least one de facto standard)
   encapsulation protocols available, but there was not one which was
   agreed upon as an Internet Standard.

   A number of protocols have been proposed to the Internet community,
   but no consensus was reached as to which protocol should be adopted
   as a standard.  The reason may be that these proposals often
   addressed specific problems rather than providing general purpose
   service.

   For example, one of the most successful protocols to-date was Rick
   Adam's SLIP protocol for BSD UNIX [9].  SLIP provides only the most
   rudimentary support for sending IP datagrams over asynchronous serial
   lines, and ignores issues such as the use of protocols other than IP
   and the use of synchronous links.

   This document proposes a set of requirements for an Internet Standard
   point-to-point protocol (ISPPP).  Its purpose is not to propose any
   one design for the standard; any solutions outlined in the text are
   intended only as examples, and do not preclude other implementations.

   The document is divided into four major sections.  The first section
   defines a number of technical terms used in this document.  The
   second section lists the proposed requirements and details some



Perkins                                                         [Page 3]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


   issues that are ignored by other protocols.  The third section
   attempts to clarify a number of non-requirements.  The fourth section
   analyzes existing protocols in light of the proposed requirements and
   discusses the failure of each to address key issues.

1.1 Definitions of Terms

   This section defines many of the terms which will be used in further
   sections of this document.  The terms "layer" and "level" are used
   extensively and refer to protocol layers as defined by the
   International Organization For Standardization's Reference Model
   (ISORM) standard.  In particular, the terms Physical Layer, Data Link
   Layer and Network Layer refer to layers one, two and three
   respectively of the ISORM.  A "higher layer" refers to one with a
   numerically larger layer number.

    datagram

      The unit of transmission in the network layer (such as IP).  A
      datagram may be encapsulated in one or more packets (q.v.) passed
      to the data link layer.

    data link layer

      Layer two in the ISO reference model.  Defines how bits
      transmitted and received by the physical layer are recognized as
      bytes and frames.  May also define procedures for error detection
      and correction, sequencing and flow control.

    fragment

      The result of fragmentation.  Fragmentation at the network layer
      breaks large datagrams into multiple parts less than or equal to
      the size of the packets passed to the data link layer.
      Fragmentation at the data link layer breaks large packets into
      multiple frames.

    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.

    framing protocol

      A protocol at the data link level for marking the beginning and
      end of a frame transmitted across a link.




Perkins                                                         [Page 4]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


    internet

      An interconnected system of networks tied together by a common
      "internet protocol" providing a common and consistent network
      address structure.

    Internet

      Specifically refers to the IP Internet.

    Internet Standard Point-to-Point Protocol (ISPPP)

      A point-to-point protocol which is declared an official Internet
      Standard.  This protocol does not yet exist, but its proposed
      characteristics are presented in this paper.

    Maximum Transmission Unit (MTU)

      The maximum allowable length for a packet (q.v.) transmitted over
      a point-to-point link without incurring network layer
      fragmentation.

    network layer

      Layer three in the ISO reference model.  Responsible for routing
      packets (q.v) between physical networks.

    octet

      A unit of transmission consisting of 8 bits.  On most machines an
      octet is the same as a byte or a character, but this need not be
      true.

    packet

      The unit of transmission passed across the interface between the
      network layer and the data link layer.  A packet is usually mapped
      to a frame (q.v); the exception is when data link layer
      fragmentation is being performed.

    physical layer

      The first layer in the ISO reference model.  Describes electrical,
      mechanical and timing characteristics of a link.

    point-to-point protocol (ppp)

      A data link layer protocol for the transmission of packets (q.v.)



Perkins                                                         [Page 5]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


      over a point-to-point link.  In the following discussion, the
      acronym "ppp" refers to any generic point-to-point protocol.

    serial line IP (slip)

      Often incorrectly used as a synonym for "point-to-point protocol",
      "slip" specifically refers to any protocol for the transmission of
      IP datagrams over a serial point-to-point line.

    SLIP

      Although many proposed protocols are named "SLIP", this document
      will use SLIP (uppercase) to refer to Rick Adam's slip (q.v.) for
      BSD UNIX [9].

2. Required Features

   In order for a point-to-point protocol to be accepted by the Internet
   community it must adequately address many requirements.  This section
   itemizes and discusses the proposed requirements.  Although the main
   emphasis of the discussion is on protocol architecture requirements,
   implementation requirements are sometimes discussed as well.

   These particular requirements were chosen to assure that the ISPPP
   adequately serves the needs of its users.  Some of these needs are
   universal and dictate clear requirements for the protocol; for
   example, a packet framing protocol is a fundamental necessity.  Other
   needs are more specific and may even be conflicting.  Connection
   liveness determination is very important on some links but can be
   very expensive on others.  A standard protocol must address all of
   these needs; in particular, it must be able to resolve conflicts
   effectively.

   Resolving these conflicts requires that a protocol feature have both
   enabled and disabled modes and that these modes must be compatible
   with each other.  The enabled mode allows the protocol to solve
   problems in environments where they exist.  The disabled mode allows
   problems to be ignored in environments where they do not exist.  To
   assure interoperabilty, implementations are required to support both
   modes and allow the user (not necessarily human) to dynamically
   choose which is appropriate.

   This is essentially the same solution used in the User Datagram
   Protocol (UDP) [2].  The UDP datagram checksum may be computed
   (enabled mode) or it may not (disabled mode).  Compatibility is
   maintained by requiring the checksum to be transmitted as zero in
   disabled mode and ignored when received as zero in either mode.
   Implementations of UDP are generally encouraged to support both modes



Perkins                                                         [Page 6]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


   but allow the application to choose modes.

2.1 Simplicity

   The ISPPP must be simple.  The Internet architecture very carefully
   places the most complexity in the transport layer (that is, TCP).
   The internetwork layer (IP) is a fairly simple, almost stateless
   protocol providing an unreliable datagram service.  The data link
   layer need provide no more capability than the IP protocol; no error
   correction, sequencing or flow control is necessary.  Including these
   would in most cases needlessly duplicate the capabilities of the
   transport layer, and might possibly decrease efficiency.  This is not
   to say that these capabilities must never be included; there are some
   cases which may warrant them.  For instance, very noisy links may be
   more efficiently handled using a more complex data link layer
   protocol such as CCITT's LAPB.  Nevertheless, the watchword for a
   point-to-point protocol should be simplicity.

   A simple design also decreases the incidence of programming errors,
   thereby increasing the likelihood of interoperability among different
   implementations.  Since interoperability is a primary goal of
   standardization, this is another strong argument for simplicity.

2.2 Transparency

   The ISPPP must be transparent to higher layers.  The protocol must
   not place any constraints on transmitted data.  All ISPPP data,
   including higher level headers as well as data, must be transported
   unmodified end-to-end.  No restrictions are placed on how the ISPPP
   accomplishes this.  For example, if the ISPPP uses a particular
   character for framing, it must also provide some way of
   disambiguating higher level data containing that character from a
   framing character (such as escaping or bit-stuffing).  This is mainly
   an issue for the data link and physical layer protocols incorporated
   into the ISPPP.

2.3 Packet Framing

   The ISPPP must be able to correctly and efficiently frame packets.  A
   receiver must be able to locate correctly the beginning and end of
   each transmitted packet.  Within each packet, the receiver must be
   able to identify the boundaries of each octet.  Finally, within each
   octet, each bit must be located and identified.  No restrictions
   other than those specified in this document are placed on the packet
   framing protocol.






Perkins                                                         [Page 7]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


2.4 Bandwidth Efficiency

   The ISPPP must make efficient use of available bandwidth.  At most,
   the ppp overhead may impose a few percent reduction in raw link
   bandwidth.

2.5 Protocol Processing Efficiency

   The processing of the ISPPP headers must typically be very fast and
   efficient.  The format for data packets should be very simple in the
   normal case, without complex field checking.

2.6 Protocol Multiplexing

   The ISPPP must support multiplexing of many higher level protocols.
   Although the Internet community is interested mainly in IP, co-
   existence of other protocols is frequently required.  IP networks
   must often support additional protocols such as AppleTalk, DECnet,
   IPX, and XNS.  For point-to-point links to connect gateways on
   geographically separated Local Area Networks (LANs), the ISPPP must
   simultaneously support all protocols implemented on both the LANs and
   the gateways.  This suggests that the ISPPP must include a protocol
   type field or other multiplexing scheme.  Given the large number of
   protocols, the potential use of the protocol type field as a data
   compression aid, and the experimental nature of the Internet, eight
   bits of type field are not sufficient.  Sixteen bits of type field
   are suggested, although twelve bits (4096 protocols) should suffice.

2.7 Multiple Physical and Data Link Layer Protocols

   The ISPPP must support a multiplicity of physical and data link layer
   protocols.  Many types of point-to-point links exist.  Links can be
   serial or parallel, synchronous or asynchronous, low speed or high
   speed, electrical or optical.  Standards are required for the
   transmission of IP datagrams over each type of commonly used link.

   The ISPPP must not inhibit the use of any type of link.  This
   includes, but is not limited to, asynchronous, bit-oriented
   synchronous (HDLC [10] and X.25 LAPB [11]), and byte-oriented
   synchronous (BISYNC and DDCMP [15]) links.

   The ISPPP must initially provide support for at least the following
   types of links:

      Full duplex asynchronous RS-232 [3] links with 8 bits of data and
      no parity, ranging in speeds from 300 to 19.2k bps or more.

      Full duplex bit-oriented synchronous links including RS-422, RS-



Perkins                                                         [Page 8]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


      423, V.35 and T1.

      Other links should be standardized as the need arises.

2.8 Error Detection

      The ISPPP must provide some form of basic error detection.  Most
      network and transport layer protocols provide mechanisms to detect
      corrupted packets.  However, some network protocols expect error
      free transmission and either provide error detection only on a
      conditional basis or do not provide it at all.  It is the
      consensus of the Internet community that error correction should
      always be implemented in the end-to-end transport, but that link
      error detection in the form of a checksum, Cyclic Redundancy Check
      (CRC) or other frame check mechanism is useful to prevent wasted
      bandwidth from propagation of corrupted packets.  Link level error
      correction is not required.

2.9 Standardized Maximum Packet Length (MTU)

      The ISPPP must have a standardized default maximum packet length
      for each type of point-to-point link.  This standardization helps
      to promote interoperable implementations.  Higher layer protocols
      must not attempt to transmit packets longer than the MTU.  If a
      higher layer protocol does try to transmit a packet which is too
      long, the ISPPP must drop the packet and return an error.  The MTU
      may potentially be changed from the default via some sort of
      explicit negotiation or private agreement, but the default must be
      enforced in all other cases.  The default should be at least 1500
      bytes, to efficiently carry common LAN traffic.

2.10 Switched and Non-Switched Media

      The ISPPP must be able to support both switched (dynamic) and non-
      switched (static) point-to-point links.  A common example of a
      non- switched link is a 3-wire asynchronous RS-232 cable which
      might connect a host to a particular gateway.  Switched media may
      be exemplified by connections over a standard voice network or an
      Integrated Services Digital Network (ISDN).  Links over ISDN are
      currently rare, but are expected to become increasingly
      commonplace.  To be a viable standard, the ISPPP must be able to
      effectively support both types of links.  Procedures for
      establishing switched connections are beyond the scope of this
      document.

2.11 Symmetry

      The ISPPP should operate symmetrically to maximize flexibility.



Perkins                                                         [Page 9]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


      The ISPPP must allow communications among any combination of
      gateways and hosts.  One host may need to communicate directly
      with another host, or it may be connected to a gateway to gain
      access to a whole network.  A gateway may establish a connection
      to a single host in order to deliver a packet, or it may connect
      to another gateway on a permanent or transient basis.  Symmetry is
      destroyed by pre-assigned static roles, such as master and slave
      or gateway and host.  If necessary, roles may be dynamically
      determined on a per connection basis.

2.12 Connection Liveness

      The ISPPP must include a mechanism to automatically determine when
      a link is functioning properly and when it is defunct.  This
      mechanism should be enabled by default, but the protocol and all
      implementations must allow this mechanism to be disabled.

      When enabled, this mechanism should discover changes in a link's
      status in a timely fashion -- no more than a few minutes.
      Continuing to utilize a link which is down often causes routing
      problems commonly referred to as "black holes".  These problems
      can be hard to find and diagnose.  By automatically detecting a
      failing link, a point-to-point protocol can avoid such problems,
      and also provide a powerful tool for a network manager trying to
      locate and remedy the fault.

      When a point-to-point connection is not functioning properly, it
      must be declared "down" for the purposes of routing packets for
      higher level protocols.  In order to certify a link "up", the
      systems on either end of the link must be able to successfully
      exchange packets.  In other words, the systems at both ends must
      be able both to transmit and to receive packets, and the link must
      be able to transport packets in both directions.  Links are
      defined to be "down" at initialization, their liveness must be
      verified before they may be declared "up".

      This feature may be disabled in situations where connection status
      determination is "expensive".  For example, a link may traverse a
      Public Data Network (such as TELENET or TYMNET) which accounts for
      bandwidth utilization.  Constant pinging would result in charges
      being accrued even in the absence of useful communications.

2.13 Loopback Detection

   The ISPPP must be capable of automatically detecting a looped-back
   link without operator assistance.  Modems and other communications
   gear are often placed in a loopback mode to aid in diagnosis of
   circuit failures.  Detection of this condition must take no longer



Perkins                                                        [Page 10]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


   than one period of the liveness protocol.  While the link is in
   loopback mode, each end of the link must declare the other end to be
   unreachable.  However, to aid in diagnosis, each end of the link may
   declare itself reachable for any higher-level protocol which
   distinguishes between the two ends of the link.

2.14 Misconfiguration Detection

   The ISPPP must be able to quickly detect misconfigured point-to-point
   connections.  A connection which is misconfigured must never be
   declared to be up.  Many systems, gateways in particular, have more
   than one point-to-point connection.  When many cables terminate
   within a small area, the possibility for confusion abounds.  It
   becomes very easy to mistakenly plug a cable into the wrong
   connector, or even to swap cables.  The protocol should do its best
   to provide protection against these errors by verifying the remote
   end's identity whenever possible before marking an interface as
   operational.  The purpose of this verification is not rigorous
   authentication but the detection of simple errors.

2.15 Network Layer Address Negotiation

   The ISPPP must allow network layer (such as IP) addresses to be
   negotiated.  The negotiation algorithm should be as simple as
   possible and must be guaranteed to terminate in all cases.  Many
   network layer protocols and implementations are required to know the
   addresses at both ends of a point-to-point link before packets may be
   routed.  These addresses may be statically configured, but it may
   sometimes be necessary or convenient for these addresses be
   dynamically ascertained at connection establishment.  This is
   especially important when switched media are used.  For example, a
   dial-up IP gateway must know the IP address of its peer before
   packets can be successfully routed.  This address can be either
   statically or dynamically configured.  In the former case, the
   gateway's peer must therefore learn the static address (static with
   respect to the gateway).  In the latter situation, the gateway must
   dynamically learn the address used by its peer.

2.16 Data Compression Negotiation

   The ISPPP must provide a way to negotiate the use of data compression
   algorithms.  This mechanism should be as simple as possible and must
   be guaranteed to terminate in all cases.  The protocol is not
   required to standardize any data compression algorithms; conforming
   implementations of the protocol therefore may refuse to do data
   compression when negotiating (refusal to do data compression always
   takes precedence over an offer to do it).  However, to allow the use
   of data compression between consenting systems, the point-to-point



Perkins                                                        [Page 11]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


   protocol must not impede the use of data compression.  In fact, it
   should be possible to use multiple, independent data compression
   schemes simultaneously.  Because data compression algorithms are
   still very experimental in the Internet environment, it is likely
   that many different algorithms will be tried.  The negotiation
   protocol must distinguish between these different algorithms to
   ensure that data compression is not enabled unless the same algorithm
   or algorithms are used at both ends of the connection.  The number of
   such supported algorithms must be easily extensible.

2.17 Extensibility and Option Negotiation

   The ISPPP must allow for future extensions in a flexible way.  The
   Internet will never cease to evolve.  Changes in technology and user
   demands create new requirements.  To function effectively as a
   standard, the protocol must have the ability to evolve along with its
   environment.

   To accomplish this, the ISPPP should be designed to be as extensible
   as possible and to allow for experimentation within the guidelines of
   the other requirements presented in this document.  A proposed
   solution is to specify an option negotiation protocol.  The option
   negotiation protocol could be used for the negotiation of network
   layer addresses, data compression schemes, MTU, encryption, etc.  The
   option negotiation protocol must itself be extensible; it should
   allow the negotiation of a large number of future options and it
   should allow the use of other types of point-to-point links and
   encapsulation schemes.

3.  Features Not Required

   This section discusses functionality which is explicitly not
   required.  These functions may potentially be included in
   implementations as long as the inclusion does not violate any of the
   requirements itemized in the previous section.

3.1 Error Correction

   As discussed above in the sections on Simplicity and Error Detection,
   error correction is the responsibility of the transport layer and is
   not required in a point-to-point protocol.  However, on links with
   high error rates, performance may be increased by adding error
   correction at the data link level.  Therefore, the ISPPP must not
   prevent the addition of error correction by private agreement, even
   though such mechanisms are not required in the basic implementation.






Perkins                                                        [Page 12]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


3.2 Flow Control

   Flow control (such as XON/XOFF) is not required.  Any implementation
   of the ISPPP is expected to be capable of receiving packets at the
   full rate possible for the particular data link and physical layers
   used in the implementation.  If higher layers cannot receive packets
   at the full rate possible, it is up to those layers to discard
   packets or invoke flow control procedures.  As discussed above, end-
   to-end flow control is the responsibility of the transport layer.
   Including flow control within a point-to-point protocol often causes
   violation of the simplicity requirement.

3.3 Sequencing

   Sequencing of packets is not required.  The ISPPP need provide no
   more service than the IP protocol, an unreliable datagram service
   which is free to reorder packets.  In fact, it is specifically
   allowed to reorder packets based upon some type-of-service criteria
   implemented in higher-level protocols.

3.4 Backward Compatibility

   There is no requirement for the ISPPP to provide backward
   compatibility with any other point-to-point protocol.  First, there
   are no official Internet Standards with which backward compatibility
   must be maintained.  Second, attempting to maintain backward
   compatibility may lead to needless restrictions on the new protocol.
   However, there is no need for the designers of the ISPPP to go out of
   their way to inhibit backward compatibility.

3.5 Multi-Point Links

   There is no requirement for supporting multi-point links.  Many
   features which are required are only valid between two peers.  These
   links are sufficiently rare that the benefits of supporting them are
   outweighed by the added complexity their support would introduce into
   the ISPPP.

      Historical Note: The original rationale also stated: "Furthermore,
      it is unlikely that many new types of multi-point links will be
      introduced in the foreseeable future."  Since this was written,
      considerable effort has been expended in new multi-point links,
      including Switched Multimegabit Data Service, Frame Relay, and
      Asynchronous Transfer Mode.  However, it is clear that these are
      considerably more complex than ISPPP.






Perkins                                                        [Page 13]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


3.6 Half-Duplex or Simplex Links

   Support for half-duplex or simplex links is not required.  These
   types of links are not in common use in the current Internet.  Half-
   duplex links require some method of turning the line around.  The
   ISPPP need not have an explicit mechanism for handling line turn-
   around.  Such support might possibly be added in the future via the
   required extension mechanism.

3.7  7-bit Asynchronous RS-232 Links

   The use of asynchronous RS-232 need not support 7-bit links.  8-bit
   links are predominant in the Internet environment and supporting 7-
   bit links introduces unnecessary complexity.

4.  Prior Work On PPP Protocols

   This section reviews a number of existing point-to-point and data
   link layer protocols and points out which of our requirements are not
   satisfied.

4.1 Internet Protocols

4.1.1 RFC 891 - DCN Local-Network Protocols, Appendix A

   In Appendix A of RFC 891, "DCN Local-Network Protocols" [4], D.L.
   Mills describes the data link layer packet formats used by the
   Fuzzball system for asynchronous, character-oriented synchronous,
   DDCMP, HDLC, ARPANET 1822, X.25 LAPB and ethernet links.  These
   protocols meet the stated requirements for simplicity, transparency,
   packet framing and efficiency, but fall short of many of the others.
   Most of these protocols assume the use of the IP protocol, and do not
   include any type of protocol demultiplexing field.  No error
   detection mechanism is provided except when necessary to comply with
   another standard such as ethernet.  RFC 891 does not mention the MTU
   used for any of these links.  Other requirements such as loopback
   detection and misconfiguration detection are not discussed.  Finally,
   no option negotiation scheme is defined; without a protocol
   demultiplexing field it would be difficult or impossible to include
   one.

4.1.2 RFC 914 - Thinwire Protocols

   RFC 914, "Thinwire Protocols" [5], discusses the use of low speed
   links in the Internet.  This document places its main emphasis on
   decreasing round-trip delay and increasing link efficiency with the
   help of header compression (vs. data compression) techniques.  Three
   "Thinwire" protocols are discussed, Thinwire I, Thinwire II and



Perkins                                                        [Page 14]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


   Thinwire III.  The latter two protocols require the use of a reliable
   data link layer protocol; one such protocol, "SLIP" (not to be
   confused with Rick Adams' SLIP), is proposed in Appendix D of the
   RFC.  As proposed, "SLIP" does not meet many of the stated
   requirements.  Although not terribly complex, as a reliable, error
   detecting and correcting protocol, it is not "simple".  The 32 octet
   packet size makes it inefficient for large or uncompressed packets,
   requiring complex fragmentation and reassembly.  The use of other
   than asynchronous links is not mentioned.  The entire reliable link
   layer would be redundant over LAPB links.  There is no mechanism for
   option negotiation or future extensibility.

4.1.3 RFC 916 - Reliable Asynchronous Transfer Protocol

   RFC 916 [6] presents RATP, the Reliable Asynchronous Transfer
   Protocol.  RATP provides error detection and correction, sequencing
   and flow control across a point-to-point connection.  It is directed
   towards full duplex RS-232 links although it is useful for other
   point-to-point links.  Although the author claims that RATP is not as
   complex as some other protocols, it is far from simple.  RATP solves
   many of the problems which we have labeled non-requirements and fails
   to solve many of our stated requirements.  Specifically, RATP does
   not support option negotiation and has no mechanism for future
   extensibility.  Since RFC 916 was published, no consensus has emerged
   advocating RATP.  For these reasons RATP is not recommended as the
   ISPPP.

4.1.4 RFC 935 - Reliable Link Layer Protocols

   RFC 935 [7] is a rebuttal to the protocols proposed in RFCs 914 and
   916.  J. Robinson discusses existing and widely-used national and
   international standards which meet the needs addressed by the two
   prior RFCs.  The standards reviewed include character-oriented
   asynchronous and synchronous (bisynch) protocols and bit-oriented
   synchronous protocols.  RFC 935 does not present any higher level
   issues such as option negotiation or extensibility.


4.1.5 RFC 1009 - Requirements for Internet Gateways

   Section 3 of RFC 1009, "Constituent Network Interfaces" [8], briefly
   discusses requirements for transmission of IP datagrams over a number
   of types of point-to-point links including X.25 LAPB, HDLC framed
   synchronous links, Xerox Synchronous Point-to-Point synchronous lines
   and the MIT Serial Line Framing Protocol for asynchronous lines.  RFC
   1009 merely mentions these as reasonable candidates and does not go
   into depth on any of them.  All are discussed further in this
   document.



Perkins                                                        [Page 15]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


4.1.6 RFC 1055 - Serial Line IP

   Rick Adams' Serial Line IP (SLIP) protocol [9] has become something
   of a de facto standard due to the popularity of the 4.2 and 4.3BSD
   UNIX operating systems.  SLIP is easily added to 4.2 systems and is
   included with 4.3.  Many other TCP/IP implementation have added SLIP
   implementations in order to be compatible.  Yet SLIP is not a real
   standard; the protocol was only recently published in RFC form.
   Before RFC 1055 it was specified in the SLIP source code.  SLIP does
   not meet most of the requirements set forth above.  SLIP certainly
   meets the requirement for simplicity, and also meets the requirements
   for transparency and bandwidth efficiency.  But SLIP only provides
   for sending IP packets over asynchronous serial lines.  Since it
   provides no higher level protocol field for demultiplexing, SLIP
   cannot support multiple concurrent higher level protocols.  Providing
   only a framing protocol, SLIP would be entirely redundant when used
   with a LAPB synchronous link.  SLIP includes absolutely no mechanism
   for error detection, not even parity.  Again due to its lack of a
   protocol type field, SLIP does not support any type of option
   negotiation or extensibility.

4.2 International Protocols

4.2.1 ISO 3309 - HDLC Frame Structure

   ISO 3309 [10], the HDLC frame structure, is a simple data link layer
   protocol which provides framing of packets transmitted over bit-
   oriented synchronous links.  Special flag sequences mark the
   beginning and end of frames and bit stuffing allows data containing
   flag characters to be transmitted.  A 16-bit Frame Check Sequence
   provides error detection.

   By itself, the HDLC frame structure does not meet most of the
   requirements.  HDLC does not provide protocol multiplexing, standard
   MTUs, fault detection or option negotiation.  There is no mechanism
   for future extensibility.

   Given the HDLC frame structure's wide acceptance and simplicity, it
   may be an ideal building block for the ISPPP.

4.2.2 ISO 6256 - HDLC Balanced Class of Procedures

   ISO 6256, the HDLC Balanced Class of Procedures, specifies a data
   link layer protocol which provides error correction, sequencing and
   flow control.  ISO 6256 builds on ISO 3309 and ISO 4335, HDLC
   Elements of Procedures.

   As far as meeting our requirements is concerned, ISO 6256 does not



Perkins                                                        [Page 16]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


   provide any more utility than does ISO 3309.  The capabilities that
   are provided are all considered unnecessary and overly complex.

4.2.3 CCITT X.25 and X.25 LAPB

   CCITT recommendation X.25 [11] describes a network layer protocol
   providing error-free, sequenced, flow controlled virtual circuits.
   X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335
   and 6256.  Neither X.25 LAPB or full LAPB meet any more of our
   requirements than the ISO protocols.

4.2.4 CCITT I.441 LAPD

   CCITT I.441 LAPD [12] defines the Link Access Procedure on the ISDN
   D-Channel.  The data link layer of LAPD is very similar to that of
   LAPB and fails to meet the same requirements.

4.3 Other Protocols

4.3.1 Cisco Systems point-to-point protocols

   The Cisco Systems gateway supports both asynchronous links using SLIP
   and synchronous links using either simple HDLC framing, X.25 LAPB or
   full X.25.  The HDLC framing procedure includes a four byte header.
   The first octet (address) is either 0x0F (unicast intent) or 0x8F
   (multicast intent).  The second octet (control byte) is left zero and
   is not checked on reception.  The third and fourth octets contain a
   standard 16 bit Ethernet protocol type code.

   A "keepalive" or "beaconing" protocol is used to ensure the two-way
   connectivity of the serial line.  Each end of the link periodically
   sends two 32 bit sequence numbers to the other side.  One sequence
   number is the local side's sequence number, the other is the sequence
   number received from the other side.  Hearing the local sequence
   number from the other side indicates that the link is working in both
   directions.

   The keepalive protocol is extensible.  One extension is used to
   default IP addresses on serial lines of systems without non-volatile
   memory.  A request for address is sent to the remote side.  The
   remote side responds with its own IP address and a subnet mask.  When
   the querying side receives the reply, it checks if the host portion
   of the remote address is either 1 or 2.  If so, the opposite address
   is chosen for the local address.  If not, the protocol cannot be used
   and we must rely on other address resolution means.  This protocol
   assumes that each serial link uses one subnet or network number.

   LAPB assuming IP is another possible encapsulation.  A multi-protocol



Perkins                                                        [Page 17]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


   extension of LAPB (multi-LAPB) includes a 16 bit Ethernet type code
   after the address and control bytes and in front of the actual
   protocol data.  DDN X.25 and Commercial X.25 encapsulations are also
   supported.  Multiple protocols are supported by making protocol
   dependent CALL REQUEST's.

4.3.2 MIT PC/IP framing protocol

   The MIT PC/IP framing protocol [13] provides a mechanism for the
   transmission of IP datagrams over asynchronous links.  The low-level
   protocol (LLP) sublayer provides encapsulation while the local net
   protocol provides multiplexing of IP datagrams and IP address request
   packets.  The protocol only allows host-to-gateway connections.
   Host-to-gateway flow control is provided by requiring the host to
   transmit request packets to the gateway until an acknowledgment is
   received.  Rudimentary IP address negotiation requires the host to
   ascertain its IP address from the gateway.

   The protocol does not implement error detection, connection status
   determination, fault detection or option negotiation.  Only
   asynchronous links are supported.

4.3.3 Proteon p4200 point-to-point protocol

   The Proteon p4200 multi-protocol router supports transmission of
   packets over bit-oriented synchronous links with a wide range of
   speeds (zero to 2 Mb/sec).  The p4200 point-to-point protocol
   encapsulates packets inside HDLC frames but does not use the HDLC
   address or control fields; these two octets are instead used for a
   16-bit type field.  The p4200 does use the HDLC frame check sequence
   trailer.  Protocol type numbers are ad hoc and do not correspond to
   any existing standard.  A simple liveness protocol detects dead
   connections.

   Although the Proteon protocol does meet many of our requirements, it
   does not meet our requirements for option negotiation.

4.3.4 Ungermann Bass point-to-point protocol

   The Ungermann Bass router supports synchronous links using simple
   HDLC framing.  Neither the HDLC address or control field are used, IP
   datagrams are placed immediately after the HDLC flag.

   The U-B protocol does not meet any of our requirements for fault
   detection or option negotiation.  No mechanism for future
   extensibility is currently defined.





Perkins                                                        [Page 18]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


4.3.5 Wellfleet point-to-point protocol

   The Wellfleet router supports synchronous links using simple HDLC
   framing.  The HDLC framing procedure uses the HDLC address and places
   the Unnumbered Information (UI) command in all frames.  A simple
   header following the UI command provides a two octet type field using
   the same values as Ethernet.

   The Wellfleet protocol does not meet any of our requirements for
   fault detection or option negotiation.  No mechanism for future
   extensibility is currently defined, although one could be added.

4.3.6 XNS Synchronous Point-to-Point Protocol

   The Xerox Network Systems Synchronous Point-to-Point protocol (XNS
   PPP) [14] was designed to address most of the same issues that an
   ISPPP must address.  In particular, it addresses the issues of
   simplicity, transparency, efficiency, packet framing, protocol
   multiplexing, error detection, standard MTUs, symmetry, switched and
   non-switched media, connection status, network address negotiation
   and future extensibility.  However, the XNS SPPP does not meet our
   requirements for multiple data link layer protocols, fault detection
   and data compression negotiation.  Although protocol multiplexing is
   provided, the packet type field has only 8 bits which is too few.



























Perkins                                                        [Page 19]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


References

   [1]  Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
        Sciences Institute, September 1981.

   [2]  Postel, J., "User Datagram Protocol", STD 6, RFC768, USC/Information
        Sciences Institute, August 1980.

   [3]  Electronic Industries Association, EIA Standard RS-232-C,
        "Interface Between Data Terminal Equipment and Data
        Communications Equipment Employing Serial Binary Data
        Interchange", August 1969.

   [4]  Mills, D. L., "DCN Local-Network Protocols", STD 44, RFC 891,
        University of Delaware, December 1983.

   [5]  Farber, David J., Delp, Gary S., and Conte, Thomas M., "A
        Thinwire Protocol for Connecting Personal Computers to the
        Internet", RFC 914, University of Delaware, September 1984.

   [6]  Finn, G., "Reliable Asynchronous Transfer Protocol (RATP)",
        RFC 916, USC/Information Sciences Institute, October 1984.

   [7]  Robinson, J., "Reliable Link Layer Protocols", RFC 935, BBN,
        January 1985.

   [8]  Braden, R., and J. Postel, "Requirements for Internet
        Gateways", STD 4, RFC1009, USC/Information Sciences Institute,
        June 1987.

   [9]  Romkey, J., "A Nonstandard for the Transmission of IP Datagrams
        Over Serial Lines: SLIP", STD 47, RFC 1055, June 1988.  STD
        4, RFC 1009, June 1987.

   [10] ISO International Standard (IS) 3309, "Data Communications -
        High-level Data Link Control Procedures - Frame Structure",
        1979.

   [11] CCITT Recommendation X.25, "Interface Between Data Terminal
        Equipment (DTE) and Data Circuit Terminating Equipment (DCE)
        for Terminals Operating in the Packet Mode on Public Data
        Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.

   [12] CCITT Recommendation Q.921 "ISDN User-Network Interface Data
        Link Layer Specification".






Perkins                                                        [Page 20]

RFC 1547          Point-to-Point Protocol Requirements     December 1993


   [13] Romkey, J.L., "PC/IP Programmer's Manual", Massachussetts
        Institute of Technology Laboratory for Computer Science,
        January 1986.

   [14] Xerox Corporation, "Synchronous Point-to-Point Protocol", Xerox
        System Integration Standard, Stamford, Connecticut, XSIS
        158412, December 1984.

   [15] "Digital Data Communications Message Protocol", Digital
        Equipment Corporation.

Security Consideration

   Security issues are not discussed in this memo.

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:

      Drew Perkins
      4015 Holiday Park Drive
      Murrysville, PA  15668

      EMail: perkins+@cmu.edu

Editor's Address

   Typographic revision and historical notes by:

      William Allen Simpson
      1384 Fontaine
      Madison Heights, Michigan  48071

      EMail: Bill.Simpson@um.cc.umich.edu






Perkins                                                        [Page 21]