removed plain text of non ready ID

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]
-