home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipatm / ipatm-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  7KB  |  186 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Andy Malis/Ascom Nexion and Mark Laubach/Com21
  5.  
  6. Minutes of the IP Over Asynchronous Transfer Mode Working Group (IPATM)
  7.  
  8. The IPATM Working Group met once at the 33rd IETF on Thursday, 20 July
  9. with 101 people in attendance.  The session was multicast but there were
  10. no comments or questions from the multicast audience.
  11.  
  12. Documents of the IPATM Working Group are available on the Web:
  13.  
  14.  
  15.      http://www.com21.com/pages/ietf.html
  16.  
  17.  
  18. ATM Forum Update
  19.  
  20. Joel Halpern gave a very short summary of the current ATM Forum MPOA
  21. work.  MPOA will be relying heavily on the Next Hop Routing Protocol
  22. (NHRP) work in the Routing Over Large Clouds Working Group (ROLC).
  23.  
  24.  
  25. The IPMC, Multicast Encapsulation and Broadcast Drafts
  26.  
  27.      ``Support for Multicast over UNI 3.1 based ATM Networks''
  28.      draft-ietf-ipatm-ipmc-05.txt
  29.  
  30.      ``Issues surrounding a new encapsulation for IP over ATM''
  31.      draft-armitage-ipatm-encaps-02.txt
  32.  
  33.      ``IP Broadcast over ATM Networks''
  34.      draft-smith-ipatm-bcast-01.txt
  35.  
  36.  
  37. Grenville Armitage led the discussion of these three documents.  A copy
  38. of his slides follow these minutes.  He has a Web repository for
  39. multicast drafts and related material:
  40.  
  41.  
  42.      http://gump.bellcore.com:8000/~gja/i-drafts.html
  43.  
  44.  
  45. Version -06 of the IPMC draft will be coming out very soon (in a week or
  46. two).  Mark Laubach summarized outstanding issue decisions that effect
  47. the next turn of the IPMC draft:
  48.  
  49.  
  50.    o Do Class II only, to avoid interoperability issues.  This did not
  51.      get any dissent.
  52.  
  53.    o The cluster scope is the same as the LIS, at least for now.  Walter
  54.      agrees, and wants this emphasized.  Joel Halpern also agrees.  Rob
  55.      Coltun, on the other hand, wants to expand the scope, and allow
  56.      cutthrough.  The current consensus is that this is premature, but
  57.      may be investigated in the future.  Mark raised the point that
  58.      making the two scopes the same now is a good starting point.
  59.      Everyone seemed to agree on this.
  60.  
  61.    o Choose encapsulation option #6?  No dissent.
  62.  
  63.  
  64. Walter Milliken (BBN) made the argument that the Broadcast draft is much
  65. more complicated than it need be.  His comments will be considered for
  66. the next draft.
  67.  
  68.  
  69. The Framework Document
  70.  
  71.      ``IP over ATM: A Framework Document''
  72.      draft-ietf-ipatm-framework-doc-03.ps, .txt
  73.  
  74.  
  75. David Shur (AT&T) gave an update on the Framework document.  Version -03
  76. came out several weeks ago, and has received a few comments.  They would
  77. like to freeze the document as it is, and move forward to turning it
  78. into an Informational RFC. They solicited any additional comments to
  79. come soon, so that they can go to the RFC as soon as possible.
  80.  
  81. Joel argued in favor of keeping it an Internet-Draft, so that it can be
  82. updated continuously.  Mark pointed out that it cannot be referenced as
  83. an Internet-Draft, so it will be made into an RFC to allow it to be a
  84. ``real'' document which can be referenced.  Joel agreed with that
  85. reasoning.  Future mods can be done as new RFCs.
  86.  
  87.  
  88. The IP Multicasting over ATM Draft
  89.  
  90.      ``IP Multicasting over ATM: System Architecture Issues''
  91.      draft-ietf-ipatm-arch-00.txt
  92.  
  93.  
  94. Ann Demirtjis, Sprint, presented draft-ietf-ipatm-arch-00.txt and will
  95. edit the next version of the draft.  In her slides (which follow these
  96. minutes), italics represent points where she has added material from
  97. Walter's draft, or disagrees with it.
  98.  
  99. There was a discussion during her presentation of whether IP over ATM
  100. should use IGMP for multicast:
  101.  
  102.  
  103.    o Walter:  one additional comment is IGMPv3.  It is a new thing and
  104.      requires more stuff to happen.  It would require a MARS rewrite to
  105.      handle the new functionality.
  106.  
  107.    o Ann:  I think that this is a non-issue for IP over ATM multicast.
  108.      MARS should be able to get join information and pass it back to the
  109.      router.
  110.  
  111.    o Grenville:  Let me clarify a few points.  The model ought to be
  112.      viewed as the MARS being the link level driver underneath
  113.      IGMP---neither requiring it or supporting it directly.  There is a
  114.      distinction that the MARS lies under IGMP. It would be fair to say
  115.      that people could implement an IP over ATM driver that could
  116.      support IGMP via an ioctl() that queries the MARS.
  117.  
  118.    o Ann:  what should be in this document is that all the protocols at
  119.      the IP layer must be supported.
  120.  
  121.    o Walter:  I would prefer the ``hack'' taken out so that we do not
  122.      have future interoperability problems.  I believe the IGMP support
  123.      is mandatory and should be stated in the document.
  124.  
  125.    o Grenville:  we can restate things so that any implementation must
  126.      support IGMP.
  127.  
  128.    o Joel:  clearly the document will not give anyone the right to not
  129.      implement IGMP. However, at the same time, the document should talk
  130.      about ways of improving the system so that things will work better.
  131.  
  132.    o Rob:  DVMRP uses IGMP.
  133.  
  134.    o Ann:  yes, IGMP must be supported.  Applications should be able to
  135.      use ATM QoS directly without.
  136.  
  137.    o Eric:  you must pay attention to QoS when leaving the ATM cloud if
  138.      you want to have QoS carried.
  139.  
  140.    o Unknown:  It is appropriate to say that RSVP must be supported.  It
  141.      is not appropriate to say that RVSP exclusively.
  142.  
  143.  
  144. In Walter's draft, QoS can only be provided via RSVP. Ann feels that you
  145. don't need to use RSVP if the host is directly on ATM---it can set up
  146. the VC on its own that fulfills its needs.  The point was made that this
  147. works only as long as all the multicast receivers are on the same ATM
  148. network.
  149.  
  150. The group discussed how LIJ can be used---the MARS could give the
  151. required GCID to the host for the LIJ.
  152.  
  153. There was a discussion of when meshes make sense vs.  multicast servers,
  154. and when RSVP should or should not be used.
  155.  
  156. The document is going to be restructured based on comments, and Ann will
  157. be producing a new version (date unknown).
  158.  
  159. Mark reviewed the multicast overview issues from the Danvers IETF that
  160. the group asked Ann and Walter to address.  Please see Mark's slides
  161. which follow these minutes.
  162.  
  163.  
  164. The Integrated Services Draft
  165.  
  166.      ``Integrated Services IP Multicasting over ATM''
  167.      draft-milliken-ipatm-services-00.txt
  168.  
  169.  
  170. Walter Milliken presented some slides on his integrated services draft.
  171. A copy of his slides follow these minutes.
  172.  
  173. Walter put up some diagrams, including one that illustrated using NRHP
  174. to produce shortcut multicast path setup.  However, he realizes that
  175. there's a lot of work left to do to make this work.  Shortcut also
  176. introduces problems with using TTL to end routing loops or control
  177. geographic distribution.
  178.  
  179.  
  180. Conclusion
  181.  
  182. Mark ended the meeting with a brief summary of the status of the
  183. RFC 1577 update and of items remaining on the group's work plan.  Please
  184. see his slides which follow these minutes.
  185.  
  186.