RE: iFCP: RE: FCIP: RE: iFCP

[Charles Monia <cmonia@NishanSystems.com>]

Hi Wayland:

My comments are in line below:

Charles
> -----Original Message-----
> From: Wayland Jeong [mailto:wayland@troikanetworks.com]
> Sent: Monday, November 27, 2000 1:45 PM
> To: 'Charles Monia'; Ips (E-mail)
> Subject: iFCP: RE: FCIP: RE: iFCP
> 
> 
> [ stuff regarding differences between FCIP and iFCP deleted ]
> 
> > With regard to transparency, the decision to support FCP is a design
> choice
> > driven by the fact that this is the only application 
> protocol supported by
> > the vast majority of FC device implementations. If 
> necessary, iFCP can be
> > extended to support the small residue of implementations 
> that support
> other
> > protocols, such as FC-VI.
> > 
> I must have missed something in the iFCP proposal. I still 
> don't see how
> this
> gateway protocol precludes the use of any valid FC-4 mapping. 
> The draft
> describes
> implications to addressing and hence some of the necessary 
> "augmentation" of
> ELS's, but I didn't see anything that deals specifically with 
> FCP. There
> were
> some references to a multi-connection session model (MC) 
> which implied that
> future drafts would support separate FCP_CMD and FCP_DATA TCP 
> connections
> but the current draft mandates the single connection model 
> (SC). In this
> model,
> a TCP session is established or bound when a device PLOGI's 
> with another
> device.
> Once the TCP session is created, the gateway is fairly 
> transparent to the
> ensuing
> conversations.
> 

Yes -- you are correct regarding the level of FC-4 transparency once an
N_PORT login session has been established.

As I've noted, our design goal was storage, since that accounts for the vast
bulk of FC device implementations. This, in turn, drove the definition of
the set of FC link service requests requiring augmentation.

Charles
Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385