FC over IP: Requirements

["Rodriguez, Elizabeth G (Elizabeth)" <egrodriguez@lucent.com>]

Hello all,

The authors of the FC over IP draft are still in the process of trying to
reformulate the requirements for the FC over IP draft.  In addition,
(according to what I have been told), the decision for where the FC over IP
work item is to be hosted is still being discussed.  It may be placed in the
IPS working group, or the decision may be made to place it elsewhere. In
order to try to minimize confusion, the other authors and I have been
talking offline, while monitoring these lists.

That said, we list below some of what we (the authors of the FC over IP
draft) have been talking about wrt FC over IP requirements:

The basic premise of the FC over IP draft remains unchanged --

Have a high speed IP based interconnect which will bridge FC traffic between
two (or more) SAN islands, such that only the edge devices are aware of the
fact that tunneling of FC frames over IP is being performed.

Included in the initial draft was the following assumption:
The backbone would be at least as reliable and at least as fast as the FC
fabric itself.  With such a restriction, it was expected that congestion
control would not be necessary.

At the Pittsburgh meeting, it was mandated that FC over IP would include
congestion management of some form.  In addition, a few people have
indicated that they expect that this would be run over a lower speed
backbone than the fabric itself.  So, we are investigating options,
including looking at the various transport mechanisms, as well as other
non-transport related mechanisms to perform congestion management. 

As mentioned before, FC over IP is intended (i.e. being written with the
assumption that) this protocol will be implemented in a switch device.
There will be no prohibitions against implementing in a different type of
device, such as an edge device, it will simply not be optimized for
implementation in an edge device.  

Keeping that a switch topology is the target, the addition of transport
support/mechanism to an otherwise level 2 type switch seems to the authors
to be expensive, especially if retries as specified in many of the
transports is required.  Expensive in terms of additional overhead to add
the transport to every FC frame as well as additional hardware requirements.


Another issues that needs to be considered w.r.t. use of a transport is a
transport level retry mechanism.  Some transports do not provide a means by
which retries can be turned off, plus are dynamic in their timeout values
(e.g. when retries are invoked).   If retries are required to be handled in
the transport due to transport design (e.g. we use a transport such as TCP,
where retries cannot be turned off), we feel it may conflict with upper
level exception handling (as mentioned in the 02 draft) as well as create a
cost (financial as well as engineering wise) prohibitive requirement for
buffering of packets at the FC over IP SWITCH while waiting for
acknowledgements.  This is especially when RTT can be on the order of
seconds (e.g. approaches RA_TOV). It is for this very reason we are trying
to consider the various options available to us.  We are considering ECM,
ECN, SCTP, TCP as well as other mechanisms.  We are monitoring the iSCSI
threads regarding Transport for their applicability to this draft as well.
While we cannot guarantee that the FC over IP draft will follow the
transport method iSCSI selects, it will be considered in the analysis for FC
over IP. 

There has never been any intention for this draft to be constrained to a
private network, though that is a possible/plausible environment.  There was
the assumption of a well engineered network though. This requirement is
being omitted, due to both feedback from attendees of the ipfc presentation
as well as direction from the ADs.

Summary of Requirements for FC over IP (from the authors' perspective)

First Draft:
(1) FC and IP devices can be used in conjunction with an 'FC over IP'
compliant edge device UNMODIFIED to bridge traffic between FC islands over
an IP based backbone.
(2) FC over IP compliant devices will support some form of congestion
management.
(3) FC over IP compliant devices will support authentication of the FC over
IP devices before the tunnel shall be established.

Other possible requirements, which will most likely be deferred to a follow
on draft:
(4) Dynamic discovery of other FC over IP edge devices.
(5) Data Encryption support.

Additional requirements are also being sought from the Fibre Channel
community.  A new effort has recently been chartered in the T11
organization, FC-BB2 (Fibre Channel BackBone 2). This group will be used to
solicit further requirements for FC over IP.  FC-BB2 will be a companion
specification to FC over IP and will leverage work done in FC over IP.  It
will not redefine/conflict with FC over IP, but instead will identify and
define amendments to certain FC documents/values to allow greater distance
and performance to be attained over an FC over IP backbone.  FC devices will
not be required to be FC-BB2 compliant in order to work with FC over IP
(this would violate the basic premise of this work), but should a customer
choose to upgrade their FC network to comply with FC-BB2, they could expect
better performance and longer distances to be attained.  Specifically, media
specific issues, speed of light vs. timeout issues, BB credit issues, among
others will be addressed in this specification.  

Notes:
(1) Indicates that FC devices CAN be used unmodified in conjunction with FC
over IP. FC-BB2 will address FC specific issues, and will identify and
define amendments to certain FC documents/values to allow for greater
distance/performance to be attained.  
(2) Retries need to be addressed.  It needs to be determined if retries
support at the transport level, should a transport be included, need to be
required, optional or prohibited.  The authors believe much of this decision
is dependent on how retries are defined by the selected transport.  If it
can be insured that the selected transport retry mechanism will not conflict
with other retry mechanisms, then it may be valuable to support.  On the
other hand, if requirement of retry support makes the FC over IP device an
unattractive solution, due to prohibitive costs associated with implementing
retry, then it should not be supported.

The authors plan to come back with recommendations as well as an initial FC
over IP draft that addresses the new requirements.  

Please direct any feedback or input to the authors (egrodriguez@lucent.com,
muralir@lightsand.com, rajb@lightsand.com, and marjorie.krueger@vixel.com)
as well as to the ips(ips@ece.cmu.edu) and ipfc(ipfc@standards.gadzoox.com)
mailing lists.

Thanks,

Elizabeth G. Rodriguez              Marjorie Krueger
Lucent Technologies                 Vixel Corporation

Murali Rajagopal                    Raj Bhagwat
LightSand Communications            LightSand Communications



-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, August 25, 2000 5:42 PM
To: ips@ece.cmu.edu; ipfc@standards.gadzoox.com
Subject: RE: draft-otis-fc-sctp-ip-00.txt


A couple of comments:

- This discussion should be moved onto the ips mailing
list (ips@ece.cmu.edu) as further IETF work on FC-over-IP
will occur there.  Despite it's name, the fcoverip draft
has not been an official work item of the ipfc WG.  The
use of the ipfc list rather than ips is completely
understandable, as the draft was misnamed, nonetheless,
further discussion should be on ips.

- Wayland wrote:

> I guess, what I'm trying to say is that someone should clearly state the
requirements for
> FCoverIP. If the requirements are that it simply run on a private tuned
network which can
> virtually guarantee a loss-less medium, then I would argue that we don't
need congestion
> control and hence a retry mechanism. I would also argue that FCoverIP is a
niche, proprietary
> solution which probably does not belong in IETF since it is not intended
for the internet.

Not only is that a good argument, it is in fact basically the
position of the IETF, as conveyed by the Area Directors to the
authors of the FC-over-IP draft - congestion control is REQUIRED
if the work is to advance in the IETF because otherwise the
protocol would be unsuitable for the internet.  Whether to have
a retry mechanism is an engineering decision that can be made as
the work progresses (an implementation that didn't have to buffer
for retransmission might consume less memory than one that did),
but congestion control is REQUIRED, period.

Thanks,
--David (co-chair of the ips WG-to-be)

p.s. For those on ips and not ipfc, I'm going to forward the ipfc
	discussion in a separate message.

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
black_david@emc.com  Cellular: +1 (978) 394-7754
---------------------------------------------------