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
<draft-ietf-bmwg-benchres-term-02.txt>
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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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 <draft-ietf-bmwg-benchres-term-02.txt> 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]