home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / cip / cip-minutes-90may.txt < prev    next >
Text File  |  1993-02-17  |  5KB  |  108 lines
  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Claudio Topolcic/ BBN
  7.  
  8. The CO-IP Working Group met at the May 1-4 IETF Meeting at
  9. Carnegie-Mellon University.  During the Tuesday sessions we tried to
  10. pick up where we had left off in Florida State.  We heard updates on
  11. DARTNet and the TWBNet.  Tony Mazraani gave a progress report on the
  12. COIP kernel and a presentation on Washington University's work on
  13. Resource Management in Broadcast Lans.  Work toward defining experiments
  14. for the DARTNet was hindered since not all the key people were present.
  15. We spent the balance of the sessions discussing the current draft of the
  16. ST-2 protocol specification.
  17.  
  18. Charlie Lynn had previously edited and distributed the current draft of
  19. the ST-2 protocol specification.  He had also written up a number of
  20. issues that needed more thinking.  The group discussed these issues and
  21. a few others that came up during the meetings.
  22.  
  23. A number of editorial comments to the draft were discussed.  These
  24. included some minor restructuring to minimize repetition and increase
  25. clarity.  More forward and backward pointers were suggested, as well as
  26. more examples.  Numerous editing changes were suggested.
  27.  
  28. We discussed the relation between ST and IP. We decided to allow two
  29. forms of the ST header.  The short form is as had previously been
  30. specified.  A long form is structured like an IP header so that it can
  31. be processed by IP-only agents, and takes the place of the concept of IP
  32. encapsulation.  The long form may also be used when IP security is
  33. required or to reduce either deliberate or accidental denial of service
  34. problems.
  35.  
  36. The issue of use of multicast lead to a lot of discussion.  Ideally, we
  37. would like to be able for an ST agent to request that the local network
  38. dynamically create a multicast group for use by a stream, as its use
  39. could reduce the network bandwidth required to support the stream.
  40. Unfortunately, there does not seem to be much support for dynamic
  41. management of multicast addresses (how does a ``user'' dynamically
  42. request a multicast address at a given protocol layer, what agent(s) on
  43. a network robustly assign multicast addresses, how are the assigned
  44. addresses mapped into addresses for use above the network layer, e.g.,
  45. IP multicast addresses, how are the assigned addresses reliably
  46. released/garbage collected, etc.).
  47.  
  48. It was felt that trying to create such a service was a challenging
  49. problem tangential to the work of the Working Group and should be
  50. delegated to some other group.  The result was to either to use
  51. replication instead of multicast, or to use static multicast groups.
  52. The problem with the former is wasted bandwidth, that with the latter is
  53. scaling -- what were formerly seperable problems (solvable by each
  54. stream independantly) now become problems which must be solved in common
  55. by all streams on a network.  HID negotiation is one example.
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64. We discussed mechanisms by which changes could be made to established
  65. streams.  For example, it may be desirable to allow a request to change
  66. a stream's bandwidth to allow a range of possible bandwidths.  Also,
  67. when a new target is added to a stream, it would be desirable to
  68. decrease the stream's bandwidth, if that is allowed by the stream, if
  69. the new target can only be added with that decreased bandwidth.  These
  70. features causes some difficulties in coordinating the changes among the
  71. ST agents, as well as the applications, while maintaining the
  72. uninterrupted flow of data packets.
  73.  
  74. Other specific issues discussed included the following:
  75.  
  76.  
  77.   1. A Target cannot be an IP multicast group.
  78.   2. The ACCEPT message should be delayed until the HID negotiation has
  79.      been completed.
  80.   3. We are not addressing the issues of spoofing (beyond the security
  81.      features to be provided for IP by SDNS), intentional denial of
  82.      service, or unintentional denial of service resulting from broken
  83.      routes.
  84.   4. The structure of the ``Group of Streams'' specification.
  85.   5. Whether source routes would be strict, loose, strict in ST and
  86.      loose in IP, or something else.  This issue was not resolved.
  87.  
  88.  
  89. ATTENDEES
  90.  
  91.     Fred Bohle                fab@saturn.acc.com
  92.     Terry Braun               tob@kinetics.com
  93.     Stephen Casner            casner@isi.edu
  94.     Danny Cohen               cohen@isi.edu
  95.     Richard Fox               sytek!rfox@sun.com
  96.     Jonathan Goldick          goldick@b.psc.edv
  97.     Jack Hahn                 hahn@umd5.umd.edu
  98.     Charles Lynn              clynn@bbn.com
  99.     Tony Mazraani             tonym@flora.wustl.edu
  100.     Zaw-Sing Su               zsu@sri.com
  101.     Ian Thomas                ian@chipcom.com
  102.     Claudio Topolcic          topolcic@bbn.com
  103.     Dave Wood                 wood@gateway.mitre.org
  104.  
  105.  
  106.  
  107.                                    2
  108.