1. Field of the Invention
The present invention relates generally to the field of high speed data transfer, and more specifically to methods and apparatus for efficiently implementing VoQs for different classes of service in a high speed IP router environment.
2. Description of the Related Art
Data communication networks receive and transmit ever increasing amounts of data. Data is transmitted from an originator or requester through a network to a destination, such as a router, switching platform, other network, or application. Along this path may be multiple transfer points, such as hardware routers, that receive data typically in the form of packets or data frames. At each transfer point data must be routed to the next point in the network in a rapid and efficient manner. Certain protocols or standards may be employed in transferring data from one point to another, and such standards enable hardware and software using different configurations to effectively receive and transfer the data. Such standards include, but are not limited to, standards promulgated by the ITU (International Telecommunications Union) and ANSI (American National Standards Institute).
The points through the data network operate to receive data frames or packets from various requesters and provide results or satisfy requests in an orderly and efficient manner. Frames or packets including requests for access to resources may arrive synchronously or asynchronously. Requests may be for access to multiple resources or channels or to particular sets of resources or channels.
In different applications, different incoming requests may be accorded different classes of service, some classes having higher priority than others. The data received may take different forms, including different packet sizes and related parameters. Packets may arrive from multiple queues, each packet having a specific class of service.
The problem with such a multiple class of service VoQ arrangement is that simply queuing the incoming requests in a FIFO (first in, first out) manner can result in inefficiencies, the most notable inefficiency being timing required to assess the quality of the packet, assemble the queue, and prepare the data for transfer. Such a process can require multiple seeks to memory, as received packets may be stored in memory, or enqueued, read from memory, or dequeued, and then transmitted.
Previous systems have employed a FIFO design which queues the packet upon receipt of the first bytes of a packet. This type of system can encounter delays if the packet is incomplete or interrupted. Such an imperfect packet must either be repaired or discarded, and either action decreases throughput and system performance. Alternately, systems have employed FIFO logic based on the timing of the last bits of the packet received. In many circumstances, this too can result in inefficiencies; for example, in the case of a damaged packet, packet length and error information is not available until the end of the packet. These inefficiencies, among others, result in an excessive number of memory accesses to manage the different VoQs, which is undesirable.
With the current state of internet traffic, and in view of the significant latency associated with enqueueing, dequeueing, and transmitting output queues on currently available memory devices, it would be desirable to provide a system and method that would improve the maximum attainable transmission rate of network processors, traffic managers, or other devices employing VoQs or other queuing arrangements over those systems and methods previously offered.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which:
The present design implements VoQs for multiple classes of service including requisite enqueueing and dequeueing algorithms, and provides the external memory structure for implementing VoQs. The present design may be employed in packet enqueueing and dequeueing applications where arrival time of the last byte of the received packets determines the transmission order of packets in the associated VoQ. Further, certain information that can only be generated upon receipt of the last byte of a packet, such as packet length or reception error information, can be prepended to the packet when dequeued from memory. Prepending of packet information enables either transmission or discarding of the packet earlier than previously available. The prepended information may be stored in data memory, either on-chip or remotely, in addition to the contents of the packet.
The system may be any multi-service access engine, including but not limited to a multi-service broadband access engine for ATM, IP, and Ethernet transmission over SONET/SDH streams operating at a rate between approximately 622 Mbps and 2.4 Gbps. The system provides full duplex traffic management and handles simultaneous flows of cells and/or packets in accordance with the functionality described herein. The design may also be implemented in other Layer 2 or Layer 3 products. The present design links packets belonging to the same VoQ by their last partition. The number of accesses is typically identical to the number of partitions enqueued.
The basic concept of enqueuing and building a VoQ is illustrated in
The system maintains specific information in the form of pointers associated with the partitions and packets. The information is used for enqueueing or dequeueing each VoQ. The information may be maintained in an on-chip memory, but any readily available storage mechanism known to those skilled in the art may be employed. A Head Pointer points to the memory partition containing the last partition of the packet at the beginning of one VoQ. In
The system further builds a linked list or set of linked lists in data memory. Control fields may be employed in each partition of a packet to enable and facilitate linking. In all packet memory partitions except the last memory partition of a packet, certain control fields may be employed. A Next Partition Pointer points to the next partition after the current partition. Thus, in
For the last partition of a packet, Partition 5205 in
Varying quantities of control field bits for a partition may be employed, and one implementation can be 64 bits. Control fields may include the aforementioned fields as well as fields such as packet length. Packet length can be encoded by including a number of partitions instead of quantity of bytes along with a bit indicating whether the last partition is full. If the last partition is full, it is equal size with the preceding partitions. If, however, the last partition is not full, the last byte of the partition may be used to store the number of bytes in the last partition. Three fields, namely packet length, last partition full, and last partition length, enable computation of packet length in bytes. For a one partition packet, the first and last partition uses the Next Partition Pointer control field to store the flow number or VCC number corresponding to the packet.
One example of the design for multiple VoQs is presented in
As used herein, three elements of a packet include the First Partition, the Penultimate Partition, and the Last Partition. First and Penultimate Partitions contain data and the control fields discussed above, while the Last Partition includes the reference information, is placed in the VoQ linked list 320, and is associated with the First Partition from the VoQ linked list 320. Other terminology may be employed when referring to these partitions or subgroupings of the packet. Two linked lists are thus formed, a VoQ linked list 320 and a VCC/Flow linked list linking the non-last partitions received from each flow.
The next packet received in time is Packet A received from Flow 1301. The First Partition of Packet A 331 is received, followed by Penultimate Partition of Packet A 332. The Last Partition of Packet A 333 is captured and associated with Last Partition of Packet C 313 in VoQ linked list 320, and is associated or linked with First Partition of Packet A 331 for location and transmission. The next packet received is Packet B, also received from Flow 1301. The First Partition of Packet B 334 is received, followed by Penultimate Partition of Packet B 335. The Last Partition of Packet B 336 is captured and associated with Last Partition of Packet A 333 in VoQ linked list 320, and is associated or linked with First Partition of Packet B 334 for location and transmission.
The next packet received is a single partition Packet D 341, received from Flow 3303. As a single packet, it is simply placed in the VoQ linked list 320 in its entirety with an association with the Last Partition of Packet B 336. No association from the VoQ linked list 320 is provided, and Packet D is not linked to the VCC/Flow linked list.
The next packet received in time is Packet E received from Flow 3303. The First Partition of Packet E 342 is received, followed by Penultimate Partition of Packet E 343. The Last Partition of Packet E 344 is captured and associated with Penultimate Partition of Packet D 341 in linked list 320, and is also associated or linked with First Partition of Packet E 342 for location and transmission. The next packet received is Packet F, also received from Flow 3303. The First Partition of Packet F 345 is received, followed by Penultimate Partition of Packet F 346. The Last Partition of Packet F 347 is captured and associated with Last Partition of Packet E 344 in VoQ linked list 320, and is associated or linked with First Partition of Packet F 345 for location and transmission.
Tail pointer 350 points to the tail of the linked list. The packets are linked as shown in the linked list 320 of
In a situation where each flow is assigned its own VoQ, the data structure of
From
In both
A partition may be added or received from a VoQ as follows. When the partition is not the last part of the packet, the system writes the partition into data memory using a reserved future partition address for the corresponding VCC/Flow. If the partition is the first partition of the packet, the corresponding VCC/Flow number may be written into the memory partition. The system then updates the control fields in the memory partition. When the partition is the last partition of a packet, including any single partition packets, the system can write the partition into data memory using the reserved future last partition address as indicated by the tail pointer for the corresponding VoQ. The system allocates a new free partition, updates the tail pointer, and updates the control fields in the memory partition. In the event the corresponding VoQ has no packet, the system updates the head pointer to reflect the absence of the packet.
For transmitting or removing a partition, the system initially reads the memory partition indicated by the Current Pointer. Three different situations may exist. If the partition is the same as the one indicated by the Head Pointer, and the partition is not a one partition packet, the partition is the Last Partition of the packet. The system then stores this partition, transmits the last partition of the previous packet, stores the address of the next last partition as the Head Pointer, and stores the address of the first partition of the packet as the Current Pointer. If the situation is such that the partition is the Penultimate partition, found by comparing the number of partitions that have been read and the packet length, the system stores the address in the Head Pointer as the Current Pointer and transmits the partition. In the third situation, namely any other scenario, the system stores the address of the next partition as the Current Pointer and transmits the partition. Finally, in all three situations, the system frees the transmitted memory partition.
The present system may be implemented using hardware, software, or firmware having the capability to function as described herein. One implementation is a processor having available queuing, parsing, and assembly capability, data memory, and possibly on chip storage, but other hardware, software, and/or firmware may be employed.
It will be appreciated to those of skill in the art that the present design may be applied to other systems that perform enqueueing and/or dequeueing, or that build output queues, and is not restricted to the enqueue/dequeue structures and processes described herein. Further, while specific queues, VCCs, Flows, requesters, packets, partitions, and control fields have been discussed herein, it is to be understood that more or less of each may be employed while still within the scope of the present invention. Accordingly, any and all modifications, variations, or equivalent arrangements which may occur to those skilled in the art, should be considered to be within the scope of the present invention as defined in the appended claims.
Number | Name | Date | Kind |
---|---|---|---|
6088734 | Marin et al. | Jul 2000 | A |
6088745 | Bertagna et al. | Jul 2000 | A |
6169748 | Barbas et al. | Jan 2001 | B1 |
6574231 | Leung | Jun 2003 | B1 |
6754744 | Kim et al. | Jun 2004 | B2 |
6892284 | Ling et al. | May 2005 | B2 |
6944728 | Calderon et al. | Sep 2005 | B2 |
7061867 | Huang et al. | Jun 2006 | B2 |
7154853 | Caia et al. | Dec 2006 | B2 |
20030091041 | Caia | May 2003 | A1 |
20030223442 | Huang et al. | Dec 2003 | A1 |
20030225991 | Calderon et al. | Dec 2003 | A1 |
Number | Date | Country | |
---|---|---|---|
20040131069 A1 | Jul 2004 | US |