Editor's Note: Minutes received 12/4/92
CURRENT_MEETING_REPORT_
Reported by Lansing Sloan/LLNL
Minutes of the IP over Fibre Channel BOF (FIBREIP)
Agenda
o Introduction to Fibre Channel (Lansing Sloan).
o Review ``IP and ARP on Fibre Channel'' Internet-Draft (Yakov
Rekhter).
o What next?
- Level of interest.
- Next steps for document.
Introduction to Fibre Channel
The introduction to Fibre Channel stressed points that influenced ``IP
and ARP on Fibre Channel.''
Fibre Channel (FC) defines several topologies. Some topologies provide
many parallel paths, therefore may not support broadcast and multicast
well. This affects address resolution procedures.
Fibre Channel is being defined by ANSI X3T9.3 in a set of (draft)
standards. ``IP and ARP on Fibre Channel'' depends on one of these
draft standards, ``Fibre Channel -- Physical and Signaling Interface
(FC-PH).'' FC-PH version 3.0 is current. The first ANSI public review
of FC-PH ends January 1, 1993.
Some Fibre Channel prototype implementations were shown in November at
the Supercomputing '92 conference.
Review ``IP and ARP on Fibre Channel''
Fibre Channel has many options, and for interoperability IP must
constrain their use appropriately. Some topics are within the scope of
the Internet-Draft and all others are outside the scope.
IEEE 802.2 LLC and IEEE SNAP are used for encapsulation (but full
support of 802.2 is outside the scope).
Fibre Channel mechanisms (``exchanges'') are used in a unidirectional
manner. When IP traffic is bi-directional, independent ``exchanges''
are used for the two directions. Some optimizations may use more than
two.
For address resolution, a ``hardware address'' consists of a 24-bit
interface ID and a 64-bit ``Initial Process Associator'' (the latter may
1
have a null value). A single IP address may map to multiple hardware
addresses, to support redundant connections.
The ability to do local address resolution configuring (for
bootstrapping and point-to-point links) is required. The ARP server is
optional, it has a well-known address, its external behavior is
described, its internal behavior is not described. The ARP format is
followed; some fields are variable length.
Fibre Channel defines several classes of service, including
connection-oriented and datagram modes. A connection maximizes
performance for a given pair of interfaces but denies service to other
interfaces while the connection lasts. The Draft has some guidelines.
Connections should not last longer than 500 milliseconds.
Some Fibre Channel configurations permit non-transitive behavior. The
Internet-Draft handles this by defining fully-connected ``regions'' and
assigns distinct IP subnets to each region. No router is required for
IP communication within a region. An interface can be in multiple
regions and therefore may have multiple IP addresses.
Controversial and/or Unresolved Issues
There was some strong feeling that either the encapsulations should be
limited to IP/ARP for efficiency or, alternatively, that IEEE 802.2 XID
and TEST functions should be supported. Agreement may have been
reached. For now, in any case, the Draft will not change.
There was some discussion whether the draft should provide more
guidance. It now emphasizes interoperability. For now, that will not
change.
Better wording for ARP on point-to-point connections is needed.
Hosts can learn the hardware addresses of routers using address
resolution, but details were not discussed.
The reason for 500-millisecond connection limits was not discussed.
The draft does not specify reverse ARP. RARP can be provided, but having
hosts pop up in the network may be undesirable.
Decisions (What next?)
Philip Almquist said he thought that the IETF should let ANSI continue
with the technical work for now. Attendance was light, and in effect
there was no independent review of the Internet-Draft by non-ANSI
people. The people with detailed comments all work for companies that
attend ANSI X3T9.3 meetings regularly. The IETF wants an IETF Fibre
Channel working group but Philip said attendance shows that interest is
presently too low.
2
One suggestion was to fix the Internet-Draft until ANSI was happy and
then submit it to IETF for standards processing as a joint BOF/ANSI
contribution. However, because the IETF has not had an effective review
and because the draft is not particularly self-contained (it assumes
familiarity with quite a bit of Fibre Channel), it is unlikely that the
Internet Architecture Board could effectively read the document and
determine if it assures interoperability. Therefore the draft probably
will not be submitted for the IETF standards track until interoperable
implementations based on it exist. This will probably happen next
summer.
Probably the existing ANSI mail groups ``fibre-channel-ext'' and
``fc-ip-ext'' may be used as the IETF mail groups as well, provided that
people are not excluded.
A draft MIB for Fibre Channel is expected within a couple of months.
The IETF still wants the final say and change control on IP standards.
Attendees
Philip Almquist almquist@jessica.stanford.edu
Vickie Brown brown@osi540sn.gsfc.nasa.gov
Paul Griffiths griff@chang.austin.ibm.com
Mark Laubach laubach@hpl.hp.com
Drew Perkins ddp@andrew.cmu.edu
Yakov Rekhter yakov@watson.ibm.com
Lansing Sloan ljsloan@llnl.gov
Elizabeth Vanderbeck beth@tdcsys2.vnet.ibm.com
Gerry White gerry@lancity.com
3