Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/qosr/qosr-minutes-97apr.txt

Text File | 1997-05-29 | 11.2 KB | 202 lines

Editor's Note:  These minutes have not been edited.


                        Minutes of the QoS Routing WG

  Wednesday, April 6th, 1997
  Co-Chairs:  Eric S. Crawley <[e-mail]>
              Hal Sandick <[e-mail]>

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.