Minutes of the QoS Routing WG meeting Aug. 14, 1997. Minutes taken by Steve Shew, edited by Hal Sandick Co-chairs: Eric Crawley, 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. 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 services 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 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 path 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. 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 scaleability. 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. Path pinning is done by setting a flag in RRA which is consulted during SPF calculation. 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.