🚀 go-pugleaf

In article <GAH.92Nov18150548@HP370T.trc.mew.mei.co.jp>, gah@trc.mew.mei.co.jp (Gary A. Hildebrand) writes:
|>All,
|>
|>Let's imagine a hypothetical case.  You want to implement minimal data
|>transport over FDDI, with just enough MAC/SMT support for somewhat robust
|>LLC, and nothing more.  You don't care about MIB management or SRF's at
|>this point.  Anyone who's read through the FDDI standards can tell you what
|>is perscribed as mandatory and what is optional, but how much can you
|>really get away with?  In a real implementation, are any SMT frame services
|>absolutely essential for keeping the ring up?  NIF frames immediately come
|>to mind.  What about the many different types of CMT services and
|>functions?  I would suppose that most nodes would cause trouble if they
|>didn't all implement full RMT and PCM support in or out of the MAC
|>chip/software layer.

If you don't care about standards conformance, and your network is small
enough that you don't feel a need to worry about some of the fancier
fault recovery mechanism, you could cut quite a lot.  You need MAC, PHY,
and PMD as specified, of course.  In SMT, you need very little.  PCM is
necessary, because that's how you talk your neighbor into letting you join
the ring.

However, your node and the ring will work just fine (in the sense of allowing
user data traffic to proceed -- though NOT in the sense of being manageable)
without ANY SMT frames at all.  Of course, you can't get a ring map, not
even from fully conforming stations, unless you at least do NIF by the rules.
And so it goes in general ... the more of the required parts are in fact
present, the more your node resembles a normal, fully manageable, FDDI node.

|>This case is actually not so hypothetical.  I'm wondering about PC FDDI
|>interface cards such as the one from Network Periperals.  Does the small
|>NDIS driver loaded and/or firmware on the board actually implement all the
|>ANSI-draft-standard mandatory components of the MAC/SMT protocols that are
|>not covered by the National chipset, or just a bare minimum functional
|>subset?  Unfortunately, this board comes with little or no technical
|>information.

I don't know about that PC card.  But there is at least one (the DEC one)
where the SMT support is done entirely by firmware (in a 68000) on the
adapter itself.

|>Gary Hildebrand

	paul koning

In article <GAH.92Nov18150548@HP370T.trc.mew.mei.co.jp>, gah@trc.mew.mei.co.jp (Gary A. Hildebrand) writes:
> 
> Let's imagine a hypothetical case.  You want to implement minimal data
> transport over FDDI, with just enough MAC/SMT support for somewhat robust
> LLC, and nothing more.  You don't care about MIB management or SRF's at
> this point.  Anyone who's read through the FDDI standards can tell you what
> is perscribed as mandatory and what is optional, but how much can you
> really get away with?  In a real implementation, are any SMT frame services
> absolutely essential for keeping the ring up?  NIF frames immediately come
> to mind.  What about the many different types of CMT services and
> functions?  I would suppose that most nodes would cause trouble if they
> didn't all implement full RMT and PCM support in or out of the MAC
> chip/software layer.

All you need to play with other standard-conforming FDDI stations
and concentrators is CMT signalling.  You need none of the frame
management stuff including NIF's.  The ring will work just fine even
if other stations' ring maps are bogus.

By "play", I mean just that.  You can't sell a real product that does
not do all of the mandatory stuff in SMT 6.x.  Too many of your biggest
potential customers would run screaming.

> This case is actually not so hypothetical.  I'm wondering about PC FDDI
> interface cards such as the one from Network Periperals.  Does the small
> NDIS driver loaded and/or firmware on the board actually implement all the
> ANSI-draft-standard mandatory components of the MAC/SMT protocols that are
> not covered by the National chipset, or just a bare minimum functional
> subset?  Unfortunately, this board comes with little or no technical
> information.

For many reasons, from the people involved to their evident intention
to make a profitable product to the test beds their systems have been
seen on, I would be very surprised if NPI's products failed to
implement more than just the mandatory part of SMT 6.x or if they do
not soon conform to SMT 7.2.

As you say, there are a lot of messy SMT frames.  I think a case can be
made that handling the SMT frames is about as complicated as doing
TCP/IP.  Fortunately, a straight forward implementation of the
mandatory SMT frames (or of TCP/IP) is not hard, at least for computers
of this decade.  That's shown by the nearly universal support of SNMP
in FDDI concentrators and even ethernet twisted pair hubs.

Ironically, some in ANSI X3T9.5 justified much of the SMT frame based
stuff on the grounds that most stations and concentrators could not
afford TCP or TP4 stacks and so could not use SNMP or CMOT.  The
company that pushed that view hardest was in the business of selling
SMT implementations to other vendors.  Most ironically, that company
was soon seen at test beds with SNMP managed products.


Vernon Schryver,  vjs@sgi.com

In article gah@trc.mew.mei.co.jp (Gary A. Hildebrand) writes:
>Let's imagine a hypothetical case.  You want to implement minimal data
>transport over FDDI, with just enough MAC/SMT support for somewhat robust
>LLC, and nothing more.  You don't care about MIB management or SRF's at
>this point.  Anyone who's read through the FDDI standards can tell you what
>is perscribed as mandatory and what is optional, but how much can you
>really get away with?  In a real implementation, are any SMT frame services
>absolutely essential for keeping the ring up?  NIF frames immediately come
>to mind.  What about the many different types of CMT services and
>functions?  I would suppose that most nodes would cause trouble if they
>didn't all implement full RMT and PCM support in or out of the MAC
>chip/software layer.

Go ask Vernon.  He did that also. ;-)
You don't even need SMT to run FDDI.  I ran a good size
FDDI ring without SMT when our chips first come out.  But if you want
some SMT functionality, then you can probably pick the part that you need.
For example, you can use (all or part of) RMT and CMT in your ring.  If you 
just want to "connect" to the "standard" FDDI ring, you can probably get by
with only PCM and some sort of real simple RMT/CFM.  The problem comes when
something goes wrong.  When the ring is not working right, SMT can help you
to detect and recover from some or most errors.  Do you really need
any of the frame services?  May be not.  But then someone will tell you
that they cannot manage those stations (tell them to get lost or use SNMP ;-)

>
>This case is actually not so hypothetical.  I'm wondering about PC FDDI
>interface cards such as the one from Network Periperals.  Does the small
>NDIS driver loaded and/or firmware on the board actually implement all the
>ANSI-draft-standard mandatory components of the MAC/SMT protocols that are
>not covered by the National chipset, or just a bare minimum functional
>subset?  Unfortunately, this board comes with little or no technical
>information.

Well I don't speak for NPI (and I don't even speak for National), but I think
that NPI has a 100% complete 6.2 SMT.  I don't think that they implemented
all the optional SMT stuffs.  After all, those are optional, right?

All the MAC protocols and more are implement on the National chipset.
The NPI "SMT processor" on board implements the CMT and RMT and possibly some
portion of the frame driver.  The rest runs on the system driver.  

Along the same line, I really don't think that one should associate the 
size of the program with the completeness, robustness, etc., of the program.
But then again, if you prefer to have huge driver to make you feel better, 
you can always patch their code with white space.  ;)  They need to spend
extra time to make the driver small so that it will work in the PC, especially
DOS (or DOG ;-).

---
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!

In article vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>Ironically, some in ANSI X3T9.5 justified much of the SMT frame based
>stuff on the grounds that most stations and concentrators could not
>afford TCP or TP4 stacks and so could not use SNMP or CMOT.  The
>company that pushed that view hardest was in the business of selling
>SMT implementations to other vendors.  Most ironically, that company
>was soon seen at test beds with SNMP managed products.

One argument that ANSI committee brought up was that they "needed"
management for FDDI ring and no one could decide that if a station
would implement SNMP or CMOT or both.  Therefore, SMT frames are 
"needed".  But then again, if the network manager did not brother to
install SNMP for network management, then he probably didn't care
about management or did not know about it.  So ... what good is to 
having SMT frames running around?  Well you can get a pretty ring map.

-- 
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!