WikiPatents - Community Patent Review
Create Free Account  |  License or Sell Your Patent  |  WikiPatents Marketplace  |  WikiPatents Blog
Username:  Password:  
    
Advanced Search
Method and apparatus for accelerated packet processing    
United States Patent5598410   
Link to this pagehttp://www.wikipatents.com/5598410.html
Inventor(s)Stone; Geoffrey C. (Minneapolis, MN)
AbstractA method and apparatus are provided to transfer protocol data units within a communication network. This transferring is accomplished with a protocol data unit processor that is operated in the communication network. The processor includes a preprocessor which establishes subsequent processing requirements of a particular protocol data unit received from the communication network to generate at least one associated directive for the particular protocol data unit. Subsequently, a synchronizing mechanism synchronizes the particular protocol data unit with the at least one associated directive to generate a synchronized protocol data unit. A restructuring device restructures the synchronized protocol data unit in accordance with the at least one associated directive for the protocol data unit to generate a restructured protocol data unit. In addition, a method of operating the protocol data unit processor in a heterogeneous communication network is provided.
   














 Title Information Submit all comments and votes
 
Patent Text Patent PDF Print Page Summary File History
Plain text PDF images Print Summary File History
Drawing from US Patent 5598410
Method and apparatus for accelerated packet processing - US Patent 5598410 Drawing
Method and apparatus for accelerated packet processing
Inventor     Stone; Geoffrey C. (Minneapolis, MN)
Owner/Assignee     Storage Technology Corporation (Louisville, CO)
Patent assignment
All assignments
Publication Date     January 28, 1997
Application Number     08/366,225
PAIR File History     Application Data   Transaction History
Image File Wrapper   Patent Term   Fees
Litigation
Filing Date     December 29, 1994
US Classification     370/469 718/100
Int'l Classification     H04L 012/56 G06F 013/00
Examiner     Hsu; Alpus H.
Assistant Examiner    
Attorney/Law Firm     Schulte; Timothy R.
Address
Parent Case    
Priority Data    
USPTO Field of Search     370/58.1 370/58.2 370/58.3 370/60 370/60.1 370/61 370/79 370/82 370/83 370/85.13 370/85.14 370/94.1 370/94.2 370/94.3 370/99 395/200 395/325 395/375 395/650 395/800
Patent Tags     accelerated packet processing
   
Enter a comma (,) or semicolon (;) between multiple tag words/phrases.
Describe this patent:
 Amusing   
 Clever   
 Complex   
 Efficient   
 Historic   
 Important   
 Innovative   
 Interesting   
 Practical   
 Simple   
[no votes]
Patent WIKI

Share information and news about this patent, including information and news about the technology, inventors, company, ligation and licensing.

 References Submit all comments and votes
 
*references marked with an asterisk below are user-added references
 U.S. References
 
Add a new US reference:  
ReferenceRelevancyCommentsReferenceRelevancyComments
5430709
Galloway
370/241
Jul,1995

[0 after 0 votes]
5414707
Johnston
370/395.6
May,1995

[0 after 0 votes]
5414702
Kudoh
370/395.7
May,1995

[0 after 0 votes]
5307343
Bostica
370/398
Apr,1994

[0 after 0 votes]
5280476
Kojima
370/397
Jan,1994

[0 after 0 votes]
5278834
Mazzola
370/469
Jan,1994

[0 after 0 votes]
5249292
Chiappa
370/392
Sep,1993

[0 after 0 votes]
5200953
Spatafore
370/429
Apr,1993

[0 after 0 votes]
5134610
Shand
370/400
Jul,1992

[0 after 0 votes]
 Foreign References
 Other References
 Market Review Submit all comments and votes
   
Market Size
Estimate the gross annual revenues of the relevant market sector:
> $10B
$5B - $10B
$2B - $5B
$500M - $2B
$100M - $500M
$10M - $100M
$1M - $10M
$500K - $1M
$100K - $500K
< $100K
[No votes]
$0
 
$0   $2.5B   $5B   $7.5B   $10B
Market Share
Estimate the percentage of the relevant market sector this invention will capture:
75% - 100%
50% - 74.99%
25% - 49.99%
10 - 24.99%
5 - 9.99%
2 - 4.99%
1 - 1.99%
< 1%
[No votes]
0.0%
 
0%   25%   50%   75%   100%
Reasonable Royalty
What percentage of gross sales should the inventor or assignee be paid?
75% - 100%
50% - 74.99%
25% - 49.99%
10 - 24.99%
5 - 9.99%
2 - 4.99%
1 - 1.99%
< 1%
[No votes]
0.0%
 
0%   25%   50%   75%   100%
Public's "Guesstimation" of Royalty Value
Market SizeN/A[No votes]
xMarket ShareN/A[No votes]
xReasonable RoyaltyN/A[No votes]

N/A

License Availablity
If you are NOT the owner or assignee, answer here:
Yes, license is available for purchase

No, license is not currently available



[No votes]
License Availablity
If you ARE the owner or assignee, answer here:
Yes, license is available for purchase

No, license is not currently available



[No votes]
Competitive Advantage
Does this invention have a significant competitive advantage over similar technologies?
Yes

No



[No votes]
Most helpful competitive advantage comment
[No comments]

Commercial Alternatives
Are there viable commercial alternatives for this invention?
Yes

No



[No votes]
Most helpful commercial alternative comment
[No comments]

 Technical Review Submit all comments and votes
 Claims Submit all comments and votes
 


What is claimed is:

1. A protocol data unit processing device for use in a communication network to transfer protocol data units within the communication network, the protocol data unit processing device comprising:

(a) preprocessor means for establishing subsequent processing requirements of a particular protocol data unit received from the communication network to generate at least one associated directive for the particular protocol data unit;

(b) synchronizing means, operatively coupled to the preprocessing means, for synchronizing the particular protocol data unit with the at least one associated directive for the particular protocol data unit to generate a synchronized protocol data unit; and

(c) restructuring means, operatively coupled to the synchronizing means, for restructuring the synchronized protocol data unit in accordance with the at least one associated directive for the protocol data unit to generate a restructured protocol data unit.

2. The protocol data unit processing device of claim 1 wherein the preprocessor means includes means for establishing subsequent processing requirements of the particular protocol data unit by identifying, verifying, and generating at least one associated directive for the particular protocol data unit.

3. The protocol data unit processing device of claim 1 wherein:

(a) the preprocessor means includes means for operating on a first and a second protocol data units such that the preprocessor means can interleave processing of both the first and the second protocol data units during a single time span; and

(b) the synchronizing means comprises means for synchronizing both the first and the second protocol data units with the at least one associated directive for that particular protocol data unit.

4. The protocol data unit processing device of claim 1 wherein the preprocessor means includes means for establishing the at least one associated directive for the particular protocol data unit based upon only a portion of the protocol data unit which enables an identification of the particular protocol data unit.

5. The protocol data unit processing device of claim 4 wherein the preprocessor means includes means for sequentially storing the particular protocol data unit as it is received until the portion of the protocol data unit which enables the identification of the particular protocol data unit is received.

6. The protocol data unit processing device of claim 5 wherein:

(a) the preprocessor means includes means for establishing subsequent processing requirements based upon the stored portion of the particular protocol data unit; and

(b) the synchronizing means comprises means for storing a portion of the particular protocol data unit such that the particular protocol data unit can be synchronized with the at least one associated directive for the particular protocol data unit.

7. The protocol data unit processing device of claim 4 wherein the restructuring means operates on the synchronized protocol data unit prior to the protocol data unit processing device receiving all of the protocol data unit.

8. The protocol data unit processing device of claim 7 wherein the restructuring means includes means for outputting a portion of the restructured protocol data unit to a transmitting device prior to receiving all of the protocol data unit.

9. The protocol data unit processing device of claim 1 wherein the restructuring means includes means for restructuring the synchronized protocol data unit by deleting, inserting, and replacing bits in the synchronized protocol data unit in accordance with the at least one associated directive for the protocol data unit.

10. The protocol data unit processing device of claim 1 wherein the restructuring means includes means for monitoring the synchronized protocol data unit by dropping, sending, sending a copy of, and auditing the contents of the synchronized protocol data unit in accordance with the at least one associated directive for the protocol data unit.

11. The protocol data unit processing device of claim 1 further comprising receiving means, operatively coupled to the preprocessor means, for receiving the protocol data unit from the communication network.

12. The protocol data unit processing device of claim 1 further comprising transmitting means, operatively coupled to the restructuring means, for transmitting the reconstructed protocol data unit over the communication network.

13. The protocol data unit processing device of claim 1:

(a) wherein the restructuring means includes means for indicating a particular transmit path for the restructured protocol data unit; and

(b) further comprising a plurality of transmitting means, operatively coupled to the restructuring means, for transmitting the restructured protocol data unit over the communication network via the particular transmit path indicated by the restructuring means.

14. The protocol data unit processing device of claim 1 wherein:

(a) the protocol data unit processing device is selected from the group consisting of a bridge, a router, a switch, an inline filter, a protocol converter, an encapsulating device, and a security device;

(b) the protocol data unit is selected from the group consisting of a frame, a cell, and a packet;

(c) the communication network is selected from the group consisting of local area network, wide area network, metropolitan area network, and wireless network; and

(d) the communication network transfers protocol data units having a content selected from the group consisting of voice, video, and data.

15. A protocol data unit processing device for use in a communication network to transfer protocol data units within the communication network, the protocol data unit processing device comprising:

(a) a first and a second preprocessor, operatively coupled to a receiving mechanism, for establishing subsequent processing requirements of a particular received protocol data unit by generating at least one associated directive for the particular protocol data unit, the first preprocessor being operatively connected in series to the second preprocessor such that the first preprocessor performs a portion of processing necessary for generating the at least one associated directive and the second preprocessor completes the processing necessary for generating the at least one associated directive;

(b) synchronizing means, operatively coupled to the preprocessors, for synchronizing the particular protocol data unit with the at least one associated directive for the particular protocol data unit to generate a synchronized protocol data unit;

(c) restructuring means, operatively coupled to the synchronizing means, for restructuring the synchronized protocol data unit in accordance with the at least one associated directive for the protocol data unit to generate a restructured protocol data unit; and

(d) presenting means, operatively coupled to the restructuring means, for providing the restructured protocol data unit to a transmitting mechanism.

16. The protocol data unit processing device of claim 15 wherein:

(a) the means for optimizing the first preprocessor a identification process by selectively examining only significant bits of the particular protocol data unit which affect an identification process and verifying the identification process by comparing a portion of the particular protocol data unit with a predetermined tuple; and

(b) the second preprocessor comprises means for generating the at least one associated directive for the protocol data unit based on the verified identification process.

17. The protocol data unit processing device of claim 16 wherein the means for optimizing the first preprocessor comprises means for selectively examining significant bits of the particular protocol data unit according to a radix decision process.

18. The protocol data unit processing device of claim 16 wherein the first preprocessor means for optimizing comprises means for selectively examining several significant bits of the particular protocol data unit in a single step of the decision process.

19. The protocol data unit processing device of claim 16 wherein the predetermined tuple consists of known values for specific portions of the particular protocol data unit.

20. The protocol data unit processing device of claim 15 wherein:

(a) each preprocessor comprises means for operating on a first and a second protocol data units such that each preprocessor can interleave processing of both the first and the second protocol data units during a single time span; and

(b) the synchronizing means comprises means for synchronizing both the first and the second protocol data units with the at least one associated directive for that particular protocol data unit.

21. The protocol data unit processing device of claim 15 wherein the restructuring means operates on the synchronized protocol data unit prior to the protocol data unit processing device receiving all of the protocol data unit.

22. The protocol data unit processing device of claim 15 further comprising the receiving mechanism, operatively coupled to the first and the second preprocessor means, which receives the particular protocol data unit from the communication network, the communication network being selected from the group consisting of a local protocol data unit source device, a local area network, a wide area network, a metropolitan area network, and a wireless network.

23. The protocol data unit processing device of claim 15 further comprising the transmitting mechanism, operatively coupled to the presenting means, which transmits the restructured protocol data unit over the communication network, the communication network being selected from the group consisting of a local protocol data unit source device, a local area network, a wide area network, a metropolitan area network, and a wireless network.

24. A protocol data unit processing device for use in a communication network to transfer protocol data units within the communication network, the protocol data unit processing device comprising:

(a) a first and a second preprocessor, operatively coupled to a receiving mechanism, for establishing subsequent processing requirements of a particular received protocol data unit by generating at least one associated directive for the particular protocol data unit, each preprocessor being optimized to perform the processing necessary for generating the at least one associated directive for a particular type of protocol data unit;

(b) synchronizing means, operatively coupled to the preprocessors such that the first and second preprocessor are connected in parallel, for synchronizing the particular protocol data unit with the at least one associated directive for the particular protocol data unit to generate a synchronized protocol data unit;

(c) restructuring means, operatively coupled to the synchronizing means, for restructuring the synchronized protocol data unit in accordance with the at least one associated directive for the protocol data unit to generate a restructured protocol data unit; and

(d) presenting means, operatively coupled to the restructuring means, for providing the restructured protocol data unit to a transmitting mechanism.

25. The protocol data unit processing device of claim 24 wherein the first preprocessor is optimized to perform the processing necessary for generating the at least one associated directive for a particular type of protocol data unit selected from the group consisting of a particular physical layer media type, a particular link layer signaling protocol, and a particular network layer protocol.

26. The protocol data unit processing device of claim 24 wherein:

(a) each preprocessor comprises means for operating on a first and a second protocol data units such that each preprocessor can interleave processing of both the first and the second protocol data units during a single time span; and

(b) the synchronizing means comprises means for synchronizing both the first and the second protocol data units with the at least one associated directive for that particular protocol data unit.

27. The protocol data unit processing device of claim 24 wherein the restructuring means operates on the synchronized protocol data unit prior to the protocol data unit processing device receiving all of the protocol data unit.

28. The protocol data unit processing device of claim 24 further comprising the receiving mechanism, operatively coupled to the first and the second preprocessor means, which receives the particular protocol data unit from the communication network, the communication network being selected from the group consisting of a local protocol data unit source device, a local area network, a wide area network, a metropolitan area network, and a wireless network.

29. The protocol data unit processing device of claim 24 further comprising the transmitting mechanism, operatively coupled to the presenting means, which transmits the reconstructed protocol data unit over the communication network, the communication network being selected from the group consisting of a local protocol data unit source device, a local area network, a wide area network, a metropolitan area network, and a wireless network.

30. A method for utilizing a protocol data unit processing device in a heterogeneous communication network to transfer protocol data units within the communication network, the method comprising the steps of:

(a) receiving a first and a second protocol data unit from the communication network, the first and the second protocol data unit being of different types;

(b) establishing subsequent processing requirements of the first and the second protocol data unit to generate at least one associated directive for each protocol data unit;

(c) synchronizing each protocol data unit with the at least one associated directive for each protocol data unit to generate a first and a second synchronized protocol data unit, respectively;

(d) restructuring each synchronized protocol data unit in accordance with the at least one associated directive for each protocol data unit to generate a first and a second restructured protocol data unit, respectively; and

(e) providing the first and the second restructured protocol data unit to other components in the communication network.

31. The method of claim 30 wherein the first and the second protocol data unit differ from one another by being selected from the group consisting of different physical layer media types, different link layer signaling protocols, and different network layer protocols.
 Description Submit all comments and votes
 


RELATED INVENTIONS

The present invention is related to:

Co-pending U.S. patent application Ser. No. 08/366,221, filed on Dec. 23, 1994, which is entitled "Method And Apparatus For Accelerated Packet Forwarding" by Mark Bakke et al.,

Co-pending U.S. patent application Ser. No. 08/366,221, filed on Dec. 23, 1994, which is entitled "Method And Apparatus For Radix Decision Packet Processing" by Geof Stone,

Co-pending U.S. patent application Ser. No. 08/366,221, filed on Dec. 23, 1994, which is entitled "Method And Apparatus For Virtual Switching" by Ken Hardwick et al.;

and which were all filed concurrently herewith and assigned to the assignee of the present invention.

FIELD OF THE INVENTION

The present invention relates generally to data communication networks. More particularly, the present invention relates to protocol data unit forwarding systems that direct the flow of protocol data units in the data communication networks.

BACKGROUND OF THE INVENTION

In a data communication network, a forwarding device (e.g., a data packet switch) directs protocol data units (e.g., data packets) from one network node to another. These data packets may include voice, video, or data information as well as any combination thereof.

To better understand how forwarding devices work within a data communication network, an analogy may be helpful. In many respects, data communication networks are similar to postal delivery systems, with pieces of mail, such as letters or packages, being comparable to the data packets which are transferred within a data communication network. In a postal delivery system, the pieces of mail may be input into the postal delivery system in a variety of ways. Once within the postal delivery system, all of the pieces of mail are collected and transported to nearby processing facilities where the pieces of mail are sorted for further processing. Although each piece of mail will have a unique delivery address, most of the pieces of mail are automatically sorted by a shorter zip code or some other type of routing code. Letters without zip codes must be sorted and processed by hand. Some postal delivery systems also have special forms of encoded delivery addresses, such as Post Office box numbers at a Post Office, which are not recognizable by other postal delivery systems such as Federal Express or United Parcel Service. Regardless of which particular postal delivery system the piece of mail is deposited into, once the mail has been sorted by destination it is routed through additional intermediary processing facilities until it arrives at the local indicated by the destination on the piece of mail. At this point, the zip code or routing code is no longer sufficient to deliver the piece of mail to the intended destination and the local delivery office must further decode the destination address in order to deliver the piece of mail to the intended recipient. In addition to processing pieces of mail for routing the mail to the correct destination, the pieces of mail may go on through several other processing steps. For example, if the piece of mail is going out of the country, it must go through a customs operation in each country. If the national postal delivery system is being used to deliver the piece of mail then it must also be transferred from one national postal delivery system to another. In a private postal delivery system however, this transfer step would not be necessary. The pieces of mail may also be monitored or filtered for such things as mail fraud violation or shipment of hazardous materials.

Data packets are manipulated in a data communication network in a manner similar to that by which pieces of mail are delivered in a postal delivery system. Data packets, for example, are generated by many different types of devices and are placed onto a communication network. Typically, the data packets are concentrated into a forwarding device, such as a local bridge or router, and are then directed by destination over one or more media types (e.g., fiber optic) which are connected to destination devices that could be other larger or smaller bridges or routers. These destination devices then deliver the data packet to its terminal end point (i.e., the end user). Along the way the data communication network may perform filtering and monitoring functions with respect to the data packets.

Just like postal delivery systems have experienced ever increasing volumes of mail which must be delivered, the volume of protocol data units being transferred across computer networks continues to increase as experience is being gained with this new form of communication delivery system and as more and more applications, with more and more expansive means are being developed. In addition, quickly changing technology has made the underlying data transmission resources for computer communication networks relatively inexpensive. Fiber optics, for example, offer data transfer rates in the gigabyte per second range.

The capability or through put of a forwarding device and a computer communication network can be measured either by the number of data packets per second or by the number of bits per second which pass through the forwarding device. The former measure is important because in typical network traffic, the bulk of protocol data units or data packets are small and the critical parameter is how many data packets a forwarding device can handle. If network traffic is weighted by packet size, however, the bulk of the data is carried in large packets. In large bulk data transfers, the second measure of how many bits are being transferred is more important regardless of the number of data packets that are handled. This tension between packet transfer rate versus bit transfer rate is a continuing dichotomy in through put measurements of forwarding devices. Regardless of which through put measure is used, there is a need for through put rates that are substantially higher than the through put rates currently available in forwarding devices.

The existing types of forwarding devices which offer the greatest potential to meet the increasing demand on through put rates are packet switches. Several classes of packet switches exist. Each class differs substantially from the other class of devices, but all may be commonly referred to as packet switches or forwarding devices.

A first class of packet switches is that commonly used in digital telephone exchanges. By analogy, these switches can perform the functions only of a mail carrier picking up and delivering mail along a single route. These switches are intended only to transfer packets among the devices in a single station, such as a telephone exchange. The format of the packet in these systems is chosen to make the hardware in the switch as simple as possible; and this usually means that the packets include fields designed for direct use by the hardware. The capabilities of this class of switches (for example, in such areas as congestion control) are very limited in order to keep the hardware simple.

A second class of packet switches is used in smaller or restricted computer networks, such as X.25 networks. By analogy, these switches are equivalent to the Post Office in a single town with no connection to other Post Offices. In some sense, these switches are little different from the first class of packet switches described above, but there is one substantial difference. The format of the packets (that is, the protocols) handled by the second class of packet switches is much more complex. This greater complexity is necessary because the protocols are designed to work in less restricted environments, and because the packet switches must provide a greater range of services. While the formats interpreted by the first class of switches are chosen for easy implementation in hardware, the data packets handled by this second class of switches are generally intended to be interpreted by software (which can easily and economically handle the greater complexity) and provides the inherit benefit of incremental flexibility in the design of the packet switch.

In a third class of packet switches, the packet protocols are intended to be used in very large data networks having many very dissimilar links (such as a mix of very high speed local area networks (LANs) and low speed long distance point to point lines). Examples of such protocols are the United States designed Transmission Control Protocol/Internetwork Program (TCP/IP), and the International Standards Organization's Internetworking Protocol/Connectionless Network Service (IP/CLNS) protocols.

In addition, this third class of switches (commonly referred to as bridge/routers) often must handle multiple protocols simultaneously. This third class of switches is very similar to the mail processing devices used in the modern postal system. Just as there are many countries, there are many data packet protocols used in computer networks. While a single postal system was once thought to be sufficient to handle mail going anywhere in the world, today several competing systems like United Parcel Service, Federal Express, and the U.S. Postal Service exist to handle the special needs of mail going to every country, state, city, town, and street in the world. Similarly, in computer communication systems, the packet switches are more involved in the carrying of data, and must understand some of the details of each protocol to be able to correctly handle data packets which are being conveyed in that protocol. The routers in this third class of packet switches often have to make fairly complex changes to the data packets as they pass through the packet switch.

It is this latter class of packet switches to which the following detailed description primarily relates. It will be appreciated however, that the detailed description of this invention can readily be applied to the first and second class of switches as well. In current conventional packet switch design, a programmed general purpose processor examines each data packet as it arrives over the network interface and then processes that packet. Packet processing requires assignment of the data packet to an outbound network interface for transmission over the next communications link in the data path. While attempts are being made to build higher speed packet switches, based on this architecture of using general purpose processors, the attempts have not been very successful. One approach is to use faster processors, another is to make the software run faster, and a third is to apply multiple processors to the processing task. All of these approaches fail to meet the increasing performance demands for packet switches for the reasons noted below.

The approach which uses faster processors simply keeps pace with processor dependent (future) demands because the traffic which the packet switch will handle will depend upon the speed of the user processors being used to generate the traffic. Those user processors, like the processors in the packet switches, will increase in speed at more or less the same rate. Accordingly, there is no overall increase in the ability of the future packet switch over present packet switches, relative to traffic load. Furthermore, this approach may be impractical as not being cost-effective for widespread use. For example, two high speed machines, distant from each other, must have intermediate switches which are all equally as powerful; deployment on a large scale of such expensive switches is not likely to be practicable.

The approach which increases the execution rate of the software itself by, for example, removing excess instructions or writing the code in assembly language, leads to a limit beyond which an increase in performance cannot be made. The gains which result are typically small (a few percent) and the engineering costs of such distortions in the software are significant in the long term. This type of assembly code optimization restricts the ability to enhance the software as well as port the software to a different processor platform.

The use of multiple processors to avoid the "processor bottleneck" provides some gains but again has limits. Given a code path to forward a data packet, it is not plausible to split that path into more than a few stages. Typically these stages would involve network input, protocol functions, and network output. The basis for this limitation is the overhead incurred to interface the different processors beyond a limited number of task divisions. That is, after a certain point, the increase in interface overhead outweighs the savings obtained from the additional stage. This is particularly true because of the need to tightly integrate the various components; for example, congestion control at the protocol level requires dose coordination with the output device. Also, the interface overhead costs are made more severe by the complication of the interface which is required.

Currently, most bridge/router implementations rely heavily on off-the-shelf microprocessors to perform the packet forwarding functions. The best implementations are able to sustain processing rates approaching 100,000 packets per second (PPS). When dealing with media such as ethernet or current telecommunications lines, this processing rate is more than adequate. When faster media such as Fiber Distributed Data Interchange (FDDI) is used, existing processing rates may still be sufficient as long as there is only one such high packet rate interface present. When multiple high packet rate interfaces are used, 100,000 PPS become inadequate. Current software-based implementations for bridges/routers are simply not capable of media-rate packet forwarding on emerging media such as asynchronous transfer mode (ATM) or Optical Connection-12 Synchronous Optical Network (OC-12 SONET) which can accommodate communication rates up to 6 times the current 100 megabits per second limits to rates of 600 megabits per second.

It should be noted that the ever increasing power of off-the-shelf microprocessors might solve the throughput problem, but this is probably a vain hope. For example a single OC-24 ATM interface can sustain nearly 3 million internetworking protocol (IP) packets per second. This is over 30 times the rates achieved by the current best software techniques. If processing power doubles every year, the wait for sufficient processing power to make a software approach viable would be at least 4-5 years. In addition, the media capabilities will likely continue to increase over such a span of years. Additionally, any such processor will likely require large amounts of the fastest (most expensive) memory available to operate at full speed, resulting in an unacceptably high system cost.

In general then, the multiprocessor approach is not the answer to substantially increasing the throughput of the packet switching network. This has been borne out by several attempts by technically well-regarded groups to build packet switches using this approach. While aggregate throughput over a large number of interfaces can be obtained, this is, in reality, little different than having a large number of small switches. It has thus far proven implausible to substantially speed up a single stream using the multiprocessing approach.

A need still exists for an improved protocol data unit (i.e., frame, cell, or packet) forwarding system which solves the above-identified problems in a manner which can better handle large numbers of input streams, large numbers of output destinations and lines, many different types of communication protocols, and large and small data packets at both high bit throughput rates and high packet throughput rates, while maintaining reasonable costs and complexity.

SUMMARY OF THE INVENTION

The present invention provides a packet processing system with improved throughput performance by means of a method and apparatus for accelerated processing of protocol data units. The present invention addresses the problem of media rate forwarding of packets at gigabyte rates by providing an architecture for the design of bridges/routers that are capable of forwarding packets across different media which can sustain multi-gigabyte rates. This architecture also includes design approaches for implementing key features of a packet-forwarding device operating at these high transfer rates, such as filtering functions. By splitting processing functions, the present invention avoids the "processor bottleneck" inherent in prior art processing device architectures.

In accordance with a first aspect of the invention, a protocol data unit processor is used in a communication network to transfer protocol data units within the communication network. The processor includes a preprocessor which establishes subsequent processing requirements of a particular protocol data unit received from the communication network to generate at least one associated directive for the particular protocol data unit. Subsequently, a synchronizing mechanism synchronizes the particular protocol data unit with the at least one associated directive to generate a synchronized protocol data unit. A restructuring device restructures the synchronized protocol data unit in accordance with the at least one associated directive for the protocol data unit to generate a restructured protocol data unit. In addition, a method of operating the protocol data unit processor in a heterogeneous communication network is provided.

With reference to the postal delivery analogy, the present invention can be likened to a system which both increases the speed at which pieces of mail can be moved through the postal delivery system and provides an ability to handle in a common system pieces of mail entered into a variety of different postal delivery systems. By utilizing the preprocessor and restructuring device of the present invention to split the required protocol data unit processing functions, the present invention is able to significantly increase the through put of the processing device, both in terms of the number of data packets per second and in terms of the number of bits per second which pass through the processing device.

The preprocessor preferably establishes the subsequent processing requirements of the particular protocol data unit by identifying, verifying, and generating at least one associated directive for the particular protocol data unit. In addition, the restructuring device preferably restructures the synchronized protocol data unit by deleting, inserting, and replacing bits in the synchronized protocol data unit in accordance with the at least one associated directive for the protocol data unit. Alternatively, the restructuring device may, in addition to or in place of modifying particular bits, monitor the synchronized protocol data unit by dropping, sending, sending a copy of, and/or auditing the contents of the synchronized protocol data unit in accordance with the at least one associated directives for the protocol data unit.

In order to accelerate the processing of a received protocol data unit, the preprocessor preferably is configured to operate on a first and a second protocol data unit such that the preprocessor can interleave processing of both the first and the second protocol data unit during a single time span. In addition, multiple preprocessors connected in either parallel or series may be used to increase the through put of protocol data units. This use of multiple preprocessors may necessitate the use of a more sophisticated synchronizing mechanism which is able to track and synchronize more that one protocol data unit at a time with the particular associated directives for each protocol data unit. In addition, the preprocessor is configured to establish the at least one associated directive for the particular protocol data unit after having received only a portion (i.e., the first several bits or bytes) of the protocol data unit. The preprocessor may need to buffer into memory or store a portion of the particular protocol data unit as it is received until a large enough portion or the particular portion of the protocol data unit which enables the identification of the particular protocol data unit is received. Similarly, the restructuring device preferably is configured to operate on the synchronized protocol data unit prior to the protocol data unit processing device receiving all of the protocol data unit. This optimization can be taken a step further by outputting a portion of the restructured protocol data unit to a transmitting device prior to receiving all of the protocol data unit. All of these optimizations are particularly important when manipulating large protocol data units which extend over several frames or consist of several smaller parts that are received at various times and/or from various incoming interfaces.

In accordance with a second aspect of the invention, a method of operating a protocol data unit processing device in a heterogeneous communication network is provided to transfer protocol data units within the communication network. This method is performed by device-implemented steps in a series of distinct processing steps that can be implemented in one or more processors. In the first processing step a first and a second protocol data unit are received from the communication network where the first and the second protocol data unit are of different types. The second processing step involves establishing the subsequent processing requirements of the first and the second protocol data unit to generate at least one associated directive for each protocol data unit. Each protocol data unit is synchronized with the at least one associated directive for each protocol data unit to generate a first and a second synchronized protocol data unit, respectively. Then, each synchronized protocol data unit is restructured in accordance with the at least one associated directive for each protocol data unit to generate a first and a second restructured protocol data unit, respectively. Finally, the first and the second restructured protocol data unit are provided to other components in the communication network.

The first and the second protocol data unit may differ from one another in several ways in the heterogeneous communication network including but not limited to being of different physical layer media types, different link layer signaling protocols, and/or different network layer protocols.

These and various other features as well as advantages which characterize the present invention will be apparent upon reading of the following detailed description and review of the associated drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a prior art network device.

FIG. 2 is a block diagram of a preferred embodiment network device in accordance with the present invention.

FIG. 3 is a block diagram of an alternative preferred embodiment network device having serial connected preprocessors in accordance with the present invention.

FIG. 4 is a block diagram of an alternative preferred embodiment network device having parallel connected preprocessors in accordance with the present invention.

FIG. 5 is a block diagram of a preferred embodiment decision processor and mem