WO2018171901A1

WO2018171901A1 - System and method for dynamic peer detection in a software defined network

Info

Publication number: WO2018171901A1
Application number: PCT/EP2017/057101
Authority: WO
Inventors: Itamar OFEK; Omer ANSON; Lionel ZERBIB
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2017-03-24
Filing date: 2017-03-24
Publication date: 2018-09-27
Also published as: CN109417513A; CN109417513B

Abstract

A system for dynamically detecting a peer node in a software defined network (SDN) comprises a processor of a node of an SDN. The processor is adapted to: receive over the SDN a first data packet originating from a source entity and addressed to a target entity; send a centralized controller of the SDN a request to configure the SDN according to certain network forwarding settings; and forward the first data packet over the SDN according to the certain network forwarding settings.

Description

SYSTEM AND METHOD FOR DYNAMIC PEER DETECTION IN A

SOFTWARE DEFINED NETWORK

BACKGROUND The present invention, in some embodiments thereof, relates to peer detection in a software defined network (SDN) and, more specifically, but not exclusively, to a new node in an SDN dynamically detecting a peer.

In an SDN a sub-system that makes decisions about when network traffic is sent, typically known as a control plane, is decoupled (or disassociated) from underlying sub-systems, typically known as data planes, that forward network traffic to a selected destination. In a typical SDN, the separated control plane resides on a logically centralized controller. The centralized controller has information about where hosts connect to the network and what a network topology connecting the hosts together looks like. In traditional network technologies, forwarding information is exchanged between network devices using dedicated protocols, for example Routing Information Protocol (RIP), Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP). On the other hand, in a typical SDN forwarding tables on network devices (for example routers and switches) are programmed according to instructions from the centralized controller according to a network policy. Two hosts connected to an SDN can exchange network traffic only if the SDN's centralized controller programmed the SDN's network devices to forward network traffic between the two hosts. Adding a new network node to an SDN typically requires proactive configuration of other nodes in the network, incorporating knowledge that the new node has been added.

SUMMARY

It is an object of the present invention to provide a system and a method for monitoring presence(s) and/or action(s) of person(s) on premises and reacting to person related events such as predetermined audio events. The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to a first aspect of the invention, a system for dynamically detecting a peer node in a software defined network (SDN), comprises a processor of a node of an SDN. The processor is adapted to: receive over the SDN a first data packet originating from a source entity and addressed to a target entity; send a centralized controller of the SDN a request to configure the SDN according to certain network forwarding settings; and forward the first data packet over the SDN according to the certain network forwarding settings.

According to a second aspect of the invention, a method for dynamically detecting a peer node in a software defined network (SDN), comprises at a node of an SDN: receiving over the SDN a first data packet originating from a source entity and addressed to a target entity; sending a centralized controller of the SDN a request to configure the SDN according to certain network forwarding settings; and forwarding the first data packet over the SDN according to the certain network forwarding settings. When a node receives new network traffic, the node requests setting up an appropriate network tunnel for forwarding the new network traffic to the traffic' s destination. There is no need for prior registration of the node or for prior configuration of the network tunnel.

With reference to the first aspect, in a possible implementation the centralized controller comprises a database. Using a database preserves the registration information and can allow other nodes to retrieve the information if needed without adding to the centralized controller's load. With reference to the first aspect, in a possible implementation the node is a computing node in the SDN, hosting a plurality of virtual machines. A node may be a computing node hosting virtual machines (presumably running non-SDN forwarding related applications). The present invention allows any type of SDN node to join dynamically. With reference to the first aspect, in a possible implementation the node is a network node in the SDN. A node may be a network node that is a node running SDN forwarding related applications. The invention allows any type of SDN node to join dynamically.

With reference to the first and second aspect, in a possible implementation the processor is further adapted to receive over the SDN a plurality of data packets originating from the source entity and addressed to the target entity; and forward the plurality of data packets over the SDN according to the certain network forwarding settings. Once a network tunnel is configured upon demand, the node continues to forward traffic on the network tunnel with no need to request further configuration. A node can set up alternative network tunnels if the first network tunnel failed. There is no need for the centralized controller to monitor the success of the configuration; the node detects the failure and triggers a new configuration.

With reference to the first and second aspect, in a possible implementation the processor is further adapted to: receive over the SDN a data packet indicating a failure of the forward of the first data packet; send the centralized controller a request to configure the SDN according to other network forwarding settings; send the first data packet over the SDN according to the other network forwarding settings; receive over the SDN a plurality of data packets originating from the source entity and addressed to the target entity; and forward the plurality of data packets over the SDN according to the other of the plurality of network forwarding settings. With reference to the first and second aspect, in a possible implementation the processor is further adapted to: send a registration message to a centralized controller of the SDN; and receive from the centralized controller a response comprising a plurality of network forwarding settings. The certain network forwarding settings is one of the plurality of network forwarding settings. By registering with the SDN's centralized controller, the node can be known to other active nodes and can receive traffic from the SDN even before it starts forwarding traffic into the SDN.

With reference to the first and second aspect, in a possible implementation the request to configure the SDN comprises the node's authorization credentials. When a node registers with the centralized controller, either via the first request to configure a network tunnel or via an explicit registration message, the node can send the centralized controller credentials so that it is identified by data other than its IP address. With reference to the first and second aspect, in a possible implementation the certain network forwarding settings include settings for a network tunnel. Configuring network forwarding tunnels allows for the creation of virtual networks over public data networks, providing a cost effective solution for private networking instead of creating dedicated networks.

With reference to the first and second aspect, in a possible implementation the network tunnel is a member of a group comprising: Generic Network Virtualization Encapsulation (Geneve), Virtual extensible Local Area Network (VXLAN), Stateless Transport Tunneling Protocol (STT), Generic Routing Encapsulation (GRE) and Layer 2 Tunneling Protocol (L2TP) .

With reference to the first and second aspect, in a possible implementation the certain network forwarding settings include settings for enforcing traffic policies. Traffic policies allow network service providers to offer a plurality of service levels.

With reference to the first and second aspect, in a possible implementation the traffic policies include Quality of Service policies. Quality of Service policies allow network service providers to offer a plurality of service levels.

With reference to the first and second aspect, in a possible implementation the traffic policies include security policies. Security policies allow protecting the privacy of network traffic. Other systems, methods, features, and advantages of the present disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims. Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting. BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.

FIG. 1 is a schematic block diagram of an exemplary SDN system according to some embodiments of the present invention; FIG. 2 is a flow diagram of an optional flow of operations according to some embodiments of the present invention;

FIG. 3 is a flow diagram of a second optional flow of operations according to some embodiments of the present invention; and

FIG. 4 is a flow diagram of a third optional flow of operations according to some embodiments of the present invention.

DETAILED DESCRIPTION

The present invention, in some embodiments thereof, relates to peer detection in a software defined network (SDN) and, more specifically, but not exclusively, to a new node in an SDN dynamically detecting a peer.

A network node is an entity capable of receiving, creating, storing or sending data over network routes. Henceforth, the term "network nodes" includes SDN nodes, such as SDN compute nodes and SDN network nodes, and network devices, such as switches and routers. A typical network node may comprise one or more hardware processors connected to one or more network interfaces. Some network nodes may be hardware network devices, for example routers and switches, having hardware adapted to forward network traffic comprising data packets or running code adapted to forward network traffic comprising data packets. Other network nodes may comprise a processor running multiple codes, including a code adapted to forward network traffic.

In traditional network technologies, forwarding information is exchanged between network nodes using dedicated protocols, for example Routing Information Protocol (RIP), Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP). On the other hand, in a typical SDN forwarding tables on network nodes are programmed according to instructions from the centralized controller according to a network policy. Two entities connected to an SDN can exchange network traffic only if the SDN's centralized controller programmed the SDN's network nodes needed to setup a network tunnel for forwarding network traffic between the two entities.

Adding a new network node to an SDN typically requires proactive configuration of other nodes in the network incorporating knowledge that the new node has been added, and may require an immediate topological change in the network affecting multiple network nodes. In some cases this change involves configuring all network nodes in the network.

In addition, currently a single predetermined technology, service, or underlying tunnel protocol is typically used for communication between all network nodes in the network. For example, Generic Network Virtualization Encapsulation (Geneve), Virtual extensible Local Area Network (VXLAN), Stateless Transport Tunneling Protocol (STT), Generic Routing Encapsulation (GRE) and Layer 2 Tunneling Protocol (L2TP). Changing the protocol requires reconfiguration and restarting of all services in the network. While it is technically possible to use multiple mechanisms for communication between nodes, this is typically not done due to the configuration overhead. There is a need to inform both tunnel endpoints of the mechanism used, thus the need to configure the network prior to forwarding network traffic on a tunnel. An endpoint is a network node that does not forward data over network routes. A source entity and a target entity are endpoints of a network tunnel between the source entity and the target entity.

To overcome the complexity of proactively configuring the entire network when adding a new network node or when changing the protocol of communication for one or more network tunnels, the present invention, in some embodiments thereof, enables a network node to dynamically discover a peer node when needed, and request the configuration of a network tunnel in the SDN to the peer node. A peer node is another network node connected to the SDN. A target entity is an example of a peer node.

In some embodiments of the present invention, the SDN's centralized controller does not configure all network nodes of the SDN upon adding a new network node to the SDN. When a new network node receives a data packet originating from a source entity and addressed to a target entity, the new network node may check its internal forwarding tables for forwarding instructions to the target entity. In some embodiments of the present invention, when no forwarding instructions for the target entity are configured in the new network node' s internal forwarding tables, the new network node sends a request to the centralized controller to configure the network according to network forwarding settings for the target entity. In such embodiments, upon receiving the request, the SDN's centralized controller configures some of the SDN's network nodes, including the new network node, according to the network forwarding settings for the target entity. Now, network traffic from the source entity received by the new network node is forwarded to another network node. Some of the SDN's network nodes receiving network traffic originating from the source entity and addressed to the target entity may forward the network traffic without the need to send additional configuration requests to the centralized controller.

In such embodiments, the centralized controller configures the network forwarding settings for network traffic originating from the source entity addressed to the target entity only when such network traffic exists, eliminating the need to pre- configure the new network node for all possible network traffic between any two entities connected to the SDN, or the need to pre-configure other network nodes with network settings incorporating the new network node. The network forwarding settings for the target entity may be pre-defined settings configured in the new network node at initialization time. In some embodiments, the new network node retrieves the network forwarding settings for the target entity from a database of the centralized controller. Optionally, the network forwarding settings for the target entity are default settings. In some embodiments where the SDN's centralized controller does not configure network nodes of the SDN upon adding a new network node to the SDN, the centralized controller interprets the request to configure the network as a request to register the new network node as an active node. The centralized controller may now incorporate the new network node in configurations of the SDN. In addition, other network nodes receiving network traffic addressed to the new network node may retrieve network forwarding settings for the new network node.

Similarly, when changing a protocol of communication for one or more network tunnels, in some embodiments of the present invention the centralized controller configures network nodes according to a new protocol only when a source entity initiates network traffic to a target entity.

In some embodiments a network node requests information about one or more peer network nodes from the centralized controller. Optionally, the network node requests the information from the centralized controller after receiving a failure indication when forwarding network traffic originating from the source entity and addressed to the target entity according to existing network traffic forwarding settings. In other embodiments, the network node sends a request for information about one or more peer network nodes at a predefined time interval, for example in order to facilitate dynamic changes.

The centralized controller may send the network node a response including one or more other network forwarding settings for the one or more peer network nodes. Optionally, the network node retrieves the one or more other network forwarding settings from a database. The network node may send the centralized controller a request to configure the

SDN according to one of the one or more other forwarding settings. In some embodiments the one or more other forwarding settings include forwarding settings for a new protocol of communication for a network tunnel between the source entity and the target entity. The forwarding settings for the new protocol are configured only when network traffic originating from the source entity and addressed to the target entity exists.

Network forwarding settings may include a peer node's network address, a peer node's name or other unique identifier, a plurality of network technologies supported by the peer node and security data, e.g. a cryptographic key. Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. The invention is capable of other embodiments or of being practiced or carried out in various ways. The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network.

The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention. Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware -based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Reference is now made to FIG. 1, showing a schematic block diagram of an exemplary SDN system according to some embodiments of the present invention. In such embodiments, SDN 100 comprises a centralized controller 101. Optionally, the system comprises a database 102. In some embodiments the centralized controller is connected to the database via the SDN. The SDN comprises a plurality of existing nodes, for example existing node A 104, existing node B 105 and existing node C 106. Some existing node pairs may be connected through a network tunnel, for example existing node A is connected to existing node C through networking tunnel 107. When a new node 103 is added to the SDN, it may need to communication with existing node A but not with existing node B or existing node C. In such embodiments, the new node is connected to the centralized controller and may send the centralized controller a request to configure a network tunnel between the new node and existing node A. In some embodiments the centralized controller configures another plurality of network nodes to establish a network tunnel 108 between the new node and existing node A, without interrupting or affecting network tunnel 107, or other existing network tunnels 109 and 110. Platforms for developing, configuring and managing an SDN include OpenFlow, Ciscon System's Application Centric Infrastructure and Open Network Environment, VMWare NSX, Nicira' s network virtualization platform and Juniper Networks Contrail. Network nodes may be managed using a cloud management system, for example OpenStack, Eucalyptus, CloudStack, Amazon Web Services (AWS) and Microsoft Azure. In some embodiments a network node may be a compute node, housing a plurality of virtual machines, executing a plurality of codes. Some of the plurality of code may forward network traffic. Optionally, a network node runs one or more virtual machines that do no forward network traffic. In some embodiments having a database, the database is a Neutron Database. In some embodiments, network nodes communicate directly with the database. In other embodiments only the centralized controller communicates with the database.

Reference is now made to FIG. 2, showing a flow diagram of an optional flow of operations 200 according to some embodiments of the present invention. In such embodiments a new node 201 joins an SDN and begins listening 210 for incoming tunnels and connections. Another network node 204 in the SDN sends to the new node a first data packet 214 addressed to an existing peer node A 202. The internal forwarding tables in the new network node may not include forwarding instructions for peer node A. In some embodiments the new node sends to the centralized controller 203 a request 215 to configure the SDN with network forwarding settings for peer node A. Now the network node forwards 216 the first data packet to peer node A, according to the network forwarding settings. A plurality of additional data packets 217 arriving from the other network node and addressed to peer node A are now forwarded 218 according to the network forwarding settings. In some embodiments, the request to configure the SDN comprises network forwarding settings including settings for a network tunnel. Examples of network tunnel technologies are Generic Network Virtualization Encapsulation (Geneve), Virtual extensible Local Area Network (VXLAN), Stateless Transport Tunneling Protocol (STT), Generic Routing Encapsulation (GRE) and Layer 2 Tunneling Protocol (L2TP). The settings for a network tunnel may include peer node A's network address, peer node A's name or other unique identifier, a plurality of network technologies supported by peer node A and security data, e.g. a cryptographic key. This allows the centralized controller to identify the network tunnel's endpoint by name or other unique identifier, and not by network address which may change over time.

The configuration of SDN nodes may be generated before deploying the SDN nodes and pre-configured to the centralized controller, including authorization credentials and supported network technologies for each of the SDN's nodes. In some embodiments, the request to configure the SDN comprises the new network node's authorization credentials, for example the new network node's name or other unique identifier, a key, and a cryptographic key. This allows the centralized controller to identify the new network node by a name or other unique identifier and not by a network address, which may change over time. In such embodiments the centralized controller is pre-configured to accept requests from the new network node, but the centralized controller does not configure other nodes of the SDN until the new network node sends a configuration request. This is sometimes referred to as lazy configuration.

Reference is now made to FIG. 3, showing a flow diagram of a second optional flow of operations 300 according to some embodiments of the present invention. In such embodiments, upon joining the SDN, new network node 201 sends the centralized controller a registration message 211. Optionally, the new node registers directly with a database. Next the new node receives 212 a plurality of network forwarding settings for one or more active peer nodes. In some embodiments the centralized controller sends the plurality of network forwarding settings for a plurality of active nodes. In other embodiments the new network node retrieves the plurality of network forwarding settings from the database. Registering with the centralized controller or the database allows other network nodes receiving traffic addressed to the new network node to retrieve network forwarding settings for the new network node before the new network node forwards any traffic. Optionally, the new network node notifies 213 one or more existing nodes 202 that the new network node is active. This allows the one or more existing nodes to be aware of the new network node even without querying the centralized controller or the database for a list of active peer nodes. Typically the one or more existing nodes share a network segment with the new network node. Now, when the new network node receives a first data packet 214 addressed to existing peer node A, the new network node may identify peer node A in the one or more active nodes and choose one of the plurality of network forwarding settings for peer node A. Having a plurality of network forwarding setting for peer node A, the new network node may choose network settings for a preferred network tunnel technology.

Referring now to FIG. 4, showing a flow diagram of a third optional flow of operations 400 according to some embodiments of the present invention. In such embodiments, there is a need to change the network protocol for a network tunnel between two nodes. Upon forwarding the first data packet 216, the new node may receive a failure notification 310. An example of a failure notification is Internet Control Message Protocol (ICMP) Port Unreachable, indicating the packet was successfully forwarded to peer node A but peer node A does not support the protocol used for communication. This may happen when there has been a change to peer node A after the new node received 212 the plurality of network forwarding settings for the one or more active nodes. Other error messages may be returned by other network nodes, for example ICMP Network Unreachable and ICMP Host Unreachable, indicating a full network tunnel to peer node A according to the network forwarding settings does not exist. In these embodiments, the new network node chooses other network forwarding settings from the plurality of network forwarding settings for peer node A and sends a request 311 to the centralized controller to configure the SDN according to the other network forwarding settings. The new network node forwards 312 the first data packet to peer node A according to the other network forwarding settings. A plurality of additional data packets 313 arriving from the other network node and addressed to peer node A are now forwarded 314 according to the other network forwarding settings.

When there is a need to migrate an existing connection between two entities to a newer technology, the centralized controller may be updated with the new technology network forwarding settings for the two entities. At a next time when one of the two entities attempts to send data packets to the other of the two entities, the centralized controller uses the new technology network forwarding settings when requested to configure the SDN with a network tunnel between the two entities. This is done without disrupting other existing connections in the SDN and without a need to update the two entities.

In some embodiments, the network forwarding settings include settings for enforcing traffic policies, for example for rate limiting. In some embodiments the network forwarding settings include settings for Quality of Service (QoS) policies, for example Internet Engineering Task Force (IETF) Differentiated Services (DiffServ) and bandwidth reservation. In some embodiments the network forwarding settings include security policies.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is expected that during the life of a patent maturing from this application many relevant network forwarding settings will be developed and the scope of the term network forwarding settings is intended to include all such new technologies a priori. As used herein the term "about" refers to ± 10 %.

The terms "comprises", "comprising", "includes", "including", "having" and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of and "consisting essentially of.

The phrase "consisting essentially of means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof.

The word "exemplary" is used herein to mean "serving as an example, instance or illustration". Any embodiment described as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments. The word "optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments". Any particular embodiment of the invention may include a plurality of "optional" features unless such features conflict. Throughout this application, various embodiments of this invention may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the invention. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range. Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases "ranging/ranges between" a first indicate number and a second indicate number and "ranging/ranges from" a first indicate number "to" a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals there between.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub combination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting.

Claims

An apparatus for dynamically detecting a peer node in a software defined network, SDN, comprising:

a processor of a node of an SDN, said processor is adapted to:

receive over said SDN a first data packet originating from a source entity and addressed to a target entity;

send a centralized controller of said SDN a request to configure said SDN according to certain network forwarding settings; and

forward said first data packet over said SDN according to said certain network forwarding settings.

The apparatus of claim 1, wherein said processor is further adapted to:

receive over said SDN a plurality of data packets originating from said source entity and addressed to said target entity; and

forward said plurality of data packets over said SDN according to said certain network forwarding settings.

The apparatus of claim 1, wherein said processor is further adapted to:

receive over said SDN a data packet indicating a failure of said forward of said first data packet;

send said centralized controller a request to configure said SDN according to other network forwarding settings;

send said first data packet over said SDN according to said other network forwarding settings;

forward said plurality of data packets over said SDN according to said other of said plurality of network forwarding settings.

The apparatus of claim 1, wherein said processor is further adapted to:

send a registration message to a centralized controller of said SDN; and receive from said centralized controller a response comprising a plurality of network forwarding settings;

wherein said certain network forwarding settings is one of said plurality of network forwarding settings.

5. The apparatus of claim 1, wherein said request to configure said SDN comprises said node's authorization credentials.

6. The apparatus of claim 4, wherein said registration message comprises said node's authorization credentials.

7. The apparatus of claim 1, wherein said centralized controller comprises a database.

8. The apparatus of claim 1, wherein said node is a computing node in said SDN hosting a plurality of virtual machines.

9. The apparatus of claim 1, wherein said node is a network node in said SDN.

10. The apparatus of claim 1, wherein said certain network forwarding settings include settings for a network tunnel.

11. The apparatus of claim 10, wherein said network tunnel is a member of a group comprising: Generic Network Virtualization Encapsulation, Geneve, Virtual extensible Local Area Network, VXLAN, Stateless Transport Tunneling Protocol, STT, Generic Routing Encapsulation, GRE, and Layer 2 Tunneling Protocol, L2TP.

12. The apparatus of claim 1, wherein said certain network forwarding settings include settings for enforcing traffic policies.

13. The apparatus of claim 12, wherein said traffic policies include Quality of Service policies.

14. The apparatus of claim 12, wherein said traffic policies include security policies.

15. A method for dynamically detecting a peer node in a software defined network (SDN), comprising: at a node of an SDN:

receiving over said SDN a first data packet originating from a source entity and addressed to a target entity;

sending a centralized controller of said SDN a request to configure said SDN according to certain network forwarding settings; and

forwarding said first data packet over said SDN according to said certain network forwarding settings.