blob: a1a7a4bbb779834abe65a841559df23ba0b80bc0 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd' [
<!ENTITY rfc3068 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml'>
]>
<rfc ipr='full3978' docName='draft-gsenger-anycast-tcp-stream-relay-00'>
<front>
<title>Anycast TCP stream relaying</title>
<author initials='O.G.' surname='Gsenger'
fullname='Othmar Gsenger'>
<organization></organization>
<address>
<postal>
<street>Sporgasse 6</street>
<city>Graz</city>
<code>8010</code>
<country>AT</country>
</postal>
<phone></phone>
<email>otti@wirdorange.org</email>
<uri>http://anytun.org/</uri>
</address>
</author>
<date month='March' year='2007' />
<area>General</area>
<workgroup></workgroup>
<keyword>anytun</keyword> <keyword>Internet-Draft</keyword>
<keyword>Anycast TCP relaying</keyword>
<abstract>
<t>The anycast tunneling (anytun) protocol defines a protocol used for communication between unicast clients and anycast servers. It can be used for tunneling information between 2 clients over the servers or in relay mode to transmit data form the client over the servers to a third party not using the protocol and vice versa.
</t>
</abstract> </front> <middle>
<section title="full anycast tcp">
<section title="Introduction">
<t>TCP is statefull, this is a big problem, because every anycast server has to know the tcp state. The TCP state has to be synced between the servers, that meens a lot of overhead. To keep this amount small and therefor make anycast TCP connections efficient some tricks MUST be used. This is considered to be a real hack, so it is not recommendid to use this mode unless it is really necessary. It might for instance be necessary to build connection trough special kind of NAT routers or firewalls.
</t>
</section>
<section title="Reducing syncronisaton overhead">
<section title="Fragmentation">
<t>
The only way of fully supporting fragmentation would be to syncronise fragments between all anycast servers. This is considered to be to much overhead, so there are two non perfect solutions for this problems. Either fragmentation HAS TO be disabled or if not all fragments arrive at the same server the ip datagramm HAS TO be discarded. As routing changes are not expected to occure very frequently, the ip datagram will get retransmitted by TCP and all fragments will arrive at the new server.
</t>
</section>
<section title="sequence number">
<t>It is nessarary to send tcp segments with a correct sequence number, that appear to come from the same host, in order to get a valid connecton to the client. Syncronisation of sequence numbers would mean to much overhead, so it hast to be provided by the relayed data. The relayed data from the anycast serveres point of view, consits of multible datastream, each directed from one client to anotherIn tunneling mode all anytun packets from the client
</t>
</section>
</section>
<section title="keep alive message request">
<t>Most NAT routers need a tcp connection to transmit some packets once in while to stay open. In full anycast tcp mode anytun hast to predict the tcp state including the sequence number. Synconisation of the sequence number would be to much overhead, so a keep alive intervall is agreed. This interval is used to calculate the sequemce number.</t>
</section>
</section>
<appendix title='The appan'></appendix>
</middle>
<back>
<references>
&rfc3068; An Anycast Prefix for 6to4 Relay Routers
</references>
</back>
</rfc>
|
