draft-ietf-bmwg-benchres-term-07.txt   draft-ietf-bmwg-benchres-term-08.txt 
Benchmarking Working Group Gabor Feher, BUTE Benchmarking Working Group Gabor Feher, BUTE
INTERNET-DRAFT Krisztian Nemeth, BUTE INTERNET-DRAFT Krisztian Nemeth, BUTE
Expiration Date: August 2006 Andras Korn, BUTE Expiration Date: August 2007 Andras Korn, BUTE
Istvan Cselenyi, TeliaSonera Istvan Cselenyi, TeliaSonera
February 2006 February 2007
Benchmarking Terminology for Resource Reservation Capable Routers Benchmarking Terminology for Resource Reservation Capable Routers
<draft-ietf-bmwg-benchres-term-07.txt> <draft-ietf-bmwg-benchres-term-08.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The IETF Trust (2007).
Table of contents Table of contents
Abstract...........................................................2 Abstract...........................................................2
1. Introduction....................................................2 1. Introduction....................................................2
2. Existing definitions............................................3 2. Existing definitions............................................3
3. Definition of Terms.............................................3 3. Definition of Terms.............................................3
3.1 Traffic Flow Types..........................................3 3.1 Traffic Flow Types..........................................3
3.1.1 Data Flow..............................................3 3.1.1 Data Flow..............................................4
3.1.2 Distinguished Data Flow................................4 3.1.2 Distinguished Data Flow................................4
3.1.3 Best-Effort Data Flow..................................4 3.1.3 Best-Effort Data Flow..................................4
3.2 Resource Reservation Protocol Basics........................4 3.2 Resource Reservation Protocol Basics........................5
3.2.1 QoS Session............................................5 3.2.1 QoS Session............................................5
3.2.2 Resource Reservation Protocol..........................6 3.2.2 Resource Reservation Protocol..........................6
3.2.3 Resource Reservation Capable Router....................6 3.2.3 Resource Reservation Capable Router....................6
3.2.4 Reservation State......................................6 3.2.4 Reservation State......................................7
3.2.5 Resource Reservation Protocol Orientation..............7 3.2.5 Resource Reservation Protocol Orientation..............8
3.3 Router Load Factors.........................................8 3.3 Router Load Factors.........................................8
3.3.1 Best-Effort Traffic Load Factor........................9 3.3.1 Best-Effort Traffic Load Factor........................9
3.3.2 Distinguished Traffic Load Factor......................9 3.3.2 Distinguished Traffic Load Factor......................9
3.3.3 Session Load Factor...................................10 3.3.3 Session Load Factor...................................10
3.3.4 Signaling Intensity Load Factor.......................10 3.3.4 Signaling Intensity Load Factor.......................11
3.3.5 Signaling Burst Load Factor...........................11 3.3.5 Signaling Burst Load Factor...........................11
3.4 Performance Metrics........................................12 3.4 Performance Metrics........................................12
3.4.1 Signaling Message Handling Time.......................12 3.4.1 Signaling Message Handling Time.......................12
3.4.2 Distinguished Traffic Delay...........................13 3.4.2 Distinguished Traffic Delay...........................13
3.4.3 Best-effort Traffic Delay.............................13 3.4.3 Best-effort Traffic Delay.............................14
3.4.4 Signaling Message Deficit.............................14 3.4.4 Signaling Message Deficit.............................14
3.4.5 Session Maintenance Capacity..........................15 3.4.5 Session Maintenance Capacity..........................15
3.5 Router Load Conditions and Scalability Limit...............15 3.5 Router Load Conditions and Scalability Limit...............16
3.5.1 Loss-Free Condition...................................15 3.5.1 Loss-Free Condition...................................16
3.5.2 Lossy Condition.......................................16 3.5.2 Lossy Condition.......................................17
3.5.3 Scalability Limit.....................................17 3.5.3 QoS Compliant Condition...............................18
4. Security Considerations........................................17 3.5.4 Not QoS Compliant Condition...........................18
5. IANA Considerations............................................17 3.5.5 Scalability Limit.....................................18
6. Acknowledgements...............................................18 4. Security Considerations........................................19
7. References.....................................................18 5. IANA Considerations............................................19
7.1 Normative References.......................................18 6. Acknowledgements...............................................20
7.2 Informative References.....................................18 7. References.....................................................20
Authors' Addresses................................................19 7.1 Normative References.......................................20
Disclaimer of Validity............................................19 7.2 Informative References.....................................20
Copyright Notice..................................................20 Authors' Addresses................................................21
Disclaimer........................................................20 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 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.
1. Introduction 1. Introduction
Signaling based resource reservation (e.g. via RSVP [3]) is an Signaling based resource reservation using the IntServ paradigm [3]
important part of the different QoS provisioning approaches. is an important part of the different QoS provisioning approaches.
Therefore network operators who are planning to deploy signaling Therefore network operators who are planning to deploy signaling
based resource reservation may want to examine the scalability based resource reservation may want to examine the scalability
limitations of reservation capable routers and the impact of limitations of reservation capable routers and the impact of
signaling on their data forwarding performance. 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
resource reservation. This document defines terminology for a IntServ based resource reservation. This document defines
specific set of tests that vendors or network operators can carry terminology for a specific set of tests that vendors or network
out to measure and report the signaling performance characteristics operators can carry out to measure and report the signaling
of router devices that support resource reservation protocols. The performance characteristics of router devices that support resource
results of these tests provide comparable data for different reservation protocols. The results of these tests provide comparable
products, and thus support the decision-making process before data for different products, and thus support the decision-making
purchase. Moreover, these measurements provide input characteristics process before purchase. Moreover, these measurements provide input
for the dimensioning of a network in which resources are provisioned characteristics for the dimensioning of a network in which resources
dynamically by signaling. Finally, the tests are applicable for are provisioned dynamically by signaling. Finally, the tests are
characterizing the impact of the resource reservation signaling on applicable for characterizing the impact of the resource reservation
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 [3] and resource reservation protocols: the IETF standard RSVP [4], NSIS
several experimental ones, such as YESSIR [5], ST2+ [6], SDP [7], [5][6][7][8] and several experimental ones, such as YESSIR [9], ST2+
Boomerang [8] and Ticket [9]. Some of these protocols are also [10], SDP [11], Boomerang [12] and Ticket [13]. Some of these
analyzed in an IETF NSIS working group draft [10]. Although at the protocols were also analyzed by the IETF NSIS working group [14].
moment the authors are only aware of resource reservation capable Although at the moment the authors are only aware of resource
router products that interpret RSVP, this document defines terms reservation capable router products that interpret RSVP, this
that are valid in general and not restricted to any of the above document defines terms that are valid in general and not restricted
listed protocols. to any of the above listed protocols.
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 are predominantly beyond our scope. toolbox are predominantly beyond our scope.
2. Existing definitions 2. Existing definitions
RFC 1242 "Benchmarking Terminology for Network Interconnect RFC 1242 "Benchmarking Terminology for Network Interconnect
Devices" [1] and RFC 2285 "Benchmarking Terminology for LAN Devices" [1] and RFC 2285 "Benchmarking Terminology for LAN
Switching Devices" [2] contain discussions and definitions for a Switching Devices" [2] contain discussions and definitions for a
number of terms relevant to the benchmarking of signaling number of terms relevant to the benchmarking of signaling
performance of reservation capable routers and should be consulted performance of reservation capable routers and should be consulted
before attempting to make use of this document. before attempting 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 Next Steps in Signaling working
group laid out in [4]. group laid out in [5][6][7].
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
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.
skipping to change at page 4, line 12 skipping to change at page 4, line 21
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 [4]. packets. For more comment on flow identification refer to [5].
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:
skipping to change at page 6, line 5 skipping to change at page 6, line 12
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 [11]. an aggregation [15].
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) are only concerned with resource reservation protocols (e.g. RSVP, NSIS QoS NSLP[7]) are
this, i.e. carrying the QoS-related information to all the only concerned with this, i.e. carrying the QoS-related
appropriate network nodes, without being aware of its content. information to all the appropriate network nodes, without being
This latter approach allows changing the way the QoS parameters aware of its content. This latter approach allows changing the way
are described, and different kinds of provisioning can be realized the QoS parameters are described, and different kinds of
without the need to change the protocol itself. provisioning can be realized without the need to change the
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.
skipping to change at page 7, line 10 skipping to change at page 7, line 23
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 [6]) require Hard-state resource reservation protocols (e.g. ST2 [10]) 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 set-up 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 certain
period then the router stops the maintenance of the QoS session period then the router stops the maintenance of the QoS session
assuming that the end-points do not intend to keep the session up assuming that the end-points do not intend to keep the session up
skipping to change at page 13, line 6 skipping to change at page 13, line 22
This fact has to be considered during the benchmarking process. This fact has to be considered during the benchmarking process.
As noted above, the first one of multiple idempotent signaling As noted above, the first one of multiple idempotent signaling
messages that each accomplish exactly the same end will probably messages that each accomplish exactly the same end will probably
not take the same amount of time to be processed as subsequent not take the same amount of time to be processed as subsequent
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 unit of the signaling message handling time is the second. The dimension of the signaling message handling time is the
second, reported with a resolution sufficient to distinguish
between different events/DUTs (e.g., milliseconds). Reported
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
skipping to change at page 13, line 37 skipping to change at page 14, line 6
performance of the router. In this case the distinguished traffic performance of the router. In this case the distinguished traffic
delay metric also indicates the influence the two planes have on delay metric also indicates the influence the two planes have on
each other. 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 unit of the distinguished traffic delay is the second. The dimension of the signaling message handling time is the
second, reported with resolution sufficient to distinguish between
different events/DUTs (e.g., millisecond units). Reported results
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 unit of the best-effort traffic delay is the second. The dimension of the signaling message handling time is the
second, reported with resolution sufficient to distinguish between
different events/DUTs (e.g., millisecond units). Reported results
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
skipping to change at page 15, line 45 skipping to change at page 16, line 17
signaling messages either. This has direct consequences on the signaling messages either. This has direct consequences on the
signaling message deficit metric. 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 of the following two conditions at a router, it can be in exactly one of the following four conditions at
time: loss-free or lossy. These conditions are defined below, along a time: loss-free and QoS compliant; lossy and QoS compliant; loss-
with the scalability limit, which is the 'boundary' between them. free but not QoS compliant; and neither loss-free nor QoS compliant.
These conditions are defined below, along with the scalability
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 the A router is in loss-free condition, or loss-free state, if and
extent to which its internal resources are utilized interferes only if it is able to perform its tasks correctly and in a timely
with neither the correctness nor the timeliness of its operation. 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
next incoming packet when it arrives. Also, the router has enough next incoming packet when it arrives. Also, the router has enough
processing power to cope with all its tasks, thus all required processing power to cope with all its tasks, thus all required
operations are carried out within the time the protocol operations are carried out within the time the protocol
specification allows; or, if this time is not specified by the specification allows; or, if this time is not specified by the
protocol, then in "reasonable time" (which is then defined in the protocol, then in "reasonable time" (which is then defined in the
skipping to change at page 16, line 33 skipping to change at page 17, line 4
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 measurement
it is impossible to determine whether a packet was dropped as part it is impossible to determine whether a packet was dropped as part
of a congestion control mechanism or because the router was unable of a congestion control mechanism or because the router was unable
to forward it; therefore, if packet loss is observed, the router to forward it; therefore, if packet loss is observed except as
is by definition in lossy state (lossy condition). noted below, the router is by definition in lossy state (lossy
condition).
If a distinguished data flow exceeds its allotted bandwidth, it is
acceptable for routers to drop excess packets. Thus, a router that
is QoS Compliant (see below) is also loss-free provided that it
only drops packets from distinguished data flows.
If a device is not in a loss-free state, it is in a lossy
condition/state.
Related definitions: Related definitions:
Lossy Condition Lossy Condition
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 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 perform its duties adequately for some reason; that is, if it does
doesn't meet protocol specifications, or -- if time-related not meet protocol specifications (except QoS guarantees, which are
specifications are missing -- doesn't complete some operations in treated separately), or -- if time-related specifications are
"reasonable time" (which is then defined in the benchmarks). missing -- doesn't complete some operations in "reasonable time"
(which is then defined in the benchmarks).
Discussion: Discussion:
A router may be in a lossy state for several reasons, including A router may be in a lossy state for several reasons, including
but not necessarily limited to the following: but not necessarily limited to the following:
a) Buffer memory has run out, so either an incoming or a buffered a) Buffer memory has run out, so either an incoming or a buffered
packet has to be dropped. packet has to be dropped.
b) The router doesn't have enough processing power to cope with b) The router doesn't have enough processing power to cope with
all its duties. Some required operations are skipped, aborted all its duties. Some required operations are skipped, aborted
or suffer unacceptable delays. or suffer unacceptable delays.
c) Some other finite internal resource is exhausted. c) Some other finite internal resource is exhausted.
skipping to change at page 17, line 4 skipping to change at page 17, line 42
Discussion: Discussion:
A router may be in a lossy state for several reasons, including A router may be in a lossy state for several reasons, including
but not necessarily limited to the following: but not necessarily limited to the following:
a) Buffer memory has run out, so either an incoming or a buffered a) Buffer memory has run out, so either an incoming or a buffered
packet has to be dropped. packet has to be dropped.
b) The router doesn't have enough processing power to cope with b) The router doesn't have enough processing power to cope with
all its duties. Some required operations are skipped, aborted all its duties. Some required operations are skipped, aborted
or suffer unacceptable delays. or suffer unacceptable delays.
c) Some other finite internal resource is exhausted. c) Some other finite internal resource is exhausted.
d) The router runs a defective (non-conforming) protocol d) The router runs a defective (non-conforming) protocol
implementation. implementation.
e) Hardware malfunction. e) Hardware malfunction.
f) A congestion control mechanism is active.
Loss can mean the loss of data packets as well as signaling
message deficit.
A router that does not lose data packets and does not experience
signaling message deficit but fails to meet required QoS
parameters is in the loss-free, but not in the QoS compliant
state.
If a device is not in a lossy state, it is in a loss-free
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
QoS Compliant Condition
Not QoS Compliant Condition
3.5.3 Scalability Limit 3.5.3 QoS Compliant Condition
Definition:
A router is in the QoS compliant state if and only if all
distinguished data flows receive the QoS treatment they are
entitled to.
Discussion:
Defining what specific QoS guarantees must be upheld is beyond the
scope of this document because every reservation model may specify
a different set of such parameters.
Loss, delay, jitter etc. of best-effort data flows are irrelevant
when considering whether a router is in the QoS compliant state.
Related definitions:
Loss-Free Condition
Lossy Condition
Not QoS Compliant Condition
Scalability Limit
3.5.4 Not QoS Compliant Condition
Definition:
A router is in the not QoS compliant state if and only if it is
not in the QoS compliant condition.
Related definitions:
Loss-Free Condition
Lossy Condition
QoS Compliant Condition
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 a loss-free state but the conditions where the router is still in the loss-free and QoS
smallest amount of additional load would drive it to a lossy compliant ("good") state but the smallest amount of additional
state. load would drive it to a state that is "bad": either not loss-
free; or not QoS compliant; or neither loss-free nor QoS
compliant.
Discussion: Discussion:
An unloaded router that operates correctly is in loss-free state. An unloaded router that operates correctly is in a "good" state
As load increases, the resources of the router are becoming more because it is both loss-free and QoS compliant. As load increases,
and more utilized. There is a certain point where the router the resources of the router are becoming more and more utilized.
leaves the loss-free state and enters the lossy state. Note that There is a certain point where the router leaves the "good" state
such a point may be impossible to reach in some cases (for and enters a "bad" state as defined above. Note that such a point
example, the bandwidth of the physical medium prevents increasing may be impossible to reach in some cases (for example if the
the traffic load any further). bandwidth of the physical medium prevents increasing the 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-tuple
of numbers (5 is the number of load factors, but two of them have of numbers (there are only five load factors, but the traffic load
composite units and thus require two numbers each to express). We factors have composite units and thus require two numbers each to
can think of these tuples as vectors that correspond either to express). We can think of these tuples as vectors that correspond
loss-free state or to lossy state. The scalability limit of the either to a "good" state or to a "bad" state. The scalability
router is, then, the boundary between the sets of vectors limit of the router is, then, the boundary between the sets of
corresponding to loss-free and lossy states. Finding these vectors corresponding to "good" and "bad" states. Finding these
boundary points if one of the objectives of benchmarking. boundary points if one of the objectives of benchmarking.
Benchmarks MAY try to separately identify the boundaries of the
loss-free and of the QoS compliant conditions in the (seven-
dimensional) space defined by the load-vectors.
Related definitions: Related definitions:
Loss-Free Condition
Lossy Condition Lossy Condition
Loss-Free Condition
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 describes neither a
protocol nor an implementation or a procedure, there are no security protocol nor an implementation or a procedure, there are no security
considerations associated with it. considerations associated with it.
5. IANA Considerations 5. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
skipping to change at page 18, line 25 skipping to change at page 20, line 25
7. References 7. References
7.1 Normative References 7.1 Normative References
[1] S. Bradner, "Benchmarking Terminology for Network [1] S. Bradner, "Benchmarking Terminology for Network
[2] R. Mandeville, "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 7.2 Informative References
[3] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) [3] Braden R., Clark D., Shenker S., "Integrated Services in the
- Version 1 Functional Specification", RFC 2205, September [4] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP)
1997. - Version 1 Functional Specification", RFC 2205, September 1997
[4] R. Hancock, et al., "Next Steps in Signaling (NSIS): [5] R. Hancock, et al., "Next Steps in Signaling (NSIS):
[5] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism [6] H. Schulzrinne, R. Hancock, "GIST: General Internet Signaling
Transport", Internet Draft (draft-ietf-nsis-ntlp-11), August
2006 (work in progress)
[7] J. Manner (ed.), G. Karagiannis, A. McDonald, "NSLP for
Quality-of-Service Signaling", Internet Draft (draft-ietf-nsis-
qos-nslp-12), October 2006 (work in progress)
[8] J. Ash, A. Bader, C. Kappler, D. Oran, "QoS NSLP QSPEC
Template", Internet Draft (draft-ietf-nsis-qspec-14), January
2007 (work in progress)
[9] 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
[6] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 [10] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2
(ST2) Protocol Specification - Version ST2+", RFC 1819, August (ST2) Protocol Specification - Version ST2+", RFC 1819, August
1995 1995
[11] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated
[7] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated
Reservation in the Internet", Journal on High Speed Networks, Reservation in the Internet", Journal on High Speed Networks,
Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998 Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998
[8] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I. [12] 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
[9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight [13] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight
Resource Reservation for Unicast IP Traffic", International WS Resource Reservation for Unicast IP Traffic", International WS
on QoS'98, IWQoS'98, May 18-20, 1998 on QoS'98, IWQoS'98, May 18-20, 1998
[10] J. Manner, X. Fu, "Analysis of Existing Quality of Service [14] J. Manner, X. Fu, "Analysis of Existing Quality of Service
[11] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation [15] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation
of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September
2001 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 Mediainformatics
Magyar Tudosok krt. 2, H-1117, Budapest, Hungary Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
Phone: +36 1 463-1538 Phone: +36 1 463-1538
skipping to change at page 19, line 29 skipping to change at page 21, line 41
Department of Telecommunications and Mediainformatics Department of Telecommunications and Mediainformatics
Magyar Tudosok krt. 2, H-1117, Budapest, Hungary Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
Phone: +36 1 463-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 Mediainformatics
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 Phone: +36 1 412-2705
Email: Istvan.Cselenyi@teliasonera.com Email: Istvan.Cselenyi@teliasonera.com
Disclaimer of Validity Disclaimer of Validity
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
skipping to change at page 20, line 13 skipping to change at page 22, line 31
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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 Disclaimer
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
 End of changes. 49 change blocks. 
104 lines changed or deleted 205 lines changed or added

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