computation. This overhead is incurred when flow-specific
state information has to be collected by a router to determine
QoS-accommodating paths to a receiver.
Depending on the multicast routing scheme, one or both of these
aspects become important. For instance, under the present RSVP model,
reservations are established on the same path over which sender
traffic characterizations are sent, and hence there is no path
computation overhead. On the other hand, under the proposed QOSPF
model [ZSSC97] of multicast source routing, receiver discovery
overheads are incurred by MOSPF [M94] receiver location broadcasts,
and additional path computation overheads are incurred due to the
need to keep track of existing flow paths. Scaling of QoS-based
multicast depends on both these scaling issues. However, scalable
best-effort multicasting is really not in the domain of QoS-based
routing work (solutions for this are being devised by the IDMR WG
[BCF94, DEFV94]). QoS-based multicast routing may build on these
solutions to achieve overall scalability.
There are several options for QoS-based multicast routing. Multicast
source routing is one under which multicast trees are computed by the
first-hop router from the source, based on sender traffic
advertisements. The advantage of this is that it blends nicely with
the present RSVP signaling model. Also, this scheme works well when
receiver reservations are homogeneous and the same as the maximum
reservation derived from sender advertisement. The disadvantages of
this scheme are the extra effort needed to accommodate heterogeneous
reservations and the difficulties in optimizing resource allocation
based on shared reservations.
In these regards, a receiver-oriented multicast routing model seems
to have some advantage over multicast source routing. Under this
model:
1. Sender traffic advertisements are multicast over a best-effort
tree which can be different from the QoS-accommodating tree for
sender data.
2. Receiver discovery overheads are minimized by utilizing a
scalable scheme (e.g., PIM, CBT), to multicast sender traffic
characterization.
3. Each receiver-side router independently computes a QoS-
accommodating path from the source, based on the receiver
reservation. This path can be computed based on unicast routing
information only, or with additional multicast flow-specific
state information. In any case, multicast path computation is
broken up into multiple, concurrent nunicast path computations.
4. Routers processing unicast reserve messages from receivers
aggregate resource reservations from multiple receivers.
Flow-specific state information may be limited in Step 3 to achieve
scalability [RN98]. In general, limiting flow-specific information in
making multicast routing decisions is important in any routing model.
The advantages of this model are the ease with which heterogeneous
reservations can be accommodated, and the ability to handle shared
reservations. The disadvantages are the incompatibility with the
present RSVP signaling model, and the need to rely on reverse paths
when link state routing is not used. Both multicast source routing
and the receiver-oriented routing model described above utilize per-
source trees to route multicast flows. Another possibility is the
utilization of shared, per-group trees for routing flows. The
computation and usage of such trees require further work.
Finally, scalability at the interdomain level may be achieved if
QoS-based multicast paths are computed independently in each domain.
This principle is illustrated by the QOSPF multicast source routing
scheme which allows independent path computation in different OSPF
areas. It is easy to incorporate this idea in the receiver-oriented
model also. An evaluation of multicast routing strategies must take
into account the relative advantages and disadvantages of various
approaches, in terms of scalability features and functionality
supported.
6.2 Multicast Admission Control
Higher level admission control, as defined for unicast, prevents
excessive resource consumption by flows when traffic load is high.
Such an admission control strategy must be applied to multicast flows
when the flow path computation is receiver-oriented or sender-
oriented. In essence, a router computing a path for a receiver must
determine whether the incremental resource allocation for the
receiver is excessive under some administratively determined
admission control policy. Other admission control criteria, based on
the total resource consumption of a tree may be defined.
7. QOS-BASED ROUTING AND RESOURCE RESERVATION PROTOCOLS
There must clearly be a well-defined interface between routing and
resource reservation protocols. The nature of this interface, and the
interaction between routing and resource reservation has to be
determined carefully to avoid incompatibilities. The importance of
this can be readily illustrated in the case of RSVP.
RSVP has been designed to operate independent of the underlying
routing scheme. Under this model, RSVP PATH messages establish the
reverse path for RESV messages. In essence, this model is not
compatible with QoS-based routing schemes that compute paths after
receiver reservations are received. While this incompatibility can be
resolved in a simple manner for unicast flows, multicast with
heterogeneous receiver requirements is a more difficult case. For
this, reconciliation between RSVP and QoS-based routing models is
necessary. Such a reconciliation, however, may require some changes
to the RSVP model depending on the QoS-based routing model [ZES97,
ZSSC97, GOA97]. On the other hand, QoS-based routing schemes may be
designed with RSVP compatibility as a necessary goal. How this
affects scalability and other performance measures must be
considered.
8. SECURITY CONSIDERATIONS
Security issues that arise with routing in general are about
maintaining the integrity of the routing protocol in the presence of
unintentional or malicious introduction of information that may lead
to protocol failure [P88]. QoS-based routing requires additional
security measures both to validate QoS requests for flows and to
prevent resource-depletion type of threats that can arise when flows
are allowed to make arbitratry resource requests along various paths
in the network. Excessive resource consumption by an errant flow
results in denial of resources to legitimate flows. While these
situations may be prevented by setting up proper policy constraints,
charging models and policing at various points in the network, the
formalization of such protection requires work [BCCH94].
9. RELATED WORK
"Adaptive" routing, based on network state, has a long history,
especially in circuit-switched networks. Such routing has also been
implemented in early datagram and virtual circuit packet networks.
More recently, this type of routing has been the subject of study in
the context of ATM networks, where the traffic characteristics and
topology are substantially different from those of circuit-switched
networks [MMR96]. It is instructive to review the adaptive routing
methodologies, both to understand the problems encountered and
possible solutions.
Fundamentally, there are two aspects to adaptive, network state-
dependent routing:
1. Measuring and gathering network state information, and
2. Computing routes based on the available information.
Depending on how these two steps are implemented, a variety of
routing techniques are possible. These differ in the following
respects:
- what state information is used
- whether local or global state is used
- what triggers the propagation of state information
- whether routes are computed in a distributed or centralized manner
- whether routes are computed on-demand, pre-computed, or in a
hybrid manner
- what optimization criteria, if any, are used in computing routes
- whether source routing or hop by hop routing is used, and
- how alternate route choices are explored
It should be noted that most of the adaptive routing work has focused
on unicast routing. Multicast routing is one of the areas that would
be prominent with Internet QoS-based routing. We treat this
separately, and the following review considers only unicast routing.
This review is not exhaustive, but gives a brief overview of some of
the approaches.
9.1 Optimization Criteria
The most common optimization criteria used in adaptive routing is
throughput maximization or delay minimization. A general formulation
of the optimization problem is the one in which the network revenue
is maximized, given that there is a cost associated with routing a
flow over a given path [MMR96, K88]. In general, global optimization
solutions are difficult to implement, and they rely on a number of
assumptions on the characteristics of the traffic being routed
[MMR96]. Thus, the practical approach has been to treat the routing
of each flow (VC, circuit or packet stream to a given destination)
independently of the routing of other flows. Many such routing
schemes have been implemented.
9.2 Circuit Switched Networks
Many adaptive routing concepts have been proposed for circuit-
switched networks. An example of a simple adaptive routing scheme is
sequential alternate routing [T88]. This is a hop-by-hop
destination-based routing scheme where only local state information
is utilized. Under this scheme, a routing table is computed for each
node, which lists multiple output link choices for each destination.
When a call set-up request is received by a node, it tries each
output link choice in sequence, until it finds one that can
accommodate the call. Resources are reserved on this link, and the
call set-up is forwarded to the next node. The set-up either reaches
the destination, or is blocked at some node. In the latter case, the
set-up can be cranked back to the previous node or a failure
declared. Crankback allows the previous node to try an alternate
path. The routing table under this scheme can be computed in a
centralized or distributed manner, based only on the topology of the
network. For instance, a k-shortest-path algorithm can be used to
determine k alternate paths from a node with distinct initial links
[T88]. Some mechanism must be implemented during path computation or
call set-up to prevent looping.
Performance studies of this scheme illustrate some of the pitfalls of
alternate routing in general, and crankback in particular [A84, M86,
YS87]. Specifically, alternate routing improves the throughput when
traffic load is relatively light, but adversely affects the
performance when traffic load is heavy. Crankback could further
degrade the performance under these conditions. In general,
uncontrolled alternate routing (with or without crankback) can be
harmful in a heavily utilized network, since circuits tend to be
routed along longer paths thereby utilizing more capacity. This is an
obvious, but important result that applies to QoS-based Internet
routing also.
The problem with alternate routing is that both direct routed (i.e.,
over shortest paths) and alternate routed calls compete for the same
resource. At higher loads, allocating these resources to alternate
routed calls result in the displacement of direct routed calls and
hence the alternate routing of these calls. Therefore, many
approaches have been proposed to limit the flow of alternate routed
calls under high traffic loads. These schemes are designed for the
fully-connected logical topology of long distance telephone networks
(i.e., there is a logical link between every pair of nodes). In this
topology, direct routed calls always traverse a 1-hop path to the
destination and alternate routed calls traverse at most a 2-hop path.
"Trunk reservation" is a scheme whereby on each link a certain
bandwidth is reserved for direct routed calls [MS91]. Alternate
routed calls are allowed on a trunk as long as the remaining trunk
bandwidth is greater than the reserved capacity. Thus, alternate
routed calls cannot totally displace direct routed calls on a trunk.
This strategy has been shown to be very effective in preventing the
adverse effects of alternate routing.
"Dynamic alternate routing" (DAR) is a strategy whereby alternate
routing is controlled by limiting the number of choices, in addition
to trunk reservation [MS91]. Under DAR, the source first attempts to
use the direct link to the destination. When blocked, the source
attempts to alternate route the call via a pre-selected neighbor. If
the call is still blocked, a different neighbor is selected for
alternate routing to this destination in the future. The present call
is dropped. DAR thus requires only local state information. Also, it
"learns" of good alternate paths by random sampling and sticks to
them as long as possible.
More recent circuit-switched routing schemes utilize global state to
select routes for calls. An example is AT&T's Real-Time Network
Routing (RTNR) scheme [ACFH92]. Unlike schemes like DAR, RTNR handles
multiple classes of service, including voice and data at fixed rates.
RTNR utilizes a sophisticated per-class trunk reservation mechanism
with dynamic bandwidth sharing between classes. Also, when alternate
routing a call, RTNR utilizes the loading on all trunks in the
network to select a path. Because of the fully-connected topology,
disseminating status information is simple under RTNR; each node
simply exchanges status information directly with all others.
From the point of view of designing QoS-based Internet routing
schemes, there is much to be learned from circuit-switched routing.
For example, alternate routing and its control, and dynamic resource
sharing among different classes of traffic. It is, however, not
simple to apply some of the results to a general topology network
with heterogeneous multirate traffic. Work in the area of ATM network
routing described next illustrates this.
9.3 ATM Networks
The VC routing problem in ATM networks presents issues similar to
that encountered in circuit-switched networks. Not surprisingly, some
extensions of circuit-switched routing have been proposed. The goal
of these routing schemes is to achieve higher throughput as compared
to traditional shortest-path routing. The flows considered usually
have a single QoS requirement, i.e., bandwidth.
The first idea is to extend alternate routing with trunk reservation
to general topologies [SD95]. Under this scheme, a distance vector
routing protocol is used to build routing tables at each node with
multiple choices of increasing hop count to each destination. A VC
set-up is first routed along the primary ("direct") path. If
sufficient resources are not available along this path, alternate
paths are tried in the order of increasing hop count. A flag in the
VC set-up message indicates primary or alternate routing, and
bandwidth on links along an alternate path is allocated subject to
trunk reservation. The trunk reservation values are determined based
on some assumptions on traffic characteristics. Because the scheme
works only for a single data rate, the practical utility of it is
limited.
The next idea is to import the notion of controlled alternate routing
into traditional link state QoS-based routing [GKR96]. To do this,
first each VC is associated with a maximum permissible routing cost.
This cost can be set based on expected revenues in carrying the VC or
simply based on the length of the shortest path to the destination.
Each link is associated with a metric that increases exponentially
with its utilization. A switch computing a path for a VC simply
determines a least-cost feasible path based on the link metric and
the VC's QoS requirement. The VC is admitted if the cost of the path
is less than or equal to the maximum permissible routing cost. This
routing scheme thus limits the extent of "detour" a VC experiences,
thus preventing excessive resource consumption. This is a practical
scheme and the basic idea can be extended to hierarchical routing.
But the performance of this scheme has not been analyzed thoroughly.
A similar notion of admission control based on the connection route
was also incorporated in a routing scheme presented in [ACG92].
Considering the ATM Forum PNNI protocol [PNNI96], a partial list of
its stated characteristics are as follows:
o Scales to very large networks
o Supports hierarchical routing
o Supports QoS
o Uses source routed connection setup
o Supports multiple metrics and attributes
o Provides dynamic routing
The PNNI specification is sub-divided into two protocols: a signaling
and a routing protocol. The PNNI signaling protocol is used to
establish point-to-point and point to multipoint connections and
supports source routing, crankback and alternate routing. PNNI source
routing allows loop free paths. Also, it allows each implementation
to use its own path computation algorithm. Furthermore, source
routing is expected to support incremental deployment of future
enhancements such as policy routing.
The PNNI routing protocol is a dynamic, hierarchical link state
protocol that propagates topology information by flooding it through
the network. The topology information is the set of resources (e.g.,
nodes, links and addresses) which define the network. Resources are
qualified by defined sets of metrics and attributes (delay, available
bandwidth, jitter, etc.) which are grouped by supported traffic
class. Since some of the metrics used will change frequently, e.g.,
available bandwidth, threshold algorithms are used to determine if
the change in a metric or attribute is significant enough to require
propagation of updated information. Other features include, auto
configuration of the routing hierarchy, connection admission control
(as part of path calculation) and aggregation and summarization of
topology and reachability information.
Despite its functionality, the PNNI routing protocol does not address
the issues of multicast routing, policy routing and control of
alternate routing. A problem in general with link state QoS-based
routing is that of efficient broadcasting of state information. While
flooding is a reasonable choice with static link metrics it may
impact the performance adversely with dynamic metrics.
Finally, Integrated PNNI [I-PNNI] has been designed from the start to
take advantage of the QoS Routing capabilities that are available in
PNNI and integrate them with routing for layer 3. This would provide
an integrated layer 2 and layer 3 routing protocol for networks that
include PNNI in the ATM core. The I-PNNI specification has been
under development in the ATM Forum and, at this time, has not yet
incorporated QoS routing mechanisms for layer 3.
9.4 Packet Networks
Early attempts at adaptive routing in packet networks had the
objective of delay minimization by dynamically adapting to network
congestion. Alternate routing based on k-shortest path tables, with
route selection based on some local measure (e.g., shortest output
queue) has been described [R76, YS81]. The original ARPAnet routing
scheme was a distance vector protocol with delay-based cost metric
[MW77]. Such a scheme was shown to be prone to route oscillations
[B82]. For this and other reasons, a link state delay-based routing
scheme was later developed for the ARPAnet [MRR80]. This scheme
demonstrated a number of techniques such as triggered updates,
flooding, etc., which are being used in OSPF and PNNI routing today.
Although none of these schemes can be called QoS-based routing
schemes, they had features that are relevant to QoS-based routing.
IBM's System Network Architecture (SNA) introduced the concept of
Class of Service (COS)-based routing [A79, GM79]. There were several
classes of service: interactive, batch, and network control. In
addition, users could define other classes. When starting a data
session an application or device would request a COS. Routing would
then map the COS into a statically configured route which marked a
path across the physical network. Since SNA is connection oriented,
a session was set up along this path and the application's or
device's data would traverse this path for the life of the session.
Initially, the service delivered to a session was based on the
network engineering and current state of network congestion. Later,
transmission priority was added to subarea SNA. Transmission
priority allowed more important traffic (e.g. interactive) to proceed
before less time-critical traffic (e.g. batch) and improved link and
network utilization. Transmission priority of a session was based on
its COS.
SNA later evolved to support multiple or alternate paths between
nodes. But, although assisted by network design tools, the network
administrator still had to statically configure routes. IBM later
introduced SNA's Advanced Peer to Peer Networking (APPN) [B85]. APPN
added new features to SNA including dynamic routing based on a link
state database. An application would use COS to indicate it traffic
requirements and APPN would calculate a path capable of meeting these
requirements. Each COS was mapped to a table of acceptable metrics
and parameters that qualified the nodes and links contained in the
APPN topology Database. Metrics and parameters used as part of the
APPN route calculation include, but are not limited to: delay, cost
per minute, node congestion and security. The dynamic nature of APPN
allowed it to route around failures and reduce network configuration.
The service delivered by APPN was still based on the network
engineering, transmission priority and network congestion. IBM later
introduced an extension to APPN, High Performance Routing
(HPR)[IBM97]. HPR uses a congestion avoidance algorithm called
adaptive rate based (ARB) congestion control. Using predictive
feedback methods, the ARB algorithm prevents congestion and improves
network utilization. Most recently, an extension to the COS table
has been defined so that HPR routing could recognize and take
advantage of ATM QoS capabilities.
Considering IP routing, both IDRP [R92] and OSPF support type of
service (TOS)-based routing. While the IP header has a TOS field,
there is no standardized way of utilizing it for TOS specification
and routing. It seems possible to make use of the IP TOS feature,
along with TOS-based routing and proper network engineering, to do
QoS-based routing. The emerging differentiated services model is
generating renewed interest in TOS support. Among the newer schemes,
Source Demand Routing (SDR) [ELRV96] allows on-demand path
computation by routers and the implementation of strict and loose
source routing. The Nimrod architecture [CCM96] has a number of
concepts built in to handle scalability and specialized path
computation. Recently, some work has been done on QoS-based routing
schemes for the integrated services Internet. For example, in [M98],
heuristic schemes for efficient routing of flows with bandwidth
and/or delay constraints is described and evaluated.
9. SUMMARY AND CONCLUSIONS
In this document, a framework for QoS-based Internet routing was
defined. This framework adopts the traditional separation between
intra and interdomain routing. This approach is especially meaningful
in the case of QoS-based routing, since there are many views on how
QoS-based routing should be accomplished and many different needs.
The objective of this document was to encourage the development of
different solution approaches for intradomain routing, subject to
some broad requirements, while consensus on interdomain routing is
achieved. To this end, the QoS-based routing issues were described,
and some broad intradomain routing requirements and an interdomain
routing model were defined. In addition, QoS-based multicast routing
was discussed and a detailed review of related work was presented.
The deployment of QoS-based routing across multiple administrative
domains requires both the development of intradomain routing schemes
and a standard way for them to interact via a well-defined
interdomain routing mechanism. This document, while outlining the
issues that must be addressed, did not engage in the specification of
the actual features of the interdomain routing scheme. This would be
the next step in the evolution of wide-area, multidomain QoS-based
routing.
REFERENCES
[A79] V. Ahuja, "Routing and Flow Control in SNA", IBM Systems
Journal, 18 No. 2, pp. 298-314, 1979.
[A84] J. M. Akinpelu, "The Overload Performance of Engineered
Networks with Non-Hierarchical Routing", AT&T Technical
Journal, Vol. 63, pp. 1261-1281, 1984.
[ACFH92] G. R. Ash, J. S. Chen, A. E. Frey and B. D. Huang, "RealTime
Network Routing in a Dynamic Class-of-Service Network",
Proceedings of ITC 13, 1992.
[ACG92] H. Ahmadi, J. Chen, and R. Guerin, "Dynamic Routing and Call
Control in High-Speed Integrated Networks", Proceedings of
ITC-13, pp. 397-403, 1992.
[B82] D. P. Bertsekas, "Dynamic Behavior of Shortest Path Routing
Algorithms for Communication Networks", IEEE Trans. Auto.
Control, pp. 60-74, 1982.
[B85] A. E. Baratz, "SNA Networks of Small Systems", IEEE JSAC,
May, 1985.
[BBCD98] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z., and
W. Weiss, "An Architecture for Differentiated Services",
Work in Progress.
[BCCH94] Braden, R., Clark, D., Crocker, D., and C. Huitema, "Report
of IAB Workshop on Security in the Internet Architecture",
RFC1636, June 1994.
[BCF94] A. Ballardie, J. Crowcroft and P. Francis, "Core-Based
Trees: A Scalable Multicast Routing Protocol", Proceedings
of SIGCOMM `94.
[BCS94] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: An Overview", RFC1633, July
1994.
[BZ92] S. Bahk and M. El Zarki, "Dynamic Multi-Path Routing and How
it Compares with Other Dynamic Routing Algorithms for High
Speed Wide Area Networks", Proc. SIGCOMM `92, pp. 53-64,
1992.
[BZBH97] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Spec", RFC2205, September 1997.
[C91] C-H. Chow, "On Multicast Path Finding Algorithms",
Proceedings of the IEEE INFOCOM `91, pp. 1274-1283, 1991.
[CCM96] Castineyra, I., Chiappa, J., and M. Steenstrup, "The Nimrod
Routing Architecture", RFC1992, August 1996.
[DEFV94] S. E. Deering, D. Estrin, D. Farinnacci, V. Jacobson, C-G.
Liu, and L. Wei, "An Architecture for Wide-Area Multicast
Routing", Technical Report, 94-565, ISI, University of
Southern California, 1994.
[ELRV96] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
Zappala, "Source Demand Routing: Packet Format and
Forwarding Specification (Version 1)", RFC1940, May 1996.
[GKR96] R. Gawlick, C. R. Kalmanek, and K. G. Ramakrishnan, "On-Line
Routing of Permanent Virtual Circuits", Computer
Communications, March, 1996.
[GPSS98] A. Ghanwani, J. W. Pace, V. Srinivasan, A. Smith and M.
Seaman, "A Framework for Providing Integrated Services over
Shared and Switched IEEE 802 LAN Technologies", Work in
Progress.
[GM79] J. P. Gray, T. B. McNeil, "SNA Multi-System Networking", IBM
Systems Journal, 18 No. 2, pp. 263-297, 1979.
[GOA97] Y. Goto, M. Ohta and K. Araki, "Path QoS Collection for
Stable Hop-by-Hop QoS Routing", Proc. INET '97, June, 1997.
[GKOP98] R. Guerin, S. Kamat, A. Orda, T. Przygienda, and D.
Williams, "QoS Routing Mechanisms and OSPF extensions", work
in progress, March, 1998.
[IBM97] IBM Corp, SNA APPN - High Performance Routing Architecture
Reference, Version 2.0, SV40-1018, February 1997.
[IPNNI] ATM Forum Technical Committee. Integrated PNNI (I-PNNI) v1.0
Specification. af-96-0987r1, September 1996.
[ISI81] Postel, J., "Internet Protocol", STD 5, RFC791, September
1981.
[JMW83] J. M. Jaffe, F. H. Moss, R. A. Weingarten, "SNA Routing:
Past, Present, and Possible Future", IBM Systems Journal,
pp. 417-435, 1983.
[K88] F.P. Kelly, "Routing in Circuit-Switched Networks:
Optimization, Shadow Prices and Decentralization", Adv.
Applied Prob., pp. 112-144, March, 1988.
[L95] W. C. Lee, "Topology Aggregation for Hierarchical Routing in
ATM Networks", ACM SIGCOMM Computer Communication Review,
1995.
[M86] L. G. Mason, "On the Stability of Circuit-Switched Networks
with Non-hierarchical Routing", Proc. 25th Conf. On Decision
and Control, pp. 1345-1347, 1986.
[M98] Moy, J., "OSPF Version 2", STD 54, RFC2328, April 1998.
[M94] Moy, J., "MOSPF: Analysis and Experience", RFC1585, March
1994.
[M98] Q. Ma, "Quality-of-Service Routing in Integrated Services
Networks", PhD thesis, Computer Science Department, Carnegie
Mellon University, 1998.
[MMR96] D. Mitra, J. Morrison, and K. G. Ramakrishnan, "ATM Network
Design and Optimization: A Multirate Loss Network
Framework", Proceedings of IEEE INFOCOM `96, 1996.
[MRR80] J. M. McQuillan, I. Richer and E. C. Rosen, "The New Routing
Algorithm for the ARPANET", IEEE Trans. Communications, pp.
711-719, May, 1980.
[MS91] D. Mitra and J. B. Seery, "Comparative Evaluations of
Randomized and Dynamic Routing Strategies for Circuit
Switched Networks", IEEE Trans. on Communications, pp. 102-
116, January, 1991.
[MW77] J. M. McQuillan and D. C. Walden, "The ARPANET Design
Decisions", Computer Networks, August, 1977.
[NC94] Nair, R. and Clemmensen, D. : "Routing in Integrated
Services Networks", Proc. 2nd International Conference on
Telecom. Systems Modeling and Analysis, March 1994.
[P88] R. Perlman, "Network Layer Protocol with Byzantine
Robustness", Ph.D. Thesis, Dept. of EE and CS, MIT, August,
1988.
[PNNI96] ATM Forum PNNI subworking group, "Private Network-Network
Interface Spec. v1.0 (PNNI 1.0)", afpnni-0055.00, March
1996.
[R76] H. Rudin, "On Routing and "Delta Routing": A Taxonomy and
Performance Comparison of Techniques for Packet-Switched
Networks", IEEE Trans. Communications, pp. 43-59, January,
1996.
[R92] Y. Rekhter, "IDRP Protocol Analysis: Storage Overhead", ACM
Comp. Comm. Review, April, 1992.
[R96] B. Rajagopalan, "Efficient Link State Routing", Work in
Progress, available from braja@ccrl.nj.nec.com.
[RN98] B. Rajagopalan and R. Nair, "Multicast Routing with Resource
Reservation", to appear in J. of High Speed Networks, 1998.
[SD95] S. Sibal and A. Desimone, "Controlling Alternate Routing in
General-Mesh Packet Flow Networks", Proceedings of ACM
SIGCOMM, 1995.
[SPG97] Shenker, S., Partridge, C., and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC2212, September 1997.
[T88] D. M. Topkis, "A k-Shortest-Path Algorithm for Adaptive
Routing in Communications Networks", IEEE Trans.
Communications, pp. 855-859, July, 1988.
[W88] B. M. Waxman, "Routing of Multipoint Connections", IEEE
JSAC, pp. 1617-1622, December, 1988.
[W97] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC2211, September 1997.
[WC96] Z. Wang and J. Crowcroft, "QoS Routing for Supporting
Resource Reservation", IEEE JSAC, September, 1996.
[YS81] T. P. Yum and M. Schwartz, "The Join-Based Queue Rule and
its Application to Routing in Computer Communications
Networks", IEEE Trans. Communications, pp. 505-511, 1981.
[YS87] T. G. Yum and M. Schwartz, "Comparison of Routing Procedures
for Circuit-Switched Traffic in Nonhierarchical Networks",
IEEE Trans. Communications, pp. 535-544, May, 1987.
[ZES97] Zappala, D., Estrin, D., and S. Shenker, "Alternate Path
Routing and Pinning for Interdomain Multicast Routing", USC
Computer Science Technical Report #97-655, USC, 1997.
[ZSSC97] Zhang, Z., Sanchez, C., Salkewicz, B., and E. Crawley, "QoS
Extensions to OSPF", Work in Progress.
AUTHORS' ADDRESSES
Bala Rajagopalan
NEC USA, C&C Research Labs
4 Independence Way
Princeton, NJ 08540
U.S.A
Phone: +1-609-951-2969
EMail: braja@ccrl.nj.nec.com
Raj Nair
Arrowpoint
235 Littleton Rd.
Westford, MA 01886
U.S.A
Phone: +1-508-692-5875, x29
EMail: nair@arrowpoint.com
Hal Sandick
Bay Networks, Inc.
1009 Slater Rd., Suite 220
Durham, NC 27703
U.S.A
Phone: +1-919-941-1739
EMail: Hsandick@baynetworks.com
Eric S. Crawley
Argon Networks, Inc.
25 Porter Rd.
Littelton, MA 01460
U.S.A
Phone: +1-508-486-0665
EMail: esc@argon.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.