rfc1220.txt

RFC 的详细文档！

Network Working Group                                   F. Baker, Editor
Request for Comments: 1220                                           ACC
                                                              April 1991


            Point-to-Point Protocol Extensions for Bridging

1.  Status of this Memo

   This document defines an extension of the Internet Point-to-Point
   Protocol (PPP) described in RFC 1171, targeting the use of Point-to-
   Point lines for Remote Bridging.  It is a product of the Point-to-
   Point Protocol Extensions Working Group of the Internet Engineering
   Task Force (IETF).

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

2.  Historical Perspective

   Two basic algorithms are ambient in the industry for Bridging of
   Local Area Networks.  The more common algorithm is called
   "Transparent Bridging" and has been standardized for Extended LAN
   configurations by IEEE 802.1.  IEEE 802.5 has proposed an alternative
   approach, called "Source Routing", and is in the process of
   standardizing that approach for IEEE 802.5 extended networks.

   Although there is a subcommittee of IEEE 802.1 addressing remote
   bridging, neither standard directly defines Remote Bridging per se,
   as that would technically be beyond the IEEE 802 committee's charter.
   Both allow for it, however, modeling the line as an unspecified
   interface between half-bridges.

   This document assumes that the devices at either end of a serial link

      - have agreed to utilize the RFC 1171 line discipline in some form.

      - may have agreed, by some other means, to exchange other
        protocols on the line interspersed with each other and with any
        bridged PDUs.

      - may be willing to use the link as a vehicle for Remote Bridging.

      - may have multiple point-to-point links that are configured in
        parallel to simulate a single line of higher speed or



Point-to-Point Protocol Extensions Working Group                [Page 1]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


        reliability, but message sequence issues are solved by the
        transmitting end.

3.  General Considerations

3.1.  Link Quality Monitoring

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

3.2.  Message Sequence

   The multiple link case requires consideration of message
   sequentiality.  The transmitting station must 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 the several links, enqueuing
   traffic to links to minimize delay.

   In the absence of such a determination, the transmitting station must
   act as though all protocols require order preservation; many
   protocols designed primarily for use on a single LAN in fact do.  A
   protocol could be described to maintain message sequentiality across
   multiple links, either by sequence numbering or by fragmentation and
   re-assembly, but this is neither elegant nor absolutely necessary.

3.3.  Maximum Receive Unit Considerations

   Please note that the negotiated MRU must be large enough to support
   the MAC Types that are negotiated for support, there being no
   fragmentation and re-assembly.  Even Ethernet frames are larger than
   the default MRU of 1500 octets.

3.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



Point-to-Point Protocol Extensions Working Group                [Page 2]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


   do that, he must configure both ends to not exchange BPDUs on a link.
   For the sake of robustness, a bridge which is so configured must
   silently discard the BPDU of its neighbor, should it receive one.

4.  IEEE 802.1 Transparent Bridging

4.1.  Overview of IEEE 802.1 Transparent Bridging

   As a favor to the uninitiated, let us first describe Transparent
   Bridging.  Essentially, the bridges in a network operate as isolated
   entities, largely unaware of each others' presence.  A Transparent
   Bridge maintains a Forwarding Database consisting of

            {address, interface}

   records by saving the Source Address of each LAN transmission that it
   receives along with the interface identifier for the interface it was
   received on.  It goes on to check whether the Destination Address is
   in the database, and if so, either discards the message (if the
   destination and source are located at the same interface) or forwards
   the message to the indicated interface.  A message whose Destination
   Address is not found in the table is forwarded to all interfaces
   except the one it was received on; this describes Broadcast/Multicast
   behavior as well.

   The obvious fly in the ointment is that redundant paths in the
   network cause indeterminate (nay, all too determinate) forwarding
   behavior to occur.  To prevent this, a protocol called the IEEE
   802.1(d) Spanning Tree Protocol is executed between the bridges to
   detect and logically remove redundant paths from the network.

   One system is elected as the "Root", which periodically emits a
   message called a Bridge Hello Protocol Data Unit, or BPDU, heard by
   all of its neighboring bridges.  Each of these modifies and passes
   the BPDU on to its neighbors, and they to theirs, until it arrives at
   the leaf LAN segments in the network (where it dies, having no
   further neighbors to pass it along) or until the message is stopped
   by a bridge which has a superior path to the "Root".  In this latter
   case, the interface the BPDU was received on is ignored (i.e., it is
   placed in a Hot Standby status, no traffic is emitted onto it except
   the BPDU, and all traffic received from it is discarded) until a
   topology change forces a recalculation of the network.

4.2.  IEEE 802.1 Remote Bridging Activity

   There exist two basic sorts of bridges - ones that interconnect LANs
   directly, called Local Bridges, and ones that interconnect LANs via
   an intermediate medium such as a leased line, called Remote Bridges.



Point-to-Point Protocol Extensions Working Group                [Page 3]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


   The Point-to-Point Protocol might be used by a Remote Bridge.

   There is more than one proposal within the IEEE 802.1 Interworking
   Committee for modeling the Remote Bridge.  In one model, the
   interconnecting serial link(s) are treated in the same way that a LAN
   is, having a standard IEEE 802.1 Link State; in another, the serial
   links operate in a mode quite different from the LANs that they
   interconnect.  For the sake of simplicity of specification, the first
   model is adopted, although some of the good ideas from proponents of
   the second model are included or allowed for.

   Therefore, given that transparent bridging is configured on a line or
   set of lines, the specifics of the link state with respect to the
   bridge is defined by IEEE 802.1(d).  The Bridge Protocol Data Unit,
   or BPDU, is defined there, as well as the algorithms for its use.

   It is assumed that, if a Point-to-Point Link neighbor receives IEEE
   802.1 BPDUs without rejecting them with the RFC 1171 Protocol-Reject
   LCP PDU, Transparent Bridging is permitted on the link.

4.3.  IEEE 802.5 Source Routing

   The IEEE 802.5 Committee has defined a different approach to bridging
   for use on the Token Ring, called Source Routing.  In this approach,
   the originating system has the responsibility of indicating what path
   that the message should follow.  It does this, if the message is
   directed off the local ring, by including a variable length MAC
   header extension called the Routing Information Field, or RIF.  The
   RIF consists of one 16 bit word of flags and parameters followed by
   zero or more ring-and-bridge identifiers.  Each bridge en route
   determines from this "source route list" whether it should receive
   the message and how to forward it.

   The algorithm for Source Routing requires the bridge to be able to
   identify any interface by its ring-and-bridge identifier, and to be
   able to identify any of its OTHER interfaces likewise.  When a packet
   is received which has the Routing Information Field (RIF) present, a
   boolean in the RIF is inspected to determine whether the ring-and-
   bridge identifiers are to be inspected in "forward" or "reverse"
   sense.  In a "forward" search, the bridge looks for the ring-and-
   bridge identifier of the interface the packet was received on, and
   forwards the packet toward the ring identified in the ring-and-bridge
   identifier that follows it.  In a "reverse" search, the bridge looks
   for the ring-and-bridge identifier of the OTHER INTERFACE, and
   delivers the packet to the indicated interface if such is found.

   The algorithms for handling multicasts ("Functional Addresses" and
   "Group Addresses") have been the subject of much discussion in 802.5,



Point-to-Point Protocol Extensions Working Group                [Page 4]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


   and are likely to be the most troublesome for bridge implementations.
   Fortunately, they are beyond the scope of this document.

4.4.  IEEE 802.5 Remote Bridging Activity

   There is no Remote Bridge proposal in IEEE 802.5 at this time,
   although IBM ships a remote Source Routing Bridge.  Simplicity would
   dictate that we choose the same model for IEEE 802.5 Source Routing
   that was selected for IEEE 802.1, but necessity requires a ring
   number for the line in some cases.  We allow for both models.

   Given that source routing is configured on a line or set of lines,
   the specifics of the link state with respect to the bridge is defined
   by the IEEE 802.5 Addendum on Source Routing.  The requisite PDUs for
   calculating the spanning tree (used for assuring that each ring will
   receive at most one copy of a multicast) are defined there, as well
   as the algorithms for their use.  MAC PDUs (Beacon, Ring Management,
   etc) are specific to the MAU technology and are not exchanged on the
   line.

4.5.  Source Routing to Transparent Bridge Translation

   IEEE 802 also has a subcommittee looking at the interoperation of
   Transparent Bridging and Source Routing.  For the purposes of this
   standard, such a device is both a transparent and a source routing
   bridge, and will act on the line in both ways, just as it does on the
   LAN.

5.  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.

5.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.






Point-to-Point Protocol Extensions Working Group                [Page 5]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


5.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?".

   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.

5.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 Figure 1 describes the algorithms.