HK1187750A - System for performing data cut-through - Google Patents

Abstract

The present invention provides a system for performing data cut-through. The system for transferring data includes an ingress node transferring data at a determined bandwidth. The ingress node includes a buffer and operates based on a monitored node parameter. The system includes a controller in communication with the ingress node. The controller is configured to allocate, based on the monitored node parameter, an amount of the determined bandwidth for directly transferring data to bypass the buffer of the ingress node.

Description

System for performing data cut-through forwarding

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims the benefit of U.S. provisional patent application serial No. 61/654,395 filed on 6/1/2012 and U.S. patent application No. 13/610,165 filed on 11/9/2012, which are incorporated herein by reference.

Technical Field

The present invention relates to systems and methods for transmitting data (collectively referred to as systems). More particularly, the present invention relates to a system that performs cut-through switching or data transmission.

Background

Data and other information may be transmitted from one or more ports, nodes, locations or devices to one or more other ports, nodes, locations or devices. In some cases, a switching system or network switch facilitates the transfer of data between ports, nodes, locations, or devices.

Disclosure of Invention

(1) A system for transmitting data, comprising:

an ingress node transmitting data at a determined bandwidth, the ingress node comprising a buffer and the ingress node operating based on monitoring node parameters; and

a controller in communication with the ingress node, the controller configured to allocate an amount of the determined bandwidth for directly transmitting data to bypass the buffer of the ingress node based on the monitoring node parameter.

(2) The system of (1), wherein the controller is configured to identify a change in the monitoring node parameter.

(3) The system of (2), wherein the controller is configured to adjust an amount of allocation in the determined bandwidth for direct transmission of data based on the identified change in the monitored node parameter.

(4) The system of (1), wherein the monitoring node parameter comprises a fill level of the buffer of the ingress node.

(5) The system of (4), wherein the amount of allocation in the determined bandwidth for direct transmission of data varies inversely proportional to a fill level of the buffer of the ingress node.

(6) The system of (1), wherein the monitoring node parameter comprises a period of time that the ingress node has directly transmitted a data packet bypassing the buffer of the ingress node without saving the data packet to the buffer.

(7) The system of (6), wherein the amount of allocation in the determined bandwidth for direct transmission of data varies inversely proportional to a length of time that the ingress node has bypassed the buffer of the ingress node to directly transmit a data packet.

(8) The system of (1), wherein the ingress node comprises a set of ingress ports; and is

Wherein the ratio of the allocated amount of direct transfer data in the determined bandwidth corresponds to a ratio of a number of ingress ports of the set of ingress ports allocated for direct transfer of data bypassing memory of the ingress node to a size of the set of ingress ports.

(9) A method of transmitting data, comprising:

monitoring parameters of an entry node;

allocating a first amount of the determined amount of bandwidth of the ingress node for transmitting a data segment of a first data packet to an egress node prior to receiving a subsequent data segment of the first data packet at the ingress node based on the parameter;

transmitting the data segment using at least a portion of the first amount of the determined bandwidth;

allocating a second amount of the determined bandwidth for transmitting second data packets stored in the memory of the ingress node based on the parameter; and

transmitting the second data packet using at least a portion of the second amount of the determined bandwidth.

(10) The method of (9), wherein the determining the first amount of bandwidth is allocated based on a comparison of the parameter to an entry in a lookup table.

(11) The method of (9), wherein the determining the first amount of bandwidth is allocated based on an allocation algorithm that receives the parameter as an input.

(12) The method of (9), wherein the second amount of the determined bandwidth comprises a difference between the determined bandwidth and the first amount of the determined bandwidth.

(13) The method of (9), wherein the parameters include a fill level of a buffer, a length of time an ingress port has transmitted a previous data packet before receiving a subsequent data segment of the previous data packet at the ingress node, a store-and-forward credit, an enqueue rate, or a dequeue rate.

(14) The method of (9), further comprising: updating the first amount of allocation of the determined bandwidth and the second amount of allocation of the determined bandwidth in response to a change in the parameter.

(15) An ingress node, comprising:

a data transmission component configured to transmit data at a determined bandwidth;

a buffer in communication with the data transmission component and configured to store data related to a data packet;

an interface in communication with the data transmission component and configured to receive a data segment of a data packet;

a controller in communication with the data transfer component, the buffer, and the interface, the controller operable to determine a first amount of the determined bandwidth and a second amount of the determined bandwidth based on a fill level of the buffer, wherein the data transfer component uses the first amount to transfer data stored in the buffer and the data transfer component uses the second amount to transfer a segment of data to an egress node before receiving a subsequent segment of data of a data packet at the interface.

(16) The ingress node of (15), wherein the controller is configured to store the data packet in the buffer if the second amount of the determined bandwidth is insufficient to transmit the data segment to the egress node.

(17) The ingress node of (16), wherein the data transmission component is configured to transmit the subsequent data segment of the data packet from a buffer at the first amount of the determined bandwidth after receiving the data segment at the interface.

(18) The ingress node of (15), wherein the data stored in the buffer is destined for another egress node, and wherein the data transmission component does not transmit the data stored in the buffer until a data transmission credit is received from the other egress node.

(19) The ingress node of (15), wherein the data segment includes an identifier indicating an egress node to which the data packet is to be transmitted, and wherein the controller determines whether the egress node is in an idle state or available to receive a data segment before receiving a subsequent data segment of the data packet at the interface.

(20) The ingress node of (15), wherein the data transmission component is configured to transmit data using pass-through data transmission using the first amount of the determined bandwidth, and wherein the data transmission component is configured to transmit data using store-and-forward data transmission using the second amount of the determined bandwidth.

Drawings

The inventive aspects may be better understood with reference to the following drawings and description. In the drawings, like reference numerals designate corresponding parts throughout the different views.

Fig. 1 is a block diagram of an exemplary network for transmitting data.

Fig. 2 is a block diagram of an exemplary system for transferring data.

Fig. 3 is a block diagram of an exemplary system for transferring data.

Fig. 4 is a block diagram of an exemplary node of a system for transmitting data.

Fig. 5 is a block diagram of an exemplary system for transferring data.

Fig. 6 is a diagram of an exemplary allocation look-up table.

Fig. 7 is a diagram of an exemplary allocation look-up table.

Fig. 8 is an illustration of an exemplary state diagram.

Fig. 9 is a flow diagram of example logic for transferring data.

Fig. 10 is a flow diagram of exemplary logic for transferring data.

Detailed Description

As technology and data transmission requirements grow larger, emerging cloud network customers may benefit from high bandwidth aggregation devices for their networks. In addition to high bandwidth aggregation, an ideal system may also have low latency data transmission. The delay may determine or reflect the quality of the response and results seen by the user, or may affect the revenue of the internet service provider. Therefore, a system that provides high bandwidth aggregation and increased data transmission speeds may be useful.

Fig. 1 is a block diagram of an exemplary network 100 for transmitting data. The network 100 may include a variety of devices, such as one or more servers 110, 120 and one or more computers 130, 140. The network 100 may include a group of servers or an array of servers (server bank). Network 100 may include a vast network of interconnected computers or network devices. The devices may be interconnected as part of a data center, or may be devices interconnected in an automotive environment. Network 100 may include one or more other devices, such as one or more wireless telephones, mobile or mobile devices, smart phones, communication devices, tablets, Personal Computers (PCs), set-top boxes (STBs), Personal Digital Assistants (PDAs), palmtops, laptops, desktops, landline telephones, control systems, cameras, scanners, fax machines, printers, pagers, personal credit devices, web appliances, network routers, switches or bridges, or any other machine or device.

One or more systems, such as system 105, may be implemented to facilitate communication between one or more devices of network 100. Some or all of the devices of network 100, such as some or all of servers 110 and 120 and computers 130 and 140, may be connected to or communicate with each other through or using system 105.

Fig. 2 is a block diagram of an exemplary system 205 for transferring data. The system 205 may be similar, identical, or analogous to the system 105. The system 205 may include one or more integrated circuits, chips, or wafers 210, 220. A wafer may refer to a block of semiconductor material on which a circuit or integrated circuit of a given function may be fabricated. Wafers 210, 220 may include one or more tiles (tiles) or nodes (nodes), such as node A220 and node B225 of wafer 210, and node C230 and node D235 of wafer 220. The system 205 may include a full mesh topology or other topologies (such as a non-full mesh topology).

A system, such as system 105 or 205, may have any number of wafers, and a wafer may have any number of tiles or nodes. The nodes or tiles may represent individual wafers in a chip. A node may refer to multiple chips in a device or system, or multiple devices in a system or chassis. A node may represent a single logical entity in a wafer. Some systems may include multiple wafers, where each wafer contains one or more nodes in a single chip or device. Some systems may additionally or alternatively include one or more chips or devices.

The nodes of system 205 may include one or more ports. One or more devices (such as servers 110, 120 or computers 130, 140) may be connected to or in communication with system 205 using one or more ports of the nodes. Node a220 may have two ports so that server 110 may connect with a first port of node a220 and server 120 may connect with a second port of node a 220. A node of the system may have only one port or may have more than two ports.

The ports of system 205 may be internal on a single chip or wafer, or may extend across multiple chips or wafers. In some cases, the system 205 may be similar or analogous to a network switch. The system 205 may have any number of nodes or ports.

The ports in a tile or node may be, for example, ingress ports or egress ports. Data, data bits, packets, groups of data, signals, or frames (referred to as "data" or "packets") may arrive at system 205 or may be received by system 205 at or through an ingress port. In some cases, packets may be large and may arrive and/or be processed in small blocks (sometimes referred to as data "units," "segments," "blocks," or "portions"). The packet may exit the system 205 at or through an egress port. Other variations or port types are possible.

Each wafer may contain one or more nodes or tiles. A device (such as a chip or package) may include one or more wafers. For example, the apparatus may comprise two wafers, each wafer comprising two tiles, such that the apparatus comprises four tiles. Other variations and examples are possible.

For example, the server 110 may send the packet to an ingress port of node A220 of the system 205, which in turn will be sent to the computer 130 connected to an egress port of node B225 of the system 205. The system 205 may transmit the packet internally from the ingress port of node a220 to the egress port of node B225. The system 205 may transmit the data packet from the node B225 to the server 120. Other variations and examples are possible.

Ingress ports and ingress nodes may transmit data to an egress node or egress port in a number of ways. The ingress port may receive a data segment of a data packet in accordance with a store-and-forward data transfer. The ingress port may internally store the data segment in a memory or buffer within the ingress port or ingress node until the entire packet is received. Once a packet is received at an ingress port and its destination egress port is available to receive the data, the ingress port may be authorized to transfer the stored data segment of the packet from the ingress port or an internal memory of the ingress node to the egress port. In store-and-forward data transmission, all data segments may be stored before the data packet is transmitted on the egress port.

The ingress port may receive a data segment of a data packet in accordance with a cut-through data transfer (cut-through data transfer). In a pass-through data transfer, an ingress port may transfer a data segment to an egress port without storing the data segment in an internal buffer or memory of the ingress port or ingress node. In pass-through data transmission, an egress port may transmit a portion of a packet before the packet is completely received from an ingress port. Data may be transmitted from an ingress port to an egress port with lower latency in the case of transmitting data using pass-through data transmission than if the data were transmitted using store-and-forward data transmission.

The data transfer component of the ingress node may transfer data according to or using a determined or set bandwidth (sometimes referred to as an "ingress/egress node bandwidth"). A data transfer component may refer to one or more ingress ports or data transfer elements of an ingress node. Whether data is sent using store-and-forward or pass-through may depend on a determined amount of bandwidth available to an ingress port or ingress node, with or based on which the determined amount of bandwidth is utilized or otherwise required for transmission.

One or more components of the ingress node, such as a control module, may be configured or operable to determine an allocation or amount of ingress and egress node bandwidth that the ingress node may use to transfer data using, for example, a cut-through method or a store-and-forward method. Determining the allocation or amount of bandwidth may be based on or may be determined based on the status of the ingress node and one or more monitoring parameters of the ingress node.

The entry node or a control module of the entry node may monitor a parameter or parameter value of the entry node. For example, the ingress node may include a monitoring component that may track a value of a buffer fill level of the ingress node. For example, the ingress node may determine and set an allocation or amount of ingress and egress node bandwidth for communicating data in a pass-through manner based on a monitored parameter or value without storing the data packet and/or before all data packets have been received. Additionally or alternatively, the ingress node may determine an allocation or amount of ingress and egress node bandwidth for transmitting data using store-and-forward methods (e.g., by storing packets prior to forwarding the packets). The amount of bandwidth determined by the ingress node or the control module may correspond to or reflect the number of ingress ports used by the ingress node for one type of data transfer. Additionally or alternatively, the amount of bandwidth determined by the ingress node or the control module may correspond to or reflect a portion of the ingress and egress node bandwidth for transmitting data using one or more types of data transmission.

Fig. 3 is a block diagram of an exemplary system 305 for transmitting data packets. System 305 may be similar to, the same as, or different from system 105. This figure shows an expanded view of an example of system 305, showing the system architecture including the interconnection of different nodes of the system. System 305 may be a full mesh topology. The ingress node 310 and 315 can communicate or connect with the egress node 320 and 325.

For simplicity, the system 305 may be described assuming that the ingress node 310 and 315 include only one ingress port and the egress node 320 and 325 include only one egress port. However, it should be understood that the nodes 310, 315, 320, 325 may include more than one port. When one or more of the ingress nodes 310-315 (or the egress nodes 320-325) include multiple ports, the ingress (or egress) node may be configured or operable for communicating with the egress (or ingress) node.

The system 305 may include six ingress nodes with ingress ports, such as ingress node a310, ingress node B311, ingress node C312, ingress node D313, ingress node E314, ingress node F315, and six egress nodes, such as egress node a320, egress node B321, egress node C322, egress node D323, egress node E324, egress node F325. In other variations, the system 305 may have more or fewer ingress or egress nodes.

The ingress ports of the one or more ingress nodes 310-315 and the egress ports of the one or more egress nodes 320-325 may be configured or operable for connecting or communicating with one or more devices. The portal ports associated with the portal nodes 310 through 315 can be connected to servers in a server array.

The nodes or tiles may be connected to equipment and may include an inlet port and an outlet port. A node may include or function as an ingress port and an egress port and may be connected to one device.

The portal ports of the portal nodes 310-315 can be configured or operable to receive signals, packets, or other information, such as the data 300-305. The ingress port of ingress node a310 may be configured or operable to receive data 300 from a server connected to ingress node a 310. The ingress port of ingress node C may be configured or operable to receive data 302 from a server connected to the ingress port of ingress node C312.

A piece of received data 300-305 may be directed, destined, or otherwise mean one or more egress ports, such as an egress port of any of egress node a320, egress node B321, egress node C322, egress node D323, egress node E324, or egress node F325. In some cases, the received data 300-305 may be directed to, destined for, or otherwise mean one or more devices connected to the system 305 through one or more egress ports of the egress nodes 320-325. For example, the data 300 may be sent by a device to an ingress port of ingress node a310 and may be destined or intended for a device that is transported or sent to an egress port of egress node D323 or connected to the system 305 through egress node D323.

In some systems, the received data 300-305 may specify or include an identifier that may indicate to which egress port of the egress nodes 320-325 the data is directed, destined, or otherwise intended. The received data packet may contain information that may be used by packet processing logic or a packet processing unit in the node to resolve the destination node or port. For example, a first data segment of a data packet may include one or more tags or identifiers that may indicate destination egress ports for this data segment and for some or all of the other data segments of this data packet. In other systems, the ingress port or ingress node receiving the data 300-305 may perform one or more functions or algorithms to determine the egress port of the egress node 320-325 to which the data is intended to be sent. For example, the PPU may resolve the destination address for the destination egress port. The packet may be destined for one node or port or may be a multicast packet that may have more than one destination node or port.

The ingress ports or ingress nodes 310 to 315 may process the received data 300 to 305 and may determine to which egress port or egress node 320 to 325 the data 300 to 305 should be sent. The packet may then be sent from the receiving ingress port or ingress node to the destination egress port or egress node to which the packet is intended. In some systems, a packet received at any ingress port of the ingress nodes 310-315 may be designated, transmitted to, and/or otherwise sent to any egress port of the egress nodes 320-325 of the system 305. In other systems, data packets received at certain ingress ports may be restricted to being transmitted only to one or some egress ports. Other variations are possible.

The data packet may then be received by the destination egress port or egress node. The egress ports or egress nodes 320-325 may perform one or more processes on the data and may then output the data as output data 330-335 to one or more devices attached to the destination egress ports of the egress nodes. Other variations and examples are possible.

A port may have one or more classes of service, or priority levels associated therewith. The class of service may have its own separate queue for data to be transmitted to or from the port. For example, a port may have 8 classes of service, or priorities, each with a separate data queue. Other variations are possible.

Fig. 4 is a block diagram of an exemplary node of a system for transmitting data. Node a220 in fig. 4 may be node a220 of system 205 and may be operable to receive data packets from one or more other ports or nodes of system 205 or to transmit data packets to one or more other ports or nodes of system 205 using store-and-forward data transmission. Node a220 may include or function as both an ingress port and an egress port.

System 205 is operable to transmit data packets between nodes through system 205 in different manners and using a variety of data transmission types. In terms of store-and-forward, the nodes of system 205 may process data by storing segments of data packets in buffers or memories of the nodes or system 205 before transmitting the data packets from one node to another.

In store-and-forward, node a220 may be or may function as an ingress port and receive data packets, such as at or through a network interface, from one or more devices connected to or in communication with node a 220. For example, a node may have twelve ports configured to receive 1 gigabit of data per second. Other variations are possible.

The data packet received at node a220 may be destined for one or more other nodes or ports of the system 205 (which may be referred to as "destination tiles," "destination nodes," "destination egress ports," or "destination ports"). The server 110 may be ported to an ingress of node a220 of the system 205 and may transmit data to the ingress port of node a220 for transmission to one or more other devices that may be connected to an egress port of a different node of the system 205, such as a computer 130 attached to an egress port of node B225. The destination node or destination port of the data may be an egress port of the node B225.

Packet processing may be performed on the received packet by or with a packet processing unit ("PPU"), such as ingress PPU ("IPPU") 1410. IPPU1410 may, for example, perform an initial packet processing phase in which a destination node and/or port may be determined or parsed. The packet or segment may then be forwarded to an ingress traffic manager ("ITM") 415.

Node a220 may be prepared to send or transmit packets to the egress port of the node at different times and according to a variety of conditions. For example, in some systems, packets may be large and may be received at an ingress port in terms of data segments, which may be internally processed by the ingress port when received. In some cases, such as in some store-and-forward data transfers, received data segments may be stored in the ITM415 until all data segments of the data packet have been received and/or until the node is ready to send the data packet to an egress port. In some systems, the ingress port may perform one or more validity checks on the data packet prior to transmitting the data packet. If the packet is invalid, the ingress port may drop or not transmit the packet. In other cases, such as with some pass-through data transfers, the data packet may not be stored in the ITM 415.

As another example, the ingress port of node A220 may store a received data segment, or an entire packet, within the ITM415 until the egress port is ready to receive the data segment or packet. Multiple ingress ports may cause a packet to be sent to an egress port. In these, if an egress port has received data from one ingress port, the egress port may not be configured or operable for receiving data from the ingress port of node a 220. As another example, in some systems, an egress port may have data (such as store-and-forward data) that it received in a previous period or clock cycle, and may need to process the data or transmit the data to one or more devices. In some of these systems, the egress port may not be operable or operable to receive packets from the ingress port of node a 220. The outlet port may additionally or alternatively be flow controlled or controlled to restrict the flow of data to the outlet port (sometimes referred to as "data flow control"). For example, an egress port may perform flow control when the device to which the egress port is connected or communicating is full, congested or otherwise unable to accept any additional data and alert the egress port of such a condition, and in some of these systems, the egress port may not be or may not be operable to receive data from the ingress port of node a 220. When an egress port is associated with more than one class of service or priority, flow control of the egress port may be applied per class of service. For example, when an egress port has four classes of service, the port may flow control for the first class of service and not flow control for the other three classes of service. Other variations are possible.

In these and other systems, packets may be stored in the ITM415 of the ingress port of node a220 until the egress port is available to receive data, such as when the egress port is in an idle state. In some cases, the ingress port of node a220 is not ready to send a packet until one or more combinations of factors are met, such as when all packets have been received and the egress port is ready to receive a packet. Other variations are possible.

In terms of store-and-forward, when an ingress port of node A220 is ready to send or transmit a packet stored in ITM415 to a destination egress port, the packet may first be sent to one or more packet processing units that may perform additional processing on the packet prior to transmission to the egress port. For example, the data may be sent to the IPPU2420 first or passed through the IPPU2420, and the IPPU420 may perform one or more processes on the data. Data may be transmitted after additional processing of the destination egress port of the egress node of the system 205, such as with or through a tile architecture adapter or other component. In other systems, the transmission packet may be prepared without further packet processing.

Node a220 may also be, may include or may act as an egress port. Data packets sent or transmitted by different ports or nodes in the system 205 may be received by an egress port of node a 220. Once received, the data packet may be transmitted or sent to one or more packet processing units, such as egress PPU ("EPPU") 1430, which EPPU1430 may perform one or more processes on the received data packet before passing the received data packet to an egress traffic manager ("ETM") 435. For example, EPPU1430 may perform destination multicast resolution to determine all destination egress ports.

ETM435 may be a memory, buffer, or storage device that receives packets or data segments from an egress port. ETM435 may store the received data packet or data segment until the egress port of node a220 is ready to send or transmit the data packet to a device connected to node a220, such as server 110. In some systems, the egress port of node a220 is not ready to send or transmit a data packet to a device connected to node a220 until the entire data packet is received at the egress port of node a 220. In some systems, the egress port of node a220 is not ready to send or transmit packets to the device connected to node a220 until the device indicates that it is ready to receive packets. In some systems, the egress port of node a220 is not ready to send a packet stored in ETM435 until one or more combinations of these or other conditions are met. Other variations are possible.

When the egress port of node a220 is ready to send a packet to a device, the packet may be sent from ETM435 to one or more packet processing units (such as EPPU 2440) that may perform some processing on the packet prior to transmission of the packet from the egress port. The data may then be transmitted to the device, such as by or through an interface. In other instances, the data packet may be sent directly from ETM435 to the device without any further processing of the data packet.

In some systems, a node or tile, such as node a220, may additionally or alternatively include one or more controllers or control modules. The ports of the nodes or tiles may have controllers or control modules. The controller, control component, or control module may include one or more components of node a220, or various other components. The controller or control module may perform various functions or tasks. For example, the control module may analyze and determine the destination egress port based on the received data segments or packets. As another example, a control module may perform one or more functions, run one or more algorithms, and/or make one or more decisions that may affect or control the functionality or performance of a node or a port of a node. The controller or control module may perform various other functions or tasks.

Unlike store-and-forward data transport, in some systems, data packets may be processed and transported from an ingress port of node a220 using pass-through data transport (sometimes referred to as "pass-through," "pass-through forwarding switching," or "pass-through data transport"). With the cut-through method, parts of a data frame or data packet can be forwarded before the entire frame has been received, for example, as long as the destination address is processed. With the cut-through method, the data segment of the data packet may be transmitted through the ingress port or ingress node to the egress port or egress node without being stored in a buffer or memory (such as ITM 415) of the ingress node.

The data segment or packet may be received by node a220 in a cut-through forwarding. However, in pass-through, data segments or packets may obtain fabric bandwidth after initial packet processing at IPPU1410 to determine the destination node, without waiting for all packets to reach the ingress node. For example, upon receiving and parsing the destination node, the received data segment may be sent through the ingress port of node a220 to the egress port of the receiving node without waiting to receive all data segments of the data packet. The data segment of the data packet may be transmitted to the receiving node through the ingress port of node a220 before all other data segments of the data packet are received at the ingress port of node a220 or processed by the ingress port of node a 220.

In some cases, the received data segments may be transmitted to the egress port without being stored in any physical memory or buffer (such as ITM 415). Alternatively, one or more data segments may be stored in memory prior to transmission to the egress port. Because the data segments transferred in the pass-through method may bypass the physical memory or buffer, it may not be necessary or take any time to read the data out of the memory or buffer. In addition, pass-through data transmission may result in lower latency because certain data segments may be transmitted before the entire data packet is received. Thus, pass-through data transmission may reduce latency and/or be faster, more efficient than store-and-forward data transmission for transmitting data packets between ingress and egress ports.

Ingress ports or nodes and egress ports or nodes may be said to operate in a "store-and-forward mode" or in a "pass-through mode". When operating in a store-and-forward mode, the ingress port may transmit data to the destination egress port using store-and-forward data transmission, and the egress port may receive data from the ingress port using store-and-forward data transmission. When operating in the pass-through mode, the ingress port may transmit data to the destination egress port using pass-through data transfer, and the egress port may receive data from the ingress port using pass-through data transfer. Other terms and variations are possible.

Data may be sent or transmitted between the ingress node and the egress node according to one or more architectures. In pull architecture, an egress node may provide one or more ingress nodes with a quota or credit of data that may be allowed to be sent to the egress node. The egress node may provide one or more ingress nodes with quotas or credits that are equal to or close to the processing rate of the egress node. Traffic or data provided to an egress node according to a quota provided to an ingress node in the pull architecture may be referred to as dispatch traffic.

In a push architecture, an ingress node may forward a data segment or packet to one or more egress nodes. Data segments or packets can be forwarded at a high rate, such as the highest rate possible for the ingress node. In the push architecture, an egress node may receive data from a plurality of ingress nodes, and the reception rate of the data may exceed the processing rate of the egress node. When the arrival rate of data exceeds a threshold, such as the egress node's maximum processing rate, the egress node may instruct the ingress node to stop sending traffic, or may control ("flow control") the data flow. Traffic or data provided by an ingress node to an egress node according to the push architecture may be referred to as unscheduled traffic. An example of unscheduled traffic may be or may include data that is transmitted to the egress node using pass-through data transmission ("pass-through data"). Other architectures for the manner in which data is transferred are possible.

The ingress node may be configured or operable to transmit data at the determined transmission rate, or according to or employing or at the determined bandwidth. The determined bandwidth may be or may represent a limited amount of bandwidth and/or time by which the ingress node may transmit data to one or more egress nodes. The ports may have limited receive and transmit bandwidth, while the system 205 may have an aggregate bandwidth achieved by combining the bandwidths of the ports of the systems. For example, a system may have four ports with a bandwidth of 100 giga per second, whereby system 205 may have an aggregate bandwidth of 400 giga per second.

An ingress node or ingress port may receive data at a first rate and may transmit data at a second rate. The ingress node may also store the data in a buffer (such as ITM 415). For example, the portal node may store data that exceeds the data that the portal node can process at any time. The buffers may be of different sizes, such as greater than the amount of bandwidth available to the ingress node at a given time.

The ingress node, or a control module of the ingress node, may control the ingress port of the ingress node. The control module of the ingress node may, for example, determine the resource allocation of the ingress node or ingress ports of the ingress node, and may control the manner in which each ingress port may transmit or communicate data, and to which egress port.

Fig. 5 is a block diagram of an exemplary system 505 for transferring data. The system 505 may include an ingress node 510 and two egress nodes a530, B535. The system 505 may be similar or analogous to the systems 105, 205. Although one ingress node and two egress nodes are shown in system 505 for simplicity, in other systems, more or fewer ingress or egress nodes may be included.

The portal node 510 can be similar, identical, or analogous to one or more of node a220, node B225, node C230, node D235, or portal nodes 310-315. The ingress node 510 may include one or more components of node a 220. The ingress node 510 may have one or more ingress ports.

The ingress node 510 may additionally or alternatively include a memory or buffer 515. Buffer 515 may be the same as ITM415, may be part of ITM415 or may include ITM415, or may be a different buffer than ITM 415. Buffer 515 may be configured or operable to store data, such as data 550. Data 550 may include segments or blocks of data, packets, bits or bytes of data, or various other data or information. The buffer 515 of the ingress node 510 may be configured or operable to store packets, or segments of packets, destined to be sent to one or more egress nodes or ports when the entire packet is received by the ingress node 510, such as with a store-and-forward data transmission. One or more ingress ports of ingress node 510 may have a separate buffer 515 for storing data 550 or may have a buffer 515 that may store data 550 for some or all of the ports of ingress node 510. Other variations are possible.

Ingress node 510 may be configured and/or operable to receive and/or store more than two different sets of data or data packets simultaneously, one or more of which may be destined for different egress ports or egress nodes. The ingress node may receive and store data 550 destined for a first egress node, such as egress node a 530. The data 550 may be a data packet that the ingress node 510 may store as store-and-forward data for transmission to the egress node a530 when all segments of the data 550 are received and/or stored by the ingress node 510. The ingress node 510 may also or alternatively receive another different set of data or data packets, such as data 560. At the interface 530 of the ingress node 510, the data 560 may be received by the ingress node 510. Data 560 may be received while data 550 is received or stored in buffer 515. The data 560 may be a data packet that may be destined for the egress node B535.

Ingress node 510 may identify, determine, or receive an indication that egress node B535 may be in an idle state, may be eligible, available, or capable of receiving data (such as data 560) from ingress node 510 using pass-through data transfer. Ingress node 510 may receive an indication from a central control or determination system that may determine and communicate with ingress node 510 whether transmission of data 560 to egress node B535 would result in any data collisions at egress node B535. Alternatively or additionally, ingress node 510 may determine whether egress node 535 may be in an idle state, available, or capable of receiving data in various other ways using pass-through data transfer. When ingress node 510 determines that egress node B535 is in an idle state, available, or capable of receiving data 560 using pass-through data transmission, ingress node 510 may determine that egress node B535 is configurable or operable to receive data 560 transmission without ingress node 510 receiving the entire packet for data 560 and that data 560 has not been stored in any buffer or memory of ingress node 510.

The ingress node 510 may need, use, require, or occupy a portion or all of the egress bandwidth of the ingress node 510 in transmitting the data 560 to the egress node B535. The output bandwidth of the ingress node 510 may be the bandwidth that the ingress node 510 may use for transmission to another egress node or a local egress port. However, as long as ingress node 510 is receiving data (such as data 560) that may be transmitted to an egress node (such as egress node B535) using pass-through data transmission, immediately transmitting data 560 that is higher priority than data 550 may result in data 550 being stored in buffer 515 for a longer time and may delay data 550 from being transmitted to egress node a 530.

The ingress node 510 may include a controller, control component, or control module 520. The control module 520 may perform one or more other functions or tasks, may perform or run one or more algorithms, and may control one or more aspects, functions, operations, or data transfers of the ingress node or ingress port.

The control module 520 may control resource allocation of the ingress node 510. The control module 520 may allocate, determine, and set one or more amounts of ingress and egress node bandwidth available for one or more data transfers in the ingress node 510. The control module 520 may determine the ingress node bandwidth amount based on or based on the ingress node status and/or one or more monitored parameters of the ingress node 510. The control module 520 may effectively balance the need and efficiency of immediately sending pass-through data 560 to egress node B535, necessitating and smoothing the sending of stored data 550 to egress node a530 without incurring undue or infinite delay. Additionally or alternatively, the control module 520 may perform one or more other functions on the ingress node 510, such as analyzing and determining a destination egress port from received data segments or packets, or determining whether a destination egress node or port may be idle, available, or operable to receive data from the ingress node 510 using pass-through data transfer.

The control module 520 may include one or more components of node a220, such as a monitoring component for monitoring parameters of the ingress node 510, as well as various other components. The control module 520 may control or direct a portion or all of the ports of the ingress node 510, or one or more ingress ports of the ingress node 510 may have a separate control module 520 for the ingress port. Other variations are possible.

In determining and setting the resource allocation, the control module 520 may monitor the data and parameter values (sometimes referred to as "node parameters") of the ingress node 510. The monitoring node parameters may be or may describe one or more states, features, characteristics, or other elements of the ingress node or data transmission performed by the ingress node 510. The control module 520 may track values of monitoring node parameters in order to create, set, adjust, change, or modify allocations or amounts of bandwidth of ingress nodes for transmitting data with one or more data transmissions (such as an amount of bandwidth for transmitting store-and-forward data and an amount of bandwidth for transmitting pass-through data).

The ingress node parameter that the control module 520 may monitor may be or include a buffer fill level of the ingress node 510 or a level or amount of the buffer 515 that may have data 550 stored therein. The buffer fill level may indicate how much store-and-forward data 550 the ingress node 510 has waiting to transmit to an egress node (such as egress node a 530). The buffer fill level may be represented in a number of ways, such as an accurate or estimated buffer fill level, a range of buffer fill levels, or a category or state of buffer fill levels. Other variations are possible.

The ingress node parameter that the control module 520 may monitor may be or include a duration of time that the ingress node 510 has transmitted data using pass-through data transmission. Duration may refer to the length of time that ingress node 510 has continuously performed data transfers on data (such as data 550) using pass-through data transfers. Additionally or alternatively, the duration may refer to an accumulated time or a ratio of time that the ingress node 510 has performed a data transfer using a pass-through data transfer to a given time period. Alternatively, the duration may refer to the time that the ingress node 510 has transmitted data using store-and-forward data transmission. The control module 520 may monitor or receive data or information regarding the duration.

The portal node parameter that the control module 520 may monitor may be or include a credit or pull algorithm attribute. Credits or pull algorithm attributes may be assigned to ingress node 510 for one or more egress nodes 530 or 535. Egress node a530 may be configured or operable to receive a given amount of data and may send quotas or credits to one or more ingress nodes, such as ingress node 510. The credits may indicate how much and/or when data may be transmitted by the ingress node 510 to the egress node a 530. It may be useful to determine or identify quotas or credits, for example, when ingress node 510 has a large amount of store data 550, but does not have credits for transmitting the data to egress port A535, thus, in situations where it may not benefit from a large store-and-forward allocation. The control module 520 may monitor the value of the information, data, or credit information of the ingress node 510.

The ingress node parameter that the control module 520 may monitor may be or include an enqueue rate or a dequeue rate. The enqueue rate may refer to the time or rate at which the ingress port may encapsulate or may transmit data segments to the egress port. The dequeue rate may indicate a time or rate at which the data segment it receives may be dequeued by the mouth port. The enqueue rate or dequeue rate may be a measure of the packet's performance over each time period. The enqueue rate or dequeue rate may vary with the size of a data segment that may be transmitted from an ingress node to an egress node over a bus. A transmitting ingress node (or receiving egress port) may need, use, or require longer time or more resources to enqueue (or dequeue) smaller pieces of data sent over a bandwidth or bus. Conversely, a transmitting ingress node (or receiving egress port) may need, use, or require less time or less resources to enqueue (or dequeue) larger pieces of data. Higher enqueue or dequeue rates may require more resources and may reduce or limit the bandwidth available to transmit other data with pass-through data transfers. The control module 520 may also or alternatively monitor the values of various other ingress node parameters or combinations of ingress node parameters.

The control module 520 may analyze and use the monitoring node parameters to determine and/or set the resource allocation of the ingress node. For example, the control module 520 may determine a resource allocation for the ingress node, or a determined amount of output bandwidth for transmitting data, which the ingress node may use to employ one or more tables (such as an allocation look-up table) to transmit store-and-forward or pass-through data. Fig. 6 is an illustration of an exemplary assignment look-up table 600.

The allocation lookup table 600 may provide, sort, or list settings for one or more resource allocations, such as bandwidth allocations or determining an amount of output bandwidth. The settings may be a function of the values of one or more monitoring node parameters. The allocation lookup table 600 may include a column 610 of values for a first monitoring node parameter, such as a buffer fill level. The allocation lookup table 600 may also include a pass-through bandwidth allocation that provides, classifies, or lists one or more values for the first monitoring node parameter shown in column 610. The pass-through bandwidth allocation may be a determination or setting of an ingress node bandwidth amount or percentage that the ingress node uses or is dedicated to performing data transfers with pass-through data transfers. Data (such as data 560) that is eligible for transmission by ingress node 510 using pass-through data may be transmitted to a destination egress node using a certain amount or percentage of the determined or set egress node bandwidth specified by the pass-through bandwidth allocation of table 600.

The control module 520 may compare the monitored node parameters of the ingress node 510 with the resource allocation settings provided in the allocation look-up table 600. For example, control module 520 may compare the received value for the first monitoring node parameter to the value or range of values associated with the first monitoring node parameter in column 610. When control module 520 determines that the received value of the monitoring node parameter is within the lookup range of values in column 610, control module 520 may determine or identify a resource allocation, such as a pass-through bandwidth allocation, from the allocations listed in column 650 that is near or associated with the value or range of values found in column 610.

For example, the control module 520 may determine a value of 250KB for a first monitored ingress node parameter, such as the buffer fill level of the buffer 515 of the ingress node 510. The deterministic value may indicate that the buffer 515 has 250KB of data 550 stored within the buffer 515 for transmission to the egress node using store-and-forward data transmission. The control module 520 may look up one or more entries in the column 610 of the assignment look-up table 600. When the entry 660 may correspond to a buffer fill level range of 150KB to 450KB, which may include monitored values of the buffer fill level of the buffer 515 of the ingress node 510, the control module 520 may identify the entry 660 as corresponding to the monitored buffer fill level of the buffer 515. The control module 520 may identify or determine the resource allocation based on the 50% setting (the value of the entry in column 650 corresponding to entry 660). Ingress node 510 may transmit pass-through data, such as data 560, using up to 50% of the ingress and egress node bandwidth for transmitting data. The node settings may be used, for example, to specify a peak bandwidth for cut-through that may be consumed prior to forcing traffic to be stored and forwarded, e.g., by monitoring collection. Various other examples are possible.

Fig. 7 is an illustration of an alternative exemplary assignment look-up table 700. The allocation lookup table 700 may provide resource allocation information that may be based on, or may be set according to, a combination of monitored ingress node parameters. The assignment look-up table 700 may include a column listing values or ranges of values for a plurality of monitored ingress node parameters. The entries, values, and ranges are exemplary and may vary depending on the implementation. The allocation lookup table 700 may include a column 710 that provides an entry, value, or range of values for the buffer fill level of the buffer 515 of the ingress node 510. The lookup table 700 may also include a column 720 that provides a value or range of values for the time at which the ingress node 510 has performed the pass-through data transfer. The lookup table 700 may also include a column 730 that provides an entry, value, or range of values for the ingress node 510 credit. The allocation lookup table 700 may provide resource allocations (such as cut-through bandwidth allocations) that the ingress node 510 may set, change or implement based on one or more monitored ingress node parameters identified in the allocation lookup table 700.

The control module 520 may compare the identified values, data, or information about monitoring ingress node parameters to entries in the allocation look-up table 700 to identify resource allocation settings. The control module 520 may determine a resource allocation for the ingress node 510 based on the comparison. For example, the control module may monitor ingress node parameters, which may include a buffer fill level of the first category or falling within a buffer fill level 1 range, a duration value of approximately 400 nanoseconds ("ns") for which the ingress node 510 has utilized pass-through data transmission to transmit data, and an indication that the ingress node 510 has no credit. The control module 520 may compare the value of the monitored ingress node parameter to entries of the assignment look-up table 700 and may identify an entry 760 corresponding to the monitored ingress node parameter. Using the allocation lookup table 700, the control module 520 may determine that the pass-through allocation under the entry 760 condition is approximately 100%. Other examples are possible.

The allocation lookup table 600, 700 may provide resource or bandwidth allocation for the ingress node 510 based on various different ingress node parameters or combinations of ingress node parameters. The allocation lookup table may provide, for example, bandwidth allocation settings corresponding to one or a combination of parameters, such as a duration for which the ingress node 510 has transmitted data using one or more data transmission types, credits of the ingress node 510, enqueue/dequeue rates of the ingress node 510, or various other parameters. Data (such as data 560) that is eligible for transmission by ingress node 510 using pass-through data may be transmitted to a destination egress node using a certain amount or percentage of the determined or set egress node bandwidth specified by the pass-through bandwidth allocation of table 600 or 700.

The allocation lookup tables 600, 700 may provide settings for resource or bandwidth allocation in different forms or manners. The allocation lookup table 600, 700 may provide a percentage of bandwidth or resources that should be allocated for one or more data transfers, such as store-and-forward data transfers or pass-through data transfers. The assignment lookup table 600, 700 may provide a number or identification of ports that may be used to transfer data using one or more data transfers. The allocation lookup table 600, 700 may provide an indication of whether data may be transmitted using one or more data transmissions. Various other examples are possible.

Additionally or alternatively, the control module 520 may utilize one or more action or state tables or graphs to determine resource allocation for the ingress node 510.

Fig. 8 is an illustration of an exemplary state diagram 800. The values in state diagram 800 are for illustration purposes and may vary depending on the implementation. The state diagram 800 may be referred to or used by the control module 520 to determine the amount of ingress/egress node bandwidth available for transmitting pass-through data. State diagram 800 may produce resource allocations similar to look-up table 700.

The control module 520 may use the values of the monitor node parameters to navigate the state table 800. The state diagram 800 may include a decision tree that the control module 520 may navigate to find a state, such as one of the states 850-863, that may correspond to the current state of the entry node 510. The decision tree may include one or more branch points, such as a buffer fill level branch 805, one or more cut-through time branches 815-817, or one or more credit branches 820-824. The control module 520 may navigate from the branch point down to the appropriate branch of the state diagram based on the monitoring node parameters of the entry node 510. For example, when the monitoring ingress node parameters include a buffer fill level of the first category or falling within the buffer fill level 1 range, a value of about 400ns for the duration that the ingress node 510 has transmitted data with pass-through data transfer, and an indication that the ingress node 510 has no credit, the control module may proceed along the branch of buffer fill level 1 from the first branch point 805 to the branch point 815, proceed down the "0-500 ns" branch to the branch point 820, and may proceed down the no branch to state 852. The status may indicate a resource allocation, such as a percentage of a determined output ingress/egress node bandwidth for transmitting data using pass-through data transmission.

State diagram 800 may include one or more branch points, branches, and states that may be related to or based on one or more monitored ingress node parameters or values of parameters. The state diagram 800 may include similar branch points for each branch from the previous branch points (such as the three pass time branch points 815-817 for each branch from the buffer fill level branch point 805). Additionally or alternatively, the state diagram 800 may include branches that are different from the branch points (such as the two branch points 823, 824 from the branch of the through time branch point 817 and the state 14863 as the third branch of the through time branch point 817). Other variations are possible.

Additionally or alternatively, the control module 520 may utilize one or more algorithms or formulas to determine the resource allocation for the ingress node 510. An algorithm, formula, or other function is operable to provide a resource allocation value based on one or more inputs.

The control module 520 may execute one or more formulas that may be factors in determining resource allocation for the ingress node 510 or weighted values of one or more monitored ingress node parameters. One formula executed by the control module 520 to determine resource allocation may be:

CT allocation =100 min (1; 1.4- (buffer fill value/1 MB))

Where the CT allocation may be a percentage of the output bandwidth allocated for the pass-through data transfer, and where the percentage of the bandwidth allocated for the pass-through data transfer may be about 100% or 100 x (1.4- (buffer fill level/1 MB)), whichever is smaller. The resource allocation algorithm may consider different monitored ingress node parameters or different combinations of ingress node parameters to determine the resource allocation for the ingress node. For example, the algorithm may consider both the buffer fill level and the credits of the ingress node 510. Various other examples and variations of algorithms are possible. Alternatively or additionally, the control module 520 may utilize various other tools or components to determine the resource allocation of the ingress node 510 in various other ways.

The tables (such as assignment look-up tables 600, 700) and/or algorithms or formulas may be predetermined or preconfigured by a programmer prior to use with the ingress node. Alternatively or additionally, the tables and/or algorithms may be configured, determined or set based on one or more visible or measurable characteristics of the system. The allocation lookup table and/or algorithm may be dynamic, may change and/or may be updated. The bandwidth allocation provided by the allocation look-up tables 600, 700 and/or algorithm may provide a tradeoff or balance between the requirements and priority of immediate transmission of data segments that an ingress port may receive using pass-through data transmission, and the requirement to avoid the unworkable and undue delay of transmitting the data 550 stored in the buffer 515 of the ingress node 510. For example, an allocation look-up table or algorithm may provide increased pass-through bandwidth for use by ingress node 510 that has stored data 550 in buffer 515 for a long period of time, but where ingress node 510 does not have a credit to transmit data 550 to a destination egress port, and therefore does not require bandwidth for store-and-forward data transmission. Other examples and variations are possible.

The control module 520 may set or implement resource allocation. Once the resource allocation has been determined, the resource allocation may be implemented using one or more allocation look-up tables 600, 700 or one or more algorithms or functions, or various other times, etc.

The control module 520 may implement resource allocation by setting each ingress port of the ingress node 510 to operate in a mode or to transfer data with one type of data transfer. The control module 520 may set the number of ingress ports according to the determined resource allocation. When the allocation lookup table 600 indicates, for example, that the pass-through bandwidth allocation for a given entry (such as entry 660) should be 50%, the control module 520 may specify that half of the ingress ports of the ingress node 510 operate in the pass-through mode and the other half of the ingress ports of the ingress node 510 operate in the store-and-forward mode. If the bandwidth allocation is 80%, control module 520 may set 4 of the 5 ingress ports of ingress node 510 to operate in a pass-through mode, while the remaining 1 of the 5 ingress ports may be set to operate in a store-and-forward mode.

Additionally or alternatively, the control module 520 may configure the ingress ports of the ingress node to utilize different types of data transmissions to transmit a percentage or portion of the data, or to allocate a percentage of bandwidth for one type of data transmission at the ingress ports. When control module 520 determines an 80% pass-through allocation, for example, the ingress port of ingress node 510 may be configured to allocate 80% of the bandwidth for the ingress port to transmit data using pass-through data transmission, and the remaining 20% of the ingress port to transmit data using store-and-forward data transmission.

Additionally or alternatively, determining the resource allocation itself may identify how the resource allocation is to be implemented. One or more allocation lookup tables 600, 700 may specify how each ingress port may be configured or operated, such as by indicating for an entry (such as entry 660 or 760) that ingress ports 1-4 of ingress node 510 (for example) may be configured to operate in a pass-through mode, while ports 5-10 may be configured to operate in a store-and-forward mode. Additionally or alternatively, the control module 520 may compare the value of the monitoring node parameter to a threshold value. The control module 520 may allocate a portion or all of the bandwidth for data transmission utilizing store-and-forward data transmission or pass-through data transmission, with the value of the node parameter being greater than or less than a threshold value. Other variations are possible.

The ingress node 510 may operate and transmit data based on the set or implemented resource allocation. Data, such as data 560, may be transmitted by cut-through methods using cut-through amounts of ingress node bandwidth that may be determined by an allocation look-up table, a state table, an algorithm, or in various other ways. Data, such as data 550, may be transmitted by a store-and-forward method using a store-and-forward amount of ingress node bandwidth that may be determined by an allocation look-up table, a state table, an algorithm, or in various other ways. The store-and-forward amount of ingress node bandwidth may be an ingress node bandwidth that does not include a straight throughput of ingress node bandwidth. Other examples are possible.

Fig. 9 is a flow diagram of example logic for transferring data. The logic may be executed, for example, by the control module 520 of the ingress node 510. Logic may be used to determine and set the bandwidth allocation of the ingress node 510. The bandwidth allocation value is for illustration purposes and may vary depending on the implementation. The ingress node may transmit or send data (such as store-and-forward data 550 and potential cut-through data 560) according to the set bandwidth allocation. The logic may begin at block 900.

In block 902, the control module 520 may monitor one or more node parameters of the ingress node 510. The control module 520 may monitor values for monitored parameters such as buffer fill level, credits of the ingress node 510, duration of time that the ingress node 510 has transmitted data in yet one or the other, enqueue/dequeue rates, and/or various other ingress node parameters.

In block 904, the control module 520 may determine a resource allocation for the ingress node 510, such as a bandwidth allocation, a port allocation, a determined amount of bandwidth for transmitting data, or other data transmission resource allocation. For example, the control module 520 may identify a setting of the resource allocation corresponding to a value of the monitoring node parameter. The control module 520 may determine the resource allocation in different ways, such as by using or referencing a table (e.g., the allocation lookup table 600 or 700), or by using an algorithm or formula. The control module may determine the resource allocation based on, or in accordance with one or more monitored values for one or more ingress node parameters.

Once the resource allocation has been determined, the logic may proceed to block 906. In block 906, the control module 520 or another component of the ingress node 510 may implement the resource allocation based on the monitored parameter value of the ingress node 510. The control module 520 may set or implement a portion or all of the ingress ports of the ingress node to be operable or configured to transmit data using a first mode (such as a store-and-forward mode) and/or a portion or all of the ingress ports of the ingress node to be operable or configured to transmit data using a second mode (such as a pass-through mode) according to the determined resource allocation. Alternatively or additionally, the control module 520 may configure or set a portion or all of the ingress ports to allocate some bandwidth for data transmissions utilizing a first type of data transmission and to allocate a portion or all of the bandwidth for data transmissions utilizing another type or mode.

Resource allocations, such as bandwidth allocations, may indicate or warrant allocations for certain types of data transfers, such as allocations for transferring data with pass-through data transfers and allocations for transferring data with store-and-forward data transfers. Alternatively or additionally, a resource allocation (such as a bandwidth allocation) may indicate or guarantee a maximum allocation for a type of data transmission (such as a direct data transmission). For example, the resource allocation may indicate a maximum resource allocation of 40% for transmitting data with pass-through data transmission, where up to 40% of the resources (such as bandwidth) may be used to transmit data with pass-through data transmission. Resources (or bandwidth) that may be allocated as part of the maximum resource allocation but that are not needed or used for data transfer (such as unused pass-through bandwidth) may be used to transfer data using another data transfer (such as store-and-forward). Other variations are possible.

In block 908, the ingress node 510 may transmit data according to the implemented resource allocation. For example, when the resource allocation is determined and implemented to provide approximately 40% bandwidth for store-and-forward data transfers and approximately 60% bandwidth for pass-through data transfers, data 550 in buffer 515 may be transferred to egress node a530 using approximately 40% of the available bandwidth of ingress node 510. Data 560 received by ingress node 510 for egress node B535 may be transmitted using approximately 60% of the express bandwidth of ingress node 510. Even when data 560 may be received and capable of being transmitted using pass-through data transfer, with the allocation look-up table or algorithm so configured, control module 520 may be configured to transmit data that may be stored in buffer 515 of ingress node 510. Other variations and examples are possible.

In block 910, the control module 520, the ingress node 510, or another component in communication with the control module 520 or the ingress node 510 may monitor an ingress node parameter. The control module 520 may, for example, monitor the buffer fill level of the ingress node's buffer 515 and the duration for which the ingress node has transmitted data according to the pass-through data transmission. The ingress node parameters may be monitored continuously, during each clock cycle, periodically, at certain or determined intervals, triggered, or at other times.

In block 912, the control module 520, the ingress node 510, or another component in communication with the ingress node 510 may determine whether the resource allocation setting has been changed. The resource allocation settings may change when one or more of the ingress node parameters have changed. For example, a buffer fill level change from 750KB to 200KB may trigger a resource allocation setting change. The resource allocation settings may change when the value of the ingress node parameter exceeds a threshold, switches from one range of values to another range of values, or switches from one level or state to another level or state. The threshold, range of values, and/or state or level may correspond to a value in an assignment look-up table or other defined value. For example, if the change does not move the buffer fill level from a first range of values to a second range of values (such as associated with allocation lookup table 700), a change in the buffer fill level from 250KB to 200KB does not trigger a resource allocation setting change. Other variations are possible.

If no change in resource allocation settings is detected, the logic may return to block 908. The data may continue to be transmitted using the bandwidth allocation at block 908, and the control module 520, the ingress node 510, or other component in communication with the ingress node 510 may continue to monitor the ingress node parameters.

If a change in resource allocation settings is detected, the logic may return to block 904 where a new resource allocation may be determined based on the new ingress node parameters or resource allocation settings. In block 906, the resource allocation may be set or implemented, or may simply be updated.

In certain variations, the logic of FIG. 9 may include fewer or more blocks or functions. In some variations, one or more blocks may perform different functions, or one or more blocks may be combined into fewer functions or determinations. In certain variations, one or more blocks or functions may be performed in a different order or concurrently. Various other examples and variations of logic are possible.

The logic of fig. 9 may enable the control module 520 and ingress node 510 to provide resource allocation, or determine an amount of bandwidth, for ingress node 510 that may utilize both pass-through data transfer and store-and-forward data transfer for data transfer. By configuring the allocation look-up table or algorithm, the resource allocation may be adjustable and set to provide a balance and trade-off between the immediacy of transferring pass-through data and the desire to avoid undue delays in transferring store-and-forward data. The logic of fig. 9 may be used to avoid bandwidth starvation under certain traffic scenarios and device configurations. The logic of fig. 9 may also allow the control module 520 and the ingress node 510 to adjust and dynamically control the resource allocation of the ingress node 510 to change as ingress node parameters change.

Fig. 10 is a flow diagram of exemplary logic for transferring data. The logic may be executed, for example, by the control module 520 of the ingress node 510. Logic may be used to determine when the bandwidth allocation of ingress node 510 is sufficient to transmit a data segment to the egress node using pass-through data transmission. The logic may begin at block 1000.

In block 1002, an ingress node (such as ingress node 510) may receive a data segment. The data segments may be the same, similar or analogous to data 560. A data segment may be a portion of data or a piece of data from a larger data packet. The data segment may be destined or intended to be sent to a destination egress port (such as an egress port of egress node B535). The control module 520 or the ingress node 510 may analyze the data segment. The control module 520 may determine a destination egress port for the received data segment and/or a bandwidth required to send or transmit the data segment to the destination egress port.

In block 1004, the ingress node 510 or the control module 520 may determine whether the destination egress port is eligible to receive the data segment in a pass-through mode of data transfer. The control module 520 can determine whether a destination egress port is eligible to receive data segments in a different manner in a pass-through data transfer or data transfer mode, such as by receiving an indication from a central controller of a system, such as the system 505, or by receiving information from egress ports and other ingress nodes and analyzing the information. The pass-through data transfer or data transfer mode may include transferring a data segment of a larger data packet to the egress port before the remaining portion of the larger data packet has been received at the ingress port. The pass-through data transfer or mode may include transferring the data segment to the egress port without storing the data segment in a buffer or internal memory of the receiving ingress node.

In block 1006, the ingress node 510 or the control module 520 may identify the bandwidth allocation of the ingress node 510 (or the amount of ingress node bandwidth used to transmit pass-through data or store-and-forward data). The ingress node 510 or the control module 520 may perform one or more functions or run a portion or all of the logic of fig. 9 to determine the bandwidth allocation of the ingress node 510. The bandwidth allocation may indicate or identify a portion or amount of bandwidth used by an ingress node that may be configured or operable to transmit data to an egress node using a different mode or type of data transmission, such as direct or store-and-forward. The bandwidth allocation may indicate or identify an amount of bandwidth of the ingress node 510 or a number of ingress ports of the ingress node 510 that may be configured or operable to transmit data to an egress node or egress port (such as a destination egress port) using pass-through data transmission.

In block 1008, the ingress node 510 or the control module 520 may determine whether the bandwidth allocation identified in block 1006 may support, allow, or be sufficient to utilize pass-through data transmission to transmit the received data segment. The ingress node 510 or the control module 520 may compare the bandwidth required to transmit an immediate data segment (such as by a pass-through data transmission or data transmission mode) to the egress port with the available bandwidth allocated for immediate or pass-through data transmission. The bandwidth required to immediately transmit the data segment to the egress port may be or may represent a threshold, whereby the available bandwidth may need to be greater than before the data segment is allowed to be transmitted to the egress port using pass-through data transmission. The threshold may be approximately zero so that any amount of bandwidth available for transmitting pass-through data may be greater than the threshold level.

The logic of block 1010 may be performed if the allocated bandwidth supports, allows, or is sufficient to utilize pass-through data transfer to transfer the data segment to the egress node (such as if the allocated bandwidth is greater than a threshold, such as an amount of bandwidth required to transfer the data segment utilizing pass-through data transfer). The ingress node 510 or the control module 520 may immediately transmit the data segment to the destination egress port using the allocated amount of ingress node bandwidth using a pass-through mode or type of data transmission.

If instead the allocated bandwidth does not support, allow, or is insufficient to utilize pass-through data transfer to transfer the data segment to the egress node (such as if no amount of ingress node bandwidth is available to perform data transfer utilizing pass-through data transfer), the logic of block 1012 may be performed. The ingress node 510 or the control module 520 may store the data segments in a memory or buffer, such as buffer 515 or ITM 415. The ingress node 510 and the control module 520 may store subsequent segments of the same packet in the buffer 515 or the ITM415 until the entire packet has been received and/or stored. Once the entire packet has been received at ingress node 510 and ingress node 510 has bandwidth to transmit the packet to an egress port using store-and-forward mode of data transmission, the data may be transmitted to the egress port using store-and-forward data transmission.

In certain variations, the logic of FIG. 10 may include more or fewer blocks or functions. In some variations, one or more blocks may perform different functions, or one or more blocks may be combined into fewer functions or determinations. In certain variations, one or more blocks or functions may be performed in a different order or concurrently. For example, in a variation, blocks 1006, 1008 may be performed or executed prior to block 1004. Various other examples and variations of logic are possible.

The logic of fig. 10 may enable the control module 520 and ingress node 510 to determine when a received data segment may be transmitted using a pass-through data transmission or a store-and-forward data transmission. The logic of fig. 10 may also or alternatively indicate or determine how much ingress node bandwidth is available to transmit the data segment. Resource allocation may provide a balance and tradeoff between the immediacy of transferring pass-through data and the requirement to avoid undue delays in transferring store-and-forward data. The logic of fig. 10 may also allow the control module 520 and the ingress node 510 to quickly assess the status and bandwidth availability of the ingress node and to coordinate and dynamically control the transmission of data from the ingress node.

Control module 520 may provide a mechanism to adaptively allocate bandwidth for high bandwidth cloud devices and architectures. The control module 520 may resolve fabric access contention between scheduled data transmissions or traffic (such as store-and-forward data) and unscheduled data transmissions or traffic (such as pass-through data). The control module 520 may apply bandwidth allocation or bandwidth ratios based on the state of the ingress node 510 or other chip. The control module 520 may apply thresholds and algorithms that may offset the bandwidth used by the ingress node 510 based on monitoring the range or value of the ingress node parameter. Offsetting the bandwidth for use by the ingress node 510 using the control module 520 may enable the bandwidth ratio to be adaptively configured based on the status of the ingress node. The control module 520 may dynamically or adaptively change the data transmission order or priority of the data at the ingress node 510.

The resource allocation and/or cut-through decisions may be made in each clock cycle, or more or less frequently. The bandwidth allocation may be made upon receipt of a portion of the data, upon a change in a parameter of the node, or at various other times. The ingress node may execute one or more algorithms or functions to determine whether the data packet may be transmitted or delivered to the egress port using pass-through data transmission based on the state and parameters of the ingress node operation. These algorithms or functions may be executed in parallel on each ingress node at the same time or at approximately the same time. These methods and systems may substantially improve the efficiency of data transmission at each ingress node, may reduce the computation time of the system, and may allow data to be transmitted more quickly and efficiently through the system 105. These methods and systems may provide useful distributed functionality for cloud processing, financial departments, and social networks if low latency and high bandwidth may be needed and available to increase revenue.

The above described methods, apparatus and logic, such as an ingress node or port, an egress node or port and/or a controller or control module of an ingress node or egress node or port, may be implemented in many different ways in hardware, software or different combinations of both hardware and software. For example, all or part of the system may include circuitry in a controller, a microprocessor, or an Application Specific Integrated Circuit (ASIC), or may be implemented using discrete logic or components, or a combination of other types of analog or digital circuitry combined on a single integrated circuit or distributed among multiple integrated circuits. All or a portion of the logic described above may be implemented as instructions executed by a processor, controller, or other processing device and may be stored in a tangible or non-transitory machine-readable or computer-readable medium, such as a flash memory, a Random Access Memory (RAM) or a Read Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM), or other machine-readable medium, such as a Compact Disc Read Only Memory (CDROM), a magnetic disk, or an optical disk. Thus, an article of manufacture, such as a computer program product, may comprise a storage medium and computer readable instructions stored on the medium which, when executed in an endpoint, computer system, or other device, cause the device to perform operations according to any of the descriptions above.

The processing power of the system may be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically or physically organized in a variety of different ways, and may be implemented in a variety of ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms. A program can be a single program, a portion of a separate program (e.g., a subroutine), can be distributed across several memories and processors, or can be implemented in a number of different ways, such as in a library, such as a shared library (e.g., a Dynamic Link Library (DLL)). For example, the DLL may store code that performs any of the system processes described above.

While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible that are within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.

Claims (10)

1. A system for transmitting data, comprising:

an ingress node transmitting data at a determined bandwidth, the ingress node comprising a buffer and the ingress node operating based on monitoring node parameters; and

a controller in communication with the ingress node, the controller configured to allocate an amount of the determined bandwidth for directly transmitting data to bypass the buffer of the ingress node based on the monitoring node parameter.

2. The system of claim 1, wherein the controller is configured to identify a change in the monitoring node parameter.

3. The system of claim 2, wherein the controller is configured to adjust an amount of allocation in the determined bandwidth for direct transmission of data based on the identified change in the monitoring node parameter.

4. The system of claim 1, wherein the monitoring node parameter comprises a fill level of the buffer of the ingress node.

5. The system of claim 4, wherein the amount of allocation in the determined bandwidth for direct transmission of data varies inversely proportional to a fill level of the buffer of the ingress node.

6. The system of claim 1, wherein the monitoring node parameter comprises a period of time that the ingress node has directly transmitted a data packet bypassing the buffer of the ingress node without saving the data packet to the buffer.

7. The system of claim 6, wherein the determined amount of allocation in bandwidth for direct transmission of data varies inversely proportional to a length of time that the ingress node has bypassed the buffer of the ingress node to directly transmit a data packet.

8. The system of claim 1, wherein the ingress node comprises a set of ingress ports; and is

Wherein the ratio of the allocated amount of direct transfer data in the determined bandwidth corresponds to a ratio of a number of ingress ports of the set of ingress ports allocated for direct transfer of data bypassing memory of the ingress node to a size of the set of ingress ports.

9. A method of transmitting data, comprising:

monitoring parameters of an entry node;

allocating a first amount in the determined bandwidth of the ingress node for transmitting a data segment of a first data packet to an egress node before receiving a subsequent data segment of the first data packet at the ingress node based on the parameter;

transmitting the data segment using at least a portion of the first amount of the determined bandwidth;

allocating a second amount of the determined bandwidth for transmitting second data packets stored in the memory of the ingress node based on the parameter; and

transmitting the second data packet using at least a portion of the second amount of the determined bandwidth.

10. An ingress node, comprising:

a data transmission component configured to transmit data at a determined bandwidth;

a buffer in communication with the data transmission component and configured to store data related to a data packet;

an interface in communication with the data transmission component and configured to receive a data segment of a data packet;

a controller in communication with the data transfer component, the buffer, and the interface, the controller operable to determine a first amount of the determined bandwidth and a second amount of the determined bandwidth based on a fill level of the buffer, wherein the data transfer component uses the first amount to transfer data stored in the buffer and the data transfer component uses the second amount to transfer a segment of data to an egress node before receiving a subsequent segment of data of a data packet at the interface.