ACKGROUND

[0001] High speed communication networks form part of the backbone of what has become indispensable worldwide data connectivity. Within such communication networks, various network devices including endpoint devices and switching devices direct network traffic from source ports to destination ports, helping to eventually guide a data packet from a source to a destination. Improvements in the efficiency of these communication networks will increase the effectiveness of communicating data.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Certain examples are described in the following detailed description and in reference to the drawings.

[0003] Figure 1 shows an example of a system that supports reduced orthogonal network policy set selection.

[0004] Figure 2 shows an example selection of a reduced orthogonal network policy set by an orthogonal policy reduction engine.

[0005] Figure 3 shows another example selection of a reduced orthogonal network policy set by the orthogonal policy reduction engine,

[0006] Figure 4 shows an example of reduced orthogonal network policy set selections for different switching devices.

[0007] Figure 5 shows an example of logic that a system or device may implement to support reduced orthogonal network policy set selection.

[0008] Figure 6 shows an example of a device that supports reduced orthogonal network policy set selection. DETAILED DESCRIPTION

[0009] The disclosure herein describes systems, methods, devices, and logic that may support selection of a particular reduced orthogonal network policy set among multiple different reduced orthogonal network policy sets that each represent network policies to enforce on network traffic communicated across a communication network. As described in greater detail below, selection of the particular reduced orthogonal network policy set may be based on a characteristic of a target switching device, such as a switching capability of the target switching device. The selection features described herein may increase network operations efficiency and network throughput, such as through selection of a particular reduced orthogonal network policy set that the target switching device can implement with increased efficiency.

[0010] Figure 1 shows an example of a system 100 that supports reduced orthogonal network policy set selection. The system 100 may take the form of a computing system, including a single or multiple computing devices such as application servers, switching devices, network controllers, compute nodes, desktop or laptop computers, smart phones or other mobile devices, tablet devices, embedded controllers, and more. The system 100 may be part of a communication network, and may thus take the form of an endpoint device, a controller device that manages switching functions in the communication network, a switching device, a router, an edge device, or any other network device that transmits, receives, or otherwise controls the routing of data through the communication network. In some examples, the communication network is implemented, controlled, or managed through a software defined networking (SDN) architecture, and the system 100 may implement an SDN controller in such an example.

[0011] The system 100 may effectuate intent-based network policies in a communication network. An intent-based network policy may refer to or take the form of any expression of matching criteria for network traffic and a corresponding action to take for network traffic satisfying the matching criteria. The matching criteria of an intent-based network policy may be specified through various policy dimensions, and the matching criteria may thus include specific dimension values to match for among network traffic.

[0012] As one example, an intent-based network policy may specify a network policy according to source, destination, classifier, and context dimensions, wherein network traffic matching the specific dimension values of the policy result in performing of the corresponding action. The source dimension may include an indication of a source of network traffic (e.g., a source Internet Protocol (IP) address of an endpoint device transmitting a packet) and the destination dimension may include an indication of a destination for the network traffic. The classifier dimension may refer to a particular type of network traffic, a particular type of device to or from which the network traffic is routed, or any other type of identifier by which network traffic can be categorized. For instance, a classifier can include a combination of logical expressions involving an IP protocol, an ethernet type, an L4 source port, among other types of expressions. The context dimension may refer to a global condition during which the network policy should apply (e.g., during a particular timeframe, when network consumption exceeds a threshold level, or according to any other contextual criteria).

[0013] The system 100 may identify intent-based network policies from applications executing on endpoint devices of a communication network. For example, a particular application may specify a first intent-based network policy to "Inspect all traffic sent to the datacenter" and another application may specify a second intent-based network policy to "Log all IP traffic from contractors during 8am-5pm". When applications within the communication network want to control the same switching devices in the network to process network traffic in a particular way, a conflict may arise between the instructions of one application and the instructions of another application for a particular switching device. In such instances, the system 100 may support detection and resolution of policy conflicts that arise between different intent-based network policies, e.g., which action(s) to take when network traffic meets the matching criteria (e.g., specified dimension values) of more than one intent-based network policy. [0014] !n particular, the system 100 may transform the multiple intent-based network policies into an orthogonal network policy set. An orthogonal network policy set may refer to a set of multiple network policies (also referred to as orthogonal network policies) that are orthogonal to one another in that no orthogonal network policy in the orthogonal network policy set conflicts with any other orthogonal network policy in the orthogonal network policy set. Put another way, orthogonal network policies may not have any overlapping policy space in that the dimension values of the orthogonal network policies do not overlap. Conflict detection and determination of orthogonal network policy sets are described in further detail below as well as in PCT Application No. US2015/015122, entitled "Network Policy Conflict Detection and Resolution" and filed on February 10, 2015, which is hereby incorporated by reference in its entirety. As also described in greater detail below, the system 100 may further reduce the orthogonal network policy set into multiple reduced orthogonal network policy sets and select a particular reduced orthogonal network policy set to implement on a target switching device, e.g., through translation into a protocol- specific format supported by the target switching device.

[0015] As one example, the system 100 shown in Figure 1 includes a conflict resolution engine 108 and an orthogonal policy reduction engine 1 10. The system 100 may implement the engines 108 and 1 10 (and components thereof) in various ways, for example as hardware and programming. The programming for the engines 108 and 1 10 may take the form of processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the engines 108 and 1 10 may include a processing resource to execute those instructions. A processing resource may take the form of single processor or multi-processor systems, and in some examples, the system 100 implements multiple engines using the same computing system features or hardware components (e.g., a common processing resource).

[0016] As seen in the example shown in Figure 1 , the conflict resolution engine 108 may include an engine component to derive an orthogonal network policy set that represents a first intent-based network policy and a second intent-based network policy. As also seen in Figure 1 , the orthogonal policy reduction engine 1 10 may include engine components to determine a first reduced orthogonal network policy set that combines a pair of orthogonal network policies from the orthogonal network policy set into a first reduced orthogonal network policy; determine a second reduced orthogonal network policy set that combines a different pair of orthogonal network policies from the orthogonal network policy set into a second reduced orthogonal network policy; and select the first reduced orthogonal network policy set, and not the second reduced orthogonal network policy set, to implement on a target switching device based on a characteristic of the target switching device,

[0017] Some example features and concrete illustrations relating to reduced orthogonal network policy set selection are described in greater detail next.

[0018] Figure 2 shows an example selection of a reduced orthogonal network policy set by the orthogonal policy reduction engine 1 10. The example in Figure 2 includes a switching device 201 , which may be any device that communicates network traffic such as a router, switch, hub, or various other network devices. A controller 210 is also shown in Figure 2, which may manage the switching device 201 . The controller 210 may implement a conflict resolution engine 108, orthogonal policy reduction engine 1 10, and any number of other engines to support conflict resolution and implementation of intent-based network policies in switching devices of a communication network. As noted above, the engines may take the form of hardware and programming, for example.

[0019] !n some examples, the controller 210 is an SDN controller. The controller 210 may thus be physically separate from the switching devices managed by the controller 210, decoupling the system that makes decisions about where network traffic is sent (which may be referred to as a control plane) from the underlying systems that forward then the network traffic to the selected destination (which may be referred to as a data plane). The controller 210 may control how data traverses across the data plane, for example by determining and assigning data routes in the communication network for traffic flows and configuring the managed switching devices to route a particular traffic flow (also referred to as a dataflow) according to a determined data route. The controller 210 may thus assign network switching functions to a target switching device, such as the switching device 201 shown in Figure 2.

[0020] The controller 210 may identify intent-based network policies specified by various applications, such as applications executing in an application layer of an SDN architecture. In response, the controller 210 may implement the intent- based network policies in a managed communication network, particularly by instructing switching devices which actions to take when network traffic satisfies the matching criteria (e.g. , dimension values) of the intent-based network policies. For conflicts that arise between multiple intent-based network policies, the controller 210 may identify and resolve such conflicts. In doing so, the conflict resolution engine 108 may derive an orthogonal network policy set 220 that represents multiple intent-based network policies, including in any of the ways described in PCT Application No. US2015/015122.

[0021] The conflict resolution engine 108 may determine policy overlap between multiple intent-based policies with the following four dimensions: a source dimension, a destination dimension, a classifier dimension, and a context dimension. To illustrate through intent-based network policies "A" and "B", the conflict resolution engine 108 may identify orthogonal policy spaces "A and B" (or "A && B"), "A and not B" (or "A && IB"), and "not A and B" (or "!A && B ^" ), and do so on a dimension-specific basis. Thus, for the 4-dimensional intent-based policies "A" and "B", up to a total of 81 orthogonal network policies without overlapping policy spaces are possible. Table 1 below illustrates the 81 possible orthogonal network policies that the conflict resolution engine 108 may identify for 4~dimensional intent-based network policies "A" and "B".

Reference Source Destination Classifier Context

Number SA SB DA DB CA CB TA TB Valid?

#1 0 1 0 1 0 1 0 1

#2 0 1 0 1 0 1 1 0 Invalid

#3 0 1 0 1 0 1 1 1

#4 0 1 0 1 1 0 0 1 Invalid

#5 0 1 0 1 1 0 1 0 Invalid

#6 0 1 0 1 1 0 1 1 Invalid

#7 0 1 0 1 1 1 0 1 #8 0 1 0 1 1 1 1 0 Invalid

#9 0 1 0 1 1 1 1 1

#10 0 1 1 0 0 1 0 1 Invalid

#1 1 0 1 1 0 0 1 1 0 Invalid

#12 0 1 1 0 0 1 1 1 Invalid

#13 0 1 1 0 1 0 0 1 Invalid

#14 0 1 1 0 1 0 1 0 Invalid

#15 0 1 1 0 1 0 1 1 Invalid

#16 0 1 1 0 1 1 0 1 Invalid

#17 0 1 1 0 1 1 1 0 Invalid

#18 0 1 1 0 1 1 1 1 Invalid

#19 0 1 1 1 0 1 0 1

#20 0 1 1 1 0 1 1 0 Invalid

#21 0 1 1 1 0 1 1 1

^■ ^ ^■ 22 0 1 1 1 1 0 0 1 Invalid

^■ ^23 0 1 1 1 1 0 1 0 Invalid

#24 0 1 1 1 1 0 1 1 Invalid

#25 0 1 1 1 1 1 0 1

#26 0 1 1 1 1 1 1 0 Invalid

#27 0 1 1 1 1 1 1 1

#28 1 0 0 1 0 1 0 1 Invalid

#29 1 0 0 1 0 1 1 0 Invalid

#30 1 0 0 1 0 1 1 1 Invalid

#31 1 0 0 1 1 0 0 1 Invalid

#32 1 0 0 1 1 0 1 0 Invalid

#33 1 0 0 1 1 0 1 1 Invalid

#34 1 0 0 1 1 1 0 1 Invalid

#35 1 0 0 1 1 1 1 0 Invalid

#36 1 0 0 1 1 1 1 1 Invalid

#37 1 0 1 0 0 1 0 1 Invalid

#38 1 0 1 0 0 1 1 0 Invalid

#39 1 0 1 0 0 1 1 1 Invalid

#40 1 0 1 0 1 0 0 1 Invalid

#41 1 0 1 0 1 0 1 0

#42 1 0 1 0 1 0 1 1

#43 1 0 1 0 1 1 0 1 Invalid

#44 1 0 1 0 1 1 1 0

#45 1 0 1 0 1 1 1 1

#46 1 0 1 1 0 1 0 1 Invalid

#47 1 0 1 1 0 1 1 0 Invalid

#48 1 0 1 1 0 1 1 1 Invalid

#49 1 0 1 1 1 0 0 1 Invalid

#50 1 0 1 1 1 0 1 0

#51 1 0 1 1 1 0 1 1

^■ "52 1 0 1 1 1 1 0 1 Invalid #53 1 0 1 1 1 1 1 0

#54 1 0 1 1 1 1 1 1

#55 1 1 0 1 0 1 0 1

#56 1 1 0 1 0 1 1 0 Invalid

#57 1 1 0 1 0 1 1 1

#58 1 1 0 1 1 0 0 1 Invalid

#59 1 1 0 1 1 0 1 0 Invalid

#60 1 1 0 1 1 0 1 1 Invalid

#61 1 1 0 1 1 1 0 1

#62 1 1 0 1 1 1 1 0 Invalid

#63 1 1 0 1 1 1 1 1

#64 1 1 1 0 0 1 0 1 Invalid

#65 1 1 1 0 0 1 1 0 Invalid

#66 1 1 1 0 0 1 1 1 Invalid

#67 1 1 1 0 1 0 0 1 Invalid

#68 1 1 1 0 1 0 1 0

#69 1 1 1 0 1 0 1 1

#70 1 1 1 0 1 1 0 1 Invalid

#71 1 1 1 0 1 1 1 0

#72 1 1 1 0 1 1 1 1

#73 1 1 1 1 0 1 0 1

4 1 1 1 1 0 1 1 0 Invalid

#75 1 1 1 1 0 1 1 1

#76 1 1 1 1 1 0 0 1 Invalid

#77 1 1 1 1 1 0 1 0

#78 1 1 1 1 1 0 1 1

#79 1 1 1 1 1 1 0 1

#80 1 1 1 1 1 1 1 0

#81 1 1 1 1 1 1 1 1

Table 1 : Possible Orthogonal Meiwork Policies for ■^-dimensional Intent-Based etwork Policies A and B

[0022] As shown above, some of the orthogonal network policies are labeled as "invalid". The conflict resolution engine 108 may identify such invalid orthogonal network policies, and exclude the invalid orthogonal network policies from the orthogonal network policy set 220. An invalid orthogonal network policy may refer to an orthogonal network policy that represents a policy space that exclusively matches one dimension of the first policy and exclusively matches another dimension of the second policy. Since both policies are excluded in at least one dimension, neither the matching criteria of the first policy nor the matching criteria of the second policy are met. Thus, the entire orthogonai policy does not apply and can thus be deemed invalid.

[0023] For instance, each of network policies #10-#18 includes (i) only the source dimension matching criterion of intent-based network policy "B", and (ii) only the destination dimension matching criterion of intent-based network policy "A". Thus, for each of these network policies #10-#18, the intent-based network policies "A" and "B", one dimension (the source dimension) of network policy "A" is excluded and one dimension of network policy "B" (the destination dimension) is excluded, regardless of the classifier and context dimensions for these intent- based network poiicies. That is, for policies #10-#18, the matching criteria of both policy "A" and policy "B" are not met, so there is no action to perform. These policies #10-#18 may therefore be identified as invalid by the conflict resolution engine 108. The conflict resolution engine 108 may similarly identify other invalid orthogonai network policies to exclude from the orthogonal network policy set

[0024] Table 1 above includes a "Valid?" column indicating invalid orthogonal network poiicies that the conflict resolution engine 108 may exclude from the orthogonai network policy set 220. Table 2 illustrates 31 possible valid orthogonal network policies that the conflict resolution engine 108 may identify for 4- dimensional intent-based network policies "A" and "B", using consistent policy reference numbers with Table 1 .

Reference Source Destination Cf essif ser Context

MCtlOn

Number SA SB DA DB CA CB TA TB

#1 0 1 0 1 0 1 0 1 Actions

#3 0 1 0 1 0 1 1 1 Actions

#7 0 1 0 1 1 1 0 1 Actions

#9 0 1 0 1 1 1 1 1 Actions

#19 0 1 1 1 0 1 0 1 Actions

#21 0 1 1 1 0 1 1 1 Actions

0 1 1 1 1 1 0 1 Actions

#27 0 1 1 1 1 1 1 1 Actions

#41 1 0 1 0 1 0 1 0 ActionA

#42 1 0 1 0 1 0 1 1 ActionA

#44 1 0 1 0 1 1 1 0 ActionA

#45 1 0 1 0 1 1 1 1 ActionA

#50 1 0 1 1 1 0 1 0 ActionA #51 1 0 1 1 1 0 1 1 ActionA

#53 1 0 1 1 1 1 1 0 ActionA

#54 1 0 1 1 1 1 1 1 ActioriA

#55 1 1 0 1 0 1 0 1 Actions

#57 1 1 0 1 0 1 1 1 Actions

#61 1 1 0 1 1 1 0 1 Actions

#63 1 1 0 1 1 1 1 1 Actions

#68 1 1 1 0 1 0 1 0 ActionA

#69 1 1 1 0 1 0 1 1 ActionA

#71 1 1 1 0 1 1 1 0 ActionA

#72 1 1 1 0 1 1 1 1 ActionA

#73 1 1 1 1 0 1 0 1 Actions

#75 1 1 1 1 0 1 1 1 Actions

#77 1 1 1 1 1 0 1 0 ActionA

#78 1 1 1 1 1 0 1 1 ActionA

#79 1 1 1 1 1 1 0 1 ActionB

#80 1 1 1 1 1 1 1 0 ActionA

ActionA +

#81 1 1 1 1 1 1 1 1

ActionB

Table 2: Possible Valid Orthogonal Network Policies for 4-dimer!sio!iaS Intent-Based Network Policies A and B

[0025] As seen above, Table 2 above illustrates the corresponding action to perform for each of the possible valid orthogonal network policies. The corresponding action to perform may be reflective of the intent-based network policy "A" or "B" that has each of its matching criteria met for a particular orthogonal network policy. For instance, orthogonal network policy #69 has a "1 " (or satisfied) value for each of the source, destination, classifier, and context dimensions for policy "A", and thus the action for intent-based network policy "B" is performed (denoted as Actions). For orthogonal network policy #81 , the conflict resolution engine 108 may determine that the corresponding action for both network policies "A" and "B" are performed, as policy #81 includes a satisfied value for each of the dimensions for both policies "A" and "B".

[0026] Thus, for the example 4-dimensional intent-based network policies "A" and "B", the conflict resolution engine 108 may derive up to 31 orthogonal network policies to include in orthogonal network policy set 220. However, the exact number of orthogonal network policies specified included in the orthogonal network policy set 220 may vary depending on the specific matching criteria (e.g., dimension values) of the intent-based network policies "A" and "B". To illustrate, the intent-based network policies "A" and "B" may have some or no overlapping policy spaces for a particular policy dimension (e.g., a source dimension). As such, the conflict resolution engine 108 may determine not to include some of the possible orthogonal network policies listed above in Table 2 in the orthogonal network policy set 220. The number of orthogonal network policies included in the orthogonal network policy set 220 may thus vary according to the degree of overlap between the intent-based network policies represented by the orthogonal network policy set 220.

[0027] To provide a continuing, concrete illustration to help explain the features described herein, the controller 210 may control switching devices in a communication network (e.g., according to an SDN architecture) to implement an intent-based network policy P1 to "Inspect all traffic sent to the datacenter" and an intent-based network policy P2 to "Log all IP traffic from contractors during 8arn-5pm", In this concrete illustration, the controller 210 may identify the intent- based network policy P1 in a 4-dimensional intent-based network policy framework as follows:

Dest natsonpi Classifserpi Contextpi

Inspect

Thus, the controller 210 may identify matching criteria for the source, destination, classifier, and context dimensions as well as a corresponding action for network traffic satisfying the matching criteria. The ^* matching criteria value in the intent- based network policy P1 may be a wildcard value representative of any value, an unspecified value, or a "do not care" value for the source, classifier, and context dimensions. That is, the ^* wildcard value may indicate that any value for the particular dimension will satisfy the matching criteria of the network policy. For the intent-based network policy P2, the controller 210 may identify the intent- based policy P2 in the 4-dimensional intent-based network policy framework as follows: From the intent-based network policies P1 and P2, the conflict resolution engine 108 may determine an orthogonal network policy set 220 that includes multiple orthogonal network policies that together represent the policies P1 and P2 (and resolving conflicts between overlapping policy spaces).

[0028] Thus, applying these concrete network policies P1 and P2 to the valid orthogonal network policies in Table 2 above, the conflict resolution engine 108 may identify the following dimension values for the valid orthogonal network policies, shown in Table 3 below (with actions shown):

Inspect +

#81 Contractor Datacenter IP 8am-5pm

Table 3: Dimerssior! Values for Example Network Policies P1 arid P2

Note that the expression (not ^* ) or (! ^* ), which represents the inverse of an "any" value, reduces to a "none" value for the source, destination, and classifier dimensions and to a "never" value for the context dimension. Also, the logical combination of any matching criterion with a "none" or "never" value reduces simply to "none" or "never". For example, a source dimension expression of (Contractor && ! ^* ) reduces to none, because there is no dimension value that satisfies the expression. Likewise, a context dimension expression of (8am-5pm && ! ^* ) reduces to never, as the inverse of an "any" context dimension value (or "unspecified") is never (or none), and the logical combination of any matching criterion with a "never" value reduces simply to "never". Also note that the logical combination of a wildcard value ^* and a particular dimension value reduces to just the particular dimension value. For example, the source dimension value for orthogonal network policy #50 can be represented as the expression (Sourcepi && !Sourcep2). In the concrete illustration, this expression takes the form ( ^* && !Contractor), and reduces to simply (!Contractor) as shown above.

[0029] For orthogonal network policies with a "none" or "never" value for any dimension, the conflict resolution engine 108 may exclude, ignore, or prune such policies from the orthogonal network policy 220. Thus, for this particular concrete illustration, the conflict resolution engine 108 may determine the orthogonal network policy set 220 to include 9 orthogonal network policies instead of all 31 of the possible orthogonal network policies listed above. In particular, the conflict resolution engine 108 may identify the following orthogonal network policies shown in Table 4 to represent the intent-based network policies P1 and P2 in this concrete illustration:

Reference

Source Destination Classifier Context Action Number

#50 !Contractor Datacenter IIP !(8am-5pm) Inspect

#51 !Contractor Datacenter IIP 8am-Spm Inspect

#53 !Contractor Datacenter IP !(Sam-5pm) Inspect

#54 !Contractor Datacenter IP 8am-Spm Inspect

#63 Contractor ! Datacenter IP 8am -5pm Log

Tabie 4: Example Orthogonal Network Policy Set 220 (with actions) for example Network Policies P1 arid P2

Thus, the conflict resolution engine 108 may determine the orthogonal network policy set 220 in this concrete illustration to include the 9 orthogonal network policies above,

[0030] From the orthogonal network policy set 220, the orthogonal policy reduction engine 1 10 may determine multiple reduced orthogonal network policy sets, such as the reduced orthogonal network policy sets 221 and 222 shown in Figure 2. A reduced orthogonal network policy set may refer to a set of orthogonal network policies that includes at least one combined orthogonal network policy that combines two or more orthogonal network policies, e.g., network policies from the orthogonal network policy set 220 or previously-combined orthogonal network policies. The reduced orthogonal network policy set may be reduced in the sense that it includes a lesser number of orthogonal network policies than the original orthogonal network policy set 220.

[0031] The orthogonal policy reduction engine 1 10 may combine various orthogonal network policies in an orthogonal network policy set 220 in differing combinations to generate multiple, different reduced orthogonal network policy sets. Each of the reduced orthogonal network policy sets may represent the same intent-based network policies, but do so in different ways. The example in Figure 2 shows two reduced orthogonal network policy sets that the orthogonal policy reduction engine 1 10 determines (labeled as the reduced orthogonal network policy sets 221 and 222 respectively), though the orthogonal policy reduction engine 1 10 may determine more reduced orthogonal network policy sets than two.

[0032] The orthogonal policy reduction engine 1 10 may combine orthogonal network policies through a wildcard value (denoted herein as a ^* value). For instance, the orthogonal policy reduction engine 1 10 may identify a pair of orthogonal network policies that differ in whether a matching criterion of a particular policy dimension is satisfied, and combine the pair of orthogonal network policies into a combined orthogonal network policy that utilizes the wildcard value for the differing dimension value. The pair may be two orthogonal network policies from the orthogonal network policy set 220, an orthogonal network policy from the orthogonal network policy set 220 and a previously- combined orthogonal network policy, or two previously-combined orthogonal network policies. As an example, the orthogonal policy reduction engine 1 10 may determine that the orthogonal network policy set 220 representing a particular set of intent-based network policies (e.g. , intent-based network policies P1 and P2) includes the following three orthogonal network policies that correspond to policy reference numbers #78, #77, and #80 from Tables 1 , 2, 3, and 4 above:

The orthogonal network policies #78, #77, and #80 may be a subset of the orthogonal network policy set 220, e.g. , as shown in Table 4 in the context of the continuing, concrete illustration. As seen above, orthogonal network policies #78 and #77 differ only in whether the matching criterion (or criteria) of the context dimension of the intent-based network policy P2 is satisfied or not. Orthogonal network policies #77 and #80 differ only in whether the matching criterion (or criteria) of the classifier dimension value of the intent-based network policy P2 is satisfied or not.

[0033] In the example above, the orthogonal policy reduction engine 1 10 may determine a first reduced orthogonal network policy set that includes the orthogonal policies #78 and #77 combined into the following combined orthogonal network policy: In a consistent manner, the orthogonal policy reduction engine 1 10 may determine a second reduced orthogonal network policy set that combines a different pair of orthogonal network policies, such as orthogonal network policies #77 and #80, which may be combined into the following combined orthogonal network poiicy:

In this example, the first and second reduced orthogonal network policy sets each represent the same intent-based network policies, but do so with a different combination of orthogonal and combined orthogonal network policies.

[0034] To illustrate in the context of the continuing concrete illustration with the intent-based network policies P1 and P2, the orthogonal poiicy reduction engine 1 10 may derive the following three orthogonal network policies as a subset of the orthogonal network policy set 220 (using consistent reference numbers as Tables 1 , 2, 3, and 4):

The orthogonal poiicy reduction engine 1 10 may thus combine policies #78 and #77 to determine a first reduced orthogonal network policy set and combine policies #77 and #78 to determine a second, different orthogonal network poiicy set (and even more beyond these two as well, as illustrated in greater detail below). Then, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set to implement on the target switching device. A detailed illustration of reduced orthogonal network policy set determination in the context of the continuing concrete illustration with intent- based network policies P1 and P2 is presented below.

[0035] !n some examples, the orthogonal poiicy reduction engine 1 10 combines orthogonal network policies with the same corresponding action, but determines not to combine orthogonal network policies with different corresponding actions. For instance, the orthogonal poiicy reduction engine 1 10 may determine not to combine a first orthogonal network policy with a corresponding action (e.g., inspect) with a second orthogonal network policy with a different corresponding action (e.g., log or iog+inspect).

[0036] While an example combinations of orthogonal network policies were described above, the orthogonal policy reduction engine 1 10 may combine orthogonal network policies in multiple different ways and for multiple different dimensions. The orthogonal policy reduction engine 1 10 may determine reduced orthogonal network policy sets iterativeiy, sequentially, or in parallel by further combining previously-combined orthogonal network policies with other orthogonal network policies (or other previously-combined orthogonal network policies) to yield many different combinations. The process by which the orthogonal policy reduction engine 1 10 determines reduced orthogonal network policy sets from the orthogonal network policy set 220 may also be referred to as reductions of the orthogonal network policy set 220.

[0037] Thus, the orthogonal policy reduction engine 1 10 may generate multiple reduced orthogonal network policy sets that each include a single or multiple combined orthogonal network policy, the multiple reduced orthogonal network policy sets resulting from multiple, different combinations of orthogonal network policies. In some examples, the controller 210 may set a combination limit for the number of combinations that occur to control resource consumption (e.g., by limiting the number of combinations included for a particular combined orthogonal network policy or in various other ways).

[0038] From the multiple reduced orthogonal network policy sets, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set to implement on a target switching device. In Figure 2, the switching device 201 is the target switching device that the orthogonal policy reduction engine 1 10 selects a particular reduced orthogonal network policy set for, e.g., from among the reduced orthogonal network policy sets 221 and 222 and any other reduced orthogonal network policy sets that are determined.

[0039] In some implementations, the orthogonal policy reduction engine 1 10 selects a particular reduced orthogonal network policy set for implementation after translating some or all of the multiple reduced orthogonal network policy sets into a protocol-specific format supported by the target switching device. The protocol-specific format may refer to a configuration message format or switching configuration format of a protocol used by a switching device to implement matching criteria and perform the corresponding action. Example protocols include the OpenFlow protocol for SDN architectures or Access Control Lists (ACLs). Translation of a reduced orthogonal network policy set may thus take the form of protocol-specific messages (e.g., OpenFlow messages or ACL messages).

[0040] In the example shown in Figure 2, the orthogonal policy reduction engine 1 10 passes the reduced orthogonal network policy sets 221 and 222 to the translation engine 230, which may also be part of the controller 210. The translation engine 230 may translate the reduced orthogonal network policy sets 221 and 222 into a protocol-specific format supported by the switching device 201 , including according to any of the ways described in U.S. PCT Application No. US2015/015122. !n this example, the orthogonal policy reduction engine 1 10 selects the particular reduced orthogonal network policy set to implement on the switching device 201 from the translated protocol-specific messages 231 and 232. That is, the orthogonal policy reduction engine 1 10 selects the reduced orthogonal network policy set 221 in this particular example. In doing so, the orthogonal policy reduction engine 1 10 may make the selection based on various factors or combination of factors, some example of which are presented next.

[0041] The orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set based on a characteristic of the target switching device. For instance, the orthogonal policy reduction engine 1 10 may identify a resource consumption rate, particular switching capability, table implementation, packet processing characteristic, or any other attribute of the target switching device to account for in selecting a particular reduced orthogonal network policy set to translate. By accounting for a specific characteristic of the target switching device itself, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set that, when translated into a protocol-specific format, supports effectuating the represent intent-based network policies with increased efficiency, e.g., with reduced resource consumption or increased network throughput.

[0042] In some examples, the characteristic of the target switching device accounted for in the reduced orthogonal network policy set selection is a wildcard processing capability for a particular match field in the orthogonal network policy set 220. A match field may refer to a particular packet characteristic that corresponds to a dimension value of the orthogonal network policy set 220, e.g., the source IP address of a packet that corresponds to a source dimension value of the orthogonal network policy set 220. Thus, when the target switching device supports wildcard processing capabilities for a particular match field, but not other match fields, the orthogonal policy reduction engine 1 10 may select a reduced orthogonal network policy set that includes a wildcard value for the particular match field (e.g., for the corresponding dimension value).

[0043] As another example, the characteristic of the target switch device accounted for in the reduced orthogonal network policy set selection may be a table capability of the target switch device. A table may refer to any lookup mechanism or logic by which a switching device parses network traffic, e.g., to identify network traffic satisfying matching criteria for packet forwarding or security actions, and the like. Thus, a table capability of the switching device may refer to any capability with regards to how the switching device processes packet data. Example table capabilities of the target switching device include a number of tables implemented by the target switching device, a table size of a table implemented by the target switching device, a number, type, or combination of actions supported by the table implemented by the target switching device, a particular action that the table implemented by the target switching device implements with increased efficiency, or any combination thereof.

[0044] As another example, the orthogonal policy reduction engine 1 10 may select the particular reduced orthogonal network policy set based on the implementation of a table or other packet processing logic. For instance, the target switching device may implement a table for a particular action using a ternary content addressable memory (TCAM), for which the orthogonal policy reduction engine 1 10 may select, for implementation, a reduced orthogonal network policy set that matches on multiple fields and has a lesser number of flow entries to match for. On the other hand, when the target switching device implements a table for the particular application using a hash table, the orthogonal policy reduction engine 1 10 may select a reduced orthogonal network policy set that may have a larger number of flows entries, but matches on a single field (instead of multiple fields),

[0045] !n accounting for the characteristics of the target switching device, the orthogonal policy reduction engine 1 10 may select the reduced orthogonal policy network set to maintain a particular action distribution among flows tables of the target switching device. For instance, the target switching device may assign a high-performance table for a particular action (e.g., duplicate packets) and assign other low-performance tables for other actions with lesser performance requirements (e.g., drop packets). A high-performance table may refer to a table or other packet processing logic that processes network traffic above a threshold rate or at a rate greater than other tables implemented by a switching device (e.g., low-performance tables). In this example, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set that maintains the action distribution for the high-performance table, the low-performance tables, or both. The orthogonal policy reduction engine 1 10 may do so by selecting a particular reduced orthogonal network policy set with a lesser number of flows to match for the high-performance action, for example.

[0046] In that regard, the orthogonal policy reduction engine 1 10 may account for a table scale of any number of tables of the target switching device. Table scale may refer to the used capacity or unused capacity of a particular table of the switching device. The orthogonal policy reduction engine 1 10 may select the particular reduced orthogonal network policy set according to particular table scale criteria, such as increasing the used capacity of a particular low- performance table above a threshold level (e.g., > 90% used capacity) or not increasing the used capacity of a high-performance table beyond a threshold amount or at all (e.g., implements only 30 additional table entries for a high- performance table or any other configurable value or metric). Thus, accounting for table scale may allow the orthogonal policy reduction engine 1 10 to specifically select the reduced orthogonal network policy set to implement while decreasing performance impact, e.g., when the implemented network policies of the reduced orthogonal network policy set do not include performance-intensive actions, allowing reservation of high-performance tables for other policies with higher performance utilization,

[0047] The number of dataflows or table entries to match for may be a factor that the orthogonal policy reduction engine 1 10 accounts for in selecting a reduced orthogonal network policy set among the multiple reduced orthogonal network policy sets. A dataflow may refer to a stream of data communicated between a source and a destination, either of which may be a single or set of endpoint entities (e.g., devices, IP addresses, etc.). In that regard, a dataflow may refer to a class of network traffic. A table entry may refer to any packet processing mechanism by which a switching device identifies a dataflow (or set of dataflows). Thus, a table entry for a switching device may specify specific matching criteria to identify in network traffic, including as examples a source and destination IP address, ethertype, packet priority, or various other data fields to parse from a data packet. In accounting for the number of dataflows or table entries, the orthogonal policy reduction engine 1 10 may determine that protocol- specific messages translated from a particular reduced orthogonal network policy set result in the least number of table entries to implement in the target switching device or the least number of dataflows to match for from among protocol-specific messages that were or would be translated from each of the multiple reduced orthogonal network policy sets.

[0048] As another example, selecting of the particular reduced orthogonal network policy set may be based on a number of data values for a particular match field in the orthogonal network policy set. To illustrate, a first reduced orthogonal network policy set may specify matching a classifier dimension value of "contractor" and wildcard a source dimension value and a second reduced orthogonal network policy set may specify matching the source dimension value for "datacenter" and wildcard the classifier dimension value. In this example, the number of contractors (e.g., data values meeting the "contractor" dimension value) and number datacenters (e.g., data values meeting the "datacenter" dimension value) may be accounted for by the orthogonal policy reduction engine 1 10. Thus, if there are 200 contractors but only 2 datacenters accessing the communication network, the orthogonal policy reduction engine 1 10 may select the second reduced orthogonal network policy set for implementation on the target switching device.

[0049] In some implementations, the orthogonal policy reduction engine 1 10 accounts for table performance and efficiency of the various tables implemented in a target switching device. A switching device may implement different tables that support the same action, and the different tables may have different performance characteristics (e.g., higher performance tables may process packets with a particular action or combination of actions with increased throughput, speed, or efficiency), !n that regard, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set that has more table entries than another reduced orthogonal network policy set, but can be implemented (partially or wholly) in a higher-performance table in the switching device. When the higher-performance table does not have an unused capacity to support all of the table entries translated from reduced orthogonal network policy sets, the orthogonal network policy may select a particular reduced orthogonal network policy set with table entries mapping to dataflows with a priority level, consumed bandwidth, number of associated end hosts, or any other dataflow characteristic that exceeds a predetermined threshold (e.g. high-priority, high level of expected bandwidth consumption, etc.)

[0050] !n the example described above, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set that translates into a greater number of table entries to implement or dataflows to match for than other reduced orthogonal network policy sets determined from the orthogonal network policy set 220. The orthogonal policy reduction engine 1 10 may nonetheless make such a selection because the particular reduced orthogonal network policy set may yield better performance (e.g., throughput, speed, etc.) despite having a greater number of table entries to implement or dataflows to match for. Such a scenario may occur when the orthogonal policy reduction engine 1 10 selects a particular reduced orthogonal network policy set with a wildcard value for a dimension that a higher-performance table (e.g., a TCAM) has a wildcard processing capability for, but translates into a greater number of table entries or dataflows to match for than another reduced orthogonal network policy set (e.g., which has a wildcard value for a dimension that the higher- performance table does not support a wildcard processing capability for).

[0051] Put another way, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set even when a different reduced orthogonal network policy set translates into a lesser number of protocol-specific messages than the particular reduced orthogonal network policy set. The orthogonal policy reduction engine 1 10 may do so because the target switching device includes a particular table that processes the particular reduced orthogonal network policy set at a greater speed than the different reduced orthogonal network policy set. In this example, the particular table (e.g., a high- performance table) may include a wildcard processing capability for a particular match field of the particular reduced orthogonal network policy set but not a wildcard processing capability of a different match field of the different reduced orthogonal network policy set.

[0052] As yet another example, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set accounting for a combination of actions that a table in the target switching device supports. In the context of the concrete illustration involving network policies P1 and P2, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set that includes a greater number of entries that can be implemented in a table that supports both "log ^" and "inspect" actions, which may thus reduce the number of table entries that may be duplicated into both a first table to perform the "log" action and a second table to perform the "inspect" action, !n that regard, the orthogonal network reduction engine 1 10 may account for the richness (e.g., degree of combinations) of actions supported by tables of the target switching device.

[0053] While some examples of switching device characteristics and other selection factors have been presented above, the orthogonal policy reduction engine 1 10 may select the particular reduced orthogonal network policy set to implement on the target switching device in any number of ways. The orthogonal policy reduction engine 1 10 may account for any combination of the factors described above, and in some examples weights different characteristics according to configurable or user-specified weights.

[0054] As described above, the orthogonal policy reduction engine 1 10 may account for various factors in selecting a reduced orthogonal network policy set to implement in a target switching device. The orthogonal policy reduction engine 1 10 may also apply multiple iterations or instances of orthogonal policy combinations to determine the reduced orthogonal network policy sets to select from. Some of these features are illustrated next in the context of the continuing concrete illustration involving network policies P1 and P2.

[0055] !n particular, three different sets of reductions on the orthogonal network policy set 220 that the orthogonal policy reduction engine 1 10 may perform are detailed. For each of the reductions, the orthogonal policy reduction engine 1 10 may start with the orthogonal network policy set 220 for the network policies P1 and P2, shown above in Table 4. The sets of reductions performed by the orthogonal policy reduction engine 1 10 in this illustration are referred to as reductions A, B, and C respectively.

[0056] For reduction A, the orthogonal policy reduction engine 1 10 may perform a first set of reductions by combining orthogonal network policies in the orthogonal network policy set 220 as shown in Table 5 below:

TabUe S: First set of reductions for Reduction A

From the first set of reductions, the orthogonal policy reduction engine 1 10 may perform a second set of reductions by further combining the orthogonal network policies as shown in Table 6 below:

Table 6: Second set of reductions for Reduction A

After the second set of reductions shown in Table 8, the orthogonal policy reduction engine 1 10 may determine that no further reductions for reduction A are possible, and may thus identify the orthogonal network policies in Table 6 as the reduced orthogonal network policy set resulting from performing reduction A (referred to also as reduced orthogonal network policy set A in the context of this concrete illustration). Reduced orthogonal network policy set A may thus be implemented as (e.g., translated into) 5 table entries, with 2 table entries that are applied at ail times by a target switching device (e.g., with a context dimension value of ^* ), 2 table entries that is applied from 8am-5pm, and 1 entry that is applied outside of 8am-5pm. Thus, the reduced orthogonal network policy set A, when implemented, may require that at least 3 table entries be applied at any given point in time, with 4 table entries applied from 8am-5pm.

[0057] Turning to reduction B, the orthogonal policy reduction engine 1 10 may perform a first set of reductions by combining orthogonal network policies in the orthogonal network policy set 220 as shown in Table 7 below:

Reference

Source Destination Classifier Context Action Number

#50+#51 !Contractor Datacenter IIP _* Inspect

Tab!e 7: First set of reductions for Reduction B

Note that the first set of reductions for reductions A and B differ only in that reduction A combines policies #77 and #78 (with policy #80 not combined with another policy) whereas reduction B combines policies #77 and #80 (with policy #78 not combined instead). From the first set of reductions for reduction B, the orthogonal policy reduction engine 1 10 may perform a second set of reductions by further combining the orthogonal network policies as shown in Table 8 below:

Table 8: Second set of reductions for Reduction B

After the second set of reductions shown in Table 8, the orthogonal policy reduction engine 1 10 may determine that no further reductions for reduction B are possible, and may thus identify the orthogonal network policies in Table 8 as the reduced orthogonal network policy set that results from performing reduction B (referred to also as reduced orthogonal network policy set B in the context of this concrete illustration). Reduced orthogonal network policy set B may thus be implemented as (e.g., translated into) 5 table entries, with 1 entry that is applied at ail times by a target switching device (e.g. , with a context dimension value of ^* ), 3 entries that are applied from 8am-5pm, and 1 entry that is applied outside of 8am~5pm. Thus, the reduced orthogonal network policy set B, when implemented, may require that at least 2 table entries be applied at any given point in time, with 4 table entries being applied from 8am-5pm. [0058] Next, regarding reduction C, the orthogonal policy reduction engine 1 10 may perform a first set of reductions by combining orthogonal network policies in the orthogonal network policy set 220 as shown in Table 9 below:

Tab!e 9: First set of reductions for Reduction C

Note that for reduction C, the orthogonal policy reduction engine 1 10 does not perform the policy combinations of (i) #77 and #78 or (ii) #77 and #80 that are performed for reductions A and B respectively. Instead, the orthogonal policy reduction engine 1 10 combines the network polices of the orthogonal network policy set 220 in a different way, while nonetheless representing the network policies P1 and P2. From the first set of reductions for reduction C, the orthogonal policy reduction engine 1 10 may perform a second set of reductions by further combining the orthogonal network policies as shown in Table 10 below:

Table 10: Second set of reductions for Reduction C

After the second set of reductions shown in Table 10, the orthogonal policy reduction engine 1 10 may determine that no further reductions for reduction C are possible, and may thus identify the orthogonal network policies in Table 10 as the reduced orthogonal network policy set that results from performing reduction C (referred to also as reduced orthogonal network policy set C in the context of this concrete illustration). Reduced orthogonal network policy set C may thus be implemented as (e.g., translated into) 5 table entries, with 1 entry that is applied at all times by a target switching device (e.g., with a context dimension value of ^* ), 3 entries that are applied from 8am-5pm, and 1 entry that is applied outside of 8am-5pm. Thus, the reduced orthogonal network policy set C, when implemented, may require that at least 2 fable entries be applied at any given point in time, with 4 table entries being applied from 8am-5pm.

[0059] The orthogonal policy reduction engine 1 10 may select among the reduced orthogonal network policy sets A, B, and C to implement on a target switching device. As noted above, the orthogonal policy reduction engine 1 10 may account for the number of dataflows to match for or the number of fable entries to implement in evaluating the various reduced orthogonal network policy sets. For a company with Nc number of contractor endpoints, ND number of datacenfer endpoints and NT total number of endpoints, the orthogonal policy reduction engine 1 10 may determine the reduced orthogonal network policy sets A, B, and C produce the following number of dataflows to match for, as shown in Tables 1 1 , 12, and 13 respectively:

ibie 12: Mtsmber of dataflows to match for Reduced Orthogonal Metwork Policy Set E

Table 13: Number of dataflows to match for Reduced Orthogonal Metwork Policy Set C

[0060] To evaluate the reduced orthogonal network policy sets A, B, and C for selection, the orthogonal policy reduction engine 1 10 may identify or refer to specific elements of a communication network, such as making the selection in reference to a specific set of endpoinf devices in the communication network. In particular, the orthogonal policy reduction engine 1 10 may track or identify the number of particular network elements in the communication network. To illustrate with definite numbers, a sample communication network may include 10 contractor endpoints, 5 datacenter endpoints, and 100 total endpoints. In this scenario, the orthogonal policy reduction engine 1 10 may determine the specific number of dataflows that the reduced orthogonal network policy sets match for during the 8am-5pm timeframe and outside of the 8am-5pm timeframe, as shown in Tables 14 and 15 below:

((NT - Nc) x ND) +

B (Nc x (NT - ND)) + 1500 0

2 (Nc x ND)

((NT - Nc) x ND) +

(Nc x (NT - ND)) + 45

C 1455

ND + (3% better) Nc x ND

Table 14: Uw Tiber of Dataflows to atc for Reductions A, B, aoc J C durirsg Sarrs-Spm

Table 15: Number of Dataflows to match for Reductions A, B, and C outside of 8am-5pm

[0061] In Tables 14 and 15 above, a savings comparison with reference to Reduction A is also shown. Thus, in this example, the orthogonal policy reduction engine 1 10 may select the reduced orthogonal network policy set C to implement on a target switching device, as doing so may result in the least number of dataflows to match for or least number of table entries to implement on the target switching device. In this example, the number of dataflows and savings comparison are determined assuming that the target switching device includes a wildcard processing capability for the various wildcard dimension values in the policies of the reduced orthogonal network policy sets A, B, and C. When the target switching device includes wildcard processing capabilities for some, but not ail, dimension values of network policies in the reduced orthogonal network policy sets A, B, and C, the orthogonal policy reduction engine 1 10 may determine the number of dataflows to match for differently, and may select a different reduced orthogonal network policy set to implement on the target switching device,

[0062] !n some examples, the orthogonal policy reduction engine 1 10 may precompute calculations to measure the number of table entries or dataflows to match for, and do so prior to referencing a particular set of intent-based network policies or orthogonal network policy set 220. To explain further, the orthogonal policy reduction engine 1 10 may recognize that for a set of intent-based network policies, there are a certain set of combinations according to whether the dimension values for each dimension are specified or not (and when not, may take the form of a unspecified or wildcard value). As an illustration, the source dimension of intent-based network policies P1 and P2 may be categorized according to one of the following combinations:

The combinations above thus include when (i) when both the source dimension value of intent-based network policy P1 and the source dimension value of intent- based network policy P2 are unspecified (e.g., any or wildcard); (ii) when the source dimension value of intent-based network policy P1 is unspecified and the source dimension value of intent-based network policy P2 is specified (e.g., "all contractors", "with a source address of 192.168.25. ^* ", etc.); (iii) when the source dimension value of intent-based network policy P1 is specified and the source dimension value of intent-based network policy P2 is unspecified; and (iv) when both the source dimension value of intent-based network policy P1 and the source dimension value of intent-based network policy P2 are specified.

[0063] In this example, the orthogonal policy reduction engine 1 10 may identify a total set of dimension combinations, which may vary based on the number of dimensions included in the intent-based network policies. When network policies P1 and P2 are 4-dimensionai (e.g., source, destination, classifier, and context), the orthogonal policy reduction engine 1 10 may identify 258 dimension combinations (e.g., 4 ⁴ number). For each dimension combination in the total set of dimension combinations, the orthogonal policy reduction engine 1 10 may determine the orthogonal network policy set 220 and multiple reduced orthogonal network policy sets, which may vary according to which dimension values of the particular dimension combination include a wildcard value. The orthogonal policy reduction engine 1 10 may do so, as a wildcard value for a particular dimension may result in a "none" or "never" value for various possible orthogonal network policies, allowing the orthogonal policy reduction engine 1 10 to prune such orthogonai network policies from the orthogonai policy set 220.

[0064] To illustrate, one of the dimension combinations that the orthogonal policy reduction engine 1 10 may identify is as follows:

Intent-Based Network Policy A:

Note that the above dimension combination corresponds to the intent-based network policies P1 and P2 in the concrete illustration presented above, and the orthogonai policy reduction engine 1 10 may determine this dimension combination even before receiving the actual intent-based network policies P1 and P2 from applications of a communication network.

[0065] As the logical inverse and combinations of a wildcard value may result in "none" or "never" values, the orthogonai policy reduction engine 1 10 (or conflict resolution engine 108) may determine the orthogonai network policy set 220 for each dimension combination. That is, even prior to receiving the intent-based network policies P1 and P2, the orthogonal policy reduction engine 1 10 may determine the orthogonal network policy set 220 that would apply to intent-based network policies P1 and P2, e.g., among the orthogonai network policy sets 220 applicable to each of the 258 dimension combinations. The orthogonal policy reduction engine 1 10 may do so based on the specific dimensions of each dimension combination that include the wildcard value,

[0066] For the example dimension combination for intent-based network policies A and B specified above (which intent-based network policies P1 and P2 correspond to), the orthogonal policy reduction engine 1 10 may precompute the following orthogonal network policies from possible valid orthogonal network policies as shown in Table 18:

Table 16: Precomputed Orthogonal Network Policies

for ars Example Dimension Combination

From the precomputed orthogonal network policies for a particular dimension combination, the orthogonal policy reduction engine 1 10 may prune any orthogonal network polices that include a "never or "none" dimension value, which may yield the orthogonal network policy 220 for the dimension combination specified according to logical dimension values (e.g., SourceB or DestinationA). In the example above, the orthogonal policy reduction engine 1 10 may prune policies #1 , #3, #7, #9, #19, #21 , #25, #27, #41 , #42, #44, #45, #55, #57, #61 , #68, #69, #71 , #72, #73, #75, and #79. When the orthogonal policy reduction engine 1 10 receives intent-based network policies that match this particular dimension combination, the orthogonal policy reduction engine 1 10 (or conflict engine 108) may determine the orthogonal network policy set 220 by replacing the logical dimension values with the concrete values of the policies (e.g., replace Sourcee with "Contractors ^" or replace DestinationA with "Datacenter").

[0067] For each dimension combination, the orthogonal policy reduction engine 1 10 may further perform various reductions to the orthogonal network policy set 220 expressed with logical values. The orthogonal policy reduction engine 1 10 may precompute the reductions, even prior to receiving actual intent-based network policies. As an example using the particular dimension combination above, the orthogonal policy reduction engine 1 10 may determine reductions to the orthogonal network policy set 220 expressed with logical values in a consistent manner as described above for reductions A, B, and C, using logical values instead of concrete policy values. Similar to reduction C described above, the orthogonal policy reduction engine 1 10 may precompute the following reduced orthogonal network policy set for the particular dimension combination, as shown in Table 17:

Table 17: Precompiled reduced orthogorsa! rsetwork policy set for example dimension combsrsatiori The orthogonal policy reduction engine 1 10 may thus determine multiple reduced orthogonal network policy sets expressed with logical values, and do so for each dimension combination,

[0068] Along similar lines, the orthogonal policy reduction engine 1 10 may precompute a logical expression indicative of a number of dataflows to match for or table entries to implement from the determined reduced orthogonal network policy sets. For instance, the orthogonal network policy reduction engine 1 10 may include numerical indicators in the logical expression that indicate a logical, as opposed to a concrete, numerical value. The numerical indicators may represent a number of endpoints in a communication network, such as a particular class, type, or set of endpoints. Continuing the particular dimension combination example above, the orthogonal policy reduction engine 1 10 may precompute the logical expression for the reduced orthogonal network policy set shown in Table 17 as the following, as shown in Table 18 below:

Table 18: Precompiled !ogical expression for example dimension combination

In the example above in Table 18, the numerical indicator N-rotai may represent the total number of endpoints in a communication network, the numerical indicator oestinationA may represent the number of endpoints matching the destination dimension value of intent-based network policy A, and the numerical indicator NsourceB may represent the number of endpoints matching the source dimension value of intent-based network policy B. Thus, for each dimension combination, the orthogonal policy reduction engine 1 10 may precompute an orthogonal network policy set 220, multiple reduced orthogonal network policy sets, and logical expressions with numerical indicators the multiple reduced orthogonal policy sets.

[0069] Once a set of intent-based network policies is received, the orthogonal policy reduction engine 1 10 may determine the specific dimension values of the intent-based policies, identify the particular dimension combination the received intent-based policies correspond to, and retrieve and populate (with concrete values) the orthogonal network policy set 220, reduced orthogonal network policy sets, the logical expressions, or any combination thereof. Accordingly, the orthogonal policy reduction engine 1 10 may compute the number of dataflows to match for or table entries to implement according to the concrete numerical values of the precomputed numerical indicators. Then, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set for implementation on a target switching device, for example based on replacing the precomputed numerical indicators with concrete values.

[0070] By precomputing the dimension combinations and precomputing, for each dimension combination, the orthogonal network policy set 220 (expressed with logical values), reduced orthogonal network policy sets (also expressed with logical values), and logical expressions with numerical indicators, the orthogonal policy reduction engine 1 10 may increase the speed and efficiency by which a particular reduced orthogonal network policy set is selected for implementation.

[0071] In some instances, the precomputed reduced orthogonal network policy sets may assume that a target switching device includes a wildcard processing capability for some or ail of the dimensions of a network policy. When the target switching device does not include a wildcard processing capability for a dimension in the precomputed reduced orthogonal network policy sets with a wildcard value, the orthogonal policy reduction engine 1 10 may determine not to use the precomputed logical expressions to compare the number of dataflows to match for or table entries to implement among the multiple reduced orthogonal network policy sets. [0072] As described above, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set to implement on a target switching device (e.g., transmit to a target switching device in a protocol-specific format) based on a characteristic of the target switching device itself. In doing so, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set that the target switching device may more efficiently or quickly effectuate, which may result in increased network throughput and increased communication speeds. Moreover, the reduced orthogonal network policy set selection features may support increased flexibility for different types of switching devices, allowing a SDN controller or other management entity to manage switching functions of a communication network with greater flexibility, efficiency, and effectiveness.

[0073] Figure 3 shows another example selection of a reduced orthogonal network policy set by the orthogonal policy reduction engine 1 10. In the example shown in Figure 3, the orthogonal policy reduction engine 1 10 selects a particular reduced orthogonal network policy set for transmission to a target switching device prior to policy translation. In doing so, the orthogonal policy reduction engine 1 10 may utilize previously-identified characteristics of the target switching device to select the particular reduced orthogonal network policy set for translation into a protocol-specific format and transmission to the target switching device.

[0074] The orthogonal policy reduction engine 1 10 may identify device characteristics of a target switching device in various ways. In some examples, the controller 210 receives capability communications from various switching devices managed by the controller 210. A capability communication may indicate particular switching characteristics provided by a switching device, including packet processing capabilities, wildcard processing capabilities (e.g., specific packet fields or match fields that the switching device can wildcard), or table capabilities, including a number of tables implemented by the target switching device, a table size of a table implemented by the target switching device, a number of actions supported by the table implemented by the target switching device, a particular action that the table implemented by the target switching device implements with increased efficiency, or any combination thereof. In the example shown in Figure 3, the switching device 201 sends a fable capability communication 310, which may indicate to the controller 210 a switching device characteristic of the switching device 201 (including any of the characteristics described above).

[0075] Using the previously-identified characteristic of a target switching device (e.g., the switching device 201 ), the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal policy network set from among multiple reduced orthogonal network policy sets, consistently as described herein in accounting for characteristics of the target switching device. That is, the orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set for translation and transmission that the target switching device can more efficiently process, whether based on a wildcard processing capability for a particular match field, a particular table or action that the target switching device can process more efficiently, or according to any other factor or combination of factors. As seen in Figure 3, the orthogonal policy reduction engine 1 10 selects the reduced orthogonal network policy set 221 for translation into the protocol-specific format by the translation engine 230 and for transmission of the protocol-specific messages 231 to the target switching device, which the switching device 201 may implement more efficiently or effectively than had the orthogonal policy reduction engine 1 10 selected the reduced orthogonal network policy set 222 for translation.

[0076] While the examples in Figures 2 and 3 above depict a single switching device, the controller 210 may manage communication networks with multiple switching devices with differing characteristics, capabilities, resource availability, network bandwidth, and the like. The orthogonal policy reduction engine 1 10 may select a reduced orthogonal network policy set to transmit to some or all of the managed switching devices, and perform such a selection individually for each different switching device. Some of these features are described in greater detail next in Figure 4. [0077] Figure 4 shows an example of reduced orthogonal network policy set selections for different switching devices. In Figure 4, the controller 210 manages the switching device 201 (continuing the examples from Figures 2 and 3), the switching device 402, and the switching device 403. The switching devices 201 , 402, and 403 may have differing switching characteristics, e.g. , differing table capabilities. Thus, a particular reduced orthogonal network policy set may be more efficiently effectuated on the switching device 201 , but not the switching devices 402 and 403 and a different reduced orthogonal network policy set may be more efficiently effectuated on the switching device 403, but not the switching devices 201 and 402. The orthogonal policy reduction engine 1 10 may select a particular reduced orthogonal network policy set to transmit to the switching devices 201 , 402, and 403 respectively, and based on the respective characteristics of the switching devices.

[0078] !n Figure 4, the orthogonal policy reduction engine 1 10 transmits the protocol-specific messages 231 to the switching device 201 (e.g., as described above, translated from the reduced orthogonal network policy set 221 ). For the switching device 403, the orthogonal policy selection engine 1 10 selects a different reduced orthogonal network policy set. That is, when the switching device 403 is the target switching device, the orthogonal policy reduction engine 1 10 may select the reduced orthogonal network policy set 222 for translation based on characteristics of the switching device 403, e.g., based on the switching device 403 including a wildcard processing capability for a match field with a wildcard value in the reduced orthogonal network policy set 222 but not including a wildcard processing capability for a different match field with a wildcard value in the reduced orthogonal network policy set 221 . !n this example, the orthogonal policy reduction engine 1 10 passes the reduced orthogonal network policy set 222 to the translation engine 230 for translation into the protocol-specific messages 232, which the controller 210 may transmit to the switching device 403 to implement.

[0079] Thus, the orthogonal policy reduction engine 1 10 may select different reduced orthogonal network policy sets for different switching devices, which may leverage the specific capabilities of the different switching devices. The reduced orthogonal network policy set selection may thus flexibly provide device-specific increases in processing efficiency as different switching devices vary in capability, hardware, and bandwidth.

[0080] Figure 5 shows an example of logic 500 that a system or device may implement to support reduced orthogonal network policy set selection. The system 100, for instance, may implement the logic 500 as hardware, executable instructions stored on a machine-readable medium, or as combinations thereof. In some examples, a system or network controller (e.g., the controller 210) implements the logic 500 via the orthogonal policy reduction engine 1 10, through which the system or network controller may perform the logic 500 as a method or process to select a particular reduced orthogonal network policy set for translation into a protocol-specific format for a target switching device.

[0081] The logic 500 includes accessing an orthogonal network policy set that represents a first intent-based network policy and a second intent-based network policy (502). The orthogonal network policy set may be derived by a conflict resolution engine 108, for example. The logic 500 also includes determining multiple reduced orthogonal network policy sets from the orthogonal network policy set (504). The multiple reduced orthogonal network policy sets may differ from one another, but each represent the first and second intent-based network policies. The logic 500 may further include selecting a particular reduced orthogonal network policy set among the multiple reduced orthogonal network policy sets to transmit to a target switching device in a protocol-specific format supported by the target switching device (506), including according to any of the selection features described herein.

[0082] In some examples, selecting the particular reduced orthogonal network policy set includes translating each of the multiple reduced orthogonal network policy sets into protocol-specific messages and determining that the protocol- specific messages translated from the particular reduced orthogonal network policy set has the least number of dataflows to match for from among the matching criteria translated from each of the multiple reduced orthogonal network policy sets. As another example, selecting of the particular reduced orthogonal network policy set may be based on a number of data values for a particular match field in the orthogonal network policy set,

[0083] As yet another example, the logic 500 may further include receiving an indication of a table capability from the target switching device and selecting the particular reduced orthogonal network policy based on the table capability. In this example, the table capability may include a wildcard processing capability for a particular match field in the orthogonal network policy set and selecting the particular reduced orthogonal network policy set may include determining that the particular reduced orthogonal network policy includes a wildcard value for the particular match field.

[0084] Regarding performance as a factor to account for in selecting the particular reduced orthogonal network policy set, the logic 500 may, in some examples, include selecting the particular reduced orthogonal network policy set even when a different reduced orthogonal network policy set translates into a lesser number of protocol-specific messages than the particular reduced orthogonal network policy set, but the target switching device includes a particular table that processes the particular reduced orthogonal network policy set at a greater speed than the different reduced orthogonal network policy set. In this example, the logic 500 may further include determining that the particular table of the target switching includes a wildcard processing capability for a particular match field of the particular reduced orthogonal network policy set but not a wildcard processing capability of a different match field of the different reduced orthogonal network policy set.

[0085] Figure 6 shows an example of a device 600 that supports reduced orthogonal network policy set selection. The device 600 may include a processing resource 610, which may take the form of a single or multiple processors. The processor(s) may include a central processing unit (CPU), microprocessor, or any hardware device suitable for executing instructions stored on a machine-readable medium, such as the machine-readable medium 620 shown in Figure 6. The machine-readable medium 620 may take the form of any non-iransitory electronic, magnetic, optical, or other physical storage device that stores executable instructions, such as the instructions 622, 624, 626, 628, and 630 shown in Figure 6. As such, the machine-readable medium 620 may be, for example, Random Access Memory (RAM) such as dynamic RAM (DRAM), flash memory, memristor memory, spin-transfer torque memory, an Electrically- Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disk, and the like.

[0086] The device 600 may execute instructions stored on the machine- readable medium 620 through the processing resource 610. Executing the instructions may cause the device 600 to perform any of the features described herein, including according to any features of the orthogonal network policy reduction engine 1 10. For example, execution of the instructions 622, 624, 626, 628, and 630 by the processing resource 610 may cause the device 600 to access an orthogonal network policy set that represents a first intent-based network policy and a second intent-based network policy (instructions 622); determine a first reduced orthogonal network policy set that combines a pair of orthogonal network policies from the orthogonal network policy set into a first reduced orthogonal network policy (instructions 624); determine a second reduced orthogonal network policy set that combines a different pair of orthogonal network policies from the orthogonal network policy set into a second reduced orthogonal network policy (instructions 626); select the first reduced orthogonal network policy set, and not the second reduced orthogonal network policy set, for transmission to a first target switching device based on a characteristic of the first target switching device (e.g. , for translation and transmission in a protocol- specific format) (instructions 628); and select the second reduced orthogonal network policy set, and not the first reduced orthogonal network policy set, for transmission to a second target switching device in the protocol-specific format based on a characteristic of the second target switching device (e.g., for translation and transmission in a protocol-specific format) (instructions 630).

[0087] In some examples, the first reduced orthogonal network policy may include a wildcard value for a particular match field of the first reduced orthogonal network policy and the Instructions 628 may be executable by the processing resource 610 to select the first reduced orthogonal network policy set based on the first target switching device including a wildcard processing capability for the particular match field.

[0088] The systems, methods, devices, and logic described above, including the conflict resolution engine 108, orthogonal policy reduction engine 1 10, translation engine 220, and controller 210, may be implemented in many different ways in many different combinations of hardware, logic, circuitry, and executable instructions stored on a machine-readable medium. For example, the conflict resolution engine 108, orthogonal policy reduction engine 1 10, translation engine 220, controller 210, or any combination thereof, may include circuitry in a controller, a microprocessor, or an application specific integrated circuit (ASIC), or may be implemented with discrete logic or components, or a combination of other types of analog or digital circuitry, combined on a single integrated circuit or distributed among multiple integrated circuits. A product, such as a computer program product, may include a storage medium and machine readable instructions stored on the medium, which when executed in an endpoint, computer system, or other device, cause the device to perform operations according to any of the description above, including according to any features of the conflict resolution engine 108, orthogonal policy reduction engine 1 10, translation engine 220, controller 210, or any combination thereof.

[0089] The processing capability of the systems, devices, and engines described herein, including the conflict resolution engine 108, orthogonal policy reduction engine 1 10, translation engine 220, controller 210, or any combination thereof, may be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may implemented in many ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms. Programs may be parts (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library (e.g., a shared library).

[0090] While various examples have been described above, many more implementations are possible.