|Número de publicación||US7372864 B1|
|Tipo de publicación||Concesión|
|Número de solicitud||US 10/211,098|
|Fecha de publicación||13 May 2008|
|Fecha de presentación||1 Ago 2002|
|Fecha de prioridad||1 Ago 2002|
|Número de publicación||10211098, 211098, US 7372864 B1, US 7372864B1, US-B1-7372864, US7372864 B1, US7372864B1|
|Inventores||Dayne A. Reast, Benjamin Hur, Sangyu Wang|
|Cesionario original||Applied Micro Circuits Corporation|
|Exportar cita||BiBTeX, EndNote, RefMan|
|Citas de patentes (30), Otras citas (4), Citada por (13), Clasificaciones (16), Eventos legales (9)|
|Enlaces externos: USPTO, Cesión de USPTO, Espacenet|
This application is related to and incorporates by reference herein in its entirety a commonly owned and concurrently filed U.S. application Ser. No. 10/211,080 entitled “Reassembly of Out-of-order Data Fragments In A Network” by Ari Birger, Dayne A. Reast and Benjamin Hur.
Segmentation and reassembly (SAR) of units of data (such as packets or cells) that are transferred between elements (also called “store and forward elements”) of a communication network is performed to break up large data units into smaller, more manageably sized data units. The need to break up a data unit may arise, for example, if the data unit is of a length greater than a maximum length permitted by a portion of the network. Once broken up, such fragments of a data unit are sequentially transmitted, may traverse different network paths, and must be reassembled at a destination.
For example, when performing voice trunking over ATM (asynchronous transfer mode) using AAL2 for narrowband services (e.g. as described in ATM Forum standard AF-VTOA-0113.000), a number of packets (called CPS packets) are generated and embedded in ATM cells that are transmitted to a remote device. CPS stands for “common part sublayer”. At the destination, a number of ATM cells are processed by a SAR device 101 (
A network processor 102 and a switch fabric 103 normally process each CPS packet retrieved by the SAR device. For example, network processor 102 may perform classification, metering and/or ATM policing of the CPS packets, collect statistics, and perform operation and maintenance (OAM) functions. Switch fabric 103 (and/or a traffic manager) provides a number of fixed size buffers for temporary storage, and also performs per-flow queuing and scheduling, implements dynamic discard thresholds and random early detection. Switch fabric 103 (and/or a traffic manager) is typically connected to other network processors either directly or via an interconnect fabric (not shown).
Instead of performing segmentation and reassembly (SAR) in hardware, these functions can be implemented in software that is programmed into network processor 106 (
Instead of using a doubly linked list, a software implementation in network processor 106 may use a number of queues also implemented in memory 105, with each queue being limited to holding multiple fragments of a single datagram. Note that in
Network processors (also called communications processors) of the type described above may perform one or more of the following functions (called “network processing functions”): parsing, searching, resolving and modifying. During parsing, a network processor analyzes and classifies the contents of the header and fields. During searching, tables are searched for a match between the content that was classified and pre-defined content and rules. During resolving, the destination and quality of service (QoS) requirements are resolved and the packet/cell is routed to its destination. During modifying, where necessary, the packet/cell is modified, e.g. certain fields (such as time to live and checksum) within the packet/cell are changed. Examples of commercially available network processors include: Intel's IXP1200, Agere's Payload Plus, AMCC's nP7250, IBM's PowerNP NP4GS3, Motorola's C-Port C-5 and Vitesse's IQ2000.
A network processor of the type described above is typically coupled to and used with a traffic manager and/or a switch fabric. Either or both devices (traffic manager and/or switch fabric) may perform one or more of the following functions: queuing and output scheduling (round robin, weighted fair queuing), policing of traffic flows to assure quality of service, traffic shaping (e.g. to meet delay or jitter requirements), statistics collection, congestion management and provisioning. Examples of commercially available devices that perform switch fabric functions include: Motorola's Q5 TMC, and AMCC's nPX5710/nPX5720 (together referred to as nPX5700).
For traffic management as well as for switching, each packet/cell must be stored in memory and later transmitted. The above-described functions may be implemented together in a chipset consisting of two chips: a traffic manager (such as AMCC's nPX5710) and a memory manager (such as AMCC's nPX5720). The just-described two chips are normally used together and frequently treated as a single device that contains queues. Such a queue-containing device may have four ports, each of which is coupled to a network processor by serial links operating at 2.5 Gbps or 10 Gbps.
Buffering of traffic is typically implemented via an external memory attached to the memory manager. Typical requirements in today's networks may require traffic up to two hundred and fifty six thousand (256K) queues to be managed. In some implementations, at any given time, only information related to a subset of these queues (e.g. up to eight thousand queues) may be cached on chip (e.g. in DDR SDRAM or RDRAM) by taking advantage of statistical multiplexing (i.e. the likelihood that the incoming traffic belongs to more than eight thousand queues is very low). Therefore, eight thousand queues (containing packets/cells) are stored in a buffering chip (such as AMCC's nPX5720) having embedded DRAM channels for example, and these queues are managed by a control logic chip (such as AMCC's nPX5710). These two chips when used together act as a switch fabric and traffic manager.
Incorporated by reference herein in their entirety are the following references:
U.S. Pat. No. 6,307,860 granted to Joffe, et al. on Oct. 23, 2001, and entitled “Systems and methods for data transformation and transfer in networks”;
U.S. Pat. No. 6,330,584 granted to Joffe, et al. on Dec. 11, 2001, and entitled “Systems and methods for multi-tasking, resource sharing and execution of computer instructions”;
U.S. Pat. No. 5,901,147 granted to Joffe on May 4, 1999, and entitled “Apparatus and methods to change thresholds to control congestion in ATM switches”; and
U.S. Pat. No. 6,128,278 granted to Joffe, et al. on Oct. 3, 2000 and entitled “Cell queuing in ATM switches.”
In several embodiments, a reassembly and/or a segmentation function is spread across (i.e. partially performed in) each of ingress and egress software programmed into one (or more) network processors, with use of queues in a queuing device (such as a switch fabric or traffic manager) to temporarily buffer data. Use of queues in a queuing device (that normally uses queues for other functions such as traffic management or switching) to temporarily hold data while a network processor is waiting for additional data eliminates the need to use a memory located in or coupled to the network processor, for this purpose.
Eliminating usage of such a local memory reduces the number of instructions required in the network processor, thus improving network processor performance in a path (called “data path”) of the data through the network processor. For example, instructions used to program a network processor to access local memory are eliminated. Moreover, such a reduction in instructions does not require an additional SAR device if SAR functions are performed in software by the ingress and egress network processors.
In some embodiments, on receipt of data in one or more data units (also called “ingress data units”), a network processor (also called “ingress network processor”) transfers the data to an adjacent queuing device in the data path, to be held in a queue for the destination. Of note, the ingress network processor forwards the data to the next device in the direction of the destination (i.e. without diverting the data to a local memory for reassembly), and reassembly is performed in an inline manner as follows.
Specifically, the queue accumulates data until an indication that the last buffer has been received and that the accumulated data is ready to be transferred (e.g. last cell in packet indication). The indication is provided by the ingress network processor when the accumulated data is sufficient to form an egress data unit. If there is not enough data to from an egress data unit, the ingress network processor does not mark the data as last buffer. Such unmarked data remains in the adjacent queuing device in the data path until additional data from one or more ingress data units is received in an amount sufficient to form an egress data unit.
In many embodiments, such a queuing device (e.g. a switch fabric and/or traffic manager) implements each queue using a number of fixed size buffers. In using the buffers, no attempt is made by the ingress network processor to completely fill each buffer. Instead, filling of data into a current buffer is stopped (and the remainder of current buffer is filled with padding) if there is no more data available, or if sufficient data has been accumulated to form an egress data unit. In other words, data for each egress data unit is placed in one or a number of fixed size buffers, with the ingress network processor inserting padding in the last fixed size buffer on a need basis. Sufficient number of ingress data units are stored this way in a queuing device until an egress data unit can be formed.
Any remaining data is stored in a next buffer that remains partially filled. Such partially filled buffers serve as temporary storage until additional data is received in sufficient amount to form an egress data unit. Any padding inserted by the ingress network processor is removed by the egress network processor which assembles an egress data unit using data from the queue, thereby to complete the reassembly function.
In a similar manner, segmentation of one or more ingress data units among a number of egress data units may be spread across two (or more) network processors, and a queuing device may be used to temporarily store data while waiting for accumulation of data in an amount sufficient to form an egress data unit.
In several embodiments, a number of data units (also called “ingress data units”) that are received (as per act 211 in
Therefore, in some embodiments, ingress network processor 202 (
In some embodiments, ingress network processor 202 and egress network processor 205 are both identical copies of a single network processor, such as EPIF-200 or nP7250 available from Applied Micro Circuits Corporation (AMCC) that are coupled to one another via a switch fabric (also called “traffic manager”) such as products nPX5400, nPX5500, or nPX5700 also available from AMCC. The just-described identical network processors are programmed appropriately to perform an ingress function and an egress function for a specific flow. A network processor that performs an ingress function for a specific flow may be programmed to perform an egress function for another flow, and vice versa. Furthermore, a single network processor may be programmed to perform both an ingress function and an egress function for a specific flow.
Moreover, although only one switch fabric is illustrated in
In several such embodiments, switch fabric 103 (
In such embodiments, the amount of data placed in each buffer 206I is determined by ingress network processor 202 (
If this condition is met, then the currently received data is filled into additional buffers 206I+1 to 206N until the queue contains sufficient amount of data needed to form an egress data unit (as per act 213). At this stage if a last buffer 206N is only partially filled, the unfilled locations are filled with padding (as per act 214), and furthermore all buffers in queue 206 are flagged as being ready for transfer (as per act 214) to egress network processor 205. Depending on the implementation, only a last buffer 206N may be marked with an “L” flag (i.e. last buffer) to indicate that all preceding buffers and the last buffer are ready for transfer.
In the just-described situation, filling of data is stopped in last buffer 206N and additional data that remains to be stored (e.g. if there is data leftover from an ingress data unit), the filling of data is continued in a next buffer 206N+1 (not shown in
If the above-described condition is not met (as per act 212 in
Note that switch fabric 103 automatically transfers the buffered data (as per act 218) to memory 204 (as per act 218) when buffers are filled but are not marked as being ready for transfer to the egress network processor. On the other hand when the buffered data is marked as being ready for transfer (e.g. at the end of act 214), switch fabric 103 automatically transfers the buffered data from memory 204. Memory 204 may be implemented off chip, i.e. separate from switch fabric 103 and coupled thereto with a bus that is as wide as a buffer. Depending on the implementation, such as bus may be wider than a buffer (e.g. ½ times as wide) or narrower than a buffer (e.g. M as wide).
When a buffer 206N is flagged as the last buffer, switch fabric 103 transfers data in each preceding buffer as well as data in the last buffer (e.g. in buffers 206A-206I) to egress network processor 205.
Any data leftover in the remaining buffers 206N+1 to 206Z is stored therein until additional data (from one or more additional ingress data units) is received sufficient to form another egress data unit.
Egress network unit 205 receives the data from a number of buffers (e.g. buffers 206A-206I) in an act 221 (
In one example illustrated in
In filling buffers 301-306 (
At some later point in time, when a packet B is received, ingress network processor 202 fills 34 bytes of data from packet B into a buffer 303 as per act 212 because 13 bytes of data (from packet A) is already present (in the memory of switch fabric 103), ready for transfer. The number 34 is obtained by subtracting the already present bytes 13 from size 47 of the payload in a cell to be formed by the egress network processor 205. Therefore, although 60 bytes of data were received in packet B, only 34 bytes are filled into buffer 303 which is then flagged by setting the “L” flag. All unfilled locations in buffer 303 are filled with padding.
Furthermore, the remaining 26 bytes of data from packet B that are left over are filled in the next buffer 304. As all 60 bytes of packet B have been stored, all unfilled locations of buffer 304 are now filled with padding. The data in buffer 304 is held in switch fabric 103 until 21 bytes of additional data is received sufficient to form another 47 bytes of payload for a next cell. In this example, when packet C is received, 21 bytes of data are stored in the next buffer 305, the remaining unfilled locations in buffer 305 are filled with padding, and this buffer 305 is flagged by setting the “L” flag. The remaining 39 bytes of data from packet C are stored in a next buffer 306.
A similar example is illustrated in
Another example is illustrated in
Certain embodiments of the invention are used for segmentation and reassembly as described in AAL2. Specifically, in the receive direction (i.e. AAL2 cells to packets), such embodiments take AAL2 cells (which have the format illustrated in
Reassembly in several embodiments of CPS packets that are received embedded in AAL2 cells is illustrated in
In act 514, ingress network processor 501 checks if there is enough in the currently-received AAL2 cell to form the complete packet. This check is necessary because a CPS packet may span two or more AAL2 cells. If all data for the CPS packet has been received, ingress network processor 501 goes to act 515 and transfers the currently-received data for the CPS packet to the switch fabric (including AAL5 trailer and padding as needed) with an “L” flag. Thereafter, ingress network processor 501 checks if there are any more CPS packets in the currently-received AAL2 cell, and if so returns to act 514.
In act 514, if the current AAL2 cell does not contain all the data of a CPS packet, then ingress network processor 501 goes to act 516 and transfers the data to switch fabric 502, but without the “L” flag. Prior to transferring the data, ingress network processor 501 adds padding as needed to fill out a data unit that is transferred between ingress network processor 501 and switch fabric 502.
Such a data unit may be, for example, a cell that conforms to the ViX protocol, although other data units may be used in other examples. Of note, such cells are frequently only partially filled with data, and the remainder of each cell is filled with padding. Moreover, such cells are locally stored by switch fabric 502 until receipt of a cell with the “L” flag at which time data from the received cell and all preceeding cells is transferred to the egress network processor 503.
In embodiments that use cells in conformance with the ViX format (e.g. of the type described in U.S. Pat. No. 5,440,523 that is incorporated by reference herein in its entirety), each cell is of a fixed length similar to ATM cells, except that the ViX cells are 64 bytes in length instead of 53 bytes in length. Each ViX cell has 16 bytes of overhead that is divided into cell header, user defined fields and reserved fields. The ViX cell header identifies the source and destination ports, and flow-specific information. Note that the above-described ViX format is not used in some embodiments.
The ViX cell header also includes information that is used to implement reassembly, such as a queue number (which identifies a queue in the switch fabric coupled to a destination or source network processor), an “L” flag for the last cell, and a flow ID that is used to identify whether AAL5 reassembly and removal of AAL5 encapsulation is required. If a specific bit in flow ID is clear, then the current cell is considered part of a packet and AAL5 reassembly and removal of the AAL5 encapsulation is performed. If the just-described bit is set, then this cell is considered a single cell and passed to the network processor untouched with no AAL5 processing.
After act 516, ingress network processor 501 goes to act 517 and stores in its own local memory the working AAL5 trailer and the CRC and length for the data that has been sent to switch fabric 502 without the “L” flag, so that this information can be later used when the remaining data of the CPS packet arrives. Therefore, only the last CPS packet fragment that is sent to switch fabric 502 (in a partially filled cell) contains the AAL5 trailer (which includes the length and CRC-32 calculated over the full AAL5 packet, including the inserted padding, not just that final fragment) and last cell indication.
Furthermore, ingress network processor 501 is also programmed with a watchdog timer to flush incomplete cells packets in each queue. If a partially reassembled CPS packet is in a queue for longer than a predetermined time out period, it is aborted by queuing a dummy last cell to this queue, with an incorrect AAL5 trailer and CRC-32 so that it will be discarded by egress network processor 503.
As noted above, each queue in switch fabric 502 is configured in packet mode so that each CPS packet (whether spanning more than one cell or not) is sent to egress network processor 502 as back-to-back cells. In egress network processor 502, the AAL5 trailer is removed, and the padding is also removed.
Where the CPS packet is in a single cell in the queue, the AAL5 trailer and padding is removed automatically by a ViX interface, and all that is required of egress network processor 502 is to add the appropriate egress packet header for the packet interface (eg. RTP/UDP/IP header).
Where data for the CPS packet is received from switch fabric 502 in multiple cells, the AAL5 trailer and padding in the last cell is removed automatically by the ViX interface, but the padding in the middle (which was inserted for the non-last fragments) needs to be removed by egress network processor 502 before adding the appropriate egress packet header for the packet interface (eg. RTP/UDP/IP header).
Next, ingress network processor 501 determines (as per act 524) whether this packet can fit into a current AAL2 cell (that is to be formed by egress network processor 502) for the required VPI/VCI. If the CPS packet can fit into the current AAL2 cell, ingress network processor 501 writes the data (as per act 525) for this CPS packet into a single buffer in switch fabric 502 (including CPS packet header, and with padding added to fill out the buffer, and with the last flag “L” set).
In performing act 525, if a CPS packet is longer than the space available in the current AAL2 cell, the CPS packet is written into multiple buffers in switch fabric 502. Specifically, one buffer is filled (as per act 525) with only sufficient data to complete the AAL2 cell, and that buffer is flagged with the last flag “L” set. This buffer also contains the AAL5 trailer (which includes the length and CRC-32 calculated over the full ‘AAL2 cell’, including the inserted padding). The remaining data of the CPS packet is written into another buffer, without last flag “L” being set (as per act 529). The working AAL5 trailer, CRC and length are saved (as per act 530) for future use.
Therefore, data for each AAL2 cell is queued in switch fabric 502 in multiple buffers, each containing a single CPS packet or packet fragment, with the multiple buffers making up an AAL5 cell, and all unused locations of all buffers are filled with padding.
On egress, each output queue is configured in packet mode so that each AAL5 packet (whether spanning more than one cell or not) is scheduled as back-to-back cells. In the egress network processor 503, the AAL5 trailer is removed, and the padding removed. Where the AAL5 packet is in a single cell, the AAL5 trailer and padding is removed automatically by a ViX interface in the network processor, and all that is required of the software in egress network processor 503 is to add the appropriate ATM cell header for the egress ATM interface. Where the AAL5 packet is in multiple cells, the AAL5 trailer and padding in the last cell is removed automatically by the ViX interface, but the padding in the middle (which was inserted for the non-last fragments) needs to be removed by software before adding the appropriate ATM cell header for the egress ATM interface.
Several embodiments of the type described herein may be implemented using the nPX5700/nP7250 chipset available from Applied Micro Circuits Corporation, although other implementations may also be made using other commercially available chipsets as would be apparent to the skilled artisan in view of this disclosure.
Numerous modifications and adaptations of the embodiments, examples and implementations described herein will be apparent to the skilled artisan in view of the disclosure.
Although in some embodiments, segmentation and reassembly have been described above in the context of AAL2, reassembly of fragments of an IP packet may also be performed in the manner described herein. In some embodiments, such reassembly of IP packet fragments is performed in addition to reordering of out of order fragments by use of a loop between a network processor and a switch fabric as described in the related U.S. patent application Ser. No. 10/211,080 entitled “Reassembly of Out-of-order Data Fragments In A Network” by Ari Birger, Dayne A. Reast and Benjamin Hur which has been incorporated by reference above.
Moreover, any value may be used as a padding byte if such a value is expected to not occur in real data. The value for a padding byte may be assigned by the user, in some embodiments. Furthermore, a header of a cell transferred between the network processor and the switch fabric may contain a field (e.g. in user data) that indicates the amount of valid data in the cell (e.g. similar to packet length).
Although only certain functions are identified above as being performed by an ingress network processor in some embodiments, in other embodiments such an ingress network processor may perform a number of other functions, such as identifying and extracting various packet headers, performing table lookups using information from the packet headers, updating counters for protocol processing, examining flow control information and checking for conformance with preallocated bandwidth, and creating fixed-size cells for transmission through the switch fabric.
Moreover, although network processors and switch fabrics of a particular architecture have been described above, these are merely illustrative. Therefore, any network processor and any switch fabric may be used as described herein. For more information on other types of network processors, see “Understanding Network Processors” by Niraj Shah (available over the Internet at http://www.cs.ucsd.edu /classes/sp02/cse291_E/reading/UnderstandNP.pdf) that is incorporated by reference herein in its entirety. See also http://www.commsdesign.com/dcenters/netprocessing.
Furthermore, although certain embodiments use cells (e.g. in the ViX format) when transferring data between a network processor and a switch fabric, other embodiments may not use any cells (e.g. such other embodiments may employ one or more packet switches in the switching fabric instead of cell switches).
Moreover, queues of the type described herein (such as queues 206 and 207 illustrated in
Furthermore, depending on the embodiment, spreading of a reassembly and/or a segmentation function may be across (i.e. partially performed in) one or more network processor(s) and one or more switch fabric(s) that are respectively implemented as different logic blocks in a single IC chip or as different IC chips mounted on a single printed circuit board (PCB), or as different PCBs mounted in a single chassis.
Numerous such examples, embodiments, implementations and variations are within the scope of the appended claims.
|Patente citada||Fecha de presentación||Fecha de publicación||Solicitante||Título|
|US5383182||12 Nov 1993||17 Ene 1995||Alcatel N.V.||Resequencing device for a node of a cell switching system|
|US5590122||22 Dic 1994||31 Dic 1996||Emc Corporation||Method and apparatus for reordering frames|
|US5781549||23 Feb 1996||14 Jul 1998||Allied Telesyn International Corp.||Method and apparatus for switching data packets in a data network|
|US5809024 *||12 Jul 1996||15 Sep 1998||Bay Networks, Inc.||Memory architecture for a local area network module in an ATM switch|
|US5870394||23 Jul 1996||9 Feb 1999||Northern Telecom Limited||Method and apparatus for reassembly of data packets into messages in an asynchronous transfer mode communications system|
|US5901147||30 Ago 1996||4 May 1999||Mmc Networks, Inc.||Apparatus and methods to change thresholds to control congestion in ATM switches|
|US6128278||30 Ago 1996||3 Oct 2000||Mmc Networks, Inc.||Cell queuing in ATM switches|
|US6148000||30 Sep 1997||14 Nov 2000||International Business Machines Corporation||Merging of data cells at network nodes|
|US6246684||24 Dic 1997||12 Jun 2001||Nortel Networks Limited||Method and apparatus for re-ordering data packets in a network environment|
|US6249528||12 Mar 1998||19 Jun 2001||I-Cube, Inc.||Network switch providing per virtual channel queuing for segmentation and reassembly|
|US6259699 *||30 Dic 1997||10 Jul 2001||Nexabit Networks, Llc||System architecture for and method of processing packets and/or cells in a common switch|
|US6266687||18 Sep 1998||24 Jul 2001||Telefonaktiebolaget Lm Ericsson (Publ)||Flexibility enhancement to the modified fast convolution algorithm|
|US6307860||3 Abr 1998||23 Oct 2001||Mmc Networks, Inc.||Systems and methods for data transformation and transfer in networks|
|US6314101||20 May 1998||6 Nov 2001||Qualcomm Incorporated||Method for detecting delayed data frames in a transport function|
|US6317433 *||13 Oct 1998||13 Nov 2001||Cisco Technology, Inc.||Method and system for optimizing transmission link bandwidth occupation in high speed digital networks|
|US6330584||3 Abr 1998||11 Dic 2001||Mmc Networks, Inc.||Systems and methods for multi-tasking, resource sharing and execution of computer instructions|
|US6388994 *||16 Sep 1998||14 May 2002||Nec Corporation||Traffic rate controller in a packet switching network|
|US6404752 *||27 Ago 1999||11 Jun 2002||International Business Machines Corporation||Network switch using network processor and methods|
|US6463067||13 Dic 1999||8 Oct 2002||Ascend Communications, Inc.||Submission and response architecture for route lookup and packet classification requests|
|US6556568 *||7 Abr 1998||29 Abr 2003||Hitachi Communication Technologies, Ltd.||Cell fluctuation absorption receiving system|
|US6654343||19 Mar 2001||25 Nov 2003||Turin Networks||Method and system for switch fabric flow control|
|US6687246 *||31 Ago 1999||3 Feb 2004||Intel Corporation||Scalable switching fabric|
|US6714985||28 Abr 2000||30 Mar 2004||Cisco Technology, Inc.||Method and apparatus for efficiently reassembling fragments received at an intermediate station in a computer network|
|US6937606 *||20 Abr 2001||30 Ago 2005||International Business Machines Corporation||Data structures for efficient processing of IP fragmentation and reassembly|
|US6954430 *||16 Mar 2001||11 Oct 2005||Telefonaktiebolaget Lm Ericsson (Publ)||Load regulation|
|US7058057||1 May 2001||6 Jun 2006||Integrated Device Technology, Inc.||Network switch port traffic manager having configurable packet and cell servicing|
|US7072342||20 Mar 2002||4 Jul 2006||Applied Micro Circuits Corporation||Reordering of out-of-order packets|
|US7092409 *||21 Mar 2001||15 Ago 2006||Telefonaktiebolaget Lm Ericsson (Publ)||Timing distribution redundacy in a wireless network|
|US20030074388 *||12 Oct 2001||17 Abr 2003||Duc Pham||Load balanced scalable network gateway processor architecture|
|USRE31182||11 Oct 1979||15 Mar 1983||International Telephone And Telegraph Corporation||Packet-switched data communication system|
|1||"Reconsidering Fragmentation and Reassembly" by Girish P. Chandranmenon and George Varghese, believed to be published at Seventeenth ACM Symposium on Principles of Distributed Computing (PODC '98), at a conference held in Peurto Vallarta, Jun. 28-Jul. 2, 1998.|
|2||Entire Prosecution History of U.S. Appl. No. 10/211,080 filed by Ari Birger et al, on Aug. 1, 2002, including an Office Action dated Sep. 11, 2006.|
|3||Shan, N. "Understanding Network Processors", Version 1.0, University of California, Berkeley, Sep.,2001, http://courses.ece.uiuc.edu/ece511/papers/np.pdf, pp. 93.|
|4||The ATM Forum Technical Committee, "ATM Trunking using AAL2 for Narrowband Services", AF-VTOA-0113.000, Feb., 1999, pp. 58.|
|Patente citante||Fecha de presentación||Fecha de publicación||Solicitante||Título|
|US7577133||9 Sep 2005||18 Ago 2009||Juniper Networks, Inc.||Scalable central memory switching fabric|
|US7593330 *||30 Ene 2006||22 Sep 2009||Juniper Networks, Inc.||Processing of partial frames and partial superframes|
|US7903644||9 Jul 2009||8 Mar 2011||Juniper Networks, Inc.||Scalable central memory switching fabric|
|US8077727||14 Ago 2009||13 Dic 2011||Juniper Networks, Inc.||Processing of partial frames and partial superframes|
|US8325717 *||30 Jul 2003||4 Dic 2012||Foundry Networks, Llc||Method and system for IP fragmentation handling|
|US8381230 *||21 Abr 2010||19 Feb 2013||International Business Machines Corporation||Message passing with queues and channels|
|US8428055||31 Ene 2011||23 Abr 2013||Juniper Networks, Inc.||Scalable central memory switching fabric|
|US8543722||30 Mar 2010||24 Sep 2013||International Business Machines Corporation||Message passing with queues and channels|
|US20100128735 *||14 Ago 2009||27 May 2010||Juniper Networks, Inc.||Processing of partial frames and partial superframes|
|US20100150148 *||30 Jul 2003||17 Jun 2010||Foundry Networks, Inc.||Method and system for IP fragmentation handling|
|US20110122892 *||31 Ene 2011||26 May 2011||Juniper Networks, Inc.||Scalable central memory switching fabric|
|US20110265098 *||21 Abr 2010||27 Oct 2011||International Business Machines Corporation||Message Passing with Queues and Channels|
|CN102665240A *||29 Mar 2012||12 Sep 2012||钱袋网（北京）信息技术有限公司||Data sending method, data receiving method, apparatuses and system|
|Clasificación de EE.UU.||370/428, 370/505|
|Clasificación internacional||H04J3/07, H04L12/54|
|Clasificación cooperativa||H04L49/9094, H04L47/10, H04L49/9021, H04L49/90, H04L47/34, H04L49/9047|
|Clasificación europea||H04L49/90M, H04L49/90, H04L47/34, H04L47/10, H04L49/90S, H04L49/90E|
|18 Ene 2005||AS||Assignment|
Owner name: APPLIED MICRO CIRCUITS CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:REAST, DAYNE A.;HUR, BEN;WANG, SANGYU;REEL/FRAME:016156/0582;SIGNING DATES FROM 20041026 TO 20041028
|23 Sep 2008||CC||Certificate of correction|
|8 Ago 2011||AS||Assignment|
Owner name: NET NAVIGATION SYSTEMS, LLC, TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:APPLIED MICRO CIRCUITS CORPORATION;REEL/FRAME:026714/0383
Effective date: 20110624
|17 Oct 2011||FPAY||Fee payment|
Year of fee payment: 4
|21 Nov 2013||AS||Assignment|
Owner name: NET NAVIGATION SYSTEMS, LLC, TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PACKETQ SOLUTIONS LLC;REEL/FRAME:031645/0183
Effective date: 20131119
|24 Dic 2015||REMI||Maintenance fee reminder mailed|
|1 Feb 2016||AS||Assignment|
Owner name: RPX CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NET NAVIGATION SYSTEMS, LLC;REEL/FRAME:037679/0953
Effective date: 20160122
|13 May 2016||LAPS||Lapse for failure to pay maintenance fees|
|5 Jul 2016||FP||Expired due to failure to pay maintenance fee|
Effective date: 20160513