Internet Engineering Task Force R. Guerin/S. Kamat/S. Herzog
INTERNET DRAFT IBM
20 March 1997
QoS Path Management with RSVP
<draft-guerin-qospath-mgmt-rsvp-00.txt>
Status of This Memo
This document is an Internet-Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as
reference material, or to cite them other than as a ``working draft''
or ``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the internet-drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This document describes a proposal aimed at allowing management
through the RSVP [RZB+96] protocol of paths selected by a QoS
routing algorithm such as those of [GOW96, ZSSC96]. The goals of the
proposal are to allow efficient management of such QoS paths with
the minimum possible impact to the RSVP protocol and the existing
routing infrastructure. Basic features of the approach include
leveraging of RSVP soft state mechanisms, and simple extensions
to enable soft pinning (sticking) of paths selected by the QoS
routing algorithm. In addition, the proposal addresses the issue
of preventing the formation of data path loops, and of avoiding
potential race conditions.
Guerin,Kamat,Herzog Expires 25 September 1997 [Page i]
Internet Draft QoS Path Management with RSVP 20 March 1997
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Path Management (Pinning and Unpinning) State and Rules 3
3. Discussions and Examples 6
3.1. Impact of QoS routing on the data path . . . . . . . . . 6
3.2. Handling and prevention of loops . . . . . . . . . . . . 7
3.3. Handling of race conditions in resources allocation . . . 9
4. Alternatives and Extensions 11
5. Summary 12
Guerin,Kamat,Herzog Expires 25 September 1997 [Page ii]
Internet Draft QoS Path Management with RSVP 20 March 1997
1. Introduction
The goal of QoS routing is to select paths for flows with QoS
requirements, in such a manner as to increase the likelihood that the
network will indeed be capable of satisfying them. For example, QoS
routes can be computed using extended versions of existing link state
algorithms such as OSPF [GOW96, ZSSC96]. In general, though, the
use of QoS routing algorithms has a number of implications above and
beyond what is required when using standard routing algorithms.
First, a specific mechanism needs to be used to identify flows with
QoS requirements, so that they can be assigned to the corresponding
QoS routing algorithm. In this document, we assume that the RSVP
protocol is used for that purpose. Specifically, RSVP PATH messages
serve as the trigger to query QoS routing. Second, because of
variations in the availability of resources in the network, routes
between the same source and destination and for the same QoS, may
often differ depending on when the request is made. However, it is
important to ensure that such changes are not always reflected on
existing paths. This is to avoid potential oscillations between
paths and limit changes to cases where the initial selection turns
out to be inadequate.
As a result, some state information needs to be associated with a
QoS route to determine its current validity, i.e., should the QoS
routing algorithm be queried to generate a new and potentially better
route, or does the current one remain adequate. We say that a path
is ``pinned'' when its state specifies that QoS routing need not be
queried anew, while a path is considered ``unpinned'' otherwise.
The main issue is then to define how, when, and where route pinning
and unpinning is to take place. In our context, where the RSVP
protocol is used as the vehicle to request QoS routes, we also want
this process to be as synergetic as possible with the existing RSVP
state management. In particular, our goal is to support pinning and
unpinning (1) of routes in a manner consistent with RSVP soft states
while requiring minimal changes to the RSVP processing rules [BZ96].
It should be noted that some changes are unavoidable, especially
to the interface between RSVP and routing. Specifically,
QoS routing requires, in addition to the current source and
destination addresses, at a minimum, knowledge of the flow's traffic
characteristics (TSpec), and possibly also service types (as per
----------------------------
1. Note that we use the terms pinning and unpinning in
a generic sense, and in particular do not specifically associate them
with a hard state concept.
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 1]
Internet Draft QoS Path Management with RSVP 20 March 1997
the information in the Adspec), PHOP, IP TTL value, etc. In this
document, we assume that the information provided by RSVP to QoS
routing includes at least the sender TSpec in addition to the source
and destination addresses. While such changes seem unavoidable, our
goal is again to keep them as small as possible and also to avoid
any change to the existing RSVP message format. In particular,
we do not consider the option of including an (opaque) object in
the RSVP messages that would contain information specific to QoS
routing, e.g., a source route object. Such an option may indeed have
benefits, but its definition and use are outside the scope of this
document. Instead, we assume that (QoS) routing decisions are made
independently at each hop.
Specifically, we assume interactions between RSVP and routing that
are very similar to what is currently defined. During the processing
of RSVP PATH messages, RSVP queries (QoS) routing to obtain the
next hop(s) for forwarding the PATH message. The PATH message
is then forwarded on the interface(s) returned by (QoS) routing.
As mentioned before, the sender TSpec is part of the information
made available to routing, and a QoS routing algorithm such as in
[GOW96, ZSSC96] selects the next hop along a path to the destination
that is most likely to support the flow specified by the sender
TSpec. Thus, forwarding the PATH message along this next hop should
improve the likelihood of the reservation request succeeding during
RESV message processing. In particular, RESV messages, if any,
propagate as before in the reverse direction of the PATH messages and
attempt to reserve the required resources along the path delineated
by PATH messages.
In the context of the above hop-by-hop routing, there are two main
issues associated with the pinning and unpinning of QoS paths.
1. Detection of loops that may be caused by inconsistencies in the
QoS routes returned by QoS routing at different nodes. Such
inconsistencies are typically transient, but it is important
that the pinning of a path does not result in the formation of
permanent loops.
2. Query of a new QoS route in case of failures. An example of
such failures is a reservation failure because the RESV message
arrived substantially later after the QoS route was initially
selected. Other failures include the usual link failures, and in
general it is important to allow QoS routing to become aware of
the failure and select a better route if one is available.
The QoS path management scheme proposed here addresses the above two
issues based on the following two design rules:
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 2]
Internet Draft QoS Path Management with RSVP 20 March 1997
(i) What is pinned is a ``path'' taken by a specific RSVP flow and
not a ``route'' as computed by the routing algorithm. Hence
pinning and unpinning are RSVP domain operations, and as a result
completely independent of the specific QoS routing algorithm
being used.
(ii) Path pinning and unpinning is kept ``soft'' by tying it to the
existing RSVP soft state mechanism. In other words, we rely on
existing RSVP refreshes and time-out mechanisms to detect the
state changes that trigger pinning and unpinning of paths. In
addition, such changes are triggered only on the basis of current
RSVP state information.
In the rest of this document, we review how the above two rules
translate into the conditions and processing rules for pinning
and unpinning paths, that address the problem of loops while also
enabling reactions to failures. Some examples that illustrate
the operation of these rules in different configurations are also
provided.
2. Path Management (Pinning and Unpinning) State and Rules
The state of a QoS path as maintained by RSVP consists of a flag
that is used to indicate whether the path is currently pinned or
not. Specifically, a pinned path means that QoS routing need not be
queried for a new path (next hop) for forwarding a PATH refresh. The
rules for pinning and unpinning paths are as follows:
1. Paths get pinned during processing of PATH messages.
2. Paths get unpinned when
(a) corresponding path states are removed (time-out or
PATH_TEAR),
(b) some of the parameters received in PATH messages change,
(c) a local admission control failure error is detected after
receiving a RESV message,
(d) a PATH_ERR with a specific error code is received, or
(e) failure notification of a local link belonging to the path is
received.
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 3]
Internet Draft QoS Path Management with RSVP 20 March 1997
The above rules translate into a number of small changes to the
existing RSVP processing rules. These changes can be grouped in two
categories and are described next.
(i) Modifications to RSVP/Routing interface to make use of QoS
routing:
Currently, RSVP acquires routing entries using its asynchronous
query-response interface to routing [Zap96]. Route query is of
the form
Route_Query( [SrcAddress], DestAddress, Notify_flag )
and Routing responds with OutInterface (or OutInterface_list in
case of a multicast connection).
In order for RSVP to interact with a QoS routing algorithm,
QoS_Route_Query needs to also include (at a minimum) the
sender_TSpec, so that it is now of the form
Route_Query( [SrcAddress], DestAddress, TSpec, Notify_flag )
and again responds with OutInterface (or OutInterface_list in
case of a multicast connection).
Another small difference with the current interface is that
the Notify_flag should always be set to True. This is because
there will be no Route_Query to QoS routing in the case of
pinned paths. Hence, it is important that a trigger be provided
to unpin the path in case of failure. However, note that QoS
routing will only generate an asynchronous Route_Change callback
to RSVP in the case of the failure of a local (to the router)
link currently used by the QoS path.
(ii) Modifications to message processing rules in the context of
pinning/unpinning of paths.
* PATH message processing:
When receiving the *first* PATH message, RSVP determines
that no PATH state exists for the flow. It then queries QoS
routing to obtain the next hop along the ``best'' available
path. This next hop is stored as part of the PATH state with
its pinned flag set.
Upon receiving a PATH refresh, RSVP checks for changes
in PATH state that are of relevance to QoS routing. In
particular, it checks for changes in PHOP and the IP TTL
value. If there are no changes and the current next hop is
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 4]
Internet Draft QoS Path Management with RSVP 20 March 1997
indicated as pinned, it will be used to forward the next PATH
refresh. If the PATH state has changed or the current next
hop is marked as unpinned, RSVP queries QoS routing again
to obtain (and pin) a new next hop that is to be used when
forwarding the next PATH refresh. Similarly, at the time
when a PATH refresh is to be sent, RSVP checks if the current
next hop is pinned or not. If it is, it is used to forward
the PATH refresh. Otherwise, QoS routing is again queried to
obtain (and pin) a new next hop.
The unpinning of the path upon detecting changes in either
the PHOP or the IP TTL value of an incoming PATH message is
used to ensure that transient loops caused by inconsistent
routing information are eventually cleared. This is further
explained in Section 3.2.
* PATH_TEAR Processing:
Processing is similar to what is currently done. PATH and
RESV states are removed.
* RESV Processing:
The only change needed is for the case when the resource
reservation attempt fails. As currently specified, a
RESV_ERR message with ``admission control failure'' error
code is still sent downstream in such instances. However,
some additional processing is needed in order to enable
selection of a better path in case one exists. This starts
with the unpinning of the current next hop, and then proceeds
in either one of two ways: attempt *local* repair of the QoS
path or not.
In case local repair is attempted, RSVP queries again
its local QoS routing table. If a different next hop is
returned, i.e., the reservation may now succeed, then local
repair is attempted by pinning the new next hop and sending
a PATH message along the new route. If the same next hop
is returned, then local repair has failed. In this case or
when local repair is not attempted, the current next hop is
then unpinned in the PATH state (but kept). Furthermore, a
PATH_ERR message is sent upstream with a new QoS_Path_Failure
Error Code (the exact code point is tbd) and an associated
Error Value specifying that the type of error was ``Requested
QoS unavailable'' (the specific format of the Error Value
field is tbd). As described below, the receipt of a PATH_ERR
message with the QoS_Path_Failure Error Code triggers
unpinning of the next hop information at upstream router.
This ensures that QoS routing will be queried at the time of
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 5]
Internet Draft QoS Path Management with RSVP 20 March 1997
the next PATH refresh, so that a better path, if one exists,
can be identified.
* Route_Change Notification processing:
A Route_Change notification is triggered when QoS routing
detects that a local link currently used by a QoS path
failed. Upon receiving such a notification, RSVP immediately
unpins the current next hop. As in the case of reservation
failure, RSVP can then first attempt local repair, i.e.,
query QoS routing for a new next hop. If a new next hop is
returned by QoS routing, RSVP uses it to replace the previous
next hop, marks it as pinned, and forwards a PATH message
towards the new next hop. If QoS routing responds that no
path to the destination is available or if local repair is
not attempted, RSVP sends upstream a PATH_ERR message with
the QoS_Path_Failure Error Code and an Error Value specifying
``Link failure''.
* PATH_ERR Processing:
The only modification is, as mentioned above, to recognize
the new QoS_Path_failure Error Code and unpin the associated
next hop. This forces a fresh QoS route query during the
processing of the next PATH refresh.
* RESV_ERR Processing:
There are no changes to RESV_ERR processing.
3. Discussions and Examples
3.1. Impact of QoS routing on the data path
The use of QoS routing only affects the choice of a data path and not
how the actual forwarding of data packet takes place. Nevertheless,
there is an important aspect that needs to be noted. Specifically,
while PATH messages are immediately forwarded onto the next hop
returned by QoS routing, the same need not apply to data packets.
This is because of the potential for transient loops in QoS paths.
Forwarding PATH messages on a QoS path that may contain loops has
minimal impact on the routers and is actually useful to detect and
eliminate loops (more on this below). However, depending on how fast
loops can be resolved, forwarding data packets on a QoS path may be
best deferred until the absence of a loop has been verified.
As a result, it is proposed that modification of the packet
classifier in the forwarding loop that will result in data packets
being sent towards the next hop specified by QoS routing, be deferred
until the time a RESV message is received. As discussed below, the
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 6]
Internet Draft QoS Path Management with RSVP 20 March 1997
receipt of a RESV message also implies that loops are not present in
the QoS path. Note that the update of classifiers at the time of
receipt of a RESV message is consistent with when this is done using
the current default routing. The main difference is that the actual
flow of data packets may not start following the QoS path until after
the classifier has been updated in the first node where the default
and the QoS paths start differing.
There are some drawbacks with the above approach, e.g., inability to
take advantage of partial reservations in some instances, and they
can be addressed in a number of ways. One possibility, that may be
acceptable if transient loops are detected and removed quickly, is
to actually update classifiers upon receipt of a PATH message (or a
certain number of PATH messages, when it appears that the QoS path
is stable and loops are not present). Another more comprehensive
alternative is to couple this process with the handling of policy
information. Such a coupling is a natural step as the ability for
users to specify how much of a partial reservation is acceptable
to them, i.e., does one need to look for another path, is really
a policy issue. In order to support such a coupling, policy data
objects would have to be included in PATH, RESV, RESV_ERR, and
PATH_ERR messages, in order to enable the local policy control module
[Her96] to assess the suitability of a QoS path. The discussion and
description of such an approach is the subject of future work.
3.2. Handling and prevention of loops
As mentioned before, pinning of a QoS path introduces the possibility
of loops when nodes use inconsistent information to make QoS routing
decisions. Therefore, it is important to detect such occurrence and
unpin the selected QoS path (next hop), so that loops can eventually
be eliminated once nodes have converged to consistent information.
We now illustrate how the processing rules described earlier
are successful at detecting and eliminating loops. We do so in
the context of two possible looping scenarios, that respectively
illustrate the use of detecting changes in the PHOP and IP TTL value
for detecting different occurrences of loops.
Scenario_1:_
In scenario 1, we assume that R2 (and possibly other routers along
RX...RY) has routing (metrics) information that is not consistent
with that of R1. Router R1 identified R2 as the next hop on the best
QoS to RH on the basis that this QoS path was R1-R2-R3...RH. However,
because of inconsistent metrics information, R2 identifies RX as
the next hop on the best QoS path to RH, so that the PATH message
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 7]
Internet Draft QoS Path Management with RSVP 20 March 1997
SH ....... R1 -------- R2 ----------- R3 ....... RH
/ \
/ \
/ \
/ \
RX ......... RY
SH - Sender host
RH - Receiver host
Figure 1: Scenario 1
forwarded to RX eventually comes back to R2 from RY. As a result, a
temporary loop is created and would remain in effect for as long as
the next hop information remains pinned. However, because the PATH
message arriving from RY to R2 comes with a different PHOP value,
this triggers unpinning of the next hop information at R2. QoS
routing is, therefore, queried anew the next time R2 has to forward a
PATH message for the flow, so that the loop is eventually (once the
routing/metrics information at R2 becomes consistent with that at R1)
removed.
Note that how quickly the loop is removed depends on the RSVP timer
values and also how they are synchronized between the different
routers. For example, R2 may receive a PATH refresh from RY just
after having received one from R1. This would not affect the
unpinning of the next hop (RX), but means that RY will be kept as
the PHOP for the flow, at least until the next refresh from R1 (if
the routing information at R2 is now consistent, PATH messages will
be forwarded to R3 and not RX, so that RY will not receive PATH
refreshes and, therefore, not send any itself). As a result, a RESV
from RH may initially be forwarded to RY instead of R1. However,
this will not create a reservation loop, since when the RESV returns
to R2 from RX, R2 determines that RX is not the correct NHOP for the
flow.
Scenario_2:_
Scenario 1 showed the case where the router which caused the loop was
also the one where the loop closed. Scenario 2 considers the case
where the loop does not close at the router that caused it in the
first place.
Here the ``correct'' QoS path from SH to RH is SH....R1-R2-RX-R3....RH.
However, router RX has inconsistent routing information based on
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 8]
Internet Draft QoS Path Management with RSVP 20 March 1997
SH ....... R1 -------- R2.........RY
\ /
\ /
\ /
\ /
RX----------- R3 ....... RH
SH - Sender host
RH - Receiver host
Figure 2: Scenario 2
which it identifies RY as the best next hop. This eventually creates
a loop closing at R2 as RY identifies R2 as the best next hop to RH.
In this case, RX would not see any change in PHOP, and therefore this
criterion cannot be relied upon to unpin the next hop state at RX.
However, RX will receive PATH messages with varying IP TTL values,
and this will then trigger unpinning of the path so that when RX
routing information eventually gets updated, it can then identify the
correct next hop, namely R3.
3.3. Handling of race conditions in resources allocation
The problem of race conditions, i.e., having several paths competing
for the same resources, is intrinsic to the distributed nature of
QoS routing decisions. This is not unique to the model assumed in
this document, e.g., PNNI routing in an ATM network faces a similar
quandary, but the problem can be exacerbated by the potential time
lag between the selection of a path and when reservation of resources
is actually attempted, i.e., upon receipt of a RESV message. As a
result, it is important to ensure that QoS routing and the associated
mechanisms for establishing QoS paths is sufficiently flexible to
handle such race conditions and change paths if and when required.
In this section, we illustrate how the mechanisms described in this
document handle such situations in the context of a representative
example.
Consider the topology shown in Figure 3 and assume that link R2-R3
can accommodate only one of the two flows at a time, and that the
segment R1-R2-R3-R5-R6 is pinned for both the flows before either RH1
or RH2 has generated a RESV message. Next, assume that RH1 is the
first to generate a RESV message and that its reservation succeeds
on the entire path. When RH2 generates its own RESV message, its
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 9]
Internet Draft QoS Path Management with RSVP 20 March 1997
SH1 SH2
. .
. .
. .
R1
|
|
R2
/ \
/ \
R3 R4
\ /
\ /
R5
|
|
R6
. .
. .
. .
RH1 RH2
SH1 sends a PATH message to set up a flow to RH1.
SH2 sends a PATH message to set up a flow to RH2.
Current QoS routes for the two flows (selected independently) are
SH1 ...... R1-R2-R3-R5-R6 ...... RH1
SH2 ...... R1-R2-R3-R5-R6 ...... RH2.
Figure 3: Competing Flows.
reservation will succeed at R6, R5, and R3, but fail at R2. Based on
the processing rules outlined above, R2 will then unpins its next hop
state in addition to forwarding a RESV_ERR downstream. Note, that
the path and reservation states for the flow remain intact on the
downstream segment.
If R2 attempts local repair next, it will then query QoS routing.
If the same next hop, R3, is returned, R2 determines that local
repair has failed and sends a PATH_ERR message upstream with Error
Code QoS_Path_failure and Error Value ``Requested QoS unavailable''.
Receipt of this PATH_ERR message then triggers unpinning of the next
hop state at all upstream nodes, i.e., at R1 (and SH1). This in
turn will trigger querying of QoS routing at the time of the next
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 10]
Internet Draft QoS Path Management with RSVP 20 March 1997
PATH refresh. This ensures that if at some time resources become
available on the path through R4 and this information is provided
to QoS routing, then the flow from SH2 to RH2 will ultimately be
routed over that path, i.e., R2 will identify R4 as its next hop for
the flow. As a result, a PATH message will then be sent out on the
interface to R4 so that RESV messages from R5 will eventually be
forwarded towards R4, and the flows' reservation will then likely
succeed. A similar process would have been followed if QoS routing
had returned R4 as the best next hop, when R2 attempted to perform
local repair.
Note that R2 did not issue a PATH_TEAR to R3 at the time of the
reservation failure. There are a number of reasons for this. First,
the path through R3 may indeed be the best one currently available,
and any reservation that has succeeded on it so far should probably
not be taken down (a PATH_TEAR would) unless the receiver itself
decides so. Second, keeping the reservations in place also avoids
the problem of having the resources on links from R5 to R6 and R6
to RH2 be taken by some other flows, while the flow from SH2 to
RH2 is in the process of switching paths. Instead, the existing
reservations on the downstream segment R5-R6....RH2 will be reused,
and the path and reservation states for the flow at R3 will time
out. On the other hand, keeping the reservations in place may affect
the outcome of QoS routing. This is because QoS routing typically
won't know, that on some links the resources actually available to
the flow are higher than what is currently advertised. However, this
should be mitigated by the fact that advertised resources are always
inaccurate and also because the QoS routing will always return the
best possible path, even if it does not think that the necessary
resources are available on it.
4. Alternatives and Extensions
In this document, we have discussed an approach where the bulk of the
responsibility for QoS path management, i.e., pinning and unpinning
of next hop information, lies with RSVP. This was motivated in part
by the need to couple path management with the RSVP soft state
management, and by the close relation to existing RSVP processing
rules. However, it is also possible to defer this responsibility to
routing itself. The cost of such an approach would be the need for
QoS routing to replicate some of the RSVP state information, e.g.,
store PHOP, NHOP, TSpec, etc., for each flow, and also by requiring
that this information be passed across the interface between RSVP and
routing.
Another different design approach is to rely on the inclusion of
source (explicit) route objects, that would be carried in RSVP PATH
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 11]
Internet Draft QoS Path Management with RSVP 20 March 1997
messages as opaque objects and passed to QoS routing at each node.
Such a design affords some simplification as it avoids the problem
of loops altogether, but issues related to pinning and unpinning of
paths (at the source) remain for the cases of reservation and link
failures. The discussion of such a design is clearly of interest,
but it is beyond the scope of this document.
5. Summary
In this document, we have described a possible approach to provide
QoS routing while using RSVP as the signaling protocol to setup QoS
routes. The goal was to minimize changes to RSVP processing rules,
rely as much as possible on the existing RSVP soft states, and do so
without limiting the benefits of QoS routing. The approach taken
relies on hop-by-hop routing decisions similar to those used by the
current best effort routing. Potential routing loops are detected
and eliminated through simple monitoring of RSVP state information.
Similarly, reservation and link failures are handled using existing
RSVP error messages with new error codes specifying the type of
routing failure.
It should be noted that while the approach described in this document
is not dependent on the use of a particular QoS routing protocol,
it has been essentially targeted at unicast routing and possibly
multicast routing protocols such as MOSPF, where consistent routing
decisions can be made at all nodes based on common global knowledge.
Other multicast routing protocols may have additional requirements
that necessitate additional or different processing rules.
Acknowledgment
The authors would like to thank Ariel Orda, Ping Pan, and Dimitris
Pendarakis for helpful feedback on early versions of this proposal.
References
[BZ96] R. Braden and L. Zhang. Resource reSerVation
Protocol (RSVP) version 1, processing rule
(draft-ietf-rsvp-procrules-00.ps). INTERNET-DRAFT,
Internet Engineering Task Force - RSVP WG, November 1996.
[GOW96] R. Guerin, A. Orda, and D. Williams. QoS Routing
Mechanisms and OSPF Extensions, (draft-guerin-qos-routing-ospf-00.txt).
INTERNET-DRAFT, Internet Engineering Task Force, November
1996.
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 12]
Internet Draft QoS Path Management with RSVP 20 March 1997
[Her96] S. Herzog. Local Policy Modules (LPM): Policy
Control for Resource Reservation Protocols.
(draft-ietf-rsvp-policy-lpm-01.[ps,txt]). INTERNET-DRAFT,
Internet Engineering Task Force - RSVP WG, November 1996.
[RZB+96] R. Braden (Ed.), L. Zhang, S. Berson, S. Herzog, and
S. Jamin. Resource reSerVation Protocol (RSVP) version
1, functional specification (draft-ietf-rsvp-spec-13.ps).
INTERNET-DRAFT, Internet Engineering Task Force - RSVP WG,
July 1996.
[Zap96] D. Zappala. RSRR: A Routing Interface for RSVP
(draft-ietf-rsvp-routing-01.ps). INTERNET-DRAFT, Internet
Engineering Task Force - RSVP WG, November 1996.
[ZSSC96] Z. Zhang, C. Sanchez, B. Salkewicz, and E. Crawley.
Quality of Service Extensions to OSPF or Quality of Service
Path First Routing (QOSPF). INTERNET-DRAFT, Internet
Engineering Task Force, June 1996.
Authors' Address
Roch Guerin
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
guerin@watson.ibm.com
VOICE +1 914 784-7038
FAX +1 914 784-6205
Sanjay Kamat
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
sanjay@watson.ibm.com
VOICE +1 914 784-7402
FAX +1 914 784-6205
SHai Herzog
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
herzog@watson.ibm.com
VOICE +1 914 784-6059
FAX +1 914 784-6205
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 13]
Internet Draft QoS Path Management with RSVP 20 March 1997
Guerin,Kamat,Herzog Expires 25 September 1997 [Page 14]