home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 92nov / fibreip-minutes-92nov.txt < prev    next >
Text File  |  1993-02-17  |  6KB  |  157 lines
  1. Editor's Note:  Minutes received 12/4/92
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Lansing Sloan/LLNL
  7.  
  8. Minutes of the IP over Fibre Channel BOF (FIBREIP)
  9.  
  10. Agenda
  11.  
  12.  
  13.    o Introduction to Fibre Channel (Lansing Sloan).
  14.    o Review ``IP and ARP on Fibre Channel'' Internet-Draft (Yakov
  15.      Rekhter).
  16.    o What next?
  17.  
  18.       -  Level of interest.
  19.       -  Next steps for document.
  20.  
  21.  
  22. Introduction to Fibre Channel
  23.  
  24. The introduction to Fibre Channel stressed points that influenced ``IP
  25. and ARP on Fibre Channel.''
  26.  
  27. Fibre Channel (FC) defines several topologies.  Some topologies provide
  28. many parallel paths, therefore may not support broadcast and multicast
  29. well.  This affects address resolution procedures.
  30.  
  31. Fibre Channel is being defined by ANSI X3T9.3 in a set of (draft)
  32. standards.  ``IP and ARP on Fibre Channel'' depends on one of these
  33. draft standards, ``Fibre Channel -- Physical and Signaling Interface
  34. (FC-PH).'' FC-PH version 3.0 is current.  The first ANSI public review
  35. of FC-PH ends January 1, 1993.
  36.  
  37. Some Fibre Channel prototype implementations were shown in November at
  38. the Supercomputing '92 conference.
  39.  
  40. Review ``IP and ARP on Fibre Channel''
  41.  
  42. Fibre Channel has many options, and for interoperability IP must
  43. constrain their use appropriately.  Some topics are within the scope of
  44. the Internet-Draft and all others are outside the scope.
  45.  
  46. IEEE 802.2 LLC and IEEE SNAP are used for encapsulation (but full
  47. support of 802.2 is outside the scope).
  48.  
  49. Fibre Channel mechanisms (``exchanges'') are used in a unidirectional
  50. manner.  When IP traffic is bi-directional, independent ``exchanges''
  51. are used for the two directions.  Some optimizations may use more than
  52. two.
  53.  
  54. For address resolution, a ``hardware address'' consists of a 24-bit
  55. interface ID and a 64-bit ``Initial Process Associator'' (the latter may
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. have a null value).  A single IP address may map to multiple hardware
  64. addresses, to support redundant connections.
  65.  
  66. The ability to do local address resolution configuring (for
  67. bootstrapping and point-to-point links) is required.  The ARP server is
  68. optional, it has a well-known address, its external behavior is
  69. described, its internal behavior is not described.  The ARP format is
  70. followed; some fields are variable length.
  71.  
  72. Fibre Channel defines several classes of service, including
  73. connection-oriented and datagram modes.  A connection maximizes
  74. performance for a given pair of interfaces but denies service to other
  75. interfaces while the connection lasts.  The Draft has some guidelines.
  76. Connections should not last longer than 500 milliseconds.
  77.  
  78. Some Fibre Channel configurations permit non-transitive behavior.  The
  79. Internet-Draft handles this by defining fully-connected ``regions'' and
  80. assigns distinct IP subnets to each region.  No router is required for
  81. IP communication within a region.  An interface can be in multiple
  82. regions and therefore may have multiple IP addresses.
  83.  
  84. Controversial and/or Unresolved Issues
  85.  
  86. There was some strong feeling that either the encapsulations should be
  87. limited to IP/ARP for efficiency or, alternatively, that IEEE 802.2 XID
  88. and TEST functions should be supported.  Agreement may have been
  89. reached.  For now, in any case, the Draft will not change.
  90.  
  91. There was some discussion whether the draft should provide more
  92. guidance.  It now emphasizes interoperability.  For now, that will not
  93. change.
  94.  
  95. Better wording for ARP on point-to-point connections is needed.
  96.  
  97. Hosts can learn the hardware addresses of routers using address
  98. resolution, but details were not discussed.
  99.  
  100. The reason for 500-millisecond connection limits was not discussed.
  101.  
  102. The draft does not specify reverse ARP. RARP can be provided, but having
  103. hosts pop up in the network may be undesirable.
  104.  
  105. Decisions (What next?)
  106.  
  107. Philip Almquist said he thought that the IETF should let ANSI continue
  108. with the technical work for now.  Attendance was light, and in effect
  109. there was no independent review of the Internet-Draft by non-ANSI
  110. people.  The people with detailed comments all work for companies that
  111. attend ANSI X3T9.3 meetings regularly.  The IETF wants an IETF Fibre
  112. Channel working group but Philip said attendance shows that interest is
  113. presently too low.
  114.  
  115.  
  116.  
  117.                                    2
  118.  
  119.  
  120.  
  121.  
  122.  
  123. One suggestion was to fix the Internet-Draft until ANSI was happy and
  124. then submit it to IETF for standards processing as a joint BOF/ANSI
  125. contribution.  However, because the IETF has not had an effective review
  126. and because the draft is not particularly self-contained (it assumes
  127. familiarity with quite a bit of Fibre Channel), it is unlikely that the
  128. Internet Architecture Board could effectively read the document and
  129. determine if it assures interoperability.  Therefore the draft probably
  130. will not be submitted for the IETF standards track until interoperable
  131. implementations based on it exist.  This will probably happen next
  132. summer.
  133.  
  134. Probably the existing ANSI mail groups ``fibre-channel-ext'' and
  135. ``fc-ip-ext'' may be used as the IETF mail groups as well, provided that
  136. people are not excluded.
  137.  
  138. A draft MIB for Fibre Channel is expected within a couple of months.
  139.  
  140. The IETF still wants the final say and change control on IP standards.
  141.  
  142. Attendees
  143.  
  144. Philip Almquist          almquist@jessica.stanford.edu
  145. Vickie Brown             brown@osi540sn.gsfc.nasa.gov
  146. Paul Griffiths           griff@chang.austin.ibm.com
  147. Mark Laubach             laubach@hpl.hp.com
  148. Drew Perkins             ddp@andrew.cmu.edu
  149. Yakov Rekhter            yakov@watson.ibm.com
  150. Lansing Sloan            ljsloan@llnl.gov
  151. Elizabeth Vanderbeck     beth@tdcsys2.vnet.ibm.com
  152. Gerry White              gerry@lancity.com
  153.  
  154.  
  155.  
  156.                                    3
  157.