🚀 go-pugleaf

In article <19921102.120905.916@almaden.ibm.com>, gator@vnet.ibm.com writes:
> In article <1992Oct31.014819.16180@netcom.com>, seifert@netcom.com (Rich
> Seifert) writes:
> 
> > Of course, there will be no connectivity to devices connected to the
> > backbone.  Neither Ethernet nor FDDI devices support source routing.
> > Let's just hope that it won't cause them to crash--The problem area is
> > when someone sends a frame to a multicast (or broadcast) with source
> > routing enabled.  The receiving Ethernet or FDDI station will see a
> > source address with the Routing Information Indicator set to one.  This
> > looks like a multicast source address, which is outlawed in Ethernet.
> 
> While it is a given that Ethernet does not support source routing, I
> beleive FDDI does. I am looking at the Source Routing Supplement to IEEE
> 802.1d (MAC Bridges) (Unapproved Draft) and it mentions SRT operation
> for FDDI several times. Could you please clarify what you mean?


Please notice that ANSI is not IEEE and IEEE is not ANSI.
(Unless your sufficiently cynical to have trouble telling the
difference among standards organizations.)

There is "support" and then there is also "support." Some old versions
of some documents from the ANSI X3T9.5 committee did mention source
routing.

Concretely, I think no stations on the FDDI rings last week at InterOP
sent out any source routed frames that they expected to be handled by
any other stations.


Vernon Schryver,  vjs@sgi.com

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>There is "support" and then there is also "support." Some old versions
>of some documents from the ANSI X3T9.5 committee did mention source
>routing.
>Concretely, I think no stations on the FDDI rings last week at InterOP
>sent out any source routed frames that they expected to be handled by
>any other stations.

Quoted from dpANSI SMT 7.2, June 25, 1992:

page 10, "4.1.2 Addressing"
"In the Source Address field of the MAC header, the I/G bit indicates the
presence or absence of source routing (see 4.1.2.5) informtion."

page 13, "4.1.2.5 MAC addresses"
"For a Source Address, which is always an individual address, the first bit
is either reserved or it is used as a Routing Information Indicator (RII) bit."

My comments:
It seems that the dpStandard allows source routing on FDDI, and sooner or
later this feature will be used by some vendors.

Thomas Ruf
SK
-- 
Thomas Ruf	tom@rsp.de	Schneider & Koch GmbH
{uunet,mcvax}!unido!rsp!tom	Germany

In article <19921102.120905.916@almaden.ibm.com>, gator@vnet.ibm.com writes:
> In article <1992Oct31.014819.16180@netcom.com>, seifert@netcom.com (Rich
> Seifert) writes:
> 
> > Of course, there will be no connectivity to devices connected to the
> > backbone.  Neither Ethernet nor FDDI devices support source routing.
> > Let's just hope that it won't cause them to crash--The problem area is
> > when someone sends a frame to a multicast (or broadcast) with source
> > routing enabled.  The receiving Ethernet or FDDI station will see a
> > source address with the Routing Information Indicator set to one.  This
> > looks like a multicast source address, which is outlawed in Ethernet.
> 
> While it is a given that Ethernet does not support source routing, I
> beleive FDDI does. I am looking at the Source Routing Supplement to IEEE
> 802.1d (MAC Bridges) (Unapproved Draft) and it mentions SRT operation
> for FDDI several times. Could you please clarify what you mean?
> 
We wrote the 802.1d SRT supplement with the idea that Source Routing would
be supported on FDDI at some point. But it is not currently supported,
meaning that the frame formats for Source Routing are not part of the FDDI
standard. (802 can't make requirements of FDDI, which is ANSI.)


-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"

In article <1076@rsp.UUCP>, tom@rsp.UUCP (Thomas Ruf) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >There is "support" and then there is also "support." Some old versions
> >of some documents from the ANSI X3T9.5 committee did mention source
> >routing.
> >Concretely, I think no stations on the FDDI rings last week at InterOP
> >sent out any source routed frames that they expected to be handled by
> >any other stations.
> 
> Quoted from dpANSI SMT 7.2, June 25, 1992:
> 
> page 10, "4.1.2 Addressing"
> "In the Source Address field of the MAC header, the I/G bit indicates the
> presence or absence of source routing (see 4.1.2.5) informtion."
> 
> page 13, "4.1.2.5 MAC addresses"
> "For a Source Address, which is always an individual address, the first bit
> is either reserved or it is used as a Routing Information Indicator (RII) bit."
> 
> My comments:
> It seems that the dpStandard allows source routing on FDDI, and sooner or
> later this feature will be used by some vendors.


I bet not, at least for TCP/IP.   Other protocols may well be different.

By the time someone tries to use source routing on FDDI rings, the
installed base of RFC-1188 based TCP/IP/FDDI machines will be too big
to change or fix.

It will be Ethernet vs. 802.3 all over again.  (RFC-1042 encapsulation
on ethernets has been the coming thing for many years.)

Will anyone's current TCP/IP/FDDI implementation cope well when
presented with a packet with other than 13 bytes of MAC header?  For
example, how many people using the DEC or Motorol MAC's just set the
bit that tells the MAC to ignore all frames with the source route bit
set?  (That bit seems handy for at least gracefully ignoring frames
with surprising MAC headers.)


Vernon Schryver,  vjs@sgi.com