rfc1638.txt

RFC 的详细文档！


RFC 1638                      PPP Bridging                     June 1994


      The MAC Type of the frame determines the contents of the Frame
      Control field.  A pad octet is present to provide 32-bit packet
      alignment.

   Destination MAC Address

      As defined by the IEEE.  The MAC Type field defines the bit
      ordering.

   Source MAC Address

      As defined by the IEEE.  The MAC Type field defines the bit
      ordering.

   LLC data

      This is the remainder of the MAC frame which is (or would be were
      it present) protected by the LAN FCS.

      For example, the 802.5 Access Control field, and Status Trailer
      are not meaningful to transmit to another ring, and are omitted.

   LAN FCS

      If present, this is the LAN FCS which was calculated by (or which
      appears to have been calculated by) the originating station.  If
      the LAN FCS flag is not set, then this field is not present, and
      the PDU is four octets shorter.

   Optional Data Link Layer Padding

      Any PPP frame may have padding inserted between the Information
      field and the Frame FCS.  The Pads field contains the length of
      this padding, which may not exceed 15 octets.

      The PPP LCP Extensions [5] specify a self-describing pad.
      Implementations are encouraged to set the Pads field to zero, and
      use the self-describing pad instead.

   Frame FCS

      Mentioned primarily for clarity.  The FCS used on the PPP link is
      separate from and unrelated to the LAN FCS.








Baker & Bowen                                                  [Page 15]

RFC 1638                      PPP Bridging                     June 1994


4.3.  Spanning Tree Bridge PDU

   This is the Spanning Tree BPDU, without any MAC or 802.2 LLC header
   (these being functionally equivalent to the Address, Control, and PPP
   Protocol Fields).  The LAN Pad and Frame Checksum fields are likewise
   superfluous and absent.

   The Address and Control Fields are subject to LCP Address-and-
   Control-Field-Compression negotiation.

   A PPP system which is configured to participate in a particular
   spanning tree protocol and receives a BPDU of a different spanning
   tree protocol SHOULD reject it with the LCP Protocol-Reject.  A
   system which is configured not to participate in any spanning tree
   protocol MUST silently discard all BPDUs.

   Spanning Tree Bridge PDU

    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
   +-+-+-+-+-+-+-+-+
   |   HDLC FLAG   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Address and Control      |     Spanning Tree Protocol    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              BPDU data       ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Frame FCS            |   HDLC FLAG   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Address and Control

      As defined by the framing in use.

   Spanning Tree Protocol

      Up-to-date values of the Spanning-Tree-Protocol field are
      specified in the most recent "Assigned Numbers" RFC [4].  Current
      values are assigned as follows:

         Value (in hex)  Protocol

         0201            IEEE 802.1 (either 802.1D or 802.1G)
         0203            IBM Source Route Bridge
         0205            DEC LANbridge 100

      The two versions of the IEEE 802.1 spanning tree protocol frames
      can be distinguished by fields within the BPDU data.



Baker & Bowen                                                  [Page 16]

RFC 1638                      PPP Bridging                     June 1994


   BPDU data

      As defined by the specified Spanning Tree Protocol.

5.  BCP Configuration Options

   BCP Configuration Options allow modifications to the standard
   characteristics of the network-layer protocol to be negotiated.  If a
   Configuration Option is not included in a Configure-Request packet,
   the default value for that Configuration Option is assumed.

   BCP uses the same Configuration Option format defined for LCP [6],
   with a separate set of Options.

   Up-to-date values of the BCP Option Type field are specified in the
   most recent "Assigned Numbers" RFC [4].  Current values are assigned
   as follows:


         1       Bridge-Identification
         2       Line-Identification
         3       MAC-Support
         4       Tinygram-Compression
         5       LAN-Identification
         6       MAC-Address
         7       Spanning-Tree-Protocol

5.1.  Bridge-Identification

   Description

      The Bridge-Identification Configuration Option is designed for use
      when the line is an interface between half bridges connecting
      virtual or physical LAN segments.  Since these remote bridges are
      modeled as a single bridge with a strange internal interface, each
      remote bridge needs to know the LAN segment and bridge numbers of
      the adjacent remote bridge.  This option MUST NOT be included in
      the same Configure-Request as the Line-Identification option.

      The Source Routing Route Descriptor and its use are specified by
      the IEEE 802.1D Appendix on Source Routing.  It identifies the
      segment to which the interface is attached by its configured
      segment number, and itself by bridge number on the segment.

      The two half bridges MUST agree on the bridge number.  If a bridge
      number is not agreed upon, the Bridging Control Protocol MUST NOT
      enter the Opened state.




Baker & Bowen                                                  [Page 17]

RFC 1638                      PPP Bridging                     June 1994


      Since mismatched bridge numbers are indicative of a configuration
      error, it is strongly recommended that a system not change its
      bridge number for the purpose of resolving a mismatch.  However,
      to allow two systems to proceed to the Opened state despite a
      mismatch, a system MAY change its bridge number to the higher of
      the two numbers.  A higher-numbered system MUST NOT change its
      bridge number to a lower number.

      By default, a system that does not negotiate this option is
      assumed to be configured not to use the model of the two systems
      as two halves of a single source-route bridge.  It is instead
      assumed to be configured to use the model of the two systems as
      two independent bridges.

   Example

      If System A announces LAN Segment AAA, Bridge #1, and System B
      announces LAN Segment BBB, Bridge #1, then the resulting Source
      Routing configuration (read in the appropriate direction) is then
      AAA,1,BBB.

   A summary of the Bridge-Identification 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     | LAN Segment Number    |Bridge#|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      1

   Length

      4

   LAN Segment Number

      A 12-bit number identifying the LAN segment, as defined in the
      IEEE 802.1D Source Routing Specification.

   Bridge Number

      A 4-bit number identifying the bridge on the LAN segment, as
      defined in the IEEE 802.1D Source Routing Specification.



Baker & Bowen                                                  [Page 18]

RFC 1638                      PPP Bridging                     June 1994


5.2.  Line-Identification

   Description

      The Line-Identification Configuration Option is designed for use
      when the line is assigned a LAN segment number as though it were a
      two system LAN segment in accordance with the Source Routing
      algorithm.  This option MUST NOT be included in the same
      Configure-Request as the Bridge-Identification option.

      The Source Routing Route Descriptor and its use are specified by
      the IEEE 802.1D Appendix on Source Routing.  It identifies the
      segment to which the interface is attached by its configured
      segment number, and itself by bridge number on the segment.

      The two bridges MUST agree on the LAN segment number.  If a LAN
      segment number is not agreed upon, the Bridging Control Protocol
      MUST NOT enter the Opened state.

      Since mismatched LAN segment numbers are indicative of a
      configuration error, it is strongly recommended that a system not
      change its LAN segment number for the purpose of resolving a
      mismatch.  However, to allow two systems to proceed to the Opened
      state despite a mismatch, a system MAY change its LAN segment
      number to the higher of the two numbers.  A higher-numbered system
      MUST NOT change its LAN segment number to a lower number.

      By default, a system that does not negotiate this option is
      assumed to have its LAN segment number correctly configured by the
      user.

   A summary of the Line-Identification 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     | LAN Segment Number    |Bridge#|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      2

   Length

      4



Baker & Bowen                                                  [Page 19]

RFC 1638                      PPP Bridging                     June 1994


   LAN Segment Number

      A 12-bit number identifying the LAN segment, as defined in the
      IEEE 802.1D Source Routing Specification.

   Bridge Number

      A 4-bit number identifying the bridge on the LAN segment, as
      defined in the IEEE 802.1D Source Routing Specification.

5.3.  MAC-Support

   Description

      The MAC-Support Configuration Option is provided to permit
      implementations to indicate the sort of traffic they are prepared
      to receive.  Negotiation of this option is strongly recommended.

      By default, when an implementation does not announce the MAC Types
      that it supports, all MAC Types are sent by the peer which are
      capable of being transported given other configuration parameters.
      The receiver will discard those MAC Types that it does not
      support.

      A device supporting a 1600 octet MRU might not be willing to
      support 802.5, 802.4 or FDDI, which each support frames larger
      than 1600 octets.

      By announcing the MAC Types it will support, an implementation is
      advising its peer that all unspecified MAC Types will be
      discarded.  The peer MAY then reduce bandwidth usage by not
      sending the unsupported MAC Types.

      Announcement of support for multiple MAC Types is accomplished by
      placing multiple options in the Configure-Request.

      The nature of this option is advisory only.  This option MUST NOT
      be included in a Configure-Nak.

   A summary of the MAC-Support 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     |    MAC Type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Baker & Bowen                                                  [Page 20]

RFC 1638                      PPP Bridging                     June 1994


   Type

      3

   Length

      3

   MAC Type

      One of the values of the PDU MAC Type field (previously described
      in the "Bridged LAN Traffic" section) that this system is prepared
      to receive and service.

5.4.  Tinygram-Compression

      Description

      This Configuration Option permits the implementation to indicate
      support for Tinygram compression.

      Not all systems are prepared to make modifications to messages in
      transit.  On high speed lines, it is probably not worth the
      effort.

      This option MUST NOT be included in a Configure-Nak if it has been
      received in a Configure-Request.  This option MAY be included in a
      Configure-Nak in order to prompt the peer to send the option in
      its next Configure-Request.

      By default, no compression is allowed.  A system which does not
      negotiate, or negotiates this option to be disabled, should never
      receive a compressed packet.

   A summary of the Tinygram-Compression 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     | Enable/Disable|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      4




Baker & Bowen                                                  [Page 21]