draft-ietf-bmwg-benchres-term-00.txt   draft-ietf-bmwg-benchres-term-01.txt 
Network Working Group Gabor Feher, BUTE Network Working Group Gabor Feher, BUTE
INTERNET-DRAFT Istvan Cselenyi, TRAB INTERNET-DRAFT Istvan Cselenyi, TRAB
Expiration Date: January 2002 Andras Korn, BUTE Expiration Date: May 2002 Andras Korn, BUTE
July 2001 November 2001
Benchmarking Terminology for Routers Supporting Resource Reservation Benchmarking Terminology for Routers Supporting Resource Reservation
<draft-ietf-bmwg-benchres-term-00.txt> <draft-ietf-bmwg-benchres-term-01.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
6.1.1 Resource Reservation Session...........................3 6.1.1 Resource Reservation Session...........................3
6.1.2 Multicast Resource Reservation Session.................4 6.1.2 Multicast Resource Reservation Session.................4
6.1.3 Resource Reservation Capable Router....................4 6.1.3 Resource Reservation Capable Router....................4
6.1.4 Signaling End-point....................................5 6.1.4 Signaling End-point....................................5
6.1.5 Reservation Initiator..................................5 6.1.5 Reservation Initiator..................................5
6.1.6 Reservation Session Maintenance........................6 6.1.6 Reservation Session Maintenance........................6
6.1.7 Signaling Path.........................................7 6.1.7 Signaling Path.........................................7
6.2 Traffic Types...............................................8 6.2 Traffic Types...............................................8
6.2.1 Premium Traffic........................................8 6.2.1 Premium Traffic........................................8
6.2.2 Best-Effort Traffic....................................8 6.2.2 Best-Effort Traffic....................................8
6.3 Router Load Types...........................................8 6.3 Router Load Types...........................................9
6.3.1 Session Load...........................................9 6.3.1 Traffic Load...........................................9
6.3.2 Signaling Load.........................................9 6.3.2 Session Load...........................................9
6.3.3 Signaling Burst.......................................10 6.3.3 Signaling Load........................................10
6.4 Performance Metrics........................................10 6.3.4 Signaling Burst.......................................11
6.4.1 Signaling Message Handling Time.......................10 6.4 Performance Metrics........................................11
6.4.2 Premium Traffic Delay.................................11 6.4.1 Signaling Message Handling Time.......................11
6.4.3 Best-effort Traffic Delay.............................12 6.4.2 Premium Traffic Delay.................................12
6.4.4 Signaling Message Loss................................12 6.4.3 Best-effort Traffic Delay.............................13
6.4.5 Scalability Limit.....................................13 6.4.4 Signaling Message Loss................................13
7. Acknowledgement................................................13 6.4.5 Session Refreshing Capacity...........................14
8. References.....................................................14 6.4.6 Scalability Limit.....................................14
9. Authors' Addresses:............................................14 7. Acknowledgement................................................15
8. References.....................................................15
9. Authors' Addresses:............................................15
3. Abstract 3. Abstract
The purpose of this document is to define terminology specific to the The purpose of this document is to define terminology specific to the
performance benchmarking of the resource reservation signaling of IP performance benchmarking of the resource reservation signaling of IP
routers. These terms are used in additional documents that define routers. These terms are used in additional documents that define
benchmarking methodologies for routers supporting resource benchmarking methodologies for routers supporting resource
reservation and define reporting formats for the benchmarking reservation and define reporting formats for the benchmarking
measurements. measurements.
skipping to change at page 2, line 56 skipping to change at page 3, line 5
tests provide comparable data for different products supporting the tests provide comparable data for different products supporting the
decision process before purchase. Moreover, these measurements decision process before purchase. Moreover, these measurements
provide input characteristics for the dimensioning of a network in provide input characteristics for the dimensioning of a network in
which resources are provisioned dynamically by signaling. Finally, which resources are provisioned dynamically by signaling. Finally,
the tests are applicable for characterizing the impact of the control the tests are applicable for characterizing the impact of the control
plane signaling on the forwarding performance of routers. plane signaling on the forwarding performance of 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) several very gained by examination of (and experimentation with) several very
different resource reservation protocols: RSVP [2], Boomerang [5], different resource reservation protocols: RSVP [2], Boomerang [5],
YESSIR [6], ST2+ [7], SDP [8], Ticket [9] and Load Control [10]. YESSIR [6], ST2+ [7], SDP [8] and Ticket [9]. Nevertheless, this
document aspires to compose terms that are valid in general and not
Nevertheless, this document aspires to compose terms that are valid restricted to these protocols.
in general and not restricted to these protocols.
5. Existing definitions 5. Existing definitions
RFC 1242 [3] "Benchmarking Terminology for Network Interconnect RFC 1242 [3] "Benchmarking Terminology for Network Interconnect
Devices" and RFC 2285 [4] "Benchmarking Terminology for LAN Switching Devices" and RFC 2285 [4] "Benchmarking Terminology for LAN Switching
Devices" contains discussions and definitions for a number of terms Devices" contains discussions and definitions for a number of terms
relevant to the benchmarking of signaling performance of reservation relevant to the benchmarking of signaling performance of reservation
capable routers and should be consulted before attempting to make use capable routers and should be consulted before attempting to make use
of this document. of this document.
skipping to change at page 3, line 44 skipping to change at page 3, line 45
special QoS treatment to a certain traffic flow. special QoS treatment to a certain traffic flow.
Discussion: Discussion:
The QoS treatment is specified by giving the amount of networking The QoS treatment is specified by giving the amount of networking
resources that are dedicated to the traffic flow during the length resources that are dedicated to the traffic flow during the length
of the reservation session. Depending on the protocol, there are of the reservation session. Depending on the protocol, there are
different approaches to define the network resource requirement of different approaches to define the network resource requirement of
a traffic flow. It can be described by high-level parameters, like a traffic flow. It can be described by high-level parameters, like
the required bandwidth, service class or the maximum traffic the required bandwidth, service class or the maximum traffic
delay; or it can be low-level information, like the parameters of delay; or it can be low-level information, like the parameters of
a leaky-bucket model of the traffic flow [11]. a leaky-bucket model of the traffic flow [10].
Issues: Issues:
There are resource reservation protocols, where resource There are resource reservation protocols, where resource
dedications in a router are unique for each resource reservation dedications in a router are unique for each resource reservation
session. However, in this case the number of resource dedications session. However, in this case the number of resource dedications
grows along with the number of sessions and working with huge grows along with the number of sessions and working with huge
number of resource dedications raise problems (see Reservation number of resource dedications raise problems (see Reservation
Session Maintenance). Therefore, many resource reservation Session Maintenance). Therefore, many resource reservation
protocols allow to bunch different reservation sessions into one protocols allow to bunch different reservation sessions into one
aggregated session, which takes only one resource dedication for aggregated session, which takes only one aggregated resource
the whole bunch. The aggregation can be based on the similar allocation for the whole bunch. The aggregation can be based on
attributes of the flows, (e.g. aggregation using DiffServ code- the similar attributes of the flows, (e.g. aggregation using
points [12]) or it can combine arbitrary sessions as well. DiffServ code-points [11]) or it can combine arbitrary sessions as
well.
See Also: See Also:
Reservation Session Maintenance Reservation Session Maintenance
6.1.2 Multicast Resource Reservation Session 6.1.2 Multicast Resource Reservation Session
Definition: Definition:
A multicast resource reservation session (or, in short, multicast A multicast resource reservation session (or, in short, multicast
reservation) denotes that certain QoS treatment is applied to the reservation) denotes that certain QoS treatment is applied to the
packets of every traffic flow related to a multicast group. packets of every traffic flow related to a multicast group.
skipping to change at page 4, line 25 skipping to change at page 4, line 28
Discussion: Discussion:
Usually, there are several traffic sources and destinations in a Usually, there are several traffic sources and destinations in a
multicast group. In order to be able to guarantee the QoS multicast group. In order to be able to guarantee the QoS
parameters for each packet of the multicast flow, every router parameters for each packet of the multicast flow, every router
that forwards the multicast traffic must dedicate resources to the that forwards the multicast traffic must dedicate resources to the
flow. flow.
Generally, there are two types of multicast resource reservations: Generally, there are two types of multicast resource reservations:
many-to-many and one-to-many multicast reservations. Those of the many-to-many and one-to-many multicast reservations. Those of the
first type allow traffic to be originated from several sources, first type allow traffic to be originated from several sources,
while those of the second type allow only one traffic source in while those of the second type permit only one traffic source in
the whole multicast group and it should not change during the the whole multicast group and this source should not change during
lifetime of the session. In several cases, a many-to-many the lifetime of the session. Additionally, in several cases, a
multicast reservation session does not require the same amount of many-to-many multicast reservation session does not require the
resources reserved for every involved router. Depending on the same amount of resources reserved in every involved router.
capabilities of the resource reservation protocol, the traffic Depending on the resource reservation protocol, the traffic
destinations in the multicast group may request different QoS destinations of the multicast group may request different QoS
parameters. Moreover, beside the different QoS requirements, the parameters. Furthermore, the protocols may describe more than one
protocols may describe more than one reservation styles expressing reservation styles expressing the resource reservation
the resource reservation distribution among the involved routers. distribution method among the involved routers. (e.g. RSVP
(e.g. RSVP SE/WF/FF [2]) SE/WF/FF [2])
Issues: Issues:
Naturally, many-to-many multicast reservation capable protocols Naturally, many-to-many multicast reservation capable protocols
are bound to be more complex than one-to-many or non-multicast are bound to be more complex than one-to-many or non-multicast
protocols. Usually, the router has to be aware of the location of protocols. Usually, the router has to be aware of the location of
the traffic sources and destinations participating in the the traffic sources and destinations participating in the
multicast reservation in the aspect of its network interfaces, multicast reservation in the aspect of its network interfaces,
plus the resource requirements of the traffic destinations in plus the resource requirements of the traffic destinations in
order to be able to calculate the right amount of resources order to be able to calculate the right amount of resources
dedicated to the session. dedicated to the session.
skipping to change at page 5, line 4 skipping to change at page 5, line 6
6.1.3 Resource Reservation Capable Router 6.1.3 Resource Reservation Capable Router
Definition: Definition:
By definition, a router is resource reservation capable - supports By definition, a router is resource reservation capable - supports
resource reservation - if it understands a resource reservation resource reservation - if it understands a resource reservation
protocol that signals the set-up, tear-down and modification of protocol that signals the set-up, tear-down and modification of
resource reservation sessions. resource reservation sessions.
Discussion: Discussion:
Resource reservation protocols define signaling messages that are Resource reservation protocols define signaling messages that are
interpreted by resource reservation capable routers. The router interpreted by resource reservation capable routers. The router
captures the signaling message and manipulates resource captures the signaling message and manipulates resource
reservation sessions according to the content of the message. In reservation sessions according to the content of the message. In
addition, the protocol might declare to forward the signaling addition, the protocol might declare to forward the same or a
message or an altered version of it to other routers as well. modified signaling message to other routers as well.
Issues: Issues:
There are resource reservation protocols where routers are There are resource reservation protocols where routers are
required to initiate signaling messages besides the signaling required to initiate signaling messages besides the signaling
message forwarding. The benefits of such protocols are that message forwarding. The benefits of such protocols are that
changes in resource reservation sessions can be signaled to other changes in resource reservation sessions can be signaled to other
routers immediately, even if the change is not caused by signaling routers immediately, even if the change is not caused by signaling
messages directly. In contrast, the message initiation takes time messages directly. In contrast, the message initiation takes time
that slows down the signaling message processing, so there are that slows down the signaling message processing, so there are
protocols where routers communicate with each other using the protocols declaring instant responses, where all the signaling
forwarded signaling messages. messages are forwarded to other routers immediately, avoiding the
signaling message initiation.
6.1.4 Signaling End-point 6.1.4 Signaling End-point
Definition: Definition:
A signaling end-point is a network node capable of initiating and A signaling end-point is a network node capable of initiating and
terminating resource reservation sessions. terminating resource reservation sessions.
Discussion: Discussion:
Typically, signaling end-points have a separate protocol stack Typically, signaling end-points have a separate protocol stack
that is capable of generating and understanding the signaling that is capable of generating and understanding the signaling
messages. However, in some special cases, the resource reservation messages. However, in some special cases, the resource reservation
initiation is carried out without the notice of the signaling initiation is carried out without the notice of the signaling
terminating node. For example, the Boomerang resource reservation terminating node. For example, the Boomerang resource reservation
protocol encapsulates the reservation requests in an ICMP Echo protocol encapsulates the reservation requests in an ICMP Echo
message. This message is bounced back from the signaling message. This message is bounced back from the signaling
terminating network node and as a result the node becomes a terminating network node and as a result the node becomes a
signaling end-point without understanding the reservation signaling end-point without understanding the reservation
protocol. protocol.
Reservation gateways are protocol translators that translate the There are reservation gateways that translate the signaling
signaling messages of one resource reservation protocol into messages of one resource reservation protocol into messages of
messages of another resource reservation protocol. Thus the another resource reservation protocol. Thus the reservation
reservation gateway represents two signaling end-points in one, as gateway represents two signaling end-points in one, as it is both
it is both a signaling terminator and a signaling initiator. a signaling terminator and a signaling initiator.
6.1.5 Reservation Initiator 6.1.5 Reservation Initiator
Definition: Definition:
The reservation initiator is the signaling end-point that The reservation initiator is the signaling end-point that
initiates the resource reservation session setup. initiates the resource reservation session setup.
Discussion: Discussion:
Resource reservation protocols can be classified depending on the Resource reservation protocols can be classified depending on the
relationship between the reservation initiators and their role in relationship between the reservation initiators and their role in
the traffic flow. the traffic flow.
In the case of receiver-oriented protocols, the traffic In the case of receiver-oriented protocols, the traffic
destinations, which are the receivers of the data traffic, destinations, which are the receivers of the data traffic,
initiate the reservation session setup, unlike the sender-oriented initiate the reservation session setup, unlike the sender-oriented
protocols where this is done by traffic sources. Moreover, there protocols where this is done by traffic sources. Moreover, there
are protocols where both the traffic source and destination can are protocols where both the traffic source and destination can
act as the reservation initiator. act as the reservation initiator.
skipping to change at page 6, line 22 skipping to change at page 6, line 26
The importance of the reservation initiator orientation is only The importance of the reservation initiator orientation is only
dominant in case of multicast reservation sessions. Generally, in dominant in case of multicast reservation sessions. Generally, in
multicast groups the number of traffic destinations changes more multicast groups the number of traffic destinations changes more
frequently than the number of traffic sources. In this case, the frequently than the number of traffic sources. In this case, the
receiver-oriented protocols do not require the traffic sources to receiver-oriented protocols do not require the traffic sources to
change their states generating signaling messages when a new change their states generating signaling messages when a new
traffic destination joins or an existing one leaves the group, traffic destination joins or an existing one leaves the group,
since the reservation session is managed by the traffic since the reservation session is managed by the traffic
destinations. destinations.
Issues:
Receiver-oriented resource reservation protocols often require two
pass to setup the reservation session. Since the resource
dedication should take place on all the routers that are on the
path from the sources to the destinations, thus the reservation
initiator must have a method to reach every such router. In the
case of the sender-oriented protocols this method is assured by
sending the signaling traffic same way as the data traffic, which
guarantees that signaling messages goes through the same routers
as the data traffic. However, in the case of the receiver-oriented
protocols the reservation initiation requests go from the
destinations to the sources, which is the opposite direction
compared to the data traffic. Thus, receiver-oriented protocols
must provide a mechanism that at first discovers all the routers
along the path of the data traffic (RSVP PATH message [2]), before
the second pass, where the traffic destinations are ready to
initiate resource reservation requests.
6.1.6 Reservation Session Maintenance 6.1.6 Reservation Session Maintenance
Definition: Definition:
Resource reservation protocols require the routers to maintain the Soft-state resource reservation protocols require the routers to
resource reservation sessions from the initiation until the maintain the resource reservation sessions from the initiation
teardown of the session. This maintenance often involves the until the teardown of the session. This maintenance often involves
regular checking and refreshing of the session. the regular checking and refreshing of the session.
Discussion: Discussion:
Based on the approach of reservation session maintenance, resource Based on the approach of reservation session maintenance, resource
reservation protocols can be divided into two categories: soft- reservation protocols can be divided into two categories: soft-
state protocols and hard-state protocols. state protocols and hard-state protocols.
In the case of hard-state protocols (e.g. ST2 [7]), the resource In the case of hard-state protocols (e.g. ST2 [7]), the resource
reservation session established by a set-up signaling primitive is reservation session established by a set-up signaling primitive is
permanent and is cancelled only when the corresponding tear-down permanent and is cancelled only when the corresponding tear-down
signaling primitive arrives to the router. Contrary, in the case signaling primitive arrives to the router. Contrary, in the case
skipping to change at page 7, line 18 skipping to change at page 7, line 42
one signaling message. one signaling message.
6.1.7 Signaling Path 6.1.7 Signaling Path
Definition: Definition:
A signaling path is a sequence of network nodes and links along A signaling path is a sequence of network nodes and links along
which signaling messages travel from one signaling end-point to which signaling messages travel from one signaling end-point to
the other. the other.
Discussion: Discussion:
In the case of sender-oriented protocols, the data traffic and the The resource reservation protocol must provide that each router,
signaling messages are addressed to the IP address of the which is responsible to handle a signaling message, truly receives
destination and therefore routed on the same path. Thus the the signaling message. Usually it is assured by passing through
signaling messages are delivered to every router that handles the the signaling messages along the signaling path, which involves
traffic flow to which the reservation session refers. No more and every router affected by the resource reservation session.
no fewer routers are affected. However, in the case of receiver-
oriented protocols, the reservation request and the data traffic
are forwarded in opposite directions. And since Internet routing
is not symmetric, it is not trivial that they go through the same
routers. To assure that the signaling messages reach every router
that handles the traffic flow from the source to the destination,
the traffic sources should issue a special message addressed to
the destinations marking the path for the reservation session.
Each router that receives the path dedicating signaling message
remembers the address of the node where the message came from, and
when a signaling message arrives carrying reservation information
it is forwarded to the address of the previous node. Thus the path
dedicating messages mark out a path along which the reservation
messages travel backward.
In the case of a multicast reservation session, the situation is Resource reservation protocol must be also prepared that there are
slightly more complicated. The signaling path is rather a routers forwarding the data traffic of a resource reservation
signaling mesh where the signaling messages travel from the session that do not support the actual resource reservation
sources to the destinations. protocol. In this case the signaling traffic must be tunneled
through the zones of the routers that can not interpret the
signaling messages in order to keep the continuity of the
signaling path.
Issues: Issues:
It is not unusual for routers to change their routing from time to It is not unusual for routers to change their routing from time to
time. The reason for the change can be a failure of a neighboring time. One reason for the change can be a failure of a neighboring
router or link. In case of route changes the data traffic will be router or link. In case of route changes the data traffic will be
forwarded along a different path than the signaling messages used forwarded along a different path than the signaling messages used
in establishing the resource dedications for the reservation in establishing the resource dedications for the reservation
session. In order to properly handle this situation, hard-state session. In order to properly handle this situation, hard-state
protocols have to be much more sophisticated in order to detect protocols have to be much more sophisticated in order to detect
the route change and to re-reserve the resources on the new path. the route change and to re-reserve the resources on the new path.
However, soft-state protocols do not have to worry about such However, soft-state protocols do not have to worry about such
situation, since the refresh messages can be used to set up the situation, since the refresh messages can be used to set up the
reservation on the new path and the dedicated resources will reservation on the new path and the dedicated resources will
eventually disappear from routers of the obsoleted path. eventually disappear from routers of the obsoleted path.
skipping to change at page 8, line 30 skipping to change at page 8, line 43
associated flow descriptor that is established by the signaling associated flow descriptor that is established by the signaling
messages during the reservation session setup. messages during the reservation session setup.
The router may distinguish several types of premium traffic (e.g. The router may distinguish several types of premium traffic (e.g.
delay sensitive traffic, loss sensitive traffic, etc.). Different delay sensitive traffic, loss sensitive traffic, etc.). Different
types of premium traffic may receive different QoS treatment. types of premium traffic may receive different QoS treatment.
Issues: Issues:
The router has to identify every packet whether it has dedicated The router has to identify every packet whether it has dedicated
resource or not. This can be done by either multi-field resource or not. This can be done by either multi-field
classification [12] using the IP 5-tuple or behavior-aggregate classification [11] using the IP 5-tuple or behavior-aggregate
classification using the DSCP field. However, if a packet claims classification using the DSCP field. However, if a packet claims
that it has an associated resource reservation session in the that it has an associated resource reservation session in the
router, the router has to find the flow descriptor, which might be router, the router has to find the flow descriptor, which might be
time consuming in routers with vast amounts of resource time consuming in routers with vast amounts of resource
reservation sessions. reservation sessions.
6.2.2 Best-Effort Traffic 6.2.2 Best-Effort Traffic
Definition: Definition:
Best-effort traffic is a traffic type that has no reservation Best-effort traffic is a traffic type that has no reservation
skipping to change at page 8, line 55 skipping to change at page 9, line 16
are considered to be best-effort traffic. "Best-effort" means that are considered to be best-effort traffic. "Best-effort" means that
the router makes its best effort to forward every data packet, but the router makes its best effort to forward every data packet, but
does not guarantee anything. This is the most common type of does not guarantee anything. This is the most common type of
traffic on today's Internet. (There may be scenarios where traffic on today's Internet. (There may be scenarios where
resource reservation is done for BE traffic too, but those are resource reservation is done for BE traffic too, but those are
outside of the focus of this memo.) outside of the focus of this memo.)
6.3 Router Load Types 6.3 Router Load Types
This group of definitions describes different load component types This group of definitions describes different load component types
that are independent of each other and impact only a specific part of that impact only a specific part of the resource reservation capable
the resource reservation capable router's control plane. Arbitrary router. Categorizing the router load is crucial, since the
router load can be derived from the combination of different amount conventional router load metric expressing the processing power
of such independent load components. utilization of the router does not characterize perfectly the
resource reservation capable router. In the case of routers
supporting resource reservations it is also important to know the
source of the processing power utilization.
6.3.1 Session Load 6.3.1 Traffic Load
Definition:
Traffic load is the load that is raised by forwarding data traffic
on the router.
Discussion:
It is obvious that forwarding the data packets, which requires
obtaining the routing information and transferring the data packet
between network interfaces, requires processing power. Speaking of
general router measurements only this type of load is considered
as the source of the processing power utilization expressed by the
router load metric. Although the traffic load is the dominant load
component, benchmarking routers supporting resource reservations
must consider other load components also in line with the resource
reservation handling.
Measurement unit:
The amount of the traffic load is represented by the volume of the
data traffic. The volume is measured with the transferred bits
during a specified time unit, which is typically bit per seconds
(bps).
6.3.2 Session Load
Definition: Definition:
Session load is the load that manifests itself as the excess Session load is the load that manifests itself as the excess
processing power required to keep track of reservation sessions. processing power required to keep track of reservation sessions.
Discussion: Discussion:
All signaling based resource reservation protocol implementation All signaling based resource reservation protocol implementation
employ a packet classifier algorithm that distinguishes the flows employ a packet classifier algorithm that distinguishes the flows
having reservations in the router from the others that do not. having reservations in the router from the others that do not.
Therefore each implementation maintains a list of reservation Therefore each implementation maintains a list of reservation
skipping to change at page 9, line 52 skipping to change at page 10, line 38
signaling end-points have their own schedule for the refresh signaling end-points have their own schedule for the refresh
message initiation. The first approach lightens the load of the message initiation. The first approach lightens the load of the
session maintenance task; however, the second approach bears the session maintenance task; however, the second approach bears the
ability to adjust the signaling message traffic intensity along ability to adjust the signaling message traffic intensity along
the signaling path. the signaling path.
Measurement unit: Measurement unit:
The session load is represented by the number of reservation The session load is represented by the number of reservation
sessions in the router. sessions in the router.
6.3.2 Signaling Load 6.3.3 Signaling Load
Definition: Definition:
Signaling load is the load that manifests itself as the time Signaling load is the load that manifests itself as the time
required to process the incoming signaling messages. required to process the incoming signaling messages.
Discussion: Discussion:
The processing of signaling messages requires processing power The processing of signaling messages requires processing power
that raises load on the control plane of the router. In the case that raises load on the control plane of the router. In the case
of routers where the control plane and the data plane are not of 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 by
skipping to change at page 10, line 26 skipping to change at page 11, line 12
these message types may require a different amount of processing these message types may require a different amount of processing
power from the router. power from the router.
Measurement unit: Measurement unit:
The signaling load is characterized by the signaling intensity, The signaling load is characterized by the signaling intensity,
which expresses how many signaling messages arrive to the router which expresses how many signaling messages arrive to the router
within a time unit. The typical unit of the signaling intensity is within a time unit. The typical unit of the signaling intensity is
[1/s], which is the number of signaling messages that arrive [1/s], which is the number of signaling messages that arrive
within one second. within one second.
6.3.3 Signaling Burst 6.3.4 Signaling Burst
Definition: Definition:
The signaling burst denotes a certain number of signaling messages The signaling burst denotes a certain number of signaling messages
that arrive to the input port(s) of the router without that arrive to the input port(s) of the router without
interruption, causing persistent load on the signaling message interruption, causing persistent load on the signaling message
handler. handler.
Discussion: Discussion:
Back-to-back signaling messages on one port of the router form a Back-to-back signaling messages on one port of the router form a
typical signaling burst. However, other cases are imaginable, for typical signaling burst. However, other cases are imaginable, for
skipping to change at page 10, line 48 skipping to change at page 11, line 34
simultaneously or with an overlap in time (i.e. when the tail of simultaneously or with an overlap in time (i.e. when the tail of
one signaling message is behind the head of another one arriving one signaling message is behind the head of another one arriving
on another port). on another port).
Measurement unit: Measurement unit:
The signaling burst is characterized by its length, which is the The signaling burst is characterized by its length, which is the
number of messages that have arrived during the burst. number of messages that have arrived during the burst.
6.4 Performance Metrics 6.4 Performance Metrics
This group of definitions is a collection of the measurable effects This group of definitions is the collection of the measurable impacts
of the impact a resource reservation protocol has on the router that a resource reservation protocol has over the tested router
device it is running on. device it is running on.
6.4.1 Signaling Message Handling Time 6.4.1 Signaling Message Handling Time
Definition: Definition:
The signaling message handling time (or, in short, signal handling The signaling message handling time (or, in short, signal handling
time) is the time that a signaling message spends inside the time) is the time that a signaling message spends inside the
router before it is forwarded to the next node on the signaling router before it is forwarded to the next node on the signaling
path. path.
skipping to change at page 12, line 52 skipping to change at page 13, line 37
Discussion: Discussion:
There are certain types of signaling messages, which are required There are certain types of signaling messages, which are required
to be forwarded by the router immediately when their processing is to be forwarded by the router immediately when their processing is
finished. However, due to the high router load or for other finished. However, due to the high router load or for other
reasons, the forwarding or even the processing of the signaling reasons, the forwarding or even the processing of the signaling
message might be canceled. To characterize such situations we message might be canceled. To characterize such situations we
introduce the signaling message loss metric, which expresses the introduce the signaling message loss metric, which expresses the
ratio of the signaling messages that actually have left the router ratio of the signaling messages that actually have left the router
and those ones that were expected to leave the router as a result and those ones that were expected to leave the router as a result
of the incoming signaling messages processing. of the incoming sequence of signaling messages.
Since the most frequent reason for the signaling message loss is Since the most frequent reason for the signaling message loss is
the high router load, therefore this metric is suitable for the high router load, therefore this metric is suitable for
sounding out the scalability limits of resource reservation sounding out the scalability limits of resource reservation
capable routers. capable routers.
Issues: Issues:
In the case of routers where network packets are queued in several In the case of routers where network packets are queued in several
places, we have to be aware of that a signaling message may be places, we have to be aware of that a signaling message may be
delayed seriously. Therefore, it may be hard or impossible to delayed seriously. Therefore, it may be hard or impossible to
determine whether the signaling message is still in the queues or determine whether the signaling message is still in the queues or
whether it was already dropped. By definition we say that a whether it was already dropped. By definition we say that a
signaling message is lost if there is no appearing forwarded signaling message is lost if there is no appearing forwarded
signaling message within a reasonable long time period. This time signaling message within a reasonable long time period. This time
period should be adjusted to the actual resource reservation period should be adjusted to the actual resource reservation
protocol (e.g. soft-state protocols may wait as much as the protocol (e.g. soft-state protocols may wait as much as the
refresh period to determine the loss of a signaling message) refresh period to determine the loss of a signaling message).
Measurement unit: Measurement unit:
Usually, we measure the signaling message loss over a longer Usually, we measure the signaling message loss over a longer
period of time and then we express it as a percentage value. period of time and then we express it as a percentage value.
Besides, in many cases it is enough to know that there was Besides, in many cases it is enough to know that there was
signaling loss. signaling loss.
6.4.5 Scalability Limit 6.4.5 Session Refreshing Capacity
Definition:
The session refreshing capacity is the ratio of the truly
refreshed sessions and the number of session that have to be
refreshed during one refresh period. This metric is applied for
soft-state routers only.
Discussion:
The session refreshing capacity informs about condition of the
session maintenance. When the router is overloaded it may happen
that the router is not capable to refresh all the allocated
reservation sessions due to other tasks with higher priorities. In
this case sooner or later the resource reservation sessions over
the session refresh capacity are dropped even if the resource
reservation end-points are still refreshing them.
The session refreshing capacity sounds out the limit of resource
reservation session number that the router is capable to maintain.
Measurement unit:
The session refreshing capacity is expressed as a percentage
value.
6.4.6 Scalability Limit
Definition: Definition:
The scalability limit is the threshold between the steady state The scalability limit is the threshold between the steady state
and the overloaded state of the device under test. and the overloaded state of the device under test.
Discussion: Discussion:
All existing routers have finite buffer memory and finite All existing routers have finite buffer memory and finite
processing power. In the steady state of the router, the buffer processing power. In the steady state of the router, the buffer
memories are not fully utilized and the processing power is enough memories are not fully utilized and the processing power is enough
to cope with all tasks running on the router. As the router load to cope with all tasks running on the router. As the router load
skipping to change at page 14, line 7 skipping to change at page 15, line 17
7. Acknowledgement 7. Acknowledgement
We would like to thank the following individuals for their help in We would like to thank the following individuals for their help in
forming this document: Joakim Bergkvist and Norbert Vegh from Telia forming this document: Joakim Bergkvist and Norbert Vegh from Telia
Research AB, Sweden, Krisztian Nemeth, Balazs Szabo, Gabor Kovacs and Research AB, Sweden, Krisztian Nemeth, Balazs Szabo, Gabor Kovacs and
Peter Vary from High Speed Networks Laboratory of Budapest University Peter Vary from High Speed Networks Laboratory of Budapest University
of Technology and Economics, Hungary. of Technology and Economics, Hungary.
8. References 8. References
[1] Y. Bernet, et. al., "A Framework For Integrated Services [1] Y. Bernet, et. al., "A Framework for Integrated Services
Operation Over Diffserv Networks", Internet Draft, work in Operation over Diffserv Networks", RFC 2998, November 2000
progress, May 2000, <draft-ietf-issll-diffserv-rsvp-05.txt>
[2] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) - [2] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) -
Version 1 Functional Specification", RFC 2205, September 1997. Version 1 Functional Specification", RFC 2205, September 1997.
[3] S. Bradner, "Benchmarking Terminology for Network [3] S. Bradner, "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991 Interconnection Devices", RFC 1242, July 1991
[4] R. Mandeville, "Benchmarking Terminology for LAN Switching [4] R. Mandeville, "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998 Devices", RFC 2285, February 1998
[5] J. Bergkvist, I. Cselenyi, D. Ahlard, "Boomerang - A Simple [5] G. Feher, K. Nemeth, M. Maliosz, "Boomerang : A Simple Protocol
Resource Reservation Framework for IP", Internet Draft, work in for Resource Reservation in IP Networks," Vancouver, IEEE Real-
progress, November 2000, <draft-bergkvist-boomerang-framework- Time Technology and Applications Symposium, June 1999
00.txt>
[6] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism [6] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism
for the Internet", Computer Communication Review, on-line for the Internet", Computer Communication Review, on-line
version, volume 29, number 2, April 1999 version, volume 29, number 2, April 1999
[7] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 [7] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2
(ST2) Protocol Specification - Version ST2+", RFC 1819, August (ST2) Protocol Specification - Version ST2+", RFC 1819, August
1995 1995
[8] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated [8] 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
[9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight [9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight
Resource Reservation for Unicast IP Traffic", International WS Resource Reservation for Unicast IP Traffic", International WS
on QoS'98, IWQoS'98, May 18-20, 1998 on QoS'98, IWQoS'98, May 18-20, 1998
[10] L. Westberg, Z. R. Turanyi, D. Partain, Load Control of Real- [10] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
Time Traffic, A Two-bit Resource Allocation Scheme, Internet
Draft, work in progress, <draft-westberg-loadcntr-03.txt>, April
2000
[11] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997 RFC 2210, September 1997
[12] K. Nichols et al., "Definition of the Differentiated Services [11] K. Nichols et al., " Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers ", RFC 2474 Field (DS Field) in the IPv4 and IPv6 Headers ", RFC 2474
9. Authors' Addresses: 9. Authors' Addresses:
Gabor Feher Gabor Feher
Budapest University of Technology and Economics (BUTE) Budapest University of Technology and Economics (BUTE)
Department of Telecommunications and Telematics Department of Telecommunications and Telematics
Pazmany Peter Setany 1/D, H-1117, Budapest, Hungary Pazmany Peter Setany 1/D, H-1117, Budapest, Hungary
Phone: +36 1 463-3110 Phone: +36 1 463-3110
Email: feher@ttt-atm.ttt.bme.hu Email: feher@ttt-atm.ttt.bme.hu
 End of changes. 

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