Parallel Bridging

The application includes a microfiche appendix pursuant to 37 CFR .sctn.1.96(b) containing 1 microfiche with 74 frames.

This invention relates to bridges used to transmit and receive information from one local area network to another local area network.

In one typical arrangement, a bridge is connected to a local area network (LAN) and used to (i) transmit packets of information from that LAN over a wide area network (WAN) link or other LAN link to a partner bridge which is connected to another LAN and (ii) receive information packets transmitted over the WAN link by the partner bridge. The WAN link is typically a phone line. The LANs in this arrangement are referred to as remote because they are usually located in different cities.

A common network configuration may include three LANs in three different cities (i.e., a first city, a second city, and a third city), a bridge connected to each LAN (i.e., a first bridge, a second bridge, and a third bridge), and links connecting each bridge to the other two bridges. All bridges typically embody the IEEE 802.1d communication protocol. In this exemplary network configuration, the IEEE 802.1d protocol requires blocking one link as a communication path so that no "loops" exist in the system that might continuously recirculate information packets. In other words, the IEEE 802.1d protocol allows only one path to exist between any two LANs. The IEEE 802.1d protocol also accommodates a single link failure by activating the blocked link if either of the active links fails. The nonuse of the blocked link in this exemplary network configuration is referred to as the triangulation problem.

A data-link-sharing product from Vitalink Communications Corporation allows use of the normally blocked link while avoiding data recirculation in the loop. Reference is also made to U.S. Pat. No. 4,811,337.

If a fourth city with a fourth LAN and a fourth bridge is added and link failure tolerance is required, the fourth city cannot be linked to the first city by simply adding a fifth bridge to the first city and connecting this fifth bridge to the fourth bridge at the fourth city by a fourth link. The IEEE 802.1d protocol requires sixth and seventh bridges at the first and fourth cities, respectively, intercoupled by a fifth link to assure single link failure tolerance between the first and fourth cities. While the IEEE 802.1d protocol avoids the looping problem in this configuration by blocking either the fourth or fifth link, a different problem arises, referred to as the parallel problem. Nonuse of the blocked one of the fourth and fifth links in parallel between the first and fourth cities is referred to as the parallel problem.

According to the invention, there is transmission of information packets over parallel paths between first and second terminals in a network having other terminals while maintaining conformity with a protocol that precludes establishing loops formed by links between terminals that allow information packets to recirculate indefinitely. A first pair of bridges are interconnected by a first link and connected to a respective one of the first and second terminals. A second pair of bridges are interconnected by a second link with each bridge connected to a respective one of the first and second terminals. At least one bridge in each of the first pair of bridges and the second pair of bridges is designatable as a master bridge. All bridges, including the master bridge, have a forward/filtering module for forwarding and filtering information packet transfer between the first and second terminals, a topology recognition/traffic assignment module for sensing the existence of parallel transmission paths between the first and second terminals and assigning information packets to respective ones of the parallel transmission paths for transfer between the first and second terminals, and a spanning tree module for providing a spanning tree bridge identifier signal. A spanning tree bridge identifier signal sensor senses the spanning tree identifier signals and designates as a master that bridge having the spanning tree bridge identifier signal meeting a predetermined condition. Typically the spanning tree bridge identifier signal sensor designates as the master that bridge having the spanning tree bridge identifier signal with a value that is one of lower and higher than the value of all other spanning tree bridge identifier signals for other bridges in parallel paths between the first and second terminals.

Preferably each bridge is assigned at least one unique bucket value. Each information packet is processed to provide an observed bucket value. The assigned and observed bucket values are compared to provide an assignment signal that assigns the associated packet signal for transmission over that one of the parallel paths characterized by an assigned bucket value that bears a predetermined relationship to the observed bucket value. Preferably the data transmission over each of the parallel paths is monitored to provide an average utilization signal that may be processed to reassign assigned bucket values to one or more of the parallel paths to improve the efficiency of data transmission.

Other features and advantages of the invention will become apparent from the following detailed description when read in connection with the accompanying drawing in which:

FIG. 1 is a block diagram of a system utilizing parallel bridges in accordance with the present invention where the local area networks are remote;

FIG. 2 is a block diagram of the functional modules contained in the bridge of the present invention;

FIG. 3 is a block diagram of a second embodiment of a system utilizing parallel bridges in accordance with the present invention where the local area networks are local;

FIG. 4 is a flow chart that illustrates the high-level operation of parallel bridges in the embodiment of FIG. 1;

FIG. 5 is a block diagram of an observed bucket value computation;

FIG. 6 is a block diagram of an alternate observed bucket value computation;

FIG. 7 is a diagram showing the format of information included in a packet header of an Ethernet II message packet used in the invention;

FIG. 8 is a table listing the names and possible values associated with three fields common to some message packets; and

FIGS. 9 through 14 are tables showing the various fields in a LAN identifier message (FIG. 9), a LAN master/slave message (FIGS. 10 and 11), a LAN peer message (FIG. 12), and a WAN message (FIGS. 13 and 14).

Referring to FIG. 1, bridges 44 (numbered by tens from B.sub.10 to B.sub.L) and bridges 46 (numbered by tens from B.sub.11 to B.sub.M) are connected to each other by at least one phone line (i.e., WAN link) 48 and are connected to local area networks 50, 52 by LAN links 55, 57, respectively. Thus, bridges 44 and 46 establish parallel communication paths between a plurality of computer stations 54 (numbered by tens from C.sub.10 to C.sub.H) on LAN 50 and a plurality of computer stations 56 (numbered by tens from C.sub.11 to C.sub.I) on LAN 52.

FIG. 2 illustrates functional modules contained in each bridge 44, 46 (also 72, FIG. 3). Referring to FIG. 2, functionally, each bridge may comprise a forwarding/filtering module 58, a network management module 60, a topology recognition/traffic assignment module 62, a LAN address module 64, a spanning tree module 66, a WAN link module 68, and a LAN link module 70. The higher level modules in FIG. 2 control the lower level modules, i.e, a higher level module may request a lower level module to perform a function and return a result. However, a lower level module may send unrequested information to a higher level module to inform the higher level module of certain events.

Referring to FIG. 3, bridges 72 (numbered by tens from B.sub.12 to B.sub.N) connect LAN 74 to LAN 76 by using LAN links 79, 81. Thus, bridges 72 establish parallel communication paths between a plurality of computer stations 78 (numbered by tens from C.sub.12 to C.sub.J) on LAN 74 and a plurality of computer stations 80 (numbered by tens from C.sub.13 to C.sub.K) on LAN 76.

Having described the physical arrangement of a system according to the invention, its mode of operation will be described. The operation of bridges used to create at least two parallel communication paths between two LANs in accordance with the present invention is illustrated by the flow chart in FIG. 4 of data transfer in the embodiment of FIG. 1.

Referring to FIG. 4, the first step 82 in achieving functioning parallel communication paths between two LANs is for all bridges to exchange messages in order to become aware of the parallel topology and to select a master bridge from the bridges in the parallel topology. The next step 84 is for the master bridge to assign unique bucket values to each bridge pair in the parallel topology. A bucket value is some value from some range that can be the result of some computation. Two bridges connected to different LANs and connected to each other by at least one WAN link constitute a bridge pair. The next step 86 is for each bridge in the parallel topology to constantly monitor the LAN to which it is connected and receive each packet of information put on the LAN by the computer stations connected to the LAN. Next, for step 88 the bridge computes an "observed" bucket value for each information packet it receives. In the next decision step 90, the bridge determines if the observed bucket value matches the assigned bucket value (i.e., the bucket value assigned to the bridge by the master bridge). If the observed and assigned bucket values match, the bridge proceeds to step 92, and the information packet is forwarded over the WAN link to the other bridge in the bridge pair. Otherwise, the bridge loops back to step 86 and processing continues as described above.

The use of assigned and observed bucket values effectively distributes the traffic of information packets to each bridge pair in the parallel topology. The combined throughput of information packets across all of the parallel bridge pairs is potentially greater than the throughput possible across a single bridge pair.

The next step 94 involves a decision by the master bridge. Specifically, if the master bridge determines, based on actual observed information packet traffic between bridge pairs, that assigned bucket values should be reassigned to achieve more balanced traffic loads on each bridge pair, step 84 is again performed and processing continues as described above. Otherwise, step 94 loops back to step 86 and processing continues as described above.

Even after functioning parallel communication paths have been established, the bridges in the parallel topology continue to periodically exchange messages similar to when the bridges were trying to establish the parallel topology and select a master bridge (step 82). These messages serve to inform the bridges in the parallel topology of certain critical events, such as a WAN link either "coming up" (i.e., becoming functional) or "going down", or a bridge in the parallel topology going down. If a critical event occurs, step 82 is again performed by all bridges and processing continues as described above.

In an exemplary embodiment there are 32 unique possible bucket values capable of supporting up to 32 parallel bridge pairs. With 2.sup.48 possible unique bucket values, up to 2.sup.48 parallel bridge pairs may be supported.

The operation of the parallel bridge topology according to the invention complies with the IEEE 802.1d protocol. The bridges in the parallel topology of the invention operate to insure that if the IEEE 802.1d protocol designates any of the parallel links for transmission, the designated link always connects the bridge pair that includes the master bridge. Even though information packet traffic may be distributed to each bridge pair and interconnecting link in the parallel topology, once the bridge pair that includes the master bridge is designated, it appears to any other bridges outside the parallel topology that the bridge pair that includes the master bridge is the only bridge pair transferring data without loop recirculation in accordance with the IEEE 802.1d protocol.

The bridges described above may also be used in a similar system, such as that illustrated in FIG. 3. Whereas LANs 50, 52 of FIG. I are considered to be remote (i.e., located in different cities), LANs 74, 76 of FIG. 3 are local (i.e., located in the same physical building or at least in the same general area). When used with local LANs, as in FIG. 3, each bridge 72 is connected directly to both LANs 74, 76 by LAN links 79, 81. The operation of parallel bridge pairs connected between local LANs is similar to the operation of parallel bridge pairs. However, rather than blocking a WAN link, the IEEE 802.1d operation normally blocks the use of at least one LAN link in all but one of the bridges.

The operation of the functional modules included in a bridge is described below.

Referring to FIG. 2, there is shown a block diagram of functional modules suitable for use in systems according to the invention. Forwarding/filtering module 58 provides standard bridge forwarding and filtering functions. In this example network management module 60 provides operator control over the operation of the bridges in the parallel topology. Topology recognition/traffic assignment module 62 provides recognition of the parallel topology and assignment of information packet traffic across the bridge pairs in the parallel topology. LAN identifier module 64 provides real-time establishment of an address for each LAN to which a bridge in the parallel topology is connected. Spanning tree module 66 provides information about and control over the operation of the "spanning tree algorithm" which operates under the IEEE 802.1d communication protocol. WAN link module 68 provides access to a WAN link for transmission and reception of information packets between a bridge pair in the parallel topology. LAN link module 70 provides access to the LAN link for transmission and reception of information packets between a bridge in the parallel topology and a LAN to which the bridge is connected.

The network management, spanning tree, WAN link, and LAN link modules are known in the art and are not described in detail herein to avoid obscuring the inventive concepts.

To enable topology recognition/traffic assignment module 62 to recognize the parallel topology and select a master bridge, a unique LAN identifier for each LAN to which a bridge is connected is determined by LAN identifier module 64. The LAN identifier is the lowest 8-byte (i.e., 64-bit) "spanning tree bridge identifier" of any bridge in the parallel topology connected to the LAN and adhering to the present invention. A LAN identifier message is periodically "multicast" between bridges on the same LAN in order to compare spanning tree bridge identifiers and determine the LAN identifier for each LAN. All bridges connected to the same LAN form an 8-byte spanning tree bridge identifier by concatenating a 2-byte (i.e., 16-bit) bridge priority value with a 6-byte (i.e., 48-bit) address value. The 2-byte bridge priority enters the most significant positions, and the 6-byte address enters in the least significant positions when forming the 8-byte spanning tree bridge identifier. An operator assigns a 2-byte bridge priority value to each bridge in accordance with the IEEE 802.1d protocol. Under the IEEE 802.3 (i.e., Ethernet) network communication protocol, a unique 6-byte address is assigned, usually at the factory, to every device connected to a LAN by the IEEE 802.3 protocol. (Note that in the case of local LANs, e.g., FIG. 3, where bridges are directly connected to more than one LAN by LAN links, the "local" bridges are capable of determining a unique LAN identifier for each local LAN to which they are directly connected.)

Still referring to LAN identifier module 64, initially each bridge transmits as if its own spanning tree bridge identifier is the LAN identifier, and multicasts a protocol message to other bridges connected to the same LAN indicating that its own spanning tree bridge identifier is the lowest spanning tree bridge identifier known. If a bridge receives a protocol message from another bridge that indicates the other bridge has a lower spanning tree bridge identifier, the receiving bridge records the lower spanning tree bridge identifier as the LAN identifier. Eventually, all bridges connected to the same LAN record a common unique LAN identifier for the LAN to which they are connected. The result is that all LANs, which have at least one connected bridge adhering to the present invention, are assigned unique LAN identifiers without any LAN-to-LAN communication.

Topology recognition/traffic assignment module 62 is now ready to recognize the parallel bridge topology and select a master bridge. In order to recognize the parallel topology, each bridge periodically multicasts messages onto its LAN link or links. If the bridge is a remote bridge, it also periodically transmits a directed message on its WAN link or links to its bridge partner. The messages periodically transmitted on the WAN link(s) contain the LAN identifier of the LAN to which the sending bridge is connected. The messages multicast on the LAN link(s) contain the LAN identifier of the LAN to which the sending bridge's partner is connected. All bridges connected to the same LAN whose bridge partners all have the same LAN identifier are in parallel.

These messages also carry information possessed by each bridge as to which bridge in the parallel topology has the lowest spanning tree bridge identifier. The bridge with the lowest spanning tree bridge identifier is designated the master bridge among all bridges in the parallel topology. When first started, the information in each bridge indicates that bridge is the master bridge. As messages are exchanged, each bridge that is not the master bridge will eventually receive a message identifying the correct master bridge, and eventually all messages will identify the same bridge as the master bridge. It does not matter to which LAN the master bridge is connected. Because of the contents of the 8-byte spanning tree bridge identifier, only one master bridge is selected for the parallel topology. Because an operator assigns the 2-byte bridge priority value to each bridge, the operator can cause a particular bridge to be selected as the master bridge.

It is convenient to refer to all the bridges in the parallel topology that are not the master bridge, but are on the same LAN as the master bridge, as peer bridges, and all bridges in the parallel topology that are not on the same LAN as the master bridge, as slave bridges. Referring to FIG. 1, if the master bridge is bridge B.sub.20, all other bridges connected to LAN 50 by LAN links 55 (i.e., B.sub.10, B.sub.L, etc.) are peer bridges, and bridges B.sub.11 through B.sub.M are slave bridges. In FIG. the master bridge, peer bridges, and slave bridges are denoted by M, P, and S, respectively.

Topology recognition/traffic assignment module 62 uses the periodically multicast messages not only to recognize the parallel topology and select a master bridge, but also to ascertain a "cost" associated with each LAN and WAN link in the parallel topology. Usually the cost of using a link is inversely proportional to the speed (i.e., data rate and/or bandwidth) of the link. Specifically, faster links usually have lower use costs than slower links. The IEEE 802.1d protocol determines all link costs and preferably identifies a collection of links in which the total cost for transmitting a particular packet from any point to any other point in the network is minimized.

Typically, in an arrangement with remote LANs, the WAN link costs dominate the LAN link costs, i.e., the LAN links are usually assigned a very low (or zero) cost. However, in an arrangement with local LANs, LAN link costs dominate because no WAN links exist.

After the master bridge receives signals representative of the costs of all the links in the parallel topology, it preferably determines an effective link cost for all of the links combined. The computation used to arrive at the effective link cost is similar to the computation used to determine the equivalent resistor value of resistors in parallel. Therefore, the effective link cost for transmitting over parallel paths is always less than for transmitting on any of the individual links in the parallel topology.

Once the master bridge has determined the effective link cost, it may broadcast this cost in accordance with the IEEE 802.1d protocol. All other bridges in the parallel topology may also broadcast their effective costs in accordance with the IEEE 802.1d protocol. However, bridges in the parallel topology, other than the master bridge, broadcast effective link costs that are greater than the master bridge's effective link cost in order to assure that the link designated as a "forwarding" link in accordance with the IEEE 802.1d protocol is the link connected to the master bridge.

With the parallel topology recognized, the master bridge selected, and effective costs ascertained, topology recognition/traffic assignment module 62 in the master bridge may assign information packets to certain bridge pairs in the parallel topology, i.e., assign traffic.

Referring to FIG. 1, if computer C.sub.10 sends an information packet to computer C.sub.11, each bridge 44 receives the packet because all bridges in the parallel topology are what is known as promiscuous receivers on the LAN to which they are connected. Under the IEEE 802.1d protocol, an information packet is transferred to the other LAN over only one path, i.e., duplicate packets should not be received by the other LAN. Therefore, although all bridges 44 receive the packet, only one forwards the packet over a link to its bridge partner and ultimately to the destination computer C.sub.11. Topology recognition/traffic assignment module 62 and forwarding/filtering module 58 (FIG. 2) control the transfer of packets between the two LANs 50, 52.

Initially, topology recognition/traffic assignment module 62 in the master bridge assigns unique bucket values to each bridge pair in the parallel topology. The bridge pairs use these assigned bucket values to determine if a particular information packet should be forwarded. Forwarding/filtering module 58 in each bridge determines whether or not to forward the packet after computing an "observed" bucket value for the packet. If the observed bucket value matches the assigned bucket value (i.e., the bucket value assigned to the bridge by the master bridge), the information packet is forwarded over a link to the bridge partner. Otherwise, the packet is not forwarded.

Under the IEEE 802.3 or Ethernet protocols, each information packet begins with a 12-byte (i.e., 96-bit) packet header consisting of a 6-byte (i.e., 48-bit) destination address and a 6-byte source address. The 6-byte destination address and the 6-byte source address are used to compute the observed bucket value.

In both IEEE 802.3 and Ethernet, each information packet actually begins with 14 bytes (i.e., 112 bits) where the last 2-byte (i.e., 16-bit) segment is referred to as a "length" field in IEEE 802.3 and a "protocol type" field in Ethernet. The decimal value of the last 2-byte segment identifies it as a length (IEEE 802.3) or a protocol type (Ethernet) field. If the last 2-byte segment is between 0 and 1500 (decimal), it is an IEEE 802.3 length field. If it is between I501 and 65535 (decimal), it is an Ethernet protocol type field.

Referring to FIG. 5, two binary functions are performed on the two addresses: an Exclusive-OR (i.e., XOR) function 96 and an AND function 98. Specifically, the 6-byte destination address 100 is XORed with the 6-byte source address 102, and the 6-byte result 104 of this XOR operation is ANDed with a 6-byte mask 106. The 6-byte result 108 of this AND operation is the observed bucket value 108 of the packet.

The last 2-byte (i.e., 16-bit) segment of each information packet that is unused in the computation of FIG. 5 may be used in an alternate observed bucket value computation. Referring to FIG. 6, the alternate computation involves three binary functions: two Exclusive-OR (i.e., XOR) functions 110, 112 and an AND function 114. Specifically, the 6-byte destination address 116 is XORed with the 6-byte source address 118, the 6-byte result 120 is XORed with the 2-byte segment 122, and the 6-byte result 124 is ANDed with a 6-byte mask 126. The 6-byte final result 128 is the observed bucket value 128 of the packet. The 2-byte segment 122 is "padded" with zeroes in the most significant 4 bytes so that it is properly aligned with the lowest two bytes of the 6-byte result 120 during the XOR computation 112.

It is possible to use functions other than the XOR functions 96, 110 in computing observed bucket values (FIGS. 5 and 6). An advantage of the XOR function is the commutative property. In other words, the order in which the values are XORed is unimportant to the ultimate result. Any function that has such a property could be used in place of XOR functions 96, 110 (i.e., in place of the functions that operate on the 6-byte destination and source addresses 100, 102, 116, 118). In contrast, XOR function 112 (FIG. 6) can be any equivalent function even if it is non-commutative.

In this example, the 6-byte mask (106, FIG. 5 and 126, FIG. 6) has a decimal value of 31, i.e., the five least significant bits in the 6-byte mask are ones, and the remaining bits are zeroes. Because the mask has a decimal value of 31, the observed bucket values may range from 0 to 31. However, a mask value as high as 2.sup.48-1 (in decimal) may also be used. In this case, observed bucket values would range from 0 to 2.sup.48-1. A decimal mask value of 2.sup.48-1 means all 48 bits in the 6-byte mask are ones.

If there are fewer bridge pairs than unique bucket values in the parallel topology, topology recognition/traffic assignment module 62 in the master bridge assigns more than one unique bucket value to some or all bridge pairs until all possible bucket values have been assigned. In the present example, the master bridge only assigns 32 unique bucket values so 32 bridge pairs can be supported in the parallel topology. However, more bridge pairs may be supported in the parallel topology by having the master bridge assign more (such as up to 2.sup.48) unique bucket values.

Topology recognition/traffic assignment module 62 in the master bridge preferably assigns bucket values to bridge pairs in inverse proportion to the cost of the links between the bridge pairs. For instance, if the parallel topology consists of only two bridge pairs and a link associated with the first bridge pair has twice the cost of a link associated with the second bridge pair, the master bridge preferably assigns half as many bucket values to the first bridge pair link as to the second bridge pair link.

In brief summary, topology recognition/traffic assignment module 62 in the master bridge and forwarding/filtering module 58 in the other bridges control information packet traffic. The master bridge assigns one or more bucket values to each bridge pair in the parallel topology. The bridges compute an observed bucket value for each information packet they receive from the LAN to which they are connected and compare this observed bucket value with their assigned bucket values (i.e., the bucket values assigned to them by the master bridge). If the observed and the assigned bucket values match, the information packet is forwarded over the link to the bridge partner on the other LAN. However, if the observed and the assigned bucket values do not match, the information packet is not forwarded.

The parallel topology then assumes a static state, and the bridge pairs in the parallel topology continue to forward information packets from one LAN to another. While in this static state, all bridges in the parallel topology continue periodic communication with each other.

If a change occurs in the parallel topology, all bridges sense the change because of the continual and periodic communication. A change may include a bridge failing, a new bridge coming on-line, a link failing, or a link cost changing in the parallel topology. After sensing such a change, all bridges in the parallel topology halt operation and stop forwarding information packets. All bridges then effectively reset and repeat the process described above beginning with the LAN identifier module determining a unique LAN identifier for each LAN.

As indicated above, a feature of the invention is that operation of the parallel bridge topology may be in total conformity to the IEEE 802.1d protocol. For instance, if a link outside the parallel topology has a lower cost than the effective link cost announced by the master bridge and conformity with the IEEE 802.1d protocol chooses this lower cost link and blocks the link between the master bridge and its bridge partner, the master bridge then instructs all bridges in the parallel topology to halt operation and stop forwarding information packets. The master bridge may continue to announce the effective link cost in conformity with the IEEE 802.1d protocol for possible selection again.

As described above, the master bridge is in constant communication with the other bridges in the parallel topology. The bridge pairs in the parallel topology preferably determine an average utilization of the link connecting them by keeping and manipulating information about the information packet traffic on the link. This constant communication allows the bridge pairs to inform the master bridge of the average utilization of their links. If the master bridge finds the link utilization of any bridge to be unacceptable, the master bridge may preferably reassign the assigned bucket values. If the master bridge determines, based on actual observed information packet traffic between bridge pairs, that assigned bucket values should be reassigned to achieve more balanced traffic loads across each bridge pair, the master bridge will instruct all bridges in the parallel topology to halt operation and stop forwarding information packets. The master bridge will then repeat the process described above beginning with topology recognition/traffic assignment module 62 in the master bridge assigning information packets to certain bridge pairs in the parallel topology.

Having described the physical arrangement and the mode of operation of a system according to the invention, the specific format of messages used in a system according to the invention will now be described.

In one exemplary embodiment, all transmitted messages use the Ethernet II message packet format. An Ethernet II message packet includes a packet header and a portion containing the actual message. The packet header contains 14 octets (where an octet is an 8-bit byte), and the actual message portion of the message packet may contain between 0 and 1500 octets. An Ethernet II message packet must consist of at least sixty-four octets.

Unless otherwise stated, all multi-octet fields within the Ethernet II message packet are transmitted by sending the high-order octet first. All single-octet fields within the message packet are transmitted in order from "top to bottom", as top and bottom is indicated in FIGS. 8 through 14.

Referring to FIG. 7, the 14-byte packet header of an Ethernet II message packet includes fourteen octets numbered zero (least significant byte) to thirteen (most significant byte). The first six octets (i.e., octets 0 through 5) contain a destination address 130, and the next six octets (i.e., octets 6 through 11) contain a source address 132. A 2-byte (i.e., two-octet) protocol type field 134 (octets 12 and 13) is set to hexadecimal 088A. Octet 12 contains hexadecimal 08, and octet 13 contains hexadecimal 8A.

The invention uses two single-octet fields which immediately follow octet 13 of the packet header. These two fields are technically part of the actual message portion of the message packet, but, for simplicity, they may be considered octets 14 and 15 of the packet header, as indicated in FIG. 7. Octet 14 is a pad count field 136 which contains a non-zero value when the information to be transmitted in a single message packet requires less than sixty-four octets. When the information to be transmitted can be contained in less than sixty-four octets, the value in the pad count field 136 represents the number of zero-value octets that have been added to the message packet as "padding" to bring the total number of octets in the message packet to sixty-four. Octet 15 is a single-byte LAN identifier field 138 which is set to either the value 4 (hexidecimal or decimal) to indicate that the LAN identifier message (described previously) is contained in the actual message portion of the message packet to be transmitted, or the value 5 (hexidecimal or decimal) to indicate that a message other than the LAN identifier message is forthcoming in the actual message portion.

The LAN identifier message, as described previously, is sent by a bridge over its LAN link or links in order to determine the LAN identifier for the LAN to which the bridge is connected. Referring to FIG. 9, the LAN identifier message includes four fields. The first field is a one-octet (i.e., one 8-bit byte) TYPE field which identifies the message type, and is simply set to a default value of 1 in this embodiment. The second field is a one-octet VERSION field which identifies the version number of the system, and is simply set to a default value of 0 in this embodiment. The third field is an eight-octet (i.e., 8-byte) LAN-ID field which contains the LAN identifier of the LAN to which the sending bridge is connected. The fourth field is a one-octet STABLE-FLAG field which indicates whether the sending bridge believes the LAN identifier is stable (value 1) or not (value 0).

A "LAN master/slave" message is sent by the master bridge (e.g., B.sub.20, FIG. 1) of a parallel group of bridges over its LAN link or links (e.g., 55, FIG. 1), and by the master bridge's slave partner (e.g., B.sub.21, FIG. 1) over its LAN link or links (e.g., 57, FIG. 1). Referring to FIG. 10, the LAN master/slave message includes eight fields. The first field is a one-octet TYPE field which contains the value 1 (the default value) to indicate that the master bridge is sending, or the value 3 to indicate that the master bridge's partner is sending. The second field is a one-octet VERSION field which identifies the version number of the system, and is simply set to a default value of 0. The third and fourth field are a two-octet CONFIG field and a one-octet STP-STATE field, respectively, which are both described below with reference to FIG. 8. The fifth is a one-octet GROUP-SIZE field which identifies the number of "records" contained in a GROUPS field (described below). The sixth is an eight-octet REMOTE-LAN-ID field which contains the LAN identifier of the sending bridge's partner's LAN. The seventh is an eight-octet GROUP-MASTER-ID field which contains what the sending bridge believes to be the master bridge's spanning tree bridge identifier (described previously). The eighth field is the GROUPS field which contains GROUP-SIZE "records".

Referring to FIG. 11, each of the GROUP-SIZE "records" in the GROUPS field includes eight defined fields and two undefined fields. The first defined field is an eight-octet NEIGHBOR-ID field containing a neighboring bridge's spanning tree bridge identifier, where a neighbor bridge is equivalent to a peer bridge described previously. The second defined field is a one-octet NEIGHBOR-STATE field which contains a neighboring bridge's state (see description of STATE field below with reference to FIG. 8). The third defined field is a four-octet NEIGHBOR-PATH-COST field which contains a neighboring bridge's spanning tree path cost associated with the WAN link between the neighbor and its partner bridge. The fourth defined field is a four-octet NEIGHBOR-BUCKETS field containing a bit map of bucket value(s) assigned to a neighboring bridge. The fifth is an eight-octet PARTNER-ID field containing the spanning tree bridge identifier of a neighboring bridge's partner bridge. The sixth is a one-octet PARTNER-STATE field which contains a neighboring bridge's partner's state (see description of STATE field below with reference to FIG. 8). The seventh defined field is a four-octet PARTNER-PATH-COST field containing a neighboring bridge's partner's spanning tree path cost associated with the WAN link between the neighboring bridge and its partner. The eighth is a four-octet PARTNER-BUCKETS field containing a bit map of bucket value(s) assigned to a neighboring bridge's partner.

Referring to FIG. 8, the two-octet CONFIG, one-octet STP-STATE, and one-octet STATE fields mentioned above are now described. The CONFIG field contains a bit map of the configuration of the sending bridge, and is generally a description of the capabilities of the transmitting system. Three bit configurations for the CONFIG field are possible. If neither bit 0 nor bit 1 are set, all bridging is totally disabled. If bit 0 is set and bit 1 is not set, normal bridging is enabled. If both bit 0 and bit 1 are set, parallel bridging according to the invention is enabled. The STP-STATE field generally contains the spanning tree state of the transmitting system, and more specifically it contains the spanning tree port state which all bridges in the parallel group should take for all of their WAN links. A value of 0 in the STP-STATE field means the spanning tree port is blocked, a value of 1 means the spanning tree port is listening, a value of 2 means learning, and a value of 3 indicates forwarding of messages. The STATE field indicates the state of the transmitting system, and is referred to as NEIGHBOR-STATE (see above), PARTNER-STATE (see above), and SELF-STATE (see below). The STATE field (in any of its three forms) contains any one of the values 1, 2, 3, 4, 5, 6, 8, 10, 11, 13, 14, or 15 which indicate, respectively, bad topology, disabled, same LAN, not stable, local LAN stable, remote LAN stable, slave bridge, peer bridge waiting, peer bridge, master bridge waiting, master bridge, or master bridge stopped.

A "LAN peer" message is sent by a peer bridge (e.g., B.sub.10, FIG. 1) of the master bridge (e.g., B.sub.20, FIG. 1) over the LAN shared by the peer and the master (e.g., 50, FIG. 1). Referring to FIG. 12, the LAN peer message includes twelve defined fields and two undefined fields. The first defined field is a one-octet TYPE field which contains a default value of 2, in this embodiment. The second defined field is a one-octet VERSION field which identifies the version number of the system, and is simply set to a default value of 0. The third field is a two-octet CONFIG field, as described previously with reference to FIG. 8. The fourth defined field is an eight-octet REMOTE-LAN-ID field which contains the LAN identifier of a parallel group's remote LAN. The fifth is an eight-octet SELF-ID field containing the sending bridge's spanning tree bridge identifier. The sixth is a one-octet SELF-STATE field which identifies the sending bridge's state, as state has been defined with reference to FIG. 8. The seventh defined field is a four-octet SELF-PATH-COST field which contains the sending bridge' s spanning tree path cost associated with the peer bridge's WAN link. The eighth is a four-octet SELF-BUCKETS field containing a bit map of the bucket value(s) assigned to the sending bridge. The ninth is an eight-octet PARTNER-ID field containing the sending bridge's partner's spanning tree bridge identifier. The tenth is a one-octet PARTNER-STATE field containing the sending bridge's partner's state, as state has been described with reference to FIG. 8. The eleventh defined field is a four-octet PARTNER-PATH-COST field containing the sending bridge's partner's spanning tree path cost associated with the WAN link connecting the sending bridge's partner to the sending bridge. The twelfth is a four-octet PARTNER-BUCKETS field containing a bit map of the bucket value(s) assigned to the sending bridge's partner.

In the case of remote LANs (e.g., FIG. 1), a "WAN" message is sent by each bridge in the parallel group to its bridge partner over the WAN link (e.g., B.sub.10 to B.sub.11, FIG. 1). Referring to FIG. 13, the WAN message includes thirteen defined fields and one undefined field. The first defined field is a one-octet TYPE field which contains the value 4, 5, 6, or 7 to identify the message as originating from, respectively, a master bridge (message in long format), a master bridge (message not in long format), a peer bridge, or a slave bridge. The second defined field is a one-octet VERSION field containing a default value of 0. The third and fourth fields are the two-octet CONFIG and one-octet STP-STATE fields which have been described previously. The fifth defined field is a one-octet GROUP-SIZE field identifying the number of "records" in a GROUPS field (described below) and containing the value 0 except when the TYPE field contains the value 4. The sixth is a four-octet COMBINED-PATH-COST field which indicates either the average spanning tree path cost associated with the WAN link as seen by the sending bridge and its slave bridge when the message is sent by a master or a peer bridge, or the last value received in this field from the slave bridge's partner when the message is sent by a slave bridge. The seventh defined field is an eight-octet LOCAL-LAN-ID field containing the LAN identifier of the sending bridge's LAN. The eighth is an eight-octet GROUP-MASTER-ID field containing what the sending bridge believes to be the spanning tree bridge identifier of the master bridge. The ninth is an eight-octet SELF-ID field containing the sending bridge's spanning tree bridge identifier. The tenth defined field is a one-octet SELF-STATE field containing the sending bridge's state, as state has been described with reference to FIG. 8. The eleventh is a four-octet SELF-PATH-COST field which contains the sending bridge's spanning tree path cost associated with the WAN link on which this message is sent. The twelfth is a four-octet SELF-BUCKETS field containing a bit map of the bucket value(s) assigned to the sending bridge. The thirteenth defined field is the GROUPS field which contains GROUP-SIZE "records". The value of GROUP-SIZE is 0 (i.e., the GROUPS field contains nothing) unless the TYPE field contains the value 4 (i.e., unless the TYPE field indicates the message as a "master--long format" type).

Referring to FIG. 14, each of the GROUP-SIZE "records" in the GROUPS field includes eight defined fields and two undefined fields. The possible contents of the eight defined fields and their meaning are the same as for the eight defined fields described previously with reference to FIG. 11.

Software may be used to implement the system described above. An example of computer source code which implements the system is set forth in Appendix A. The code in Appendix A is written in the C programming language. Appendix A is subject to copyright protection. The copyright owner has no objection to the reproduction of Appendix A as it appears in the United States Patent and Trademark Office, but otherwise reserves all copyright rights whatsoever. ##SPC1##

Other embodiments are within the following claims.