Systems and methods for performing selective flow control

FIELD OF THE INVENTION

0001The present invention relates generally to communication networks and, more particularly, to systems and methods for controlling the flow of traffic in an Ethernet-based communication network.

BACKGROUND OF THE INVENTION

0002Service providers commonly find it valuable to allow bursty traffic from customers into the communication network and, similarly, from the network towards customers. To accommodate these traffic bursts, service providers often set a guaranteed service rate and a maximum burst rate in a service contract (e.g., a Service Level Agreement). The service provider may guarantee a fixed rate for the services provided to the customer, but also allow the customer to transmit or receive information at a higher rate, up to the maximum burst rate, when there are accommodating resources in the network.

0003Due to the increased volume of traffic associated with these bursts, devices in the network, such as a switch, may become congested. Conventional Ethernet networks lack the necessary control mechanisms for handling bursty traffic while still maintaining the intrinsic benefits of the Ethernet networking technology. Many current designs use a buffer to hold excessive traffic when there is congestion or a need for congestion avoidance downstream, and transmit the buffered traffic at the available downstream capacity. Such a design introduces the following drawbacks, however. Since buffer size is limited, packet loss may be experienced in those situations where the excessive traffic causes the buffer to overflow. Such packet loss leads to an unfavorable impact on the service contract. Moreover, buffering introduces delay and delay variation, which may degrade the quality of the services supported.

0004Another conventional approach to handling bursty traffic involves the use of PAUSE messages, as defined in IEEE Std 802.3, 2000 Edition. In this approach, when a network device detects congestion on an outgoing link, the network device automatically sends a PAUSE message to all upstream devices to which the network device is connected, indicating that the flow of traffic from those upstream devices should temporarily cease. Upon receipt of the PAUSE message at the upstream devices, each device automatically transmits a PAUSE message to each other upstream device to which that device is connected, and so on.

0005This approach also has some drawbacks. For instance, assume that a customer's network devices are operating at or below the guaranteed service rate defined in their Service Level Agreement. If a network device that is downstream of the customer's devices experiences congestion or receives a PAUSE message, that device will automatically transmit a PAUSE message to the customer's devices causing the devices to temporarily stop transmitting packets. Since the customer's devices are operating at or below their guaranteed service rate, the downstream device unnecessarily restricts the flow of traffic from the customer's devices. Requiring network devices that are operating within their guaranteed service rate to temporarily stop transmitting packets leads to an unfavorable impact on the service contract.

0006Accordingly, there is a need in the art for systems and methods that improve flow control in an Ethernet-based networking environment.

SUMMARY OF THE INVENTION

0007In accordance with the principles of this invention as embodied and broadly described herein, a method controls the flow of traffic in a network including a group of nodes. The method includes receiving, from a downstream node, a flow control message indicating that a flow of traffic is to temporarily cease, determining an appropriate flow control action based on at least one of a set of control policies, and performing the appropriate flow control action.

0008In an implementation consistent with the present invention, a network device includes an input interface that receives a flow control signal, a memory that stores a set of predetermined control policies, and flow control logic. The flow control logic determines a flow control action based on the set of policies and causes the flow control action to be performed.

BRIEF DESCRIPTION OF THE DRAWINGS

0009The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, explain the invention. In the drawings,

0010<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary network in which systems and methods, consistent with the present invention, may be implemented;

0011<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary configuration of node C of <figref idref="DRAWINGS">FIG. 1</figref> according to an implementation consistent with the present invention;

0012<figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary process for performing selective traffic flow control according to an implementation consistent with the present invention; and

0013<figref idref="DRAWINGS">FIG. 4</figref> illustrates an exemplary alternative process for performing selective flow control according to an implementation consistent with the present invention.

DETAILED DESCRIPTION

0014The following detailed description of implementations consistent with the present invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and equivalents.

0015Implementations consistent with the present invention provide systems and methods for selectively performing flow control in a communication network. According to one implementation, when a network device receives a flow control signal from a downstream device, the network device determines the appropriate flow control action to be performed based on a predetermined set of control policies.

EXEMPLARY NETWORK

0016<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary network <b>100</b> in which systems and methods, consistent with the present invention, may be implemented. As illustrated, the network <b>100</b> includes host devices <b>110</b> and <b>120</b> and several interconnected nodes <b>130</b>. Two host devices <b>110</b> and <b>120</b> and six nodes <b>130</b> have been shown for simplicity. A typical network may include more or fewer host devices and nodes. While the host devices <b>110</b> and <b>120</b> and the nodes <b>130</b> are illustrated as separate devices, it will be appreciated that in some implementations consistent with the present invention, a host device may perform the functions of a node and a node may perform the functions of a host device.

0017The host devices <b>110</b> and <b>120</b> may include devices, such as mainframes, minicomputers, personal computers, laptops, personal digital assistants, or the like, capable of transmitting data through the network <b>100</b>. The host devices <b>110</b> and <b>120</b> may be connected to the nodes <b>130</b> via a wired or wireless connection (including optical).

0018The nodes <b>130</b> may include one or more devices for receiving and transmitting data in the network <b>100</b>. In an exemplary implementation, the nodes <b>130</b> may include a Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) transport node, an Ethernet switching node, or an Internet Protocol/Multiprotocol Label Switching (IP/MPLS) routing/switching node.

0019<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary configuration of node C <b>130</b> of <figref idref="DRAWINGS">FIG. 1</figref> according to an implementation consistent with the present invention. In this exemplary implementation, node C <b>130</b> operates as an Ethernet switch. It will be appreciated that the processing described below is equally applicable to other node configurations. Nodes A, B, and D-F may be configured in a manner similar to that of node C <b>130</b>.

0020As illustrated, node C <b>130</b> includes interfaces <b>210</b>, <b>220</b>, and <b>240</b> and switching logic <b>230</b>. Node C <b>130</b> may include additional mechanisms (not shown) that aid in the reception, processing, or transmission of data. Three interfaces have been shown for simplicity. A typical node <b>130</b> may include more or fewer interfaces than illustrated in <figref idref="DRAWINGS">FIG. 2</figref>.

0021Interfaces <b>210</b>, <b>220</b>, and <b>240</b> may include one or more mechanisms that allow node C <b>130</b> to receive data, temporarily store data, and transmit data to a node connected to that particular interface. For example, interface <b>210</b> may include one or more buffers for storing data received from or to be transmitted to node B <b>130</b>. Interface <b>220</b> may include one or more buffers for storing data received from or to be transmitted to node D <b>130</b>. Similarly, interface <b>240</b> may include one or more buffers for storing data received from or to be transmitted to node F <b>130</b>. Interfaces <b>210</b>, <b>220</b>, and <b>240</b> may also include logic for processing data.

0022Switching logic <b>230</b> may include one or more mechanisms for processing data received via interfaces <b>210</b>, <b>220</b>, and <b>240</b> in a well-known manner and for switching the data to the appropriate interface for transmission through the network <b>100</b>. As will be described in additional detail below, switching logic <b>230</b> may also include a memory <b>232</b> for storing a set of control policies and flow control logic <b>234</b> for deciding, based on the policies, how to process flow control messages.

EXEMPLARY PROCESSING

0023<figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary process for performing selective traffic flow control according to an implementation consistent with the present invention. Assume that host device <b>110</b> (<figref idref="DRAWINGS">FIG. 1</figref>) transmits data to host device <b>120</b>. Assume further that node F enters a congested state or detects that host device <b>120</b> has entered a congested state. In response, assume that node F transmits a flow control message towards host device <b>110</b> requesting to delay sending data. Node F may also transmit a flow control message in order to avoid congestion at one or more downstream nodes. In an exemplary implementation, node F transmits a PAUSE message according to IEEE Std 802.3, 2000 Edition (Incorporating IEEE Std 802.3, 1998 Edition, IEEE Std 802.3ac-1998, IEEE Std 802.3ab-1999, and 802.3ad-2000).

0024Processing may begin with node C receiving the PAUSE message from node F [act <b>310</b>] (<figref idref="DRAWINGS">FIG. 3</figref>). Upon receiving the PAUSE message, node C may determine the type of flow control action to take, if any [act <b>320</b>]. The type of action taken may be based on a set of predetermined policies. These policies may, for example, depend on parameters that have been previously set by users/customers and/or a service provider, and on the current state of the network <b>100</b>. As described above, these policies may be stored in memory <b>232</b> or elsewhere in node C.

0025Upon receiving the PAUSE message, node C may, for example, decide to generate a corresponding PAUSE message and transmit the message to one or more upstream nodes, such as nodes B and D. In the network <b>100</b> illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, node C may decide, for example, to send a PAUSE message to only node B, to nodes B and D, or to only node D. The selection of a subset of upstream nodes may be based on the set of predetermined control policies. For example, node C may select only those upstream nodes that send traffic to node C at a rate above the respective guaranteed service rate.

0026Alternatively, node C may, upon receiving the PAUSE message, decide to take action to slow down or “PAUSE” the traffic flow to node F. In this case, node C may slow down the transmission of data to node F by reducing the rate at which data is transmitted to node F. Alternatively, node C may stop sending data to node F for a predetermined period of time or until a message is received from node F that data transmissions can resume.

0027Finally, node C may decide to take no control action at all in response to receiving the PAUSE message (i.e., node C may simply ignore the PAUSE message). Node C may, for example, decide to ignore the PAUSE message in those situations where the traffic flowing from upstream nodes are at or below the guaranteed service rates defined in the service contract.

0028Once node C has determined the flow control action to take, node C may take the appropriate action [act <b>330</b>]. That is, node C may generate a corresponding PAUSE message and transmit the message to one or more upstream nodes, slow down or pause the transmission of data to the downstream node (i.e., node F), or ignore the PAUSE message.

0029The above-described processing may vary slightly when the node that receives the PAUSE message is the device that is the source of the data. <figref idref="DRAWINGS">FIG. 4</figref> illustrates an exemplary alternative process for performing selective flow control according to an implementation consistent with the present invention. Assume again that host device <b>110</b> (<figref idref="DRAWINGS">FIG. 1</figref>) transmits data to host device <b>120</b>. Assume further that node A enters a congested state or detects its downstream node has entered a congested state. In response, assume that node A transmits a PAUSE message to host device <b>110</b> instructing host device <b>110</b> to delay sending data.

0030Processing may begin with host device <b>110</b> receiving the PAUSE message [act <b>410</b>]. Upon receiving the message, host device <b>110</b> may determine the type of flow control action to take, if any [act <b>420</b>]. The type of action taken may be based on a set of predetermined control policies. These policies may, for example, depend on parameters that have been previously set by users/customers and/or a service provider, and on the current state of the network <b>100</b>.

0031Upon receiving the PAUSE message, host device <b>110</b> may, for example, decide to take action to slow down or temporarily cease the traffic flow to host device <b>120</b>. Here, host device <b>110</b> may reduce the rate or PAUSE the transmission of traffic to node A for a predetermined period of time or until a message is received from node A indicating that data transmissions can resume.

0032Alternatively, host device <b>110</b> may decide to take no control action at all in response to receiving the PAUSE message (i.e., host device <b>110</b> may simply ignore the message). Host device <b>110</b> may, for example, decide to ignore the PAUSE message in those situations where the amount of data transmitted is at or below the guaranteed service rates defined in the service contract.

0033Once host device <b>110</b> has determined the flow control action to take, host device <b>110</b> may take the selected action [act <b>430</b>]. That is, host device may slow down or temporarily stop the transmission of data to the downstream node (i.e., node A) or ignore the PAUSE message.

CONCLUSION

0034Systems and methods, consistent with the present invention, provide selective flow control in a communication network. When a network device receives a flow control signal from a downstream device, the network device determines, based on a set of control policies, whether to propagate the flow control signal to one or more upstream devices, halt transmissions of data to a downstream device, or ignore the flow control signal. Such intelligent flow control processing improves network performance particularly in the presence of bursty traffic in any Ethernet-based networks.

0035The foregoing description of exemplary embodiments of the present invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while the above flow control techniques were described as being implemented in an Ethernet environment, the present invention is not so limited. In fact, implementations consistent with the present invention are equally applicable to any networking environment in which traffic flow control is desired. Moreover, while the flow control logic and control policies were described as being located within the switching logic of the node, the flow control logic and control policies may, in an alternative implementation, be located within the interfaces of the node.

0036It will be appreciated that the present invention can be implemented in hardware, software, or a combination of hardware and software. Thus, the present invention is not limited to any specific combination of hardware circuitry and software.

0037No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used.

0038The scope of the invention is defined by the claims and their equivalents.