US20030067874A1

US20030067874A1 - Central policy based traffic management

Info

Publication number: US20030067874A1
Application number: US10/127,167
Authority: US
Inventors: Michael See; David Morgan; Stephen Clawson; L. Goodwin
Original assignee: Alcatel SA
Current assignee: Alcatel Lucent SAS
Priority date: 2001-10-10
Filing date: 2002-04-22
Publication date: 2003-04-10
Also published as: EP1303079B1; EP1303087A2; DE60224629D1; US7339942B2; EP1303079A2; ATE350831T1; US20030076849A1; ATE384381T1; EP1303087A3; DE60217253D1; EP1303087B1; EP1303079A3; DE60217253T2

Abstract

A switching node configuring different traffic management protocols via a single centralized set of policies. The switching node includes a central policy repository, a central policy engine, and a central management engine. The central policy repository stores a single set of policies used to manage a plurality of different traffic management protocols in a consistent and predictable manner. The different traffic management protocols may include QoS, NAT, ACL, and the like. The central policy engine evaluates inbound traffic flows based on the policies in the central policy repository, and configures one or more traffic management protocol entities based on a selected policy. The management engine configures and manages the single set of policies via a common set of commands helping to eliminate the danger of creating conflicting policies that may lead to unpredictable results.

Description

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application claims the benefit of U.S. provisional application No. 60/328,159, filed on Oct. 10, 2001, the content of which is incorporated herein by reference.[0001]

FIELD OF THE INVENTION

The present invention relates generally to traffic control in a data communications network, and more particularly, to configuring different network protocols associated with traffic management via a single centralized set of policies.

BACKGROUND OF THE INVENTION

Policy based traffic control has become increasingly important in data communication networks as data traffic competes for limited bandwidth. Policy based traffic control generally involves separate, independent interfaces for configuring different traffic management protocols.

FIG. 1 is a schematic block diagram of a

switching node

9 for policy based traffic control according to conventional mechanisms. The switching node includes separate,

independent policy engines

11, 13, 15 and associated

interfaces

17, 19, 21 for managing and configuring different traffic management protocols. For example, a switching node may include a separate policy engine for controlling quality of service (QoS), IP filtering via access control lists (ACL), network address translation (NAT), and the like. Each policy engine is associated with a control interface used by a network administrator to configure and manage the associated policies for a discrete traffic management protocol.

In general terms, an inbound packet is processed by a first policy engine, such as, a QoS policy engine, for a matching policy. If a match is found, the matching policy is enforced and the packet is generally not processed by the other policy engines. If a match is not found, the packet is processed by a next policy engine for a match. Under existing technology, therefore, multiple actions from different policy engines are either impossible or difficult to perform for a specific traffic flow. It is often desirable, however, to be able to perform such multiple actions. For example, it may be desirable to invoke a NAT policy engine for address translation based on a source IP address while simultaneously invoking the QoS policy engine for assigning a QoS priority to the flow based on the same source address.

Another problem with the current policy based traffic control is that the use of separate, independent interfaces for configuring the policies generally requires the network administrator to learn and use different command sequences for configuring and managing different policy engines. This may result in the configuration of conflicting policy rules that may lead to unpredictable results, especially if the configurations are done by different administrators or the same administrator at different times.

Accordingly, there is a need for a mechanism for providing and applying a common and consistent set of policies to traffic flowing through a data communications network. The mechanism should allow a switching node to enforce a singe policy with multiple actions in a consistent manner.

SUMMARY OF THE INVENTION

The present invention is directed to traffic management via a single centralized set of policies. According to one embodiment, the invention is directed to a switching node in a data communications network that includes an input, a repository, a policy engine, and a management engine. The repository stores a single set of policies for controlling a plurality of different traffic management protocols. The policy engine is coupled to the input and the repository, and is configured to evaluate an inbound packet based on a policy selected from the single set of policies, and configure one or more traffic management protocol entities based on the selected policy. The management engine is coupled to the repository and the policy engine. The management engine configures and manages the single set of policies via a common set of commands.

According to another embodiment, the invention is directed to a method for policy based traffic management where the method includes storing in a repository a single set of policies for controlling a plurality of different traffic management protocols. The method includes receiving a first packet, retrieving a first policy from the repository where the first policy identifies a first action for configuring a traffic management protocol entity of a first protocol type, and configuring the traffic management protocol entity based on the first action. The method also includes receiving a second packet, retrieving a second policy from the repository where the second policy identifies a second action for configuring a traffic management protocol entity of a second protocol type, and configuring the traffic management protocol entity based on the second action.

According to a further embodiment, the invention is directed to a method for policy based traffic management where the method includes storing in a repository a single set of policies for controlling a plurality of different traffic management protocols, receiving a packet, and retrieving a policy from the repository which identifies a first and second action for controlling traffic management protocol entities of a first and second protocol type. The method includes configuring the traffic management protocol entity of the first protocol type based on the first action and configuring the traffic management protocol of the second protocol type based on the second action.

In an additional embodiment, the invention is directed to a method for policy based traffic management where the method includes storing in a repository a single set of policies for controlling a plurality of different traffic management protocols, receiving a packet, and searching a policy cache for a policy applicable to the packet. If the policy cache does not include an applicable policy, the method includes searching the repository for a match, and generating and storing a new policy in the policy cache. The new policy is selected as applicable to a future packet if the repository contains no other policies that are also applicable to a future packet but are different from the new policy.

It should be appreciated, therefore, that the evaluation of traffic via a central policy engine allows the configuration of traffic management protocol entities of different protocol types, such as quality of service, access control, network address translation, and the like, in a consistent and predictable manner. The management of the policies via a common set of commands and the storage of the policies in a central repository help eliminate the creation and application of conflicting policies that could result in unpredictable results.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects and advantages of the present invention will be more fully understood when considered with respect to the following detailed description, appended claims, and accompanying drawings where: [0013]
FIG. 1 is a schematic block diagram of a switching node for policy based traffic management according to conventional mechanisms; [0014]
FIG. 2 is a schematic block diagram of a network environment including a packet switching node according to one embodiment of the invention; [0015]
FIG. 3 is a block diagram of a switching interface in one embodiment of the present invention; [0016]
FIG. 4 is a schematic block diagram of the packet switching controller providing and applying a common, centralized set of simple policies for controlling a plurality of traffic management protocols according to one embodiment of the invention; [0017]
FIG. 5 is a more detailed diagram of the switching controller of FIG. 4 according to one embodiment of the invention; [0018]
FIG. 6 is a conceptual layout diagram of various types of policy objects provided by a central management engine for creating a centralized set of policies according to one embodiment of the invention; [0019]
FIG. 7 is a conceptual layout diagram of a central policy repository according to one embodiment of the invention; and [0020]
FIG. 8 is a flow diagram of a central policy based traffic management according to one embodiment of the invention.[0021]

DETAILED DESCRIPTION

FIG. 2 is a schematic block diagram of a network environment including a [0022] packet switching node 10 according to one embodiment of the invention. The packet switching node may also be referred to as a switch, a data communication node or a data communication switch. The packet switching node 10 includes switching interfaces 14, 16 and 18 interconnected to respective groups of LANs 30, 32, 34, and interconnected to one another over data paths 20, 22, 24 via switching backplane 12. The switching backplane 12 preferably includes switching fabric. The switching interfaces may also be coupled to one another over control paths 26 and 28.
The [0023] switching interfaces 14, 16, 18 preferably forward packets to and from their respective groups of LANs 30, 32, 34 in accordance with one or more operative communication protocols, such as, for example, media access control (MAC) bridging and Internet Protocol (IP) routing. The switching node 10 is shown for illustrative purposes only. In practice, packet switching nodes may include more or less than three switching interfaces.
FIG. 3 is a block diagram of a [0024] switching interface 50 in one embodiment of the present invention. The switching interface 50 may be similar, for example, to the switching interfaces 14, 16, 18 of FIG. 2. The switching interface 50 includes an access controller 54 coupled between LANs and a packet switching controller 52. The access controller 54, which may, for example, include a media access controller (MAC), preferably receives inbound packets off LANs, performs flow-independent physical and MAC layer operations on the inbound packets and transmits the inbound packets to the packet switching controller 52 for flow-dependent processing. The access controller 54 also receives outbound packets from the packet switching controller 52 and transmits the packets on LANs. The access controller 54 may also perform physical and MAC layer operations on the outbound packets prior to transmitting them on LANs.
The [0025] packet switching controller 52 receives inbound packets, classifies the packets, modifies the packets in accordance with flow information and transmits the modified packets on switching backplane, such as the switching backplane 12 of FIG. 2. The packet switching controller 52 preferably also receives packets modified by other packet switching controllers via the switching backplane and transmits them to the access controller 54 for forwarding on LANs. The packet switching controller 52 may also subject selected ones of the packets to egress processing prior to transmitting them to the access controller 54 for forwarding on LANs.
FIG. 4 is a schematic block diagram of the [0026] packet switching controller 52 providing and applying a common, centralized set of simple policies for coordinating a plurality of traffic management protocols, such as, for example, access control, address translation, server load balancing, quality of service, and the like. The switching controller 52 includes a central policy engine 56 coupled to a central management engine 58. The central policy engine 56 evaluates the traffic flow against the centralized set of policies to perform, from a central location, one or more policy actions typically performed by separate, independent policy engines. The centralized set of policies include, but are not limited to system policies, network policies, access policies, services policies, and the like. The one or more actions include, but are not limited to packet filtering, packet prioritizing, address translation, server load balance group assignment, and assignment of 802.1p. TOS, or DSCP values.
The [0027] central management engine 58 may include software and/or hardware components to enable a network administrator to configure and manage the centralized set of policies. With the central management engine 58, the network administrator may, from a single location and using a common set of commands, create policies that manage different traffic management protocols.
FIG. 5 is a more detailed diagram of the switching [0028] controller 52 according to one embodiment of the invention. The switching controller includes a packet buffer 102, packet classification engine 104, central policy engine 106, central policy enforcement engine 120, central policy repository 100, and central management engine 107. The packet classification engine 104, central policy engine 106, central policy enforcement engine 120, and central policy management engine 107 are logical devices that may be implemented in software, hardware, firmware (e.g. ASIC), or any combination thereof. It is understood, of course, that FIG. 5 illustrates a block diagram of the packet switching controller without obfuscating inventive aspects of the present invention with additional elements and/or components that may be required for creating the controller. These additional elements and/or components, which are not shown in FIG. 5 are well known to those skilled in the art.
The switching [0029] controller 52 receives inbound packets 108. The packets may include, but are not limited to, Ethernet frames, ATM cells, TCP/IP and/or UDP/IP packets, and may also include other Layer 2 (Data Link/MAC Layer), Layer 3 (Network Layer) or Layer 4 (Transport Layer) data units.
The received packets are stored in the [0030] packet buffer 102. The packet buffer 102 provides via output signal 110 the stored packets or portions thereof to the packet classification engine 104 for processing.
The [0031] packet classification engine 104 may include one or more of a data extractor and a data cache. In an alternative embodiment, the data extractor and data cache are provided within the packet buffer 102.
The data extractor is used to extract one or more fields from the packets, and to store the extracted fields in the data cache as extracted data. The extracted data may include, but is not limited to, some or all of the packet header. For example, the extracted data may include, but are not limited to, one or more of [0032] Layer 2 MAC addresses, 802.1P/Q tag status, Layer 2 encapsulation type, Layer 3 protocol type, Layer 3 addresses, ToS (type of service) values, Layer 4 port numbers, portions of the packet body, and/or any other data used for determining a policy.
The extracted data is transmitted to the [0033] central policy engine 106 via an output signal 112. The central policy engine 106 may be similar to the central policy engine 56 of FIG. 4.
The [0034] central policy engine 106 accesses either an internal policy cache 116 or the central policy repository 100 for selecting a policy applicable to the packet. In accessing the central policy repository 100, the central policy engine 106 communicates with the repository using protocols such as, for example, LDAP.
According to one embodiment of the invention, the [0035] policy cache 116 includes sufficient information for applying policies to existing traffic flows without having to process the entire list of policies in the central policy repository 100 for every packet in the traffic flow. The information in the policy cache 116 is specific enough to prevent packets for which a different applicable rule may exist in the central policy repository 100 to be processed by the policy cache 116.
The [0036] central policy repository 100 may be implemented in a local memory and/or an external directory server with Lightweight Directory Access Protocol (LDAP) access. The central policy repository 100 includes a list of policies that are based on the contents of a packet and/or other elements such as, for example, time information, port information, and the like. In general terms, policies are rules composed of one or more conditions that describe a packet and one or more actions defining how the packet is to be processed if the condition is satisfied.
The [0037] central policy engine 106 compares the extracted packet data with either the policies in the policy cache 116 or central policy repository 100. If a match is found between the condition(s) in the policy and the extracted data, the policy engine determines the action(s) to be taken on the packet. The action(s) to be taken on the packet are transmitted to the central policy enforcement engine 120 via an output signal 117.
The central [0038] policy enforcement engine 120 ensures that the packet is processed according to the parameters defined in the action(s). In this regard, the central policy enforcement engine 120 interacts with other hardware and software elements in the switching node 30 for causing a desired processing of the packet. For example, if the policy actions specify that the packet is to be transmitted at a high priority, the policy enforcement engine 120 may direct the packet buffer 102 to place the packet in a high priority queue of an egress port.
The [0039] central management engine 107 of FIG. 5 may be similar to the central management engine 58 of FIG. 4. The engine 107 may be either a dedicated console or part of a network management console. A network administrator accesses the central management engine 107 for configuring and managing the policies in the central policy repository 100 and the central policy engine 106. According to one embodiment, the central management engine 107 provides a graphical user interface that provides a common set of commands and tools for configuring and managing polices that control different network elements such as, for example, QoS, NAT, ACL, and the like. The central management engine 107 also allows a network administrator to test policies before they are applied.
FIG. 6 is a conceptual layout diagram of various types of policy objects provided by the [0040] central management engine 107 for creating the centralized set of policies according to one embodiment of the invention. In the illustrated embodiment, the policy objects include rule 200 objects, condition 202 objects, action 204 objects, service 206 objects, and group 208 objects. Rules 200 are top level objects including conditions 202 and actions 204. According to one embodiment, rules are provided precedence values indicative of an order in which the rules are to be applied.
[0041] Conditions 202 are parameters used to classify traffic, and actions 204 are parameters describing how to treat the classified traffic. A condition 202 may include a service 206 and/or a group 208. A policy service 206 may be used as a shorthand for certain parts of a condition. According to one embodiment, a policy service 206 is defined by a service name, an IP protocol, a source IP port, and/or a destination IP port. For example, a “video” service may be defined as being associated with a “UDP” protocol and destination IP port number “4500.” In another example, a “telnet” service may be defined as being associated with a “TCP” protocol and destination IP port number “23.”
A [0042] policy group 208 may be defined by a list of IP/MAC addresses, ports, or services. Policy groups allow a network administrator to define conditions for a group of address, ports, or services, instead of creating a separate condition for each address, port, or service. For example, an “engineering” group may be defined as a set of particular IP addresses. A “basic services” group may be defined as a set of particular services such as telnet, FTP, HTTP, and Sendmail.
According to one embodiment of the invention, the [0043] central management engine 107 allows the creation of policies defining multiple actions for managing different traffic management protocols. For example, a policy in the central policy repository 100 may indicate that traffic with a particular source address and a particular destination address is to have the source address translated and receive a high priority. Thus, two different actions, a NAT policy action and a QoS policy action, may be defined via a single policy rule. FIG. 7 is a conceptual layout diagram of the central policy repository 100 according to one embodiment of the invention. In this illustrated embodiment, the repository includes a policy table 300 including a list of simple policy rules 302. Associated with each policy rule are a precedence number 304, condition 306, and action 308. The precedence number 304 indicates an order in which the rules are to be applied. If traffic matches more than one rule, the central policy engine 106 uses the rule with the highest precedence. In the illustrated embodiment, rule 4 is not matched since it is a subset, or more specific, than the higher precedence rule 2. The precedence ordering of the rules helps eliminate any rule conflicts and ensures that the results of evaluating a traffic flow against the policies is predictable and consistent.
The [0044] condition 306 for each rule defines parameters used for classifying inbound packets. These parameters include but are not limited to individual source addresses or source address groups, individual destination addresses or destination groups, and individual IP protocols 306 e, individual IP ports 306 d, or policy service groups 306 c.
The [0045] action 308 for each rule defines one or more operations to be performed on the packet and/or traffic management protocol entities. The action 308 may be a filtering action, such as for example, dropping or admitting a packet. The action 308 may also be a QoS action such as, for example, assigning a priority to the packet. The action 308 may further be server load balancing, source or destination address translation, mapping or marking 802.1P, TOS, or DSCP values, or a combination of any of the discussed actions.
FIG. 8 is a flow diagram of a central policy based traffic control according to one embodiment of the invention. The process starts, and in [0046] step 400, the packet buffer 102 receives an inbound data packet and stores the packet in the buffer. In step 402, the packet classification engine 104 extracts one or more fields from the packets. In step 404, the central policy engine 106 determines whether the policy cache contains entries that match the extracted fields of the packet. If the answer in YES, the central policy enforcement engine 120 ensures that the policy action indicated in the matched entry of the policy cache is enforced.
If no match exists in the [0047] policy cache 116, the central policy engine 106 determines in step 408 whether there is an exact match of the extracted fields with conditions of a rule in the central policy repository 100. If the answer is YES, the central policy engine proceeds to program, in step 414, the policy cache 116 with the condition fields of the matched policy, the fields having the values of the corresponding extracted fields. This allows future data packets with the same extracted fields to match the newly programmed entry in the policy cache 116, avoiding another search of the central policy repository 100. In step 416, the central policy enforcement engine 120 proceeds to take the policy actions indicated in the matched policy rule.
If there is no exact match of the conditions of a rule in the [0048] central policy repository 100, a determination is made in step 410 whether a partial match exists. If the answer is YES, the central policy engine 106 proceeds to program the policy cache 116 in step 418 with the condition fields of the selected policy, the fields having the values of the corresponding extracted fields, and with a default action. In step 420, the central policy enforcement engine 120 proceeds to take the default policy action.
If the search of the [0049] central policy repository 100 does not result in even a partial match of the rules, the central policy engine 106 proceeds to program the policy cache 116, in step 412, with minimal information needed to forward the packet. According to one embodiment of the invention, such minimal information is a source address of the packet, a destination address of the packet, and a default policy action. In another embodiment of the invention, the minimal necessary information is simply the destination address and the default policy action. The default policy action is enforced by the central policy enforcement engine 120 in step 420.
The programming of the [0050] policy cache 116 will be best understood when considering the following example. Assume that the central policy repository 100 includes the rules depicted in FIG. 7.
A first packet received by the [0051] central policy engine 106 includes the following fields extracted by the classification engine 104:
Source IP—192.200.200.200 [0052]
Destination IP—10.5.3.4 [0053]
Protocol—TCP [0054]
Port—80 (HTTP) [0055]
The [0056] central policy engine 106 compares the extracted information with entries in the policy cache 116. Assuming for purposes of this example that this is a first packet processed by the central policy engine 106, no entries are contained in the policy cache 116.
The [0057] central policy engine 106 then proceeds to search the central policy repository 100 for a match. Upon a finding of no match in the central policy repository 100, the central policy engine programs the policy cache with a minimal amount of information needed to process and forward future similar packets. In one example, the central policy engine may program the policy cache with a source IP address, destination IP address, and a default action. The default action in this example is the assignment of a default priority. The entry placed in the policy cache is as follows:
Source IP—192.200.200.200 [0058]
Destination IP—10.5.3.4 [0059]
Action—0 (best effort priority) [0060]
The [0061] central policy engine 106 next receives a packet that includes the following fields:
Source IP—192.200.200.200 [0062]
Destination IP—192.168.1.1 [0063]
Protocol—TCP [0064]
Port—80 (HTTP) [0065]
The [0066] central policy engine 106 compares the extracted information with entries in the policy cache 116. Upon a no match, the extracted information is compared against the rules in the central policy repository 100. Rule 1 matches the packet's source IP address, destination IP address, and protocol. However, there is no match in the port information, resulting in a partial match with rule 1.
In determining an entry for the policy cache, the [0067] central policy engine 106 ensures that the entry is specific enough to prevent packets for which a different applicable rule may exist in the central policy repository 100 to be processed by the policy cache. In this regard, the central policy engine 106 determines the number of condition fields of the rule that resulted in the partial match. Rule 1 that resulted in the partial match includes four condition fields: source IP address, destination IP address, protocol and port. Thus, the entry placed in the fast path includes four condition fields although only the source IP and the destination IP are needed to forward future packets. The value of the four fields is based on the information extracted from the packet. Accordingly, the entry placed in the policy cache is as follows:
Source IP—192.200.200.200 [0068]
Destination IP—192.168.1.1 [0069]
Protocol—TCP [0070]
Port—80 (HTTP) [0071]
Action—0 (best effort priority) [0072]
A next packet received by the [0073] central policy engine 106 includes the following fields:
Source IP—192.200.200.200 [0074]
Destination IP—192.168.1.1 [0075]
Protocol—TCP [0076]
Port—21 (FTP) [0077]
The [0078] central policy engine 106 compares the extracted information with entries in the policy cache 116 and does not find a match. If, however, the policy cache had been programmed with less than four fields in processing the previous packet, a match would have resulted in the policy cache, causing the current packet to the forwarded without consulting the rules in the central policy repository.
The [0079] central policy engine 106 proceeds to search the central policy repository 100 and finds an exact match with rule 1. In determining the entry to be programmed in the policy cache, the central policy engine determines the number of condition fields in the rule that resulted in the exact match. The four condition fields of the matching rule 1 are then programmed into the policy cache. The value of the four fields is based on the information extracted from the packet. The entry placed in the policy cache is as follows:
Source IP—192.200.200.200 [0080]
Destination IP—192.168.1.1 [0081]
Protocol—TCP [0082]
Port—21 (FTP) [0083]
Action—7 (high priority) [0084]
The [0085] central policy engine 106 next receives a packet that includes the following fields:
Source IP—192.200.200.200 [0086]
Destination IP—192.168.2.2 [0087]
Protocol—UDP [0088]
Port—300 [0089]
The [0090] central policy engine 106 compares the extracted information with entries in the policy cache 116 and does not find a match. The central policy engine 106 then proceeds to search the rules in the central policy repository 100 and finds an exact match with Rule 2. The fields in Rule 2 that resulted in the exact match are source IP address and destination IP address. Accordingly, the entry placed in the policy cache is as follows:
Source IP—192.200.200.200 [0091]
Destination IP—192.168.2.2 [0092]
Action—7 (high priority) [0093]
Although this invention has been described in certain specific embodiments, those skilled in the art will have no difficulty devising variations which in no way depart from the scope and spirit of the present invention. It is therefore to be understood that this invention may be practiced otherwise than is specifically described. Thus, the present embodiments of the invention should be considered in all respects as illustrative and not restrictive, the scope of the invention to be indicated by the appended claims and their equivalents rather than the foregoing description. [0094]

Claims

What is claimed is:

1. A switching node in a data communications network, the switching node comprising:

an input receiving an inbound packet;

a repository storing a single set of policies for controlling a plurality of different traffic management protocols;

a policy engine coupled to the input and the repository, the policy engine evaluating the packet based on a policy selected from the single set of policies and configuring one or more traffic management protocol entities based on the selected policy; and

a management engine coupled to the repository and the policy engine, the management engine configuring and managing the single set of policies via a common set of commands.

2. The switching node of claim 1, wherein the single set of policies includes a policy identifying two or more actions for controlling two or more traffic management protocols.

3. The switching node of claim 1, wherein the single set of policies includes a first policy identifying a first action for controlling a first traffic management protocol and a second policy identifying a second action for controlling a second traffic management protocol.

4. The switching node of claim 1, wherein one of the traffic management protocols is quality of service.

5. The switching node of claim 1, wherein one of the traffic management protocols is access control.

6. The switching node of claim 1, wherein one of the traffic management protocols is address translation.

7. The switching node of claim 1 further comprising a policy cache coupled to the repository and the policy engine for storing a plurality of cached policies.

8. The switching node of claim 7, wherein the policy engine is configured to evaluate the packet based on the plurality of cached policies prior to evaluating the packet based on the policies in the repository.

9. The switching node of claim 8, wherein the central policy engine selects a cached policy as applicable to the packet if no other policies are stored in the repository that are also applicable to the packet but are different from the selected cached policy.

10. The switching node of claim 8, wherein if no match of a policy is found in the repository, the policy engine is configured to store in the policy cache a policy having a destination address of the packet and a default action.

11. The switching node of claim 8, wherein if a partial match of a policy is found in the repository, the policy engine is configured to store in the policy cache a policy having condition fields of the policy in the repository where the values of the condition fields are obtained from the packet, and a default action.

12. The switching node of claim 8, wherein if a complete match of a policy is found in the repository, the policy engine is configured to store in the policy cache a policy having condition fields of the policy in the repository where the values of the condition fields are obtained from the packet, and an action indicated by the policy in the repository.

13. A method for policy based traffic management comprising:

storing in a repository a single set of policies for controlling a plurality of different traffic management protocols;

receiving a first packet;

retrieving a first policy from the repository, the first policy identifying a first action for configuring a traffic management protocol entity of a first protocol type;

configuring the traffic management protocol of the first protocol type based on the first action;

receiving a second packet;

retrieving a second policy from the repository, the second policy identifying a second action for configuring a traffic management protocol entity of a second protocol type; and

configuring the traffic management protocol entity of the second protocol type based on the second action.

14. The method of claim 13, wherein one of the traffic management protocols is quality of service.

15. The method of claim 13, wherein one of the traffic management protocols is access control.

16. The method of claim 13, wherein one of the traffic management protocols is address translation.

17. The method of claim 13 further comprising managing the single set of policies via a common set of commands.

18. A method for policy based traffic management comprising:

receiving a packet;

retrieving a policy from the repository, the policy identifying a first and second action for controlling a first and second traffic management protocol entity, respectively, of a first and second protocol type, respectively;

configuring the first traffic management protocol entity based on the first action; and

configuring the second traffic management protocol entity based on the second action.

19. The method of claim 18, wherein one of the traffic management protocols is quality of service.

20. The method of claim 18, wherein one of the traffic management protocols is access control.

21. The method of claim 18, wherein one of the traffic management protocols is address translation.

22. The method of claim 18 further comprising managing the single set of policies via a common set of commands.

23. A method for policy based traffic management comprising:

receiving a packet;

searching a policy cache for a policy applicable to the packet;

searching the repository if the policy cache does not include an applicable policy; and

generating and storing a new policy in the policy cache, wherein if the new policy is selected as applicable to a future packet, no policies are stored in the repository that are also applicable to the future packet but are different from the new policy.

24. The method of claim 23, wherein if no match of a policy is found in the repository, the policy generated and stored in the policy cache includes a destination address of the packet and a default action.

25. The method of claim 23, wherein if a partial match of a policy is found in the repository, the policy generated and stored in the policy cache includes condition fields of the policy in the repository where the values of the condition fields are obtained from the packet, and a default action.

26. The method of claim 23, wherein if a complete match of a policy is found in the repository, the policy generated and stored in the policy cache includes condition fields of the policy in the repository where the values of the condition fields are obtained from the packet, and an action indicated by the policy in the repository.