home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rsvp / rsvp-minutes-95apr.txt < prev    next >
Text File  |  1995-05-27  |  11KB  |  283 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Lixia Zhang/Xerox PARC and Robert Braden/USC-ISI
  5.  
  6. Minutes of the Resource Reservation Setup Protocol Working Group (RSVP)
  7.  
  8. The RSVP Working Group met on Wednesday and Thursday.  The primary
  9. objective of the meeting was to review and discuss the major revision to
  10. the protocol specification that resulted from the San Jose meeting, with
  11. the intent of moving towards standardization.
  12.  
  13.  
  14.  
  15. Review of Revised Functional Specification
  16.  
  17. Bob Braden gave a presentation on the revised Functional Specification,
  18. emphasizing the changes from the November 1994 draft (04).  The new
  19. draft is:  draft-ietf-rsvp-spec-05.ps, .txt.
  20.  
  21. Modifications/additions:
  22.  
  23.  
  24.    o RSVP session:  `generalized port' is (UDP/TCP) port.
  25.  
  26.    o Flowspec:  Rspec and Tspec.
  27.  
  28.    o Filterspec:  `generalized port' is (UDP/TCP) port.
  29.  
  30.    o If link layer is active (e.g., ATM), the traffic scheduler does
  31.      whatever is necessary to obtain desired QoS from link (e.g., use
  32.      signaling protocol).
  33.  
  34.    o Added OPWA.
  35.  
  36.    o Dynamic filter style moved to appendix:  high priority study.
  37.  
  38.    o Format of RSVP messages completely changed to small fixed header
  39.      followed by sequence of variable-length typed objects.
  40.  
  41.  
  42. Issue from Berson:  Whether to forward a Resv message when an error is
  43. found, is still open.  Note that reservation error may still occur even
  44. with OPWA.
  45.  
  46. Issue:  Recovery from routing changes:  should we do local recovery, or
  47. end-to-end?  The argument for local recovery is protocol simplicity; no
  48. additions are necessary.  Arguments for end-to-end recovery are:  (1)
  49. RSVP cannot recover faster than the underlying routing protocol's
  50. reaction time, and (2) local recovery has the danger of making
  51. reservation along wrong paths.  Comment from Farinacci:  We have
  52. experienced that in PIM implementation -- whenever topology changes,
  53. hosts often rejoin the multicast group through wrong interface, and have
  54. to readjust later.
  55.  
  56. Fixed header includes length, since we did not include a pseudo-header.
  57. Question:  Is pseudo header a good thing anyway?  (The audience seemed
  58. to reached consensus of not using pseudo-header).  It was noted that the
  59. explicit message length field is redundant, since it can be easily
  60. derived by parsing the objects in the message.
  61.  
  62. Issue:  Why not just define one filter type instead of two?  Braden:
  63. allows different address families:  currently IPv4 and IP6, in the
  64. future perhaps IPX, etc.
  65.  
  66. Issue from Ajit:  RSVP interface has to be redesigned to match the
  67. latest multicast routing release.  Braden:  Yes, RSVP has a
  68. routing-dependent adaptation module to interface to routing.  Farinacci:
  69. Better not to design a protocol based only on the implementation one
  70. knows today.
  71.  
  72. Have one credential per sender in Path messages, but only one credential
  73. per reservation -- this is due to resv merging, in order to scale.
  74.  
  75. In WF style, an optional filter specification is allowed, to support
  76. partial wildcarding:  e.g., (host,*) or (*,port), as well as a full
  77. wildcard sender (*,*).  Not clear this is useful, but it is an easy
  78. generalization.
  79.  
  80. Issue:  How to compute merge sender_Tspecs in order to compute
  81. reservation = MIN(Tspec, sender_Tspec).  It seems that they must be
  82. summed.  Question:  why should different receiver and sender Tspec be
  83. allowed?  Braden:  to prevent over-reservation on access links.
  84.  
  85. Question:  Who is working on the RSVP/routing interface issue now?
  86. Braden:  Daniel Zappala, with Deborah Estrin.  Will make sure document
  87. is presented to the working group.
  88.  
  89.  
  90. Presentations on Two Major Open Issues
  91.  
  92. Issue One:  Wildcard Filter Looping
  93.  
  94. Steve Berson presented a review and proposed solution to the two
  95. problems posed by the wildcard filter style (more generally, by any
  96. style with wildcard scope) with looped topologies:  unwanted
  97. reservations, and self-refreshing loops.  This was joint work with
  98. Daniel Zappala.
  99.  
  100. Their proposed solution:  Record the upstream senders for each outgoing
  101. link and carry that sender list in each Resv message going upstream.  If
  102. the underlying multicast routing protocol uses shared trees, then this
  103. information not necessary.
  104.  
  105. The main issue with the proposed solution is scalability:  it causes a
  106. linear increase in the size/number of Resv messages with the number of
  107. senders.  However, Zappala and Berson pointed out that its scaling is
  108. the same as the scaling of Path messages and of (source-tree-based)
  109. multicast routing.
  110.  
  111. Braden introduced a related proposal:  Add a new reservation style,
  112. ``shared explicit.''  This style would allow a receiver to explicitly
  113. list the senders to use a shared reservation.  It would also be possible
  114. for the application to call for a wildcard SE reservation, with the RSVP
  115. daemon filling in the complete sender list from the path state.  The
  116. result would be exactly analogous to a WF reservation using the
  117. Zappala/Berson scheme.
  118.  
  119. There was a lengthy discussion of the issues.  Wroclawski strongly
  120. objected to the proposed WF modification, due to scaling.  He suggested
  121. that it could seriously impact possible future applications.  Others in
  122. the room attempted to construct alternative solutions (and there were
  123. later claims of success, although no alternative has yet been
  124. documented).
  125.  
  126. Issue:  our application requires reservation ACK. Braden:  Can be added
  127. into OPWA messages.
  128.  
  129. There seemed to be general agreement that the SE style (without the
  130. wildcard) was a useful feature that should be in the specification.
  131. There was not a clear consensus on what to do about wildcard filters.
  132. Zhang argued for taking some time to look for a better solution.
  133.  
  134.  
  135.  
  136. Issue Two:  IP6 Flow Label in RSVP
  137.  
  138. Lixia Zhang presented a proposal on how to support IP6 flow labels in
  139. RSVP, to speed packet classification.  IP6 flow labels have the
  140. constraint:  all packets carrying the same flow label must have the same
  141. source and destination address.  This limits the use of flow labels to
  142. demultiplexing packet streams within each source host.
  143.  
  144. She proposed that a flow label could simply replace the port number and
  145. protocol ID fields in an RSVP filter specification.  There was general
  146. agreement with this approach.
  147.  
  148.  
  149.  
  150. Implementation Status and Vendor Plans
  151.  
  152.    o Prototype RSVP daemon:  Steve Berson, ISI
  153.  
  154.      Release 2.1 of the RSVP code was released on 17 March.  The rsvpd
  155.      in 2.1 is functionally the same as release 2.01, but 2.1 has many
  156.      updates and fixes.  Release 2.1 also includes the modified
  157.      applications from MIT and a modified mrouted.
  158.  
  159.    o Applications using RSVP: Bobby Minnear, MIT
  160.  
  161.      MIT has updated their Tk/Tcl-based RSVP interface program tkrsvp to
  162.      use the new API. This supports RSVP reservations for vat, for
  163.      example.  They have also modified nv to support RSVP. This code is
  164.      part of the latest ISI release.
  165.  
  166.    o Traffic control kernel using RSVP: John Wroclawski, MIT
  167.  
  168.      MIT has done a FreeBSD implementation of a traffic control kernel,
  169.      including CSZ scheduling with link-sharing.
  170.  
  171.    o Solaris implementation:  Don Hoffman, Sun
  172.  
  173.      The Solaris RSVP+CBQ version of the release 2.01 RSVP code is
  174.      available now on the net.  Releast 2.1 will be available very soon.
  175.  
  176.    o Bay Networks:  John Krawczyk
  177.  
  178.      Bay Networks is implementing multiple sources of reservation
  179.      information:  RSVP, ST2, and static configuration for reserved
  180.      flows.  Their architecture will have these sources as parallel
  181.      inputs to the scheduler.  Their timetable:
  182.  
  183.       -  Ship ST2 implementation by summer (September)
  184.       -  Ship RSVP implementation by fall (October)
  185.  
  186.  
  187.    o Cisco:  Dino Farinacci
  188.  
  189.      Multicast routing has been widely deployed inside Cisco (PIM), they
  190.      plan to ship WFQ by July, and RSVP by the end of the year.
  191.  
  192.  
  193.  
  194. Discussion of More Open Issues
  195.  
  196.    o Flowspec format
  197.  
  198.      Braden suggested that the format of flowspecs should be defined by
  199.      the INTSERV Working Group, with an appropriate indirection in the
  200.      RSVP specification.
  201.  
  202.      Issue:  since one cannot leave a hole in real code, whose
  203.      responsibility it is to define a minimal flowspec that vendors can
  204.      implement now?
  205.  
  206.    o More on WF style looping
  207.  
  208.      Zhang:  Some progress has been made towards resolving WF loop
  209.      problems.  The basic idea is that:  (1) PATH messages do not loop
  210.      themselves; (2) if RESV messages are made to reverse the paths of
  211.      PATH messages precisely (this is not done in the current
  212.      specification), they will be loop-free and travel no further than
  213.      PATH messages.
  214.  
  215.    o UDP encapsulation revisited
  216.  
  217.      Presentation by Braden:  UDP encapsulation turned out to be more
  218.      complex than expected.  Two different well-known multicast
  219.      addresses need to be used for encapsulation.
  220.  
  221.      UDP encapsulation allowed RSVP to work through PARC firewall (their
  222.      security people did not link a new IP type, but they understood how
  223.      to handle UDP packets with given address and port numbers).  But
  224.      there was a multicast tunnel, which required a special provision:
  225.      unicasting Path messages from host to first-hop router.
  226.  
  227.      Question by Wroclawski:  Getting worried about hack after hack,
  228.      hence losing architectural oversight.  Please summarize all the
  229.      hacks that have been proposed so far in one place for assessment.
  230.  
  231.      Question by Baker:  Why not just UDP encapsulations everywhere and
  232.      forget protocol ID 46?  Farinacci:  Would make it much harder/less
  233.      efficient to grab RSVP packets in routers.
  234.  
  235.    o Functionality and reliability issues
  236.  
  237.       -  Require RPF check on received messages?
  238.       -  Do we need to send more than one copy of teardown messages?
  239.       -  How to use IP6 flowIDs?  [Resolved earlier.]
  240.  
  241.  
  242.    o Security issues
  243.  
  244.       -  Security data
  245.       -  Do we need credential for teardown?  [The answer seemed to be
  246.          no.]
  247.       -  What if a credential changes?
  248.  
  249.      Question:  What is needed for Version 1 specification in terms of
  250.      security considerations?
  251.  
  252.       -  RSVP needs the same integrity check used by routing protocols
  253.          today.
  254.  
  255.       -  There was some discussion of credentials.  USC/ISI and MIT are
  256.          working on the administrative model for credentials.  There is
  257.          a note that will be distributed to the working group.
  258.          Question:  Should the credential issue be left for future study
  259.          or defined now?  (Lots of discussion).
  260.  
  261.  
  262. Advanced Reservations
  263.  
  264.    o Using RSVP for advanced reservations:  Mikael Degermark, University
  265.      of Lulea, Sweden
  266.  
  267.      Question:  Receivers may not be all turned on yet when you make
  268.      reservations one month in advance, and the topology may also change
  269.      in between.  Therefore RSVP does not seem to be the right vehicle
  270.      for advanced reservations in the way as the authors have proposed.
  271.      Response:  RSVP messages can be sent very slowly in advance of the
  272.      event.
  273.  
  274.    o The `RBONE' proposal for using RSVP in the MBONE: Steve Casner, ISI
  275.  
  276.      Comments:  A proper analogy between advanced reservation and RSVP
  277.      is airline reservations:  airlines make advanced reservations by
  278.      selling tickets, air traffic controller controls the real traffic.
  279.  
  280.      Issue:  Would the proposed advanced reservations motivate people to
  281.      all make advanced reservations?  What would be the impact?
  282.  
  283.