Abstract:
An egress traffic management system for a data communication system is disclosed. The egress traffic management system makes use of a hierarchical queue ID header paradigm that enables data packets to be directed for egress traffic management to either one of a plurality of assignable queues in a main egress queue module or to one of a plurality of distributed queue modules via a common queue of the main egress queue module. This behavior enables egress traffic management functionality and scale to be varied independently and in a cost-effective manner to meet evolving requirements of a data communications system.

Description:
FIELD OF THE INVENTION 
       [0001]    The invention is directed to communication networks, particularly to providing flexibility in both scale and functionality of egress traffic management in a data communications system. 
       BACKGROUND OF THE INVENTION 
       [0002]    One of the challenges in designing state of the art traffic management systems is that often the cost of the traffic management circuitry becomes a “barrier to entry”. This is especially the case for egress traffic management, which term refers to management of data packet traffic flows exiting a data communication system such as a data packet switch or router. Specifically, many traffic management schemes have a centralized egress queuing point from which traffic is scheduled. This results in traded-offs relating to cost and flexibility of future applications. 
         [0003]    One problem is that the scale of the traffic management requirements needs to be determined ahead of time and designed into the data communication system. These requirements are often related to supporting many applications, some of which are unique to various customers. Some of the main factors in this regard are the depth of memory, the number of queuing entities, and the number of virtual output ports used for egress traffic management. Often, the cost of satisfying these requirements makes it difficult to meet low “Cost of Entry” market demands. Furthermore, if the scale of traffic management requirements has been met in the most cost-effective manner, then often there is not enough flexibility in the egress traffic management functionality to support new applications. 
         [0004]    Accordingly, there is a need for an egress traffic management system that provides flexibility in both scale and functionality of egress traffic management in a cost-effective manner. 
       SUMMARY OF THE INVENTION 
       [0005]    It is an object of the invention to provide an egress traffic management system for a data communication system. 
         [0006]    According to an aspect of the invention an egress traffic management system for a data communication system is provided. The egress traffic management system includes a packet processor that is operable to receive a data packet from a switch fabric and to affix an egress queue header to the data packet; a main egress queue module having a set of internal queues for data packets and that is operable to receive the data packet from the packet processor and to forward the data packet to one of the internal queues depending upon a main queue identifier of the egress queue header; and an interface module that is operable to receive the data packet from the main egress queue module and to forward the data packet to either a main input/output module or one of a plurality of distributed queue modules in accordance with a secondary queue identifier of the egress queue header. 
         [0007]    Preferably, the set of internal queues includes a common queue and a plurality of assignable queues. Accordingly, the main queue identifier provides either an identifier of one of the assignable queues to which the data packet is to be forwarded or provides an indication that the data packet is to be forwarded to the common queue. 
         [0008]    Advantageously, one or more of the assignable queues may be specific to a customer, a network, a virtual local area network, or an application. 
         [0009]    According to another aspect of the invention a method of egress traffic management of data packets in a communications system is provided. The method comprising the steps of: receiving a data packet from a switch fabric; affixing an egress queue header to the data packet; determining whether to forward the data packet to one of a plurality of internal queues of a main egress queue or to forward the data packet to one of a plurality of distributed queue modules depending upon a main queue identifier of the egress queue header; and forwarding the data packet according to the determination. 
         [0010]    Embodiments of the invention provide a “pay as you grow” aspect to egress traffic management that enables egress traffic management functionality and scale to be varied independently and in a cost-effective manner to meet evolving requirements of a data communications system. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    The invention will be further understood from the following detailed description with reference to the drawings, in which: 
           [0012]      FIG. 1  is a high-level functional block diagram of an egress traffic management system according to an embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0013]    Referring to  FIG. 1 , a high level block diagram of an egress traffic management system  10  in accordance with the present invention is depicted. The FIGURE also shows a switching fabric  12 , which supplies data packets to the egress traffic management system  10  but does not form part thereof. 
         [0014]    The egress traffic management system  10  includes a packet processing module  14  coupled to a main egress queue module  16 . The packet processing module  14  receives data packets P from the switch fabric  12 , affixes an egress queue header H to each data packet, and then sends the modified data packets P′, P″ to the main egress queue module  16 . The main egress queue module  16  includes a set of internal queues  11  for data packets P′, P″. The set of internal queues  11  includes a common queue  13  and a plurality of customer-specific queues  15 . The customer-specific queues  13  could be considered generally as assignable queues since one or more of them could be assigned to a particular customer, network, virtual local area network, or an application. 
         [0015]    The egress queue header H includes a main queue ID M and a secondary queue ID S. The secondary queue ID S could also be viewed as an embedded queue ID with regard to the main egress queue module  16  since the secondary queue ID S is transparent to the main egress queue module  16  in that it does not affect the operation thereof. The main queue ID M is used to direct a data packet P′ to a main input/output module  20  via one of the customer-specific queues  15  or to direct a data packet P″ to the internal common queue  13 . The secondary queue ID S is used to direct a data packet P″ to a distributed queue module  22 ,  24 . The main egress queue module  16  removes the main queue ID M before forwarding the data packet P, P′″. 
         [0016]    The various forms of data packets shown in  FIG. 1  and referred to hereinafter will now be described for greater clarity. The first form P is a data packet without any egress queue header H. The second form P′ includes an egress header H that has a main queue ID M but no secondary queue ID S. The third form P″ is a data packet having an egress queue header H that includes a main queue ID M and a secondary queue ID S. The fourth form P′″ is a data packet having an egress queue header H that includes a secondary queue ID S but no main queue ID M. 
         [0017]    The main egress queue module  16  is coupled to an interface module  18 . This coupling provides a path for data packets P′, P″ and for backpressure information BP. The main egress queue module  16  receives data packets P′, P″ from the packet processing module  14 . Based on the main queue ID M of each data packet P′, P″, the main egress queue module  16  either forwards the data packet P′ to one of the customer-specific queues  15  associated with a specific customer traffic flow or directs the data packet P″ to the common queue  13 . In the case of the latter the data packet P″ would subsequently be directed to one of the distributed queue modules  22 ,  24  based on the secondary queue ID S. In either case, after the main egress queue module removes the main queue ID header M resulting in data packets P, P′″, those data packets would be sent to the interface module  18  before being transmitted to a distributed queue module  22 , 24  or a main input/output module  20 . 
         [0018]    The packet processing module  14  determines the content of each egress queue header H, and thereby whether the corresponding data packet P is to be forwarded to one of the internal customer-specific queues  15  or to a distributed queue module  22 ,  24  based on the egress traffic management functionality that is to be applied to a particular packet, according to information contained in the packet and/or information about a traffic flow to which the data packet belongs. 
         [0019]    The interface module  18  receives data packets P from the customer-specific queues  15  and sends such data packets to the main input/output module  20  coupled thereto. The interface module  18  also receives data packets P′″ from the common queue  13  and forwards each one of such data packets to one of the distributed queue modules  22 ,  24  in accordance with the secondary queue ID S of each of the data packets. 
         [0020]    The interface module  18  is connected to a plurality of distributed queue modules  22 ,  24 . This connection provides a path for data packets P′″ to respective distributed queue modules  22 ,  24 . The distributed queue modules  22 ,  24  each receives data packets P′″ from the interface module  18  and remove the secondary queue ID S before transmitting the data packets P′. The distributed queue modules  22 ,  24  are each connected to a respective input/output module  26 ,  28 . This connection provides a path for data packets P and for flow control information FC 1  to FCN to provide flow control capability with respect to the flow of data packets P from distributed queue modules  22 ,  24 . The main input/output module  20  is also connected to the interface module  18 . This connection provides a path for data packets P and flow control information FC to provide flow control capability with respect to the flow of data packets P from the customer-specific queues  15 . In this case, the interface module  18  may provide some translation of the flow control information FC before communicating the backpressure information BP to the customer-specific queues  15 . For example, such translation would be required in a case where the main input/output module  20  provides one method of flow control information FC but the main egress queue module  16  requires a different method of backpressure information BP. Both of the flow control information FC and backpressure information BP may include information such as information on traffic flows of multiple priorities, fill levels of virtual output queues, etc. 
         [0021]    The operation of the flow control functionality will now be explained in greater detail for the case in which data packets of a traffic flow are queued in the common queue  13  and for the case in which data packets of a traffic flow are queued in one of the customer-specific queues  15 . In the latter case, the data packets would be transmitted from the data communications system via the main input/output module  20 , which could have multiple ports of which one is experiencing backpressure. This port could be specific to a customer that has a traffic profile which the flow of data packets from the port must be within and which is being exceeded, hence the backpressure situation. Under this and similar scenarios, the main input/output module  20  would generate flow control information FC that would be communicated back to the particular one of the customer-specific queues  15 , which is associated with the port experiencing backpressure. This flow control information FC would be communicated via the interface module  18  and the backpressure information BP to the main egress module  16 . The flow control information FC and backpressure information BP would contain an indication of the port that is experiencing backpressure and hence make it possible to determine which one of the customer-specific queues should apply flow control to the traffic flow. In the case where data packets of a traffic flow are queued in the common queue  13 , a distributed queue module  22 ,  24  that is transmitting those data packets from a port that is experiencing backpressure would generate corresponding flow control information FC 1 , FCN. This flow control information FC 1 , FCN would contain an indication of the specific port that is experiencing backpressure if the distributed input/output module  26 ,  28  had more than one port. The flow control information FC 1 , FCN would be communicated back to corresponding distributed queue module  22 ,  24 , which would apply flow control to that traffic flow. 
         [0022]    The egress traffic management system  10  in its most basic form would include only the packet processing module  14 , the main egress queue module  16 , and the interface module  18 . The main input/output module  20  is not considered to be part of the egress traffic management system  10 . The egress traffic management system  10  in a more scaled-up form would include one or more of the distributed queue modules  22 ,  24 . This form can be attained by adding one or more distributed queue modules  22 ,  24  to a more basic form. This expansion could be done for example if egress traffic management capacity and/or functionality requirements have increased from those that were satisfied by a more basic form. This capability is referred to as the “pay as you grow” aspect of embodiments of the invention 
         [0023]    The operation of the egress traffic management system  10  will now be further explained in the case where one or more distributed queue modules  22 ,  24  are included. The main queue ID M affixed to a data packet P by the packet processing module  14  provides either an identifier of one of the customer-specific queues  15  or the common queue  13 . In the case of the latter, the main egress queue module  16  removes the main queue ID M from the data packet P″ before transmitting the data packet P′″ to the interface module  18 . Receiving such a data packet P′″, the interface module  18  examines the secondary queue ID S. The secondary queue ID S provides an indication of one of the distributed queue modules  22 ,  24  to which the data packet P′″ is to be sent. Upon receiving a data packet P′″ from the interface module  18 , the receiving distributed queue module  22 ,  24  queues the data packet P′″ according to the secondary queue ID S and later removes the secondary queue ID S before forwarding the data packet P to a corresponding input/output module  26 ,  28  to which it is connected. The corresponding input/output module  26 ,  28  subsequently transmits the data packet P from the data communication system via one of its ports. 
         [0024]    It should be understood that the foregoing description of operation is not intended to limit the interface module  18  to examining only the secondary queue ID S to determine to which distributed queue module  22 ,  24  the data packet P′″ is to be sent. Other information associated with the data packet P′″ such as port context, bus address field, or bits in a header of the data packet P could be used. 
         [0025]    It should be noted that one or more distributed queue modules  22 ,  24  can be added to the egress traffic management system  10  up to a maximum number that are supported by the data communication system. A set of indications such as labels that provides an indication of distributed queue modules  22 ,  24  that are present in the egress traffic management system  10  is stored therein or otherwise made available to the packet processing module  14 . The set of indications would include an indication of any queues contained in one or more of such modules, or would make derivation of such contained queues possible. The packet processing module  14  is therefore operable to select or otherwise determine one indication from the set of indications before affixing the egress queue header H to a data packet P so as to provide a secondary queue ID S. The actual selection mechanism used by the packet processing module  14  would depend on the egress traffic management functionality that is to be applied to a particular data packet P, according to information contained in the data packet P and/or information about a traffic flow to which the data packet P belongs. 
         [0026]    An advantage of embodiments of the invention is that an “entry level” main egress queue module  16  can be designed with, for example, a fixed amount of queuing and fixed number of virtual output queues, without the main egress queue module  16  becoming a bottleneck to future growth of the data communication system. Distributed queue modules  22 ,  24  could then be added to increase the amount of buffering and number of virtual output queues outside of the main egress queue module  16  with growth of the data communications system. Further, the main egress queue module  16  can be used for common functions that are not intensive so that these functions do not need to be replicated in the distributed queue modules  22 ,  24 . 
         [0027]    The egress queue header H, via its main queue ID M and secondary queue ID S, supports a hierarchical queue ID header paradigm. This “queue ID within a queue ID” model allows existing distributed queue modules  22 ,  24 , possibly implemented on separate circuit cards, to be used and yet at the same time enables benefits to be derived from feature enhancements in the main egress queue module  16 . This model removes restrictions of a pre-determined queue ID structure and allows parts of the main and distributed queuing architecture (i.e. main egress queue module  16  and distributed queue modules  22 ,  24  respectively) to be changed as customer feature set demands change. For example, additional distributed queue modules  22 ,  24  could be added to the architecture, the main egress queue module  18  and any of the existing distributed queue modules  22 ,  24  could be replaced with versions having enhanced functionality, or any combination thereof. Furthermore, it should be appreciated that the number of levels of embedded queue IDs is not limited to 1. For example, an additional third queue ID in the egress queue header H after the secondary queue ID S could be used to indicate another queue module, subtended from one of the distributed queue modules  22 ,  24 , to which a data packet is to be queued before being sent to an input/output module. 
         [0028]    While the invention has been described with respect to specific embodiments, many modifications, variations, substitutions, and equivalents will be apparent to those skilled in the art. For example, the common queue  13  could comprise multiple queues, each for traffic flows of data packets of a certain priority. Similarly, the main input/output module  20  could comprise a plurality of input/output modules that collectively function as a main input/output module  20 . Accordingly, the invention is to be considered as limited only by the spirit and scope of the appended claims.