Patent Publication Number: US-11025527-B2

Title: Topology change processing in bridged networks using a spanning tree protocol

Description:
BACKGROUND 
     The present disclosure relates to computer networks, and more particularly to topology changes in networks using a spanning tree protocols. 
       FIG. 1  shows a typical network  104  interconnecting network stations  110 . The network is divided into multiple segments Lx (L 1 , L 2 , L 3 , . . . ). Data are forwarded from one segment Lx to another through bridges Bx (B 1 , B 2 , etc.). Each segment Lx has zero or more stations  110 , and has one or more bridges attached to the segment. A segment Lx can be a bus type (e.g. Ethernet), a token ring, or some other type. 
     An important goal in network management is loop avoidance, i.e. not allowing data to circulate from bridge to bridge, possibly never reaching the destination. Loops can be avoided by selectively deactivating some of the bridge ports so that the network would have only one active path between any two bridges Bx and between any two segments Lx. 
     Specifically, each bridge Bx has ports connected to respective segments (“links”) Lx. For example, bridge B 1  has ports P 1 , P 2 , P 3  connected to respective links L 2 , L 7 , L 1 . See also  FIG. 2 , in which the stations  110  are omitted for clarity. Network  104  has a loop formed by bridges B 1 , B 2 , B 4 , B 6 . The loop can be eliminated by blocking a port in the loop, for example, port P 2  of switch B 6 . The port blocking is shown in  FIG. 2  by line  210  adjacent to port P 2 . Port P 2  can be unblocked in case of failure of some other port in the loop, e.g. of port P 2  of bridge B 2 ; or in case there is a change in the cost of the paths, e.g. if link L 5  becomes more expensive and/or link L 6  becomes less expensive; or in case a link or a bridge is added or removed; or in response to other needs. 
     Bridges Bx can automatically configure themselves to block or unblock their ports. The configuration can be performed by the bridges executing a Spanning Tree Protocol (STP) or its variants, e.g. Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), or some other STP variant; STP and its variants are denoted generally as “xSTP”. RSTP is described, for example, in IEEE (Institute of Electrical and Electronic Engineers) Standard 802.1D™-2004, incorporated herein by reference; and is currently defined by IEEE standard 802.1w. See e.g. “Understanding Rapid Spanning Tree Protocol (802.1w)”, Cisco, Inc., Document ID: 24062, Aug. 1, 2017, incorporated herein by reference. Under xSTP, the bridges Bx exchange Bridge Protocol Data Units (BPDUs) to learn about each other and block or unblock ports as needed. The BPDUs are consumed by the bridges and are not forwarded. Therefore, BPDUs cannot circulate indefinitely, and can be transmitted even on blocked ports and even if loops are present. 
     Much effort has been devoted to shorten the time and network traffic required for network configuration. See e.g. U.S. Pat. No. 9,059,930, issued Jun. 16, 2015 (inventors: Janardhanan et al.), incorporated herein by reference. Improved network configuration techniques are desirable. 
     SUMMARY 
     This section describes some aspects of the present invention. Other aspects are described in subsequent sections. The invention is defined by the appended claims. 
     Some embodiments of the present invention provide network configuration techniques that may reduce the configuration time and/or improve bridge resource utilization. For example, as described in the aforementioned U.S. Pat. No. 9,059,930, a port reconfiguration on one bridge may require topology change notifications sent to other bridges. Some embodiments identify specific situations when topology change notifications are unnecessary. The topology change notification (TCN) traffic is therefore reduced, resulting in better bandwidth utilization and reduction of unnecessary TCN processing by bridges. 
     Other features are within the scope of the present invention as defined by the appended claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIGS. 1 and 2  illustrate a bridged network. 
         FIG. 3  illustrates a network bridge. 
         FIG. 4  illustrates network data. 
         FIG. 5  illustrates a bridged network. 
         FIG. 6  is a flowchart of a network configuration process. 
         FIGS. 7, 8, 9, 10A, 10B, 11A, 11B, 11C, 11D, 11E  illustrate bridged networks. 
     
    
    
     DETAILED DESCRIPTION 
     This section illustrates some features of the invention. The invention is not limited to such features, except as defined by the appended claims. 
     As noted above, the xSTP protocols aim at providing only one active path between any two bridges and between any two segments. This means that the active network topology is a tree. In the example of  FIG. 2 , the bridge B 1  can be the root bridge of the tree. (The root bridge can be selected by an administrator (a human), or automatically selected using bridge priorities and/or bridge IDs; see the IEEE 802.1D standard cited above.) Every non-root bridge Bx has a Root port through which the bridge can reach the root bridge B 1  in the active topology. (Typically, the Root port is on the lowest-cost path to the Root bridge.) For example, in bridges B 6 , B 2 , and B 3 , the ports P 1  are Root ports, having Root “role” in RSTP terminology. (RSTP is used as an example; some aspects of the invention apply to other xSTP protocols.) In stable topology (not during network configuration), the Root ports are active, i.e. in Forwarding state. The forwarding state is shown as “/F” in  FIG. 2 , so the Root/Forwarding ports are marked as “R/F”. 
     In each network segment Lx, there is a single Forwarding port used by the segment&#39;s stations  110  to reach the root bridge B 1 . This port&#39;s role is “Designated” (shown as “D” in  FIG. 2 ). For example, in segment L 6 , the port P 1  of bridge B 4  is Designated (shown as “D/F”; the port is Forwarding). Typically, the Designated port is on the lowest-cost path to the Root bridge. 
     In bridge B 6 , port P 2  is blocked, i.e. in Discarding state (shown as /D). This port&#39;s role is “Alternate” (“A”): if Root port P 1  fails, the port P 2  may become unblocked, and may become the Root port, to provide access to root bridge B 1  through bridges B 4  and B 2 . 
     In bridge B 2 , port P 3  is Designated for segment L 3 , and port P 4  is Backup for the same segment: if the Designated port P 3  fails, port P 4  may become the new designated port. 
     The Alternate and Backup ports are typically Discarding (/D). 
     Besides the Forwarding and Discarding states, a port may be in a “Learning” state, which can be intermediate between Discarding and Forwarding. For example, if port P 1  on bridge B 4  fails, and port P 2  on bridge B 6  becomes Designated for segment L 6 , then port P 2  of bridge B 6  may become Learning before becoming Forwarding. In Learning state, the port P 2  will monitor the data from stations  110  on segment L 6  to learn their addresses. The addresses are recoded in filtering data base (FDB)  302  shown in  FIG. 3  and described below. After a short period of time, a Learning port becomes Forwarding. 
       FIG. 3  illustrates an exemplary architecture of a bridge Bx. (Other architectures are also possible, and different bridges may have different architectures in the same network.) The bridge of  FIG. 3  includes circuitry  310  which may include one or more computer processors that execute computer programs with instructions (not shown) stored in memory  320 . For example, the computer programs may execute the learning algorithms to learn the station  110  addresses and store them in FDB  302  maintained in memory  320 . The address learning occurs when a port receives data in the Learning or Forwarding state. The computer programs may also create and maintain Address Resolution Protocol (ARP) cache  328  stored in memory  320  and described below. Circuitry  310  may also include circuits that receive, store, and forward data frames based on FDB  302  and ARP cache  328  and possibly other data. 
     The bridge includes ports Px (such as P 1 , P 2 , etc. described above) and, possibly, user interface  329  for use by an administrator. 
     Memory  320  includes configuration data  330  which define various aspects of the bridge operation. See e.g. the aforementioned IEEE Standard 802.1D-2004. In particular, for each port Px, configuration data  330  includes per-port data  340  which define various aspects of the port operation. The types of port data depend on the STP variant and implementation, and may include: state data  346  indicating the port&#39;s state (Forwarding, Discarding, or Learning in RSTP); role data  347  indicating the port&#39;s role (e.g. Root, Designated, Alternate, or Backup); Edge port flag  350  (explained below); link type  352  (explained below); and peer port data  354 , defining the role and state of the peer ports, i.e. other bridge ports on the same link Lx. 
     Edge port flag  350  defines whether the port is an Edge port, i.e. the attached link Lx is not attached to any other bridge port. For example, the port P 2  of bridge B 5  is an Edge port. 
     Link type  352  indicates, for a non-edge port, whether the attached link is point-to-point (attached to only one other bridge port) or shared (attached to more than one other bridge ports). In  FIG. 2 , link L 6  is shared, and links L 4  and L 7  are point-to-point. 
     If the port s not an edge port, then peer port data  354  define the role and state of every peer port. 
     The data described above indicate the type of information stored by the bridge; this information can be coded in many ways. For example, edge port flag  350  and link type  352  can be represented by a single code: “zero” means this is an Edge port; “1” means this is a point-to-point link; “2” means a shared link. Other variations are possible. 
       FIG. 4  illustrates FDB  302 , ARP cache  328 , and a data frame  400 . When a bridge Bx receives a data frame  400 , the bridge must decide on which port (“outbound port”) the frame must be forwarded. Data frame  400  contains a source address  406 S and a destination address  406 D (sometimes called MAC addresses (MAC stands for Media Access Control) or Layer-2 addresses). The FDB  302  specifies the outbound port or ports for destination address  406 D. For example, for bridge B 1 , the FDB  302  may specify the port P 1  for destination addresses on LAN (Local Area Network) segments L 2  through L 6  and L 8 . 
     The bridge will not forward a frame on a port on which the frame was received. 
     If the destination address  406 D is not in database  302 , the bridge floods the frame, i.e. forwards the frame on all the ports except the port on which the frame was received (unless security or other restrictions apply). Flooding can be avoided however if ARP cache  328  is used to forward the frame, as described below. 
     FDB  302  can be populated by an administrator (a human), but can also be dynamically learned by the bridge from the data frames&#39; source addresses. For example, if bridge B 1  receives a data frame on port P 1  with some source address value AD 1 , the bridge will associate AD 1  with the port P 1 , and will enter this association into FDB  302 . The database will show the port P 1  as the outbound port for address AD 1 . Clearly, when the network topology changes, e.g. stations  110  or Bx are disconnected or moved, the filtering database  302  should be flushed entirely or partially. Preferably, the flooding should be limited to those entries which become obsolete due to the topology change. Removal of other entries may lead to unnecessary flooding. 
     ARP cache  328  is used for forwarding data frames for which the bridge does not have a MAC address in FDB  302 , if the data frame contains a network destination address  430 D (also called Layer-3 address, e.g. an IP address). No flooding is performed in this case. Specifically, a data frame&#39;s Layer-2 payload may include Layer-3 destination address  430 D and Layer-3 source address  4305 . If the data frame&#39;s MAC destination address  406 D is the bridge&#39;s address, and the frame&#39;s Layer-3 destination address  430 D is present in the bridge&#39;s ARP cache  328 , then the bridge will forward the frame to the corresponding MAC address in the ARP cache (unless restrictions apply). The MAC address can be looked up in FDB  302  to determine the outbound port. The MAC address may be that of the final destination (the same as identified by Layer-3 address  430 D), or may be of another bridge that can forward the frame to the final destination. 
     The ARP cache is populated by an administrator or an automatic learning process in which the bridge may broadcast an inquiry about a layer-3 address to obtain the corresponding MAC address; the MAC address is provided in response to the inquiry by the address owner (a station  110  or bridge Bx) or another bridge that can forward data frames to the layer-3 address. 
     If a port Px is no longer part of the active topology, some stations  110  and bridges Bx are no longer reachable through the port, and the corresponding dynamic entries in the bridge&#39;s FDB  302  should be removed. See IEEE 802.4, section 17.11. (Dynamic entries are modifiable entries obtained through learning, as opposed to Static, non-modifiable entries.) For example, if port P 2  of bridge B 2  goes down, and port P 2  of bridge B 6  is unblocked, then bridge B 2  should remove the MAC addresses associated with its port P 2  from the bridge&#39;s FDB  302 . 
     The ARP cache should also flushed. The reason is as follows. In a bridge, different ports have different MAC addresses. Therefore, in the ARP cache, the MAC addresses correspond to the ports of final destinations or intermediate bridges. If the topology changes, the path to the final destination or the intermediate bridge may also change, and may terminate at a different port of the final destination or the intermediate bridge. In such a case, the MAC address in the ARP cache should change. 
     An entry removal can be performed by reducing the entries&#39; aging time, e.g. from 300 seconds to 15 seconds in the FDB. 
     Topology changes should also be reflected in other bridges. For example, in bridge B 6 , the newly-activated port P 2  provides a new way to reach the segments L 6 , L 5 , and L 8 , which were previously reachable through port P 1 . Therefore, bridge B 6  should flush its FDB  302  and ARP cache  328 . Hence, when a bridge changes the state of any port to Forwarding, the bridge sends a topology change notification message (TCN) on this port and all the other active (Forwarding) ports. (In RSTP, a TCN can be sent as a BPDU with the TC flag set.) Each bridge receiving a TCN removes, from its FDB  302 , the entries associated with the addresses learned on all the other active non-Edge ports, and transmits TCNs on such ports. For example, when bridge B 1  receives a TCN on port P 2 , bridge B 1  removes the FDB entries for port P 1 , and propagates the TCN on port P 1 . Port P 3  is an Edge port, and is excepted from this process: the entries learned on this port are not removed, and no TCN is propagated on the port. See e.g. the topology change state machine in the aforementioned IEEE Standard 802.1D, section 17.31. 
     When any part of the FDB is flushed, the ARP cache is also flushed. 
     Some topology changes do not need FDB or ARP flushing however; see for example, the aforementioned U.S. Pat. No. 9,059,930. At least some TCNs can be omitted in such cases. 
     The inventors discovered additional cases when TCNs can be omitted. In particular, if a Designated port is becoming Forwarding on a point-to-point link, and the peer port is Alternate/Discarding or Backup/Discarding, then the paths to the root bridge and the paths between pre-existing links Lx do not change, and a TCN is unnecessary. For example,  FIG. 5  shows a point-to-point link Lx interconnecting the ports P 1  of bridges B 10  and B 11 .  FIG. 6  shows a pertinent part of the network configuration process. At step  604 , bridge B 10  makes its port P 1  Designated, and records the Designated role in corresponding data block  347  ( FIG. 3 ). Bridge B 11  makes its port P 1  Alternate, which is recorded in data block  347  of bridge B 11  and in peer data block  354  of bridge B 10 . At this time, both ports are Discarding, as recorded in the bridges&#39; blocks  346 . Then bridge B 10  exchanges BPDUs with bridge B 11  (e.g. Proposal/Agreement BPDUs in RSTP), and determines that its port P 1  can be made Forwarding. Bridge B 10  makes its port Forwarding (step  610  in  FIG. 6 ): the bridge updates the corresponding data  346  ( FIG. 3 ). Bridge B 10  also executes the TC process  612 , which is executed when a port becomes Forwarding. Specifically, at step  614 , the bridge performs one or more tests to determine whether TC processing is needed. The one or more tests include a test  614 A, which checks the port&#39;s data  352  and  354  to determine whether the attached link Lx is point-to-point, and the peer port (P 1  of bridge B 11 ) is Discarding and is Alternate or Backup. If test  614 A passes (as is the case in  FIG. 5 ), the bridge omits topology change (TC) processing, as schematically shown at  624 . In particular, the bridge does not change its FDB  302  or ARP cache  328 , and does not send any TCNs. 
     Test  614  may include other tests. For example, if the port is an Edge port, TC processing can be omitted (path  624  is followed). Other possible tests are described in the aforementioned U.S. Pat. No. 9,059,930, and still other tests are possible. 
     If test  614  fails, the appropriate TC policy is followed (step  618 ), e.g., as specified in IEEE Standard 802.1w. For example, bridge B 10  may flush its FDB  302  and ARP cache  328 , and may transmit TCNs on all the active, non-edge ports. 
     Step  630  schematically indicates the end of TC process performed in connection with a port becoming Forwarding. 
     Some TC processing examples will now be illustrated for the network of  FIG. 7  running RSTP. The network has six bridges B 1  through B 6 . Each bridge has four ports P 1  through P 4 . In all the examples, all links Lx are point-to-point. Bridge B 1  has been elected as the Root bridge. Its ports P 1  through P 4  are Designated/Forwarding, and are connected by respective links L 1  through L 4  to the following respective ports, all of which are Root/Forwarding: port B 3 /P 1 , i.e. bridge B 3 , port P 1 ; port B 4 /P 2 ; port B 5 /P 2 ; port B 6 /P 1 . 
     Link L 5  connects port B 2 /P 2  (Root/Forwarding) to port B 3 /P 3  (Designated/Forwarding). The remaining ports are disabled, as shown by dashes (-). Disabled ports are ports disabled by an administrator; they are treated as non-existent by xSTP, with no BPDUs transmitted on them, and incoming BPDUs being ignored. 
     Then ( FIG. 8 ) link L 6  is added to connect port B 2 /P 1  to port B 3 /P 2 . When the RSTP algorithm is executed by the bridges, the two ports are initially Designated/Discarding. Then port B 2 /P 1  becomes Alternate. 
     Bridge B 3  then initiates the RSTP “sync” process, sending a Proposal BPDU on port P 2  (with “Proposal” bit set), to propose moving the port P 2  to Forwarding. Bridge B 2  responds with the Agreement BPDU. 
     Bridge B 3  then makes P 2  Forwarding (step  610  in  FIG. 6 ), and executes the TC process  612 . In this process, the test of step  614 A is successful, so no topology change is detected (i.e. no TC processing is performed); see control path  624 . The network resource utilization is consequently improved. 
     As is clear from  FIGS. 7 and 8 , the addition of link L 6  does not change the network paths between the pre-existing links L 1  through L 5 , so FDB or ARP flushing is not needed. 
       FIG. 9  is similar to  FIG. 8 , illustrating the addition of link L 6  to the network of  FIG. 7 , but link L 6  of  FIG. 9  connects port B 2 /P 4  to port B 4 /P 3 . The network reconfiguration process is similar to the one of  FIG. 8 . In particular, the newly interconnected ports, B 2 /P 4  and B 4 /P 3  are initially disabled, then become Designated/Discarding, then port B 2 /P 4  become Alternate. Bridge B 4  initiates the Proposal/Agreement sequence, then makes its port P 3  Forwarding; this state is illustrated in  FIG. 9 . The test  614 A is successful, so the topology change is not detected (control path  624 ). 
     In some examples, if a link or a bridge goes down, the TCNs may be generated as in prior art. 
       FIGS. 10A, 10B  illustrate network reconfiguration when a new, non-root bridge is added. Before the bridge addition, the network is as in  FIG. 10A , with bridges B 1  (Root), B 2 , B 4 , B 5 , B 6 , and with links L 2  connecting D/F port B 1 /P 2  to RIF port B 4 /P 2 ; L 3  connecting D/F port B 1 /P 3  to R/F port B 5 /P 2 ; L 4  connecting D/F port B 1 /P 4  to R/F port B 6 /P 1 ; L 6  connecting R/F port B 2 /P 2  to D/F port B 4 /P 4 ; L 7  connecting A/D port B 2 /P 3  to D/F port B 5 /P 4 ; and L 8  connecting A/D port B 2 /P 4  to D/F port B 6 /P 4 . 
     Then ( FIG. 10B ), bridge B 3  is added. New link L 1  connects port B 1 /P 1  to port B 3 /P 1 ; and new link L 5  connects port B 2 /P 1  to port B 3 /P 3 . In this example, the RSTP configuration algorithm leaves bridge B 1  as the root bridge. Ports B 1 /P 1  and B 3 /P 1  are initially disabled ( FIG. 10A ), but become Designated/Discarding. Then bridge B 3  receives, on port P 1 , a superior BPDU from bridge B 1  (with the cost to the Root bridge being zero), and makes its port P 1  to be the Root port, moving the port to Forwarding (R/F) at step  610  ( FIG. 6 ). Bridge B 3  then executed the TO process  612 . The test of step  614 A fails. If test  614 A is the only test at step  614 , or there are other tests but test  614  nonetheless fails, then TC processing is performed at step  618 . 
     Bridge B 1  sends a Proposal BPDU on port P 1 , receives Acceptance BPDU, and moves the port P 1  to Forwarding state (step  610 ). Bridge B 1  then executes the TC process  612  for port P 1 . The test  614 A fails. If test  614 A is the only test at step  614 , or there are other tests but test  614  nonetheless fails, then TC processing is performed at step  618 . 
     On link L 5 , the two ports are initially D/D. Then port B 2 /P 1  becomes Alternate (A/D), and port B 3 /P 3  becomes Designated (D/D). Bridge B 3  sends a proposal BPDU on port P 3 , and receives an Acknowledgement BPDU from bridge B 2 . Bridge B 3  now moves its port P 3  to Forwarding (step  610 ), and executes the TC process  612 . The test  614 A is successful, so no TC is detected (path  624 ). 
       FIGS. 11A through 11E  illustrate a Root bridge addition. Before the bridge addition, the network is as in  FIG. 11A , with bridges B 2  (Root), B 3 , B 4 , B 5 , B 6 . The ports P 1  through P 4  of bridge B 2  are all Designated/Forwarding. Each link Lx (L 1  through L 4 ) connects the respective port B 2 /Px to the port P 4  of the respective bridge B 3 , B 4 , B 5 , B 6 . The ports P 4  of bridges B 3 , B 4 , B 5 , B 6  are Root/Forwarding, and the ports P 1  through P 3  of these bridges are disabled. 
     Then ( FIG. 11B ), bridge B 1  is added, with links L 5  through L 8  connecting the ports P 1  through P 4  of bridge B 1  to ports P 2  of the respective bridges B 3 , B 4 , B 5 , B 6 . The newly connected ports—ports B 1 /P 1  through B 1 /P 4  and the ports P 2  of bridges B 3 , B 4 , B 5 , and B 6 —are enabled, and become Designated/Discarding per the RSTP algorithm. The RSTP algorithm then determines, in this example, that bridge B 1  should be the Root bridge; see  FIG. 110 . Accordingly, in bridges B 3  through B 6 , the ports P 2  become Root/Forwarding, and the ports P 4  become Designated/Discarding. The ports of bridge B 2  also become Designated/Discarding. When a bridge B 3 , B 4 , B 5 , or B 6  makes its port P 2  Forwarding, the bridge executes the process  612  ( FIG. 6 ). In this process, the test  614 A fails. If test  614 A is the only test at step  614 , or there are other tests but test  614  nonetheless fails, then TC processing is performed at step  618 . 
     Bridge B 1  initiates the sync process on its ports, sending the Proposal BPDU to bridges B 3  through B 6 . Bridges B 3  through B 6  respond with the Acceptance BPDUs, and send Proposal BPDUs on their ports P 4  to bridge B 2  to initiate the sync process on links L 1  through L 4 . When Root bridge B 1  receives the Acceptances, bridge B 1  makes its ports P 1  through P 4  Forwarding (D/F), as shown in  FIG. 11D , and executes the TC process  612  for each port. Test  614 A fails. If test  614 A is the only test at step  614 , or there are other tests but test  614  nonetheless fails, then TC processing is performed at step  618 . 
     Bridge B 2  makes its port P 1  to be the Root port, as having the best path to the Root bridge B 1 , and sets the port&#39;s state to Forwarding and executes process  612 . Test  614 A fails. If test  614 A is the only test at step  614 , or there are other tests but test  614  nonetheless fails, then TO processing is performed at step  618 . 
     Bridge B 2  makes the ports P 2 , P 3 , P 4  Alternate/Discarding. Bridge B 2  sends Acceptance BPDUs on its ports P 1  through P 4  in response to the Proposals received from bridges B 3 , B 4 , B 5 , B 6 . Upon receiving the Acceptances, the bridges B 3 , B 4 , B 5 , B 6  make their ports P 4  Forwarding—see  FIG. 11E —and perform the TC process  612  for each of these ports. Test  614 A is successful at bridges B 4 , B 5 , B 6 , so the TC processing is omitted (path  624 ). Test  614 A fails at bridge B 3 . If test  614 A is the only test at step  614 , or there are other tests but test  614  nonetheless fails, then TC processing is performed at step  618 . 
     The invention is not limited to the embodiments discussed above. Some embodiments are defined by the following clauses; the parentheticals provide examples that do not limit the clauses. 
     Clause 1 defines a method for operating a first bridge in a computer network comprising a plurality of bridges including the first bridge, each bridge including a plurality of ports, the computer network comprising a plurality of network segments (e.g. Lx) each of which is attached to one or more of the ports, the method comprising: 
     executing, by the first bridge, a spanning tree protocol (e.g. RSTP) to configure ports of the first bridge; and 
     forwarding data by the first bridge based on the ports configuration of the first bridge and based on one or more forwarding databases (e.g. FDB, ARP cache); 
     wherein executing the spanning tree protocol comprises changing (e.g. at step  610 ), by the first bridge, a state of at least one port of the first bridge from a first state (e.g. Discarding or Learning) to a second state (e.g. Forwarding), wherein in the second state the bridge uses the port to forward data, but in the first state the bridge does not use the port to forward data; 
     wherein for each changing operation the method comprises, for the port (“first port”) whose state is changed in the changing operation determining (e.g. at  614 ), by the first bridge, whether a topology change (TC) processing is to be performed which comprises at least one of: (1) removing at least one entry for at least one port of the first bridge from one or more of the forwarding databases; (2) sending a TC notification (TCN) to one or more of the bridges; 
     wherein determining whether the TC processing is to be performed comprises determining whether a first condition is true ( 614 A), wherein the first condition requires that all of conditions (a), (b), and (c) be true, wherein: 
     condition (a) is that the first port is attached to a point-to-point link (disabled ports are ignored when determining whether the link is point-to-point); 
     condition (b) is that the first port is a Designated port for the point-to-point link (i.e. the first port is to be used for all data forwarding between the link and the Root bridge); and 
     condition (c) is that a peer port of the first port is an Alternate or Backup port and is in a state (e.g. Discarding) that cannot be used to forward data; 
     whenever the first condition is true, omitting the TC processing (e.g. at  624 ); 
     for at least one instance when the first condition is not true, performing the TC processing (e.g. at  618 ). 
     2. The method of clause 1, wherein the first condition requires the peer port to be an Alternate port. 
     3. The method of clause 1 or 2, wherein the first condition requires the peer port to be a port of a bridge other than the first bridge. 
     4. The method of any preceding clause, wherein the first bridge maintains, for each enabled port having a peer port, a state and role of each peer port, the state and role being recorded in a memory of the first bridge. 
     5. The method of any preceding clause, wherein the TC processing comprises sending a TCN on the first port. 
     6. The method of any preceding clause, wherein the spanning tree protocol is the Rapid Spanning Tree Protocol. 
     The invention includes bridges configured to perform the methods discussed above. For example, the bridge may be software-programmed to perform such methods. The invention also includes computer readable media comprising computer instructions which, if executed by the bridge, will cause the bridge to perform the methods discussed above. 
     Although illustrative embodiments have been shown and described, a wide range of modification, change and substitution is contemplated in the foregoing disclosure and in some instances, some features of the embodiments may be employed without a corresponding use of other features. The features described above can be implemented in one or more Virtual Local Area Networks (VLANs) defined in the computer network, with each VLAN executing xSTP independently of other VLANs, while some other VLANs may be operated without using xSTP. A link Lx may be implemented using a tunnel through a non-LAN network, e.g. the Internet. Other embodiments and variations are within the scope of the invention, as defined by the appended claims.