diff options
Diffstat (limited to 'internet-draft-anycast-tcp-stream-relay.txt')
| -rw-r--r-- | internet-draft-anycast-tcp-stream-relay.txt | 392 |
1 files changed, 0 insertions, 392 deletions
diff --git a/internet-draft-anycast-tcp-stream-relay.txt b/internet-draft-anycast-tcp-stream-relay.txt deleted file mode 100644 index ad91815..0000000 --- a/internet-draft-anycast-tcp-stream-relay.txt +++ /dev/null @@ -1,392 +0,0 @@ - - - -Network Working Group O. Gsenger -Internet-Draft March 2007 -Expires: September 2, 2007 - - - Anycast TCP stream relaying - draft-gsenger-anycast-tcp-stream-relay-00 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 2, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 1] - -Internet-Draft Anycast TCP stream relaying March 2007 - - -Abstract - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 2] - -Internet-Draft Anycast TCP stream relaying March 2007 - - -1. full anycast tcp - -1.1. Introduction - - 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. - -1.2. Reducing syncronisaton overhead - -1.2.1. Fragmentation - - 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. - -1.2.2. sequence number - - 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 - -1.3. keep alive message request - - 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. - - - - - - - -Gsenger Expires September 2, 2007 [Page 3] - -Internet-Draft Anycast TCP stream relaying March 2007 - - -Appendix A. The appan - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 4] - -Internet-Draft Anycast TCP stream relaying March 2007 - - -2. References - - [1] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", - RFC 3068, June 2001. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 5] - -Internet-Draft Anycast TCP stream relaying March 2007 - - -Author's Address - - Othmar Gsenger - Sporgasse 6 - Graz 8010 - AT - - Phone: - Email: otti@wirdorange.org - URI: http://anytun.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 6] - -Internet-Draft Anycast TCP stream relaying March 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Gsenger Expires September 2, 2007 [Page 7] - |