Method and system for shortcut trunking of LAN bridges

Information

  • Patent Grant
  • 6370121
  • Patent Number
    6,370,121
  • Date Filed
    Monday, June 29, 1998
    26 years ago
  • Date Issued
    Tuesday, April 9, 2002
    22 years ago
Abstract
The invention provides a method and system for routing traffic between LAN bridges. A method and system for enabling a blocked link to allow forwarding of traffic across the blocked link includes determining whether the blocked link is a point-to-point connection between two bridges, each one of the two bridges having a plurality of ports, ascertaining whether each one of the two bridges operates a Shortcut Trunking Exchange protocol, and calculating whether on at least one of the two bridges, a port cost of the blocked link is equal to or lower than a port cost of each other one of the plurality of ports. In addition, a method for selecting traffic to forward on a blocked link, the traffic having a source and a destination address, includes building an outside address list for a first bridge, the outside address list including each address “outside” the first bridge, building an outside address list for a second bridge, the outside address list including each address “outside” the second bridge, determining that the source and destination addresses are both “outside” the first and second bridges using the outside address lists for the first and second bridges, and forwarding the traffic if the traffic is unicast traffic when the source and destination addresses are both “outside” the first and second bridges.
Description




BACKGROUND OF THE INVENTION




1. Field of the Invention




The present invention relates to routing traffic between LAN bridges.




2. The Prior Art




Local area networks (LANs) are typically configured using a plurality of interconnected multi-port bridges. Through the use of these interconnected bridges, a potential exists that a “loop” will form, in which traffic will flow endlessly. To avoid this problem, human operators may verify that no loops are created when these bridges are connected. However, to reduce the potential for human error and to simplify this verification process, some networks use a Spanning Tree Protocol (STP).




The Spanning Tree Protocol is a topology reduction technique which consists of two steps. First, a “root” bridge is selected which is logically made the center of the network. Second, each remaining bridge determines through which of its ports lies the optimal path to the root. This optimal path is determined according to static path costs. Ports which lead to the root, but which are not optimal, are blocked, thus eliminating all loops. All remaining ports remain active, allowing forwarding of traffic on these connections. Thus, a “spanning tree” is created in which every pair of points in the network is connected via one, and only one unblocked path.




Although the Spanning Tree Protocol is in wide use today, the protocol has several distinct disadvantages. First, in response to a topology change in the network, the Spanning Tree Protocol must perform a reconfiguration, negotiating among all participating devices to determine which ports to block. This process can last approximately 30-60 seconds for an ordinary sized network. During this time, newly active ports are not yet enabled for forwarding. As a result, protocol timeouts may occur before a new link is enabled. Moreover, learned addresses are quickly discarded during the reconfiguration, to be relearned appropriate to the new topology. Flooding of unknown destination traffic before a new link is established or prior to relearning can substantially decrease the performance of the network. Second, the Spanning Tree Protocol, in eliminating loops, creates a number of blocked ports. Since these blocked ports carry no traffic, the Spanning Tree Protocol substantially reduces the number of bridge connections in use. As a result, network traffic is sent along a limited number of bridge connections. Third, the Spanning Tree Protocol is designed to select an optimal path to a root bridge from each other bridge in the network, rather than selecting an optimal path between end systems. Therefore, efficiency resulting from the use of the Spanning Tree Protocol reduced topology can be far from optimal.




It would be desirable to provide a mechanism to provide for use of blocked links. Two such mechanisms exist. First, a Dynamic Load Sharing protocol is disclosed in U.S. Pat. No. 4,811,337. Second, a Generalized Dynamic Load Sharing protocol is disclosed in U.S. Pat. No. 5,150,360.




According to the Dynamic Load Sharing protocol, a blocked link may be used if four requirements are satisfied. First, the blocked link must be a point-to-point connection between two bridges running the Dynamic Load Sharing protocol. Second, the Spanning Tree Protocol active path between the two bridges must pass through the root bridge. Third, the root bridge must run the Dynamic Load Sharing protocol. Fourth, the Spanning Tree Protocol cost between the two bridges must be greater than the direct Dynamic Load Sharing protocol link cost.




The Dynamic Load Sharing protocol forwards traffic to the blocked link under limited conditions. First, the traffic must arrive from “below” one of the two bridges according to the spanning tree, with the root bridge located at the top of the spanning tree. Second, the traffic must be destined to a station “below” the other of the two bridges. Therefore, the Dynamic Load Sharing protocol unnecessarily limits the blocked paths which can be used. Similarly, the effectiveness of the protocol relies upon the selection of a root bridge.




According to the Generalized Dynamic Load Sharing protocol, a blocked link may be used if the link is a point-to-point connection between two bridges running the Generalized Dynamic Load Sharing protocol. Traffic is forwarded across a blocked link upon a dynamic load balancing through an exchange of packets. Frames are sent on both the Generalized Dynamic Load Sharing link and the Spanning Tree Protocol link. Traffic is then sent along the link determined to be the fastest link. In this manner, traffic is dynamically reallocated through the shifting of addresses, unlike the Dynamic Load Sharing Protocol. Moreover, the need for a third bridge, such as the root bridge used in the Dynamic Load Sharing Protocol, is removed. However, two significant drawbacks exist with the Generalized Dynamic Load Sharing Protocol. First, determination of the fastest link through the sending of traffic is difficult to determine in high speed, bursty load environments. Second, the movement of addresses from one link to another creates a high risk of misordering frames.




Accordingly, it would be desirable to provide a method and system for using blocked links through a more reliable link determination mechanism, and a more reliable method for exchanging addresses. These advantages are achieved in an embodiment of the invention in which address tables are maintained for each bridge, and in which the fastest link is determined based upon port cost.




BRIEF DESCRIPTION OF THE INVENTION




The present invention provides a method and system for utilizing ports blocked by the Spanning Tree Protocol. According to a first aspect of the present invention, a method for determining which blocked links may be used including two steps. First, the blocked link must be a point-to-point connection between two bridges running shortcut trunking. A point-to-point connection might be indicated by a full-duplex connection between bridges. A point-to-point connection is a connection in which two bridges are direct neighbors and which have no intervening bridges. A full-duplex connection is one on which traffic may be passed in both directions simultaneously. This ensures that no loops will be created through intervening shared media. Second, on at least one of the two bridges, the port cost of the blocked link must be of equal or lower cost than the cost of the unblocked port linking the two devices via the STP reduced topology. This guarantees that the selected blocked link is not more expensive than the path through the Spanning Tree Protocol path.




According to a second aspect of the present invention, a method for determining which traffic may be forwarded across the blocked link includes several steps. First, each bridge builds a shortcut address list including each unicast address “outside” the bridge, relative to the shortcut and the active STP path between the two bridges. Second, the address lists are exchanged. Third, each bridge compares traffic arriving from “outside” to determine if the destination is on the shortcut list received from the other bridge. If it is, the traffic is forwarded on the shortcut.




The present invention creates a mesh-like topology, permitting traffic to travel through the shortest path in the mesh. This reduces latency for traffic forwarded on the shortcut created through the blocked path. Moreover, overall network performance is improved since traffic is more evenly distributed on network links.











BRIEF DESCRIPTION OF THE DRAWINGS





FIG. 1

is a block diagram of a network having two bridges connected by a blocked link.





FIG. 2

illustrates a method for selecting a blocked link to allow forwarding of traffic on the blocked link according to a presently preferred embodiment of the present invention.





FIG. 3

illustrates the calculating step shown in

FIG. 2

according to a presently preferred embodiment of the present invention.





FIG. 4

illustrates a method for selecting traffic to forward on a blocked link according to a presently preferred embodiment of the present invention.





FIG. 5

illustrates a process for determining whether the source and destination addresses are both “outside” the first and second bridges according to a presently preferred embodiment of the present invention.





FIG. 6

illustrates a method for updating shortcut address lists according to a presently preferred embodiment of the present invention.





FIG. 7

is a block diagram of a bridge having more than one link useful as a shortcut link.





FIG. 8

is a block diagram of a bridge having more than one shortcut bridge reachable via a single Spanning Tree Protocol enabled port.





FIG. 9

is a block diagram illustrating two shortcut bridges reachable via a single Spanning Tree Protocol enabled port and having overlapping address lists.





FIG. 10

illustrates a method for determining which shortcut link to use for addresses requested by one or both of two shortcut bridges according to a presently preferred embodiment of the present invention.











DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS




In the following description, a preferred embodiment of the invention is described with regard to preferred process steps and data structures. However, those skilled in the art would recognize, after perusal of this application, that embodiments of the invention may be implemented using a set of general purpose computers operating under program control, and that modification of a set of general purpose computers to implement the process steps and data structures described herein would not require undue invention.




The present invention provides a method and system for utilizing blocked ports created by the Spanning Tree Protocol. Through the use of the present invention, a method for determining which blocked links may be used is provided. Moreover, a method for determining which traffic may be forwarded across the blocked link is set forth. These methods may be implemented in software or firmware, as well as in programmable gate array devices, ASIC and other hardware.




Referring first to

FIG. 1

, a block diagram of a network having two bridges


20


,


22


connected by a blocked link


24


is presented. Traffic having a source or destination address “within” the two bridges


26


must remain on the Spanning Tree Protocol enabled path


28


. Traffic is “outside” the two bridges


26


if it is reachable only through these two bridges


26


, and otherwise “inside” the two bridges


26


. In addition, all broadcast, multicast and unknown destination traffic must traverse this Spanning Tree Protocol enabled path


28


. Traffic “outside” the two bridges


30


,


32


will benefit from using a shortcut provided by utilizing the blocked link


24


between the two bridges


20


,


22


. Specifically, directed traffic from anywhere in region


30


to anywhere in region


32


, or from


32


to


30


, may beneficially traverse


24


rather than


28


. Although the invention is applied to bridges, the protocol is equally applicable to routers and other equivalent means.




Referring now to

FIG. 2

, a method for selecting a blocked link to allow forwarding of traffic on the blocked link according to a presently preferred embodiment of the present invention is illustrated. At step


34


, the next blocked link is found. At step


36


, it is determined whether the blocked link is a point-to-point connection between two bridges, each one of the two bridges having a plurality of ports. If the blocked link is not a point-to-point connection between the two bridges, if it is determined that there are more blocked links at step


38


, the next blocked link is analyzed at step


34


. If it is determined that the blocked link is a point-to-point connection between two bridges, at step


40


it is ascertained whether each one of the two bridges operates a Shortcut Trunking Exchange protocol. If the two bridges do not operate the Shortcut Trunking Exchange protocol, if it is determined that there are more blocked links at step


38


, the next blocked link is analyzed at step


34


. If it is determined that the two bridges operate the Shortcut Trunking Exchange protocol, at step


42


it is calculated whether (on at least one of the two bridges), a port cost of the blocked link


24


is equal to or lower than a port cost of the spanning tree enabled connection port that leads to the spanning tree enabled path


28


, on at least one of the two bridges.




If the port cost of the blocked link is equal or lower cost than all other port link costs, the blocked link is selected at step


44


. (Because of the nature of the spanning tree protocol, the port cost of the blocked link is equal or lower cost than all other port link costs if the port cost is equal or lower than the port cost of the spanning tree enabled connection port that leads to the spanning tree enabled path


28


.) If the port cost of the blocked link is not equal to or lower than all other port link costs, the next blocked link is analyzed at step


34


if it is determined that more blocked links exist at step


38


. If no more blocked links are available, the selection process fails at step


46


, and the traffic must be sent along the Spanning Tree Protocol enabled path. Those of ordinary skill in the art will readily recognize that the above steps are illustrative only and may be performed in an alternate order.




Referring now to

FIG. 3

, the calculating step


42


of

FIG. 2

according to a presently preferred embodiment of the present invention is illustrated. On at least one of the two bridges, the port cost of the blocked link must be of equal or lower cost than all other port link costs. For example, bridge protocol data units (BPDUs) are compared to determine which connection is the optimum connection. In a preferred embodiment, port cost has a default value, responsive to link speed, as specified in the IEEE 802.1D standard. It also may have been set to some other value by the user via management controls of the bridge.




At step


48


, a first bridge and a second bridge bordering the blocked link are located, the first and second bridges each having a plurality of ports. Next, at step


50


, a port cost of the blocked link is determined for the first bridge. Next, at step


52


, it is determined for the first bridge whether the port cost of the blocked link is of equal or lower cost than the port cost of each other one of the plurality of first bridge ports. If the port cost is equal or lower, the blocked link is selected as a shortcut link, and the process ends at step


54


. However, if the port cost is not equal or lower, the process continues.




At step


56


, a port cost of the blocked link is determined for the second bridge. Next, at step


58


, it is determined for the second bridge whether the port cost of the blocked link is of equal or lower cost than the port cost of each other one of the plurality of second bridge ports. If it is, the blocked link is selected as a shortcut link at step


54


. However, if it is not, the blocked link cannot be used as a shortcut link.




Those of ordinary skill in the art will readily recognize that the above steps are illustrative only and may be performed in an alternative order. In a preferred embodiment, the first bridge and the second bridge each independently make their own determination of port link cost, and communicate their determinations to each other using a “discovery” packet in the STEP protocol; the discovery packet is communicated between the first bridge and the second bridge using the blocked link


24


.




Once the blocked link


24


is selected for use as a shortcut link, selected traffic may be forwarded on the blocked link. Referring now to

FIG. 4

, a method for selecting traffic to forward on a blocked link according to a presently preferred embodiment of the present invention is presented. The traffic may be described as having both a source and a destination address. At step


60


, an outside address list is built for a first bridge, the shortcut address list including each address “outside” the first bridge. Next, at step


62


, an outside address list is built for a second bridge, the shortcut address list including each address “outside” the second bridge. Next, at step


64


, it is determined whether the source and destination addresses are both “outside” the first and second bridges. This is performed using the outside address lists for the first and second bridges. If the source and destination addresses are both “outside” the first and second bridges, the traffic may be forwarded.




At step


66


, it is determined that the traffic is unicast traffic, with a destination address for the traffic on the shortcut address list for the bridge (and arriving from an input interface other than the blocked link


24


). If the traffic is broadcast or multicast, the traffic remains on the Spanning Tree Protocol active paths. If the traffic is unicast traffic with a destination address on the shortcut address list (and arrives from an input interface other than the blocked link


24


), the traffic is forwarded across the blocked link


24


at step


68


. In other instances, the traffic remains on the Spanning Tree Protocol enabled paths at step


70


. Those of ordinary skill in the art will readily recognize that the above steps are illustrative only and may be performed in an alternative order.




Referring now to

FIG. 5

, a process for determining whether the source and destination addresses are both “outside” the first and second bridges


64


as shown in

FIG. 4

is presented. First, at step


72


, a Shortcut Trunking Exchange protocol packet is sent from the first bridge out every Spanning Tree Protocol enabled port of the first bridge to learn which Spanning Tree Protocol enabled port leads to the second bridge. Next, at step


74


, a Shortcut Trunking Exchange protocol packet is sent from the second bridge out every Spanning Tree Protocol enabled port of the second bridge to learn which Spanning Tree Protocol enabled port leads to the first bridge. Next, at step


76


, an acknowledgment is sent through the blocked link from the first bridge. Similarly, at step


78


, an acknowledgment is sent through the blocked link from the second bridge.] A shortcut address list for the first bridge is built at step


80


, the shortcut address list including all addresses on all ports except the Spanning Tree Protocol enabled port leading to the second bridge. Next, at step


82


, a shortcut address list for the second bridge is built, the shortcut address list again including all addresses on all ports except the Spanning Tree Protocol enabled port leading to the first bridge. Next, at step


84


, the shortcut address list for the first bridge is sent across the blocked link. Next, at step


86


, the shortcut address list for the second bridge is sent across the blocked link. The addresses specified in the shortcut address lists are those between which traffic is to be forwarded through the shortcut. Therefore, at step


88


, the shortcut address lists for the first and second bridges are ultimately used to determine whether traffic should be forwarded across the blocked link. Those of ordinary skill in the art will readily recognize that the above steps are illustrative only and may be performed in an alternate order.




Referring now to

FIG. 6

, a method for updating shortcut address lists according to a presently preferred embodiment of the present invention is presented. At step


90


, an address may be added to the shortcut address list for the first bridge. In a preferred embodiment, the address is added by forwarding the address along the shortcut port leading to the second bridge at step


92


.




Forwarding all such addresses has the advantage that little additional control traffic is added to the spanning tree paths of the network. However, in alternative embodiments, addresses may be added by one of the following techniques:




A complete list of shortcut addresses is built periodically by the bridge;




A complete list of shortcut addresses is sent periodically to the bridge;




A set of changes to the list of shortcut addresses is sent periodically to the bridge;




A message regarding shortcut addresses sent to the bridge may be optionally acknowledged by the bridge; or




A list of shortcut addresses at the bridge may be aged according to known techniques for aging destination addresses in a network topology.




An acknowledgment is sent from the second bridge across the blocked link to the first bridge at step


94


. Similarly, at step


96


, an address may be removed from the shortcut address list for the first bridge. According to a presently preferred embodiment of the present invention, the address to be removed is removed by forwarding the address along the blocked link to the second bridge at step


98


. Next, at step


100


, an acknowledgment is sent from the second bridge to the first bridge along the Spanning Tree Protocol enabled port leading to the first bridge. These steps may similarly be performed for each bridge in the network. Those of ordinary skill in the art will readily recognize that the above steps are illustrative only and may be performed in an alternate order.




Referring now to

FIG. 7

, a block diagram of a bridge


102


having more than one link useful as a shortcut link is presented. As shown, the bridge


102


has two possible shortcut links. A first shortcut link


104


connects the bridge


102


to a first shortcut bridge


106


, while the second shortcut link


108


connects the bridge


102


to a second shortcut bridge


110


. Each one of the shortcut bridges


106


,


110


will provide a shortcut address list of addresses which will use a selected shortcut. The shortcut address list for each shortcut bridge will include addresses on the “outside” of the corresponding shortcut bridge. As illustrated in

FIG. 7

, the shortcut address list for the first shortcut bridge will include addresses of bridges and devices “outside” the first shortcut bridge


112


. For example, the first shortcut bridge


106


will provide its shortcut address list over to the bridge


102


, which then forwards traffic arriving from the second shortcut bridge


110


and which matches these addresses along the first shortcut link


104


. Similarly, the shortcut address list for the second shortcut bridge


110


will include addresses of bridges and devices “outside” the second shortcut bridge


114


. For example, the second shortcut bridge


110


will provide its shortcut address list over to the bridge


102


, which then forwards traffic arriving from the first shortcut bridge


106


and which matches these addresses along the second shortcut link


108


. Traffic originating from or destined for an address which lies “inside” the first and second shortcut bridges


116


,


118


must remain on the STP path


120


.




In order to determine which shortcut link should be selected as the shortcut, the STP enabled port from the bridge directed toward each shortcut bridge is considered. If the STP enabled port directed to the first shortcut bridge and the second shortcut bridge are distinct, the first and second shortcut links can operate independently, and the corresponding shortcut lists are similarly distinct. However, if the STP enabled port directed to the first shortcut bridge and the second shortcut bridge are identical, the corresponding shortcut lists may contain overlapping addresses. Therefore, it is useful that a mechanism be provided to determine which one of the shortcut links to use for addresses requested by both the first shortcut bridge and the second shortcut bridge. If no mechanism is provided, indeterminacy may be handled by forwarding only on the STP paths in such cases.




Referring now to

FIG. 8

, a block diagram of a bridge having more than one shortcut bridge reachable via a single Spanning Tree Protocol enabled port is presented. A bridge


122


has addresses


124


reachable through an STP port


126


. A first shortcut bridge


128


has a shortcut address list


130


containing addresses “outside” the first shortcut bridge. In addition, a second shortcut bridge


132


has a shortcut address list


134


containing addresses “outside” the second shortcut bridge. As shown, the addresses contained in the shortcut address list


130


corresponding to the first shortcut bridge


128


and the addresses contained in the shortcut address list


134


corresponding to the second shortcut bridge


132


do not overlap. Thus, the two shortcuts


136


,


138


can operate independently, as shown in FIG.


7


.




Referring now to

FIG. 9

, a block diagram illustrating two shortcut bridges reachable via a single Spanning Tree Protocol enabled port and having overlapping address lists is presented. A first shortcut bridge


140


has a shortcut address list containing addresses “outside” the first shortcut bridge. As shown, the shortcut address list corresponding to the first shortcut bridge will contain bridge and device addresses corresponding to a first group


142


, a second group


144


, and a third group


146


of addresses. A second shortcut bridge


148


has a shortcut address list containing addresses “outside” the second shortcut bridge. The shortcut address list corresponding to the second shortcut bridge will contain bridge and device addresses corresponding to the third group


146


of addresses, as shown. Source and destination addresses


150


not falling “outside” the first


140


and second


148


shortcut bridges are sent along the STP path


152


.




Referring now to

FIG. 10

, a method for determining which shortcut link to use for addresses requested by one or both of the two shortcut bridges according to a presently preferred embodiment of the present invention is presented. First, at step


154


, the bridge asks each of the two shortcut bridges to “discover” an STP enabled port between the two shortcut bridges. At step


156


, a comparison between the STP enabled port from each of the two shortcut bridges to the other of the two shortcut bridges and the STP enabled port from each of the two shortcut bridges to the bridge is performed. At step


158


, each of the two shortcut bridges reports to the bridge whether the STP enabled port to the other of the two shortcut bridges is the same as the STP enabled port to the bridge. At step


160


, if the STP enabled ports in step


158


are determined to be different, the two shortcut bridges may maintain separate shortcut lists at step


162


. However, if at step


160


, the STP enabled ports of step


158


are determined to be identical, a process for determining which one of the shortcut links to use for overlapping addresses is followed. At step


164


, a multicast discovery frame is defined by the bridge. At step


166


, the multicast discovery frame is then sent along each STP enabled path via each Shortcut Trunking Exchange protocol enabled bridge within the network. Thus, the multicast discovery frame is received by each Shortcut Trunking Exchange protocol enabled bridge. Next, at step


168


, each Shortcut Trunking Exchange protocol enabled bridge within the network appends its bridge address to the multicast discovery frame. Next, at step


170


, the multicast discovery frame is forwarded along each remaining STP enabled port within the Shortcut Trunking Exchange protocol enabled bridge. These steps are repeated until the multicast discovery frame has been sent along each bridge. Thus, any addresses requested by both the first shortcut bridge and the second shortcut bridge are shortcutted to the shortcut bridge address lowest on the list of addresses contained in the multicast discovery frame at step


172


, since this shortcut bridge is furthest from the bridge. Those of ordinary skill in the art will readily recognize that the above steps are illustrative only and may be performed in an alternate order.




Through application of the present invention, a mesh-like topology may be created, allowing traffic to travel through the shortest path in the mesh. This reduces latency for traffic forwarded on the shortcut created through the blocked path. Moreover, overall network performance is improved since traffic is more evenly distributed throughout the network.




While embodiments and applications of this invention have been shown and described, it would be apparent to those skilled in the art that many more modifications than mentioned above are possible without departing from the inventive concepts herein. The invention, therefore, is not to be restricted except in the spirit of the appended claims.



Claims
  • 1. A method for enabling a blocked link to allow forwarding of traffic on the blocked link, the method including the following steps:determining whether the blocked link is a point-to-point connection between two bridges, each one of the two bridges having a plurality of ports; and ascertaining whether each one of the two bridges operates a Shortcut Trunking Exchange protocol; and calculating whether on at least one of the two bridges, a port cost of the blocked link is equal to or lower than a port cost of each other one of the plurality of ports.
  • 2. The method according to claim 1, wherein the calculating step includes the following sub-steps:locating a first bridge and a second bridge bordering the blocked link, the first and second bridges each having a plurality of ports; determining for the first bridge a port cost of the blocked link; and determining for the first bridge whether the port cost of the blocked link is of equal or lower cost than the port cost of a port for a spanning tree path connection between the bridges.
  • 3. The method according to claim 2, wherein the calculating step includes the following sub-steps:determining for the second bridge a port cost of the blocked link; and determining for the second bridge whether the port cost of the blocked link is of equal or lower cost than the port cost of a port for a spanning tree path connection from the second bridge to a spanning tree root node.
  • 4. A method for selecting traffic to forward on a blocked link, the traffic having a source and a destination address, the method including the following steps:building an outside address list for a first bridge, the outside address list including each address “outside” the first bridge; building an outside address list for a second bridge, the outside address list including each address “outside” the second bridge; determining that the input interface and destination address are both “outside” the first and second bridges using the outside address lists for the first and second bridges; and forwarding unicast traffic when the input interface and destination address are both “outside” the first and second bridges.
  • 5. The method according to claim 4, wherein the determining step includes the following sub-steps:sending from the first bridge a Shortcut Trunking Exchange protocol packet out every Spanning Tree Protocol enabled port of the first bridge to learn which Spanning Tree Protocol enabled port leads to the second bridge; sending from the second bridge a Shortcut Trunking Exchange protocol packet out every Spanning Tree Protocol enabled port of the second bridge to learn which Spanning Tree Protocol enabled port leads to the first bridge; sending an acknowledgment through the blocked link from the first bridge; sending an acknowledgment through the blocked link from the second bridge; building a shortcut address list for the first bridge based upon the outside address list for the first bridge, the shortcut address list excluding the Spanning Tree Protocol enabled port leading to the second bridge; building a shortcut address list for the second bridge based upon the outside address list for the second bridge, the shortcut address list excluding the Spanning Tree Protocol enabled port leading to the first bridge; sending the shortcut address list for the first bridge across the blocked link; sending the shortcut address list for the second bridge across the blocked link; and using the shortcut address lists for the first and second bridges to determine whether traffic should be forwarded across the blocked link.
  • 6. The method according to claim 5, the method including the following sub-step:adding an address to the shortcut address list for the first bridge.
  • 7. The method according to claim 6, wherein the adding step includes the following sub-steps:forwarding the address along the Spanning Tree Protocol enabled port leading to the second bridge; and sending an acknowledgment from the second bridge across the blocked link to the first bridge.
  • 8. The method according to claim 5, the method including the following step:replacing an address from the shortcut address list for the first bridge with an received address for said shortcut address list.
  • 9. The method according to claim 8, wherein the removing step includes the following sub-steps:forwarding the address along the shortcut to the second bridge; and sending an acknowledgment from the second bridge to the first bridge along the Spanning Tree Protocol enabled port leading to the first bridge.
  • 10. A method for selecting one of two blocked links within a network, the two blocked links including a first shortcut link and a second shortcut link, the first shortcut link bordered by a bridge and a first shortcut bridge, the second shortcut link bordered by the bridge and a second shortcut bridge, the method including the following steps:discovering an STP enabled port between the two shortcut bridges; reporting from the first shortcut bridge to the bridge whether the STP enabled port between the two shortcut bridges is identical to an STP enabled port from the first shortcut bridge to the bridge; reporting from the second shortcut bridge to the bridge whether the STP enabled port between the two shortcut bridges is identical to an STP enabled port from the second shortcut bridge to the bridge; and selecting one of the two shortcut links when the first shortcut bridge reporting step and the second shortcut bridge reporting step indicate that the STP enabled port between the two shortcut bridges is identical to the STP enabled port from the first shortcut bridge to the bridge and identical to the STP enabled port from the second shortcut bridge to the bridge.
  • 11. The method according to claim 10, wherein the selecting step includes the following sub-steps:defining a multicast discovery frame; sending the multicast discovery frame along each STP enabled path via a Shortcut Trunking Exchange protocol enabled bridge within the network; appending a bridge address to the multicast discovery frame; forwarding the multicast discovery frame along each remaining STP enabled port within the Shortcut Trunking Exchange protocol enabled bridge; and shortcutting addresses requested by the first shortcut bridge and the second shortcut bridge to a bridge corresponding to an address list appended to the multicast discovery frame.
  • 12. An apparatus for enabling a blocked link to allow forwarding of traffic on the blocked link, including:means for determining whether the blocked link is a point-to-point connection between two bridges, each one of the two bridges having a plurality of ports; and means for ascertaining whether each one of the two bridges operates a Shortcut Trunking Exchange protocol; and means for calculating whether on at least one of the two bridges, a port cost of the blocked link is equal to or lower than a port cost of a port for a spanning tree path connection between the bridges.
  • 13. The apparatus according to claim 12, wherein the means for calculating includes:means for locating a first bridge and a second bridge bordering the blocked link, the first and second bridges each having a plurality of ports; means for determining for the first bridge a port cost of the blocked link; and means for determining for the first bridge whether the port cost of the blocked link is of equal or lower cost than the port cost of a port for a spanning tree path connection between the said first bridge and a spanning tree root node.
  • 14. The apparatus according to claim 13, wherein the means for calculating includes:means for determining for the second bridge a port cost of the blocked link; and means for determining for the second bridge whether the port cost of the blocked link is of equal or lower cost than the port cost of a port for a spanning tree path to a spanning tree root node.
  • 15. An apparatus for selecting traffic to forward on a blocked link, the traffic having a source and a destination address, the apparatus including:means for building an outside address list for a first bridge, the outside address list including each address “outside” the first bridge; means for building an outside address list for a second bridge, the outside address list including each address “outside” the second bridge; means for determining that the source and destination addresses are both “outside” the first and second bridges using the outside address lists for the first and second bridges; and means for forwarding the traffic if the traffic is unicast traffic when the source and destination addresses are both “outside” the first and second bridges.
  • 16. The apparatus according to claim 15, wherein the means for determining includes:means for sending from the first bridge a Shortcut Trunking Exchange protocol packet out every Spanning Tree Protocol enabled port of the first bridge to learn which Spanning Tree Protocol enabled port leads to the second bridge; means for sending from the second bridge a Shortcut Trunking Exchange protocol packet out every Spanning Tree Protocol enabled port of the second bridge to learn which Spanning Tree Protocol enabled port leads to the first bridge; means for sending an acknowledgment through the blocked link from the first bridge; means for sending an acknowledgment through the blocked link from the second bridge; means for building a shortcut address list for the first bridge based upon the outside address list for the first bridge, the shortcut address list excluding the Spanning Tree Protocol enabled port leading to the second bridge; means for building a shortcut address list for the second bridge based upon the outside address list for the second bridge, the shortcut address list excluding the Spanning Tree Protocol enabled port leading to the first bridge; means for sending the shortcut address list for the first bridge across the blocked link; means for sending the shortcut address list for the second bridge across the blocked link; and means for using the shortcut address lists for the first and second bridges to determine whether traffic should be forwarded across the blocked link.
  • 17. The apparatus according to claim 16, the apparatus including means for adding an address to the shortcut address list for the first bridge.
  • 18. The apparatus according to claim 17, wherein the means for adding includes:means for forwarding the address along the Spanning Tree Protocol enabled port leading to the second bridge; and means for sending an acknowledgment from the second bridge across the blocked link to the first bridge.
  • 19. The apparatus according to claim 16, the apparatus including means for removing an address from the shortcut address list for the first bridge.
  • 20. The apparatus according to claim 19, wherein the means for removing includes:means for forwarding the address along the shortcut to the second bridge; and means for sending an acknowledgment from the second bridge to the first bridge along the Spanning Tree Protocol enabled port leading to the first bridge.
  • 21. An apparatus for selecting one of two blocked links within a network, the two blocked links including a first shortcut link and a second shortcut link, the first shortcut link bordered by a bridge and a first shortcut bridge, the second shortcut link bordered by the bridge and a second shortcut bridge, the apparatus includingmeans for discovering an STP enabled port between the two shortcut bridges; means for reporting from the first shortcut bridge to the bridge whether the STP enabled port between the two shortcut bridges is identical to an STP enabled port from the first shortcut bridge to the bridge; means for reporting from the second shortcut bridge to the bridge whether the STP enabled port between the two shortcut bridges is identical to an STP enabled port from the second shortcut bridge to the bridge; and means for selecting one of the two shortcut links when the first shortcut bridge reporting step and the second shortcut bridge reporting step indicate that the STP enabled port between the two shortcut bridges is identical to the STP enabled port from the first shortcut bridge to the bridge and identical to the STP enabled port from the second shortcut bridge to the bridge.
  • 22. The apparatus according to claim 21, wherein the means for selecting includes the following:means for defining a multicast discovery frame; means for sending the multicast discovery frame along each STP enabled path via a Shortcut Trunking Exchange protocol enabled bridge within the network; means for appending a bridge address to the multicast discovery frame; means for forwarding the multicast discovery frame along each remaining STP enabled port within the Shortcut Trunking Exchange protocol enabled bridge; and means for shortcutting addresses requested by the first shortcut bridge and the second shortcut bridge to a bridge corresponding to an address last appended to the multicast discovery frame.
  • 23. A method for routing traffic across a blocked link, the traffic having a source and a destination address, the method including the following steps:determining whether the blocked link is a point-to-point connection between two bridges, each one of the two bridges having a plurality of ports; and ascertaining whether each one of the two bridges operates a Shortcut Trunking Exchange protocol; calculating whether on at least one of the two bridges, a port cost of the blocked link is equal to or lower than a port cost of a port for a spanning tree path; building an outside address list for a first bridge, the outside address list including each address “outside” the first bridge; building an address list for a second bridge, the outside address list including each address “outside” the second bridge; determining that the source and destination addresses are both “outside” the first and second bridges using the outside address lists for the first and second bridges; and forwarding the traffic if the traffic is unicast traffic when the source and destination addresses are both “outside” the first and second bridges.
  • 24. An apparatus for routing traffic across a blocked link, the traffic having a source and a destination address, including:means for determining whether the blocked link is a point-to-point connection between two bridges, each one of the two bridges having a plurality of ports; and means for ascertaining whether each one of the two bridges operates a Shortcut Trunking Exchange protocol; means for calculating whether on at least one of the two bridges, a port cost of the blocked link is equal to or lower than a port cost of a port for a spanning tree path; means for building an outside address list for a first bridge, the outside address list including each address “outside” the first bridge; means for building an outside address list for a second bridge, the outside address list including each address “outside” the second bridge; means for determining that the source and destination addresses are both “outside” the first and second bridges using the outside address lists for the first and second bridges; and means for forwarding the traffic if the traffic is unicast traffic when the source and destination addresses are both “outside” the first and second bridges.
  • 25. A method for routing traffic in a network having a spanning tree, said spanning tree including a plurality of nodes in said network and a plurality of links coupling pairs of said nodes, said plurality of nodes including a root node and at least one non-root node, said plurality of links forming a path coupling each non-root node to said root node, and said plurality of links forming a path coupling a first said non-root node to a second said non-root node through said route node, said spanning tree including substantially all nodes in said network and excluding a set of links in said network, said method including steps fordetermining a set of shortcut routes for said network, each said shortcut route including at least one link excluded from said spanning tree, each said shortcut route having a set of shortcut destinations associated therewith, said set of shortcut routes excluding a closed loop of links, whereby messages routed within a union of said spanning tree and said set of shortcut routes are not returned in a closed loop to a point of origin.
  • 26. A method as in claim 25, wherein said steps for determining includeselecting a set of shortcut routes, each said shortcut route including at least one link excluded from said spanning tree; associating a set of shortcut destinations with each said shortcut route, wherein said steps for associating include steps for transmitting a list of shortcut destinations to a node coupled to said shortcut route.
  • 27. A method as in claim 26, whereinsaid steps for transmitting are performed substantially periodically; and said list of shortcut destinations includes a substantially complete list.
  • 28. A method as in claim 26, whereinsaid steps for transmitting are performed substantially periodically; and said list of shortcut destinations includes a set of updates.
  • 29. A method as in claim 26, whereinsaid steps for associating include steps for, at least one said node coupled to said shortcut route, aging said shortcut destinations.
US Referenced Citations (233)
Number Name Date Kind
4131767 Weinstein Dec 1978 A
4161719 Parikh et al. Jul 1979 A
4316284 Howson Feb 1982 A
4397020 Howson Aug 1983 A
4419728 Larson Dec 1983 A
4424565 Larson Jan 1984 A
4437087 Petr Mar 1984 A
4438511 Baran Mar 1984 A
4439763 Limb Mar 1984 A
4445213 Baugh et al. Apr 1984 A
4446555 Devault et al. May 1984 A
4456957 Schieltz Jun 1984 A
4464658 Thelen Aug 1984 A
4499576 Fraser Feb 1985 A
4506358 Montgomery Mar 1985 A
4507760 Fraser Mar 1985 A
4532626 Flores et al. Jul 1985 A
4644532 George et al. Feb 1987 A
4646287 Larson et al. Feb 1987 A
4677423 Benvenuto et al. Jun 1987 A
4679189 Olson et al. Jul 1987 A
4679227 Hughes-Hartogs Jul 1987 A
4723267 Jones et al. Feb 1988 A
4731816 Hughes-Hartogs Mar 1988 A
4750136 Arpin et al. Jun 1988 A
4757495 Decker et al. Jul 1988 A
4763191 Gordon et al. Aug 1988 A
4769810 Eckberg, Jr. et al. Sep 1988 A
4769811 Eckberg, Jr. et al. Sep 1988 A
4771425 Baran et al. Sep 1988 A
4819228 Baran et al. Apr 1989 A
4827411 Arrowood et al. May 1989 A
4833706 Hughes-Hartogs May 1989 A
4835737 Herrig et al. May 1989 A
4879551 Georgiou et al. Nov 1989 A
4893304 Giacopelli et al. Jan 1990 A
4893306 Chao et al. Jan 1990 A
4903261 Baran et al. Feb 1990 A
4905233 Cain et al. Feb 1990 A
4922486 Lidinsky et al. May 1990 A
4933937 Konishi Jun 1990 A
4960310 Cushing Oct 1990 A
4962497 Ferenc et al. Oct 1990 A
4962532 Kasirai et al. Oct 1990 A
4965772 Daniel et al. Oct 1990 A
4970678 Sladowski et al. Nov 1990 A
4979118 Kheradpir Dec 1990 A
4980897 Decker et al. Dec 1990 A
4991169 Davis et al. Feb 1991 A
4996685 Farese et al. Feb 1991 A
5003595 Collins et al. Mar 1991 A
5014265 Hahne et al. May 1991 A
5020058 Holden et al. May 1991 A
5033076 Jones et al. Jul 1991 A
5051987 Conlon Sep 1991 A
5054034 Hughes-Hartogs Oct 1991 A
5059925 Weisbloom Oct 1991 A
5072449 Enns et al. Dec 1991 A
5088032 Bosack Feb 1992 A
5095480 Fenner Mar 1992 A
RE33900 Howson Apr 1992 E
5115431 Williams et al. May 1992 A
5115495 Tsuchiya et al. May 1992 A
5128926 Perlman et al. Jul 1992 A
5128945 Enns et al. Jul 1992 A
5136580 Videlock et al. Aug 1992 A
5166930 Braff et al. Nov 1992 A
5189662 Kleine-Altekamp Feb 1993 A
5199049 Wilson Mar 1993 A
5206886 Bingham Apr 1993 A
5208811 Kashio et al. May 1993 A
5212686 Joy et al. May 1993 A
5224099 Corbalis et al. Jun 1993 A
5226120 Brown et al. Jul 1993 A
5228062 Bingham Jul 1993 A
5229994 Balzano et al. Jul 1993 A
5231633 Hluchyj et al. Jul 1993 A
5233604 Ahmadi et al. Aug 1993 A
5237564 Lespagnol et al. Aug 1993 A
5241682 Bryant et al. Aug 1993 A
5243342 Kattemalalavadi et al. Sep 1993 A
5243596 Port et al. Sep 1993 A
5247516 Bernstein et al. Sep 1993 A
5249178 Kurano et al. Sep 1993 A
5249292 Chiappa Sep 1993 A
5251205 Callon et al. Oct 1993 A
5253251 Aramaki Oct 1993 A
5255291 Holden et al. Oct 1993 A
5260933 Rouse Nov 1993 A
5260978 Fleischer et al. Nov 1993 A
5268592 Bellamy et al. Dec 1993 A
5268900 Hluchyj et al. Dec 1993 A
5271004 Proctor et al. Dec 1993 A
5274631 Bhardwaj Dec 1993 A
5274635 Rahman et al. Dec 1993 A
5274643 Fisk Dec 1993 A
5280470 Buhrke et al. Jan 1994 A
5280480 Pitt et al. Jan 1994 A
5280500 Mazzola et al. Jan 1994 A
5283783 Nguyen et al. Feb 1994 A
5287103 Kasprzyk et al. Feb 1994 A
5287453 Roberts Feb 1994 A
5291482 McHarg et al. Mar 1994 A
5305311 Lyles Apr 1994 A
5307343 Bostica et al. Apr 1994 A
5309437 Perlman et al. May 1994 A
5311509 Heddes et al. May 1994 A
5313454 Bustini et al. May 1994 A
5313582 Hendel et al. May 1994 A
5317562 Nardin et al. May 1994 A
5319644 Liang Jun 1994 A
5325358 Goeldner Jun 1994 A
5327421 Hiller et al. Jul 1994 A
5331637 Francis et al. Jul 1994 A
5335224 Cole et al. Aug 1994 A
5345445 Hiller et al. Sep 1994 A
5345446 Hiller et al. Sep 1994 A
5353283 Tsuchiya Oct 1994 A
5359592 Corbalis et al. Oct 1994 A
5361250 Nguyen et al. Nov 1994 A
5361256 Doeringer et al. Nov 1994 A
5361259 Hunt et al. Nov 1994 A
5365524 Hiller et al. Nov 1994 A
5367517 Cidon et al. Nov 1994 A
5371852 Attanasio et al. Dec 1994 A
5386567 Lien et al. Jan 1995 A
5390170 Sawant et al. Feb 1995 A
5390175 Hiller et al. Feb 1995 A
5394394 Crowther et al. Feb 1995 A
5394402 Ross Feb 1995 A
5400325 Chatwani et al. Mar 1995 A
5408469 Opher et al. Apr 1995 A
5416842 Aziz May 1995 A
5422880 Heitkamp et al. Jun 1995 A
5422882 Hiller et al. Jun 1995 A
5423002 Hart Jun 1995 A
5426636 Hiller et al. Jun 1995 A
5426637 Derby et al. Jun 1995 A
5428607 Hiller et al. Jun 1995 A
5430715 Corbalis et al. Jul 1995 A
5430729 Rahnema Jul 1995 A
5432784 Ozveren Jul 1995 A
5442457 Najafi Aug 1995 A
5442624 Bonomi et al. Aug 1995 A
5442630 Gagliardi et al. Aug 1995 A
5452297 Hiller et al. Sep 1995 A
5473599 Li et al. Dec 1995 A
5473607 Hausman et al. Dec 1995 A
5477541 White et al. Dec 1995 A
5485455 Dobbins et al. Jan 1996 A
5490140 Abensour et al. Feb 1996 A
5490258 Fenner Feb 1996 A
5491687 Christensen et al. Feb 1996 A
5491693 Britton et al. Feb 1996 A
5491804 Heath et al. Feb 1996 A
5497368 Reijnierse et al. Mar 1996 A
5504747 Sweasey Apr 1996 A
5509006 Wilford et al. Apr 1996 A
5517494 Green May 1996 A
5517617 Sathaye et al. May 1996 A
5517620 Hashimoto et al. May 1996 A
5519704 Farinacci et al. May 1996 A
5519858 Walton et al. May 1996 A
5524254 Morgan et al. Jun 1996 A
5526489 Nilakantan et al. Jun 1996 A
5530963 Moore et al. Jun 1996 A
5535195 Lee Jul 1996 A
5535338 Krause et al. Jul 1996 A
5539734 Burwell et al. Jul 1996 A
5541911 Nilakantan et al. Jul 1996 A
5546370 Ishikawa Aug 1996 A
5550816 Hardwick et al. Aug 1996 A
5555244 Gupta et al. Sep 1996 A
5561669 Lenney et al. Oct 1996 A
5577105 Baum et al. Nov 1996 A
5583862 Callon Dec 1996 A
5586121 Mourn et al. Dec 1996 A
5592470 Rudrapatna et al. Jan 1997 A
5596574 Perlman et al. Jan 1997 A
5598581 Daines et al. Jan 1997 A
5600798 Chenrukuri et al. Feb 1997 A
5604868 Komine et al. Feb 1997 A
5608726 Virgile Mar 1997 A
5617417 Sathe et al. Apr 1997 A
5617421 Chin et al. Apr 1997 A
5630125 Zellweger May 1997 A
5631908 Saxe May 1997 A
5632021 Jennings et al. May 1997 A
5634010 Ciscon et al. May 1997 A
5634011 Auerbach et al. May 1997 A
5638359 Peltola et al. Jun 1997 A
5644718 Belove et al. Jul 1997 A
5659684 Giovannoni et al. Aug 1997 A
5666353 Klausmeier et al. Sep 1997 A
5673265 Gupta et al. Sep 1997 A
5678006 Valizadeh et al. Oct 1997 A
5680116 Hashimoto et al. Oct 1997 A
5684797 Aznar et al. Nov 1997 A
5684954 Kaiserswerth et al. Nov 1997 A
5687324 Green et al. Nov 1997 A
5689506 Chiussi et al. Nov 1997 A
5694390 Yamato et al. Dec 1997 A
5724351 Chao et al. Mar 1998 A
5740157 Demiray et al. Apr 1998 A
5742760 Picazo, jr. et al. Apr 1998 A
5742905 Pepe et al. Apr 1998 A
5748186 Raman May 1998 A
5748617 McLain, Jr. May 1998 A
5751971 Dobbins et al. May 1998 A
5754547 Nakazawa May 1998 A
5774698 Olnowich Jun 1998 A
5802054 Bellenger Sep 1998 A
5835710 Nagami et al. Nov 1998 A
5854903 Morrison et al. Dec 1998 A
5856981 Voelker Jan 1999 A
5892924 Lyon et al. Apr 1999 A
5898686 Virgile Apr 1999 A
5898687 Harriman et al. Apr 1999 A
5903559 Acharya et al. May 1999 A
5905723 Varghese et al. May 1999 A
5914953 Krause et al. Jun 1999 A
5959968 Chin et al. Sep 1999 A
5991817 Rowett et al. Nov 1999 A
6023733 Periasamy et al. Feb 2000 A
6032194 Gai et al. Feb 2000 A
6035105 McCloghrie et al. Mar 2000 A
6078590 Farinacci et al. Jun 2000 A
6081512 Muller et al. Jun 2000 A
6097718 Bion Aug 2000 A
6111877 Wilford et al. Aug 2000 A
6122272 Tomaszewski et al. Sep 2000 A
6157641 Wilford Dec 2000 A
6219739 Dutt et al. Apr 2001 B1
Foreign Referenced Citations (7)
Number Date Country
0 384 758 Aug 1990 EP
0 431 751 Jun 1991 EP
0 567 217 Oct 1993 EP
WO9307569 Apr 1993 WO
WO9307692 Apr 1993 WO
WO9401828 Jan 1994 WO
WO9520850 Aug 1995 WO
Non-Patent Literature Citations (17)
Entry
William Stallings, Data and Computer Communications, pp. 329-333, Prentice Hall, Upper Saddle River, New Jersey 07458.
Allen, M., “Novell IPX Over Various WAN Media (IPXW AN),” Network Working Group, RFC 1551, Dec. 1993, pp. 1-22.
Becker, D., “3c589.c: A 3c589 EtherLink3 ethernet driver for linux,” beckerΞCESDIS.gsfc.nasa.gov, May 3, 1994, pp. 1-13.
Chowdhury, et al., “Alternative Bandwidth Allocation Algorithms for Packet Video in ATM Networks,” INFOCOM 1992, PP. 1061-1068.
Doeringer, W., “Routing on Longest-Matching Prefixes,” IEEE/ACM Transactions in Networking, vol. 4, No. 1, Feb. 1996, pp. 86-97.
Esaki, et al., “Datagram Delivery in an ATM-Internet,” 2334b IEICE Transactions on Communications, Mar. 1994, No. 3, Tokyo, Japan.
IBM Corporation, “Method and Apparatus for the Statistical Multiplexing of Voice, Data and Image Signals,” IBM Technical Disclosure Bulletin, No. 6, Nov. 1992, pp. 409-411.
Pei, et al., “Putting Routing Tables in Silicon,” IEEE Network Magazine, Jan. 1992, pp. 42-50.
Perkins, D., “Requirements for an Internet Standard Point-to-Point Protocol,” Network Working Group, RFC 1547, Dec. 1993, pp. 1-19.
Simpson, W., “The Point-to-Point Protocol (PPP),” Network Working Group, RFC 1548, Dec. 1993, pp. 1-53.
Tsuchiya, P.F., “A Search Algorithm for Table Entries with Non-Contiguous Wildcarding,” Abstract, Bellcore.
Zhang, et al., “Rate-Controlled Static-Priority Queueing,” INFOCOM 1993, pp. 227-236.
ATM Forum Technical Committee. “Fault Tolerant for point-to-Multipoint connections in PNNI”. Jul. 20-25, 1997. Montreal, Quebec, Canada.
Frame Relay Documentation. Copyright 1989-1999, Cisco Systems, Inc., Posted Tue Sep. 21, 1999.
Nick McKeown et al. “The Bay Bridge: A High Speed Bridge/Router”. Presented at IFIP PFHSN Workshop, Stockholm, Swede, May 1992.
Nick McKeown et al. Architecture and Performance of The Bay Bridge: A High Speed Bridge/Router Between FDDI and SMDS. Project Report: 13 Revision: 2.0 Dept. of EE, University of California at Berkeley.
Nick McKeown and Fouad Tobagi. “Bridges, Routers and Switches”. Dept. of EE, Standford University, Standford, California.