📄 rfc1638.txt
字号:
Baker & Bowen [Page 7]
RFC 1638 PPP Bridging June 1994
Each bridge port may be considered to have two additional variables
associated with it: "domain" and "checkDomain".
The variable "domain" (a 32-bit unsigned integer) is assigned a value
that uniquely labels a set of bridge ports in an extended network,
with a default value of 1, and the values of 0 and 0xffffffff being
reserved.
The variable "checkDomain" (a boolean) controls whether this value is
used to filter output to a bridge port. The variable "checkDomain"
is generally set to the boolean value True for LAN bridge ports, and
set to the boolean value False for WAN bridge ports.
The action of the bridge is then as modified as expressed in the
following C code fragments:
On a packet being received from a bridge port:
if (domainNotPresentWithPacket) {
packetInformation.domain = portInformation[inputPort].domain;
} else {
packetInformation.domain = domainPresentWithPacket;
}
On a packet being transmitted from a bridge port:
if (portInformation[outputPort].checkDomain &&
portInformation[outputPort] != packetInformation.domain) {
discardPacket();
return;
}
For example, suppose you have the following configuration:
E1 +--+ +--+ E3
------------| | | |------------
| | W1 | |
|B1|------------|B2|
E2 | | | | E4
------------| | | |------------
+--+ +--+
E1, E2, E3, and E4 are Ethernet LANs (or Token Ring, FDDI, etc.). W1
is a WAN (PPP over T1). B1 and B2 are MAC level bridges.
You want End Stations on E1 and E3 to communicate, and you want End
Stations on E2 and E4 to communicate, but you do not want End
Stations on E1 and E3 to communicate with End Stations on E2 and E4.
Baker & Bowen [Page 8]
RFC 1638 PPP Bridging June 1994
This is true for Unicast, Multicast, and Broadcast traffic. If a
broadcast datagram originates on E1, you want it only to be
propagated to E3, and not on E2 or E4.
Another way of looking at it is that E1 and E3 form a Virtual LAN,
and E2 and E4 form a Virtual LAN, as if the following configuration
were actually being used:
E1 +--+ W2 +--+ E3
------------|B3|------------|B4|------------
+--+ +--+
E2 +--+ W3 +--+ E4
------------|B5|------------|B6|------------
+--+ +--+
To accomplish this (using the LAN Identification option), B1 and B2
negotiate this option on, and send datagrams with bit 6 set to 1,
with the LAN ID field inserted in the frame. Traffic on E1 and E3
would be assigned LAN ID 1, and traffic on E2 and E4 would be
assigned LAN ID 2. Thus B1 and B2 can separate traffic going over
W1.
Note that execution of the spanning tree algorithm may result in the
subdivision of a domain. The administrator of LAN domains must
ensure, through spanning tree configuration and topology design, that
such subdivision does not occur.
4. A PPP Network Control Protocol for Bridging
The Bridging Control Protocol (BCP) is responsible for configuring,
enabling and disabling the bridge protocol modules on both ends of
the point-to-point link. BCP uses the same packet exchange mechanism
as the Link Control Protocol. BCP packets may not be exchanged until
PPP has reached the Network-Layer Protocol phase. BCP packets
received before this phase is reached SHOULD be silently discarded.
The Bridging Control Protocol is exactly the same as the Link Control
Protocol [6] with the following exceptions:
Frame Modifications
The packet may utilize any modifications to the basic frame format
which have been negotiated during the Link Establishment phase.
Implementations SHOULD NOT negotiate Address-and-Control-Field-
Compression or Protocol-Field-Compression on other than low speed
links.
Baker & Bowen [Page 9]
RFC 1638 PPP Bridging June 1994
Data Link Layer Protocol Field
Exactly one BCP packet is encapsulated in the PPP Information
field, where the PPP Protocol field indicates type hex 8031 (BCP).
Code field
Only Codes 1 through 7 (Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
and Code-Reject) are used. Other Codes SHOULD be treated as
unrecognized and SHOULD result in Code-Rejects.
Timeouts
BCP packets may not be exchanged until PPP has reached the
Network-Layer Protocol phase. An implementation SHOULD be
prepared to wait for Authentication and Link Quality Determination
to finish before timing out waiting for a Configure-Ack or other
response. It is suggested that an implementation give up only
after user intervention or a configurable amount of time.
Configuration Option Types
BCP has a distinct set of Configuration Options, which are defined
in this document.
4.1. Sending Bridge Frames
Before any Bridged LAN Traffic or BPDUs may be communicated, PPP MUST
reach the Network-Layer Protocol phase, and the Bridging Control
Protocol MUST reach the Opened state.
Exactly one Bridged LAN Traffic or BPDU is encapsulated in the PPP
Information field, where the PPP Protocol field indicates type hex
0031 (Bridged PDU).
4.1.1. Maximum Receive Unit Considerations
The maximum length of a Bridged datagram transmitted over a PPP link
is the same as the maximum length of the Information field of a PPP
encapsulated packet. Since there is no standard method for
fragmenting and reassembling Bridged PDUs, PPP links supporting
Bridging MUST negotiate an MRU large enough to support the MAC Types
that are later negotiated for Bridging support. Because they include
the MAC headers, even bridged Ethernet frames are larger than the
default PPP MRU of 1500 octets.
Baker & Bowen [Page 10]
RFC 1638 PPP Bridging June 1994
4.1.2. Loopback and Link Quality Monitoring
It is strongly recommended that PPP Bridge Protocol implementations
utilize Magic Number Loopback Detection and Link-Quality-Monitoring.
The 802.1 Spanning Tree protocol, which is integral to both
Transparent Bridging and Source Routing (as standardized), is
unidirectional during normal operation. Configuration BPDUs emanate
from the Root system in the general direction of the leaves, without
any reverse traffic except in response to network events.
4.1.3. Message Sequence
The multiple link case requires consideration of message
sequentiality. The transmitting system may determine either that the
protocol being bridged requires transmissions to arrive in the order
of their original transmission, and enqueue all transmissions on a
given conversation onto the same link to force order preservation, or
that the protocol does NOT require transmissions to arrive in the
order of their original transmission, and use that knowledge to
optimize the utilization of several links, enqueuing traffic to
multiple links to minimize delay.
In the absence of such a determination, the transmitting system MUST
act as though all protocols require order preservation. Many
protocols designed primarily for use on a single LAN require order
preservation.
Work is currently in progress on a protocol to allow use of multiple
PPP links [7]. If approved, this protocol will allow use of multiple
links while maintaining message sequentiality for Bridged LAN Traffic
and BPDU frames.
4.1.4. Separation of Spanning Tree Domains
It is conceivable that a network manager might wish to inhibit the
exchange of BPDUs on a link in order to logically divide two regions
into separate Spanning Trees with different Roots (and potentially
different Spanning Tree implementations or algorithms). In order to
do that, he should configure both ends to not exchange BPDUs on a
link. An implementation that does not support any spanning tree
protocol MUST silently discard any received IEEE 802.1D BPDU packets,
and MUST either silently discard or respond to other received BPDU
packets with an LCP Protocol-Reject packet.
Baker & Bowen [Page 11]
RFC 1638 PPP Bridging June 1994
4.2. Bridged LAN Traffic
For Bridging LAN traffic, the format of the frame on the line is
shown below. The fields are transmitted from left to right.
802.3 Frame format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address and Control | 0x00 | 0x31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|I|Z|0| Pads | MAC Type | LAN ID high word (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN ID low word (optional) | Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| potential line protocol pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Baker & Bowen [Page 12]
RFC 1638 PPP Bridging June 1994
802.4/802.5/FDDI Frame format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address and Control | 0x00 | 0x31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|I|Z|0| Pads | MAC Type | LAN ID high word (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN ID low word (optional) | Pad Byte | Frame Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional Data Link Layer padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address and Control
As defined by the framing in use.
PPP Protocol
0x0031 for PPP Bridging
Flags
bit F: Set if the LAN FCS Field is present
bit I: Set if the LAN ID Field is present
bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum size
bit 0: reserved, must be zero
Pads
Any PPP frame may have padding inserted in the "Optional Data Link
Layer Padding" field. This number tells the receiving system how
many pad octets to strip off.
Baker & Bowen [Page 13]
RFC 1638 PPP Bridging June 1994
MAC Type
Up-to-date values of the MAC Type field are specified in the most
recent "Assigned Numbers" RFC [4]. Current values are assigned as
follows:
0: reserved
1: IEEE 802.3/Ethernet with canonical addresses
2: IEEE 802.4 with canonical addresses
3: IEEE 802.5 with non-canonical addresses
4: FDDI with non-canonical addresses
5-10: reserved
11: IEEE 802.5 with canonical addresses
12: FDDI with canonical addresses
"Canonical" is the address format defined as standard address
representation by the IEEE. In this format, the bit within each
byte that is to be transmitted first on a LAN is represented as
the least significant bit. In contrast, in non-canonical form,
the bit within each byte that is to be transmitted first is
represented as the most-significant bit. Many LAN interface
implementations use non-canonical form. In both formats, bytes
are represented in the order of transmission.
If an implementation supports a MAC Type that is the higher-
numbered format of that MAC Type, then it MUST also support the
lower-numbered format of that MAC Type. For example, if an
implementation supports FDDI with canonical address format, then
it MUST also support FDDI with non-canonical address format. The
purpose of this requirement is to provide backward compatibility
with earlier versions of this specification.
A system MUST NOT transmit a MAC Type numbered higher than 4
unless it has received from its peer a MAC-Support Configuration
Option indicating that the peer is willing to receive frames of
that MAC Type.
LAN ID
This optional 32-bit field identifies the Community of LANs which
may be interested to receive this frame. If the LAN ID flag is
not set, then this field is not present, and the PDU is four
octets shorter.
Frame Control
On 802.4, 802.5, and FDDI LANs, there are a few octets preceding
the Destination MAC Address, one of which is protected by the FCS.
Baker & Bowen [Page 14]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -