Subject: I-D: a tcp extension to allow transfer of virtual circuits

From: "David L. Nicol" <[email-masked]>
Date: Sat, 18 Mar 2000 01:20:34 +0000

Experimental                                                  David
Nicol
                                     University of Missouri - Kansas
City
                                                               March
2000				

a tcp extension to allow transfer of virtual circuits

Status of this memo

this request for comments is being written after realizing that several
independent problems could be solved by the method described herein,
which works entirely at the transport layer.  I would like to see this
proposal considered for adoption as an IETF standard, if it is deemed
acceptable.  In particular, the physical format of the commands, beyond
that it may make sense to encapsulate them in the data portion of
invalid
reset packets, is left to be determined by discussion.

Summary

the TCP virtual circuit as defined in Jon Postel's 1981 standard and
subsequently clarified offers no facility for moving an end point of
an established virtual circuit to a different peer.  There are
situations
in which this would be desirable.  This memo suggests a method of 
implementing such a mechanism in such a way that it will co-exist
seamlessly with nonextended TCP, and will work over any link layer that
supports the TCP transport layer abstraction.

1: INTRODUCTION

Thinking about migratable sockets and load sharing, 
I realized that there is an entire class of unimplemented interface
problems, such as how to move a running xterm from one display
to another, and how to implement "user roaming" without channeling
all network traffic through a central forwarding agent, which
could all be solved without making massive changes to all existing
socket based applications, by adding a new primitive to TCP allowing
a peer to "transfer" its end of a virtual circuit to another machine.

2: IMPLEMENTATION OF THE TRANSFER IMPERATIVE EVENT

This primitive would be a communication wedged into the cracks in
current
TCP implementation, either by claiming a "reserved control bit"
or by sending information in the data space of a RST segment.

Packing information into a RST packet looks more doable at this time,
since the RST segment has some spare data area in it, and the
implementation
guidleines in the standard include a variety of situations in which RST
segments are to be dropped.

The primitives would include "prepare-to-accept transfer from
host:socket"
to which the response would be a host identifier:socket number which the
connection could be transferred to; and "transfer to host:socket" which
would cause the requested peer to send further packets in the stream
being
transferred to the new host.

Or the transfer could take place in a single step, by sending extended
RST packets to both peers which are to synchronize and carry on the
virtual
circuit.

3: ONE EXAMPLE OF LIFE MADE EASIER BY USE OF THIS EXTENSION

As an example of this extension in use, imagine a situation in which you
have an x-application running on host A, displayed on display server B,
and you wish to move the display to display server C.

A:3841 <-----> B:6000 ESTABLISHED
C

To transfer the window, B would open a connection to the X-server on C
and
display a placeholding window there, with similar characteristics as the
window A is displaying on B.

A:3861 <------> B:6000 ESTABLISHED
C:6000 <------> B:3094 ESTABLISHED

To this point, all has been accomplished with current TCP.  Using
current
standards, an extended X-server may relay the packets from A to C via B,
however there is no way to phase B's role out.

The extension I am proposing in this message would allow B to send a
message to A and C, so that A and C continue a data stream with each
other,
without B being involved any more.

B would accomplish this by sending A a transfer initation message on the
A:3861-B:6000 channel, stating

"prepare to transfer this channel to C:6000, passively."

This message could take the form of an invalid RST segment including a
data block with enough information to carry the message.

A replies with the number of a socket on A which would be able to
accept this new connection with C.  Usually this will be the current
socket number, but there may be cases when a new number will need to 
be selected.

In these rare cases, A reestablishes the connection being reset for
transfer and initiates a transfer of the A-B circuit to a new port
number on A which will not collide with an existing A-C virtual circuit.

This has the effect of A initiating a connection open, or opening a
socket with the same number as the one connected to B, for listening.

A:3861 <------> B:6000 TRANSFERING
C:6000 <------> B:3094 ESTABLISHED
A:3861                 LISTEN

A can then send B another extended RST packet, indicating that
it is ready to transfer the connection to C.

A noncompliant TCP will of course ignore an invalid reset segment.

This preliminary step having succeeded, B now sends C a message
on the C:6000 <------> B:3094 channel, stating

"transfer this connection to A:3861, actively"

A and C now establish the new connection, using a slow start.

A:3861 <------> B:6000
C:6000 <------> B:3094
A:3861 <------> C:6000

and close their connections with B.

A:3861 <------> C:6000

4: NO EFFECT ON HIGHER LAYERS

There will be no indication that this has occurred, above the transport
layer: it will be indistinguishable from a normal traffic hiccup.

On receipt of ACK of FIN packets, B's system call, if it had been
blocking
for completion of the transfer function, can return with a success code.

5: FAST TRANSFERRING WITH KNOWN-COMPLIANT TCP

If it is known in advance that both peers' TCPs support transferring,
the extended RSTs could be sent to both, immediately, and then again,
in case of a port number collission.

6. SECURITY IMPLICATIONS

To prevent connection transfer being used as a way to tunnel through
common firewall implementations, the resulting connection must be
nominally established as if it were new.

7. STATUS DISINFORMATION

For backwards compatability with applications that may rely on functions
such as getpeername and sin_port member data, the transfer messages may
include an option flag "OPT_REMEMBER" which will cause the TCP software
to
remember what the original host:socket was, instead of the current peer,
after
a transfer, for purposes of responding to status requests.

8. USE CASE: ROAMING

To use this extension to aid roaming, transfers would be arranged by the
"home server" after connections are established, instead of the home
server
continuing to forward all traffic.

9. USE CASE: PROCESS MIGRATION LOAD BALANCING

In process migration based load balancing, tcp connections (with
compliant peers)
could be transferred at migration time and handled by the TCP on the
host machine.

terminology:

In the above example, the "B" host is the "transfer initiating peer."
A and C are "transfer end peers."

On backwards compatability:

I believe that the RST loading method would be the best way to implement
these extensions.  The TCP wishing to initiate the transfer could send
RST
packets to both peers, containing the full description of the current
connection and the connection to be established, actively.  A TCP
compliant with
this standard will attempt a simultaneous open with the new peer instead
of the old one, and send an acknowledgement. An old TCP will merely
reset
the current connection as if there had been a problem, and the transfer 
initiating peer can return from the transferring function with an error
code.

FUNCTIONAL SPECIFICATION:

The privelege to perform the transfer operation will need to
be carefully delegated by the implementing operating system.
Since circuit transfer operations may be initiated by a process
outside the scope of the local connection name, both fully
specified <local socket, foreign socket> pairs will need to appear
in the invocation of a circuit transfer initation call, such as

Join

   Format: JOIN (
	first local address, 
	first local port,
	first foreign address, 
	first foreign port,
	second local address, 
	second local port,
	second foreign address, 
	second foreign port
	)

This call would cause the two fully specified connections
to be validated for existence and establishment, and then
combined as described in the example.

Transfer

   Format: TRANSFER (
	local address, 
	local port,
	foreign address, 
	foreign port,
	second foreign address, 
	second foreign port
	)

This call would be in effect similar to a http Location: directive;
causing an extended RST to be sent, which would indicate that the
connection would be better carried out with the TCP at the second
link and port, which doesn't know you're coming, but which may be
better prepared to provide the desired service.  Widely adopted
implementation of this extension could greatly ease design of graceful
load balancing, as after a server is operating at capacity instead
of merely saying "Sorry, full up!" it could explicitly and instantly
(no waiting for backup MX records to propagate through the DNS) refer
the connection to another server.

references: rfcs 793, 2414, 1379, 2525, 721, 875

Author:
David Nicol 
[email-masked]
post office box 45163
kansas city Missouri 64171