Layer two (L2) devices of the Open Systems Interconnection (OSI) reference model are known as “bridges” or “switches” and are controlled by proprietary, standardized L2 (IEEE) and L3 (IETF) protocols. Multiple Spanning Tree Protocol (MSTP) is intended to provide full connectivity while preventing any undesirable loop for frames assigned to any given VLAN throughout a Bridged Local Area Network (LAN). Such a LAN includes arbitrarily interconnected Bridges, each operating a respective type or respective types of Spanning Tree Protocol. Examples of such types of spanning tree protocols include, but are not necessarily limited to, Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP) and Multiple Spanning Tree Protocol (MSTP). STP is a legacy protocol in accordance with the IEEE 802.1D 1998 standard. RSTP is in accordance with IEEE 802.1D 2004 standard. MSTP is in accordance with the IEEE 802.1Q 2005 standard.
Avoiding a loop is one of the most, if not the most, important tasks of a spanning tree protocol. Loop refers to a type of network issue in which data packets continue to be routed in an endless circle among Bridges rather than reaching their intended destinations. When a loop occurs, communication of information via an affected Bridge or Bridges quickly becomes very confusing and demanding of processing resources (e.g., central processing unit resources). MSTP is a Virtual Local Area Network (VLAN) aware implementation of spanning tree protocol, thus allowing frames assigned to different VLANs to follow separate paths. Each path is based on an independent Multiple Spanning Tree Instance (MSTI), within Multiple Spanning Tree (MST) regions composed of LANs and/or MST Bridges. These regions and constituent Bridges and/or LANs are connected into a single Common Spanning Tree (CST). The term “instance” refers to a physical tree without loop for a set of VLANs handled by a set of MSTP state machines. The user can define several MSTIs and can map any VLANs to any MSTI. An Internal Spanning Tree (IST) instance runs inside a MSTP region to define the topology for all VLANs mapped to that common instance. This is what extends the CST but inside a region as opposed to outside of the region. The IST instance is always present in regions of a topology. MSTI may also run inside a region but never extends beyond it. A CST instance is the unique and mandatory instance that connects all 802.1 regions and all the Bridges that do not run 802.1 (i.e., those that run a flat version of STP such as, for example, 802.1D-2004). In fact, the CST instance treats each region as a virtual Bridge. Accordingly, for all practical purposes, the combination of IST and CST yields CIST (i.e., the combined functionality IST and CST).
Spanning tree computation (i.e., roll and state computations) enables each port of a Bridge in a network to be assigned a role (e.g., Root, Master Designated, Alternate, Backup or Disabled) and a state (e.g., Learning, Forwarding, or Discarding). The role and state are assigned in accordance with the state machines described in the MSTP standard (i.e., IEEE 802.1Q 2005 standard). MSTP dictates that “ . . . on a boundary port, the Multiple Spanning tree instances roles must follow the Common and Internal Spanning Tree (CIST) role . . . ”. CIST and its associated role is defined in the 802.1Q 2005 paragraph 13.13 (Stable Connectivity) as, at a boundary port, frames allocated to the CIST and all MSTIs which are forwarded alike or not forwarded alike. This is because boundary port information assignments are such that if the CIST port information is Root Port the MSTI port information will be Master Port, and if the CIST port information is Designated Port, Alternate Port, Backup Port, or Disabled Port, each MSTI's port information will be the same. Port information is defined herein to include port role information (e.g., a port role) and port state information (e.g., a current state).
A problem discovered in the latest standard 802.1Q 2005 is the following: when some information changes on a boundary port causing a previously Alternate state becoming Root Forwarding, the reciprocal change for MSTI which is Alternate to Master Forwarding does not happen at the same moment as for the CIST. The reason is that the MSTI must wait until a Proposal/Agreement handshake takes place in the Designated Discarding port. In other words, CIST and MSTI states on boundary port can be slightly desynchonized on purpose, to allow taking care of a known 802.1Q 2003 problem of a transient loop on MSTIs. Therefore, while a new CIST Root port may already Forwarding and proceed to a Topology Change (TC) conforming to the states machines, a new Master port may still be discarding and according to the latest disposition document, will wait until the CIST Proposal/Agreement sequence takes place on the formerly CIST Root port, because it is Designated Discarding. Therefore, it should still be necessary for the Bridge to proceed to a new Topology Change as soon as the MSTI Master port becomes Forwarding because the newest CIST Root port and MSTI Master Port are not becoming Forwarding at the same time anymore.
If the Bridge does not proceed to Topology Change right away when the MSTI Master port becomes Forwarding, lack of connection for such MSTI traffic may arise in the Bridge network because no flushing happens at the time a new Master port is forwarding for such MSTI. Therefore, the old information for bridging the traffic remains and may correspond to a path that is not usable anymore. Worst case is a lack of connection for 2 seconds, which is the time needed to send a hello Bridge Protocol Data Unit (BPDU) transporting the TC.
While a situation of a transient loop seems to be addressed in the 802.1Q 2005 standard, the documented solution results in a corresponding situation that is undesirable. More specifically, the flushing of the Source Learning tables used to Bridge the traffic does not occur when the MSTI master port becomes Forwarding. This is because there is currently a test in the Port Transmit state machine that prevents a Master port from sending any BPDU. Undesirably, the action to flush the Source Learning tables used to Bridge the traffic occurs about two seconds later or, worst case, when a corresponding hello BPDU is sent. Therefore, facilitating Topology Change functionality in a manner that overcomes shortcomings associated with conventional approaches for facilitating Topology change when Regional Root information changes would be advantageous, desirable and useful.
USPTO Backgrounds
USPTO Backgrounds