Network element and a controller for managing the network element

#The invention relates generally to a software-defined network “SDN”. More particularly, the invention relates to a network element for a software-defined network and to a controller of a software-defined network. Furthermore, the invention relates to a method for enabling a controller of a software-defined network to manage a network element and to a method for managing a network element of a software-defined network. Furthermore, the invention relates to a computer program for a network element of a software-defined network and to a computer program for a controller of a software-defined network.

#Software-defined networking is an emerging architecture for data transfer networks. In a software-defined network “SDN”, the control plane is separated from the data plane so that the control plane is implemented in one or more controllers that can be separate from the network elements and the data plane is implemented in the network elements. The network elements can be, for example, Internet Protocol “IP” routers, multiprotocol label switching “MPLS” nodes, packet optical switches, and/or Ethernet switches. Each network element may consist of a single apparatus or a combination of a plurality of apparatuses. Typically, the software-defined networking allows for quick experimenting and optimization of switching and/or routing policies and external access to the innards of network elements that formerly were closed and proprietary.

#Internet Protocol “IP” based networks were initially built based on the concept of Autonomous Systems “AS”. This concept allows networks to scale and extend by connected junctions that forward packets to a reasonable next hop based on partial need-to-know information. The AS principle works much like the traditional post office service, where a postal worker in a given city does not need to know all the tenants of all the streets in another city in order to choose a reasonable next hop for a letter at hand. This approach to networking is simple, and has proven resilient and scalable. This approach has, however, a few drawbacks. It does not allow the designated destinations, or tenants with home mail-boxes, to move without changing their identity as far as the packet delivery service is concerned. The topological location of destinations, which is the network interface they are attached to, dictates their identity related to the packet delivery service. In addition, using only the basic AS principle, it is hard to specify other qualities, such as logical grouping, access control, quality of service, intermediate network processing, or to specify aspects that relate to a sequence of packets that form a flow.

#The exemplifying and non-limiting embodiments of the invention and their advantages are explained in greater detail below with reference to the accompanying drawings, in which:

#FIG. 1 shows a schematic illustration of a software-defined network comprising network elements according to an exemplifying embodiment of the invention and controllers according to an exemplifying embodiment of the invention,

#FIG. 2 shows a schematic illustration of a controller according to an exemplifying embodiment of the invention for managing a network element of a software-defined network,

#FIG. 1 shows a schematic illustration of an exemplifying software-defined network “SDN” 100. The software-defined network comprises network elements 101, 102, 103, and 104. The software-defined network 100 further comprises controllers 105 and 106 that can be deemed to constitute a controller system of the software-defined network. The network elements 101-104 of this exemplifying software-defined network are mutually interconnected with data transfer links as illustrated in FIG. 1. Furthermore, the exemplifying software-defined network “SDN” 100 may comprise other network elements that are not shown in FIG. 1. Each of the network elements may be e.g. an Internet Protocol “IP” router, a multiprotocol label switching “MPLS” node, a packet optical switch, and/or an Ethernet switch. Each network element may consist of a single apparatus or a combination of a plurality of apparatuses. As well, each of the controllers 105 and 106 may consist of a single apparatus or a combination of a plurality of apparatuses. In the exemplifying case illustrated in FIG. 1, the controller 105 comprises two interconnected apparatuses. A user-interface device 107 is connected to the controller 105, and correspondingly a user-interface device 108 is connected to the controller 106. In the exemplifying case illustrated in FIG. 1, the network element 102 acts as a gateway to an external network 109 that can be e.g. the global Internet. It is to be noted that the controller 105 or one or more parts of it can also act as one or more network elements that can be e.g. an Internet Protocol “IP” router, a multiprotocol label switching “MPLS” switch, a packet optical switch, and/or an Ethernet switch. Correspondingly, the controller 106 or one or more parts of it can also act as one or more network elements of the kind mentioned above.

#Without limiting generality and for illustrative purposes, we consider the operation of the controller 105. The controller 106 may operate in the similar way, and/or the controller 106 may constitute a backup for the controller 105. The controller 105 is adapted to send, to at least one of the network elements 101-104, configuration data enabling the network element under consideration to construct a configuration system that enables the network element to manage data in a desired manner. The configuration system comprises typically a system of interconnected look-up tables defining actions to be carried out in different operational situations. The data can be in form of data frames such as for example Internet Protocol IP-packets, MPLS-labeled frames, Ethernet frames, or the data can be in some other form accordant with one or more data transfer protocols being used. The controller 105 can be adapted to configure the network element under consideration in accordance with the OpenFlow or some other suitable protocol. The OpenFlow is managed by the Open Networking Foundation “ONF”. In the exemplifying case where the OpenFlow is used, the configuration system comprises a look-up system that may include one or more successive flow tables and a group table. Each flow table contains a set of flow entries. Each flow entry may consist of match fields, counters, and a set of actions to apply to matching data frames. The group table contains group entries, where each group entry may contain a list of actions to be directed to data frames defined to belong to a particular group. Furthermore, the configuration data that is sent to one or more of the network elements 101-104 may define one or more configuration programs each of which comprising one or more computer executable instructions defining an action or a chain of actions to be executed in conjunction with managing data in the network element under consideration. The action or the chain of actions defined by the configuration program may comprise for example: recording data into a memory, modifying the data, selecting one or more of egress ports of the network element and forwarding the data and its possible duplicates to the selected one or more egress ports, selecting one or more look-up tables of the configuration system of the network element and executing one or more look-ups from the selected look-up tables, performing arithmetic operations, branching operations, performing logical operations, reading metadata associated with the data being managed, writing metadata associated with the data, modifying metadata associated with the data, dropping the data, and/or duplicating the data.

#In the software-defined network 100, many different events which may cause a need to verify the configuration system of one or more of the network elements 101-104 may take place. The verb “to verify” is to be understood in the broad sense so that it may cover for example checking the integrity of the configuration system, restoring the integrity of configuration system, reconstructing the configuration system, constructing a part of the configuration system, and/or any other process for ensuring the congruency between the configuration system and the status of the controller under consideration. Events causing the need to verify the configuration system can be, for example, a case where a data transfer connection between the controller and the network element has been lost and subsequently re-established, a case where the operational responsibility is received by the network element from another network element, a case where the management responsibility is received by the controller from another controller, a case where the controller sends to the network element a notice message indicating the need to verify the configuration system, etc.