[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]