INTERNET-DRAFT D. Ahlard, Telia Research
Expires: August 1999 J. Bergkvist, Telia Research
I. Cselenyi, Telia Research
T. Engborg, Telia Research
February, 1999
Boomerang - A Simple Resource Reservation Framework for IP
<draft-ahlard-boomerang-framework-00.txt>
Status of this Memo
This document is an Internet-Draft and is NOT offered in
accordance with Section 10 of RFC2026, and the author does not
provide the IETF with any rights other than to publish as an
Internet-Draft. Internet-Drafts are working documents of the
Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
This draft describes a framework for providing quantitative IP
services with guaranteed QoS. Although the proposed reservation
approach is based on a new, lightweight signaling protocol, it can
be used with interoperability with other IP QoS techniques such as
Diff-Serv, Int-Serv.
Distinguishing features of the Boomerang protocol are:
* 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, thus good
scalability can be achieved
* bi-directional reservation can be made independently of
the path, which yields a fast and effective reservation
process
* the only requirement on the far-end node is that it
should be able to bounce the Boomerang message back,
ensuring quick penetration into the current Internet.
Bergkvist, et.al. Expires: August 1999 [Page 1]
INTERNET-DRAFT Boomerang framework February 1999
There is a lab prototype in which the Boomerang protocol is
wrapped in ICMP ECHO / ECHO-REPLY (PING) messages.
Table of contents
1 Terminology 3
2 Introduction 3
3 Properties 4
3.1Simple Implementation 4
3.2Good Scalability 4
3.3Simple But Effective Signaling Process 5
3.3.1Bi-directional Reservation 5
3.3.2Concentrated Intelligence 5
3.3.3Low protocol overhead 5
3.3.4Soft-state 5
3.3.5Resource Query 5
3.3.6Fast Reservation Process 5
3.4Penetration 6
3.4.1Transparency 6
3.4.2QoS Interoperability 6
3.4.3Multiple Scope 6
3.4.4No requirements on the Far-end Node 6
4 Reservation Concept 6
4.1Boomerang Reservation Message 6
4.1.1Signaling Header 7
4.1.2Flow Specification 7
4.1.3QoS Specification 7
4.1.4Transport Mechanism 7
4.2Operation 8
4.2.1Lost Boomerang 9
5 Issues 9
5.1Flow-state Aggregation 9
5.1.1Aggregation Suggested by Earlier Node 9
5.1.2Measurement Based Admission Control 10
5.1.3Refresh Message based Admission Control 10
5.2Route Changes 10
5.3Multicasting 11
5.4Denial of Service 11
5.5Selective Hunting 11
5.6Security 11
5.7Decreasing network signaling 11
5.7.1Network flooding by refresh messages 12
5.7.2Network loading by end to end transmission of NACKED
connections 12
6 Illustrative scenarios 13
6.1Single-domain with a bottleneck 13
6.2End-to-end reservation with aggregation 14
7 References 15
8 Author Information 16
Bergkvist, et.al. Expires: August 1999 [Page 2]
INTERNET-DRAFT Boomerang framework February 1999
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 initiating the resource reservation. Can be the
sender or receiver host or any BOOMP-aware network node.
Far-End Node (FEN)
This is the 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
Besides Differentiated Services [DSARCH] network operators may
also be interested in offering guaranteed services to ambitious
customers, and quantitative QoS applications [E2E] in an end-to-
end manner. However, best effort network domains or bottleneck
segments within a DS domain may compromise the end-to-end QoS
during peak hours in the network. Therefore a simple signaling
protocol is needed to signal per micro-flow QoS requirements to
the network and to reserve resources end-to-end in guaranteed
manner.
RSVP is the only accepted signaling protocol for resource
reservation setup in IP networks [RSVP], although it has several
limitations:
1. it relies on per micro-flow state, which results in a
scalability problem in terms of memory, capacity and processing
time
2. it is complex to implement both in nodes and hosts due to
separation of reservation and path finding messages, receiver
Bergkvist, et.al. Expires: August 1999 [Page 3]
INTERNET-DRAFT Boomerang framework February 1999
diversity
3. it requires modification in the far end host
4. The intelligence of signaling processing is spread over
the network. Each node along a reserved path contains a flow state
and a signaling state. Therefore, each reservation session
increases the load on network nodes.
5. it requires multiple interaction between sender and
receiver for a successful reservation setup
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. No special requirements on the far end
4. Concentrating the intelligence in the Initiating Node (IN). The
IN is responsible for signaling- and handling flow state for the
setup reservation. Network nodes along reserved path keep only
flow states, resulting in low load and processing time on network
nodes.
5. Quick reservation setup thanks to a single signaling loop
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.
3 Properties
The properties of the Boomerang protocol are grouped according to
the main benefits they yield.
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 and it is a reasonable belief that BOOMP can be
simply implemented in other nodes. Another feature that
contributes to simplicity is that BOOMP is focused on unicast and
sender oriented multicast services.
3.2 Good Scalability
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
Bergkvist, et.al. Expires: August 1999 [Page 4]
INTERNET-DRAFT Boomerang framework February 1999
simply rely on the information steadily coming in Boomerang
messages or handle micro-flow states.
3.3 Simple But Effective Signaling Process
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 Concentrated Intelligence
The signaling control logic is concentrated in the initiating node
in BOOMP. Other nodes are not generating signaling messages.
3.3.3 Low protocol overhead
There is typically one or maximum two signaling loop required per
reservation session. Only the IN generates signaling messages,
other BNs do not. A simple calculation is given in Section 6.
about the amount of signaling overhead for BOOMP.
3.3.4 Soft-state
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.3.5 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.6 Fast Reservation Process
BOOMP requires only one 'signaling loop' between the IN and FEN
Bergkvist, et.al. Expires: August 1999 [Page 5]
INTERNET-DRAFT Boomerang framework February 1999
for a successful reservation.
3.4 Penetration
The following features results in an incremental deployment of
BOOMP in current IP networks.
3.4.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.4.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.4.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.4.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.
4 Reservation Concept
4.1 Boomerang Reservation Message
The BOOMP reservation message contains the following fields for
IPv4 traffic [BOOMP]:
Bergkvist, et.al. Expires: August 1999 [Page 6]
INTERNET-DRAFT Boomerang framework February 1999
* 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 in the Boomerang message is a measure of how
often the reservation has to be refreshed in order to keep it from
timing out in the network nodes. The Initiating Node chooses a
refresh interval. But it can be decreased by any router that needs
a lower refresh interval; thus enforcing a higher refresh rate by
the IN.
If the IN stops sending refresh messages the resource allocation
will eventually time out. The network administrator should choose
the actual timeout in the network, and the IN should make no
assumptions about it.
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 in current BOOMP implementation is
bit rate, but other formats are also possible [DGVECTOR].
Requested handling of the flow is specified in the reservation
message. Different types of data flow require different queue
handling rules in the nodes. The Boomerang protocol categorizes
different service classes, each with different types of queue
handling rules. Queue handling rules differ regarding priority,
loss sensitivity and delay sensitivity.
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
Bergkvist, et.al. Expires: August 1999 [Page 7]
INTERNET-DRAFT Boomerang framework February 1999
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
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.
Bergkvist, et.al. Expires: August 1999 [Page 8]
INTERNET-DRAFT Boomerang framework February 1999
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.
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. However, other kind of states may be needed for several
other reasons such as policing of flows and to keep track of the
amount of resources used in a robust way. To take full benefit of
the Boomerang protocol in network nodes with a high aggregation of
traffic we require ways of doing admission control that does not
require us to keep information per micro-flow.
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
Bergkvist, et.al. Expires: August 1999 [Page 9]
INTERNET-DRAFT Boomerang framework February 1999
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 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.
Bergkvist, et.al. Expires: August 1999 [Page 10]
INTERNET-DRAFT Boomerang framework February 1999
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.
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
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
Bergkvist, et.al. Expires: August 1999 [Page 11]
INTERNET-DRAFT Boomerang framework February 1999
and their possible solutions.
5.7.1 Network flooding by refresh messages
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
correllation. 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.
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.
Bergkvist, et.al. Expires: August 1999 [Page 12]
INTERNET-DRAFT Boomerang framework February 1999
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 indicate the result in the Boomerang
message. 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 [DSHEAD]. The initiating
host should refresh the reservation by sending BOOMP messages
periodically to prevent the soft states in the nodes from timing
out.
Bergkvist, et.al. Expires: August 1999 [Page 13]
INTERNET-DRAFT Boomerang framework February 1999
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.
(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
Bergkvist, et.al. Expires: August 1999 [Page 14]
INTERNET-DRAFT Boomerang framework February 1999
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", IETF
<draft-ietf-DiffServ-rsvp-00.txt>, March 1998.
[DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang,
and W. Weiss, "An Architecture for Differentiated Services",
Internet Draft, May 1998.
[DSHEAD] K. Nichols and S. Blake, "Definition of the Differentiated
Services Field (DS Byte) in the IPv4 and IPv6 Headers",
Internet Draft, May 1998.
[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>
[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
Mechnism for the Internet",
http://www.ctr.columbia.edu/~pan/work/yessir/yessir.ps
Bergkvist, et.al. Expires: August 1999 [Page 15]
INTERNET-DRAFT Boomerang framework February 1999
[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
[BOOMP] _The Boomerang Resource Reservation Protocol_
[RALERT] D. Katz, "IP router alert option", RFC 2113, IETF,
February 1997
8 Author Information
Ahlard, David
Telia Research
Vitsandsgatan 9B
S-123 86 Farsta, Sweden
Phone: +46 8 713 81 90
Email: davahl@trab.se
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
Engborg, Tomas
Telia Research
Vitsandsgatan 9B
S-123 86 Farsta, Sweden
Phone: +46 8 713 81 76
Email: toeng@trab.se
Bergkvist, et.al. Expires: August 1999 [Page 16]