Network Working Group M. Higashiyama
Request for Comments: 2878 Anritsu
Obsoletes: 1638 F. Baker
Category: Standards Track Cisco
July 2000
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)
PPP桥接控制协议（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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
点到点协议（PPP）[6]提供了通过点到点链路传输多协议数据报的标准方法。PPP定义了一个可扩展的链路控制协议，并提出了一系列用于建立和配置不同网络层协议的网络控制协议。
This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links.
本文件定义了用于为PPP链路建立和配置远程桥接的网络控制协议。
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.
本文件淘汰了基于IEEE 802.1D-1993 MAC网桥[3]的RFC 1638。本文件通过包括IEEE 802.1D-1998 MAC网桥[8]和IEEE 802.1Q虚拟局域网（VLAN）[9]标准扩展了该规范。本文档还改进了协议，以支持高速交换局域网。
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
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
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.
有两种基本算法是业界用于局域网桥接的环境算法。更常见的算法称为“透明桥接”，IEEE 802.1已对扩展LAN配置进行了标准化。另一种称为“源路由桥接”，在IEEE 802.5令牌环LAN上很流行。
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].
IEEE已经将这两种方法组合成一种称为源路由透明（SRT）网桥的设备，它同时提供源路由和透明网桥。IEEE标准802.1D-1998[8]中规定了透明和SRT网桥。
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.
尽管IEEE委员会802.1G正在解决远程桥接[2]，但这两个标准都没有直接定义实现远程桥接的机制。从技术上讲，这将超出IEEE 802委员会的章程。但是，802.1D和802.1G都允许这样做。实现者可以将线路建模为单个MAC中继实体内的组件，或者建模为两个远程网桥之间的LAN介质。
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.
最初的IEEE 802.1D由IEEE 802.1Q[9]扩展，以提供对虚拟LAN的支持。虚拟局域网是交换式局域网的一个重要特征。
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].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[12]中的说明进行解释。
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}
{地址、接口、VLAN ID}
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.
通过保存接收到的每个LAN传输的源地址以及接收到该传输的接口的接口标识符来记录。支持虚拟LAN的网桥还将虚拟LAN ID保留在其转发数据库中。它接着检查目标地址是否在数据库中，如果是，则在目标和源位于同一接口时丢弃消息，或者将消息转发到指定的接口。在表中找不到目标地址的消息将转发到所有接口，但接收它的接口除外。此行为也适用于广播/多播帧。
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.
一个系统被选为“根”，它周期性地发出一个称为网桥协议数据单元（BPDU）的消息，由其所有相邻网桥听到。其中每一个都修改BPDU并将其传递给其邻居，直到它到达网络中的叶LAN段（在那里它死亡，没有其他邻居可以传递它），或者直到消息被具有到“根”的高级路径的网桥停止。在后一种情况下，将忽略接收BPDU的接口（该接口处于热备用状态，除BPDU外，不会向其发送任何通信量，从其接收的所有通信量都将被丢弃），直到拓扑更改强制重新计算网络。
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.
为了在多网桥环境中建立虚拟局域网，在网桥之间执行GVRP（GARP VLAN注册协议）以交换虚拟局域网信息。GVRP提供了一种机制，用于动态建立和更新他们对当前具有活动成员的虚拟LAN集的了解。
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.
为了减少网络中不必要的多播泛滥，网桥使用GARP多播注册协议交换组MAC地址。GMRP提供了一种机制，以便网桥可以知道应该在每个端口上转发哪些多播帧。
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.
存在两种基本类型的网桥——直接互连局域网的网桥，称为本地网桥；通过中间介质（如租用线路）互连局域网的网桥，称为远程网桥。PPP可用于连接远程网桥。
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.
IEEE 802.1G远程MAC桥接委员会提出了一种远程网桥模型，其中一组通过远程线路互连的两个或更多远程网桥被称为远程网桥组。在一个组中，通过执行生成树动态地形成远程网桥集群，作为可以在彼此之间传递帧的网桥集。
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.
该模型赋予远程线路LAN的基本属性，但不需要线路到虚拟LAN段的一对一映射。例如，三个相互连接的远程网桥A、B和C的模型可能是A和B之间的一个虚拟LAN网段以及B和C之间的另一个虚拟LAN网段的模型。但是，如果远程网桥B和C之间存在一条线路，实际上可以将一个帧从B直接发送到C，只要其外观是经过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.
因此，只要模型保持不变，IEEE 802.1G允许在路由优化和负载平衡等功能方面有很大的实现自由度。
For simplicity, we discuss Remote Bridging in this document in terms of two Remote Bridges connected by a single line.
为了简单起见，我们在本文档中讨论了通过单线连接的两个远程网桥的远程桥接。
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.
IEEE 802.1D委员会已经为任何允许其使用的MAC类型标准化了源路由。目前，支持源路由的MAC类型是FDDI和IEEE 802.5令牌环。
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].
IEEE标准仅将源路由定义为SRT网桥的一个组件。然而，已经实现了许多能够单独执行源路由的网桥。这些通常根据IBM令牌环网体系结构参考[1]或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.
在源路由方法中，发起系统负责指示消息应遵循的路径。如果消息直接从本地段发送出去，它就会这样做，包括一个称为路由信息字段（RIF）的可变长度MAC报头扩展。RIF由一个16位的标志和参数字组成，后跟零个或多个段和桥标识符。路由中的每个网桥根据此源路由列表确定是否应接受消息以及如何转发消息。
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帧。所有路由资源管理器（ARE）框架跟随所有可能到达目的地的路径。生成树
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.
Explorer（STE）帧仅遵循由桥接端口定义的路径，生成树算法已将这些路径置于转发状态。端口状态不适用于ARE或特定路由帧。目标系统使用特定路由帧回复ARE帧的每个副本，并使用ARE帧回复STE帧。在任何一种情况下，始发站都可以接收多个应答，从中选择将用于未来特定路由帧的路由。
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.
源路由算法要求网桥能够通过其网段和网桥标识符识别任何接口。当接收到具有RIF的数据包时，检查RIF中的布尔值，以确定是否以“正向”或“反向”意义检查段和网桥标识符。在其搜索中，网桥查找接收数据包的接口的段和网桥标识符，并将数据包转发给在其后的段和网桥标识符中标识的段。
GVRP and GMRP are available and effective on Source Routing networks.
GVRP和GMRP在源路由网络上可用且有效。
There is no Remote Source Route Bridge proposal in IEEE 802.1 at this time, although many vendors ship remote Source Routing Bridges.
目前在IEEE 802.1中没有远程源路由网桥方案，尽管许多供应商提供远程源路由网桥。
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.
我们允许将线路建模为“拆分”网桥两半之间的连接（拆分网桥模型），或两个网桥之间的LAN网段（独立网桥模型）。在后一种情况下，线路需要LAN段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.
默认情况下，PPP源路由网桥使用独立网桥模型。这一要求确保了在没有选项协商的情况下的互操作性。为了使用拆分网桥模型，系统必须成功协商网桥标识配置选项。
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.
尽管使用独立桥接器模型的系统不需要进行选项协商，但强烈建议使用该模型的系统协商线路标识配置选项。这样做将验证分配给线路的LAN段Id的正确配置。
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
当两个PPP系统使用拆分网桥模型时，将浏览器帧传输到PPP链路的系统必须代表两个系统更新RIF。此约束的目的是确保互操作性并保持桥接算法的简单性。例如，如果接收系统没有
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.
要知道传输系统是否更新了RIF，它必须扫描RIF并决定是否更新它。选择用于更新RIF的传输系统允许从PPP链路接收帧的系统转发帧，而不处理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.
假设源路由是在一行或一组行上配置的，那么关于STE帧的链路状态的细节由使用中的生成树协议定义。分裂桥或独立桥模型的选择不影响生成树操作。在这两种情况下，生成树协议在两个系统上独立执行。
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.
IEEE 802目前没有寻址在透明桥接和源路由之间转换的桥接。就本标准而言，此类设备可以是透明的，也可以是源路由桥，并将以这两种方式之一在线路上运行，就像在LAN上一样。
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.
针对不同的系统类型和用户配置，提供了多种服务。这些包括LAN帧校验和保存、LAN帧校验和生成、Tinygram压缩和识别闭合的LAN集。
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.
IEEE 802.1规定，扩展LAN必须具有与单个LAN相同的未检测到错误的概率。尽管对该算法存在相当大的争议，但没有提出过比最终接收机接收的LAN帧校验和与原始发射机计算的值相同的算法。当然，实现这一点需要线路协议从端到端保留LAN帧校验和。协议针对这种方法进行了优化。
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?".
协议针对LAN帧校验和保存进行了优化，这一事实提出了两个问题：“无论出于何种原因，无法轻松支持帧校验和保存的系统将使用什么方法？”“当系统生成一条没有预先计算的帧校验和的消息时，使用什么方法？”。
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.
然而，实施LAN帧校验和保护的站点必须已经解决这个问题，因为它们确实会产生流量。因此，所采用的解决方案是，对没有帧校验和的消息进行标记并跨行传输。
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.
当未实现LAN帧校验和保存的系统接收到具有嵌入式FCS的帧时，它会通过删除后面的四个八位字节来转换该帧以供自己使用。当任何系统将不包含嵌入式FCS的帧转发到LAN时，其转发方式会导致计算FCS。
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.
远程以太网桥接中的一个问题是，对桥接最有吸引力的协议在低速（64 KBPS及以下）线路上容易出现问题。通过观察定义这些协议的供应商通常在PDU中填充零的八位字节，可以部分缓解这种情况。因此，从（1）小于最小PDU大小且（2）存在LAN帧校验和的线路接收的以太网或IEEE 802.3 PDU，在LAN上传输之前，必须通过在最后四个八位组和PDU的其余部分之间插入零来填充。这些协议经常用于交互式会话，因此通常非常小。
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.
为了避免歧义，需要填充的PDU被显式标记。压缩由发射站选择，并且可能仅在低速线路上执行，可能在配置控制下执行。
The pseudo-code in Appendix B describes the algorithms.
附录B中的伪代码描述了算法。
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.
IEEE 802.1Q定义了虚拟局域网及其可交换VLAN标记帧格式。虚拟局域网允许用户在一个网桥中同时存在多个社区组。桥接社区由其VLAN ID标识。如果支持虚拟LAN的系统从LAN接收到帧，则该帧将仅发射到属于同一社区的LAN上。为了在一条线路上处理多个社区，IEEE 802.1Q定义了一个VLAN标记的帧。
For example, suppose you have the following configuration:
例如，假设您具有以下配置：
E1 +--+ +--+ E3
------------| | | |------------
| | W1 | |
|B1|------------|B2|
E2 | | | | E4
------------| | | |------------
+--+ +--+
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.
E1、E2、E3和E4是以太网LAN（或令牌环、FDDI等）。W1是广域网（PPP超过T1）。B1和B2是MAC级网桥。
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.
您希望E1和E3上的端站通信，并且希望E2和E4上的端站通信，但不希望E1和E3上的端站与E2和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.
这适用于单播、多播和广播流量。如果广播数据报源于E1，则只希望它传播到E3，而不希望传播到E2或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和E3构成一个虚拟LAN，E2和E4构成一个虚拟LAN，就好像实际使用了以下配置：
E1 +--+ W2 +--+ E3
------------|B3|------------|B4|------------
+--+ +--+
E1 +--+ W2 +--+ E3
------------|B3|------------|B4|------------
+--+ +--+
E2 +--+ W3 +--+ E4
------------|B5|------------|B6|------------
+--+ +--+
E2 +--+ W3 +--+ E4
------------|B5|------------|B6|------------
+--+ +--+
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.
桥接控制协议（BCP）负责配置、启用和禁用点到点链路两端的桥接协议模块。BCP使用与链路控制协议相同的数据包交换机制。直到PPP达到网络层协议阶段，才能交换BCP数据包。在到达此阶段之前收到的BCP数据包应被静默丢弃。
The Bridging Control Protocol is exactly the same as the Link Control Protocol [6] with the following exceptions:
桥接控制协议与链路控制协议[6]完全相同，但有以下例外：
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).
PPP信息字段中仅封装了一个BCP数据包，其中PPP协议字段指示类型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.
仅使用代码1至7（配置请求、配置确认、配置Nak、配置拒绝、终止请求、终止确认和代码拒绝）。其他代码应视为无法识别，并应导致代码拒绝。
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.
直到PPP达到网络层协议阶段，才能交换BCP数据包。在等待配置Ack或其他响应超时之前，实现应该准备等待身份验证和链路质量确定完成。建议只有在用户干预或可配置的时间量之后，实现才会放弃。
Configuration Option Types
配置选项类型
BCP has a distinct set of Configuration Options, which are defined in this document.
BCP有一组独特的配置选项，这些选项在本文档中定义。
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.
在任何桥接LAN通信或BPDU通信之前，PPP必须达到网络层协议阶段，桥接控制协议必须达到打开状态。
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).
PPP信息字段中只封装了一个桥接LAN通信量或BPDU，其中PPP协议字段指示hex 0031类型（桥接PDU）。
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.
通过PPP链路传输的桥接数据报的最大长度与PPP封装数据包的信息字段的最大长度相同。由于没有标准的方法来分割和重新组装桥接的PDU，支持桥接的PPP链路必须协商一个足够大的MRU，以支持稍后协商桥接支持的MAC类型。因为它们包含MAC头，所以即使桥接以太网帧也比默认的PPP MRU（1500个八位字节）大。
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.
强烈建议PPP网桥协议实现利用幻数环回检测和链路质量监控。802.1生成树协议是透明桥接和源路由（标准化）的组成部分，在正常运行期间是单向的。配置BPDU从根系统沿着叶子的一般方向发出，除了响应网络事件外，没有任何反向通信。
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.
在没有这种确定的情况下，传输系统必须像所有协议都需要保留顺序一样工作。许多主要设计用于单个LAN的协议都需要保留顺序。
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.
PPP多链路[7]及其多类扩展[11]可用于允许在一对系统之间使用多个PPP链路，而不会丢失消息序列性。它将链路组视为速度等于组中链路速度之和的单个链路。
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.
可以想象，网络管理器可能希望抑制链路上bpdu的交换，以便在逻辑上将两个区域划分为具有不同根（以及可能不同的生成树实现或算法）的独立生成树。为了做到这一点，他应该将两端配置为不在链路上交换BPDU。不支持任何生成树协议的实现必须静默地丢弃任何接收到的IEEE 802.1D BPDU数据包。
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:
如果一个网桥连接到一个旧的BCP网桥[10]，另一个网桥不能按照本规范操作。因此，可选择的办法是决定：
(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.
(a) 如果网桥想要终止连接，它会发送终止请求并终止连接。（b） 如果网桥希望运行连接，但不接收旧的BPDU，那么它唯一的选择就是运行时根本不在链路上生成树，这是危险的。它应该配置拒绝选项，并通知网络管理部门它已经这样做了。（c） 如果网桥选择完全向后兼容，它将发送Configure Ack并按照附录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.
如果新的管理内联选项和生成树协议配置选项都被拒绝，这表明对等方根本没有实现生成树协议，并且不理解这些选项，那么这是一个不完整的实现。出于安全原因，系统应停止尝试配置桥接，并记录事实。如果对等方配置拒绝选项以完全禁用生成树，则它理解该选项，但无法在其配置中遵守。它应该发送值为NULL的生成树协议配置选项。
Implementations SHOULD implement a backward compatibility mode.
实现应该实现向后兼容模式。
For Bridging LAN traffic, the format of the frame on the line is shown below. This format is used if the traffic does not include VLAN ID and priority.
对于桥接LAN流量，线路上的帧格式如下所示。如果流量不包括VLAN ID和优先级，则使用此格式。
The fields are transmitted from left to right.
字段从左向右传输。
802.3 Frame format (IEEE 802 Un-tagged Frame)
802.3帧格式（IEEE 802未标记帧）
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|0|Z|0| Pads | MAC Type | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|Z|0| Pads | MAC Type | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802.4/802.5/FDDI Frame format (IEEE 802 Un-tagged Frame)
802.4/802.5/FDDI帧格式（IEEE 802未标记帧）
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|0|Z|0| Pads | MAC Type | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|Z|0| Pads | MAC Type | 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
PPP协议
0x0031 for PPP Bridging
用于PPP桥接的0x0031
Flags
旗帜
bit F: Set if the LAN FCS Field is present bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum size bit 0: reserved, must be zero
位F：如果存在LAN FCS字段，则设置位Z：如果IEEE 802.3 Pad必须为零填充到最小大小，则设置位0：保留，必须为零
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.
任何PPP帧都可以在“可选数据链路层填充”字段中插入填充。这个数字告诉接收系统要去除多少pad八位字节。
MAC Type
MAC类型
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:
MAC类型字段的最新值在最近的“已分配编号”RFC[4]中指定。当前值分配如下：
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
0:保留1:IEEE 802.3/具有规范地址的以太网2:IEEE 802.4具有规范地址3:IEEE 802.5具有非规范地址4:FDDI具有非规范地址5-10:保留11:IEEE 802.5具有规范地址12:FDDI具有规范地址
"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.
“Canonical”是IEEE定义为标准地址表示的地址格式。在这种格式中，LAN上首先传输的每个字节中的位表示为最低有效位。相反，在非规范形式中，每个字节中首先传输的位表示为最高有效位。许多LAN接口实现使用非规范形式。在这两种格式中，字节都按传输顺序表示。
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.
如果实现支持的MAC类型是该MAC类型中编号较高的格式，则它还必须支持该MAC类型的编号较低的格式。例如，如果一个实现支持具有规范地址格式的FDDI，那么它还必须支持具有非规范地址格式的FDDI。本要求的目的是提供与本规范早期版本的向后兼容性。
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.
系统不得传输编号大于4的MAC类型，除非它已从其对等方接收到MAC支持配置选项，指示该对等方愿意接收该MAC类型的帧。
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.
在802.4、802.5和FDDI LAN上，目标MAC地址前有几个八位字节，其中一个八位字节受FCS保护。
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.
帧的MAC类型决定帧控制字段的内容。存在一个pad八位字节以提供32位数据包对齐。
Destination MAC Address
目的MAC地址
As defined by the IEEE. The MAC Type field defines the bit ordering.
根据IEEE的定义。MAC类型字段定义位顺序。
Source MAC Address
源MAC地址
As defined by the IEEE. The MAC Type field defines the bit ordering.
根据IEEE的定义。MAC类型字段定义位顺序。
LLC data
有限责任公司数据
This is the remainder of the MAC frame which is (or would be were it present) protected by the LAN FCS.
这是由LAN FCS保护的（或如果存在的话）MAC帧的剩余部分。
For example, the 802.5 Access Control field, and Status Trailer are not meaningful to transmit to another ring, and are omitted.
例如，802.5访问控制字段和状态拖车对于传输到另一个环没有意义，因此被省略。
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.
如果存在，这是由始发站计算（或似乎已由始发站计算）的LAN FCS。如果未设置LAN FCS标志，则该字段不存在，并且PDU短四个八位字节。
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.
任何PPP帧都可以在信息字段和帧FCS之间插入填充。Pads字段包含此填充的长度，不能超过15个八位字节。
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.
PPP LCP扩展[5]指定了一个自描述pad。鼓励实现将pad字段设置为零，并改用自描述pad。
Frame FCS
框架FCS
Mentioned primarily for clarity. The FCS used on the PPP link is separate from and unrelated to the LAN FCS.
提及主要是为了澄清。PPP链路上使用的FCS独立于LAN FCS，且与LAN FCS无关。
To connect two or more Virtual LAN segments, the frame MUST include its VLAN ID and priority. An IEEE 802 Tagged Frame may be used if the IEEE-802-Tagged-Frame Option is accepted by the peer. The format of the frame on the line is shown below.
要连接两个或多个虚拟LAN段，帧必须包含其VLAN ID和优先级。如果对等方接受IEEE-802-taged-Frame选项，则可以使用IEEE 802标记的帧。行上的帧格式如下所示。
The fields are transmitted from left to right.
字段从左向右传输。
802.3 Frame format (IEEE 802 Tagged Frame)
802.3帧格式（IEEE 802标记帧）
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|0|Z|0| Pads | MAC Type | Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address | 0x81 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pri |C| VLAN ID | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| potential line protocol pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|Z|0| Pads | MAC Type | Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address | 0x81 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pri |C| VLAN ID | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| potential line protocol pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802.4/802.5/FDDI Frame format (IEEE 802 Tagged Frame)
802.4/802.5/FDDI帧格式（IEEE 802标记帧）
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|0|Z|0| Pads | MAC Type | Pad Byte | Frame Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP-encoded TPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP-encoded TPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pri |C| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional Data Link Layer padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|Z|0| Pads | MAC Type | Pad Byte | Frame Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP-encoded TPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP-encoded TPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pri |C| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
PPP协议
0x0031 for PPP Bridging
用于PPP桥接的0x0031
Flags
旗帜
bit F: Set if the LAN FCS Field is present bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum size bit 0: reserved, must be zero
位F：如果存在LAN FCS字段，则设置位Z：如果IEEE 802.3 Pad必须为零填充到最小大小，则设置位0：保留，必须为零
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.
任何PPP帧都可以在“可选数据链路层填充”字段中插入填充。这个数字告诉接收系统要去除多少pad八位字节。
MAC Type
MAC类型
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:
MAC类型字段的最新值在最近的“已分配编号”RFC[4]中指定。当前值分配如下：
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
0:保留1:IEEE 802.3/具有规范地址的以太网2:IEEE 802.4具有规范地址3:IEEE 802.5具有非规范地址4:FDDI具有非规范地址5-10:保留11:IEEE 802.5具有规范地址12:FDDI具有规范地址
"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.
“Canonical”是IEEE定义为标准地址表示的地址格式。在这种格式中，LAN上首先传输的每个字节中的位表示为最低有效位。相反，在非规范形式中，每个字节中首先传输的位表示为最高有效位。许多LAN接口实现使用非规范形式。在这两种格式中，字节都按传输顺序表示。
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.
如果实现支持的MAC类型是该MAC类型中编号较高的格式，则它还必须支持该MAC类型的编号较低的格式。例如，如果一个实现支持具有规范地址格式的FDDI，那么它还必须支持具有非规范地址格式的FDDI。本要求的目的是提供与本规范早期版本的向后兼容性。
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.
系统不得传输编号大于4的MAC类型，除非它已从其对等方接收到MAC支持配置选项，指示该对等方愿意接收该MAC类型的帧。
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.
在802.4、802.5和FDDI LAN上，目标MAC地址前有几个八位字节，其中一个八位字节受FCS保护。
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.
帧的MAC类型决定帧控制字段的内容。存在一个pad八位字节以提供32位数据包对齐。
Destination MAC Address
目的MAC地址
As defined by the IEEE. The MAC Type field defines the bit ordering.
根据IEEE的定义。MAC类型字段定义位顺序。
Source MAC Address
源MAC地址
As defined by the IEEE. The MAC Type field defines the bit ordering.
根据IEEE的定义。MAC类型字段定义位顺序。
Pri 3 bit priority value as defined by IEEE 802.1D.
IEEE 802.1D定义的Pri 3位优先级值。
C Canonical flag as defined by IEEE 802.1Q. It must be set if RIF data is present in the LLC data.
C IEEE 802.1Q定义的规范标志。如果LLC数据中存在RIF数据，则必须设置该参数。
VLAN ID 12 bit VLAN identifier number as defined by IEEE 802.1Q.
VLAN ID由IEEE 802.1Q定义的12位VLAN标识符编号。
LLC data
有限责任公司数据
This is the remainder of the MAC frame which is (or would be were it present) protected by the LAN FCS.
这是由LAN FCS保护的（或如果存在的话）MAC帧的剩余部分。
For example, the 802.5 Access Control field, and Status Trailer are not meaningful to transmit to another ring, and are omitted.
例如，802.5访问控制字段和状态拖车对于传输到另一个环没有意义，因此被省略。
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.
如果存在，这是由始发站计算（或似乎已由始发站计算）的LAN FCS。如果未设置LAN FCS标志，则该字段不存在，并且PDU短四个八位字节。
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.
任何PPP帧都可以在信息字段和帧FCS之间插入填充。Pads字段包含此填充的长度，不能超过15个八位字节。
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.
PPP LCP扩展[5]指定了一个自描述pad。鼓励实现将pad字段设置为零，并改用自描述pad。
Frame FCS
框架FCS
Mentioned primarily for clarity. The FCS used on the PPP link is separate from and unrelated to the LAN FCS.
提及主要是为了澄清。PPP链路上使用的FCS独立于LAN FCS，且与LAN FCS无关。
To avoid network loops and improve redundancy, Bridges exchange a Spanning Tree Protocol data unit known as BPDU. Bridges also exchange a Generic Attributes Registration Protocol data unit to carry the GARP VLAN Registration Protocol (GVRP) data and GARP Multicast Registration Protocol (GMRP). GVRP allow the Bridges to create VLAN groups dynamically. GMRP allows bridges to filter Multicast data if the receiver is absent from the network. These Bridge protocols include Spanning Tree Protocol and GARP protocols data units are carried with a special destination address assigned by the IEEE.
为了避免网络循环和提高冗余，网桥交换一个称为BPDU的生成树协议数据单元。网桥还交换通用属性注册协议数据单元，以承载GARP VLAN注册协议（GVRP）数据和GARP多播注册协议（GMRP）。GVRP允许网桥动态创建VLAN组。如果接收器不在网络中，GMRP允许网桥过滤多播数据。这些网桥协议包括生成树协议和GARP协议。数据单元由IEEE分配一个特殊的目的地址。
These bridge protocols data units and GARP protocol data units must be carried in the frame format shown in section 4.2 or 4.3. The Bridge that receives these data units identifies these protocols based on the destination address in the frame format, just like the operation of receiving frames from a LAN segment.
这些网桥协议数据单元和GARP协议数据单元必须以第4.2节或第4.3节所示的帧格式进行传输。接收这些数据单元的网桥基于帧格式的目标地址识别这些协议，就像从LAN段接收帧的操作一样。
Bridge protocols and GARP protocols data units MUST be recognized by checking the destination addresses, which are assigned by IEEE.
网桥协议和GARP协议数据单元必须通过检查由IEEE分配的目标地址来识别。
01-80-c2-00-00-00 Bridge Group Address (used by STP) 01-80-c2-00-00-01 IEEE Std. 802.3x Full Duplex PAUSE operation 01-80-c2-00-00-10 Bridge Management Group Address 01-80-c2-00-00-20 GARP Multicast Registration Protocol (GMRP) 01-80-c2-00-00-21 GARP VLAN Registration Protocol (GVRP)
01-80-c2-00-00-00网桥组地址（STP使用）01-80-c2-00-00-01 IEEE标准802.3x全双工暂停操作01-80-c2-00-00-10网桥管理组地址01-80-c2-00-00-20 GARP多播注册协议（GMRP）01-80-c2-00-00-21 GARP VLAN注册协议（GVRP）
But there is one exception to this rule: if the bridge is connected to an old BCP bridge [10] and can support backward compatibility, it MUST send the BPDU in the old format described in Appendix A.
但该规则有一个例外：如果网桥连接到旧的BCP网桥[10]，并且可以支持向后兼容性，则必须以附录A中所述的旧格式发送BPDU。
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配置选项允许修改要协商的网络层协议的标准特性。如果配置请求数据包中未包含配置选项，则假定该配置选项的默认值。
BCP uses the same Configuration Option format defined for LCP [6], with a separate set of Options.
BCP使用为LCP[6]定义的相同配置选项格式，并带有一组单独的选项。
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:
BCP选项类型字段的最新值在最近的“已分配编号”RFC[4]中指定。当前值分配如下：
1 Bridge-Identification 2 Line-Identification 3 MAC-Support 4 Tinygram-Compression 5 LAN-Identification (obsoleted) 6 MAC-Address 7 Spanning-Tree-Protocol (old formatted) 8 IEEE 802 Tagged Frame 9 Management Inline
1网桥标识2线路标识3 MAC支持4 Tinygram压缩5 LAN标识（过时）6 MAC地址7生成树协议（旧格式）8 IEEE 802标记帧9管理内联
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.
网桥标识配置选项设计用于线路是连接虚拟或物理LAN段的半桥之间的接口时。由于这些远程网桥被建模为具有奇怪内部接口的单个网桥，因此每个远程网桥都需要知道相邻远程网桥的LAN网段和网桥编号。此选项不得包含在与线路标识选项相同的配置请求中。
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.
源路由描述符及其使用由IEEE 802.1D源路由附录规定。它通过配置的段号标识接口连接到的段，并通过段上的网桥号标识接口本身。
The two half bridges MUST agree on the bridge number. If a bridge number is not agreed upon, the Bridging Control Protocol MUST NOT enter the Opened state.
两座半桥必须在桥号上达成一致。如果未商定网桥编号，则网桥控制协议不得进入打开状态。
Since mismatched bridge numbers are indicative of a configuration error, a correct configuration requires that either the bridge declare the misconfiguration or choose one of the options. To allow two systems to proceed to the Opened state despite a mismatch, a system MAY change its bridge number to the higher of the two numbers. A higher-numbered system MUST NOT change its bridge number to a lower number. It should, however, inform the network administration of the misconfiguration in any case.
由于不匹配的网桥编号表示配置错误，因此正确的配置要求网桥声明错误配置或选择其中一个选项。为了允许两个系统在不匹配的情况下继续进入打开状态，系统可以将其网桥号更改为两个数字中的较高者。编号较高的系统不得将其网桥编号更改为较低的编号。但是，在任何情况下，它都应将错误配置告知网络管理部门。
By default, a system that does not negotiate this option is assumed to be configured not to use the model of the two systems as two halves of a single source-route bridge. It is instead
默认情况下，假定未协商此选项的系统配置为不将两个系统的模型用作单个源路由网桥的两半。而是
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宣布LAN段AAA，网桥#1，系统B宣布LAN段BBB，网桥#1，则生成的源路由配置（以适当的方向读取）为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#|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
1.
Length
长
4
4.
LAN Segment Number
局域网段号
A 12-bit number identifying the LAN segment, as defined in the IEEE 802.1D Source Routing Specification.
标识LAN段的12位数字，如IEEE 802.1D源路由规范中所定义。
Bridge Number
桥号
A 4-bit number identifying the bridge on the LAN segment, as defined in the IEEE 802.1D Source Routing Specification.
标识LAN段上网桥的4位数字，如IEEE 802.1D源路由规范中所定义。
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.
线路标识配置选项设计用于根据源路由算法为线路分配一个LAN网段编号，就像它是一个双系统LAN网段一样。
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.
源路由描述符及其使用由IEEE 802.1D源路由附录规定。它通过配置的段号标识接口连接到的段，并通过段上的网桥号标识接口本身。
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.
两个网桥必须在LAN网段编号上达成一致。如果LAN段编号未达成一致，桥接控制协议不得进入打开状态。
Since mismatched LAN segment numbers are indicative of a configuration error, a correct configuration requires that either the bridge declare the misconfiguration or choose one of the options. To allow two systems to proceed to the Opened state despite a mismatch, a system MAY change its LAN segment number to the higher of the two numbers. A higher-numbered system MUST NOT change its LAN segment number to a lower number. It should, however, inform the network administration of the misconfiguration in any case.
由于不匹配的LAN段号表示配置错误，因此正确的配置要求网桥声明错误配置或选择其中一个选项。为了允许两个系统在不匹配的情况下继续进入打开状态，系统可以将其LAN段号更改为两个编号中的较高者。编号较高的系统不得将其LAN段编号更改为较低的编号。但是，在任何情况下，它都应将错误配置告知网络管理部门。
By default, a system that does not negotiate this option is assumed to have its LAN segment number correctly configured by the user.
默认情况下，不协商此选项的系统假定其LAN段号由用户正确配置。
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#|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
2.
Length
长
4
4.
LAN Segment Number
局域网段号
A 12-bit number identifying the LAN segment, as defined in the IEEE 802.1D Source Routing Specification.
标识LAN段的12位数字，如IEEE 802.1D源路由规范中所定义。
Bridge Number
桥号
A 4-bit number identifying the bridge on the LAN segment, as defined in the IEEE 802.1D Source Routing Specification.
标识LAN段上网桥的4位数字，如IEEE 802.1D源路由规范中所定义。
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.
提供MAC支持配置选项是为了允许实现指示它们准备接收的通信量的种类。强烈建议协商这一方案。
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.
默认情况下，当实现未宣布其支持的MAC类型时，所有MAC类型都由对等方发送，在给定其他配置参数的情况下，这些MAC类型都能够被传输。接收器将丢弃其不支持的MAC类型。
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.
支持1600个八位字节MRU的设备可能不愿意支持802.5、802.4或FDDI，因为它们都支持大于1600个八位字节的帧。
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.
通过宣布它将支持的MAC类型，一个实现通知它的对等方所有未指定的MAC类型都将被丢弃。然后，对等方可以通过不发送不受支持的MAC类型来减少带宽使用。
Announcement of support for multiple MAC Types is accomplished by placing multiple options in the Configure-Request.
通过在配置请求中放置多个选项，可以宣布支持多种MAC类型。
The nature of this option is advisory only. This option MUST NOT be included in a Configure-Nak.
此选项的性质仅为咨询性质。此选项不得包含在配置Nak中。
A summary of the MAC-Support Option format is shown below. The fields are transmitted from left to right.
MAC支持选项格式的摘要如下所示。字段从左向右传输。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
3
3.
Length
长
3
3.
MAC Type
MAC类型
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.
此系统准备接收和服务的PDU MAC类型字段的一个值（之前在“桥接LAN流量”部分中描述）。
Description
描述
This Configuration Option permits the implementation to indicate support for Tinygram compression.
此配置选项允许实现指示对Tinygram压缩的支持。
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.
如果在配置请求中收到此选项，则该选项不得包含在配置Nak中。此选项可能包含在配置Nak中，以便提示对等方在其下一个配置请求中发送该选项。
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.
Tinygram压缩选项格式的摘要如下所示。字段从左向右传输。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
4.
Length
长
3
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.
如果该值为1，则启用Tinygram压缩。如果该值为2，Tinygram压缩将被禁用，并且不会发生解压缩。
The implementations need not agree on the setting of this parameter. One may be willing to decompress and the other not.
实现不需要对该参数的设置达成一致。一个愿意减压，另一个不愿意。
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.
MAC地址配置选项使实现能够宣布其MAC地址或分配一个MAC地址。MAC地址以IEEE 802.1标准格式表示，也就是说，多播位是地址的第一个八位组的最低有效位。
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.
如果系统希望公布其MAC地址，则发送指定MAC地址的选项。在配置请求中指定非零MAC地址时，必须忽略配置Nak中包含的任何此选项。
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.
如果实现希望分配MAC地址，则发送MAC地址为00-00-00-00-00-00的选项。没有地址分配机制的系统将配置拒绝该选项。
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.
配置Nak必须指定有效的IEEE 802.1格式物理地址；多播位必须为零。强烈建议（尽管不是强制性的）设置“本地分配的地址”位（第一个八位组中第二个最低有效位），表示本地分配的地址。
A summary of the MAC-Address Option format is shown below. The fields are transmitted from left to right.
MAC地址选项格式的摘要如下所示。字段从左向右传输。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
6
6.
Length
长
8
8.
MAC Byte
MAC字节
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.
802.1标准顺序的MAC地址的六个八位字节。为清楚起见，本地分配（L）和多播（M）位的位置如图所示。
Description
描述
The Spanning-Tree-Protocol Configuration enables a Bridge to remain compatible with older implementations of BCP [10]. This configuration option is, however, incompatible with the Management-Inline option, which enables a bridge to implement the many protocols that IEEE now expects a bridge to be able to use.
生成树协议配置使网桥能够与BCP的旧实现保持兼容[10]。但是，此配置选项与管理内联选项不兼容，后者使网桥能够实现IEEE现在期望网桥能够使用的许多协议。
If the peer rejects the Management-Inline configuration option, by sending configure-reject, it must be an implementation of [10], which is described in Appendix A. The system may optionally terminate the negotiation or offer to negotiate in that manner.
如果对等方通过发送configure reject拒绝管理内联配置选项，则该选项必须是附录A中所述的[10]的一个实现。系统可以选择终止协商或以这种方式提供协商。
In this case, if both bridges support a spanning tree protocol, they MUST agree on the protocol to be supported. The old BPDU described in Appendix A MUST be used rather than the format shown in section 4.2 or 4.3. 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.
在这种情况下，如果两个网桥都支持生成树协议，那么它们必须就要支持的协议达成一致。必须使用附录A中所述的旧BPDU，而不是第4.2节或第4.3节中所示的格式。当两者不一致时，应使用两个生成树协议中编号较低的协议。要解决冲突，使用编号较低协议的系统应配置Nak选项，建议使用自己的协议。如果未就生成树协议达成一致，除非一个系统不支持任何生成树协议，否则桥接控制协议不得进入打开状态。
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
大多数系统将只参与一个生成树协议。如果一个系统希望同时参与多个生成树协议，它可以在单个生成树协议配置选项中包括所有适当的协议类型。协议类型必须以递增的数字顺序指定。为了在协商期间进行比较，必须将协议编号视为单个编号。例如，如果系统A包括协议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.
和03，系统B指示协议03，系统B应配置Nak并指示协议类型03，因为0103大于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 MUST either silently discard or respond to other received BPDU packets with an LCP Protocol-Reject packet in this case.
默认情况下，实现必须支持IEEE 802.1D生成树或不支持生成树协议。不支持任何生成树协议的实现必须以静默方式丢弃任何接收到的IEEE 802.1D BPDU数据包，并且在这种情况下必须以LCP协议拒绝数据包静默地丢弃或响应其他接收到的BPDU数据包。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Protocol 1 | Protocol 2 | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Protocol 1 | Protocol 2 | ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
类型
7
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.
2个八位字节加上1个额外的八位字节用于积极支持的每个协议。大多数系统只支持一个生成树协议，因此长度为3。
Protocol n
协议n
Each Protocol field is one octet and indicates a desired spanning tree protocol. Up-to-date values of the Spanning-Tree-Protocol field are specified as PPP DLL numbers in the most recent "Assigned Numbers" RFC [4]. Current values are assigned as follows:
每个协议字段是一个八位字节，表示所需的生成树协议。生成树协议字段的最新值在最近的“已分配编号”RFC[4]中指定为PPP DLL编号。当前值分配如下：
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
0 Null（不支持生成树协议）1 IEEE 802.1D生成树2 IEEE 802.1G扩展生成树协议3 IBM源路由生成树协议4 DEC LANbridge 100生成树协议
Description
描述
This configuration option permits the implementation to indicate support for IEEE 802 Tagged Frame. Negotiation of this option is strongly recommended.
此配置选项允许实现指示对IEEE 802标记帧的支持。强烈建议协商这一方案。
A device supporting IEEE 802 Tagged Frame must be willing to support IEEE 802 Tagged Frame shown in section 4.3.
支持IEEE 802标记帧的设备必须愿意支持第4.3节所示的IEEE 802标记帧。
By default, IEEE 802 Tagged Frame is not supported. A system which does not negotiate, or negotiates this option to be disabled, should never receive a IEEE 802 Tagged Frame.
默认情况下，不支持IEEE 802标记帧。不协商或协商禁用此选项的系统不应接收IEEE 802标记的帧。
A summary of the IEEE 802 Tagged Frame Option format is shown below. The fields are transmitted from left to right.
IEEE 802标记帧选项格式的摘要如下所示。字段从左向右传输。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
类型
8
8.
Length
长
3
3.
Enable/Disable
启用/禁用
If the value is 1, IEEE-802-Tagged-Frame is enabled. If the value is 2, IEEE-802-Tagged-Frame is disabled, and MUST not send any IEEE-802-Tagged-Frame packet.
如果该值为1，则启用IEEE-802-Tagged-Frame。如果该值为2，则禁用IEEE-802-Tagged-Frame，并且不得发送任何IEEE-802-Tagged-Frame数据包。
Description
描述
The Management-Inline Configuration Option indicates that the system is willing to receive any IEEE-defined inter-bridge protocols, such as bridge protocol data units and GARP protocol data units, in the frame format shown in section 4.2 or 4.3.
管理内联配置选项表示系统愿意以第4.2节或第4.3节所示的帧格式接收任何IEEE定义的网桥间协议，如网桥协议数据单元和GARP协议数据单元。
Old BCP [10] implementations will use the negotiation procedure described in section 5.6. Implementations of this procedure will use this option to indicate compliance with the new BCP and may optionally negotiate the section 5.6 procedure, either on the same configure-request or in response to a configure-reject, as well. It is recommended that the configure-request only show this option when it is relevant, and that it reply with the Spanning-Tree-Protocol (old formatted) option if a configure-reject is received, as in the normal case one can expect it to be the quickest negotiation.
旧的BCP[10]实施将使用第5.6节所述的协商程序。本程序的实施将使用此选项指示是否符合新的BCP，并可根据相同的配置请求或响应配置拒绝，选择协商第5.6节程序。建议configure请求仅在相关时显示此选项，如果收到configure拒绝，则使用生成树协议（旧格式）选项进行回复，在正常情况下，这是最快的协商。
If a system receives a configure-request offering both alternatives, it should accept this procedure and reject the Spanning-Tree-Protocol (old format) option.
如果系统接收到提供两种备选方案的配置请求，则应接受此过程并拒绝生成树协议（旧格式）选项。
One can expect old BCP [10] implementations to not understand the option and issue a configure-reject.
可以预期旧的BCP[10]实现会不理解该选项并发出配置拒绝。
By default, Management-Inline is not allowed. A system which does not negotiate, or negotiates this option to be disabled, should never receive a Bridge Protocol data unit or GARP protocol data unit inline.
默认情况下，不允许管理内联。不协商或协商禁用此选项的系统不应内联接收网桥协议数据单元或GARP协议数据单元。
A summary of the Management-Inline Option format is shown below. The fields are transmitted from left to right.
管理内联选项格式的摘要如下所示。字段从左向右传输。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
9
9
Length
长
2
2.
This section enumerates changes made to old BCP [10] to produce this document.
本节列举了为编制本文件而对旧BCP[10]所做的更改。
(1) Remove all LAN Identification descriptions and replace with IEEE 802.1Q VLAN descriptions.
(1) 删除所有LAN标识说明，并替换为IEEE 802.1Q VLAN说明。
(2) Remove LAN Identification field from frame format and I flags from flag field. (3) Merge the Spanning Tree BPDU frame format with Bridged traffic.
(2) 从帧格式中删除LAN标识字段，从标志字段中删除I标志。（3） 将生成树BPDU帧格式与桥接流量合并。
This network control protocol compares the configurations of two devices and seeks to negotiate an acceptable subset of their intersection, to enable correct interoperation even in the presence of minor configuration or implementation differences. In the event that a major misconfiguration is detected, the negotiation will not complete successfully, resulting in the link coming down or not coming up. It is possible that if a bridged link comes up with a rogue peer, network information may be learned from forwarded multicast traffic, or denial of service attacks may be created by closing loops that should be detected and isolated or by offering rogue load.
此网络控制协议比较两个设备的配置，并寻求协商其交集的可接受子集，以实现正确的互操作，即使存在微小的配置或实现差异。如果检测到重大错误配置，协商将无法成功完成，从而导致链接关闭或无法打开。如果桥接链路出现恶意对等点，则可能会从转发的多播流量中学习网络信息，或者通过关闭应检测和隔离的环路或提供恶意负载来创建拒绝服务攻击。
Such attacks are not isolated to this NCP; any PPP NCP is subject to attack when connecting to a foreign or compromised device. However, no situations arise which are not common to all NCPs; any NCP that comes up with a rogue peer is subject to snooping and other attacks. Therefore, it is recommended that links on which this may happen should be configured to use PPP authentication during the LCP start-up phase.
此类攻击并非本NCP所独有；任何PPP NCP在连接到外部或受损设备时都会受到攻击。但是，不会出现所有NCP都不常见的情况；任何发现流氓对等点的NCP都会受到窥探和其他攻击。因此，建议将可能发生这种情况的链路配置为在LCP启动阶段使用PPP身份验证。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat."
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。”
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
This document proposes a total of two new BCP option numbers to be maintained by the IANA. These options (described in Section 5.1 and 5.2) are IEEE-802-Tagged-Frame and Management-Inline. The IANA has assigned the values 8 and 9 respectively for these option numbers.
本文件建议IANA总共维护两个新的BCP选项编号。这些选项（在第5.1节和第5.2节中描述）是IEEE-802-Tagged-Frame和管理内联选项。IANA分别为这些选项编号指定了值8和9。
This document is a product of the Point-to-Point Protocol Extensions Working Group.
本文档是点对点协议扩展工作组的产品。
This document is based on the PPP Bridging Control Protocol, RFC 1638 [10], edited by Rich Bowen of IBM and produced by the Point-to-Point Protocol Extensions Working Group. It extends that document by providing support for Virtual LANs as outlined in [9].
本文件基于PPP桥接控制协议RFC 1638[10]，由IBM的Rich Bowen编辑，由点对点协议扩展工作组编制。它通过提供对虚拟局域网的支持扩展了该文档，如[9]所述。
A. Spanning Tree Bridge PDU (old format)
A.生成树桥PDU（旧格式）
By default, Spanning Tree BPDUs MUST be encoded with a MAC or 802.2 LLC header as described in section 4.2 or 4.3 of this document. However, should the remote entity Configure-Reject the Management-Inline option, thereby indicating that it is a purely RFC 1638 compliant device, the local entity may subsequently encode BPDUs as described in section 4.3 of RFC 1638 provided that use of a suitable non-NULL STP protocol across the link is successfully negotiated using the (old) Spanning-Tree-Protocol option.
默认情况下，生成树BPDU必须使用MAC或802.2 LLC头进行编码，如本文件第4.2节或第4.3节所述。然而，如果远程实体配置拒绝管理内联选项，从而表明它是一个完全符合RFC 1638的设备，则本地实体随后可以按照RFC 1638第4.3节所述对BPDU进行编码，前提是使用（旧）协议成功协商在链路上使用合适的非空STP协议生成树协议选项。
This is the Spanning Tree BPDU used in RFC 1638, 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.
这是RFC1638中使用的生成树BPDU，没有任何MAC或802.2 LLC头（这些头在功能上等同于地址、控制和PPP协议字段）。LAN Pad和帧校验和字段同样是多余的，不存在。
The Address and Control Fields are subject to LCP Address-and-Control-Field-Compression negotiation.
地址和控制字段接受LCP地址和控制字段压缩协商。
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.
配置为参与特定生成树协议并接收不同生成树协议的BPDU的PPP系统应使用LCP协议reject将其拒绝。配置为不参与任何生成树协议的系统必须静默地丢弃所有BPDU。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
生成树协议字段的最新值在最新的“分配编号”RFC[4]中指定。当前值分配如下：
Value (in hex) Protocol
值（十六进制）协议
0201 IEEE 802.1 (either 802.1D or 802.1G) 0203 IBM Source Route Bridge 0205 DEC LANbridge 100
0201 IEEE 802.1（802.1D或802.1G）0203 IBM源路由网桥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.
IEEE 802.1生成树协议帧的两个版本可以通过BPDU数据中的字段来区分。
BPDU data
BPDU数据
As defined by the specified Spanning Tree Protocol.
由指定的生成树协议定义。
B. Tinygram-Compression Pseudo-Code
B.Tinygram压缩伪码
PPP Transmitter:
PPP发射机：
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 */
}
}
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:
PPP接收器：
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 */
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 */
}
}
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 */
}
}
References
工具书类
[1] IBM, "Token-Ring Network Architecture Reference", 3rd edition, September 1989.
[1] IBM，“令牌环网络体系结构参考”，第3版，1989年9月。
[2] IEEE 802.1, "Draft Standard 802.1G: Remote MAC Bridging", P802.1G/D7, December 30, 1992.
[2] IEEE 802.1，“802.1G标准草案：远程MAC桥接”，P802.1G/D7，1992年12月30日。
[3] IEEE 802.1D-1993, "Media Access Control (MAC) Bridges", ISO/IEC 15802-3:1993 ANSI/IEEE Std 802.1D, 1993 edition., July 1993.
[3] IEEE 802.1D-1993，“媒体访问控制（MAC）网桥”，ISO/IEC 15802-3:1993 ANSI/IEEE标准802.1D，1993年版，1993年7月。
[4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[5] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.
[5] 辛普森W.，“PPP LCP扩展”，RFC 15701994年1月。
[6] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[6] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[7] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[7] K.Sklower、Lloyd、B.McGregor、G.Carr、D.和T.Coradetti，“PPP多链路协议（MP）”，RFC 1990，1996年8月。
[8] IEEE 802.1D-1998, "Information technology - Telecommunications and Information exchange between systems - Local and metropolitan area networks - Common Specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998.
[8] IEEE 802.1D-1998，“信息技术-系统间电信和信息交换-局域网和城域网-通用规范-第3部分：媒体访问控制（MAC）网桥：修订版。这是ISO/IEC 10038:1993、802.1j-1992和802.6k-1992的修订版。它包含了P802.11c、P802.1p和P802.12e。”ISO/IEC 15802-3:1998。
[9] IEEE 802.1Q, ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998.
[9] IEEE 802.1Q，ANSI/IEEE标准802.1Q，“局域网和城域网的IEEE标准：虚拟桥接局域网”，1998年。
[10] Baker, F. and R. Bowen, "PPP Bridging Control Protocol (BCP)", RFC 1638, June 1994.
[10] Baker，F.和R.Bowen，“PPP桥接控制协议（BCP）”，RFC16381994年6月。
[11] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[11] Bormann，C.，“多链路PPP的多类扩展”，RFC 2686，1999年9月。
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[12] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Authors' Addresses
作者地址
Questions about this memo can also be directed to:
有关本备忘录的问题，请联系：
Mitsuru Higashiyama Anritsu Corporation 1800 Onna, Atsugi-shi, Kanagawa-prf., 243-8555 Japan
日本神奈川县Atsugi shi Onna 1800号东山安立商事株式会社，邮编243-8555
Phone: +81 (46) 296-6625
EMail: Mitsuru.Higashiyama@yy.anritsu.co.jp
Phone: +81 (46) 296-6625
EMail: Mitsuru.Higashiyama@yy.anritsu.co.jp
Fred Baker 519 Lado Drive Santa Barbara, California 93111
弗雷德·贝克加利福尼亚州圣巴巴拉拉多大道519号，邮编93111
EMail: fred.baker@cisco.com
EMail: fred.baker@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。