WO2016206741A1 - Forwarding device, controller and method - Google Patents

Forwarding device, controller and method Download PDF

Info

Publication number
WO2016206741A1
WO2016206741A1 PCT/EP2015/064345 EP2015064345W WO2016206741A1 WO 2016206741 A1 WO2016206741 A1 WO 2016206741A1 EP 2015064345 W EP2015064345 W EP 2015064345W WO 2016206741 A1 WO2016206741 A1 WO 2016206741A1
Authority
WO
WIPO (PCT)
Prior art keywords
controller
forwarding device
address
identification address
identification
Prior art date
Application number
PCT/EP2015/064345
Other languages
French (fr)
Inventor
Vivek Kulkarni
Ermin SAKIC
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to PCT/EP2015/064345 priority Critical patent/WO2016206741A1/en
Publication of WO2016206741A1 publication Critical patent/WO2016206741A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Definitions

  • the invention relates to a forwarding device to be integrated in a software defined network and a controller for managing forwarding devices in a software defined network and a corre- sponding method.
  • SDN Software defined networking
  • An example of a protocol for communication between the controller and forwarding devices, such as switches, bridges etc. is "OpenFlow”. Objectives of SDN are to facilitate networking by e.g.
  • One aspect thereof is the integra ⁇ tion of new forwarding devices or nodes.
  • new devices are to be integrated into a network, they need to be configurated first, e.g. adapted to the network's re ⁇ quirements.
  • the configuration sets which IP addresses are to be used and where they are retrieved from.
  • the invention relates to a forwarding device, e.g. a switch, for use in a software defined network.
  • the forwarding device is arranged to exchange control data with a controller, which assigns an identification address to the forwarding device, and for performing the steps of broadcasting a request to re ⁇ ceive an identification address of at least one controller; further the step of receiving, under the assigned identifica ⁇ tion address, the at least one controller's identification address and of setting in the forwarding device the at least one controller' s identification address as entry to which control data are forwarded.
  • a forwarding device discov ⁇ ers the existence of a controller and control data may be ex ⁇ changed between the controller and the forwarding device.
  • the invention further relates to a controller for use in a software defined network, which manages at least one forward ⁇ ing device by exchanging control data.
  • the controller is arranged for performing the steps of assigning an identifica- tion address to the at least one forwarding device; further of receiving a broadcast for a request to receive the con ⁇ troller' s identification address and of sending, to the assigned identification address, the controller's identifica ⁇ tion address.
  • new forwarding de- vices may be integrated in the network automatically, in par ⁇ ticular in a plug and play mode.
  • the invention further relates to a corresponding method for integrating a forwarding device into a software defined net- work managed by a controller.
  • the method comprises the fol ⁇ lowing steps of assigning, by the controller, an identification address to the at least one forwarding device; further of broadcasting, by the forwarding device a request to re ⁇ ceive an identification address of at least one controller; further of receiving, by the forwarding device under the assigned identification address, the at least one controller's identification address and of setting in the forwarding device the at least one controller' s identification address as entry to which control data are forwarded.
  • Fig. 1 an exemplary sequence diagram showing phases of the process of automatically integrating a switch
  • Fig. 2a and b exemplary embodiments of a SDN network with one controller.
  • Fig. 1 an exemplary embodiment of a sequence diagram is depicted showing various phases of integrating a forwarding device or switch into a SDN (software defined network) . The progress in time is from top to bottom.
  • the switches in this example are communicating with the SDN controller via the
  • OpenFlow protocol which has been designed for the communica ⁇ tion between controllers and switches for setting so called "forwarding tables", i.e. to which entities data are to be forwarded from the respective switch.
  • Other communication protocols may be employed.
  • a network address provision for a SDN controller and forwarding devices takes place.
  • a forwarding device or switch S which is a direct neighbour to a SDN controller C
  • a DHCP discover request is broadcast to the controller C.
  • Direct neighbour means that the switch S is communicating with the controller without an intermediate switch or other device, i.e. over one hop.
  • the controller C can also provide the functions of a DHCP server, i.e. act as DHCP server itself or providing the DHCP functions in such a way to the switch that the switch S only "sees" the controller and needs not to address a further de ⁇ vice.
  • a dedicated DHCP server is executed on same host as the SDN-Controller and an SDN forwarding device runs a DHCP client instance. If installed, the DHCP client running on OpenFlow-enabled switches will contact the DHCP server via broadcast messaging, which is run on the SDN Controller and establish its bridge's or switches' network ad ⁇ dress from the pool of available IP addresses.
  • the controller C answers by sending a DHCP offer message to the switch S an ⁇ swering the discover request that it can provide IP ad- dresses.
  • the switch S then broadcasts a DHCP Request message requesting an IP address, which is acknowledged by the con ⁇ troller C by sending a DHCP acknowledgement message DHCP A back to the switch S wherein the IP address for the switch S is provided.
  • the management of designated data plane interfaces or ports of the switch can be done later by the OpenFlow-talking SDN- Controller.
  • more than one dynamic parameter, e.g. forward entries can be managed with a single IP address.
  • IP address assignment e.g. either dynamic IP address association or static MAC-IP address associations are achievable with an appropriately configured DHCP server instance.
  • an initial static configuration on SDN switches and SDN-Controller may take place.
  • the network addresses of both the SDN- Controller listening for OpenFlow packets, as well as of the OpenFlow-enabled switches or bridges can be configured statically as well.
  • the SDN-Controller listens for OpenFlow events on its host's interfaces by binding a TCP socket to all available interfaces and listening on a standardized or user-designated port number.
  • an IP address is assigned to the switch which is to be integrated.
  • a SDN controller discovery procedure takes place and the switch S broadcasts a PnP (plug and play) discovery message to all direct neighbours, e.g. broadcast messages are sent not only on specific but on every single switch interface as the position of the controller ( s ) rela ⁇ tive to the position of the switch in network is unknown.
  • the objective is that the switch receives the IP address of the respective controller ( s ) C and optionally other static pa ⁇ rameters of the switch.
  • the forwarding device or switch is integrated into the network.
  • Static parameters are e.g. the IP addresses of controllers, which are in particular valid as long as the switch S is powered on.
  • the switch S sends these PnP discovery messages or packets periodically. These packets are destined for a broadcast address and targeting a well known port number and are sent out on all interfaces which are part of the switch S, destined for all direct neighbours, of which at least one is the controller C.
  • the IP address of the switch S is contained in the header and can be detected in a step PH where the headers are parsed. From thereon, the switch S can be addressed by the controller C. With this information a safe connection, e.g. a TCP (Transmission Control Protocol) or TLS (transport layer security) connection can be opened and the Open PnP TCP/TLS Connection message is sent unicast. Alternatively other protocols that enable a sage connection may be used.
  • TCP Transmission Control Protocol
  • TLS transport layer security
  • the controller C remotely configures a set of possible controllers for the switch S, i.e. provides the IP addresses of the main and alternative con- trollers.
  • the set OF (OpenFlow) Con ⁇ troller IP message and set OVSDB (Open vSwitch Database Management Protocol) Manager IP message are sent unicast.
  • the safe connection is closed and the close PnP connection message is sent unicast.
  • the control plane of the switch S is organised and therewith the switch integrated in the network, such that it can forward data.
  • a TCP/IP Connection is opened, e.g. an OpenFlow channel is established.
  • the switch S will reattempt to establish the unicast connection, e.g. TCP or TLS connection, to one or more of the controllers C in a separate TCP/TLS channel used for OpenFlow-based communica- tion.
  • the unicast connection e.g. TCP or TLS connection
  • the switch S will reattempt to establish the unicast connection, e.g. TCP or TLS connection, to one or more of the controllers C in a separate TCP/TLS channel used for OpenFlow-based communica- tion.
  • dynamic parameters of the switch are set such as the forwarding entries for individual ports.
  • the "OFPT_HELLO" messages are exchanged and standard OpenFlow messaging initiated, which is in particular used for running conditions .
  • P4 default flow rules for matching discovery packets are provided to the switch S.
  • the objective thereof is to integrate also forwarding devices or further switches S' that are several hops away from the controller into the network, i.e. need to communication across a further forwarding device with the switch. This is done by providing rules to the directly connected switches S on how various data are to be forwarded.
  • the connected switches S forward the DHCP and PnP Discovery packets, originating from further switches S' which have no direct connection with the SDN- Controller, to the main or alternative controller ( s ) and re ⁇ spective replies to newly added further switches S' .
  • In-band refers to a control communication path that follows the path for communication in the data plane.
  • phase 4 i.e. before the switch S has an IP address, knows the IP addresses of the respective controllers, and be ⁇ fore the dynamic properties such as forwarding entries, of the switch are set, the packets of further switches S' are not accepted which is depicted by a cross in Fig.l.
  • switches will throw away the incom ⁇ ing packets, e.g. in this case packets originating at S')PnP Discovery packets are distinguished from other broadcast traffic in network by matching on the well-known transport layer port number used in PnP discovery procedure.
  • Replies to both PnP Discovery and DHCP discovery packets, destined for newly added further switches S' can be for ⁇ warded using standard learning switch forwarding techniques, e.g. using output action "NORMAL" in OpenFlow, or by a set of rules which forward the packets that originate from a SDN- Controller and are destined for the further switch S' to be newly added.
  • Fig. 2a an embodiment is depicted where the controller C is directly connected to a first node or switch SI, a second switch S2 and a third switch S3, i.e. all switches or nodes are direct neighbours of the controller. In relation to Fig. 1 they would correspond to a forwarding device or switch S.
  • the communication between the switches SI, S2, S3 and the controller C is not following the paths between the switches. This is referred to as a out of band control network as the control traffic is not following the paths of the data plane, i.e. control traffic's path in out-of-band setup is exclusive for controller-switch communication flow.
  • each of the nodes provides a dedicated management interface for communication with the controller.
  • Newly added switches in the network have a direct connection to SDN-Controller and following the network address association procedure, i.e. send DHCP and PnP discovery packets to a broadcast address on all ports associated with logical switch instance. Since the packets are destined for user-designated or standardized listening ports (as specified in OpenFlow protocol specification) , broadcasted packets are received by the listening SDN-Controller. The TCP or TLS connection establishment and procedure described in Phase 3 then takes place. Actions described in Phase 4 are omitted, since every switch is capable of reaching the SDN-Controller over a di- rect connection or single-hop.
  • Fig. 2b an embodiment is depicted with in-band control channels, with PnP and OpenFlow control packets being for- warded over the SDN-Controller managed data-plane flows with no dedicated management interfaces on nodes in network
  • the in-band controller C i.e. the communication between con- troller and forwarding devices is along the same paths as the communication in the data plane, i.e. exchange of user data, between the switches, is connected directly, i.e. by a dis ⁇ tance of one hop to a first switch SI and indirectly, i.e. by a multi hop distance, to a second switch S2 and a third switch S3.
  • the further switches added in the network which have no di ⁇ rect connection to the controller C, namely the second switch S2 and third switch S3, send the DHCP and PnP Discovery pack- ets to a broadcast address on all ports associated with the respective switch.
  • the packets sent out are destined for user designated (PnP) or standardized listening ports (DHCP, PnP)
  • PnP user designated
  • DHCP, PnP standardized listening ports
  • DHCP and PnP discovery packets are forwarded to the control ⁇ ler C throughout the network based on learning switch flow rules which distinguish input packets based on destination address, e.g. for a L (layer) 2 broadcast in a ethernet the broadcast MAC address or for L3 broadcast in an IP network an IP address, and destination port.
  • replies to these are forwarded to initiating switch based on learning switch flow rules which match by switch' s destination ad- dress, e.g. for L2 in a Ethernet a MAC address or for layer 3 in an IP network the IP address, or using a set of rules which matches the packets originating from SDN-Controller and are destined for the newly added switch.
  • Phase 2 P2 describes a method for automated and self-managed SDN-Controller discovery procedure where SDN devices can simply be "attached" to network, and a self-configuration of address properties can take place. This way, both the logical OpenFlow switch instances' and the SDN controllers' IP, netmask and broadcast addresses, as well as the remote
  • SDN controllers' IP addresses of the main and the alternative in logical OpenFlow switch instances' configuration are managed autonomously.
  • An introduction of an automated addressing scheme in SDN directly decreases the need for engineering and manual configu ⁇ ration of addressing parameters in networks lowers the re ⁇ lated costs, especially when deploying large-scale SDNs, e.g. of multiple 1000s of interconnected switching nodes.
  • logical switch instances are able to share the same hardware/switching fabric but in an isolated manner.
  • a physical switch does not necessarily assume a single switch representation in a network, but can optionally be partitioned in multiple "logical" instances.
  • Each logical instance has a dedicated number of physical interfaces it has access too, and a separate IP and forwarding rules configuration, for reaching SDN controller and forwarding data plane packets, respectively.
  • Logical switch instances can optionally be interconnected via internal interfaces or ports or over physical interfaces or ports.
  • Phase 4 P4 proposes a possible solution to extending the SDN- controller discovery procedure and autonomous configuration of network addresses to support in-band control networks as well, where multi-hop paths in between OpenFlow switches and corresponding SDN-Controllers might need to be taken.
  • pro ⁇ visioning the intermediate switches on such paths with a spe ⁇ cific set of flow rules which match the discovery and control packets and forward these in a deterministic fashion on local output ports, routes in between the SDN switches and SDN-Controllers can be established and endless circulation of broadcast packets in ring-based networks prevented.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention relates to a forwarding device (S,S') for use in a software defined network (SDN) wherein the forwarding device (S,S') is arranged to exchange control data with a controller (C), which assigns an identification address to the forwarding device, and for performing the following steps of Broadcasting a request to receive an identification address of at least one controller (C) and receiving, under the assigned identification address, the at least one controller' s (C) identification address and setting in the forwarding device the at least one controller' s (C) identification address as entry to which control data are forwarded. The invention further relates to a controller and a method.

Description

Description
Forwarding Device, Controller and Method Field of the Invention
The invention relates to a forwarding device to be integrated in a software defined network and a controller for managing forwarding devices in a software defined network and a corre- sponding method.
Background
Software defined networking (SDN) provides an architecture wherein the functionality of lower layers is abstracted for a more effective management of network services. Therefore, within the network, the system is decoupled into so called "planes". Thereof, the control plane decides about where and how the traffic is sent and in the underlying data plane data is forwarded to a selected destination. In other words, con- trol and forwarding functions are separated.
As the lower layer functions are abstracted, this has the consequence that network control become independent from the detailed physical or actual set-up of the lower layers. Net- work control is implemented in controllers which form a logi¬ cally centralised entity which considers the capabilities of the physical network on the one hand and the requirements of the plurality of applications, to be performed on the network on the other hand.
An example of a protocol for communication between the controller and forwarding devices, such as switches, bridges etc. is "OpenFlow". Objectives of SDN are to facilitate networking by e.g.
providing interoperability, scalability and in particular al¬ so flexibility to adjust the network traffic according to the needs and prerequisites. One aspect thereof is the integra¬ tion of new forwarding devices or nodes.
If new devices are to be integrated into a network, they need to be configurated first, e.g. adapted to the network's re¬ quirements. As an example, the configuration sets which IP addresses are to be used and where they are retrieved from.
However, an integration of new devices into a network usually is cumbersome, especially if work has to be done manually.
It is one object of the invention to offer a possibility for an effective integration of forwarding devices into a soft¬ ware defined network.
Brief Summary of the Invention
This is solved by what is disclosed in the independent claims. Advantageous embodiments are subject of the dependent claims.
The invention relates to a forwarding device, e.g. a switch, for use in a software defined network. The forwarding device is arranged to exchange control data with a controller, which assigns an identification address to the forwarding device, and for performing the steps of broadcasting a request to re¬ ceive an identification address of at least one controller; further the step of receiving, under the assigned identifica¬ tion address, the at least one controller's identification address and of setting in the forwarding device the at least one controller' s identification address as entry to which control data are forwarded. Thus, a forwarding device discov¬ ers the existence of a controller and control data may be ex¬ changed between the controller and the forwarding device. By opening this communication capability an integration of a new forwarding device is enabled. The invention further relates to a controller for use in a software defined network, which manages at least one forward¬ ing device by exchanging control data. The controller is arranged for performing the steps of assigning an identifica- tion address to the at least one forwarding device; further of receiving a broadcast for a request to receive the con¬ troller' s identification address and of sending, to the assigned identification address, the controller's identifica¬ tion address. By using such a controller new forwarding de- vices may be integrated in the network automatically, in par¬ ticular in a plug and play mode.
The invention further relates to a corresponding method for integrating a forwarding device into a software defined net- work managed by a controller. The method comprises the fol¬ lowing steps of assigning, by the controller, an identification address to the at least one forwarding device; further of broadcasting, by the forwarding device a request to re¬ ceive an identification address of at least one controller; further of receiving, by the forwarding device under the assigned identification address, the at least one controller's identification address and of setting in the forwarding device the at least one controller' s identification address as entry to which control data are forwarded.
Brief description of the drawings:
Further embodiments, features, and advantages of the present invention will become apparent from the subsequent descrip- tion and dependent claims, taken in conjunction with the ac¬ companying drawings of which show:
Fig. 1: an exemplary sequence diagram showing phases of the process of automatically integrating a switch;
Fig. 2a and b: exemplary embodiments of a SDN network with one controller. In Fig. 1 an exemplary embodiment of a sequence diagram is depicted showing various phases of integrating a forwarding device or switch into a SDN (software defined network) . The progress in time is from top to bottom. The switches in this example are communicating with the SDN controller via the
OpenFlow protocol which has been designed for the communica¬ tion between controllers and switches for setting so called "forwarding tables", i.e. to which entities data are to be forwarded from the respective switch. Other communication protocols may be employed.
In a first phase PI, a network address provision for a SDN controller and forwarding devices takes place. For this, from a forwarding device or switch S, which is a direct neighbour to a SDN controller C, a DHCP discover request is broadcast to the controller C. Direct neighbour means that the switch S is communicating with the controller without an intermediate switch or other device, i.e. over one hop.
The controller C can also provide the functions of a DHCP server, i.e. act as DHCP server itself or providing the DHCP functions in such a way to the switch that the switch S only "sees" the controller and needs not to address a further de¬ vice. In particular a dedicated DHCP server is executed on same host as the SDN-Controller and an SDN forwarding device runs a DHCP client instance. If installed, the DHCP client running on OpenFlow-enabled switches will contact the DHCP server via broadcast messaging, which is run on the SDN Controller and establish its bridge's or switches' network ad¬ dress from the pool of available IP addresses. The controller C answers by sending a DHCP offer message to the switch S an¬ swering the discover request that it can provide IP ad- dresses.
The switch S then broadcasts a DHCP Request message requesting an IP address, which is acknowledged by the con¬ troller C by sending a DHCP acknowledgement message DHCP A back to the switch S wherein the IP address for the switch S is provided.
Thus in the example of an OpenFlow-enabled network switch, the management of designated data plane interfaces or ports of the switch can be done later by the OpenFlow-talking SDN- Controller. In such a way more than one dynamic parameter, e.g. forward entries can be managed with a single IP address.
In regard to the IP address assignment, e.g. either dynamic IP address association or static MAC-IP address associations are achievable with an appropriately configured DHCP server instance. At the beginning, an initial static configuration on SDN switches and SDN-Controller may take place. In particular both, the network addresses of both the SDN- Controller listening for OpenFlow packets, as well as of the OpenFlow-enabled switches or bridges, can be configured statically as well. The SDN-Controller listens for OpenFlow events on its host's interfaces by binding a TCP socket to all available interfaces and listening on a standardized or user-designated port number. Thus, in the first phase an IP address is assigned to the switch which is to be integrated.
In a second phase P2 a SDN controller discovery procedure takes place and the switch S broadcasts a PnP (plug and play) discovery message to all direct neighbours, e.g. broadcast messages are sent not only on specific but on every single switch interface as the position of the controller ( s ) rela¬ tive to the position of the switch in network is unknown. The objective is that the switch receives the IP address of the respective controller ( s ) C and optionally other static pa¬ rameters of the switch. As a result, the forwarding device or switch is integrated into the network. Static parameters are e.g. the IP addresses of controllers, which are in particular valid as long as the switch S is powered on. In particular the switch S sends these PnP discovery messages or packets periodically. These packets are destined for a broadcast address and targeting a well known port number and are sent out on all interfaces which are part of the switch S, destined for all direct neighbours, of which at least one is the controller C.
In this broadcasted PnP Discovery message the IP address of the switch S is contained in the header and can be detected in a step PH where the headers are parsed. From thereon, the switch S can be addressed by the controller C. With this information a safe connection, e.g. a TCP (Transmission Control Protocol) or TLS (transport layer security) connection can be opened and the Open PnP TCP/TLS Connection message is sent unicast. Alternatively other protocols that enable a sage connection may be used.
Across the safe connection the controller C remotely configures a set of possible controllers for the switch S, i.e. provides the IP addresses of the main and alternative con- trollers. In the example thereby the set OF (OpenFlow) Con¬ troller IP message and set OVSDB (Open vSwitch Database Management Protocol) Manager IP message are sent unicast. Then the safe connection is closed and the close PnP connection message is sent unicast. Thus the control plane of the switch S is organised and therewith the switch integrated in the network, such that it can forward data.
In a third phase P3 a TCP/IP Connection is opened, e.g. an OpenFlow channel is established. Based on the previously es- tablished Controller IP address entries, the switch S will reattempt to establish the unicast connection, e.g. TCP or TLS connection, to one or more of the controllers C in a separate TCP/TLS channel used for OpenFlow-based communica- tion. In this OpenFlow-based communication dynamic parameters of the switch are set such as the forwarding entries for individual ports. After finalizing the discovery process, the "OFPT_HELLO" messages are exchanged and standard OpenFlow messaging initiated, which is in particular used for running conditions .
In a fourth phase P4 default flow rules for matching discovery packets are provided to the switch S. The objective thereof is to integrate also forwarding devices or further switches S' that are several hops away from the controller into the network, i.e. need to communication across a further forwarding device with the switch. This is done by providing rules to the directly connected switches S on how various data are to be forwarded.
Via in-band OpenFlow rules, the connected switches S forward the DHCP and PnP Discovery packets, originating from further switches S' which have no direct connection with the SDN- Controller, to the main or alternative controller ( s ) and re¬ spective replies to newly added further switches S' .
In-band refers to a control communication path that follows the path for communication in the data plane.
Before phase 4, i.e. before the switch S has an IP address, knows the IP addresses of the respective controllers, and be¬ fore the dynamic properties such as forwarding entries, of the switch are set, the packets of further switches S' are not accepted which is depicted by a cross in Fig.l.
In other words, as long as there are no forwarding flow-rules configured in the switch, switches will throw away the incom¬ ing packets, e.g. in this case packets originating at S')PnP Discovery packets are distinguished from other broadcast traffic in network by matching on the well-known transport layer port number used in PnP discovery procedure. Replies to both PnP Discovery and DHCP discovery packets, destined for newly added further switches S' , can be for¬ warded using standard learning switch forwarding techniques, e.g. using output action "NORMAL" in OpenFlow, or by a set of rules which forward the packets that originate from a SDN- Controller and are destined for the further switch S' to be newly added.
In Fig. 2a an embodiment is depicted where the controller C is directly connected to a first node or switch SI, a second switch S2 and a third switch S3, i.e. all switches or nodes are direct neighbours of the controller. In relation to Fig. 1 they would correspond to a forwarding device or switch S. The communication between the switches SI, S2, S3 and the controller C is not following the paths between the switches. This is referred to as a out of band control network as the control traffic is not following the paths of the data plane, i.e. control traffic's path in out-of-band setup is exclusive for controller-switch communication flow.
Preferably each of the nodes provides a dedicated management interface for communication with the controller.
Newly added switches in the network have a direct connection to SDN-Controller and following the network address association procedure, i.e. send DHCP and PnP discovery packets to a broadcast address on all ports associated with logical switch instance. Since the packets are destined for user-designated or standardized listening ports (as specified in OpenFlow protocol specification) , broadcasted packets are received by the listening SDN-Controller. The TCP or TLS connection establishment and procedure described in Phase 3 then takes place. Actions described in Phase 4 are omitted, since every switch is capable of reaching the SDN-Controller over a di- rect connection or single-hop.
In Fig. 2b an embodiment is depicted with in-band control channels, with PnP and OpenFlow control packets being for- warded over the SDN-Controller managed data-plane flows with no dedicated management interfaces on nodes in network
The in-band controller C, i.e. the communication between con- troller and forwarding devices is along the same paths as the communication in the data plane, i.e. exchange of user data, between the switches, is connected directly, i.e. by a dis¬ tance of one hop to a first switch SI and indirectly, i.e. by a multi hop distance, to a second switch S2 and a third switch S3.
The further switches added in the network, which have no di¬ rect connection to the controller C, namely the second switch S2 and third switch S3, send the DHCP and PnP Discovery pack- ets to a broadcast address on all ports associated with the respective switch. The packets sent out are destined for user designated (PnP) or standardized listening ports (DHCP, PnP) A specific standardized listening port can be specified or it is being left to the implementation which port number is go- ing to be used for the PnP connection.
DHCP and PnP discovery packets are forwarded to the control¬ ler C throughout the network based on learning switch flow rules which distinguish input packets based on destination address, e.g. for a L (layer) 2 broadcast in a ethernet the broadcast MAC address or for L3 broadcast in an IP network an IP address, and destination port. Analogously, replies to these are forwarded to initiating switch based on learning switch flow rules which match by switch' s destination ad- dress, e.g. for L2 in a Ethernet a MAC address or for layer 3 in an IP network the IP address, or using a set of rules which matches the packets originating from SDN-Controller and are destined for the newly added switch. Thus the embodiments offer a novel approach to the process of discovery of the existence of a controller C in a software defined network, in particular to an open flow controller. This is described in relation with phases 2 for devices hav- ing a direct or one hop connection with the switch and in relation with phase 4 for indirectly or multi-hop connected de¬ vices. Phase 2 P2 describes a method for automated and self-managed SDN-Controller discovery procedure where SDN devices can simply be "attached" to network, and a self-configuration of address properties can take place. This way, both the logical OpenFlow switch instances' and the SDN controllers' IP, netmask and broadcast addresses, as well as the remote
SDN controllers' IP addresses of the main and the alternative in logical OpenFlow switch instances' configuration, are managed autonomously.
An introduction of an automated addressing scheme in SDN directly decreases the need for engineering and manual configu¬ ration of addressing parameters in networks lowers the re¬ lated costs, especially when deploying large-scale SDNs, e.g. of multiple 1000s of interconnected switching nodes.
In particular, logical switch instances are able to share the same hardware/switching fabric but in an isolated manner. A physical switch does not necessarily assume a single switch representation in a network, but can optionally be partitioned in multiple "logical" instances. Each logical instance has a dedicated number of physical interfaces it has access too, and a separate IP and forwarding rules configuration, for reaching SDN controller and forwarding data plane packets, respectively. Logical switch instances can optionally be interconnected via internal interfaces or ports or over physical interfaces or ports.
Phase 4 P4 proposes a possible solution to extending the SDN- controller discovery procedure and autonomous configuration of network addresses to support in-band control networks as well, where multi-hop paths in between OpenFlow switches and corresponding SDN-Controllers might need to be taken. By pro¬ visioning the intermediate switches on such paths with a spe¬ cific set of flow rules, which match the discovery and control packets and forward these in a deterministic fashion on local output ports, routes in between the SDN switches and SDN-Controllers can be established and endless circulation of broadcast packets in ring-based networks prevented.
Although the present invention has been described in accor- dance with preferred embodiments, in particular in regard to the OF and OVSDB protocols, it is obvious for the person skilled in the art that modifications or combination between the embodiments, fully or in one or more aspects, are possi¬ ble in all embodiments.

Claims

Forwarding device (S,S') for use in a software defined network (SDN), wherein the forwarding device (S,S') is arranged to exchange control data with a controller (C) , which has assigned an identification address to the forwarding device, and is arranged to perform the following steps:
a. Broadcasting a request to receive an identifica¬ tion address of at least one controller (C) ; b. Receiving, addressed by the assigned identifica¬ tion address, the at least one controller's (C) identification address;
c. Setting in the forwarding device the at least one controller' s (C) identification address as entry to which control data are forwarded.
Forwarding device (S, S' ) according to claim 1, which is further arranged to forward user data to at least one other forwarding device (S, S' ) .
Forwarding device (S, S' ) according to any of the pre¬ vious claims, wherein in step b a main controller's (C) identification address is provided and an identi¬ fication address of at least one substitute controller (C) .
Forwarding device (S, S' ) according to any of the pre¬ vious claims, wherein the identification address is an IP address.
Forwarding device (S, S' ) according to any of the pre¬ vious claims, wherein the identification address is assigned to the forwarding device' (S,S') by perform¬ ing the steps of
i . Broadcasting a request for an identification address to be assigned to the forwarding device (S, S' ) and of ii. Receiving the identification address from the controller .
Forwarding device (S) according to any of the previous claims, which is directly connected to the at least one controller (C) and forwards control data from other forwarding devices (S, S' ) according to rules provided by the at least one controller (C) .
Forwarding device (S' ) according to any of the previous claims, which is connected to the at least one controller (C) via at least one intermediate forward¬ ing device (S, S' ) between the further forwarding device (S' ) and the controller (C) .
Forwarding device (S, S' ) according to any of the pre¬ vious claims, wherein for the exchange of control data comprising in particular the identification address of the controller (C) an OVSDB protocol is used.
Forwarding device (S, S' ) according to any of the pre¬ vious claims, which is arranged for performing the further step of receiving control data from the controller (C) , said control data denoting at least one forwarding entry, in particular using an OpenFlow protocol for receiving control data in relation to forwarding entries.
Controller (C) for use in a software defined network (SDN) to manage at least one forwarding device (S, S' ) by exchanging control data, arranged for performing the following steps:
a. Assigning an identification address to the at least one forwarding device (S, S' ) ;
b. Receiving a broadcast request to send the con¬ troller' s (C) identification address to the forwarding device; c. Sending, to the assigned identification address, the controller's (C) identification ad¬ dress;
Controller (C) according to the previous claim 10, wherein the sending according to step c further comprises sending of at least one further, substitute controller's (C) identification address.
Controller (C) according to any of the previous claims 10 or 11, wherein the controller (C) comprises a DHCP server .
Controller (C) according to any of the previous claims 10 to 12, wherein the assigning in step a. comprises the steps of
a.l Receiving a broadcast request for an identifi¬ cation address to be assigned to the at least one forwarding device (S, S' ) ;
a.2 Sending unicast the identification address to the at least one forwarding device (S, S' ) .
Method for integrating a forwarding device (S, S' ) into a software defined network (SDN) managed by a controller (C) comprising the following steps:
a. address to the at least one forwarding device (S, S');
b. Broadcasting, by the forwarding device (S, S' ) a request to send an identification address of at least one controller (C) to the forwarding device ;
c. Receiving, by the forwarding device (S, S' ) ad¬ dressed by the assigned identification address Assigning, by the controller (C) , an identification, the at least one controller' s (C) identification address;
d. Setting in the forwarding device (S, S' ) the at least one controller' s (C) identification ad- dress as entry to which control data are for¬ warded .
PCT/EP2015/064345 2015-06-25 2015-06-25 Forwarding device, controller and method WO2016206741A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/064345 WO2016206741A1 (en) 2015-06-25 2015-06-25 Forwarding device, controller and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/064345 WO2016206741A1 (en) 2015-06-25 2015-06-25 Forwarding device, controller and method

Publications (1)

Publication Number Publication Date
WO2016206741A1 true WO2016206741A1 (en) 2016-12-29

Family

ID=53541642

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/064345 WO2016206741A1 (en) 2015-06-25 2015-06-25 Forwarding device, controller and method

Country Status (1)

Country Link
WO (1) WO2016206741A1 (en)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018145267A1 (en) * 2017-02-08 2018-08-16 华为技术有限公司 Forwarder network-access recognition method, sdn controller, and forwarder
WO2019000332A1 (en) * 2017-06-29 2019-01-03 华为技术有限公司 Method and device for establishing connection between switch and controller
EP3461081A1 (en) 2017-09-22 2019-03-27 Siemens Aktiengesellschaft Method for operating a communication network comprising multiple communication devices of an industrial automation system, control unit and communication device
EP3462673A1 (en) 2017-09-29 2019-04-03 Siemens Aktiengesellschaft Method for operating a communication network of an industrial automation system and control device
EP3499798A1 (en) 2017-12-15 2019-06-19 Siemens Aktiengesellschaft Method for transmitting data within an industrial communication network and network controller
CN110691151A (en) * 2019-10-09 2020-01-14 广州市品高软件股份有限公司 Distributed equipment IP address distribution management method and system
US10560390B2 (en) 2018-03-05 2020-02-11 Schweitzer Engineering Laboratories, Inc. Time-based network operation profiles in a software-defined network
US10581684B2 (en) 2017-12-06 2020-03-03 Schweitzer Engineering Laboratories, Inc. Network management via a secondary communication channel in a software defined network
US10756956B2 (en) 2018-03-05 2020-08-25 Schweitzer Engineering Laboratories, Inc. Trigger alarm actions and alarm-triggered network flows in software-defined networks
US10812392B2 (en) 2018-03-05 2020-10-20 Schweitzer Engineering Laboratories, Inc. Event-based flow control in software-defined networks
US11012442B2 (en) 2019-04-11 2021-05-18 Schweitzer Engineering Laboratories, Inc. Address resolution protocol response handling
US11201759B1 (en) 2020-07-08 2021-12-14 Schweitzer Engineering Laboratories, Inc. Reconfigurable dual-ring network redundancy
US11425033B2 (en) 2020-03-25 2022-08-23 Schweitzer Engineering Laboratories, Inc. SDN flow path modification based on packet inspection
US20220417148A1 (en) * 2014-06-25 2022-12-29 Huawei Technologies Co., Ltd. Packet Processing Method and Apparatus
US11677663B2 (en) 2021-08-12 2023-06-13 Schweitzer Engineering Laboratories, Inc. Software-defined network statistics extension
US11882002B2 (en) 2022-06-22 2024-01-23 Schweitzer Engineering Laboratories, Inc. Offline test mode SDN validation

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130268686A1 (en) * 2012-03-14 2013-10-10 Huawei Technologies Co., Ltd. Method, switch, server and system for sending connection establishment request
WO2014108178A1 (en) * 2013-01-09 2014-07-17 Telefonaktiebolaget L M Ericsson (Publ) Connecting a booting switch to a network
US20140211661A1 (en) * 2013-01-25 2014-07-31 Argela Yazilim Ve Bilisim Teknolojileri San. Ve. Tic. A.S. Automatic Discovery of Multiple Controllers in Software Defined Networks (SDNs)
EP2800304A1 (en) * 2013-04-30 2014-11-05 Telefonaktiebolaget L M Ericsson (Publ) Technique for configuring a Software-Defined Network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130268686A1 (en) * 2012-03-14 2013-10-10 Huawei Technologies Co., Ltd. Method, switch, server and system for sending connection establishment request
WO2014108178A1 (en) * 2013-01-09 2014-07-17 Telefonaktiebolaget L M Ericsson (Publ) Connecting a booting switch to a network
US20140211661A1 (en) * 2013-01-25 2014-07-31 Argela Yazilim Ve Bilisim Teknolojileri San. Ve. Tic. A.S. Automatic Discovery of Multiple Controllers in Software Defined Networks (SDNs)
EP2800304A1 (en) * 2013-04-30 2014-11-05 Telefonaktiebolaget L M Ericsson (Publ) Technique for configuring a Software-Defined Network

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11855891B2 (en) * 2014-06-25 2023-12-26 Huawei Technologies Co., Ltd. Packet processing method and apparatus
US20220417148A1 (en) * 2014-06-25 2022-12-29 Huawei Technologies Co., Ltd. Packet Processing Method and Apparatus
WO2018145267A1 (en) * 2017-02-08 2018-08-16 华为技术有限公司 Forwarder network-access recognition method, sdn controller, and forwarder
WO2019000332A1 (en) * 2017-06-29 2019-01-03 华为技术有限公司 Method and device for establishing connection between switch and controller
EP3461081A1 (en) 2017-09-22 2019-03-27 Siemens Aktiengesellschaft Method for operating a communication network comprising multiple communication devices of an industrial automation system, control unit and communication device
EP3462673A1 (en) 2017-09-29 2019-04-03 Siemens Aktiengesellschaft Method for operating a communication network of an industrial automation system and control device
US10581684B2 (en) 2017-12-06 2020-03-03 Schweitzer Engineering Laboratories, Inc. Network management via a secondary communication channel in a software defined network
EP3499798A1 (en) 2017-12-15 2019-06-19 Siemens Aktiengesellschaft Method for transmitting data within an industrial communication network and network controller
US10756956B2 (en) 2018-03-05 2020-08-25 Schweitzer Engineering Laboratories, Inc. Trigger alarm actions and alarm-triggered network flows in software-defined networks
US10812392B2 (en) 2018-03-05 2020-10-20 Schweitzer Engineering Laboratories, Inc. Event-based flow control in software-defined networks
US10560390B2 (en) 2018-03-05 2020-02-11 Schweitzer Engineering Laboratories, Inc. Time-based network operation profiles in a software-defined network
US11012442B2 (en) 2019-04-11 2021-05-18 Schweitzer Engineering Laboratories, Inc. Address resolution protocol response handling
CN110691151B (en) * 2019-10-09 2020-09-22 广州市品高软件股份有限公司 Distributed equipment IP address distribution management method and system
CN110691151A (en) * 2019-10-09 2020-01-14 广州市品高软件股份有限公司 Distributed equipment IP address distribution management method and system
US11425033B2 (en) 2020-03-25 2022-08-23 Schweitzer Engineering Laboratories, Inc. SDN flow path modification based on packet inspection
US11201759B1 (en) 2020-07-08 2021-12-14 Schweitzer Engineering Laboratories, Inc. Reconfigurable dual-ring network redundancy
US11677663B2 (en) 2021-08-12 2023-06-13 Schweitzer Engineering Laboratories, Inc. Software-defined network statistics extension
US11882002B2 (en) 2022-06-22 2024-01-23 Schweitzer Engineering Laboratories, Inc. Offline test mode SDN validation

Similar Documents

Publication Publication Date Title
WO2016206741A1 (en) Forwarding device, controller and method
US11115375B2 (en) Interoperability between data plane learning endpoints and control plane learning endpoints in overlay networks
EP3681110B1 (en) A region interconnect control using vrf tables across heterogeneous networks
US9385949B2 (en) Routing controlled by subnet managers
CN106936777B (en) Cloud computing distributed network implementation method and system based on OpenFlow
KR102018395B1 (en) Packet broadcast mechanism in a split architecture network
KR101503629B1 (en) Differential forwarding in address-based carrier networks
WO2016177030A1 (en) Method, device and system for establishing link of sdn network device
US8848609B2 (en) Forwarding internet protocol version 6 link-local multicast to support roaming of wireless mobile client devices
US11025497B2 (en) Network fabric topology expansion and self-healing devices
US8958305B2 (en) OSPF point-to-multipoint over broadcast or NBMA mode
CN103763207A (en) In-band control connection establishment method and device in SDN
WO2016058329A1 (en) Service transfer method and device
US9729948B1 (en) Systems and methods for discovery of a controller in openflow networks
JP2009512287A (en) Ethernet GMPLS control
US20160050147A1 (en) Distributing route
CN107204907B (en) Cloud data center interconnection method and device
US20190342262A1 (en) Zero touch provisioning of a network element through a Network Address Translation gateway
US9083650B2 (en) Overlay network
US20150341253A1 (en) Connecting a booting switch to a network
US10439961B2 (en) Network fabric control
CN108880969B (en) Method and device for establishing link in SDN network
US9438475B1 (en) Supporting relay functionality with a distributed layer 3 gateway
US20140136714A1 (en) Method for exchanging information about network resources
CN110380900B (en) Network configuration system based on SDN

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15736418

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15736418

Country of ref document: EP

Kind code of ref document: A1