Source: http://www.google.ca/patents/US20040081171
Timestamp: 2018-01-19 04:05:44
Document Index: 784693639

Matched Legal Cases: ['art 104', 'art 106', 'art 104', 'art 106', 'art 106', 'art 1218', 'arts 1218', 'arts 1218']

Patent US20040081171 - Large-scale layer 2 metropolitan area network - Google Patents
A system and method permits the creation of very-large metropolitan area networks (MANs) using Layer 2 (L2) switching technology. Different groups of L2 switches are logically organized into Islands. Connected to each Island are a plurality of customers sites, and an interconnect fabric couples the Islands...http://www.google.ca/patents/US20040081171?utm_source=gb-gplus-sharePatent US20040081171 - Large-scale layer 2 metropolitan area network
Publication number US20040081171 A1
Application number US 10/279,360
Priority date 24 Oct 2002
Also published as CA2502308A1, CA2502308C, CN1820463A, CN1820463B, DE60321809D1, EP1557006A2, EP1557006B1, US7292581, WO2004039015A2, WO2004039015A3
Publication number 10279360, 279360, US 2004/0081171 A1, US 2004/081171 A1, US 20040081171 A1, US 20040081171A1, US 2004081171 A1, US 2004081171A1, US-A1-20040081171, US-A1-2004081171, US2004/0081171A1, US2004/081171A1, US20040081171 A1, US20040081171A1, US2004081171 A1, US2004081171A1
Inventors Norman Finn
Original Assignee Finn Norman W.
Patent Citations (10), Referenced by (167), Classifications (9), Legal Events (3)
Large-scale layer 2 metropolitan area network
US 20040081171 A1
A system and method permits the creation of very-large metropolitan area networks (MANs) using Layer 2 (L2) switching technology. Different groups of L2 switches are logically organized into Islands. Connected to each Island are a plurality of customers sites, and an interconnect fabric couples the Islands together. The Islands cooperate to provide a Virtual Ethernet Connection (VEC) to each set of customer sites being coupled together. Customers identify their traffic that corresponds to a VEC by labeling or tagging it with a Customer-Equipment VLAN Identifier (CE-VLAN ID). Within each Island, the CE-VLAN ID specified by the customer's traffic (and hence the corresponding VEC) is mapped to a unique MAN Provider-Equipment VLAN ID (PE-VLAN ID). To prevent the formation of loops, the Islands run the Inter-MAN Control Protocol (IMCP), which represents a modified version of the Multiple Spanning Tree Protocol (MSTP).
1. A method of preventing Layer 2 (L2) loops in a Metropolitan Area Network (MAN) having a plurality of intermediate network devices, and providing a plurality of Virtual Ethernet Connections (VECs), each representing a virtual shared medium, the method comprising the steps of:
organizing the plurality of intermediate network devices into two or more administrative groups, each containing one or more intermediate network devices;
using an Interconnect Fabric to couple the two or more administrative groups by providing redundant links between each administrative group and the Interconnect Fabric; and
for each VEC provided by an administrative group, blocking all but one of the redundant links to the Interconnect Fabric.
defining one or more logical Trunks within the Interconnect Fabric, each logical Trunk representing a shared medium connecting two or more administrative groups;
assigning each VEC to no more than one logical Trunk;
within each administrative group, defining a plurality of Provider Equipment Virtual Local Area Network (VLAN) Identifiers (IDs); and
within each administrative group, associating a given VEC with exactly one PE-VLAN ID.
3. The method of claim 2 wherein the PE-VLAN IDs defined within two administrative groups and associated with the same VEC are dissimilar.
4. The method of claim 1 wherein the step of blocking comprises the steps of:
providing a separate VEC for configuration bridge protocol data unit (BPDU) messages generated by the intermediate network devices of the administrative groups of the MAN; and
assigning a Multiple Spanning Tree (MST) Configuration Identifier (ID) to each intermediate network device of the MAN, the MST Configuration ID specifying an Island name.
receiving from a logical Trunk one or more BPDU messages associated with the VEC at a given intermediate network device of an administrative group, each received BPDU message specifying an MST Configuration ID and a first root; and
using the received BPDU message in computing a spanning tree instance in accordance with the Multiple Spanning Tree Protocol (MSTP), provided that the MST Configuration ID of the received BPDU matches the MST Configuration ID assigned to the given intermediate network device.
the MST Configuration IDs further specify a Configuration name, a Revision level and a Configuration digest, and
two MST Configuration IDs match where the specified Island names, Configuration names, Revision levels and Configuration digests all match.
storing a root ID at the given intermediate network device; and
discarding the received BPDU, if the Island name of the received BPDU's MST Configuration ID Island ID does not match the Island name of the MST Configuration ID assigned to the given intermediate network device, and the received BPDU's first root does not match the root ID stored by the given intermediate network device.
the step of blocking further comprises the steps of using the received BPDU in computing a spanning tree instance in accordance with the Rapid Spanning Tree Protocol (MSTP) specification standard, if the Island name of the received BPDU matches the Island name of the given intermediate network device, but one or more of the Configuration name, Revision level and Configuration digest of the received BPDU does not match the respective one of the Configuration name, Revision level and Configuration digest assigned to the given intermediate network device.
each administrative group of the MAN is identified as a corresponding Island, and
a plurality of customer networks are coupled to each Island.
10. The method of claim 9 wherein the customer networks send configuration bridge protocol data unit (BPDU) messages into their respective Islands, the method further comprising the step of returning BPDU messages generated in the customer networks back to the customer networks unmodified.
11. The method of claim 1 wherein the step of blocking comprises the steps of:
configuring a logical Trunk so that each intermediate network device can communicate configuration bridge protocol data unit (BPDU) messages over the logical Trunk only with intermediate network devices that belong to the same administrative group; and
using the received BPDU messages in computing a spanning tree instance in accordance with the Multiple Spanning Tree Protocol (MSTP).
12. An intermediate network device for use in forwarding network messages within a computer network, the intermediate network device comprising:
means for associating the intermediate network device with an Island name, a Configuration name, a Revision level and a Configuration digest;
means for issuing configuration bridge protocol data unit (BPDU) messages with the Island name, Configuration name, Revision level and Configuration digest associated with the intermediate network device; and
means for utilizing one or more received BPDU messages in computing a spanning tree instance provided that each of the Island name, Configuration name, Revision level and Configuration digest of the one or more received BPDU matches the respective Configuration name, Revision level and Configuration digest associated with the intermediate network device.
13. The intermediate network device of claim 12 further comprising means for preventing one or more received BPDU messages from being used in computing a spanning tree instance where the Island name of the received BPDU does not match the Island name associated with the intermediate network device.
Many organizations, including businesses, governments and educational institutions, utilize computer networks so that employees and others may share and exchange information and/or resources. A computer network typically comprises a plurality of entities interconnected by means of one or more communications media. An entity may consist of any device, such as a computer, that “sources” (i.e., transmits) or “sinks” (i.e., receives) data frames over the communications media. A common type of computer network is a local area network (“LAN”) which typically refers to a privately owned network within a single building or campus. LANs typically employ a data communication protocol (LAN standard), such as Ethernet, FDDI or token ring, that defines the functions performed by data link and physical layers of a communications architecture (i.e., a protocol stack).
One or more intermediate network devices are often used to couple LANs together and allow the corresponding entities to exchange information. For example, a bridge may be used to provide a “switching” function between two or more LANs or end stations. Typically, the bridge is a computer and includes a plurality of ports that are coupled via LANs either to other bridges, or to end stations such as routers or host computers. Ports used to couple bridges to each other are generally referred to as a trunk ports, whereas ports used to couple bridges to end stations are generally referred to as access ports. The bridging function includes receiving data from a sending entity at a source port and transferring that data to at least one destination port for forwarding to one or more receiving entities.
Ethernet is one of the most common LAN standards used today. The original Ethernet transmission standard, referred to as 10 Base-T, is capable of transmitting data at 10 Megabits per second (Mbs). In 1995, the Institute of Electrical and Electronics Engineers (IEEE) approved a Fast Ethernet transmission standard, referred to as 100 Base-T, which is capable of operating at 100 Mbs. Both 10 Base-T and 100 Base-T, however, are limited to cable lengths that are less than 100 meters. A committee of the IEEE, known as the 802.3z committee, is currently working on Gigabit Ethernet, also referred to as 1000 Base-X (fiber channel) and 1000 Base-T (long haul copper), for transmitting data at 1000 Mbs. In addition to the substantially increased transmission rate, Gigabit Ethernet also supports cable lengths of up to 3000 meters. Gigabit Ethernet thus represents a potentially significant increase in the size or range of Ethernet LANS.
Recently, the IEEE promulgated a new standard (the IEEE Std. 802.1W-2001™ specification standard) that defines a Rapid Spanning Tree Protocol (RSTP). The RSTP similarly selects one bridge of a bridged network to be the Root Bridge and defines an active topology that provides complete connectivity among the LANs while severing any loops. Each individual port of each bridge is assigned a port role according to whether the port is to be part of the active topology. The port roles defined by the 802.1w specification standard include Root, Designated, Alternate and Backup. The bridge port offering the best, e.g., lowest cost, path to the Root Port is assigned the Root Port Role. Each bridge port offering an alternative, e.g., higher cost, path to the Root Bridge is assigned the Alternate Port Role. For each LAN, the one port providing the lowest cost path to the Root Bridge from that LAN is assigned the Designated Port Role, while all other ports coupled to the LAN are assigned the Root, Backup or, in some cases, the Alternate Port Role. At the Root Bridge, all ports are assigned the Designated Port Role.
In addition to the '402 Patent, the IEEE promulgated the 802.1Q specification standard for Virtual Bridged Local Area Networks. To preserve VLAN associations of messages transported across trunks or links in VLAN-aware networks, both Ross and the IEEE Std. 802.1Q-1998 specification standard disclose appending a VLAN identifier (VID) field to the corresponding frames. In addition, U.S. Pat. No. 5,742,604 to Edsall et al. (the “'604 patent”), which is commonly owned with the present application, discloses an Interswitch Link (ISL) encapsulation mechanism for efficiently transporting packets or frames, including VLAN-modified frames, between switches while maintaining the VLAN association of the frames. In particular, an ISL link, which may utilize the Fast Ethernet standard, connects ISL interface circuitry disposed at each switch. The transmitting ISL circuitry encapsulates the frame being transported within an ISL header and ISL error detection information, while the ISL receiving circuitry strips off this information and recovers the original frame.
[0023]FIG. 1 is a highly schematic block diagram of an MST BPDU 100. The MST BPDU 100 includes a header 102 compatible with the Media Access Control (MAC) layer of the respective LAN standard, e.g., Ethernet. The header 102 comprises a destination address (DA) field, a source address (SA) field, a Destination Service Access Point (DSAP) field, and a Source Service Access Point (SSAP), among others. The DA field 104 carries a unique bridge multicast destination address assigned to the spanning tree protocol, and the DSAP and SSAP fields carry standardized identifiers assigned to the spanning tree protocol. Appended to header 102 is a BPDU message area that includes an “outer” part 104 and an “inner” part 106. The outer part 104 has the same format as an RSTP BPDU message and is recognized as a valid RSTP BPDU message by bridges that do not implement MSTP. The “inner” part 106 is utilized by bridges executing MSTP to establish the IST and the MSTIs. The inner part 106 has a set of spanning tree parameters for the IST and a set of parameters for each MSTI supported by the bridge sourcing the MSTP BPDU 100.
As mentioned above, the MST configuration ID field 138 is made up of three sub-fields: a configuration name sub-field 154, a revision level sub-field 156 and an MD-5 checksum sub-field 158. The configuration name sub-field 154 carries a variable length text string encoded within a fixed size, e.g., 32-octets. The revision level sub-field 156 carries an integer encoded within a fixed field of two octets. The MD-5 checksum sub-field 158 carries a 16-octet signature created by applying the MD-5 algorithm to the bridge's VLAN to MSTI table, which contains 4096 consecutive two octet elements.
Briefly, the invention is directed to a system and method for building very-large metropolitan area networks (MANS) using Layer 2 (L2) switching technology. In the illustrative embodiment, different groups of L2 switches are logically organized into Islands. Each Island, moreover, is configured as a separate administrative domain. Connected to each Island are a plurality of customers sites, which are typically local area networks (LANs). An interconnect fabric is utilized to couple the Islands together so that a customer site connected to a first Island can communicate with a customer site connected either to the same or a second Island. In the illustrative embodiment, the interconnect fabric is formed from a plurality of Layer 3 (L3) devices configured to provide an Emulated VLAN over Multiple Label Switching Protocol (EVoMPLS) service, where EVoMPLS is the analogy, over MPLS, of ATM LAN Emulation (ATM Forum standard af-lane-0021.000). Alternatively, the interconnect fabric may be formed of an Ethernet LAN using 802.1Q or similar tags. The Islands cooperate to provide a Virtual Ethernet Connection (VEC) to each set of customer sites being coupled together. Customers identify their traffic that corresponds to a VEC by labeling or tagging it with a Customer-Equipment VLAN Identifier (CE-VLAN ID). Within each Island, the CE-VLAN ID specified by the customer's traffic (and hence the corresponding VEC) is mapped to a unique MAN Provider-Equipment VLAN ID (PE-VLAN ID). The PE-VLAN ID selected for a given VEC in one Island may differ from the PE-VLAN ID selected for the given VEC but used in another Island. For each VEC that traverses the interconnect fabric, an Inter-Island Trunk is established to carry VEC traffic between the two Islands. The Inter-Island Trunk is a logical construct that functions, at least from the point of view of the Islands, as a shared medium. Specifically, the Islands joined by an Inter-Island Trunk are configured to append the same Virtual Circuit Identifier (ID), preferably as an MPLS label, to network messages being placed on the Inter-Island Trunk. Network messages received at an Island from the Inter-Island have their Virtual Circuit ID label and any other labels stripped off before being transmitted to the respective customer site.
The concatenated MAN consisting of Islands and interconnect fabric may be expected to be too large for any of the standard Spanning Tree Protocols to serve satisfactorily to prevent the formation of loops. To prevent the formation of loops within the MAN, the Islands are configured to prevent two or more VECs from sharing the same Inter-Island Trunk. The Islands also run a new protocol, the Inter-MAN Control Protocol (IMCP), which represents a modified version of the Multiple Spanning Tree Protocol (MSTP). Specifically, the L2 devices disposed in each Island are configured with a new Multiple Spanning Tree (MST) Configuration ID that includes an Island name in addition to the configuration name, revision level and checksum. Furthermore, the L2 devices disposed in the same Island are all given the same Island ID, configuration name and revision level. Each Island thus identifies itself as a separate MSTP Region. Second, the L2 devices within each Island also ensure that, for each VEC that crosses the interconnect fabric, all but one of the redundant links connecting the Island to the interconnect fabric are blocked. As a result, loops that might otherwise result from the presence of redundant links between the customer sites and the Islands are severed, regardless of the version of the STP being run in the customer sites. For different VECs, however, the links that are blocked may vary, thereby providing a level of load-sharing between the links extending between the Islands and the interconnect fabric.
The IMCP also imposes several new rules. In particular, BPDUs received within an Island whose entire MST Configuration ID matches that of the receiving L2 device are treated as normal, matching BPDUs. Received BPDUs whose Island name matches the Island name of the receiving L2 device, but whose configuration name, revision level and/or configuration digest does not match are treated as Rapid Spanning Tree Protocol (RSTP) BPDUs. This rule allows bridges in the same Island to operate in the same manner as for 802.1S, and maintain connectivity during the reconfiguration of the bridges. Received BPDUs whose Island name does not match the Island name of the L2 device receiving the BPDUs and whose specified Root ID does not match that of the receiving L2 device are ignored, if received from the Inter-Island Trunk. This rule effectively decouples the Islands' Spanning Trees from each other. If received on a bridge port other than an Inter-Island Trunk, the receipt of a BPDU whose Island name does not match the Island name of the L2 device receiving the BPDU causes the receiving bridge to block the respective port for all VLANs and issue an operator alarm. This rule prevents inadvertent connections among Islands other than on an Inter-Island Trunk. In the preferred embodiment, the L2 devices also respond to receiving BPDUs whose Island name does not match the Island name of the L2 device receiving the BPDUs but whose specified Root ID does match that of the receiving L2 device by blocking the respective port for all VLANs and issue an operator alarm. This rule allows an Island to detect inadvertent connections among Islands which are not otherwise detected.
[0035]FIG. 1, previously discussed, is a schematic block diagram of a conventional configuration bridge protocol data unit in accordance with the Multiple Spanning Tree Protocol;
[0036]FIG. 2 is a highly schematic illustration of a large Metropolitan Area Network (MAN);
[0037]FIG. 3 is a highly schematic illustration of an Island of the MAN of FIG. 2;
[0038]FIG. 4 is a partial, functional diagram of a Layer 2 (L2) device of the Island of FIG. 3;
[0039]FIG. 5 is a highly schematic illustration of a Configuration Identifier (ID);
[0040]FIG. 6 is a highly schematic illustration of a VLAN Mapping Table;
[0041]FIG. 7 is a highly schematic illustration of an Inter-Island Trunk Mapping Table;
[0042]FIG. 8 is a highly schematic illustration of a labeled network message format;
FIGS. 9-11 are highly schematic partial illustrations of the MAN of FIG. 2; and
[0044]FIGS. 12 and 13 are highly schematic illustrations of another MAN in accordance with the present invention.
[0045]FIG. 2 is a highly schematic illustration of a very large layer 2 (L2) Metropolitan Area Network (MAN) 200 in accordance with the present invention. As used herein, the term “very large MAN” refers to a MAN capable of covering an entire metropolitan area, such as the San Francisco Bay area, Silicon Valley, etc. The MAN 200 includes a plurality of Islands, such as Islands 202, 204 and 206. As described herein, each Island comprises one or more interconnected Layer 2 (L2) intermediate network devices, such as bridges or switches. Typically, each Island is operated by the same MAN Provider, and represents a separate administrative domain. The MAN 200 is organized into different Islands to increase the total number of VLAN designations beyond 4096 that may be supported by the MAN 200. Some or all of the individual Islands, moreover, may be assigned to different administrators.
The Islands are coupled together by an Island Interconnect Fabric 208. Preferably, each Island is coupled to the Island Interconnect Fabric 208 by multiple links, such as Inter-Island links 210 a-f. Also, attached to each Island are one or more customer sites, such as personal customers, sites 212-217. In the illustrative embodiment, each customer site comprises a plurality of entities or hosts, such as personal computers, workstations, servers, etc., which are all in the same physical location, and are interconnected to form one or more Local Area Networks (LANs) so that the entities may source or sink data frames to one another. As used herein, the term “same physical location” refers to a single building or a plurality of buildings on a single campus or within the area of roughly a single city block. The LANs at the customer sites may be interconnected by one or more customer operated L2 intermediate network devices such as bridges, switches or routers.
Customer sites 212-217 will typically belong to different organizations, such as organization A and organization B. In particular, organization A includes customer sites 212 (A1), 213 (A2), 216 (A3) and 217 (A4). Organization B includes customer sites 214 (B1), and 215 (B2). Each customer site 212-217 is preferably coupled to at least one Island by a plurality of site links 220-231. As described herein, a customer obtains various services from the MAN 200, such as interconnecting its sites that are geographically remote from each other. In this way, entities located at one customer site can communicate with the entities of another site.
[0049]FIG. 3 is a highly schematic illustration of Island 202. Island 202 includes a plurality of L2 intermediate network devices, such as switches (S) 302, 304 and 306. Each switch 302, 304 and 306 includes a plurality of ports (P) 402 at least some of which are utilized to connect the switches to the customer sites. Other switch ports 402 are coupled to intra-Island links 308-310 extending between the switches 302, 304 and 306. Links 308-310 may be point-to-point links or shared media links that carry network messages, such as frames, among the switches. Each switch 302-306, moreover, preferably identifies its own ports 402, e.g., by port numbers, such as port zero (P0), port one (P1), port two (P2), port three (P3), etc. Switches 302-306 are thus able to associate specific ports with the customer sites and/or other switches coupled thereto.
[0052]FIG. 4 is a partial block diagram of MAN Provider switch, such as switch 302. Switch 302 includes a plurality of ports 402 a-402 e each of which is preferably identified by a number (e.g., P0-P4). One or more frame transmission and reception objects, designated generally 404, are associated with the ports 402 a-d such that network messages, including frames, received at a given port, e.g., P3, may be captured, and frames to be transmitted by switch 302 may be delivered to the appropriate port, e.g., P1, for transmission. Frame reception and transmission objects 404 are preferably message storage structures, such as priority queues. In the illustrated embodiment, switch 302 includes transmitting and receiving circuitry, including one or more line cards and/or network interface cards (NICs) establishing ports for the exchange of network messages, one or more supervisor cards having central processing units (CPUs) and/or microprocessors and associated memory devices for performing computations and storing the results therefrom and one or more bus structures.
Switch 302 has a plurality of protocol entities, including at least one Multiple Spanning Tree Protocol (MSTP) entity 408, at least one forwarding engine 410, and a Virtual Ethernet Channel (VEC) entity 412. The MSTP entity 408 preferably comprises a plurality of subcomponents, including a port role selection state machine 414, a port transition state machine 416, a bridge protocol data unit (BPDU) message generator 418, an Island Boundary Determination engine 420, and an MSTP Digest Generator 422. Island Boundary Determination engine 420 preferably includes one or more comparators, such as comparator 423. The MSTP entity 408 preferably operates in accordance with the IEEE 802.1s Multiple Spanning Tree Protocol (MSTP) draft supplement to the 802.1Q specification standard, the current draft (IEEE Draft P802.1s/D13™—Jun. 13, 2002) of which is hereby incorporated by reference in its entirety, as modified by the Inter-MAN Control Protocol (IMCP) described herein. The MSTP entity 408 includes or is in communicating relationship with a memory device or structure, such as STP memory 424, which may be a volatile or non-volatile random access memory (RAM) or some other memory device. Memory 424 is preferably organized to include a plurality of records or cells (not shown) for storing spanning tree related information or parameters such as the switch's Configuration ID, numeric bridge identifier (ID), the assigned path cost for each port 402 a-e for each MSTI, the current or “best” spanning tree information for each port P0-P4 for each MSTI, etc. In addition to memory 424, the STP entity 408 further includes a VLAN ID (VID) to Multiple Spanning Tree Instance (MSTI) translation table 426 configured to store the mappings of VLANs to MSTIs.
The Inter-Island Trunk Mapping engine 432 has an Inter-Island Trunk Mapping table 700 that maps PE-VLAN IDs to VEC Identifiers (IDs). VEC IDs are preferably appended to frames prior to transmission into the Island Interconnect Fabric 208. To provide connectivity between different customer sites, VEC entity 412 is configured to establish one or more User Network Interface (UNIs), such as UNI 01 also designated by reference numeral 436 and UNI 02 also designated by reference numeral 438. As described herein, each UNI represents the termination point of one or more VECs, and may thus be considered to define one or more logical VEC ports. UNI 436, for example, has three VEC ports 440 a-c. UNI 438 has two VEC ports 442 a-b.
The forwarding engine 410 is in communicating relationship with the frame transmission and reception objects 404 and is coupled to at least one filtering database 444 that stores address information corresponding to the entities of the MAN 200 (FIG. 2). Specifically, filtering database 444 has a plurality of records (not shown) each containing a plurality of cells, including a destination address cell, a destination port cell, a filtering database ID (FID) cell and a corresponding timer cell. Each record in the filtering database 444 preferably corresponds to a particular network entity. The FID, which is derived from the message's PE-VLAN ID, allows a given destination MAC address to correspond to the same or to different MAC addresses for different PE-VLAN IDs. The forwarding engine 410 is configured to switch or bridge network messages, such as packets and/or frames, from a source port 402 to one or more destinations ports 402 depending on information contained in the forwarding database 428 and also on the spanning tree port states of the respective ports 402 as managed by MSTP entity 408. The forwarding engine 410 is also in communicating relationship with the MSTP entity 408 and relays MSTP-related messages received at ports 402 thereto. Forwarding engine 410 may also be in communicating relationship with VEC entity 412.
In the preferred embodiment, the Island Name field 502 is 2-bytes or longer, the Configuration Name field 503 is 32-bytes, the Revision Level field 504 is 2-bytes and the Configuration Digest field 506 is 2-bytes. In an alternative embodiment, the Island Name field 502 and Configuration Name field 503 are a combined 32-bytes and the two values may be separated by some specially selected character, such as the “#” symbol.
For example, switches 302, 304 and 306 (FIG. 3), which are all disposed in Island 202, are each be configured with the same Island name, e.g., “ISLAND0001”, the same configuration name, e.g., “MAN4452” and the same revision level, e.g., “0001”. Switches 302, 304 and 306 will additionally be configured to have the same mapping of PE-VLANs to MSTP Instance IDs. The switches disposed in Island 204 (FIG. 2), on the other hand, will each be configured with a different Island name, e.g., “ISLAND0002”. They may each be configured with the same or a different configuration name and/or revision level and will typically be configured with a different mapping of PE-VLANs to MSTP Instance IDs.
It should be understood that an Intra-Island Link is simply a logical representation of an interconnection between two customer sites across a single Island that, in the preferred embodiment, is a VLAN operating in accordance with the IEEE Std. 802.1Q-1998 specification standard. The Intra-Island Link may additionally or alternatively employ the ISL protocol from Cisco Systems, Inc.
The second VEC, on the other hand, must span multiple Islands, i.e., Islands 202 and 204. Accordingly, the MAN Provider must establish an Inter-Island Trunk 242 that connects Islands 202 and 204 for use by the second VEC. The third VEC similarly spans multiple Islands and thus it too requires access to an Inter-Island Trunk 244 that couples Islands 204 and 206.
Creation of the first VEC which couples customer sites 212 and 213 preferably proceeds as follows. Within Provider Edge switch 302, which connects to customer site 212, the MAN Provider establishes a User Network Interface (UNI), such as UNI 438 (FIG. 4). A UNI is a logical interface between a customer site and the MAN Provider's network, e.g., an Island. Each UNI established by the MAN Provider has one or more VEC ports each of which represents a termination or end point of a corresponding VEC that has been created by the MAN Provider. Within UNI 438, VEC port 442 a may be assigned to the first VEC. The MAN Provider then assigns a MAN Provider Equipment VLAN ID (PE-VLAN ID) to the first VEC. As described herein, the PE-VLAN ID is a VLAN designation that is appended to and thus identifies frames travelling through the respective Island, e.g., Island 202, that correspond to a respective VEC, e.g., the first VEC which connects customers sites 212 and 213. The PE-VLAN ID for the first VEC may be “4011”.
The customer selects a Customer Equipment VLAN ID (CE-VLAN ID) to be used by the customer when communicating between customer sites 212 and 213 coupled by Island 202. The CE-VLAN ID, which may be “0014”, is typically selected based on the needs of the customer's own sites and its networking equipment. The customer configures its own equipment so that all network messages, e.g., Ethernet frames, created in one of the sites, e.g., site 212, that are to be delivered to the other site, e.g., site 213, are tagged with the chosen CE-VLAN ID. The MAN Provider learns of the selection and configures the VEC entities 412 of the switches that are at the Island's boundaries and that connect to the two customer sites, i.e., switches 302 and 304 of Island 202, to map the chosen CE-VLAN ID, i.e., “0014”, to the respective PE-VLAN ID, i.e., “4011”. In particular, the MAN Provider configures the Customer VLAN mapping table 600 of the VEC entities 412.
[0072]FIG. 6 is a highly schematic illustration of VLAN mapping table 600 of switch 302. Table 600 is organized at least logically as a table or array having a plurality of columns and rows whose intersections define cells or records for storing information. Table 600 preferably has a CE-VLAN ID column 602, a VEC column 604, a PE-VLAN ID column 606, a UNI column 608, and a VEC Port column 610. Table 600 also has a plurality of rows 614 a-c. The MAN Provider preferably assigns a free row, e.g., row 614 a, to the first VEC. At row 614 a, the MAN Provider loads the chosen CE-VLAN ID, i.e., “0014”, into the cell corresponding to column 602, a VEC ID, e.g., “001”, into the cell corresponding to column 604, the PE-VLAN ID, e.g., “4011”, that has been assigned to the chosen CE-VLAN ID into the cell corresponding to column 606, the particular UNI assigned to this VEC, i.e., UNI 01, into the cell corresponding to column 608, and the particular VEC Port, i.e., VEC Port 0, into the cell corresponding to column 610. The MAN Provider similarly configures the VLAN mapping table 600 of switch 304 which is at the boundary of Island 202 and customer site 213.
End stations in the two sites 212 and 213 can now communicate with each other by using the chosen CE-VLAN ID. Suppose, for example, that a workstation disposed in site 212 wishes to communicate with a workstation in site 213. The workstation in site 212 encodes its message into one or more Ethernet frames, and in the frames' VLAN ID field inserts the CE-VLAN ID chosen by the customer, i.e., “0014”. These VLAN ID tagged frames are received by switch 302 within Island 202, which is at the boundary to customer site 212. The VLAN ID tagged frames are initially provided to the switch's VEC entity 412, which accesses its VLAN mapping table 600 to perform a look-up. Specifically, the VEC entity 412 searches table 600 to determine to which VEC the received frames belong. Row 614 a of the VLAN mapping table 600 indicates that CE-VLAN ID “0014” corresponds to VEC “001” and that this VEC has been mapped to PE-VLAN ID “4011”.
In one embodiment of the present invention, the VEC entity's tag manipulation engine 430 loads the frames' VLAN ID fields with PE-VLAN ID “4011”, replacing CE-VLAN ID “0014”. Alternatively, the tag manipulation engine 430 may add a new VLAN Identifier (VID) field (not shown) to the message and load this new VID field with the respective PE-VLAN ID, i.e., “4011”, leaving the original VID field (carrying the CE-VLAN ID) unmodified.
The frames, which are now tagged with PE-VLAN ID “4011”, are then provided to the UNI for transmission via the VEC Port that has been established for this VEC. The frames travel on the Intra-Island Link 240 established for the VEC and are received at switch 304. As indicated above, the Intra-Island Link 240 basically corresponds to a portion of the MSTP Instance or active topology defined within Island 202 to which PE-VLAN ID “4011” has been mapped. To the extent the frames are forwarded by any intermediary switches or bridges disposed in-between switches 302 and 304, these intermediary switches preferably do not modify the frames. That is, the frames do not undergo any further changes to their VLAN tags by switches that are forwarding the frames to other switches within Island 202.
At switch 304, the frames are received on a VEC Port that represents the other end of the VEC created to interconnect customer sites 212 and 213. As the frames are about to be transmitted from the UNI at switch 304, i.e., they are about to be transmitted outside of Island 202, they are subjected to another transformation. More specifically, the frames are provided to the VEC entity 412 of switch 304, which performs a look-up on its VLAN mapping table 600. Here, VEC entity 412 searches table 600 based on the PE-VLAN ID with which the frames have been tagged. The VEC entity 412 determines that PE-VLAN ID “4011” corresponds to CE-VLAN ID “0014”. Accordingly, the tag manipulation engine 430 loads the frames' VLAN ID fields with CE-VLAN ID “0014”, replacing PE-VLAN ID “4011”. The frames, which have been restored with their original VLAN IDs, are then sent from switch 302 into customer site 213. The frames are then delivered to the targeted workstation based on the destination address carried by the frames.
In the embodiment where the new VID field is added to the frame upon receipt in the Island 202, the tag manipulation engine 430 at switch 304 strips off the new VID field before sending the frame into customer site 213.
It should be understood that different CE-VLAN IDs could have been selected within customer sites 212 and 213 for use with the first VEC. In this case, the VLAN Mapping table 600 is preferably configured to specify both CE-VLAN IDs.
Creation of the second VEC coupling customer sites 212 and 216 preferably proceeds as follows. Within switch 302, which connects to customer site 212, the MAN Provider either establishes a new UNI or assigns an existing UNI to the second VEC. As UNI 438 is already assigned to customer site 212 for purposes of the first VEC, the MAN Provider may re-use this existing UNI 438 for the second VEC. Nonetheless, a new VEC Port at UNI 438, such as VEC Port 442 b, must be provided for the second VEC as each VEC must have its own VEC port. The MAN Provider then selects and assigns a PE-VLAN ID to the second VEC for use within Island 202. The selected PE-VLAN ID will be used to identify frames travelling through the Island 202 that correspond to the second VEC. Suppose that the MAN Provider selects PE-VLAN ID “4027” for the second VEC within Island 202.
A CE-VLAN ID is chosen by the customer for use by network entities disposed in customer site 212 when communicating with network entities disposed in customer site 216. Suppose the customer chooses CE-VLAN ID “0038” for use in customer site 212. The customer configures its own networking equipment disposed within site 212 so that all network messages, e.g., Ethernet frames, created within that site and destined for network entities in site 216 are tagged with CE-VLAN ID “0038”. The customer also notifies the MAN Provider of the selected CE-VLAN ID. In response, the MAN Provider then configures the VEC entity 412 of switch 302 which is at the boundary between Island 202 and customer site 212 to map frames tagged with the chosen CE-VLAN ID, i.e., “0038”, to the selected PE-VLAN ID, i.e., “4027” that is being mapped thereto. In particular, the MAN Provider configures the VLAN mapping table 600 of the VEC entity 412 at switch 302.
More specifically, the MAN Provider assigns a free row, e.g., row 614 b, to the second VEC. At row 614 b, the MAN Provider loads the chosen CE-VLAN ID, i.e., “0038”, into the cell corresponding to column 602, a VEC ID, e.g., “002”, into the cell corresponding to column 604, and the corresponding PE-VLAN ID, e.g., “4027”, selected by the MAN Provider into the cell corresponding to column 606. The MAN Provider also loads the particular UNI assigned to this VEC, i.e., UNI 01, into the cell corresponding to column 608, and the selected VEC Port, i.e., VEC Port 1, into the cell corresponding to column 610.
Within Island 204, which connects to customer site 216, the MAN Provider establishes a UNI that gives network entities in customer site 216 access to the second VEC. The UNI is preferably provided at the Provider Edge switch(es) at the boundary between Island 204 and site 216, i.e., the switch(es) that are directly connected to customer site 216, i.e., via site links 228 and/or 229. The MAN Provider also establishes a VEC port within the UNI to terminate the second VEC at Island 204. The MAN Provider then selects and assigns a PE-VLAN ID to the second VEC for use within Island 204. The selected PE-VLAN ID will be used to identify frames travelling within Island 204 that correspond to the second VEC. Notably, the selected PE-VLAN ID for use in Island 204 may be different from PE-VLAN ID “4027” which was selected for use in Island 202. Indeed, suppose that the MAN Provider selects PE-VLAN ID “4017” for the second VEC within Island 204.
As above, the customer chooses a CE-VLAN ID based on its own needs and the capabilities of its networking equipment to be used by network entities disposed in customer site 216 when communicating with network entities disposed in customer site 212. The CE-VLAN ID that is chosen for use in site 216 may be the same or may differ from the one selected for use in customer site 212. Suppose the customer selects CE-VLAN ID “0018” for use in customer site 216. The customer configures its own internetworking equipment disposed within site 216 so that all network messages, e.g., Ethernet frames, created within that site and destined for network entities in site 212 are tagged with CE-VLAN ID “0018”. The customer also notifies the MAN Provider of the selected CE-VLAN ID. The MAN Provider then configures the VEC entity 412 of the switch disposed in Island 204 that is directly connected to customer site 216 to map frames tagged with CE-VLAN ID “0018” to the PE-VLAN ID selected for use in Island 204, i.e., “4017”. In particular, the MAN Provider configures the VLAN mapping table 600 of the VEC entity 412 at the Provider Edge switch(es) of Island 204 relative to customer site 216.
Row 614 c (FIG. 6) illustrates how the VLAN Mapping Table 600 at the respective Provider Edge switch(es) of Island 204 are configured. More specifically, the MAN Provider loads the chosen CE-VLAN ID, i.e., “0018”, into the cell corresponding to column 602, the VEC ID, e.g., “002”, into the cell corresponding to column 604, and the corresponding PE-VLAN ID, e.g., “4017”, that has been mapped to the chosen CE-VLAN ID into the cell corresponding to column 606. The MAN Provider also loads the UNI assigned to this VEC, e.g., UNI 00, into the cell corresponding to column 608, and the VEC Port, e.g., VEC Port 0, into the cell corresponding to column 610.
[0089]FIG. 7 is a highly schematic illustration of an Inter-Island Trunk Mapping Table 700. Table 700 is organized at least logically as a table or array having a plurality of columns and rows whose intersections define cells or records for storing information. Table 700 preferably has a PE-VLAN ID column 702, a VEC column 704, and an Inter-Island Trunk ID column 706. Table 700 also has a plurality of rows 710 a-c. At the Island Boundary Bridges in Island 202, the MAN Provider preferably assigns a free row, e.g., row 710 a, to the second VEC. At row 710 a, the MAN Provider loads the selected PE-VLAN ID for Island 202, i.e., “4027”, into the cell corresponding to column 702, and a VEC ID selected for the second VEC, e.g., “002”, into the cell corresponding to column 704. The MAN Provider loads the cell corresponding to column 706 with an Inter-Island Trunk ID corresponding to the tag or label that is to be appended to network messages traversing the Island Interconnect Fabric 208. The Inter-Island Trunk ID, which may comprise more than one label or tag, is selected depending on the particular protocol(s) used to interconnect the Islands. Assuming that the MPLS protocol and, more specifically, Emulated VLAN over MPLS (EVoMPLS) is the protocol being used, a unique MPLS label, e.g., “6042”, is selected for the second VEC's Inter-Island Trunk.
The MAN Provider also configures the Inter-Island Trunk Mapping Table 700 at the Island Boundary Bridge(s) of Island 204. Row 710 b (FIG. 7) illustrates how this entry would be configured. Specifically, PE-VLAN ID “4017” which was selected for use in Island 204 is loaded into the cell corresponding to column 702, the common VEC ID, i.e., “002”, is loaded into the cell corresponding to column 704, and the common Inter-Island Trunk ID is loaded into the cell corresponding to column 706.
Second, the MAN Provider configures the Island Boundary Bridges to tag frames for transmission over the Inter-Island Trunk and to capture and process frames received over the Inter-Island Trunk. In particular, when switch 302 of Island 202 receives a frame tagged with CE-VLAN ID “0038” which corresponds to the second VEC, it uses the CE-VLAN ID to perform a look-up on its VLAN Mapping Table 600 to derive the corresponding PE-VLAN ID, i.e., “4027”. Switch 302 then replaces the CE-VLAN ID with corresponding PE-VLAN ID and forwards the frame into Island 202 (assuming the VEC is utilizing Island link 210 b at switch 306). The frame is received at switch 306, which encapsulates the received frame for transmission across the Island Interconnect Fabric 208.
[0092]FIG. 8 is a highly schematic illustration of an encapsulated frame 800 for transmission across Island Interconnect Fabric 208. The encapsulated frame 800 includes an MPLS label stack 802 appended to the original Ethernet frame 804. As indicated above, if the PE-VLAN ID was added to the CE-VLAN ID at the UNI, instead of replacing it, then the Ethernet frame 804 may include a VLAN ID (VID) field 805, corresponding to the CE-VLAN ID. The MPLS label stack 802 includes a Layer 2 (L2) header 806 that corresponds to the medium employed by the Island Interconnect Fabric 208, an IP/MPLS header 808 and a Virtual Ethernet Circuit ID field 810. A suitable encapsulation scheme for use with the present invention is described in Request for Comments (RFC) 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5 (September 1999). The Island Boundary Bridge performs a look-up on its Inter-Island Trunk Mapping Table 700 to derive the Virtual Ethernet Circuit ID. Specifically, the Island Boundary Bridge locates the Inter-Island Trunk ID that corresponds to the PE-VLAN ID with which the received Ethernet frame is tagged. Here, the PE-VLAN ID is “4027” and the matching Inter-Island Trunk ID is “6042”. This retrieved value is loaded into the Virtual Ethernet Circuit ID field 810.
The encapsulated frame is then transmitted onto the Island Interconnect Fabric 208. The Inter-Island Trunk 242 delivers the frame to all ports within Islands 202-206 that are members of the same VEC as specified by the Virtual Ethernet Circuit ID (other than the port on which the frame was sent). The encapsulated frame is thus received at the Island Boundary Bridge(es) of Island 204. The Island Boundary Bridge of Island 204 utilizes the value loaded in the encapsulated frame's Virtual Ethernet Circuit ID field to derive the corresponding PE-VLAN ID for use in Island 204. Here, the Virtual Ethernet Circuit ID is “6042” and the matching PE-VLAN ID from row 710 b (FIG. 7) is thus “4017”. The Island Boundary Bridge also determines whether it can accept the received frame based on the spanning tree state of the port on which it was received. If the port is in the blocking spanning tree port state for VLAN “4017”, the frame is discarded. In this case, there would be another Island Boundary Port at Island 204 that is in the forwarding spanning tree port state for VLAN “4017”, and could thus accept the frame.
The Island Boundary Bridge of Island 204 at which the frame is accepted strips off the MPLS label stack and recovers the original Ethernet frame 804. In the frame's VLAN ID field 805, the Island Boundary Bridge loads the PE-VLAN ID for this VEC, i.e., “4017”. The Island Boundary Bridge then transmits the frame within Island 204. The frame is received at the Provider Edge bridge of Island 204 for customer site 216. The Provider Edge bridge performs a look-up on its VLAN Mapping Table 600 using the frame's PE-VLAN ID to derive the corresponding CE-VLAN ID. Here, the PE-VLAN ID is “4017” and thus the matching CE-VLAN ID is “0018”. Accordingly, the Provider Edge bridge loads the CE-VLAN ID into the Ethernet frame replacing the PE-VLAN ID. The frame, tagged with the CE-VLAN ID, is then transmitted by the Provider Edge switch of Island 204 into customer site 216 for receipt by the target network entity.
To avoid the formation of loops resulting from the presence of multiple connections between a given Island and the Island Interconnect Fabric 208, the Islands preferably run a new protocol, the Inter-MAN Control Protocol (IMCP) in accordance with the present invention. The IMCP, which represents a modified version of MSTP, specifies special rules and methods to efficiently prevent the formation of loops among the Islands of a MAN Provider's Metropolitan Area Network. This modified version blocks the formation of loops and yet avoids having to run a single instance of the spanning tree protocol across the entire MAN, i.e., across all of the Islands. Indeed, because there may be hundreds of Islands (if not more) and because the total-number of VECs defined within the Islands may be much greater than the 4096 permitted by the IEEE Std. 802.1Q-1998 and IEEE Draft P802.1s/D13 specification standards, it would be impractical if not impossible to run a spanning tree instance across them.
Row 710 c may correspond to an entry for the extra VEC, i.e., VEC “301”, used in Inter-Island Trunk 242, i.e., “6042”, as data VEC “002”. As shown, no PE-VLAN ID is assigned to the extra VEC as BPDUs received by an Island Boundary Bridge are not forwarded. The assigned VEC ID is loaded into the Virtual Ethernet Circuit ID field 810 of encapsulated BPDUs prior to transmission into Inter-Island Trunk 242.
As described above, an Inter-Island Trunk functions like a shared-medium Ethernet or a bridged LAN in connectivity. Thus, BPDUs transmitted onto an Inter-Island Trunk are received by all other switches “coupled” to the Inter-Island Trunk as well as by other ports of the switch transmitting the BPDU that also happen to be coupled to the Inter-Island Trunk. Accordingly, BPDUs issued from one Inter-Island Port and encapsulated with the extra VEC ID are delivered to all Inter-Island Ports (other than the port on which they were sent) coupled to the Inter-Island Trunk. The switches, moreover, utilize the information in the received BPDUs to compute an active topology for each MSTI defined at the switch. As a result, for each PE-VLAN ID, an Island will block all but one Island link 210 to the respective Inter-Island Trunk. Because each VEC is associated with a single PE-VLAN ID within each Island, moreover, all but one of the Inter-Island links 210 for each VEC will be blocked. The particular Island link 210 that transitions to the forwarding state may, moreover, vary among PE-VLAN IDs. This provides a measure of load-sharing among the Inter-Island links 210.
Similarly, if a BPDU is received that does not have an Island ID field 502, it is 5 discarded and not relied upon by the receiving bridge in its spanning tree calculations.
[0112]FIG. 9 is a highly schematic, partial block diagram of network 200 illustrating Inter-Island Trunk 242 disposed within Island Interconnect Fabric 208 and configured to carry traffic for the second VEC. As described above, the second VEC extends between Islands 202 and 204. Each of these Islands 202 and 204, moreover, have two Inter-Island links 210 a, 210 b and 210 c and 210 d, respectively. Each Island 202 and 204 prevents the formation of a loop that would otherwise be caused by the existence of Inter-Island Trunk 242 by placing all but one of its ports coupled to Inter-Island Trunk 242 in the blocking state. For example, the port coupled to Island link 210 b at Island 202 and the port coupled to Island link 210 d at Island 204 may each be transitioned to the blocking state, as indicated by dots 902 and 904. The ports corresponding to links 210 a and 210 c, on the other hand, are each transitioned to forwarding.
[0113]FIG. 10 is a highly schematic, partial block diagram of MAN 200 illustrating Inter-Island Trunk 244 disposed within Island Interconnect Fabric 208 and configured to carry traffic for the third VEC configured to connect customer sites 216 and 217 (FIG. 2) via Islands 204 and 206. Islands 204 and 206 are coupled to Inter-Island Trunk 244 via Inter-Island links 210 c, 210 d and 210 e and 210 f. Each Island 204 and 206 prevents the formation of a loop that would otherwise be caused by the existence of Inter-Island Trunk 244 by placing all but one of its ports coupled to Inter-Island Trunk 244 in the blocking state. For example, the port coupled to Island link 210 c at Island 204 the port coupled to Island link 210 e at Island 206 may each be transitioned to the blocking state, as indicated by dots 1002 and 1004. The ports corresponding to links 210 d and 210 f transition to forwarding.
[0116]FIG. 12 is a highly schematic illustration of another Inter-Island Trunk 1200 in accordance with the present invention. The Island Interconnect Fabric has been omitted for clarity. Inter-Island Trunk 1200 includes a plurality of Islands 1202-1210. Each Island, moreover, has a plurality of interconnected bridges. As shown, there are three VECs 1212-1216 formed among the Islands 1202-1210, all carried on a single Inter-Island Trunk. Island 1202 has only a single connection 1215 to VEC 1212. Therefore, if connection 1215 is lost, Island 1202 loses connectivity with Islands 1204 and 1210. The bridges of Island 1208 are organized into two parts, part 1218 a and 1218 b, each made up of four interconnected bridges. However, there are no connections between the bridges forming the two parts 1218 a and 1218 b inside of Island 1208. Instead, the two parts 1218 a and 1218 b of Island 1208 utilize VECs 1214 and 1216 for intercommunication. Similarly, at Island 1206, execution of the IMCP results in link 1219 between the two bridges being blocked. The two bridges of Island 1206 utilize VEC 1216 to intercommunicate.
[0117]FIG. 13 is a highly schematic illustration of the same Inter-Island Trunk 1200 as FIG. 12. However, the VECs have been omitted for clarity and the BPDU VEC or BPDU Service Instance 1302 is shown. As mentioned above, each Inter-Island Bridge of the Islands 1202-1210 that are connected to an Inter-Island Trunk have a connection to the BPDU VEC 1302. As described herein, the Inter-Island Bridges utilize the BPDU VEC 1302 to exchange BPDUs among themselves. The Inter-Island Bridges use these received BPDUs in their execution of the IMCP to identify and block redundant links to the VECs. For those Inter-Island Bridges connected to multiple VECs on a given Inter-Island Trunk, only a single connection is required to the BPDU VEC 1302. For example, bridge 1304 at Island 1210 which is connected to VECs 1212 and 1214 (FIG. 12) need only establish a single connection 1306 to the BPDU VEC 1302.
As mentioned above, there are different categories of VECs. The VECs described above correspond to “bridge-like” VECs in which the CE-VLAN IDs of received frames are altered within the Island. Additionally, network messages corresponding to L2 protocols that are not used for customer-MAN interaction, such as IEEE Std. 802.3-2000 pause frames (also known as 802.3x pause frames) are discarded upon receipt at the UNI. As indicated above, BPDUs from the customer sites are never utilized by the switches disposed in the Islands in their computation of the CIST. With “wire-like” VECs, CE-VLAN ID tagged frames are carried transparently through the MAN as are network messages corresponding to L2 protocols that are not used for customer-MAN interaction.
US5959968 * 30 Jul 1997 28 Sep 1999 Cisco Systems, Inc. Port aggregation protocol
US5959989 * 25 Jun 1997 28 Sep 1999 Cisco Technology, Inc. System for efficient multicast distribution in a virtual local area network environment
US6163543 * 17 May 1999 19 Dec 2000 Cisco Technology, Inc. Port aggregation protocol
US6188694 * 23 Dec 1997 13 Feb 2001 Cisco Technology, Inc. Shared spanning tree protocol
US6236659 * 1 Dec 1997 22 May 2001 3Com Technologies Network configuration
US6298061 * 19 Sep 2000 2 Oct 2001 Cisco Technology, Inc. Port aggregation protocol
US6446131 * 19 Jun 1999 3 Sep 2002 Hewlett-Packard Company Bridges and other layer-two devices for forwarding MAC frames
US6560236 * 4 Oct 1999 6 May 2003 Enterasys Networks, Inc. Virtual LANs
US7061876 * 29 Jan 2002 13 Jun 2006 Fujitsu Limited Switch and bridged network
US7127523 * 25 Jan 2002 24 Oct 2006 Corrigent Systems Ltd. Spanning tree protocol traffic in a transparent LAN
US7443845 * 6 Dec 2002 28 Oct 2008 Cisco Technology, Inc. Apparatus and method for a lightweight, reliable, packet-based transport protocol
US7475142 13 May 2005 6 Jan 2009 Cisco Technology, Inc. CIFS for scalable NAS architecture
US7508774 * 27 Apr 2004 24 Mar 2009 Alcatel-Lucent Usa Inc. Extensions to the spanning tree protocol
US7529199 * 31 May 2005 5 May 2009 Cisco Technology, Inc. System and method for resolving conflicts in proxy routing information associated with multicast distribution trees
US7558205 * 1 Aug 2003 7 Jul 2009 Foundry Networks, Inc. System and method for detecting and isolating a remote loop
US7564858 1 Aug 2003 21 Jul 2009 Foundry Networks, Inc. System and method for enabling a remote instance of a loop avoidance protocol
US7565455 * 28 Jan 2004 21 Jul 2009 Huawei Technologies Co., Ltd. System and method of accessing and transmitting different data frames in a digital transmission network
US7580372 * 15 Dec 2005 25 Aug 2009 Alcatel Lucent System and method for implementing multiple spanning tree protocol automatic 802.1Q trunking
US7606178 * 10 Feb 2006 20 Oct 2009 Cisco Technology, Inc. Multiple wireless spanning tree protocol for use in a wireless mesh network
US7606240 * 16 Jun 2005 20 Oct 2009 Extreme Networks Ethernet automatic protection switching
US7627654 9 Jun 2003 1 Dec 2009 Foundry Networks, Inc. System and method for multiple spanning tree protocol domains in a virtual local area network
US7653011 10 Feb 2006 26 Jan 2010 Cisco Technology, Inc. Spanning tree protocol for wireless networks
US7660313 * 22 Apr 2005 9 Feb 2010 Huawei Technologies Co., Ltd. Sub-rate transmission method for user data services in transmission devices of a metropolitan area network
US7760738 * 28 Jul 2005 20 Jul 2010 Verizon Services Corp. Admission control for services
US7821972 29 Sep 2005 26 Oct 2010 Cisco Technology, Inc. System and method for building large-scale layer 2 computer networks
US7822049 * 6 Oct 2005 26 Oct 2010 Foundry Networks, Llc System and method for enabling a remote instance of a loop avoidance protocol
US7835367 * 23 Mar 2005 16 Nov 2010 Fujitsu Limited Network connection method, network connection system, and, layer 2 switch and management server forming the network connection system
US7856490 15 Oct 2009 21 Dec 2010 Foundry Networks, Llc System and method for multiple spanning tree protocol domains in a virtual local area network
US7872991 * 4 Feb 2003 18 Jan 2011 Alcatel-Lucent Usa Inc. Methods and systems for providing MPLS-based layer-2 virtual private network services
US7912071 * 27 Mar 2007 22 Mar 2011 Hitachi, Ltd. Passive optical network system for supporting virtual ethernet service and method for the same
US7916741 * 2 Apr 2007 29 Mar 2011 William Marsh Rice University System and method for preventing count-to-infinity problems in ethernet networks
US7944816 14 May 2009 17 May 2011 Foundry Networks, Llc System and method for detecting and isolating a remote loop
US7953089 * 16 May 2006 31 May 2011 Cisco Technology, Inc. Systems and methods for multicast switching in a private VLAN
US8018880 * 25 Mar 2008 13 Sep 2011 Brixham Solutions Ltd. Layer 2 virtual private network over PBB-TE/PBT and seamless interworking with VPLS
US8040897 * 27 Feb 2009 18 Oct 2011 Cisco Technology, Inc. Multiple spanning tree extensions for trunk ports carrying more than 4K virtual services
US8045487 * 31 Mar 2006 25 Oct 2011 Huawei Technologies Co., Ltd. Method for implementing multicast in rapid spanning tree protocol ring network
US8081633 11 Jul 2006 20 Dec 2011 Siemens Enterprise Communications Gmbh & Co. Kg Network node unit and method for forwarding data packets
US8094663 31 May 2005 10 Jan 2012 Cisco Technology, Inc. System and method for authentication of SP ethernet aggregation networks
US8144629 8 Jun 2010 27 Mar 2012 Verizon Services Corp. Admission control for services
US8166151 * 22 Dec 2003 24 Apr 2012 Enterasys Networks, Inc. Method and apparatus for determining a spanning tree
US8194656 * 28 Apr 2005 5 Jun 2012 Cisco Technology, Inc. Metro ethernet network with scaled broadcast and service instance domains
US8213435 * 28 Apr 2005 3 Jul 2012 Cisco Technology, Inc. Comprehensive model for VPLS
US8274989 30 Mar 2007 25 Sep 2012 Rockstar Bidco, LP Point-to-multipoint (P2MP) resilience for GMPLS control of ethernet
US8345699 9 Sep 2010 1 Jan 2013 Foundry Networks, Llc System and method for enabling a remote instance of a loop avoidance protocol
US8369330 30 Jun 2006 5 Feb 2013 Rockstar Consortium LP Provider backbone bridging—provider backbone transport internetworking
US8385355 29 Oct 2008 26 Feb 2013 Brixham Solutions Ltd E-Trees over MPLS and PBB-TE networks
US8392509 * 26 Mar 2004 5 Mar 2013 Cisco Technology, Inc. Ethernet local management interface (E-LMI)
US8446819 19 Apr 2011 21 May 2013 Foundry Networks, Llc System and method for detecting and isolating a remote loop
US8514878 24 Aug 2012 20 Aug 2013 Rockstar Consortium Us Lp Point-to-multipoint (P2MP) resilience for GMPLS control of ethernet
US8520507 * 8 Mar 2004 27 Aug 2013 Extreme Networks, Inc. Ethernet automatic protection switching
US8553697 14 Dec 2012 8 Oct 2013 Rockstar Consortium Us Lp Provider backbone bridging—provider backbone transport internetworking
US8565123 * 3 May 2006 22 Oct 2013 Cisco Technology, Inc. System and method for running a multiple spanning tree protocol with a very large number of domains
US8619784 * 22 Jan 2008 31 Dec 2013 Brixham Solutions Ltd. Mapping PBT and PBB-TE traffic to VPLS and other services
US8630303 * 15 Nov 2010 14 Jan 2014 Cisco Technology, Inc. Preventing loops in networks operating different protocols to provide loop-free topology
US8793095 9 Mar 2011 29 Jul 2014 Intel Corporation Functional fabric-based test controller for functional and structural test and debug
US8817666 * 3 Nov 2010 26 Aug 2014 Foundry Networks, Llc System and method for multiple spanning tree protocol domains in a virtual local area network
US8842579 7 Jul 2011 23 Sep 2014 Cisco Technology, Inc. Shared virtual device ports
US8855122 22 Jun 2005 7 Oct 2014 Rockstar Consortium Us Lp Backbone provider bridging networks
US8923292 6 Apr 2005 30 Dec 2014 Rockstar Consortium Us Lp Differential forwarding in address-based carrier networks
US8976793 21 Nov 2012 10 Mar 2015 Rockstar Consortium Us Lp Differential forwarding in address-based carrier networks
US9036641 9 Sep 2013 19 May 2015 Rpx Clearinghouse Llc Provider backbone bridging—provider backbone transport internetworking
US9043665 * 9 Mar 2011 26 May 2015 Intel Corporation Functional fabric based test wrapper for circuit testing of IP blocks
US9087037 5 Jun 2013 21 Jul 2015 Intel Corporation Functional fabric based test access mechanism for SoCs
US9088669 28 Apr 2005 21 Jul 2015 Cisco Technology, Inc. Scalable system and method for DSL subscriber traffic over an Ethernet network
US9118590 21 Mar 2013 25 Aug 2015 Rpx Clearinghouse Llc VLAN support of differentiated services
US9122507 * 18 Feb 2012 1 Sep 2015 Cisco Technology, Inc. VM migration based on matching the root bridge of the virtual network of the origination host and the destination host
US9219655 * 25 Oct 2012 22 Dec 2015 Symantec Corporation Systems and methods for discovering network topologies
US9264354 9 Oct 2013 16 Feb 2016 Brixham Solutions Ltd. Mapping PBT and PBB-TE traffic to VPLS and other services
US9356862 5 Sep 2014 31 May 2016 Rpx Clearinghouse Llc Differential forwarding in address-based carrier networks
US9509526 * 18 Apr 2008 29 Nov 2016 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for quality of service (QoS) planning for an Ethernet based network
US9544219 * 31 Jul 2015 10 Jan 2017 Brocade Communications Systems, Inc. Global VLAN services
US9608903 * 30 Nov 2011 28 Mar 2017 Donald E. Eastlake, III Systems and methods for recovery from network changes
US9735859 * 27 Nov 2013 15 Aug 2017 Vt Idirect, Inc. Method and apparatus for distributing addresses of communication devices within a satellite network
US9736065 * 24 Jun 2011 15 Aug 2017 Cisco Technology, Inc. Level of hierarchy in MST for traffic localization and load balancing
US9787607 * 4 Apr 2011 10 Oct 2017 Infinera Corporation End-to-end provisioning of Ethernet Virtual Circuits
US20030128688 * 26 Dec 2002 10 Jul 2003 Lg Electronics Inc. ATM based MPLS-LER system and method for establishing connection
US20040109443 * 6 Dec 2002 10 Jun 2004 Andiamo Systems Inc. Apparatus and method for a lightweight, reliable, packet-based transport protocol
US20040151181 * 4 Feb 2003 5 Aug 2004 Chu Thomas P. Methods and systems for providing MPLS-based layer-2 virtual private network services
US20040252634 * 27 Apr 2004 16 Dec 2004 Alcatel Ip Networks, Inc. Extensions to the spanning tree protocol
US20050005029 * 28 Jan 2004 6 Jan 2005 Zhiqun He System and method of accessing and transmitting different data frames in a digital transmission network
US20050013260 * 9 Jun 2003 20 Jan 2005 Foundry Networks, Inc. System and method for multiple spanning tree protocol domains in a virtual local area network
US20050013261 * 10 Jul 2004 20 Jan 2005 Seaman Michael John Reducing address learning in virtual bridged local area networks
US20050138008 * 22 Dec 2003 23 Jun 2005 Tsillas Demetrios J. Method and apparatus for determining a spanning tree
US20050141567 * 29 Dec 2003 30 Jun 2005 Abed Jaber Extending Ethernet-over-SONET to provide point-to-multipoint service
US20050180391 * 23 Mar 2005 18 Aug 2005 Katsumi Shimada Network connection method, network connection system, and, layer 2 switch and management server forming the network connection system
US20050190773 * 22 Apr 2005 1 Sep 2005 Huawei Technologies Co., Ltd. Sub-rate transmission method for user data services in transmission devices of a metropolitan area network
US20050190788 * 28 Feb 2005 1 Sep 2005 Wong Yu-Man M. System and method for VLAN multiplexing
US20050237943 * 8 Nov 2004 27 Oct 2005 Yasushi Sasagawa Transmission device
US20050286541 * 22 Jun 2005 29 Dec 2005 Nortel Networks Ltd. Backbone provider bridging networks
US20060182133 * 13 Apr 2006 17 Aug 2006 Takanori Choumaru Data transmission device
US20060245435 * 28 Apr 2005 2 Nov 2006 Cisco Technology, Inc. Scalable system and method for DSL subscriber traffic over an Ethernet network
US20060245436 * 28 Apr 2005 2 Nov 2006 Cisco Technology, Inc. Comprehensive model for VPLS
US20060245438 * 28 Apr 2005 2 Nov 2006 Cisco Technology, Inc. Metro ethernet network with scaled broadcast and service instance domains
US20060268749 * 10 Feb 2006 30 Nov 2006 Rahman Shahriar I Multiple wireless spanning tree protocol for use in a wireless mesh network
US20060268856 * 31 May 2005 30 Nov 2006 Cisco Technology, Inc. System and method for authentication of SP Ethernet aggregation networks
US20060280131 * 10 Feb 2006 14 Dec 2006 Rahman Shahriar I Spanning tree protocol for wireless networks
US20070002770 * 30 Jun 2005 4 Jan 2007 Lucent Technologies Inc. Mechanism to load balance traffic in an ethernet network
US20070076719 * 30 Jun 2006 5 Apr 2007 Nortel Networks Limited Provider backbone bridging - provider backbone transport internetworking
US20070140147 * 15 Dec 2005 21 Jun 2007 Jeremy Touve System and method for implementing multiple spanning tree protocol automatic 802.1Q trunking
US20070230370 * 31 Mar 2006 4 Oct 2007 Yong Luo Method for Implementing Multicast in Rapid Spanning Tree Protocol Ring Network
US20070258390 * 3 May 2006 8 Nov 2007 Tameen Khan System and method for running a multiple spanning tree protocol with a very large number of domains
US20070258462 * 11 Jul 2006 8 Nov 2007 Oliver Veits Network Node Unit And Method For Forwarding Data Packets
US20070280266 * 8 Aug 2006 6 Dec 2007 Via Technologies, Inc. Method and apparatus for packet switching
US20080212595 * 22 Jan 2008 4 Sep 2008 Hammerhead Systems, Inc. Mapping PBT and PBB-TE traffic to VPLS and other services
US20080240129 * 2 Apr 2007 2 Oct 2008 Khaled Elmeleegy System and method for preventing count-to-infinity problems in ethernet networks
US20080247406 * 25 Mar 2008 9 Oct 2008 Hammerhead Systems, Inc. Layer 2 virtual private network over PBB-TE/PBT and seamless interworking with VPLS
US20080279196 * 6 Apr 2005 13 Nov 2008 Robert Friskney Differential Forwarding in Address-Based Carrier Networks
US20090010265 * 5 Jul 2007 8 Jan 2009 Cisco Technology, Inc. Flexible mapping of virtual local area networks to Ethernet virtual circuits
US20090022070 * 18 Apr 2008 22 Jan 2009 Paola Iovanna Method and apparatus for quality of service (QoS) planning for an ethernet based network
US20090225668 * 14 May 2009 10 Sep 2009 Jordi Moncada-Elias System and Method For Detecting And Isolating A Remote Loop
US20100246393 * 8 Jun 2010 30 Sep 2010 Haidar Chamas Admission control for services
US20110064001 * 9 Sep 2010 17 Mar 2011 Brocade Communications Systems, Inc. System and method for enabling a remote instance of a loop avoidance protocol
US20110064002 * 15 Nov 2010 17 Mar 2011 Cisco Technology, Inc. Preventing loops in networks operating different protocols to provide loop-free topology
US20110267983 * 3 Nov 2010 3 Nov 2011 Foundry Networks, LLC, a Delware limited liability company System And Method For Multiple Spanning Tree Protocol Domains In A Virtual Local Area Network
US20120233514 * 9 Mar 2011 13 Sep 2012 Srinivas Patil Functional fabric based test wrapper for circuit testing of ip blocks
US20120254376 * 4 Apr 2011 4 Oct 2012 David Bumstead End-to-end provisioning of ethernet virtual circuits
US20120327766 * 24 Jun 2011 27 Dec 2012 Cisco Technology, Inc. Level of hierarchy in mst for traffic localization and load balancing
US20130219384 * 18 Feb 2012 22 Aug 2013 Cisco Technology, Inc. System and method for verifying layer 2 connectivity in a virtual environment
US20130254356 * 30 Nov 2011 26 Sep 2013 Donald E. Eastlake, III Systems and methods for recovery from network changes
US20150003295 * 18 Sep 2014 1 Jan 2015 Rockstar Consortium Us Lp Backbone Provider Bridging Networks
US20160006613 * 2 Dec 2013 7 Jan 2016 Hangzhou H3C Technologies Co., Ltd. Detecting an access customer edge device of a provider edge device
US20160065458 * 17 Sep 2013 3 Mar 2016 Zte Corporation System, Method and Device for Forwarding Packet
DE102005035201A1 * 27 Jul 2005 8 Feb 2007 Siemens Ag Netzknoteneinheit und Verfahren zur Weiterleitung von Datenpaketen
DE102005035201B4 * 27 Jul 2005 26 Feb 2009 Siemens Ag Netzknoteneinheit und Verfahren zur Weiterleitung von Datenpaketen
EP1774712A2 * 22 Jun 2005 18 Apr 2007 Nortel Networks Limited Backbone provider bridging networks
EP1774712A4 * 22 Jun 2005 22 Jan 2014 Nortel Networks Ltd Backbone provider bridging networks
EP1969767A1 * 5 Jan 2007 17 Sep 2008 Belair Networks Inc. Virtual root bridge
EP1969767A4 * 5 Jan 2007 5 Oct 2011 Belair Networks Inc Virtual root bridge
EP2095258A2 * 12 Dec 2007 2 Sep 2009 CiscoTechnology Inc. Shared virtual device ports
EP2095258A4 * 12 Dec 2007 26 Jun 2013 Cisco Tech Inc Shared virtual device ports
WO2006002230A3 * 22 Jun 2005 7 Dec 2006 Nortel Networks Ltd Backbone provider bridging networks
WO2006130278A1 26 Apr 2006 7 Dec 2006 Cisco Technology, Inc. A spanning-tree protocol for wireless networks
WO2006130385A2 * 23 May 2006 7 Dec 2006 Alcatel Lucent Facilitating computation of role and state information for multiple spanning tree instances
WO2006130385A3 * 23 May 2006 30 Oct 2008 Alcatel Lucent Facilitating computation of role and state information for multiple spanning tree instances
WO2007005307A1 * 22 Jun 2006 11 Jan 2007 Lucent Technologies Inc. Mechanism to load balance traffic in an ethernet network
WO2007038853A1 * 11 Sep 2006 12 Apr 2007 Nortel Networks Limited Provider backbone bridging - provider backbone transport internetworking
WO2008079667A2 12 Dec 2007 3 Jul 2008 Cisco Technology, Inc. Shared virtual device ports
WO2008118467A1 * 25 Mar 2008 2 Oct 2008 Hammerhead Systems, Inc. Layer 2 virtual private network over pbb-te/pbt and seamless interworking with vpls
Cooperative Classification H04L45/00, H04L45/48, H04L12/462
European Classification H04L45/00, H04L45/48, H04L12/46B7
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:FINN, NORMAN W.;REEL/FRAME:013539/0618