An Efficient Approach for State Sharing in Server ... - Semantic Scholar

An Efficient Approach for State Sharing in Server Pools Thomas Dreibholz August 06, 2002

Thomas Dreibholz Universität Essen Institut für Experimentelle Mathematik Ellernstraße 29 D-45326 Essen, Germany Phone: +49 201 183-7637 Fax: +49 201 183-7673

Abstract Many Internet services require high availability. That is, downtimes cause loss of money (e.g. electronic shops) or damages of equipment (e.g. control systems for production processes). Server pooling provides a high availability solution using multiple redundant servers. If one server fails, the service is continued by another one. A big challenge for server pooling is efficient state sharing. That is, servers contain states for each client (e.g. user identity or media position). To continue the service in case of a failover, the new server has to know the old server’s state. The goal of this paper is to present an efficient, simple and scalable approach, applicable to a large range of server pooling applications, that provides secure transfer of states by the client itself, using an extended cookie mechanism. Finally, it also provides implementation considerations. Keywords: high availability, server pooling, state sharing, client, server

1

Introduction

In classical client/server scenarios, the service provided by a server becomes unavailable when the

server fails (e.g. a hardware damage or simply a software crash) or the network connection is broken. If a server provides commercial applications like electronic shops, video and audio on demand, tele-medicine, control systems for production processes or any other critical applications requiring high availability, a downtime causes a loss of possibly lots of money for the service provider. For example, customers cannot use the services, customers change to concurrent providers with a better service or a company’s employees are unable to do their work. To cope with the challenge of ensuring high availability, the Reliable Server Pooling (RSerPool) is currently under development by an IETF working group (see [RSerPool]). It consists of an efficient and scalable framework allowing a service provider to run several servers providing the same service. An appropriate server is selected for each client. In case of server failure, a failover is made to another working server. Such a redundant set of servers is called a server pool. The servers within the pool are called pool elements (PE). Pool elements may be located in different networks, multi-homed (having direct connections to more than one network) and may be spread over possibly large geographical areas. Server pools are managed by redundant name servers. The name servers keep a namespace with pool names (e.g. “Video Pool” or “Sound Pool”) and a transport address list of all pool elements having registered to one of the pools using the ASAP protocol (Aggregate Server Access Protocol, see [ASAP] for details). Figure 1 shows the namespace containing a video pool (named “Video Pool”), an audio pool (named “Audio Pool”), a pool of compute servers (named “Compute Pool”) and a file pool (named “Down-

11 00 00 11 00 11 00 11

Pool Element PE1

11 00 00 11 00 11 00 11

Server Pool

Audio Pool

Download Pool Video Pool

Pool Element PE2

Legacy Servers

Compute Pool 1 0 0 1 11 00

11 00 00 11 00 11 00 11

1 0 0 1 11 00

Proxy Pool Element PPE3

Figure 1: Server Pools

Pool Element PE1 ENRP Server #1

Pool Element PE2

ASAP Protocol

Proxy Pool Element PPE3 Application Protocol

11 00 00 11 00 11 00 11

1 0 0 1 11 00

Legacy Clients

ENRP Protocol 00 11 11 00 00 11 00 11

ENRP Server #2

1 0 0 1 11 00

...

1 0 0 1 11 00

Pool User

Pool User

1 0 0 1 11 00

Proxy

1 0 0 1 11 00

Pool User

Figure 2: Pool Users load Pool”). Three pool elements have registered to the video pool: PE1, PE2 and PPE3 (proxy pool element, see below). The ASAP connection between pool element and name server is also used to monitor the availability of the element using heartbeats. The reliability of the name servers is ensured by the ENRP protocol (Endpoint Name Resolution Protocol, see [ENRP] for details). It is responsible for synchronising the namespace with other name servers. Figure 2 shows a client requesting a service from a pool. That is, the client becomes a socalled pool user of this pool. First, a name server is queried for the transport addresses of appropriate

pool elements using the ASAP protocol. The name server replies all or a set of pool element transport addresses selected by a so-called pool policy (e.g. least used, most inexpensive, nearest etc.). Using this set, the pool user selects one of them, again by the given policy, and contacts this element using its specific application layer protocol. Note, that an ASAP connection between pool user and pool element is usually not necessary. At the moment, the only case in which this is required is when the pool user itself is also a pool element. Then, it has to transmit information about how to contact other elements in case of failure (e.g. its pool name or trans-

port addresses). This information is called Business Card and may be sent over a separate ASAP connection (out-band) or combined with the user data (inband, this avoids establishment of a separate connection). The RSerPool architecture also provides support for legacy servers without ASAP support (e.g. a classic FTP server) via a proxy pool element (PPE). Figure 1 shows the proxy pool element PPE3 and two legacy servers. The proxy pool element contacts the servers using their specific application protocol; the proxy itself uses ASAP for communication to name servers. On the user side, client proxies can also provide communication between legacy clients and the RSerPool architecture. Figure 2 shows two legacy clients that connect to a proxy via their specific application protocol. For each legacy client, the proxy becomes an RSerPool pool user, finds an appropriate pool element, establishes a transport connection and ensures failover. Proxies provide a migration path for legacy servers and clients, but of course they are always a single point of failure. Using RSerPool, there may be many pool elements, possibly even spread over a large geographical area. If the service requires no transaction state to be stored by the server, there will be no problems. For example, if the pool user only requests static web pages, one request may be sent to pool element X while the next one may be sent to Y. But there is a problem if the transaction requires saving of a state at the server, e.g. the user logs in with his personal account, requests a personalized train schedule dynamically generated by the server and starts downloading. Now, a failover is not simply possible any more: The user is not logged in at the new pool element and the new element has no information how to re-create the requested file and how many bytes of this file the user has already received. A simple solution for this problem would be to copy the states to all elements of the pool and keep them synchronized. This might be applicable for small pools e.g. in a local LAN. But it is absolutely unusable for large and possibly geographically distributed pools, since it is not scalable: Each element would have to keep and synchronize the states of all other ones. The goal of this paper is to present a simple, efficient and scalable approach to provide state sharing between pool elements for a large subset of server pooling applications. This approach uses cryptographic methods to securely transfer the server state

by the client itself, using an extended cookie mechanism. Finally, this paper also presents implementation considerations.

2 An Example Scenario Before the new state sharing approach can be introduced, it is first necessary to present and observe a larger example scenario: An electronic shop contains a virtual reality interface which allows the user to move within a 3D shopping mall, view information videos about products in a display and add products to a shopping cart. A customer can request advise from a shop assistant using a video chat and the shop assistant can grant a discount or additional free products to the customer (e.g. to convince the customer to buy a more expensive product). To ensure high availability, RSerPool is used. This example scenario has the following states: 1. The 3D scenario requires the current position and rotation angle of the user. 2. For the product information display, the current media name, video and audio quality settings and the current media position are required. Further, the user’s language setting has to be stored. 3. The shopping cart system requires a list of all products and their amount. Further, it may contain special offers granted by a shop assistant to the customer (e.g. 5% discount for buying video recorder XYZ and 5 free videotapes). Further, it also requires the identity of the customer and especially a flag showing that the identity is verified by an authentication system. Finally, the shop assistant can also add some comments about the customer omitted during video chat for other shop assistants. For example: “This customer dislikes Microsoft, offer him Linux products and services!”

3 An Examination of the Example Scenario’s Server States An observation of the example scenario above shows that the server state for a client consists of a combination of long-term and short-term sub-states.

That is, a server state is equal to a set of long-term plus a set of short-term sub-states. This sub-state classification is described in the following.

3.1 Long-Term Sub-States Long-term sub-states are only changed in longer time intervals or when there is a client interaction (e.g. when the user changes a setting). For example, the user identity, the shopping cart contents and the media settings (name, quality, language) are such sub-states. Depending on the application, the class of longterm sub-states can be further subdivided into two groups: 1. Public Long-Term Sub-States. The group of public long-term states contains state information that is not confidential from the client. That is, the client may have knowledge about the sub-state’s content. For example, media quality and file name, language setting and the shopping cart contents are states of this group. Public long-term sub-states can further be subdivided into two sub-groups, again depending on a specific application: Mutable: A change (within a well-defined range) of a mutable sub-state during a failover does not affect the proper usage of the service. For example, the video stream for the selected quality is generated online from a highquality stored file by resizing and frame dropping. In this case, it may be allowed to change the media quality during failover: If quality q1 if requested from PE1 and a failover is made to PE2, the new requested quality may be changed to q2 . Immutable: On the other side, immutable states may not be changed during failover. Examples are the user’s identity and the shopping cart content. The first PE created these entries based on products and special offers by shop assistants. Therefore, it is mandatory that the content may not be changed when the application is continued using another PE. 2. Private Long-Term Sub-States: On the opposite of public long-term states, private ones are confidential from the client. That is, the client may not know its content. An example for such

a kind of state are the comments added by shop assistants about the customer. Internal information like “This customer does not pay his bills in time. Do not grant any discounts!” or “This customer has lots of money. Try to sell him more expensive products!” should never be visible to the customer’s client.

3.2 Short-Term Sub-States In contrast to long-term sub-states, short-term substates only last for a short time period, possibly even without client interaction. The most important example for this sub-state class is a media position of e.g. an audio or video file. It automatically increases (in normal play mode) for each media frame transmitted. Again, as it is explained for public long-term substates, short-term ones can be subdivided into the two groups of public and private sub-states with the public ones being either mutable or immutable. But it is important to mention here that states of this class are usually all public and mutable for most applications. For example, the client also knows the media position and if the client changes it during failover, this should be no problem.

4 An Approach for Client-Based State Sharing As described in the introduction, the replication of server states to all servers in a pool is very inefficient and prevents scalability. But for many cases (an exact definition is given later in section 5), it is simply possible to use an extended cookie mechanism and let the client itself provide the transfer of the old pool element’s state to a new one. That is, digital signature and encryption are used to transfer a pool element’s current state to the client. These ensure authenticity and prevent the client from making unwanted changes (integrity) and reading confidential values (confidentiality). To make a failover, the current state is transmitted to the new pool element. Due to the digital signature, its correctness and integrity can be verified easily. Then, the new pool element restores the state and continues the service. An illustration of the mechanism to be explained in the following can be found in figure 3.

Server Pool

Pool Element PE1

Pool Key Pool Element PE2

Server State to be Restored Pool Element PE3

State Cookie

1 0 0 1 11 00

Pool User

State Cookie

State Synchronization

Current Server State

Failover

Encryption + Digital Signature

Decryption + Signature Verification

Figure 3: Client-Based State Sharing First of all, all elements of a pool require the same encryption/decryption key K for digital signatures and encryption of confidential data. This key, in the following called pool key, could be selected randomly and distributed to all servers. For security reasons, it should be changed within certain time intervals in the range of about some hours. Due to this large update interval, the necessary distribution to all pool elements is not critical. In more detail, the server’s current state consists of the following parts: Server State S : 1. Long-Term Server Sub-State S LT  Public Sub-States LT – Mutable SM – Immutable SILT

 Private Sub-States SPLT

2. Short-Term Server Sub-States S ST  Public Sub-States ST – Mutable SM – Immutable SIST

 Private Sub-States SPST

Validity Range Sequence Number Pool Key Reference Long-Term Sub-State S LT Short-Term Sub-State S ST

'K ( LT ) 'K (LT ) 'K () LT SM 'K (SILT ) K (SPLT ) ST SM 'K (SIST ) K (SPST )

Table 1: A Full State Cookie That is, formally a state S is a tuple S = (S LT ; S ST ) with S LT = (SMLT ; SILT ; SPLT ) and ST ; S ST ; S ST ). S ST = (SM I P Now, every time one sub-state changes, the complete server state could be forwarded to the client. But short-term states have the property to usually change very frequently (e.g. for the media position, which changes for every media frame). In order to prevent the server from having to update the complete state e.g. for every media frame, one key idea of this paper is to handle long-term and short-term sub-states separately. That is, every time the long-term part S LT changes, the complete state S would have to be transmitted to the client. This can be realized in the form of a full state cookie as shown in table 1. It contains

Reference to S LT Validity Range Sequence Number Short-Term Sub-State S ST

'K (LT ) 'K ( ST ) 'K (ST ) ST SM 'K (SIST ) K (SPST )

Table 2: A Partial State Cookie the following entries: To ensure the confidentiality of the private sub-states S LT and S ST , the private parts are encrypted by an encryption function K using the pool key K . Since this key should change regularly in the range of about some hours, it must be ensured that the state transfer between two pool elements also works during a key-changing phase from key K1 to key K2 . Therefore, the cookie also needs a reference  stating to use pool key K . For example the reference  is a counter incremented by one for each new key. To prevent too old cookies from being used, a validity time range  also has to be included (e.g. “valid from 29-Sep-2002, 01:00 to 29-Sep-2002 01:05 CET”). Too old cookies or future cookies (e.g. error or invalid clock setting) must be rejected by the new pool element. Note, that there has to be some tolerance since it is hardly possible to keep clocks synchronized exactly. But a maximum of a few minutes should be quite sufficient if the clocks are regularly updated using e.g. NTP (Network Time Protocol, see [RFC1305]). Furthermore, a sequence number LT is necessary if different long-term states have the same validity range. It must be incremented for each state transmitted using the same given validity range. To be sure that the client or attackers within the network are unable to modify private and immutable parts of the state cookie, validity range  LT , sequence number  LT , key reference , immutable public sub-states (SILT , SIST ) and private sub-states (SPLT , SPST ) have to be digitally signed by a signature function ' using the pool key K . Note, that mutable sub-states are defined to be changeable (within well-defined ranges) by the client and are therefore remaining unsigned! When there is only a change of the short-term part of the server’s state S , a partial state cookie is sent to the client instead of a full one. The contents

of this partial state cookie can be found in table 2. First, the long-term part is not included because it has not been changed since the last full state cookie. Further, an own pool key reference is not necessary if always the pool key of the current long-term substate is used. Since the key changes in intervals of about some hours, it should usually be cheaper to send a full state cookie when the key changes and skip the reference in all partial state cookies. Validity range  ST , sequence number  ST , the sub-states ST , S ST and S ST , the encryption function SM K and M M the signature function 'K have the same meaning as for long-term sub-states, therefore an explaination is not necessary. To ensure the correct recombination of the complete server state S = (S LT ; S ST ), the short-term substate S ST requires an unique reference LT to the long-term one S LT . As such a reference, the validity range  LT and the sequence number  LT of the long-term sub-state part can be used. Then, the tuple LT = ( LT ;  LT ) uniquely references the long-term sub-state to which the short-term one belongs. It can be compared to a primary key in a relational database management system (RDBMS). The digital signature ensures authenticity and integrity of this reference. Note, that in many cases, the short-term sub-state S ST only consists of public mutable sub-states (e.g. only a media position). That is, formally: S ST = (SMST ; ;; ;). In this case, the complete signature and encryption mechanism can be skipped for the short-term sub-states S ST . That is, only the public mutable sub-state and the reference LT , validity range  ST and sequence number  ST have to be transmitted. If further the short-term sub-state transfer from the pool element to the user is guaranteed to be in order, it is also possible to skip the reference LT , validity range  ST and sequence number  ST . That is, if the transport protocol ensures that when S1 is transmitted before S2 , the client never receives S2 before S1 . Therefore, the client always gets the latest value of S ST :

5 Applicability of State Sharing

Client-Based

The approach of client-based state sharing can be applied in all situations where the following two situations do not cause security problems:

 The client-based state sharing allows the client to revert to an older server state that is still within its validity range. For example, the state of PE1 is X. Then, the client causes a transition to Y. Now, the client makes a failover to PE2 but sends the old state X within the validity range of X. Therefore, X is verified and restored.

while quality settings are changed by user interactions. Then, the complete long-term sub-state (media name + quality) may be transmitted only once, while following updates only contain the quality part. Again, correct recombination is ensured using a unique reference (e.g. the validity range and sequence number of the next upper group), protected by a digital signature.

 Further, the client-based state sharing approach allows forking. That is, the old state can be restored simultaneously on multiple pool elements, as long as its validity range is accepted. Therefore, duplicates of existing sessions may be created. Note, that authentication of the user (e.g. using a certificate verifiable by the pool elements) prevents forking by hackers having sniffed states from a session. This ensures that only the user itself is able to fork a session.

In more general, this splitting approach leads to a hierarchical sub-state grouping with the short-term sub-states in the lower groups. The shorter the change interval, the higher the group number n. An illustration can be found in figure 4. Every time a state of group n changes, all states of lower groups (having a group number higher than n) also have to be transmitted with updated references. Without a forced update in the lower groups, their references to the next upper group (lower group number) would become invalid and make the state recombination therefore impossible. This can be compared to relational database systems. A change of the primary key requires an update of all tuples using this key as reference.

In the example scenario (3D shopping mall, video display, shopping cart), the two described conditions are no problem for the service, since old states only contain an older video file, media quality, position or shopping cart content. Further, forking is not critical since it does not create problems when the user opens more than one shopping session. Note again, that usage of forking by attackers is easily preventable using authentication by the client! All in all, the client-based state sharing approach offers scalability and is efficiently implementable due to its simplicity.

6

Optimisations

To save transmission resources, there are several possibilities to optimise the state transmissions. These optimisation approaches are described in the following.

6.1

State Splitting

The state splitting technique described for longand short-term sub-states can also be applied to the long-term and short-term sub-states themselves. This means that these sub-states are divided up into sub-groups, sorted ascending by their (most probable) change interval length. For example, the media name is usually valid for the complete session

6.2 State Derivation from Application Data Furthermore, the client may be able to derive the public states directly from the received user data. For example, that could be simply the RTP timestamp (see [RFC1889]) of the last received media frame in the case of the media position. In the public/mutable-only case with all states derivable, no separate server to client transmission of states is necessary at all!

6.3 State Approximation Depending on the application, it may be sufficient to use an approximation of the current state. That is, a new state is only transmitted when “important” changes are made. For example, a video server’s media position and therefore the short-term state changes for every media frame (e.g. 25 times per second). Now, instead of transmitting a new state for every frame, the short-term state transmission rate is reduced to e.g. once per second. This means that in case of failover to a new server, there is a video repetition of at most one second. But since a

Group 1

Group 2

Key Reference

Reference to Group 1 (VR, Seq)

Group n

111111111111111111111111111111111111 000000000000000000000000000000000000 000000000000000000 111111111111111111 000000000000000000000000000000000000 111111111111111111111111111111111111 000000000000000000 111111111111111111 Public le 000000000000000000000000000000000000 111111111111111111111111111111111111 000000000000000000 111111111111111111 Mutab table 000000000000000000000000000000000000 111111111111111111111111111111111111 000000000000000000 111111111111111111 2 Immu 0000000000 1111111111 000000000000000000000000000000000000 111111111111111111111111111111111111 000000000000000000 111111111111111111 0000000000 1111111111 Private

Validity Range, Sequence Number

Validity Range, Sequence Number

1111111111111111111 0000000000000000000 000000000000000000 111111111111111111 0000000000000000000 1111111111111111111 000000000000000000 111111111111111111 0000000000000000000 1111111111111111111 000000000000000000 111111111111111111 Public le 0000000000000000000 1111111111111111111 000000000000000000 111111111111111111 0000000000000000000 1111111111111111111 000000000000000000 111111111111111111 Mutab table 0000000000000000000 1111111111111111111 000000000000000000 111111111111111111 0000000000000000000 1111111111111111111 000000000000000000 111111111111111111 1 Immu 0000000000000000000 1111111111111111111 000000000000000000 111111111111111111 0000000000000000000 1111111111111111111 000000000000000000 111111111111111111

111111111111 000000000000 000000000000 111111111111 000000000000 111111111111 000000000000 111111111111

1111111111 0000000000 2 0000000000 1111111111 0000000000 1111111111

Private 1

Reference to Group n−1 (VR, S ...

...

(not necessary here)

1111111111111111 0000000000000000 000000000000000 111111111111111 0000000000000000 1111111111111111 000000000000000 111111111111111 0000000000000000 1111111111111111 000000000000000 111111111111111 Public le 0000000000000000 1111111111111111 000000000000000 111111111111111 0000000000000000 1111111111111111 000000000000000 111111111111111 Mutab table 0000000000000000 1111111111111111 000000000000000 111111111111111 0000000000000000 1111111111111111 000000000000000 111111111111111 n Immu 0000000000000000 1111111111111111 000000000000000 111111111111111 0000000000000000 1111111111111111 000000000000000 111111111111111

111111111111111 000000000000000 000000000000000 111111111111111 Private 000000000000000 111111111111111 000000000000000 111111111111111 n 000000000000000 111111111111111

Figure 4: State Splitting failover usually takes at least a few hundreds of milliseconds (recognition of failure, selecting and contacting a new server, restoring state, starting transmission), the failover will be visible to the user anyway, e.g. as a short picture freeze. For applications without strict requirements, state approximation provides an approach to save transmission resources at the cost of small effects to the service quality in the usually quite rare case of failover (e.g. once per week or month).

7 Implementation Considerations This section gives some recommendations on the implementation of client-based state sharing using the RSerPool architecture.

7.1 Authentication and Encryption To ensure confidentiality, authenticity and integrity, appropriate algorithms for digital signatures and encryption are necessary. For authentication, key hashing for message authentication (HMAC) can be used. It is defined in [RFC2104] and provides a simple and efficient algorithm for digital signatures in form of encrypted hash functions. For hash functions, the well-known standards MD5 and SHA1 are available. HMAC-MD5 and HMACSHA1 are also used for IPsec authentication (see [RFC2403, RFC2404]). For encryption, symmetric algorithms are the recommended choice. Since the pool key should only be known by the pool elements, asymmetric algorithms (e.g. RSA, see [RFC2437]) would not improve security but only increase complexity and computation power requirements. Possible standards for the encryption of the private sub-states

are the well known Triple-DES, CAST-128 (defined in [RFC2144]), CAST-256 (defined in [RFC2612]), and MISTY1 (defined in [RFC2994]). To enhance security, it is necessary to change the pool key regularly to a new randomly selected value; change intervals should not exceed more than a few hours. A key change could be initiated by a central management station1 and distributed to the servers using a public key mechanism (e.g. RSA, see [RFC2437]). Note, that it is not allowed to use the old pool key to transmit the new one. Otherwise, a hacker can simply obtain the new key by cracking an older one and decrypting the transmissions of new keys.

7.2 Out-Band and In-Band State Transmission To transmit the state information, two transport methods are possible: Out-Band Transmission: A separate connection can be established between pool user and pool element. The advantage of this method is that the state data does not interfere with the user data. On the other side, synchronisation problems may occur. For example, the user data path may have a higher delay. Then, a new state may reach the pool user before the user data it refers to. Therefore, additional effort to keep the state data and user data synchronized may be necessary. Note that this is application dependent. For example, exact synchronization may not be necessary for some streaming media applications (see State Approximation in section 6). 1

Due to the large key change interval of e.g. some hours, this should be no problem.

In-Band Transmission: The other possibility for the state connection is to add the state data to the user data stream itself. The advantages of this approach are that no additional connection maintenance is necessary and synchronization with the user data is ensured. But the in-band transmission requires a mechanism to separate state and user data. Using SCTP as transport protocol, state data identification is trivial due to the Payload Identifier field (see [RFC2960]). The RTP protocol (see [RFC1889]) provides a Payload Type field to separate different data types. But for other protocols like TCP and UDP, additional effort for the state and user data multiplexing is necessary. Therefore, the in-band approach may require additions to the application protocol.

7.3

Crash Protection for the Clients

To protect against crashes of the client itself, the server state along with the client’s state can be saved to disk, either regularly or on every change. After the client is restarted, the saved states of client and server can be restored. Note, that state saving could be realized using a RAM disk instead of a hard disk. If the client’s operating system itself crashes rarely, this approach may provide acceptable reliability at very low cost - no slow hard disk access is necessary.

7.4

Reliable Transactions

A failover is triggered when the existing transport connection to a pool element is broken. For example using SCTP, no acknowledgements for data or answers to heartbeats are received anymore (see [RFC2960]). After a transport connection to a new pool element is established, already queued data can be sent to the new destination. But data that has been sent to the old pool element and that has already been acknowledged by the transport layer (not by a new state cookie) is lost. That is, if reliability is required, it has to be ensured above the transport layer. For example, the user selects a product for the shopping cart. The message to add the product has been sent and the transport layer received an acknowledgement for its delivery. But no new state cookie has been received. Now, the pool element fails. This means that the client has to

revert to the last state received from the server (here: before the product has been added) and redo all later actions. Such behaviour for the client can be realised using savepoints as it is usually done in SQL database management systems (DBMS). That is, the client saves all client-side states and is able to make a rollback to them. There are two kinds of savepoints, major and minor ones: Major Savepoint: When the pool element acknowledges the client’s actions up to this savepoint (by sending a new state cookie), all earlier savepoints may be deleted. Major savepoints should be used synchronously. That is, after setting a major savepoint, the client should wait for the pool element’s updated state. Minor Savepoint: The client is able to revert to the state of this savepoint but must be prepared to revert to earlier ones down to the last major savepoint. Minor savepoints may be set asynchronously, that is the client does not wait for the updated server state. The following table shows an example for the shopping cart system described in section 1: Step 1 2 3 4 5 6 7 8

Action User begins product selection Set major savepoint S1 User selects a product Set minor savepoint S1.1 User selects another product Set minor savepoint S1.2 User completes product selection Set major savepoint S2

Note, that the savepoint mechanism is used at the client to manage the states of the client application only; it is independent of the server state transmission. That is, the pool element decides when to transmit its states.

8 Summary and Conclusions In this paper, an efficient, simple and scalable approach for state sharing in server pools has been presented, which is applicable to a large range of server

pooling applications: The server states are transmitted to the client using an extended cookie mechanism and kept up-to-date there. In case of a failover, the client itself is able to transfer the old server state to the new server. The integrity, authenticity and confidentiality of the server state are ensured using digital signatures and encryption. Further, optimisations to the introduced mechanism have been shown, allowing a reduction of the state transmission effort using state splitting (partial transmission of updates), state approximation and derivation of states from application data. Finally, implementation considerations have been presented. Further work will include the formal definition of a state sharing protocol, its implementation and finally standardisation by the IETF.

References [ASAP]

Aggregate Server Access Protocol (ASAP) draft-ietf-rserpool-asap-04.txt

[ENRP]

Endpoint Name Resolution Protocol (ENRP) draft-ietf-rserpool-enrp-03.txt

[RFC1305] Network Time Protocol (Version 3) Specification, Implementation. David L. Mills. March 1992 [RFC1889] RTP: A Transport Protocol for Real-Time Applications. AudioVideo Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. January 1996 [RFC2104] HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997 [RFC2144] The CAST-128 Encryption Algorithm. C. Adams. May 1997 [RFC2268] A Description of the RC2(r) Encryption Algorithm. R. Rivest. January 1998 [RFC2403] The Use of HMAC-MD5-96 within ESP and AH. C. Madson, R. Glenn. November 1998

[RFC2404] The Use of HMAC-SHA-1-96 within ESP and AH. C. Madson, R. Glenn. November 1998 [RFC2437] PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, J. Staddon. October 1998 [RFC2612] The CAST-256 Encryption Algorithm. C. Adams, J. Gilchrist. June 1999 [RFC2960] Stream Control Transmission Protocol. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. October 2000. [RFC2994] A Description of the MISTY1 Encryption Algorithm. H. Ohta, M. Matsui. November 2000 [RSerPool] Architecture for Reliable Server Pooling draft-ietf-rserpool-arch-03.txt