1. Technical Field of the Invention
The present invention generally relates to Multiple Spanning Tree (“MST”) protocol. More particularly, and not by way of any limitation, the present invention is directed to system and method for implementing automatic IEEE 802.1Q trunk formation in connection with MST protocol.
2. Description of Related Art
MST protocol (“MSTP”), as defined by IEEE 801.1s, combines the best aspects of both Rapid Spanning Tree Protocol (“RSTP”) and virtual local area network (“VLAN”) technology. In MSTP, several VLANs can be mapped to a single spanning tree instance, referred to as an MST instance (“MSTI”), and each spanning tree instance is independent of other spanning tree instances. Each MSTI is identified by an MSTI number, which is locally significant within a region; MSTIs do not span across MST regions. This approach provides multiple forwarding paths for data traffic, enabling load-balancing, and reduces the number of spanning tree instances required to support a large number of VLANs.
In MST protocol (“MSTP”), as defined in IEEE 802.1S, a problem exists in that the actual VLAN topology created by IEEE 802.1Q tagging is not taken into consideration when the active (forwarding) topology of the spanning tree is determined. Thus, in manual configurations of VLANS, where the logical VLAN topology differs from the active spanning tree topology, connectivity can be lost for those VLANS where the VLANs possible connecting routes between switches are all blocked on the spanning tree.
This possible connectivity loss can be demonstrated using an example of two redundant links between two bridges in the same MST region. A VLAN may be assigned to only one of the links, whereas the MSTI to which it belongs may have designated that link to be “blocking,” rather than “forwarding” for the MSTI. As a result, connectivity for that VLAN, and possibly additional VLANs, is lost, even though a valid physical link exists. To configure the network correctly, the VLAN should be assigned to both links, so that despite the fact that one of the links is blocking, the VLAN still has a forwarding link. This simple example can be expanded upon with many VLANs and much more complicated physical topologies, but the root problem is still evident, and indeed the need for a simple and complete solution is made more apparent.
One way to partially obviate the problem is to let use Generic Attribute Registration Protocol (“GARP”) VLAN Registration Protocol (“GVRP”) to determine the VLAN topology, as GVRP uses only the forwarding path of the spanning tree to define the VLAN topology. Although GVRP can avert the problem if properly applied, it is not by any means a complete solution. In particular, GVRP suffers from deficiencies in terms of scaling, security, and resource allocation, to name a few. GVRP can be configured by management to also not provide sufficient protection from the problem of concern. GVRP presents an additional problem in that dynamic VLAN “learns” can result in reconvergence of the network
Another partial solution is to use a system in which “infinite” path costs are assigned to given ports automatically for a specific spanning tree instance when not all of the VLANs that are mapped to the spanning instance are assigned to a port. In this manner, only links that have all of the VLANs assigned to them are favored by spanning tree when determining topology. This is done automatically with a specific algorithm. This solution also gives rise to additional problems. In particular, whenever VLAN topology changes, a path cost may change, which will in turn create a spanning tree topology change, which is undesirable. Moreover, this solution provides no protection against erroneous configurations, as many scenarios result in no port being favored. Additionally, configuration can be difficult in many scenarios in which an attempt is made to employ this solution.
Yet another partial solution is to filter MST instance (“MSTI”) information in the MSTP bridge protocol data units (“BPDUs”) based on whether the VLANs mapped to a particular MSTI exist on a specific port. This works because the MSTIs will converge only to be forwarding on good ports that have related VLANs; however, this solution is not compliant with the IEEE standard. There also exists the possibility of configuring a port as a trunk port, thus allowing all VLANs manually created in the system to be configured on the port. This solution is deficient in that it is not based exclusively on MSTP.
Therefore, what is needed is a system and method for implementing automatic trunk formation (“ATF”), or automatic trunking, in MSTP in a manner that is compliant with IEEE 802.1Q.
USPTO Backgrounds
USPTO Backgrounds