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