home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipatm / ipatm-minutes-95apr.txt < prev    next >
Text File  |  1995-05-26  |  6KB  |  175 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Mark Laubach/Com21
  5.  
  6. Minutes of the IP Over Asynchronous Transfer Mode Working Group (IPATM)
  7.  
  8. The IPATM Working Group met twice at the 32nd IETF. The first session on
  9. Monday, 3 April, was a joint meeting with the ROLC Working Group, while
  10. the second session on Wednesday, 5 April, was a meeting of IPATM only.
  11. The minutes from the joint session can be found in the ROLC section of
  12. these Proceedings.
  13.  
  14. Documents of the IPATM Working Group are available on the Web:
  15.  
  16.      http://www.com21.com/pages/ietf.html
  17.  
  18.  
  19. The ITU is also now available on the Web:
  20.  
  21.      http://www.itu.ch/
  22.  
  23.  
  24. IPMC Overview
  25.  
  26. Grenville Armitage presented an overview of his IPMC Internet-Draft.
  27. During his presentation of the Multiast Address Resolution Service
  28. (MARS), the topic of supporting or interacting with a multicast server
  29. was addressed.  This subject generated much discussion.  The general
  30. consensus at the end of this discussion was that the working group
  31. needed to have a plan for the overall IP multicast service system model
  32. before it could understand how the pieces, like MARS, would fit in to
  33. the systems model.
  34.  
  35. To that end, Grenville will continue work on the IPMC draft and the
  36. working group has added a new Multicast System Specification item to the
  37. work plan.  Ann Demirtjis volunteered to work on this effort, and Walter
  38. Milliken is going to assist.
  39.  
  40. The issues that the specification must address are:
  41.  
  42.    o ``Service'' definition
  43.    o Noticing reflected packets to sending client from multicast server
  44.    o Noticing reflected packets to sending router from multicast server
  45.    o Other layer two (datalink) requirements
  46.    o Changes (if any) that are required to mrouter(s)
  47.    o IDMR Working Group Coordination needed?
  48.    o IGMP and IGMPv2 Restrict/Promiscuous needed?
  49.    o Any other host issues
  50.    o Multiserver synchronization
  51.    o Non-LIS interoperation issues
  52.    o Any leverage from other ATMF work (e.g., LAN Emulation,
  53.      Multi-Protocol Ad Hoc group, etc.)
  54.    o Specifying IP Broadcast mapping
  55.  
  56.  
  57. Update to RFC 1577:  ``RFC 1577+''
  58.  
  59. In addition to the changes approved in the joint IPATM/ROLC meeting (see
  60. the joint meeting minutes), Mark Laubach presented additional issues
  61. that needed to be addressed in the update of RFC 1577.  The original
  62. slides of this presentation are available in these proceedings.  The
  63. text of the meeting is reflected below.  Each item concludes with an
  64. ``Action:''  section listing the consensus of the working group on that
  65. item.
  66.  
  67.  
  68.   1. Client Registration Problem
  69.  
  70.        o Introduction:
  71.          -  ATMARP server registers clients via InATMARP_REQUEST.
  72.        o Problem:
  73.          -  Race condition with connection setup in client.
  74.          -  IP subnet membership issues for server.
  75.        o Proposed Solution:
  76.          -  Do away with server's first use of InATMARP.
  77.          -  Server becomes promiscuous and builds its table based on
  78.             looking at source information in ATMARP_Requests.
  79.          -  Clients must first register and update by ARPing for
  80.             themselves.  RFC 1577+ Rewrite.
  81.        o Action:
  82.          -  Approved as stated.
  83.  
  84.  
  85.   2. ATMARP Variable vs.  Fixed
  86.  
  87.        o Introduction:
  88.          -  RFC 1577 specifies a variable length packet format.
  89.        o Problem:
  90.          -  Not every implementer read/understood this.
  91.        o Proposed solution:
  92.          -  Just strengthen the text which says that it is a variable
  93.             length packet format.
  94.          -  ``null'' means for xmit:  zero length indicated no storage
  95.             allocated, no field present - just like DNS.
  96.          -  Added note:  when ATM addr len=0, the type field is ``don't
  97.             care.''  RFC 1577+ Rewrite.
  98.        o Action:
  99.          -  Approved as stated.  Null means zero length, no allocation.
  100.             There will be consistency between InATMARP and ATMARP, and
  101.             IPv4 with ATM addresses.  IPv4 receipt of Len=4 with 0.0.0.0
  102.             value is ok, but Len=0, no storage for transmit.
  103.  
  104.   3. ARP_NAK Format
  105.  
  106.        o Issue:
  107.          -  RFC 1577 is not completely clear on how to specify the
  108.             ARP_NAK packet.  Mark had thought that the best way was to
  109.             just copy the packet to the output and just change the op
  110.             code from a request to a nak, others prefer generating a new
  111.             packet.
  112.        o Solution?
  113.          -  What do we really want?
  114.        o Action:
  115.          -  Reflect (bcopy) what was received, and just change the
  116.             opcode to a NAK.
  117.  
  118.  
  119.   4. InATMARP
  120.  
  121.        o Problem:
  122.          -  Lack of specification of how null target protocol address is
  123.             specified.
  124.        o Solution?
  125.          -  RFC 1293 null?  ; i.e., 4 bytes with 0.0.0.0?, or
  126.          -  RFC 1577 null?  ; length = 0, no storage/field.
  127.        o Action:
  128.          -  To be consistent with ATMARP packet format, both form are
  129.             accepted for reception.  The RFC 1577 Len=0, no storage, is
  130.             required for transmit.
  131.  
  132.  
  133.   5. What Else?
  134.  
  135.        o Issue:
  136.          -  Authenticated ARPs?
  137.        o Solution?
  138.        o Action:
  139.          -  List as an open issue.
  140.          -  Add information text in Appendix if appropriate.
  141.          -  Consider adding Type, Len, and Key fields to ATMARP packet.
  142.          -  Check with other authentication folks before proceeding.
  143.  
  144.  
  145.  
  146. IP Broadcast
  147.  
  148. A question about IP broadcast support was raised on the mailing list
  149. prior to the meeting.  The item was placed on the agenda for discussion
  150. and possible conclusion.
  151.  
  152. After some discussion, the working group decided to treat IP broadcast
  153. as a special case of IP multicast services; e.g., provide a mapping from
  154. IP broadcast to a ``well-known'' IP multicast group address and let the
  155. future IPMC (et al.)  services support it in that manner.  The Multicast
  156. Systems Overview effort will need to detail any issues with this type of
  157. mechanism.
  158.  
  159.  
  160. 1995 Work Plan
  161.  
  162. The 1995 work plan was discussed and presented.  Mark Laubach will work
  163. on getting dates assigned to the items and working with our new Area
  164. Directors to refresh the out-of-date work plan in the IPATM Charter.
  165.  
  166.  
  167.    o Framework draft --> Informational RFC
  168.    o Multicast draft (IPMC) --> Proposed Standard
  169.    o RFC 1483 Proposed Standard --> Draft Standard
  170.    o RFC 1577 + RFC 1626 Proposed Standard --> RFC 1577+ Proposed
  171.      Standard
  172.    o UNI 3.1 Signaling --> Updated to UNI 4.0
  173.    o Multicast Systems Overview draft
  174.  
  175.