Conference 7.286::fddi

   >>We seem to be drawing a blank in terms of an FDDI controller supporting 
   >>remote boot. Also Windows 95 desktops, so requisite drivers etc. are needed 
   >>even if a suitable NIC is available.
    
    Pure remote boot over Digital's FDDI EISA and PCI NICs is not possible
    since there is no room (or support) for an option ROM.  In the case of
    the PCI FDDI NIC, you'd need to make a serious business case for this
    since it means rearchitecting the board and bus interface chip.  For
    more on that, contact the product manager, George Nielsen, at
    DELNI::G_NIELSEN.
    
    As for network boot, some of the Alpha systems are supporting this. 
    The concept being that a console driver that knows how to communicate
    over the FDDI controller performs the requisite reads/writes to get
    things going before the operating system comes up.  This isn't a
    typical remote boot because the console driver lives in the host, not
    on-board the adapter.  Also, you're limited to systems that support
    this function.
    
    FDDI has not been generally cost-effective to the desktop where issues
    such as remote boot would come into play - as evident by the lack of
    third-party FDDI NICs that support remote boot option ROMS.
    
       - Larry

    re: .0
    
    With regards to Windows 95, the latest DEFPA (FDDI PCI) driver kit
    (v2.42) includes a 32-bit Windows 95 driver.  It has limited protocol
    support, however, because Windows 95 has limited support for FDDI.
    
       - Larry      

   Larry
 
   Thanks for your input - you confirm my findings re: available NICs with 
   remote boot capability...
 
   From what you describe the network boot is just part of a system load in the 
   "end" node. ie. the system has a disk to boot from.
 
   The customer in this instance is Military in nature wanting diskless systems 
   for the ability to connect into networks of different security 
   classifications. Their view is that once a system with a disk has "touched" 
   a high-security LAN then the disk contained in that system is classified to 
   that level and unable to connect to lower levels.
 
   As we move into multimedia and the like I can see more (similar) users 
   wanting to operate remote boot over higher speed networks. Unfortunately the 
   volumes may always be on the low side to make viable production of new 
   boot-ROM ready NICs unlikley.
 
   Do you know whether 100baseT (or FX) or ATM will address this issue ? If 
   they do, then they can steal the market share from FDDI.
 
   I'll trawl these other notes if I can find them.
 
   Rog
 

   >>From what you describe the network boot is just part of a system load in the 
   >>"end" node. ie. the system has a disk to boot from.
 
    Not necessarily.  For example, the console driver I spoke of in .1 is
    stored in flash memory on the system motherboard, not on a disk.
    
   >>The customer in this instance is Military in nature wanting diskless systems 
   >>for the ability to connect into networks of different security 
   >>classifications. Their view is that once a system with a disk has "touched" 
   >>a high-security LAN then the disk contained in that system is classified to 
   >>that level and unable to connect to lower levels.
 
    I understand.  All I'm suggesting is that the FDDI cards don't have
    anything inherent to support remote boot.  However, a driver is a
    driver is a driver.  The host based driver that controls the card can
    be read off a floppy, read off a hard disk, or stored in flash.  You
    don't *have* to have a disk and for custom military applications
    such as yours, a company could write a boot driver and store it in a
    ROM on their system.
    
    >>Do you know whether 100baseT (or FX) or ATM will address this issue ? If 
    >>they do, then they can steal the market share from FDDI.
    
    We'll likely be including remote boot ROM support for future 10/100
    Ethernet cards, but you can check with the Product Manager (again,
    George Nielsen) to be sure.  I don't think that much market share will
    be lost since FDDI is already too expensive for many to implement on
    remote boot clients as you're describing.  Workstations and servers,
    yes, but there's not much interest in running Windows 95 and FDDI.
    
    Regards,
       Larry
    

>   Do you know whether 100baseT (or FX) or ATM will address this issue ? If 

ATM certainly won't support network boot.  Or at least not for some time.  The
code required to just barely exchange packets over ATM is way beyond what is
required for Ethernet or FDDI to load VMS, and that code makes anyone who used
to toggle in bootstraps pause midstride.