rfc1547.txt

RFC 的详细文档！

   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.