WO2010043247A1

WO2010043247A1 - Method of and device for defining a data flow description in a network

Info

Publication number: WO2010043247A1
Application number: PCT/EP2008/063777
Authority: WO
Inventors: Changpeng Fan; Carmelita GÖRG; Frank Pittmann; Umar Toseef; Asanga Udugama
Original assignee: Nokia Siemens Networks Oy
Priority date: 2008-10-14
Filing date: 2008-10-14
Publication date: 2010-04-22

Abstract

A Method of and a device for defining a data flow description in a network is disclosed. First, a first flow description or parts of it for a first direction (D1a, D2a) of the data flow is received. Subsequently, a second flow description for a second, reverse direction (D1b, D2b) is created by setting a value of at least one parameter of the second flow description to the value of a reversed parameter of the first flow description.

Description

Title

Method of and device for defining a data flow description in a network

The invention is directed to a method of defining a data flow description in a network. Moreover, the invention is directed to a device for defining a data flow description in a network, in particular to a mobile node and a home agent.

When a first network node connects to a second network node within the same network (e.g. two computers in the same local area network, or a computer connected to an internet server via a router, wherein both the router and the server are part of the same internet service provider) , all of the network traffic that originates from the first network node is sent to the second network node through the network, to which the nodes are connected. Similarly, all the IP packets that are sent from the second node to the first node are sent over said network. Obviously, this is a rather simple example for routing data through a network.

However, if a network node is connected to a network, for example the internet, through two or more access technologies/networks (e.g. WLAN and Ethernet), it is advantageous to manage the data streams, i.e. to decide which type of traffic should take which access network interface to said network.

This management is called "flow management'. Flow management denotes a method of directing a stream of data (packets) from the source towards its destination via a certain path. In other words, flow management is the way a network node di- rects its data traffic to available network interfaces according to predefined policies. It is obvious that flow management is useful if a node has multiple network accesses, which can be used simultaneously. An example is a laptop, which is connected to the internet via WLAN and LAN. While a file download is conducted over high speed LAN network, the user simultaneously makes a voice call over the second available network access via WLAN. In this way, the user of the laptop can benefit from the use of the resources, i.e. two different network interfaces, of the laptop .

Flow management is done by flow descriptions or filters, which selectively let through or block data packets as they (want to) pass through a network entity, such as a router or a home agent in a network working according to the Mo- bile Internet Protocol. Filter rules specify the criteria that a packet must match and the resulting action, either blocking or letting through, that is taken when a match is found. The criteria that are used when inspecting packets can be based on the Layer 3 and Layer 4 headers. Commonly, the source and destination address, source and destination port, and protocol, are used as criteria, wherein said tuple is associated with an end-to-end data communication session.

Flow management can be performed for downlink traffic flows (called as forward filtering) as well as for uplink traffic flows (called as reverse filtering) of a user's terminal. The need to distinguish uplink and downlink traffic flows results from the fact that quality of service requirements may be different for uplink and downlink flows. For ex- ample, a user terminal may have asymmetric access links to networks with different uplink and downlink bandwidths . Hence, it is useful to manage uplink and downlink traffic differently.

In forward filtering, flows (i.e. data destined for the terminal of the user) are usually identified by investigating the information contained in a packet. Examples for such information are the transport protocol type, the source address and the source/destination port numbers, etc. Forward filtering of the traffic is achieved by setting filters at the correspondent node or another anchor point in the network. Forward filtering plays an important role for a mobile user equipment having limited downlink bandwidth and running various applications that are competing for the downlink data rate. Thus, there is a need of bandwidth resource management.

In this context, reference is made to the standard RFC 3484, ^λDefault Address Selection for Internet Protocol version 6 (IPv6) ' , February 2003, in particular to chapters 5 (Source Address Selection) and 6 (Destination Address Selection) .

Although forward filtering significantly improves the effi- ciency of use of available bandwidth resources and gives a tool to manage incoming traffic flows, the user equipment should also be able manage its outgoing traffic flows in order to fully benefit from flow management. Although forward filters direct all incoming packets of that flow towards the destination through the defined network access, the reply (outgoing) traffic packets associated with the flow will not be affected by that forward filter and hence possibly does not use the same network access when leaving the host for the destination.

Accordingly, the object of the invention is to provide a possibility to create a flow description in a network.

According to the invention, this object is achieved by a me- thod according to claim 1 and a device according to claim 7.

Accordingly, a method of defining a data flow description in a network is proposed, comprising the steps of: a) receiving a first flow description or parts of it for a first direction of data flow and b) creating a second flow description for a second, reverse direction by setting a value of at least one parameter of the second flow description to the value of a reversed parameter of the first flow description.

Furthermore, a device for defining a data flow description in a network is proposed, comprising: a) means for receiving a first flow description or parts of it for a first direction of data flow and b) means for creating a second flow description for a second, reverse direction by setting a value of at least one pa- rameter of the second flow description to the value of a re^¬ versed parameter of the first flow description.

The invention offers the advantage that a reverse filter can be derived from a forward filter and vice versa. Thus, the inventions prevents the users or administrators of a network from devising filter policies for both the incoming and outgoing traffic of the user equipment, e.g. a mobile terminal. If, for example, a forward filter has been set to direct downlink traffic from a correspondent node over a WLAN net- work access, then the reverse filter can be constructed in a way that it directs uplink traffic to that correspondent node over the same WLAN network access. Thus, the invention offers a mechanism to derive the flow description of the reverse flow by inverting or reversing the parameters of a filter rule, which describes a forward flow. Reverse filter rules (or mirror filter rules) are derived automatically and can be set up automatically at the mobile node without the explicit intervention of the user or a software (decision engine) in the mobile node. In this way, the mobile node is able to manage its outgoing traffic flows in line with the strategy for incoming traffic flows. This approach offers the advantage that there is no need for defining addi^¬ tional (manual) configurations. In this way, an optimal man^¬ agement of the data streams of a user terminal can be achieved.

However, under certain circumstances one can find the generated reverse filter not as the best solution. Thus, a manual post configuration, i.e. the amendment of the automatically generated filter, is not excluded. Anyway, the invention provides a good starting point for these amendments.

The automatically generated reverse filters, along with forward filters, guarantee that all incoming and outgoing packets of a certain flow are treated in a similar - if not in the same - way. For example, a data packet between two network nodes will follow the same path, irrespective of the di- rection in which it is sent.

In the context of the invention, the flow management based on reverse filters as explained hereinbefore is called reverse filtering.

In the context of the invention, moreover, a filter rule is part of flow description, which flow description itself is part of the flow management. In other words, the flow management consists of a number of flow descriptions and a flow de- scription consists of a number of filter rules. Finally, a filter rule is defined as filter parameter plus condition.

The receiving means and creating means of the inventive device may be embodied in hardware or software. Often, these means will be part of a software in a network node, for example in a mobile node or a home agent of a mobile network. In this context the receiving means and creating means may have a physical meaning, in particular if they are embodied in hardware, as well as a functional meaning, in particular if they are embodied in software. In the latter case, these means may form a subroutine of a software code.

It should be noted at this point that there are substantial differences to the standard RFC 3484 mentioned hereinbefore: - the context of the invention is flow management not multi- homing;

- the reverse path is being determined by looking at the forward path and - the source address is not the only criteria. Since the forward filter criteria is inversed, there may be any type of information in the packet (i.e. ports, traffic class, etc) .

Preferred embodiments of the invention can be found in the dependent claims as well as in the description and the figures .

In a preferred embodiment, the invention also comprises the step of setting a value of at least one parameter of the second flow description to the value of said parameter of the first flow description. Often, the "inversion' of parameters is not applicable to all of the filter parameters. Examples are the parameters "protocol' and "network interface identi- fication'. Advantageously, the values of these parameters of the second flow description are set to the values of said parameters of the first flow description parameters.

In a preferred embodiment, at least one of the following map- pings is performed: source address in first flow description to destination address in second flow description, source address prefix in first flow description to destination address prefix in second flow description, destination address in first flow description to source address in second flow de- scription, destination address prefix in first flow description to source address prefix in second flow description, source port range in first flow description to destination port range in second flow description, destination port range in first flow description to source port range in second flow description, protocol in first flow description to protocol in second flow description, network interface identification in first flow description to network interface identification in second flow description. Said parameters are commonly sent in a TCP header or IP header on the one hand and allow fil- tering of data streams on the other hand. Thus, a reverse filter can be generated with relatively low technical effort. In another preferred embodiment, said first direction is the direction for incoming data at a network node, in particular at a mobile node, and said second direction is the direction for outgoing data at said network node. The advantages of this embodiment are particularly visible, if the first flow description is implicitly received, e.g. by an incoming data packet having a TCP header or IP header. So, the second flow description can simply be generated when data is received.

In yet another preferred embodiment, the network node is a mobile node and a flow description for outgoing data is executed in the mobile node and a flow description for incoming data is executed in a home agent associated with the mobile node. Mobile networks are quite common nowadays why it is beneficially to offer the advantages of the invention also to this kind of network. In this context, the use of the home agent is explained hereinafter. The home agent is a special server, which is necessary to realize Mobile IP (Mobile Internet Protocol) . It is connected to the home network of the mobile terminal (also known as "mobile node' and "mobile host') and forwards data packets to the mobile node if the mobile node is not within its home network. Furthermore, the home agent holds location information of the mobile host.

Furthermore it is advantageous, if said network is a mobile network working according to the standard of network mobility. This is a further type of a common network, to which the advantages of the invention shall be provided.

In another preferred embodiment, a mobile node comprises an inventive device, wherein said first direction is the direction for incoming data at said mobile node and said second direction is the direction for outgoing data at said mobile node. In this case, the second flow description can simply be generated when data is received as already explained hereinbefore. The inventive device may, for example, form a part of the software running in a mobile node. In yet another preferred embodiment, the mobile node is designed to execute the flow description for outgoing data. In this embodiment, the mobile node can direct outgoing data packets to a particular network interface without the need of further network entities.

In a further preferred embodiment, a home agent comprises an inventive device, wherein said first direction is the direction for outgoing data at a mobile node associated with said home agent and said second direction is the direction for incoming data at said mobile node associated with said home agent. In a mobile network, the home agent forwards data coming from a correspondent node to the mobile node. This may also involve the step of filtering respectively routing data. For this use, a second filter description for data sent to the mobile node may be generated based on a first filter description, which is used for data sent from the mobile node. Again, the first flow description can implicitly be received, e.g. by an data packet sent from the mobile node having a TCP header or IP header. So, the second flow description can simply be generated when data is received at the home agent.

Finally, it is preferred if the home agent is designed to execute the flow description for incoming data at said mobile node associated with said home agent. As the home agent performs the routing of data to the mobile node, it is advantageous if said flow description is executed in the home agent.

It should be noted that the embodiments of the invention dis- closed hereinbefore can be combined in any desired way.

These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described and shown in the schematic Figure hereinafter.

The Figure shows a typical setup of a network working according to the standard for network mobility (NEMO) , comprising a mobile node MN, a correspondent node CN and a home agent HA. All entities are connected to the internet IN, the correspondent node CN directly, the home agent HA via a home network HN and the mobile node MN via a local area network LAN and a wireless local area network WLAN. The address of the local area network LAN is ethl and the address of the wireless local area network WLAN is eth2. Traffic incoming at the mobile node MN via the local area network LAN is designated with DIa, traffic incoming at the mobile node MN via the wireless local area network WLAN is designated with D2a. Traffic out- going via the local area network LAN is designated with DIb, traffic outgoing via the wireless local area network WLAN is designated with D2b.

In this example it is assumed that both network interface ad- dresses ethl and eth2 are registered as care-of addresses in the home agent HA of the mobile node MN. The mobile node MN receives data through an ipvβ-ipvβ tunnel from its home agent HA. In other words, traffic destined for the mobile node MN reaches it via the home agent HA and therefore filter rules can be applied at home agent HA to perform flow management of downlink traffic. The (tunneled) connection between home agent HA and mobile node MN via the local area network LAN is shown in dashed lines, the (tunneled) connection between home agent HA and mobile node MN via the wireless local area net- work WLAN is shown in dash-dotted lines, and the connection between home agent HA and correspondent node CN is shown in continuous lines.

If the user of the mobile node MN wants to activate flow man- agement, he can create filter rules and send them to the home agent HA. Subsequently, the home agent HA can perform flow management on behalf of the mobile node MN.

The filter rule parameters presented in the following example have symbolic values. Moreover, it is assumed that the default outgoing network interface for the mobile node MN is ethl. In this example, the mobile node MN shall communicate with the correspondent node CN over a TCP/IP (transmission control protocol/internet protocol) connection. This TCP/IP connection is initiated by the correspondent node CN with source port 6789 and is received by the mobile node MN at port 7890. TCP and IP headers of a packet received by the mobile node MN accordingly will have the values: source port=6789, source address=address of correspondent node CN, destination port=7890 and destination address=address of mobile node MN as shown in Table 1 below.

Table 1

In this example, packets belonging to the TCP connection shall be received at network interface eth2. Thus, the user of the mobile node MN or a software application in the mobile node MN constructs a forward filter rule as shown in the table 2 below.

Filter rule parameter Parameter value name

Table 2

In principle, this filter rule contains enough information to recognize all packets belonging to the TCP connection. Therefore, all TCP connection packets sent to the mobile node MN will be directed over the wireless local area network WLAN (address eth2) when this filter rule is activated at the home agent HA.

Up to now, there is no filter set at the mobile node MN. Hence, all traffic generated by the mobile node MN will be sent over the default network interface, which is the interface with the address ethl in our case. In other words, the mobile node MN receives TCP traffic from the correspondent node CN via the address eth2 while outgoing traffic to the correspondent node CN of the same TCP connection will be sent over the address ethl without further intervention.

However, If the user of the mobile node MN wants to use the address eth2 for sending data as well as for receiving data over the same TCP connection, he has to create a reverse filter for this purpose. In this example, user action is required, at least the confirmation of a proposal for a reverse filter. However, one can imagine that the reverse filter can be generated and activated automatically, that means without any user interaction. Table 3 shows some parameters of the TCP header and the IP header of a data packet sent from the mobile node MN to the corresponding node CN. As an example, parameters of an header according to the internet protocol in the version 6 is shown. However, one skilled in the art will easily perceive that the invention applies to other versions as well.

Table 3

Accordingly, a reverse filter can be constructed in the following manner. The first forward filter rule parameter in Table 2 is the 'Source Address' . According to the invention, the value of the 'Destination Address' of the reverse filter becomes the value of the 'Source Address' of the forward filter (=CN address) . Similarly, the value of the 'Destination Port' of the reverse filter becomes the value of the 'Source Port' of the forward filter (=6789) . The third and the fourth parameter of the forward filter rule (protocol and network interface identification) are not inverted. Thus, the value of the 'Protocol' of the reverse filter becomes the value of the 'Protocol' of the forward filter (=TCP) and the value of the 'Network Interface ID of the reverse filter becomes the value of the 'Network Interface ID' of the forward filter (=eth2) . The result of these mappings, i.e. the reverse filter belonging to the same TCP/IP connection, is shown in the Table 4 below.

Table 4

If this automatically generated reverse filter rule is applied at the mobile node MN, data packets generated by the mobile node MN and associated with the TCP/IP connection are directed to the corresponding node CN via the address eth2.

In addition to the protocol and the network interface identification, there are other parameters in the layer 3 of an IP header that are used in filter rule construction. Examples are the security parameter index, the flow label, and the traffic class. Some of them allow using the same value (e.g. the parameter flow label uses the same value for incoming/outgoing traffic for a video conferencing session) , some of them usually have different values for incoming and outgoing traffic packets. Hence, the "inversion' of parameters is usually not applicable to all of the parameters in a TCP header or IP header.

Accordingly, step b) of the inventive method can also comprise the creation of a second flow description for a second, reverse direction DIb, D2b by setting a value of at least one parameter of the second flow description to the value of said parameter of the first flow description. This has already been shown for the Protocol and the Network Interface ID hereinbefore . It should be noted that the creation of a reverse flow description can require manual input if the parameter set for a flow description is complex, i.e. if there is no unambiguous solution for setting the parameters of the second flow description .

Furthermore, one should note that a first flow description may be received explicitly as well as implicitly. In the first case, the primary use of a set of parameters is the description of a flow. In the second case, said set of parameters has another primary use. As have been shown hereinbefore, the TCP headers and IP headers of a received data packet can be used to create a second flow description. This is an example of an implicitly received first flow description .

It should also be noted, that although in the Fig. the mobile node MN is connected to just one correspondent node CN, the mobile node MN may also be connected to more than one correspondent node CN. For example, a connection to a first correspondent node may be routed via the local area network LAN, whereas a connection to a second correspondent node may be routed via the wireless local area network WLAN.

Furthermore, one should note that the local area network LAN and the wireless local area network WLAN are just examples to connect a mobile node MN to a network. Further examples are USB, Bluetooth and NFC (Near Field Communication) . These ex- amples just illustrate the invention and may not be construed to limit the invention.

Finally, it should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The verb "comprise' and its conjugations do not exclude the presence of elements or steps other than those listed in any claim or the specifica- tion as a whole. The singular reference of an element does not exclude the plural reference of such elements and vice- versa. In a device claim enumerating several means, several of these means may be embodied by one and the same item of software or hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage .

List of references:

CN correspondent node

DIa, D2a first (incoming) direction DIb, D2b second (outgoing) direction ethl address of the local area network eth2 address of the wireless local area network HA home agent IN internet LAN local area network MN mobile node WLAN wireless local area network

Claims

1. Method of defining a data flow description in a network, comprising the steps of: a) receiving a first flow description or parts of it for a first direction (DIa, D2a) of data flow and b) creating a second flow description for a second, reverse direction (DIb, D2b) by setting a value of at least one parameter of the second flow description to the value of a re- versed parameter of the first flow description.

2. Method as claimed in claim 1, also comprising the step of setting a value of at least one parameter of the second flow description to the value of said parameter of the first flow description.

3. Method as claimed in one of the claims 1 to 2, wherein at least one of the following mappings is performed: source address in first flow description to destination address in second flow description, source address prefix in first flow description to destination address prefix in second flow description, destination address in first flow description to source address in second flow description, destination address prefix in first flow description to source address pre- fix in second flow description, source port range in first flow description to destination port range in second flow description, destination port range in first flow description to source port range in second flow description, protocol in first flow description to protocol in second flow descrip- tion, network interface identification in first flow description to network interface identification in second flow description .

4. Method as claimed in one of the claims 1 to 3, wherein said first direction (DIa, D2a) is the direction for incoming data at a network node and said second direction (DIb, D2b) is the direction for outgoing data at said network node.

5. Method as claimed in claim 4, wherein the network node is a mobile node (MN) and a flow description for outgoing data is executed in the mobile node (MN) and a flow description for incoming data is executed in a home agent (HA) associated with the mobile node (MN) .

6. Method as claimed in one of the claims 1 to 5, wherein said network is a mobile network working according to the standard of network mobility.

7. Device for defining a data flow description in a network, comprising : a) means for receiving a first flow description or parts of it for a first direction (DIa, D2a) of data flow and b) means for creating a second flow description for a second, reverse direction (DIb, D2b) by setting a value of at least one parameter of the second flow description to the value of a reversed parameter of the first flow description.

8. Device as claimed in claim 7, also comprising means for setting a value of at least one parameter of the second flow description to the value of said parameter of the first flow description .

9. Device as claimed in one of the claims 7 to 8, wherein the means for creating the second flow description are designed to perform at least one of the following mappings: source address in first flow description to destination address in second flow description, source address prefix in first flow description to destination address prefix in second flow description, destination address in first flow description to source address in second flow description, destination address prefix in first flow description to source address prefix in second flow description, source port range in first flow description to destination port range in second flow description, destination port range in first flow description to source port range in second flow description, protocol in first flow description to protocol in second flow descrip- tion, network interface identification in first flow description to network interface identification in second flow description .

10. Device as claimed in one of the claims 7 to 9, designed to be connected to a mobile network working according to the standard of network mobility.

11. Mobile node (MN), comprising a device as claimed in one of the claims 7 to 10, wherein said first direction (DIa, D2a) is the direction for incoming data at said mobile node (MN) and said second direction (DIb, D2b) is the direction for outgoing data at said mobile node (MN) .

12. Mobile node (MN) as claimed in claim 11, designed to execute the flow description for outgoing data.

13. Home agent (HA), comprising a device as claimed in one of the claims 7 to 10, wherein said first direction is the di- rection for outgoing data (DIb, D2b) at a mobile node (MN) associated with said home agent (HA) and said second direction is the direction for incoming data (DIa, D2a) at said mobile node (MN) associated with said home agent (HA) .

14. Home agent (HA) as claimed in claim 13, designed to execute the flow description for incoming data at said mobile node (MN) associated with said home agent (HA) .