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,
    
    On your point below:
    
    > 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.
    
    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
    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.
    
    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.
    
    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