Internet DRAFT - draft-bergkvist-boomerang-framework
draft-bergkvist-boomerang-framework
Network Working Group J. Bergkvist, Telia Research
INTERNET-DRAFT I. Cselenyi, Telia Research
Expiration Date: May 2001 D. Ahlard, Telia Research
November 2000
Boomerang - A Simple Resource Reservation Framework for IP
<draft-bergkvist-boomerang-framework-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft shadow directories can be accessed at
http://www.ietf.org/shadow.html
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This draft describes a framework for providing quantitative IP
services with guaranteed QoS. The proposed reservation approach is
based on a new, lightweight signaling protocol and it suits both
Diff-Serv, Int-Serv QoS architectures.
The main designing principle of the Boomerang protocol is to make
reservation almost as simple as forwarding an ordinary packet. Thus:
* Signaling messages are generated only by the initiating node,
therefore complexity and intelligence is concentrated in one point
enabling simple implementation
* Flow state aggregation can be suggested to subsequent nodes by
appending the Boomerang message
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 1]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
* Bi-directional reservation can be made by a single message loop
independently of the path, which yields fast and effective
reservation setup
* The only requirement on the far-end node is that it should be able
to bounce the Boomerang message back, thus it works where Ping
works.
According to actual measurements, a Linux-based Boomerang-aware
router can handle more than 120 000 concurrent reservation sessions
and up to 6800 reservation requests per second, while the impact on
data forwarding performance is negligible.
1. Terminology
The terminology given in [E2E] is used in this document extended with
the following notions:
Boomerang Protocol (BOOMP)
The simple, hop-by-hop resource reservation protocol used in this
framework.
Initiating Node (IN)
This is the node that initiates the resource reservation. Can be the
sender or receiver of data traffic or any BOOMP-aware network node.
Far-End Node (FEN)
This is the destination node to which reservations are being made.
Micro-Flow
A data flow from one end-point to another, defined uniquely by MF
classification [MF].
Boomerang Node (BN)
A BOOMP-aware node which performs admission control and reservation
for single or aggregated micro-flows.
Aggregating Node (AN)
A Boomerang Node that associates several micro-flows with a common,
aggregated QoS specification and appends an aggregation field to the
Boomerang messages of associated micro-flows, in order to suggest an
aggregated reservation state for subsequent BNs.
2. Introduction
In DiffServ networks, the DS field signals the resource and
forwarding demands of DS Behavior Aggregates [DSARCH]. Traffic
Conditioner nodes - placed on the edge or inside of the DS region -
are responsible for enforcing the Traffic Conditioning Agreement
(TCA) referred by the particular DiffServ Code Point (DSCP)
[DSFIELD]. Although signaling protocol based interaction between
traffic conditioners and traffic sources were discouraged earlier,
there are emerging work on this topic again [DSRSVP].
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 2]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
A simple and dynamic way of interchanging information between traffic
conditioners and traffic sources is to periodically insert signaling
packets among data packets and let them return to the traffic source
[TICKET]. Signaling messages can be transparently forwarded on
statically overprovisioned links while border nodes and upstream
nodes of bottleneck links can reserve resources according to the
message content. In this way, the source can explicitly express the
resource demand of a specific traffic stream in terms of bandwidth,
buffer or forwarding behavior and it can generate traffic according
to the feed-back from traffic conditioners. Using this dynamic QoS
approach, network operators can offer guaranteed services to
ambitious customers and quantitative QoS applications [E2E] in an
end-to-end manner.
Currently RSVP is the only accepted signaling protocol for resource
reservation setup in IP networks [RSVP] and it is probably the best
choice for making multicast reservation sessions. However, there are
several points where the handling of signaling could be simplified
(i.e. speeded up), if unicast sessions are considered:
* Reservation and path finding messages should not be separated
* The far end host should not be modified
* Network nodes should not keep track of the life-cycle of signaling
session, i.e. they should not store signaling states just
reservation states
* The number of message types should be kept very low
Therefore we propose a new reservation protocol for IP networks,
called Boomerang, which meets the following challenges:
1. Simple way for aggregating micro-flow reservation states
2. Simple processing of signaling messages at network nodes resulting
in simple implementation
3. Only one message type and a single signaling loop for reservation
set-up and tear-down
4. No requirements on the far end node
5. Concentrating the intelligence in the Initiating Node (IN). The IN
is responsible for signaling and maintaining the reservation
session. Network nodes along reserved path keep only flow states,
resulting in low load and processing time on network nodes.
The Boomerang protocol has been designed to be quick and simple, yet
powerful. It aims for extending the QoS mechanisms offered by DS,
RSVP, Int-Serv [IntServ] rather than replacing them.
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 3]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
3. Designing Objectives
3.1 Simple Implementation
In BOOMP, signaling states (meaning intelligence) are needed only in
the initiating node. Other BNs are 'passive' and the only requirement
is that they are able to interpret the Boomerang message. Therefore
the most complex BOOMP implementation is made locally in IN, while
other BNs only look-up reservation state and setup QoS treatment for
the flow. That also contributes to simplicity that BOOMP is focused
on unicast and sender oriented multicast services.
3.2 Small Processing Load in Routers
In order to decrease the context made for keeping track of the
reservation state of micro-flows, ANs can propose an aggregation of
these flow states. Consistency of micro-flow aggregation is
maintained by appending an aggregation field in the repeatedly
circulated BOOMP refresh messages. All control logic related to an
aggregation is concentrated in one AN, while other nodes can simply
rely on the information steadily coming in Boomerang messages or
handle micro-flow states.
3.3 Fast Reservation Setup
3.3.1 Bi-Directional Reservation
This implies that both the sender and the receiver node can send a
Boomerang, i.e. can act as IN. Many applications can not benefit from
receiver orientated reservations. Moreover, policy and billing may
suit better to sender initiated reservation in case of certain
applications (like broadcast video). For unicast applications BOOMP
can be used in a receiver oriented manner.
Different QoS parameters might be set up along the forward and
reverse path of the traffic flow. The forward and reverse path for a
bi-directional flow may differ.
3.3.2 Resource Query
When the Boomerang flies through the network, each BN decreases the
resource request field if it has less resources available for the
corresponding reservation. In this way the IN gets information about
the current network state and has a good chance to make a successful
reservation trial.
3.3.3 Single Message Loop
BOOMP requires only one 'signaling loop' between the IN and FEN for a
successful reservation.
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 4]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
3.4 Low Protocol Overhead
There is typically one or maximum two signaling loop required per
reservation session and signaling messages are small. A simple
calculation is given in Section 6. about the amount of signaling
overhead for BOOMP.
3.5 Robustness
BNs maintain reservation states as soft states, i.e. reservations
time out if they are not refreshed periodically. In this way orphan
reservations disappear automatically and routing changes have just a
temporary effect.
3.6 Quick Penetration
The following features results in an incremental deployment of BOOMP
in current IP networks.
3.6.1 Transparency
The only requirement for BOOMP-unaware nodes is to forward the BOOMP
messages. QoS in this node has to be ensured by another (loose or
tight) QoS mechanism, otherwise the end-to-end QoS can be
compromised. There is a prototype in which PING is used as the
transport mechanism of BOOMP enabling the proper behavior in the vast
majority of current IP-capable network devices.
3.6.2 QoS Interoperability
On the top of guaranteed resource reservation in Boomerang Nodes,
BOOMP can be used for asking for both tight QoS (such as the EF DSCP)
and loose QoS (such as AF DSCP) [EF, AF]. It is not limited to any
specific QoS specification, for instance it can transport Intserv
parameters as well.
3.6.3 Multiple Scope
There are many different way of using the Boomerang protocol for
resource reservation. It can be used between two hosts running
unicast services, either in a sender in or receiver oriented manner.
It can also be used for sender oriented multicast services.
Moreover, the scope of BOOMP can be limited to a single network
domain, which is connected to domains utilizing other QoS techniques.
3.6.4 No requirements on the Far-end Node
The other end-user can be quite unaware of all BOOMP implementation
in initiating node and network nodes and still profit from its
functionality.
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 5]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
4. Reservation Concept
4.1 Boomerang Reservation Message
The BOOMP reservation message contains the following fields for IPv4
traffic [BOOMER]:
* A signaling header
* A flow specification
* QoS specification
4.1.1 Signaling Header
This field contains the refresh interval and several flags in which
BNs can indicate the result of processing the Boomerang message.
The refresh interval is a measure of how often the reservation has to
be refreshed in order to preserve it in network nodes. The Initiating
Node can choose any refresh interval. Moreover, it can be decreased
by any router that needs a higher refresh rate.
If the IN stops sending refresh messages the resource allocation will
eventually time out.
4.1.2 Flow Specification
A BN identifies a micro-flow uniquely by five fields, found in the
BOOMP reservation message that sets up the flow. These fields in the
reservation message are: source IP address, source port number,
destination IP address, destination port number and the IP protocol
field.
4.1.3 QoS Specification
The IN indicates the type of QoS it requires with the BOOMP
reservation message - for the forward as well as for the reverse
direction. The QoS parameter specifies a service class (PHB) and
related resources. In our current BOOMP implementation EF PHB [EF]
and bit rate are used, but other formats are also possible
[DGVECTOR].
4.1.4 Transport Mechanism
There are several ways for transporting the Boomerang protocol.
ICMP ECHO / ECHO REPLY
In the current prototype implementation BOOMP is wrapped in an ICMP
ECHO / ECHO REPLY messages, i.e. a normal PING message. This
conveniently ensures the correct node behavior from most existing
nodes both passive routers and hosts.
New protocol or new ICMP message
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 6]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
A cleaner implementation would be to define a new ICMP message for
the BOOMP primitives, or to assign an entirely new protocol for BOOMP
signaling.
In both these later cases however, we would not have the correct end-
node behavior for free. We would probably have to configure each
unaware network node to accept these messages.
The router alert option should be set for each Boomerang message in
order to indicate that the routers should investigate this message
[RALERT].
Inbound signaling
A slightly different approach is to transport the reservation
messages as an integral part of the transport protocol. In this case
a transport mechanism must be defined for each transport protocol
where we desire to do resource reservation. This is the approach
taken in YESSIR [YESSIR], which is an inbound signaling protocol for
RTP connections.
4.2 Operation
Resource reservation with the Boomerang protocol is simple. The
Initiating Node (IN) sends a Boomerang message to the Far-End Node
(FEN) containing the desired forward and reverse QoS descriptors
(e.g. bit rate). When this message reaches the FEN, it is echoed back
to the IN. The Boomerang message follows standard routing protocols,
and allocates resources hop-by-hop in all Boomerang-aware nodes (BNs)
en route. This ensures that the reservation will be made along the
correct path for both upstream and downstream traffic. When IN gets
back the Boomerang message, it verifies the completion of the
reservation by examining the appropriate message flags that have been
set in the BOOMP message by the BNs along the way. Reservation
messages are then sent periodically from the IN to the FEN (the rate
is specified by the IN itself) to keep the reservation alive in all
of the nodes along the upstream and downstream paths.
If a reservation request is denied by a BN, the following actions are
taken before the reservation message is forwarded using standard
routing rules:
a) The NACK flag in the message is set
b) If the requested resources are greater than the available
resources at the current node, the QoS Specification fields of
the Boomerang message are updated to reflect the current lowest
available resources.
c) If the Refresh Interval in the Boomerang exceeds the network
node's current maximum refresh interval, it is updated to reflect
the current minimum refresh interval.
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 7]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
If a message arrives at the network node with the NACK flag already
set, only actions (b) and (c) are taken.
When the reservation arrives back at the IN, it checks the message to
see if the reservation was successful.
If the NACK flag is NOT set, the reservation was successful, but the
Refresh Interval field might still have changed. If this is the case,
the IN continues to send Boomerang messages with the interval stated
in the refresh interval field.
If the NACK flag is set, the request was denied somewhere along the
message path. This is where the IN has to take some action. A new
maximum QoS Specification might have been specified, so the IN may
choose to retry the old request, revoke it with the attained new QoS
specification, or release the request.
4.2.1 Lost Boomerang
If the Boomerang message does not return to the IN within a certain
time, it is considered to be lost. The IN can wait and repeat the
original request again, or downgrade the demanded resource amount and
request less.
5. Issues
5.1 Flow-state Aggregation
The Boomerang protocol requires no signaling states in the network
nodes, but aggregation of reservation (or flow) states is still
desirable. There are different ways for making flow state aggregation
in BOOMP.
5.1.1 Aggregation Suggested by Earlier Node
This is an extension to the Boomerang protocol, which allows a
microflow node to suggest a destination subnet-based aggregation to a
later network node. When the microflow node discovers that it has a
large number of reservations between two subnets it can decide to
append aggregation information for these subnets to each signaling
message within this aggregated flow. This is done by appending a
special message field to Boomerang containing the class, IP protocol,
source / destination subnetmask for this aggregation, an aggregation
key (e.g. the aggregating node's own IP number) and the total
resource demand of this aggregated flow. Nodes inside the network may
now use this information to create states for these aggregates of
micro-flows and can perform policing on these. The later node can
then in turn suggest further aggregation for following nodes.
5.1.2 Measurement Based Admission Control
This covers any method where no hard control is kept of the allocated
resources. On contrary, admission control is performed by measuring
the current amount of traffic in the given class. Experiments
indicate [MEASURE] that measurement based techniques can be made to
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 8]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
work even with long range dependant flows for a reasonably large
aggregation.
5.1.3 Refresh Message based Admission Control
Instead of storing hard states for keeping track of the used
resources, the refresh request messages can be used. By summing the
requested rates weighted by the refresh interval over a sliding
window, the node can estimate the amount of resources already
reserved and use this knowledge to do admission control. A similar
approach is proposed in [TICKET]. The accuracy of the estimate will
depend on the number of refresh messages within the sliding window,
and the node should therefore refresh a rather frequent refresh
interval. As with the measurement-based scheme, dynamic policeing of
individual flows is not possible.
5.2 Route Changes
While the issues of routing and route changes are not strictly a part
of the signaling problem, the questions inevitably arise. If we are
granted resources along a specific path, our data must stay along
this path or our reservation will be useless. Furthermore, if we
reserve resources along a path and allow these packets through
policing as e.g. EF PHB, a path change may ruin the performance of
other EF users in violation of the PHB specifications. To avoid this
we must either keep states at each potential bottleneck where we
might expect sudden route changes, or pin the route. This can be done
either dynamically by "freezing" the router cache entry, or by using
static route policies over narrow links. Our own experiences shows
that in a network with best effort routing, route changes are very
rare and are almost always triggered by a change in topology (such as
a link failure). The case of non topology driven route changes almost
always occur in the access network where the number of flows is
reasonably low. Refreshed reservations and soft reservation states
can help in most of the cases.
5.3 Multicasting
The Boomerang protocol does not distinguish individual leafs within a
multicast group, so the most natural way to use it in conjunction
with multicast would be a sender oriented scheme. The sender would
send the reservation request to the entire multicast group and it
would be up to the leafs to detect the success or failure for that
particular branch. A typical application could be a broadcast video
server similar to the pay-TV found in hotel rooms. The server would
send reservation messages to the multicast group with a short refresh
interval (e.g. 3 seconds) and the NO_ECHO flag set. When a new client
is added to the multicast group resource reservation is attempted
within one refresh interval and the client will start receiving data
along with either ACKed or NACKed reservations. If it receives NACKs
then obviously the reservation failed and it is up to the client to
ask to be removed from the multicast list.
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 9]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
From the perspective of the BOOMP, it is possible to ask for
resources for a multicast group along a specific branch. However, we
think that solving the complexity of multiple users depending on the
same reservation (accounting and such) is out of the scope of the
network layer.
5.4 Denial of Service Attacks
The Boomerang protocol provides a special "key" field for preventing
misuse of partially failed reservations. The access router could
easily have a rate limit mechanism per source address. This is mainly
an implementation issue.
5.5 Selective Hunting
The main idea is that even if the node is "Boomerang aware" we only
need to actually process the Boomerang messages if the node is judged
to be a bottleneck. The Boomerang protocol could be deactivated by
something like a bandwidth broker, if the node is not a bottleneck.
However, computers as opposed to humans do not benefit significantly
from resting so the main gain from deactivating the Boomerang
protocol would be a decrease in signaling delay.
5.6 Security
TBD.
5.7 Decreasing network signaling
There are a few issues concerning the efficiency of the protocol and
their possible solutions.
5.7.1 Signaling Overhead
Since the Boomerang protocol suggests refreshing of reservations with
intervals down to a few seconds, using it with no aggregation might
create a significant network load. If the refresh interval is the
same for a large number of sources these will not quickly decorrelate
if they happen to be correlated, which may result in unpleasant
bursts of network traffic. A small numerical example: with the very
short refresh interval of 3 sec and packets consisting of 56 byte
IPv4 Boomerang message + ICMP + IP+ Ethernet = 92 bytes we will have
a bitrate of 245bps. For a 12kbps IP telephony call this is about 2%
overhead. In practical use with longer refresh interval, the overhead
should be significantly less. As for the correlation, the
reservations are obviously initiated in an uncorrelated fashion and
it would therefore be quite rare that more than a few sources at a
time would drive into correlation. The impact of these occurrences
could be further reduced by letting hosts and nodes that sets the
refresh value randomize it in a neighborhood of the desired value.
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 10]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
5.7.2 Network loading by end to end transmission of NACKED connections
In the Boomerang protocol we state that all signaling is end to end.
This means that network nodes does not generate signaling they only
modify and update incoming signaling messages. The reason for this is
that it makes the protocol extremely simple to implement. This also
means that a reservation which is NACKed early in the network still
has to travel the entire way to the end node and back, which both
loads the network and increases the probability of the reservation
getting lost. A solution to this would be to return the NACK
immediately by the NACKing node. We have chosen not to do this since
the NACK messages are an extremely small part of the network traffic
and we value the simplicity of passive nodes more. Instead we treat
the NACKed message as a query, and update it along the path with the
minimum available resources. This way the returning NACK can serve as
decision support for the initiating node.
6. Illustrative scenarios
The multiple scopes of Boomerang based reservation process is
illustrated by two simple examples.
6.1 Single-domain with a bottleneck
Let us consider a scenario where we have two hosts (A, F) attached to
a DS domain (B-C-D-E). The DS network is non blocking for high
priority traffic, but there is a highly utilized link in the middle
(C-D) where over-provisioning is difficult or very expensive (e.g.
the Atlantic cable). This is a potential bottleneck link for the
guaranteed service.
A B C D E F
/-------------------------\
| |
+---+ +----+ +---+ +---+ +----+ +---+
|IN | | | |BN | |BN | | | |FEN|
+---+--| |----| |===| |----| |--+---+
+---+ +----+ +---+ +---+ +----+ +---+
| |
\-------DS domain---------/
The traffic between hosts (A) and (F) has to pass through the DS
compliant network including the bottleneck link. Therefore one of the
hosts should send a BOOMP reservation request, in order to get
resources on the bottleneck link in a guaranteed manner.
Let us assume that host (A) sends a BOOMP message, which is forwarded
hop-by-hop through the network and echoed back by host (F). Since (B)
and (E) are BOOMP-unaware nodes, they just simply forward the
Boomerang message to the next hop. Node (C) as the ingress node of
the bottleneck link performs admission control for the requested
resources and indicates the result in the Boomerang message.
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 11]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
Similarly, node (D) performs admission control for the backward
traffic. It is possible to specify different amount of resources for
the traffic going in the forward and reverse directions, and forward
and reverse paths can differ.
Host A can then see the result of the reservation from the returned
BOOMP message.
In case of a successful reservation, host A can start to send (or
receive) traffic with guaranteed QoS on the bottleneck links and DS-
based QoS in the rest of the DS network. For the latter, data packets
shall be marked with proper DSCP [DSFIELD]. The initiating host
should refresh the reservation by sending BOOMP messages periodically
to prevent the soft states in the nodes from timing out.
6.2 End-to-end reservation with aggregation
SUBNET_1 SUBNET_2
+---+ +---+
| X |\ A B C D /| Z |
+---+ \ +---+ +----+-+ +----+ +----+ / +---+
+---+ \ | | | AN | | |BN | |BN | / +---+
*---+ +--| | |--| |--| |---*
+---+ / +---+ +----+-+ +----+ +----+ \ +---+
| Y | / \ | U |
+---+/ \+---+
+---+ B -- aggregating node +---+
Aggregation of flow states can be made, if one or more resource
reservations share the same QoS specifications. It can be made on a
subnet-to-subnet basis, and requires no special de-aggregation
functionality.
In this example, (X) and (Y) are two nodes that want to allocate
resources to (Z). They do this in the usual way by sending Boomerang
messages that will pass through (A), (B), (C) and (D), bounce at (Z)
and then go back, reserving bandwidth in the opposite direction. (X)
and (Y) send their reservations periodically, each with its own
refresh interval.
The (B) node might aggregate these reservations, since it is aware of
the fact that both reservations are made with source=SUBNET_1 and
destination=SUBNET_2. To aggregate these reservations, (B) appends an
aggregation field to each refresh Boomerang message that arrives from
(X) and (Y). This aggregation field contains the sum of resources
reserved for the aggregate, information that helps to identify the
corresponding subnets (SUBNET_1 and SUBNET_2), and a special
aggregation key to differentiate this aggregation from other ones
made between the same subnets.
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 12]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
(B) still keeps track of each reservation, it does not remove any
context. When the Boomerang messages leaves (B), heading for (Z), it
will contain this appended aggregation field and subsequent nodes may
use it to create contexts.
If (C) gets a Boomerang message from (X), with an aggregation field
appended, it may ignore the information about the individual flow,
and only create a context for the aggregation. Whenever another
reservation message arrives, (C) looks for aggregation fields, and
uses this part of the Boomerang message as a refresh message for the
aggregated reservation state.
Node (D) may, on the other hand, simply ignore these aggregation
fields, and treat each message as a unique reservation. If (X) then
stops sending refresh messages, the corresponding reservation state
times out in (B), and (B) updates the aggregated state to be
consistent with the currently reserved bandwidth. Moreover, (B)
indicates this change in the corresponding Boomerang messages by
removing the aggregation field. When the aggregation is removed
completely, the aggregated reservation will eventually time out in
(C), but by that time a new context should have been created in (C)
for each individual flow.
7. References
[E2E] Bernet, Y., Yavatka,r R., Ford, P., Baker, F., Nichols,
K., Speer, M., "A Framework for End-to-End QoS Combining
RSVP/Intserv and Differentiated Services", Internet
Draft, <draft-ietf-DiffServ-rsvp-00.txt>, March 1998.
[DSARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[DSRSVP] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M.
Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine
"A Framework for Integrated Services Operation Over
Diffserv Networks", Internet Draft, September 1999,
<draft-ietf-issll-diffserv-rsvp-03.txt>
[EF] V. Jacobson, Kathleen Nichols, Kedernath Poduri, "An
Expedited Forwarding PHB", Internet Draft, February 1999,
<draft-ietf-diffserv-phb-ef-02.txt>
[AF] F. Baker, J. Heinanen, J. Wroclawski, W. Weiss, "Assured
Forwarding PHB Group", Internet Draft, February 1999.
<draft-ietf-diffserv-af-06.txt>
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 13]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
[IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated Services
in the Internet Architecture: An Overview", Internet RFC
1633, July 1994.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin,
S., "Resource Reservation Protocol (RSVP) Version 1
Functional Specification", IETF RFC 2205, Proposed
Standard, September 1997.
[YESSIR] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation
Mechanism for the Internet",
http://www.ctr.columbia.edu/~pan/work/yessir/yessir.ps
[DGVECTOR] Cselényi, I., Szabó, R., Szabó, I., Björkman, N., Latour-
Henner, A., "Experimental Platform for Telecommunication
Resource Management" Computer Communications (21)17
(1998) pp.1624-1640
[MEASURE] J.T. Lewis, R. Russell, F. Toomey, B. McGurk, S. Crosby,
I. Leslie, "Practical connection admission control for
ATM networks based on on-line measurements", Computer
Communications (21)17 (1998) pp. 1585-1596
[TICKET] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight
Resource Reservation for Unicast IP Traffic",
International WS on QoS'98, IWQoS'98, May 18-20, 1998
[BOOMER] D. Ahlard, J. Bergkvist, I. Cselényi, "Boomerang Protocol
Specification", Internet Draft, June 1999, Internet
Draft, <draft-bergkvist-boomerang-spec-00.txt>
[RALERT] D. Katz, "IP router alert option", RFC 2113, IETF,
February 1997
8. Author Information
Bergkvist, Joakim
Telia Research
Vitsandsgatan 9B
S-123 86 Farsta, Sweden
Phone: +46 8 713 81 71
Email: jobe@trab.se
Cselenyi, Istvan
Telia Research
Vitsandsgatan 9B
S-123 86 Farsta, Sweden
Phone: +46 8 713 81 73
Email: cse@trab.se
Ahlard, David
Telia Research
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 14]
INTERNET-DRAFT<draft-bergkvist-boomerang-framework-01.txt> November 2000
Vitsandsgatan 9B
S-123 86 Farsta, Sweden
Phone: +46 8 713 81 90
Email: davahl@trab.se
Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 15]
