home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rsvp / rsvp-minutes-94jul.txt < prev    next >
Text File  |  1994-11-02  |  8KB  |  206 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Bob Braden/USC ISI and Lixia Zhang/Xerox PARC
  5.  
  6. Minutes of the Resource Reservation Setup Protocol Working Group (RSVP)
  7.  
  8.  
  9. Agenda - Wednesday Session
  10.  
  11.    o Implementation reports
  12.       -  RSVP daemon, API: Steve Berson and Don Hoffman
  13.       -  CSZ kernels for SunOS 4.x and PC, packet classifier:  John
  14.          Wroclawski/MIT
  15.       -  LBL/UCL/Sun CBQ kernel:  Don Hoffman/Sun
  16.       -  UCL packet classifier:  Ian Wakeman/UCL
  17.       -  sd/tcl invoking RSVP: John Wroclawski
  18.  
  19.    o Interaction between routing and RSVP
  20.       -  Long-term architecture:  Deborah Estrin/ISI
  21.       -  Short-term approach:  Lixia Zhang/Xerox PARC
  22.  
  23.  
  24. Implementation Reports
  25.  
  26. Steve Berson and Don Hoffman described work on an RSVP daemon, which is
  27. running in both the SunOS 4.x and Solaris operating systems.  This
  28. daemon implements all the major features of the current RSVP protocol
  29. specification.  Two more significant changes are in the works.
  30.  
  31.  
  32.    o RSVP hooks are being added (at PARC) to the new pruning version of
  33.      mrouted.  This will allow the RSVP daemon to directly query mrouted
  34.      for multicast routes.  It is expected to appear in a multicast
  35.      release later this summer.
  36.  
  37.    o The current protocol specification contains a simplified generic
  38.      API, and Don Hoffman has implemented a corresponding UNIX library
  39.      call interface.
  40.  
  41.  
  42. Does the kernel have to be changed to use RSVP? Hosts only need to add
  43. multicast routing to their kernels; routers must change anyway to add
  44. packet scheduling.
  45.  
  46. Is there any access control on reservations?  RSVP includes a user
  47. identification/authorization field for this purpose, but its contents
  48. and meaning are not yet specified.  Some feel that access control is
  49. useless without full encryption-based authentication, but others believe
  50. that even a simple ad hoc mechanism (e.g., manually configured access
  51. lists) can be very useful for administrative control in the short term.
  52. The chair invited someone interested in the administrative model for
  53. access control to work on the problem.
  54.  
  55. John Wroclawski described a packet scheduling kernel he has been
  56. developing at MIT, based on the CSZ (Clark/Shenker/Zhang) approach.  He
  57. can make it available for a PC/BSD and/or a DARTnet SunOS 4.1 platform;
  58. he asked the meeting which is more useful to release.  Hoffman has
  59. interfaced RSVP to a Solaris kernel containing the CBQ packet scheduler
  60. that was originally developed by Van Jacobson and Sally Floyd and
  61. repackaged as a streams module at UCL. RSVP provides dynamic setup of
  62. CBQ classes.
  63.  
  64. Ian Wakeman described a new packet classifier he is developing at UCL.
  65.  
  66. Finally, Wroclawski explained how MIT has added RSVP calls to sd, vat,
  67. and nv.
  68.  
  69.  
  70. Interaction Between Routing and RSVP
  71.  
  72. Deborah Estrin presented a discussion of the long-term architectural
  73. issues in the interaction between routing and reservation setup (see
  74. slides).  There are compelling reasons to keep routing protocols
  75. distinct from the reservation setup protocol; however, they must
  76. interact.  The routing protocol is used to distribute reservation
  77. requests along the appropriate path, while the reservation protocol may
  78. need to give feedback to influence the routing decision.
  79.  
  80. The general approach that Estrin described is as follows.  RSVP obtains
  81. a (``default'') route and tries to set up a reservation along it; if
  82. that fails, RSVP asks for an alternate route and tries it, repeating
  83. this if necessary.  In asking for a route, RSVP may ask for a route that
  84. satisfies some very rough QoS criteria (e.g., ``low delay''); these
  85. criteria define the QoR (``Quality of Route'').  RSVP sets up the
  86. desired specific QoS (e.g., a specific numeric delay bound) along the
  87. route(s) provided to it.
  88.  
  89. Estrin pointed out an ugly problem due to heterogeneity of requests:  a
  90. larger reservation trying to graft onto an existing distribution tree
  91. may force rerouting of existing upstream reservations.
  92.  
  93. There was an extensive discussion from the floor.  There was some
  94. distaste expressed about alternate routing; however, it was pointed out
  95. that we do not yet know how important alternate routing will be,
  96. although we need to understand its cost and mechanisms, should it be
  97. necessary.
  98.  
  99. One suggestion was that a QoS used by an application should choose from
  100. a small set of specific values, and that the routing protocols can then
  101. compute routes to provide exactly the desired QoS. This approach would
  102. essentially remove the distinction between QoR and QoS; if acceptable,
  103. it would greatly simplify the interaction between routing and RSVP.
  104. There was considerable debate on whether this approach is sufficiently
  105. general; it appears that QoR cannot completely assume the role of QoS,
  106. implying that the present complication is necessary.
  107.  
  108. Lixia Zhang then presented a proposal for how the working group should
  109. proceed with the routing/RSVP interaction in the short term (This talk
  110. was actually deferred to the beginning of the Thursday session).  She
  111. made the following proposals for the short term:
  112.  
  113.  
  114.    o Orientation of routes:  RSVP will work with existing routing
  115.      protocols that provide only forward routes (handled by path
  116.      messages).
  117.  
  118.    o Quality of routes:  Route selection by QoR will not be possible.
  119.  
  120.    o Stability of reservation:  Defer the design of ``route pinning,''
  121.      or ``smooth transition,'' which would keep reservations stable when
  122.      routes change.  As a result, there may be gaps in QoS when routes
  123.      change.
  124.  
  125.    o Reservation repair:  RSVP provides periodic refresh messages to
  126.      trigger repair after a route fails.  Defer the design of local
  127.      repair mechanisms.
  128.  
  129.  
  130. There appeared to be general acceptance of this proposal.
  131.  
  132.  
  133. Agenda - Thursday Session
  134.  
  135.    o Reservation model:  Scott Shenker/PARC
  136.    o Open issue in RSVP protocol:  Lixia Zhang/PARC
  137.    o Release plans
  138.    o Future meetings
  139.  
  140.  
  141. Reservation Model
  142.  
  143. Scott Shenker presented a talk on the reservation model, part two of the
  144. talk he delivered in the Integrated Services Working Group (INTSERV). He
  145. explained the mechanism to implement his proposed ``one-pass with
  146. advertising'' (OPWA) reservation model.  In this model, information is
  147. gathered hop-by-hop along the path(s) from sender(s) to receiver, and
  148. delivered to the receiver application as an ``advertisement.''  This
  149. information tells the receiver application the end-to-end delay bounds
  150. that will result from each possible hop/hop reservation request.
  151.  
  152. Implementation of the OPWA model requires little additional machinery in
  153. RSVP. Path messages would carry the ``advertising'' information forward
  154. to the receivers.
  155.  
  156. There was a lively discussion of this proposal.  Issues included the
  157. necessity for end-to-end guarantees, how to make it more efficient
  158. (e.g., advertizing on demand), the importance of end-to-end delay
  159. knowledge for an application, the difficulty of transparent rerouting
  160. using OPWA and the use of worst-case versus current values for the
  161. bounds.
  162.  
  163.  
  164. Open Issues
  165.  
  166. Lixia Zhang discussed the major open issues in RSVP. Following her
  167. presentation, individual working group members volunteered to track each
  168. of the items and report at the next meeting.  The list is:
  169.  
  170.  
  171.    o Negotiation model:  Scott Shenker
  172.  
  173.    o Interface with routing:  Deborah Estrin, ``X'' from the Nimrod
  174.      group (``X'' to be designated by Noel Chiappa)
  175.  
  176.    o Access control:  ``Y'' (``Y'' to be designated by Dave Clark)
  177.  
  178.    o Filter specification representation:  John Wroclawski, Bob Braden
  179.  
  180.    o ``Killer reservations'':  Steve Berson
  181.  
  182.    o Firewall architecture:  Don Hoffman
  183.  
  184.    o Multicast groups versus RSVP filters:  Lixia Zhang, Deborah Estrin,
  185.      Noel Chiappa
  186.  
  187.  
  188. Release Plans
  189.  
  190. Braden presented the plans for releasing initial versions of resource
  191. reservation code.  This will include RSVP, two different packet
  192. scheduling kernels, and modified vat, nv, and sd tools to invoke RSVP.
  193. He asked for a few sites to volunteer to test the first release, which
  194. is projected for later in August.
  195.  
  196. It was pointed out that testing over the MBone would be useful.  Braden
  197. agreed to discuss this with Deering.
  198.  
  199.  
  200. Future Meetings
  201.  
  202. The group agreed to hold an interim teleconference on Thursday 27
  203. October.  Steve Casner noted that we hope to be able to demonstrate RSVP
  204. during the Multimedia '94 conference, 19-20 October in San Francisco.
  205.  
  206.