CURRENT_MEETING_REPORT_

Reported by Mark Laubach/Com21

Minutes of the IP Over Asynchronous Transfer Mode Working Group (IPATM)

The IPATM Working Group met twice at the 32nd IETF. The first session on
Monday, 3 April, was a joint meeting with the ROLC Working Group, while
the second session on Wednesday, 5 April, was a meeting of IPATM only.
The minutes from the joint session can be found in the ROLC section of
these Proceedings.

Documents of the IPATM Working Group are available on the Web:

     http://www.com21.com/pages/ietf.html


The ITU is also now available on the Web:

     http://www.itu.ch/


IPMC Overview

Grenville Armitage presented an overview of his IPMC Internet-Draft.
During his presentation of the Multiast Address Resolution Service
(MARS), the topic of supporting or interacting with a multicast server
was addressed.  This subject generated much discussion.  The general
consensus at the end of this discussion was that the working group
needed to have a plan for the overall IP multicast service system model
before it could understand how the pieces, like MARS, would fit in to
the systems model.

To that end, Grenville will continue work on the IPMC draft and the
working group has added a new Multicast System Specification item to the
work plan.  Ann Demirtjis volunteered to work on this effort, and Walter
Milliken is going to assist.

The issues that the specification must address are:

   o ``Service'' definition
   o Noticing reflected packets to sending client from multicast server
   o Noticing reflected packets to sending router from multicast server
   o Other layer two (datalink) requirements
   o Changes (if any) that are required to mrouter(s)
   o IDMR Working Group Coordination needed?
   o IGMP and IGMPv2 Restrict/Promiscuous needed?
   o Any other host issues
   o Multiserver synchronization
   o Non-LIS interoperation issues
   o Any leverage from other ATMF work (e.g., LAN Emulation,
     Multi-Protocol Ad Hoc group, etc.)
   o Specifying IP Broadcast mapping


Update to RFC 1577:  ``RFC 1577+''

In addition to the changes approved in the joint IPATM/ROLC meeting (see
the joint meeting minutes), Mark Laubach presented additional issues
that needed to be addressed in the update of RFC 1577.  The original
slides of this presentation are available in these proceedings.  The
text of the meeting is reflected below.  Each item concludes with an
``Action:''  section listing the consensus of the working group on that
item.


  1. Client Registration Problem

       o Introduction:
         -  ATMARP server registers clients via InATMARP_REQUEST.
       o Problem:
         -  Race condition with connection setup in client.
         -  IP subnet membership issues for server.
       o Proposed Solution:
         -  Do away with server's first use of InATMARP.
         -  Server becomes promiscuous and builds its table based on
            looking at source information in ATMARP_Requests.
         -  Clients must first register and update by ARPing for
            themselves.  RFC 1577+ Rewrite.
       o Action:
         -  Approved as stated.


  2. ATMARP Variable vs.  Fixed

       o Introduction:
         -  RFC 1577 specifies a variable length packet format.
       o Problem:
         -  Not every implementer read/understood this.
       o Proposed solution:
         -  Just strengthen the text which says that it is a variable
            length packet format.
         -  ``null'' means for xmit:  zero length indicated no storage
            allocated, no field present - just like DNS.
         -  Added note:  when ATM addr len=0, the type field is ``don't
            care.''  RFC 1577+ Rewrite.
       o Action:
         -  Approved as stated.  Null means zero length, no allocation.
            There will be consistency between InATMARP and ATMARP, and
            IPv4 with ATM addresses.  IPv4 receipt of Len=4 with 0.0.0.0
            value is ok, but Len=0, no storage for transmit.

  3. ARP_NAK Format

       o Issue:
         -  RFC 1577 is not completely clear on how to specify the
            ARP_NAK packet.  Mark had thought that the best way was to
            just copy the packet to the output and just change the op
            code from a request to a nak, others prefer generating a new
            packet.
       o Solution?
         -  What do we really want?
       o Action:
         -  Reflect (bcopy) what was received, and just change the
            opcode to a NAK.


  4. InATMARP

       o Problem:
         -  Lack of specification of how null target protocol address is
            specified.
       o Solution?
         -  RFC 1293 null?  ; i.e., 4 bytes with 0.0.0.0?, or
         -  RFC 1577 null?  ; length = 0, no storage/field.
       o Action:
         -  To be consistent with ATMARP packet format, both form are
            accepted for reception.  The RFC 1577 Len=0, no storage, is
            required for transmit.


  5. What Else?

       o Issue:
         -  Authenticated ARPs?
       o Solution?
       o Action:
         -  List as an open issue.
         -  Add information text in Appendix if appropriate.
         -  Consider adding Type, Len, and Key fields to ATMARP packet.
         -  Check with other authentication folks before proceeding.



IP Broadcast

A question about IP broadcast support was raised on the mailing list
prior to the meeting.  The item was placed on the agenda for discussion
and possible conclusion.

After some discussion, the working group decided to treat IP broadcast
as a special case of IP multicast services; e.g., provide a mapping from
IP broadcast to a ``well-known'' IP multicast group address and let the
future IPMC (et al.)  services support it in that manner.  The Multicast
Systems Overview effort will need to detail any issues with this type of
mechanism.


1995 Work Plan

The 1995 work plan was discussed and presented.  Mark Laubach will work
on getting dates assigned to the items and working with our new Area
Directors to refresh the out-of-date work plan in the IPATM Charter.


   o Framework draft --> Informational RFC
   o Multicast draft (IPMC) --> Proposed Standard
   o RFC 1483 Proposed Standard --> Draft Standard
   o RFC 1577 + RFC 1626 Proposed Standard --> RFC 1577+ Proposed
     Standard
   o UNI 3.1 Signaling --> Updated to UNI 4.0
   o Multicast Systems Overview draft