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 >
Wrap
Text File
|
1994-02-16
|
12KB
|
283 lines
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