WO2003101122A2 - Procede et dispositif pour systeme de reseaux commutes hierarchises - Google Patents

Procede et dispositif pour systeme de reseaux commutes hierarchises Download PDF

Info

Publication number
WO2003101122A2
WO2003101122A2 PCT/US2003/016637 US0316637W WO03101122A2 WO 2003101122 A2 WO2003101122 A2 WO 2003101122A2 US 0316637 W US0316637 W US 0316637W WO 03101122 A2 WO03101122 A2 WO 03101122A2
Authority
WO
WIPO (PCT)
Prior art keywords
node
ring
address
network
destination
Prior art date
Application number
PCT/US2003/016637
Other languages
English (en)
Other versions
WO2003101122A3 (fr
Inventor
Pei Chong Tang
Dale John Shpak
Shu-Chu Lin
Original Assignee
Pei Chong Tang
Dale John Shpak
Shu-Chu Lin
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pei Chong Tang, Dale John Shpak, Shu-Chu Lin filed Critical Pei Chong Tang
Priority to AU2003247420A priority Critical patent/AU2003247420A1/en
Publication of WO2003101122A2 publication Critical patent/WO2003101122A2/fr
Publication of WO2003101122A3 publication Critical patent/WO2003101122A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing

Definitions

  • 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.
  • SONET Synchronous Optical NET work
  • SDH Synchronous Digital Hierarchy
  • 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.
  • 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.
  • 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.
  • SONET as well as SDH, the standard widely used outside of North America
  • TDMA Time Division Multiple Access
  • Packet traffic was often carried using Frame Relay or Asynchronous Transfer Mode (ATM) systems.
  • ATM Asynchronous Transfer Mode
  • 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.
  • 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.
  • 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 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.
  • 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.
  • PoS uses standard SONET redundancy and protection mechanisms, which requires a 100% protection capacity that is not used unless there is a failure.
  • ATM Asynchronous Transfer Mode
  • 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.
  • QoS Quality of Service
  • Resilient Packet Ring addresses many of the shortcomings of PoS, such as its poor total link capacity utilization caused by provisioned point-to-point links.
  • 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.
  • SRP-fa distributed fairness algorithm
  • 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.
  • 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.
  • 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.
  • RPR represents an improvement for packet transport over SONET
  • 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.
  • 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.
  • 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.
  • 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
  • a network node for transmitting and receiving data over a hierarchical interconnected network
  • 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.
  • 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.
  • MAC Media Access Control
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • MAC Destination Media Access Control
  • 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.
  • MAC Media Access Control
  • a method 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.
  • 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.
  • Fig. 1 illustrates the structure of the suggested hierarchical ring-based network system (abbreviated as HRN hereinafter).
  • HRN suggested hierarchical ring-based network system
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • the third field in the MAC address of node 1.14 will be the number that this node is assigned on ring 1.34.
  • 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.
  • the frame headers that help enable the system's high efficiency data frame transmission capability.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • block 3.6 shows the contents of the headers used when sending unicast data
  • 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.
  • 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.
  • these nodes are the ones that switch the data frame over to a neighboring ring.
  • 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.
  • Priority attribute 3.9 and 3.15 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.
  • CRC Cyclic Redundancy Check
  • Mode attributes 3.11 and 3.17
  • 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.
  • 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.
  • 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.
  • 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.
  • a one-byte MAC Address is used to simplify the demonstration.
  • 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.
  • 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.
  • 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.
  • the Source MAC address 3.18 is used to indicate the MAC address of the source node when receiving broadcast or multicast data.
  • 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.
  • 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.
  • 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.
  • the node that interconnects the two rings transfers the data frame from the source ring into its transmission buffer for the adjacent ring.
  • 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.
  • 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.
  • 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).
  • 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;
  • 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.
  • header decoding can be completed shortly after the header bytes arrive at the node.
  • 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.
  • 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.
  • FIFO 5.5 will accumulate the entire data frame and forward it to the CPU 5.11 for further processing.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a four-byte node MAC address 6.1 is implemented in this example.
  • a CAM table of a size close to 4 gigabits is needed.
  • 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.
  • 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).
  • 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.
  • the required size for each CAM tables is dependent on the number of bits allocated to each field in the MAC address.
  • the isThis signal 6.7 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the current data frame is a unicast frame.
  • 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.
  • 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.
  • 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
  • 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;
  • 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.
  • the illustrated sub-network belongs to a MAN with an Area Code of 1159.
  • 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.
  • 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.
  • 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*
  • 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.
  • 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.
  • 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.
  • 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
  • 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
  • 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.
  • 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.
  • the output signal of isArea is zero as well.
  • these intermediate control signals result in the activation of the enCopy signal and the data frame is copied to the lower ring.
  • 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.
  • node 10.6 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • node 10.6 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.
  • 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.
  • 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).
  • the value of the Mode signal is *0 and the decision-making table of Fig. 8 is used to generate the data control signals.
  • 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.
  • node 10.6 will also copy it to the lower ring 10.2 for further distribution.
  • 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.
  • the data frame will be dropped at this node.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne une architecture de réseaux hiérarchisés comprenant des procédés et un appareil pour la mise en oeuvre d'un système de désignation d'adresse MAC hiérarchisé. Selon l'invention, les adresses physiques de tous les noeuds ou éléments de réseau d'un réseau hiérarchisé à plusieurs anneaux sont affectées de façon hiérarchisée. La mise en oeuvre de celle logique d'adressage MAC hiérarchisé diminue de façon importante la taille des tables de mémoire associative nécessaires à la manipulation des trames de données. De la même façon, la structure de réseau hiérarchisé permet la mise en oeuvre de mécanismes décisionnels simples pour la commutation des trames de données en direction de leurs destinations. Grâce à ce mécanisme, il est possible d'acheminer les trames de données au travers du hiérarchisé décrit jusqu'au noeud de destination, rapidement et facilement, en ne se servant que de circuits matériels simple qui analyse l'information d'en-tête située au début de la trame de données. Cette structure de réseau hiérarchisé est par nature compatible avec les fonctions de diffusion sélective et d'émission en circuit ouvert. En outre, elle admet les extensions nécessaires aux réseaux grandes distances, par incorporation d'une information de code de zone dans l'adresse MAC. En outre, les longueurs de zones à l'intérieur de l'adresse MAC peuvent être adaptées avec souplesse pour répondre aux demandes réelles pendant le déploiement du réseau.
PCT/US2003/016637 2002-05-27 2003-05-27 Procede et dispositif pour systeme de reseaux commutes hierarchises WO2003101122A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2003247420A AU2003247420A1 (en) 2002-05-27 2003-05-27 Method and apparatus for a hierarchial switched network system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US38421402P 2002-05-27 2002-05-27
US60/384,214 2002-05-27

Publications (2)

Publication Number Publication Date
WO2003101122A2 true WO2003101122A2 (fr) 2003-12-04
WO2003101122A3 WO2003101122A3 (fr) 2004-03-18

Family

ID=29584617

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2003/016637 WO2003101122A2 (fr) 2002-05-27 2003-05-27 Procede et dispositif pour systeme de reseaux commutes hierarchises

Country Status (2)

Country Link
AU (1) AU2003247420A1 (fr)
WO (1) WO2003101122A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005003882A2 (fr) * 2003-07-01 2005-01-13 Yair Lahav Adressage mac dynamique
EP1876765A2 (fr) 2006-07-04 2008-01-09 Huawei Technologies Co., Ltd. Procédé pour l'acquisition et le transfert de trames de données Ethernet, réseau Ethernet et pont
EP2053834A1 (fr) * 2006-08-15 2009-04-29 Huawei Technologies Co Ltd Procédé, réseau et dispositif nodal pour la retransmission de données dans un réseau à double couche
ITMI20081811A1 (it) * 2008-10-13 2010-04-14 Franco Barbalato Sistema e metodo per la gestione di informazioni provenienti da istituzioni o da enti aderenti da veicolarsi in tempo reale all'attenzione del pubblico attraverso sistemi elettronici posti esclusivamente presso istituti di credito

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5351146A (en) * 1993-03-01 1994-09-27 At&T Bell Laboratories All-optical network architecture
US6021121A (en) * 1996-10-31 2000-02-01 Stmicroelectronics Gmbh Device, method, and apparatus for selecting address words using digital segment filters
US6032205A (en) * 1997-03-06 2000-02-29 Hitachi, Ltd. Crossbar switch system for always transferring normal messages and selectively transferring broadcast messages from input buffer to output buffer when it has sufficient space respectively
US6404752B1 (en) * 1999-08-27 2002-06-11 International Business Machines Corporation Network switch using network processor and methods

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5351146A (en) * 1993-03-01 1994-09-27 At&T Bell Laboratories All-optical network architecture
US6021121A (en) * 1996-10-31 2000-02-01 Stmicroelectronics Gmbh Device, method, and apparatus for selecting address words using digital segment filters
US6032205A (en) * 1997-03-06 2000-02-29 Hitachi, Ltd. Crossbar switch system for always transferring normal messages and selectively transferring broadcast messages from input buffer to output buffer when it has sufficient space respectively
US6404752B1 (en) * 1999-08-27 2002-06-11 International Business Machines Corporation Network switch using network processor and methods

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005003882A2 (fr) * 2003-07-01 2005-01-13 Yair Lahav Adressage mac dynamique
WO2005003882A3 (fr) * 2003-07-01 2005-04-14 Yair Lahav Adressage mac dynamique
EP1876765A2 (fr) 2006-07-04 2008-01-09 Huawei Technologies Co., Ltd. Procédé pour l'acquisition et le transfert de trames de données Ethernet, réseau Ethernet et pont
EP1876765A3 (fr) * 2006-07-04 2008-01-23 Huawei Technologies Co., Ltd. Procédé pour l'acquisition et le transfert de trames de données Ethernet, réseau Ethernet et pont
US7693152B2 (en) 2006-07-04 2010-04-06 Huawei Technologies Co., Ltd. Method for ethernet data frame learning and forwarding, ethernet network and bridge
EP2053834A1 (fr) * 2006-08-15 2009-04-29 Huawei Technologies Co Ltd Procédé, réseau et dispositif nodal pour la retransmission de données dans un réseau à double couche
EP2053834A4 (fr) * 2006-08-15 2009-10-21 Huawei Tech Co Ltd Procédé, réseau et dispositif nodal pour la retransmission de données dans un réseau à double couche
US8804713B2 (en) 2006-08-15 2014-08-12 Huawei Technologies Co., Ltd. Method and system for forwarding data in layer-2 network
US9100351B2 (en) 2006-08-15 2015-08-04 Huawei Technologies Co., Ltd. Method and system for forwarding data in layer-2 network
ITMI20081811A1 (it) * 2008-10-13 2010-04-14 Franco Barbalato Sistema e metodo per la gestione di informazioni provenienti da istituzioni o da enti aderenti da veicolarsi in tempo reale all'attenzione del pubblico attraverso sistemi elettronici posti esclusivamente presso istituti di credito

Also Published As

Publication number Publication date
AU2003247420A1 (en) 2003-12-12
AU2003247420A8 (en) 2003-12-12
WO2003101122A3 (fr) 2004-03-18

Similar Documents

Publication Publication Date Title
US20040184450A1 (en) Method and system for transport and routing of packets over frame-based networks
US6909720B1 (en) Device for performing IP forwarding and ATM switching
US6553030B2 (en) Technique for forwarding multi-cast data packets
US6847644B1 (en) Hybrid data transport scheme over optical networks
US7272157B2 (en) Any size and location of concatenated packet data across SONET frames in a SONET signal
US6771663B1 (en) Hybrid data transport scheme over optical networks
US20040252688A1 (en) Routing packets in frame-based data communication networks
US7006525B1 (en) Hybrid data transport scheme over optical networks
US20020085567A1 (en) Metro switch and method for transporting data configured according to multiple different formats
US20020085565A1 (en) Technique for time division multiplex forwarding of data streams
US20020083190A1 (en) Apparatus and method for GFP frame transfer
US6990121B1 (en) Method and apparatus for switching data of different protocols
US20060045012A1 (en) Method and apparatus for controlling the admission of data into a network element
US6999479B1 (en) Hybrid data transport scheme over optical networks
JP2001503949A (ja) 伝送アーキテクチャおよびネットワーク要素
US20020085507A1 (en) Address learning technique in a data communication network
US6778561B1 (en) Hybrid data transport scheme over optical networks
US20020085545A1 (en) Non-blocking virtual switch architecture
US6510166B2 (en) Stuffing filter mechanism for data transmission signals
US6982989B2 (en) Transmission of data frames using low-overhead encapsulation and multiple virtual tributaries in a synchronous optical network
US7095760B1 (en) Routers for switching ATM cells in a packet-like manner using a packet switch
WO2007102068A2 (fr) Agrégation de tables de routage vci
JP2002223202A (ja) データ伝送方法及びそれを用いた伝送装置
US6996095B2 (en) Shared VT connectivity over SONET
WO2003101122A2 (fr) Procede et dispositif pour systeme de reseaux commutes hierarchises

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP