Systems and methods for facilitating a dynamic policy engine with recursive key selection

Abstract

One embodiment provides a system and method for facilitating a dynamic policy engine with recursive key selection. During operation, the system may receive a user request at a network device for creating a policy table, the user request including multiple sets of policy fields and specifying an amount of hardware resources for the policy table. The system may, in response to determining that the amount of unallocated hardware resources is less than the amount of hardware resources specified in the user request, release a portion of the allocated hardware resources and allocate a specified amount of hardware resources for the policy table. The system may identify an optimized matching policy template that accommodates multiple sets of policy fields based on the user request. Thereafter, the system may configure one or more hardware template registers based on the optimized matching policy template and create a policy table.

Description

Technical Field

[0001] The present disclosure relates generally to the field of networking policies. More specifically, the present disclosure relates to a system and method for facilitating a dynamic policy engine with recursive key selection. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 An exemplary environment and system architecture that facilitates a dynamic policy engine with a recursive key selection algorithm according to one embodiment is illustrated.

[0003] Figure 2A An example of a policy template and a policy table according to one embodiment is illustrated.

[0004] Figure 2B An example of selecting a policy template from different policy templates including different combinations of fields according to one embodiment is illustrated.

[0005] Figure 3 A flow chart illustrating an exemplary process for selecting a minimal policy template according to one embodiment is presented.

[0006] Figure 4 Illustrated are different stages of a recursive key selection algorithm with corresponding assignments of different user-specified policy fields to containers within a policy template, according to one embodiment.

[0007] Figure 5 A flow chart illustrating a process for selecting a policy template based on a dynamic policy engine with recursive key selection according to one embodiment is presented.

[0008] Figure 6 An exemplary computer system equipped with circuitry that facilitates implementation of a dynamic policy engine with recursive key selection is illustrated in accordance with one embodiment.

[0009] In the various drawings, like reference numerals refer to like drawing elements. DETAILED DESCRIPTION

[0010] The following description is intended to enable any person skilled in the art to make and use these examples, and is provided in the context of a specific application and its requirements. Various modifications to the disclosed examples will be apparent to those skilled in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the present disclosure. Therefore, the scope of the present disclosure is not limited to the examples shown but is intended to conform to the widest scope consistent with the principles and features disclosed herein.

[0011] Network devices in a computer network can implement a collection of networking policies that can be associated with multiple applications, such as an access control list (ACL) that allows users to specify rules to deny specific types of traffic. In addition, networking policies can also correspond to forwarding rules, such as policy-based forwarding (PBF), and can be used to identify quality of service (QoS). Networking policies can be implemented as {match criteria, action} operations. Match criteria can include different packet fields and internal flags, such as media access control (MAC) addresses, Internet Protocol (IP) addresses, ingress ports, virtual LAN (VLAN) numbers, and so on.

[0012] Current systems assign a fixed amount of resources (e.g., a fixed amount of memory) to each policy query that may be associated with a use case. Typically one (or some) users may desire additional resources to be allocated for ACL-type policies, while other users may prefer additional resources to be allocated to PBF-type policies. Typically, it may be a challenging or practically difficult task to predict or adapt to different use cases in a way that hardware resources are optimally allocated. This is because existing systems may not be able to predict what type of resource prioritization a user may prefer to apply to different use cases. In other words, existing systems may have problems with determining the most appropriate resource solution for different use cases.

[0013] For example, a network device may support seven policy tables, but the number of use cases can be addressed using only three policy lookups, in which case the existing system cannot redistribute or release resources allocated to the remaining four unused policy lookups. In addition, each policy lookup includes a fixed number of entries, i.e., a fixed number of resources are assigned to each policy lookup, which also limits the flexibility of redistributed resources when they are not used. In order to redistribute resources, some existing systems require a restart of the switch to turn on the switch in a different configuration. In other words, each restart of the switch requires a different configuration or redistribution of resources, which can result in interruption of network services and degradation of system performance.

[0014] In addition, network packets may include variable fields or programmable components, i.e., fields that may have different sizes or be associated with different applications, which may correspond to non-standard packet fields. During the process of creating a policy query, identifying a policy template that matches these variable fields may be challenging because there may be a large set of combinations, e.g., about five million possibilities, to choose from. Therefore, finding an optimized policy template that consumes the least amount of resources from among a large set of possibilities may add significant delays in creating a policy query and may therefore significantly degrade the performance of the system.

[0015] The embodiments described herein provide a technical solution to the above-mentioned technical problems by providing a system and method for facilitating a dynamic policy engine, which can dynamically redistribute resources to policy queries without interrupting network traffic, i.e., without restarting a switch or network device. Specifically, based on the policy fields specified in a user request for creating a new policy query and the specified amount of hardware resources, the dynamic policy engine can identify the best template, such as the smallest template, from among the multiple templates supported in the hardware, which can accommodate the user-specified policy fields and can provide optimized resource utilization. In other words, the dynamic policy engine can select a suitable matching policy template and a corresponding hardware configuration based on the matching criteria specified by the user provided for creating a policy query. In addition, when the unallocated hardware resources in the network device are less than the specified amount of hardware resources, the dynamic policy engine can release a portion of the allocated hardware resources, thereby facilitating the redistribution of resources and the allocation of the specified amount of hardware resources to the created policy table.

[0016] In addition, when a user request includes a variable policy field, the dynamic policy engine can apply a novel recursive matching template (or key) selection algorithm to efficiently select the best template from among a large number of available possibilities. Specifically, the recursive algorithm can assign various policy fields to different templates with some pre-specified constraints based on specific occupancy rules and can identify matching policy templates that can host the fields. In other words, the recursive algorithm can identify matching policy templates by complying with occupancy rules and hardware constraints within a manageable runtime.

[0017] The term "policy table" refers to a data table in a memory (eg, a ternary content addressable memory (TCAM)) that includes multiple policy entries, and each policy query is associated with a different template. The terms "policy query" and "policy table" are used interchangeably in this disclosure.

[0018] The term "policy template" refers to a hardware-supported template that includes a specific layout or combination of grouped fields.

[0019] System architecture and dynamic strategy engine

[0020] Figure 1 An exemplary environment and system architecture for facilitating a dynamic policy engine with a recursive key selection algorithm according to one embodiment is illustrated. Figure 1In the example shown in , environment 100 allows devices (e.g., personal computers 108-112, servers 114-118, and data storage devices) coupled via network 104 to exchange data. The data path between these devices can typically include multiple intermediary datapath devices, such as network switches, gateways, and routers, for routing data between devices along selected data paths. For example, network device 102 is an intermediary datapath device that can implement networking policies. These networking policies can include a set of forwarding rules that can be applied to packets when some matching criteria are met.

[0021] The network device 102 may include an application specific integrated circuit (ASIC) or circuit for implementing a dynamic policy engine 120. The ASIC may support multiple policy queries, where each policy query is associated with some matching criteria and applications. The dynamic policy engine 120 may include: a resource allocation module 122 for dynamically allocating resources to different policy queries; an optimization template selection module 124 for selecting the best matching policy template from among multiple policy templates supported in the hardware; a recursive key selection module 126 for selecting a matching policy template when a user request includes a programmable field; a communication module 128 for receiving user requests and network packets; and hardware resources 130. With reference to the following Figure 3-6 To describe the different operations associated with the dynamic policy engine 120.

[0022] The hardware resources 130 may include a memory for storing a policy table 132 (e.g., in a TCAM table), for storing a policy template 134, i.e., the policy table may be implemented as a TCAM table. The hardware resources 130 may also include a counter associated with each policy entry of the policy table. For example, for a particular policy entry, the dynamic policy engine 120 may apply a counter to count the number of packets that match the policy entry in the policy table.

[0023] The dynamic policy engine 120 can dynamically assign resources to different policy queries without interrupting the network traffic flowing through the network device 102, that is, the dynamic policy engine 120 can dynamically assign policy tables in the TCAM. For example, the hardware resources 130 can support a TCAM resource pool and the dynamic policy engine 120 can enable two TCAMs to be combined into one TCAM.

[0024] In another example, when the circuit implementing the dynamic policy engine 120 supports seven policy queries, the dynamic policy engine 120 may first assign "X" amount of resources to the first three policy queries associated with the ACL type use case. Later, during runtime when the user decides to use a PBF type application, the dynamic policy engine 120 may dynamically reassign or redistribute TCAM and counter resources (i.e., hardware resources 130) to the remaining four of the seven policy queries.

[0025] In one embodiment, the dynamic policy engine 120 can effectively reconfigure the hardware and assign the match key (or template) used in each policy query. The circuitry implementing the dynamic policy engine 120 can support a set of predefined match keys or match templates with different sizes. The dynamic policy engine 120 can apply these match templates to create different policy entries in each policy query. Figure 2A and 2B To describe examples of matching templates and policy queries.

[0026] Figure 2A An example of a policy template and a policy table according to one embodiment is illustrated. In this example, a set of policy tables 212-216 is shown. Each policy table is associated with a policy template, i.e., policy table 212 is associated with policy template 202, policy table 214 is associated with policy template 204, and so on. A policy template represents a predefined combination of fields supported by hardware. Each policy table may include a set of policy entries (i.e., entries 1-N). The circuitry implementing the dynamic policy engine may support a predefined number of policy templates.

[0027] Whenever the dynamic policy engine receives a user request for creating a policy table, the dynamic policy engine can create a policy table based on the matching fields specified in the user request. In other words, based on the matching fields specified in the user request, the dynamic policy engine can identify the best or smallest policy template from a predefined set of policy templates that accommodate the matching fields. Therefore, the dynamic policy engine can create a new policy table and each policy table can have a different number of policy entries. In other words, the dynamic policy engine can assign different amounts of resources to different policy tables. For example, the dynamic policy engine can assign 1K entries for one policy table and assign 2K entries for another policy table.

[0028] Figure 2B An example of selecting a policy template from different policy templates including different combinations of fields according to one embodiment is illustrated. Figure 2BA simple example is provided to illustrate how the best policy template can be selected from a set of hardware-supported templates 238. For example, when a user desires to create a policy table, the user can specify in a user request one or more policy fields, the amount of resources to be allocated to the policy table (e.g., 10K policy entries), and a size component indicating the size of the lookup key. In this example, for simplicity, the user can specify one field 230, i.e., field 1, in the user request. The dynamic policy engine can match the user-specified field 230 with the hardware-supported template 238. A policy template can represent a specific layout or combination of fields supported in the hardware.

[0029] The dynamic policy engine can select a policy template that accommodates the user-specified field 230 and has a minimum size. In this example, although all three templates (i.e., 232-236) accommodate field 230, the dynamic policy engine selects template 234 with the smallest size. This is because the smallest template (i.e., template 234) consumes fewer resources than the other templates (i.e., templates 232 and 236). In addition, the policy table created associated with the smallest template can accommodate more policy entries when compared to a policy table with a larger template size. In a working system, the hardware can support a large number of policy templates, and searching for the best policy template that matches the user specifications can be a complex operation that is efficiently performed by the dynamic policy engine. Refer to the following Figure 3-6 To describe the operation of the dynamic policy engine.

[0030] Figure 3 A flow chart illustrating an exemplary process for selecting a minimum policy template according to one embodiment is presented. Figure 3 300, during operation, the system (i.e., the dynamic policy engine) receives a user request for creating a policy table and the user request may include a set of policy fields that must be matched with policy templates supported in hardware to find the best matching policy template (operation 302). The user request may specify a size component indicating the size of the query key (i.e., the size of the policy template). When the size of the policy template is large, the policy template can accommodate a large number of group fields but may result in consuming more hardware TCAM resources.

[0031] In response to receiving the user request, the system may perform grouping of the received policy fields into three categories, which may include: a common component category, a context component category, and a programmable component category (operation 304). The common component category may correspond to a set of common fields based on traffic type. For example, some of the common fields may include a MAC source address (SA), a MAC destination address (DA), an IP SA, an IP DA, and the like. The context component category may include a set of context fields corresponding to an interface identifier, which may be part of a policy key or template. For example, some of the interface identifiers that may be included in the context component category are a source VLAN number, a destination physical port, and the like.

[0032] Programmable component types correspond to variable components, i.e., variable fields that can have different sizes or can be associated with different applications. Some of the associated applications may be custom applications with unconventional or non-standard grouping fields. Unlike common component types and contextual component types, programmable component types can be complex and challenging. This is because programmable component types can provide flexible structures that result in a large number of combinations, for example, about five million or more possibilities, and the system must find a suitable matching template configuration that accommodates the user's request within a manageable time. Figure 4 and Figure 5 To describe the process of finding the best template when a user request includes a programmable component.

[0033] In response to classifying the set of policy fields into three categories, the system can select one or more policy templates based on common fields (operation 306), context fields (operation 308), and based on programmable or variable fields (operation 312). The system can then select a minimum policy template from among the policy templates identified in operations 306-310 (operation 312), and then return to operation 312.

[0034] In one embodiment, the user request may include the amount of hardware resources to be allocated to the policy table. For example, the user may desire to allocate 10K entries for the policy table. Based on the amount of resources specified in the user request, the system may determine whether a sufficient amount of unallocated hardware resources are available to accommodate the resource requirements specified by the user. When a sufficient amount of unallocated hardware resources are available, the system may assign the user-specified amount of resources to accommodate the policy table.

[0035] However, when the system determines that the amount of unallocated hardware resources is less than the amount of resources specified by the user, the system can redistribute or release a portion of the allocated hardware resources to a new policy table. For example, the system may support five policy tables and the system may be using only three policy tables corresponding to three different applications. In such a case, the system can reassign or release the resources of the unused policy table so that they can be used to create a new policy table and / or can be added to the available or unallocated resource pool.

[0036] In another embodiment, the system may receive a request for adding a policy entry to an already existing policy table. The user may also specify the type of policy query in the user request, such as an ACL type policy query, a PBF type policy query, and the like. When the system determines that the amount of unallocated hardware resources is less than the amount of resources specified by the user for the policy entry, the system may redistribute or release a portion of the allocated hardware resources (e.g., these allocated hardware resources may correspond to an unused policy table) to the policy table to which the user desires to add a policy entry. In other words, the system may allow the user to add a policy entry or delete a policy entry in an already existing policy table. The system may then dynamically assign resources to the policy table and configure the ASIC without hindering network traffic and without interrupting network services.

[0037] Dynamic policy engine with recursive key selection algorithm

[0038] If already referenced Figure 3 As explained, the programmable components provide a flexible structure that can generate a large number of field combinations (e.g., about millions of possibilities). From a large number of combinations, the system must find a suitable matching policy template configuration that accommodates the policy fields specified in the user request in a short time without reducing the flexibility provided by the variable fields. One embodiment provides an efficient combination-finder algorithm or recursive key selection algorithm for programmable fields. The recursive key selection algorithm can provide a manageable runtime, meaning that the algorithm can reduce the time used to create a new policy query or policy table by several orders of magnitude. In addition, the recursive key selection algorithm can be well extended for future ASIC generations.

[0039] A recursive key selection algorithm (RKSA) can sort individual elements or programmable fields that obey a specific occupancy rule into different templates with one or more constraints. RKSA can then find a suitable template that can host the programmable field in a manageable runtime, obeying the occupancy rule and hardware constraints.

[0040] Each field in the set of programmable fields can be associated with one or more occupancy rules. The occupancy rules indicate which (which) positions or places in the grouping can accommodate different programmable fields specified in the user request. There can be a finite number of these places or positions and can be defined as containers because they can host one or more fields depending on one or more constraints. Let S(field1, field2, ...) represent a function that can return a set of containers, where the (multiple) fields provided in the function can fit into the container at the same time. Table 1 below shows an example of a first mapping between containers and fields.

[0041] function Container table <![CDATA[S(field1)]]> <![CDATA[{container A ,container B ,container C ,container D }]]> <![CDATA[S(field2)]]> <![CDATA[{container A ,container B ,container D }]]> <![CDATA[S(field3)]]> <![CDATA[{container A ,container B ,container D }]]> <![CDATA[S(field4)]]> <![CDATA[{container E ,container F }]]> <![CDATA[S(field2,field3)]]> <![CDATA[{container D }]]>

[0042] Table 1: First mapping indicating mapping between containers and fields

[0043] In hardware, these containers can be organized into predefined sets called templates. Each template can provide a specific set of containers. Table 2 shows an example of a second mapping between containers and hardware templates.

[0044] template Container List <![CDATA[template1]]> <![CDATA[{container A ,container B ,container D }]]> <![CDATA[template2]]> <![CDATA[{container B ,container F ,container G }]]> <![CDATA[template3]]> <![CDATA[{container A ,container B ,container C ,container E }]]> <![CDATA[template4]]> <![CDATA[{container D ,container H }]]>

[0045] Table 2: Second mapping indicating mapping between containers and templates

[0046] RKSA can find a template that can accommodate the variable or programmable fields specified in the user request, that is, RKSA can select a possible container for each field. In other words, based on the examples provided in Tables 1 and 2 that only include four fields and four templates, RKSA can determine the following assignment: field1 → container C ;field2→container A ;field3→container B ;field4→container E Based on these assignments, RKSA can select template3 to host the fields specified in the user request. In a working system, the number of fields, containers, and templates can be large, i.e., they can correspond to millions of possible combinations and applying limited processing resources to effectively select the best template can be a complex and challenging task. RKSA is an efficient combinatorial search algorithm that can select the best template from a large number of field combinations (i.e., on the order of millions).

[0047] Specifically, RKSA can include three stages: a finder stage, a replacer stage, and a shuffler stage. In one embodiment, RKSA can implement these three stages in three logic units (e.g., a finder logic unit, a replacer logic unit, and a shuffler logic unit). Depending on the difficulty level of finding an available container for each user-specified programmable field, RKSA calls these three stages continuously. In other words, RKSA can accommodate programmable fields before all three stages have been implemented or called. In addition, in some cases, RKSA may not accommodate programmable fields even after the operations in the three stages have been completed, thereby indicating that the current template under consideration may not be able to host all user-specified programmable fields and the dynamic policy engine may have to consider another template to apply RKSA. The operations performed in the three stages are explained below with reference to examples.

[0048] Assume that the user has specified four programmable fields in the user request: field1, field2, field3, and field4. Table 3 provides a list of the set of containers for each field (the first mapping between containers and user-specified fields), i.e., the function (In hardware, this list of containers is provided based on the design specification).

[0049] function Container List <![CDATA[S(field1)]]> <![CDATA[{container A ,container B ,container σ }]]> <![CDATA[S(field2)]]> <![CDATA[{container A ,container D }]]> <![CDATA[S(field3)]]> <![CDATA[{container A ,container D }]]> <![CDATA[S(field4)]]> <![CDATA[{container B ,container c }]]> <![CDATA[S(field1,field3)]]> <![CDATA[{container D }]]>

[0050] Table 3: Container list for list of fields (first mapping)

[0051] Table 4 provides a list of available templates, i.e., a second mapping between containers and templates supported by the hardware. During operation of the system, the list of available templates must be provided before RKSA starts (this list of available templates is also provided based on the hardware design specification). For simplicity, the example includes only two templates, while actual hardware may include a large number of templates with different combinations of containers (e.g., in the order of millions of combinations).

[0052] template Container List <![CDATA[template0]]> <![CDATA[{container C ,container E ,container F }]]> <![CDATA[template1]]> <![CDATA[{container A ,container B ,container D }]]>

[0053] Table 4: Templates and associated container list (second mapping)

[0054] Figure 4 The different stages of a recursive key selection algorithm with corresponding assignments of different user-specified policy fields to containers within a policy template are illustrated according to one embodiment. Figure 4In the example shown in FIG. 1 , in response to receiving a user-specified programmable field, RKSA may begin with a finder phase, where RKSA may consider a first template, such as template0, and find an available container for each field ( Figure 4 The first template (i.e., template0) includes three places or locations. RKSA successively searches for an available container for field1 in the first, second, and third places. It can be observed from Tables 3 and 4 that there is no container in template0 that can accommodate field1, i.e. In such a case, RKSA can discard template0 in the finder phase and continue with the next template, template1 in the above example. Figure 4 , the RKSA may perform operations associated with three phases in a sequence indicated by arrow 414. The order or sequence in which these three phases are implemented may be based on the policy template under consideration and the user-specified fields.

[0055] For template1434, the RKSA in the finder stage 402 may search for an available container starting from the first position or space in template1434 to the last position in template1434. In other words, when the RKSA finds a container for field1 in the first position (i.e., container A Occupies the first position in template1434), RKSA can assign field1 to container A (Assignment 416). RKSA may continue in finder stage 402 to find another available container for the next field field2. The field may be contained in container A or container D Internal (based on the examples in Table 3 and Table 4). RKSA can identify the container A has been occupied in the first implementation of the finder phase 402, and therefore field2 can be assigned to the next available container, container D . For field1 to container A and field2 to container D The assignment of is shown in 418 .

[0056] RKSA can continue to search for an available container for the next field (i.e., field3). Based on Table 3 and Table 4, field3 can be accommodated in containerA or container D Internally, however, these two containers are already occupied by fields field1 and field2 (see assignment in 418). In this case, RKSA can proceed to the next stage, the replacer stage 404, and can facilitate the reassignment or movement of one or more previously assigned fields to another available container and release the previously occupied container for field3.

[0057] Specifically, in the replacer phase 404, RKSA may identify that the incoming field (e.g., field3) can be accommodated within at least one container in a given template (e.g., template1), but no container is currently available for field3. In such a case, the replacer phase 404 may determine that the already assigned field1 can also be accommodated within a container B (based on Tables 3 and 4). RKSA may then call the finder stage 406 again to perform the field assignment. However, each time RKSA calls or implements the finder stage, new constraints are included, which may correspond to locks on one or more containers used to assign the current policy fields.

[0058] for Figure 4 In the example shown in FIG. 4 , RKSA may apply the replacer stage 404 to replace the first position in template1 (i.e., container A , which has been previously assigned to field1 (see 418 in finder phase assignment 402). Replacer phase 404 may find another available container for field1 so that container A Can be used for the next incoming field field3. To perform the lookup operation, the replacer stage 404 can trigger a rerun of the RKSA from the first stage (i.e., the finder stage 406), but with locking constraints or without using a container A Therefore, based on the function S(field1) (see Table 3), field1 can be contained in the container B Internally (see 420 in replacer stage 404). Now container A Once again available, RKSA may apply finder stage 406 to generate assignments 422 and 424 .

[0059] When the function S() returns a list of containers (where two or more fields are associated with one container), this can indicate that the finder stage can accommodate two or more fields in one container at the same time. Such containers are called shareable containers. In this example, container Dfield1 and field3 are sharable. Therefore, when RKSA calls finder stage 406 after replacer stage 404, RKSA may apply replacer stage 404 to lock at least one container (see assignment 420 in replacer stage 404), such as container A or container D , which can contain field3. In other words, in the replacer phase 404, RKSA can lock and release the locked container, that is, the locked container container A , used for the current incoming field. Since the replacer stage 404 has locked the container A , so the previously assigned field1 is sent again to the finder stage 406 for assignment to any available container other than the locked container, e.g., container R . Locked container A It can then be used for field3. In addition, RKSA can perform such a locking operation to prevent the finder stage from assigning any other incoming fields (ie, other than field3) to the locked container(s).

[0060] RKSA can then identify that for the new field (i.e., field4), there is no available container and no container is available in the finder or replacer phase. This is because all available containers (e.g., container A 、container B and container D ) is already occupied by three previous fields (see assignment 424). In such a case, the RKSA can proceed to the shuffler stage 408, which can represent the last stage in the RKSA. The shuffler stage 408 can provide a solution by identifying at least two already assigned fields whose containers can be interchanged. In other words, the shuffler stage 408 can find a combination of fields that can be shared by the containers. Specifically, the shuffler stage 408 can move the already assigned fields from the previous container to the shareable container, thereby freeing the previous container to accommodate the new field or the new field can be accommodated in the shareable container.

[0061] Therefore, whenever the shuffler stage 408 finds two fields that can be interchanged, the two fields are moved or shuffled and RKSA is restarted from the finder stage for the new field field4. Since all containers are still occupied, RKSA identifies that the finder stage cannot find an available container for the new field field4. RKSA can then proceed to the replacer stage 410, where it identifies that field1 and field3 can share containers. D Therefore, the replacer stage 410 can lock the container B (See assignment 428) This makes it available for the new field field4 and can facilitate field1 and field3 to be contained in a shareable container D Now container B It is available again and RKSA can assign field4 to the container in the finder stage 412 B (See assignments 430 and 432.) Therefore, RKSA identifies template1 as the best template that can accommodate the fields specified by the user. Figure 4 In the example shown in , RKSA is recursive, meaning that in each iteration, the same process (eg, finder phase, replacer phase, and / or shuffler phase) is executed multiple times applying new constraints.

[0062] RKSA is independent of the hardware implementation, which means that RKSA may only need to know the association of fields to containers and to templates supported in the hardware, i.e., the first mapping and the second mapping. Therefore, future ASICs implementing a dynamic policy engine with RKSA can dynamically add or remove new fields or templates without interrupting network services.

[0063] Figure 5 A flow chart illustrating a process for selecting a policy template based on a dynamic policy engine with recursive key selection according to one embodiment is presented. Figure 5 500, during operation, a system implementing a dynamic policy engine with recursive key selection may receive a user request for a policy field including a set of programmable or variable fields (operation 502). The system may identify a set of containers for each user-specified policy field that represents a first mapping (operation 504; see also the example in Table 3 above). The system may identify different templates, each of which includes a different set of containers that represent a second mapping (operation 506; see Table 4). The system may then obtain the policy field (operation 508) and select a policy template from a set of templates supported in hardware (operation 510).

[0064] In response to selecting a particular template, the system can apply RKSA ( Figure 4 ), i.e., a finder logic unit (operation 512), a replacer logic unit (operation 514), and a shuffler logic unit (operation 516) to identify a policy template that accommodates all policy fields specified in the user request and then the operation returns.

[0065] Specifically, the system can apply a finder logic unit (operation 512) to perform the following operations: find and assign one or more policy fields to one or more available containers in the policy template under consideration; apply a replacer logic unit in response to determining that a container for the next policy field in the user request has been assigned to another field and the current policy template includes available containers; apply a shuffler logic unit in response to determining that a container for the next policy field in the user request has been assigned to another field and the policy template does not include available containers; select the current policy template as a matching policy template in response to determining that policy fields in a programmable component group are assigned to a set of containers in the current policy template; and apply the finder logic unit to the next policy template in response to determining that policy fields in a programmable component group are not assigned to a set of containers in the current policy template.

[0066] The system can apply a replacer logic unit (operation 514) to perform the following operations: in response to determining that a first container has been assigned to a first field in a policy template and there is a second container available for the first field, lock the first container for the next policy field; and apply a finder logic unit to move the first field to the second container and use it to assign the next policy field to the first container; and in response to determining that the policy template does not include an available container, but the first policy field is associated with a shareable container assigned to the second policy field, lock the first container for the next policy field; apply a finder logic unit to move the first policy field to the shareable container and use it to assign the next policy field to the first container.

[0067] The system can apply the shuffler logic (operation 516) to perform the following: shuffle the fields that have been assigned to the container; and apply the replacer logic when the policy template includes a shareable container.

[0068] Exemplary Computer System

[0069] Figure 6An exemplary computer system equipped with an ASIC that facilitates implementation of a dynamic policy engine with recursive key selection according to one embodiment is illustrated. In this example, computer system 600 may include processor 602, memory 604, storage device 606. Computer system 600 may be coupled to peripheral input / output (I / O) user devices 634, such as display device 612, keyboard 614, and pointing device 616. Storage device 606 may store instructions for operating system 618. One or more applications 620 may operate operating system 618. Computer system 600 may be coupled to network 636 via one or more network interfaces.

[0070] The computer system 600 may be equipped with an ASIC or circuit 608, which may include hardware resources 610. The hardware resources 610 may include counters, TCAM resources for storing information related to networking policies (e.g., policy tables, policy templates, etc.). The circuit 608 may include a dynamic policy engine logic unit 622 to perform the methods and / or processes described in the present disclosure. The dynamic policy engine logic unit 622 may include a communication logic unit 624, a resource allocation logic unit 626, an optimized policy template selection logic unit 628, a recursive key selection logic unit 630, and a configuration and creation policy table logic unit 632.

[0071] The communication logic unit 622 can send and / or receive data packets from other nodes and / or network devices in the network 636. The communication logic unit 624 can also receive user requests. For example, the user request can correspond to a request for creating a policy table to add a policy entry to an already existing policy table, delete a policy table, delete an entry in a policy table, and the like. The user request can include a user-specified policy field, a user-specified size component indicating the size of the query key. A large query key size indicates a large template size that can accommodate more packet fields and can also consume hardware TCAM resources. The user request can also specify the amount of hardware resources used for the policy table, for example, the size of the policy table or the number of entries to be accommodated in the policy table.

[0072] Resource allocation logic 626 may allocate the amount of hardware resources specified in the user request. For example, when the user request corresponds to creating a policy table, resource allocation logic 626 may allocate the specified amount of hardware resources for the policy table. However, if the amount of unallocated hardware resources is less than the specified amount of hardware resources, resource allocation logic 626 may redistribute and / or release a portion of the allocated hardware resources to accommodate the policy table using the specified amount of hardware resources.

[0073] In another example, the user request may include a request to add an entry to a policy table and may specify a desired size of the policy table to accommodate the policy entry. In such a case, the resource allocation logic unit 626 may determine whether a sufficient amount of resources are available to accommodate the specified size for the policy table. When a sufficient amount of resources is not available, the resource allocation logic unit 626 may redistribute or release a portion of the hardware resources associated with other policy tables (e.g., unused policy tables) to accommodate the new policy entry in the user-specified policy table.

[0074] Dynamic policy engine logic unit 622 can apply optimized policy template selection logic unit 628 to search for one or more policy templates corresponding to each of the user-specified field categories (e.g., common component fields, context component fields, and programmable component fields). Optimized template selection unit 628 can then select a minimal template that accommodates the user-specified policy fields. The minimal template is selected because it consumes a smaller amount of hardware resources for the policy table.

[0075] When the user request for creating a policy table includes a programmable policy field, the dynamic policy engine logic unit 622 may apply the recursive key selection logic unit 630 to implement RKSA to identify one or more templates that can accommodate the user-specified programmable field. The dynamic policy engine logic unit 622 may then apply the optimized policy template selection unit 628 to select a minimal template that accommodates the user-specified policy field. In response to selecting a minimal or optimized policy template, the dynamic policy engine unit 622 may: apply the configuration logic unit 632 to configure one or more hardware registers based on the optimized policy template; and create a policy table.

[0076] One embodiment described in the present disclosure may provide a system and method for facilitating a dynamic policy engine with recursive key selection. During operation, the system may receive a user request at a network device for creating a policy table, the user request including multiple sets of policy fields and specifying an amount of hardware resources for the policy table. The system may release a portion of the allocated hardware resources in response to determining that the amount of unallocated hardware resources is less than the amount of hardware resources specified in the user request. The system may then allocate a specified amount of hardware resources for the policy table. The system may identify an optimized matching policy template that accommodates multiple sets of policy fields based on the user request and multiple policy templates supported in the hardware. The corresponding policy templates are associated with different sets of policy fields. The system may then: configure one or more hardware template registers based on the optimized matching policy template; and create a policy table based on the configured one or more hardware template registers.

[0077] In a variation on this embodiment, the system may identify one or more matching policy templates for the corresponding policy field group.

[0078] In a variation of this embodiment, the optimized matching policy template corresponds to a matching policy template with a minimum size in the set of matching policy templates.

[0079] In a variation on this embodiment, when multiple groups of policy fields include programmable component groups, the system may apply a recursive algorithm to identify one or more matching policy templates, which includes: identifying a first mapping between one or more containers and corresponding fields in the programmable component group; identifying a second mapping between a set of containers and corresponding policy templates in a set of templates supported in hardware; based on the first mapping and the second mapping, determining the matching policy template by applying the following items: a finder logic unit; a replacer logic unit; and a shuffler logic unit.

[0080] In a variation on this embodiment, the system may apply a finder logic unit, which includes: in response to determining that the current policy template includes one or more available containers for one or more policy fields in the programmable component group, assigning one or more policy fields to the corresponding available one or more containers; in response to determining that the container for the next policy field has been assigned to another field and the current policy template includes an available container, applying a replacer logic unit; in response to determining that the container for the next policy field in the user request has been assigned to another field and the policy template does not include an available container, applying a shuffler logic unit; and in response to determining that the policy fields in the programmable component group are assigned to a set of containers in the current policy template, selecting the current policy template as a matching policy template; and in response to determining that the policy fields in the programmable component group are not assigned to the set of containers in the current policy template, applying the finder logic unit to the next policy template.

[0081] In another variation, the system may apply a replacer logic unit, comprising: in response to determining that a first container has been assigned to a first field in a policy template and there is a second container available for the first field, locking the first container for a next policy field; and applying a finder logic unit to reassign the first field to the second container and for assigning the next policy field to the first container; and in response to determining that the policy template does not include an available container, but the first policy field is associated with a shareable container assigned to the second policy field, locking the first container for the next policy field; and applying a finder logic unit to reassign the first policy field to the shareable container and for assigning the next policy field to the first container.

[0082] In another variation, the system may apply shuffler logic including: shuffling fields that have been assigned to containers; and applying replacer logic when the policy template includes a shareable container.

[0083] In another variation, the multiple sets of policy fields include one or more of: a common component group comprising a collection of common fields based on traffic type; a context component group comprising one or more interface identifiers; and a programmable component group comprising one or more variable fields having different sizes.

[0084] In another variation, the hardware resources include: a ternary content addressable memory; and one or more counters.

[0085] In another variation, the system may receive a user request at a network device to add one or more policy entries to an existing policy table. The system may add the one or more policy entries to the existing policy table in response to determining that the existing policy table includes sufficient memory. The system may then reassign resources to the existing policy table for accommodating the one or more policy entries in response to determining that the existing policy table does not include sufficient memory.

[0086] An embodiment described in the present disclosure may provide a network device, which includes a processor, a memory, and a circuit. The circuit may include: a set of hardware resources for storing a set of policy tables, a set of policy templates, and one or more counters; a communication logic unit for receiving a user request for creating a policy table, the user request including multiple sets of policy fields and specifying the amount of hardware resources for the policy table; a resource allocation logic unit for: in response to determining that the amount of unallocated hardware resources is less than the amount of hardware resources specified in the user request, releasing a portion of the allocated hardware resources; and allocating the specified amount of hardware resources for the policy table.

[0087] The circuit may also include: an optimized policy template selection unit, used to identify an optimized matching policy template that accommodates multiple groups of policy fields based on a user request and multiple policy templates supported in the hardware, wherein the corresponding policy templates are associated with different sets of policy fields; a configuration logic unit, used to configure one or more hardware template registers based on the optimized matching policy template; and a policy table creation logic unit, used to create a policy table based on the configured one or more hardware template registers.

[0088] The methods and processes described in the detailed description section may be embodied as code and / or data, which may be stored in a computer-readable storage medium as described above. When a computer system reads and runs the code and / or data stored on the computer-readable storage medium, the computer system executes the methods and processes embodied as data structures and codes and stored in the computer-readable storage medium.

[0089] In addition, the methods and processes described above may be included in a hardware module or device. The hardware module or device may include, but is not limited to, an ASIC chip, a field programmable gate array (FPGA), a dedicated or shared processor that runs a specific software module or code fragment at a specific time, and other programmable logic devices now known or developed later. When the hardware module or device is activated, it executes the methods and processes included therein.

[0090] The foregoing description of the embodiments has been presented for the purpose of illustration and description only. It is not intended to be exhaustive or to limit the scope of the present disclosure to the disclosed forms. Therefore, many modifications and variations will be apparent to those skilled in the art.

Claims

1. A computer-implemented method comprising: receiving, at a network device, a user request for creating a policy table, the user request including a plurality of sets of policy fields and specifying an amount of hardware resources for the policy table; In response to determining that the amount of unallocated hardware resources is less than the amount of hardware resources specified in the user request, releasing a portion of the allocated hardware resources; allocating the specified amount of the hardware resources for use with the policy table; Based on the user request and a plurality of policy templates supported in the hardware, identifying an optimized matching policy template that accommodates the plurality of groups of policy fields, wherein respective policy templates are associated with different sets of policy fields, when the plurality of groups of policy fields include a programmable component group: applying a recursive key selection algorithm to identify a matching policy template, comprising: identifying a first mapping between one or more containers and corresponding fields in the set of programmable components; identifying a second mapping between the set of containers and corresponding policy templates in the set of templates supported in the hardware; Based on the first mapping and the second mapping, the matching policy template is determined by applying: Finder logic unit; a replacer logic unit; and shuffler logic unit; configuring one or more hardware template registers based on the optimized matching policy template; and The policy table is created based on the configured one or more hardware template registers.

2. The computer-implemented method of claim 1 , further comprising: One or more matching policy templates are identified for the corresponding policy field group. 3 . The computer-implemented method of claim 1 , wherein the optimized matching policy template corresponds to a matching policy template having a smallest size among a set of matching policy templates.

4. The computer-implemented method of claim 1 , wherein applying the finder logic unit comprises: In response to determining that the current policy template includes one or more available containers for one or more policy fields in the group of programmable components, assigning the one or more policy fields to the corresponding available one or more containers; in response to determining that a container for a next policy field has been assigned to another field and the current policy template includes an available container, applying the replacer logic unit; In response to determining that the container for the next policy field in the user request has been assigned to another field and the policy template does not include an available container, applying the shuffler logic unit; In response to determining that the policy fields in the group of programmable components are assigned to the set of containers in the current policy template, selecting the current policy template as the matching policy template; as well as In response to determining that the policy field in the group of programmable components is not assigned to the set of containers in the current policy template, applying the finder logic unit to a next policy template.

5. The computer-implemented method of claim 4, wherein applying the replacer logic comprises: responsive to determining that a first container has been assigned to a first field in the policy template and there is a second container available for the first field, locking the first container for a next policy field, and applying the finder logic to reassign the first field to the second container and for assigning the next policy field to the first container; as well as In response to determining that the policy template does not include an available container, but the first policy field is associated with a shareable container assigned to a second policy field, locking the first container for the next policy field and applying the finder logic unit to reassign the first policy field to the shareable container and to assign the next policy field to the first container.

6. The computer-implemented method of claim 4, wherein applying the shuffler logic unit comprises: shuffling the fields that have been assigned to the container; as well as The replacer logic is applied when the policy template includes a shareable container.

7. The computer-implemented method of claim 1 , wherein the plurality of sets of policy fields include one or more of the following: The common component group includes a collection of common fields based on traffic type; a context component group, including one or more interface identifiers; and A programmable component group includes one or more variable fields of different sizes.

8. The computer-implemented method of claim 1 , wherein the hardware resources include: ternary content addressable memory; as well as One or more counters.

9. The computer-implemented method of claim 1 , further comprising: receiving, at the network device, a user request to add one or more policy entries to an existing policy table; in response to determining that the existing policy table includes sufficient memory, adding the one or more policy entries to the existing policy table; as well as In response to determining that the existing policy table does not include sufficient memory, resources are reassigned to the existing policy table for accommodating the one or more policy entries.

10. A network device comprising: processor; Memory; A circuit, the circuit comprising: A collection of hardware resources for storing a collection of policy tables, a collection of policy templates, and one or more counters; a communication logic unit, configured to receive a user request for creating a policy table, the user request including a plurality of sets of policy fields and specifying an amount of hardware resources for the policy table; Resource allocation logic unit, used to: In response to determining that the amount of unallocated hardware resources is less than the amount of hardware resources specified in the user request, releasing a portion of the allocated hardware resources; and allocating the specified amount of the hardware resources for use with the policy table; an optimized policy template selection unit, configured to identify an optimized matching policy template accommodating the multiple groups of policy fields based on the user request and multiple policy templates supported in the hardware, wherein respective policy templates are associated with different sets of policy fields; A configuration logic unit, configured to configure one or more hardware template registers based on the optimized matching policy template; and a policy table creation logic unit, configured to create the policy table based on the configured one or more hardware template registers; Recursive key selection logic unit for: When the plurality of sets of policy fields include a programmable component group, applying a recursive key selection algorithm to identify a matching policy template; Wherein, when applying the recursive key selection algorithm, the recursive key selection logic unit is further used for: identifying a first mapping between one or more containers and corresponding fields in the set of programmable components; identifying a second mapping between a set of containers and corresponding policy templates in a set of templates supported in the hardware; Based on the first mapping and the second mapping, the matching policy template is determined by applying: Finder logic unit; a replacer logic unit; and Shuffler logic unit.

11. The network device according to claim 10, wherein the optimization policy template selection logic unit is further used to identify one or more matching policy templates for the corresponding policy field group. 12 . The network device according to claim 10 , wherein the optimized matching policy template corresponds to a matching policy template with a minimum size in a set of matching policy templates.

13. The network device of claim 10, wherein the finder logic unit is configured to: In response to determining that the current policy template includes one or more available containers for one or more policy fields in the group of programmable components, assigning the one or more policy fields to the corresponding available one or more containers; in response to determining that a container for a next policy field has been assigned to another field and the current policy template includes an available container, applying the replacer logic unit; In response to determining that the container for the next policy field in the user request has been assigned to another field and the policy template does not include an available container, applying the shuffler logic unit; In response to determining that the policy fields in the group of programmable components are assigned to the set of containers in the current policy template, selecting the current policy template as the matching policy template; as well as In response to determining that the policy field in the group of programmable components is not assigned to the set of containers in the current policy template, applying the finder logic unit to a next policy template.

14. The network device of claim 10, wherein the replacer logic unit is configured to: In response to determining that a first container has been assigned to a first field in the policy template and there is a second container available for the first field, locking the first container for a next policy field and applying the finder logic to reassign the first field to the second container and for assigning the next policy field to the first container; and In response to determining that the policy template does not include an available container, but the first policy field is associated with a shareable container assigned to a second policy field, locking the first container for the next policy field and applying the finder logic unit to reassign the first policy field to the shareable container and to assign the next policy field to the first container.

15. The network device of claim 10, wherein the shuffler logic unit is configured to: shuffling the fields that have been assigned to the container; and The replacer logic is applied when the policy template includes a shareable container.

16. The network device of claim 10, wherein the plurality of sets of policy fields include one or more of the following: The common component group includes a collection of common fields based on traffic type; a context component group, including one or more interface identifiers; and A programmable component group includes one or more variable fields of different sizes.

17. The network device according to claim 10, wherein the hardware resources include: ternary content addressable memory; as well as One or more counters.

18. The network device of claim 10, wherein the communication logic unit is further configured to receive a user request to add one or more policy entries to an existing policy table; and The resource allocation logic unit is further configured to: In response to determining that the existing policy table includes sufficient memory, adding the one or more policy entries to the existing policy table; and In response to determining that the existing policy table does not include sufficient memory, resources are reassigned to the existing policy table for accommodating the one or more policy entries.

Images