Method and apparatus to increase forwarding silicon functionality through packet manipulation

A packet preprocessing device is used in conjunction with a non-programmable packet forwarding processor (NLFP) to apply a different system function to received data packets than the function normally applied by the NLFP on the packets. Received data packets are pre-processed (e.g., modifying, manipulating, altering, spoofing, etc.) in order to enable, or cause, NLFPs that process the data packets to provide, in effect, a system-level behavior on the packets that is different from the system-level behavior for which the NLFP is/was conventionally designed. The data packet is “pre-processed” to change or manipulate the data packet, and then the NLFP processes the pre-processed data packet in accordance with its conventional function(s) which alters the overall function applied to the data packet.

TECHNICAL FIELD

The present invention relates generally to data packet communications, and more particularly, to methods and devices for forwarding data packets using packet manipulation.

BACKGROUND

One class of semiconductor devices gaining prominence in the data packet communications industry is referred to as non-programmable packet forwarding processors (NLFP). These devices, as compared to conventional network processors, are inexpensive with relatively high performance, but lack flexibility and programmability. One reason for this is that the devices are mass-produced with economies of scale. However, these same economies dictate the support functions in mass market systems. The major drawback is that features associated with “long-tail” or niche applications are not supported. Examples of these NLFPs include devices manufactured by Broadcom, such as those marketed and designated under the name Trident™ (BCM56XXX), and Intel, such as those marketed and designated under the name Fulcrum™ (FM2000, FM4000).

For historical and market reasons, these devices are optimized around functionality related to Layer 2 switching. The broad prevalence of Ethernet switching has made it an attractive point of optimization. It is difficult, if not impossible, to implement highly-scaled Layer 3 routing functionality in these devices when such functionality is new and complex, such as in new forms of VPN functionality or IPv6. Advanced and differentiated functionality requires the use of more expensive and power-consuming network processors.

In the rapidly changing networking industry, it would be optimal to leverage the low-cost and high forwarding capacity of these NLFPs to make a cost-effective system design while implementing some of the advanced capabilities and flexibility of network processors. This is particularly true in the data center space. As data centers expand and take on more complexity with virtualization, they require traditional switching silicon to provide more scaled and diverse functions.

Accordingly, there are needed methods and devices that can be utilized with conventional NLFPs to provide these devices with some advance capabilities (as those provided in expensive and programmable network processors).

SUMMARY

In accordance with one embodiment, there is provided a method of routing/forwarding a data packet. The method includes receiving a data packet, pre-processing the received data packet to generate a modified data packet, forwarding the modified data packet to a non-programmable packet forwarding processor (NLFP), processing, by the NLFP, the received modified data packet according to the NLFP functionality to generate a processed data packet, and outputting the processed data packet.

In accordance with another embodiment of the present disclosure, there is provided a routing/forwarding switching device having a packet pre-processor configured to receive a data packet and pre-process the data packet to generate a pre-processed data packet; and a non-programmable packet forwarding processor (NLFP) configured to receive the pre-processed data packet and process the data packet according to the NLFP functionality.

In still another embodiment, there is provided a method for pre-processing a data packet in a network. The method includes receiving a data packet at a pre-processor (PP) device; pre-processing the received data packet to generate a modified data packet; and forwarding the modified data packet to a non-programmable packet forwarding processor (NLFP) for processing.

In yet another embodiment, there is provided a pre-processing (PP) device for use in a data packet communication system. The PP device includes an interface configured for receiving a data packet, a processor coupled to the interface and configured for pre-processing the data packet and generating a modified data packet, memory coupled to the processor and configured for storing information that enables the processor to generate the modified data packet, and the interface is further configured for outputting the modified data packet for input to a non-programmable packet forwarding processor (NLFP).

DETAILED DESCRIPTION

In general terms, the present disclosure describes and teaches methods and devices for pre-processing data packets. In one embodiment, a packet pre-processing (PP) device is coupled to a non-programmable packet forwarding processor (NLFP) to pre-process the data packet prior to processing by the NLFP. The PP device and its functionality described herein may be implemented in various embodiments. For example, the PP device may be constructed or implemented as a field programmable gate array (FPGA), programmable array logic (PAL), an application specific integrated circuit (ASIC), and the like. The PP devices may also be implemented as software within a controller, processor, central processing unit (CPU), and the like. In other embodiments, the PP device may be embodied as a logic block within a media access controller (MAC), or as a logic block or core within an NLFP device itself.

The present disclosure introduces ways to implement new features with (or on) low-cost non-programmable silicon (e.g., NLFP devices) in an efficient manner. This allows communications equipment manufacturers to utilize NLFPs (e.g., an Ethernet controller) in their designs, while also implementing and integrating unique and differentiated functionality. In this way, a manufacturer can benefit from the economics of NLFPs suppliers' production, but avoid the commoditization of the manufacturer's systems. The present disclosure discloses and describes a mapping function that translates one set of features to another set of features, and/or alters portions of features.

As one example, large Internet data centers (e.g., Facebook, Google), as well as Enterprise data centers (e.g., Microsoft), are actively moving or transitioning to the Internet Protocol (IP) version 6 (IPv6). Current data center switching technology (e.g., NLFPs) does not support a scalable IPv6 data path (the current data path limit is about 30K routes). The PP device and methods described in the present disclosure enable systems to substantially increase that limit, and in some cases, perhaps by an order of magnitude (about 250K routes).

Generally, the present disclosure teaches and describes devices and methods for pre-processing (e.g., modifying, manipulating, altering, spoofing, etc.) data packets in order to enable, or cause, NLFPs that process the data packets to provide, in effect, a system-level behavior on the packets that is different from the system-level behavior for which the NLFP is/was conventionally designed. In other words, the data packet is “pre-processed” to change or manipulate the data packet, and then the NLFP processes the pre-processed data packet in accordance with its conventional function(s).

As will be appreciated, the term “pre-process” as used and described herein refers to processing the data packet in some manner so as to modify its contents. This may include appending data to the packet, or in most cases, changing the contents of the data packet. Pre-processing a data packet (as described herein) refers to modifying a data packet to enable a non-programmable packet forwarding processor (NLFP) to further process the data packet in accordance with a system function different from the system function normally provided by the NLFP in the switching system.

As one example, let us assume that a particular NLFP normally functions to provide data packet routing/forwarding based on MAC address(es) (e.g., source and/or designation MAC address). This NLFP cannot be utilized for routing/forwarding of data packets according to an IPv6 address scheme. In the present disclosure, pre-processing of a data packet having IPv6 addresses occurs in such a manner so as to enable the NLFP to route/forward the data packet according to the IPv6 address(es) therein. While this is but one example of pre-processing the data packet, data packets may be pre-processed differently depending on the functionality of the NLFP and the desired system function to be performed on the received data packet. Examples of other desired system functions that may be applied to data packets or processed in accordance with this disclosure may include L2 VPN forwarding, L3 VPN forwarding, network address translation, IPv4 forwarding table expansion, Openflow-based forwarding (based on Open Network Foundation forwarding specifications), deep-packet inspection, and the like, etc.

Now turning toFIG. 1, there are shown in block diagram form relevant portions of a switching system or device100in accordance with the present disclosure. The switching device100(which may also be referred to herein as a “packet forwarding processor”) includes a packet pre-processor (PP) device110and a non-programmable packet forwarding processor (NLFP)120. Though shown implemented within a line card180having a physical port/connector190, the switching device100may be implemented or incorporated into any suitable device or system.

As will be appreciated, the NLFP120is non-programmable, and those of ordinary skill in the art can readily understand (and differentiate between) those conventional NLFPs which are non-programmable and those which are programmable. In the event such understanding may not be apparent, a programmable packet forwarding processor is a device which includes an instruction store in memory and uses a load and execute architecture/functionality (e.g., loads and executes instructions). In other words, a packet forwarding processor structured or operating as a Von Neumann (Princeton) or Harvard architecture is programmable. The NLFP120of the present disclosure does not include this architecture/programmability.

The PP device110pre-processes a received data packet prior to the NLFP120performing its relevant process(es) or function(s) on the data packet. Thus, as shown inFIG. 1, the PP device110is disposed within the data path upstream from the NLFP120. In another embodiment (not specifically shown), the PP device110may be coupled to the NLFP120via a “look-aside” interface that is coupled to the data path within the NLFP120at a point prior to the point the relevant process(es) or function(s) are performed on the data packet by the NLFP120.

One example embodiment that may be implemented using the teachings herein is directed to IPv6 data packet routing/forwarding. In this example, scaled IPv6 routing/forwarding can be accomplished using the NLFP120which is configured as a Layer 2 Ethernet switching device based on MAC addressing. As will be appreciated, current conventional NLFPs support large MAC forwarding tables (about 250K entries) and also support relatively small IPv6 forwarding tables (e.g., about 30K entries). Data centers that currently use a Layer 3 design and which want to support IPv6 will need support for a much larger IPv6 forwarding table.

Utilization of the PP device110and the methods described herein enables continued use of the conventional NLFPs within the overall switching/routing system. This provides support for larger IPv6 forwarding tables without the need for expensive programmable network processors. The present disclosure also introduces a control plane process that maps the desired function or behavior to the function(s) of the NLFP120.

Now turning toFIG. 2, there is illustrated a flow diagram of a process200for receiving a data packet at the PP device110(step210), pre-processing the received data packet (step220) to generate a modified data packet, forwarding the modified data packet to the NLFP120(step230), processing the received modified data packet by the NLFP120according to the original/conventional functionality of the NLFP120(step240), and outputting (from the NLFP120) the processed data packet (step250).

The PP device110modifies the received data packet in a manner or way which enables the NLFP120to perform its original/conventional process(es) or function(s) on the modified packet—yet provides a system function on the data packet that is different from the normal system function provided on the data packet without the pre-processing. Without the PP device110, the received data packet could not be processed, or would not be processed according to the desired system function, by simply inputting the received data packet to the NLFP120. In other words, data packets that normally cannot be processed by the NLFP120(in accordance with a desired system function different from the normal system function of the NLFP) can now be processed and routed/forwarded by the NLFP120.

Now turning toFIG. 3, there is shown an example flow diagram illustrating the format of data packets as received and output by the PP device110and the NLFP120. This example is directed to pre-processing and processing of an IPv6 data packet310for forwarding purposes (based on the IPv6 destination address field). As shown, the PP device110receives the data packet310at its input. The data packet310includes a source MAC address310a, a destination MAC address310b, and an IPv6 header310c. Within the IPv6 header are typically included a source IPv6 address and a destination IPv6 address. As will be understood, other fields or data bits are typically included in the data packet310but are unnecessary for an understanding of the present disclosure.

Typically, within a switching/routing network, the various routers/switches have access to one or more routing/forwarding tables. These tables may global or local, and generated statically (e.g., manually, at setup, etc.) or dynamically/adaptively during operation of the network (e.g., open shortest path forwarding (OSPF), etc.). The manner in which these particular tables may be generated is well-known in the art, and no further description is provided. In other words, the network generally includes a control plane that maintains and populates these routing/forwarding tables.

As will be appreciated, the device100, and more particularly the PP device110, is configured to access an IPv6 routing/forwarding table (not shown in the Figures) populated with numerous entries. It will be further understood that the IPv6 routing/forwarding table may be stored in memory within the PP device110or otherwise accessible to the PP device110.

In one embodiment, a processor or controller (not shown inFIG. 2) within the PP device110generates a pseudo-MAC (PMAC) table from information found in the IPv6 routing/forwarding table. In the example shown inFIG. 2(i.e., forwarding based on IPv6 destination address), the PMAC table includes numerous entries each including a correspondence between an IPv6 destination address and a PMAC. As will be appreciated, the PMACs are pointers or identifiers that correspond to IPv6 addresses in the IPv6 table. In other embodiments, the PMAC table may be statically or dynamically/adaptively generated, and may further be stored and maintained at some location other than within the PP device110but accessible to the PP device110.

The PP device110looks up the IPv6 destination address in the PMAC table to find its corresponding PMAC. The PP device110pre-processes (modifies) the received packet310by overwriting the destination MAC310bof the packet310with the PMAC that corresponds to the IPv6 destination address found in the IPv6 header310cand generates a modified packet320. As shown inFIG. 3, the output of the PP device110is the pre-processed or modified packet320including a source MAC address320a, a PMAC320b, and an IPv6 header320c. In this embodiment, the source MAC address320aand the IPv6 header320care the same as the source MAC310band the IPv6 header310cfrom the original packet310.

After pre-processing (modification), the modified packet320is forwarded to the NLFP120for processing. This processing performs a MAC-based routing/forwarding process and sends the processed packet out the correct egress port toward its destination). In this procedure, the NLFP120correlates the received PMAC320band the source MAC320awith a MAC-based forwarding table. As will be appreciated, the NLFP120performs its normal function of routing/forwarding (MAC-based routing) based on the information in the MAC address field(s)—and in this particular embodiment, that field is the conventional destination MAC address field (e.g.,320b). Thus, the NLFP120inspects the information in the field which it believes is a destination MAC address and routes/forwards the packet based on its MAC routing table (not shown). As will be appreciated, the destination MAC address field does not include a real destination MAC address, but actually includes the PMAC320bin its place.

In normal operation, the NLFP120maintains (or has access to) a MAC-based next hop table which identifies the egress port/interface to which the data packet should be sent. The NLFP120performs its normal function of receiving a data packet having MAC address fields (and other fields) and generating an internal header for the data packet for delivery of the data packet to the appropriate egress/interface port.

As noted previously, within the switching/routing network, the various routers/switches have access to one or more routing/forwarding tables. With respect to the NLFP120, it utilizes a MAC-based routing/forwarding table to process the data packets. Similarly, such MAC-based routing/forwarding tables may be stored in memory within the NLFP120or otherwise accessible to the NLFP120.

In one embodiment, the MAC-based routing/forwarding table is generated by the processor or controller (not shown inFIG. 2) within the PP device110. In another embodiment, it may be generated by another control plane (e.g., the network). The MAC-based routing/forwarding table may be stored within the NLFP120or stored at some other location accessible to the NLFP120.

With reference/access to the original IPv6 routing/forwarding table and the generated PMAC table, the MAC-based routing/forwarding table to be used by the NLFP120can be generated. As will be appreciated, and for example, the original IPv6 table will include entries associating the IPv6 destination entries with forwarding entries. With the knowledge of which PMAC is assigned to which IPv6 destination address (in the PMAC table), the MAC-based routing/forwarding table is generated with PMAC entries and their associated routing/forwarding entries.

As a result, the NLFP120routes/forwards the data packet unknowingly based on the information within the IPV6 routing/forwarding table, although it inspects the data packet field which normally includes a destination MAC address.

In the embodiment shown inFIG. 3, the NLFP120outputs a processed data packet330having an internal header331, a source MAC330a, a PMAC330band an IPv6 header330c. As will be appreciated, the source MAC330a, the PMAC330band the IPv6 header330care the same source MAC320a, the PMAC320band the IPv6 header320cfrom the pre-processed packet320. The internal header331includes a MAC address and next hop information (obtained from the MAC-based routing/forwarding table.

The embodiment described above and shown inFIG. 3is directed to routing/forwarding of IPv6 data packets based on the IPv6 destination address. As will be appreciated, the routing/forwarding may also be based on the source address or on both the source and destination addresses. In addition, although the embodiment described is directed to receiving and routing/forwarding a data packet, the principles and teachings of the present disclosure are similarly or equally applicable in the reverse.

There are two ways to solve the problem of collisions between real MACs and PMACs. One method is to simply reserve a small number of officially registered MACs under a known Organizationally Unique Identifier (OUI) to be used as PMACs. The same set may be used by any PP device110because the MACs may be overwritten (in Layer 3 mode). The other method would be for the PP device110to look for packets with collisions and overwrite the MACs of such packets with a PMAC that does not correspond to any forwarding entry (a NULL PMAC).

Similar methods can be used to implement tunneling and VPNs techniques such as Virtual Private Local Area Network (LAN) Service (VPLS), List Processing (LISP), Layer 3 (L3) VPNs. Other methods may be implemented using the teachings herein (e.g., utilization of a PP device110to modify data packets prior to input to the NLFP120to enable a different system function to be applied to the data packet than the system function normally applied by the NLFP120).

At least the PP device110described in the disclosure may be implemented as a network apparatus or component, such as a network node or unit. For instance, the features/methods in the disclosure may be implemented using in a PP device including hardware, firmware, and/or software installed to execute on hardware (as described above).

As illustrated inFIG. 4, the PP device110may be implemented in accordance with a device400that includes one or more ingress ports410and egress ports420(interface), a receiver430coupled to the ingress ports410(for receiving data packets from other devices), a transmitter440coupled to the egress ports420(for transmitting data packets to other devices, such as the NLFP120), and a processor450(or controller) coupled to the receiver430and to the transmitter440for preprocessing (modifying) received data packets. The processor450may include one or more processors, or multi-core processors. Though not shown, the device400includes memory that stores various operating instructions (e.g., firmware, software) which controls the operation of the device400as desired, and may be configured to store the PMAC table. Further, the ingress ports410and/or the egress ports420may be constructed or configured with components to provide electrical and/or optical transmitting and/or receiving functionality.

At least one embodiment is disclosed and variations, combinations, and/or modifications of the embodiment(s) and/or features of the embodiment(s) made by a person having ordinary skill in the art are within the scope of the disclosure. Alternative embodiments that result from combining, integrating, and/or omitting features of the embodiment(s) are also within the scope of the disclosure.