draft-ietf-bmwg-benchres-term-02.txt   draft-ietf-bmwg-benchres-term-03.txt 
Benchmarking Working Group Gabor Feher, BUTE Benchmarking Working Group Gabor Feher, BUTE
INTERNET-DRAFT Istvan Cselenyi, TRAB INTERNET-DRAFT Krisztian Nemeth, BUTE
Expiration Date: May 2003 Andras Korn, BUTE Expiration Date: December 2003 Andras Korn, BUTE
Istvan Cselenyi, TeliaSonera
November 2002 June 2003
Benchmarking Terminology for Routers Supporting Resource Reservation Benchmarking Terminology for Routers Supporting Resource Reservation
<draft-ietf-bmwg-benchres-term-02.txt> <draft-ietf-bmwg-benchres-term-03.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 44 skipping to change at line 45
this memo is unlimited. this memo is unlimited.
2. Table of contents 2. Table of contents
1. Status of this Memo.............................................1 1. Status of this Memo.............................................1
2. Table of contents...............................................1 2. Table of contents...............................................1
3. Abstract........................................................2 3. Abstract........................................................2
4. Introduction....................................................2 4. Introduction....................................................2
5. Existing definitions............................................3 5. Existing definitions............................................3
6. Definition of Terms.............................................3 6. Definition of Terms.............................................3
6.1 Resource Reservation Protocol Basics........................3 6.1 Traffic Flow Types..........................................3
6.1.1 Unicast Resource Reservation Session...................3 6.1.1 Data Flow..............................................3
6.1.2 Multicast Resource Reservation Session.................4 6.1.2 Distinguished Data Flow................................4
6.1.3 Resource Reservation Capable Router....................4 6.1.3 Best-Effort Data Flow..................................4
6.1.4 Signaling End-point....................................5 6.2 Resource Reservation Protocol Basics........................5
6.1.5 Reservation Orientation................................5 6.2.1 QoS Session............................................5
6.1.6 Reservation Session State..............................6 6.2.2 Resource Reservation Protocol..........................6
6.1.7 Signaling Path.........................................7 6.2.3 Resource Reservation Capable Router....................6
6.2 Traffic Types...............................................8 6.2.4 Reservation State......................................6
6.2.1 Best-Effort Data Packets...............................8
Feher, Cselenyi, Korn Expires May 2003 [Page 1] Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 1]
6.2.2 Premium Data Packets...................................8 6.2.5 Resource Reservation Protocol Orientation..............7
6.3 Router Load Types...........................................9 6.3 Router Load Factors.........................................8
6.3.1 Traffic Load...........................................9 6.3.1 Best-Effort Traffic Load Factor........................8
6.3.2 Session Load...........................................9 6.3.2 Distinguished Traffic Load Factor......................9
6.3.3 Signaling Load........................................10 6.3.3 Session Load Factor....................................9
6.3.4 Signaling Burst.......................................11 6.3.4 Signaling Intensity Load Factor.......................10
6.3.5 Signaling Burst Load Factor...........................10
6.4 Performance Metrics........................................11 6.4 Performance Metrics........................................11
6.4.1 Signaling Message Handling Time.......................11 6.4.1 Signaling Message Handling Time.......................11
6.4.2 Premium Traffic Delay.................................12 6.4.2 Distinguished Traffic Delay...........................12
6.4.3 Best-effort Traffic Delay.............................12 6.4.3 Best-effort Traffic Delay.............................12
6.4.4 Signaling Message Loss................................13 6.4.4 Signaling Message Loss................................13
6.4.5 Session Refreshing Capacity...........................13 6.4.5 Session Maintenance Capacity..........................13
6.4.6 Scalability Limit.....................................14 6.5 Scalability Limit..........................................14
7. Security Considerations........................................14 7. Security Considerations........................................15
8. Acknowledgement................................................15 8. Acknowledgements...............................................15
9. References.....................................................15 9. References.....................................................15
10. Authors' Addresses............................................16
3. Abstract 3. Abstract
The purpose of this document is to define terminology specific to the The purpose of this document is to define terminology specific to the
benchmarking of the resource reservation signaling of IP routers. benchmarking of the resource reservation signaling of IP routers.
These terms can be used in additional documents that define These terms can be used in additional documents that define
benchmarking methodologies for routers supporting resource benchmarking methodologies for routers that support resource
reservation and define reporting formats for the benchmarking reservation or reporting formats for the benchmarking measurements.
measurements.
4. Introduction 4. Introduction
The IntServ over DiffServ framework [1] outlines a heterogeneous Signaling based resource reservation (e.g. via RSVP [1]) is an
Quality of Service (QoS) architecture for multi domain Internet important part of the different QoS provisioning approaches.
services. Signaling based resource reservation (e.g. via RSVP [2]) is Therefore network operators who are planning to deploy signaling
an integral part of that model. While this approach significantly based resource reservation may want to scrutinize the scalability
lightens the load on most of the core routers, the performance of limitations of reservation capable routers and the impact of
border routers that handle QoS signaling is still crucial. Therefore signaling on their data forwarding performance.
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 An objective way of quantifying the scalability constraints of QoS
signaling is to perform measurements on routers that are capable of signaling is to perform measurements on routers that are capable of
resource reservation. This document defines terminology for specific resource reservation. This document defines terminology for a
set of tests that vendors or network operators can use to measure and specific set of tests that vendors or network operators can carry out
report the signaling performance characteristics of router devices to measure and report the signaling performance characteristics of
that support resource reservation protocols. The results of these router devices that support resource reservation protocols. The
tests provide comparable data for different products supporting the results of these tests provide comparable data for different
decision process before purchase. Moreover, these measurements products, and thus support the decision process before purchase.
provide input characteristics for the dimensioning of a network in Moreover, these measurements provide input characteristics for the
which resources are provisioned dynamically by signaling. Finally, dimensioning of a network in which resources are provisioned
the tests are applicable for characterizing the impact of the dynamically by signaling. Finally, the tests are applicable for
resource reservation signaling on the forwarding performance of the characterizing the impact of the resource reservation signaling on
routers. the forwarding performance of the routers.
Feher, Cselenyi, Korn Expires May 2003 [Page 2]
This benchmarking terminology document is based on the knowledge This benchmarking terminology document is based on the knowledge
gained by examination of (and experimentation with) several very gained by examination of (and experimentation with) different
different resource reservation protocols: RSVP [2], Boomerang [5], resource reservation protocols: the IETF standard RSVP [1] and
YESSIR [6], ST2+ [7], SDP [8] and Ticket [9]. Nevertheless, this several experimental ones, such as YESSIR [5], ST2+ [6], SDP [7],
document defines terms that are valid in general and not restricted
to these protocols. Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 2]
Boomerang [8] and Ticket [9]. Some of these protocols are also
analyzed in an IETF NSIS working group draft [10]. Although the
authors are only aware of resource reservation capable router
products that interpret RSVP, this document defines terms that are
valid in general and not restricted to any of the above listed
protocols.
In order to avoid any confusion we would like to emphasize that this
terminology considers only signaling protocols that provide IntServ
resource reservation; the DiffServ world, for example, is out of our
scope.
5. Existing definitions 5. Existing definitions
RFC 1242 [3] "Benchmarking Terminology for Network Interconnect RFC 1242 "Benchmarking Terminology for Network Interconnect
Devices" and RFC 2285 [4] "Benchmarking Terminology for LAN Switching Devices" [2] and RFC 2285 "Benchmarking Terminology for LAN Switching
Devices" contains discussions and definitions for a number of terms Devices" [3] contains discussions and definitions for a number of
relevant to the benchmarking of signaling performance of reservation terms relevant to the benchmarking of signaling performance of
capable routers and should be consulted before attempting to make use reservation capable routers and should be consulted before attempting
of this document. to make use of this document.
Additionally, throughout this document, an attempt is being made to
define terminology in a way that is consistent with the terms used by
Next Steps in Signaling working group laid out in [4].
For the sake of clarity and continuity this document adopts the For the sake of clarity and continuity this document adopts the
template for definitions set out in Section 2 of RFC 1242. template for definitions set out in Section 2 of RFC 1242.
Definitions are indexed and grouped together into different sections Definitions are indexed and grouped together into different sections
for ease of reference. for ease of reference.
6. Definition of Terms 6. Definition of Terms
6.1 Resource Reservation Protocol Basics 6.1 Traffic Flow Types
This group of definitions applies to various signaling based resource This group of definitions describes traffic flow types forwarded by
reservation protocols implemented on IP router devices. resource reservation capable routers.
6.1.1 Unicast Resource Reservation Session 6.1.1 Data Flow
Definition: Definition:
The term unicast resource reservation session (or shortly A data flow is a stream of data packets from one sender to one or
reservation session) expresses that two end-nodes explicitly more receivers, where each packet has a flow identifier unique to
request the network nodes, which forward their data flow, to the flow.
assign special QoS treatment for data packets belonging to the
flow.
Discussion: Discussion:
The QoS treatment is defined by specifying the amount of The flow identifier can be an arbitrary subset of the packet
networking resources that should be dedicated to the data flow header fields that uniquely distinguishes the flow from others.
during the length of the reservation session. There are different The 5-tuple "source address; source port; destination address;
approaches, how to specify the network resource requirement of a destination port; protocol number" is most commonly used for this
data flow. It can be described by high-level parameters, like the purpose (where port number are applicable). For more comment on
required bandwidth or the maximum data delay; or it can be low- flow identification refer to [4].
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]
however in extreme cases the transport address of the source
should be included as well.
See Also: Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 3]
Reservation Session State The flow identification can be time- and/or resource-consuming,
but this can sometimes be avoided as routers do not necessarily
have to classify every packet. Instead, packets that should be
classified by routers can be marked with special flags that
routers understand. One existing marking approach is to use the
ToS field of the IP header. Naturally, unmarked packets are not
classified by routers and this way valuable resources can be
saved.
6.1.2 Multicast Resource Reservation Session 6.1.2 Distinguished Data Flow
Definition: Definition:
A multicast resource reservation session (or, in short, multicast Distinguished data flows are flows that resource reservation
reservation session) denotes that end-nodes forming a multicast capable routers intentionally treat better or worse than
group ask the network nodes, which forward the data packets of the "ordinary" data flows, according to a QoS agreement defined for
multicast group, to assign a certain QoS treatment to their data the distinguished flow.
traffic.
Discussion: Discussion:
In a multicast group there can be several data traffic sources and Packets of distinguished data flows are marked so that the routers
destinations. The required QoS treatment is specified the same way that forward them know they require differentiated treatment.
as in the case of the unicast resource reservation sessions. In Routers classify these incoming packets and identify the data flow
the case of multicast reservations, however, unlike in the case of they belong to.
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: The most common usage of the distinguished data flow is to get
many-to-many and one-to-many. Those of the first type allow higher priority treatment than that of best-effort data flows (see
multicast data traffic to be originated from several sources, the next definition) flows. In these cases, a distinguished data
while those of the second type permit only one fix data traffic flow is sometimes referred to as a "premium data flow".
source in the whole multicast group that must not change during Theoretically, it is possible to require worse treatment than that
the lifetime of the session. of best-effort flows, however this is practically never done in
IntServ networks.
6.1.3 Resource Reservation Capable Router 6.1.3 Best-Effort Data Flow
Definition: Definition:
A router is resource reservation capable -- supports resource Best-effort data flows are flows that are not treated in any
reservation -- if it understands a resource reservation protocol special manner by resource reservation capable routers; thus,
that signals the set-up, tear-down and modification of resource their packets are served (forwarded) in some default way.
reservation sessions.
Discussion: Discussion:
Resource reservation protocols define signaling messages that are "Best-effort" means that the router makes its best effort to
interpreted by resource reservation capable routers. The router forward the data packet quickly and safely, but does not guarantee
captures the signaling message and manipulates the resource anything (e.g. delay or loss probability). This type of traffic is
reservation sessions and/or the reserved network resources the most common in today's Internet.
according to the content of the message.
Issues: In the case of best-effort data flow the packets are not specially
Despite that resource reservation sessions are considered to be marked and thus they are not classified by the routers.
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] Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 4]
(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 6.2 Resource Reservation Protocol Basics
This group of definitions applies to signaling based resource
reservation protocols implemented by IP router devices.
6.2.1 QoS Session
Definition: Definition:
A signaling end-point is a network node capable of initiating and A QoS session is an application layer concept, shared between a
terminating resource reservation sessions. set of network nodes, that pertains to a specific set of data
flows. The information associated with the session includes the
data required to identify the set of data flows in addition to a
specification of the QoS treatment they require.
Discussion: Discussion:
Besides traditional end-systems, there is also another type of A QoS session is an end-to-end relationship. Whenever end-nodes
signaling end-point: the reservation gateways. Reservation decide to obtain special QoS treatment for their data
gateways translate the signaling messages of one resource communication, they set up a QoS session; as part of the process,
reservation protocol into messages of another resource reservation they or their proxies make a QoS agreement with the network,
protocol. Thus the reservation gateway represents two signaling specifying their data flows and the QoS treatment that the flows
end-points in one, as it is both a signaling terminator and a require.
signaling initiator.
It is possible for the same QoS session to span multiple network
domains that have different resource provisioning architectures.
In this document, however, we only deal with the case where the
QoS session is realized over an IntServ architecture. It is
assumed that sessions will be established using signaling messages
of a resource reservation protocol.
QoS sessions must have unique identifiers; it must be possible to
determine which QoS session a given signaling message pertains to.
Therefore, each signaling message should include the identifier of
its corresponding session. As an example, in the case of RSVP, the
"session specification" identifies the QoS session plus refers to
the data flow; the "flowspec" specifies the desired QoS treatment
and the "filter spec" defines the subset of data packets in the
data flow that receive the QoS defined by the flowspec.
QoS sessions can be unicast or multicast depending on the number
of participants. In a multicast group there can be several data
traffic sources and destinations. Here the QoS agreement does not
have to be the same for each branch of the multicast tree
forwarding the data flow of the group. Instead, a dedicated
network resource in a router can be shared among many traffic
sources from the same multicast group (e.g. multicast reservation
styles in the case of RSVP).
Issues: Issues:
Typically, signaling end-points have a dedicated protocol stack, Even though QoS sessions are considered to be unique, resource
which interprets and generates the signaling messages. However, in reservation capable routers might aggregate them and allocate
some special cases, the resource reservation initiation is carried network resources to these aggregated sessions at once. The
out without the notice of the signaling terminating node. For aggregation can be based on similar data flow attributes (e.g.
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 Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 5]
similar destination addresses) 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 QoS sessions and might also lead to the violation of
the quality guaranties referring to individual data flows within
an aggregation [12].
6.2.2 Resource Reservation Protocol
Definition: Definition:
The reservation orientation tells which signaling end-point(s) Resource reservation protocols define signaling messages and
initiates the network resources allocation to obtain special QoS message processing rules used to control resource allocation in
treatment for the data traffic of the reservation session. IntServ architectures.
Discussion: Discussion:
Resource reservation protocols can be classified into two groups It is the signaling messages of a resource reservation protocol
depending on the relationship between the reservation initiators that carry the information related to QoS sessions. This
and their role in the data traffic flow. First, there are sender- information includes a session identifier, the actual QoS
oriented protocols, where the source(s) of the reservation parameters, and possibly flow descriptors.
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]
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 message processing rules of the signaling protocols ensure
The orientation of the reservation initiator affects the basics of that signaling messages reach all network nodes concerned. Some
the resource reservation protocols and therefore it is an resource reservation protocols (e.g. RSVP) are only concerned with
important design decision. In the case of multicast reservation this, i.e. carrying the QoS-related information to all the
sessions, the sender-oriented protocols require the traffic appropriate network nodes, without being aware of its content.
sources to maintain a list of receivers and send their allocation This approach allows changing the way the QoS parameters are
messages considering the requirements of the receivers. A less described and provisioning is done without the need to change the
polite, but less demanding solution is when the sources ignore the protocol itself.
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 6.2.3 Resource Reservation Capable Router
Definition: Definition:
A reservation session state is a holder for all the relevant A router is resource reservation capable (it supports resource
information about the corresponding reservation session registered reservation) if it is able to interpret signaling messages of a
in the resource reservation capable router. resource reservation protocol and based on these messages is able
to adjust the management of its flow classifiers and network
resources so as to conform with the content of the messages
Discussion: Discussion:
Resource reservation capable routers maintain reservation session Routers capture signaling messages and manipulates reservation
states to store information about the reservation session. This states and/or reserved network resources according to the content
information might include the QoS treatment that the reservation of the messages. This ensures that the flows are treated as their
session requires; the description of how and where to forward the specified QoS requirements indicate.
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 6.2.4 Reservation State
reservation capable router, the routers can be categorized into
three classes:
Hard-state resource reservation capable routers (e.g. ST2 capable Definition:
routers [7]) store the reservation session states permanently, A reservation state is the set of entries in the routerĂs memory
established by a set-up signaling primitive, until a corresponding that contain all relevant information about a given QoS session
tear-down signaling primitive arrives or until the router is registered with the router.
informed that the reservation session canceled.
There are also soft-state resource reservation capable routers, Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 6]
where there are no permanent reservation session states, but each Discussion:
States are needed because IntServ related resource reservation
protocols require the routers to keep track of QoS session and
data-flow-related metadata. The reservation state includes the
parameters of the QoS treatment; the description of how and where
to forward the incoming signaling messages; refresh timing
information; etc.
Feher, Cselenyi, Korn Expires May 2003 [Page 6] Based on how reservation states are stored in a reservation
state have to be regularly refreshed by appropriate refresh capable router, the routers can be categorized into two classes:
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 Hard-state resource reservation protocols (e.g. ST2 [6]) require
storing no information about the individual reservation sessions. routers to store the reservation states permanently, established
Without reservation session states the resource reservation by a set-up signaling primitive, until the router is explicitly
capabilities of such routers are limited, e.g. there is no support informed that the QoS session is canceled.
for many-to-many multicast resource reservation sessions; and the
reservation session must be sender oriented. There are also soft-state resource reservation capable routers,
where there are no permanent reservation states, and each state
has to be regularly refreshed by appropriate refresh signaling
messages. If no refresh signaling message arrives during a certain
period then the router stops the maintenance of the QoS session
assuming that the end-points do not intend to keep the session up
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 resources to stay permanently stuck
in the routers.
Issues: Issues:
Although soft-state reservation capable routers are more robust Based on the initiating point of the refresh messages, soft-state
than hard-state ones, the frequent processing of refresh signaling resource reservation protocols can be divided into two groups.
messages or the detection of the missing reservation session state First, there are protocols where it is the responsibility of the
refreshes might cause serious increase in the router load, which end-points or their proxies to initiate refresh messages. These
can be a base of the scalability problems. In order to decrease messages are forwarded along the path of the data flow refreshing
the number of refresh signaling messages, the resource reservation the corresponding reservation states in each router affected by
capable router might support various mechanisms to pack several the flow. Secondly, there are other protocols, where routers and
refresh signaling messages into one larger message. end-points have their own schedule for the reservation state
refreshes and they signal these refreshes to the neighboring
routers.
6.1.7 Signaling Path 6.2.5 Resource Reservation Protocol Orientation
Definition: Definition:
A signaling path is a sequence of network nodes and links along The orientation of a resource reservation protocol tells which end
which signaling messages travel from one signaling end-point to of the protocol communication initiates the allocation of the
the other. network resources. Thus, the protocol can be sender or receiver
initiated, depending on the location of the data flow source
(sender) and destination (receiver) compared to the reservation
initiator.
Discussion: Discussion:
Resource reservation capable routers must assure that all other In the case of sender-initiated protocols the resource reservation
router, which is responsible for handling the actual signaling propagates the same directions as of the data flow. Consequently,
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] Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 7]
signaling messages must be delivered to all corresponding resource in the case of receiver-initiated protocols the signaling messages
reservation capable routers (usually using some kind of reserving resources are forwarded backward on the path of the data
tunneling). flow. Due to the asymmetric routing nature of the Internet, in
this latter case, the path of the desired data flow should be
known before the reservation initiator would be able to send the
resource allocation messages. For example in the case of RSVP, the
RSVP PATH message [1], traveling from the data flow sources
towards the destinations, first marks the path of the data flow on
which the resource allocation messages will travel backward.
6.2 Traffic Types This definition considers only protocols that reserve resources
for just one data flow between the end-nodes. The reservation
orientation of protocols reserving more than one data flow is not
defined here.
This group of definitions defines traffic types forwarded by resource Issues:
reservation capable routers. The location 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 QoS sessions,
the sender-oriented protocols require the traffic sources to
maintain a list of receivers and send their allocation messages
considering the different requirements of the receivers. Using
multicast QoS 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.
6.2.1 Best-Effort Data Packets 6.3 Router Load Factors
Definition: The router load expressing the utilization the device naturally
Best-effort data packet is a packet that has no associated affects the performance of the router. During the benchmarking
resource reservation session in the routers and thus it is served process several load conditions have to be examined.
in the "default" way.
Discussion: This group of definitions describes different load components that
Data packets that do not require QoS guarantees along their path impact only a specific part of the resource reservation capable
are considered to be best-effort packets. "Best-effort" means that router.
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 6.3.1 Best-Effort Traffic Load Factor
Definition: Definition:
Premium data packets are the packets that the resource reservation The best-effort traffic load factor is defined as the volume of
capable router distinguishes from best-effort packets and forwards the best-effort data traffic that traverses the router in a
them according to a QoS agreement. second.
Discussion: Discussion:
Data packets that correspond to a resource reservation session in Forwarding the best-effort data packets, which requires obtaining
the router are premium data packets. The QoS treatment is defined the routing information and transferring the data packet between
in the associated resource reservation state (e.g. flow network interfaces, requires processing power, which is expressed
descriptor) that is established by signaling messages during the by this load factor.
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: Issues:
The router has to identify every packet whether it belongs to any The same amount of data segmented into differently sized packets
resource reservation session or not. This can be done by either causes different amounts of load on the router, which has to be
multi-field classification [11] using the IP 5-tuple or the ToS considered during the benchmarking measurements.
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]
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 Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 8]
that impact only a specific part of the resource reservation capable Measurement unit:
router. Categorizing the router load is crucial, since the bits per second (bps)
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 6.3.2 Distinguished Traffic Load Factor
Definition: Definition:
Usually traffic load means the load that is raised by the data The distinguished traffic load factor is defined as the volume of
traffic forwarding task of the router. However, we define the the distinguished data traffic that traverses the router in a
traffic load as the volume of the input data traffic that causes second.
the router to be loaded.
Discussion: Discussion:
It is obvious that forwarding the data packets, which requires Similarly to the best-effort data, forwarding the distinguished
obtaining the routing information and transferring the data packet data packets requires obtaining the routing information and
between network interfaces, requires processing power. In general transferring the data packet between network interfaces. However,
router benchmarking measurements only this type of load is in this case packets have to be classified as well, which requires
considered as the source of the processing power utilization. additional processing capacity.
Although the traffic load is the dominant load component,
benchmarking routers supporting resource reservations must Issues:
consider other load components also in line with the resource Just as in the best-effort case, the same amount of data segmented
reservation handling. into differently sized packets causes different amounts of load on
the router, which has to be considered during the benchmarking
measurements.
Measurement unit: Measurement unit:
The amount of the traffic load is represented by the volume of the bits per second (bps)
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 6.3.3 Session Load Factor
Definition: Definition:
Similar to the traffic load, we define the session load as the The session load factor is the number of QoS sessions the router
number of reservation sessions in the router. is keeping track of.
Discussion: Discussion:
Each resource reservation capable router that employs a packet Resource reservation capable routers maintain reservation states
classifier algorithm distinguishing the flows referring to keeping track of the QoS sessions. Obviously, the more reservation
reservation sessions maintains resource reservation session states states are registered with the router, the more complex the
keeping track of the resource reservation dedication. Obviously, traffic classification becomes, and the longer time it takes to
the more reservation session states are set up on the router, the look up the corresponding resource reservation sate. Moreover, not
only the traffic flows, but also the signaling messages that
Feher, Cselenyi, Korn Expires May 2003 [Page 9] control the reservation states have to be identified first, before
more complex the traffic classification becomes, and the longer taking any other action. This kind of classification also means
time it takes to look up the corresponding resource reservation extra work for the router.
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 protocols, the
In the case of soft-state resource reservation capable routers, session load also affects reservation state maintenance. For
the session load also affects reservation session maintenance. The example, the maintenance of timers that watchdog the reservation
maintenance of timers that watchdog the reservation session state refreshes may cause further load on the router.
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: Measurement unit:
The session load is measured by the number of reservation sessions This factor is measured by the number of QoS sessions impacting
in the router. the router, thus it has no unit.
6.3.3 Signaling Load Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 9]
6.3.4 Signaling Intensity Load Factor
Definition: Definition:
Similarly to the previous load types, the signaling load is The signaling intensity load factor is defined as the number of
determined by the incoming signaling message intensity. signaling messages that hit the router during one second.
Discussion: Discussion:
The processing of signaling messages requires processor power that The processing of signaling messages requires processor power that
raises the load on the control plane of the router. In routers raises the load on the control plane of the router.
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.
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,
transfer buses or any other resources) the signaling load can have
an impact on the router's packet forwarding performance as well.
Naturally, just as everywhere else in this document, the term
"signaling messages" refer only to the resource reservation
protocol related primitives.
Issues:
Most of the resource reservation protocols have several protocol Most of the resource reservation protocols have several protocol
primitives realized by different signaling message types. Each of primitives realized by different signaling message types. Each of
these message types may require a different amount of processing these message types may require a different amount of processing
power from the router. power from the router. This fact has to be considered during the
benchmarking measurements.
Feher, Cselenyi, Korn Expires May 2003 [Page 10]
Measurement unit: Measurement unit:
The signaling load is characterized by the signaling intensity, The unit of this factor is 1/second.
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 6.3.5 Signaling Burst Load Factor
Definition: Definition:
The signaling burst denotes a certain number of signaling messages The signaling burst load factor is defined as the number of
that arrive to the input port(s) of the router back-to-back, signaling messages that arrive to one input port of the router
causing persistent load on the signaling message handler. back-to-back [2], causing persistent load on the signaling message
handler.
Discussion: Discussion:
Back-to-back signaling messages on one port of the router form a The definition focuses on one input port only. A set of messages
typical signaling burst. However, other cases are imaginable, for arriving at different ports, but with such a timing that would be
example when signaling messages arrive on different ports a burst if the messages arrived at the same port, is not
simultaneously or with an overlap in time (i.e. when the tail of considered to be a burst. The reason for this is that it is not
one signaling message is behind the head of another one arriving guaranteed at a black-box test that this would have the same
on another port). effect on the router as a burst (incoming at the same interface)
has.
This definition conforms to the burst definition given in [3].
Issues:
Most of the resource reservation protocols have several protocol
primitives realized by different signaling message types. Bursts
built up of different messages may have a different effect on the
Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 10]
router. Consequently, during measurements the content of the burst
has to be considered as well.
Measurement unit: Measurement unit:
The signaling burst is characterized by its length, which is the This load factor is measured by the number of messages in the
number of messages that have arrived within the burst. burst, thus it has no unit.
6.4 Performance Metrics 6.4 Performance Metrics
This group of definitions is the collection of the measurable impacts This group of definitions is a collection of measurable quantities
that a resource reservation protocol has over the tested router that describe the impact the different load components have on the
device it is running on. router.
6.4.1 Signaling Message Handling Time 6.4.1 Signaling Message Handling Time
Definition: Definition:
The signaling message handling time (or, in short, signal handling The signaling message handling time (or, in short, signal handling
time) is the time that a signaling message spends inside the time) is the latency [2] of a signaling message passing through
router before it is forwarded to the next node on the signaling the router.
path.
Discussion: Discussion:
Depending on the type of the signaling message, the router also The router interprets the signaling messages, acts based on their
interprets the signaling messages, acts on them and usually content and usually forwards them in an unmodified or modified
forwards a modified signaling message. Thus the message handling form. Thus the message handling time is usually longer than the
time is usually longer than forwarding time of data packets of the forwarding time of data packets of the same size.
same size. In addition, there might be also signaling message
primitives that are drained or generated by the router. Thus, the There might be signaling message primitives, however, that are
signal handling time is defined as the time difference between the drained or generated by the router, like certain refresh messages.
time when a signaling message is received and the time the In this case the signal handling time is immeasurable, therefore
corresponding processed signaling message is transmitted. If a it is not defined for such messages.
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]
In the case of signaling messages that carry information In the case of signaling messages that carry information
pertaining to multicast flows, the router might issue multiple pertaining to multicast flows, the router might issue multiple
signaling messages after processing. In this case, by definition, signaling messages after processing them. In this case, by
the signal handling time is the time interval elapsed between the definition, the signal handling time is the latency between the
arrival of the incoming signaling message and the departure of the incoming signaling message and the last signaling message related
last signaling message related to the received one. to the received one.
This metric depends on the load on the router, as other tasks may The signal handling time may be dependent on the type of the
limit the processing power available to signaling message signaling message. For example, it usually takes a shorter time
handling. In addition to the router load, the signal handling time for the router to remove a reservation state than to set it up.
may also be dependent on the type of the signaling message. For This fact has to be considered during the benchmarking process.
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 The signal handling time is an important characteristic as it
directly affects the setup time of a session. directly affects the setup time of a QoS session.
Measurement unit: Measurement unit:
The unit of the signaling message handling time is the second. The unit of the signaling message handling time is the second.
6.4.2 Premium Traffic Delay Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 11]
6.4.2 Distinguished Traffic Delay
Definition: Definition:
Premium traffic delay is the forwarding time of a premium data Distinguished traffic delay is the latency [2] of a distinguished
packet passing through a resource reservation capable router. data packet passing through the tested router device.
Discussion: Discussion:
Premium traffic packets must be classified first in order to Distinguished traffic packets must be classified first in order to
assign the network resources dedicated to the flow. The time of assign the network resources dedicated to the flow. The time of
the classification is added to the usual forwarding time the classification is added to the usual forwarding time
(including the queuing) that a router would spend on the packet (including the queuing) that a router would spend on the packet
without any resource reservation capability. without any resource reservation capability. This classification
procedure might be quite time consuming in routers with vast
amounts of reservation states.
There are routers where the processing power is shared between the There are routers where the processing power is shared between the
control plane and the data plane. This means that the processing control plane and the data plane. This means that the processing
of signaling messages may have an impact on the data forwarding of signaling messages may have an impact on the data forwarding
performance of the router. In this case the premium traffic delay performance of the router. In this case the distinguished traffic
metric reflects the influence the two planes have on each other. delay metric is an indicator of the influence the two planes have
on each other.
Issues:
Queuing of the incoming data packets in routers might bias this
metric, measurement procedures have to consider this effect.
Measurement unit: Measurement unit:
The unit of the premium traffic delay is the second. The unit of the distinguished traffic delay is the second.
6.4.3 Best-effort Traffic Delay 6.4.3 Best-effort Traffic Delay
Definition: Definition:
Best-effort traffic delay is the forwarding time of a best-effort Best-effort traffic delay is the latency of a best-effort data
packet passing through a resource reservation capable router. packet traversing the tested router device.
Discussion: Discussion:
Marking the premium traffic packets also marks the best-effort If the processing power of the router is shared between the
traffic packets via the lack of marking. In this case the control and data plane, then the processing of signaling messages
detection of the best-effort packets is straightforward, so the may have an impact on the data forwarding performance of the
classification algorithms do not have any influence on the best- router. In this case the best-effort traffic delay metric is an
indicator of the influence the two planes have on each other.
Feher, Cselenyi, Korn Expires May 2003 [Page 12] Issues:
effort traffic. However, the processing power sharing between the Queuing of the incoming data packets in routers might bias this
control and data plane might still cause delays in the forwarding metric as well, so measurement procedures have to consider this
procedure of each packet. effect.
Measurement unit: Measurement unit:
The unit of the best-effort traffic delay is the second. The unit of the best-effort traffic delay is the second.
Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 12]
6.4.4 Signaling Message Loss 6.4.4 Signaling Message Loss
Definition: Definition:
Signaling message loss is the ratio of the actual and the expected Signaling message loss is the ratio of the actual and the expected
number of signaling messages leaving a resource reservation number of signaling messages leaving a resource reservation
capable router subtracted from one. capable router, subtracted from one.
Discussion: Discussion:
There are certain types of signaling messages required to be This definition gives the same value as the ratio of the lost and
forwarded by the resource reservation capable router immediately the expected messages. The reason for choosing the given
when their processing is finished. However, due to the high router definition is that the number of lost messages cannot be measured
load or for other reasons, the forwarding or even the processing directly.
of these signaling messages might be canceled. To characterize
such situations we introduce the signaling message loss metric There are certain types of signaling messages that are required to
be forwarded by reservation capable routers as soon as 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 expressing the ratio of the signaling messages that actually have
left the router and those ones that were expected to leave the left the router and those ones that were expected to leave the
router as a result of the incoming sequence of signaling messages. router.
Since the most frequent reason for the signaling message loss is Since the most frequent reason for signaling message loss is high
the high router load, therefore this metric is suitable for router load, this metric is suitable for sounding out the
sounding out the scalability limits of resource reservation scalability limits of resource reservation capable routers.
capable routers.
Issues: During the measurements one must be able to determine whether a
Sometimes it may be hard to determine whether a signaling message signaling message is still in the queues of the router or if it
is still in the queues of the router or whether it has already has already been dropped. For this reason we define a signaling
been dropped. For this reason we define that a signaling message message as lost if no forwarded signaling message is emitted
is lost if there is no appearing forwarded signaling message within a reasonably long time period. This period is defined along
within a reasonable long time period. This time period should be with the benchmarking methodology.
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: Measurement unit:
This measure has no unit; it is expressed by a real number, which This measure has no unit; it is expressed as a real number, which
is between zero and one (including the limits). is between zero and one, including the limits.
6.4.5 Session Refreshing Capacity 6.4.5 Session Maintenance Capacity
Definition: Definition:
The session refreshing capacity metric is applied for soft-state The session maintenance capacity metric is used in the case of
resource reservation capable routers only and tells the ratio of soft-state resource reservation protocols only. It gives the ratio
the truly refreshed reservation sessions and the number of of the number of QoS sessions actually maintained and the number
sessions that should be refreshed during one refresh period. of QoS sessions that should have been maintained during one
refresh period.
Feher, Cselenyi, Korn Expires May 2003 [Page 13]
Discussion: Discussion:
For soft-state protocols maintaining a QoS session means
refreshing the reservation states associated with it.
Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 13]
When a soft-state resource reservation capable router is When a soft-state resource reservation capable router is
overloaded, it may happen that the router is not able to refresh overloaded, it may happen that the router is not able to refresh
all the registered reservation sessions having no time to run the all the registered reservation states, because it does not have
session refresh task. In this case sooner or later the resource the time to run the state refresh task. In this case sooner or
reservation sessions over the session refresh capacity are dropped later some QoS sessions will be lost even if the endpoints still
even if the resource reservation end-points are still refreshing require their maintenance.
them.
The session refreshing capacity sounds out the limit of the The session maintenance capacity sounds out the maximal number of
resource reservation session number that the router is capable to QoS sessions that the router is capable of maintaining.
maintain.
Issues:
In the case of soft-state resource reservation protocols a router
that fails to maintain a QoS session will not generate refresh
signaling messages either. This has direct consequences on the
signaling message loss metric.
Measurement unit: Measurement unit:
This measure has no unit; it is expressed by a real number, which This measure has no unit; it is expressed as a real number, which
is between zero and one (including the limits). is between zero and one (including the limits).
6.4.6 Scalability Limit 6.5 Scalability Limit
Definition: Definition:
The scalability limit is the threshold between the steady state The scalability limit is the threshold between the steady state
and the overloaded state of the device under test. and the overloaded state of the device under test.
Discussion: Discussion:
All existing routers have finite buffer memory and finite All existing routers have finite buffer memory and finite
processing power. In the steady state of the router, the buffer processing power. In the steady state of the router, the buffer
memories are not fully utilized and the processing power is enough memories are not fully utilized and the processing power is enough
to cope with all tasks running on the router. As the router load to cope with all tasks running on the router. As the router load
increases the router has to postpone more and more tasks. These increases the buffers are starting to fill up and/or the router
tasks (e.g. forwarding certain packets) are queued in the buffers, has to postpone more and more tasks. However, there is a certain
and processed later. However, there is a certain point where no point where no more buffer memory is available, or a task cannot
more buffer memory is available or a task cannot be postponed any be postponed any longer; thus the router is forced to drop a
longer; thus, the router is forced to drop the packet or the packet or an activity. This way the overloaded state of the
activity. This way the overloaded state of the resource resource reservation capable router can be recognized by the fact
reservation capable router can be recognized by the fact that some that some kind of data (signaling or packet) or task (e.g. QoS
kind of data (signaling or packet) or task (e.g. refreshing) loss session maintenance) loss occurs.
occurs.
The critical load condition when the router is still in the steady The scalability limit of the router is the particular critical
state but the smallest amount of constant load increase would load condition when the router is still in the steady state but
drive it to the overloaded state is the scalability limit of the the smallest amount of additional load would drive it to the
router. overloaded state.
7. Security Considerations Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 14]
As this document is solely for providing terminology and describes 7. Security Considerations
neither a protocol nor an implementation, there are no security
considerations associated with this document.
Feher, Cselenyi, Korn Expires May 2003 [Page 14] As this document only provides terminology and describes neither a
protocol nor an implementation, there are no security considerations
associated with it.
8. Acknowledgement 8. Acknowledgements
We would like to thank the following individuals for their help in We would like to thank the following individuals for their help in
forming this document: Joakim Bergkvist and Norbert Vegh from Telia the research and development work, which contributed to form this
Research AB, Sweden, Krisztian Nemeth, Balazs Szabo, Gabor Kovacs and document: Joakim Bergkvist and Norbert Vegh from Telia Research AB,
Peter Vary from the High Speed Networks Laboratory, Budapest Sweden; Balazs Szabo, Gabor Kovacs and Peter Vary from the High Speed
University of Technology and Economics, Hungary. Networks Laboratory, Budapest University of Technology and Economics,
Hungary.
9. References 9. References
[1] Y. Bernet, et. al., "A Framework for Integrated Services [1] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) -
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. Version 1 Functional Specification", RFC 2205, September 1997.
[3] S. Bradner, "Benchmarking Terminology for Network [2] S. Bradner, "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991 Interconnection Devices", RFC 1242, July 1991
[4] R. Mandeville, "Benchmarking Terminology for LAN Switching [3] R. Mandeville, "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998 Devices", RFC 2285, February 1998
[5] G. Feher, K. Nemeth, M. Maliosz, "Boomerang : A Simple Protocol [4] R. Hancock (ed.), et. al., "Next Steps in Signaling: Framework",
for Resource Reservation in IP Networks," Vancouver, IEEE Real- IETF draft: draft-ietf-nsis-fw-02.txt (work in progress), 2003
Time Technology and Applications Symposium, June 1999
[6] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism [5] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism
for the Internet", Computer Communication Review, on-line for the Internet", Computer Communication Review, on-line
version, volume 29, number 2, April 1999 version, volume 29, number 2, April 1999
[7] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 [6] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2
(ST2) Protocol Specification - Version ST2+", RFC 1819, August (ST2) Protocol Specification - Version ST2+", RFC 1819, August
1995 1995
[8] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated [7] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated
Reservation in the Internet", Journal on High Speed Networks, Reservation in the Internet", Journal on High Speed Networks,
Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998 Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998
[8] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I.
Cselënyi, M. Maliosz, "Boomerang : A Simple Protocol for
Resource Reservation in IP Networks", Vancouver, IEEE Real-Time
Technology and Applications Symposium, June 1999
[9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight [9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight
Resource Reservation for Unicast IP Traffic", International WS Resource Reservation for Unicast IP Traffic", International WS
on QoS'98, IWQoS'98, May 18-20, 1998 on QoS'98, IWQoS'98, May 18-20, 1998
[10] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 15]
RFC 2210, September 1997 [10] J. Manner (ed.), X. Fu (ed.), "Analysis of Existing Quality of
Service Signaling Protocols", IETF draft: draft-ietf-nsis-
[11] K. Nichols et al., "Definition of the Differentiated Services signalling-analysis-01.txt (work in progress), 2003
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, [11] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
September 1981 RFC 2210, September 1997
Feher, Cselenyi, Korn Expires May 2003 [Page 15] [12] F. Baker,C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation
of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September
2001
10. Authors' Addresses Authors' Addresses
Gabor Feher Gabor Feher
Budapest University of Technology and Economics (BUTE) Budapest University of Technology and Economics
Department of Telecommunications and Telematics Department of Telecommunications and Mediainformatics
Magyar Tudosok krt. 2, H-1117, Budapest, Hungary Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
Phone: +36 1 463-1538 Phone: +36 1 463-1538
Email: feher@ttt-atm.ttt.bme.hu Email: Gabor.Feher@tmit.bme.hu
Istvan Cselenyi Krisztian Nemeth
Telia Research AB Budapest University of Technology and Economics
Vitsandsgatan 9B Department of Telecommunications and Mediainformatics
SE 12386, Farsta Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
SWEDEN, Phone: +36 1 463-1565
Phone: +46 8 713-8173 Email: Krisztian.Nemeth@tmit.bme.hu
Email: istvan.i.cselenyi@telia.se
Andras Korn Andras Korn
Budapest University of Technology and Economics (BUTE) Budapest University of Technology and Economics
Institute of Mathematics, Department of Analysis Institute of Mathematics, Department of Analysis
Egry Jozsef u. 2, H-1111 Budapest, Hungary Egry Jozsef u. 2, H-1111 Budapest, Hungary
Phone: +36 1 463-2475 Phone: +36 1 463-2475
Email: korn@math.bme.hu Email: Korn@math.bme.hu
Feher, Cselenyi, Korn Expires May 2003 [Page 16] Istvan Cselenyi
TeliaSonera International Carrier
Vaci ut 22-24, H-1132 Budapest, Hungary
Phone: +36 1 412-2705
Email: Istvan.Cselenyi@teliasonera.com
Feher, Nemeth, Korn, Cselenyi Expires December 2003 [Page 16]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/