Editor's Note: These minutes have not been edited. Minutes of the QoS Routing WG Wednesday, April 6th, 1997 Co-Chairs: Eric S. Crawley Hal Sandick Reported by Hal Sandick and Eric Crawley Meeting notes taken by JJ Krawczyk and Steven Shew URLs for presentations given at the WG meeting: QoSR WG Agenda ---------------- ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/agenda.pdf ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/agenda.ppt ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/agenda.ps QOS Routing Framework - Bala Rajagopalan ---------------------------------------- ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/framework.pdf ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/framework.ppt ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/framework.ps Alternate path route construction heuristics - Daniel Zappala ------------------------------------------------------------- ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/morf-color.ppt ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/morf-color.ps ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/morfbw.ppt ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/morfbw.ps QoS Path Management with RSVP - Sanjay Kamat -------------------------------------------- ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/qos-path-mgmt-rsvp.ps ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/qos-path-mgmt-rsvp.pdf QoS Routing Mechanisms and OSPF Extensions - Tony Przygienda ------------------------------------------------------------ ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/qospf-Przygienda.ppt ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0497/qospf-Przygienda.ps.zip The QoS Routing (QoSR) WG met for one session at the 38th IETF with approxi- mately 160 attendees. The meeting began with Eric Crawley presenting the proposed agenda. Eric stressed the point that the WG has one deliverable, the QoS Routing framework document and, therefore, the development of this document is the main mission of the group. To the extent possible the WG would allow related material (e.g. QoS tree building algorithm) to be pre- sented and discussed. However, items that were clearly in the realm of research were beyond the scope of the WG. Bala Ragagopalan presented the work group's framework document, "A Framework for QoS-Based Routing in the Internet" (draft-ietf-qosr-framework-00.txt). The key goal of framework document is to develop a consensus on QoS routing requirements and to facilitate the development of a high level architecture. Bala reviewed several QoS Routing solutions that were enumerated in the draft and then discussed four broad QoSR issues o Routing information and how it is generated and propagated o Path computation o Path establishment o Administrative Control. In order to deal with these issues in a manageable way the framework document will organize requirements and solutions into the separate problem spaces of intradomain (IGP) and interdomain (EGP) routing. Within the limits of intra- domain routing a number of independent solutions are possible (e.g. qospf). Because of this, the framework will not focus on IGP solutions. Instead the framework will focus on a scalable interdomain QoSR architecture which will allow consistent and stable interactions between domains. Inter-domain QoS routing issues include: o What interdomain routing capabilities are needed? o What information is exchanged to achieve these? o How is the external routing information represented within a domain? o How are interdomain paths computed and set up? o What policy controls may be exerted on interdomain path computation and flow routing? Bala then turned the discussion to multicast QoS routing. In addition to the interdomain QoS routing requirements, multicast QoS routing is also concerned with scalablity to large groups with dynamic membership, support of receiver initiated heterogeneous reservations, and support for RSVP shared reservation styles. Two significant issues that especially impact multicast QoS routing are reverse path forwarding and the needed for existing flow specific know- ledge in order to add new receivers. One solution presented was receiver-oriented multicast routing. This approach would, cause the RSVP reservation message to travel a different path than RSVP PATH message which preceded it. Some viewed this approach as "RSVP unfriendly." Daniel Zappala disagreed with this evaluation and indicated that receiver oriented multicast routing could be handled differently (see summary of his presentation below). This discussion raised the question if QoS routing should be constrained to specific signalling assumptions, e.g. RSVP and it's existing design. Bala ended his presentation with the following conclusions from the framework document. o Definition of link and path metrics requires considerable thought. o Cost as a routing parameter should be considered. o Receiver-oriented multicast routing has advantages. In the ensuing discussion Joel Halpern expressed concern about using cost in the QoS routing path computations. He felt this was dangerous to include in the framework because we don't know how to charge for a flow. Fred Baker suggested that RSVP could define additional objects if required. Hal asked for feedback from the WG on the framework document particularly on the issues of link and path metrics and receiver oriented multicast. The next presentation was given by Sanjay Kamat on "QoS Path Management with RSVP" (draft-guerin-qospath-mgmt-rsvp-00.txt). This draft dealt with exten- sions to RSVP required to run over a link state routing protocol which adver- tised available bandwidth (the presentation of the companion draft describing QoS extensions to OSPF is summarized below). The problem this draft is trying to solve is how keep a RSVP path in place as long as the path meets the service requirements of the flow. Today a path might change because of opportunistic routing, i.e. a better path becomes available. This is how best effort routing works today. In addition, advertising available band- width may also cause an RSVP path to change unnecessarily. This will happen because an RSVP router can't tell from these advertisements if a particular flow's receivers were able to obtain the desired reservations. Without this additional information, upstream RSVP routers would have to re-route the flow if the advertised available bandwidth dropped below the target level (e.g. the Tspec). This would happen even if the routers on the current path had been able to satisfy all the receivers' reservation requests. To solve these 2 problems the draft proposes pinning a path as the RSVP PATH message traversed the QoSR path toward the receiver(s). Once a path was setup it would stay pinned as long as the path could continue to meet the service requirements of the flow. This was presented as an optional service, i.e. an application would have to request it. The proposal also required the RSVP/routing interface to include the int-service Tspec as an input param- eter. It was pointed out that pinning the path during routing transients could produce an acceptable path that was extremely sub-optimal. Sanjay suggested that for unicast, source routing might solve this problem. People stated concerns about a unicast only solution. Joel Halpern brought up the point that a packet should not be allowed go back forth between pinned and unpinned paths -- this could produce routing loops. Fred Baker expressed two con- cerns, one that QoS implies RSVP and that QOS routing implies link-state. Eric and Bala pointed out that the framework document discusses both link state and distance vector solutions. Tony Przygienda followed this presentation with one on QoS extensions for OSPF, "QoS Routing Mechanisms and OSPF Extensions" (draft-guerin-qos-routing-ospf-01.txt). The proposed extensions were in two areas, metrics and path computation. The new metrics are delay and available bandwidth. These metrics encodings will not change the existing OSPF packet format and will be backward compatible. This will allow QoS capable imple- mentations to coexist with non-QoS capable OSPF routers. The new path compu- tation for QoS routing will be based on the Bellman-Ford algorithm instead of the Dyjkstra algorithm. The path computation algorithm will be used to build a routing table with two indices, the destination and the number of hops. In this way a shorter (less hops) but acceptable path could be selected over a "better" path (e.g. lower delay) which was longer and, therefore, used more resources. This work is to be addressed in the OSPF WG. Next Daniel Zappala presented another method for obtaining QoS routes, "A Route Setup Mechanism for Multicast Routing" (based on the drafts draft-zappala-multicast-routing-ar-00.txt and draft-zappala-multicast-routing-me-00.txt). Daniel identified three current approaches to route pinning: hop by hop sender oriented (Kamat et al), hop- by-hop receiver oriented (previous work by presenter) and source initiated explicit routing (PNNI and QOSPF). He then proposed a fourth way - receiver oriented multicast using explicit routing. The approach is called Match or Fail (MORF) and has the following design points: o Designed for interdomain multicast route setup o No global distribution of topology, resource availability or tree place- ment o Receivers independently construct and install alternate paths and pinned routes o No resource checks; all requests are equal o Resolves route conflicts on a first come first served basis o Has good loop prevention properties The MORF mechanism requires a receiver desiring a QoS route to send a route setup message containing an explicit route to the source of the flow. The setup message traverses the routers in the explicit route and allows upstream routers to merge route setup requests. On the positive side, MORF supports the same amount of heterogeneity as RSVP and doesn't require global coordi- nation of routing or the multicast tree. On the other hand, it would be dif- ficult to avoid a service disruption during MORF re-routing. Daniel has gotten favorable results when simulating the MORF algorithm and plans to con- tinue the development of this work. Masataka's presentation was on "Stable QoS Aggregation". Masataka pointed out that there is a problem when aggregating QoS metric information from smaller links in a domain with links of larger capacity. Outside the domain, the information about the smaller links could be lost. There was some dis- cussion about whether to advertise optimistic or pessimistic capacities but the differences could be significant. Masataka proposed using RSVP PATH mes- sages to help ameliorate this problem. Eric closed the meeting by indicating that the group would meet at the Munich IETF. At this meeting the WG will focus on reviewing an updated version of the framework document.