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.