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 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 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 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 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 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 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 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 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 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 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 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 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 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, , 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, [EF] V. Jacobson, Kathleen Nichols, Kedernath Poduri, "An Expedited Forwarding PHB", Internet Draft, February 1999, [AF] F. Baker, J. Heinanen, J. Wroclawski, W. Weiss, "Assured Forwarding PHB Group", Internet Draft, February 1999. Bergkvist, Cselenyi, Ahlard Expires May 2001 [Page 13] INTERNET-DRAFT 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, [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 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]