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
Grant status
Application
Patent type
Prior art keywords
controller
forwarding device
address
identification address
according
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

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/08Configuration management of network or network elements
    • H04L41/0803Configuration setting of network or network elements
    • H04L41/0806Configuration setting of network or network elements for initial configuration or provisioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/12Arrangements for maintenance or administration or management of packet switching networks network topology discovery or management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/20Address allocation
    • H04L61/2007Address allocation internet protocol [IP] addresses
    • H04L61/2015Address allocation internet protocol [IP] addresses using the dynamic host configuration protocol [DHCP] or variants

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 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)

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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Similar Documents

Publication Publication Date Title
US6449279B1 (en) Aggregation of data flows over a pre-established path to reduce connections
US20060002370A1 (en) VLAN support of differentiated services
US20060274744A1 (en) Dynamic VLAN ID assignment and packet transfer apparatus
US20050271035A1 (en) Method for enabling multipoint network services over a ring topology network
US20140006585A1 (en) Providing Mobility in Overlay Networks
US20050220096A1 (en) Traffic engineering in frame-based carrier networks
US20140044126A1 (en) Scalable Media Access Control Protocol Synchronization Techniques for Fabric Extender Based Emulated Switch Deployments
US20140307744A1 (en) Service Chain Policy for Distributed Gateways in Virtual Overlay Networks
WO2012093429A1 (en) Communication control system, control server, forwarding node, communication control method, and communication control program
US20140112122A1 (en) System and method for optimizing next-hop table space in a dual-homed network environment
US20130266012A1 (en) System and method for implementing multiple label distribution protocol (ldp) instances in a network node
US8369335B2 (en) Method and system for extending routing domain to non-routing end stations
US20130100851A1 (en) Multicast Source Move Detection for Layer-2 Interconnect Solutions
US7009983B2 (en) Methods and apparatus for broadcast domain interworking
US20060041650A1 (en) Method and system for cluster managing of network facilities
Detti et al. Wireless mesh software defined networks (wmSDN)
US20100135265A1 (en) Dynamic eqam discovery in m-cmts architecture
US9055000B1 (en) Distributed network subnet
CN102857416A (en) Method for implementing virtual network and virtual network
US20090234969A1 (en) Automatic MEP Provisioning in a Link State Controlled Ethernet Network
US20130188514A1 (en) Managing a cluster of switches using multiple controllers
US7421483B1 (en) Autodiscovery and self configuration of customer premise equipment
US20050013307A1 (en) Method for bridging traffic on a PLC LAN segment
US7623446B1 (en) MPLS virtual rings
US6912205B2 (en) Autoconfiguring IP routers

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 in:

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