WO2017138952A1

WO2017138952A1 - Generating protocol-specific instructions for ambiguous forwarding behavior

Info

Publication number: WO2017138952A1
Application number: PCT/US2016/017700
Authority: WO
Inventors: Shaun Wackerly; Duane Edward Mentze
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2016-02-12
Filing date: 2016-02-12
Publication date: 2017-08-17

Abstract

Example implementations relate to generating protocol-specific instructions for ambiguous forwarding behavior. In an example, a method includes generating protocol-specific instructions to implement a plurality of policies and identifying a subset of protocol-specific instructions within the protocol-specific instructions that specify ambiguous forwarding behavior. For each protocol-specific instruction in the subset, the method determines unambiguous forwarding behavior associated with the respective protocol-specific instruction using a forwarding engine, and generates additional protocol-specific instructions to implement the unambiguous forwarding behavior. The unambiguous forwarding behavior can be determined using a forwarding engine of an SDN controller.

Description

GENERATING PROTOCOL-SPECIFIC INSTRUCTIONS FOR AMBIGUOUS

FORWARDING BEHAVIOR

Background

[0001 ] Networks can include a plurality of resources connected by

communication links, and can be used to connect people, provide services (e.g., internally and/or externally via the Internet and/or intranet), and/or organize information, among other activities associated with an entity. An example network can include a software-defined network (SDN).

Brief Description of the Drawings

[0002] Figure 1 a illustrates a flow chart of an example method for generating protocol-specific instructions, according to an example.

[0003] Figure 1 b illustrates a flow chart of an example method for generating protocol-specific instructions, according to an example.

[0004] Figure 2a illustrates an example environment with devices for generating and implementing protocol-specific instructions, according to an example.

[0005] Figure 2b illustrates an example of generating unambiguous protocol- specific instructions from an ambiguous protocol-specific instruction, according to an example.

[0006] Figure 3 illustrates an example computer for generating protocol- specific instructions, according to an example. Detailed Description

[0008] Networks can include a plurality of resources such as network devices and databases to connect endpoint devices via communication links.

Networks can be used to connect people, provide services (e.g., internally and/or externally via the Internet and/or intranet), and organize information, among other activities. Examples of endpoint devices include computers, tablets, phones, printers, cameras, door locks, HVAC controller, among other endpoint devices capable of operating on a network. An example network can include a software- defined network (SDN).

[0009] SDN controllers can direct network devices such as servers, SDN- capable switches and routers, and other computing devices, on how to forward network traffic. SDN applications may execute on or interface with the SDN controller to provide input to the SDN controller and influence how the SDN controller forwards traffic. SDN applications might provide services on the network, including observing network traffic and conditions and taking one or more actions as a result. For instance, one application may look for infected hosts on the network, while another application may attempt to optimize voice over internet protocol (VoIP) calls on the network. Both applications may run on the same SDN controller, and use the SDN controller to communicate down to network devices in a protocol-specific format, such as according to the OpenFlow protocol.

[0010] When applications within a network, such as an SDN, want to tell the same devices in the network what to do, a conflict may arise between the instructions of one application and the instructions of another application with respect to the same endpoint device. In such instances, the SDN controller may be unable to determine which actions from which applications should be executed, and/or if the instructions of both applications should be executed.

[001 1 ] Instructions from applications may be characterized as network policies to be applied to the network. Network policies from different applications may be compiled together to yield a cohesive set of non-overlapping policies to be applied to the network. This set of non-overlapping policies are referred to herein as "orthogonal policies". An orthogonal policy is a policy generated from one or more original/source policies (e.g., policies that are received from an application) that does not conflict with any other orthogonal policy in a set of orthogonal policies. This means that all policies from the source set of policies to be applied to any single packet in the network would be implemented by a single orthogonal policy. These orthogonal policies may then be transformed into protocol-specific instructions (i.e., instructions in a protocol understood and implementable by a network device) for implementation by network devices. PCT Application No.

US2015/015122, entitled "Network Policy Conflict Detection and Resolution" and filed on February 10, 2015, PCT Application No. US2015022074, entitled

"Implementing Policy Instructions in Multiple Tables" and filed on March 23, 2015, and PCT Application No. US20155/022068, entitled "Compiling Network Policies" and filed on March 23, 2015, each of which are hereby incorporated by reference, describe in further detail how policies may be compiled and then implemented in network devices as protocol-specific instructions.

[0012] In some cases, policies may specify unambiguous forwarding behavior for a given set of network traffic. For example, a policy may specify that matching flows be dropped, forwarded to a specific device for application of a network service (e.g., deep packet inspection, load balancing, etc.), quarantined, or forwarded to a specific destination device. In other cases, a policy may specify ambiguous forwarding behavior. For example, a policy may specify that matching flows be handled by a native forwarding function of the network device or that matching flows be forwarded to the SDN controller for determination of a

forwarding decision for the flow. Such forwarding behavior is referred to as

"ambiguous" herein because the ultimate forwarding decision is not clear on its face and instead relies on input from the native forwarding function of the network device or the forwarding engine of the SDN controller. To be clear, the forwarding behavior may eventually become unambiguous after the network device or SDN controller determines the appropriate forwarding action, but it is ambiguous until that point. [0013] Example implementations relate to generating protocol-specific instructions for ambiguous forwarding behavior. In an example, a method includes generating protocol-specific instructions to implement a plurality of policies and identifying a subset of protocol-specific instructions within the protocol-specific instructions that specify ambiguous forwarding behavior. For each protocol- specific instruction in the subset, the method determines unambiguous forwarding behavior associated with the respective protocol-specific instruction and generates additional protocol-specific instructions to implement the unambiguous forwarding behavior. In an example, the unambiguous forwarding behavior can be determined using a forwarding engine of an SDN controller. The method may then include instructing a network device to create flow entries in a flow table corresponding to (1 ) the protocol-specific instructions except the subset of protocol-specific instructions, and (2) the additional protocol-specific instructions (which were created based on the subset of protocol-specific instructions).

[0014] As a result of this technique, the generated protocol-specific instructions may specify all forwarding behavior for the network device, rather than requiring the network device to obtain input on forwarding behavior from a forwarding engine, such as a forwarding engine of an SDN controller or a non-SDN forwarding pipeline of the network device. This technique also allows an SDN controller to override the forwarding behavior that would otherwise be dictated by a non-SDN forwarding pipeline of the network device, if desired. Additionally, in the case where the network device does not have a non-SDN forwarding pipeline, this technique can ensure that protocol-specific instructions that require reliance on a non-SDN forwarding pipeline are not forwarded to the network device and are instead converted into explicit, unambiguous protocol-specific instructions that can be implemented by the network device.

[0015] FIGS. 1 a-b illustrate methods to generate protocol-specific

instructions, according to an example. Methods 100 and 120 may be performed by a computing device, computer, server, or the like, such as SDN controller 210 or computer 310. Computer-readable instructions for implementing methods 100 and 120 may be stored on a computer readable storage medium. These instructions as stored on the medium are referred to herein as "modules" and may be executed by a computer.

[0016] Methods 100 and 120 will be described here relative to environment 200 of FIG. 2. Environment 200 may include SDN controller 210 and network devices 220, 230. SDN controller 210 may be a computer configured to manage the control plane of a software defined network. SDN controller 210 may

include/be implemented by one or multiple computers. Network devices 220, 230 may be network infrastructure devices, such as a switch or router, of the software defined network. The network devices 220, 230 may thus be part of the data plane of the software defined network, which may include multiple network devices.

[0017] SDN controller 210 may communicate with network devices 220, 230 via an SDN protocol, such as the OpenFlow protocol. SDN controller 210 may program rules in the flow tables 222, 232 of network devices 220, 230. Network devices 220, 230 may use these rules to process and forward network traffic. Flow tables 222, 232 may be implemented by multiple hardware elements (e.g., Tertiary Content Addressable Memory (TCAM), Application Specific Integrated Circuit (ASIC)) within network devices 220, 230, and each flow table may include multiple tables. While both network devices 220, 230 have a flow table, which enables packet forwarding in accordance with the OpenFlow protocol, only network device 230 has a non-SDN forwarding pipeline 234. Network device 230 can be referred to as a hybrid SDN device because it supports both SDN forwarding and traditional forwarding (which may be in accordance with other network protocols). In contrast, network device 220 can be referred to as a pure SDN device because it supports only SDN forwarding (and thus relies on SDN controller 210 to configure its forwarding function). Additionally, a variety of SDN applications may run on or interface with SDN controller 210. These SDN applications may be part of the application plane of the software defined network.

[0018] SDN controller 210 and network devices 220, 230 may include one or more controllers and one or more machine-readable storage media. A controller may include a processor and a memory for implementing machine readable instructions. The processor may include at least one central processing unit (CPU), at least one semiconductor-based microprocessor, at least one digital signal processor (DSP) such as a digital image processing unit, other hardware devices or processing elements suitable to retrieve and execute instructions stored in memory, or combinations thereof. The processor can include single or multiple cores on a chip, multiple cores across multiple chips, multiple cores across multiple devices, or combinations thereof. The processor may fetch, decode, and execute instructions from memory to perform various functions. As an alternative or in addition to retrieving and executing instructions, the processor may include at least one integrated circuit (IC), other control logic, other electronic circuits, or

combinations thereof that include a number of electronic components for performing various tasks or functions.

[0019] The controller may include memory, such as a machine-readable storage medium. The machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, the machine-readable storage medium may comprise, for example, various Random Access Memory (RAM), Read Only Memory (ROM), flash memory, and combinations thereof. For example, the machine-readable medium may include a Non-Volatile Random Access Memory (NVRAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a NAND flash memory, and the like. Further, the machine- readable storage medium can be computer-readable and non-transitory.

Additionally, SDN controller 210 and network devices 220, 230 may include one or more machine-readable storage media separate from the one or more controllers, as well as additional hardware elements, such as TCAMs and ASICs.

[0020] Turning to FIG 1 a, method 100 may be used to generate protocol- specific instructions, according to an example. At 101 , instruction module 212 may generate protocol-specific instructions to implement a plurality of network policies. The protocol-specific instructions may be instructions in accordance with a protocol supported by network devices 220, 230, such as the OpenFlow protocol. The protocol-specific instructions may thus be instructions suitable for the network devices 220, 230 to implement the policies when processing and forwarding traffic. In particular, the protocol-specific instructions may be instructions for creating or modifying flow entries in flow tables 222, 232, where the flow tables are consulted by the respective network devices to determine how to process and forward a received packet. Generation of protocol-specific instructions, including precursor steps such as grouping the network policies and compiling them into orthogonal polices, is described in more detail in PCT Application No. US2015/015122, entitled "Network Policy Conflict Detection and Resolution", PCT Application No. US2015022074, entitled "Implementing Policy Instructions in Multiple Tables", and PCT Application No. US20155/022068, entitled "Compiling Network Policies".

[0021 ] At 102, identification module 214 may identify a subset of protocol- specific instructions within the generated protocol-specific instructions that specify ambiguous forwarding behavior. In some cases, policies may specify

unambiguous forwarding behavior for a given set of network traffic. For example, a policy may specify that matching flows be dropped, forwarded to a specific device for application of a network service (e.g., deep packet inspection, load balancing, etc.), quarantined, or forwarded to a specific destination device. However, in other cases a policy may specify ambiguous forwarding behavior. For example, a policy may specify that matching flows be handled by a native forwarding function of the network device or that matching flows be forwarded to the SDN controller for determination of a forwarding decision for the flow. Such forwarding behavior is ambiguous because the ultimate forwarding decision is not clear from the instruction itself and instead relies on input from the native forwarding function of the network device or the forwarding engine of the SDN controller. Furthermore, the ultimate forwarding decision may depend on one or more parameters associated with the packet, such as its source address or destination address. Although the forwarding behavior may eventually become unambiguous after the network device or SDN controller determines the appropriate forwarding action, it is considered ambiguous until that point.

[0022] As a result, some of the generated protocol-specific instructions may specify ambiguous forwarding behavior. It is these instructions that are identified by identification module 214. Ambiguous forwarding behavior may be identified in various ways. At a high-level, if the ultimate forwarding decision depends on input from another device, whether it be a forwarding engine of an SDN controller (e.g., forwarding engine 216) or a non-SDN forwarding function of a network device (e.g., non-SDN forwarding pipeline 234), then the forwarding behavior may be identified as ambiguous. At a lower level, identification module 214 can identify whether a given protocol-specific instruction relies on input from another entity by examining the action associated with the instruction.

[0023] In the OpenFlow protocol, the protocol-specific instructions (which may be in the form of flow table modification messages) will have a match field and an action field (among others fields). The match field provides parameters for matching network packets to the flow table rule. The match parameters may be a source or destination address, for example. The action field specifies what do with a matching packet, including which port in the network device to forward the packet (referred to as the destination port). By examining the destination port specified in the action field of the instruction, identification instructions can determine whether the instruction relies on an SDN controller or non-SDN forwarding pipeline of the network device. If the instruction relies on the SDN controller, the destination port will be a port dedicated to communication between the network device and the controller (referred to as a controller port). If the instruction relies on a non-SDN forwarding pipeline, the destination port will be a reserved port called "NORMAL", which is a reserved port according to the OpenFlow protocol that causes the network device to send any matching packets through the non-SDN forwarding pipeline of the network device.

[0024] In the case where an instruction relies on a non-SDN forwarding pipeline, it may be desirable to allow the instruction to be forwarded to the network device as is (with the ambiguous forwarding behavior) rather than adding the instruction to the subset for the purpose of generating non-ambiguous forwarding behavior. For example, this may be deemed more efficient, assuming that the non- SDN forwarding pipelines of the network devices in the network are trusted. In some cases, it may be desirable to trust the non-SDN forwarding pipeline of certain network devices while not trusting such a pipeline in other network devices. For example, certain classes of network devices may be trusted (e.g., devices provided by a particular company) while others are not. In such a case, a blacklist may be created for the untrusted devices, and the protocol-specific instructions that both rely on a non-SDN forwarding pipeline and are destined for such devices on the blacklist may be flagged. This will enable another forwarding engine, such as the forwarding engine of the controller, to make the ultimate forwarding decisions.

Other criteria that could be considered are resource utilization of the device (e.g., CPU utilization percentage, hardware table utilization) or performance capabilities of the device. For example, identification module 214 could be configured to consider one or more of these criteria when deciding which protocol-specific instructions to add to the subset.

[0025] In another example, block 101 of method 100 could be performed such that any generated protocol-specific instruction that relies on another entity for the ultimate forwarding decision (e.g., whether it be a forwarding engine of a SDN controller or a non-SDN forwarding pipeline of a network device) is provided with a common indicator in the action field that signals such reliance. The indicator could be forwarding to the NORMAL port, forwarding to the controller port, or some other indicator such as "Allow". Then, block 102 could identify all such instructions based on the common indicator. Method 120 depicted in FIG. 1 b illustrates this case. At 121 , protocol-specific instructions are identified where an associated action indicates that a matching packet should be forwarded to the NORMAL port (of course, a different indicator could be used, as described above). At 122, for each identified instruction, method 120 determines whether a network device the instruction is destined for has a non-SDN forwarding capability (e.g., non-SDN forwarding pipeline 234), and includes the instruction in the subset only if the network device does not have a non-SDN forwarding capability. If the network device has a non-SDN forwarding capability, the instruction can be left as is such that the network device will make the ultimate forwarding decision using its non- SDN forwarding capability. Since the action already specifies the NORMAL port, the instruction need not be changed. However, if a different indicator were used, the action would need to be updated to indicate forwarding to the non-SDN forwarding pipeline through the NORMAL port.

[0026] At 103, method 100 may determine unambiguous forwarding behavior for each protocol-specific instruction identified in 102 and added to the subset. The unambiguous forwarding behavior may be determined by a forwarding engine, such as forwarding engine 216 of SDN controller 210. The forwarding engine 216 may be a module configured to determine forwarding paths through a network according to the topology of the network and in accordance with various network protocols implemented by the network. The forwarding engine 216 may generate multiple forwarding decisions for a given protocol-specific instruction in the subset. These multiple forwarding decisions constitute the determined unambiguous forwarding behavior for the given protocol-specific instruction.

Instruction module 212 may then generate additional protocol-specific instructions based on the determined unambiguous behavior.

[0027] FIG. 2b illustrates an example of generating unambiguous forwarding behavior from ambiguous forwarding behavior 242 specified by a protocol-specific instruction. The unambiguous forwarding behavior is translated into additional protocol-specific instructions 244, 246, 248. In particular, protocol-specific instruction 242 is generated by instruction module 212 and specifies that packets matching type=TCP and source port=60 be sent to the NORMAL port. Instruction 242 may be flagged by identification module as specifying ambiguous forwarding behavior. Forwarding engine 216 then determines that there are three possible forwarding decisions associated with instruction 216, each result depending on the Media Access Control address of the source device and resulting in a different forwarding decision (i.e., sending a matching packet to port 5, 6, or 8). Instruction module 212 then generates protocol-specific instructions 244, 246, 248 to implement the forwarding decisions determined by the forwarding engine 216. These protocol-specific instructions may then be forwarded to the appropriate network device instead of ambiguous protocol-specific instruction 216.

[0028] Instruction generation module 218 may then send the protocol- specific instructions (e.g., as flow table modification messages) to the appropriate network devices (e.g., network device 220, 230). In particular, module 218 may send (1 ) the protocol-specific instructions except the subset of protocol-specific instructions, and (2) the additional protocol-specific instructions to the appropriate network devices. The network devices may then add flow table entries to their flow tables in accordance with the received instructions.

[0029] In an example, a threshold could be applied to block 103. For example, SDN controller 210 could be configured to generate forwarding decisions using forwarding engine 216 only up to a threshold. The threshold could take many forms, such as a specific value (e.g., only generate up to 10 entries per instruction) or a percentage (e.g., generate entries per instruction may not exceed 5% of the network device's flow table). Where the threshold is passed, the associated protocol-specific instruction could be completely removed from the set of protocol-specific instructions to be communicated to the network device. In other words, neither the original protocol-specific instruction that was identified for the subset nor any additional protocol-specific instructions generated based on the instruction would be communicated to the network device. To accommodate this condition, a default protocol-specific instruction could be created for the network device to be stored as the last, lowest priority entry in the device's flow table that matches all packets and causes the device to forward any matched packets to the SDN controller for handling.

[0030] FIG. 3 illustrates a computer to compile and implement policies, according to an example. Computer 310 may be part of SDN controller 210. The computer may include one or more controllers and one or more machine-readable storage media, as described with respect to SDN controller 210, for example.

[0031 ] Processor 320 may be at least one central processing unit (CPU), at least one semiconductor-based microprocessor, other hardware devices or processing elements suitable to retrieve and execute instructions stored in machine-readable storage medium 330, or combinations thereof. Processor 320 can include single or multiple cores on a chip, multiple cores across multiple chips, multiple cores across multiple devices, or combinations thereof. Processor 320 may fetch, decode, and execute instructions 332-338 among others, to implement various processing. As an alternative or in addition to retrieving and executing instructions, processor 320 may include at least one integrated circuit (IC), other control logic, other electronic circuits, or combinations thereof that include a number of electronic components for performing the functionality of instructions 332-338. Accordingly, processor 320 may be implemented across multiple processing units, and instructions 332-338 may be implemented by different processing units in different areas of computer 310.

[0032] Machine-readable storage medium 330 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, the machine-readable storage medium may comprise, for example, various Random Access Memory (RAM), Read Only Memory (ROM), flash memory, and combinations thereof. For example, the machine-readable medium may include a Non-Volatile Random Access Memory (NVRAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a NAND flash memory, and the like. Further, the machine- readable storage medium 330 can be computer-readable and non-transitory.

Machine-readable storage medium 330 may be encoded with a series of executable instructions for managing processing elements.

[0033] The instructions 332-338 when executed by processor 320 (e.g., via one processing element or multiple processing elements of the processor) can cause processor 320 to perform processes, for example, methods 100 and 120, and/or variations and portions thereof. Instructions 332-338 will now be briefly described, which description should be read in light of the description of methods 100, 120 and environment 200 above.

[0034] Computer 310 may generate protocol-specific instructions. For example, generating instructions 332 may cause processor 320 to generate protocol-specific instructions to implement a plurality of policies. Identifying instructions 334 may cause processor 320 to identify a subset of protocol-specific instructions within the protocol-specific instructions that specify ambiguous forwarding behavior. For each identified protocol-specific instruction in the subset, determining instructions 336 may cause processor 320 to determine unambiguous forwarding behavior associated with the respective protocol-specific instruction using a forwarding engine. The forwarding engine may be a forwarding engine of an SDN controller, such as forwarding engine 216. Generating instructions 332 may then cause processor 320 to generate additional protocol-specific instructions to implement the determined unambiguous forwarding behavior. Instruction instructions 338 may cause processor 320 to instruct a network device to create flow entries in a flow table corresponding to (1 ) the protocol-specific instructions except the subset of protocol-specific instructions, and (2) the additional protocol- specific instructions.

[0035] In the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how a number of examples of the disclosure can be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples can be used and that process, electrical, and/or structural changes can be made without departing from the scope of the present disclosure.

[0036] As used herein, "logic" is an alternative or additional processing resource to perform a particular action and/or function, etc., described herein, which includes hardware, e.g., various forms of transistor logic, application specific integrated circuits (ASICs), etc., as opposed to computer executable instructions, e.g., software firmware, etc., stored in memory and executable by a processor. Further, as used herein, "a" or "a number of something can refer to one or more such things. For example, "a number of widgets" can refer to one or more widgets. Also, as used herein, "a plurality of" something can refer to more than one of such things.

[0037] The above specification, examples and data provide a description of the method and applications, and use of the system and method of the present disclosure. Since many examples can be made without departing from the spirit and scope of the systems and methods of the present disclosure, this specification merely sets forth some of the many possible embodiments, configurations, and implementations.

Claims

What is claimed is:

1 . A method for generating protocol-specific instructions to implement network policies, comprising, by a processor:

generating protocol-specific instructions to implement a plurality of network policies;

identifying a subset of protocol-specific instructions within the protocol- specific instructions that specify ambiguous forwarding behavior; and

for each protocol-specific instruction in the subset:

determining unambiguous forwarding behavior associated with the respective protocol-specific instruction using a forwarding engine; and

generating additional protocol-specific instructions to implement the unambiguous forwarding behavior.

2. The method of claim 1 , wherein the unambiguous forwarding behavior corresponds to multiple different forwarding decisions, and the additional protocol- specific instructions correspond to each of the multiple different forwarding decisions.

3. The method of claim 1 , wherein ambiguous forwarding behavior is forwarding behavior that may result in a different forwarding decision depending on one or more parameters.

4. The method of claim 1 , wherein ambiguous forwarding behavior is identified where the protocol-specific instruction relies on a software defined network (SDN) controller to dictate the forwarding decision.

5. The method of claim 1 , wherein ambiguous forwarding behavior is identified where the protocol-specific instruction relies on a non-SDN forwarding pipeline of a network device to dictate the forwarding decision.

6. The method of claim 5, wherein ambiguous forwarding behavior is identified where an action associated with the protocol-specific instruction indicates that a matching packet should be forwarded to the NORMAL port, wherein the protocol- specific instruction is according to the OpenFlow protocol.

7. The method of claim 5, wherein the protocol-specific instruction is included in the subset of protocol-specific instructions only if a type of the network device it is destined for is on a blacklist.

8. The method of claim 1 , further comprising instructing a network device to create flow entries in a flow table corresponding to (1 ) the protocol-specific instructions except the subset of protocol-specific instructions, and (2) the additional protocol-specific instructions.

9. The method of claim 8, wherein the processor is part of a controller in a software defined network, the network device is a SDN-enabled switch, and the controller communicates with the network device in accordance with the OpenFlow protocol.

10. The method of claim 1 , wherein the forwarding engine is a forwarding engine on a SDN controller, and the forwarding engine generates one or more unambiguous forwarding decisions for each respective protocol-specific instruction.

1 1 . The method of claim 10, wherein the SDN controller is to generate forwarding decisions only up to a threshold, and if the threshold is passed, no additional forwarding decisions are generated and no additional protocol-specific instructions are generated for the respective protocol-specific instruction.

12. The method of claim 1 , wherein identifying a subset of protocol-specific instructions within the protocol-specific instructions that specify ambiguous forwarding behavior comprises:

identifying protocol-specific instructions where an action associated with the protocol-specific instruction indicates that a matching packet should be forwarded to the NORMAL port; and

for each identified protocol-specific instruction,

determining whether a network device the protocol-specific instruction is destined for has a non-SDN forwarding capability; and

including the protocol-specific instruction in the subset only if the network device does not have a non-SDN forwarding capability.

13. A controller in a software defined network (SDN), comprising:

an instruction generation module to generate protocol-specific instructions to implement a plurality of policies;

an identification module to identify a subset of protocol-specific instructions within the protocol-specific instructions that specify ambiguous forwarding behavior;

a forwarding engine to determine unambiguous forwarding behavior for the subset of protocol-specific instructions,

the instruction generation module to generate additional protocol-specific instructions to implement the unambiguous forwarding behavior.

14. The controller of claim 13, further comprising an instruction module to instruct a network device to add flow entries to a flow table in accordance with (1 ) the protocol-specific instructions except the subset of protocol-specific instructions, and (2) the additional protocol-specific instructions.

15. The controller of claim 14, wherein the forwarding engine is to determine unambiguous forwarding behavior for a given protocol-specific instruction by calculating multiple forwarding decisions up to a threshold, the multiple forwarding decisions constituting the unambiguous forwarding behavior, and

wherein if the threshold is reached, the instruction generation module does not generate any additional protocol-specific instructions corresponding to the given protocol-specific instruction.

16. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor of an SDN controller, cause the processor to: generate protocol-specific instructions to implement a plurality of policies; identify a subset of protocol-specific instructions within the protocol-specific instructions that specify ambiguous forwarding behavior;

for each protocol-specific instruction in the subset:

determine unambiguous forwarding behavior associated with the respective protocol-specific instruction using a forwarding engine; and

generate additional protocol-specific instructions to implement the unambiguous forwarding behavior; and

instruct a network device to create flow entries in a flow table corresponding to (1 ) the protocol-specific instructions except the subset of protocol-specific instructions, and (2) the additional protocol-specific instructions.