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 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 , 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 [AF] F. Baker, J. Heinanen, J. Wroclawski, W. Weiss, "Assured Forwarding PHB Group", Internet Draft, February 1999. [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]