Allocation of asymmetric priority to traffic flow in network switches

[0002] This invention relates to switches for packet-based data communication networks wherein messages in the form of addressed data packets are conveyed from, for example, user to server and from server to user by way of at least one switch which can respond to address data within a packet to determine an egress port or ports. The invention more particularly relates to the allocation of priority to different classes of traffic.

[0003] Data packets of the kind to which the invention relates are intended to conform to the OSI model in that they will normally include source and destination media access control addresses, otherwise known as ‘layer 2’ addresses in the OSI model, network or protocol addresses of the entities which are communicating, further information, called herein ‘higher layer’ information identifying for example the ‘application’ which the entities are operating to exchange information, message data and, conventionally, cyclic redundancy code data. As is well known, not all packets will conform to such a format precisely, since the exchange of information between entities, such as a user and a server, may require initially the discovery of appropriate address data by means of an address resolution protocol, but it is assumed in the following that two entities have begun to exchange data using packets conforming to the aforementioned general format.

[0004] In order to ameliorate the effects of congestion in networks, it is customary for different types of traffic to be accorded different priority levels. For example, control frames or packets sent by a management entity to a particular designation may be accorded a high priority whereas other traffic may be accorded a low priority. Once a given type of traffic is allocated a particular priority, tile priority may be indicated and implemented in a variety of ways. Which of these is selected is not important to the present invention. Some ways of implementing it will be discussed in relation to a specific example.

[0005] For a variety of different applications, for example those relating to HTTP (hypertext transmission protocol) the bandwidth requirement for traffic from the server to the ‘client’ far exceeds the requirement for bandwidth from the ‘client’ to the server. Typically the ratio of the requirements for bandwidth is 5 to 1 or greater. Where conversations (the exchange of messages) are allocated the same priority in both directions there is a substantial waste of the bandwidth allocated to the messages passing from client to server.

[0006] The present invention is based on the detection of the commencement of a conversation by recourse to higher layer information, that is to say layer 4 or above, to provide storage of the source port associated with the message and to allocate traffic which passes through the switch with a destination port equal to the stored or latched source port a higher priority. That technique will allow server-client traffic to have a higher priority than client server traffic and avoid the wastage of bandwidth noted above.

[0007] Further features and benefits of the present invention will become apparent during the following detailed description with reference to the accompanying drawings.

[0008] FIG. 1 is an explanatory diagram of a packet-based network showing different types of traffic therein.

[0009] FIG. 2 is another diagram of the network showing the modification of priority allocated to certain types of traffic.

[0010] FIG. 3 is a generally conventional diagram of a switch within which the invention may be implemented.

[0011] FIG. 4 is a diagram illustrating the determination of a transit priority in a switch.

[0012] FIG. 5 is another diagram illustrating the use of the transit priority.

[0013] FIG. 6 is a diagram of a ‘quality of service’ classification.

[0014] FIG. 7 is a schematic diagram illustrating the implementation of the invention.

[0015] FIG. 8 is a flow diagram of a process according to the invention.

[0016] FIG. 1 of the drawings illustrates in simplified form a network including a switch 10, for example a switch capable of operating at 100 megabits per second or 1000 megabits per second, disposed between a client, for example a user terminal such as a personal computer, and a server 11. Traffic flowing between the client and the server is shown as traffic 13 in the section between the client 12 and the switch 10 and as traffic flow 13abetween the switch 10 and the server 11. The course which is also shown as receiving traffic 14 from a voice source and traffic 15 from a ‘business critical’ source.

[0017] For the sake of example, the traffic 13, 13ais shown as ‘HTTP’ traffic, arising from a request by the client to a web site for information thereon and the provision of information from the web site, handled by server 11.

[0018] It is assumed just for the sake of example that the voice traffic 14 has a priority ‘3’, the ‘business critical’ has a priority 4 and the HTTP conversation between server and client has a priority 5 (the highest).

[0019] It is customary for switches such as core switch 10 to include a variety of conversation tables, identified by source/destination pairs and to allocate priority to those conversations. Such priority may be determined by an examination of protocol data within the packets as discussed for example in GB patent application number 9908125.9. Nevertheless priority may be imposed for certain types of traffic by means of a network administrator.

[0020] Where traffic is allocated on a source/destination (conversation) basis, it is symmetric, in that no distinction is drawn between traffic from client to server and traffic from server to client, thus, if HTTP traffic is allocated priority 5, it will have that priority for both directions, as shown in FIG. 1.

[0021] FIG. 2 illustrates the intended effect of the present invention, in that the traffic 13 passing from client to switch will necessarily be set with a low priority but on the detection of an HTTP conversation the traffic from switch to client will be allocated a priority ‘5’.

[0022] As will be made apparent later, the present invention may be implemented in practice by means of ‘snooping’ on packets which pass through a switch so as to detect the start of a conversation denoted by an HTTP (hypertext transmission protocol) packet from the client to the server, latching the value of the destination port and employing that detection to latch a source port number (normally but not essentially a 16-bit number) so that this latched port number can be compared with a destination port in a packet of a ‘server to client’ conversation and on detection of a match to set a higher priority for the server/client messages. Before that process can be fully explained, it is expedient to describe the general features of a switch in which the present invention can be performed and also to explain the manner in which priority may be allotted in a switch of that nature.

[0023] FIG. 3 illustrates for the sake of example a typical switch 40 within which the invention may be performed. A core switch such as switch 10 commonly has a larger multiplicity of ports but for the sake of simplicity the switch 40 shown in FIG. 3 has four ports 41, 42, 43 and 44. Each of these is associated with a respective port ASIC 41ato 44arespectively. The port ASICs each have some means of applying priority to traffic passing through the switch. The switch includes a memory 45 for the temporary storage of packets between the time they are received and are forwarded to their respective port or ports. The forwarding of packets is controlled by means of a forwarding database 46 (relating destination addresses with specific port numbers). The forwarding database is accessed by means of a look-up engine 49 which operates in conjunction with a switching engine 48 to retrieve packets from memory 45 and to direct them to their respective locations. The allocation of priority to switches is shown schematically by a priority block 50. The snooping of packets between the port ASIC and memory 45 is shown by the snoop block 51 and the control of the ASICs by means of priority block 50 is shown by arrow 52. The port ASICs 41-44, memory 45, forwarding database 46, switching engine 48, look-up engine 49, priority block 50 and snoop block 51 are connected to each other through bus 47.

[0024] FIG. 4 illustrates how a packet passing through a switch is allocated a ‘transit priority’ which it carries through the system. Such a transit priority is used (as is well known in itself) to determine the priority of transmission of packets from the switch or from individual ports by means of transmit queues which are allocated different priorities and which can be selected in accordance with the transit priority. The internal transit priority can be mapped to a priority field, specifically a 802.1q field for an Ethernet packet if the packet is to be sent out on a link which is configured for the transmission of packets containing a priority tag field. FIG. 4 illustrates in particular how the priority of a packet is determined having regard to various priority values associated with different fields in the header of the packet and other indications of priority.

[0025] In FIG. 4, the numeral 60 denotes in simplified form part of an Ethernet packet and particularly part of the header of it. Typically an Ethernet packet contains ‘layer 2’ information constituted by destination address data (which may be a single destination MAC address in the case of a unicast packet or a group address in the case of a multicast packet), a source MAC address and, in this example, an 802.1q tag which defines a priority for the packet in terms of a 3-bit field, the value corresponding to zero representing the lowest priority. The packet 60 also contains ‘layer 3’, or ‘IP’ data which may comprise an IP or network destination address and source address and which, in this example, contains a network priority field known as a DSCP (Differential Services Code Point) field conventionally consisting of a 6-bit field. Further, the packet contains higher layer information, particularly in this example ‘layer 4’ information in the form of UDP/TCP destination and source port numbers, shown in packet 60 by the legends ‘DestPort’ and ‘Src Port’ respectively.

[0026] Furthermore, the port on which the packet is received may have a priority allotted to it.

[0027] In the present example, a multiplexer 61 receives at one input a priority value which represents the default priority 62 of the port on which the packet was received. The packet is ‘parsed’ that is to say routinely examined to determine whether it has an 802.1q tag, and, if the packet has such a tag, a relevant signal is asserted on a select line 63 to allow multiplexer 61 to select the priority determined in the 802.1q tag field instead of the default priority associated with the receiving port. The priority value obtained at the output of multiplexer 61 is converted by a mapping table 64 to an internal priority. This priority is hierarchical so that the greater the number the higher the priority. If the table receives at its input a value which is not applicable, for example from an non-IP frame, then it sets an internal priority at the lowest value (zero).

[0028] A decision circuit 65 is arranged to choose the higher priority obtained from the mapping table 64 and a further mapping table 66 which converts the DSCP value to a 3-bit internal priority. The value selected by decision circuit 65 will become the transmit priority unless an examination of layer 4 (or higher layer) source and destination address yields a match as about to be described.

[0029] The values ‘DestPort’ and ‘SrcPort’ obtained from the ‘layer 4’ fields in packet 60 are coupled to a port table 67 which has the effect of an associative store indexed on the (16-bit) port number. If the port is found in the table then the result is a 3-bit priority value. This port priority will override the priority value obtained from the ‘media access control’ and protocol priorities. Thus if there is a match in the port table a multiplexer 68, which has a default setting to choose the output of decision circuit 65 is controlled to select tile priority value obtained from the port table 67. The result at the output of multiplexer 68 is a ‘transit’ priority which is always a 3-bit number. The advantage of this is that it allows a simple re-mapping to an appropriate 802.1q field on a packet output from the switch.

[0030] FIG. 5 shows how a transit priority may typically be used in a switch. The transit priority value appears on a line 70 and is coupled to a multiplicity of registers (71 to 75). These define various bit masks and are accessed by the transit priority. Register 71 is the Rx link table priority select mask which provides priority for extracting packets from a receive queue Register 74 is a mapping of a transit priority to an 802.1p priority mapping table. Register 73 provides priority on a ‘cascade’. Register 74 provides a mask for a transmit queue and register 75 provides a Tx low loss/normal loss select mask.

[0031] TCP/UDP port number matching may also be used for quality of service support, as shown in FIG. 6. Received packets 80 may be parsed to make available various data relating to the packet, particularly the source port, the 802.1d COS (Conditions of Service), the DSCP, the TCP-UDP ports, the MAC address and the IP address. Which of the relevant data is selected depends upon selection rules as shown by block 82. The DSCP priority may be fed out on line 83 or connected to registers 84, 86 to provide the PHB 85 (Per Hop Behaviour) for use by the switching engine or the COS value 87 for use when re-marking.

[0032] There are therefore a variety of schemes for controlling priority within a switch from the transit priority.

[0033] FIG. 7 illustrates the manner in which a packet may be snooped in order to provide a different priority which may be superimposed on the existing priority schemes. An HTTP packet from a client to a server is snooped as shown by line 31 which provides an enable for a set of 16 flip flops constituting a register 30 which is used for latching the source port provided on line 32 for the switch. The saved application port number provided on line 33 can be compared in comparator 34 with ‘destination’ ports of packets proceeding from server to client on line 35 to provide on line 36 a higher priority for a download.

[0034] In practice, FIG. 7 is integrated with the scheme shown in FIG. 5 by including (or storing) the latched source port number in table 67, so that the function of the comparator is performed by the look-up process associated with the table. Alternatively the latched source port number may be included in the ‘TCP/UDP ports’ data in block 81 of FIG. 6.

[0035] FIG. 8 illustrate the process of the present invention. Stage 90 is the snooping on packets, stage 91 the detection of the start of an HTTP conversation, stage 92 the latching of the source port, stage 93 the detection of a server/client conversation, stage 94 the obtaining of the destination port, stage 95 the comparison of the destination port with the latched port and finally stage 96 represents the setting of priority.