Benchmarking Working Group Gabor Feher, BUTE INTERNET-DRAFT Istvan Cselenyi, TRAB Expiration Date: May 2003 Andras Korn, BUTE November 2002 Benchmarking Terminology for Routers Supporting Resource Reservation 1. 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. 2. Table of contents 1. Status of this Memo.............................................1 2. Table of contents...............................................1 3. Abstract........................................................2 4. Introduction....................................................2 5. Existing definitions............................................3 6. Definition of Terms.............................................3 6.1 Resource Reservation Protocol Basics........................3 6.1.1 Unicast Resource Reservation Session...................3 6.1.2 Multicast Resource Reservation Session.................4 6.1.3 Resource Reservation Capable Router....................4 6.1.4 Signaling End-point....................................5 6.1.5 Reservation Orientation................................5 6.1.6 Reservation Session State..............................6 6.1.7 Signaling Path.........................................7 6.2 Traffic Types...............................................8 6.2.1 Best-Effort Data Packets...............................8 Feher, Cselenyi, Korn Expires May 2003 [Page 1] INTERNET-DRAFT November 2002 6.2.2 Premium Data Packets...................................8 6.3 Router Load Types...........................................9 6.3.1 Traffic Load...........................................9 6.3.2 Session Load...........................................9 6.3.3 Signaling Load........................................10 6.3.4 Signaling Burst.......................................11 6.4 Performance Metrics........................................11 6.4.1 Signaling Message Handling Time.......................11 6.4.2 Premium Traffic Delay.................................12 6.4.3 Best-effort Traffic Delay.............................12 6.4.4 Signaling Message Loss................................13 6.4.5 Session Refreshing Capacity...........................13 6.4.6 Scalability Limit.....................................14 7. Security Considerations........................................14 8. Acknowledgement................................................15 9. References.....................................................15 10. Authors' Addresses............................................16 3. Abstract The purpose of this document is to define terminology specific to the benchmarking of the resource reservation signaling of IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers supporting resource reservation and define reporting formats for the benchmarking measurements. 4. Introduction The IntServ over DiffServ framework [1] outlines a heterogeneous Quality of Service (QoS) architecture for multi domain Internet services. Signaling based resource reservation (e.g. via RSVP [2]) is an integral part of that model. While this approach significantly lightens the load on most of the core routers, the performance of border routers that handle QoS signaling is still crucial. Therefore network operators, who are planning to deploy this model, shall scrutinize the scalability limitations of reservation capable routers and the impact of signaling on the forwarding performance of the routers. An objective way for quantifying the scalability constraints of QoS signaling is to perform measurements on routers that are capable of resource reservation. This document defines terminology for specific set of tests that vendors or network operators can use to measure and report the signaling performance characteristics of router devices that support resource reservation protocols. The results of these tests provide comparable data for different products supporting the decision process before purchase. Moreover, these measurements provide input characteristics for the dimensioning of a network in which resources are provisioned dynamically by signaling. Finally, the tests are applicable for characterizing the impact of the resource reservation signaling on the forwarding performance of the routers. Feher, Cselenyi, Korn Expires May 2003 [Page 2] INTERNET-DRAFT November 2002 This benchmarking terminology document is based on the knowledge gained by examination of (and experimentation with) several very different resource reservation protocols: RSVP [2], Boomerang [5], YESSIR [6], ST2+ [7], SDP [8] and Ticket [9]. Nevertheless, this document defines terms that are valid in general and not restricted to these protocols. 5. Existing definitions RFC 1242 [3] "Benchmarking Terminology for Network Interconnect Devices" and RFC 2285 [4] "Benchmarking Terminology for LAN Switching Devices" contains discussions and definitions for a number of terms relevant to the benchmarking of signaling performance of reservation capable routers and should be consulted before attempting to make use of this document. For the sake of clarity and continuity this document adopts the template for definitions set out in Section 2 of RFC 1242. Definitions are indexed and grouped together into different sections for ease of reference. 6. Definition of Terms 6.1 Resource Reservation Protocol Basics This group of definitions applies to various signaling based resource reservation protocols implemented on IP router devices. 6.1.1 Unicast Resource Reservation Session Definition: The term unicast resource reservation session (or shortly reservation session) expresses that two end-nodes explicitly request the network nodes, which forward their data flow, to assign special QoS treatment for data packets belonging to the flow. Discussion: The QoS treatment is defined by specifying the amount of networking resources that should be dedicated to the data flow during the length of the reservation session. There are different approaches, how to specify the network resource requirement of a data flow. It can be described by high-level parameters, like the required bandwidth or the maximum data delay; or it can be low- level information, such as the parameters of a leaky-bucket model describing the data flow [10]. Reservation sessions must be uniquely registered in network nodes assuring the QoS treatments. Practically, the transport address of the destination end-node and the transport protocol of the communication are sufficient to distinguish the reservations, Feher, Cselenyi, Korn Expires May 2003 [Page 3] INTERNET-DRAFT November 2002 however in extreme cases the transport address of the source should be included as well. See Also: Reservation Session State 6.1.2 Multicast Resource Reservation Session Definition: A multicast resource reservation session (or, in short, multicast reservation session) denotes that end-nodes forming a multicast group ask the network nodes, which forward the data packets of the multicast group, to assign a certain QoS treatment to their data traffic. Discussion: In a multicast group there can be several data traffic sources and destinations. The required QoS treatment is specified the same way as in the case of the unicast resource reservation sessions. In the case of multicast reservations, however, unlike in the case of unicast reservations, the amount of reserved network resources does not have to be the same on each network node forwarding the multicast data traffic. Multicast reservations must be registered in network nodes forwarding the associated data traffic similarly as it happens in the unicast case. Generally, there are two types of multicast resource reservations: many-to-many and one-to-many. Those of the first type allow multicast data traffic to be originated from several sources, while those of the second type permit only one fix data traffic source in the whole multicast group that must not change during the lifetime of the session. 6.1.3 Resource Reservation Capable Router Definition: A router is resource reservation capable -- supports resource reservation -- if it understands a resource reservation protocol that signals the set-up, tear-down and modification of resource reservation sessions. Discussion: Resource reservation protocols define signaling messages that are interpreted by resource reservation capable routers. The router captures the signaling message and manipulates the resource reservation sessions and/or the reserved network resources according to the content of the message. Issues: Despite that resource reservation sessions are considered to be unique, resource reservation capable routers might aggregate them and allocate network resources to these aggregated sessions at once. The aggregation can be based on similar flow attributes Feher, Cselenyi, Korn Expires May 2003 [Page 4] INTERNET-DRAFT November 2002 (e.g. aggregation using DiffServ code-points [11]) or it can combine arbitrary sessions as well. While reservation aggregation significantly lightens the signaling processing task of a resource reservation capable router, it also requires the administration of the aggregated flows and might also lead to the violation of the quality guaranties of individual reservations within an aggregation. 6.1.4 Signaling End-point Definition: A signaling end-point is a network node capable of initiating and terminating resource reservation sessions. Discussion: Besides traditional end-systems, there is also another type of signaling end-point: the reservation gateways. Reservation gateways translate the signaling messages of one resource reservation protocol into messages of another resource reservation protocol. Thus the reservation gateway represents two signaling end-points in one, as it is both a signaling terminator and a signaling initiator. Issues: Typically, signaling end-points have a dedicated protocol stack, which interprets and generates the signaling messages. However, in some special cases, the resource reservation initiation is carried out without the notice of the signaling terminating node. For example, the Boomerang resource reservation protocol encapsulates the reservation requests in an ICMP Echo message. This message is bounced back from the signaling terminating network node ("Far-End Node") and as a result the node becomes a signaling end-point without understanding the reservation protocol. 6.1.5 Reservation Orientation Definition: The reservation orientation tells which signaling end-point(s) initiates the network resources allocation to obtain special QoS treatment for the data traffic of the reservation session. Discussion: Resource reservation protocols can be classified into two groups depending on the relationship between the reservation initiators and their role in the data traffic flow. First, there are sender- oriented protocols, where the source(s) of the reservation sessionĘs data traffic initiates the network resource allocation message. Second, in the case of the receiver-oriented protocols, the receiver(s) of the reservation sessionĘs data traffic initiates the resource allocation messages. Due to the asymmetric routing nature of the Internet, in the latter case, the receiver(s) should know the route(s) of the desired data traffic before it would be able to send the resource allocation Feher, Cselenyi, Korn Expires May 2003 [Page 5] INTERNET-DRAFT November 2002 message(s). For this reason, even in the second case, the first signaling message(s) establishing the reservation session comes from the source(s) of the data traffic marking the route(s) on which the resource allocation message(s) might travel backward. Issues: The orientation of the reservation initiator affects the basics of the resource reservation protocols and therefore it is an important design decision. In the case of multicast reservation sessions, the sender-oriented protocols require the traffic sources to maintain a list of receivers and send their allocation messages considering the requirements of the receivers. A less polite, but less demanding solution is when the sources ignore the QoS requirements of the receivers and send the allocation requests at will. Using multicast reservation sessions, the receiver- oriented protocols give the chance to the receivers to place their own resource allocation requests and thus ease the task of the sources. However, in this case the resource allocations must be preceded by the marking of the data routes of the reservation session (c.f. RSVP PATH message [2]). In case of large multicast groups, enabling the receivers to specify their QoS requirements, the receiver-oriented approach seems to be a better choice, however in other cases the sender-oriented protocols promise less complexity. 6.1.6 Reservation Session State Definition: A reservation session state is a holder for all the relevant information about the corresponding reservation session registered in the resource reservation capable router. Discussion: Resource reservation capable routers maintain reservation session states to store information about the reservation session. This information might include the QoS treatment that the reservation session requires; the description of how and where to forward the incoming signaling messages; policies regarding the QoS treatment or the reservation session; timing information about the reservation session; etc. Based on how reservation session states are stored in a reservation capable router, the routers can be categorized into three classes: Hard-state resource reservation capable routers (e.g. ST2 capable routers [7]) store the reservation session states permanently, established by a set-up signaling primitive, until a corresponding tear-down signaling primitive arrives or until the router is informed that the reservation session canceled. There are also soft-state resource reservation capable routers, where there are no permanent reservation session states, but each Feher, Cselenyi, Korn Expires May 2003 [Page 6] INTERNET-DRAFT November 2002 state have to be regularly refreshed by appropriate refresh signaling messages. If no refresh signaling message arrives during a certain period then the router cancels the reservation session assuming that the signaling end-points do not intend to keep up the reservation session any longer or the communication lines are broken somewhere along the data path. This feature makes soft- state resource reservation capable routers more robust than hard- state routers, since no failures can cause permanent resource stuck in the routers. Finally, there are stateless resource reservation capable routers storing no information about the individual reservation sessions. Without reservation session states the resource reservation capabilities of such routers are limited, e.g. there is no support for many-to-many multicast resource reservation sessions; and the reservation session must be sender oriented. Issues: Although soft-state reservation capable routers are more robust than hard-state ones, the frequent processing of refresh signaling messages or the detection of the missing reservation session state refreshes might cause serious increase in the router load, which can be a base of the scalability problems. In order to decrease the number of refresh signaling messages, the resource reservation capable router might support various mechanisms to pack several refresh signaling messages into one larger message. 6.1.7 Signaling Path Definition: A signaling path is a sequence of network nodes and links along which signaling messages travel from one signaling end-point to the other. Discussion: Resource reservation capable routers must assure that all other router, which is responsible for handling the actual signaling message, really receives that message. Therefore, routers forward the signaling messages along the signaling path and each router, affected by the message, processes it. Usually signaling messages are immediately forwarded by resource reservation capable routers towards the destination(s), spreading the information as fast as possible. However, there might be protocol messages that do not affect all the routers along the signaling path, but only a subset of it (e.g. refresh messages in RSVP). These kinds of signaling messages are terminated by routers when they are not necessary anymore. Issues: Resource reservation capable routers must be prepared that there are other routers along the signaling path unable to interpret the actual resource reservation protocol. Even in this case the Feher, Cselenyi, Korn Expires May 2003 [Page 7] INTERNET-DRAFT November 2002 signaling messages must be delivered to all corresponding resource reservation capable routers (usually using some kind of tunneling). 6.2 Traffic Types This group of definitions defines traffic types forwarded by resource reservation capable routers. 6.2.1 Best-Effort Data Packets Definition: Best-effort data packet is a packet that has no associated resource reservation session in the routers and thus it is served in the "default" way. Discussion: Data packets that do not require QoS guarantees along their path are considered to be best-effort packets. "Best-effort" means that the router makes its best effort to forward the data packet quickly and safely, but does not guarantee anything (e.g. delay or loss probability). This type of traffic is the most common type in today's Internet. (There may be scenarios where resource reservation is done even for best-effort traffic too, but those are outside of the focus of this memo.) We will refer to the traffic of the best-effort data packets shortly as best-effort traffic. 6.2.2 Premium Data Packets Definition: Premium data packets are the packets that the resource reservation capable router distinguishes from best-effort packets and forwards them according to a QoS agreement. Discussion: Data packets that correspond to a resource reservation session in the router are premium data packets. The QoS treatment is defined in the associated resource reservation state (e.g. flow descriptor) that is established by signaling messages during the reservation session setup. The router may distinguish several types of premium. Data packets belonging to different types of premium traffic may receive different QoS treatment. We will refer to the traffic of the premium data packets shortly as premium traffic. Issues: The router has to identify every packet whether it belongs to any resource reservation session or not. This can be done by either multi-field classification [11] using the IP 5-tuple or the ToS field in the header of the IP packet. However, if a packet has an associated resource reservation session in the router, then the Feher, Cselenyi, Korn Expires May 2003 [Page 8] INTERNET-DRAFT November 2002 corresponding resource reservation states describing the QoS treatment has to be looked up. This look up procedure might be quite time consuming in routers with vast amounts of resource reservation sessions. 6.3 Router Load Types This group of definitions describes different load component types that impact only a specific part of the resource reservation capable router. Categorizing the router load is crucial, since the conventional router load metric expressing the processing power utilization of the router does not characterize precisely enough a the resource reservation capable router. In the case of routers supporting resource reservations it is also important to know the source of the processing power utilization. 6.3.1 Traffic Load Definition: Usually traffic load means the load that is raised by the data traffic forwarding task of the router. However, we define the traffic load as the volume of the input data traffic that causes the router to be loaded. Discussion: It is obvious that forwarding the data packets, which requires obtaining the routing information and transferring the data packet between network interfaces, requires processing power. In general router benchmarking measurements only this type of load is considered as the source of the processing power utilization. Although the traffic load is the dominant load component, benchmarking routers supporting resource reservations must consider other load components also in line with the resource reservation handling. Measurement unit: The amount of the traffic load is represented by the volume of the data traffic. The volume is measured by the transferred bits during a second, i.e. the measurement unit is bit per seconds (bps). 6.3.2 Session Load Definition: Similar to the traffic load, we define the session load as the number of reservation sessions in the router. Discussion: Each resource reservation capable router that employs a packet classifier algorithm distinguishing the flows referring to reservation sessions maintains resource reservation session states keeping track of the resource reservation dedication. Obviously, the more reservation session states are set up on the router, the Feher, Cselenyi, Korn Expires May 2003 [Page 9] INTERNET-DRAFT November 2002 more complex the traffic classification becomes, and the longer time it takes to look up the corresponding resource reservation session sate. Moreover, in most protocols, not only the traffic flows, but also the signaling messages that manipulate resource reservation sessions on the router have to identify themselves first, before taking any other actions. This kind of classification also gives extra work to the router. Issues: In the case of soft-state resource reservation capable routers, the session load also affects reservation session maintenance. The maintenance of timers that watchdog the reservation session refreshes and the refresh signaling messages may cause severe load on the router. Based on the initiating point of the refresh messages, resource reservation protocols can be divided into two groups. First, there are protocols where it is the responsibility of the signaling end-points to initiate refresh messages and these messages are forwarded along the whole signaling path refreshing the corresponding resource reservation session. Second, there are other protocols, where the reservation session refresh happens only between the two peering network nodes of the signaling path. In this latter case, the routers and signaling end-points have their own schedule for the refresh message initiation. The first approach lightens the load of the session maintenance task; however, the second approach bears the ability to adjust the signaling intensity along the signaling path. Measurement unit: The session load is measured by the number of reservation sessions in the router. 6.3.3 Signaling Load Definition: Similarly to the previous load types, the signaling load is determined by the incoming signaling message intensity. Discussion: The processing of signaling messages requires processor power that raises the load on the control plane of the router. In routers where the control plane and the data plane are not totally independent (e.g. certain parts of the tasks are served by the same processor; or the architecture has common memory buffers or transfer buses) the signaling load can have an impact on the router's packet forwarding performance as well. Most of the resource reservation protocols have several protocol primitives realized by different signaling message types. Each of these message types may require a different amount of processing power from the router. Feher, Cselenyi, Korn Expires May 2003 [Page 10] INTERNET-DRAFT November 2002 Measurement unit: The signaling load is characterized by the signaling intensity, which expresses how many signaling messages arrive to the router within a second. Thus the unit of the signaling intensity is [1/s]. 6.3.4 Signaling Burst Definition: The signaling burst denotes a certain number of signaling messages that arrive to the input port(s) of the router back-to-back, causing persistent load on the signaling message handler. Discussion: Back-to-back signaling messages on one port of the router form a typical signaling burst. However, other cases are imaginable, for example when signaling messages arrive on different ports simultaneously or with an overlap in time (i.e. when the tail of one signaling message is behind the head of another one arriving on another port). Measurement unit: The signaling burst is characterized by its length, which is the number of messages that have arrived within the burst. 6.4 Performance Metrics This group of definitions is the collection of the measurable impacts that a resource reservation protocol has over the tested router device it is running on. 6.4.1 Signaling Message Handling Time Definition: The signaling message handling time (or, in short, signal handling time) is the time that a signaling message spends inside the router before it is forwarded to the next node on the signaling path. Discussion: Depending on the type of the signaling message, the router also interprets the signaling messages, acts on them and usually forwards a modified signaling message. Thus the message handling time is usually longer than forwarding time of data packets of the same size. In addition, there might be also signaling message primitives that are drained or generated by the router. Thus, the signal handling time is defined as the time difference between the time when a signaling message is received and the time the corresponding processed signaling message is transmitted. If a signaling message is not forwarded on the router (see Signaling Path), the signal handling time is immeasurable; therefore it is not defined for such messages. Feher, Cselenyi, Korn Expires May 2003 [Page 11] INTERNET-DRAFT November 2002 In the case of signaling messages that carry information pertaining to multicast flows, the router might issue multiple signaling messages after processing. In this case, by definition, the signal handling time is the time interval elapsed between the arrival of the incoming signaling message and the departure of the last signaling message related to the received one. This metric depends on the load on the router, as other tasks may limit the processing power available to signaling message handling. In addition to the router load, the signal handling time may also be dependent on the type of the signaling message. For example, it usually takes a shorter time for the router to tear down a resource reservation session than to set it up. The signal handling time is an important characteristic as it directly affects the setup time of a session. Measurement unit: The unit of the signaling message handling time is the second. 6.4.2 Premium Traffic Delay Definition: Premium traffic delay is the forwarding time of a premium data packet passing through a resource reservation capable router. Discussion: Premium traffic packets must be classified first in order to assign the network resources dedicated to the flow. The time of the classification is added to the usual forwarding time (including the queuing) that a router would spend on the packet without any resource reservation capability. There are routers where the processing power is shared between the control plane and the data plane. This means that the processing of signaling messages may have an impact on the data forwarding performance of the router. In this case the premium traffic delay metric reflects the influence the two planes have on each other. Measurement unit: The unit of the premium traffic delay is the second. 6.4.3 Best-effort Traffic Delay Definition: Best-effort traffic delay is the forwarding time of a best-effort packet passing through a resource reservation capable router. Discussion: Marking the premium traffic packets also marks the best-effort traffic packets via the lack of marking. In this case the detection of the best-effort packets is straightforward, so the classification algorithms do not have any influence on the best- Feher, Cselenyi, Korn Expires May 2003 [Page 12] INTERNET-DRAFT November 2002 effort traffic. However, the processing power sharing between the control and data plane might still cause delays in the forwarding procedure of each packet. Measurement unit: The unit of the best-effort traffic delay is the second. 6.4.4 Signaling Message Loss Definition: Signaling message loss is the ratio of the actual and the expected number of signaling messages leaving a resource reservation capable router subtracted from one. Discussion: There are certain types of signaling messages required to be forwarded by the resource reservation capable router immediately when their processing is finished. However, due to the high router load or for other reasons, the forwarding or even the processing of these signaling messages might be canceled. To characterize such situations we introduce the signaling message loss metric expressing the ratio of the signaling messages that actually have left the router and those ones that were expected to leave the router as a result of the incoming sequence of signaling messages. Since the most frequent reason for the signaling message loss is the high router load, therefore this metric is suitable for sounding out the scalability limits of resource reservation capable routers. Issues: Sometimes it may be hard to determine whether a signaling message is still in the queues of the router or whether it has already been dropped. For this reason we define that a signaling message is lost if there is no appearing forwarded signaling message within a reasonable long time period. This time period should be adjusted to the actual resource reservation protocol and might also depend on the type of the message, too. For example, in the case of soft-state resource reservation capable routers the measurer may wait as much as the refresh period to detect the loss of a signaling message. Measurement unit: This measure has no unit; it is expressed by a real number, which is between zero and one (including the limits). 6.4.5 Session Refreshing Capacity Definition: The session refreshing capacity metric is applied for soft-state resource reservation capable routers only and tells the ratio of the truly refreshed reservation sessions and the number of sessions that should be refreshed during one refresh period. Feher, Cselenyi, Korn Expires May 2003 [Page 13] INTERNET-DRAFT November 2002 Discussion: When a soft-state resource reservation capable router is overloaded, it may happen that the router is not able to refresh all the registered reservation sessions having no time to run the session refresh task. In this case sooner or later the resource reservation sessions over the session refresh capacity are dropped even if the resource reservation end-points are still refreshing them. The session refreshing capacity sounds out the limit of the resource reservation session number that the router is capable to maintain. Measurement unit: This measure has no unit; it is expressed by a real number, which is between zero and one (including the limits). 6.4.6 Scalability Limit Definition: The scalability limit is the threshold between the steady state and the overloaded state of the device under test. Discussion: All existing routers have finite buffer memory and finite processing power. In the steady state of the router, the buffer memories are not fully utilized and the processing power is enough to cope with all tasks running on the router. As the router load increases the router has to postpone more and more tasks. These tasks (e.g. forwarding certain packets) are queued in the buffers, and processed later. However, there is a certain point where no more buffer memory is available or a task cannot be postponed any longer; thus, the router is forced to drop the packet or the activity. This way the overloaded state of the resource reservation capable router can be recognized by the fact that some kind of data (signaling or packet) or task (e.g. refreshing) loss occurs. The critical load condition when the router is still in the steady state but the smallest amount of constant load increase would drive it to the overloaded state is the scalability limit of the router. 7. Security Considerations As this document is solely for providing terminology and describes neither a protocol nor an implementation, there are no security considerations associated with this document. Feher, Cselenyi, Korn Expires May 2003 [Page 14] INTERNET-DRAFT November 2002 8. Acknowledgement We would like to thank the following individuals for their help in forming this document: Joakim Bergkvist and Norbert Vegh from Telia Research AB, Sweden, Krisztian Nemeth, Balazs Szabo, Gabor Kovacs and Peter Vary from the High Speed Networks Laboratory, Budapest University of Technology and Economics, Hungary. 9. References [1] Y. Bernet, et. al., "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000 [2] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997. [3] S. Bradner, "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991 [4] R. Mandeville, "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998 [5] G. Feher, K. Nemeth, M. Maliosz, "Boomerang : A Simple Protocol for Resource Reservation in IP Networks," Vancouver, IEEE Real- Time Technology and Applications Symposium, June 1999 [6] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism for the Internet", Computer Communication Review, on-line version, volume 29, number 2, April 1999 [7] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995 [8] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated Reservation in the Internet", Journal on High Speed Networks, Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998 [9] 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 [10] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997 [11] K. Nichols et al., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474 [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998 [13] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981 Feher, Cselenyi, Korn Expires May 2003 [Page 15] INTERNET-DRAFT November 2002 10. Authors' Addresses Gabor Feher Budapest University of Technology and Economics (BUTE) Department of Telecommunications and Telematics Magyar Tudosok krt. 2, H-1117, Budapest, Hungary Phone: +36 1 463-1538 Email: feher@ttt-atm.ttt.bme.hu Istvan Cselenyi Telia Research AB Vitsandsgatan 9B SE 12386, Farsta SWEDEN, Phone: +46 8 713-8173 Email: istvan.i.cselenyi@telia.se Andras Korn Budapest University of Technology and Economics (BUTE) Institute of Mathematics, Department of Analysis Egry Jozsef u. 2, H-1111 Budapest, Hungary Phone: +36 1 463-2475 Email: korn@math.bme.hu Feher, Cselenyi, Korn Expires May 2003 [Page 16]