rfc1547.txt

RFC 的详细文档！

    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