🚀 go-pugleaf

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