Conference noted::atm

    The SPD onRIS Bootp says it supports the DEFPA FDDI cards, are the
    ATM cards not DEFPA cards as well?      

The DEFPA cards are FDDI cards, not ATM cards.

doug

	How does RIS work?

	If you do something like
		>>> boot -protocols bootp ewa0

	the system broadcasts a bootp request....
		   ^^^^^^^^^^

	Now to ATM. ATM is a Non Broadcast Multiple Access (NBMA) media.

	You would need some prerequisites to do a broadcast over ATM
	(you basically have to emulate multicasts and broadcasts):

	You need a Multicast Address Resolution Server (MARS), or at least
	a Multicast Server (MCS), the NSAP of that MARS/MCS, an up and
	running ATM subsystem with signalling (ILMI) enabled, a VC to the
	MARS/MCS.
	Then you could send a bootp request to the MARS/MCS which in turn would
	send it to all registered end systems. If your 

	But I don't think that all the prerequisites (MARS, running ATM
	subsystem, signalling, etc.) would nicely fit into the console code
	(which is already about 2 MB, when memory serves right). So this
	is no UNIX issue for the RIS client.
	Not to mention that there's no MARS implementation for
	DIGITAL UNIX <whatever_version> currently available.

	Nevertheless, it would be definately breath taking to do a RIS install
	over ATM regarding the speed!

	But NFS over ATM runs just fine (up to the point when you lose the
	ATM connection to the NFS client/server. NFS can't imagine that it
	cannot write to a device which is the case when you lose the VC or PPA.
	Even if your VC to the NFS clien/server comes back online, NFS is still
	puzzeled about a failure of the write call and hangs there).

	Rudi

|	the system broadcasts a bootp request....
|		   ^^^^^^^^^^

        While this is not supported with our gear, you do not actually
        have to broadcast. I have seen ATM based set top boxes that have
        their "bootp" server NSAP in PROM/Flash and then just sets up an SVC
        directly to it to load.

	>Per

    We don't support RIS installing or running diskless on systems with
    only an ATM adapter.  There is no console support for booting over ATM,
    and as Rudi mentioned it would be a significant task just to fit it in.
    
    If the clients are on Ethernet, FDDI, etc and it is the server that has
    only ATM, then it should work, provided the router in between can act
    as a "bootp relay agent".
    
    	/gary
    

	
    Re: .4

    If you wanted to support SVC-based booting, you wouldn't even need to
    configure the server address in every workstation.

    Just configure it once in each switch, and have the workstations read
    it from the ILMI Service Registry MIB, like LECs do.  Benefit: if the
    server address changes, you'd have many fewer copies to update.

|   Just configure it once in each switch, and have the workstations read
|   it from the ILMI Service Registry MIB, like LECs do.  Benefit: if the
|   server address changes, you'd have many fewer copies to update.

That is a good idea. The environment I was talking about did not have ILMI.
Also, the slight drawback with using ILMI as the only source is that offers
only one boot server for all systems connected to that switch (unless you
have an elaborate negotation protocol) and also assumes that the first switch
will actually know; your first switch may be nothing but a front end, like
a 6 port Virata. Perhaps a combination of the two would work: check prom
first and if nothing, default to ILMI?

Cheers,

>Per

>  Also, the slight drawback with using ILMI as the only source is that offers
>  only one boot server for all systems connected to that switch (unless you
>  have an elaborate negotiation protocol)

That depends upon the implementation.  Ours will let you set up things so that
one group of workstations sees addresses A and B, while another sees address C.
Each peer ATM node thinks it sees "THE" Service Registry MIB, when in fact, it
sees the view that the switch wants it to see.

>  Perhaps a combination of the two would work: check prom first and if
>  nothing, default to ILMI?

Yes.

For the case where the front-end switch does not implement the Service Registry
MIB, you could use a well-known ATM address.

You'd probably have to submit a SVC-boot proposal to the ATM Forum to get one -
but having a standardized version might not be all that bad.

    Will we be supporting RIS/bootp/diskless in the future? It seems it's been
    identified how to do it, is this something we will be doing?
    
    SUN would not commit to my customer (Sandia Labs) that they would do
    it.
    
    Mike p.

    Some aspects of "how to do it" have been identified.  There are more,
    in particular, how do you cram an ATM driver, signalling stack, 
    ILMI and RFC1577 into the 2 MB of memory available to the console
    (which is already heavily overlayed and has trouble fitting on large
    configurations).
    
    Also, it's unlikely to be supported across all platforms...there aren't
    console development resources available to make such major changes to
    older consoles.  Actually, I don't believe all platforms currently
    support diskless operation, although I think they all support ris.
    
    I'm not aware of any current plans to support or to investigate supporting
    RIS/bootp/diskless over ATM.  Since this would involve significant
    development work for the console (hardware) groups, I suspect it will
    only happen if someone makes the case that it will generate significant
    incremental hardware revenue.
    
    	/gary