rfc2878.txt

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

   When two PPP systems use the split-bridge model, the system that
   transmits an Explorer frame onto the PPP link MUST update the RIF on
   behalf of the two systems.  The purpose of this constraint is to
   ensure interoperability and to preserve the simplicity of the
   bridging algorithm.  For example, if the receiving system did not



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


   know whether the transmitting system had updated the RIF, it would
   have to scan the RIF and decide whether to update it.  The choice of
   the transmitting system for the role of updating the RIF allows the
   system receiving the frame from the PPP link to forward the frame
   without processing the RIF.

   Given that source routing is configured on a line or set of lines,
   the specifics of the link state with respect to STE frames are
   defined by the Spanning Tree Protocol in use.  Choice of the split-
   bridge or independent-bridge model does not affect spanning tree
   operation.  In both cases, the spanning tree protocol is executed on
   the two systems independently.

2.5.  SR-TB Translational Bridging

   IEEE 802 is not currently addressing bridges that translate between
   Transparent Bridging and Source Routing.  For the purposes of this
   standard, such a device is either a Transparent or a Source Routing
   bridge, and will act on the line in one of these two ways, just as it
   does on the LAN.

3.  Traffic Services

   Several services are provided for the benefit of different system
   types and user configurations.  These include LAN Frame Checksum
   Preservation, LAN Frame Checksum Generation, Tinygram Compression,
   and the identification of closed sets of LANs.

3.1.  LAN Frame Checksum Preservation

   IEEE 802.1 stipulates that the Extended LAN must enjoy the same
   probability of undetected error that an individual LAN enjoys.
   Although there has been considerable debate concerning the algorithm,
   no other algorithm has been proposed than having the LAN Frame
   Checksum received by the ultimate receiver be the same value
   calculated by the original transmitter.  Achieving this requires, of
   course, that the line protocols preserve the LAN Frame Checksum from
   end to end.  The protocol is optimized towards this approach.

3.2.  Traffic having no LAN Frame Checksum

   The fact that the protocol is optimized towards LAN Frame Checksum
   preservation raises twin questions: "What is the approach to be used
   by systems which, for whatever reason, cannot easily support Frame
   Checksum preservation?" and "What is the approach to be used when the
   system originates a message, which therefore has no Frame Checksum
   precalculated?".




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


   Surely, one approach would be to require stations to calculate the
   Frame Checksum in software if hardware support were unavailable; this
   would meet with profound dismay, and would raise serious questions of
   interpretation in a Bridge/Router.

   However, stations which implement LAN Frame Checksum preservation
   must already solve this problem, as they do originate traffic.
   Therefore, the solution adopted is that messages which have no Frame
   Checksum are tagged and carried across the line.

   When a system which does not implement LAN Frame Checksum
   preservation receives a frame having an embedded FCS, it converts it
   for its own use by removing the trailing four octets.  When any
   system forwards a frame which contains no embedded FCS to a LAN, it
   forwards it in a way which causes the FCS to be calculated.

3.3.  Tinygram Compression

   An issue in remote Ethernet bridging is that the protocols that are
   most attractive to bridge are prone to problems on low speed (64 KBPS
   and below) lines.  This can be partially alleviated by observing that
   the vendors defining these protocols often fill the PDU with octets
   of ZERO.  Thus, an Ethernet or IEEE 802.3 PDU received from a line
   that is (1) smaller than the minimum PDU size, and (2) has a LAN
   Frame Checksum present, must be padded by inserting zeroes between
   the last four octets and the rest of the PDU before transmitting it
   on a LAN.  These protocols are frequently used for interactive
   sessions, and therefore are frequently this small.

   To prevent ambiguity, PDUs requiring padding are explicitly tagged.
   Compression is at the option of the transmitting station, and is
   probably performed only on low speed lines, perhaps under
   configuration control.

   The pseudo-code in Appendix B describes the algorithms.

3.4.  Virtual LANs

   IEEE 802.1Q defines Virtual LANs and their exchangeable VLAN Tagged
   frame format. Virtual LANs allow user multiple community groups to
   co-exist within one bridge. A bridging community is identified by its
   VLAN ID. If a system that supports Virtual LANs receives a frame from
   the LAN, that frame will be only emitted onto a LAN which belongs to
   the same community. In order to handle multiple communities on a
   single line, IEEE 802.1Q defines a VLAN Tagged Frame.






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


   For example, suppose you have the following configuration:

           E1     +--+            +--+     E3
      ------------|  |            |  |------------
                  |  |     W1     |  |
                  |B1|------------|B2|
           E2     |  |            |  |     E4
      ------------|  |            |  |------------
                  +--+            +--+

   E1, E2, E3, and E4 are Ethernet LANs (or Token Ring, FDDI, etc.).  W1
   is a WAN (PPP over T1).  B1 and B2 are MAC level bridges.

   You want End Stations on E1 and E3 to communicate, and you want End
   Stations on E2 and E4 to communicate, but you do not want End
   Stations on E1 and E3 to communicate with End Stations on E2 and E4.

   This is true for Unicast, Multicast, and Broadcast traffic.  If a
   broadcast datagram originates on E1, you want it only to be
   propagated to E3, and not on E2 or E4.

   Another way of looking at it is that E1 and E3 form a Virtual LAN,
   and E2 and E4 form a Virtual LAN, as if the following configuration
   were actually being used:

           E1     +--+     W2     +--+     E3
      ------------|B3|------------|B4|------------
                  +--+            +--+

           E2     +--+     W3     +--+     E4
      ------------|B5|------------|B6|------------
                  +--+            +--+

4.  A PPP Network Control Protocol for Bridging

   The Bridging Control Protocol (BCP) is responsible for configuring,
   enabling and disabling the bridge protocol modules on both ends of
   the point-to-point link.  BCP uses the same packet exchange mechanism
   as the Link Control Protocol.  BCP packets may not be exchanged until
   PPP has reached the Network-Layer Protocol phase.  BCP packets
   received before this phase is reached SHOULD be silently discarded.

   The Bridging Control Protocol is exactly the same as the Link Control
   Protocol [6] with the following exceptions:







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


   Frame Modifications

      The packet may utilize any modifications to the basic frame format
      which have been negotiated during the Link Establishment phase.

      Implementations SHOULD NOT negotiate Address-and-Control-Field-
      Compression or Protocol-Field-Compression on other than low speed
      links.

   Data Link Layer Protocol Field

      Exactly one BCP packet is encapsulated in the PPP Information
      field, where the PPP Protocol field indicates type hex 8031 (BCP).

   Code field

      Only Codes 1 through 7 (Configure-Request, Configure-Ack,
      Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
      and Code-Reject) are used.  Other Codes SHOULD be treated as
      unrecognized and SHOULD result in Code-Rejects.

   Timeouts

      BCP packets may not be exchanged until PPP has reached the
      Network-Layer Protocol phase.  An implementation SHOULD be
      prepared to wait for Authentication and Link Quality Determination
      to finish before timing out waiting for a Configure-Ack or other
      response.  It is suggested that an implementation give up only
      after user intervention or a configurable amount of time.

   Configuration Option Types

      BCP has a distinct set of Configuration Options, which are defined
      in this document.

4.1.  Sending Bridge Frames

   Before any Bridged LAN Traffic or BPDUs may be communicated, PPP MUST
   reach the Network-Layer Protocol phase, and the Bridging Control
   Protocol MUST reach the Opened state.

   Exactly one Bridged LAN Traffic or BPDU is encapsulated in the PPP
   Information field, where the PPP Protocol field indicates type hex
   0031 (Bridged PDU).







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


4.1.1.  Maximum Receive Unit Considerations

   The maximum length of a Bridged datagram transmitted over a PPP link
   is the same as the maximum length of the Information field of a PPP
   encapsulated packet.  Since there is no standard method for
   fragmenting and reassembling Bridged PDUs, PPP links supporting
   Bridging MUST negotiate an MRU large enough to support the MAC Types
   that are later negotiated for Bridging support.  Because they include
   the MAC headers, even bridged Ethernet frames are larger than the
   default PPP MRU of 1500 octets.

4.1.2.  Loopback and Link Quality Monitoring

   It is strongly recommended that PPP Bridge Protocol implementations
   utilize Magic Number Loopback Detection and Link-Quality-Monitoring.
   The 802.1 Spanning Tree protocol, which is integral to both
   Transparent Bridging and Source Routing (as standardized), is
   unidirectional during normal operation.  Configuration BPDUs emanate
   from the Root system in the general direction of the leaves, without
   any reverse traffic except in response to network events.

4.1.3.  Message Sequence

   The multiple link case requires consideration of message
   sequentiality.  The transmitting system may determine either that the
   protocol being bridged requires transmissions to arrive in the order
   of their original transmission, and enqueue all transmissions on a
   given conversation onto the same link to force order preservation, or
   that the protocol does NOT require transmissions to arrive in the
   order of their original transmission, and use that knowledge to
   optimize the utilization of several links, enqueuing traffic to
   multiple links to minimize delay.

   In the absence of such a determination, the transmitting system MUST
   act as though all protocols require order preservation.  Many
   protocols designed primarily for use on a single LAN require order
   preservation.

   PPP Multilink [7] and its multi-class extension [11] may be used to
   allow the use of multiple PPP links between a pair of systems without
   loss of message sequentiality. It treats the group of links as a
   single link with speed equal to the sum of the speeds of the links in
   the group.








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


4.1.4.  Separation of Spanning Tree Domains

   It is conceivable that a network manager might wish to inhibit the
   exchange of BPDUs on a link in order to logically divide two regions
   into separate Spanning Trees with different Roots (and potentially
   different Spanning Tree implementations or algorithms).  In order to
   do that, he should configure both ends to not exchange BPDUs on a
   link.  An implementation that does not support any spanning tree
   protocol MUST silently discard any received IEEE 802.1D BPDU packets.

   If a bridge is connected to an old BCP bridge [10], the other bridge
   cannot operate according to this specification. Options are therefore
   to decide that:

   (a) If the bridge wants to terminate the connection, it sends a
       Terminate-Request and terminate the connection.
   (b) If the bridge wants to run the connection but not receive old
       BPDUs, its only option is to run without spanning tree on the
       link at all, which is dangerous. It should Configure-Reject the
       option and advise the network administration that it has done so.
   (c) If the bridge chooses to be entirely backward compatible, it
       sends Configure-Ack and operates in the manner described in
       Appendix A.

   In the event that both the new Management-Inline Option and the
   Spanning-Tree-Protocol-Configuration Option are configure-rejected,
   indicating that the peer implements no spanning tree protocol at all
   and doesn't understand the options, it is an incomplete
   implementation. For safety reasons the system should cease attempting
   to configure bridging, and log the fact. If the peer was configure-
   rejecting the options in order to disable spanning tree entirely, it
   understood the option but could not within its configuration comply.
   It should have sent the Spanning-Tree-Protocol-Configuration Option
   with the value NULL.