SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    iFCP: RE: FCIP: RE: iFCP



    Hi Folks:
    
    
    To emphasize what others have said in this thread, the issue here is the
    difference in the intent of the two approaches and the end result:
    
    The self-described role of FCIP is to interconnect "Islands" of FC SANs.  At
    the end of the day, with this approach, the user must continue to bear the
    management, training and provisioning costs for both kinds of network.
    
    iFCP together with iSNS (the name service protocol) is designed go beyond
    tunnelling by replacing the fibre channel switching infrastructure with a
    standards-based IP equivalent. This is accomplished, in part, by addressing
    the following issues:
    
    a) Investment Protection -- The architecture (iFCP plus iSNS) allows
    implementations in which existing storage SANs may be seamlessly integrated
    into an IP-based storage fabric.
    
    b) Compatibility --  Due to a legacy of incompatibility, the FC end-user who
    needs to expand storage is often locked into the single-source procurement
    of fibre channel fabric elements. Tunelling will not solve this problem. In
    contrast, the combination of iFCP, iSNS and existing IP standards offers an
    alternative that is fully standards-based from day one. 
    
    c) Scaleability --  iFCP is intended to allow the configuration of IP-based
    storage fabrics that extend beyond the addressability limits imposed by FC
    fabrics.
    
    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.
    
    Charles
    
    > -----Original Message-----
    > From: Murali Rajagopal [mailto:muralir@lightsand.com]
    > Sent: Wednesday, November 22, 2000 5:32 PM
    > To: Joshua Tseng; Vi Chau
    > Cc: ips@ece.cmu.edu
    > Subject: FCIP: RE: iFCP
    > 
    > 
    > With my Technical Coordinator hat off:
    > 
    > I like to clarify that the FCIP protocol forwards all 
    > encapsulated FC frames
    > inside the IP network also based on destination IP 
    > address.There are No FC
    > Switches or no FC switching inside the IP network. In this 
    > respect, both
    > iFCP and FCIP are similar.
    > 
    > Regards,
    > 
    > Murali Rajagopal
    > LightSand Communications
    > 
    > -----Original Message-----
    > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > Joshua Tseng
    > Sent: Tuesday, November 21, 2000 7:26 PM
    > To: Vi Chau
    > Cc: ips@ece.cmu.edu
    > Subject: RE: iFCP
    > 
    > 
    > Hi Vi,
    > 
    > Lest there be any confusion about iFCP and mFCP, I would
    > like to clarify that in these protocols, all next-hop
    > forwarding decisions between switching nodes are made on the
    > basis of the destination IP address, NOT the D_ID as
    > in Fibre Channel switches.  While an iFCP implementation
    > MAY have Fibre Channel elements, these are statelessly
    > mapped to IP.  But once again, all routing and forwarding
    > decisions are made by the switch looking at the destination
    > IP address.  This means you need an IP switch, not a
    > Fibre Channel switch, to route and forward iFCP through
    > a network.
    > 
    > Josh
    > 
    > > -----Original Message-----
    > > From: Vi Chau [mailto:vchau@gadzoox.com]
    > > Sent: Tuesday, November 21, 2000 4:35 PM
    > > To: 'mark.carlson@sun.com'; KRUEGER,MARJORIE (HP-Roseville,ex1)
    > > Cc: 'John Hufferd'; ips@ece.cmu.edu
    > > Subject: RE: iFCP
    > >
    > >
    > > If you have an iFCP gateway that connects multiple
    > > FC nodes to the IP network, and if you want these
    > > FC nodes to talk to one another, you need an FC
    > > switch inside the gateway. An FCoverIP device
    > > works in exactly the same way; but it is not
    > > limited to shipping FCP frames around. It can do
    > > FC-VI, for instance, in addition to FCP. SANs (and
    > > more) can be had with FCoverIP.
    > >
    > >
    > > Vi Chau
    > > Gadzoox Networks, Inc.
    > >
    > >
    > > > -----Original Message-----
    > > > From: Mark A. Carlson [mailto:mark.carlson@sun.com]
    > > > Sent: Tuesday, November 21, 2000 3:16 PM
    > > > To: KRUEGER,MARJORIE (HP-Roseville,ex1)
    > > > Cc: 'John Hufferd'; ips@ece.cmu.edu
    > > > Subject: Re: iFCP
    > > >
    > > >
    > > > IMHO, the most interesting thing about this proposal is that
    > > > "SAN"s can be had without a single FC switch anywhere. This
    > > > is quite different from bridging FC switch based SANs over
    > > > IP.
    > > >
    > > > All the n*n stuff can happen in IP based switches without
    > > > changing hosts or devices (in theory ;-). The "edge connects"
    > > > do the conversion for hosts and devices.
    > > >
    > > > -- mark
    > > >
    > >
    > >
    > 
    

    • Follow-Ups:
      • iFCP vs FCIP
        • From: David Robinson <david.robinson@EBay.Sun.COM>


Home

Last updated: Tue Sep 04 01:06:17 2001
6315 messages in chronological order