NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Eric Crawley <esc@baynetworks.com>
Hal Sandick <sandick@vnet.ibm.com>
Joel Halpern <jhalpern@newbridge.com>
General Discussion:qosr@newbridge.com
To Subscribe: qosr-request@newbridge.com
Archive:
This working group is chartered to define a framework and techniques for Quality of Service (QoS) Routing in the Internet. QoS Routing allows the network to determine a path that supports the QoS needs of one or more flows in the network. The path chosen may not be the "traditional shortest path" that is typically computed based on current metrics and policies. The group's work will focus on how to select and maintain packet forwarding paths capable of meeting specific service class objectives. In particular, the techniques will specify what extensions and adaptations to routing and QoS setup protocols are required to support QoS routing and new packet handling techniques that may be needed to avoid packet loops for QoS flows. While it is not intended, this may also spawn the development of new routing protocols that can specifically address QoS routing. The WG will identify topics and issues in QOS routing which require additional research.
The WG needs to work closely with other routing protocol working groups such as OSPF, IDR, BGP, and IDMR. A close relationship with the RSVP, IntServ, and ISSLL working groups is also needed to understand the QoS signaling and specification.
Goals and Milestones:
· A Framework for QoS-based Routing in the Internet
Minutes of the QoS Routing (QoSR) Working Group
Reported by: Hal Sandick and Eric Crawley
Meeting notes taken by: JJ Krawczyk and Steven Shew
URLs for presentations given at the Working Group meeting:
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 Zappalaftp://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) Working Group met for one session at the 38th IETF with approximately 160 attendees. The meeting began with Eric Crawley presenting the proposed agenda. Eric stressed the point that the Working Group 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 Working Group would allow related material (e.g., QoS tree building algorithm) to be presented and discussed. However, items that were clearly in the realm of research were beyond the scope of the Working Group.
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:
1. Routing information and how it is generated and propagated
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 intradomain 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:
1. What interdomain routing capabilities are needed?
2. What information is exchanged to achieve these?
3. How is the external routing information represented within a domain?
4. How are interdomain paths computed and set up?
5. 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 scalability 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 knowledge 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 signaling assumptions, e.g., RSVP and its existing design.
Bala ended his presentation with the following conclusions from the framework document.
Definition of link and path metrics requires considerable thought.
Cost, as a routing parameter, should be considered.
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 Working Group 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 extensions to RSVP required to run over a link state routing protocol that advertised 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 bandwidth 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 two 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 parameter.
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 concerns, 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 implementations to coexist with non-QoS capable OSPF routers. The new path computation 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 Working Group.
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:
· Designed for interdomain multicast route setup
· No global distribution of topology, resource availability or tree placement
· Receivers independently construct and install alternate paths and pinned routes
· No resource checks; all requests are equal
· Resolves route conflicts on a first-come, first-served basis
· 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 coordination of routing or the multicast tree. On the other hand, it would be difficult to avoid a service disruption during MORF re-routing. Daniel has gotten favorable results when simulating the MORF algorithm and plans to continue 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 discussion about whether to advertise optimistic or pessimistic capacities but the differences could be significant. Masataka proposed using RSVP PATH messages to help ameliorate this problem.
Eric closed the meeting by indicating that the group would meet at the Munich IETF. At this meeting the Working Group will focus on reviewing an updated version of the framework document.