[1310] in Commercialization & Privatization of the Internet
Re: Interesting new player
daemon@ATHENA.MIT.EDU (stev knowles)
Fri Sep 6 11:13:23 1991
Date: Fri, 6 Sep 91 11:08:36 -0400
To: "Stan Hanks (bcm)" <stan@karazm.math.uh.edu>
From: stev@ftp.com (stev knowles)
Cc: com-priv@psi.com
[sorry this took so long, i was on a business trip]
Anyway, what an encapsulator does is pretty straightforward. Much like a
bridge (or for that matter a gateway) it decides what traffic needs to
be forwarded, to which flow it should be forwarded, then the *whole MAC
datagram* is encapsulated as the data portion of an IP encapsulation protocol
packet, which is then injected into the IP routed network. On arrival at
the target decapsulator, verification is done that this encapsulated packet
is OK to unpack, at which point the MAC datagram is forwarded to the external
network the decapsulator represents.
so, since i assume this is meant to be mac protocol independant, it brings
up some questions that a non-wizard user may run into:
1) since you have a "way" of dealing with out of order packets (playing with
the TOS bits), how are you getting the transit routers to implement the
required functionality? also, you should be aware that the IETF router
requirements working group had trouble changing/adding to the TOS bits.
2) what about duplicate packets?
3) what happens to the ICMP messages that the packet may generate? if
fragmentation is required, are you assuming that the recieving gateway will
reconstruct the packet? what if fragments get lost?
4) what if random packets get lost? are you really basing this on TCP, or
are you planning, over time, to duplicate TCP, as the NFS boyz are on their
way to doing?
this is an interesting concept, and one that some of us have played around
with for the cutover phase to a new version of IP (encapsulating the old IP
in the new verion on the long haul links).
