rfc1570.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      10      Self-Describing-Padding
      13      Callback
      15      Compound-Frames




2.1.  FCS-Alternatives

   Description

      This Configuration Option provides a method for an implementation
      to specify another FCS format to be sent by the peer, or to
      negotiate away the FCS altogether.

      This option is negotiated separately in each direction.  However,
      it is not required that an implementation be capable of
      concurrently generating a different FCS on each side of the link.

      The negotiated FCS values take effect only during Authentication
      and Network-Layer Protocol phases.  Frames sent during any other
      phase MUST contain the default FCS.

   A summary of the FCS-Alternatives Configuration Option format is
   shown below.  The fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Options    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      9





Simpson                                                         [Page 6]
RFC 1570                   PPP LCP extensions               January 1994


   Length

      3

   Options

      This field is one octet, and is comprised of the "logical or" of
      the following values:

          1   Null FCS
          2   CCITT 16-bit FCS
          4   CCITT 32-bit FCS


   Implementation Note:

      For most PPP HDLC framed links, the default FCS is the CCITT 16-
      bit FCS.  Some framing techniques and high speed links may use
      another format as the default FCS.


2.1.1.  LCP considerations

   The link can be subject to loss of state, and the LCP can re-
   negotiate at any time.  When the LCP begins renegotiation or
   termination, it is recommended that the LCP Configure-Request or
   Terminate-Request packet be sent with the last negotiated FCS, then
   change to the default FCS, and a duplicate LCP packet is sent with
   the default FCS.  The Identifier field SHOULD NOT be incremented for
   each such duplicate packet.

   On receipt of a LCP Configure-Request or Terminate-Request packet,
   the implementation MUST change to the default FCS for both
   transmission and reception.  If a Request packet is received which
   contains a duplicate Identifier field, a new reply MUST be generated.

   Implementation Notes:

      The need to send two packets is only necessary after the
      Alternative-FCS has already been negotiated.  It need not occur
      during state transitions when there is a natural indication that
      the default FCS is in effect, such as the Down and Up events.  It
      is necessary to send two packets in the Ack-Sent and Opened
      states, since the peer could mistakenly believe that the link has
      Opened.

      It is possible to send a single 48-bit FCS which is a combination
      of the 16-bit and 32-bit FCS.  This may be sent instead of sending



Simpson                                                         [Page 7]
RFC 1570                   PPP LCP extensions               January 1994


      the two packets described above.  We have not standardized this
      procedure because of intellectual property concerns.  If such a
      48-bit FCS is used, it MUST only be used for LCP packets.


2.1.2.  Null FCS

   The Null FCS SHOULD only be used for those network-layer and
   transport protocols which have an end-to-end checksum available, such
   as TCP/IP, or UDP/IP with the checksum enabled.  That is, the Null
   FCS option SHOULD be negotiated together with another non-null FCS
   option in a heterogeneous environment.

   When a configuration (LCP or NCP) or authentication packet is sent,
   the FCS MUST be included.  When a configuration (LCP or NCP) or
   authentication packet is received, the FCS MUST be verified.

   There are several cases to be considered:

   Null FCS alone

      The sender generates the FCS for those frames which require the
      FCS before sending the frame.

      When a frame is received, it is not necessary to check the FCS
      before demultiplexing.  Any FCS is treated as padding.

      Receipt of an Authentication or Control packet would be discovered
      after passing the frame to the demultiplexer.  Verification of the
      FCS can easily be accomplished using one of the software
      algorithms defined in "PPP in HDLC Framing" [3] (16-bit FCS) and
      Appendix A (32-bit FCS).

   Null FCS with another FCS, using software

      This is similar to the above case.

      Those packets which are required to have the FCS (Authentication,
      Control, or Network-Protocols lacking a checksum) are checked
      using software after demultiplexing.  Packets which fail the FCS
      test are discarded as usual.

   Null FCS with another FCS, using hardware

      A flag is passed with the frame, indicating whether or not it has
      passed the hardware FCS check.  The incorrect FCS MUST be passed
      with the rest of the data.  The frame MUST NOT be discarded until
      after demultiplexing, and only those frames that require the FCS



Simpson                                                         [Page 8]
RFC 1570                   PPP LCP extensions               January 1994


      are discarded.

   All three FCS forms (Null, 16 and 32) may be used concurrently on
   different frames when using software.  That is probably not possible
   with most current hardware.



2.2.  Self-Describing-Padding

   Description

      This Configuration Option provides a method for an implementation
      to indicate to the peer that it understands self-describing pads
      when padding is added at the end of the PPP Information field.

      This option is most likely to be used when some protocols, such as
      network-layer or compression protocols, are configured which
      require detection and removal of any trailing padding.  Such
      special protocols are identified in their respective documents.

      If the option is Rejected, the peer MUST NOT add any padding to
      the identified special protocols, but MAY add padding to other
      protocols.

      If the option is Ack'd, the peer MUST follow the procedures for
      adding self-describing pads, but only to the specifically
      identified protocols.  The peer is not required to add any padding
      to other protocols.

      Implementation Notes:

         This is defined so that the Reject handles either case where
         the peer does not generate self-describing pads.  When the peer
         never generates padding, it may safely Reject the option.  When
         the peer does not understand the option, it also will not
         successfully configure a special protocol which requires
         elimination of pads.

         While some senders might only be capable of adding padding to
         every protocol or not adding padding to any protocol, by design
         the receiver need not examine those protocols which do not need
         the padding stripped.

         To avoid unnecessary configuration handshakes, an
         implementation which generates padding, and has a protocol
         configured which requires the padding to be known, SHOULD
         include this Option in its Configure-Request, and SHOULD



Simpson                                                         [Page 9]
RFC 1570                   PPP LCP extensions               January 1994


         Configure-Nak with this Option when it is not present in the
         peer's Request.

      Each octet of self-describing pad contains the index of that
      octet.  The first pad octet MUST contain the value one (1), which
      indicates the Padding Protocol to the Compound-Frames option.
      After removing the FCS, the final pad octet indicates the number
      of pad octets to remove.  For example, three pad octets would
      contain the values 1, 2, 3.

      The Maximum-Pad-Value (MPV) is also negotiated.  Only the values 1
      through MPV are used.  When no padding would otherwise be
      required, but the final octet of the PPP Information field
      contains the value 1 through MPV, at least one self-describing pad
      octet MUST be added to the frame.  If the final octet is greater
      than MPV, no additional padding is required.

      Implementation Notes:

         If any of the pad octets contain an incorrect index value, the
         entire frame SHOULD be silently discarded.  This is intended to
         prevent confusion with the FCS-Alternatives option, but might
         not be necessary in robust implementations.

         Since this option is intended to support compression protocols,
         the Maximum-Pad-Value is specified to limit the likelihood that
         a frame may actually become longer.

   A summary of the Self-Describing-Padding Configuration Option format
   is shown below.  The fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Maximum    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      10

   Length

      3






Simpson                                                        [Page 10]
RFC 1570                   PPP LCP extensions               January 1994


   Maximum

      This field specifies the largest number of padding octets which
      may be added to the frame.  The value may range from 1 to 255, but
      values of 2, 4, or 8 are most likely.



2.3.  Callback

   Description

      This Configuration Option provides a method for an implementation
      to request a dial-up peer to call back.  This option might be used
      for many diverse purposes, such as savings on toll charges.

      When Callback is successfully negotiated, and authentication is
      complete, the Authentication phase proceeds directly to the
      Termination phase, and the link is disconnected.

      Then, the peer re-establishes the link, without negotiating
      Callback.

      Implementation Notes:

         A peer which agrees to this option SHOULD request the
         Authentication-Protocol Configuration Option.  The user
         information learned during authentication can be used to
         determine the user location, or to limit a user to certain
         locations, or merely to determine whom to bill for the service.

         Authentication SHOULD be requested in turn by the
         implementation when it is called back, if mutual authentication
         is desired.

   A summary of the Callback Option format is shown below.  The fields
   are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   Operation   |  Message ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      13



Simpson                                                        [Page 11]
RFC 1570                   PPP LCP extensions               January 1994


   Length

      >= 3

   Operation

      The Operation field is one octet and indicates the contents of the
      Message field.

      0       location is determined by user authentication

      1       Dialing string, the format and contents of which assumes
              configuration knowledge of the specific device which is
              making the callback.

      2       Location identifier, which may or may not be human
              readable, to be used together with the authentication
              information for a database lookup to determine the
              callback location.

      3       E.164 number.

      4       Distinguished name.

   Message

      The Message field is zero or more octets, and its general contents
      are determined by the Operation field.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.
      The size is determined from the Length field.

      It is intended that only an authorized user will have correct site