rfc1547.txt

中、英文RFC文档大全打包下载完全版 .

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: [e-mail]

Author's Address

   Questions about this memo can also be directed to:

      Drew Perkins
      4015 Holiday Park Drive
      Murrysville, PA  15668

      EMail: [e-mail]

Editor's Address

   Typographic revision and historical notes by:

      William Allen Simpson
      1384 Fontaine
      Madison Heights, Michigan  48071

      EMail: [e-mail]






Perkins                                                        [Page 21]