NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Hal Sandick <sandick@vnet.ibm.com>
Eric Crawley <esc@gigapacket.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Routing Area Advisor:
Joel Halpern <jhalpern@newbridge.com>
Mailing Lists:
General Discussion: qosr@newbridge.com
To Subscribe: qosr-request@newbridge.com
Archive:
Description of Working Group:
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:
Apr 97 |
|
Post internet-draft outlining the requirements, issues, history, and an initial framework for QoS routing in the Internet. |
Aug 97 |
|
Refine the QOS Framework internet-draft with inputs from other working groups such as RSVP and some of the routing WGs. |
Dec 97 |
|
Submit internet-draft to IESG for publication as an Informational RFC. |
Dec 97 |
|
Revise charter or shut down. |
Internet-Drafts:
· A Framework for QoS-based Routing in the Internet
No Request For Comments
Minutes of the QoS Routing WG meeting
Co-chairs: Eric Crawley, Hal Sandick
Reported by Steve Shew, edited by Hal Sandick
QoSR Presentations URLs
Agenda
ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0897/agenda.pdf
ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0897/agenda.ps
QoS Routing Framework - Bala Rajagopalan
ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0897/qosrfrwk.ps
ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0897/qosrfrwk.pdf
Extended RSVP-Routing Interface - Roch Guerin
ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0897/exproute.pdf
ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0897/exproute.ps
QOSPF update - Jeffrey Zhang
ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0897/qospf_sl.pdf
ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0897/qospf_sl.ps
Setting up Reservations on Explicit Paths using RSVP - Roch Guerin
ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0897/rsvprout.pdf
ftp://ftp.networking.ibm.com/pub/standards/qosr/ietf0897/rsvprout.ps
Minutes
Hal Sandick opened the meeting by presenting the meeting agenda. He restated that the goal of the QoS Routing WG is to produce the QoS routing framework document.
I. QoS Routing Framework - Bala Rajagopalan (draft-ietf-qosr-framework-01.txt)
Bala presented the status of the framework document. Updates from version 00 include more separation between inter and intra domain routing, and organizational changes.
One major issue involves the definition of a flow. In the framework document, a flow is treated as the traffic between two endpoints. This is the original integrated service definition. However, the term is now beginning to be used to also describe an aggregated set of traffic flows between two points, e.g., all the best effort traffic between two border routers. Another issue for discussion is whether signaling should be implicit or explicit. Other broad QoSR issues were presented and are discussed in the draft including stability, which is addressed in path management.
The document suggests extensions to present IP routing that place minimal QoSR requirements on intradomain routing. This should enable flexibility in the intradomain routing solution space. More focus is placed on interdomain routing and requirements for it were presented. These requirements included that best effort traffic be supported without signaling. It was suggested that best effort can take special paths, but should not require signaling to do so. Another requirement was that scalability must be part of any specific QoSR extension or proposal.
Interdomain routing goals, routing issues, and a proposed routing capability set were then presented. In this context it is anticipated that domains are the usual autonomous systems.
For interdomain QoS paths it was assumed that AS metrics are relatively simple and static. With respect to the term "path QoS" it was suggested that the term was overloaded. Within an AS, paths between border AS nodes should be engineered in order to derive a path QoS to advertise outside of the AS. The idea is to engineer them so that QoS is not denied most of the time (probability of service availability). Issues exist in determining the cost of a path which in this context is related to accounting and charging customers.
On a given path, it is useful to be able to aggregate flows. Individually signaled flows within an AS may be aggregated over the inter-AS links. Open issues exist in this area.
Multicast QoS routing goals were presented. These are based on an RSVP model which is more multicast oriented (few senders, lots of receivers). A comment was made that support of sparse mode should be included in the goals. In order to scale, multicast routing requires flow-specific knowledge so that new receivers can be added in an efficient manner. A multicast source routing scheme was presented in which several unicast reverse path computations were needed due to the receiver orientation.
Bala then discussed the need for a routing and signaling interface is needed. It was observed that signaling seems to have some dependency on routing.
Many QoSR issues exist and a number of suggestions and comments were made:
· Exclude cost based routing and not mix with QoS routing
· Multicast routing needs to consider inter and intra domain routing together
· GUM (Grand Unified Multicast) could give useful ideas for multicast QoSR. GUM follows separation model but is still at a research level
II. Extended RSVP-Routing Interface and Setting up Reservations on Explicit Paths using RSVP
Roch Guerin (draft-guerin-ext-rsvp-routing-intf-00.txt) (draft-guerin-expl-path-rsvp-00.txt)
Roch Guerin presented two internet drafts for informational purposes. The focus of these drafts is using RSVP to support explicit paths and route pinning (including QoS routing) for unicast flows.
For both MPLS and QoSR, explicit routes may provide better control of flows. The rationale for placing the explicit route control in RSVP was presented and essentially combining RSVP signaling and route setup avoids having two signaling protocols. MPLS will have RSVP PATH messages follow an explicit MPLS path. QoSR will have routing supply suitable paths for flows. Explicit paths have several desirable characteristics including being loop free. In addition, explicit routes help ensure those paths are adhered to and facilitate enforcement of high-level admission control policies. Explicit routes also involve only one decision point; this has the benefit of simplifying accounting and network resource control.
Two design options were presented: first hop router selects the path, or the host selects the path. Roch's preference is for host not to pick path.
Roch discussed the hop-by-hop mode presented in a draft at the last IETF. He discussed that the Hop-by-hop mode could benefit from loop-free routing protocols and it was noted that hop-by-hop often has the actual path computed in the first router when the network is stable. So use of this mode has some validity. However, during transient conditions an extremely sub optimal path could be selected.
Roch then went on to discuss the pre-computation approach to QoS paths described in the current draft. To correctly compute path QoS, routing must be provided with the necessary information to make its decision. This information should be obtained from RSVP. Conversely, routing could supply change notifications to RSVP. A proposed RSVP/routing interface allowing such interactions was presented. Passing of information across this boundary requires an explicit route object in RSVP.
Ongoing work will address finalization of explicit route objects, loose source routes and error scenarios, and possible combination with MPLS path setup.
Design tradeoffs in implementing explicit routes for QoSR were presented. These include:
· control volume of routing updates versus need for accurate link state
· parameters for number of b/w classes, update mechanism, and quantified values.
Roch presented simulation work analyzing the performance of path precomputation in an ISP-type topology. The accuracy of pre-computed paths is affected by two important factors, the difference between advertised and actual QoSR parameter values, and advertisement hold down times. The impact of these two factors over a variety of values was discussed.
III. QOSPF update - Jeffrey Zhang (draft-zhang-qospf-00.txt,ps)
Changes from previous version were presented. These changes included:
· Partial best-effort trees
· Partial route pinning
· Requirement that all routers in the area support QOSPF
· Editorial fixes
Jeffrey then presented an overview of the original QOSPF work. In QOSPF paths are calculated on demand according to the QoS requirement and routing pinning is optional. Link Resource LSA and Resource Reservation Advertisements (RRAs) are used to disseminate QoS state information. Only source routers recalculate routes and only source routers store RRAs for scalability.
For route pinning, once reservations have been made, a pinned route should not change even though a better path develops. For partial route pinning part of a multicast branch or unicast path is pinned. Setting a flag in RRA which is consulted during SPF calculation does path pinning.
In the interface with RSVP, RSVP queries QOSPF which responds with routes and QOSPF notifies RSVP of changes.
An overview of a Dijkstra modification was presented as part of the implementation status report. Controlled load service only is supported now, and other intserv models need to be accommodated.
None Received