rfc1172.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,758 行 · 第 1/5 页

      In the interest of simplicity, the standard PPP frame uses this
      fact and always sends Protocol fields with a two octet
      representation.  Protocol field values less than 256 (decimal) are
      prepended with a single zero octet even though transmission of
      this, the zero and most significant octet, is unnecessary.

      However, when using low speed links, it is desirable to conserve
      bandwidth by sending as little redundant data as possible.  The
      Protocol Compression Configuration Option allows a trade-off
      between implementation simplicity and bandwidth efficiency.  If
      successfully negotiated, the ISO 3309 extension mechanism may be
      used to compress the Protocol field to one octet instead of two.
      The large majority of frames are compressible since data protocols
      are typically assigned with Protocol field values less than 256.

      To guarantee unambiguous recognition of LCP packets, the Protocol
      field must never be compressed when sending any LCP packet.  In
      addition, PPP implementations must continue to be robust and MUST
      accept PPP frames with double-octet, as well as single-octet,
      Protocol fields, and MUST NOT distinguish between them.

      When a Protocol field is compressed, the Data Link Layer FCS field



Perkins & Hobby                                                [Page 11]

RFC 1172                  PPP Initial Options                  July 1990


      is calculated on the compressed frame, not the original
      uncompressed frame.

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

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

   Type

      7

   Length

      2

   Default

      Disabled.



























Perkins & Hobby                                                [Page 12]

RFC 1172                  PPP Initial Options                  July 1990


2.7.  Address-and-Control-Field-Compression

   Description

      This Configuration Option provides a way to negotiate the
      compression of the Data Link Layer Address and Control fields.  By
      default all implementations must transmit frames with Address and
      Control fields and must use the hexadecimal values 0xff and 0x03
      respectively.  Since these fields have constant values, they are
      easily compressed.  this Configuration Option may be used to
      inform the remote end that you can receive compressed Address and
      Control fields.

      Compressed Address and Control fields are formed by simply
      omitting them in all non-ambiguous cases.  Ambiguous frames may
      not be compressed.  Ambiguous cases result when the two octets
      following the Address and Control fields have values that could be
      interpreted as valid Address and Control fields (i.e., 0xff,
      0x03).  This can happen when Protocol-Field-Compression is enabled
      and the Protocol field is compressed to one octet.  If the
      Protocol value is 0xff, and the first octet of the Information
      field is 0x03, the result is ambiguous and the Address and Control
      fields must not be compressed on transmission.

      On reception, the Address and Control fields are decompressed by
      examining the first two octets.  If they contain the values 0xff
      and 0x03, they are assumed to be the Address and Control fields.
      If not, it is assumed that the fields were compressed and were not
      transmitted.

      One additional case in which the Address and Control fields must
      never be compressed is when sending any LCP packet.  This rule
      guarantees unambiguous recognition of LCP packets.

      When the Address and Control fields are compressed, the Data Link
      Layer FCS field is calculated on the compressed frame, not the
      original uncompressed frame.

   A summary of the Address-and-Control-Field-Compression configuration
   option format is shown below.  The fields are transmitted from left
   to right.

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




Perkins & Hobby                                                [Page 13]

RFC 1172                  PPP Initial Options                  July 1990


   Type

      8

   Length

      2

   Default

      Not compressed.








































Perkins & Hobby                                                [Page 14]

RFC 1172                  PPP Initial Options                  July 1990


3.  Link Quality Monitoring

   Data communications links are rarely perfect. Packets can be dropped
   or corrupted for various reasons (line noise, equipment failure,
   buffer overruns, etc.).  Sometimes, it is desirable to determine
   when, and how often, the link is dropping data.  Routers, for
   example, may want to temporarily allow another route to take
   precedence.  An implementation may also have the option of
   disconnecting and switching to an alternate link.  The process of
   determining data loss is called "Link Quality Monitoring".

3.1.  Design Motivation

   There are many different ways to measure link quality, and even more
   ways to react to it.  Rather than specifying a single scheme, Link
   Quality Monitoring is divided into a "mechanism" and a "policy".  PPP
   fully specifies the "mechanism" for Link Quality Monitoring by
   defining the LCP Link-Quality-Report (LQR) packet and specifying a
   procedure for its use.  PPP does NOT specify a Link Quality
   Monitoring "policy" -- how to judge link quality or what to do when
   it is inadequate.  That is left as an implementation decision, and
   can be different at each end of the link.  Implementations are
   allowed, and even encouraged, to experiment with various link quality
   policies.  The Link Quality Monitoring mechanism specification
   insures that two implementations with different policies may
   communicate and interoperate.

   To allow flexible policies to be implemented, the PPP Link Quality
   Monitoring mechanism measures data loss in units of packets, octets,
   and Link-Quality-Reports.  Each measurement is made separately for
   each half of the link, both inbound and outbound.  All measurements
   are communicated to both ends of the link so that each end of the
   link can implement its own link quality policy for both its outbound
   and inbound links.

   Finally, the Link Quality Monitoring protocol is designed to be
   implementable on many different kinds of systems. Although it may be
   common to implement PPP (and especially Link Quality Monitoring) as a
   single software process, multi-process implementations with hardware
   support are also envisioned. The PPP Link Quality Monitoring
   mechanism provides for this by careful definition of the Link-
   Quality-Report packet format, and by specifiying reference points for
   all data transmission and reception measurements.

3.2.  Design Overview

   Each Link Quality Monitoring implementation maintains counts of the
   number of packets and octets transmitted and successfully received,



Perkins & Hobby                                                [Page 15]

RFC 1172                  PPP Initial Options                  July 1990


   and periodically transmits this information to its peer in a Link-
   Quality-Report packet.  These packets contain three sections: a
   Header section, a Counters section, and a Measurements section.

   The Header section of the packet consists of the normal LCP Link
   Maintenance packet header including Code, Identifier, Length and
   Magic-Number fields.

   The Counters section of the packet consists of four counters, and
   provides the information necessary to measure the quality of the
   link.  The LQR transmitter fills in two of these counters: Out-Tx-
   Packets-Ctr and Out-Tx-Octets-Ctr (described later).  The LQR
   receiver fills in the two remaining counters: In-Rx-Packets-Ctr and
   In-Rx-Octets-Ctr (described later).  These counters are similar to
   sequence numbers; they are constantly increasing to give a "relative"
   indication of the number of packets and octets communicated across
   the outbound link.  By comparing the values in successive Link-
   Quality-Reports, an LQR receiver can compute the "absolute" number of
   packets and octets communicated across its inbound link. Comparing
   these absolute numbers then gives an indication of an inbound link's
   quality.  Relative numbers, rather than absolute, are transmitted
   because they greatly simplify link synchronization; an implementation
   merely waits to receive two LQR packets.

   The Measurements section of the packet consists of six state
   variables: In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In-
   Rx-Packets, and In-Rx-Octets (described later).  This section allows
   an implementation to report inbound link quality measurements to its
   peer (for which the report will instead indicate outbound link
   quality) by transmitting the absolute, rather than relative, number
   of LQRs, packets, and octets communicated across the inbound link.
   These values are calculated by observing the Counters section of the
   Link-Quality-Report packets received on the inbound link.  Absolute
   numbers may be used in this section without synchronization problems
   because it is necessary to receive only one LQR packet to have valid
   information.

   Link Quality Monitoring is described in more detail in the following
   sections.  First, a description of the processes comprising the Link
   Quality Monitoring mechanism is presented.  This is followed by the
   packet and byte counters maintained; the measurements, calculations,
   and state variables used; the format of the Link-Quality-Report
   packet; some policy suggestions; and, finally, an example link
   quality calculation.

3.3.  Processes

   The PPP Link Quality Monitoring mechanism is described using a



Perkins & Hobby                                                [Page 16]

RFC 1172                  PPP Initial Options                  July 1990


   "logical process" model. As shown below, there are five logical
   processes duplicated at each end of the duplex link.

   +---------+   +-------+   +----+ Outbound
   |         |-->|  Mux  |-->| Tx |=========>
   | Link-   |   +-------+   +----+
   | Manager |
   |         |   +-------+   +----+ Inbound
   |         |<--| Demux |<--| Rx |<=========
   +---------+   +-------+   +----+

   Link-Manager

      The Link-Manager process transmits and receives Link-Quality-
      Reports, and implements the desired link quality policy.  LQR
      packets are transmitted at a constant rate, which is negotiated by
      the LCP Link-Quality-Monitoring Configuration Option.  The Link-
      Manager process fills in only the Header and Measurements sections
      of the packet; the Counters section of the packet is filled in by
      the Tx and Rx processes.

   Mux

      The Mux process multiplexes packets from the various protocols
      (e.g., LCP, IP, XNS, etc.) into a single, sequential, and
      prioritized stream of packets.  Link-Quality-Report packets MUST
      be given the highest possible priority to insure that link quality
      information is communicated in a timely manner.

   Tx

      The Tx process maintains the counters Out-Tx-Packets-Ctr and Out-
      Tx-Octets-Ctr which are used to measure the amount of data which
      is transmitted on the outbound link.  When Tx processes a Link-
      Quality-Report packet, it inserts the values of these counters
      into the Counters section of the packet.  Because these counters
      represent relative, rather than absolute, values, the question of
      when to update the counters, before or after they are inserted
      into a Link-Quality-Report packet, is left as an implementation
      decision. However, an implementation MUST make this decision the
      same way every time.  The Tx process MUST follow the Mux process
      so that packets are counted in the order transmitted to the link.