TO ADJUST FORWARDING BEHAVIOR OF PACKETS

TECHNICAL FIELD

[0001] The present disclosure relates to systems and methods for assessing the viability of a communication link in a software defined network (“SDN”). More particularly, but not exclusively, the techniques disclosed in the present application may be configured to analyze data flows and traffic metrics in an SDN to adapt the forwarding behavior of information packets based on such analysis.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Non-limiting and non-exhaustive embodiments of the disclosure are described, including various embodiments of the disclosure, with reference to the figures, in which:

[0003] Figure 1 illustrates a simplified one-line diagram of an electric power transmission and distribution system in which a plurality of communication devices may facilitate communication in an SDN consistent with embodiments of the present disclosure.

[0004] Figure 2A illustrates a conceptual representation of an SDN including a control plane, a data plane, and a plurality of data-consuming and data-producing devices that may be deployed in an electric power transmission and distribution system consistent with embodiments of the present disclosure.

[0005] Figure 2B illustrates a conceptual representation of the SDN system of

Figure 2A configured to redirect a data flow based on a reverse metering threshold consistent with embodiments of the present disclosure.

[0006] Figure 3 illustrates a conceptual representation of a system configured to implement a redundant communication path that may be adapted based on an analysis of traffic flows consistent with embodiments of the present disclosure.

[0007] Figure 4 illustrates a flowchart of a method for processing an information packet in a SDN consistent with the embodiments in the present disclosure.

[0008] Figure 5 illustrates a block diagram of a system including an SDN controller, a SDN, and a plurality of communication devices consistent with embodiments of the present disclosure. DETAILED DESCRIPTION

[0009] Modern electric power distribution and transmission systems may incorporate a variety of communication technologies that may be used to monitor and protect the system. The communication equipment may be configured and utilized to facilitate an exchange of data among a variety of devices that monitor conditions on the power system and implement control actions to maintain the stability of the power system.

The communication networks carry information necessary for the proper assessment of power system conditions and for implementing control actions based on such conditions. In addition, such messages may be subject to time constraints because of the potential for rapid changes in conditions in an electric power distribution and transmission system.

[0010] Some electric power transmission and distribution systems may incorporate software defined network (“SDN”) networking technologies that utilize a controller to configure and monitor network traffic on the network. SDN networking technologies offer a variety of advantages that may be advantageous in electric power systems, such as deny-by-default security, deterministic transit times, latency control, symmetric transport capabilities, redundancy, fail-over planning, etc.).

[0011] SDN networking technologies allow programmatic changes to a network and allow an entire communication network to be managed as a single asset, which may simply the management of the network, and enable continuous monitoring of the network. In an SDN, the control plane, which forwards the traffic, is separated from the data plane, which performs the forwarding of the traffic in the network. In contrast, in conventional networking devices the control plane and the data plane are typically implemented in a single device (i.e. , a network router or switch). A conventional networking device may generate an address table or database to process

communications.

[0012] The control plane may be used to achieve the optimal usage of network resources by creating specific data flows through the communication network. A data flow, as the term is used herein, refers to a set of parameters used to match and take action based on network packet contents. Data flows may permit specific paths based on a variety of criteria that offer significant control and precision to operators of the network. In contrast, in large traditional networks, trying to match a network-discovered path with an application desired data path may be a challenging task involving changing configurations in many devices. To compound this problem, the management interfaces and feature sets used on many devices are not standardized. Still further, network administrators often need to reconfigure the network to avoid loops, gain route convergence speed, and prioritize a certain class of applications.

[0013] Significant complexity in managing a traditional network in the context of an electric power transmission and distribution system arises from the fact that each network device (e.g., a switch or router) has control logic and data-forwarding logic integrated together. For example, in a traditional network appliances, dynamic control plane protocols such as Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Spanning Tree Protocol (STP), Address Resolution Protocol (ARP), and the like may be used to determine how a packet should be forwarded. The paths determined by the routing protocol are encoded in address tables, which are then used to forward packets. Similarly, in a Layer 2 device such as a network bridge (or network switch), configuration parameters and/or Spanning Tree Algorithm (STA) constitute the control logic that determines the path of the packets. Thus, the control plane in a traditional network is distributed in the switching fabric (network devices).

[0014] In an SDN, a controller embodies the control plane and determines how packets (or frames) should flow (or be forwarded) in the network. The controller communicates this information to the network devices, which constitute the data plane, by setting their forwarding tables. This enables centralized configuration and

management of a network. As such, the data plane in an SDN may consist of relatively simple packet-forwarding devices with a communications interface to the controller to receive forwarding decisions. In addition to simplifying management of a network, an SDN architecture may also enable monitoring and troubleshooting features that may be beneficial for use in an electric power distribution system, including but not limited to: mirroring a data-selected flow rather than mirroring a port; alarming on bandwidth near saturation; providing metrics (e.g., counters and meters for quality of service, packet counts, errors, drops, or overruns, etc.) for a specified flow; and/or permitting

monitoring of specified applications rather than monitoring based on VLANs or MAC addresses.

[0015] An SDN may operates on and control packet sequences by a variety of techniques, including meter entries, flow entries, and group entries. Flow entries define how a switch in the data plane is to handle packets. The flow entry operates on a packet when there is a match between some criteria(s) of the packet and the flow entry’s match fields. Meter entries are attached to flow entries and enable ingress rate limiting. Each meter band may specify the rate at which the band will be activated for processing a data flow. Group entries may be utilized to enhance forwarding behavior of the data flows and to apply Quality of Service (QoS) policies to the packet. Group entries contain a list of“action buckets,” each of which may detail a set of actions for packets that fall into the action bucket. In connection with various embodiments, the phrase“reverse metering” may be used to describe the concept of using meter bands associated with meter entry attributes to alter forwarding behavior of a data flow. In various embodiments consistent with the present disclosure, the OpenFlow protocol may be utilized to control communication devices in a data plane of a SDN.

[0016] A“fast failover group” type is a group type designed to detect and overcome port failures in an SDN. In addition to action buckets, the fast failover group has a watch port and/or a watch group as a parameter that monitors the“liveliness” of the indicated port or group. Only one bucket can be used at a time, and the bucket can only be used if liveness conditions are met

[0017] The present disclosure enhances the forwarding capabilities of an SDN device by increasing the available options for making failover decisions. Using the systems and methods disclosed herein, a SDN network may be configured to change the forwarding behavior of a packet based on traffic activity instead of, or in addition to making failover decisions based solely on a port link state. In various situations, some of which may involve operator error, traffic may be misdirected, and may not reach its intended destination; however, the port link state may remain“up.” By incorporating an analysis of the data traffic associated with a particular data flow, and utilizing such information to control the port link state, the system may both be able to failover based on additional criteria. Detection of a condition in which traffic fails to satisfy a threshold improves reliability in the system by leveraging attributes of an SDN system.

[0018] In some embodiments, systems and methods consistent with the present disclosure may define a new flow attribute to be used for condition-based actions. In various embodiments, the new meter behavior may be based on traffic metrics and/or may be based on a watch port in a fast failover group. Accordingly, the forwarding behavior of a communication device may be changed based on the meter value and/or the port link state of a watch port. In one specific embodiment, a threshold value from a meter may be used to specify the port link state of a watch port. In such an

embodiment, if the traffic count is less than a specific threshold, then the flow

forwarding action may change. Alternatively, if the configured count exceeds the configured count, the switch may return to original forwarding behavior

[0019] Multiple groups within an SDN may use a single watch port as a trigger, even if the watch port is associated with another device. This may enable data flows to influence themselves or other flows through the SDN or through the same switch. In some embodiments, changes to data flows based on a reverse meter may be

automatically reversed once a network burden meets one or more thresholds. In other embodiments, the changes to the flows may remain in in effect until reset by a network administrator.

[0020] Systems and methods disclosed herein may utilize various features available in an SDN to monitor physical and/or logical communication links in the network and to take action based on physical changes (e.g., disconnection of a physical link) or logical changes (e.g., a change in routing) that result in changes to a data flow. As the term is used here, a logical communication link refers to a data communication channel between two or more communicating hosts in a network. A logical communication link may encompass any number of physical links and forwarding elements used to make a connection between the communicating hosts. The physical links and forwarding elements used to create a specific communication path embodying a logical

communication link may be adjusted and changed based on conditions in the network. For example, where an element in a specific communication path fails (e.g., a communication link fails or a forwarding device fails), a failover path may be activated so that the logical communication link is maintained. Information may be gathered by monitoring the physical and/or logical communication link to identify and associate information that may be utilized to assess a likelihood of a failure, to generate

information about the precursors to a failure, and to identify the root cause of a failure. Such information may then be used to generate reliable failover paths for data flows within the SDN.

[0021] Embodiments consistent with the present disclosure may be utilized in a variety of communication devices. A communication device, as the term is used herein, is any device that is capable of accepting and forwarding data traffic in a data communication network. In addition to the functionality of accepting and forwarding data traffic, communication devices may also perform a wide variety of other functions and may range from simple to complex devices.

[0022] The embodiments of the disclosure will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout. It will be readily understood that the components of the disclosed embodiments, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the systems and methods of the disclosure is not intended to limit the scope of the disclosure, as claimed, but is merely representative of possible

embodiments of the disclosure. In addition, the steps of a method do not necessarily need to be executed in any specific order, or even sequentially, nor need the steps be executed only once, unless otherwise specified.

[0023] In some cases, well-known features, structures, or operations are not shown or described in detail. Furthermore, the described features, structures, or operations may be combined in any suitable manner in one or more embodiments. It will also be readily understood that the components of the embodiments as generally described and illustrated in the figures herein could be arranged and designed in a wide variety of different configurations.

[0024] Several aspects of the embodiments described may be implemented as software modules or components. As used herein, a software module or component may include any type of computer instruction or computer-executable code located within a memory device and/or transmitted as electronic signals over a system bus or wired or wireless network. A software module or component may, for instance, comprise one or more physical or logical blocks of computer instructions, which may be organized as a routine, program, object, component, data structure, etc., that performs one or more tasks or implements particular abstract data types.

[0025] In certain embodiments, a particular software module or component may comprise disparate instructions stored in different locations of a memory device, which together implement the described functionality of the module. Indeed, a module or component may comprise a single instruction or many instructions, and may be distributed over several different code segments, among different programs, and across several memory devices. Some embodiments may be practiced in a distributed computing environment where tasks are performed by a remote processing device linked through a communications network. In a distributed computing environment, software modules or components may be located in local and/or remote memory storage devices. In addition, data being tied or rendered together in a database record may be resident in the same memory device, or across several memory devices, and may be linked together in fields of a record in a database across a network.

[0026] Embodiments may be provided as a computer program product, including a non-transitory computer and/or machine-readable medium having stored thereon instructions that may be used to program a computer (or other electronic device) to perform processes described herein. For example, a non-transitory computer-readable medium may store instructions that, when executed by a processor of a computer system, cause the processor to perform certain methods disclosed herein. The non- transitory computer-readable medium may include, but is not limited to, hard drives, floppy diskettes, optical disks, CD-ROMs, DVD-ROMs, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, solid-state memory devices, or other types of machine-readable media suitable for storing electronic and/or processor-executable instructions.

[0027] Figure 1 illustrates an example of an embodiment of a simplified one-line diagram of an electric power transmission and distribution system 100 in which a plurality of communication devices may facilitate communication in a SDN consistent with embodiments of the present disclosure. Electric power delivery system 100 may be configured to generate, transmit, and distribute electric energy to loads. Electric power delivery systems may include equipment, such as electric generators (e.g., generators 110, 112, 114, and 116), power transformers (e.g., transformers 117, 120, 122, 130, 142, 144 and 150), power transmission and delivery lines (e.g., lines 124, 134, and 158), circuit breakers (e.g., breakers 152, 160, 176), busses (e.g., busses 118, 126, 132, and 148), loads (e.g., loads 140, and 138) and the like. A variety of other types of equipment may also be included in electric power delivery system 100, such as voltage regulators, capacitor banks, and a variety of other types of equipment.

[0028] Substation 119 may include a generator 114, which may be a distributed generator, and which may be connected to bus 126 through step-up transformer 117. Bus 126 may be connected to a distribution bus 132 via a step-down transformer 130. Various distribution lines 136 and 134 may be connected to distribution bus 132. Distribution line 136 may lead to substation 141 where the line is monitored and/or controlled using IED 106, which may selectively open and close breaker 152. Load 140 may be fed from distribution line 136. Further, step-down transformer 144 in

communication with distribution bus 132 via distribution line 136 may be used to step down a voltage for consumption by load 140.

[0029] Distribution line 134 may lead to substation 151 , and deliver electric power to bus 148. Bus 148 may also receive electric power from distributed generator 116 via transformer 150. Distribution line 158 may deliver electric power from bus 148 to load 138, and may include further step-down transformer 142. Circuit breaker 160 may be used to selectively connect bus 148 to distribution line 134. IED 108 may be used to monitor and/or control circuit breaker 160 as well as distribution line 158.

[0030] Electric power delivery system 100 may be monitored, controlled, automated, and/or protected using intelligent electronic devices (lEDs), such as lEDs 104, 106,

108, 115, and 170, and a central monitoring system 172. In general, lEDs in an electric power generation and transmission system may be used for protection, control, automation, and/or monitoring of equipment in the system. For example, lEDs may be used to monitor equipment of many types, including electric transmission lines, electric distribution lines, current transformers, busses, switches, circuit breakers, reclosers, transformers, autotransformers, tap changers, voltage regulators, capacitor banks, generators, motors, pumps, compressors, valves, and a variety of other types of monitored equipment.

[0031] As used herein, an IED (such as lEDs 104, 106, 108, 115, and 170) may refer to any microprocessor-based device that monitors, controls, automates, and/or protects monitored equipment within system 100. Such devices may include, for example, remote terminal units, differential relays, distance relays, directional relays, feeder relays, overcurrent relays, voltage regulator controls, voltage relays, breaker failure relays, generator relays, motor relays, automation controllers, bay controllers, meters, recloser controls, communications processors, computing platforms,

programmable logic controllers (PLCs), programmable automation controllers, input and output modules, and the like. The term IED may be used to describe an individual IED or a system comprising multiple lEDs.

[0032] A common time signal may be distributed throughout system 100. Utilizing a common or universal time source may ensure that lEDs have a synchronized time signal that can be used to generate time synchronized data, such as synchrophasors.

In various embodiments, lEDs 104, 106, 108, 115, and 170 may receive a common time signal 168. The time signal may be distributed in system 100 using a

communications network 162 or using a common time source, such as a Global Navigation Satellite System (“GNSS”), or the like.

[0033] According to various embodiments, central monitoring system 172 may comprise one or more of a variety of types of systems. For example, central monitoring system 172 may include a supervisory control and data acquisition (SCADA) system and/or a wide area control and situational awareness (WACSA) system. A central IED 170 may be in communication with lEDs 104, 106, 108, and 115. lEDs 104, 106, 108 and 115 may be remote from the central IED 170, and may communicate over various media such as a direct communication from IED 106 or over a wide-area

communications network 162. According to various embodiments, certain lEDs may be in direct communication with other lEDs (e.g., IED 104 is in direct communication with central IED 170) or may be in communication via a communication network 162 (e.g., IED 108 is in communication with central IED 170 via communication network 162).

[0034] Communication via network 162 may be facilitated by networking devices including, but not limited to, multiplexers, routers, hubs, gateways, firewalls, and switches. In some embodiments, lEDs and network devices may comprise physically distinct devices. In other embodiments, lEDs and network devices may be composite devices, or may be configured in a variety of ways to perform overlapping functions. lEDs and network devices may comprise multi-function hardware (e.g., processors, computer-readable storage media, communications interfaces, etc.) that can be utilized in order to perform a variety of tasks that pertain to network communications and/or to operation of equipment within system 100.

[0035] An SDN controller 180 may be configured to interface with equipment in network 162 to create an SDN that facilitates communication between lEDs 170, 115, 108, and monitoring system 172. In various embodiments, SDN controller 180 may be configured to interface with a control plane (not shown) in network 162. Using the control plane, controller 180 may be configured to direct the flow of data within network 162.

[0036] SDN controller 180 may be configured to receive information from a plurality of devices in network 162 regarding transmission of data. In embodiments in which network 162 includes fiber optic communication links, the data collected by the SDN controller 180 may include traffic metrics, such as packet counts, packet loss, latency, transmission times, port link state, etc. SDN controller 180 may implement various techniques disclosed herein to ensure reliable transmission of data during periods of network congestion and other conditions that may interrupt one or more logical communications links between communicating hosts.

[0037] Figure 2A illustrates a conceptual representation of a SDN 200 including a control plane 202, a data plane 204, and a plurality of data-consuming and a plurality of data-producing devices 216a-c that may be deployed in an electric power transmission and distribution system consistent with embodiments of the present disclosure. The control plane 202 directs the flow of data through the data plane 204. More specifically, a controller 212 may communicate with the plurality of communication devices 206a- 206f via an interface 214 to establish data flows. The controller 212 may specify rules for routing traffic through the data plane 204 based on a variety of criteria. In some embodiments, applications 210a-210c may be used to configure the control plane 202.

[0038] As illustrated, the data plane 204 includes a plurality of communication devices 206a-206f in communication with one another via a plurality of physical links 208a-208h. In various embodiments, the communication devices 206a-206f may be embodied as switches, multiplexers, and other types of communication devices. The physical links 208a-208h may be embodied as Ethernet, fiber optic, and other forms of data communication channels. As illustrated, the physical links 208a-208h between the communication devices 206a-206f may provide redundant connections such that a failure of one of the physical links 208a-208h is incapable of completely blocking communication with an affected communication device. In some embodiments, the physical links 208a-208h may provide an N-1 redundancy or better.

[0039] The data consuming/producing devices 216a-c may represent a variety of devices within an electric power transmission and distribution system that produce or consume data. For example, data consuming/producing devices may, for example, be embodied as a pair of transmission line relays configured to monitor an electrical transmission line. The transmission line relays may monitor various aspects of the electric power flowing through the transmission line (e.g., voltage measurements, current measurements, phase measurements, synchrophasers, etc.) and may communicate the measurements to implement a protection strategy for the transmission line. Traffic between the transmission line relays may be forwarded through the data plane 204 using a plurality of data flows implemented by controller 212. Of course, data consuming/producing devices 216a-c may be embodied by a wide range of devices consistent with embodiments of the present disclosure.

[0040] The plurality of communication devices 206a-206f may each include a trust/encryption subsystem that secure communications among devices in the data plane 204. In various embodiments, the trust/encryption subsystem may be issued one or more certificates by controller 212. The one or more certificates may be used to encrypt data traffic sent or received by a particular device. Further, the trust/encryption subsystem may be configured to verify the identity of a sender of SDN data.

[0041] When data is received from data consuming/producing device 216a, the encryption subsystem of one of the plurality of communication devices 206a-206f may encrypt the data before forwarding the data on to another communication device. The final communication device to receive the data prior to transmission to data

consuming/producing device 216c may decrypt the data. Accordingly, the encryption and decryption of the data transmitted between data consuming/producing devices 216a and 216c may be transparent to the devices. In other words, the entire encryption and decryption process of the selected data flow may be performed by the plurality of communication devices 206a-206f without involving data consuming/producing devices 216a-c. In various embodiments, the systems and methods disclosed herein may be used to implement end-to-end encryption between a data producing device and a data consuming device that lack encryption capabilities.

[0042] Figure 2B illustrates a conceptual representation of the SDN system of

Figure 2A configured to redirect a data flow based on a reverse metering threshold consistent with embodiments of the present disclosure. A data flow 218 in data plane 204 may be configured to operate in conjunction with fast failover group entries 220. Fast failover group entries 220 may comprise a plurality of buckets, such as buckets 226 and 228. Ingress packets (not shown) may match a criterion specified by data flow 222 and may be counted by meter 224. The meter 224 may be configured to determine whether the number of ingress packets is greater than a threshold. In various embodiments, if meter 224 is less than a specified value, a port link state 234 may be set to“up.” If meter 224 is greater than the specified value, the port link state 234 may be set to“down.” Fast failover group 220 may switch between bucket 226 and bucket 228 based on the port link state 234. If the port link state 234 is“up,” bucket 226 may be active, and if the port link state 236 is“down,” bucket 228 may be active.

[0043] As illustrated, bucket 226 may forward egress traffic associated with data flow 222 through output port 236, while bucket 228 may forward egress traffic through output port 238. The traffic may be directed to different physical links and different communication devices to reduce network congestion and data packet loss. In the illustrated embodiment, output port 236 may be associated with physical link 208a and may direct the traffic associated with data flow 222 to communication device 206b. Output port 238 may be associated with physical link 208b and may be associated with physical link 208b and may direct the traffic associated with data flow 222 to

communication device 206c. In various embodiments the implementation of the logic in bucket 226 and bucket 228 may be implemented using the IEC 61850-9-2 standard.

[0044] Figure 3 illustrates a conceptual representation of a system 300 configured to implement a redundant communication path that may be adapted based on an analysis of traffic flows consistent with embodiments of the present disclosure. System 300 includes a primary application traffic source 302a and a redundant application traffic source 302b. Redundancies may be in a variety of infrastructure systems, including electric power systems, to help to ensure that important data is successfully transmitted. In the illustrated embodiment, a data plane 304 includes a plurality of communication devices 306a-f. Each of communication devices 306a-f is in

communication with two other communication devices.

[0045] Redundant traffic flows may be configured to be forwarded through physically distinct communication devices and communication links to avoid a single point of failure. For example, a primary traffic flow between primary application traffic source 302a and primary end device 328 may be forwarded through communication devices 306a, 306b, and 306c, as shown by a solid line in Figure 3. The redundant traffic between redundant application traffic source 302b and redundant end device 330 may be forwarded through communication devices 306d, 306e, and 306f, as shown by a dotted line in Figure 3. Additional physical communication links between the communication devices 306a-306f are shown using a dash-dot line pattern.

[0046] System 300 may be configured to utilize the techniques disclosed in the present application to analyze data flows and traffic metrics and adapt the redundant traffic forwarding behavior based on such analysis to reduce utilization of network resources while maintaining a high level of reliability. Although use of redundant data streams may increase the likelihood that at least one of the data streams is received, the redundant traffic consumes resources, and may only be required relatively infrequently (e.g., upon the failure of one or more communication devices or

communication links).

[0047] In the illustrated embodiment, communication devices 306a-f may comprise various components for monitoring traffic flows and statuses. More specifically, communication device 306c is illustrated as comprising a fast failover group 320c, a meter 324c, and a port link state 334c. In various embodiments, meter 324c may be used to set a port link state 334c. In the illustrated embodiment, meter 324c may ensure that the flow of traffic from primary application traffic source 302a to primary end device 328 is maintained above a threshold. While the traffic is maintained above the threshold, the redundant traffic may be suppressed or selectively discarded.

[0048] A decrease in the traffic flow below a threshold, as determined by meter 324c, may be indicative of a disruption in the data in the primary data flow.

Accordingly, the port link state 334c may be changed. The change in the port link state 334c may trigger a fast failover group 320c, which may implement actions to respond to the disruption in the primary data flow.

[0049] Upon detection of a disruption in the primary data flow (i.e. , upon a change in the port link state 334c), the redundant data flow between redundant application traffic source 302b and redundant end device 330 may be enabled. The redundant data flow may utilize communication devices 306d, 306e, and 306f and the associated

communication links between such devices. In an alternative embodiment, a timer on a fixed countdown may be reset each time a packet matches an expected data flow. The time out may be adjusted to accommodate the longest duration that would be expected between two data packets associated with a data flow. Upon expiration of the timer, the port link state 334c may be changed.

[0050] The configuration shown in Figure 3, in which a redundant path is activated when meter 324c falls below a specified threshold, may allow system 300 to avoid continuous transmission of a redundant data stream, while still realizing many of the benefits associated with a redundant system. In some embodiments, the failover performance based on a change in the port link state 334c may be on the order of microseconds. This short failover period minimizes the loss of application traffic. [0051] Moreover, such a system may also enhance situational awareness to the network operators. In current network configurations, network operators may be able to monitor the network burden and may receive notifications when a network becomes overburdened. The system illustrated in Figure 3 may enable monitoring based on the change in port link state 334c. This utilization may be useful for networks controlling electric power systems, as well as a variety of other networks, such as SCADA, phasor- measurement units, telecommunications video applications, etc.

[0052] Figure 4 illustrates a flowchart of a method 400 for processing an information packet in a SDN consistent with the embodiments in the present disclosure. At 402, an ingress packet may be received. At 404, method 400 may determine if the packet matches any existing data flows. If the packet does not match any flow IDs, it may then be determined if a there is a table for packets without a matching flow (i.e. , a table-miss entry), at 406. If there is no table-miss entry, the packet is dropped at 408. At 410, the packet may be forwarded based on the flow of the table-miss entry. A meter for the associated flows may be updated at 412.

[0053] At 414, method 400 may determine whether the meter count satisfies a threshold. In some embodiments, the meter count may be used to determine a packet rate (e.g., 100 packets per second), and the threshold may constitute a packet rate. If the threshold is satisfied, a logical port link state may be maintained at 416.

Alternatively, if the threshold is not satisfied, the logical port link state may be inverted at 420 and can be based on receiving a packet or the packet must match a specified flow. For example, if the logical port link state was“up,” the logical port link state may be updated to“down.” In some embodiments, the logical port link state may be represented as a Boolean value, and the result may be the logical negation of the prior logical port link state.

[0054] At 422, method 400 may determine if the local and physical port link states are consistent. In various embodiments, the physical port state may be based on whether a communication device detects an electrical connection to another device through a physical communication link. The logical port state may be based on whether the meter count at 414 satisfies the threshold. In some situations, the physical status may remain“up,” but the meter count may be below the threshold, and as such, the physical port link state may differ from the logical port link state. In some embodiments, the logical port status and the physical port status may be subjected to the logical AND operation to identify inconsistencies in the state and/or to change forwarding behaviors.

[0055] At 424, an operator may be notified of an inconsistency in the port link state.

In various embodiments, notifications may be provided in a variety of ways, such as an email, an event report, etc.

[0056] Figure 5 illustrates a block diagram of a system 500 including an SDN controller 501 , an SDN 540, and a plurality of communication devices 550a-d consistent with embodiments of the present disclosure. In some embodiments, system 500 may be implemented using hardware, software, firmware, and/or any combination thereof. Moreover, certain components or functions described herein may be associated with other devices or performed by other devices. The specifically illustrated configuration is merely representative of one embodiment consistent with the present disclosure.

[0057] SDN controller 501 includes a communications interface 504 configured to communicate with SDN 540 and communication devices 550a-d. Communications interface 504 may facilitate communications with multiple devices. SDN Controller 501 may further include a time input 502, which may be used to receive a time signal (e.g., a common time reference) allowing SDN controller 501 to apply a time-stamp received data. In certain embodiments, a common time reference may be received via

communications interface 504, and accordingly, a separate time input may not be required. One such embodiment may employ the IEEE 1588 protocol. A data bus 524 may facilitate communication among various components of SDN controller 501.

[0058] Processor 506 may be configured to process communications received via communications interface 504 and time input 502 and to coordinate the operation of the other components of SDN Controller 501. Processor 506 may operate using any number of processing rates and architectures. Processor 506 may be configured to perform any of the various algorithms and calculations described herein. Processor 506 may be embodied as a general-purpose integrated circuit, an application-specific integrated circuit, a field-programmable gate array, and/or any other suitable

programmable logic device.

[0059] Instructions to be executed by processor 506 may be stored in random access memory 514 (RAM). Such instructions may include information for processing routing and processing data packets received via communications interface 504 based on a plurality of traffic flows. [0060] An analysis subsystem 538 may be configured to analyze data relating to traffic transmitted via SDN 540. The data transmitted across SDN 540, communication network devices 550a-d, and hosts 552a-552f in an open mode may be monitored and analyzed to identify a plurality of communication flows within the network 162. In various embodiments, communication network devices 550a-d may collect information, such as meter counts, about the data transmitted across SDN 540. The data collected by communication network devices 550a-d relating to traffic on the network may be provided to analysis subsystem 538. In some embodiments, analysis subsystem 538 may be configured to determine whether a particular data flow falls within one or more meter bands for purposes of determining the“Nveness” of a port.

[0061] Traffic routing subsystem 534 may be configured to generate a variety of communication flows in SDN 540 based on information received from the analysis subsystem 538 and/or the user interface module. The traffic routing subsystem 534 may specify the configuration of a variety of intermediate devices (e.g., routers, switches, multiplexers, etc.), separating communicating hosts. In one example, the traffic routing subsystem 534 may be configured to generate physically distinct paths through which redundant information flows may be transmitted, as described above in connection with Figure 3.

[0062] A troubleshooting subsystem 542 may be configured to aid in identifying configuration problems in system 500 and identifying possible solutions. For example, troubleshooting subsystem 542 may be active where a physical port link status indicates that a port is“up,” but where traffic is not reaching the port, and accordingly, the logical port link status may indicate that the port is“down.”

[0063] Network device 550a is illustrated in greater detail than the other

communication devices 550b-550c, however, communication devices 550b-550d may include some or all of the illustrated features and elements. Each of the communication devices 550a-550d may include a communication interface 552, a communication link monitoring subsystem 554, a forwarding subsystem 556, a statistical information subsystem 558, a processor 560, and a logic engine 562. The components of network device 550a may be in communication via a bus 564. The communication interface 552 may facilitate communications with multiple devices. In various embodiments, the communication interface 552 may be configured to communicate via a variety of communication links, including Ethernet, fiber optic, and other forms of data communication channels.

[0064] The communication link monitoring subsystem 554 may be configured to monitor communications received or transmitted by network device 550a. In some embodiments, the communication link monitoring subsystem 554 may determine a deviation from normal parameters, monitor packet loss, monitor latency, count data packets associated with particular data flows, and monitor other metrics relating to data transmission. The communication link monitoring subsystem 554 may be configured to determine whether traffic associated with a particular data flow is within expected ranges (e.g., satisfies established thresholds or falls within specified meter bands). Such information may be communicated to the SDN controller 501.

[0065] The forwarding subsystem 556 may be configured to track the connection of devices and routing of data through network device 550a. In some embodiments, the routing information subsystem 556 may include an address table, a routing information base, a forwarding table, etc. The forwarding subsystem 556 may be configured to provide information to analysis subsystem 538 about data transmitted by network device 550a that may be utilized by analysis subsystem 538 to identify and/or reconfigure communication flows involving network device 550a.

[0066] The statistical information subsystem 558 may be configured to collect statistics relating to data passing through network device 550a. In some embodiments, such statistics may include a variety of types of information, including packet counts, errors, drops, or overruns, etc. The statistical information subsystem 558 may be configured to provide information to analysis subsystem 538 about data transmitted by network device 550a that may be utilized by analysis subsystem 538 to identify communication flows involving network device 550a.

[0067] The processor 560 may be configured to process communications received via communications interface 552 and to coordinate the operation of the other components of network device 550a. Processor 560 may operate using any number of processing rates and architectures. Processor 560 may be configured to perform any of the various algorithms and calculations described herein. Processor 560 may be embodied as a general purpose integrated circuit, an application specific integrated circuit, a field-programmable gate array, and/or any other suitable programmable logic device. [0068] Logic engine 562 may be configure to receive and implement forwarding instructions or other commands. In some embodiments, logic engine 562 may be configured to selectively implement changes associated with a fast failover group and associated action buckets. In various embodiments, logic engine 562 may be configured to utilize the IEC 61850 standard.

[0069] While specific embodiments and applications of the disclosure have been illustrated and described, it is to be understood that the disclosure is not limited to the precise configurations and components disclosed herein. Accordingly, many changes may be made to the details of the above-described embodiments without departing from the underlying principles of this disclosure. The scope of the present invention should, therefore, be determined only by the following claims.