home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipatm / ipatm-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  7KB  |  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. Documents of the IPATM Working Group are available from
  9. ftp://ftp.com21.com/ftp/pub/ip-atm.  The group also has a WWW server,
  10. http://www.com21.com/pages/ietf.html.
  11.  
  12.  
  13.  
  14. ATM Forum Liaison Report - Drew Perkins
  15.  
  16. Drew Perkins gave a report on the ATM Forum.  He will also send an
  17. e-mail report to the mailing list for the Kyoto meeting (held during the
  18. last week of November).
  19.  
  20. The following documents are complete:
  21.  
  22.  
  23.    o LANE - all minor and major questions have been answered.
  24.    o IISP
  25.    o CMIP, SNMP MIBs (m4)
  26.    o Test specifications
  27.  
  28.  
  29. LANE emulation has been made UNI mapping independent (UNI 3.0 and 3.1
  30. are supported).  Intelligent bus support has been added.  A ready
  31. indicate packet has been added (on data connections) and its use is now
  32. mandatory
  33.  
  34. PNNI has started new work items for soft Permanent Virtual Paths (PVPs).
  35.  
  36. The Multiprotocol over ATM group identified some requirements and
  37. different reference models for how the system should work centered
  38. around defining single end system host behavior (query/response).
  39.  
  40. The Signaling working group has continued progress on ``leaf initiated
  41. join.''  The group will start authenticated connection work at the next
  42. meeting, and it was reported that ATM DXI for channelized DS3 has been
  43. sent to straw ballot.
  44.  
  45. The issue of emulation of D1 circuits has been sent to straw ballot.
  46. The support of early packet drop (cell drop, frame drop) is beginning to
  47. get specified.
  48.  
  49. The PHY (physical) group is now allowed to specify more than one
  50. interface.
  51.  
  52. A new Residential Broadband (RBB) group is starting up as a Birds of a
  53. Feather (BOF) effort.  The group is calling for contributions.
  54.  
  55. There was some discussion on multiprotocol BOF models:  LANE model,
  56. combined with Classical and NHRP model.
  57.  
  58.  
  59. RFC 1577 Implementors Round-up
  60.  
  61. There are now about ten implementations in progress and Digital may have
  62. passed the first interoperability test with two other vendors (who
  63. prefer to remain anonymous).
  64.  
  65.  
  66. Interpersonal Multimedia Communications over ATM
  67.  
  68. Dario Ercole gave this presentation.  It was also shown at Interop '94.
  69. Their ATM network connected Paris with Torino using 155 Mbps and 34 Mbps
  70. links.  Sun workstations with FORE SBA200 ATM adapters were used for the
  71. presentation.  They discovered that they could not run IP over ATM over
  72. a public network if they did not perform rate control.  This means
  73. application level rate control and inter-switch rate control.  The NNI
  74. between the switches generated ``big packets.''
  75.  
  76. There was a question regarding the use of RFC 1577 over the wide-area.
  77. Who is going to provide/specify the recommendations for the policing
  78. function?  Andy Malis stated that very much is dependent on the type of
  79. network the traffic is being sent through.  Dario agrees.
  80.  
  81. Ken Hayward asked if ATM is deregulated in Europe.  He also asked about
  82. multiple vendors and solutions.  Dario responded that this topic is not
  83. network specific.  Consensus is that this is more of an ATM specific
  84. issue and that IP over ATM will make use of available services.  While
  85. not an issue of this working group's charter, performance of ATM does
  86. impact performance of IP over ATM.
  87.  
  88.  
  89. IP Multicast Draft Review
  90.  
  91. Grenville Armitage gave an overview of his two Internet-Drafts.  The
  92. goals of the documents are to work within RFC 1577 context and utilize
  93. UNI 3.1 multicast services.  UNI 4.0 and IP multicast routing are not
  94. goals.
  95.  
  96. Mark recommend that there be a separate registration server, i.e.,
  97. de-couple ATMARP_REQUEST from the multicast-request.  There was a
  98. comment to please not have the user type in two 20-byte addresses.
  99. Maybe there is a clever way to do this?  A question was raised about
  100. whether the two servers can live at the same LLC entity?  Mark raised
  101. the point of if the ARP type coding is distinct, it is possible that it
  102. and an ATMARP server could live above 0x0806, however, old
  103. implementations must be tolerant of receiving these types without doing
  104. nasty things.  RFC 1577 rewrite could specify that hosts must be
  105. tolerant of receiving other type codes.
  106.  
  107. Grenville was asked if he perceived any bounds on the size of the
  108. mcleave and join messages.  He said that ARP_MULTI response is quite
  109. large and currently exceeds the bounds on host adapters.
  110.  
  111. What happens when the ARP server fails?  What happens to the VCs that
  112. are active on the host?  These issues are currently not addressed.  Drew
  113. suggested resyncing after a period of time.  He thinks the document
  114. needs to be augmented such that failure ought to reset all state.
  115. Grenville agreed that some text is needed for this.
  116.  
  117. Drew suggested that perhaps the document's discussion of binding to LLC
  118. entities can be skipped, as it might cause more controversy and/or
  119. confusion.  He feels that it is not necessary for this to be in the
  120. document.
  121.  
  122. The end system architecture needs to be drawn out from the actual
  123. implementation.  It useful to understand how the protocol works.
  124. Consensus was to move it into the framework document.
  125.  
  126. There was a discussion of the Multicast Server.  A suggestion was to
  127. name the service Multicast Address Registration Server (MARS).
  128.  
  129. Drew raised the question of the use of an ARP_REPLY instead of an
  130. ARP_MULTI with a single member.  There was discussion of various issues
  131. surrounding setting up a multicast VC. These issues will be addressed in
  132. subsequent rewrites of the draft.
  133.  
  134.  
  135. Framework Document Discussion
  136.  
  137. Discussion of the framework document was led by David Shur.  Curtis
  138. suggested issuing the document in HTML which converts easily to both
  139. PostScript and text.  This would allow easy review and posting as an
  140. Internet-Draft.  He is willing to do the conversion if he can get the
  141. document text in ASCII. It is up to the authors at this point to give it
  142. to him.
  143.  
  144. General consensus that we need to close on this real soon, via a series
  145. of interactive discussions on the e-mail list.  There was also consensus
  146. that Grenville's LLC material from the multicast document be moved to
  147. the framework document.
  148.  
  149.  
  150. Work Plan Presentation
  151.  
  152. Mark presented the suggested FY95 work plan, as follows:
  153.  
  154.  
  155.    o UNI 3.0 Signaling draft --> Informational RFC (submitted)
  156.    o UNI 3.1 Signaling draft --> Proposed (re-submitted 12/4)
  157.    o Framework draft --> Informational RFC
  158.    o Multicast draft(s) --> Proposed (?)
  159.    o RFC 1483 Proposed --> Draft
  160.    o RFC 1577 Proposed --> Proposed (?)
  161.    o RFC 1626 Proposed --> Draft
  162.    o UNI 4.0 Signaling draft
  163.  
  164.  
  165. It was noted that ITU has a contribution for the RFC 1483 rewrite.
  166.  
  167. Questions were raised regarding when to start the RFC 1577 rewrite.
  168. Mark proposed starting this in the March/April time frame.  Drew
  169. suggested getting started sooner.
  170.  
  171. A statement was made that RFC 1626 should be rolled into the RFC 1577
  172. rewrite.  We were not able to discuss this and clarify why they are
  173. different.
  174.  
  175.