📄 rfc2878.txt
字号:
Description The MAC-Support Configuration Option is provided to permit implementations to indicate the sort of traffic they are prepared to receive. Negotiation of this option is strongly recommended. By default, when an implementation does not announce the MAC Types that it supports, all MAC Types are sent by the peer which are capable of being transported given other configuration parameters. The receiver will discard those MAC Types that it does not support. A device supporting a 1600 octet MRU might not be willing to support 802.5, 802.4 or FDDI, which each support frames larger than 1600 octets. By announcing the MAC Types it will support, an implementation is advising its peer that all unspecified MAC Types will be discarded. The peer MAY then reduce bandwidth usage by not sending the unsupported MAC Types. Announcement of support for multiple MAC Types is accomplished by placing multiple options in the Configure-Request. The nature of this option is advisory only. This option MUST NOT be included in a Configure-Nak. A summary of the MAC-Support Option format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | MAC Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3Higashiyama & Baker Standards Track [Page 25] RFC 2878 PPP Bridging Control Protocol (BCP) July 2000 Length 3 MAC Type One of the values of the PDU MAC Type field (previously described in the "Bridged LAN Traffic" section) that this system is prepared to receive and service.5.4. Tinygram-Compression Description This Configuration Option permits the implementation to indicate support for Tinygram compression. Not all systems are prepared to make modifications to messages in transit. On high speed lines, it is probably not worth the effort. This option MUST NOT be included in a Configure-Nak if it has been received in a Configure-Request. This option MAY be included in a Configure-Nak in order to prompt the peer to send the option in its next Configure-Request. By default, no compression is allowed. A system which does not negotiate, or negotiates this option to be disabled, should never receive a compressed packet. A summary of the Tinygram-Compression Option format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Enable/Disable| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 Length 3Higashiyama & Baker Standards Track [Page 26] RFC 2878 PPP Bridging Control Protocol (BCP) July 2000 Enable/Disable If the value is 1, Tinygram-Compression is enabled. If the value is 2, Tinygram-Compression is disabled, and no decompression will occur. The implementations need not agree on the setting of this parameter. One may be willing to decompress and the other not.5.5. MAC-Address Description The MAC-Address Configuration Option enables the implementation to announce its MAC address or have one assigned. The MAC address is represented in IEEE 802.1 Canonical format, which is to say that the multicast bit is the least significant bit of the first octet of the address. If the system wishes to announce its MAC address, it sends the option with its MAC address specified. When specifying a non-zero MAC address in a Configure-Request, any inclusion of this option in a Configure-Nak MUST be ignored. If the implementation wishes to have a MAC address assigned, it sends the option with a MAC address of 00-00-00-00-00-00. Systems that have no mechanism for address assignment will Configure- Reject the option. A Configure-Nak MUST specify a valid IEEE 802.1 format physical address; the multicast bit MUST be zero. It is strongly recommended (although not mandatory) that the "locally assigned address" bit (the second least significant bit in the first octet) be set, indicating a locally assigned address. A summary of the MAC-Address Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |MAC byte 1 |L|M| MAC byte 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC byte 3 | MAC byte 4 | MAC byte 5 | MAC byte 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Higashiyama & Baker Standards Track [Page 27] RFC 2878 PPP Bridging Control Protocol (BCP) July 2000 Type 6 Length 8 MAC Byte Six octets of MAC address in 802.1 Canonical order. For clarity, the position of the Local Assignment (L) and Multicast (M) bits are shown in the diagram.5.6. Spanning-Tree-Protocol (old format) 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. 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. 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. 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 01Higashiyama & Baker Standards Track [Page 28] RFC 2878 PPP Bridging Control Protocol (BCP) July 2000 and 03 and System B indicates protocol 03, System B should Configure-Nak and indicate a protocol type of 03 since 0103 is greater than 03. By default, an implementation MUST either support the IEEE 802.1D spanning tree or support no spanning tree protocol. An implementation that does not support any spanning tree protocol MUST silently discard any received IEEE 802.1D BPDU packets, and MUST either silently discard or respond to other received BPDU packets with an LCP Protocol-Reject packet in this case. 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 | .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 7 Length 2 octets plus 1 additional octet for each protocol that will be actively supported. Most systems will only support a single spanning tree protocol, resulting in a length of 3. Protocol n Each Protocol field is one octet and indicates a desired spanning tree protocol. Up-to-date values of the Spanning-Tree-Protocol field are specified as PPP DLL numbers in the most recent "Assigned Numbers" RFC [4]. Current values are assigned as follows: Value Protocol 0 Null (no Spanning Tree protocol supported) 1 IEEE 802.1D spanning tree 2 IEEE 802.1G extended spanning tree protocol 3 IBM Source Route Spanning tree protocol 4 DEC LANbridge 100 Spanning tree protocolHigashiyama & Baker Standards Track [Page 29] RFC 2878 PPP Bridging Control Protocol (BCP) July 20005.7. IEEE-802-Tagged-Frame Description This configuration option permits the implementation to indicate support for IEEE 802 Tagged Frame. Negotiation of this option is strongly recommended. A device supporting IEEE 802 Tagged Frame must be willing to support IEEE 802 Tagged Frame shown in section 4.3. 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. A summary of the IEEE 802 Tagged Frame Option format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Enable/Disable| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 Length 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.5.8. Management-Inline 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.Higashiyama & Baker Standards Track [Page 30] RFC 2878 PPP Bridging Control Protocol (BCP) July 2000 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 wel⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -