rfc1134.txt

改文件中包含了三个协议

Network Working Group                                         D. Perkins
Request for Comments: 1134                                           CMU
                                                           November 1989


       The Point-to-Point Protocol: A Proposal for Multi-Protocol
          Transmission of Datagrams Over Point-to-Point Links


                           Table of Contents

   Status of this Memo ...................................    2
   Abstract ..............................................    2
   1. Introduction .......................................    2
   1.1 Motivation ........................................    2
   1.2 Overview of PPP ...................................    3
   1.3 Organization of the document ......................    4
   2. Physical Layer Requirements ........................    4
   3. The Data Link Layer ................................    4
   3.1 Frame Format ......................................    5
   4. The PPP Link Control Protocol (LCP) ................    8
   4.1 The LCP Automaton .................................    9
   4.1.1 Overview ........................................    9
   4.1.2 State Diagram ...................................   10
   4.1.3 State Transition Table ..........................   12
   4.1.4 Events ..........................................   12
   4.1.5 Actions .........................................   14
   4.1.6 States ..........................................   16
   4.2 Loop Avoidance ....................................   19
   4.3 Packet Format .....................................   19
   4.3.1 Configure-Request ...............................   21
   4.3.2 Configure-Ack ...................................   21
   4.3.3 Configure-Nak ...................................   22
   4.3.4 Configure-Reject ................................   24
   4.3.5 Terminate-Request and Terminate-Ack .............   25
   4.3.6 Code-Reject .....................................   26
   4.3.7 Protocol-Reject .................................   27
   4.3.8 Echo-Request and Echo-Reply .....................   28
   4.3.9 Discard-Request .................................   29
   4.4 Configuration Options .............................   30
   4.4.1 Format ..........................................   31
   5. A PPP Network Control Protocol (NCP) for IP ........   32
   5.1 Sending IP Datagrams ..............................   33
   APPENDICES ............................................   33
   A. Asynchronous HDLC ..................................   33
   B. Fast Frame Check Sequence (FCS) Implementation .....   35
   B.1 FCS Computation Method ............................   35
   B.2 Fast FCS table generator ..........................   36



Perkins                                                         [Page 1]

RFC 1134                          PPP                      November 1989


   REFERENCES ............................................   37
   AUTHOR'S ADDRESS ......................................   38

Status of this Memo

   This memo defines a proposed protocol for the Internet community.

   This proposal is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments on this
   memo should be submitted to the IETF Point-to-Point Protocol Working
   Group chair by January 15, 1990.  Comments will be reviewed at the
   February 1990 IETF meeting, with the goal of advancing PPP to draft
   standard status.  Distribution of this memo is unlimited.

Abstract

   The Point-to-Point Protocol (PPP) provides a method for transmitting
   datagrams over serial point-to-point links.  PPP is composed of three
   parts:

      1. A method for encapsulating datagrams over serial links.

      2. An extensible Link Control Protocol (LCP).

      3. A family of Network Control Protocols (NCP) for establishing
         and configuring different network-layer protocols.

   This document defines the encapsulation scheme, the basic LCP, and an
   NCP for establishing and configuring the Internet Protocol (IP)
   (called the IP Control Protocol, IPCP).

   The options and facilities used by the LCP and the IPCP are defined
   in separate documents.  Control protocols for configuring and
   utilizing other network-layer protocols besides IP (e.g., DECNET,
   OSI) are expected to be developed as needed.

1.  Introduction

1.1.  Motivation

   In the last few years, the Internet has seen explosive growth in the
   number of hosts supporting TCP/IP.  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).  Relatively few of these hosts are connected
   with simple point-to-point (i.e., serial) links.  Yet, point-to-point
   links are among the oldest methods of data communications and almost



Perkins                                                         [Page 2]

RFC 1134                          PPP                      November 1989


   every host supports point-to-point connections.  For example,
   asynchronous RS-232-C [1] interfaces are essentially ubiquitous.

   One reason for the small number of point-to-point IP links is the
   lack of a standard encapsulation protocol.  There are plenty of non-
   standard (and at least one defacto standard) encapsulation protocols
   available, but there is not one which has been agreed upon as an
   Internet Standard.  By contrast, standard encapsulation schemes do
   exist for the transmission of datagrams over most popular LANs.

   One purpose of this memo is to remedy this problem.  But even more
   importantly, the Point-to-Point Protocol proposes more than just an
   encapsulation scheme.  Point-to-Point links tend to exacerbate many
   problems with the current family of network protocols.  For instance,
   assignment and management of IP addresses, which is a problem even in
   LAN environments, is especially difficult over switched point-to-
   point circuits (e.g., dialups).

   Some additional issues addressed by PPP include asynchronous
   (start/stop) and bit-oriented synchronous encapsulation, network
   protocol multiplexing, link configuration, link quality testing,
   error detection, and option negotiation for such capabilities as
   network-layer address negotiation and data compression negotiation.

   PPP addresses these issues by providing an extensible Link Control
   Protocol (LCP) and a family of Network Control Protocols (NCP) to
   negotiate optional configuration parameters and facilities.

1.2.  Overview of PPP

   PPP has three main components:

      1. A method for encapsulating datagrams over serial links.  PPP
         uses HDLC as a basis for encapsulating datagrams over point-
         to-point links.

      2. An extensible Link Control Protocol (LCP) to establish,
         configure, and test the data-link connection.

      3. A family of Network Control Protocols (NCP) for establishing
         and configuring different network-layer protocols.  PPP is
         designed to allow the simultaneous use of multiple network-
         layer protocols.

   In order to establish communications over a point-to-point link, the
   originating PPP would first send LCP packets to configure and test
   the data link.  After the link has been establish and optional
   facilities have been negotiated as needed by the LCP, the originating



Perkins                                                         [Page 3]

RFC 1134                          PPP                      November 1989


   PPP would send NCP packets to choose and configure one or more
   network-layer protocols.  Once each of the chosen network-layer
   protocols has been configured, datagrams from each network-layer
   protocol can be sent over the link.

   The link will remain configured for communications until explicit LCP
   or NCP packets close the link down, or until some external event
   occurs (e.g., inactivity timer expires or user intervention).

1.3.  Organization of the document

   This memo is divided into several sections.  Section 2 discusses the
   physical-layer requirements of PPP.  Section 3 describes the Data
   Link Layer including the PPP frame format and data link encapsulation
   scheme.  Section 4 specifies the LCP including the connection
   establishment and option negotiation procedures.  Section 5 specifies
   the IP Control Protocol (IPCP), which is the NCP for the Internet
   Protocol, and describes the encapsulation of IP datagrams within PPP
   packets.  Appendix A summarizes important features of asynchronous
   HDLC, and Appendix B describes an efficient table-lookup algorithm
   for fast Frame Check Sequence (FCS) computation.

2.  Physical Layer Requirements

   The Point-to-Point Protocol is capable of operating across any
   DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and
   CCITT V.35).  The only absolute requirement imposed by PPP is the
   provision of a duplex circuit, either dedicated or switched, which
   can operate in either an asynchronous (start/stop) or synchronous
   bit-serial mode, transparent to PPP Data Link Layer frames.  PPP does
   not impose any restrictions regarding transmission rate, other than
   those imposed by the particular DTE/DCE interface in use.

   PPP does not require the use of modem control signals, such as
   Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect
   (DCD), and Data Terminal Ready (DTR).  However, using such signals
   when available can allow greater functionality and performance.

3.  The Data Link Layer

   The Point-to-Point Protocol uses the principles, terminology, and
   frame structure of the International Organization For
   Standardization's (ISO) High-level Data Link Control (HDLC)
   procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1
   "Addendum 1: Start/stop transmission" [5].  ISO 3309-1979 specifies
   the HDLC frame structure for use in synchronous environments.  ISO
   3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to
   allow its use in asynchronous environments.



Perkins                                                         [Page 4]

RFC 1134                          PPP                      November 1989


   The PPP control procedures use the definitions and Control field
   encodings standardized in ISO 4335-1979 [3] and ISO 4335-
   1979/Addendum 1-1979 [4].  The PPP frame structure is also consistent
   with CCITT Recommendation X.25 LAPB [6], since that too is based on
   HDLC.

      Note: ISO 3309:1984/PDAD1 is a Proposed Draft standard.  At
      present, it seems that ISO 3309:1984/PDAD1 is stable and likely to
      become an International Standard.  Therefore, we feel comfortable
      about using it before it becomes an International Standard.  The
      progress of this proposal should be tracked and encouraged by the
      Internet community.

   The purpose of this memo is not to document what is already
   standardized in ISO 3309.  We assume that the reader is already
   familiar with HDLC, or has access to a copy of [2] or [6].  Instead,
   this paper attempts to give a concise summary and point out specific
   options and features used by PPP.  Since "Addendum 1: Start/stop
   transmission", is not yet standardized and widely available, it is
   summarized in Appendix A.

3.1.  Frame Format

   A summary of the standard PPP frame structure is shown below.  The
   fields are transmitted from left to right.

      +----------+---------+---------+----------+------------
      |   Flag   | Address | Control | Protocol | Information
      | 01111110 | 1111111 | 0000011 | 16 bits  |      *
      +----------+---------+---------+----------+------------
              ---+---------+----------+
                 |   FCS   |   Flag   |
                 | 16 bits | 01111110 |
              ---+---------+----------+

   This figure does not include start/stop bits (for asynchronous links)
   or any bits or octets inserted for transparency.  When asynchronous
   links are used, all octets are transmitted with one start bit, eight
   bits of data, and one stop bit.  There is no provision in either PPP
   or ISO 3309:1984/PDAD1 for seven bit asynchronous links.

   To remain consistent with standard Internet practice, and avoid
   confusion for people used to reading RFCs, all binary numbers in the
   following descriptions are in Most Significant Bit to Least
   Significant Bit order, reading from left to right, unless otherwise
   indicated.  Note that this is contrary to standard ISO and CCITT
   practice which orders bits as transmitted (i.e., network bit order).
   Keep this in mind when comparing this document with the international



Perkins                                                         [Page 5]

RFC 1134                          PPP                      November 1989


   standards documents.

   Flag Sequence

      The Flag Sequence is a single octet and indicates the beginning or
      end of a frame.  The Flag Sequence consists of the binary sequence
      01111110 (hexadecimal 0x7e).

   Address Field

      The Address field is a single octet and contains the binary
      sequence 11111111 (hexadecimal 0xff), the All-Stations address.
      PPP does not assign individual station addresses.  The All-
      Stations address should always be recognized and received.  Frames
      with other Addresses should be silently discarded.

   Control Field

      The Control field is a single octet and contains the binary
      sequence 00000011 (hexadecimal 0x03), the Unnumbered Information
      (UI) command with the P/F bit is set to zero.  Frames with other
      Control field values should be silently discarded.

   Protocol Field

      The Protocol field is two octets and its value identifies the
      protocol encapsulated in the Information field of the frame.  The
      most up-to-date values of the Protocol field are specified in the
      most recent "Assigned Numbers" RFC [11].  Initial values are also
      listed below.

      Protocol field values in the "cxxx" range identify datagrams as
      belonging to the Link Control Protocol (LCP) or associated
      protocols.  Values in the "8xxx" range identify datagrams belonging
      to the family of Network Control Protocols (NCP).  Values in the
      "0xxx" range identify the network protocol of specific datagrams.