As per Relevance of the word compression, we have this rfc below:
Network Working Group F. Baker,
Request for Comments: 1220
April 1991
Point-to-Point Protocol Extensions for
1. Status of this
This document defines an extension of the Internet Point-to-
Protocol (PPP) described in RFC 1171, targeting the use of Point-to
Point lines for Remote Bridging. It is a product of the Point-to
Point Protocol Extensions Working Group of the Internet
Task Force (IETF).
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
2. Historical
Two basic algorithms are ambient in the industry for Bridging
Local Area Networks. The more common algorithm is
"Transparent Bridging" and has been standardized for Extended
configurations by IEEE 802.1. IEEE 802.5 has proposed an
approach, called "Source Routing", and is in the process
standardizing that approach for IEEE 802.5 extended networks
Although there is a subcommittee of IEEE 802.1 addressing
bridging, neither standard directly defines Remote Bridging per se
as that would technically be beyond the IEEE 802 committee's charter
Both allow for it, however, modeling the line as an
interface between half-bridges
This document assumes that the devices at either end of a serial
- have agreed to utilize the RFC 1171 line discipline in some form
- may have agreed, by some other means, to exchange
protocols on the line interspersed with each other and with
bridged PDUs
- may be willing to use the link as a vehicle for Remote Bridging
- may have multiple point-to-point links that are configured
parallel to simulate a single line of higher speed
Point-to-Point Protocol Extensions Working Group [Page 1]
RFC 1220 Bridging Point-to-Point Protocol April 1991
reliability, but message sequence issues are solved by
transmitting end
3. General
3.1. Link Quality
It is strongly recommended that Point-to-Point Bridge
implementations utilize Magic Number Loopback Detection and Link
Quality-Monitoring. This is because the 802.1 Spanning
protocol, which is integral to both Transparent Bridging and
Routing (as standardized), is unidirectional during normal operation
with HELLO PDUs emanating from the Root System in the
direction of the leaves, without any reverse traffic except
response to network events
3.2. Message
The multiple link case requires consideration of
sequentiality. The transmitting station must determine either
the protocol being bridged requires transmissions to arrive in
order of their original transmission, and enqueue all
on a given conversation onto the same link to force
preservation, or that the protocol does NOT require transmissions
arrive in the order of their original transmission, and use
knowledge to optimize the utilization of the several links,
traffic to links to minimize delay
In the absence of such a determination, the transmitting station
act as though all protocols require order preservation;
protocols designed primarily for use on a single LAN in fact do.
protocol could be described to maintain message sequentiality
multiple links, either by sequence numbering or by fragmentation
re-assembly, but this is neither elegant nor absolutely necessary
3.3. Maximum Receive Unit
Please note that the negotiated MRU must be large enough to
the MAC Types that are negotiated for support, there being
fragmentation and re-assembly. Even Ethernet frames are larger
the default MRU of 1500 octets
3.4. Separation of Spanning Tree
It is conceivable that a network manager might wish to inhibit
exchange of BPDUs on a link in order to logically divide two
into separate Spanning Trees with different Roots (and
different Spanning Tree implementations or algorithms). In order
Point-to-Point Protocol Extensions Working Group [Page 2]
RFC 1220 Bridging Point-to-Point Protocol April 1991
do that, he must configure both ends to not exchange BPDUs on a link
For the sake of robustness, a bridge which is so configured
silently discard the BPDU of its neighbor, should it receive one
4. IEEE 802.1 Transparent
4.1. Overview of IEEE 802.1 Transparent
As a favor to the uninitiated, let us first describe
Bridging. Essentially, the bridges in a network operate as
entities, largely unaware of each others' presence. A
Bridge maintains a Forwarding Database consisting
{address, interface
records by saving the Source Address of each LAN transmission that
receives along with the interface identifier for the interface it
received on. It goes on to check whether the Destination Address
in the database, and if so, either discards the message (if
destination and source are located at the same interface) or
the message to the indicated interface. A message whose
Address is not found in the table is forwarded to all
except the one it was received on; this describes Broadcast/
behavior as well
The obvious fly in the ointment is that redundant paths in
network cause indeterminate (nay, all too determinate)
behavior to occur. To prevent this, a protocol called the
802.1(d) Spanning Tree Protocol is executed between the bridges
detect and logically remove redundant paths from the network
One system is elected as the "Root", which periodically emits
message called a Bridge Hello Protocol Data Unit, or BPDU, heard
all of its neighboring bridges. Each of these modifies and
the BPDU on to its neighbors, and they to theirs, until it arrives
the leaf LAN segments in the network (where it dies, having
further neighbors to pass it along) or until the message is
by a bridge which has a superior path to the "Root". In this
case, the interface the BPDU was received on is ignored (i.e., it
placed in a Hot Standby status, no traffic is emitted onto it
the BPDU, and all traffic received from it is discarded) until
topology change forces a recalculation of the network
4.2. IEEE 802.1 Remote Bridging
There exist two basic sorts of bridges - ones that interconnect
directly, called Local Bridges, and ones that interconnect LANs
an intermediate medium such as a leased line, called Remote Bridges
Point-to-Point Protocol Extensions Working Group [Page 3]
RFC 1220 Bridging Point-to-Point Protocol April 1991
The Point-to-Point Protocol might be used by a Remote Bridge
There is more than one proposal within the IEEE 802.1
Committee for modeling the Remote Bridge. In one model,
interconnecting serial link(s) are treated in the same way that a
is, having a standard IEEE 802.1 Link State; in another, the
links operate in a mode quite different from the LANs that
interconnect. For the sake of simplicity of specification, the
model is adopted, although some of the good ideas from proponents
the second model are included or allowed for
Therefore, given that transparent bridging is configured on a line
set of lines, the specifics of the link state with respect to
bridge is defined by IEEE 802.1(d). The Bridge Protocol Data Unit
or BPDU, is defined there, as well as the algorithms for its use
It is assumed that, if a Point-to-Point Link neighbor receives
802.1 BPDUs without rejecting them with the RFC 1171 Protocol-
LCP PDU, Transparent Bridging is permitted on the link
4.3. IEEE 802.5 Source
The IEEE 802.5 Committee has defined a different approach to
for use on the Token Ring, called Source Routing. In this approach
the originating system has the responsibility of indicating what
that the message should follow. It does this, if the message
directed off the local ring, by including a variable length
header extension called the Routing Information Field, or RIF.
RIF consists of one 16 bit word of flags and parameters followed
zero or more ring-and-bridge identifiers. Each bridge en
determines from this "source route list" whether it should
the message and how to forward it
The algorithm for Source Routing requires the bridge to be able
identify any interface by its ring-and-bridge identifier, and to
able to identify any of its OTHER interfaces likewise. When a
is received which has the Routing Information Field (RIF) present,
boolean in the RIF is inspected to determine whether the ring-and
bridge identifiers are to be inspected in "forward" or "reverse
sense. In a "forward" search, the bridge looks for the ring-and
bridge identifier of the interface the packet was received on,
forwards the packet toward the ring identified in the ring-and-
identifier that follows it. In a "reverse" search, the bridge
for the ring-and-bridge identifier of the OTHER INTERFACE,
delivers the packet to the indicated interface if such is found
The algorithms for handling multicasts ("Functional Addresses"
"Group Addresses") have been the subject of much discussion in 802.5,
Point-to-Point Protocol Extensions Working Group [Page 4]
RFC 1220 Bridging Point-to-Point Protocol April 1991
and are likely to be the most troublesome for bridge implementations
Fortunately, they are beyond the scope of this document
4.4. IEEE 802.5 Remote Bridging
There is no Remote Bridge proposal in IEEE 802.5 at this time
although IBM ships a remote Source Routing Bridge. Simplicity
dictate that we choose the same model for IEEE 802.5 Source
that was selected for IEEE 802.1, but necessity requires a
number for the line in some cases. We allow for both models
Given that source routing is configured on a line or set of lines
the specifics of the link state with respect to the bridge is
by the IEEE 802.5 Addendum on Source Routing. The requisite PDUs
calculating the spanning tree (used for assuring that each ring
receive at most one copy of a multicast) are defined there, as
as the algorithms for their use. MAC PDUs (Beacon, Ring Management
etc) are specific to the MAU technology and are not exchanged on
line
4.5. Source Routing to Transparent Bridge
IEEE 802 also has a subcommittee looking at the interoperation
Transparent Bridging and Source Routing. For the purposes of
standard, such a device is both a transparent and a source
bridge, and will act on the line in both ways, just as it does on
LAN
5. Traffic
Several services are provided for the benefit of different
types and user configurations. These include LAN Frame
Preservation, LAN Frame Checksum Generation, Tinygram Compression
and the identification of closed sets of LANs
5.1. LAN Frame Checksum
IEEE 802.1 stipulates that the Extended LAN must enjoy the
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
Checksum received by the ultimate receiver be the same
calculated by the original transmitter. Achieving this requires,
course, that the line protocols preserve the LAN Frame Checksum
end to end. The protocol is optimized towards this approach
Point-to-Point Protocol Extensions Working Group [Page 5]
RFC 1220 Bridging Point-to-Point Protocol April 1991
5.2. Traffic having no LAN Frame
The fact that the protocol is optimized towards LAN Frame
preservation raises twin questions: "What is the approach to be
by systems which, for whatever reason, cannot easily support
Checksum preservation?" and "What is the approach to be used when
system originates a message, which therefore has no Frame
precalculated?".
Surely, one approach would be to require stations to calculate
Frame Checksum in software if hardware support were unavailable;
would meet with profound dismay, and would raise serious questions
interpretation in a Bridge/Router
However, stations which implement LAN Frame Checksum
must already solve this problem, as they do originate traffic
Therefore, the solution adopted is that messages which have no
Checksum are tagged and carried across the line
When a system which does not implement LAN Frame
preservation receives a frame having an embedded FCS, it converts
for its own use by removing the trailing four octets. When
system forwards a frame which contains no embedded FCS to a LAN,
forwards it in a way which causes the FCS to be calculated
5.3. Tinygram
An issue in remote Ethernet bridging is that the protocols that
most attractive to bridge are prone to problems on low speed (64
and below) lines. This can be partially alleviated by observing
the vendors defining these protocols often fill the PDU with
of ZERO. Thus, an Ethernet or IEEE 802.3 PDU received from a
that is (1) smaller than the minimum PDU size, and (2) has a
Frame Checksum present, must be padded by inserting zeroes
the last four octets and the rest of the PDU before transmitting
on a LAN. These protocols are frequently used for
sessions, and therefore are frequently this small
To prevent ambiguity, PDUs requiring padding are explicitly tagged
Compression is at the option of the transmitting station, and
probably performed only on low speed lines, perhaps
configuration control
The pseudo-code in Figure 1 describes the algorithms
Point-to-Point Protocol Extensions Working Group [Page 6]
RFC 1220 Bridging Point-to-Point Protocol April 1991
5.4. LAN
In some applications, it is useful to tag traffic by the
community it is a part of, and guarantee that it will be only
onto a LAN which is of the same community. The user community
defined by a LAN ID. Systems which choose to not implement
feature must assume that any frame received having a LAN ID is from
different community than theirs, and discard it
Point-to-Point Protocol Extensions Working Group [Page 7]
RFC 1220 Bridging Point-to-Point Protocol April 1991
Figure 1: Tinygram Compression Pseudo-
PPP Transmitter
if (ZeroPadCompressionEnabled &&
BridgedProtocolHeaderFormat == IEEE8023 &&
PacketLength == Minimum8023PacketLength) {
/*
* Remove any continuous run of zero octets preceding
* but not including, the LAN FCS, but not
* 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 */
TrailingOctet (PDU) == 0) /* or last non-zero octet */
RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
Appendbuf (PDU, 4, FCS); /* Restore FCS */
}
else {
while (PacketLength > 14 && /* Stop at MAC header */
TrailingOctet (PDU) == 0) /* or last zero octet */
RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
}
PPP Receiver
if (ZeroCompressionFlag) { /* Flag set in header? */
/* Restoring packet to minimum 802.3 length */
Clear (ZeroCompressionFlag);
if (is_Set (LAN_FCS_Present)) {
FCS = TrailingOctets (PDU, 4); /* Store FCS */
RemoveTrailingOctets (PDU, 4); /* Remove FCS */
Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
Appendbuf (PDU, 4, FCS); /* Restore FCS */
}
else {
Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
}
Point-to-Point Protocol Extensions Working Group [Page 8]
RFC 1220 Bridging Point-to-Point Protocol April 1991
6. Protocol Data Unit
6.1. Common LAN
Figure 2: 802.3 Frame
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFF | 0x03 | 0x00 | 0x31 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|I|Z|0| Count | 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 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HDLC CRC | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For Bridging LAN traffic, the format of the frame on the line is
shown in Figures 2 or 3. This conforms to RFC 1171 section 3.1
"Frame Format". It also allows for RFC 1172 [2] negotiation
Protocol Field Compression and Address and Control Field Compression
It is recommended that devices which use controllers that
even memory addresses negotiate to NOT USE Protocol Field
on other than low speed links
Point-to-Point Protocol Extensions Working Group [Page 9]
RFC 1220 Bridging Point-to-Point Protocol April 1991
Figure 3: 802.4/802.5/FDDI Frame
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFF | 0x03 | 0x00 | 0x31 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|I|Z|0| Count | 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 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (optional) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional Data Link Layer padding +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HDLC CRC | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of this message are as follows
Address Field and Control Field
As defined by RFC 1171
Protocol Field
0x0031
Flags
bits 0-3: length of the line protocol pad field
bit 4: Reserved, Set to
bit 5: Set if IEEE 802.3 Pad must be zero filled to minimum
bit 6: Set if the LAN ID Field is
bit 7: Set if the LAN FCS Field is
The "number of trailing "pad" octets is a deference to the
that any point-to-point frame may have padding at the end.
Point-to-Point Protocol Extensions Working Group [Page 10]
RFC 1220 Bridging Point-to-Point Protocol April 1991
number tells the receiving system how many octets to strip off
end
MAC Type
0:
1: IEEE 802.3/
2: IEEE 802.4
3: IEEE 802.5
4:
other: Assigned by the Internet Assigned Numbers
LAN ID
This optional 32 bit field identifies the Community of LANs
may be interested to receive this frame, as described in
5.4. If the LAN ID flag is not set, then this field is
present, and the PDU is four octets shorter
Frame Control
On 802.4, 802.5, and FDDI LANs, there are a few octets
the Destination MAC Address, one of which is protected by the FCS
Since the MAC Type field defines the bit ordering, these are
in MAC order. A pad octet is present to avoid odd machine
boundary problems
Destination MAC Address
As defined by the IEEE. Since the MAC Type field defines the
ordering, this is sent in MAC order
Source MAC Address
As defined by the IEEE. Since the MAC Type field defines the
ordering, this is sent in MAC order
LLC data
This is the remainder of the MAC frame. This is that portion
the frame which is (or would be were it present) protected by
LAN FCS; for example, the 802.5 Access Control field, and
Trailer are not meaningful to transmit to another ring, and
omitted
LAN Frame Checksum
If present, this is the LAN FCS which was calculated by (or
appears to have been calculated by) the originating station.
the FCS Present flag is not set, then this field is not present
and the PDU is four octets shorter
Optional Data Link Layer
RFC 1171 specifies that an arbitrary pad can be added after
data intended for transmission. The "Count" portion of the
Point-to-Point Protocol Extensions Working Group [Page 11]
RFC 1220 Bridging Point-to-Point Protocol April 1991
field contains the length of this pad, which may not exceed 15
octets
CRC-
Mentioned primarily for clarity. The CRC used on the PPP link
separate from and unrelated to the LAN FCS
6.2. IEEE 802.1
This is the BPDU as defined by IEEE 802.1(d), without any MAC
802.2 LLC header (these being functionally equivalent to the Address
Control, and Protocol Fields). The LAN Pad and Frame Checksum
are likewise superfluous and absent. The Address and Control
are optional, subject to the Address and Control Field
negotiation
Figure 4: Bridge "Hello"
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFF | 0x03 | 0x02 | 0x01 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPDU data +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HDLC CRC | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of this message are as follows
Address Field and Control Field
As defined by RFC 1171
Protocol Field
0x0201
MAC Frame
802.1(d)
Point-to-Point Protocol Extensions Working Group [Page 12]
RFC 1220 Bridging Point-to-Point Protocol April 1991
6.3. IEEE 802 Network Control
The Bridge Network Control Protocol is responsible for configuring
enabling, and disabling the bridges on both ends of the point-to
point link. As with the Link Control Protocol, this is
through an exchange of packets. BNCP packets may not be
until LCP has reached the network-layer Protocol
Negotiation phase. Likewise, LAN traffic may not be exchanged
BNCP has first opened the connection
The Bridge Network Control Protocol is exactly the same as the Point
to-Point Link Control Protocol with the following exceptions
Data Link Layer Protocol
Exactly one Bridge Network Control Protocol packet is
in the Information field of PPP Data Link Layer frames where
Protocol field indicates type hex 8031 (BNCP).
Code
Only Codes 1 through 7 (Configure-Request, Configure-Ack
Configure-Nak, Configure-Reject, Terminate-Request
Terminate-Ack and Code-Reject) are used. Other Codes
be treated as unrecognized and should result in Code-Rejects
BNCP packets may not be exchanged until the Link
Protocol has reached the network-layer Protocol
Negotiation phase. An implementation should be prepared to
for Link Quality testing to finish before timing out
for Configure-Ack or other response
Configuration Option
The Bridge Network Control Protocol has a separate set
Configuration Options. These permit the negotiation of
following items
- MAC Types
- Tinygram Compression
- LAN Identification
- Ring and Bridge
6.4. IEEE 802.5 Remote Ring Identification
Since the Remote Bridges are modeled as normal Bridges with a
internal interface, each bridge needs to know the ring/bridge
of the bridges it is adjacent to. This is the subject of a
Negotiation. The exchange of ring-and-bridge identifiers is
using this option on the Network Control Protocol
Point-to-Point Protocol Extensions Working Group [Page 13]
RFC 1220 Bridging Point-to-Point Protocol April 1991
The Token Ring Ring-and-Bridge Identifier, and its use, is
by the IEEE 802.5 Addendum on Source Routing. It identifies the
that the interface is attached to by its configured ring number,
itself by bridge number on the ring
Figure 5: Remote Ring Identification
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=1 |length = 4 | ring number |bridge#|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1 = IEEE 802.5 Source Routing Ring/Bridge
4
Ring
A 12 bit number identifying the token ring, as defined in
IEEE 802.5 Source Routing Specification
Bridge
A 4 bit number identifying the bridge on the token ring,
defined in the IEEE 802.5 Source Routing Specification
6.5. IEEE 802.5 Line Identification
This option permits the systems to treat the line as a visible "
Ring", in accordance with the Source Routing algorithm. The
exchange ring-and-bridge identifiers using this option on the
Control Protocol. The configured ring numbers must be identical
normal operation
The Token Ring Ring-and-Bridge Identifier, and its use, is
by the IEEE 802.5 Addendum on Source Routing. It identifies the
that the interface is attached to by its configured ring number,
itself by bridge number on the ring
Figure 6: Line Identification
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=2 |length = 4 | ring number |bridge#|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Point-to-Point Protocol Extensions Working Group [Page 14]
RFC 1220 Bridging Point-to-Point Protocol April 1991
Type 2 = IEEE 802.5 Line "Ring/Bridge"
4
Ring
A 12 bit number identifying the line, as defined in
IEEE 802.5 Source Routing Specification
Bridge
A 4 bit number identifying the bridge on the token ring,
defined in the IEEE 802.5 Source Routing Specification
6.6. MAC Type Support
The MAC Type Selection Option is provided to permit nodes
advertise what sort of traffic they are prepared to convey. A
negotiating a 1600 octet MRU, for example, may not be willing
support 802.5 (although it might, with certain changes necessary
the RIFs it passes, and given that the hosts it supports
the 802.5 Maximum Frame Size correctly), and is definitely
prepared to support 802.4 or FDDI
A system which does not announce the MAC Types that it supports
be assumed to support all MAC Types; it will discard those that
does not understand. A system which chooses to announce MAC Types
advising its neighbor that all unspecified MAC Types will
discarded. Announcement of multiple MAC Types is accomplished
placing multiple options in the Configure Request
The Rejection of a MAC Type Announcement (in a Configure-Reject)
essentially a statement that traffic appropriate to the MAC Type,
encountered, will be forwarded on the link even though the
system has indicated it will discard it
Figure 7: MAC Type Selection
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=3 |length = 3 | MAC Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 3 = MAC Type
3
Point-to-Point Protocol Extensions Working Group [Page 15]
RFC 1220 Bridging Point-to-Point Protocol April 1991
MAC Type
One of the values of the PDU's MAC Type Field that this system
prepared to receive and service
6.7. Tinygram
Not all systems are prepared to make modifications to messages
transit; on high speed lines, it is probably not worth the effort
This option permits the system to negotiate compression
Consistent with the behavior of other compression options in
Internet Point-to-Point set of protocols, no negotiation implies
compression. The systems need not agree on the setting of
parameter; one may be willing to decompress and the other not.
system which does not negotiate, or negotiates this option to
disabled, should never receive a compressed packet, however
Figure 8: Tinygram Compression
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=4 |length = 3 | Compression |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4 = Tinygram Compression Support
3
Compression Enable/
If the value is 1, Tinygram Compression is enabled. If
value is 2, Tinygram Compression is disabled, and
decompression will occur
6.8. LAN Identification
Not all systems are prepared to make use of the LAN
field. This option enables the systems to negotiate its use
The parameter is advisory; if the value is "enabled", then there
exist labeled LANs beyond the system, and the system is prepared
service traffic to it. if the value is "disabled", then there are
labeled LANs beyond the system, and all such traffic will
definition be dropped. Therefore, a system which is advised that
peer does not service LAN Identifications need not forward
traffic on the link
Point-to-Point Protocol Extensions Working Group [Page 16]
RFC 1220 Bridging Point-to-Point Protocol April 1991
The default value is that LAN Identification disabled
Figure 9: LAN Identification
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=5 |length = 3 | Identification
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 5 = LAN Identification Support
3
Identification Enable/
If the value is 1, LAN Identification is enabled. If the
is 2, LAN Identification is disabled
7.
This document is a product of the Point-to-Point Protocol
Working Group. Special thanks go to Steve Senum of Network Systems
Dino Farinacci of 3COM, and Rick Szmauz of Digital
Corporation
8.
[1] Perkins, D., "The Point-to-Point Protocol for the Transmission
Multi-Protocol Datagrams Over Point-to-Point Links", RFC 1171,
CMU, July 1990.
[2] Hobby R., and D. Perkins, "The Point-to-Point Protocol (PPP
Initial Configuration Options", RFC 1172, CMU, UC Davis,
1990.
[3] IEEE Draft Standard P802.1d/D9 MAC Bridges, Institute
Electrical and Electronic Engineers. Also Published as ISO
10038, July 1989.
[4] IEEE Draft Standard P802.5d/D13 Draft Addendum to ANSI/IEEE
802.5-1988 Token Ring MAC and PHY Specification Enhancement
Multiple-Ring Networks, Institute of Electrical and
Engineers, May 1989.
Point-to-Point Protocol Extensions Working Group [Page 17]
RFC 1220 Bridging Point-to-Point Protocol April 1991
9. Security
Security issues are not discussed in this memo
10. Author's
Fred
Advanced Computer
720 Santa Barbara
Santa Barbara, CA 93101
Phone: (805) 963-9431
EMail: fbaker@ACC.
Or send comments to: ietf-ppp@ucdavis.
Point-to-Point Protocol Extensions Working Group [Page 18]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
