Solaris RSVP Implementation

• Shared source code base with ISI BSD-based RSVP.
• Compatible with Solaris 2.3
• Native Solaris. BSD binary compatibility not required.
• Only CBQ scheduling in version 1. Hooks remain for CSZ scheduling interface. Combination support possible in future releases.
• Binary compatibility with SunOs-compiled apps that use the standard RSVP APIs (version 1 or 2).
• Availability:
  • Standard RSVP source release from ISI for RSVP daemon.
  • Binary packages for RSVP kernel code (multicast routing and CBQ interfaces).

Solaris CBQ Implementation

• Original word done at LBL (original implementation) and UCL (Solaris port + enhancements). Modification by Sun to allow cloning/plumbing on any IP-compatible physical interface, and RSVP kernel interface for dynamic creation of classes at run-time.
• RSVP daemon builds "class hierarchy" at start-up based on configuration file.
  • Standard classes (e.g., best-effort and default) created as child of root class as per configuration file.
  • "Parent" for predictive and guaranteed service created as special classes. Admission control strategy associated with each class.

RSVP + CBQ

• New class instantiated as child of special class for each flow.
  • Class per flow allow use of CBQ for flow shaping and policing. Good for end-nodes.
  • Large number of classes => efficiency concerns?
  • Some form of aggregation probably needed on core routers.
• "Trivial" admission control strategies used based on bandwidth only. No delay bound assurances made.
  • RSVP guaranteed reservations mapped to peak bandwidth with no borrowing from parent allowed.
  • RSVP predictive reservations mapped to average bandwidth with borrowing from predictive class "parent."

RSVP, CBQ and Hierarchical Video

• Temporaly-scaled JPEG with 3 levels.
  • Level 1 = 3.75fps, Level 1+2 = 7.5fps, Level 1+2+3 = 30 fps.
  • Approximately order of magnitude stability.
• Defined as 3 Fixed Filter (FF) flows, with DROP bit set in PATH. Each receiver sends RESVs all three flows. Flow forwarded only if RESV succeeds.
• Ordering problem: No way to express ordering among RESV on different UDP sockets.
  • Add flow group concept to RSVP.
  • Use flow descriptor that can be bit masked (allow single RSVP flow to select multiple video flows). Keep trying diminishing RESV until one succeeds.