CURRENT_MEETING_REPORT_ Reported by Mark Laubach/Hewlett-Packard Minutes of the IP Over Asynchronous Transfer Mode Working Group (ATM) The Classical Internet-Draft The ``Classical IP and ARP over ATM'' (henceforth called ``Classical'') Internet-Draft Last Call closed on Monday, November 1. All issues raised during the Last Call process were dealt with and closed. One serious technical issue was raised by Dave Sincoskie regarding the ARP table entry timeout and n*n InARP transmission characteristics. A paragraph change was presented and adopted by consensus at the Thursday meeting. The change is as follows: Under section 8.5 ``ATMARP Table Aging,'' replace paragraph: Prior to aging (removing) an ATMARP table entry, all members MUST generate an InARP_REQUEST on any open virtual circuit (VC) associated with that entry. If an InARP_REPLY is received, that table entry is updated and not deleted. If there is no open VC associated with the table entry, the entry is deleted. With the following two paragraphs: Prior to aging an ATMARP table entry, an ATMARP server MUST generate an InARP_REQUEST on any open VC associated with that entry. If an InARP_REPLY is received, that table entry is updated and not deleted. If there is no open VC associated with the table entry, the entry is deleted. When an ATMARP table entry ages, an ATMARP client MUST invalidate the table entry. If there is no open VC associated with the invalidated entry, that entry is deleted. In the case of an invalidated entry and an open VC, the ATMARP client must revalidate the entry prior to transmitting any non address resolution traffic on that VC. In the case of a PVC, the client validates the entry by transmitting an InARP_REQUEST and updating the entry on receipt of an InARP_REPLY. In the case of an SVC, the client validates the entry by transmitting an ARP_REQUEST to the ATMARP Server and updating the entry on receipt of an ARP_REPLY. If a VC with an associated invalidated ATMARP table entry is closed, that table entry is removed. Dave Piscitello approved the change process; another Last Call is not needed. The Classical Internet-Draft is awaiting IESG ballot. Routing over Large Clouds Working Group Introduction Joel Halpern gave a presentation of the proposed charter of the Routing Over Large Clouds Working Group (ROLC). Juha's NBMA ARP has been moved into that working group. Issues involved with ARPing beyond the LIS and shortcut routing, et al. for IP over ATM are now in ROLC. The MTU Internet-Draft Ran Atkinson presented his Internet-Draft, ``Default IP MTU for use over ATM AAL5'' (henceforth called ``MTU''). There was much discussion over the use of SDU negotiation. Dan Grossman suggested that advantage should be taken of whatever signaling support is available and make it mandatory for SVC negotiations. The working group needs to specify the parameters of UNI 3.0 so that interoperable implementations exist. The issue was raised that a very clearly defined default case exists (classical model) and it is necessary to have a clear plan of how signaling is used, for what, and what the defaults are. A discussion of the MTU path discovery requirement took place. The question of whether system requirements (IP systems) can be driven by requiring it in IP over ATM was raised. Ran feels that an on/off switch is a implementation optimization; i.e., up to the implementor. Others feel that it is not the ATM Working Group's place to require it. The group reached the following recommendation: use the default MTU size of 9180. IP stations must implement MTU path discovery but are not required to use it. If they do use it, the MTU size may be adjusted, etc. Ran will be updating the document soon. The MTU path discovery issue is still being debated. Framework Document Bob Cole led a discussion of the framework document. Joel Halpern led a short presentation on TUNIC and TULIP. Discussion was plentiful on all issues. Bob will be seeking volunteers for help with a new version. The working group chair hopes that this document can be turned into a planning guide for the working group. Discussions will continue on the mailing list. Security and Reliability Bryan Lyles presented a brief introduction of security issues with regards to IP over ATM, in that a firewall-level mechanism is needed that allows certain streams to go through a firewall. Also, as trends will want to multiplex a VC higher in the protocol stack (e.g., TCP ports, or higher) reliability of the VC must be understood. A reliable peer protocol cannot be replaced with an unreliable VC. These issues were presented to the working group as a consideration of areas that might be worked on in the future. Wrap Up The group hosted other discussions on source address, the non-optimal behavior of InARP, selectors and multiple LIS's, application binding, and Q.93B parameters. There was not enough time to complete discussion on the issue of IP over the ATM Forum's LAN Emulation specification. Action items for the group are: o Ran and Bob each incorporate comments from the meeting into their respective documents. o Dan Grossman, Mike Goguen, and George Swallow are forming a small design team to generate an Informational document on how to use the UNI 3.0 for IP over ATM. Sufficient information will be presented to enable consistent implementations but not to duplicate ATM Forum specifications. o Bryan Lyles and Drew Perkins will collaborate on a draft statement for the framework document on possible methods of supporting IP multicast. o Andy Malis will follow through on the multiple VC thrashing issue and will generate consensus. Attendees Masuma Ahmed mxa@mail.bellcore.com Nick Alfano alfano@mpr.ca Anthony Alles aalles@cisco.com Randall Atkinson atkinson@itd.nrl.navy.mil Nutan Behki nebhki@newbridge.com Ram Bhide Richard Binder rbinder@cnri.reston.va.us Jon Boone boone@psc.edu Erik-Jan Bos erik-jan.bos@surfnet.nl Al Broscius broscius@bellcore.com Caralyn Brown cbrown@wellfleet.com Theodore Brunner tob@thumper.bellcore.com Steve Buchko stevebu@newbridge.com Glen Cairns cairns@mprgate.mpr.ca Enke Chen enke@merit.edu Ping Chen ping@ping2.aux.apple.com George Clapp clapp@ameris.ameritech.com Robert Cole rgc@qsun.att.com Rob Coltun rcoltun@ni.umd.edu Michael Conn 4387451@mcimail.com Matt Crawford crawdad@fncent.fnal.gov James Davin davin@thumper.bellcore.com Thomas Dimitri tommyd@microsoft.com Kurt Dobbins dobbins@ctron.com Waychi Doo wcd@berlioz.nsc.com David Dubois dad@pacersoft.com Pierre Dupont dupont@mdd.comm.mot.com Dario Ercole Dario.Ercole@cselt.stet.it Julio Escobar jescobar@bbn.com Stefan Fassbender stf@easi.net Steve Feldman feldman@mfsdatanet.com William Fenner fenner@cmf.nrl.navy.mil Robert Fenoglio fenoglio@vnet.ibm.com Carlos Fernandez carlos@plk.af.mil Robert Fink rlfink@lbl.gov James Forster forster@cisco.com Dan Frommer dan@isv.dec.com Mark Garrett mwg@faline.bellcore.com John Gawf gawf@compatible.com Eugene Geer ewg@cc.bellcore.com Robert Gilligan Bob.Gilligan@Eng.Sun.Com Mike Goguen goguen@synoptics.com Fengmin Gong gong@concert.net Ramesh Govindan rxg@thumper.bellcore.com Daniel Grossman dan@merlin.dev.cdx.mot.com Robert Grow bob@xlnt.com Stuart Hale stu_hale@vnet.ibm.com Joel Halpern jmh@network.com John Hanratty jhanratty@agile.com W.S. Harborth wharbort@ghost.darpa.mil Dimitry Haskin dhaskin@wellfleet.com Marc Hasson marc@mentat.com Ken Hayward Ken.Hayward@bnr.ca Juha Heinanen juha.heinanen@datanet.tele.fi Kathryn Hill khill@newbridge.com Eric Hoffman hoffman@cmf.nrl.navy.mil Mike Holloway mikeh@newbridge.com Refael Horev horev@lannet.com Kathy Huber khuber@wellfleet.com Melanie Humphrey msh@uiuc.edu Ronald Jacoby rj@sgi.com B.V. Jagadeesh bvj@novell.com Merike Kaeo mkaeo@cisco.com Yasuhiro Katsube katsube@mail.bellcore.com David Kaufman dek@magna.telco.com Byonghak Kim bhkim@cosmos.kaist.ac.kr Charles Kunzinger kunzinger@vnet.ibm.com Ted Kuo tik@ececho.ncsu.edu Sundar Kuttalingam sundark@wiltel.com Olav Kvittem Olav.Kvittem@uninett.no Mark Laubach laubach@hpl.hp.com Joseph Liu jliu@atg.wiltel.com Kim Long klong@sura.net Thang Lu tlu@mcimail.com Bryan Lyles lyles@parc.xerox.com Andrew Malis malis@maelstrom.timeplex.com Tracy Mallory tracym@3com.com Allison Mankin mankin@cmf.nrl.navy.mil Matt Mathis mathis@psc.edu Jun Matsukata jm@eng.isas.ac.jp Keith McCloghrie kzm@hls.com Donald Merritt don@arl.army.mil Orly Nicklass orly@radmail.rad.co.il Dan Nordell Karen O'Donoghue kodonog@relay.nswc.navy.mil Zbigniew Opalka zopalka@agile.com Steve Parker sparker@ossi.com Craig Partridge craig@bbn.com Laura Pate pate@gateway.mitre.org Maryann Perez perez@cmf.nrl.navy.mil Charles Perkins perk@watson.ibm.com Drew Perkins ddp@fore.com Radia Perlman perlman@novell.com David Piscitello wk04464@worldlink.com Robert Roden roden@roden.enet.dec.com Benny Rodrig brodrig@rnd-gate.rad.co.il Doris Roland droland@ghost.darpa.mil Allan Rubens acr@merit.edu Timothy Salo tjs@msc.edu Hal Sandick sandick@vnet.ibm.com Jean-Bernard Schmitt jbs@vnet.ibm.com Martin Schulman schulman@smtp.sprint.com Isil Sebuktekin isil@nevin.bellcore.com Michael See mikesee@vnet.ibm.com Kanan Shah kshah@cmf.nrl.navy.mil Satya Sharma ssharma@chang.austin.ibm.com Vincent Shekher vin@sps.mot.com Ming Sheu msheu@vnet.ibm.com Uttam Shikarpur uttam@zk3.dec.com Chi Shue chi@casc.com W. David Sincoskie sincos@bellcore.com Andrew Smith asmith@synoptics.com Tae Song tae@novell.com Steve Suzuki steve@fet.com George Swallow gswallow@bbn.com Matsuaki Terada tera@sdl.hitachi.co.jp Susan Thomson set@bellcore.com Hoe Trinh htrinh@vnet.ibm.com Keisuke Uehara kei@cs.uec.ac.jp Dono van-Mierop dono_van_mierop@3mail.3com.com Thomas Walsh tomw@kalpana.com Chuck Warlick chuck.warlick@pscni.nasa.gov Guy Wells guyw@uswest.com Douglas Williams dougw@vnet.ibm.com Honda Wu honda@nat.com Liang Wu ltwu@bellcore.com Shinichi Yoshida yoshida@sumitomo.com Jessica Yu jyy@merit.edu Chin Yuan cxyuan@pacbell.com Mauro Zallocco mdz@netlink.com Weiping Zhao zhao@nacsis.ac.jp