CURRENT MEETING REPORT

Minutes of the IP over ATM Working Group (ipatm)

Reported by Jeffrey Dunn, Hewlett-Packard, and Mark Laubach, Com 21, Inc.

Mark Laubach opened the session. This is Mark's last meeting as chair of the working group. Andy Malis has been appointed the new chair. Mark and Andy co-chaired the working group sessions for this meeting.

The ipatm email distribution list has moved to ip-atm@nexen.com. The management address has moved to ip-atm-request@nexen.com.

George Swallow gave a brief report on the ATM Forum LAN Emulation (LANE) and MultiProtocol over ATM (MPOA) activities. He reported that the ATM Forum met two times since the Dallas IETF meeting. The MPOA Working Group is looking at NHRP for layer 3, LANE for layer 2, and MARS for layer 3 multicast. This group sent a liaison to ATM Forum to ask for general configuration server. This will be investigated; LANE has its own system.

Andy Malis gave a rolc update from the sessions the day before. Server synchronization problems were addressed. It was decided that the methods must be the same for NHRP, MARS, and Classic ATMARP work. The classic2 authors agreed that the synchronized server specification will be removed from the current classic2 update draft and server mechanisms will be submitted as a separate draft.

Grenville Armitage gave an update on the IPMC draft status. The draft is currently under review by the IESG. Not much has changed since Dallas, however some implementation testing revealed a minor bug. The changes to fix the bug were small and the work was released as version-12 of the document. Expect IETF last call for this document shortly.

The authors of the Framework draft were not present. Mark Laubach reported that the draft has been updated as per some discussions on the mailing list. The new draft will be considered for promotion to informational status.

Mark Laubach and Joel Halpern presented an update on the status of the RFC1577 update, draft-ietf-ipatm-classic2-01.txt. Due to Mark's other time commitments, he added Joel Halpern as a second author on the draft. The presentation was divided into two parts, one the "bug fixes" to RFC1577, and the second the server synchronization status. Mark Laubach presented the bug fixes to RFC1577.

A question was raised regarding availability of ATMARP servers to all clients in the LIS in view of the transition to NHRP. The answer was that if there are RFC1577 ATMARP only clients in the LIS, then these clients will continue to use RFC1577 ATMARP [NHRP servers will also answer ATMARP queries for local destinations]. Joel Halpern mentioned that that ATMARP/NHRP transition plan will be in the applicability document or the framework document. This will be decided later.

A question was raised about existence of a mechanism to differentiate between classic1 and classic2 clients with respect to a timeout on the InATMARP requests. Mark Laubach answered that the lack of an InATMARP from the server will not effect operation of old clients with new servers or new clients with old servers. A discussion concluded that the old InATMARP_Request registration method was unreliable and the first request was dropped more often than not.

A question was raised on whether you could have a race condition were nobody talks. Joel Halpern replied that the client will always send an ARP. A compromise method of the server sending an InATMARP after a timeout is under consideration.

Joel Halpern presented an update on the classic2 server synchronization mechanism. The goals for the synchronization system were presented.

OSPF experience will be leveraged in the synchronized server approach. The statistical nature of the epidemic algorithms are very useful for the future, however for the moment, the default configuration will be to do reliable flooding.

An issue was raised on the email list that there is a potential race condition if a client moves to a different port and server to server update trashing occurs due to the two circulating rumors. The solution is to fix this for NHRP, since fixing this would require a change in the ATMARP client-server packet format. Also, obsolete information will be discarded completely within 20 minutes.

The synchronized server mechanism will be removed from the classic2 update and detailed in a separate draft. The remaining material in the classic2 update will be bug fixes and documentation fixed for RFC1577 and RFC1626. The details of moving from ATMARP to NHRP will be detailed in another separate draft.

Jim Luciani presented an overview of his server cache synchronization draft. Due to many people already seeing the same presentation from the rolc session, the presentation was abbreviated. The goals of the method were overviewed for ATMARP, MARS, and NHRP. It was felt that there was not enough information on the ATM Forum LANE option at this time. Jim and Joel Halpern will be authoring a combined server synchronization draft statement. They said they will issue it approximately three weeks after the IETF meeting.

Maryann Maher presented an approach for the RFC1755 update to UNI 4.0. This draft should serve as an implementers guide for UNI signaling in IP over ATM, NHRP, MARS, etc. A number of new features are of particular interest, such as ATM traffic parameter negotiation, ABR signaling for point to point calls, leaf initiated join for multicast, ATM anycast, frame discard, and signaling of individual QOS parameters. The ATM Forum final straw vote for UNI 4.0 will be in April.

The UNI 4.0 spec will have a section detailing issues of interoperability with UNI 3.1 end systems. In terms of CBR and VBR, there are issues in transition. There are combinations of parameters which could cause rejection in UNI 4.0. Traffic parameter negotiation will be in PNNI and UNI 4.0. The BBC and B-LLI information elements in PNNI come from UNI 4.0. UNI signaling will propagate to the NNI except leaf initiated join and proxy signaling.

To start the second session, Maria Greene presented an update on the Classical IP-ATM MIB draft. It is planned for a revised draft in March with an intent to go to last call in June, 1996. An issue to be resolved is: should we have the ipAtmVirtualifType? It gives the ability to have multiple interfaces per MIB. The LIS is associated with an interface of AAL5. The AToMIB can handle the modeling of PVCs. Objects for ATM subaddr can be deferred until they are needed - they can always be added. "ipAtmLisVcType" will be removed. "ipAtmLisIsSrvr" has been used to tell a machine it is the server. Instead, we will have a local addr appear in ipAtmArpSrvrTable. Further study is need for moving the ArpServer to a new location (ATM addr). The AToMIB MTU is the initial, but the classical is the actual negotiated value. This may be in the supplemental MIB, but we have agreed not to support this as it is not finished. A MARS MIB will be written in the future.

Rajesh Talpade presented his MultiCast Server (MCS) Architecture for MARS draft. This is a more detailed description of the MCS and their interaction with the MARS. Receiver sharing implies a single MCS has a smaller number of point to multipoint connections. If receivers are shared, the load is less. A leaf from a receiver tree can be dropped at only one point rather than all MCSs. The network has to remove the receivers from the tree regardless. You can reduce the problem to backup and sender sharing. It was stated that receiver sharing reduces signaling load. There was some feeling expressed that the working group needs to get involved in the specifications of the MCS architecture, specifically with the specification for the interaction for the MARS and MCS protocols. There was general agreement that the work needed to be done but not on the shape it should take, and that people should work on this between now and next meeting. MCS to MCS synchronization is an issue for further study.

Dilip Kandlur presented an overview on the Extension to the MARS model draft. Some issues were raised with regard to shared senders and MCSs, participation of direct senders with the MCS synchronization protocol, and complexity for the sender. These are for future study. Issues raised by this draft and additions to the MARS draft will be considered at a later time.

Eric Crawley presented an overview on the Multicast Routing over ATM draft. It was noted that there are still many open issues with respect to multicast routing to be resolved.

A question was raised about that status of the broadcast draft. It was generally felt that the work was valuable and that the draft should be updated to the current reference for the MARS -12 draft and that the author should contact the chair for further working group action. This can proceed before the MARS draft becomes an RFC. The RFC editor will take care of reference adjustments.