Abstract: A data center failure management system and method in a Software Defined Networking (SDN) deployment. In one embodiment, an SDN controller associated with the data center is configured to learn new flows entering the data center and determine which flows require flow stickiness. Responsive to the determination, the SDN controller generates commands to one or more switching nodes and/or one or more border gateway nodes to redirect the sticky flows arriving at the switching nodes via ECMP routes from the gateway nodes or avoid the ECMP routes by the gateway nodes in order to overcome certain failure conditions encountered in the data center, an external network, or both.

Abstract: A data center failure management system and method in a Software Defined Networking (SDN) deployment. In one embodiment, an SDN controller associated with the data center is configured to learn new flows entering the data center and determine which flows require flow stickiness. Responsive to the determination, the SDN controller generates commands to one or more switching nodes and/or one or more border gateway nodes to redirect the sticky flows arriving at the switching nodes via ECMP routes from the gateway nodes or avoid the ECMP routes by the gateway nodes in order to overcome certain failure conditions encountered in the data center, an external network, or both.

Abstract: A data center failure management system and method in a Software Defined Networking (SDN) deployment. In one embodiment, an SDN controller associated with the data center is configured to learn new flows entering the data center and determine which flows require flow stickiness. Responsive to the determination, the SDN controller generates commands to one or more switching nodes and/or one or more border gateway nodes to redirect the sticky flows arriving at the switching nodes via ECMP routes from the gateway nodes or avoid the ECMP routes by the gateway nodes in order to overcome certain failure conditions encountered in the data center, an external network, or both.

Abstract: A data center failure management system and method in a Software Defined Networking (SDN) deployment. In one embodiment, an SDN controller associated with the data center is configured to learn new flows entering the data center and determine which flows require flow stickiness. Responsive to the determination, the SDN controller generates commands to one or more switching nodes and/or one or more border gate-way nodes to redirect the sticky flows arriving at the switching nodes via ECMP routes from the gateway nodes or avoid the ECMP routes by the gateway nodes in order to overcome certain failure conditions encountered in the data center, an external network, or both.

Abstract: A software-defined networking (SDN) controller communicatively coupled with a cloud orchestrator enables live migration of a virtual machine from a first network device to a second network device. The SDN controller receives from the cloud orchestrator an indication that migration of the virtual machine is to be initiated. In response to receiving the indication, a third network device is caused to forward flows towards the first network device by passing through the second network device. The SDN controller transmits to the cloud orchestrator an indication that the migration of the virtual machine can be performed, causing the cloud orchestrator to complete the migration of the virtual machine to the second network device. In response to the migration of the virtual machine, the second network device processes the flows locally instead of forwarding them to the first network device.

Abstract: A method for path monitoring is disclosed. The method includes receiving, at the network device, a packet from a SDN controller to monitor a path for a service between the network device and another network device. The method includes sending the packet to at least a first and a second port, where a first instance of the packet is transmitted to the first port to the other network device to monitor the path, and a second instance is transmitted to the second port that loops back the second instance to the network device at a transmission interval so that the packet is sent to the first port repetitively at the transmission interval. The method also includes determining whether or not the packet is received from the other network device within a timeout interval and discarding the packet upon determination that the packet is received within the timeout interval.

Abstract: Methods for delay measurement in a software-defined networking (SDN) system are disclosed. In one embodiment, one packet each is received from a first and a second network device. The time stamps of these packets are recorded in a set of ingress time stamps and a set of egress time stamps respectively if the first and second network devices are the ingress and egress network devices of a traffic flow and if both packets include indications for delay measurement. Then the method continues with a delay measure for the traffic flow based on at least the sets of the ingress time stamps and egress time stamps associated with the flow identifier of the traffic flow, and a measurement noise the electronic device obtained from sending measurement packets to the first and second network devices.

Abstract: Methods for delay measurement in a software-defined networking (SDN) system are disclosed. In one embodiment, one packet each is received from a first and a second network device. The time stamps of these packets are recorded in a set of ingress time stamps and a set of egress time stamps respectively if the first and second network devices are the ingress and egress network devices of a traffic flow and if both packets include indications for delay measurement. Then the method continues with a delay measure for the traffic flow based on at least the sets of the ingress time stamps and egress time stamps associated with the flow identifier of the traffic flow, and a measurement noise the electronic device obtained from sending measurement packets to the first and second network devices.

Abstract: A method for path monitoring is disclosed. The method includes receiving, at the network device, a packet from a SDN controller to monitor a path for a service between the network device and another network device. The method includes sending the packet to at least a first and a second port, where a first instance of the packet is transmitted to the first port to the other network device to monitor the path, and a second instance is transmitted to the second port that loops back the second instance to the network device at a transmission interval so that the packet is sent to the first port repetitively at the transmission interval. The method also includes determining whether or not the packet is received from the other network device within a timeout interval and discarding the packet upon determination that the packet is received within the timeout interval.

Abstract: An apparatus comprising a virtual queue configured to virtually receive virtual data units as the data units are actually received by a real queue. In various embodiments, the virtual queue may include a token counter decrementor configured to, as an entering data unit virtually enters the virtual queue, attempt to allocate the entering data unit to either the committed burst or the excess burst and decrement either the committed token counter (CTC) or the excess token counter (ETC) respectively. In one embodiment, a token counter incrementer configured to, as a data unit virtually exits the virtual queue, increment one of the token counters. In some embodiments, the virtual queue may include a congestion indicator configured to categorize the entering data unit. In various embodiments, the virtual queue may be configured to provide congestion feedback information based, at least in part, upon the state of the CTC & ETC.

Abstract: An apparatus comprising a virtual queue configured to virtually receive virtual data units as the data units are actually received by a real queue. In various embodiments, the virtual queue may include a committed token counter (CTC) configured to represent a number of bytes available to be allocated to a committed burst having a maximum size. In such an embodiment, the virtual queue may include an excess token counter (ETC) configured to represent a number of bytes available to be allocated to an excess burst having a maximum size. In one embodiment, a token counter incrementer configured to, as an exiting data unit virtually exits the virtual queue, increment either the committed token counter or the excess token counter.

Abstract: There is a need to improve design of communications protocols in which two or more channels are provided and, optionally, in which collision avoidance is not available. An improved protocol is provided in which communications nodes pick a channel on which to transmit and collisions may occur where two nodes attempt to transmit on the same channel. The node currently occupying a channel is arranged to have a specified probability of holding onto that channel as compared to a newcomer. Other methods are described whereby a node is able to occupy more than one channel at the same time and whereby nodes each occupy approximately the same number of channels.