WO2017121475A1 - Gestion de mobilité dans des systèmes sdn - Google Patents

Gestion de mobilité dans des systèmes sdn Download PDF

Info

Publication number
WO2017121475A1
WO2017121475A1 PCT/EP2016/050603 EP2016050603W WO2017121475A1 WO 2017121475 A1 WO2017121475 A1 WO 2017121475A1 EP 2016050603 W EP2016050603 W EP 2016050603W WO 2017121475 A1 WO2017121475 A1 WO 2017121475A1
Authority
WO
WIPO (PCT)
Prior art keywords
forwarding
forwarding unit
unit
control unit
mobile entity
Prior art date
Application number
PCT/EP2016/050603
Other languages
English (en)
Inventor
Zoran Despotovic
Artur Hecker
Clarissa Marquezan
David Perez
Ramin KHALILI
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to PCT/EP2016/050603 priority Critical patent/WO2017121475A1/fr
Publication of WO2017121475A1 publication Critical patent/WO2017121475A1/fr

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/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
    • 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/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H04L41/083—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for increasing network speed
    • 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/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
    • H04W36/00837—Determination of triggering parameters for hand-off
    • H04W36/008375—Determination of triggering parameters for hand-off based on historical data

Definitions

  • the present invention relates to the technical field of data transmission networks, in particular to components used in software defined networks, SDN. Specifically, the present invention relates to a control unit (may also be referred to as controller) for a SDN system, an SDN system, a method for configuring an SDN system.
  • a control unit may also be referred to as controller for a SDN system, an SDN system, a method for configuring an SDN system.
  • SDN Software defined networking, SDN, is an approach that basically relates to decoupling the management and controlling tasks from data packet forwarding tasks.
  • the management and controlling tasks are usually referred to as control plane whereas the forwarding tasks are referred to as data plane.
  • This decoupling can simplify the structure of a network and can standardize interfaces between individual components and between the control and data plane.
  • the data plane is configured such that it necessarily requires control commands from the control plane in order to meet the forwarding tasks.
  • the ' intelligence ' of an SDN system is provided in the control plane whereas the data plane simply carries out commands and instructions received from the control plane.
  • OpenFlow One mechanism which relates to and defines the communication between the control plane and the data plane is OpenFlow. It should be understood that any reference to OpenFlow in the following generally relates to any mechanisms and interfaces which define the
  • OpenFlow is made representative for any of these mechanisms and interfaces.
  • a typical SDN network is composed of simple switches (or forwarding elements) in the forwarding plane and an intelligent SDN controller that configures how those switches behave by installing flow (or forwarding) rules on the switches.
  • the flow rules can be thought of as match-action pairs.
  • the context information (such as the incoming switch port), header and/or other parts of an incoming data flow, frame, packet, datagram or segment (in the following called packet for simplicity) may be matched to the contents of the flow table of the switch, and, in case of a match, the switch may trigger actions, such as forwarding to a certain port, dropping the packet altogether, redirecting the packet to the controller and so on.
  • the switch can send what is called a PACKETJN consisting of the incoming packet as well as some switch context information (such as incoming port) to the controller.
  • the controller may analyse this PACKETJN (or an application on top of the controller) and, which consequently typically will result in either i) installation of new flow rules on some switches, e.g. to handle future packets somehow corresponding to the initial one and/or ii) sending out of some packets, e.g. relaying the originally received one.
  • the controller is an entity that gathers and keeps an up-to-date per-flow network state.
  • SDN plays a role only at transport infrastructure level and the emphasis is on implementing the evolved packet core, EPC, concepts as they are, not changing them or proposing different solutions.
  • S. Matsushima and R. Wakikawa Stateless user-plane architecture for virtualized EPC, IETF Internet-Draft, 2013 describes an architecture for virtualized EPC, keeping the same architectural elements as EPC as well as GTP (General Packet Radio Service Tunneling Protocol) tunnels.
  • GTP General Packet Radio Service Tunneling Protocol
  • a control unit for a software defined networking, SDN, system is provided.
  • the control unit is configured to send configuration data to a forwarding unit of the SDN system, wherein the configuration data relates at least to configuration of a data packet handling task which is to be executed by the forwarding unit.
  • the control unit is further configured to determine an identifier of a mobile entity having established a communication link to a first forwarding unit for the SDN system and to send second configuration data to a second forwarding unit for the SDN system, wherein the second configuration data relates to handling data packets sent by or addressed to the mobile entity.
  • the control unit is configured to send the second configuration data to the second forwarding unit while the mobile entity has the communication link to the first forwarding unit, wherein the second forwarding unit is a forwarding unit serving the mobile entity after termination of the communication link between the mobile entity and the first forwarding unit.
  • the control unit may be referred to as a controller of an SDN, while the forwarding unit may be referred to as a switch of the SDN.
  • the configuration data may relate to the configuration and/or functioning of a forwarding unit.
  • a data packet forwarding task relates to the core task of the forwarding units, namely carrying out data packet forwarding according to the installed forwarding rules.
  • Configuration data generally indicates the ability of the controller to configure the switches according to a configuration policy (e.g., any switch receives its own set of forwarding rules which generally can be referred to as configuration data) while second configuration data relates to the specific commands which are sent to prepare the second switch for mobility management actions like hand over and the subsequent actions, for example.
  • a configuration policy e.g., any switch receives its own set of forwarding rules which generally can be referred to as configuration data
  • second configuration data relates to the specific commands which are sent to prepare the second switch for mobility management actions like hand over and the subsequent actions, for example.
  • the second forwarding unit is configured to handle data packet forwarding tasks related to the mobile entity before the mobile entity gets connected to the second forwarding unit. This may be referred to as proactive configuration of the second forwarding unit, wherein the second forwarding unit is a forwarding unit serving the mobile entity after termination of the communication link between the mobile entity and the first forwarding unit.
  • the mobile entity may be any mobile equipment, for example a mobile phone or other user equipment.
  • the first and second forwarding units may be access points for providing the mobile entity access to the SDN system.
  • the mobile entity can have access to the SDN via either of these forwarding units and may in particular change its current access point in case of changing its position relative to the forwarding units.
  • the changing of an access point can be referred to as handover.
  • the mobile entity may use an identifier for enabling the SDN to identify it.
  • the identifier of the mobile entity may be any address for identifying the mobile entity in the network, for example an IP Address (internet protocol address).
  • IP Address internet protocol address
  • the identifier is needed in order to be able to recognize movement of the mobile entity in the SDN and in order to apply the correct proactively installed flow rules to data packets sent by or sent to said mobile entity.
  • Termination of the communication link between the mobile entity and the first forwarding unit relates to any kind of interruption of the communication link, in particular as a result of a movement of the mobile entity, where the movement results in that the mobile entity leaves a range or a coverage area of the first forwarding unit and thus requires a connection to another forwarding unit (or access point) for establishing a connection to the SDN system.
  • the second forwarding unit is a forwarding unit serving the mobile entity either directly after termination of said communication link to the first forwarding unit (for example handover from the first to the second forwarding unit) or it may alternatively be a forwarding unit serving the mobile entity at a point in time sometimes after the termination of said communication link to the first forwarding unit, for example in a scenario where the mobile entity is handed over from the first forwarding unit to a third forwarding unit and subsequently to the second forwarding unit.
  • the second forwarding unit is enabled to initiate actions in case the mobile entity changes its SDN access point from the first forwarding unit to the second forwarding unit. These actions can be initiated by the second forwarding unit without asking the controller of the SDN. As a result, congestion of the control plane and load of the controller is reduced such that the management of scalable networks (like mobile wireless communication networks as LTE, long term evolution, for example) can be improved.
  • scalable networks like mobile wireless communication networks as LTE, long term evolution, for example
  • control unit is configured to send the second configuration data to more than one forwarding unit except for the first forwarding unit while the mobile entity has the communication link to the first forwarding unit.
  • the first forwarding unit has two or more neighboring forwarding units and a prediction relating to the movement of the mobile entity cannot be reliably made
  • two or more or all of the neighboring forwarding units can be proactively configured in order to be able to handle data packets related to the mobile entity without asking the controller of the SDN.
  • control unit is configured to determine the physical location of each one of the more than one forwarding unit and to send the second configuration data to at least one of those of the more than one forwarding unit which are located adjacent to the first forwarding unit.
  • At least one forwarding unit is assigned to any one of these cells (for example, the switch may be part of a base station) and a mobile entity is connected to that one of the switches which is assigned to the cell where the mobile entity is physically located.
  • the control unit is configured to send the second configuration data to all of those of the more than one forwarding unit which are located adjacent to the first forwarding unit.
  • the second configuration data comprises a forwarding rule which is configured to be applied to data packets sent by or addressed to the mobile entity.
  • a forwarding rule (or a flow rule) can be transmitted to the switch and activated at the switch such that the switch forwards data packets according to the actions defined in the forwarding rule.
  • a forwarding rule typically contains a match field and an action field. Fields of incoming data packets are compared with the match field of the active forwarding rules of a forwarding unit. If the match fields of a forwarding rule match the corresponding fields of a data packet, this can be referred to as a match. In case of a match, the assigned action of the forwarding rule is carried out, for example send the data packet via output port 3 to the next hop.
  • a forwarding rule is proactively installed at the second switch at the time when the mobile entity is still connected or assigned to the first forwarding rule.
  • the communication overhead in case of a handover is reduced and the time for configuring the second forwarding unit if the mobile entity uses the second forwarding unit as an access point to the SDN can be reduced because no time consuming communication between the second forwarding unit and the controller is necessary in order to handle the data packets sent by or addressed to the mobile entity.
  • control unit is configured to store information about a configuration status of any forwarding unit of the SDN system, wherein the configuration status of a forwarding unit comprises at least one forwarding rule of the forwarding unit.
  • This information about the configuration status of the forwarding units may be stored in a flow information database (FID), which is a module of the control unit.
  • FID flow information database
  • the configuration status of the switches may be helpful for a reliable prediction of the probable movement of a mobile entity. Having an overview about the configuration status and its changing in the past, a prediction may be made more reliable.
  • control unit is configured to store transactional information of the mobile entity, wherein the transactional information relates to a handover history of the mobile entity in the SDN system.
  • the transactional information may be stored in a module of the control unit which may be referred to as mobility database (MD).
  • Transactional data or transactional information relates to assignment of time information to the location information of a mobile entity.
  • the switches may be configured to transmit a time stamp assigned to any location changed event caused by a handover of the mobile entity.
  • the control unit may store the arriving time of a mobile entity at a forwarding unit, i.e., the time when the mobile entity start using a specific forwarding unit as the access point to the network. Further, the control unit may store the time spent by a mobile entity at a forwarding unit.
  • This information may be used to generate a movement profile of a mobile entity and to make predictions about where (at which forwarding unit) and when to install the second configuration data.
  • This function may be implemented in that module which stores the configuration status of the forwarding units or alternatively, in another functional or logical module which performs the latter function only.
  • the handover history of a mobile entity contains information about the access points (forwarding units) being used by the mobile entity to access the SDN; the handover history may in particular indicate which access point is being used at which period or point of time.
  • control unit is configured to carry out machine learning based on the transactional information in order to make a prediction about the movement of the mobile entity and to determine at least one forwarding unit at which to install the second configuration data.
  • the machine learning algorithm may be implemented in an individual module and may be any suitable algorithm which can be implemented as a functional or logical module at the control unit and which can learn a behavior based on a given amount of past data.
  • the module which implements the machine learning algorithm may be referred to as mobility rules miner, MRM.
  • the MRM may consider the content of the mobility database for making the prediction about the movement of the mobile entity.
  • the second configuration data comprises an instruction set for configuring the second forwarding unit such that the second forwarding unit sends a reconfiguration message to the first forwarding unit after a handover of the mobile entity from the first forwarding unit to the second forwarding unit.
  • the second forwarding unit recognizes the handover by any kind of registration of the mobile entity at the access point/forwarding unit.
  • the forwarding unit which takes over the mobile entity reconfigures the previous access point.
  • the reconfiguration message may specifically be a configuration command directed to a forwarding unit which instructs the forwarding unit to modify its flow table, e.g. at least one forwarding rule, wherein this modification may be, for example, any one of generate, modify, or delete at least one forwarding rule.
  • the new access point is configured to send a
  • the reconfiguration message may be applied to at least one forwarding rule.
  • This embodiment relates to switch-to-switch communication, the controller is not required at the moment of sending the reconfiguration message. However, the controller may send the instruction set to the new access point in advance.
  • the reconfiguration message is configured to instruct the first forwarding unit to forward any data packets addressed to the mobile entity and received by the first forwarding unit to the second forwarding unit.
  • the instruction set is configured to instruct the second forwarding unit to forward any data packets sent by the mobile entity to the second forwarding unit to a third forwarding unit.
  • the downlink path is separated from the uplink path and these paths may be different. While the downlink route is simply extended and may not be the optimal path with respect to number of hops, such a downlink route may configure the minimum number of configuration or reconfiguration messages such that the time required for the handover is reduced.
  • the uplink route must be set up from the scratch as the access point of the mobile entity is new and thus the uplink route can be set up optimally relating to any routing metric, for example minimum hop.
  • a software defined networking, SDN, system comprises at least one control unit as described above and hereinafter and at least two forwarding units.
  • Such a SDN system may be characterized by reduced control plane overhead and good scalability as the load of the controller can be reduced or dispersed over time such that at least load peaks of the control plane may be avoided.
  • a second forwarding unit of the at least two forwarding units of the SDN system is configured to send a message to the control unit after a handover of a mobile entity from a first forwarding unit of the at least two forwarding units to the second forwarding unit.
  • control unit is kept up-to-date with the current configuration status of the SDN system.
  • control unit is configured to send second configuration data to at least some of the forwarding units being direct neighbors of the second forwarding unit in the SND system.
  • the second configuration data are sent to physical neighbors of the second forwarding unit in the SDN system such that a proactive configuration of the neighboring switches moves through the SDN system as the mobile entity moves on.
  • the forwarding units are proactively configured such that the configuration ideally is always one step (one switch) ahead of the moving mobile entity.
  • the proactive configuration of the forwarding units can be carried out in advance and there is no need for time-critical configuration message transactions at the moment of the handover.
  • a method for configuring a SDN system comprises the steps of sending, by a control unit of the SDN system, configuration data to a forwarding unit of the SDN system, wherein the configuration data relates at least to configuration of a data packet handling task which is to be executed by the forwarding units, determining, by the control unit, an identifier of a mobile entity having established a communication link to a first forwarding unit; sending, by the control unit, second configuration data to a second forwarding for the SDN system unit, wherein the second configuration data relates to handling data packets sent by or addressed to the mobile entity, and sending, by the control unit, the second configuration data to the second forwarding unit while the mobile entity has the communication link to the first forwarding unit, wherein the second forwarding unit is a forwarding unit serving the mobile entity after termination of the communication link between the mobile entity and the first forwarding unit.
  • the second forwarding unit is a forwarding unit serving the mobile entity either directly after termination of said communication link to the first forwarding unit (for example handover from the first to the second forwarding unit) or it may alternatively be a forwarding unit serving the mobile entity at a point in time sometimes after the termination of said communication link to the first forwarding unit, for example in a scenario where the mobile entity is handed over from the first forwarding unit to a third forwarding unit and subsequently to the second forwarding unit.
  • the second configuration data is sent to the second forwarding unit while the mobile entity is still connected to the first forwarding unit.
  • the second forwarding unit is enabled to initiate actions in case the mobile entity changes its SDN system access point from the first forwarding unit to the second forwarding unit. These actions can be initiated by the second forwarding unit without asking the controller of the SDN system.
  • congestion of the control plane and load of the controller is reduced such that the management of scalable networks (like mobile wireless communication networks as LTE, long term evolution, for example) can be improved.
  • the described approach enables handling mobility in SDN networks.
  • the described approach may be implemented as a control application on top of an SDN controller. It is proposed to proactively install flow rules in switches which are currently forwarding flows of the mobile node, these switches possibly including also switches which are not neighbors of the switch to which the mobile node is currently attached. It is further proposed to reconfigure flow tables of at least one of these switches after the mobile node changes the point of attachment.
  • the forwarding rules are to handle mobility, i.e., this may be a higher level application to which only interaction of the controller and switches can be added.
  • An SDN system may comprise at least two switches and at least one controller as described in more detail above and hereinafter, wherein the controller and the at least two switches are communicatively connected with each other in order to be able to transmit the configuration data to each other (controller to switch and/or switch to switch) as described herein.
  • Fig. 1 schematically shows an SDN system according to an exemplary embodiment of the invention
  • Fig. 2 schematically shows the SDN architecture
  • Fig. 3 schematically shows the tasks of a mobility management application
  • Fig. 4 schematically shows the configuration message flow when applying proactive
  • Fig. 5 schematically shows the flow tables of two forwarding units configured for switch-to- switch reconfiguration according to an embodiment of the invention
  • Fig. 6 schematically shows the configuration message flow when applying switch-to-switch reconfiguration according to an embodiment of the invention
  • Fig. 7 schematically shows a forwarding unit configured for switch-to-switch reconfiguration according to an embodiment of the invention.
  • Fig. 1 provides an overview of the structure of an SDN system 10.
  • the control plane 100 is separated from the data plane 200.
  • the control plane 100 is formed by at least one control unit 1 10 which controls the configuration and the functioning of the data plane, in particular the configuration of forwarding rules on the forwarding unit 210, 220 of the data plane.
  • the SDN system 10 and its components are configured to carry out the functions as described above with reference to the method for configuring forwarding rules for data packet transmission in a software defined network, SDN, system, and further with reference to the forwarding unit and control unit.
  • Fig. 1 describes the SDN system from a structural point of view
  • Fig. 2 describes the SDN system from a logical point of view.
  • SDN Software defined networking
  • a component of an SDN network is an SDN controller. Through its southbound APIs, the controller communicates with the network elements (switches) and relays the necessary data to and from them to build a centralized view of the network state. Through its northbound APIs, it exposes that view to control applications, enabling them to execute their logic and manipulate the network state.
  • OpenFlow is a protocol that implements the southbound API.
  • the OpenFlow switch abstraction is the key assumption that the protocol makes.
  • the concepts of a flow and a flow table are in the center of that abstraction.
  • a flow is essentially any sequence of packets which share a common set of L2-L3 protocol bits (e.g.
  • a flow table of a switch is a collection of all flows relevant to that switch.
  • Each flow entry in a flow table is associated with a set of actions which should be executed when an input packet is matched to the flow entry.
  • the controller-switch communication channel is usually called control channel. It is logically implemented as a TCP connection between the controller and a switch; hence the term control connection is also used with the same meaning as control channel.
  • Physically control connections can go in-band, i.e. other switches can relay packets of the control connections of other switches, or out-of-band, in which case a separate physical network is used.
  • Centralization of the control plane requires moving of network functions to the controller, i.e. running them as control applications.
  • routing is implemented as such a control application, conventional switches run both link state distribution protocols and route (path) computation, while OpenFlow switches only distribute their link states to the controller and the controller performs path computation. These paths are then used in the switches by installing appropriate flow rules.
  • Fig. 3 illustrates the operation of the MMA.
  • a mobile node M1 as shown in Fig. 3 attached to switch 2 is exchanging traffic with a web server.
  • the mobile node or mobile entity M1 and the web server can be described as communicating entities which are configured to exchange data (unidirectional or bidirectional).
  • Flow tables of intermediate switches (some of which may also operate as access points) have been set up to enable that data transmission between the mobile entity M1 and the web server and vice versa.
  • the current flow of M1 is routed over Switch 2, Switch 1 and Switch 4, as indicated by the dash-dot line in Fig. 3 and the gray shaded flow table entries of the shown switches.
  • M1 is about to move towards Switch 3.
  • MMA is the control application that performs a series of steps needed to reconfigure the flow of M1 such that it now goes over Switch 3 and Switch 4, as shown by the dash-dot-dot line. These include updating flow tables of a set of switches in the network, so that the flow entries with the dotted background pattern are added.
  • Fig. 4 describes the process of proactively configuring forwarding units (switches) of a SDN system. It is one aspect of the proactive MMA to pre-configure forwarding rules in the neighboring access points of the access point to which a mobile node is currently attached.
  • Fig. 4 illustrates this approach.
  • three modules/components may be added to a controller. These are Flow Information Database (FID), Mobility Database (MD) and Mobility Rules Miner (MRM).
  • FID is a module that stores the information about current flows of all hosts (including mobile nodes) in the network. The FID may use a data structure which is suitable for storing this information. For example, FID stores for each flow, its endpoints, its current path and, for each hop in the path, a flow match that identifies the flow in that hop.
  • MD is a database that stores transactional data about mobility in the network. Thus, for each mobile host, it may specify the time when it arrives at a given access point, the time it spends there and so on.
  • MRM is a learning engine that mines the mobility data and makes a prediction where a given node (mobile entity) might go to.
  • a possible output of MRM might be association rules which specify to which access point a mobile entity may go to, given its short or long history of movements up to the considered point in time.
  • Switch 2 which also acts as an attachment point, AP
  • Step 1 while M1 is at Switch 2, MMA retrieves the flows of M1 .
  • the FID stores the mentioned dash-dot flow, identified by a set of flow matches and switches.
  • Step 2 with help of MRM and MD (or alternatively MRM can in the background build its information base through direct communication with the MD), MMA determines APs to which M1 might move, i.e. MMA makes a prediction about the next access point of M1 (e.g. Switch 3, wherein the prediction may also identify two or more next access points in case of uncertainty). It then calculates the routes from these APs/switches to the endpoints of M1 's flows (e.g. the web server) and splits them into Uplink and Downlink parts (UL and DL).
  • the dash-dot-dot line in Fig. 4 depicts an example of such a new route.
  • Step 3 MMA adds UL and DL forwarding rules along the calculated route(s) from each new AP (e.g. Switch 3) up to the intersecting switch (such as Switch 4 in Fig. 4) between the old and new path.
  • each new AP e.g. Switch 3
  • the intersecting switch such as Switch 4 in Fig. 4
  • two actions are specified with each flow rule of M1 : (a) forward the packet to the next hop of the new route (e.g. to Switch 4); (b) send a PACKETJN to the controller to indicate that the new route is now active.
  • Step 4 when M1 moves to Switch 3, M1 transmissions (after the appropriated physical wireless handoff, which is out of the scope of this description and which is taken for granted for the purpose of the approach described herein) will trigger the preconfigured M1 flow rules at Switch 3.
  • the UL traffic from M1 will be forwarded to Switch 4 without interruptions, see step 3a) above.
  • Step 5 the first UL packet of M1 will generate a PACKETJN.
  • the controller calls the MMA to act upon this PACKETJN.
  • Step 6 the MMA reconfigures the rules of the intersecting switch (anchoring point, Switch 4 in Fig. 4) so that the DL traffic is now sent down the new route.
  • FID as well as MD may be updated, i.e., MMA and the controller need to store the new information in MD and FID.
  • the MMA utilizes appropriate data structures to store information about mobile nodes and their flows, as well as a set of operations to manipulate these data structures.
  • the proactive MMA keeps track of active and passive flow information, which is stored in the active and passive flow list, respectively.
  • the active list contains the information about the ongoing flows, while the passive list refers to the preconfigured flows, which do not carry any traffic but may start to if the concerned mobile node moves.
  • the active list maintains information about flows each mobile node in the network has at any moment.
  • the value of ul may be set arbitrary, as long as the two flow directions can be distinguished from each other.
  • swki is a neighbor of sw1 (from the active list) and thus a starting switch of a passive path (one of the possible next hops), while swkm is the endpoint of that path, i.e. the crossover switch in which the active and the passive paths intersect.
  • swkm is the endpoint of that path, i.e. the crossover switch in which the active and the passive paths intersect.
  • Algorithm 1 presents a possible embodiment of the pseudo code of the proactive MMA. Essentially, it describes processing of a PACKET IN by the MMA. With the information extracted from the PACKET IN, such as the source (S) and the destination (D) addresses, it will be first checked whether the source generates a new flow or if this PACKET IN is due to a mobility event, as described in the following: New flow arrival: If that is the case, the flow path is calculated, the flow match is created, the active list is updated and the flow rules are pushed along the path the flow takes (the procedure setActiveRules). The rules are split into downlink and uplink parts.
  • passive flow paths are computed from the neighbors of the current access point to the crossover switch relative to the current active path, these neighbors are configured, the downlink and the uplink flow rules are pushed along the passive paths and the passive list is updated, see the procedure calculatePassiveRules for more details.
  • configuring the neighbors may mean here adding the action "forward to controller" to each neighboring access point, such that they generate a PACKET IN to the controller in addition to just forwarding the flows.
  • Mobility event In case the flow is not new, it is known that the received PACKET IN is generated by a neighbor of the current access point and thus means that the node actually moved to this new access point.
  • Figs. 5 and 6 describe how two switches of a SDN system can be used such that one of these switches reconfigures the other one in order to reduce the load of the control plane of the SDN system.
  • Fig. 5 shows two physically connected switches referred to as Switch 2 and Switch 3, along with their flow tables.
  • the flow table of Switch 3 contains a flow entry that indicates that on receiving a packet that matches "Match3" (which can be arbitrary) the action "Send FlowMod to Switch 2" should be executed.
  • a switch to send reconfiguration information, for example a flow rule, to another switch when a network event happens (e.g. a packet that matches on "Match3").
  • Switch 2 When Switch 2 receives FlowMod (flow rule) from Switch 3, the first flow rule in its flow table fires, i.e. this forwarding rule has a match. This forwarding rule tells that Switch 2 should store the received FlowMod (flow rule) in its flow table and start using it just as the other flow rules.
  • Switch 2 and Switch 3 are only required to be communicatively connected somehow, directly or via any data transmission link or data transmission network.
  • the receiving switch switch 2 in Fig. 6) used the incoming
  • the first flow rule in the flow table of Switch 2 may not be essential, but may help resolve potential security problems. It should be noted that all these forwarding rules and (re-)configuration information originate in the controller; they are not results of any control logic running in the switches. Originally, the controller provides the reconfiguration information intended for switch 2 to switch 3. In other words, a switch remains a forwarding device which just matches packets and executes rules when a match happens. Alternatively, Switch 3 can store a flow entry priority update action and send it to Switch 1 when Match3 occurs. Switch 2 can change a flow rule priority.
  • Fig. 6 schematically shows a scenario how the switch-to-switch reconfiguration steps are carried out in a SDN system. Fig.
  • FIG. 6 describes the MMA operation in this case, i.e. when two attachment points of a mobile node (switches) can store and exchange flow rules directly, without those coming directly from the controller. Steps enumerated (encircled) in Fig. 6 are described next, in the order in which they occur. Fig. 6 depicts these steps as dashed lines with numbers as follows:
  • MMA pre-configures a flow rule at a neighboring switch Switch 3 to send a
  • FlowMod to Switch 2 This FlowMod instructs Switch 2 to forward the DL traffic of M1 to Switch 3.
  • MMA also installs a rule at Switch 3 that forwards M1 uplink traffic to Switch 4.
  • Switch 2 MMA installs a rule that matches on the packets from Switch 3 and as action install the requested rule. 2.
  • M1 moves to Switch 3 and triggers the FlowMod transfer to Switch 2.
  • Switch 2 stores it in its flow table.
  • OpenFlow v1 .5 are defined so that the new introduced entities inside the OpenFlow switch can recognize the switch-to-switch programmed operation and dispatch the control message from Switch 3 o Switch 2.
  • the changes are the following:
  • SET MSG msg Action Type the type of actions available in the list of actions of OpenFlow is extended. A new action called SET MSG is introduced.
  • the msg is a FLOWMOD message data structure as currently defined in OpenFlow v1 .5.
  • SET SW sw Action Type another extension to the type of actions available in the list of actions of OpenFlow v1 .5 is related to the set of information necessary to set up the destination of the flowmod message msg.
  • a new action called SET_ SW is introduced.
  • the sw contains the data structure with information Switch 3 needs in order to reach the destination Switch 2.
  • Example of this information is: IP, MAC, TCP configuration, output port in Switch 3 to reach the destination Switch 2.
  • S2S_COMM Logical Port a new logical port inside an OpenFlow switch is defined. This port needs to be used whenever the controller or an SDN application wants to program Switch 3 to send a message to Switch 2.
  • the new logical port S2S_COMM can be used in the same way as the logical CONTROLLER port, i.e., it is a possible value to be attributed to the OUTPUT PORT type of action.
  • the only packets that will be queued and forwarded in this port are the ones defined in the SEND FLOWMOD instruction.
  • SEND FLOWMOD [output port, set_sw sw, set_msg msg] Instruction: the types of instructions currently available in the OpenFlow specification are extended by introducing the new instruction SEND FLOWMOD.
  • This instruction is composed of the output port action type currently defined in OpenFlow v1 .5 list of actions and the two new action types SET SW and SET MSG proposed in this invention.
  • the output port must be the S2S_COMM logical port.
  • Fig. 7 shows the functional extension of a forwarding unit in order to allow switch-to-switch reconfiguration and further specifies the embodiment described with reference to Figs. 5 and 6. In comparison with the OpenFlow specification (v1 .5 as of this writing), another stage is introduced in the processing pipeline of OpenFlow enabled switches.
  • the new stage is adding another step as the last stage in the conventional OpenFlow pipeline processing.
  • This last step contains the execution of the SEND FLOWMOD instruction, as shown in Fig. 7.
  • the left side of Fig. 7 contains the OpenFlow pipeline processing as defined in the specification.
  • the modification adds one check for the existence of the SEND FLOWMOD instruction and, in case it exists, it adds a box to build the FlowMod packet. Please note that the 'no' outcome of the 'Switch has egress tables' question in the normal OpenFlow pipeline processing ends with the modification in the 'SEND FLOWMOD?' check box and not in the 'Packet Out' box of the original pipeline.
  • the added step to build the packet based on the SEND FLOWMOD instruction uses the described SET_SW and SET MSG information stored in SEND FLOWMOD of the flow entry to which the entire processing is applied to.
  • Table 1 shows flow tables of switches 2 and 3 from Fig. 6. While mobile node M1 is attached to Switch 2, the flow tables of Switch 2 and Switch 3 look like it is shown in the upper part of Table 1 (labeled 'Flow tables BEFORE mobility'). Symbols X and Y in table 1 are used to denote physical ports of attachment of the mobile node at switches Switch 2 and Switch 3, respectively.
  • MAC_Switch 2 is the MAC address of Switch 2.
  • the table of Switch 2 tells that the traffic from M1 is forwarded to Switch 1 (first row), while the downlink traffic goes to port X, i.e. to M1 (second row).
  • the second row of the Switch 3 table makes sure the packets destined to M1 which arrive along the new path (via Switch 4) indeed arrive at M1 .
  • the third row in the Switch 3 table makes sure that the packets which have been sent to M1 over the old path and are still in transit indeed arrive at M1 .
  • the bottom row in both tables is the usual flow miss entry.
  • the flow tables look like it is shown in the lower part of table 1 .
  • the first row of Switch 2 table forwards the M1 's transit packets to M1
  • the first row of Switch 3 table forwards uplink M1 packets along the new path
  • the second row forwards downlink packets to M1
  • the third one makes sure the transit packets from Switch 2 arrive at M1 .

Landscapes

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

Abstract

L'invention concerne une unité de commande (110) destinée à un système de mise en réseau définie par logiciel (SDN) (10). L'unité de commande est configurée pour envoyer des données de configuration à une unité de réacheminement (210, 220) du système SDN, les données de configuration concernant au moins la configuration d'une tâche de manipulation de paquets de données qui doit être exécutée par l'unité de réacheminement. L'unité de commande est également configurée pour déterminer un identifiant d'une entité mobile ayant établi une liaison de communication avec une première unité de réacheminement du système SDN et pour envoyer des deuxièmes données de configuration à une deuxième unité de réacheminement du système SDN, les deuxièmes données de configuration concernant la gestion des paquets de données envoyés par l'entité mobile ou adressés à celle-ci. L'unité de commande est configurée pour envoyer les deuxièmes données de configuration à la deuxième unité de réacheminement pendant que l'entité mobile dispose de la liaison de communication avec la première unité d'émission, la deuxième unité de réacheminement étant une unité de réacheminement desservant l'entité mobile après la cessation de la liaison de communication entre l'entité mobile et la première unité de réacheminement. L'invention concerne également un système SDN comprenant un contrôleur de ce type et au moins deux unités de réacheminement. Elle concerne également un procédé de configuration de ce type de système SDN.
PCT/EP2016/050603 2016-01-14 2016-01-14 Gestion de mobilité dans des systèmes sdn WO2017121475A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/050603 WO2017121475A1 (fr) 2016-01-14 2016-01-14 Gestion de mobilité dans des systèmes sdn

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/050603 WO2017121475A1 (fr) 2016-01-14 2016-01-14 Gestion de mobilité dans des systèmes sdn

Publications (1)

Publication Number Publication Date
WO2017121475A1 true WO2017121475A1 (fr) 2017-07-20

Family

ID=55129878

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/050603 WO2017121475A1 (fr) 2016-01-14 2016-01-14 Gestion de mobilité dans des systèmes sdn

Country Status (1)

Country Link
WO (1) WO2017121475A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11082894B2 (en) 2017-02-01 2021-08-03 Huawei Technologies Co., Ltd. System and method for enhanced session management in nextgen mobile core networks
KR20230155256A (ko) * 2022-05-03 2023-11-10 인천대학교 산학협력단 사물인터넷을 위한 이기종 도메인간 핸드오프 방법 및 장치
KR102628279B1 (ko) * 2023-08-31 2024-01-23 한화시스템(주) Sdn 기반의 네트워크 이동성 지원 시스템 및 방법

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140362790A1 (en) * 2013-06-11 2014-12-11 Futurewei Technologies, Inc. System and Method for Coordinated Remote Control of Network Radio Nodes and Core Network Elements
WO2015009939A1 (fr) * 2013-07-17 2015-01-22 Interdigital Patent Holdings, Inc. Gestion répartie et dynamique de la mobilité dans un réseau programmable
US20150103665A1 (en) * 2013-10-14 2015-04-16 Futurewei Technologies Inc. Method, apparatus and system for implementing pdn connections

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140362790A1 (en) * 2013-06-11 2014-12-11 Futurewei Technologies, Inc. System and Method for Coordinated Remote Control of Network Radio Nodes and Core Network Elements
WO2015009939A1 (fr) * 2013-07-17 2015-01-22 Interdigital Patent Holdings, Inc. Gestion répartie et dynamique de la mobilité dans un réseau programmable
US20150103665A1 (en) * 2013-10-14 2015-04-16 Futurewei Technologies Inc. Method, apparatus and system for implementing pdn connections

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
J. KEMPF; B. JOHANSSON; S. PETTERSSON; H. LUNING; T. NILSSON: "Moving the mobile evolved packet core to the cloud", 8TH INTL. CONF. WIRELESS AND MOBILE COMPUTING, 2012
K. PENTIKOUSIS; Y. WANG; W. HU. MOBILEFLOW: "Towards software defined mobile networks", IEEE COMMUN. MAG., vol. 51, July 2013 (2013-07-01)
P. PUPATWIBUL; A. BANJAR; A.A.L. SABBAGH; R. BRAUN: "Developing an application based on OpenFlow to enhance mobile ip networks", LOCAL COMPUTER NETWORKS WORKSHOP, 2013
V. YAZICI; U.C. KOZAT; M. OGUZ: "Communications Magazine", vol. 52, November 2014, IEEE, article "Sunay: A new control plane for 5G network architecture with a case study on unified handoff, mobility, and routing management", pages: 76 - 85
WEN JIAYAO ET AL: "Data prefetching to reduce delay in software-defined cellular networks", 2015 IEEE 26TH ANNUAL INTERNATIONAL SYMPOSIUM ON PERSONAL, INDOOR, AND MOBILE RADIO COMMUNICATIONS (PIMRC), IEEE, 30 August 2015 (2015-08-30), pages 1845 - 1849, XP032822310, DOI: 10.1109/PIMRC.2015.7343599 *
X. JIN; L. LI; J. REXFORD: "Softcell: Scalable and flexible cellular core network architecture", ACM CONEXT, 2013
YOU WANG; JUN BI: "A solution for ip mobility support in software defined networks", COMPUTER COMMUNICATION AND NETWORKS (ICCCN), 2014 23RD INTERNATIONAL CONFERENCE, August 2014 (2014-08-01), pages 1 - 8, XP032651869, DOI: doi:10.1109/ICCCN.2014.6911783

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11082894B2 (en) 2017-02-01 2021-08-03 Huawei Technologies Co., Ltd. System and method for enhanced session management in nextgen mobile core networks
KR20230155256A (ko) * 2022-05-03 2023-11-10 인천대학교 산학협력단 사물인터넷을 위한 이기종 도메인간 핸드오프 방법 및 장치
KR102620678B1 (ko) 2022-05-03 2024-01-04 인천대학교 산학협력단 사물인터넷을 위한 이기종 도메인간 핸드오프 방법 및 장치
KR102628279B1 (ko) * 2023-08-31 2024-01-23 한화시스템(주) Sdn 기반의 네트워크 이동성 지원 시스템 및 방법

Similar Documents

Publication Publication Date Title
US11134012B2 (en) Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
US10728094B2 (en) Control traffic in software defined networks
Costa-Requena SDN integration in LTE mobile backhaul networks
US10893108B2 (en) Maintaining application state of mobile endpoint device moving between virtualization hosts based on sharing connection-based metadata
CN113261240A (zh) 使用可编程客户机进行多租户隔离
US20220007251A1 (en) Using location indentifier separation protocol to implement a distributed user plane function architecture for 5g mobility
CN113302898B (zh) 通信系统、通信方法、非暂时性计算机可读介质
Cominardi et al. Distributed mobility management solutions for next mobile network architectures
CN116319169A (zh) 通信系统和由通信系统实现的方法、分流控制器、交换机
EP3275131A1 (fr) Traitement de services intégré pour réseaux mobiles
CN101480002A (zh) 移动无线全IP网络中的知道QoS的服务流映射
JP2017516424A (ja) 第５世代移動ネットワークにおけるオンデマンドネットワークサービス
JP2018536345A (ja) ファイアウォールクラスタ
Bouzidi et al. Online based learning for predictive end-to-end network slicing in 5G networks
WO2017121475A1 (fr) Gestion de mobilité dans des systèmes sdn
JP6050720B2 (ja) コアネットワークにおけるゲートウェイのセッション情報を移行させるシステム及び方法
KR101409315B1 (ko) 터미널 핸드오버를 실현하는 방법 및 시스템
JP2015035729A (ja) 通信システム及び通信方式
Aghdai et al. Enabling mobility in LTE-compatible mobile-edge computing with programmable switches
Ahmad et al. Load balancing in software defined mobile networks
Sun et al. LISP-Based Integrated Control Plane Framework for Service Function Chaining in Distributed Edge Clouds
US20190108050A1 (en) Operation device, communication system, and update method
KR102620678B1 (ko) 사물인터넷을 위한 이기종 도메인간 핸드오프 방법 및 장치
Banik et al. Enabling distributed mobility management: A unified wireless network architecture based on virtualized core network
EP4329374A1 (fr) Procédé de traitement de communication et dispositif associé

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

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

Country of ref document: EP

Kind code of ref document: A1