CURRENT_MEETING_REPORT_ Reported by Andy Malis/Ascom Nexion and Mark Laubach/Com21 Minutes of the IP Over Asynchronous Transfer Mode Working Group (IPATM) The IPATM Working Group met once at the 33rd IETF on Thursday, 20 July with 101 people in attendance. The session was multicast but there were no comments or questions from the multicast audience. Documents of the IPATM Working Group are available on the Web: http://www.com21.com/pages/ietf.html ATM Forum Update Joel Halpern gave a very short summary of the current ATM Forum MPOA work. MPOA will be relying heavily on the Next Hop Routing Protocol (NHRP) work in the Routing Over Large Clouds Working Group (ROLC). The IPMC, Multicast Encapsulation and Broadcast Drafts ``Support for Multicast over UNI 3.1 based ATM Networks'' draft-ietf-ipatm-ipmc-05.txt ``Issues surrounding a new encapsulation for IP over ATM'' draft-armitage-ipatm-encaps-02.txt ``IP Broadcast over ATM Networks'' draft-smith-ipatm-bcast-01.txt Grenville Armitage led the discussion of these three documents. A copy of his slides follow these minutes. He has a Web repository for multicast drafts and related material: http://gump.bellcore.com:8000/~gja/i-drafts.html Version -06 of the IPMC draft will be coming out very soon (in a week or two). Mark Laubach summarized outstanding issue decisions that effect the next turn of the IPMC draft: o Do Class II only, to avoid interoperability issues. This did not get any dissent. o The cluster scope is the same as the LIS, at least for now. Walter agrees, and wants this emphasized. Joel Halpern also agrees. Rob Coltun, on the other hand, wants to expand the scope, and allow cutthrough. The current consensus is that this is premature, but may be investigated in the future. Mark raised the point that making the two scopes the same now is a good starting point. Everyone seemed to agree on this. o Choose encapsulation option #6? No dissent. Walter Milliken (BBN) made the argument that the Broadcast draft is much more complicated than it need be. His comments will be considered for the next draft. The Framework Document ``IP over ATM: A Framework Document'' draft-ietf-ipatm-framework-doc-03.ps, .txt David Shur (AT&T) gave an update on the Framework document. Version -03 came out several weeks ago, and has received a few comments. They would like to freeze the document as it is, and move forward to turning it into an Informational RFC. They solicited any additional comments to come soon, so that they can go to the RFC as soon as possible. Joel argued in favor of keeping it an Internet-Draft, so that it can be updated continuously. Mark pointed out that it cannot be referenced as an Internet-Draft, so it will be made into an RFC to allow it to be a ``real'' document which can be referenced. Joel agreed with that reasoning. Future mods can be done as new RFCs. The IP Multicasting over ATM Draft ``IP Multicasting over ATM: System Architecture Issues'' draft-ietf-ipatm-arch-00.txt Ann Demirtjis, Sprint, presented draft-ietf-ipatm-arch-00.txt and will edit the next version of the draft. In her slides (which follow these minutes), italics represent points where she has added material from Walter's draft, or disagrees with it. There was a discussion during her presentation of whether IP over ATM should use IGMP for multicast: o Walter: one additional comment is IGMPv3. It is a new thing and requires more stuff to happen. It would require a MARS rewrite to handle the new functionality. o Ann: I think that this is a non-issue for IP over ATM multicast. MARS should be able to get join information and pass it back to the router. o Grenville: Let me clarify a few points. The model ought to be viewed as the MARS being the link level driver underneath IGMP---neither requiring it or supporting it directly. There is a distinction that the MARS lies under IGMP. It would be fair to say that people could implement an IP over ATM driver that could support IGMP via an ioctl() that queries the MARS. o Ann: what should be in this document is that all the protocols at the IP layer must be supported. o Walter: I would prefer the ``hack'' taken out so that we do not have future interoperability problems. I believe the IGMP support is mandatory and should be stated in the document. o Grenville: we can restate things so that any implementation must support IGMP. o Joel: clearly the document will not give anyone the right to not implement IGMP. However, at the same time, the document should talk about ways of improving the system so that things will work better. o Rob: DVMRP uses IGMP. o Ann: yes, IGMP must be supported. Applications should be able to use ATM QoS directly without. o Eric: you must pay attention to QoS when leaving the ATM cloud if you want to have QoS carried. o Unknown: It is appropriate to say that RSVP must be supported. It is not appropriate to say that RVSP exclusively. In Walter's draft, QoS can only be provided via RSVP. Ann feels that you don't need to use RSVP if the host is directly on ATM---it can set up the VC on its own that fulfills its needs. The point was made that this works only as long as all the multicast receivers are on the same ATM network. The group discussed how LIJ can be used---the MARS could give the required GCID to the host for the LIJ. There was a discussion of when meshes make sense vs. multicast servers, and when RSVP should or should not be used. The document is going to be restructured based on comments, and Ann will be producing a new version (date unknown). Mark reviewed the multicast overview issues from the Danvers IETF that the group asked Ann and Walter to address. Please see Mark's slides which follow these minutes. The Integrated Services Draft ``Integrated Services IP Multicasting over ATM'' draft-milliken-ipatm-services-00.txt Walter Milliken presented some slides on his integrated services draft. A copy of his slides follow these minutes. Walter put up some diagrams, including one that illustrated using NRHP to produce shortcut multicast path setup. However, he realizes that there's a lot of work left to do to make this work. Shortcut also introduces problems with using TTL to end routing loops or control geographic distribution. Conclusion Mark ended the meeting with a brief summary of the status of the RFC 1577 update and of items remaining on the group's work plan. Please see his slides which follow these minutes.