WO2003101122A2 - Method and apparatus for a hierarchial switched network system - Google Patents

Abstract

A hierarchical networking architecture comprising methods and an apparatus for the implementation of a hierarchical MAC address designation system is disclosed. In this invention, the physical addresses of all the nodes/Network Elements ( NEs) (1.1, 1.2, 1.3, 1.4, 1.5, etc.) of a hierarchical multi-ring (1.30, 1.31, 1.32, 1.33, 1.34, etc.) network are assigned in a hierarchical manner. The implementation of this hierarchical MAC addressing scheme significantly reduces the size of Content Addressable Memory (CAM) tables needed for the manipulation of data frames. Also, the hierarchical network structure allows the implementation of a simple decision-making mechanism for switching data frames toward their destinations. With the help of this mechanism, data frames can be routed through the described hierarchical network to the destined node quickly and easily by using only simple hardware circuitry that examines header information located at the beginning of the data frame. This hierarchical network structure inherently supports multicast and broadcast functions, and it can be extended for WAN purposes by incorporating area code information with the MAC address.

Description

Method and Apparatus for a Hierarchical Switched Network System

Cross-Reference to Related Applications

This is a regular utility patent application of U.S.S.N 60/384,214 filed May 27, 2002, the priority of which is hereby claimed, and the disclosure of which is incorporated herein by reference.

Field of the Invention

This invention relates to telecommunications network systems. It is disclosed in the context of a system for transporting and distributing data among network elements in, for example, ring-based Synchronous Optical NET work (SONET) or Synchronous Digital Hierarchy (SDH) transport. However, it is believed to be useful in other applications and network topologies as well.

Background of the Invention

The demand for capacity in data communication networks is doubling every six months. It is unlikely that this growth in demand will diminish in the near future. Indeed, there are reasonably reliable predictions that it may accelerate. As voice over Internet Protocol (VoIP), storage over IP, streaming multimedia, Internet appliances, storage area networks, and wireless 3G networks proliferate, the demand for capacity will only increase.

Telecommunication service providers are faced with two significant obstacles to this explosive growth. First, existing, or legacy, telecom networks were not designed to transport packet-based data efficiently, and certainly were not designed to scale up in data-handling capacity at the rate that packet-based data traffic is increasing. Second, most existing telecoms' primary revenue streams are based on voice data, while their fastest-rising and most significant demands and costs are those associated with the increase of packet-based data traffic. Thus, the telecoms are faced with a dilemma. They can either invest significant amounts of capital to build high-capacity data networks or risk obsolescence.

Data is generally switched two ways. Voice, for example, has historically been circuit switched, h a circuit switched network each data stream is sent over a circuit between the sender and the receiver. The capacity of this circuit is dedicated for exclusive use for the duration of the data transmission, even when the line is quiet. Although circuit switching is convenient for voice data such as telephone calls, it is very inefficient for other types of data communications. Digital data, such as a file being downloaded, is preferably transported over a packet-switched network. That is, a data file is segmented into multiple packets. The individual packets are then sent along whatever path(s) is (are) available to their destination where they are reassembled into the transmitted file.

Historically, telecoms only had to transport voice traffic. Data traffic came along much later, and input/output devices were developed to interface data sources with telecoms' legacy networks. By the mid-to-late eighties, telecoms had developed the practice of maintaining distinct parallel networks for voice and data. The voice networks remained circuit switched. The data networks were packet switched. In the early nineties, the first efforts began to converge network switching to the packet switching model.

In the early nineties, telecommunication engineers began developing mechanisms for connecting the separate voice and data networks to a common SONET ring. SONET (as well as SDH, the standard widely used outside of North America) permitted multiple services based on Time Division Multiple Access (TDMA) to be multiplexed from lower-speed (e.g., voice) circuits into tributaries in the SONET hierarchy.

Packet traffic was often carried using Frame Relay or Asynchronous Transfer Mode (ATM) systems. The tremendous capacity available over a SONET/SDH interface made it attractive to then transport the traffic between ATM or Frame Relay nodes over SONET/SDH. Data traffic and voice traffic could be carried over the same physical network by provisioning a portion of the capacity to voice traffic and the remainder to data traffic.

SONET has long been the transport network workhorse and is a proven, reliable technology. Because SONET is a synchronous TDM network, it also offers predictable low latency and excellent physical-layer capacity utilization. These inherent qualities of SONET should be extended to the customer in order to economically support revenue-generating Quality of Service options.

A criticism of SONET-based solutions has been that combining IP with SONET is expensive and cumbersome at the network edge. In response to this, technologies lacking protection switching, such as Gigabit Ethernet, have been proposed for metro networks. However, it is not SONET that is inefficient, but rather the attempts at layering legacy asynchronous LAN technologies onto SONET. Since SONET was originally intended for circuit-switched constant-bit-rate (CBR) traffic, the correct approach is to design SONET IP transport systems from the ground up in order to effectively utilize SONET for packet transport. If done correctly, such a system will retain some of SONET's inherent qualities to economically offer CBR and other service classes.

In spite of this criticism, the SONET market continues to grow. Carriers are satisfied with the reliability of SONET and by the opportunity to increase capacity using DWDM. In the metro area, however, DWDM is expensive and service providers will likely continue to use only TDM for the foreseeable future. Additionally, there is an abundance of dark fiber in the metro area, which will remain dark until cost-effective solutions become available. An interesting aspect is that a significant portion of the dark fiber is in rings having relatively high dispersion, making it unsuitable for Gigabit Ethernet, but quite attractive for OC-3 and possibly OC-12 solutions.

Ethernet is by far the most pervasive LAN technology and the increase in Ethernet speeds has made it attractive to consider using Ethernet beyond the LAN. Although Gigabit Ethernet has made a foray into the metro area, many service providers prefer a SONET-based solution because of their familiarity with SONET and because existing fiber has been laid in rings, making it unsuitable for star-connected Ethernet topologies.

Packet over SONET (PoS) is essentially the transport of IP using PPP and HDLC over SONET. The PPP stream is octet-aligned with the SONET frame but PoS otherwise treats the SONET payload as an octet stream. It therefore requires HDLC frame synchronization on the octet stream.

Additionally PoS uses SONET as a point-to-point medium, i.e., each link between PoS nodes requires a separate SONET path, which is usually realized using standard SONET provisioning mechanisms. For example, if we require a physical (or virtual) bi-directional mesh between four PoS nodes where the mimmum link capacity is STS-3c, we require twelve STS-3c channels. Although this gives us a total link capacity of nearly 2 Gb/s, the maximum data transfer rate between one node and any other node is just 155 Mb/s! All data and only data on the assigned STS-3c interface is received by the PoS node and then further processed by an attached IP router. Even if the PoS node is a card inside of an ADM, it cannot utilize the capacity in other STS-3c channels even if the other channels currently carry minimal traffic. Also, PoS uses standard SONET redundancy and protection mechanisms, which requires a 100% protection capacity that is not used unless there is a failure.

Asynchronous Transfer Mode (ATM) was introduced as the ultimate transport mechanism. Its small, fixed-size frames offer low latency and reasonably straightforward hardware implementation of switching fabrics. An ATM cell has a 5-octet header, resulting in an overhead of about 10% just for the header. But when used for IP transport, the overhead increases dramatically, especially for small IP packets that get segmented across ATM cells. Nearly all IP packets need to be segmented for ATM transport and are re-assembled at the destination.

ATM is a connection-oriented technology that requires path setup/tear-down for even the smallest transient data transfers. ATM's small header size necessitates this connection- oriented paradigm. The address space available using ATM's NPI and NCI is just a fraction of that available using IPv4 and TCP. At the dawn of ATM, this was considered a reasonable solution. The big advantage of ATM's connection-oriented services is that it provides a suitable vehicle for Quality of Service (QoS) because capacity can be dedicated during path setup.

However, some of the original technological limitations behind the ATM paradigm have evaporated: modern content-addressable memories (CAMs) and network processor chips eliminate the need for ATM's tiny address space and connection-oriented paradigm when carrying packet traffic.

Resilient Packet Ring (RPR) addresses many of the shortcomings of PoS, such as its poor total link capacity utilization caused by provisioned point-to-point links. With RPR, the nodes share a high-capacity medium so that link utilization is greatly improved. Each node has two IEEE 48-bit MAC addresses (an address on each side of the node that is used for both the working and protection rings). Using its two MAC addresses, each node can extract traffic that is destined to it. Similarly, each node can send packets having variable length to any other node on the shared ring by addressing one of the interfaces on the destination node.

RPR also uses destination stripping: the traffic is extracted at the destination node. This allows the link capacity between nodes to be reused after traffic has been stripped. This further increases the ring capacity utilization when compared to the source stripping used in traditional SONET. With source stripping, traffic inserted at the source always circulates around the entire ring back to the source, even though it has already been read by the destination node. RPR nodes maintain two sets of traffic queues, one for high priority traffic and the other for low-priority traffic. High-priority traffic is sent first and therefore must never be over-subscribed. To provide reliable service in the event of a protection switch, high-priority traffic should not exceed the capacity of one ring. For low-priority traffic, the nodes run a distributed fairness algorithm called SRP-fa so that each node gets its fair share of the capacity for low-priority traffic.

And, unlike PoS, the capacity in the protection ring can be used concurrently with the working ring. This effectively doubles the available capacity. In the event of a protection- switching event, the capacity is reduced to that of a single ring.

RPR has been designed as a media-independent MAC-layer protocol. To this end, it provides its own sub-50 ms protection-switching mechanism. This protection switching is optional. And, although it is media-independent, it is normally used only with SONET/SDH, which means that in actual implementations, there is a wasted layer of protection switching.

It is important to note that RPR, as a native protocol, cannot be used to interconnect rings. The current method of interconnecting rings is to use multiple RPR cards inside of a router and to forward traffic between the cards using multiple protocol layers, such as MPLS tunneling. When compared to the native switching mechanism disclosed here, using tunneling is inefficient and also compromises QoS and adds latency.

RPR has been known as Spatial Reuse Protocol and as Dynamic Packet Transport. It is currently standards-tracked as IEEE 802.17.

Although RPR represents an improvement for packet transport over SONET, there are still issues that need to be addressed in the progression of solutions for IP transport over synchronous networks. These issues can be examined by further considering SONET.

Firstly, existing methods for transporting IP over SONET treat the SONET payload as a stream of octets, essentially ignoring the SONET framing. RPR and PoS need to subsequently perform frame synchronization on the octet stream, which requires overhead bytes and computational effort, even though SONET has already performed a framing operation. They also need to buffer variable-length packets for add, drop, and forwarding. Supporting long variable-length packets also results in increased latency and packet jitter in PoS and RPR networks.

SONET ADMs readily switch data channels from one ring to another without undergoing protocol conversion or other costly processing whereas PoS and RPR require that packets pass through a router when they move to another ring.

SONET has fast, proven protection switching. This is exactly what is needed to provide high availability. There is no need to invent new mechanisms or provide overlaid alternatives. For example, RPR was designed to be media independent and therefore has its own Intelligent Protection Switching. But, to date, it is only used with SONET, which already has protection switching.

All of these issues are resolved by the current invention. The invention is not media independent, it is designed explicitly for SONET/SDH systems, thereby reducing costs and providing a standard, proven protection-switching mechanism. The invention is optimized for the transport of IP traffic, but this does not preclude carrying other types of traffic such as combining TDM transport with packet traffic. It also has efficient, hardware-supported QoS and has a low-latency native switching mechanism for forwarding traffic from one ring to another without additional protocol overhead. This helps it to provide low-latency, low-jitter transport, which is essential for interactive services such as voice and videoconferencing. Disclosure of the Invention

According to one aspect of the invention, a network node for transmitting and receiving data over a hierarchical interconnected network is provided, said network node comprising a method for assigning a segmented Media Access Control address, wherein the number of bits used for each address segment can be different, and a method and apparatus for decoding said segmented MAC address in a received data frame where each said address segment is independently evaluated and the results from said evaluations are logically combined to determine the path to the destination node indicated by said MAC address.

Illustratively according to this first aspect of this invention, said method for assigning a segmented Media Access Control adddress wherein the number of bits used for each address segment can be different includes dynamically assigning a segmented Media Access Control (MAC) address during network configuration wherein the number of bits used for each address segment can be different.

Illustratively according to the first aspect of this invention, the method and apparatus further includes said segmented Media Access Control address indicating the location of the network node within the hierarchy of said interconnected network.

Illustratively according to the first aspect of this invention, the method and apparatus further includes a method and apparatus for evaluating a Destination Area Code and, if said Destination Area Code is different from the Area Code for the current network node, forwarding said data to the network having said Destination Area Code. Illustratively according to this aspect of the invention, permitting the number of bits used for each address segment in said segmented Media Access Control address to be different in networks having different Area Codes.

Illustratively according to the first aspect of the invention, the method and apparatus further includes logically combining the results from said evaluation of the MAC address segments with the result from the evaluation of a Multicast Group Number and using this combined result to direct multicast or broadcast data traffic to destination nodes in one or more networks that are within the same hierarchy as the source node.

Illustratively according to the first aspect of this invention, the method and apparatus further includes decoding a protocol header containing a Multicast Group Number and and a Destination Area Code wherein said Multicast Group Number and said Destination Area Code are independently evaluated and the results from said evaluations are logically combined and used to direct multicast or broadcast data traffic to destination nodes in one or more networks that are within the same hierarchy as the source node or to destination nodes within different hierarchies from the source node.

According to another aspect of the invention, a method and apparatus are provided for decoding a protocol header containing a Multicast Group Number and a Destination Area Code wherein said Multicast Group Number and said Destination Area Code are used to direct multicast or broadcast data traffic to destination nodes in one or more networks that are within the same hierarchy as the source node or to destination nodes within different networks from the source node.

According to another aspect of the invention, a method and apparatus are provided for decoding a protocol header containing fields indicating a Destination Area Code and a Destination Media Access Control (MAC) address where said Destination Area Code and said Destination MAC address are independently evaluated and the results from said evaluations are logically combined and used to direct unicast data traffic within an interconnected network or to direct said data traffic between interconnected networks.

According to another aspect of the invention, a method and apparatus are provided for decoding a protocol header containing a Multicast Group Number and a Source Media Access Control (MAC) address where said Multicast Group Number and said Source MAC address are independently evaluated and the results from said evaluations are logically combined and used to direct multicast, local broadcast, or global broadcast data traffic within a interconnected network or to direct said data traffic between interconnected networks.

According to another aspect of the invention, a method is provided for generating decoding tables wherein each decoding table has a segmented Media Access Control address, a Destination Area Code, or a Multicast address as inputs and the output from said decoding tables are logically combined and used to direct data traffic within an interconnected network or to direct data traffic between interconnected networks.

Brief Description of the Drawings

Fig. 1 is a schematic illustration of a Hierarchical Ring Network;

Fig. 2 illustrates the assignment of addresses to nodes within a Hierarchical Ring Network;

Fig. 3 illustrates the contents of a unicast header and the contents of a multicast header;

Fig. 4 illustrates the use of segmented addresses within a Hierarchical Ring Network;

Fig. 5 is a high-level schematic illustration of an embodiment of a network node;

Fig. 6 is a schematic illustration of the signal flow and logical blocks for making switching decisions;

Fig. 7 illustrates a decision table for making switching decisions for unicast data traffic within a network node;

Fig. 8 illustrates a decision table for making switching decisions for multicast and global broadcast data traffic within a network node;

Fig. 9 illustrates a decision table for making switching decisions for local broadcast data traffic within a network node;

Fig. 10 illustrates a sub-network that constitutes part of of a Hierarchical Ring Network where multiple hierarchical ring systems are interconnected;

Fig. 11 illustrates the MAC address table for a particular first node (10.6);

Fig. 12 illustrates the Area Code table for a particular first node (10.6);

Fig. 13 illustrates the Area Code table for a particular second node (10.9) for the case when data arrives from the major ring;

Fig. 14 illustrates the Area Code table for a particular second node (10.9) for the case when data arrives from the minor ring;

Fig. 15 illustrates the Multicast Group Number table for a particular first node (10.6); Fig. 16 illustrates the MAC address table for a particular second node (10.9) for the case when data arrives from the major ring; and

Fig. 17 illustrates the MAC address table for a particular second node (10.9) for the case when data arrives from the minor ring.

Detailed Description of an Illustrative Embodiment

Fig. 1 illustrates the structure of the suggested hierarchical ring-based network system (abbreviated as HRN hereinafter). In this example configuration of a network, there are four hierarchical levels with each level consisting of one or more rings. In this example, each node on a ring is therefore assigned an address containing four fields where each field corresponds to a level of the hierarchy. Fig. 2 lists the corresponding MAC addresses for the nodes in the network of Fig. 1 As can be seen from these figures, each node address within the hierarchical network is directly related to the location of the ring containing the node. For example, since node 1.2 resides on the ring of the highest hierarchical level, the first field (the leftmost number in the dotted quad notation used in Fig. 2) in its MAC address is simply the number that has been assigned to this node on its attached ring 1.30. Although node 1.2 is attached to two rings, it is assigned a MAC address only on ring 1.30. A MAC address on the subordinate ring (hereinafter sometimes subring) 1.31 is not assigned for this node.

Nodes 1.3, 1.4, and 1.5 are attached to ring 1.31, which is extended from ring 1.30 through node 1.2. Hence, the first field in the MAC address of these nodes will be the same as that of their parent node (node 1.2). This inherited field value in the MAC addresses of all the nodes on ring 1.31 is designated as the ring number of this ring. The second field in the MAC address of nodes 1.3, 1.4, and 1.5 is the number that the node is assigned on ring 1.31.

Similarly, since node 1.14 is attached to ring 1.34, which is extended from ring 1.31 through node 1.5, the first two fields are the same as the first two fields of its parent node 1.5 and these two inherited fields together form the ring number of ring 1.34. Again, the third field in the MAC address of node 1.14 will be the number that this node is assigned on ring 1.34. Finally, since node 1.29 is attached to ring 1.43, which is extended from ring 1.34 through node 1.14, the first three fields of its MAC address are again the same as the first three fields of the MAC address of node 1.14, and they form the ring number of ring 1.43. The fourth field of the MAC address of node 1.29 is the number that this node is assigned on ring 1.43.

In an HRN system, it is the frame headers that help enable the system's high efficiency data frame transmission capability. When a node receives a data frame in an HRN system, the node inspects the frame header to determine the required processing for the frame. Based on the header information, the node may, for example, drop or forward the frame, or it may switch the frame to a neighboring ring.

Fig. 3 shows examples of frame headers that may be used in a HRN system. These headers are an improvement on the ones that have been described in the encapsulation protocol presented in the patent application of PCT/USO 1/26004. These new headers contain several novel components including a Destination Area Code 3.10 and segmented MAC address fields 3.12 , 3.18. The header includes two major parts: the hardware-controlled header and the software-controlled header. In the preferred embodiment, the hardware- controlled header contains two bytes of data and the contents of these two bytes are processed only by the hardware of a node in the HRN system. Inside this header, the Allocated Bit 3.3 is used to indicate the existence of valid data in the data frame following the header. If the Allocated Bit 3.3 is set, the node will further process the header. Otherwise, the header and data frame will either be ignored or used by the node to send data to another node.

The Ring Indicator Bit 3.4 is used to indicate from which ring the received data frame is coming, and this bit is useful when each ring shown in Fig. 1 is actually a dual ring. For example, in an ordinary SONET system, the nodes on each ring are interconnected using a dual ring that is composed of two physical rings: a working ring and a protection ring. In traditional SONET systems, the purpose of the protection ring is to serve as a backup when the function of working ring is disrupted. The single byte Schedule Counter 3.5 can be used for traffic scheduling or flow control. In the current embodiment, the remaining six bits in the two-byte hardware-controlled header are reserved for future purposes. As to the software-controlled part of header, all of its contents are handled by specialized hardware or by software run by the CPU of a given node in the preferred embodiment of the HRN system. In Fig. 3, block 3.6 shows the contents of the headers used when sending unicast data and block 3.7 is the contents used when sending broadcast or multicast data. The major differences in the contents between these two types of headers are between the Destination Area Code 3.10 and the Multicast Group Number 3.16, and between the Destination MAC Address 3.12 and the Source MAC Address 3.18. Also, the values of the Mode attributes 3.11 and 3.17 in both cases are different. The other attributes, such as the Hop Limit, 3.8 and 3.14, Priority, 3.9 and 3.15, and CRC, 3.13 and 3.19, are the same in both types of headers.

The Hop Limit attribute 3.8 and 3.14 is used to indicate the maximum number of times that a frame is allowed to travel through certain types of nodes. In the preferred embodiment, these nodes are the ones that switch the data frame over to a neighboring ring. Before sending out a data frame, the CPU in the source node of a data frame will assign an initial value to the Hop limit attribute. Whenever this data frame is switched to a neighboring ring by a node, the value of Hop limit is decreased. Once the value of the Hop limit has been reduced to zero, the data frame is discarded. The Hop limit prevents incorrectly addressed data frames from circulating through the network.

The purpose of Priority attribute 3.9 and 3.15 is to provide information about the required transport priority and other Quality of Service parameters for each data frame. Depending on the value of the Priority attribute, each data frame will have specified priority in the queues of the nodes along its path of travel, which supports different levels of Quality of Service. Data frames with higher priority levels will be transmitted in preference to those with lower priority levels.

The purpose of the CRC (Cyclic Redundancy Check) bytes 3.13 and 3.19 is to allow for the detection of data errors induced during the transmission of the data frame.

The function of the Mode attributes, 3.11 and 3.17, is to indicate the type of the data frame. When its value is 11, then the data frame contains unicast data, whereas when the value is 10 or 00, the data frame contains multicast or global broadcast data. If the value is 01, then the data frame contains local broadcast data. In the preferred embodiment, global broadcast data is forwarded to all the nodes within an HRN system whereas local broadcast data is only forwarded to nodes on the same ring as the source node of the data.

The Destination Area Code 3.10 is an extension to the node MAC Address. This attribute is used as an identification number for a destination MAN (Metropolitan Area Network) in an HRN system. In an HRN system that contains several interconnected HRN MANs, every MAN system is assigned its own Area Code, and the function of this Destination Area Code is very similar to that of the country code or area code in an ordinary telephony system. The Area Code simplifies interconnecting multiple MANs.

The Destination Area Code 3.10, when used in conjunction with the Destination MAC Address 3.12 is a novel and powerful method for transporting data traffic within and between interconnected networks. Similarly, using the Multicast Group Number 3.16 with the Source MAC Address 3.18 provides a novel and powerful method for efficiently handling multicast and broadcast traffic.

The MAC Address 3.12 and 3.18 is the MAC address of a node for a data frame in an HRN system. Although the methodology for assigning MAC addresses to the nodes in an HRN system has been previously discussed, one should note that the length of each field in a node MAC address need not be constrained to one byte (or any other length) and also that the number of fields depends on the number of levels in the network hierarchy. Instead, the choice of the data length of the fields in a node MAC address of an HRN system is quite flexible. And, since the Area Code 3.10 is independent of the MAC address, networks having different Area Codes can be intercom ected without needing to consider the allocation of bits in the MAC address of the other network.

The length of each field (or segment) in the MAC address may be changed according to the deployment strategy of each individual network. For example, when the required number of levels is different from four, the length of the fields in the MAC Address can be assigned accordingly. In a typical hierarchy as shown in Fig. 1, there is a larger number of nodes at the lower level of the hierarchy and, therefore, the optimum length of the address field for the lower level would likely be greater than the length of the address field for the topmost level. In this way, the allocation of node MAC Address fields is flexible and can be selected to best serve the needs of a particular HRN system. It is important to note that this flexibility is dynamic: If the topology of the network is changed, the number of bits assigned to each field of the MAC address can be changed. Additionally, the updating of the MAC address format can be accomplished remotely using a network management system.

Fig. 4 shows a flexible method for assigning the node MAC addresses as the network grows. In this example, a one-byte MAC Address is used to simplify the demonstration. Unlike the network shown in Fig. 1 and Fig. 2, where both the number of network levels and the length of each field of the node MAC addresses are fixed at the time of initial deployment, in Fig. 4, the number of network levels and the field length for each level are not determined beforehand. Instead, they are determined after the network is operational and a clearer picture about the actual demands has emerged. This allows for flexibility in the allocation of address bits to each address field so that the bit allocation can be decided as the network is expanded.

In Fig. 4, the length of each field of node MAC addresses is selected as required by the expanding network topology. The MAC address is filled with each address field starting from its left-hand side. During the deployment of a new network level, it is only when a new subring is connected to an existing ring that the field length for this network level needs to be determined. The length of the new field is determined after estimating the maximum number of nodes that will need to be accommodated on any ring at this new network hierarchy level.

For example, the network shown in Fig. 4 is constructed starting with the topmost ring 4.1. It is decided to allocate a single bit for the MAC address field corresponding to this topmost network level and set this bit to 1 for ring 4.1. By allocating one address bit for this level, it is possible to add another ring at the same network level as ring 4.1 at some time in the future. If this future ring were to be added, the one-bit address field for its topmost network level would be set to 0.

The topmost ring 4.1 contains four nodes 4.7, 4.8, 4.9, and 4.10. At this time, it is decided to allocate two MAC address bits for this network level. Two bits can discriminate between at most four nodes, so no more nodes could be added to ring 4.1 in the future unless the bit allocation for this level was increased. The binary MAC addresses chosen for these four nodes are 10000000, 11000000, 10100000, and 11100000, respectively.

If we now consider a particular ring 4.2 at the next lower level, we see that its ring number 101 is identical to the three leading bits of the MAC address of the node 4.9 that connects it to the higher-level ring 4.1. The MAC address of each of the nodes 4.9, 4.11, 4.12, and 4.13 that are connected to this ring 4.2 start with the three-bit ring number 101. Since there are four nodes on the ring 4.2 we can allocate two bits to this address field (being the fourth and fifth bits starting at the leftmost bit) resulting in the four binary MAC addresses being 10100000, 10110000, 10101000, and 10111000 for the four nodes, respectively. Note that, since node 4.9 connects the ring 4.2 to the higher-level ring 4.1, its newly-allocated fourth and fifth bits are 0.

Similarly, when another subring 4.5 is added, its ring number is identical to the five leading bits of the node 4.11 that connects it to the higher-level ring 4.2. At this stage, we could decide to allocate the remaining three bits of the 8-bit MAC address to this level of the hierarchy, allowing up to eight nodes on the ring 4.5. Since there are currently three nodes on the ring 4.5, five more nodes could be added to the ring 4.5 in the future without changing the MAC address format.

The Source MAC address 3.18 is used to indicate the MAC address of the source node when receiving broadcast or multicast data. As in existing IP multicasting, the Multicast Group Number 3.17 is used to identify a particular multicast data stream. Each node in an HRN system may be programmed to drop, switch, and/or pass multicast data frames after examining the Group Number of the received data frames. As in IP multicast, this decision depends on whether the current node or nodes connected to the current node subscribe to a particular multicast data stream.

A HRN system generally includes three different types of nodes. The first type of node is the Simple Node, which is located only on a single ring and cannot be used to interconnect rings. Node 1.26 in Fig. 1 is atypical example of this type of node. Any data frame entering this type of node will either be dropped to the node or passed along the ring. The Simple Node is also allowed to add data onto the ring if it has been allocated a portion of the ring's data transport capacity.

The second type of node is located at the intersection of two adjacent rings that have the same hierarchical levels, such as nodes 1.17 and 1.20 of Fig. 1. For this type of node, in addition to the regular data frame pass, drop and add capabilities, data frames entering this type of node may sometimes need to be switched from one ring to another. For this type of node, data frame switching will happen only when the destination node for a unicast data frame is located on an adjacent ring at the same level in the hierarchy or on a subring of this adjacent ring. When a data frame is switched to the adjacent ring, the node that interconnects the two rings transfers the data frame from the source ring into its transmission buffer for the adjacent ring. However, to prevent unnecessary traffic, multicast data is not switched to the adjacent ring. Because this type of node connects two rings at the same level of the hierarchy, it always possesses two MAC Addresses in an HRN system.

The third type of node connects two rings at different hierarchical levels within an HRN system. Nodes 1.3 and 1.4 in Fig. 1 are typical examples of this type of node. The function of this type of node is very similar to that of the second type of node. Like the second type of node, it has the capability of dropping, adding and passing received data frames and it can switch the received data frame to the neighboring ring. Because of this switching capability, the second and third types of nodes are referred to as Switch Nodes. The behavior of the third type of node differs from that of the second type of node in two ways. Firstly, when a multicast data frame is received, this node makes a copy of the received data frame so that it transmits it to both rings to which this node is connected. The second difference, as illustrated in Fig. 2, is that a single MAC address is sufficient to identify the node on both of the rings to which it is connected.

In addition to the capabilities described for each of the three node types, every node in an HRN system can be a Link Node if required. Link Nodes serve to interconnect two MANs. One of the simplest ways of linking two MANs is through a provisioned SONET channel. Each Link Node may have one or more links established where each link is dedicated to the interconnection of two specific MANs. Since each MAN has its own set of hierarchical addresses, an area code 3.10 in the header of Fig.3 is used to specify a particular destination MAN for unicast data frames. In addition to the general node functions as stated earlier, each Link Node has the capability to forward data frames that are destined to a specific MAN that is reachable through the Link Node.

The data frame processing requirements and forwarding latency through the nodes depends on the type of data forwarding. For example, the time required for passing a data frame tlirough a node on its original ring is normally much less than that for switching it to an adjacent ring.

Fig. 5 shows one possible functional block diagram for the processing of data frames in the nodes of an HRN system. For clarity, only a few of the control signals are shown (as narrow lines). As shown in this figure, upon receiving a data frame, 5.1, the Decoder 5.3 decodes the header of the data frame and the data frame is immediately transferred to one of the FIFOs 5.4,5.5,5.6. FIFO 5.4 is used for passing the data frame along the same ring that it arrived on; FIFO 5.5 is used for dropping the data frame to the CPU 5.11 of this node; and FIFO 5.6 is used for switching the data frame to the adjacent ring. Since header decoding is implemented in hardware, the decoding time is mainly dependent on the size of the header. Thus, header decoding can be completed shortly after the header bytes arrive at the node. Once the header has been decoded, if the data frame needs to be passed along the same ring that it arrived from, the data frame in FIFO 5.4 will be forwarded to Latch 5.7 and is transmitted along the original ring by Transmitter 5.8. If header decoding indicates that the data frame needs to be switched to another ring, FIFO 5.6 will accumulate the entire data frame and forward it to Latch 5.21 where it is queued for transmission to the adjacent ring 5.21 through Transmitter 5.20.

Alternatively, if the data frame is destined to this node, then FIFO 5.5 will accumulate the entire data frame and forward it to the CPU 5.11 for further processing. Note that the CPU 5.11 is also capable of adding data to the rings if necessary and that the CPU may be connected to other systems, such as a LAN, that are not shown in the figure. If the data frame has been removed (or stripped) at this node, the node can then mark the data frame as being empty (available for re-use). This empty data frame can then either be used to transmit a data frame containing new data from the CPU or, if the node does not have any data to transmit, an empty frame can be forwarded along the ring for use by some other node along the ring.

The time required to process data frames depends on the type of handling needed. For example, assuming that a ten-byte header and 256-byte data frame are used in an HRN system, the time required for transferring a pass-through data frame from the node's receiver to the latch of the node's transmitter will take approximately 20 byte clock periods. This is because the decision to forward the frame can be made before the entire data frame arrives. With the appropriate timing of all nodes on the same ring, it is possible to use "cut-through" forwarding. Cut-through forwarding is where bytes are sent to the output transmitter before the entire input data frame has been received. Cut-through forwarding considerably reduces the forwarding latency through the node.

In comparison, the time needed for switching a data frame to a different ring could take hundreds of clock periods since it may be necessary to receive the entire input frame before transferring it to the other ring. The reason for buffering these frames is that frame synchronization on one ring can be different from the frame synchronization on the other ring. Thus the data frame processing time for forwarding a data frame onto another ring can be many times longer than simply passing the data frame along the ring that it arrived upon. It may also be necessary to queue data frames that are destined for an adjacent ring while waiting for an empty frame on the adjacent ring.

The total latency for data frame transmission through an HRN system is determined by the total time taken doing frame-pass operations (along the same ring) and frame-switch operations (to an adjacent ring). Based on the fact that the frame-switch process takes much longer time than the frame-pass process does, the dominant factor in determining the total latency is the number of frame-switch nodes that a data frame has to traverse. In a typical HRN system, the latency caused by traversing frame-pass nodes is relatively insignificant.

Thus, the more frame-switch operations that frames have to go through, the greater the total latency. Consequently, it can be concluded that the fastest path for data frames to travel from a source node to a destination node in a HRN is the one that requires the least number of frame-switch operations.

Revisiting Fig.l, we see that nodes 1.28 and 1.29 are on adjacent rings 1.42 and 1.43; hence the fastest path between these two nodes is to go through the frame-switch node 1.20. Since the host rings, 1.43 and 1.41, of nodes 1.29 and 1.27 are not adjacent; there are two possible routes for traffic from node 1.29 to node 1.27. One route is to copy the frame from ring 1.43 to the upper level ring 1.34, through node 1.14, then copy it down again, through node 1.12, and onto ring 1.41, where node 1.27 is located. The other route is to copy the data frame from ring 1.43 to ring 1.42 and then to ring 1.41 , through nodes 1.20 and 1.19, and then deliver it to the destination node 1.27. Both routes go through two frame-switch nodes, and thus are likely to have similar latencies. If the two communicating nodes are further apart but still belong to the same sub-network, such as in the case of nodes 1.29 and 1.26, the fastest route will be to copy the data frame from its source ring 1.43 directly up to ring 1.34, and then copy (switch) the data frame onto ring 1.40, where the destination node 1.26 is located. Similarly, when two nodes are farther apart in the network, such as in the case of nodes 1.29 and 1.25, the frame is copied from ring 1.43 to ring 1.31, passes through ring 1.34, and is then copied through ring 1.33 and onto ring 1.39.

From the preceding description, we see that, except for the case where one node is sending data to another node that is located on an adjacent ring or on a subring, the fastest path (the one having the least number of frame-switch nodes) is the one that goes up from the source node to the lowest level common parent ring for both nodes and then descends to the ring where the destination node is located. Based on this aspect of the invention, simple switching mechanisms can be developed for rapidly transporting data frames in the HRN.

Fig. 6 is a typical functional block diagram of the header decoding and traffic control procedures for the data frames of the HRN system. As shown in this figure, a four-byte node MAC address 6.1 is implemented in this example. To fully decode a 32-bit (four-byte) MAC address using a traditional generalized approach, a CAM table of a size close to 4 gigabits is needed. But, in this example, the four-byte MAC address is divided into four separate bytes, and each byte is mapped into a corresponding CAM table having a size of 256 bytes. The number of bits in each byte can be less than the usual eight bits since each bit in the byte is used to generate one of the intermediate control signals that are described below. Therefore the overall size of the integrated MAC Address CAM table is only 1024 bytes, which is far less than the size of the CAM tables used in traditional network elements. Hardware requirements are simplified since these small CAMs can be easily implemented with ordinary RAM (Random Access Memory). The use of a segmented address having multiple independent address fields is an important aspect of this invention and this aspect results in a considerable reduction in the size of the required CAM tables when compared to traditional address decoding methods. Of course, the required size for each CAM tables is dependent on the number of bits allocated to each field in the MAC address.

As shown in Fig. 6, after applying the Destination MAC Address 6.1 of the incoming data to the MAC address CAMs 6.2, and then performing logic functions 6.3 on the outputs from these four separate CAM tables, three major intermediate control signals are generated: the isThis signal 6.7, the isRing signal 6.8, and the isOther signal 6.9. These three signals are combined with other intermediate control signals, such as the Path signal 6.4, the Mode signal 6.5, the Error signal 6.6, the isArea signal 6.10, and the isGroup signal 6.12, to form a complete set of input signals to the look-up table 6.21.

The value of the isThis signal 6.7 is 1 when the host node is the destination of the received data frame. If the value of the isRing signal 6.8 is 1 then, if the host node is at the intersection of two different level rings, the destination of the received data frame is either on the lower-level ring of the host node or on one of the subrings connected to this lower-level ring. In the case where the host node is at the intersection of two equal-level rings, a value of 1 for the isRing signal 6.8 means that the destination of the current data frame is on a same- level neighboring ring or one of the subrings of the neighboring ring.

The isOther signal 6.9 is used to prevent the node located at the intersection of two equal-level rings from needlessly copying a data frame from the lower level ring to the upper level ring. This signal is useful when the destination of the received data frame is either on the same level neighboring ring or its subring because, as discussed earlier, the shortest path for sending data frame to nodes on the neighboring ring or its subrings is to go through the intersection node that connects the current ring and the same level neighboring ring instead of sending the data frame through higher-level rings.

The two-bit Path signal 6.4 indicates both the location of current node and the location of the node that is the source of the current data frame. In the preferred embodiment, when the value of the Path signal is 00, this node is located on the intersection of two rings having different hierarchical levels and the data frame is from the ring having the lower hierarchical level. When the value of the Path signal is 01, this node is at the intersection of two rings, but the data frame is from the higher hierarchical level ring. In the case where the value of the Path signal is 10, the current node is at the intersection of two rings having the same hierarchical level, and the data frame is coming from the adjacent ring to its left (hereinafter sometimes major ring). Finally, if the value of the Path signal is 11, then the current node is again at the intersection of two same-level rings, but the data frame is coming from the adjacent ring to the right of the current node (hereinafter sometimes minor ring).

The two-bit Mode signal 6.5 is used to distinguish unicast, multi-cast/global broadcast, and local broadcast data frames. In the preferred embodiment, when the value of the Mode signal is 11, the current data frame is a unicast frame. If the value of the Mode signal is *0, where * can be either 1 or 0, then the current data frame is a multicast or global broadcast frame. And, if the value of the Mode signal is 01, then the current data frame is a local broadcast frame. Local broadcast data is only broadcast within the single ring where the source node of this data frame is located.

The Error signal 6.6 is used to indicate errors that are detected by CRC calculations, Hop Limit exceeded conditions, etc. This Error signal has the highest priority among all of the intermediate control signals. When an error occurs, the CPU is notified and will take appropriate action such as notifying other nodes in the network or notifying a network management system.

Applying the Destination Area Code 6.15 of the received data frame to the Area CAM table 6.14 generates the is Area signal 6.10. It is used to indicate if the destination node for the received data frame is located within the current MAN. When the value of this signal is 1, the destination of the received data frame is within the current MAN system; otherwise the destination node is located within a different MAN.

Applying the Multicast Group Number 6.17 of the received data frame to the Group CAM table 6.16 generates the isGroup signal 6.12. When this signal is 1, the data frame will be forwarded to the CPU of the current node.

In the preferred embodiment, the Area CAM table and the Group CAM table support 16-bit input values and are therefore 64-kilobits in size. All of the CAM tables in Fig. 6 can be configured through the CPU 5.11 of Fig. 5 when the network is initiated, when a new node is installed, or the network configuration is changed.

All of the intermediate control signals mentioned above are fed into the look-up table 6.21 to generate three traffic control signals: the enDrop signal 6.18, the enPass signal 6.19 and the enCopy signal 6.20. These three signals are used to determine how the received data frame will flow through the node. The enDrop signal enables the dropping of the data frame to the current node, the enPass signal enables the passing of the data frame along the same ring, and the enCopy signal enables the copying of the data frame to a different ring.

The look-up table 6.21 is based on the decision-making logic shown in Fig. 7, Fig. 8, and Fig. 9. Fig. 7 is for unicast data; Fig. 8 is for multicast and global broadcast data; and Fig. 9 is for local broadcast data. An asterisk anywhere in these tables represents a number that is allowed to be any value.

Fig. 10 illustrates a sub-network that constitutes part of a larger HRN system. In Fig. 10, the illustrated sub-network belongs to a MAN with an Area Code of 1159. In this figure, nodes 10.6, 10.7, 10.11 are switching nodes that connect two different level rings. Each of these nodes has a unique hexadecimal MAC address: 5000, 6000, and 5700, respectively. Node 10.9 is at the intersection of two equal-level rings and thus it has two MAC addresses: 5600 and 6800. Nodes 10.5, 10.8, 10.10 and 10.12 are Link nodes, which interconnect MANs having different area codes, and their node MAC addresses are 4000, 5400, 6900, and 5730, respectively. Nodes 10.13 and 10.14 are simple nodes that only drop or pass received frames and their MAC addresses are 5740 and 5750, respectively.

The MAC address CAM tables for node 10.6 are shown in Fig. 11. These tables show the input address range 11.9 and the corresponding output bits for Thisl 11.5, This2 11.6, isRing 11.7, and isOther 11.8. Because there are four bytes in the MAC address, there are table four tables 11.1-11.4 with the topmost table 11.1 corresponding to the first byte of the MAC address.

The MAC address of this node, 5000, is reflected in the Thisl column 11.5. In each column of this particular CAM table, each byte of the MAC address of an incoming data frame is mapped to a 256-bit table, and the output for each column is essentially derived by ANDing all the outcomes from each of the four bytes of the MAC address. Because node 10.6 has only one MAC address, all of the elements in the This2 column 11.6 are set to zero. The output that results from columns Thisl and This2 are ORed together to generate the isThis signal.

The isRing column 11.7 is designed to match all rings that are subordinate to node 10.6. Since the MAC address of node 10.6 is 5000, the MAC addresses of all nodes on the subordinate rings of node 10.6 must have a form of 5***, where each * is a number between 0 and 255 in decimal. As shown in the isRing column 11.7, all of the output bits from decoding the first byte are zero except when the input byte equals 5, which corresponds to the first byte in the node address 5000. In the remaining three bytes, all output bits are set to one to cover all possible subrings for the node.

The isOther column 11.8 matches nodes on neighboring subrings. In Fig. 10, the node 10.7 is on the same subring as the current node 10.6. Therefore, for node 10.6, the isOther output bit for the first octet of the MAC address is set to one.

The Area CAM table for node 10.6 is shown in Fig. 12. This table shows the input address range 12.6 and the output bit for each Area Code supported by the node. The input to this table is two bytes long with the first byte corresponding to table 12.1 and the second byte corresponding to table 12.2. These tables are used to match all of the Area Codes that are supported by the subordinate Link nodes of node 10.6, such as nodes 10.8 and 10.12. The Area Codes supported by node 10.8 are 312* and those supported by node 10.12 are 084* and 065* and therefore three columns are needed to identify these area codes. Column 12.3 corresponds to 312*, column 12.4 corresponds to 084*, and column 12.5 corresponds to 065*.

Fig. 13 and Fig.14 are the Area CAM tables for node 10.9, which is at the intersection of rings 10.2 and 10.3. Like Fig. 12, tables 13.1 and 14.1 are for the first byte of the Area Code and tables 13.2 and 14.2 are for the second byte. Fig. 13 is used for data frames that are received from the major (or left-hand side) ring and Fig. 14 is used for data frames that are received from the minor (or right-hand side) ring. The contents of Fig.13 match the area codes supported by Link node 10.10, and the matching values are 055* where * means any value between 0 and 255. Similarly, Fig. 14 matches the area codes supported by Link nodes 10.8 and 10.12; hence the contents of these tables are the same as for the tables in Fig. 12.

Fig. 15 contains the Group Number CAM tables for node 10.6 and is similar to the Area CAM tables of Figs. 13 and 14. It contains two single-byte tables: 15.1 and 15.2. In this example, node 10.6 accepts multicast data frames having group numbers 0402 and 0020, and these multicast group numbers correspond to column 15.3 and 15.4 respectively. The global broadcast frames are realized as a special type of multicast data frame having a group number of 0000 and this special group number is decoded using column 15.5. Every node in an HRN system can accept any broadcast data frames and therefore all nodes in an HRN system will have a column corresponding to 0000 in the Group Number CAM tables. Column 15.3 corresponds to 0402, column 15.4 corresponds to 0020, and column 15.5 corresponds to 0000.

Fig. 16 and Fig. 17 are the MAC address CAM tables for node 10.9. In each of these figures, there are four tables 16.1-16.4 and 17.1-17.4 corresponding to the four bytes of the MAC address. Fig. 16 is used for data frames that are received from the Major (left-hand side) ring 10.2, and Fig. 17 is used for data frames received from the Minor (right-hand side) ring 10.3. The content of the isRing column 16.5 of the tables of Fig.16 match the MAC addresses of the nodes that are located on ring 10.2 and its subordinate rings where the MAC addresses are of the form 5***, where * is any number between 0-255 in decimal. Similarly, the content of the isRing column 17.5 matches the MAC addresses of the nodes that are located on ring 10.3 and its subordinate rings where the MAC addresses are of the form 6***, where * is again any number between 0-255 in decimal. The Thisl columns, 16.6 and 17.6 have the same content that matches the MAC address 5600, and the contents of the This2 columns, 16.7 and 17.7, correspond to the MAC address 6800.

A few examples will be presented here to illustrate the working principles of these aforementioned CAM tables and their associated Decision-Making tables in Figs. 7 through 9. For example, when a unicast data frame destined to node 10.14 is received from the upper ring 10.1 by node 10.6, the resulting value of the Path signal is 01. This is because the MAC address of node 10.14 is 5750, and therefore in the MAC address CAM table of node 10.6, only the column for isRing will match this address, resulting in an output of one for isRing. All of the other columns, such as isThis and isOther, do not match this address and their outputs are all zeros. Because the area code of the received data frame is the same as that of the current MAN system and is not associated with other MANs, the output signal of isArea is zero as well. Based on the decision-making table of Fig. 7, these intermediate control signals result in the activation of the enCopy signal and the data frame is copied to the lower ring. On the other hand, if node 10.6 had received this data frame from the lower ring 10.2, results would have been derived from the CAM tables in a similar manner, except that the value of the Path signal is now 00 instead of 01. The result from the decision-making table activates the enPass signal, which causes the node to pass the received data frame along the lower ring without sending it to the upper ring.

When the destination of a data frame received by node 10.6 is one of the nodes that are on the subordinate rings of node 10.7 and if the data frame is received from the upper ring

10.1, then, after the mapping of the CAM tables, only the isOther signal will be 1 and all the other signals will have a value of 0. Consequently, the outcome from the decision-making table of Fig.7 will be the activation of the enPass signal and the data frame is passed along ring 10.1 toward node 10.7. However, if node 10.6 receives this frame from the lower ring

10.2, the outputs of the CAM tables will still be the same, but the outcome from the decision- making table will be to pass the received data frame along ring 10.2. In this case, once the data frame reaches node 10.9 from its left-hand side ring 10.2, the CAM table in Fig. 16 can be used to find that the value of the Path signal will be 10 (Major) and the resulting value of the isRing signal is 1 while all the other signals from the CAM table are 0. Based on the decision-making table in Fig.7, the enCopy signal on node 10.9 will be activated and the data frame will be copied to the right-hand side ring for further delivery. Similarly, if the data is received by node 10.9 from its Minor (right-hand side) ring 10.3 and is destined to a node that is on the left-hand side ring 10.2 or its subordinate rings, then the Path signal will be 11 (Minor), and the isRing signal will be 1 while the rest of the signals from the CAM table will be 0. In this case, based on the decision table of Fig. 7, the enCopy signal on node 10.9 will be activated and the data frame will be copied to the left-hand side ring for further delivery.

In the case where the destination of the data frame received by node 10.6 is not reachable through any of its subrings or rings at the same level in the hierarchy and the destination is not associated with any distant MAN systems that can be reached through the Link nodes subordinate to node 10.6, all values of the intermediate control signals from the CAM tables will be 0. Therefore, according to the decision-making table of Fig.7, the data frame is copied to the upper ring 10.1 for further delivery. On the other hand, if node 10.6 receives such a data frame from the upper ring 10.1 , then it will simply pass the data frame along the upper ring, in accordance with the result from the decision-making table.

If node 10.6 receives a data frame from the upper ring 10.1 and this data frame is destined to a distant MAN system which is accessible through one of the Link nodes that are located on the subrings of node 10.6, then isArea is set to 1 and all the remaining signals from the CAM table will be 0. Combining this with a Path value of 01 (Higher), the decision- making table of Fig. 7 results in the activation of the enCopy signal and the data frame is copied to the lower ring and continues to be forwarded toward its associated Link node.

For a multicast or global broadcast data frame, the MAC address attribute in its header contains the MAC address of the source node for the data frame (rather than the destination address) and a multicast group number (in place of the area code attribute). In this case, the value of the Mode signal is *0 and the decision-making table of Fig. 8 is used to generate the data control signals. When node 10.6 receives such a multicast (or global broadcast) data frame from the lower ring (i.e., the Path is 00) and, if the source MAC address coincides with this node's MAC address, i.e. isThis equals one, the data frame is simply discarded at this node. Otherwise, if the source node is one of the nodes that are subordinate to node 10.6, which implies that isRing equals 1 and isThis equals 0, this data frame will not only be passed to ring 10.2 but also copied to ring 10.1 for further distribution. Additionally, if the isGroup signal from the Group CAM equals 1, this data frame is dropped at the current node 10.6. On the other hand, if the source node is neither node 10.6 nor one of its subordinate nodes, the isThis and isRing signals are both 0 and the data frame is again discarded at this node.

If multicast (or broadcast) data is received from the upper ring 10.1 by node 10.6 and if the source MAC address is the same as that of node 10.6 (i.e., isThis equals 1) then, according to the table in Fig. 8, the data frame is copied to the lower ring 10.2 for further distribution and will be discarded from the upper ring 10.1. Otherwise, if the source node is one of the subordinate nodes of node 10.6 (i.e., isRing equals 1) the data frame will be discarded at node 10.6. On the other hand, if the source node is neither node 10.6 nor one of its subordinate nodes (i.e., both isThis and isRing are 0) then, in addition to passing the data frame along ring 10.1, node 10.6 will also copy it to the lower ring 10.2 for further distribution.

If node 10.9 receives a multicast (or global broadcast) data frame from the Major (left- hand side) ring 10.2 and if the source node MAC address is the same as that for node 10.9 (i.e., isThis equals 1) the data frame will be discarded at this node. If the source MAC address of the data frame is different from that of node 10.9, then, no matter where the source node is located, the data frame may be passed along the Major ring 10.2 again. However, it will also be dropped if isGroup equals 1, since this means the data frame is either a global broadcast data frame or a multicast data frame that is acceptable to node 10.9. However, if the data frame is received from the Minor (right-hand side) ring 10.3 and if the source MAC address is the same as that of node 10.9, the data frame will be dropped at this node. Alternatively, if the source MAC address of the data frame is different from that of node 10.9, no matter where the source node is located, the data frame will be passed along the Minor ring 10.3 and never be dropped at this node because a multicast (or global broadcast) data frame will always ' arrive at node 10.9 from both sides (i.e., from rings 10.2 and 10.3) and there is no need to drop it twice at the same node.

When the data frame is a local broadcast frame, which means that this broadcast is only for the same ring where the source node is located, the value of the Mode signal will be 01 and the decision-making table of Fig.9 will determine that, no matter where a host node is located, if the source MAC address of the received data frame is the same as that of the host node, the data frame will be discarded whenever it reaches the node. On the other hand, if the source MAC address of the data frame is not the same as that of the host node, the data frame will be both dropped to the node and passed along the ring.

Cited References

Bellcore Publication GR-253-Core "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria", January 1999.

Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, IETF RFC 1661, July 1994.

Malis, A. and W. Simpson, "PPP over SONET/SDH", IETF RFC 2615, June 1999.

Resilient Packet Ring Alliance, "A Summary and Overview of the IEEE 802.17 Resilient Packet Ring Standard", version 2.1, 2003.

Simpson, W., "PPP in HDLC-like framing", IETF RFC 1662, July 1994.

The ATM Forum, "ATM in Europe: The User Handbook", 1997.

Claims

Claims:

1) A network node for transmitting and receiving data over a hierarchical interconnected network containing a plurality of network nodes, said network node comprising:

a method for assigning a segmented Media Access Control (MAC) address wherein the number of bits used for each address segment can be different; and

a method and apparatus for decoding said segmented MAC address in a received data

frame where each said address segment is independently evaluated and the results from said evaluations are logically combined to determine the path to the destination node indicated by said MAC address.

2) The method and apparatus of claim 1, wherein said method for assigning a segmented

Media Access Control (MAC) address wherein the number of bits used for each address segment can be different comprises: dynamically assigning a segmented Media Access Control (MAC) address during

network configuration wherein the number of bits used for each address segment can be

different.

3) The method and apparatus of claim 1, which further comprises:

said segmented Media Access Control address indicating the location of the network node within the hierarchy of said interconnected network.

4) The method and apparatus of claim 1, which further comprises:

a method and apparatus for evaluating a Destination Area Code and, if said Destination

Area Code is different from the Area Code for the current network node, forwarding

said data to the network having said Destination Area Code.

5) The method and apparatus of claim 4, which further comprises:

permitting the number of bits used for each address segment in said segmented Media Access Control address to be different in networks having different Area Codes.

6) The method and apparatus of claim 1, which further comprises: a method and apparatus for logically combining the results from said evaluation of the MAC address segments with the result from an evaluation of a Multicast Group Number and using this combined result to direct multicast or broadcast data traffic to destination nodes in one or more networks that are within the same hierarchy as the source node.

7) The method and apparatus of claim 1, which further comprises: a method and apparatus for decoding a protocol header containing a Multicast Group Number and a Destination Area Code wherein said Multicast Group Number and said Destination Area Code are independently evaluated and the results from said evaluations are logically combined and used to direct multicast or broadcast data traffic to destination nodes in one or more networks that are within the same hierarchy as the source node or to destination nodes within different networks from the source node.

8) A method and apparatus for decoding a protocol header containing a Multicast Group Number and a Destination Area Code wherein said Multicast Group Number and said Destination Area Code are used to direct multicast or broadcast data traffic to destination nodes in one or more networks that are within the same hierarchy as the source node or to destination nodes within different networks from the source node.

9) A method and apparatus for decoding a protocol header containing a Destination Area Code and a Destination Media Access Control (MAC) address where said Destination Area Code and said Destination MAC address are independently evaluated and the results from said evaluations are logically combined and used to direct unicast data traffic within an interconnected network or to direct unicast data traffic between interconnected networks.

10) A method and apparatus for decoding a protocol header containing a Multicast Group

Number and a Source Media Access Control (MAC) address where said Multicast Group Number and said Source MAC address are independently evaluated and the results from

said evaluations are logically combined and used to direct multicast, local broadcast, or global broadcast data traffic within an interconnected network or to direct said data traffic

between interconnected networks.

11) A method for generating decoding tables wherein each decoding table has a segmented Media Access Control address, a Destination Area Code, or a Multicast Group Number as inputs and the outputs from said decoding tables are logically combined and used to direct data traffic within an interconnected network or to direct data traffic between

interconnected networks.