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: ... Transmission of IP Datagrams over IEEE 802 ...
Message-ID: <8710220534.AA26692@opal.berkeley.edu>
Date: Thu, 22-Oct-87 01:34:30 EDT
Article-I.D.: opal.8710220534.AA26692
Posted: Thu Oct 22 01:34:30 1987
Date-Received: Sat, 24-Oct-87 15:59:58 EDT
References: <3178@ames.arpa>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 28

Hugh,
	The catch is that, as defined by IBM and (apparently) by the
current work in 802.5, "source routing" is a MAC issue.  MAC, which
means Media Access Control (or some such) is separate from LLC (==
Logical Link Control).  802.2 is LLC; if source routing were a LLC
entity, then it would apply to all 802.X MAC layers.

	I *suppose* that some of the past controversy about source
routing was whether it belonged at the MAC layer, or at the LLC
layer.  To me, it seems it belongs at the LLC layer, since routing
information (in the IBM scheme) is acquired by an LLC-layer broadcast
(a TEST or XID command) which picks up (and returns) routing information.
Additionally, the IBM "SEND_MAC_DATA" primitive (which corresponds with
the 802.2 MA_DATA.request primitive) supplies, in addition to the
MAC address of the destination, the "source route" (previously
acquired).

	Anyway, source routing is purely an 802.5 issue.  The source
routing happens during 802.5 MAC encapsulation, not during 802.2 LLC
encapsulation.  The 802.2 encapsulation remains the same.

	What it does mean, I guess, is that the interface (in your
kernel, or whereever) between the LLC and MAC layers is different
with an 802.5 MAC than with an 802.3 or 802.4 MAC.

	Hope this sheds a bit more light.

Greg Minshall