SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: fcovertcpip - N_Port support.



    Josh,
    
    > Rather, the 2nd diagram in section 6.2
    
    We must be reading different documents, because there are no diagrams in
    section 6.2! As I said in my previous email, section 6.2 is not completely
    developed, and since I am not the author of the document, I interpreted
    section 6.2 to include the possibility of connecting direct host-to-storage
    without any intervening BSW switches.
    
    Are you somehow inferring details presented in section 6.1 as requirements
    for section 6.2?
    
    Perhaps one of the authors can clarify what section 6.2 is about, and I will
    step out of the way...
    
    Best Regards,
    
    Venkat Rangan
    Rhapsody Networks Inc.
    http://www.rhapsodynetworks.com
    
    
    
    -----Original Message-----
    From: Joshua Tseng [mailto:jtseng@NishanSystems.com]
    Sent: Thursday, December 14, 2000 5:39 PM
    To: Venkat Rangan; IP Storage Working Group
    Subject: RE: fcovertcpip - N_Port support.
    
    
    Venkat,
    
    > I think an implementation per fcovertcpip-section 6.2, also
    > requires the
    > mapping of S_ID and D_ID of FC frames at the N_Port entry
    > into routable IP
    
    I do not read the same thing from section 6.2.  The diagrams in
    the FCIP document do not support your assertion.  There is nothing
    to indicate that FC devices can be directly attached to the FCIP
    gateway, unless an FC switch (i.e., BSW) has also been implemented
    in the FCIP gateway.  Rather, the 2nd diagram in section 6.2 clearly
    indicates that FC traffic must be routed by a BSW before they can
    ingress the tunnel supported by the FCIP gateway.  The BSW is running
    the FSPF routing protocol to determine which tunnel link should be
    used for the next hop.
    
    > addresses. After this mapping, the FC Frame Encapsulation
    > (section 5.2 of
    > the draft) takes place and these encapsulated frames can be
    > sent out on the
    > link-layer interface of IP address (corresponding to S_ID)
    > directly, without
    > involvement of FSPF or E_Ports/ISLs. The component that does
    > this is very
    > much identical to your iFCP Portal.
    
    Again, I disagree.  Nothing in the FCIP document indicates that the
    FC frame can be routed without the involvement of FSPF which is
    running on the BSW.  The functionality of the FCIP gateway is
    different and far more limited than that of the iFCP Portal.  FCIP
    is merely a tunnel or conduit, one instantiation of an ISL.  It
    does not do routing.  The FCIP must rely on the FC switch to do
    the routing.
    >
    > There could be other devices whose S_ID and D_ID do not get
    > mapped to IP
    > addresses, and they are routed by FSPF-established
    > E_Port/ISLs. So, both
    > routing planes can coexist. If there is no FC plane routed
    > traffic (i.e.,
    > all name server objects have an IP address mapped to it), it
    > degenerates
    > into an iFCP switch/gateway, as specified in your draft.
    >
    > When we look at the Name Server object in FC-GS-3, it already
    > has provisions
    > to map FC WWN to an IP Address. An implementation can
    > recognize the presence
    > of an IP Address in this object to decide whether they are
    > sent out on the
    > IP routing plane or the FC routing plane. The name server itself is a
    > standard function of all FC-SW-2 switches.
    
    I believe the IP address object (Object No. 5) you are refering to is
    the IP address used to send and receive IP traffic over the FC network.
    One example of its use is for SNMP messages and traps from the FC interface.
    This object is already in use and it would be inappropriate to attempt to
    use this field to tunnel FC frames originating from the device.
    
    Regards,
    Josh Tseng
    
    >
    > Regards,
    >
    > Venkat Rangan
    > Rhapsody Networks Inc.
    > http://www.rhapsodynetworks.com
    >
    > -----Original Message-----
    > From: Joshua Tseng [mailto:jtseng@NishanSystems.com]
    > Sent: Thursday, December 14, 2000 3:57 PM
    > To: Venkat Rangan; IP Storage Working Group
    > Subject: RE: fcovertcpip - N_Port support.
    >
    >
    > Venkat,
    >
    > I believe you have a good starting point.  I will offer a
    > second area of consolidation--that iFCP and FCIP can adopt
    > a common encapsulation and framing method.  This shouldn't
    > be too hard--a common encapsulation over TCP that can
    > support both FCIP and iFCP should be easy to work out.
    >
    > However, the biggest difference between iFCP and FCIP is
    > in the addressing and routing mechanisms.  iFCP maps FC
    > addresses to IP addresses, which allows IP switches and
    > IP routing protocols to route the encapsulated frames to the
    > destination FCP Portal over the IP network.  FCIP on the
    > other hand relies on the FC switch and FSPF routing protocol
    > to route traffic to the final destination, with the role of
    > the IP network only to connect tunnel endpoints within the
    > FC network.  This is the difference which I am having a hard
    > time reconciling.
    >
    > Maybe it might be possible to create a common framework,
    > (rather than a common protocol), under which both of these
    > separate and unrelated mechanisms can be specified.  The
    > framework would allow for address translation of FC addresses
    > into IP addresses & N_PORT ID's, as well as for tunneling of
    > the frames unchanged over the IP network.
    >
    > How does this suit everyone???
    >
    > Josh
    >
    > >
    > > In looking at the latest draft-ietf-ips-fcovertcpip-01.txt
    > > document, it
    > > looks like Section 6.2 (below) could cover the ability to provide
    > > connectivity between N_Ports (the area that iFCP covers in
    > > great detail).
    > > May be it needs some additional work to diagram and explain
    > > how this is
    > > possible, but if that is the case, what additional
    > > capabilities does iFCP
    > > proposal provide? Would this not be a natual way to
    > integrate the two?
    > >
    > > From draft-ietf-ips-fcovertcpip-01.txt:
    > > >   6.2 FC Device
    > > >
    > > >      The protocol encapsulation and mapping of the FC frame
    > > described
    > > >      in earlier sections applies equally to any pair of FC devices
    > > >      (e.g. switch-to-switch or host-to-storage subsystem)
    > wishing to
    > > >      tunnel FC frames across an IP-based network.  Any FC routing
    > > >      protocol exchanges may still occur transparently to the FCIP
    > > >      devices.  It should be noted that Fibre Channel Primitive
    > > >      Sequences and Primitives are not exchanged between
    > > FCIP devices.
    > >
    > > Regards,
    > >
    > > Venkat Rangan
    > > Rhapsody Networks Inc.
    > > http://www.rhapsodynetworks.com
    > >
    >
    
    


Home

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