draft-ietf-bmwg-benchres-term-08.txt   rfc4883.txt 
Benchmarking Working Group Gabor Feher, BUTE Network Working Group G. Feher
INTERNET-DRAFT Krisztian Nemeth, BUTE Request for Comments: 4883 K. Nemeth
Expiration Date: August 2007 Andras Korn, BUTE Category: Informational A. Korn
Istvan Cselenyi, TeliaSonera BUTE
I. Cselenyi
February 2007 TeliaSonera
Benchmarking Terminology for Resource Reservation Capable Routers Benchmarking Terminology for Resource Reservation Capable Routers
<draft-ietf-bmwg-benchres-term-08.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Status of This Memo
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This memo provides information for the Internet community. It does
http://www.ietf.org/shadow.html not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Table of contents
Abstract...........................................................2
1. Introduction....................................................2
2. Existing definitions............................................3
3. Definition of Terms.............................................3
3.1 Traffic Flow Types..........................................3
3.1.1 Data Flow..............................................4
3.1.2 Distinguished Data Flow................................4
3.1.3 Best-Effort Data Flow..................................4
3.2 Resource Reservation Protocol Basics........................5
3.2.1 QoS Session............................................5
3.2.2 Resource Reservation Protocol..........................6
3.2.3 Resource Reservation Capable Router....................6
3.2.4 Reservation State......................................7
3.2.5 Resource Reservation Protocol Orientation..............8
3.3 Router Load Factors.........................................8
3.3.1 Best-Effort Traffic Load Factor........................9
3.3.2 Distinguished Traffic Load Factor......................9
3.3.3 Session Load Factor...................................10
3.3.4 Signaling Intensity Load Factor.......................11
3.3.5 Signaling Burst Load Factor...........................11
3.4 Performance Metrics........................................12
3.4.1 Signaling Message Handling Time.......................12
3.4.2 Distinguished Traffic Delay...........................13
3.4.3 Best-effort Traffic Delay.............................14
3.4.4 Signaling Message Deficit.............................14
3.4.5 Session Maintenance Capacity..........................15
3.5 Router Load Conditions and Scalability Limit...............16
3.5.1 Loss-Free Condition...................................16
3.5.2 Lossy Condition.......................................17
3.5.3 QoS Compliant Condition...............................18
3.5.4 Not QoS Compliant Condition...........................18
3.5.5 Scalability Limit.....................................18
4. Security Considerations........................................19
5. IANA Considerations............................................19
6. Acknowledgements...............................................20
7. References.....................................................20
7.1 Normative References.......................................20
7.2 Informative References.....................................20
Authors' Addresses................................................21
Disclaimer of Validity............................................22
Copyright Notice..................................................22
Disclaimer........................................................22
Abstract Abstract
The primary purpose of this document is to define terminology The primary purpose of this document is to define terminology
specific to the benchmarking of resource reservation signaling of specific to the benchmarking of resource reservation signaling of
Integrated Services IP routers. These terms can be used in Integrated Services (IntServ) IP routers. These terms can be used in
additional documents that define benchmarking methodologies for additional documents that define benchmarking methodologies for
routers that support resource reservation or reporting formats for routers that support resource reservation or reporting formats for
the benchmarking measurements. the benchmarking measurements.
Table of Contents
1. Introduction ....................................................2
2. Existing Definitions ............................................3
3. Definition of Terms .............................................4
3.1. Traffic Flow Types .........................................4
3.1.1. Data Flow ...........................................4
3.1.2. Distinguished Data Flow .............................4
3.1.3. Best-Effort Data Flow ...............................5
3.2. Resource Reservation Protocol Basics .......................5
3.2.1. QoS Session .........................................5
3.2.2. Resource Reservation Protocol .......................6
3.2.3. Resource Reservation Capable Router .................7
3.2.4. Reservation State ...................................7
3.2.5. Resource Reservation Protocol Orientation ...........8
3.3. Router Load Factors ........................................9
3.3.1. Best-Effort Traffic Load Factor .....................9
3.3.2. Distinguished Traffic Load Factor ..................10
3.3.3. Session Load Factor ................................11
3.3.4. Signaling Intensity Load Factor ....................11
3.3.5. Signaling Burst Load Factor ........................12
3.4. Performance Metrics .......................................13
3.4.1. Signaling Message Handling Time ....................13
3.4.2. Distinguished Traffic Delay ........................14
3.4.3. Best-effort Traffic Delay ..........................15
3.4.4. Signaling Message Deficit ..........................15
3.4.5. Session Maintenance Capacity .......................16
3.5. Router Load Conditions and Scalability Limit ..............17
3.5.1. Loss-Free Condition ................................17
3.5.2. Lossy Condition ....................................18
3.5.3. QoS Compliant Condition ............................19
3.5.4. Not QoS Compliant Condition ........................20
3.5.5. Scalability Limit ..................................20
4. Security Considerations ........................................21
5. Acknowledgements ...............................................21
6. References .....................................................21
6.1. Normative References ......................................21
6.2. Informative References ....................................21
1. Introduction 1. Introduction
Signaling based resource reservation using the IntServ paradigm [3] Signaling-based resource reservation using the IntServ paradigm [4]
is an important part of the different QoS provisioning approaches. is an important part of the different Quality of Service (QoS)
Therefore network operators who are planning to deploy signaling provisioning approaches. Therefore, network operators who are
based resource reservation may want to examine the scalability planning to deploy signaling-based resource reservation may want to
limitations of reservation capable routers and the impact of examine the scalability limitations of reservation capable routers
signaling on their data forwarding performance. and the impact of signaling on their data forwarding performance.
An objective way of 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
IntServ based resource reservation. This document defines IntServ-based resource reservation. This document defines
terminology for a specific set of tests that vendors or network terminology for a specific set of tests that vendors or network
operators can carry out to measure and report the signaling operators can carry out to measure and report the signaling
performance characteristics of router devices that support resource performance characteristics of router devices that support resource
reservation protocols. The results of these tests provide comparable reservation protocols. The results of these tests provide comparable
data for different products, and thus support the decision-making data for different products, and thus support the decision-making
process before purchase. Moreover, these measurements provide input process before purchase. Moreover, these measurements provide input
characteristics for the dimensioning of a network in which resources characteristics for the dimensioning of a network in which resources
are provisioned dynamically by signaling. Finally, the tests are are provisioned dynamically by signaling. Finally, the tests are
applicable for characterizing the impact of the resource reservation applicable for characterizing the impact of the resource reservation
signaling on the forwarding performance of the routers. signaling on the forwarding performance of the routers.
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) different gained by examination of (and experimentation with) different
resource reservation protocols: the IETF standard RSVP [4], NSIS resource reservation protocols: the IETF standard Resource
[5][6][7][8] and several experimental ones, such as YESSIR [9], ST2+ ReSerVation Protocol (RSVP) [5], Next Steps in Signaling (NSIS)
[10], SDP [11], Boomerang [12] and Ticket [13]. Some of these [6][7][8][9], and several experimental ones, such as YESSIR (Yet
protocols were also analyzed by the IETF NSIS working group [14]. Another Sender Session Internet Reservation) [10], ST2+ [11], Session
Although at the moment the authors are only aware of resource Description Protocol (SDP) [12], Boomerang [13], and Ticket [14].
reservation capable router products that interpret RSVP, this Some of these protocols were also analyzed by the IETF NSIS working
document defines terms that are valid in general and not restricted group [15]. Although at the moment the authors are only aware of
to any of the above listed protocols. resource reservation capable router products that interpret RSVP,
this document defines terms that are valid in general and not
restricted to any of the protocols listed above.
In order to avoid any confusion we would like to emphasize that this In order to avoid any confusion, we would like to emphasize that this
terminology considers only signaling protocols that provide IntServ terminology considers only signaling protocols that provide IntServ
resource reservation; for example, techniques in the DiffServ resource reservation; for example, techniques in the DiffServ toolbox
toolbox are predominantly beyond our scope. are predominantly beyond our scope.
2. Existing definitions 2. Existing Definitions
RFC 1242 "Benchmarking Terminology for Network Interconnect RFC 1242 "Benchmarking Terminology for Network Interconnection
Devices" [1] and RFC 2285 "Benchmarking Terminology for LAN Devices" [1] and RFC 2285 "Benchmarking Terminology for LAN Switching
Switching Devices" [2] contain discussions and definitions for a Devices" [3] contain discussions and definitions for a number of
number of terms relevant to the benchmarking of signaling terms relevant to the benchmarking of signaling performance of
performance of reservation capable routers and should be consulted reservation-capable routers and should be consulted before attempting
before attempting to make use of this document. to make use of this document.
Additionally, this document defines terminology in a way that is Additionally, this document defines terminology in a way that is
consistent with the terms used by Next Steps in Signaling working consistent with the terms used by the Next Steps in Signaling working
group laid out in [5][6][7]. group laid out in [6][7][8].
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119 [2].
3. Definition of Terms 3. Definition of Terms
3.1 Traffic Flow Types 3.1. Traffic Flow Types
This group of definitions describes traffic flow types forwarded by This group of definitions describes traffic flow types forwarded by
resource reservation capable routers. resource reservation capable routers.
3.1.1 Data Flow 3.1.1. Data Flow
Definition: Definition:
A data flow is a stream of data packets from one sender to one or A data flow is a stream of data packets from one sender to one or
more receivers, where each packet has a flow identifier unique to more receivers, where each packet has a flow identifier unique to
the flow. the flow.
Discussion: Discussion:
The flow identifier can be an arbitrary subset of the packet The flow identifier can be an arbitrary subset of the packet
header fields that uniquely distinguishes the flow from others. header fields that uniquely distinguishes the flow from others.
For example, the 5-tuple "source address; source port; destination For example, the 5-tuple "source address; source port; destination
address; destination port; protocol number" is commonly used for address; destination port; protocol number" is commonly used for
this purpose (where port numbers are applicable). It is also this purpose (where port numbers are applicable). It is also
possible to take advantage of the Flow Label field of IPv6 possible to take advantage of the Flow Label field of IPv6
packets. For more comment on flow identification refer to [5]. packets. For more comments on flow identification, refer to [6].
3.1.2 Distinguished Data Flow 3.1.2. Distinguished Data Flow
Definition: Definition:
Distinguished data flows are flows that resource reservation Distinguished data flows are flows that resource reservation
capable routers intentionally treat better or worse than best- capable routers intentionally treat better or worse than best-
effort data flows, according to a QoS agreement defined for the effort data flows, according to a QoS agreement defined for the
distinguished flow. distinguished flow.
Discussion: Discussion:
Routers classify the packets of distinguished data flows and Routers classify the packets of distinguished data flows and
identify the data flow they belong to. identify the data flow to which they belong.
The most common usage of the distinguished data flow is to get The most common usage of the distinguished data flow is to get
higher priority treatment than that of best-effort data flows (see higher-priority treatment than that of best-effort data flows (see
the next definition). In these cases, a distinguished data flow is the next definition). In these cases, a distinguished data flow
sometimes referred to as a "premium data flow". Nevertheless is sometimes referred to as a "premium data flow". Nevertheless,
theoretically it is possible to require worse treatment than that theoretically it is possible to require worse treatment than that
of best-effort flows. of best-effort flows.
3.1.3 Best-Effort Data Flow 3.1.3. Best-Effort Data Flow
Definition: Definition:
Best-effort data flows are flows that are not treated in any Best-effort data flows are flows that are not treated in any
special manner by resource reservation capable routers; thus, special manner by resource reservation capable routers; thus,
their packets are served (forwarded) in some default way. their packets are served (forwarded) in some default way.
Discussion: Discussion:
"Best-effort" means that the router makes its best effort to "Best-effort" means that the router makes its best effort to
forward the data packet quickly and safely, but does not guarantee forward the data packet quickly and safely, but does not guarantee
anything (e.g. delay or loss probability). This type of traffic is anything (e.g., delay or loss probability). This type of traffic
the most common in today's Internet. is the most common in today's Internet.
Packets that belong to best-effort data flows need not be Packets that belong to best-effort data flows need not be
classified by the routers; that is, the routers don't need to find classified by the routers; that is, the routers don't need to find
a related reservation session in order to find out what treatment a related reservation session in order to find out to which
the packet is entitled to. treatment the packet is entitled.
3.2 Resource Reservation Protocol Basics 3.2. Resource Reservation Protocol Basics
This group of definitions applies to signaling based resource This group of definitions applies to signaling-based resource
reservation protocols implemented by IP router devices. reservation protocols implemented by IP router devices.
3.2.1 QoS Session 3.2.1. QoS Session
Definition: Definition:
A QoS session is an application layer concept, shared between a A QoS session is an application layer concept, shared between a
set of network nodes, that pertains to a specific set of data set of network nodes, that pertains to a specific set of data
flows. The information associated with the session includes the flows. The information associated with the session includes the
data required to identify the set of data flows in addition to a data required to identify the set of data flows in addition to a
specification of the QoS treatment they require. specification of the QoS treatment they require.
Discussion: Discussion:
A QoS session is an end-to-end relationship. Whenever end-nodes A QoS session is an end-to-end relationship. Whenever end-nodes
decide to obtain special QoS treatment for their data decide to obtain special QoS treatment for their data
communication, they set up a QoS session; as part of the process, communication, they set up a QoS session. As part of the process,
they or their proxies make a QoS agreement with the network, they or their proxies make a QoS agreement with the network,
specifying their data flows and the QoS treatment that the flows specifying their data flows and the QoS treatment that the flows
require. require.
It is possible for the same QoS session to span multiple network It is possible for the same QoS session to span multiple network
domains that have different resource provisioning architectures. domains that have different resource provisioning architectures.
In this document, however, we only deal with the case where the In this document, however, we only deal with the case where the
QoS session is realized over an IntServ architecture. It is QoS session is realized over an IntServ architecture. It is
assumed that sessions will be established using signaling messages assumed that sessions will be established using signaling messages
of a resource reservation protocol. of a resource reservation protocol.
QoS sessions must have unique identifiers; it must be possible to QoS sessions must have unique identifiers; it must be possible to
determine which QoS session a given signaling message pertains to. determine to which QoS session a given signaling message pertains.
Therefore, each signaling message should include the identifier of Therefore, each signaling message should include the identifier of
its corresponding session. As an example, in the case of RSVP, the its corresponding session. As an example, in the case of RSVP,
"session specification" identifies the QoS session plus refers to the "session specification" identifies the QoS session plus refers
the data flow; the "flowspec" specifies the desired QoS treatment to the data flow; the "flowspec" specifies the desired QoS
and the "filter spec" defines the subset of data packets in the treatment and the "filter spec" defines the subset of data packets
data flow that receive the QoS defined by the flowspec. in the data flow that receive the QoS defined by the flowspec.
QoS sessions can be unicast or multicast depending on the number QoS sessions can be unicast or multicast depending on the number
of participants. In a multicast group there can be several data of participants. In a multicast group, there can be several data
traffic sources and destinations. Here the QoS agreement does not traffic sources and destinations. Here the QoS agreement does not
have to be the same for each branch of the multicast tree have to be the same for each branch of the multicast tree
forwarding the data flow of the group. Instead, a dedicated forwarding the data flow of the group. Instead, a dedicated
network resource in a router can be shared among many traffic network resource in a router can be shared among many traffic
sources from the same multicast group (c.f. multicast reservation sources from the same multicast group (cf. multicast reservation
styles in the case of RSVP). styles in the case of RSVP).
Issues: Issues:
Even though QoS sessions are considered to be unique, resource Even though QoS sessions are considered to be unique, resource
reservation capable routers might aggregate them and allocate reservation capable routers might aggregate them and allocate
network resources to these aggregated sessions at once. The network resources to these aggregated sessions at once. The
aggregation can be based on similar data flow attributes (e.g. aggregation can be based on similar data flow attributes (e.g.,
similar destination addresses) or it can combine arbitrary similar destination addresses) or it can combine arbitrary
sessions as well. While reservation aggregation significantly sessions as well. While reservation aggregation significantly
lightens the signaling processing task of a resource reservation lightens the signaling processing task of a resource reservation
capable router, it also requires the administration of the capable router, it also requires the administration of the
aggregated QoS sessions and might also lead to the violation of aggregated QoS sessions and might also lead to the violation of
the quality guaranties referring to individual data flows within the quality guaranties referring to individual data flows within
an aggregation [15]. an aggregation [16].
3.2.2 Resource Reservation Protocol 3.2.2. Resource Reservation Protocol
Definition: Definition:
Resource reservation protocols define signaling messages and Resource reservation protocols define signaling messages and
message processing rules used to control resource allocation in message processing rules used to control resource allocation in
IntServ architectures. IntServ architectures.
Discussion: Discussion:
It is the signaling messages of a resource reservation protocol It is the signaling messages of a resource reservation protocol
that carry the information related to QoS sessions. This that carry the information related to QoS sessions. This
information includes a session identifier, the actual QoS information includes a session identifier, the actual QoS
parameters, and possibly flow descriptors. parameters, and possibly flow descriptors.
The message processing rules of the signaling protocols ensure The message processing rules of the signaling protocols ensure
that signaling messages reach all network nodes concerned. Some that signaling messages reach all network nodes concerned. Some
resource reservation protocols (e.g. RSVP, NSIS QoS NSLP[7]) are resource reservation protocols (e.g., RSVP, NSIS QoS NSLP [8]) are
only concerned with this, i.e. carrying the QoS-related only concerned with this, i.e., carrying the QoS-related
information to all the appropriate network nodes, without being information to all the appropriate network nodes, without being
aware of its content. This latter approach allows changing the way aware of its content. This latter approach allows changing the
the QoS parameters are described, and different kinds of way the QoS parameters are described, and different kinds of
provisioning can be realized without the need to change the provisioning can be realized without the need to change the
protocol itself. protocol itself.
3.2.3 Resource Reservation Capable Router 3.2.3. Resource Reservation Capable Router
Definition: Definition:
A router is resource reservation capable (it supports resource A router is resource reservation capable (it supports resource
reservation) if it is able to interpret signaling messages of a reservation) if it is able to interpret signaling messages of a
resource reservation protocol, and based on these messages is able resource reservation protocol, and based on these messages is able
to adjust the management of its flow classifiers and network to adjust the management of its flow classifiers and network
resources so as to conform to the content of the signaling resources so as to conform to the content of the signaling
messages. messages.
Discussion: Discussion:
Routers capture signaling messages and manipulate reservation Routers capture signaling messages and manipulate reservation
states and/or reserved network resources according to the content states and/or reserved network resources according to the content
of the messages. This ensures that the flows are treated as their of the messages. This ensures that the flows are treated as their
specified QoS requirements indicate. specified QoS requirements indicate.
3.2.4 Reservation State 3.2.4. Reservation State
Definition: Definition:
A reservation state is the set of entries in the router's memory A reservation state is the set of entries in the router's memory
that contain all relevant information about a given QoS session that contain all relevant information about a given QoS session
registered with the router. registered with the router.
Discussion: Discussion:
States are needed because IntServ related resource reservation States are needed because IntServ-related resource reservation
protocols require the routers to keep track of QoS session and protocols require the routers to keep track of QoS session and
data-flow-related metadata. The reservation state includes the data-flow-related metadata. The reservation state includes the
parameters of the QoS treatment; the description of how and where parameters of the QoS treatment, the description of how and where
to forward the incoming signaling messages; refresh timing to forward the incoming signaling messages, refresh timing
information; etc. information, etc.
Based on how reservation states are stored in a reservation Based on how reservation states are stored in a reservation
capable router, the routers can be categorized into two classes: capable router, the routers can be categorized into two classes:
Hard-state resource reservation protocols (e.g. ST2 [10]) require Hard-state resource reservation protocols (e.g., ST2 [11]) require
routers to store the reservation states permanently, established routers to store the reservation states permanently, established
by a set-up signaling primitive, until the router is explicitly by a setup signaling primitive, until the router is explicitly
informed that the QoS session is canceled. informed that the QoS session is canceled.
There are also soft-state resource reservation capable routers, There are also soft-state resource reservation capable routers,
where there are no permanent reservation states, and each state where there are no permanent reservation states, and each state
has to be regularly refreshed by appropriate refresh signaling has to be regularly refreshed by appropriate refresh signaling
messages. If no refresh signaling message arrives during a certain messages. If no refresh signaling message arrives during a
period then the router stops the maintenance of the QoS session certain period, then the router stops the maintenance of the QoS
assuming that the end-points do not intend to keep the session up session assuming that the end-points do not intend to keep the
any longer or the communication lines are broken somewhere along session up any longer or the communication lines are broken
the data path. This feature makes soft-state resource reservation somewhere along the data path. This feature makes soft-state
capable routers more robust than hard-state routers, since no resource reservation capable routers more robust than hard-state
failures can cause resources to stay permanently stuck in the routers, since no failures can cause resources to stay permanently
routers. (Note that it is still possible to have an explicit stuck in the routers. (Note that it is still possible to have an
teardown message in soft-state protocols for quicker resource explicit teardown message in soft-state protocols for quicker
release.) resource release.)
Issues: Issues:
Based on the initiating point of the refresh messages, soft-state Based on the initiating point of the refresh messages, soft-state
resource reservation protocols can be divided into two groups. resource reservation protocols can be divided into two groups.
First, there are protocols where it is the responsibility of the First, there are protocols where it is the responsibility of the
end-points or their proxies to initiate refresh messages. These end-points or their proxies to initiate refresh messages. These
messages are forwarded along the path of the data flow refreshing messages are forwarded along the path of the data flow refreshing
the corresponding reservation states in each router affected by the corresponding reservation states in each router affected by
the flow. Secondly, there are other protocols, where routers and the flow. Second, there are other protocols, where routers and
end-points have their own schedule for the reservation state end-points have their own schedule for the reservation state
refreshes and they signal these refreshes to the neighboring refreshes and they signal these refreshes to the neighboring
routers. routers.
3.2.5 Resource Reservation Protocol Orientation 3.2.5. Resource Reservation Protocol Orientation
Definition: Definition:
The orientation of a resource reservation protocol tells which end The orientation of a resource reservation protocol tells which end
of the protocol communication initiates the allocation of the of the protocol communication initiates the allocation of the
network resources. Thus, the protocol can be sender or receiver network resources. Thus, the protocol can be sender- or
initiated, depending on the location of the data flow source receiver-oriented, depending on the location of the data flow
(sender) and destination (receiver) compared to the reservation source (sender) and destination (receiver) compared to the
initiator. reservation initiator.
Discussion: Discussion:
In the case of sender-initiated protocols the resource reservation In the case of sender-oriented protocols (in some sources referred
propagates the same directions as of the data flow. Consequently, to as sender-initiated protocols), the resource reservation
in the case of receiver-initiated protocols the signaling messages propagates in the same direction(s) as of the data flow(s).
reserving resources are forwarded backward on the path of the data Consequently, in the case of receiver-oriented protocols, the
flow. Due to the asymmetric routing nature of the Internet, in signaling messages reserving resources are forwarded backward on
this latter case, the path of the desired data flow should be the path of the data flow. Due to the asymmetric routing nature
known before the reservation initiator would be able to send the of the Internet, in this latter case, the path of the desired data
resource allocation messages. For example in the case of RSVP, the flow should be known before the reservation initiator would be
RSVP PATH message, traveling from the data flow sources towards able to send the resource allocation messages. For example, in
the destinations, first marks the path of the data flow on which the case of RSVP, the RSVP PATH message, traveling from the data
the resource allocation messages will travel backward. flow sources towards the destinations, first marks the path of the
data flow on which the resource allocation messages will travel
backward.
This definition considers only protocols that reserve resources This definition considers only protocols that reserve resources
for just one data flow between the end-nodes. The reservation for just one data flow between the end-nodes. The reservation
orientation of protocols that reserve more than one data flow is orientation of protocols that reserve more than one data flow is
not defined here. not defined here.
Issues: Issues:
The location of the reservation initiator affects the basics of The location of the reservation initiator affects the basics of
the resource reservation protocols and therefore is an important the resource reservation protocols and therefore is an important
aspect of characterization. Most importantly, in the case of aspect of characterization. Most importantly, in the case of
multicast QoS sessions, the sender-oriented protocols require the multicast QoS sessions, the sender-oriented protocols require the
traffic sources to maintain a list of receivers and send their traffic sources to maintain a list of receivers and send their
allocation messages considering the different requirements of the allocation messages considering the different requirements of the
receivers. Using multicast QoS sessions, the receiver-oriented receivers. Using multicast QoS sessions, the receiver-oriented
protocols enable the receivers to manage their own resource protocols enable the receivers to manage their own resource
allocation requests and thus ease the task of the sources. allocation requests and thus ease the task of the sources.
3.3 Router Load Factors 3.3. Router Load Factors
When a router is under "load", it means that there are tasks its When a router is under "load", it means that there are tasks its
CPU(s) must attend to; and/or that its memory contains data it must CPU(s) must attend to, and/or that its memory contains data it
keep track of; and/or that its interface buffers are utilized to must keep track of, and/or that its interface buffers are utilized
some extent; etc. Unfortunately, we cannot assume that the full to some extent, etc. Unfortunately, we cannot assume that the
internal state of a router can be monitored during a benchmark; full internal state of a router can be monitored during a
rather, we must consider the router to be a black box. benchmark; rather, we must consider the router to be a black box.
We need to look at router "load" in a way that makes this "load" We need to look at router "load" in a way that makes this "load"
measurable and controllable. Instead of focusing on the internal measurable and controllable. Instead of focusing on the internal
processes of a router, we will consider the external, and therefore processes of a router, we will consider the external, and
observable, measurable and controllable processes that result in therefore observable, measurable and controllable processes that
"load". result in "load".
In this chapter we introduce several ways of creating "load" on a In this section we introduce several ways of creating "load" on a
router; we will refer to these as "load factors" henceforth. These router; we will refer to these as "load factors" henceforth.
load factors are defined so that they each impact the performance of These load factors are defined so that they each impact the
the router in a different way (or by different means), by utilizing performance of the router in a different way (or by different
different components of a resource reservation capable router as means), by utilizing different components of a resource
separately as possible. reservation capable router as separately as possible.
During a benchmark, the performance of the device under test will During a benchmark, the performance of the device under test will
have to be measured under different controlled load conditions, that have to be measured under different controlled load conditions,
is, with different values of these load factors. that is, with different values of these load factors.
3.3.1 Best-Effort Traffic Load Factor 3.3.1. Best-Effort Traffic Load Factor
Definition: Definition:
The best-effort traffic load factor is defined as the number and The best-effort traffic load factor is defined as the number and
length of equal-sized best-effort data packets that traverses the length of equal-sized best-effort data packets that traverse the
router in a second. router in a second.
Discussion: Discussion:
Forwarding the best-effort data packets, which requires obtaining Forwarding the best-effort data packets, which requires obtaining
the routing information and transferring the data packet between the routing information and transferring the data packet between
network interfaces, requires processing power. This load factor network interfaces, requires processing power. This load factor
creates load on the CPU(s) and buffers of the router. creates load on the CPU(s) and buffers of the router.
For the purpose of benchmarking we define a traffic flow as a For the purpose of benchmarking, we define a traffic flow as a
stream of equal-sized packets with even interpacket delay. It is stream of equal-sized packets with even interpacket delay. It is
possible to specify traffic with varying packet sizes as a possible to specify traffic with varying packet sizes as a
superposition of multiple best-effort traffic flows as they are superposition of multiple best-effort traffic flows as they are
defined here. defined here.
Issues: Issues:
The same amount of data segmented into differently sized packets The same amount of data segmented into differently sized packets
causes different amounts of load on the router, which has to be causes different amounts of load on the router, which has to be
considered during benchmarking measurements. The measurement unit considered during benchmarking measurements. The measurement unit
of this load factor reflects this as well. of this load factor reflects this as well.
Measurement unit: Measurement unit:
This load factor has a composite unit of [packets per second This load factor has a composite unit of [packets per second
(pps); bytes]. For example, [5 pps; 100 bytes] means five pieces (pps); bytes]. For example, [5 pps; 100 bytes] means five pieces
of one-hundred-byte packets per second. of one-hundred-byte packets per second.
3.3.2 Distinguished Traffic Load Factor 3.3.2. Distinguished Traffic Load Factor
Definition: Definition:
The distinguished traffic load factor is defined as the number and The distinguished traffic load factor is defined as the number and
length of the distinguished data packets that traverses the router length of the distinguished data packets that traverse the router
in a second. in a second.
Discussion: Discussion:
Similarly to the best-effort data, forwarding the distinguished Similarly to the best-effort data, forwarding the distinguished
data packets requires obtaining the routing information and data packets requires obtaining the routing information and
transferring the data packet between network interfaces. However, transferring the data packet between network interfaces. However,
in this case packets have to be classified as well, which requires in this case packets have to be classified as well, which requires
additional processing capacity. additional processing capacity.
For the purpose of benchmarking we define a traffic flow as a For the purpose of benchmarking, we define a traffic flow as a
stream of equal-sized packets with even interpacket delay. It is stream of equal-sized packets with even interpacket delay. It is
possible to specify traffic with varying packet sizes as a possible to specify traffic with varying packet sizes as a
superposition of multiple distinguished traffic flows as they are superposition of multiple distinguished traffic flows as they are
defined here. defined here.
Issues: Issues:
Just as in the best-effort case, the same amount of data segmented Just as in the best-effort case, the same amount of data segmented
into differently sized packets causes different amounts of load on into differently sized packets causes different amounts of load on
the router, which has to be considered during the benchmarking the router, which has to be considered during the benchmarking
measurements. The measurement unit of this load factor reflects measurements. The measurement unit of this load factor reflects
this as well. this as well.
Measurement unit: Measurement unit:
This load factor has a composite unit of [packets per second This load factor has a composite unit of [packets per second
(pps); bytes]. For example, [5 pps; 100 bytes] means five pieces (pps); bytes]. For example, [5 pps; 100 bytes] means five pieces
of one-hundred-byte packets per second. of one-hundred-byte packets per second.
3.3.3 Session Load Factor 3.3.3. Session Load Factor
Definition: Definition:
The session load factor is the number of QoS sessions the router The session load factor is the number of QoS sessions the router
is keeping track of. is keeping track of.
Discussion: Discussion:
Resource reservation capable routers maintain reservation states Resource reservation capable routers maintain reservation states
to keep track of QoS sessions. Obviously, the more reservation to keep track of QoS sessions. Obviously, the more reservation
states are registered with the router, the more complex the states are registered with the router, the more complex the
traffic classification becomes, and the more time it takes to look traffic classification becomes, and the more time it takes to look
skipping to change at page 10, line 52 skipping to change at page 11, line 34
only the traffic flows, but also the signaling messages that only the traffic flows, but also the signaling messages that
control the reservation states have to be identified first, before control the reservation states have to be identified first, before
taking any other action, and this kind of classification also taking any other action, and this kind of classification also
means extra work for the router. means extra work for the router.
In the case of soft-state resource reservation protocols, the In the case of soft-state resource reservation protocols, the
session load also affects reservation state maintenance. For session load also affects reservation state maintenance. For
example, the supervision of timers that watchdog the reservation example, the supervision of timers that watchdog the reservation
state refreshes may cause further load on the router. state refreshes may cause further load on the router.
This load factor utilizes the CPU(s), the main memory and the This load factor utilizes the CPU(s), the main memory, and the
session management logic (e.g. content addressable memory), if session management logic (e.g., content addressable memory), if
any, of the resource reservation capable router. any, of the resource reservation capable router.
Measurement unit: Measurement unit:
This load component is measured by the number of QoS sessions that This load component is measured by the number of QoS sessions that
impact the router. impact the router.
3.3.4 Signaling Intensity Load Factor 3.3.4. Signaling Intensity Load Factor
Definition: Definition:
The signaling intensity load factor is the number of signaling The signaling intensity load factor is the number of signaling
messages that are presented at the input interfaces of the router messages that are presented at the input interfaces of the router
during one second. 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. raises the load on the control plane of the router.
In routers where the control plane and the data plane are not In routers where the control plane and the data plane are not
totally independent (e.g. certain parts of the tasks are served by totally independent (e.g., certain parts of the tasks are served
the same processor; or the architecture has common memory buffers, by the same processor; or the architecture has common memory
transfer buses or any other resources) the signaling load can have buffers, transfer buses or any other resources) the signaling load
an impact on the router's packet forwarding performance as well. can have an impact on the router's packet forwarding performance
as well.
Naturally, just as everywhere else in this document, the term Naturally, just as everywhere else in this document, the term
"signaling messages" refer only to the resource reservation "signaling messages" refer only to the resource reservation
protocol related primitives. protocol related primitives.
Issues: Issues:
Most resource reservation protocols have several protocol Most 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. This fact has to be considered during the power from the router. This fact has to be considered during the
benchmarking measurements. benchmarking measurements.
Measurement unit: Measurement unit:
The unit of this factor is signaling messages/second. The unit of this factor is signaling messages/second.
3.3.5 Signaling Burst Load Factor 3.3.5. Signaling Burst Load Factor
Definition: Definition:
The signaling burst load factor is defined as the number of The signaling burst load factor is defined as the number of
signaling messages that arrive to one input port of the router signaling messages that arrive to one input port of the router
back-to-back ([1]), causing persistent load on the signaling back-to-back ([1]), causing persistent load on the signaling
message handler. message handler.
Discussion: Discussion:
The definition focuses on one input port only and does not The definition focuses on one input port only and does not
consider the traffic arriving at the other input ports. consider the traffic arriving at the other input ports. As a
As a consequence, a set of messages arriving at different ports, consequence, a set of messages arriving at different ports, but
but with such a timing that would be a burst if the messages with such a timing that would be a burst if the messages arrived
arrived at the same port, is not considered to be a burst. The at the same port, is not considered to be a burst. The reason for
reason for this is that it is not guaranteed in a black-box test this is that it is not guaranteed in a black-box test that this
that this would have the same effect on the router as a burst would have the same effect on the router as a burst (incoming at
(incoming at the same interface) has. the same interface) has.
This definition conforms to the burst definition given in [2]. This definition conforms to the burst definition given in [3].
Issues: 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. Bursts primitives realized by different signaling message types. Bursts
built up of different messages may have a different effect on the built up of different messages may have a different effect on the
router. Consequently, during measurements the content of the burst router. Consequently, during measurements the content of the
has to be considered as well. burst has to be considered as well.
Likewise, the first one of multiple idempotent signaling messages Likewise, the first one of multiple idempotent signaling messages
that each accomplish exactly the same end will probably not take that each accomplish exactly the same end will probably not take
the same amount of time to be processed as subsequent ones. the same amount of time to be processed as subsequent ones.
Benchmarking methodology will have to consider the intended effect Benchmarking methodology will have to consider the intended effect
of the signaling messages, as well as the state of the router at of the signaling messages, as well as the state of the router at
the time of their arrival. the time of their arrival.
Measurement unit: Measurement unit:
This load factor is characterized by the number of messages in the This load factor is characterized by the number of messages in the
burst. burst.
3.4 Performance Metrics 3.4. Performance Metrics
This group of definitions is a collection of measurable quantities This group of definitions is a collection of measurable quantities
that describe the performance impact the different load components that describe the performance impact the different load components
have on the router. have on the router.
During a benchmark, the values of these metrics will have to be During a benchmark, the values of these metrics will have to be
measured under different load conditions. measured under different load conditions.
3.4.1 Signaling Message Handling Time 3.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 latency ([1], for store-and-forward devices) of a time) is the latency ([1], for store-and-forward devices) of a
signaling message passing through the router. signaling message passing through the router.
Discussion: Discussion:
The router interprets the signaling messages, acts based on their The router interprets the signaling messages, acts based on their
content and usually forwards them in an unmodified or modified content and usually forwards them in an unmodified or modified
form. Thus the message handling time is usually longer than the form. Thus the message handling time is usually longer than the
forwarding time of data packets of the same size. forwarding time of data packets of the same size.
There might be signaling message primitives, however, that are There might be signaling message primitives, however, that are
drained or generated by the router, like certain refresh messages. drained or generated by the router, like certain refresh messages.
In this case the signal handling time is not necessarily In this case, the signal handling time is not necessarily
measureable, therefore it is not defined for such messages. measureable, therefore it is not defined for such messages.
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 them. In this case, by signaling messages after processing them. In this case, by
definition, the signal handling time is the latency between the definition, the signal handling time is the latency between the
incoming signaling message and the last outgoing signaling message incoming signaling message and the last outgoing signaling message
related to the received one. related to the received one.
The signal handling time is an important characteristic as it The signal handling time is an important characteristic as it
skipping to change at page 13, line 27 skipping to change at page 14, line 24
ones. Benchmarking methodology will have to consider the intended ones. Benchmarking methodology will have to consider the intended
effect of the signaling messages, as well as the state of the effect of the signaling messages, as well as the state of the
router at the time of their arrival. router at the time of their arrival.
Measurement unit: Measurement unit:
The dimension of the signaling message handling time is the The dimension of the signaling message handling time is the
second, reported with a resolution sufficient to distinguish second, reported with a resolution sufficient to distinguish
between different events/DUTs (e.g., milliseconds). Reported between different events/DUTs (e.g., milliseconds). Reported
results MUST clearly indicate the time unit used. results MUST clearly indicate the time unit used.
3.4.2 Distinguished Traffic Delay 3.4.2. Distinguished Traffic Delay
Definition: Definition:
Distinguished traffic delay is the latency ([1], for store-and- Distinguished traffic delay is the latency ([1], for store-and-
forward devices) of a distinguished data packet passing through forward devices) of a distinguished data packet passing through
the tested router device. the tested router device.
Discussion: Discussion:
Distinguished 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. This classification without any resource reservation capability. This classification
procedure might be quite time consuming in routers with vast procedure might be quite time consuming in routers with vast
amounts of reservation states. 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 distinguished traffic performance of the router. In this case, the distinguished
delay metric also indicates the influence the two planes have on traffic delay metric also indicates the influence the two planes
each other. have on each other.
Issues: Issues:
Queuing of the incoming data packets in routers can bias this Queuing of the incoming data packets in routers can bias this
metric, so the measurement procedures have to consider this metric, so the measurement procedures have to consider this
effect. effect.
Measurement unit: Measurement unit:
The dimension of the signaling message handling time is the The dimension of the distinguished traffic delay time is the
second, reported with resolution sufficient to distinguish between second, reported with resolution sufficient to distinguish between
different events/DUTs (e.g., millisecond units). Reported results different events/DUTs (e.g., millisecond units). Reported results
MUST clearly indicate the time unit used. MUST clearly indicate the time unit used.
3.4.3 Best-effort Traffic Delay 3.4.3. Best-effort Traffic Delay
Definition: Definition:
Best-effort traffic delay is the latency of a best-effort data Best-effort traffic delay is the latency of a best-effort data
packet traversing the tested router device. packet traversing the tested router device.
Discussion: Discussion:
If the processing power of the router is shared between the If the processing power of the router is shared between the
control and data plane, then the processing of signaling messages control and data plane, then the processing of signaling messages
may have an impact on the data forwarding performance of the may have an impact on the data forwarding performance of the
router. In this case the best-effort traffic delay metric is an router. In this case, the best-effort traffic delay metric is an
indicator of the influence the two planes have on each other. indicator of the influence the two planes have on each other.
Issues: Issues:
Queuing of the incoming data packets in routers can bias this Queuing of the incoming data packets in routers can bias this
metric as well, so measurement procedures have to consider this metric as well, so measurement procedures have to consider this
effect. effect.
Measurement unit: Measurement unit:
The dimension of the signaling message handling time is the The dimension of the best-effort traffic delay is the second,
second, reported with resolution sufficient to distinguish between reported with resolution sufficient to distinguish between
different events/DUTs (e.g., millisecond units). Reported results different events/DUTs (e.g., millisecond units). Reported results
MUST clearly indicate the time unit used. MUST clearly indicate the time unit used.
3.4.4 Signaling Message Deficit 3.4.4. Signaling Message Deficit
Definition: Definition:
Signaling message deficit is one minus the ratio of the actual and Signaling message deficit is one minus the ratio of the actual and
the expected number of signaling messages leaving a resource the expected number of signaling messages leaving a resource
reservation capable router. reservation capable router.
Discussion: Discussion:
This definition gives the same value as the ratio of the lost This definition gives the same value as the ratio of the lost
(that is, not forwarded or not generated) and the expected (that is, not forwarded or not generated) and the expected
messages. The above calculation must be used because the number of messages. The above calculation must be used because the number
lost messages cannot be measured directly. of lost messages cannot be measured directly.
There are certain types of signaling messages that reservation There are certain types of signaling messages that reservation
capable routers are required to forward as soon as their capable routers are required to forward as soon as their
processing is finished. However, due to lack of resources or other processing is finished. However, due to lack of resources or
reasons, the forwarding or even the processing of these signaling other reasons, the forwarding or even the processing of these
messages might not take place. signaling messages might not take place.
Certain other kinds of signaling messages must be generated by the Certain other kinds of signaling messages must be generated by the
router in the absence of any corresponding incoming message. It is router in the absence of any corresponding incoming message. It
possible that an overloaded router does not have the resources is possible that an overloaded router does not have the resources
necessary to generate such a message. necessary to generate such a message.
To characterize these situations we introduce the signaling To characterize these situations we introduce the signaling
message deficit metric that expresses the ratio of the signaling message deficit metric that expresses the ratio of the signaling
messages that have actually left the router and those ones that messages that have actually left the router and those ones that
were expected to leave the router. We subtract this ratio from one were expected to leave the router. We subtract this ratio from
in order to obtain a loss-type metric instead of a "message one in order to obtain a loss-type metric instead of a "message
survival metric". survival metric".
Since the most frequent reason for signaling message deficit is Since the most frequent reason for signaling message deficit is
high router load, this metric is suitable for sounding out the high router load, this metric is suitable for sounding out the
scalability limits of resource reservation capable routers. scalability limits of resource reservation capable routers.
During the measurements one must be able to determine whether a During the measurements one must be able to determine whether a
signaling message is still in the queues of the router or if it signaling message is still in the queues of the router or if it
has already been dropped. For this reason we define a signaling has already been dropped. For this reason we define a signaling
message as lost if no forwarded signaling message is emitted message as lost if no forwarded signaling message is emitted
within a reasonably long time period. This period is defined along within a reasonably long time period. This period is defined
with the benchmarking methodology. along with the benchmarking methodology.
Measurement unit: Measurement unit:
This measure has no unit; it is expressed as 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.
3.4.5 Session Maintenance Capacity 3.4.5. Session Maintenance Capacity
Definition: Definition:
The session maintenance capacity metric is used in the case of The session maintenance capacity metric is used in the case of
soft-state resource reservation protocols only. It is defined as soft-state resource reservation protocols only. It is defined as
the ratio of the number of QoS sessions actually being maintained the ratio of the number of QoS sessions actually being maintained
and the number of QoS sessions that should have been maintained and the number of QoS sessions that should have been maintained.
during one refresh period.
Discussion: Discussion:
For soft-state protocols maintaining a QoS session means For soft-state protocols maintaining a QoS session means
refreshing the reservation states associated with it. refreshing the reservation states associated with it.
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 states, because it does not have all the registered reservation states, because it does not have
the time to run the state refresh task. In this case sooner or the time to run the state refresh task. In this case, sooner or
later some QoS sessions will be lost even if the endpoints still later some QoS sessions will be lost even if the endpoints still
require their maintenance. require their maintenance.
The session maintenance capacity sounds out the maximal number of The session maintenance capacity sounds out the maximal number of
QoS sessions that the router is capable of maintaining. QoS sessions that the router is capable of maintaining.
Issues: Issues:
The actual process of session maintenance is protocol and The actual process of session maintenance is protocol and
implementation dependent, thus so is the method to examine whether implementation dependent, thus so is the method to examine whether
a session is maintained or not. a session is maintained or not.
In the case of soft-state resource reservation protocols a router In the case of soft-state resource reservation protocols, where
that fails to maintain a QoS session may not emit refresh the network nodes are responsible for generating the refresh
signaling messages either. This has direct consequences on the messages, a router that fails to maintain a QoS session may not
signaling message deficit metric. emit refresh signaling messages either. This has direct
consequences on the signaling message deficit metric.
Measurement unit: Measurement unit:
This measure has no unit; it is expressed as 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).
3.5 Router Load Conditions and Scalability Limit 3.5. Router Load Conditions and Scalability Limit
Depending mainly, but not exclusively, on the overall load of a Depending mainly, but not exclusively, on the overall load of a
router, it can be in exactly one of the following four conditions at router, it can be in exactly one of the following four conditions at
a time: loss-free and QoS compliant; lossy and QoS compliant; loss- a time: loss-free and QoS compliant; lossy and QoS compliant; loss-
free but not QoS compliant; and neither loss-free nor QoS compliant. free but not QoS compliant; and neither loss-free nor QoS compliant.
These conditions are defined below, along with the scalability These conditions are defined below, along with the scalability limit.
limit.
3.5.1 Loss-Free Condition 3.5.1. Loss-Free Condition
Definition: Definition:
A router is in loss-free condition, or loss-free state, if and A router is in loss-free condition, or loss-free state, if and
only if it is able to perform its tasks correctly and in a timely only if it is able to perform its tasks correctly and in a timely
fashion. fashion.
Discussion: Discussion:
All existing routers have finite buffer memory and finite All existing routers have finite buffer memory and finite
processing power. If a router is in loss-free state, the buffers processing power. If a router is in loss-free state, the buffers
of the router still contain enough free space to accommodate the of the router still contain enough free space to accommodate the
skipping to change at page 16, line 55 skipping to change at page 18, line 15
Note that loss-free states as defined above are not related to the Note that loss-free states as defined above are not related to the
reservation states of resource reservation protocols. The word reservation states of resource reservation protocols. The word
"state" is used to mean "condition". "state" is used to mean "condition".
Also note that it is irrelevant what internal reason causes a Also note that it is irrelevant what internal reason causes a
router to fail to perform in accordance with protocol router to fail to perform in accordance with protocol
specifications or in "reasonable time"; if it is not high load but specifications or in "reasonable time"; if it is not high load but
-- for example -- an implementation error that causes the device -- for example -- an implementation error that causes the device
to perform inadequately, it still cannot be said to be in a loss- to perform inadequately, it still cannot be said to be in a loss-
free state. The same applies to the random early dropping of free state. The same applies to the random early dropping of
packets in order to prevent congestion. In a black-box measurement packets in order to prevent congestion. In a black-box
it is impossible to determine whether a packet was dropped as part measurement it is impossible to determine whether a packet was
of a congestion control mechanism or because the router was unable dropped as part of a congestion control mechanism or because the
to forward it; therefore, if packet loss is observed except as router was unable to forward it; therefore, if packet loss is
noted below, the router is by definition in lossy state (lossy observed except as noted below, the router is by definition in
condition). lossy state (lossy condition).
If a distinguished data flow exceeds its allotted bandwidth, it is If a distinguished data flow exceeds its allotted bandwidth, it is
acceptable for routers to drop excess packets. Thus, a router that acceptable for routers to drop excess packets. Thus, a router
is QoS Compliant (see below) is also loss-free provided that it that is QoS Compliant (see below) is also loss-free provided that
only drops packets from distinguished data flows. it only drops packets from distinguished data flows.
If a device is not in a loss-free state, it is in a lossy If a device is not in a loss-free state, it is in a lossy
condition/state. condition/state.
Related definitions: Related definitions:
Lossy Condition Lossy Condition
QoS Compliant Condition QoS Compliant Condition
Not QoS Compliant Condition Not QoS Compliant Condition
Scalability Limit Scalability Limit
3.5.2 Lossy Condition 3.5.2. Lossy Condition
Definition: Definition:
A router is in a lossy condition, or lossy state, if it cannot A router is in a lossy condition, or lossy state, if it cannot
perform its duties adequately for some reason; that is, if it does perform its duties adequately for some reason; that is, if it does
not meet protocol specifications (except QoS guarantees, which are not meet protocol specifications (except QoS guarantees, which are
treated separately), or -- if time-related specifications are treated separately), or -- if time-related specifications are
missing -- doesn't complete some operations in "reasonable time" missing -- doesn't complete some operations in "reasonable time"
(which is then defined in the benchmarks). (which is then defined in the benchmarks).
Discussion: Discussion:
skipping to change at page 18, line 13 skipping to change at page 19, line 37
condition/state. condition/state.
Related definitions: Related definitions:
Loss-Free Condition (especially the discussion of congestion Loss-Free Condition (especially the discussion of congestion
control mechanisms that cause packet loss) control mechanisms that cause packet loss)
Scalability Limit Scalability Limit
Signaling Message Deficit Signaling Message Deficit
QoS Compliant Condition QoS Compliant Condition
Not QoS Compliant Condition Not QoS Compliant Condition
3.5.3 QoS Compliant Condition 3.5.3. QoS Compliant Condition
Definition: Definition:
A router is in the QoS compliant state if and only if all A router is in the QoS compliant state if and only if all
distinguished data flows receive the QoS treatment they are distinguished data flows receive the QoS treatment they are
entitled to. entitled to.
Discussion: Discussion:
Defining what specific QoS guarantees must be upheld is beyond the Defining what specific QoS guarantees must be upheld is beyond the
scope of this document because every reservation model may specify scope of this document because every reservation model may specify
a different set of such parameters. a different set of such parameters.
Loss, delay, jitter etc. of best-effort data flows are irrelevant Loss, delay, jitter etc. of best-effort data flows are irrelevant
when considering whether a router is in the QoS compliant state. when considering whether a router is in the QoS compliant state.
Related definitions: Related definitions:
Loss-Free Condition Loss-Free Condition
Lossy Condition Lossy Condition
Not QoS Compliant Condition Not QoS Compliant Condition
Scalability Limit Scalability Limit
3.5.4 Not QoS Compliant Condition 3.5.4. Not QoS Compliant Condition
Definition: Definition:
A router is in the not QoS compliant state if and only if it is A router is in the not QoS compliant state if and only if it is
not in the QoS compliant condition. not in the QoS compliant condition.
Related definitions: Related definitions:
Loss-Free Condition Loss-Free Condition
Lossy Condition Lossy Condition
QoS Compliant Condition QoS Compliant Condition
Scalability Limit Scalability Limit
3.5.5 Scalability Limit 3.5.5. Scalability Limit
Definition: Definition:
The scalability limits of a router are the boundary load The scalability limits of a router are the boundary load
conditions where the router is still in the loss-free and QoS conditions where the router is still in the loss-free and QoS
compliant ("good") state but the smallest amount of additional compliant state, but the smallest amount of additional load would
load would drive it to a state that is "bad": either not loss- drive it to a state that is either QoS compliant but not loss-
free; or not QoS compliant; or neither loss-free nor QoS free, or not QoS compliant but loss-free, or neither loss-free nor
compliant. QoS compliant.
Discussion: Discussion:
An unloaded router that operates correctly is in a "good" state An unloaded router that operates correctly is in a loss-free and
because it is both loss-free and QoS compliant. As load increases, QoS compliant state. As load increases, the resources of the
the resources of the router are becoming more and more utilized. router are becoming more and more utilized. At a certain point,
There is a certain point where the router leaves the "good" state the router enters a state that is either not QoS compliant, or not
and enters a "bad" state as defined above. Note that such a point loss-free, or neither QoS compliant nor loss-free. Note that such
may be impossible to reach in some cases (for example if the a point may be impossible to reach in some cases (for example if
bandwidth of the physical medium prevents increasing the traffic the bandwidth of the physical medium prevents increasing the
load any further). traffic load any further).
A particular load condition can be identified by the corresponding A particular load condition can be identified by the corresponding
values of the load factors (as defined in 3.3 Router Load Factors) values of the load factors (as defined in 3.3 Router Load Factors)
impacting the router. These values can be represented as a 7-tuple impacting the router. These values can be represented as a 7-
of numbers (there are only five load factors, but the traffic load tuple of numbers (there are only five load factors, but the
factors have composite units and thus require two numbers each to traffic load factors have composite units and thus require two
express). We can think of these tuples as vectors that correspond numbers each to express). We can think of these tuples as vectors
either to a "good" state or to a "bad" state. The scalability that correspond to a state that is either both loss free and QoS
limit of the router is, then, the boundary between the sets of compliant, or not loss-free (but QoS compliant), or not QoS
vectors corresponding to "good" and "bad" states. Finding these compliant (but loss-free), or neither loss-free nor QoS compliant.
boundary points if one of the objectives of benchmarking. The scalability limit of the router is, then, the boundary between
the sets of vectors corresponding to the loss-free and QoS
compliant states and all other states. Finding these boundary
points is one of the objectives of benchmarking.
Benchmarks MAY try to separately identify the boundaries of the Benchmarks may try to separately identify the boundaries of the
loss-free and of the QoS compliant conditions in the (seven- loss-free and of the QoS compliant conditions in the (seven-
dimensional) space defined by the load-vectors. dimensional) space defined by the load-vectors.
Related definitions: Related definitions:
Lossy Condition Lossy Condition
Loss-Free Condition Loss-Free Condition
QoS Compliant Condition QoS Compliant Condition
Non QoS Compliant Condition Non QoS Compliant Condition
4. Security Considerations 4. Security Considerations
As this document only provides terminology and describes neither a As this document only provides terminology and does not describe a
protocol nor an implementation or a procedure, there are no security protocol, an implementation, or a procedure, there are no security
considerations associated with it. considerations associated with it.
5. IANA Considerations 5. Acknowledgements
This document requires no IANA actions. We would like to thank Telia Research AB, Sweden and the High Speed
Networks Laboratory at the Department of Telecommunication and Media
Informatics of the Budapest University of Technology and Economics,
Hungary for their support in the research and development work, which
contributed to the creation of this document.
6. Acknowledgements 6. References
We would like to thank the following individuals for their help in 6.1. Normative References
the research and development work which contributed to the creation
of this document: Joakim Bergkvist and Norbert Vegh from Telia
Research AB, Sweden; Balazs Szabo, Gabor Kovacs and Peter Vary from
the High Speed Networks Laboratory, Department of Telecommunication
and Mediainformatics, Budapest University of Technology and
Economics, Hungary.
7. References [1] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991.
7.1 Normative References [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] S. Bradner, "Benchmarking Terminology for Network [3] Mandeville, R., "Benchmarking Terminology for LAN Switching
[2] R. Mandeville, "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
Devices", RFC 2285, February 1998
7.2 Informative References 6.2. Informative References
[3] Braden R., Clark D., Shenker S., "Integrated Services in the [4] Braden, R., Clark, D., and S. Shenker, "Integrated Services in
[4] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) the Internet Architecture: an Overview", RFC 1633, June 1994.
- Version 1 Functional Specification", RFC 2205, September 1997
[5] R. Hancock, et al., "Next Steps in Signaling (NSIS): [5] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[6] H. Schulzrinne, R. Hancock, "GIST: General Internet Signaling [6] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Transport", Internet Draft (draft-ietf-nsis-ntlp-11), August Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
2006 (work in progress) June 2005.
[7] J. Manner (ed.), G. Karagiannis, A. McDonald, "NSLP for [7] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Quality-of-Service Signaling", Internet Draft (draft-ietf-nsis- Signaling Transport", Work in Progress, April 2007.
qos-nslp-12), October 2006 (work in progress)
[8] J. Ash, A. Bader, C. Kappler, D. Oran, "QoS NSLP QSPEC [8] Manner, J., Ed., Karagiannis, G., and A. McDonald, "NSLP for
Template", Internet Draft (draft-ietf-nsis-qspec-14), January Quality-of-Service Signaling", Work in Progress, June 2007.
2007 (work in progress)
[9] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism [9] Ash, J., Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
Template", Work in Progress, March 2007.
[10] 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
[10] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 [11] Delgrossi, L. and 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.
[11] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated
[12] 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
[12] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I. [13] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I.
Cselenyi, M. Maliosz, "Boomerang : A Simple Protocol for Cselenyi, M. Maliosz, "Boomerang : A Simple Protocol for
Resource Reservation in IP Networks", Vancouver, IEEE Real-Time Resource Reservation in IP Networks", Vancouver, IEEE Real-Time
[13] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight [14] 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
[14] J. Manner, X. Fu, "Analysis of Existing Quality of Service [15] Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service
[15] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation Signaling Protocols", RFC 4094, May 2005.
of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September
2001 [16] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
Authors' Addresses Authors' Addresses
Gabor Feher Gabor Feher
Budapest University of Technology and Economics Budapest University of Technology and Economics
Department of Telecommunications and Mediainformatics Department of Telecommunications and Media Informatics
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: Gabor.Feher@tmit.bme.hu EMail: Gabor.Feher@tmit.bme.hu
Krisztian Nemeth Krisztian Nemeth
Budapest University of Technology and Economics Budapest University of Technology and Economics
Department of Telecommunications and Mediainformatics Department of Telecommunications and Media Informatics
Magyar Tudosok krt. 2, H-1117, Budapest, Hungary Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
Phone: +36 1 463-1565 Phone: +36 1 463-1565
Email: Krisztian.Nemeth@tmit.bme.hu EMail: Krisztian.Nemeth@tmit.bme.hu
Andras Korn Andras Korn
Budapest University of Technology and Economics Budapest University of Technology and Economics
Department of Telecommunication and Mediainformatics Department of Telecommunication and Media Informatics
Magyar Tudosok krt. 2, H-1117, Budapest, Hungary Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
Phone: +36 1 463-2664 Phone: +36 1 463-2664
Email: Andras.Korn@tmit.bme.hu EMail: Andras.Korn@tmit.bme.hu
Istvan Cselenyi Istvan Cselenyi
TeliaSonera International Carrier TeliaSonera International Carrier
Vaci ut 22-24, H-1132 Budapest, Hungary Vaci ut 22-24, H-1132 Budapest, Hungary
Phone: +36 1 412-2705
Email: Istvan.Cselenyi@teliasonera.com
Disclaimer of Validity
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Phone: +36 1 412-2705
assurances of licenses to be made available, or the result of an EMail: Istvan.Cselenyi@teliasonera.com
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Copyright Notice Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Disclaimer This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided Intellectual Property
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE The IETF takes no position regarding the validity or scope of any
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL Intellectual Property Rights or other rights that might be claimed to
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY pertain to the implementation or use of the technology described in
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE this document or the extent to which any license under such rights
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS might or might not be available; nor does it represent that it has
FOR A PARTICULAR PURPOSE. made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 136 change blocks. 
358 lines changed or deleted 332 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/