RE: fcovertcpip - N_Port support.

[Joshua Tseng <jtseng@NishanSystems.com>]

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
> >
>