Policy engine architecture

Details Policy engine architecture Policy engine architecture

1999-12-16

2003-09-23

Vanderpuye, Kenneth (Department: 2661)

Multiplex communications

Pathfinding or routing

Switching a message which includes an address header

C370S230000, C370S235000, C709S238000

Reexamination Certificate

active

06625150

ABSTRACT:

TECHNICAL FIELD
The present invention relates to policy-based network equipment and, in particular, to policy-based network equipment that employs a favorable division of hardware and software to provide both performance and flexibility.
BACKGROUND
Some typical policy-based computer network applications are Virtual Private Networks (VPN), Firewall, Traffic Management, Network Address Translation, Network Monitoring, and TOS Marking. In general, the policy-based application has access to the network media through an operating system driver interface. In a typical network architecture, the policy-based application examines every packet coming in from the network along the data path, compares it against flow classification criteria, and performs the necessary actions based upon the policies defined in a policy database.
Today's policy-based applications are challenged with several key issues. These issues can be major inhibitors for the future growth of the emerging industry:
1) Flow classification overhead—Flow classification specifications can be complicated and lengthy for each network service. As can be seen from
FIG. 1
, in a conventional policy-based application, each packet compared with potentially hundreds of rules in order to find the matching one and determine the proper action specifications. With stateful applications, state tracking is even more time consuming. Multiple network services on a single system simply make matters worse.
As is also shown in
FIG. 1
, the process of flow classification and action processing may repeat for many iterations as multiple policies are activated at the same time. For example, a VPN (virtual private network) application may comprise Firewall Policy, IPSEC Policy, IPCOMP (IP compression) policy, NAT (Network Address Translation) Policy, QoS (Quality of Service) policy, Monitoring Policy, L
2
TP/PPTP (L
2
Tunnel Protocol/Point To Point Tunnel Protocol) Tunnel Policy, and so on.
The flow classification is a rule based operation that can be very flexible to tune to application needs. For example, it may define a rule to identify packets with a pattern of any random byte within a packet, and/or across many packets. The flow classifiers may also differ per action processor for performance optimization. As a result the matching criteria used by a flow classifier to classify a flow may include a specific value, a range, or wildcard on interface port numbers, protocols, IP addresses, TCP ports, applications, application data, or any user specifiable criteria. The distinctions of various implementation makes it difficult to cache a flow with its decision in many ways.
2) Flow classification technique is evolving—Flow classification and analysis technique is more than just looking into the packet's address, port number and protocol type and or other header information. It often involves state tracking for newer applications. This technique is being continuously modified and, therefore, is not practically appropriate for a hardware based implementation. Furthermore, flow classification techniques are often viewed as key differentiaters between vendors.
3) Action execution speed—Once the classification process is complete, the proper actions need to be executed. Some of the actions are simple like a discard or forwarding decision for a firewall, while some others are extremely time consuming, like triple-DES encryption and SHA hashing algorithm or QOS scheduling algorithm. Software based implementations cannot keep up with the bandwidth expansion as newer and faster media technologies are employed.
4) Integrated services—As more and more policy-based applications become available, it is desirable to provide integrated services on a single platform because this ostensibly reduces policy management complexity, avoids potential policy conflicts, and lowers the TCO (Total Cost of Ownership). On the other hand, integrated services impose a very large computing power requirement that cannot be practically achieved with off-the-shelf general purpose machines. A disadvantage of the conventional architecture is that, because it is primarily software-based, it is relatively high overhead. However, precisely because it is software-based, it is quite flexible.
What is desired is a policy architecture has the flexibility of present flow classification systems, but that also has lower overhead.


REFERENCES:
patent: 5371852 (1994-12-01), Attanasio et al.
patent: 5473599 (1995-12-01), Li et al.
patent: 6041053 (2000-03-01), Douceur et al.
patent: 6078953 (2000-06-01), Vaid et al.
patent: 6104700 (2000-08-01), Haddock et al.
patent: 6157955 (2000-12-01), Narad et al.
patent: 6292465 (2001-09-01), Vaid et al.
U.S. patent application Ser. No. 09/465,123, Lin, filed Dec. 16, 1999.
Adadi, M., et al, “Secure Web Tunneling,” http://pa.bell-labs.com/~abadi/Papers/tunnel/206.html, pp. 1-13 (Dec. 16, 2000).
“Intel ISP Program Case Studies: UUNET Canada Leads the Industry in Move to Virtual Private Networks,” http://www.intel.com/isp/casestudies/uunet.htm, pp. 1-4 (2000).
“Tunnel Switching: 3Com Technology Boosts VPN Security and Flexibility,” http://www.3com.com/technology/tech_net/white_papers/503049.html, pp. 10 (1999).
“Virtual Multi-megabit Access Path: Affordable and Available Internet and IP Access at Speeds Greater than T1,” http://www.tiaranetworks.com/vmapwp.html, pp. 1-9 (1999).
“Web Workshop—Virtual Private Networking: An Overview,” http://msdn.Microsoft.com/workshop/server/feature/vpnovw.asp, pp. 1-16 (May 29, 1998).
Ferguson, Paul and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing,” http://andrew2.Andrew.cmu.edu/rfc/rfc2267.html, pp. 1-16 (Jan. 1998).
“The NetBoost Policy Engine: Comprehensive Platform Enables Today's Leading Policy Enforcement Applications to Operate at Full Wire Speed,” NetBoost Corporation, pp. 1-9 (1998).
“The NetBoost Policy Appliance: Device Enables Concurrent Operation of Multiple Policy Enforcement Applications to Operate at Full Wire Speed,” NetBoost Corporation (1998).
“NetBoost PE—1000: Network Application Engine,” NetBoost Corporation (1998).
NetBoost SKD: Software Development Kit, NetBoost Corporation (1998).
“A New Breed: The Net Boost Platform for Policy Enforcement Applications,” NetBoost Corporation, pp. 1-11 (1998).
Russell, Paul, “Keeping the TCP/IP Stream Flowing,” Linux Magazine, http://www.linux-mag.com/1999-08/bestdefemse0.2html, pp. 1-8 (Aug. 1999).

Affiliated with

Also associated with

Rating

Policy engine architecture does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Policy engine architecture, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Policy engine architecture will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3032402