rfc1548.txt

<VC++网络游戏建摸与实现>源代码

           0031            Bridging PDU
           0033            Stream Protocol (ST-II)
           0035            Banyan Vines
           0037            unused
           0039            AppleTalk EDDP
           003b            AppleTalk SmartBuffered
           003d            Multi-Link
           005d            reserved (compression inefficient)
           00cf            reserved (PPP NLPID)
           00fd            1st choice compression
           00ff            reserved (compression inefficient)

           0201            802.1d Hello Packets
           0203            IBM Source Routing BPDU
           0231            Luxcom
           0233            Sigma Network Systems

           8021            Internet Protocol Control Protocol
           8023            OSI Network Layer Control Protocol
           8025            Xerox NS IDP Control Protocol
           8027            DECnet Phase IV Control Protocol
           8029            Appletalk Control Protocol
           802b            Novell IPX Control Protocol
           802d            Reserved
           802f            Reserved
           8031            Bridging NCP
           8033            Stream Protocol Control Protocol
           8035            Banyan Vines Control Protocol
           8037            unused
           8039            Reserved
           803b            Reserved
           803d            Multi-Link Control Protocol
           80fd            Compression Control Protocol
           80ff            Reserved

           c021            Link Control Protocol
           c023            Password Authentication Protocol
           c025            Link Quality Report
           c223            Challenge Handshake Authentication Protocol

      Developers of new protocols MUST obtain a number from the Internet
      Assigned Numbers Authority (IANA), at [e-mail].

    Information Field

      The Information field is zero or more octets.  The Information
      field contains the datagram for the protocol specified in the
      Protocol field.



Simpson                                                         [Page 7]

RFC 1548              The Point-to-Point Protocol          December 1993


      The maximum length for the Information field, including Padding,
      is termed the Maximum Receive Unit (MRU), which defaults to 1500
      octets.  By negotiation, consenting PPP implementations may use
      other values for the MRU.

    Padding

      On transmission, the Information field MAY be padded with an
      arbitrary number of octets up to the MRU.  It is the
      responsibility of each protocol to distinguish padding octets from
      real information.

3.  PPP Link Operation

3.1 Overview

   In order to establish communications over a point-to-point link, each
   end of the PPP link MUST first send LCP packets to configure and test
   the data link.  After the link has been established, the peer MAY be
   authenticated.  Then, PPP MUST 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 (an inactivity timer expires or network administrator
   intervention).

3.2 Phase Diagram

   In the process of configuring, maintaining and terminating the
   point-to-point link, the PPP link goes through several distinct
   phases:

   +------+        +-----------+           +--------------+
   |      | UP     |           | OPENED    |              | SUCCESS/NONE
   | Dead |------->| Establish |---------->| Authenticate |--+
   |      |        |           |           |              |  |
   +------+        +-----------+           +--------------+  |
      ^          FAIL |                   FAIL |             |
      +<--------------+             +----------+             |
      |                             |                        |
      |            +-----------+    |           +---------+  |
      |       DOWN |           |    |   CLOSING |         |  |
      +------------| Terminate |<---+<----------| Network |<-+
                   |           |                |         |
                   +-----------+                +---------+



Simpson                                                         [Page 8]

RFC 1548              The Point-to-Point Protocol          December 1993


3.3 Link Dead (physical-layer not ready)

   The link necessarily begins and ends with this phase.  When an
   external event (such as carrier detection or network administrator
   configuration) indicates that the physical-layer is ready to be used,
   PPP will proceed to the Link Establishment phase.

   During this phase, the LCP automaton (described below) will be in the
   Initial or Starting states.  The transition to the Link Establishment
   phase will signal an Up event to the automaton.

    Implementation Note:

      Typically, a link will return to this phase automatically after
      the disconnection of a modem.  In the case of a hard-wired line,
      this phase may be extremely short -- merely long enough to detect
      the presence of the device.

3.4 Link Establishment Phase

   The Link Control Protocol (LCP) is used to establish the connection
   through an exchange of Configure packets.  This exchange is complete,
   and the LCP Opened state entered, once a Configure-Ack packet
   (described below) has been both sent and received.

   All Configuration Options are assumed to be at default values unless
   altered by the configuration exchange.  See the section on LCP
   Configuration Options for further discussion.

   It is important to note that only Configuration Options which are
   independent of particular network-layer protocols are configured by
   LCP.  Configuration of individual network-layer protocols is handled
   by separate Network Control Protocols (NCPs) during the Network-Layer
   Protocol phase.

   Any non-LCP packets received during this phase MUST be silently
   discarded.

3.5 Authentication Phase

   On some links it may be desirable to require a peer to authenticate
   itself before allowing network-layer protocol packets to be
   exchanged.

   By default, authentication is not mandatory.  If an implementation
   desires that the peer authenticate with some specific authentication
   protocol, then it MUST negotiate the use of that authentication
   protocol during Link Establishment phase.



Simpson                                                         [Page 9]

RFC 1548              The Point-to-Point Protocol          December 1993


   Authentication SHOULD take place as soon as possible after link
   establishment.  However, link quality determination MAY occur
   concurrently.  An implementation MUST NOT allow the exchange of link
   quality determination packets to delay authentication indefinitely.

   Advancement from the Authentication phase to the Network-Layer
   Protocol phase MUST NOT occur until authentication has completed,
   using the negotiated authentication protocol.  If authentication
   fails, PPP SHOULD proceed instead to the Link Termination phase.

   Any Network Control Protocol or network-layer protocol packets
   received during this phase MUST be silently discarded.

3.6 Network-Layer Protocol Phase

   Once PPP has finished the previous phases, each network-layer
   protocol (such as IP, IPX, or AppleTalk) MUST be separately
   configured by the appropriate Network Control Protocol (NCP).

   Each NCP MAY be Opened and Closed at any time.

    Implementation Note:

      Because an implementation may initially use a significant amount
      of time for link quality determination, implementations SHOULD
      avoid fixed timeouts when waiting for their peers to configure a
      NCP.

      After a NCP has reached the Opened state, PPP will carry the
      corresponding network-layer protocol packets.  Any network-layer
      protocol packets received when the corresponding NCP is not in the
      Opened state MUST be silently discarded.

    Implementation Note:

      There is an exception to the preceding paragraphs, due to the
      availability of the LCP Protocol-Reject (described below).  While
      LCP is in the Opened state, any protocol packet which is
      unsupported by the implementation MUST be returned in a Protocol-
      Reject.  Only protocols which are supported are silently
      discarded.

      During this phase, link traffic consists of any possible
      combination of LCP, NCP, and network-layer protocol packets.

3.7 Link Termination Phase

   PPP can terminate the link at any time.  This might happen because of



Simpson                                                        [Page 10]

RFC 1548              The Point-to-Point Protocol          December 1993


   the loss of carrier, authentication failure, link quality failure,
   the expiration of an idle-period timer, or the administrative closing
   of the link.  LCP is used to close the link through an exchange of
   Terminate packets.  When the link is closing, PPP informs the
   network-layer protocols so that they may take appropriate action.

   After the exchange of Terminate packets, the implementation SHOULD
   signal the physical-layer to disconnect in order to enforce the
   termination of the link, particularly in the case of an
   authentication failure.  The sender of the Terminate-Request SHOULD
   disconnect after receiving a Terminate-Ack, or after the Restart
   counter expires.  The receiver of a Terminate-Request SHOULD wait for
   the peer to disconnect, and MUST NOT disconnect until at least one
   Restart time has passed after sending a Terminate-Ack.  PPP SHOULD
   proceed to the Link Dead phase.

   Any non-LCP packets received during this phase MUST be silently
   discarded.

    Implementation Note:

      The closing of the link by LCP is sufficient.  There is no need
      for each NCP to send a flurry of Terminate packets.  Conversely,
      the fact that one NCP has Closed is not sufficient reason to cause
      the termination of the PPP link, even if that NCP was the only NCP
      currently in the Opened state.

4. The Option Negotiation Automaton

   The finite-state automaton is defined by events, actions and state
   transitions.  Events include reception of external commands such as
   Open and Close, expiration of the Restart timer, and reception of
   packets from a peer.  Actions include the starting of the Restart
   timer and transmission of packets to the peer.

   Some types of packets -- Configure-Naks and Configure-Rejects, or
   Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and
   Discard-Requests -- are not differentiated in the automaton
   descriptions.  As will be described later, these packets do indeed
   serve different functions.  However, they always cause the same
   transitions.

Events                                  Actions

Up   = lower layer is Up                tlu = This-Layer-Up
Down = lower layer is Down              tld = This-Layer-Down
Open = administrative Open              tls = This-Layer-Started
Close= administrative Close             tlf = This-Layer-Finished



Simpson                                                        [Page 11]

RFC 1548              The Point-to-Point Protocol          December 1993


TO+  = Timeout with counter > 0         irc = Initialize-Restart-Counter
TO-  = Timeout with counter expired     zrc = Zero-Restart-Counter

RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request
RCR- = Receive-Configure-Request (Bad)
RCA  = Receive-Configure-Ack            sca = Send-Configure-Ack
RCN  = Receive-Configure-Nak/Rej        scn = Send-Configure-Nak/Rej

RTR  = Receive-Terminate-Request        str = Send-Terminate-Request
RTA  = Receive-Terminate-Ack            sta = Send-Terminate-Ack

RUC  = Receive-Unknown-Code             scj = Send-Code-Reject
RXJ+ = Receive-Code-Reject (permitted)
    or Receive-Protocol-Reject
RXJ- = Receive-Code-Reject (catastrophic)
    or Receive-Protocol-Reject
RXR  = Receive-Echo-Request             ser = Send-Echo-Reply
    or Receive-Echo-Reply
    or Receive-Discard-Request

4.1 State Diagram

   The simplified state diagram which follows describes the sequence of
   events for reaching agreement on Configuration Options (opening the
   PPP link) and for later termination of the link.

   This diagram is not a complete representation of the automaton.
   Implementation MUST be done by consulting the actual state transition
   table.

   Events are in upper case.  Actions are in lower case.  For these
   purposes, the state machine is initially in the Closed state.  Once
   the Opened state has been reached, both ends of the link have met the
   requirement of having both sent and received a Configure-Ack packet.

















Simpson                                                        [Page 12]

RFC 1548              The Point-to-Point Protocol          December 1993


                 RCR                    TO+
               +--sta-->+             +------->+