doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc1638.txt b/doc/rfc/rfc1638.txt
new file mode 100644
index 0000000..4fb5449
--- /dev/null
+++ b/doc/rfc/rfc1638.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group                                           F. Baker
+Request For Comments: 1638                                           ACC
+Category: Standards Track                                       R. Bowen
+                                                                     IBM
+                                                                 Editors
+                                                               June 1994
+
+
+                  PPP Bridging Control Protocol (BCP)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Point-to-Point Protocol (PPP) [6] provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.  PPP
+   defines an extensible Link Control Protocol, and proposes a family of
+   Network Control Protocols for establishing and configuring different
+   network-layer protocols.
+
+   This document defines the Network Control Protocol for establishing
+   and configuring Remote Bridging for PPP links.
+
+Table of Contents
+
+     1.     Historical Perspective ................................    2
+     2.     Methods of Bridging ...................................    3
+        2.1       Transparent Bridging ............................    3
+        2.2       Remote Transparent Bridging .....................    3
+        2.3       Source Routing ..................................    4
+        2.4       Remote Source Route Bridging ....................    5
+        2.5       SR-TB Translational Bridging ....................    6
+     3.     Traffic Services ......................................    6
+        3.1       LAN Frame Checksum Preservation .................    6
+        3.2       Traffic having no LAN Frame Checksum ............    6
+        3.3       Tinygram Compression ............................    7
+        3.4       LAN Identification ..............................    7
+     4.     A PPP Network Control Protocol for Bridging ...........    9
+        4.1       Sending Bridge Frames ...........................   10
+           4.1.1  Maximum Receive Unit Considerations .............   10
+           4.1.2  Loopback and Link Quality Monitoring ............   11
+           4.1.3  Message Sequence ................................   11
+
+
+
+Baker & Bowen                                                   [Page 1]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+           4.1.4  Separation of Spanning Tree Domains .............   11
+        4.2       Bridged LAN Traffic .............................   12
+        4.3       Spanning Tree Bridge PDU ........................   16
+     5.     BCP Configuration Options .............................   17
+        5.1       Bridge-Identification ...........................   17
+        5.2       Line-Identification .............................   19
+        5.3       MAC-Support .....................................   20
+        5.4       Tinygram-Compression ............................   21
+        5.5       LAN-Identification ..............................   22
+        5.6       MAC-Address .....................................   23
+        5.7       Spanning-Tree-Protocol ..........................   24
+        APPENDICES ................................................   26
+        A.     Tinygram-Compression Pseudo-Code ...................   26
+        SECURITY CONSIDERATIONS ...................................   27
+        REFERENCES ................................................   27
+     ACKNOWLEDGEMENTS .............................................   28
+     CHAIR'S ADDRESS ..............................................   28
+     AUTHOR'S ADDRESS .............................................   28
+
+1.  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.  The other is called "Source Route
+   Bridging", and is prevalent on IEEE 802.5 Token Ring LANs.
+
+   The IEEE has combined these two methods into a device called a Source
+   Routing Transparent (SRT) bridge, which concurrently provides both
+   Source Route and Transparent bridging.  Transparent and SRT bridges
+   are specified in IEEE standard 802.1D [3].
+
+   Although IEEE committee 802.1G is addressing remote bridging [2],
+   neither standard directly defines the mechanisms for implementing
+   remote bridging.  Technically, that would be beyond the IEEE 802
+   committee's charter.  However, both 802.1D and 802.1G allow for it.
+   The implementor may model the line either as a component within a
+   single MAC Relay Entity, or as the LAN media between two remote
+   bridges.
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bowen                                                   [Page 2]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+2.  Methods of Bridging
+
+2.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 when 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 behavior applies to
+   Broadcast/Multicast frames 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 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 Protocol Data Unit (BPDU), heard by all of
+   its neighboring bridges.  Each of these modifies and passes the BPDU
+   on to its neighbors, 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 (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.
+
+2.2.  Remote Transparent Bridging
+
+   There exist two basic sorts of bridges -- those that interconnect
+   LANs directly, called Local Bridges, and those that interconnect LANs
+   via an intermediate medium such as a leased line, called Remote
+   Bridges.  PPP may be used to connect Remote Bridges.
+
+   The IEEE 802.1G Remote MAC Bridging committee has proposed a model of
+   a Remote Bridge in which a set of two or more Remote Bridges that are
+
+
+
+Baker & Bowen                                                   [Page 3]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   interconnected via remote lines are termed a Remote Bridge Group.
+   Within a Group, a Remote Bridge Cluster is dynamically formed through
+   execution of the spanning tree as the set of bridges that may pass
+   frames among each other.
+
+   This model bestows on the remote lines the basic properties of a LAN,
+   but does not require a one-to-one mapping of lines to virtual LAN
+   segments.  For instance, the model of three interconnected Remote
+   Bridges, A, B and C, may be that of a virtual LAN segment between A
+   and B and another between B and C.  However, if a line exists between
+   Remote Bridges B and C, a frame could actually be sent directly from
+   B to C, as long as there was the external appearance that it had
+   travelled through A.
+
+   IEEE 802.1G thus allows for a great deal of implementation freedom
+   for features such as route optimization and load balancing, as long
+   as the model is maintained.
+
+   For simplicity and because the 802.1G proposal has not been approved
+   as a standard, we discuss Remote Bridging in this document in terms
+   of two Remote Bridges connected by a single line.  Within the 802.1G
+   framework, these two bridges would comprise a Remote Bridge Group.
+   This convention is not intended to preclude the use of PPP bridging
+   in larger Groups, as allowed by 802.1G.
+
+2.3.  Source Routing
+
+   The IEEE 802.1D Committee has standardized Source Routing for any MAC
+   Type that allows its use.  Currently, MAC Types that support Source
+   Routing are FDDI and IEEE 802.5 Token Ring.
+
+   The IEEE standard defines Source Routing only as a component of an
+   SRT bridge.  However, many bridges have been implemented which are
+   capable of performing Source Routing alone.  These are most commonly
+   implemented in accordance either with the IBM Token-Ring Network
+   Architecture Reference [1] or with the Source Routing Appendix of
+   IEEE 802.1D [3].
+
+   In the Source Routing approach, the originating system has the
+   responsibility of indicating the path that the message should follow.
+   It does this, if the message is directed off of the local segment, by
+   including a variable length MAC header extension called the Routing
+   Information Field (RIF).  The RIF consists of one 16-bit word of
+   flags and parameters, followed by zero or more segment-and-bridge
+   identifiers.  Each bridge en route determines from this source route
+   list whether it should accept the message and how to forward it.
+
+
+
+
+
+Baker & Bowen                                                   [Page 4]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   In order to discover the path to a destination, the originating
+   system transmits an Explorer frame.  An All-Routes Explorer (ARE)
+   frame follows all possible paths to a destination.  A Spanning Tree
+   Explorer (STE) frame follows only those paths defined by Bridge ports
+   that the Spanning Tree Algorithm has put in Forwarding state.  Port
+   states do not apply to ARE or Specifically-Routed Frames.  The
+   destination system replies to each copy of an ARE frame with a
+   Specifically-Routed Frame, and to an STE frame with an ARE frame.  In
+   either case, the originating station may receive multiple replies,
+   from which it chooses the route it will use for future Specifically-
+   Routed Frames.
+
+   The algorithm for Source Routing requires the bridge to be able to
+   identify any interface by its segment-and-bridge identifier.  When a
+   packet is received that has the RIF present, a boolean in the RIF is
+   inspected to determine whether the segment-and-bridge identifiers are
+   to be inspected in "forward" or "reverse" sense.  In its search, the
+   bridge looks for the segment-and-bridge identifier of the interface
+   the packet was received on, and forwards the packet toward the
+   segment identified in the segment-and-bridge identifier that follows
+   it.
+
+2.4.  Remote Source Route Bridging
+
+   There is no Remote Source Route Bridge proposal in IEEE 802.1 at this
+   time, although many vendors ship remote Source Routing Bridges.
+
+   We allow for modelling the line either as a connection residing
+   between two halves of a "split" Bridge (the split-bridge model), or
+   as a LAN segment between two Bridges (the independent-bridge model).
+   In the latter case, the line requires a LAN Segment ID.
+
+   By default, PPP Source Route Bridges use the independent-bridge
+   model.  This requirement ensures interoperability in the absence of
+   option negotiation.  In order to use the split-bridge model, a system
+   MUST successfully negotiate the Bridge-Identification Configuration
+   Option.
+
+   Although no option negotiation is required for a system to use the
+   independent-bridge model, it is strongly recommended that systems
+   using this model negotiate the Line-Identification Configuration
+   Option.  Doing so will verify correct configuration of the LAN
+   Segment Id assigned to the line.
+
+   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
+
+
+
+Baker & Bowen                                                   [Page 5]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   bridging algorithm.  For example, if the receiving system did not
+   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?".
+
+
+
+Baker & Bowen                                                   [Page 6]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   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 1 describes the algorithms.
+
+3.4.  LAN Identification
+
+   In some applications, it is useful to tag traffic by the user
+   community it is a part of, and guarantee that it will be only emitted
+   onto a LAN which is of the same community.  The user community is
+   defined by a LAN ID.  Systems which choose to not implement this
+   feature must assume that any frame received having a LAN ID is from a
+   different community than theirs, and discard it.
+
+   It should be noted that the enabling of the LAN Identification option
+   requires behavior consistent with the following additions to the
+   standard bridging algorithm.
+
+
+
+Baker & Bowen                                                   [Page 7]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   Each bridge port may be considered to have two additional variables
+   associated with it: "domain" and "checkDomain".
+
+   The variable "domain" (a 32-bit unsigned integer) is assigned a value
+   that uniquely labels a set of bridge ports in an extended network,
+   with a default value of 1, and the values of 0 and 0xffffffff being
+   reserved.
+
+   The variable "checkDomain" (a boolean) controls whether this value is
+   used to filter output to a bridge port.  The variable "checkDomain"
+   is generally set to the boolean value True for LAN bridge ports, and
+   set to the boolean value False for WAN bridge ports.
+
+   The action of the bridge is then as modified as expressed in the
+   following C code fragments:
+
+      On a packet being received from a bridge port:
+
+      if (domainNotPresentWithPacket) {
+          packetInformation.domain = portInformation[inputPort].domain;
+      } else {
+          packetInformation.domain = domainPresentWithPacket;
+      }
+
+      On a packet being transmitted from a bridge port:
+
+      if (portInformation[outputPort].checkDomain &&
+          portInformation[outputPort] != packetInformation.domain) {
+          discardPacket();
+          return;
+      }
+
+   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.
+
+
+
+Baker & Bowen                                                   [Page 8]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   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|------------
+                  +--+            +--+
+
+   To accomplish this (using the LAN Identification option), B1 and B2
+   negotiate this option on, and send datagrams with bit 6 set to 1,
+   with the LAN ID field inserted in the frame.  Traffic on E1 and E3
+   would be assigned LAN ID 1, and traffic on E2 and E4 would be
+   assigned LAN ID 2.  Thus B1 and B2 can separate traffic going over
+   W1.
+
+   Note that execution of the spanning tree algorithm may result in the
+   subdivision of a domain.  The administrator of LAN domains must
+   ensure, through spanning tree configuration and topology design, that
+   such subdivision does not occur.
+
+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:
+
+   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.
+
+
+
+Baker & Bowen                                                   [Page 9]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   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).
+
+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.
+
+
+
+
+
+Baker & Bowen                                                  [Page 10]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+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.
+
+   Work is currently in progress on a protocol to allow use of multiple
+   PPP links [7].  If approved, this protocol will allow use of multiple
+   links while maintaining message sequentiality for Bridged LAN Traffic
+   and BPDU frames.
+
+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,
+   and MUST either silently discard or respond to other received BPDU
+   packets with an LCP Protocol-Reject packet.
+
+
+
+
+
+
+
+
+Baker & Bowen                                                  [Page 11]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+4.2.  Bridged LAN Traffic
+
+   For Bridging LAN traffic, the format of the frame on the line is
+   shown below.  The fields are transmitted from left to right.
+
+   802.3 Frame format
+
+    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      |      0x00     |      0x31     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |F|I|Z|0| Pads  |    MAC Type   |  LAN ID high word (optional)  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   LAN ID low word (optional)  |      Destination MAC Address  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Destination MAC Address                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Source MAC Address                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Source MAC Address        |      Length/Type              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               LLC data       ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   LAN FCS (optional)                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                potential line protocol pad                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Frame FCS            |   HDLC FLAG   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bowen                                                  [Page 12]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   802.4/802.5/FDDI Frame format
+
+    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      |      0x00     |      0x31     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |F|I|Z|0| Pads  |    MAC Type   |  LAN ID high word (optional)  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   LAN ID low word (optional)  |   Pad Byte    | Frame Control |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Destination MAC Address                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Destination MAC Address   |  Source MAC Address           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Source MAC Address                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               LLC data       ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   LAN FCS (optional)                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              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 I:  Set if the LAN ID Field is present
+      bit Z:  Set if IEEE 802.3 Pad must be zero filled to minimum size
+      bit 0:  reserved, must be zero
+
+   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.
+
+
+
+Baker & Bowen                                                  [Page 13]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   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.
+
+   LAN ID
+
+      This optional 32-bit field identifies the Community of LANs which
+      may be interested to receive this frame.  If the LAN ID flag is
+      not set, then this field is not present, and the PDU is four
+      octets shorter.
+
+   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.
+
+
+
+Baker & Bowen                                                  [Page 14]
+
+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]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   Length
+
+      3
+
+   Enable/Disable
+
+      If the value is 1, Tinygram-Compression is enabled.  If the value
+      is 2, Tinygram-Compression is disabled, and no decompression will
+      occur.
+
+      The implementations need not agree on the setting of this
+      parameter.  One may be willing to decompress and the other not.
+
+
+5.5.  LAN-Identification
+
+   Description
+
+      This Configuration Option permits the implementation to indicate
+      support for the LAN Identification field, and that the system is
+      prepared to service traffic to any labeled LANs beyond the system.
+
+      A Configure-NAK MUST NOT be sent in response to a Configure-
+      Request that includes this option.
+
+      By default, LAN-Identification is disabled.  All Bridge LAN
+      Traffic and BPDUs that contain the LAN ID field will be discarded.
+      The peer may then reduce bandwidth usage by not sending the
+      unsupported traffic.
+
+   A summary of the LAN-Identification 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
+
+      5
+
+   Length
+
+      3
+
+
+
+
+Baker & Bowen                                                  [Page 22]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   Enable/Disable
+
+      If the value is 1, LAN Identification is enabled.  If the value is
+      2, LAN Identification is disabled.
+
+      The implementations need not agree on the setting of this
+      parameter.  One may be willing to accept LAN Identification and
+      the other not.
+
+5.6.  MAC-Address
+
+   Description
+
+      The MAC-Address Configuration Option enables the implementation to
+      announce its MAC address or have one assigned.  The MAC address is
+      represented in IEEE 802.1 Canonical format, which is to say that
+      the multicast bit is the least significant bit of the first octet
+      of the address.
+
+      If the system wishes to announce its MAC address, it sends the
+      option with its MAC address specified.  When specifying a non-zero
+      MAC address in a Configure-Request, any inclusion of this option
+      in a Configure-Nak MUST be ignored.
+
+      If the implementation wishes to have a MAC address assigned, it
+      sends the option with a MAC address of 00-00-00-00-00-00.  Systems
+      that have no mechanism for address assignment will Configure-
+      Reject the option.
+
+      A Configure-Nak MUST specify a valid IEEE 802.1 format physical
+      address; the multicast bit MUST be zero.  It is strongly
+      recommended (although not mandatory) that the "locally assigned
+      address" bit (the second least significant bit in the first octet)
+      be set, indicating a locally assigned address.
+
+   A summary of the MAC-Address 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     |MAC byte 1 |L|M|  MAC byte 2   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  MAC byte 3   |  MAC byte 4   |  MAC byte 5   |  MAC byte 6   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Baker & Bowen                                                  [Page 23]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+   Type
+
+      6
+
+   Length
+
+      8
+
+   MAC Byte
+
+      Six octets of MAC address in 802.1 Canonical order.  For clarity,
+      the position of the Local Assignment (L) and Multicast (M) bits
+      are shown in the diagram.
+
+5.7.  Spanning-Tree-Protocol
+
+   Description
+
+      The Spanning-Tree-Protocol Configuration Option enables the
+      Bridges to negotiate the version of the spanning tree protocol in
+      which they will participate.
+
+      If both bridges support a spanning tree protocol, they MUST agree
+      on the protocol to be supported.  When the two disagree, the
+      lower-numbered of the two spanning tree protocols should be used.
+      To resolve the conflict, the system with the lower-numbered
+      protocol SHOULD Configure-Nak the option, suggesting its own
+      protocol for use.  If a spanning tree protocol is not agreed upon,
+      except for the case in which one system does not support any
+      spanning tree protocol, the Bridging Control Protocol MUST NOT
+      enter the Opened state.
+
+      Most systems will only participate in a single spanning tree
+      protocol.  If a system wishes to participate simultaneously in
+      more than one spanning tree protocol, it MAY include all of the
+      appropriate protocol types in a single Spanning-Tree-Protocol
+      Configuration Option.  The protocol types MUST be specified in
+      increasing numerical order.  For the purpose of comparison during
+      negotiation, the protocol numbers MUST be considered to be a
+      single number.  For instance, if System A includes protocols 01
+      and 03 and System B indicates protocol 03, System B should
+      Configure-Nak and indicate a protocol type of 03 since 0103 is
+      greater than 03.
+
+      By default, an implementation MUST either support the IEEE 802.1D
+      spanning tree or support no spanning tree protocol.  An
+      implementation that does not support any spanning tree protocol
+      MUST silently discard any received IEEE 802.1D BPDU packets, and
+
+
+
+Baker & Bowen                                                  [Page 24]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+      MUST either silently discard or respond to other received BPDU
+      packets with an LCP Protocol-Reject packet.
+
+   A summary of the Spanning-Tree-Protocol 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 2 3 4
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  Protocol 1   |  Protocol 2   | ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Type
+
+      7
+
+   Length
+
+      2 octets plus 1 additional octet for each protocol that will be
+      actively supported.  Most systems will only support a single
+      spanning tree protocol, resulting in a length of 3.
+
+   Protocol n
+
+      Each Protocol field is one octet and indicates a desired spanning
+      tree protocol.  Up-to-date values of the Protocol field are
+      specified in the most recent "Assigned Numbers" RFC [4].  Current
+      values are assigned as follows:
+
+
+           Value     Protocol
+
+             0       Null (no Spanning Tree protocol supported)
+             1       IEEE 802.1D spanning tree
+             2       IEEE 802.1G extended spanning tree protocol
+             3       IBM Source Route Spanning tree protocol
+             4       DEC LANbridge 100 Spanning tree protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bowen                                                  [Page 25]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+A.  Tinygram-Compression Pseudo-Code
+
+    PPP Transmitter:
+
+    if (ZeroPadCompressionEnabled &&
+        BridgedProtocolHeaderFormat == IEEE8023 &&
+        PacketLength == Minimum8023PacketLength) {
+     /*
+      * Remove any continuous run of zero octets preceding,
+      * but not including, the LAN FCS, but not extending
+      * into the MAC header.
+      */
+        Set (ZeroCompressionFlag);            /* Signal receiver */
+        if (is_Set (LAN_FCS_Present)) {
+            FCS = TrailingOctets (PDU, 4);    /* Store FCS */
+            RemoveTrailingOctets (PDU, 4);    /* Remove FCS */
+            while (PacketLength > 14 &&       /* Stop at MAC header or */
+                   TrailingOctet (PDU) == 0)  /*  last non-zero octet */
+                RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
+            Appendbuf (PDU, 4, FCS);          /* Restore FCS */
+        }
+        else {
+            while (PacketLength > 14 &&       /* Stop at MAC header */
+                   TrailingOctet (PDU) == 0)  /*  or last zero octet */
+                RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
+        }
+    }
+
+    PPP Receiver:
+
+    if (ZeroCompressionFlag) {                /* Flag set in header? */
+     /* Restoring packet to minimum 802.3 length */
+        Clear (ZeroCompressionFlag);
+        if (is_Set (LAN_FCS_Present)) {
+            FCS = TrailingOctets (PDU, 4);   /* Store FCS */
+            RemoveTrailingOctets (PDU, 4);   /* Remove FCS */
+            Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
+            Appendbuf (PDU, 4, FCS);         /* Restore FCS */
+        }
+        else {
+            Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
+        }
+    }
+
+
+
+
+
+
+
+
+Baker & Bowen                                                  [Page 26]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+References
+
+   [1] IBM, "Token-Ring Network Architecture Reference", 3rd edition,
+       September 1989.
+
+   [2] IEEE 802.1, "Draft Standard 802.1G: Remote MAC Bridging",
+       P802.1G/D7, December 30, 1992.
+
+   [3] IEEE 802.1, "Media Access Control (MAC) Bridges", ISO/IEC 15802-
+       3:1993 ANSI/IEEE Std 802.1D, 1993 edition., July 1993.
+
+   [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
+       USC/Information Sciences Institute, July 1992.
+
+   [5] Simpson, W., "PPP LCP Extensions", RFC 1570, Daydreamer, January
+       1994.
+
+   [6] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1548,
+       Daydreamer, December 1993.
+
+   [7] Sklower, K., "A Multilink Protocol for Synchronizing the
+       Transmission of Multi-protocol Datagrams", Work in Progress,
+       August 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bowen                                                  [Page 27]
+
+RFC 1638                      PPP Bridging                     June 1994
+
+
+Acknowledgments
+
+   This document is a product of the Point-to-Point Protocol Extensions
+   Working Group.
+
+   Special thanks go to Steve Senum of Network Systems, Dino Farinacci
+   of 3COM, Rick Szmauz of Digital Equipment Corporation, and Andrew
+   Fuqua of IBM.
+
+Chair's Address
+
+   The working group can be contacted via the current chair:
+
+   Fred Baker
+   Advanced Computer Communications
+   315 Bollay Drive
+   Santa Barbara, California  93117
+
+   EMail: fbaker@acc.com
+
+Author's Address
+
+   Questions about this memo can also be directed to:
+
+   Rich Bowen
+   International Business Machines Corporation
+   P. O. Box 12195
+   Research Triangle Park, NC  27709
+
+   Phone: (919) 543-9851
+   EMail: Rich_Bowen@vnet.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bowen                                                  [Page 28]
+