iFCP: Broadcast support

[Charles Monia <cmonia@NishanSystems.com>]

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, November 20, 2001 3:56 PM
> To: cmonia@NishanSystems.com
> Cc: ips@ece.cmu.edu
> Subject: RE: iFCP: iFCP -06 comments
> 
> 
> > > > > 10.4 b) What happens when the broadcast frame exceeds 
> the MTU size?
> 
> [... snip ...]
> 
> > We had intended to use IP datagram fragmentation
> 
> Oh ... I'm not sure that's a real good idea.  Using IP 
> fragmentation is
> one of the few ways to make UDP datagram delivery even less reliable
> than it already is.  This puts FC broadcast at the mercy of code that
> doesn't
> fragment correctly at both iFCP and network nodes 
> (infrequently used code
> paths are subject to bit rot) and systems in the network that can't or
> don't want to deal with IP fragments (e.g., firewalls and 
> NAT/NAPT boxes)
> and hence drop rather than fragment.  For source 
> fragmentation, discovering
> the MTU to fragment to may also be a problem area.
> 
> While I'm not going to put my foot down yet, I would advise 
> thinking about
> using TCP to deliver FC broadcast frames over iFCP.  If FC 
> broadcasts are
> infrequent and not performance critical, perhaps iSNS could 
> provide the
> FC broadcast forwarding service?  This would also clean up 
> any issues around
> whether an iFCP gateway knows about all the other gateways in 
> the fabric,
> as the iSNS server always knows this.
> 

We are considering a client-server variant of the above in which the iSNS
server supplies the address of a an iFCP "broadcast server", rather than
performing the actual broadcast itself.  An iFCP gateway that supports FC
broadcast would implement the iFCP Broadcast Client and may implement the
iFCP Broadcast Server function. Broadcast traffic would be sent and received
using iFCP.

The server replicates any FC frames it receives and retransmits them to
broadcast clients on other gateways for local redistribution.  A client does
not receive a copy of any broadcast frame it originates. 

The broadcast server and its clients would each have an N_PORT network
address whose N_PORT I/D component was 0xff-ff-ff ( corresponding to the
well-known address of the FC broadcast server.)

Charles