home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipatm / atm-minutes-93nov.txt < prev    next >
Text File  |  1994-02-16  |  12KB  |  283 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Mark Laubach/Hewlett-Packard
  5.  
  6. Minutes of the IP Over Asynchronous Transfer Mode Working Group (ATM)
  7.  
  8.  
  9.  
  10. The Classical Internet-Draft
  11.  
  12. The ``Classical IP and ARP over ATM'' (henceforth called ``Classical'')
  13. Internet-Draft Last Call closed on Monday, November 1.  All issues
  14. raised during the Last Call process were dealt with and closed.  One
  15. serious technical issue was raised by Dave Sincoskie regarding the ARP
  16. table entry timeout and n*n InARP transmission characteristics.  A
  17. paragraph change was presented and adopted by consensus at the Thursday
  18. meeting.  The change is as follows:
  19.  
  20. Under section 8.5 ``ATMARP Table Aging,'' replace paragraph:
  21.  
  22.  
  23.  
  24.      Prior to aging (removing) an ATMARP table entry, all members
  25.      MUST generate an InARP_REQUEST on any open virtual circuit (VC)
  26.      associated with that entry.  If an InARP_REPLY is received,
  27.      that table entry is updated and not deleted.  If there is no
  28.      open VC associated with the table entry, the entry is deleted.
  29.  
  30.  
  31.  
  32. With the following two paragraphs:
  33.  
  34.  
  35.  
  36.      Prior to aging an ATMARP table entry, an ATMARP server MUST
  37.      generate an InARP_REQUEST on any open VC associated with that
  38.      entry.  If an InARP_REPLY is received, that table entry is
  39.      updated and not deleted.  If there is no open VC associated
  40.      with the table entry, the entry is deleted.
  41.      When an ATMARP table entry ages, an ATMARP client MUST
  42.      invalidate the table entry.  If there is no open VC associated
  43.      with the invalidated entry, that entry is deleted.  In the case
  44.      of an invalidated entry and an open VC, the ATMARP client must
  45.      revalidate the entry prior to transmitting any non address
  46.      resolution traffic on that VC. In the case of a PVC, the client
  47.      validates the entry by transmitting an InARP_REQUEST and
  48.      updating the entry on receipt of an InARP_REPLY. In the case of
  49.      an SVC, the client validates the entry by transmitting an
  50.      ARP_REQUEST to the ATMARP Server and updating the entry on
  51.      receipt of an ARP_REPLY. If a VC with an associated invalidated
  52.      ATMARP table entry is closed, that table entry is removed.
  53.  
  54.  
  55. Dave Piscitello approved the change process; another Last Call is not
  56. needed.  The Classical Internet-Draft is awaiting IESG ballot.
  57.  
  58.  
  59.  
  60. Routing over Large Clouds Working Group Introduction
  61.  
  62. Joel Halpern gave a presentation of the proposed charter of the Routing
  63. Over Large Clouds Working Group (ROLC). Juha's NBMA ARP has been moved
  64. into that working group.  Issues involved with ARPing beyond the LIS and
  65. shortcut routing, et al.  for IP over ATM are now in ROLC.
  66.  
  67.  
  68.  
  69. The MTU Internet-Draft
  70.  
  71. Ran Atkinson presented his Internet-Draft, ``Default IP MTU for use over
  72. ATM AAL5'' (henceforth called ``MTU''). There was much discussion over
  73. the use of SDU negotiation.  Dan Grossman suggested that advantage
  74. should be taken of whatever signaling support is available and make it
  75. mandatory for SVC negotiations.  The working group needs to specify the
  76. parameters of UNI 3.0 so that interoperable implementations exist.  The
  77. issue was raised that a very clearly defined default case exists
  78. (classical model) and it is necessary to have a clear plan of how
  79. signaling is used, for what, and what the defaults are.
  80.  
  81. A discussion of the MTU path discovery requirement took place.  The
  82. question of whether system requirements (IP systems) can be driven by
  83. requiring it in IP over ATM was raised.  Ran feels that an on/off switch
  84. is a implementation optimization; i.e., up to the implementor.  Others
  85. feel that it is not the ATM Working Group's place to require it.  The
  86. group reached the following recommendation:  use the default MTU size of
  87. 9180.  IP stations must implement MTU path discovery but are not
  88. required to use it.  If they do use it, the MTU size may be adjusted,
  89. etc.
  90.  
  91. Ran will be updating the document soon.  The MTU path discovery issue is
  92. still being debated.
  93.  
  94.  
  95.  
  96. Framework Document
  97.  
  98. Bob Cole led a discussion of the framework document.  Joel Halpern led a
  99. short presentation on TUNIC and TULIP. Discussion was plentiful on all
  100. issues.  Bob will be seeking volunteers for help with a new version.
  101. The working group chair hopes that this document can be turned into a
  102. planning guide for the working group.  Discussions will continue on the
  103. mailing list.
  104.  
  105.  
  106.  
  107. Security and Reliability
  108.  
  109. Bryan Lyles presented a brief introduction of security issues with
  110. regards to IP over ATM, in that a firewall-level mechanism is needed
  111. that allows certain streams to go through a firewall.  Also, as trends
  112. will want to multiplex a VC higher in the protocol stack (e.g., TCP
  113. ports, or higher) reliability of the VC must be understood.  A reliable
  114. peer protocol cannot be replaced with an unreliable VC. These issues
  115. were presented to the working group as a consideration of areas that
  116. might be worked on in the future.
  117.  
  118.  
  119.  
  120. Wrap Up
  121.  
  122. The group hosted other discussions on source address, the non-optimal
  123. behavior of InARP, selectors and multiple LIS's, application binding,
  124. and Q.93B parameters.
  125.  
  126. There was not enough time to complete discussion on the issue of IP over
  127. the ATM Forum's LAN Emulation specification.
  128.  
  129. Action items for the group are:
  130.  
  131.  
  132.    o Ran and Bob each incorporate comments from the meeting into their
  133.      respective documents.
  134.  
  135.    o Dan Grossman, Mike Goguen, and George Swallow are forming a small
  136.      design team to generate an Informational document on how to use the
  137.      UNI 3.0 for IP over ATM. Sufficient information will be presented
  138.      to enable consistent implementations but not to duplicate ATM Forum
  139.      specifications.
  140.  
  141.    o Bryan Lyles and Drew Perkins will collaborate on a draft statement
  142.      for the framework document on possible methods of supporting IP
  143.      multicast.
  144.  
  145.    o Andy Malis will follow through on the multiple VC thrashing issue
  146.      and will generate consensus.
  147.  
  148.  
  149. Attendees
  150.  
  151. Masuma Ahmed             mxa@mail.bellcore.com
  152. Nick Alfano              alfano@mpr.ca
  153. Anthony Alles            aalles@cisco.com
  154. Randall Atkinson         atkinson@itd.nrl.navy.mil
  155. Nutan Behki              nebhki@newbridge.com
  156. Ram Bhide
  157. Richard Binder           rbinder@cnri.reston.va.us
  158. Jon Boone                boone@psc.edu
  159. Erik-Jan Bos             erik-jan.bos@surfnet.nl
  160. Al Broscius              broscius@bellcore.com
  161. Caralyn Brown            cbrown@wellfleet.com
  162. Theodore Brunner         tob@thumper.bellcore.com
  163. Steve Buchko             stevebu@newbridge.com
  164. Glen Cairns              cairns@mprgate.mpr.ca
  165. Enke Chen                enke@merit.edu
  166. Ping Chen                ping@ping2.aux.apple.com
  167. George Clapp             clapp@ameris.ameritech.com
  168. Robert Cole              rgc@qsun.att.com
  169. Rob Coltun               rcoltun@ni.umd.edu
  170. Michael Conn             4387451@mcimail.com
  171. Matt Crawford            crawdad@fncent.fnal.gov
  172. James Davin              davin@thumper.bellcore.com
  173. Thomas Dimitri           tommyd@microsoft.com
  174. Kurt Dobbins             dobbins@ctron.com
  175. Waychi Doo               wcd@berlioz.nsc.com
  176. David Dubois             dad@pacersoft.com
  177. Pierre Dupont            dupont@mdd.comm.mot.com
  178. Dario Ercole             Dario.Ercole@cselt.stet.it
  179. Julio Escobar            jescobar@bbn.com
  180. Stefan Fassbender        stf@easi.net
  181. Steve Feldman            feldman@mfsdatanet.com
  182. William Fenner           fenner@cmf.nrl.navy.mil
  183. Robert Fenoglio          fenoglio@vnet.ibm.com
  184. Carlos Fernandez         carlos@plk.af.mil
  185. Robert Fink              rlfink@lbl.gov
  186. James Forster            forster@cisco.com
  187. Dan Frommer              dan@isv.dec.com
  188. Mark Garrett             mwg@faline.bellcore.com
  189. John Gawf                gawf@compatible.com
  190. Eugene Geer              ewg@cc.bellcore.com
  191. Robert Gilligan          Bob.Gilligan@Eng.Sun.Com
  192. Mike Goguen              goguen@synoptics.com
  193. Fengmin Gong             gong@concert.net
  194. Ramesh Govindan          rxg@thumper.bellcore.com
  195. Daniel Grossman          dan@merlin.dev.cdx.mot.com
  196. Robert Grow              bob@xlnt.com
  197. Stuart Hale              stu_hale@vnet.ibm.com
  198. Joel Halpern             jmh@network.com
  199. John Hanratty            jhanratty@agile.com
  200. W.S. Harborth            wharbort@ghost.darpa.mil
  201. Dimitry Haskin           dhaskin@wellfleet.com
  202. Marc Hasson              marc@mentat.com
  203. Ken Hayward              Ken.Hayward@bnr.ca
  204. Juha Heinanen            juha.heinanen@datanet.tele.fi
  205. Kathryn Hill             khill@newbridge.com
  206. Eric Hoffman             hoffman@cmf.nrl.navy.mil
  207. Mike Holloway            mikeh@newbridge.com
  208. Refael Horev             horev@lannet.com
  209. Kathy Huber              khuber@wellfleet.com
  210. Melanie Humphrey         msh@uiuc.edu
  211. Ronald Jacoby            rj@sgi.com
  212. B.V. Jagadeesh           bvj@novell.com
  213. Merike Kaeo              mkaeo@cisco.com
  214. Yasuhiro Katsube         katsube@mail.bellcore.com
  215. David Kaufman            dek@magna.telco.com
  216. Byonghak Kim             bhkim@cosmos.kaist.ac.kr
  217. Charles Kunzinger        kunzinger@vnet.ibm.com
  218. Ted Kuo                  tik@ececho.ncsu.edu
  219. Sundar Kuttalingam       sundark@wiltel.com
  220. Olav Kvittem             Olav.Kvittem@uninett.no
  221. Mark Laubach             laubach@hpl.hp.com
  222. Joseph Liu               jliu@atg.wiltel.com
  223. Kim Long                 klong@sura.net
  224. Thang Lu                 tlu@mcimail.com
  225. Bryan Lyles              lyles@parc.xerox.com
  226. Andrew Malis             malis@maelstrom.timeplex.com
  227. Tracy Mallory            tracym@3com.com
  228. Allison Mankin           mankin@cmf.nrl.navy.mil
  229. Matt Mathis              mathis@psc.edu
  230. Jun Matsukata            jm@eng.isas.ac.jp
  231. Keith McCloghrie         kzm@hls.com
  232. Donald Merritt           don@arl.army.mil
  233. Orly Nicklass            orly@radmail.rad.co.il
  234. Dan Nordell
  235. Karen O'Donoghue         kodonog@relay.nswc.navy.mil
  236. Zbigniew Opalka          zopalka@agile.com
  237. Steve Parker             sparker@ossi.com
  238. Craig Partridge          craig@bbn.com
  239. Laura Pate               pate@gateway.mitre.org
  240. Maryann Perez            perez@cmf.nrl.navy.mil
  241. Charles Perkins          perk@watson.ibm.com
  242. Drew Perkins             ddp@fore.com
  243. Radia Perlman            perlman@novell.com
  244. David Piscitello         wk04464@worldlink.com
  245. Robert Roden             roden@roden.enet.dec.com
  246. Benny Rodrig             brodrig@rnd-gate.rad.co.il
  247. Doris Roland             droland@ghost.darpa.mil
  248. Allan Rubens             acr@merit.edu
  249. Timothy Salo             tjs@msc.edu
  250. Hal Sandick              sandick@vnet.ibm.com
  251. Jean-Bernard Schmitt     jbs@vnet.ibm.com
  252. Martin Schulman          schulman@smtp.sprint.com
  253. Isil Sebuktekin          isil@nevin.bellcore.com
  254. Michael See              mikesee@vnet.ibm.com
  255. Kanan Shah               kshah@cmf.nrl.navy.mil
  256. Satya Sharma             ssharma@chang.austin.ibm.com
  257. Vincent Shekher          vin@sps.mot.com
  258. Ming Sheu                msheu@vnet.ibm.com
  259. Uttam Shikarpur          uttam@zk3.dec.com
  260. Chi Shue                 chi@casc.com
  261. W. David Sincoskie       sincos@bellcore.com
  262. Andrew Smith             asmith@synoptics.com
  263. Tae Song                 tae@novell.com
  264. Steve Suzuki             steve@fet.com
  265. George Swallow           gswallow@bbn.com
  266. Matsuaki Terada          tera@sdl.hitachi.co.jp
  267. Susan Thomson            set@bellcore.com
  268. Hoe Trinh                htrinh@vnet.ibm.com
  269. Keisuke Uehara           kei@cs.uec.ac.jp
  270. Dono van-Mierop          dono_van_mierop@3mail.3com.com
  271. Thomas Walsh             tomw@kalpana.com
  272. Chuck Warlick            chuck.warlick@pscni.nasa.gov
  273. Guy Wells                guyw@uswest.com
  274. Douglas Williams         dougw@vnet.ibm.com
  275. Honda Wu                 honda@nat.com
  276. Liang Wu                 ltwu@bellcore.com
  277. Shinichi Yoshida         yoshida@sumitomo.com
  278. Jessica Yu               jyy@merit.edu
  279. Chin Yuan                cxyuan@pacbell.com
  280. Mauro Zallocco           mdz@netlink.com
  281. Weiping Zhao             zhao@nacsis.ac.jp
  282.  
  283.