Network Working Group M. Higashiyama Request for Comments: 2878 Anritsu Obsoletes: 1638 F. Baker Category: Standards Track Cisco July 2000 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 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. This document obsoletes RFC 1638, which was based on the IEEE 802.1D-1993 MAC Bridge[3]. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q Virtual LAN (VLAN)[9] standards. This document also improves the protocol in order to support high-speed switched LANs. Higashiyama & Baker Standards Track [Page 1] RFC 2878 PPP Bridging Control Protocol (BCP) July 2000 Table of Contents 1. Historical Perspective ................................ 3 1.1 Requirements Keywords ........................... 3 2. Methods of Bridging ................................... 3 2.1 Transparent Bridging ............................ 3 2.2 Remote Transparent Bridging ..................... 4 2.3 Source Routing .................................. 5 2.4 Remote Source Route Bridging .................... 6 2.5 SR-TB Translational Bridging .................... 7 3. Traffic Services ...................................... 7 3.1 LAN Frame Checksum Preservation ................. 7 3.2 Traffic having no LAN Frame Checksum ............ 7 3.3 Tinygram Compression ............................ 8 3.4 Virtual LANs .................................... 8 4. A PPP Network Control Protocol for Bridging ........... 9 4.1 Sending Bridge Frames ........................... 10 4.1.1 Maximum Receive Unit Considerations ............. 11 4.1.2 Loopback and Link Quality Monitoring ............ 11 4.1.3 Message Sequence ................................ 11 4.1.4 Separation of Spanning Tree Domains ............. 12 4.2 Bridged LAN Traffic in IEEE 802 Untagged Frame .. 12 4.3 Bridged LAN Traffic in IEEE 802 Tagged Frame .... 16 4.4 Bridge management protocol data unit ............ 21 5. BCP Configuration Options ............................. 21 5.1 Bridge-Identification ........................... 22 5.2 Line-Identification ............................. 23 5.3 MAC-Support ..................................... 25 5.4 Tinygram-Compression ............................ 26 5.5 MAC-Address ..................................... 27 5.6 Spanning Tree Protocol (old formatted) .......... 28 5.7 IEEE-802-Tagged-Frame ........................... 30 5.8 Management-Inline ............................... 30 6. Changes From RFC 1638 ................................. 31 7. Security Considerations ............................... 32 8. Intellectual Property Notice .......................... 32 9. IANA Considerations ................................... 33 10. Acknowledgments ....................................... 33 APPENDICES ................................................... 34 A. Spanning Tree Bridge PDU (old formatted) ........... 34 B. Tinygram-Compression Pseudo-Code ................... 35 References ................................................... 36 Authors' Addresses ........................................... 37 Full Copyright Statement...................................... 38 Higashiyama & Baker Standards Track [Page 2] RFC 2878 PPP Bridging Control Protocol (BCP) July 2000 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-1998 [8]. 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. The original IEEE 802.1D is augmented by IEEE 802.1Q [9] to provide support for Virtual LAN. Virtual LAN is an integral feature of switched LAN networks. 1.1 Requirements Keywords The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [12]. 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} or {address, interface, VLAN ID} Higashiyama & Baker Standards Track [Page 3] RFC 2878 PPP Bridging Control Protocol (BCP) July 2000 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. Bridges which support Virtual LANs additionally keep the Virtual LAN ID in their forwarding database. 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. To establish Virtual LANs in an environment of multiple bridges, GVRP (GARP VLAN Registration Protocol) is executed between bridges to exchange Virtual LAN information. GVRP provides a mechanism to dynamically establish and update their knowledge of the set of Virtual LANs that currently have active members. To reduce unnecessary multicast flooding in the network, bridges exchange group MAC addresses using the GARP Multicast Registration Protocol. GMRP provides a mechanism so that bridges can know which multicast frames should be forwarded on each port. 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. Higashiyama & Baker Standards Track [Page 4] RFC 2878 PPP Bridging Control Protocol (BCP) July 2000 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 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, we discuss Remote Bridging in this document in terms of two Remote Bridges connected by a single line. 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-1998 [8]. 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. 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 Higashiyama & Baker Standards Track [Page 5] RFC 2878 PPP Bridging Control Protocol (BCP) July 2000 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. GVRP and GMRP are available and effective on Source Routing networks. 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 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