Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!OPAL.BERKELEY.EDU!minshall
From: minshall@OPAL.BERKELEY.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP requesting ARP flushes and other "layering violations"
Message-ID: <8710271711.AA06964@opal.berkeley.edu>
Date: Tue, 27-Oct-87 12:11:38 EST
Article-I.D.: opal.8710271711.AA06964
Posted: Tue Oct 27 12:11:38 1987
Date-Received: Thu, 29-Oct-87 23:31:45 EST
References: <8710261735.AA02484@uunet.UU.NET>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 30

>   Hmm, a recent note explaining how with 802.5, TCP may have to 
>   request that the lower levels occassionallly "re-ARP" and that
>   this is somehow inherently evil.  I would like to present an
>   alterntive view.

	Interestingly enought, this is an area where the source routing
scheme of IBM/ 802.5 is superior to the "proxy-ARP" routers (and maybe to
the TransLan ether bridge schemes).  With the latter approaches, if a
bridge/router which is not within "local broadcast" range fails, then there
is no way for the local TCP to request that the path be redetermined.
In the source route (802.5 variety) scheme, the local TCP merely causes a
new route to be determined via a new "all rings broadcast" XID.

	However, I do agree with Mike O'Dell that some method of improving
"local reliability" is a very desirable goal (and is one reason I like
token rings; given that they pass back "delivered" and/or "addressee
unknown" indications).  The flow of information though (as the token
ring case points out) needs to go both ways.  The upper layers need
to be able to say "hey, end-to-end seems to have fallen apart", and
the lower layers need to be able to say "hey, your local packet hasn't
made it because of reason XXX".  The 802.2/x standards address the
latter issue; you get it from the MAC layer in 802.5 (and maybe 802.4),
and from the LLC layer with 802.3 IFF you are a Type 2 802.2 user
(Type 2 ==> link level acks, "flow control", etc.).

	802.2/x doesn't mention the first problem at all (allowing the
upper layers to be able to say "hey, there is some end-to-end problem").
It might be an interesting addition.

Greg Minshall