< draft-ietf-qosr-framework-04.txt   draft-ietf-qosr-framework-05.txt >
INTERNET DRAFT INTERNET DRAFT
draft-ietf-qosr-framework-04.txt April, 9, 1998 draft-ietf-qosr-framework-05.txt May, 27, 1998
A Framework for QoS-based Routing in the Internet A Framework for QoS-based Routing in the Internet
Eric Crawley Raj Nair Bala Rajagopalan Hal Sandick Eric Crawley Raj Nair Bala Rajagopalan Hal Sandick
Argon Networks Arrowpoint NEC USA Bay Networks Argon Networks Arrowpoint NEC USA Bay Networks
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
skipping to change at page 1, line 33 skipping to change at page 1, line 33
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast). (US West Coast).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet Draft expires on October, 10, 1998. This Internet Draft expires on October, 27, 1998.
ABSTRACT ABSTRACT
QoS-based routing has been recognized as a missing piece in the evolution QoS-based routing has been recognized as a missing piece in the evolution
of QoS-based service offerings in the Internet. This document describes of QoS-based service offerings in the Internet. This document describes
some of the QoS-based routing issues and requirements, and proposes a some of the QoS-based routing issues and requirements, and proposes a
framework for QoS-based routing in the Internet. This framework is based framework for QoS-based routing in the Internet. This framework is based
on extending the current Internet routing model of intra and interdomain on extending the current Internet routing model of intra and interdomain
routing to support QoS. routing to support QoS.
skipping to change at page 4, line 36 skipping to change at page 4, line 36
policy requirements of the overall resource usage by the flow. Higher- policy requirements of the overall resource usage by the flow. Higher-
level admission control may result in the failure of a flow set-up even level admission control may result in the failure of a flow set-up even
when FAC at each node along the flow path indicates resource availability. when FAC at each node along the flow path indicates resource availability.
3. QOS-BASED ROUTING: BACKGROUND AND ISSUES 3. QOS-BASED ROUTING: BACKGROUND AND ISSUES
3.1 Best-Effort and QoS-Based Routing 3.1 Best-Effort and QoS-Based Routing
--------------------------------- ---------------------------------
Routing deployed in today's Internet is focused on connectivity and Routing deployed in today's Internet is focused on connectivity and
typically supports only one type of datagram service called "best effort typically supports only one type of datagram service called "best effort"
[WC96]. Current Internet routing protocols, e.g. BGP, OSPF, RIP, use [WC96]. Current Internet routing protocols, e.g. OSPF, RIP, use
"shortest path routing"[ZES97], i.e. routing that is optimized for a "shortest path routing", i.e. routing that is optimized for a single
single arbitrary metric, administrative weight or hop count. These arbitrary metric, administrative weight or hop count. These routing
routing protocols are also "opportunistic," using the current shortest protocols are also "opportunistic," using the current shortest path
path or route to a destination. In order to eliminate loops alternative or route to a destination. Alternate paths with acceptable but non-optimal
paths with adequate but less than optimal cost can not be used to route cost can not be used to route traffic (shortest path routing protocols do
traffic (shortest path routing protocols do allow a router to alternate allow a router to alternate among several equal cost paths to a destination).
among several equal cost paths to a destination).
QoS-based routing must extend the current routing paradigm in three basic QoS-based routing must extend the current routing paradigm in three basic
ways. First, additional routing paths to support traffic using ways. First, to support traffic using integrated-services class of services,
integrated-services class of services will have to be calculated. In multiple paths between node pairs will have to be calculated. Some of these
addition, some of these new classes of service will require the new classes of service will require the distribution of additional routing
distribution of additional routing metrics, e.g. delay, and available metrics, e.g. delay, and available bandwidth. If any of these metrics change
bandwidth. If any of these metrics change frequently then routing updates frequently, routing updates can become more frequent thereby consuming network
can become more frequent consuming network bandwidth and router CPU cycles. bandwidth and router CPU cycles.
Second, today's opportunistic routing will shift traffic from one path Second, today's opportunistic routing will shift traffic from one path
to another as soon as a "better path is found. The traffic will be to another as soon as a "better" path is found. The traffic will be
shifted even if the existing path can meet the service requirements of shifted even if the existing path can meet the service requirements of
the existing traffic. If routing calculation is tied to frequently the existing traffic. If routing calculation is tied to frequently
changing consumable resources (e.g. available bandwidth) this change will changing consumable resources (e.g. available bandwidth) this change will
happen more often and can introduce routing oscillations as traffic happen more often and can introduce routing oscillations as traffic
shifts back and forth between two paths. Further, frequently changing shifts back and forth between alternate paths. Furthermore, frequently
routes can increase the variation in the delay and jitter experienced by changing routes can increase the variation in the delay and jitter experienced
the end users. by the end users.
Third, as mentioned earlier, today's optimal path routing algorithms Third, as mentioned earlier, today's optimal path routing algorithms
don't support alternate routing. If the best existing path cannot admit do not support alternate routing. If the best existing path cannot admit
a new flow the associated traffic can't be forwarded even if an adequate a new flow, the associated traffic cannot be forwarded even if an adequate
alternative path exists. It should be noted that no proposal claims to alternate path exists.
solve all of these problems without using some additional mechanisms,
e.g. a setup protocol like RSVP or MORF [ZSSC97, PGW96, ZES97].
3.2 QoS-Based Routing and Resource Reservation 3.2 QoS-Based Routing and Resource Reservation
------------------------------------------ ------------------------------------------
It is very easy to get QoS-based routing confused with resource It is important to understand the difference between QoS-based routing and
reservation. While resource reservation protocols such as RSVP [BZBH97] resource reservation. While resource reservation protocols such as RSVP
provide a method for requesting and reserving network resources, they do [BZBH97] provide a method for requesting and reserving network resources,
not provide a mechanism for assuring that the network path used has they do not provide a mechanism for determining a network path that has
adequate resources to accommodate the requested QoS. Conversely, adequate resources to accommodate the requested QoS. Conversely,
QoS-based routing increases the chance that adequate resources are QoS-based routing allows the determination of a path that has a good
available along a path but it does not reserve the resources. chance of accommodating the requested QoS, but it does not include a
mechanism to reserve the required resources.
Consequently, QoS-based routing is usually used in conjunction with some Consequently, QoS-based routing is usually used in conjunction with some
form of resource reservation or resource allocation. Simple forms of form of resource reservation or resource allocation mechanism. Simple forms
QoS-based routing have been used in the past for Type of Service (TOS) of QoS-based routing have been used in the past for Type of Service (TOS)
routing [M91]. In the case of OSPF, a different SPF tree can be computed routing [M91]. In the case of OSPF, a different shortest-path tree can be
for each of the 8 TOS values in the IP header [ISI81]. Such mechanisms computed for each of the 8 TOS values in the IP header [ISI81]. Such
can be used to select specially provisioned paths but do not completely mechanisms can be used to select specially provisioned paths but do not
assure that resources are not overbooked along the path. As long as completely assure that resources are not overbooked along the path. As long
strict resource management and control are not needed, mechanisms such as strict resource management and control are not needed, mechanisms such
as TOS-based routing are useful for separating whole classes of traffic as TOS-based routing are useful for separating whole classes of traffic
over multiple routes. Such mechanisms might work well with the emerging over multiple routes. Such mechanisms might work well with the emerging
Differential Services efforts. Differential Services efforts [BBCD98].
Combining a resource reservation protocol with QoS-based routing allows Combining a resource reservation protocol with QoS-based routing allows
fine control over the route and resources at the expense of state and fine control over the route and resources at the cost of additional
setup time. Using a signalling protocol, such as RSVP, to trigger QoS- state and setup time. For example, a protocol such as RSVP may be used to
based routing calculations provides a method for computing a route that trigger QoS-based routing calculations to meet the needs of a specific flow.
meets the needs for a specific flow.
3.3 QoS-Based Routing: Objectives 3.3 QoS-Based Routing: Objectives
----------------------------- -----------------------------
Under QoS-based routing, paths for flows would be determined based on Under QoS-based routing, paths for flows would be determined based on
some knowledge of resource availability in the network, as well as the some knowledge of resource availability in the network, as well as the
QoS requirement of flows. The main objectives of QoS-based routing are: QoS requirement of flows. The main objectives of QoS-based routing are:
1. Dynamic determination of feasible paths: QoS-based routing can 1. Dynamic determination of feasible paths: QoS-based routing can
determine a path, from among possibly many choices, that has a good determine a path, from among possibly many choices, that has a good
skipping to change at page 6, line 49 skipping to change at page 6, line 49
Some of these issues are discussed briefly next. Interdomain routing is Some of these issues are discussed briefly next. Interdomain routing is
discussed in Section 5. discussed in Section 5.
3.4 QoS Determination and Resource Reservation 3.4 QoS Determination and Resource Reservation
------------------------------------------ ------------------------------------------
To determine whether the QoS requirements of a flow can be accommodated To determine whether the QoS requirements of a flow can be accommodated
on a link, a router must be able to determine the QoS available on the on a link, a router must be able to determine the QoS available on the
link. It is still an open issue as to how the QoS availability is link. It is still an open issue as to how the QoS availability is
determined for broadcast multiple access links (e.g., Ethernet). A determined for broadcast multiple access links (e.g., Ethernet). A
related problem is the reservation of resources over such links. The related problem is the reservation of resources over such links.
ISSLL working group is attempting to resolve these issues [GSSS97]. Solutions to these problems are just emerging [GPSS98].
Similar problems arise when a router is connected to a large non- Similar problems arise when a router is connected to a large non-
broadcast multiple access network, such as ATM. In this case, if the broadcast multiple access network, such as ATM. In this case, if the
destination of a flow is outside the ATM network, the router may have destination of a flow is outside the ATM network, the router may have
multiple egress choices. Furthermore, the QoS availability on the ATM multiple egress choices. Furthermore, the QoS availability on the ATM
paths to each egress point may be different. The issues then are, paths to each egress point may be different. The issues then are,
o how does a router determine all the egress choices across the ATM o how does a router determine all the egress choices across the ATM
network? network?
o how does it determine what QoS is available over the path to each o how does it determine what QoS is available over the path to each
egress point?, and egress point?, and
o what QoS value does the router advertise for the ATM link. o what QoS value does the router advertise for the ATM link.
Typically, IP routing over ATM (e.g., NHRP) allows the selection of a Typically, IP routing over ATM (e.g., NHRP) allows the selection of a
single egress point in the ATM network, and the procedure does not single egress point in the ATM network, and the procedure does not
incorporate any knowledge of the QoS required over the path. An approach incorporate any knowledge of the QoS required over the path. An approach
like I-PNNI [IPNNI] would be helpful here, although with some complexity. like I-PNNI [IPNNI] would be helpful here, although it introduces some
complexity.
An additional problem with resource reservation is how to determine what An additional problem with resource reservation is how to determine what
resources have already been allocated to a flow. Without being able to resources have already been allocated to a multicast flow. The availability
determine this a path calculation for a flow may avoid a link which was of this information during path computation improves the chances of finding
already earmarked resources for the flow. QOSPF [ZSSC97] handles this a path to add a new receiver to a multicast flow. QOSPF [ZSSC97] handles
problem by having routers distribute reservation information to other this problem by letting routers broadcast reserved resource information to
routers in it area. Alternate path routing [ZES97] deals with this issue other routers in their area. Alternate path routing [ZES97] deals with this
by using probe messages to find a path with sufficient resources. Path issue by using probe messages to find a path with sufficient resources. Path
QoS Computation (PQC) method, proposed in [GOA97], adds the bandwidth QoS Computation (PQC) method, proposed in [GOA97], propagates bandwidth
allocated to a flow to the RSVP PATH message, but the information available allocation information in RSVP PATH messages. A router receiving the PATH
to a receiver includes only the allocation on upstream branches and not on message gets an indication of the resource allocation only on those links in
other branches of the multicast tree over which the PATH message is sent. the path to itself from the source. Allocation for the same flow on other
Thus, the PQC method may not be sufficient to find feasible QoS-accommodating remote branches of the multicast tree is not available. Thus, the PQC method
paths to all receivers. may not be sufficient to find feasible QoS-accommodating paths to all receivers.
3.5 Granularity of Routing Decision 3.5 Granularity of Routing Decision
------------------------------- -------------------------------
Routing in the Internet is currently based only on the destination Routing in the Internet is currently based only on the destination
address of a packet. Many multicast routing protocols require routing address of a packet. Many multicast routing protocols require routing
based on the source and destination of a packet. The Integrated Services based on the source AND destination of a packet. The Integrated Services
architecture and RSVP allow QoS determination for an individual flow architecture and RSVP allow QoS determination for an individual flow
between a source and destination. This set of routing granularities between a source and a destination. This set of routing granularities
presents a problem for QoS routing solutions. presents a problem for QoS routing solutions.
If routing based only on destination address is considered, then all If routing based only on destination address is considered, then an intermediate
flows between any source and the destination will be routed over the router will route all flows between different sources and a given destination
same path. This is acceptable if the path has adequate capacity but along the same path. This is acceptable if the path has adequate capacity but
it can be a problem if there are multiple flows to a destination that a problem arises if there are multiple flows to a destination that exceed the
exceed the capacity of the link. capacity of the link.
One version of QOSPF [ZSSC97] determines QoS routes based on source and One version of QOSPF [ZSSC97] determines QoS routes based on source and
destination address. This implies that all traffic between a given destination address. This implies that all traffic between a given source
source and destination, regardless of the flow, will travel down the same and destination, regardless of the flow, will travel down the same
route. Again, the route must have capacity for all the QoS traffic for route. Again, the route must have capacity for all the QoS traffic for
the source/destination pair. The amount of routing state is also the source/destination pair. The amount of routing state also
increased since the routing tables must include source/destination pairs increases since the routing tables must include source/destination pairs
instead of just destination. This amount of state increases rapidly as instead of just the destination.
the traditional routes are summarized.
The best granularity is found when routing is based on individual flows The best granularity is found when routing is based on individual flows
but this has a tremendous cost for routing state. Each QoS flow can be but this incurs a tremendous cost in terms of the routing state. Each QoS
routed separately between any source and destination. Use of the IPv6 flow can be routed separately between any source and destination. PQC [GOA97]
flow label can help in identifying or classifying flows. PQC [GOA97] and alternate path routing [ZES97], are examples of solutions which operate
and alternate path routing [ZES97], are examples of solutions which at the flow level.
operate at the flow level.
Both source/destination and flow based routing also have a dangerous Both source/destination and flow-based routing may be susceptible to
property when it comes to route loop detection. If a node along a flow packet looping under hop-by-hop forwarding. Suppose a node along a flow or
or source/ destination based path loses the state information for the source/destination-based path loses the state information for the flow.
flow and the flow based route is different from the destination only Also suppose that the flow-based route is different from the regular
based routing, the potential exists for a route loop to form when the destination-based route. The potential then exists for a routing loop to
node forwards the packet based on destination routing towards a node form when the node forwards a packet belonging to the flow using its
earlier on the path. destination-based routing table to a node that occurs earlier on the
flow-based path. This is because the latter node may use its flow-based
routing table to forward the packet again to the former and this can
go on indefinitely.
3.6 Metrics and Path Computation 3.6 Metrics and Path Computation
---------------------------- ----------------------------
3.6.1 Metric Selection and Representation 3.6.1 Metric Selection and Representation
There are some considerations in defining suitable link and node metrics There are some considerations in defining suitable link and node metrics
[WC96]. First, the metrics must represent the basic network properties of [WC96]. First, the metrics must represent the basic network properties of
interest. Such metrics include residual bandwidth, delay and jitter. interest. Such metrics include residual bandwidth, delay and jitter.
Since the flow QoS requirements have to be mapped onto path metrics, the Since the flow QoS requirements have to be mapped onto path metrics, the
metrics define the types of QoS guarantees the network can support. metrics define the types of QoS guarantees the network can support.
Alternatively, QoS routing cannot support QoS requirements that cannot be Alternatively, QoS-based routing cannot support QoS requirements that
meaningfully mapped onto a reasonable combination of path metrics. Second, cannot be meaningfully mapped onto a reasonable combination of path metrics.
path computation based on a metric or a combination of metrics must not Second, path computation based on a metric or a combination of metrics must
be too complex as to render them impractical. In this regard, it is not be too complex as to render them impractical. In this regard, it is
worthwhile to note that path computation based on certain combinations of worthwhile to note that path computation based on certain combinations of
metrics (e.g., delay and jitter) is theoretically hard. Thus, the metrics (e.g., delay and jitter) is theoretically hard. Thus, the
allowable combinations of metrics must be determined taking into account allowable combinations of metrics must be determined while taking into
the complexity of computing paths based on these metrics and the QoS account the complexity of computing paths based on these metrics and the
needs of flows. A common strategy to allow flexible combinations of QoS needs of flows. A common strategy to allow flexible combinations of
metrics while at the same time reduce the path computation complexity is metrics while at the same time reduce the path computation complexity is
to utilize "sequential filtering". Under this approach, a combination of to utilize "sequential filtering". Under this approach, a combination of
metrics is ordered in some fashion, reflecting the importance of metrics is ordered in some fashion, reflecting the importance of
different metrics (e.g., cost followed by delay, etc.). Paths based on different metrics (e.g., cost followed by delay, etc.). Paths based on
the primary metric are computed first (using a simple algorithm, e.g., the primary metric are computed first (using a simple algorithm, e.g.,
shortest path) and a subset of them are eliminated based on the secondary shortest path) and a subset of them are eliminated based on the secondary
metric and so forth until a single path is found. This is an approximation metric and so forth until a single path is found. This is an approximation
technique and it trades off global optimality for path computation technique and it trades off global optimality for path computation
complexity. (The filtering technique may be simpler, depending on the simplicity (The filtering technique may be simpler, depending on the
set of metrics used. For example, with bandwidth and cost as metrics, it set of metrics used. For example, with bandwidth and cost as metrics, it
is possible to first eliminate the set of links that do not have the is possible to first eliminate the set of links that do not have the
requested bandwidth and then compute the least cost path using the requested bandwidth and then compute the least cost path using the
remaining links.) remaining links.)
Now, once suitable link and node metrics are defined, a uniform Now, once suitable link and node metrics are defined, a uniform
representation of them is required across independent domains, employing representation of them is required across independent domains - employing
possibly different routing schemes, in order to derive path metrics possibly different routing schemes - in order to derive path metrics
consistently (path metrics are obtained by the composition of link and consistently (path metrics are obtained by the composition of link and
node metrics). Encoding of the maximum, minimum, range, and granularity node metrics). Encoding of the maximum, minimum, range, and granularity
of the metrics are needed. Also, the definitions of comparison and of the metrics are needed. Also, the definitions of comparison and
accumulation operators are required. In addition, suitable triggers must accumulation operators are required. In addition, suitable triggers must
be defined for indicating a significant change from a minor change. The be defined for indicating a significant change from a minor change. The
former will cause a routing update to be generated. The stability of the former will cause a routing update to be generated. The stability of the
QoS routes would depend on the ability to control the generation of QoS routes would depend on the ability to control the generation of
updates. With interdomain routing, it is essential to obtain a fairly updates. With interdomain routing, it is essential to obtain a fairly
stable view of the interconnection among the ASs. stable view of the interconnection among the ASs.
skipping to change at page 9, line 26 skipping to change at page 9, line 26
situation is not true in the other direction. For example, a datagram situation is not true in the other direction. For example, a datagram
flow cannot affect a real-time service. Thus, it may be necessary to flow cannot affect a real-time service. Thus, it may be necessary to
distribute and update different metrics for each type of service in the distribute and update different metrics for each type of service in the
worst case. But, several advantages result by identifying a single worst case. But, several advantages result by identifying a single
default metric. For example, one could derive a single metric combining default metric. For example, one could derive a single metric combining
the availability of datagram and real-time service over a common the availability of datagram and real-time service over a common
substrate. substrate.
3.6.3 Datagram Flows 3.6.3 Datagram Flows
A delay-sensitive metric is the probably the most obvious type of metric A delay-sensitive metric is probably the most obvious type of metric
suitable for datagram flows. However, it requires careful analysis to suitable for datagram flows. However, it requires careful analysis to
avoid instabilities and to reduce storage and bandwidth requirements. For avoid instabilities and to reduce storage and bandwidth requirements. For
example, we could use a recursive filtering technique that is based on a example, a recursive filtering technique based on a simple and efficient
simple and efficient weighted averaging algorithm [NC94]. This filter is weighted averaging algorithm [NC94] could be used. This filter is
used to stabilize the metric. While it is adequate for smoothing most used to stabilize the metric. While it is adequate for smoothing most
loading patterns, it will not distinguish between patterns consisting of loading patterns, it will not distinguish between patterns consisting of
regular bursts of traffic and random loading. Among other stabilizing regular bursts of traffic and random loading. Among other stabilizing
tools, is a minimum time between updates that can help filter out tools, is a minimum time between updates that can help filter out
high-frequency oscillations. high-frequency oscillations.
3.6.4 Real-time Flows 3.6.4 Real-time Flows
In real-time quality-of-service, delay variation is generally more In real-time quality-of-service, delay variation is generally more
critical than delay as long as the delay is not too high. Clearly, critical than delay as long as the delay is not too high. Clearly,
skipping to change at page 10, line 27 skipping to change at page 10, line 27
capabilities of the link. This requires a uniform method of combining capabilities of the link. This requires a uniform method of combining
features such as delay, bandwidth, priority and other service features. features such as delay, bandwidth, priority and other service features.
Furthermore, the costs must reflect the lost opportunity of using each Furthermore, the costs must reflect the lost opportunity of using each
link after routing the flow. link after routing the flow.
3.6.6 Performance Objectives 3.6.6 Performance Objectives
One common objective during path computation is to improve the total One common objective during path computation is to improve the total
network throughput. In this regard, merely routing a flow on any path network throughput. In this regard, merely routing a flow on any path
that accommodates its QoS requirement is not a good strategy. In fact, that accommodates its QoS requirement is not a good strategy. In fact,
this corresponds to uncontrolled alternate routing and may adversely this corresponds to uncontrolled alternate routing [SD95] and may adversely
impact performance at higher traffic loads. It is therefore necessary impact performance at higher traffic loads. It is therefore necessary
to consider the total resource allocation for a flow along a path, in to consider the total resource allocation for a flow along a path, in
relation to available resources, to determine whether or not the flow relation to available resources, to determine whether or not the flow
should be routed on the path [RSR95]. Such a mechanism is referred to should be routed on the path [RSR95]. Such a mechanism is referred to
in this document as "higher level admission control". The goal of this in this document as "higher level admission control". The goal of this
is to ensure that the "cost" incurred by the network in routing a flow is to ensure that the "cost" incurred by the network in routing a flow
with a given QoS is never more than the revenue gained. The routing with a given QoS is never more than the revenue gained. The routing
cost in this regard may be the lost revenue in potentially blocking other cost in this regard may be the lost revenue in potentially blocking other
flows that contend for the same resources. The formulation of the higher flows that contend for the same resources. The formulation of the higher
level admission control strategy, with suitable administrative hooks and level admission control strategy, with suitable administrative hooks and
skipping to change at page 16, line 32 skipping to change at page 16, line 32
\ / \ /
\ / \ /
____B_____B____ ____B_____B____
| | | |
| | | |
| | | |
| | | |
--------------- ---------------
AS4 AS4
Here, B1 may utlise an AS metric specific for AS1 when computing path Here, B1 may utilize an AS metric specific for AS1 when computing path
metrics to be advertised to AS1. This metric is based on the resources metrics to be advertised to AS1. This metric is based on the resources
engineered in AS2 for transit traffic from AS1. Similarly, B3 may utilize engineered in AS2 for transit traffic from AS1. Similarly, B3 may utilize
a different metric when computing path metrics to be advertised to AS4. a different metric when computing path metrics to be advertised to AS4.
Now, it is assumed that as long as traffic flow into AS2 from AS1 or AS4 Now, it is assumed that as long as traffic flow into AS2 from AS1 or AS4
does not exceed the engineered values, these path metrics would hold. does not exceed the engineered values, these path metrics would hold.
Excess traffic due to transient fluctuations, however, may be handled as Excess traffic due to transient fluctuations, however, may be handled as
best effort or marked with a discard bit. best effort or marked with a discard bit.
Thus, this model is different from the intradomain model, where end nodes Thus, this model is different from the intradomain model, where end nodes
pick a path dynamically based on the QoS needs of the flow to be routed. pick a path dynamically based on the QoS needs of the flow to be routed.
skipping to change at page 19, line 19 skipping to change at page 19, line 19
1. The overheads associated with receiver discovery. This overhead is 1. The overheads associated with receiver discovery. This overhead is
incurred when determining the multicast tree for forwarding incurred when determining the multicast tree for forwarding
best-effort sender traffic characterization to receivers. best-effort sender traffic characterization to receivers.
2. The overheads associated with QoS-based multicast path computation. 2. The overheads associated with QoS-based multicast path computation.
This overhead is incurred when flow-specific state information has This overhead is incurred when flow-specific state information has
to be collected by a router to determine QoS-accommodating paths to to be collected by a router to determine QoS-accommodating paths to
a receiver. a receiver.
Depending on multicast routing scheme, one or both of these aspects Depending on the multicast routing scheme, one or both of these aspects
become important. For instance, under the present RSVP model, become important. For instance, under the present RSVP model,
reservations are established on the same path over which sender traffic reservations are established on the same path over which sender traffic
characterizations are sent, and hence there is no path computation characterizations are sent, and hence there is no path computation
overhead. On the other hand, under the proposed QOSPF model [ZSSC97] of overhead. On the other hand, under the proposed QOSPF model [ZSSC97] of
multicast source routing, receiver discovery overheads are incurred by multicast source routing, receiver discovery overheads are incurred by
MOSPF [M94] receiver location broadcasts, and additional path computation MOSPF [M94] receiver location broadcasts, and additional path computation
overheads are incurred due to the need to keep track of existing flow overheads are incurred due to the need to keep track of existing flow
paths. Scaling of QoS-based multicast depends on both these scaling paths. Scaling of QoS-based multicast depends on both these scaling
issues. However, scalable best-effort multicasting is really not in the issues. However, scalable best-effort multicasting is really not in the
domain of QoS-based routing work (solutions for this are being devised domain of QoS-based routing work (solutions for this are being devised
skipping to change at page 27, line 24 skipping to change at page 27, line 29
Control in High-Speed Integrated Networks," Proceedings of Control in High-Speed Integrated Networks," Proceedings of
ITC-13, pp. 397-403, 1992. ITC-13, pp. 397-403, 1992.
[B82] D. P. Bertsekas, "Dynamic Behavior of Shortest Path Routing [B82] D. P. Bertsekas, "Dynamic Behavior of Shortest Path Routing
Algorithms for Communication Networks," IEEE Trans. Auto. Algorithms for Communication Networks," IEEE Trans. Auto.
Control, pp. 60-74, 1982. Control, pp. 60-74, 1982.
[B85] A. E. Baratz, "SNA Networks of Small Systems", IEEE JSAC, May, [B85] A. E. Baratz, "SNA Networks of Small Systems", IEEE JSAC, May,
1985. 1985.
[BBCD98] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and W. Weiss,
"An Architecture for Differentiated Services," work in progress,
May, 1998.
[BCF94] A. Ballardie, J. Crowcroft and P. Francis, "Core-Based Trees: A [BCF94] A. Ballardie, J. Crowcroft and P. Francis, "Core-Based Trees: A
Scalable Multicast Routing Protocol," Proceedings of SIGCOMM `94. Scalable Multicast Routing Protocol," Proceedings of SIGCOMM `94.
[BCS94] R. Braden, D. Clark, and S. Shenker, "Integrated Services in the [BCS94] R. Braden, D. Clark, and S. Shenker, "Integrated Services in the
Internet Architecture: An Overview," RFC 1633, July, 1994. Internet Architecture: An Overview," RFC 1633, July, 1994.
[BZ92] S. Bahk and M. El Zarki, "Dynamic Multi-Path Routing and How it [BZ92] S. Bahk and M. El Zarki, "Dynamic Multi-Path Routing and How it
Compares with Other Dynamic Routing Algorithms for High Speed Compares with Other Dynamic Routing Algorithms for High Speed
Wide Area Networks," Proc. SIGCOMM `92, pp. 53-64, 1992. Wide Area Networks," Proc. SIGCOMM `92, pp. 53-64, 1992.
skipping to change at page 28, line 5 skipping to change at page 28, line 9
1994. 1994.
[ELRV96] D. Estrin, T. Li, Y. Rekhter, K. Varadhan, and D. Zappala, [ELRV96] D. Estrin, T. Li, Y. Rekhter, K. Varadhan, and D. Zappala,
"Source Demand Routing: Packet Format and Forwarding Spec. "Source Demand Routing: Packet Format and Forwarding Spec.
(Version 1)," RFC 1940, May, 1996. (Version 1)," RFC 1940, May, 1996.
[GKR96] R. Gawlick, C. R. Kalmanek, and K. G. Ramakrishnan, "On-Line [GKR96] R. Gawlick, C. R. Kalmanek, and K. G. Ramakrishnan, "On-Line
Routing of Permanent Virtual Circuits," Computer Communications, Routing of Permanent Virtual Circuits," Computer Communications,
March, 1996. March, 1996.
[GSSS97] A. Ghanvani, V. Srinivasan, A. Smith and M. Seaman, "A Framework [GPSS98] A. Ghanwani, J. W. Pace, V. Srinivasan, A. Smith and M. Seaman,
for Providing Integrated Services over Shared and Switched IEEE "A Framework for Providing Integrated Services over Shared and
802 LAN Technologies," Internet Draft, Switched IEEE 802 LAN Technologies," work in progress, March,
draft-ietf-issll-is802-framework-04.txt, November, 1997. 1998.
[GM79] J. P. Gray, T. B. McNeil, "SNA Multi-System Networking," IBM [GM79] J. P. Gray, T. B. McNeil, "SNA Multi-System Networking," IBM
Systems Journal, 18 No. 2, pp. 263-297, 1979. Systems Journal, 18 No. 2, pp. 263-297, 1979.
[GOA97] Y. Goto, M. Ohta and K. Araki, "Path QoS Collection for Stable [GOA97] Y. Goto, M. Ohta and K. Araki, "Path QoS Collection for Stable
Hop-by-Hop QoS Routing," Proc. INET '97, June, 1997. Hop-by-Hop QoS Routing," Proc. INET '97, June, 1997.
[GKOP98] R. Guerin, S. Kamat, A. Orda, T. Przygienda, and D. Williams, [GKOP98] R. Guerin, S. Kamat, A. Orda, T. Przygienda, and D. Williams,
"QoS Routing Mechanisms and OSPF extensions," Internet Draft, "QoS Routing Mechanisms and OSPF extensions," work in
draft-guerin-qos-routing-ospf-03.txt, March, 1998. progress, March, 1998.
[IBM97] IBM Corp, SNA APPN - High Performance Routing Architecture [IBM97] IBM Corp, SNA APPN - High Performance Routing Architecture
Reference, Version 2.0, SV40-1018, February 1997. Reference, Version 2.0, SV40-1018, February 1997.
[IPNNI] ATM Forum Technical Committee. Integrated PNNI (I-PNNI) v1.0 [IPNNI] ATM Forum Technical Committee. Integrated PNNI (I-PNNI) v1.0
Specification. af-96-0987r1, September 1996. Specification. af-96-0987r1, September 1996.
[ISI81] USC-ISI, "Internet Protocol," RFC 791, September, 1981 [ISI81] USC-ISI, "Internet Protocol," RFC 791, September, 1981
[JMW83] J. M. Jaffe, F. H. Moss, R. A. Weingarten, "SNA Routing: Past, [JMW83] J. M. Jaffe, F. H. Moss, R. A. Weingarten, "SNA Routing: Past,
skipping to change at page 30, line 14 skipping to change at page 30, line 18
[YS87] T. G. Yum and M. Schwartz, "Comparison of Routing Procedures for [YS87] T. G. Yum and M. Schwartz, "Comparison of Routing Procedures for
Circuit-Switched Traffic in Nonhierarchical Networks," IEEE Circuit-Switched Traffic in Nonhierarchical Networks," IEEE
Trans. Communications, pp. 535-544, May, 1987. Trans. Communications, pp. 535-544, May, 1987.
[ZES97] Zappala, D., Estrin, D., Shenker, S. "Alternate Path Routing [ZES97] Zappala, D., Estrin, D., Shenker, S. "Alternate Path Routing
and Pinning for Interdomain Multicast Routing", USC Computer and Pinning for Interdomain Multicast Routing", USC Computer
Science Technical Report #97-655, USC, 1997. Science Technical Report #97-655, USC, 1997.
[ZSSC97] Z. Zhang, C. Sanchez, B. Salkewicz, and E. Crawley, "QoS [ZSSC97] Z. Zhang, C. Sanchez, B. Salkewicz, and E. Crawley, "QoS
Extensions to OSPF," Internet Draft, draft-zhang-qos-ospf-01.txt, Extensions to OSPF," work in progress, September, 1997.
September, 1997.
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Bala Rajagopalan Raj Nair Bala Rajagopalan Raj Nair
NEC USA, C&C Research Labs Arrowpoint NEC USA, C&C Research Labs Arrowpoint
4 Independence Way 235 Littleton Rd. 4 Independence Way 235 Littleton Rd.
Princeton, NJ 08540 Westford, MA 01886 Princeton, NJ 08540 Westford, MA 01886
U.S.A U.S.A U.S.A U.S.A
Ph: +1-609-951-2969 Ph: +1-508-692-5875, x29 Ph: +1-609-951-2969 Ph: +1-508-692-5875, x29
Email: braja@ccrl.nj.nec.com Email: nair@arrowpoint.com Email: braja@ccrl.nj.nec.com Email: nair@arrowpoint.com
Hal Sandick Eric S. Crawley Hal Sandick Eric S. Crawley
Bay Networks, Inc. Argon Networks, Inc. Bay Networks, Inc. Argon Networks, Inc.
1009 Slater Rd., Suite 220 25 Porter Rd. 1009 Slater Rd., Suite 220 25 Porter Rd.
Durham, NC 27703 Littelton, MA 01460 Durham, NC 27703 Littelton, MA 01460
U.S.A U.S.A U.S.A U.S.A
Ph: +1-919-941-1739 Ph: +1-508-486-0665 Ph: +1-919-941-1739 Ph: +1-508-486-0665
Email: Hsandick@baynetworks.com Email: esc@argon.com Email: Hsandick@baynetworks.com Email: esc@argon.com
***** This draft expires on October, 10, 1998 ***** ***** This draft expires on October, 27, 1998 *****
 End of changes. 36 change blocks. 
108 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/