rfc2878.txt

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

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              optional Data Link Layer padding                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Frame FCS            |   HDLC FLAG   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Address and Control

      As defined by the framing in use.

   PPP Protocol

      0x0031 for PPP Bridging

   Flags

      bit F:  Set if the LAN FCS Field is present
      bit Z:  Set if IEEE 802.3 Pad must be zero filled to minimum size
      bit 0:  reserved, must be zero






Higashiyama & Baker         Standards Track                    [Page 18]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


   Pads

      Any PPP frame may have padding inserted in the "Optional Data Link
      Layer Padding" field.  This number tells the receiving system how
      many pad octets to strip off.

   MAC Type

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

          0: reserved
          1: IEEE 802.3/Ethernet  with canonical addresses
          2: IEEE 802.4           with canonical addresses
          3: IEEE 802.5           with non-canonical addresses
          4: FDDI                 with non-canonical addresses
       5-10: reserved
         11: IEEE 802.5           with canonical addresses
         12: FDDI                 with canonical addresses

      "Canonical" is the address format defined as standard address
      representation by the IEEE.  In this format, the bit within each
      byte that is to be transmitted first on a LAN is represented as
      the least significant bit.  In contrast, in non-canonical form,
      the bit within each byte that is to be transmitted first is
      represented as the most-significant bit.  Many LAN interface
      implementations use non-canonical form.  In both formats, bytes
      are represented in the order of transmission.

      If an implementation supports a MAC Type that is the higher-
      numbered format of that MAC Type, then it MUST also support the
      lower-numbered format of that MAC Type.  For example, if an
      implementation supports FDDI with canonical address format, then
      it MUST also support FDDI with non-canonical address format.  The
      purpose of this requirement is to provide backward compatibility
      with earlier versions of this specification.

      A system MUST NOT transmit a MAC Type numbered higher than 4
      unless it has received from its peer a MAC-Support Configuration
      Option indicating that the peer is willing to receive frames of
      that MAC Type.

   Frame Control

      On 802.4, 802.5, and FDDI LANs, there are a few octets preceding
      the Destination MAC Address, one of which is protected by the FCS.




Higashiyama & Baker         Standards Track                    [Page 19]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


      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.

   Pri
      3 bit priority value as defined by IEEE 802.1D.

   C
      Canonical flag as defined by IEEE 802.1Q. It must be set if RIF
      data is present in the LLC data.

   VLAN ID
      12 bit VLAN identifier number as defined by IEEE 802.1Q.

   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.



Higashiyama & Baker         Standards Track                    [Page 20]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


   Frame FCS

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

4.4. Bridge protocols and GARP protocols

   To avoid network loops and improve redundancy, Bridges exchange a
   Spanning Tree Protocol data unit known as BPDU. Bridges also exchange
   a Generic Attributes Registration Protocol data unit to carry the
   GARP VLAN Registration Protocol (GVRP) data and GARP Multicast
   Registration Protocol (GMRP). GVRP allow the Bridges to create VLAN
   groups dynamically. GMRP allows bridges to filter Multicast data if
   the receiver is absent from the network. These Bridge protocols
   include Spanning Tree Protocol and GARP protocols data units are
   carried with a special destination address assigned by the IEEE.

   These bridge protocols data units and GARP protocol data units must
   be carried in the frame format shown in section 4.2 or 4.3. The
   Bridge that receives these data units identifies these protocols
   based on the destination address in the frame format, just like the
   operation of receiving frames from a LAN segment.

   Bridge protocols and GARP protocols data units MUST be recognized by
   checking the destination addresses, which are assigned by IEEE.

      01-80-c2-00-00-00  Bridge Group Address (used by STP)
      01-80-c2-00-00-01  IEEE Std. 802.3x Full Duplex PAUSE operation
      01-80-c2-00-00-10  Bridge Management Group Address
      01-80-c2-00-00-20  GARP Multicast Registration Protocol (GMRP)
      01-80-c2-00-00-21  GARP VLAN Registration Protocol (GVRP)

   But there is one exception to this rule: if the bridge is connected
   to an old BCP bridge [10] and can support backward compatibility, it
   MUST send the BPDU in the old format described in Appendix A.

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.






Higashiyama & Baker         Standards Track                    [Page 21]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


   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 (obsoleted)
         6       MAC-Address
         7       Spanning-Tree-Protocol (old formatted)
         8       IEEE 802 Tagged Frame
         9       Management Inline

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.

      Since mismatched bridge numbers are indicative of a configuration
      error, a correct configuration requires that either the bridge
      declare the misconfiguration or choose one of the options.  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. It should, however, inform the
      network administration of the misconfiguration in any case.

      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




Higashiyama & Baker         Standards Track                    [Page 22]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


      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.

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.






Higashiyama & Baker         Standards Track                    [Page 23]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


      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, a correct configuration requires that either
      the bridge declare the misconfiguration or choose one of the
      options.  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. It should,
      however, inform the network administration of the misconfiguration
      in any case.