Benchmarking Working Group                             Gabor Feher, BUTE
INTERNET-DRAFT                                     Istvan Cselenyi, TRAB
Expiration Date: May 2002 2003                              Andras Korn, BUTE

                                                           November 2001 2002

  Benchmarking Terminology for Routers Supporting Resource Reservation

1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft shadow directories can be accessed at

   This memo provides information for the Internet community. This memo
   does not specify an Internet standard of any kind. Distribution of
   this memo is unlimited.

2. Table of contents

   1. Status of this Memo.............................................1
   2. Table of contents...............................................1
   3. Abstract........................................................2
   4. Introduction....................................................2
   5. Existing definitions............................................3
   6. Definition of Terms.............................................3
      6.1 Resource Reservation Protocol Basics........................3
         6.1.1 Unicast Resource Reservation Session...........................3 Session...................3
         6.1.2 Multicast Resource Reservation Session.................4
         6.1.3 Resource Reservation Capable Router....................4
         6.1.4 Signaling End-point....................................5
         6.1.5 Reservation Initiator..................................5 Orientation................................5
         6.1.6 Reservation Session Maintenance........................6 State..............................6
         6.1.7 Signaling Path.........................................7
      6.2 Traffic Types...............................................8
         6.2.1 Premium Traffic........................................8
         6.2.2 Best-Effort Traffic....................................8 Data Packets...............................8

Feher, Cselenyi, Korn          Expires May 2003                 [Page 1] 
         6.2.2 Premium Data Packets...................................8
      6.3 Router Load Types...........................................9
         6.3.1 Traffic Load...........................................9
         6.3.2 Session Load...........................................9
         6.3.3 Signaling Load........................................10
         6.3.4 Signaling Burst.......................................11
      6.4 Performance Metrics........................................11
         6.4.1 Signaling Message Handling Time.......................11
         6.4.2 Premium Traffic Delay.................................12
         6.4.3 Best-effort Traffic Delay.............................13 Delay.............................12
         6.4.4 Signaling Message Loss................................13
         6.4.5 Session Refreshing Capacity...........................14 Capacity...........................13
         6.4.6 Scalability Limit.....................................14
   7. Acknowledgement................................................15 Security Considerations........................................14
   8. References.....................................................15 Acknowledgement................................................15
   9. References.....................................................15
   10. Authors' Addresses:............................................15 Addresses............................................16

3. Abstract

   The purpose of this document is to define terminology specific to the
   benchmarking of the resource reservation signaling of IP routers.
   These terms are can be used in additional documents that define
   benchmarking methodologies for routers supporting resource
   reservation and define reporting formats for the benchmarking

4. Introduction

   The IntServ over DiffServ framework [1] outlines a heterogeneous
   Quality of Service (QoS) architecture for multi domain Internet
   services. Signaling based resource reservation (e.g. via RSVP [2]) is
   an integral part of that model. While this approach significantly
   lightens the load on most of the core routers, the performance of
   border routers that handle the QoS signaling is still crucial. Therefore
   network operators, who are planning to deploy this model, shall
   scrutinize the scalability limitations in of reservation capable routers
   and the impact of signaling on the forwarding performance of the

   An objective way for quantifying the scalability constraints of QoS
   signaling is to perform measurements on routers that are capable of
   resource reservation. This document defines terminology for specific
   set of tests that vendors or network operators can use to measure and
   report the signaling performance characteristics of router devices
   that support resource reservation protocols. The results of these
   tests provide comparable data for different products supporting the
   decision process before purchase. Moreover, these measurements
   provide input characteristics for the dimensioning of a network in
   which resources are provisioned dynamically by signaling. Finally,
   the tests are applicable for characterizing the impact of the control
   resource reservation signaling on the forwarding performance of the

Feher, Cselenyi, Korn          Expires May 2003                 [Page 2] 
   This benchmarking terminology document is based on the knowledge
   gained by examination of (and experimentation with) several very
   different resource reservation protocols: RSVP [2], Boomerang [5],
   YESSIR [6], ST2+ [7], SDP [8] and Ticket [9]. Nevertheless, this
   document aspires to compose defines terms that are valid in general and not restricted
   to these protocols.

5. Existing definitions

   RFC 1242 [3] "Benchmarking Terminology for Network Interconnect
   Devices" and RFC 2285 [4] "Benchmarking Terminology for LAN Switching
   Devices" contains discussions and definitions for a number of terms
   relevant to the benchmarking of signaling performance of reservation
   capable routers and should be consulted before attempting to make use
   of this document.

   For the sake of clarity and continuity this document adopts the
   template for definitions set out in Section 2 of RFC 1242.
   Definitions are indexed and grouped together in into different sections
   for ease of reference.

6. Definition of Terms

6.1 Resource Reservation Protocol Basics

   This group of definitions applies to various signaling based resource
   reservation protocols implemented on IP router devices.

6.1.1 Unicast Resource Reservation Session

      The term unicast resource reservation session (or shortly reservation)
      reservation session) expresses that routers along the data path between two end-nodes explicitly
      request the network nodes apply nodes, which forward their data flow, to
      assign special QoS treatment for data packets belonging to a certain traffic the

      The QoS treatment is specified defined by giving specifying the amount of
      networking resources that are should be dedicated to the traffic data flow
      during the length of the reservation session. Depending on the protocol, there There are different approaches
      approaches, how to define specify the network resource requirement of a traffic
      data flow. It can be described by high-level parameters, like the
      required bandwidth, service class bandwidth or the maximum traffic data delay; or it can be low-level low-
      level information, like such as the parameters of a leaky-bucket model of
      describing the traffic data flow [10].

      There are resource reservation protocols, where resource
      dedications in a router are unique for each resource reservation
      session. However,

      Reservation sessions must be uniquely registered in this case network nodes
      assuring the number of resource dedications
      grows along with QoS treatments. Practically, the number transport address of sessions
      the destination end-node and working with huge
      number the transport protocol of resource dedications raise problems (see Reservation
      Session Maintenance). Therefore, many resource reservation
      protocols allow the
      communication are sufficient to bunch different reservation sessions into one
      aggregated session, which takes only one aggregated resource
      allocation for distinguish the whole bunch. The aggregation can be based on reservations,

Feher, Cselenyi, Korn          Expires May 2003                 [Page 3] 
      however in extreme cases the similar attributes transport address of the flows, (e.g. aggregation using
      DiffServ code-points [11]) or it can combine arbitrary sessions source
      should be included as well.

   See Also:
      Reservation Session Maintenance State

6.1.2 Multicast Resource Reservation Session

      A multicast resource reservation session (or, in short, multicast
      reservation session) denotes that certain QoS treatment is applied to end-nodes forming a multicast
      group ask the network nodes, which forward the data packets of every traffic flow related the
      multicast group, to assign a multicast group. certain QoS treatment to their data

      In a multicast group there are can be several data traffic sources and destinations
      destinations. The required QoS treatment is specified the same way
      as in a
      multicast group. In order to be able to guarantee the QoS
      parameters for each packet case of the multicast flow, every router
      that forwards unicast resource reservation sessions. In
      the case of multicast traffic must dedicate reservations, however, unlike in the case of
      unicast reservations, the amount of reserved network resources
      does not have to be the
      flow. same on each network node forwarding the
      multicast data traffic. Multicast reservations must be registered
      in network nodes forwarding the associated data traffic similarly
      as it happens in the unicast case.

      Generally, there are two types of multicast resource reservations:
      many-to-many and one-to-many multicast reservations. one-to-many. Those of the first type allow
      multicast data traffic to be originated from several sources,
      while those of the second type permit only one fix data traffic
      source in the whole multicast group and this source should that must not change during
      the lifetime of the session. Additionally, in several cases, a
      many-to-many multicast reservation session does not require the
      same amount of resources reserved in every involved router.
      Depending on the resource reservation protocol, the traffic
      destinations of the multicast group may request different QoS
      parameters. Furthermore, the protocols may describe more than one
      reservation styles expressing the resource reservation
      distribution method among the involved routers. (e.g. RSVP
      SE/WF/FF [2])

      Naturally, many-to-many multicast reservation capable protocols
      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
      the traffic sources and destinations participating in the
      multicast reservation in the aspect of its network interfaces,
      plus the resource requirements of the traffic destinations in
      order to be able to calculate the right amount of resources
      dedicated to the session.

6.1.3 Resource Reservation Capable Router

      By definition, a
      A router is resource reservation capable - -- supports resource
      reservation - -- if it understands a resource reservation protocol
      that signals the set-up, tear-down and modification of resource
      reservation sessions.

      Resource reservation protocols define signaling messages that are
      interpreted by resource reservation capable routers. The router
      captures the signaling message and manipulates the resource
      reservation sessions and/or the reserved network resources
      according to the content of the message. In
      addition, the protocol might declare to forward the same or a
      modified signaling message to other routers as well.

      There are
      Despite that resource reservation protocols where routers sessions are
      required considered to initiate signaling messages besides the signaling
      message forwarding. The benefits of such protocols are that
      changes in be
      unique, resource reservation capable routers might aggregate them
      and allocate network resources to these aggregated sessions at
      once. The aggregation can be signaled to other
      routers immediately, even if the change is not caused by signaling
      messages directly. In contrast, the message initiation takes time
      that slows down based on similar flow attributes

Feher, Cselenyi, Korn          Expires May 2003                 [Page 4] 
      (e.g. aggregation using DiffServ code-points [11]) or it can
      combine arbitrary sessions as well. While reservation aggregation
      significantly lightens the signaling message processing, so there are
      protocols declaring instant responses, where all processing task of a resource
      reservation capable router, it also requires the signaling
      messages are forwarded administration of
      the aggregated flows and might also lead to other routers immediately, avoiding the
      signaling message initiation. violation of the
      quality guaranties of individual reservations within an

6.1.4 Signaling End-point

      A signaling end-point is a network node capable of initiating and
      terminating resource reservation sessions.

      Besides traditional end-systems, there is also another type of
      signaling end-point: the reservation gateways. Reservation
      gateways translate the signaling messages of one resource
      reservation protocol into messages of another resource reservation
      protocol. Thus the reservation gateway represents two signaling
      end-points in one, as it is both a signaling terminator and a
      signaling initiator.

      Typically, signaling end-points have a separate dedicated protocol stack
      that is capable of generating stack,
      which interprets and understanding generates the signaling messages. However, in
      some special cases, the resource reservation initiation is carried
      out without the notice of the signaling terminating node. For
      example, the Boomerang resource reservation protocol encapsulates
      the reservation requests in an ICMP Echo message. This message is
      bounced back from the signaling terminating network node ("Far-End
      Node") and as a result the node becomes a signaling end-point
      without understanding the reservation protocol.

      There are reservation gateways that translate the signaling
      messages of one resource reservation protocol into messages of
      another resource reservation protocol. Thus the reservation
      gateway represents two signaling end-points in one, as it is both
      a signaling terminator and a signaling initiator.

6.1.5 Reservation Initiator Orientation

      The reservation initiator is the orientation tells which signaling end-point that end-point(s)
      initiates the resource network resources allocation to obtain special QoS
      treatment for the data traffic of the reservation session setup. session.

      Resource reservation protocols can be classified into two groups
      depending on the relationship between the reservation initiators
      and their role in the data traffic flow.

      In First, there are sender-
      oriented protocols, where the source(s) of the reservation
      sessionĘs data traffic initiates the network resource allocation
      message. Second, in the case of the receiver-oriented protocols,
      the traffic
      destinations, which are the receivers receiver(s) of the reservation sessionĘs data traffic,
      initiate traffic
      initiates the reservation session setup, unlike resource allocation messages. Due to the sender-oriented
      protocols where this is done by traffic sources. Moreover, there
      are protocols where both asymmetric
      routing nature of the traffic source and destination can
      act as Internet, in the reservation initiator.

      The importance of latter case, the reservation initiator orientation is only
      dominant in case of multicast reservation sessions. Generally, in
      multicast groups
      receiver(s) should know the number route(s) of traffic destinations changes more
      frequently than the number of desired data traffic sources. In
      before it would be able to send the resource allocation

Feher, Cselenyi, Korn          Expires May 2003                 [Page 5] 
      message(s). For this case, reason, even in the
      receiver-oriented protocols do not require second case, the traffic sources to
      change their states generating first
      signaling messages when a new
      traffic destination joins or an existing one leaves the group,
      since message(s) establishing the reservation session is managed by the traffic

      Receiver-oriented resource reservation protocols often require two
      pass to setup comes
      from the reservation session. Since source(s) of the resource
      dedication should take place on all data traffic marking the routers that are route(s) on
      which the
      path from resource allocation message(s) might travel backward.

      The orientation of the sources to reservation initiator affects the destinations, thus basics of
      the resource reservation
      initiator must have a method to reach every such router. protocols and therefore it is an
      important design decision. In the case of multicast reservation
      sessions, the sender-oriented protocols this method is assured by
      sending require the signaling traffic same way as the data traffic, which
      guarantees that signaling
      sources to maintain a list of receivers and send their allocation
      messages goes through considering the same routers
      as requirements of the data traffic. However, in receivers. A less
      polite, but less demanding solution is when the case sources ignore the
      QoS requirements of the receiver-oriented
      protocols receivers and send the reservation initiation allocation requests go from
      at will. Using multicast reservation sessions, the
      destinations to receiver-
      oriented protocols give the sources, which is chance to the opposite direction
      compared receivers to place their
      own resource allocation requests and thus ease the data traffic. Thus, receiver-oriented protocols
      must provide a mechanism that at first discovers all task of the routers
      sources. However, in this case the path resource allocations must be
      preceded by the marking of the data traffic (RSVP routes of the reservation
      session (c.f. RSVP PATH message [2]), before [2]). In case of large multicast
      groups, enabling the second pass, where receivers to specify their QoS requirements,
      the traffic destinations are ready receiver-oriented approach seems to
      initiate resource reservation requests. be a better choice,
      however in other cases the sender-oriented protocols promise less

6.1.6 Reservation Session Maintenance State

      Soft-state resource
      A reservation protocols require session state is a holder for all the relevant
      information about the corresponding reservation session registered
      in the resource reservation capable router.

      Resource reservation capable routers to maintain reservation session
      states to store information about the resource reservation sessions from session. This
      information might include the initiation
      until QoS treatment that the reservation
      session requires; the teardown description of how and where to forward the session. This maintenance often involves
      incoming signaling messages; policies regarding the regular checking and refreshing of QoS treatment
      or the session.

   Discussion: reservation session; timing information about the
      reservation session; etc.

      Based on the approach of how reservation session maintenance, resource states are stored in a
      reservation protocols capable router, the routers can be divided categorized into two categories: soft-
      state protocols and hard-state protocols.

      In the case of hard-state protocols
      three classes:

      Hard-state resource reservation capable routers (e.g. ST2 [7]), capable
      routers [7]) store the resource reservation session states permanently,
      established by a set-up signaling primitive is
      permanent and is cancelled only when the primitive, until a corresponding
      tear-down signaling primitive arrives to the router. Contrary, in or until the case
      of router is
      informed that the reservation session canceled.

      There are also soft-state protocols resource reservation capable routers,
      where there are no permanent resource
      reservations. The resource reservation session states, but each

Feher, Cselenyi, Korn          Expires May 2003                 [Page 6] 
      state have to be regularly refreshed by appropriate refresh
      signaling messages. No If no refresh signaling message arrived arrives during
      a certain period is assumed as then the indication that router cancels the resource reservation session is not
      maintained by
      assuming that the signaling end-points do not intend to keep up
      the reservation session any longer. In such case, longer or the router tears communication lines are
      broken somewhere along the session down waiting for no explicit request.
      For this reason, soft-state protocols exhibit data path. This feature makes soft-
      state resource reservation capable routers more robust behavior than hard-state protocols, hard-
      state routers, since no failures can cause permanent resource
      stuck in the routers.

      Finally, there are stateless resource reservation capable routers
      storing no information about the individual reservation sessions.
      Without reservation session states the resource reservation
      capabilities of such routers are limited, e.g. there is no support
      for many-to-many multicast resource reservation sessions; and the
      reservation session must be sender oriented.

      Although soft-state protocols reservation capable routers are more robust
      than hard-state
      protocols, ones, the frequent processing of refresh signaling
      messages or the detection of the missing reservation session state
      refreshes might cause serious increase in the router load. Moreover, session
      maintenance mechanisms often use timers to watch the refresh
      period expirations of the sessions. The maintenance of such timers
      and the actions due to the expiration load, which
      can be a base of such timers also
      contributes to the router load. scalability problems. In order to reduce decrease
      the large number of refresh signaling message
      processing overhead, messages, the resource reservation protocol may
      capable router might support various mechanisms to pack several
      refresh signaling messages into one signaling larger message.

6.1.7 Signaling Path

      A signaling path is a sequence of network nodes and links along
      which signaling messages travel from one signaling end-point to
      the other.

      The resource
      Resource reservation protocol capable routers must provide assure that each all other
      router, which is responsible to handle a for handling the actual signaling
      message, truly really receives
      the signaling that message. Usually it is assured by passing through Therefore, routers forward
      the signaling messages along the signaling path, which involves
      every router path and each router,
      affected by the message, processes it.

      Usually signaling messages are immediately forwarded by resource
      reservation session.

      Resource reservation protocol must be also prepared that there are capable routers forwarding towards the data traffic of a resource reservation
      session destination(s), spreading
      the information as fast as possible. However, there might be
      protocol messages that do not support the actual resource reservation
      protocol. In this case the signaling traffic must be tunneled
      through the zones of affect all the routers that can not interpret along the
      signaling path, but only a subset of it (e.g. refresh messages in order to keep the continuity
      RSVP). These kinds of the signaling path.


      It is not unusual for messages are terminated by routers to change their routing from time to
      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
      when they are not necessary anymore.

      Resource reservation capable routers must be
      forwarded prepared that there
      are other routers along a different path than the signaling messages used
      in establishing path unable to interpret the
      actual resource dedications for the reservation
      session. In order to properly handle this situation, hard-state
      protocols have to be much more sophisticated protocol. Even in order to detect
      the route change and to re-reserve the resources on the new path.
      However, soft-state protocols do not have to worry about such
      situation, since this case the refresh

Feher, Cselenyi, Korn          Expires May 2003                 [Page 7] 
      signaling messages can must be used delivered to set up the all corresponding resource
      reservation on the new path and the dedicated resources will
      eventually disappear from capable routers (usually using some kind of the obsoleted path.

6.2 Traffic Types

   This group of definitions defines traffic types forwarded by resource
   reservation capable routers.

6.2.1 Premium Traffic Best-Effort Data Packets

      Premium traffic
      Best-effort data packet is a packet that has no associated
      resource reservation session in the routers and thus it is served
      in the "default" way.

      Data packets that do not require QoS guarantees along their path
      are considered to be best-effort packets. "Best-effort" means that
      the router makes its best effort to forward the data packet
      quickly and safely, but does not guarantee anything (e.g. delay or
      loss probability). This type of traffic is the most common type in
      today's Internet. (There may be scenarios where resource
      reservation is done even for best-effort traffic too, but those
      are outside of the focus of this memo.) We will refer to the
      traffic of the best-effort data packets shortly as best-effort

6.2.2 Premium Data Packets

      Premium data packets are the packets that the resource reservation
      capable router distinguishes from best-effort traffic (to be defined later) packets and forwards its
      them according to a QoS agreement.

      Data packets that corresponds correspond to a resource reservation session in
      the router is are premium traffic. data packets. The QoS treatment is defined
      in the associated resource reservation state (e.g. flow descriptor
      descriptor) that is established by the signaling messages during the
      reservation session setup.

      The router may distinguish several types of premium traffic (e.g.
      delay sensitive traffic, loss sensitive traffic, etc.). Different premium. Data packets
      belonging to different types of premium traffic may receive
      different QoS treatment. We will refer to the traffic of the
      premium data packets shortly as premium traffic.

      The router has to identify every packet whether it has dedicated belongs to any
      resource reservation session or not. This can be done by either
      multi-field classification [11] using the IP 5-tuple or behavior-aggregate
      classification using the DSCP field. ToS
      field in the header of the IP packet. However, if a packet claims
      that it has an
      associated resource reservation session in the router, then the router

Feher, Cselenyi, Korn          Expires May 2003                 [Page 8] 
      corresponding resource reservation states describing the QoS
      treatment has to find the flow descriptor, which be looked up. This look up procedure might be
      quite time consuming in routers with vast amounts of resource
      reservation sessions.

6.2.2 Best-Effort Traffic

      Best-effort traffic is a traffic type that has no reservation
      entry in the router.


      Traffic flows that do not require QoS guarantees along their path
      are considered to be best-effort traffic. "Best-effort" means that
      the router makes its best effort to forward every data packet, but
      does not guarantee anything. This is the most common type of
      traffic on today's Internet. (There may be scenarios where
      resource reservation is done for BE traffic too, but those are
      outside of the focus of this memo.)

6.3 Router Load Types

   This group of definitions describes different load component types
   that impact only a specific part of the resource reservation capable
   router. Categorizing the router load is crucial, since the
   conventional router load metric expressing the processing power
   utilization of the router does not characterize perfectly precisely enough a
   the resource reservation capable router. In the case of routers
   supporting resource reservations it is also important to know the
   source of the processing power utilization.

6.3.1 Traffic Load

      Usually traffic load is means the load that is raised by forwarding the data
      on forwarding task of the router. However, we define the
      traffic load as the volume of the input data traffic that causes
      the router to be loaded.

      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 In general
      router benchmarking measurements only this type of load is
      considered as the source of the processing power utilization expressed by the
      router load metric. utilization.
      Although the traffic load is the dominant load component,
      benchmarking routers supporting resource reservations must
      consider other load components also in line with the resource
      reservation handling.

   Measurement unit:
      The amount of the traffic load is represented by the volume of the
      data traffic. The volume is measured with by the transferred bits
      during a specified time unit, which second, i.e. the measurement unit is typically bit per seconds

6.3.2 Session Load

      Session load is
      Similar to the traffic load, we define the session load that manifests itself as the excess
      processing power required to keep track
      number of reservation sessions. sessions in the router.

      All signaling based
      Each resource reservation protocol implementation
      employ capable router that employs a packet
      classifier algorithm that distinguishes distinguishing the flows
      having reservations in the router from the others that do not.
      Therefore each implementation referring to
      reservation sessions maintains a list of resource reservation session descriptors that is instrumental in states
      keeping track of the resource reservation dedication. Obviously,
      the more reservation
      sessions session states are set up on the router, the

Feher, Cselenyi, Korn          Expires May 2003                 [Page 9] 
      more complex the traffic classification becomes, and the more longer
      time it takes for the
      classification algorithm to identify look up the corresponding resource reservation
      session descriptor list. sate.

      Moreover, in most protocols, not only the traffic flows, but also
      the signaling messages that manipulate resource reservations reservation
      sessions on the router have to identify themselves first, before
      taking any other actions. This kind of classification also gives
      extra work for to the router.


      In the case of soft-state resource reservation capable routers,
      the session load also involves the duties related to affects reservation session maintenance. The
      maintenance of timers that watchdog the reservation session
      refreshes and the signaling of the reservation
      session refresh signaling messages may cause severe load
      on the router. Based on the initiating point of the refresh
      messages, resource reservation protocols can be divided into two
      groups. First, there are protocols where it is the responsibility
      of the signaling end-
      points end-points to initiate refresh messages, which messages and these
      messages are forwarded
      by the routers along the whole signaling path refreshing
      the corresponding resource reservation session. Second, there are
      other protocols, where the reservation session refresh happens
      only between the two peering network nodes
      from of the signaling path only. path.
      In this latter case, the routers and signaling end-points have
      their own schedule for the refresh message initiation. The first
      approach lightens the load of the session maintenance task;
      however, the second approach bears the ability to adjust the
      signaling message traffic intensity along the signaling path.

   Measurement unit:
      The session load is represented measured by the number of reservation sessions
      in the router.

6.3.3 Signaling Load

      Signaling load is
      Similarly to the previous load that manifests itself as types, the time
      required to process signaling load is
      determined by the incoming signaling messages. message intensity.

      The processing of signaling messages requires processing processor power that
      raises the load on the control plane of the router. In the case
      of routers
      where the control plane and the data plane are not totally
      independent (e.g. certain parts of the tasks are served by the
      same processor; or the architecture has common memory buffers or
      transfer buses) the signaling load can have an impact on the
      router's packet forwarding performance as well.

      Most of the resource reservation protocols have several protocol
      primitives realized by different signaling message types. Each of
      these message types may require a different amount of processing
      power from the router.

Feher, Cselenyi, Korn          Expires May 2003                [Page 10] 
   Measurement unit:
      The signaling load is characterized by the signaling intensity,
      which expresses how many signaling messages arrive to the router
      within a time unit. The typical second. Thus the unit of the signaling intensity is
      [1/s], which is the number of signaling messages that arrive
      within one second.

6.3.4 Signaling Burst

      The signaling burst denotes a certain number of signaling messages
      that arrive to the input port(s) of the router without
      interruption, back-to-back,
      causing persistent load on the signaling message handler.

      Back-to-back signaling messages on one port of the router form a
      typical signaling burst. However, other cases are imaginable, for
      example when signaling messages arrive on different ports
      simultaneously or with an overlap in time (i.e. when the tail of
      one signaling message is behind the head of another one arriving
      on another port).

   Measurement unit:
      The signaling burst is characterized by its length, which is the
      number of messages that have arrived during within the burst.

6.4 Performance Metrics

   This group of definitions is the collection of the measurable impacts
   that a resource reservation protocol has over the tested router
   device it is running on.

6.4.1 Signaling Message Handling Time

      The signaling message handling time (or, in short, signal handling
      time) is the time that a signaling message spends inside the
      router before it is forwarded to the next node on the signaling

      Depending on the type of the signaling message, the router also
      interprets the signaling messages, acts on them and usually
      forwards an
      extended a modified signaling message, which might contain information about
      the result of the message processing. message. Thus the message handling
      time is usually longer than forwarding time of data packets of the
      same size. In addition, there might be also signaling message
      primitives that are drained or generated by the router. Thus, the
      signal handling time is defined as the time difference between the
      time when a signaling message is received and the time the
      corresponding processed signaling message is transmitted. If a
      signaling message is not forwarded on the router, router (see Signaling
      Path), the signal handling time is immeasurable; therefore it is
      not defined for such messages.

Feher, Cselenyi, Korn          Expires May 2003                [Page 11] 
      In the case of signaling messages that carry information
      pertaining to multicast flows, the router might issue multiple
      signaling messages after processing. In this case, by definition,
      the signal handling time is the time interval elapsed between the
      arrival of the incoming signaling message and the departure of the
      last signaling message related to the received one.

      This metric depends on the load on the router, as other tasks may
      limit the processing power available to signaling message
      handling. In addition to the router load, the signal handling time
      may also be dependent on the type of the signaling message. For
      example, it usually takes a shorter time for the router to tear
      down a resource reservation session than to set it up.

      In the case of soft-state protocols, where refresh messages are
      exchanged between peering network nodes only (see Reservation
      Session Maintenance) the incoming refresh messages are drained by
      the router making impossible to measure the signaling message
      handling time on them.


      The signal handling time is an important characteristic as it
      directly affects the setup time of a session.

   Measurement unit:
      The typical unit of the signaling message handling time is
      microsecond. the second.

6.4.2 Premium Traffic Delay

      Premium traffic delay is the forwarding time of a packet that
      belongs to a premium traffic flow data
      packet passing through a resource reservation capable router.

      Premium traffic packets must be classified first in order to find
      assign the network resources dedicated to the flow. The time of
      the classification is added to the usual forwarding time
      (including the queuing) that a router would spend on the packet
      without any resource reservation capability.

      There are routers where the processing power is shared between the
      control plane and the data plane. This means that the processing
      of signaling messages may have an impact on the data forwarding
      performance of the router. In this case the premium traffic delay
      metric reflects the influence the two planes have on each other.

   Measurement unit:
      The typical unit of the premium traffic delay is the microsecond. second.

6.4.3 Best-effort Traffic Delay

      Best-effort traffic delay is the forwarding time of a best-effort
      packet that
      does not belong to any premium traffic flow passing through a resource reservation capable router.

      It looks trivial that
      Marking the premium traffic packets also marks the best-effort
      traffic packets via the lack of marking. In this case the
      detection of the best-effort packets is straightforward, so the
      classification algorithms do not have any influence on the best-effort best-

Feher, Cselenyi, Korn          Expires May 2003                [Page 12] 
      effort traffic. However, the processing power sharing between the
      control and data plane may might still cause delays in the forwarding
      procedure of each packet.

   Measurement unit:
      The typical unit of the best-effort traffic delay is microsecond. the second.

6.4.4 Signaling Message Loss

      Signaling message loss is the ratio of the actual and the expected
      number of signaling messages leaving a resource reservation
      capable router subtracted from one.

      There are certain types of signaling messages, which are messages required to be
      forwarded by the resource reservation capable router immediately
      when their processing is finished. However, due to the high router
      load or for other reasons, the forwarding or even the processing
      of the these signaling
      message messages might be canceled. To characterize
      such situations we introduce the signaling message loss metric, which expresses metric
      expressing the ratio of the signaling messages that actually have
      left the router and those ones that were expected to leave the
      router as a result of the incoming sequence of signaling messages.

      Since the most frequent reason for the signaling message loss is
      the high router load, therefore this metric is suitable for
      sounding out the scalability limits of resource reservation
      capable routers.

      In the case of routers where network packets are queued in several
      places, we have to be aware limits of that a signaling message may be
      delayed seriously. Therefore, resource reservation
      capable routers.

      Sometimes it may be hard or impossible to determine whether the a signaling message
      is still in the queues of the router or whether it was has already
      been dropped. By definition For this reason we say define that a signaling message
      is lost if there is no appearing forwarded signaling message
      within a reasonable long time period. This time period should be
      adjusted to the actual resource reservation protocol (e.g. and might
      also depend on the type of the message, too. For example, in the
      case of soft-state protocols resource reservation capable routers the
      measurer may wait as much as the refresh period to determine detect the loss
      of a signaling message). message.

   Measurement unit:

      Usually, we
      This measure the signaling message loss over a longer
      period of time and then we express has no unit; it as is expressed by a percentage value.
      Besides, in many cases it real number, which
      is enough to know that there was
      signaling loss. between zero and one (including the limits).

6.4.5 Session Refreshing Capacity

      The session refreshing capacity metric is applied for soft-state
      resource reservation capable routers only and tells the ratio of
      the truly refreshed reservation sessions and the number of session
      sessions that have to should be refreshed during one refresh period. This metric is applied for
      soft-state routers only.

Feher, Cselenyi, Korn          Expires May 2003                [Page 13] 
      The session refreshing capacity informs about condition of the
      session maintenance.
      When the a soft-state resource reservation capable router is overloaded
      overloaded, it may happen that the router is not capable able to refresh
      all the allocated registered reservation sessions due having no time to other tasks with higher priorities. run the
      session refresh task. In this case sooner or later the resource
      reservation sessions over the session refresh capacity are dropped
      even if the resource reservation end-points are still refreshing

      The session refreshing capacity sounds out the limit of the
      resource reservation session number that the router is capable to

   Measurement unit:
      The session refreshing capacity
      This measure has no unit; it is expressed as by a percentage
      value. real number, which
      is between zero and one (including the limits).

6.4.6 Scalability Limit

      The scalability limit is the threshold between the steady state
      and the overloaded state of the device under test.

      All existing routers have finite buffer memory and finite
      processing power. In the steady state of the router, the buffer
      memories are not fully utilized and the processing power is enough
      to cope with all tasks running on the router. As the router load
      increases the router has to postpone more and more tasks. These
      tasks (e.g. forwarding certain packets) are queued in the buffers,
      and processed later. However, there is a certain point where no
      more buffer memory is available; available or a task cannot be postponed any
      longer; thus, the router becomes
      overloaded and it is unable to store any more tasks for future
      processing, so it is forced to drop them. Therefore the packet or the
      activity. This way the overloaded state of the resource
      reservation capable router can be recognized by the fact that some
      kind of data (signaling or packet) or task (e.g. refreshing) loss
      occurs. A resource reservation
      capable router may drop signaling messages, data packets or entire
      resource reservation sessions.

      The critical load condition when the router is still in the steady
      state but the smallest amount of constant load increase would
      drive it to the overloaded state is the scalability limit of the

7. Security Considerations

   As this document is solely for providing terminology and describes
   neither a protocol nor an implementation, there are no security
   considerations associated with this document.

Feher, Cselenyi, Korn          Expires May 2003                [Page 14] 

8. Acknowledgement

   We would like to thank the following individuals for their help in
   forming this document: Joakim Bergkvist and Norbert Vegh from Telia
   Research AB, Sweden, Krisztian Nemeth, Balazs Szabo, Gabor Kovacs and
   Peter Vary from the High Speed Networks Laboratory of Laboratory, Budapest
   University of Technology and Economics, Hungary.


9. References

   [1]  Y. Bernet, et. al., "A Framework for Integrated Services
        Operation over Diffserv Networks", RFC 2998, November 2000

   [2]  B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) -
        Version 1 Functional Specification", RFC 2205, September 1997.

   [3]  S. Bradner, "Benchmarking Terminology for Network
        Interconnection Devices", RFC 1242, July 1991

   [4]  R. Mandeville, "Benchmarking Terminology for LAN Switching
        Devices", RFC 2285, February 1998

   [5]  G. Feher, K. Nemeth, M. Maliosz, "Boomerang : A Simple Protocol
        for Resource Reservation in IP Networks," Vancouver, IEEE Real-
        Time Technology and Applications Symposium, June 1999

   [6]  P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism
        for the Internet", Computer Communication Review, on-line
        version, volume 29, number 2, April 1999

   [7]  L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2
        (ST2) Protocol Specification - Version ST2+", RFC 1819, August

   [8]  P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated
        Reservation in the Internet", Journal on High Speed Networks,
        Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998

   [9]  A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight
        Resource Reservation for Unicast IP Traffic", International WS
        on QoS'98, IWQoS'98, May 18-20, 1998

   [10] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
        RFC 2210, September 1997

   [11] K. Nichols et al., " Definition "Definition of the Differentiated Services
        Field (DS Field) in the IPv4 and IPv6 Headers ", Headers", RFC 2474


   [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998

   [13] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
        September 1981

Feher, Cselenyi, Korn          Expires May 2003                [Page 15] 

10. Authors' Addresses: Addresses

   Gabor Feher
   Budapest University of Technology and Economics (BUTE)
   Department of Telecommunications and Telematics
   Pazmany Peter Setany 1/D,
   Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
   Phone: +36 1 463-3110 463-1538

   Istvan Cselenyi
   Telia Research AB
   Vitsandsgatan 9B
   SE 12386, Farsta
   Phone: +46 8 713-8173

   Andras Korn
   Budapest University of Technology and Economics (BUTE)
   Institute of Mathematics, Department of Analysis
   Egry Jozsef u. 2, H-1111 Budapest, Hungary
   Phone: +36 1 463-2475

Feher, Cselenyi, Korn          Expires May 2003                [Page 16]