CURRENT_MEETING_REPORT_ Reported by Mark Laubach/Com21 Minutes of the IP Over Asynchronous Transfer Mode Working Group (IPATM) Documents of the IPATM Working Group are available from ftp://ftp.com21.com/ftp/pub/ip-atm. The group also has a WWW server, http://www.com21.com/pages/ietf.html. ATM Forum Liaison Report - Drew Perkins Drew Perkins gave a report on the ATM Forum. He will also send an e-mail report to the mailing list for the Kyoto meeting (held during the last week of November). The following documents are complete: o LANE - all minor and major questions have been answered. o IISP o CMIP, SNMP MIBs (m4) o Test specifications LANE emulation has been made UNI mapping independent (UNI 3.0 and 3.1 are supported). Intelligent bus support has been added. A ready indicate packet has been added (on data connections) and its use is now mandatory PNNI has started new work items for soft Permanent Virtual Paths (PVPs). The Multiprotocol over ATM group identified some requirements and different reference models for how the system should work centered around defining single end system host behavior (query/response). The Signaling working group has continued progress on ``leaf initiated join.'' The group will start authenticated connection work at the next meeting, and it was reported that ATM DXI for channelized DS3 has been sent to straw ballot. The issue of emulation of D1 circuits has been sent to straw ballot. The support of early packet drop (cell drop, frame drop) is beginning to get specified. The PHY (physical) group is now allowed to specify more than one interface. A new Residential Broadband (RBB) group is starting up as a Birds of a Feather (BOF) effort. The group is calling for contributions. There was some discussion on multiprotocol BOF models: LANE model, combined with Classical and NHRP model. RFC 1577 Implementors Round-up There are now about ten implementations in progress and Digital may have passed the first interoperability test with two other vendors (who prefer to remain anonymous). Interpersonal Multimedia Communications over ATM Dario Ercole gave this presentation. It was also shown at Interop '94. Their ATM network connected Paris with Torino using 155 Mbps and 34 Mbps links. Sun workstations with FORE SBA200 ATM adapters were used for the presentation. They discovered that they could not run IP over ATM over a public network if they did not perform rate control. This means application level rate control and inter-switch rate control. The NNI between the switches generated ``big packets.'' There was a question regarding the use of RFC 1577 over the wide-area. Who is going to provide/specify the recommendations for the policing function? Andy Malis stated that very much is dependent on the type of network the traffic is being sent through. Dario agrees. Ken Hayward asked if ATM is deregulated in Europe. He also asked about multiple vendors and solutions. Dario responded that this topic is not network specific. Consensus is that this is more of an ATM specific issue and that IP over ATM will make use of available services. While not an issue of this working group's charter, performance of ATM does impact performance of IP over ATM. IP Multicast Draft Review Grenville Armitage gave an overview of his two Internet-Drafts. The goals of the documents are to work within RFC 1577 context and utilize UNI 3.1 multicast services. UNI 4.0 and IP multicast routing are not goals. Mark recommend that there be a separate registration server, i.e., de-couple ATMARP_REQUEST from the multicast-request. There was a comment to please not have the user type in two 20-byte addresses. Maybe there is a clever way to do this? A question was raised about whether the two servers can live at the same LLC entity? Mark raised the point of if the ARP type coding is distinct, it is possible that it and an ATMARP server could live above 0x0806, however, old implementations must be tolerant of receiving these types without doing nasty things. RFC 1577 rewrite could specify that hosts must be tolerant of receiving other type codes. Grenville was asked if he perceived any bounds on the size of the mcleave and join messages. He said that ARP_MULTI response is quite large and currently exceeds the bounds on host adapters. What happens when the ARP server fails? What happens to the VCs that are active on the host? These issues are currently not addressed. Drew suggested resyncing after a period of time. He thinks the document needs to be augmented such that failure ought to reset all state. Grenville agreed that some text is needed for this. Drew suggested that perhaps the document's discussion of binding to LLC entities can be skipped, as it might cause more controversy and/or confusion. He feels that it is not necessary for this to be in the document. The end system architecture needs to be drawn out from the actual implementation. It useful to understand how the protocol works. Consensus was to move it into the framework document. There was a discussion of the Multicast Server. A suggestion was to name the service Multicast Address Registration Server (MARS). Drew raised the question of the use of an ARP_REPLY instead of an ARP_MULTI with a single member. There was discussion of various issues surrounding setting up a multicast VC. These issues will be addressed in subsequent rewrites of the draft. Framework Document Discussion Discussion of the framework document was led by David Shur. Curtis suggested issuing the document in HTML which converts easily to both PostScript and text. This would allow easy review and posting as an Internet-Draft. He is willing to do the conversion if he can get the document text in ASCII. It is up to the authors at this point to give it to him. General consensus that we need to close on this real soon, via a series of interactive discussions on the e-mail list. There was also consensus that Grenville's LLC material from the multicast document be moved to the framework document. Work Plan Presentation Mark presented the suggested FY95 work plan, as follows: o UNI 3.0 Signaling draft --> Informational RFC (submitted) o UNI 3.1 Signaling draft --> Proposed (re-submitted 12/4) o Framework draft --> Informational RFC o Multicast draft(s) --> Proposed (?) o RFC 1483 Proposed --> Draft o RFC 1577 Proposed --> Proposed (?) o RFC 1626 Proposed --> Draft o UNI 4.0 Signaling draft It was noted that ITU has a contribution for the RFC 1483 rewrite. Questions were raised regarding when to start the RFC 1577 rewrite. Mark proposed starting this in the March/April time frame. Drew suggested getting started sooner. A statement was made that RFC 1626 should be rolled into the RFC 1577 rewrite. We were not able to discuss this and clarify why they are different.