From: wittmann@engr.wisc.edu (art wittmann)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: SMT Standard
Date: 9 Apr 92 18:20:17 GMT
Article-I.D.: doug.1992Apr9.132017.3551
Organization: College of Engineering, Univ. of Wisconsin-Madison
Originator: wittmann@muskie.engr.wisc.edu


In article <995@xlnt.COM>, rasp@xlnt.com (Ron Perloff) writes:
|> In article <1992Apr6.020313.18075@berlioz.nsc.com> my@berlioz.nsc.com
|> (Mike Yip), in referring to version 7.x of the draft SMT standards writes:
|> 
|> >Please understand that the newer version of SMT will still be able to
|> >interoperate with version 6.2.  The end-station will probably not need
|> >an upgrade (but of couse an upgrade is nice) but just the network
|> >manager station.
|> 
|> 
|> As I noted in my earlier posting, for basic connectivity and data
|> movement, there is NO PROBLEM in making stations using version 7.x
|> SMT interoperate with stations employing older versions. However,
|> when you try to manage such stations the older versions of the SMT
|> draft standard create some difficulties. Since network management
|> is such a big issue with today's buyers, this creates a practical,
|> i.e. business, problem for board and system vendors.
|> 
|> Here are some of the major issues:
|> 
|> Some portions of the version 6.2 SMT protocol were broken. In
|> order to build structures such as concentrators, we at XDI had to
|> design OUR own 'private' version of the paths portion of the
|> protocol. Other SMT implementers designed THEIR own fixes. Someone
|> writing a network management application would have a VERY
|> difficult time sorting things out. Version 7.0 of the draft
|> standard presents a new, correct paths protocol.
|> 
|> Older versions of the SMT protocol ignored flexible
|> configurations. Organizations building devices allowing power-on
|> insertion and removal of boards again had to develop private
|> solutions for distinguishing between existing and potential
|> configurations. Again, in a heterogeneous environment with diverse
|> solutions, one has a management problem. Version 7.0 corrects it.
|> 
|> Version 7.0 of the draft standard makes PMF Get responses
|> mandatory. They were not mandatory in earlier versions. Without
|> PMF Get responses implemented on the end-stations, a management
|> station working through a proxy agent cannot obtain the
|> information it needs. Since a number of organizations believe in
|> using proxy agents to manage FDDI sub-networks of enterprise
|> networks, end-station vendors, or board vendors selling to
|> end-station vendors, will be at a distinct disadvantage in the
|> marketplace if they do not move up to version 7.x.
|> 
|> Ron
|> 
|> Ronald S. Perloff    rasp@xlnt.com
|> XLNT Designs, Inc. (XDI)
|> 15050 Avenue of Science
|> Suite 106
|> San Diego, CA  92128
|> 
|> 619 487 9320   *   FAX: 619 487 9768

So what does this mean for Joe Average NetManager?  Should one wait for 7.X
complient adaptors, hubs & routers?  Is SMT typically implemented in 
firmware/software or in hardware?  As I understand it, and my understanding
is pretty limited, there should be only one SMT entity per device (i.e. not
per connection).  To me that implies that SMT would often be implemented in
a driver on host computers since a single host could have more than one
ring connection.  Is that true, and therefore would imply that only certain
drivers would have to be upgraded?  In the case of routers & hubs, can
any similar statements be made?

So many questions, so little knowledge (on my part).

Thanks,
Art

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Art Wittmann                                  Phone: (608) 263-1748
Network Manager                               Email: wittmann@engr.wisc.edu
Computer Aided Engineering Center                or: wittmann@cae.wisc.edu
University of Wisconsin, Madison