Tunneling solves IP traffic snarls

Existing networks, as well as the emerging multiprotocol label switching, or MPLS, types, use traditional and well-understood Ethernet, PPP (Layer 2) and IPv4 (Layer 3) addressing protocols. These serve existing networks reasonably well; however, IPv4 Layer 3 addressing space is beginning to run out with the proliferation of wireless products and a multitude of other networking appliances.

Tunneling IPv6 over IPv4 solves that problem. Combining them over existing networks is a reasonable solution since IPv4 will remain ubiquitous. The infrastructure supporting the IPv4 protocol suite is well-established, but implementing an all-native IPv6 infrastructure is far too expensive and disruptive to even contemplate. Therefore, the IPv4 address limitations must be worked around on the existing IPv4 and expanding MPLS networks.

Though IPv6 may well solve the problem of addressing, it is highly unlikely that ubiquitous IPv6 networks will soon be built end to end. The likely solution will be to tunnel IPv6 traffic over existing IPv4 networks and new MPLS networks. Clearly, a significant problem that must be solved before existing networks can be used will be how to quickly and efficiently resolve deep complex tunnels. However, tunnel resolution places severe processing burdens on edge routers in the form of multipass packet header classification and forwarding.

When it comes to handling Internet traffic, two classification problems have emerged: upper-layer "deep-packet classification" and Layer 2-4 multipass header classification.

Deep-packet classification, commonly referred to as Layer 7, is an increasingly important technology that has received much attention, but it is not the technology to solve the problems associated with complex tunnel resolution. In reality, most deep-packet switching is done on payload data content that is deeper into the packet than the Layer 7 header. The looming demands on and increasing complexity of the more established Layer 2-4 header classification are the primary concerns in the market for the next several years and cannot be ignored.

Many would assume that since the market for products that perform Layer 2-4 header classification is large and established, solutions are well-understood and implemented. Though this may be true to some extent, many factors are moving forward simultaneously that dramatically complicate and challenge the existing solutions. A prime example is the advent of IPv6 deployments. These factors make continued enhancement to Layer 2-4 classification an extremely critical area of new technology focus.

Header classification that examines specific fields (such as IPv4 or IPv6 addresses) at known locations is conceptually simpler than deep content inspection of data patterns that are located at random places deep within the packet payload. Header classification involves looking at known, fixed fields in a header and classifying them using table searches. Since only the header is analyzed, it is not necessary to wait until the entire packet has been received before beginning the process.

On the other hand, deep-packet classification uses string searches to look for data patterns (cookies, URLs, CGIs) deep within the packet payload. These searches often involve the classification of complex regular expressions, requiring the use of general-purpose CPUs or special-purpose ASICs. Moreover, deep-content inspection is inherently nondeterministic, resulting in dramatic swings in time to resolution. This nondeterministic nature is generally incompatible with today's highly channelized transport networks, where increasing bandwidth demands coupled with end-to-end latency and quality-of-service require time-critical deterministic analysis. Consequently, forwarding decisions are made much sooner when only header fields are classified since less of the packet must be buffered before the process begins and subsequently completes.

It is our belief that Layer 2 classification should be integrated directly into the fast path software-programmable network processing units, while deep-packet classification should be passed on to a dedicated coprocessor silicon. There are several very important reasons for this.

Deep-packet functionality

First, neither the market nor the technology supports the need to integrate deep-packet functionality into the majority of applications. Second, the Layer 2-4 performance and buffering overhead would be severely affected because the packet must be stored until the content match is found. Finally, updates in Layer 2-4 policies are generally very fast (microseconds) and can make use of ternary content-addressable memory (TCAM) technologies, while deep-packet policy updates are invariably made in software through the control plane and can take seconds to perform.

The concerns with Layer 2-4 header classification are therefore of a different nature than deep packet, and from both a marketing and technical point of view should be decoupled.

Most solutions today rely on software, either an algorithmic tree-based approach running on a standard network processing unit coupled to SDRAM-SSRAM tables or on content addressable memories (CAMs). Algorithmic-based solutions (Hash, Trie, Chained Index, Chained Hash) have serious disadvantages at high search rates.

They are primarily nondeterministic and can require backtracking in the search tree, resulting in unpredictable response times. Because of this, they are generally applicable to lower search rate applications (streams at 1 Gbit/second or less) where table size efficiency can be traded off for performance. For high-end applications, CAMs are generally the solution of choice, with the three-state CAMs known as TCAMs predominating.

A third approach has arisen in the form of largely hardware-based solutions: classification coprocessors using internal embedded table memory. But the market simply has not accepted this approach because table sizes grow extremely quickly and must be tuned on a system-by-system application basis. System designers must have the freedom to appropriately right-size their tables; thus, only a solution supporting external tables (or a combination of limited internal tables and external tables) is acceptable.

The market has clearly indicated that for high-performance applications, solutions must utilize TCAMs. However, TCAMs alone won't be enough to efficiently stem the rise in search rates while maintaining cost-effective implementations. What is needed is Layer 2-4 classification processors that are designed to work with software-based search tables.

See related chart