WO2012110103A1

WO2012110103A1 - Method, gateway, and client for optimizing keep-alive message handling

Info

Publication number: WO2012110103A1
Application number: PCT/EP2011/052459
Authority: WO
Inventors: Anton GYLLENBERG
Original assignee: Birdstep Technology
Priority date: 2011-02-18
Filing date: 2011-02-18
Publication date: 2012-08-23

Abstract

The present invention relates to a method to optimize keep-alive message handling used to maintain an encapsulating IP connection established between a client endpoint 10 and a gateway 12 via a Connection Tracking Router 11, CTR. located in a communication network. The CTR 11 maintains the IP connection on the basis of received keep-alive messages. The method is particularly characterized in the steps of : - the client endpoint 10 and the gateway 12 establishes an encapsulating IP connection between the endpoint 10 and the gateway 12, - the client endpoint 10 and the gateway 12 together further determine a keep-alive Time-To-Live, TTLk, - the gateway 12 sending keep-alive messages with TTLk towards the client endpoint 10 to maintain the encapsulated IP connection, the TTLk being set lower than a TTLi needed in order for the messages to reach the client endpoint 10. The client endpoint will thereby refrain from transmitting keep -alive messages on the assumption that inbound keep -alive messages sent by the gateway maintain the connection. Power consumption is significantly reduced by having the encapsulation gateway or proxy transmitting keep -alive messages with a reduced time- to- live (TTL) value, since the client endpoint does not to receive or transmit keep-alive messages.

Description

METHOD, GATEWAY, AND CLIENT FOR OPTIMIZING KEEP-ALIVE

MESSAGE HANDLING

TECHNICAL FIELD

The present invention relates to a method for optimizing keep-alive messages handling. It also relates to a client endpoint and gateway being arranged for the same purpose.

BACKGROUND

A large class of modern Internet applications used on mobile devices requires long running connections or that the application is immediately reachable by incoming data from the network. Examples of such applications are VoIP applications where incoming calls need to reach the device immediately, push-style email clients or instant messaging implementations that requires immediate delivery of incoming messages.

The prevalent internet environment includes stateful Connection Tracking Routers (CTR) that keep track of client connections and refuse or fail to forward incoming traffic from the network towards client devices unless the traffic is related to a known, existing connection. Examples of such connection tracking routers (CTR) are stateful firewalls and network address translation devices (NAT).

These CTR generally employ timers to implement connection tracking and will discard and forget a connection when no traffic belonging to the connection has been observed for some time interval. The length of these timeout intervals vary greatly between CTR implementations and between different protocols such as TCP or UDP, but mostly range between tens of seconds to tens of minutes. Generally, timeouts for TCP are longer than timeouts for UDP as TCP includes information useful for determining whether a connection is still active while UDP does not.

For an application to generally remain reachable in this environment, the application on the client device needs to be engineered to initiate the connections towards the network and server. Further, in absence of other traffic over the connection, it must transmit some otherwise unnecessary messages in order to refresh the timers of any CTR on the network path between the client device and the server to keep it from timing out. These messages are called keep-alive messages. For instance, a VoIP client running on a mobile handset needs to immediately get note of incoming calls by the VoIP gateway sending it a message. Assume there is a stateful firewall (CTR) between the VoIP gateway and the VoIP client. The gateway then cannot initiate connections to the client as the firewall prevents this. Therefore, the VoIP client has to initiate the connection. However, the client cannot possibly know in advance when an incoming call will arrive. It therefore needs to initiate a connection in advance to let the gateway use this connection to notify about incoming calls. This long running connection needs to be maintained by sending keep-alive messages. If this is not maintained, the firewall will timeout the connection and drop further messages about incoming calls.

Lacking absolute control of the whole network between the client device and the service, the general solution to the problem of achieving reachability and maintaining long running connections (in the presence of CTR devices) is thus for the client to initiate the connection and to send keep-alive messages. This however presents problems of its own. Especially for battery powered, wireless mobile devices the energy consumption caused by repeatedly transmitting keep-alive messages is so great that the technique is rendered effectively useless. For example, modern 3G handsets employ very efficient power saving techniques. The handsets turn off the radio transmitter and enter a low power state when no traffic is transmitted or received for a while. Frequent keep-alive messages prevent this from working, which causes the battery to drain quickly. In a common 3G handset, battery life may be reduced to a fifth when running an application employing keep-alive messages.

Current solutions are impractical and of limited applicability to the prevalent Internet environment. One solution leveraging a power reduction technique is presented in WO 2008/1 12396. This document discloses a solution to save energy in a handset during keep-alive messaging scenarios. It is based on the assumption that inbound keep-alive messages consume less energy and messages that do not reach the handset consume no energy at the handset.

This solution shares a general problem that the functionality described needs to be engineered into individual applications (client and server) and protocols. In the case of UDP based protocols this is expensive, prone to errors and, in the case of legacy or third party applications, often impossible. In the case of TCP based protocols, this would require accessing operating system facilities which are generally not available to applications, which is most often impossible.

SUMMARY

The object of the present invention is therefore to provide an improved method for keep-alive messaging that consumes less energy at the handset.

The object of the present invention is solved by means of a method to optimize keep- alive message handling used to maintain an encapsulating IP connection established between a client endpoint and a gateway via a Connection Tracking Router, CTR, located in a communication network. The CTR maintains the IP connection on the basis of received keep-alive messages. The method is particularly characterized in the steps of: - the client endpoint and the gateway establishes an encapsulating IP connection between the endpoint and the gateway,

- the client endpoint and the gateway together further determine a keep-alive Time-To-Live, TTLk, - the gateway sending keep-alive messages with TTLk towards the client endpoint to maintain the encapsulated IP connection, the TTLk being set lower than a TTLi needed in order for the messages to reach the client endpoint.

The object of the present invention is further solved by means of a gateway being arranged to optimize keep-alive messages handling used to maintain an encapsulating IP connection established between a client endpoint and the gateway via a Connection Tracking Router, CTR, located in a communication network. The CTR maintains the IP connection on the basis of received keep-alive messages. The gateway is particularly characterized in that: - It is arranged to establish an encapsulating IP connection between the endpoint and the gateway and, - It is further arranged to determine a keep-alive Time-To-Live, TTLk, together with the client endpoint, the gateway further being arranged to send a keep-alive messages with TTLk towards the client endpoint, TTLk being set lower than a TTLi needed in order for the message to reach the client endpoint.

The object of the present invention is finally achieved by means of a client endpoint being arranged to optimize keep-alive messages handling used to maintain an encapsulating IP connection established between the client endpoint and a gateway via a Connection Tracking Router, CTR, located in a communication network. The CTR maintains the IP connection on the basis of received keep-alive messages. The client endpoint is particularly characterized in that:

- It is arranged to establish an encapsulating IP connection between the endpoint and the gateway, - It is further arranged to determine a keep-alive Time-To-Live, TTLk, together with the gateway.

The main advantage with the present invention is that it addresses the keep-alive and battery problems on an encapsulation or tunnelling layer, transparently to applications. Power consumption is significantly reduced by having the encapsulation gateway or proxy transmitting keep-alive messages with a reduced time-to-live (TTL) value, since the client endpoint does not need to receive or transmit keep-alive messages. The client endpoint will refrain from transmitting keep-alive messages on the assumption that inbound keep-alive messages sent by the gateway maintain the connection. By working on an encapsulation layer, only a single long running connection needs to be maintained and the technique is application independent and immediately available to all applications without modification.

Additional advantages are achieved by implementing one or several of the features of the dependent claims not mentioned above. This will be further explained below. BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in greater detail in the following, with reference to the embodiments that are shown in the attached drawings, in which:

Figure 1 Network diagram illustrating a typical encapsulation or tunnelling setup.

Figure 2 Diagram illustrating keep-alive messages with limited TTL serving their purpose of refreshing connection timers on connection tracking routers (CTR) without reaching the encapsulation endpoint (ENCC).

Figure 3 Diagram illustrating a first example of a technique for determining optimal keep-alive TTL in the presence of asymmetric routes.

Figure 4 Diagram illustrating a second example of a technique for determining optimal keep-alive TTL in the presence of asymmetric routes.

Figure 5 Diagram illustrating a third example of a technique for determining optimal keep-alive TTL in the presence of asymmetric routes.

DETAILED DESCRIPTION

The present invention relates to a method for optimizing keep-alive message handling. It also relates to a client endpoint and a gateway or proxy adapted for the same purpose. The purpose is to reduce power consumption of mobile Internet devices that make use of long running or incoming connections.

In order to achieve this, the message handling used to maintain an IP connection, see figure 1 , is improved. An IP connection that encapsulates tunnels IP traffic is established between a client endpoint 10 and an encapsulation gateway or proxy 12 via a Connection Tracking Router, CTR, 1 1 located in a communication network. The CTR maintains the IP connection on the basis of received keep-alive messages. The client endpoint 10, usually a mobile device, is named ENCC (ENCapsulation Client endpoint) in the figures. The encapsulation gateway or proxy 12 is named ENCGW (ENCapsulation GateWay). These short terms will be used in the following.

As mentioned, improved keep-alive message handling can be used to reduce power consumption in the ENCC 10. In order to achieve this, the ENCGW 12 may determine a keep-alive time-to-live, TTLk, and send keep-alive messages with said TTLk towards the client endpoint. The TTLk is then set by the ENCGW to be lower than a TTLi needed in order for the message to actually reach the client endpoint. However, there is a need to improve keep-alive message handling while avoiding that the functionality needs to be engineered into applications and network services. For instance, in UDP based protocols this is expensive, prone to errors and often impossible. In TCP it would require accessing operating system facilities, which are generally not available to applications. The object is therefore to improve keep-alive messaging to avoid these problems. In order to achieve this, the present invention comprises a solution where the ENCC 10 sends a Registration Request, RRQ, message for maintaining the IP connection to the ENCGW. The message includes an original transmitted TTL, TTLq, a requested TTL offset, TTLo and a request for inbound keep-alive messages.

This means that the ENCC supports the ENCGW with information so that it can determine a TTLk which is lower than the TTLi, such that the message does not reach all the way to the ENCC. Since this is handled on the encapsulation layer, functionality therefore does not have to be engineered into the individual applications. Power consumption is further significantly reduced by having the ENCGW transmitting keep-alive messages with a reduced time-to-live (TTL) value, since the ENCC does not need to receive or transmit keep-alive messages. Thus there is no requirement by the ENCC for packet transmission.

As shown in figure 1 , a tunnel or encapsulated connection 14 is maintained between the two encapsulation endpoints; the ENCC and the ENCGW. Connection data between the ENCC and IP hosts, CN (Correspondent Node) 13, that the ENCC corresponds with (using TCP/IP), is encapsulated and transmitted between the ENCC and ENCGW. The ENCGW forwards the corresponding original data between itself and the CN.

Figure 1 illustrates a typical encapsulation or tunnelling setup. Examples of typical encapsulation or tunnelling setups are: 1 . IPsec VPN (Virtual Private Network) for remote access: The ENCGW 12 is the VPN gateway and the ENCC 10 is the VPN client. ESP (Encapsulating Security Payload) is the encapsulation protocol. When utilizing UDP (User Datagram Protocol) encapsulation for IPsec NAT-traversal, keep-alive messages are required. The IPsec tunnel encrypts and encapsulates IP packets between the client device and services (CN) behind the VPN gateway.

2. Mobile IP for seamless mobility and reachability for mobile devices: The ENCGW is the Mobile IP Home Agent (HA). The ENCC is the Mobile IP Mobile Node (MN). When utilizing UDP encapsulation for Mobile IP NAT- traversal, keep-alive messages are required.

3. Other setups where a client connects to a service via a proxy or gateway, such as: HTTP/HTTPS web proxy, SOCKS proxy, SSL proxy, VPN gateways.

As an example of an encapsulation setup, take a push email client application running on a mobile device. The client application connects to a server. Without encapsulation, the client application would directly connect to the email server application using TCP/IP. With encapsulation, the communication from client to server is intercepted by the ENCC 10, which encapsulates it within some other data transport and transports it to the ENCGW 12. The ENCGW then decapsulates and forwards the communication to the email server application. Traffic from email server application to the ENCC will pass via the ENCGW, which will encapsulate it, transport it to the ENCC for decapsulation and delivery to the email client application. Such an encapsulation setup can generally be implemented in a fashion transparent to the client and server applications. A single encapsulating connection between ENCC 10 and ENCGW 12 can encapsulate several connections to several different correspondent nodes (CN). It is in fact the most common setup for Mobile IP and IPsec to have only one tunnel between client and gateway or between MN and HA and use that same tunnel when communicating with all services and applications. The most generic solution is that the encapsulating (IP) connection is established with at least one tunnel between the ENCC and the ENCGW. There may be a number of connection tracking routers (CTR) devices 1 1 on the path between the ENCC 10 and the ENCGW 12. In the presence of such CTR, encapsulated traffic from the ENCGW to the ENCC cannot pass in case of connection timer expiry on the CTR. Then messages from network service to client application will cease to function and new connections from the network to the device can no longer be initiated.

The connection timers on all CTRs 1 1 need to be periodically reset in order to maintain a functioning encapsulating connection. This is done by periodically sending keep-alive messages either from ENCC 10 to ENCGW 12, from ENCGW to ENCC or both.

The hop count distance from ENCGW 12 to ENCC 10 is determined, and the TTL value on the IP packet of the keep-alive messages is reduced so that the IP packet will traverse all CTR, thus resetting the connection timers, but be dropped by a router before reaching the ENCC. The function is illustrated in Figure 2:

The routing path length 15 from ENCGW 12 to ENCC 10 measured in hops is 4 (router Z, router Y, router X and finally ENCC). The system has determined that a suitable TTL value for keep-alive messages from ENCGW to ENCC is 3. ENCC periodically transmits keep-alive messages with TTL=3. When processed by router Z, router Z decrements the TTL to TTL=2 before forwarding. Router Y decrements and transmits with TTL=1 . Router X decrements the TTL to TTL=0 and destroys the IP packet as required by the Internet Protocol standard (IETF RFC 791 ). This is illustrated by the dotted line between router X and ENCC. Router X never transmits the IP packet. This means that the ENCC never receives the keep-alive packet and therefore no power consumption is incurred by the keep-alive. However, all of the routers X, Y and Z process the keep-alive packet and if any of the routers perform connection tracking (are CTR), then the connection tracking counters will still be refreshed by the keep-alive packet.

The following is a description of a protocol or technique to discover the hop count distance (D) between ENCGW and ENCC) and determine the optimal TTLk for the keep-alive messages from ENCGW 12 to ENCC 10. The technique is illustrated in figures 3A, 4 and 5. As the presence or absence of a CTR cannot readily be reliably determined, the optimal TTL, TTLk, is one less than the TTL necessary to really reach the ENCC. Note that in general, the hop count distance D from ENCGW to ENCC is not the same as the distance from ENCC to ENCGW (asymmetric routes). Asymmetric routes are also a common occurrence in practice. The technique described minimizes the necessary protocol messages for determining TTLk so that in case of symmetric routes only one message exchange is required, while in case of asymmetric routes two message exchanges are required.

Message exchange 1

As part of encapsulation connection negotiation with the ENCGW 12, the ENCC 10 sends the RRQ (a protocol request message) to the ENCGW. The initial TTL value on the IP packet is contained RRQ as a parameter TTLq and a parameter TTLo, which is the TTL offset, initially set to -1 . The RRQ message further may comprise a requested keep-alive interval. The ENCGW determines a first estimate TTLk of the optimal TTL on the basis of a difference, TTLd, between the included TTLq and the actual TTL on the received IP packet containing the RRQ. The actual TTL is the resulting TTL on the IP packet containing the RRQ. More in detail, the TTLk is calculated by the formula:

TTLk = MAX (0, MIN (255, TTLd + TTLo + 1 )), The ENCGW 12 sends a Registration Response Message, RRP, to the ENCC 10 including the determined TTLk, in response to the received RRQ message. The RRP comprises the TTL used for sending said RRP message. After the exchange, the ENCGW continues to send keep-alive messages with TTLk. The ENCC 10 may then refrain from sending keep-alive messages and instead count inbound maintaining the connection. After the exchange, the ENCGW continues to send keep-alive messages with TTLk.

By comparing the TTL for the RRP with TTLp and TTLk, the ENCC can detect asymmetric routes with different hop counts, adjust TTLo and re-register TTLo to get TTLk optimally adjusted. The following formula can be used for adjusting TTLo:

TTLo' = TTLp - TTL - TTLk + TTLo, , where TTL is the TTL value on IP packet containing the response message from the ENCGW.

If the adjusted TTLo' is identical to the original TTLo, then the TTLk calculated by ENCGW in message exchange 1 is optimal and no further message exchange is required. If the adjusted TTLo' differs from the original TTLo, then ENCC can initiate a new message exchange 2 identical to message exchange 1 , but using the adjusted TTLo'.

The disclosed technique for keep-alive message handling has the following beneficial properties: 1 . In the common case of symmetric routes the message exchange is as minimal as possible with a single request and reply message.

2. In the case of asymmetric routes, the discrepancy is immediately identified and corrected with the minimal possible extra message exchange of a single additional request and reply.

3. The protocol requires no additional state (memory) to be maintained on the ENCGW for the purpose of obtaining the optimal TTLk. The ENCGW needs not track previously received or transmitted values but all necessary information can be read from the latest received protocol request.

The functioning of the protocol is in the case of asymmetric routes 15 illustrated in figures 3, 4 and 5. The route from ENCC to ENCGW is ENCC -> Router X -> Router Y -> ENCGW (3 hops). The route from ENCGW to ENCC is ENCGW -> Router Z -> Router V -> Router X -> ENCC (4 hops). In this illustration, ENCC uses a TTL of 50 and ENCGW a TTL of 77 for the protocol messages (not for the keep-alive messages). In figure 3A, message exchange 1 , ENCC transmits the protocol request message with TTL=50 and parameter values TTLq=50, TTLo = -1 . Router X decrements TTL to 49. Router Y decrements TTL to 48. ENCGW calculates TTLd = TTLq - TTL = 50 - 48 = 2. ENCGW then calculates TTLk = TTLd + TTLo + 1 = 2 + (- 1 ) + 1 = 2. This TTLk=2 is however not optimal as the asymmetric return path is of length 4. The optimal value for TTLk would be 4-1 = 3. This is illustrated in figure 3 in that a keep-alive message transmitted with TTL=2 would only reach Router V before the TTL reaches 0 and the packet is destroyed. In case Router X performs connection tracking (is a CTR) then as the keep-alive messages never reach Router X they would fail to refresh the connection timers resulting in a broken connection.

Figure 4 shows how the protocol adjusts TTLk in this scenario. The protocol reply message sent by ENCGW is sent with TTL=77 and parameter value TTLp=77. The TTL is decremented by routers Z, V and X, and is 74 when received by ENCC. ENCC then calculates TTLo' = TTLp - TTL - TTLk + TTLo = 77 - 74 - 2 + (-1 ) = 0. As this is different from the original TTLo = -1 , ENCC initiates message exchange 2 with updated TTLo' = 0 (see figure 5). The same calculations as in message exchange 1 leads to an adjusted TTLk = (TTLq - TTL) + TTLo + 1 = (50 - 48) + 0 + 1 = 3, which is the optimal value for TTLk. As illustrated in figure 5, a keep-alive message sent with TTL= 3 reaches Router X but not ENCC. The invention is not limited to the examples above, but may vary freely within the scope of the appended claims. For example, the protocol or technique described above for determining optimal TTLk can be naturally incorporated in existing encapsulation negotiation protocols. For Mobile IP the required values can be added as vendor extensions to the Mobile IP registration protocol exchange. The keep-alive message handling is then performed using the vendor extensions to an existing protocol specification. The Mobile IP mobile node (MN) would include as vendor extensions to the registration request (RRQ) the values TTLq and TTLo.

The Mobile IP home agent (HA) would include TTLk and TTLp as vendor extensions to the registration reply (RRP) message. In case of asymmetric routes, the MN would reregister with an adjusted TTLo. On reception of an RRQ with the vendor extension, the HA would start sending periodical keep-alive messages for the NAT-traversal tunnel (IETF document RFC3519) with adjusted TTL and the MN would refrain from sending keep-alive messages on reception of the RRP with the vendor extension.

Claims

1 . A method to optimize keep-alive message handling used to maintain an encapsulating IP connection established between a client endpoint (10) and a gateway (12) via a Connection Tracking Router (1 1 ), CTR, located in a communication network, the CTR maintaining the IP connection on the basis of received keep-alive messages, characterized in the steps of:

- the client endpoint (10) and the gateway (12), establishing an

encapsulating IP connection between the endpoint (10) and the gateway (12),

- the client endpoint (10) and the gateway (12) together further determine a keep-alive Time-To-Live, TTLk,

- the gateway (12) sending keep-alive messages with TTLk towards the client endpoint (10) to maintain the encapsulated IP connection, the TTLk being set lower than a TTLi needed in order for the messages to reach the client endpoint (10).

2. Method according to claim 1 wherein the client endpoint (10) sends

Request, RRQ, messages for maintaining the IP connection to the gateway (12), the messages including an original transmitted TTL, TTLq , a requested TTL offset, TTLo and a request for inbound keep-alive messages.

3. Method according to claim 2, wherein the gateway (12) determines TTLk on the basis of a difference, TTLd, between TTLq and a TTL on the received IP packet containing the RRQ.

4. Method according to claim 3 wherein TTLk is calculated as:

TTLk = MAX(0, MIN(255, TTLd+ TTLo+ 1 ) )

5. Method according to any of the claims 2 - 4 wherein the gateway (12) sends Response, RRP, messages comprising the TTLk in a response to the received RRQ messages.

6. Method according to claim 5 wherein RRP message further comprises TTL used for sending said RRP messages, TTLp.

7. Method according to claims 5 and 6 wherein the client endpoint (10)

compares a TTL for the RRP messages with TTLk and TTLp to detect asymmetric routes with different hop counts, adjust TTLo and re-register TTLo.

8. Method according to any of the preceding claims wherein the keep-alive message handling is performed using vendor extensions to an existing protocol specification.

9. Method according to any of the preceding claims wherein the RRQ

messages further comprises a requested keep-alive interval.

10. Method according to any of the preceding claims wherein the client

endpoint refrains from sending keep-alive messages and instead counts inbound maintaining the connection.

1 1 . Method according to any of the preceding claims wherein the IP

connection is established with at least one tunnel between the client endpoint (10) and the gateway (12).

12. A gateway (12) being arranged to optimize keep-alive messages handling used to maintain an encapsulating IP connection established between a client endpoint (10) and the gateway (12) via a Connection Tracking Router (1 1 ), CTR, located in a communication network, the CTR (1 1 ) maintaining the IP connection on the basis of received keep-alive messages, characterized in that the gateway (12) being arranged to establish an encapsulating IP connection between the endpoint (10) and the gateway (12) and, the gateway further being arranged to determine a keep-alive Time-To- Live, TTLk, together with the client endpoint (10), the gateway (12) further being arranged to send a keep-alive messages with TTLk towards the client endpoint (10), TTLk being set lower than a TTLi needed in order for the message to reach the client endpoint (10).

13. A client endpoint (10) being arranged to optimize keep-alive messages handling used to maintain an encapsulating IP connection established between the client endpoint and a gateway via a Connection Tracking Router (1 1 ), CTR, located in a communication network, the CTR maintaining the IP connection on the basis of received keep-alive messages, characterized in that the client endpoint (10) being arranged to establish an encapsulating IP connection between the endpoint (10) and the gateway (12), the client endpoint (10) further being arranged to determine a keep-alive Time-To-Live, TTLk, together with the gateway (12).