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

                                                           November 2002
                                            Istvan Cselenyi, TeliaSonera

                                                               June 2003

  Benchmarking Terminology for Routers Supporting Resource Reservation
                 <draft-ietf-bmwg-benchres-term-02.txt>
                 <draft-ietf-bmwg-benchres-term-03.txt>

1. Status of this Memo

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

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft shadow directories can be accessed at
   http://www.ietf.org/shadow.html

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

2. Table of contents

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

Feher, Cselenyi, Korn Nemeth, Korn, Cselenyi  Expires May December 2003            [Page 1] 
         6.2.2 Premium Data Packets...................................8 
         6.2.5 Resource Reservation Protocol Orientation..............7
      6.3 Router Load Types...........................................9 Factors.........................................8
         6.3.1 Best-Effort Traffic Load...........................................9 Load Factor........................8
         6.3.2 Session Load...........................................9 Distinguished Traffic Load Factor......................9
         6.3.3 Signaling Load........................................10 Session Load Factor....................................9
         6.3.4 Signaling Burst.......................................11 Intensity Load Factor.......................10
         6.3.5 Signaling Burst Load Factor...........................10
      6.4 Performance Metrics........................................11
         6.4.1 Signaling Message Handling Time.......................11
         6.4.2 Premium Distinguished Traffic Delay.................................12 Delay...........................12
         6.4.3 Best-effort Traffic Delay.............................12
         6.4.4 Signaling Message Loss................................13
         6.4.5 Session Refreshing Capacity...........................13
         6.4.6 Maintenance Capacity..........................13
      6.5 Scalability Limit.....................................14 Limit..........................................14
   7. Security Considerations........................................14 Considerations........................................15
   8. Acknowledgement................................................15 Acknowledgements...............................................15
   9. References.....................................................15
   10. Authors' Addresses............................................16

3. Abstract

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

4. Introduction

   The IntServ over DiffServ framework [1] outlines a heterogeneous
   Quality of Service (QoS) architecture for multi domain Internet
   services.

   Signaling based resource reservation (e.g. via RSVP [2]) [1]) is an integral
   important part of that model. While this approach significantly
   lightens the load on most of the core routers, the performance of
   border routers that handle different QoS signaling is still crucial. provisioning approaches.
   Therefore network operators, operators who are planning to deploy this model, shall signaling
   based resource reservation may want to scrutinize the scalability
   limitations of reservation capable routers and the impact of
   signaling on the their data forwarding performance of the
   routers. performance.

   An objective way for of quantifying the scalability constraints of QoS
   signaling is to perform measurements on routers that are capable of
   resource reservation. This document defines terminology for a
   specific set of tests that vendors or network operators can use carry out
   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
   products, and thus support the decision process before purchase.
   Moreover, these measurements provide input characteristics for the
   dimensioning of a network in which resources are provisioned
   dynamically by signaling. Finally, the tests are applicable for
   characterizing the impact of the resource reservation signaling on
   the forwarding performance of the routers.

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

   This benchmarking terminology document is based on the knowledge
   gained by examination of (and experimentation with) several very different
   resource reservation protocols: the IETF standard RSVP [2], Boomerang [5], [1] and
   several experimental ones, such as YESSIR [6], [5], ST2+ [7], [6], SDP [7],

Feher, Nemeth, Korn, Cselenyi  Expires December 2003            [Page 2] 
   Boomerang [8] and Ticket [9]. Nevertheless, Some of these protocols are also
   analyzed in an IETF NSIS working group draft [10]. Although the
   authors are only aware of resource reservation capable router
   products that interpret RSVP, this document defines terms that are
   valid in general and not restricted to these any of the above listed
   protocols.

   In order to avoid any confusion we would like to emphasize that this
   terminology considers only signaling protocols that provide IntServ
   resource reservation; the DiffServ world, for example, is out of our
   scope.

5. Existing definitions

   RFC 1242 [3] "Benchmarking Terminology for Network Interconnect
   Devices" [2] and RFC 2285 [4] "Benchmarking Terminology for LAN Switching
   Devices" [3] 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.

   Additionally, throughout this document, an attempt is being made to
   define terminology in a way that is consistent with the terms used by
   Next Steps in Signaling working group laid out in [4].

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

6. Definition of Terms

6.1 Resource Reservation Protocol Basics Traffic Flow Types

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

6.1.1 Unicast Resource Reservation Session

   Definition:
      The term unicast describes traffic flow types forwarded by
   resource reservation session (or shortly
      reservation session) expresses that two end-nodes explicitly
      request the network nodes, which forward their capable routers.

6.1.1 Data Flow

   Definition:
     A data flow, to
      assign special QoS treatment for flow is a stream of data packets belonging from one sender to one or
     more receivers, where each packet has a flow identifier unique to
     the flow.

   Discussion:
     The QoS treatment is defined by specifying the amount of
      networking resources that should be dedicated to the data flow
      during the length of the reservation session. There are different
      approaches, how to specify the network resource requirement of a
      data flow. It can be described by high-level parameters, like the
      required bandwidth or the maximum data delay; or it identifier can be low-
      level information, such as the parameters an arbitrary subset of a leaky-bucket model
      describing the data flow [10].

      Reservation sessions must be packet
     header fields that uniquely registered in network nodes
      assuring the QoS treatments. Practically, the transport address of distinguishes the flow from others.
     The 5-tuple "source address; source port; destination end-node and the transport address;
     destination port; protocol of the
      communication number" is most commonly used for this
     purpose (where port number are sufficient applicable). For more comment on
     flow identification refer to distinguish the reservations, [4].

Feher, Cselenyi, Korn Nemeth, Korn, Cselenyi  Expires May December 2003            [Page 3] 
      however in extreme cases 
     The flow identification can be time- and/or resource-consuming,
     but this can sometimes be avoided as routers do not necessarily
     have to classify every packet. Instead, packets that should be
     classified by routers can be marked with special flags that
     routers understand. One existing marking approach is to use the transport address
     ToS field of the source
      should IP header. Naturally, unmarked packets are not
     classified by routers and this way valuable resources can be included as well.

   See Also:
      Reservation Session State
     saved.

6.1.2 Multicast Resource Reservation Session Distinguished Data Flow

   Definition:
      A multicast
     Distinguished data flows are flows that resource reservation session (or, in short, multicast
      reservation session) denotes that end-nodes forming a multicast
      group ask the network nodes, which forward the
     capable routers intentionally treat better or worse than
     "ordinary" data packets of the
      multicast group, to assign a certain QoS treatment flows, according to their data
      traffic.

   Discussion:
      In a multicast group there can be several data traffic sources and
      destinations. The required QoS treatment is specified the same way
      as in the case of the unicast resource reservation sessions. In
      the case of multicast reservations, however, unlike in the case of
      unicast reservations, agreement defined for
     the amount distinguished flow.

   Discussion:
     Packets of reserved network resources
      does not have to be the same on each network node forwarding the
      multicast distinguished 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 flows are two types of multicast resource reservations:
      many-to-many marked so that the routers
     that forward them know they require differentiated treatment.
     Routers classify these incoming packets and one-to-many. Those of identify the first type allow
      multicast data traffic to be originated from several sources,
      while those flow
     they belong to.

     The most common usage of the second type permit only one fix distinguished data traffic
      source in the whole multicast group flow is to get
     higher priority treatment than that must not change during
      the lifetime of best-effort data flows (see
     the session.

6.1.3 Resource Reservation Capable Router

   Definition:
      A router next definition) flows. In these cases, a distinguished data
     flow is resource reservation capable -- supports resource
      reservation -- if it understands sometimes referred to as a resource reservation protocol "premium data flow".
     Theoretically, it is possible to require worse treatment than that signals the set-up, tear-down and modification
     of resource
      reservation sessions.

   Discussion:
      Resource reservation protocols define signaling messages best-effort flows, however this is practically never done in
     IntServ networks.

6.1.3 Best-Effort Data Flow

   Definition:
     Best-effort data flows are flows that are
      interpreted not treated in any
     special manner by resource reservation capable routers. The routers; thus,
     their packets are served (forwarded) in some default way.

   Discussion:
     "Best-effort" means that the router
      captures makes its best effort to
     forward the signaling message data packet quickly and manipulates the resource
      reservation sessions and/or safely, but does not guarantee
     anything (e.g. delay or loss probability). This type of traffic is
     the reserved network resources
      according to most common in today's Internet.

     In the content case of best-effort data flow the message.

   Issues:
      Despite that resource reservation sessions packets are considered to be
      unique, resource reservation capable routers might aggregate them not specially
     marked and allocate network resources to these aggregated sessions at
      once. The aggregation can be based on similar flow attributes thus they are not classified by the routers.

Feher, Cselenyi, Korn Nemeth, Korn, Cselenyi  Expires May December 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 processing task 

6.2 Resource Reservation Protocol Basics

   This group of a definitions applies to signaling based resource
   reservation capable router, it also requires the administration protocols implemented by IP router devices.

6.2.1 QoS Session

   Definition:
     A QoS session is an application layer concept, shared between a
     set of network nodes, that pertains to a specific set of data
     flows. The information associated with the aggregated flows and might also lead session includes the
     data required to identify the violation set of the
      quality guaranties data flows in addition to a
     specification of individual reservations within an
      aggregation.

6.1.4 Signaling End-point

   Definition: the QoS treatment they require.

   Discussion:
     A signaling end-point QoS session is an end-to-end relationship. Whenever end-nodes
     decide to obtain special QoS treatment for their data
     communication, they set up a network node capable QoS session; as part of initiating the process,
     they or their proxies make a QoS agreement with the network,
     specifying their data flows and
      terminating resource reservation sessions.

   Discussion:
      Besides traditional end-systems, there the QoS treatment that the flows
     require.

     It is also another type of
      signaling end-point: possible for the reservation gateways. Reservation
      gateways translate same QoS session to span multiple network
     domains that have different resource provisioning architectures.
     In this document, however, we only deal with the case where the
     QoS session is realized over an IntServ architecture. It is
     assumed that sessions will be established using signaling messages
     of one resource
      reservation protocol into messages of another a resource reservation protocol. Thus the reservation gateway represents two signaling
      end-points in one, as it is both a signaling terminator and a
      signaling initiator.

   Issues:
      Typically, signaling end-points

     QoS sessions must have a dedicated protocol stack, unique identifiers; it must be possible to
     determine which interprets and generates the QoS session a given signaling messages. However, in
      some special cases, the resource reservation initiation is carried
      out without message pertains to.
     Therefore, each signaling message should include the notice identifier of the signaling terminating node. For
     its corresponding session. As an example, in the Boomerang resource reservation protocol encapsulates case of RSVP, the reservation requests in an ICMP Echo message. This message is
      bounced back from
     "session specification" identifies the signaling terminating network node ("Far-End
      Node") and as a result QoS session plus refers to
     the node becomes a signaling end-point
      without understanding data flow; the reservation protocol.

6.1.5 Reservation Orientation

   Definition:
      The reservation orientation tells which signaling end-point(s)
      initiates "flowspec" specifies the network resources allocation to obtain special desired QoS treatment for
     and the data traffic "filter spec" defines the subset of data packets in the reservation session.

   Discussion:
      Resource reservation protocols
     data flow that receive the QoS defined by the flowspec.

     QoS sessions can be classified into two groups unicast or multicast depending on the relationship between the reservation initiators
      and their role in the data traffic flow. First, there are sender-
      oriented protocols, where the source(s) number
     of the reservation
      sessionĂs participants. In a multicast group there can be several data
     traffic initiates sources and destinations. Here the network resource allocation
      message. Second, in QoS agreement does not
     have to be the case same for each branch of the receiver-oriented protocols,
      the receiver(s) of multicast tree
     forwarding the reservation sessionĂs data traffic
      initiates the resource allocation messages. Due to the asymmetric
      routing nature flow of the Internet, group. Instead, a dedicated
     network resource in a router can be shared among many traffic
     sources from the latter case, the
      receiver(s) should know same multicast group (e.g. multicast reservation
     styles in the route(s) case of the desired data traffic
      before it would be able RSVP).

   Issues:
     Even though QoS sessions are considered to send the be unique, resource allocation
     reservation capable routers might aggregate them and allocate
     network resources to these aggregated sessions at once. The
     aggregation can be based on similar data flow attributes (e.g.

Feher, Cselenyi, Korn Nemeth, Korn, Cselenyi  Expires May December 2003            [Page 5] 
      message(s). For this reason, even in the second case, 
     similar destination addresses) or it can combine arbitrary
     sessions as well. While reservation aggregation significantly
     lightens the first signaling message(s) establishing the processing task of a resource reservation session comes
      from
     capable router, it also requires the source(s) administration of the data traffic marking the route(s) on
      which the resource allocation message(s)
     aggregated QoS sessions and might travel backward.

   Issues:
      The orientation of the reservation initiator affects also lead to the basics violation of
     the resource quality guaranties referring to individual data flows within
     an aggregation [12].

6.2.2 Resource Reservation Protocol

   Definition:
     Resource reservation protocols define signaling messages and therefore it
     message processing rules used to control resource allocation in
     IntServ architectures.

   Discussion:
     It is an
      important design decision. In the case signaling messages of multicast a resource reservation
      sessions, the sender-oriented protocols require protocol
     that carry the traffic
      sources information related to maintain QoS sessions. This
     information includes a list of receivers and send their allocation
      messages considering session identifier, the requirements actual QoS
     parameters, and possibly flow descriptors.

     The message processing rules of the receivers. A less
      polite, but less demanding solution is when signaling protocols ensure
     that signaling messages reach all network nodes concerned. Some
     resource reservation protocols (e.g. RSVP) are only concerned with
     this, i.e. carrying the sources ignore QoS-related information to all the
      QoS requirements
     appropriate network nodes, without being aware of its content.
     This approach allows changing the receivers and send the allocation requests
      at will. Using multicast reservation sessions, way the receiver-
      oriented protocols give QoS parameters are
     described and provisioning is done without the chance need to change the receivers
     protocol itself.

6.2.3 Resource Reservation Capable Router

   Definition:
     A router is resource reservation capable (it supports resource
     reservation) if it is able to place their
      own interpret signaling messages of a
     resource allocation requests reservation protocol and thus ease based on these messages is able
     to adjust the task management of its flow classifiers and network
     resources so as to conform with the
      sources. However, in this case the resource allocations must be
      preceded by the marking content of the data routes messages

   Discussion:
     Routers capture signaling messages and manipulates reservation
     states and/or reserved network resources according to the content
     of the reservation
      session (c.f. RSVP PATH message [2]). In case of large multicast
      groups, enabling messages. This ensures that the receivers to specify flows are treated as their
     specified QoS requirements,
      the receiver-oriented approach seems to be a better choice,
      however in other cases the sender-oriented protocols promise less
      complexity.

6.1.6 requirements indicate.

6.2.4 Reservation Session State

   Definition:
     A reservation session state is a holder for all the set of entries in the routerĂs memory
     that contain all relevant information about the corresponding reservation a given QoS session
     registered
      in with the resource reservation capable router.

Feher, Nemeth, Korn, Cselenyi  Expires December 2003            [Page 6] 
   Discussion:
      Resource
     States are needed because IntServ related resource reservation capable
     protocols require the routers maintain reservation session
      states to store information about the keep track of QoS session and
     data-flow-related metadata. The reservation session. This
      information might include state includes the QoS treatment that
     parameters of the reservation
      session requires; QoS treatment; the description of how and where
     to forward the incoming signaling messages; policies regarding the QoS treatment
      or the reservation session; refresh timing information about the
      reservation session;
     information; etc.

     Based on how reservation session states are stored in a reservation
     capable router, the routers can be categorized into
      three two classes:

     Hard-state resource reservation capable routers protocols (e.g. ST2 capable [6]) require
     routers [7]) to store the reservation session states permanently, established
     by a set-up signaling primitive, until a corresponding
      tear-down signaling primitive arrives or until the router is explicitly
     informed that the reservation QoS session is canceled.

     There are also soft-state resource reservation capable routers,
     where there are no permanent reservation session states, but and each

Feher, Cselenyi, Korn          Expires May 2003                 [Page 6] state have
     has to be regularly refreshed by appropriate refresh signaling
     messages. If no refresh signaling message arrives during a certain
     period then the router cancels stops the reservation maintenance of the QoS session
     assuming that the signaling end-points do not intend to keep up the reservation session up
     any longer or the communication lines are broken somewhere along
     the data path. This feature makes soft-
      state resource reservation capable routers more robust than hard-
      state routers, since no failures can cause permanent resource
      stuck in the routers.

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

   Issues:
      Although soft-state reservation capable routers are more robust
      than hard-state ones, the frequent processing of refresh signaling
      messages or the detection of the missing This feature makes soft-state resource reservation session state
      refreshes might
     capable routers more robust than hard-state routers, since no
     failures can cause serious increase permanent resources to stay permanently stuck
     in the router load, which
      can be a base of the scalability problems. In order to decrease routers.

   Issues:
     Based on the number initiating point of the refresh signaling messages, the soft-state
     resource reservation
      capable router might support various mechanisms to pack several
      refresh signaling messages protocols can be divided into one larger message.

6.1.7 Signaling Path

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

   Discussion:
      Resource reservation capable routers must assure that all other
      router, which two groups.
     First, there are protocols where it is responsible for handling the actual signaling
      message, really receives that message. Therefore, routers forward responsibility of the signaling
     end-points or their proxies to initiate refresh messages. These
     messages are forwarded along the signaling path and of the data flow refreshing
     the corresponding reservation states in each router, router affected by
     the message, processes it.

      Usually signaling messages flow. Secondly, there are immediately forwarded by resource
      reservation capable other protocols, where routers towards and
     end-points have their own schedule for the destination(s), spreading reservation state
     refreshes and they signal these refreshes to the information as fast as possible. However, there might be neighboring
     routers.

6.2.5 Resource Reservation Protocol Orientation

   Definition:
     The orientation of a resource reservation protocol messages that do not affect all tells which end
     of the routers along protocol communication initiates the
      signaling path, but only a subset allocation of it (e.g. refresh messages in
      RSVP). These kinds the
     network resources. Thus, the protocol can be sender or receiver
     initiated, depending on the location of signaling messages are terminated by routers
      when they are not necessary anymore.

   Issues:
      Resource the data flow source
     (sender) and destination (receiver) compared to the reservation capable routers must be prepared that there
      are other routers along
     initiator.

   Discussion:
     In the signaling path unable to interpret case of sender-initiated protocols the
      actual resource reservation protocol. Even in this case
     propagates the same directions as of the data flow. Consequently,

Feher, Cselenyi, Korn Nemeth, Korn, Cselenyi  Expires May December 2003            [Page 7] 
     in the case of receiver-initiated protocols the signaling messages must be delivered to all corresponding resource
      reservation capable routers (usually using some kind of
      tunneling).

6.2 Traffic Types

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

6.2.1 Best-Effort Data Packets

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

   Discussion:
      Data packets that do not require QoS guarantees along their path
      are considered to be best-effort packets. "Best-effort" means that of the router makes its best effort data
     flow. Due to forward the data packet
      quickly and safely, but does not guarantee anything (e.g. delay or
      loss probability). This type asymmetric routing nature of traffic is the most common type Internet, 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 latter case, the
      traffic path of the best-effort data packets shortly as best-effort
      traffic.

6.2.2 Premium Data Packets

   Definition:
      Premium desired data packets are the packets that flow should be
     known before the resource reservation
      capable router distinguishes from best-effort packets and forwards
      them according to a QoS agreement.

   Discussion:
      Data packets that correspond initiator would be able to a send the
     resource reservation session allocation messages. For example in the router are premium case of RSVP, the
     RSVP PATH message [1], traveling from the data flow sources
     towards the destinations, first marks the path of the data flow on
     which the resource allocation messages will travel backward.

     This definition considers only protocols that reserve resources
     for just one data packets. flow between the end-nodes. The QoS treatment reservation
     orientation of protocols reserving more than one data flow is not
     defined
      in here.

   Issues:
     The location of the reservation initiator affects the basics of
     the associated resource reservation state (e.g. flow
      descriptor) that protocols and therefore it is established by signaling messages during an
     important design decision. In the
      reservation session setup.

      The router may distinguish several types case of premium. Data packets
      belonging multicast QoS sessions,
     the sender-oriented protocols require the traffic sources to different types
     maintain a list of premium traffic may receive receivers and send their allocation messages
     considering the different requirements of the receivers. Using
     multicast QoS treatment. We will refer to sessions, the traffic of receiver-oriented protocols give the
      premium data packets shortly as premium traffic.

   Issues:
      The router has
     chance to identify every packet whether it belongs the receivers to any place their own resource reservation session or not. This can be done by either
      multi-field classification [11] using allocation
     requests and thus ease the IP 5-tuple or task of the ToS
      field in sources.

6.3 Router Load Factors

   The router load expressing the header of utilization the IP packet. However, if a packet has an
      associated resource reservation session in device naturally
   affects the router, then performance of the

Feher, Cselenyi, Korn          Expires May 2003                 [Page 8] 
      corresponding resource reservation states describing router. During the QoS
      treatment has benchmarking
   process several load conditions have to be looked up. This look up procedure might be
      quite time consuming in routers with vast amounts of resource
      reservation sessions.

6.3 Router Load Types examined.

   This group of definitions describes different load component types
   that impact only a specific part of the resource reservation capable
   router. Categorizing the router load is crucial, since the
   conventional router load metric expressing the processing power
   utilization of the router does not characterize precisely enough components that
   impact only a specific part of 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 Best-Effort Traffic Load Factor

   Definition:
      Usually
     The best-effort traffic load means the load that factor is raised by the data
      traffic forwarding task of the router. However, we define the
      traffic load defined as the volume of
     the input best-effort data traffic that causes traverses the router to be loaded. in a
     second.

   Discussion:
      It is obvious that forwarding
     Forwarding the best-effort data packets, which requires obtaining
     the routing information and transferring the data packet between
     network interfaces, requires processing power. In general
      router benchmarking measurements only power, which is expressed
     by this type of load is
      considered as the source factor.

   Issues:
     The same amount of data segmented into differently sized packets
     causes different amounts of the processing power utilization.
      Although the traffic load is on the dominant load component,
      benchmarking routers supporting resource reservations must
      consider other load components also in line with router, which has to be
     considered during the resource
      reservation handling. benchmarking measurements.

Feher, Nemeth, Korn, Cselenyi  Expires December 2003            [Page 8] 
   Measurement unit:
     bits per second (bps)

6.3.2 Distinguished Traffic Load Factor

   Definition:
     The amount of the distinguished traffic load factor is represented by defined as the volume of
     the distinguished data traffic. The volume is measured by traffic that traverses the transferred bits
      during router in a second, i.e.
     second.

   Discussion:
     Similarly to the measurement unit is bit best-effort data, forwarding the distinguished
     data packets requires obtaining the routing information and
     transferring the data packet between network interfaces. However,
     in this case packets have to be classified as well, which requires
     additional processing capacity.

   Issues:
     Just as in the best-effort case, the same amount of data segmented
     into differently sized packets causes different amounts of load on
     the router, which has to be considered during the benchmarking
     measurements.

   Measurement unit:
     bits per seconds
      (bps).

6.3.2 second (bps)

6.3.3 Session Load Factor

   Definition:
      Similar to the traffic load, we define the
     The session load as factor is the number of reservation QoS sessions in the router.

   Discussion:
      Each resource reservation capable router that employs a packet
      classifier algorithm distinguishing the flows referring to
     is keeping track of.

   Discussion:
     Resource reservation sessions maintains resource capable routers maintain reservation session states
     keeping track of the resource reservation dedication. QoS sessions. Obviously, the more reservation session
     states are set up on registered with the router, the

Feher, Cselenyi, Korn          Expires May 2003                 [Page 9] more complex the
     traffic classification becomes, and the longer time it takes to
     look up the corresponding resource reservation
      session sate. Moreover, in most protocols, not
     only the traffic flows, but also the signaling messages that manipulate resource reservation
      sessions on
     control the router reservation states have to identify themselves be identified first, before
     taking any other actions. action. This kind of classification also gives means
     extra work to for the router.

   Issues:

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

   Measurement unit:
      The session load
     This factor is measured by the number of reservation QoS sessions
      in impacting
     the router.

6.3.3 router, thus it has no unit.

Feher, Nemeth, Korn, Cselenyi  Expires December 2003            [Page 9] 

6.3.4 Signaling Intensity Load Factor

   Definition:
      Similarly to the previous load types, the
     The signaling intensity load factor is
      determined by defined as the incoming number of
     signaling message intensity. messages that hit the router during one second.

   Discussion:
     The processing of signaling messages requires processor power that
     raises the load on the control plane of the router.

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

     Naturally, just as everywhere else in this document, the term
     "signaling messages" refer only to the resource reservation
     protocol related primitives.

   Issues:
     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 from the signaling intensity,
      which expresses how many signaling messages arrive router. This fact has to be considered during the router
      within a second. Thus the
     benchmarking measurements.

   Measurement unit:
     The unit of the signaling intensity this factor is
      [1/s].

6.3.4 1/second.

6.3.5 Signaling Burst Load Factor

   Definition:
     The signaling burst denotes a certain load factor is defined as the number of
     signaling messages that arrive to the one input port(s) port of the router back-to-back,
     back-to-back [2], causing persistent load on the signaling message
     handler.

   Discussion:
      Back-to-back signaling messages
     The definition focuses on one input port only. A set of messages
     arriving at different ports, but with such a timing that would be
     a burst if the router form messages arrived at the same port, is not
     considered to be a
      typical signaling burst. However, other cases are imaginable, The reason for
      example when signaling messages arrive this is that it is not
     guaranteed at a black-box test that this would have the same
     effect on different ports
      simultaneously or with an overlap in time (i.e. when the tail router as a burst (incoming at the same interface)
     has.

     This definition conforms to the burst definition given in [3].

   Issues:
     Most of
      one the resource reservation protocols have several protocol
     primitives realized by different signaling message is behind the head types. Bursts
     built up of another one arriving different messages may have a different effect on another port). the

Feher, Nemeth, Korn, Cselenyi  Expires December 2003           [Page 10] 
     router. Consequently, during measurements the content of the burst
     has to be considered as well.

   Measurement unit:
      The signaling burst
     This load factor is characterized measured by its length, which is the number of messages that have arrived within in the burst.
     burst, thus it has no unit.

6.4 Performance Metrics

   This group of definitions is the a collection of the measurable impacts quantities
   that a resource reservation protocol has over describe the tested router
   device it is running on. impact the different load components have on the
   router.

6.4.1 Signaling Message Handling Time

   Definition:
     The signaling message handling time (or, in short, signal handling
     time) is the time that latency [2] of a signaling message spends inside the
      router before it is forwarded to the next node on passing through
     the signaling
      path. router.

   Discussion:
      Depending on the type of the signaling message, the
     The router also interprets the signaling messages, acts based on them their
     content and usually forwards a them in an unmodified or modified signaling message.
     form. Thus the message handling time is usually longer than the
     forwarding time of data packets of the same size. In addition, there size.

     There might be also signaling message
      primitives primitives, however, that are
     drained or generated by the router. Thus, the
      signal handling time is defined as the time difference between the
      time when a signaling message is received and the time the
      corresponding processed signaling message is transmitted. If a
      signaling message is not forwarded on the router (see Signaling
      Path), router, like certain refresh messages.
     In this case the signal handling time is immeasurable; 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. processing them. In this case, by
     definition, the signal handling time is the time interval elapsed latency 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

     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 remove a resource reservation session state than to set it up.
     This fact has to be considered during the benchmarking process.

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

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

Feher, Nemeth, Korn, Cselenyi  Expires December 2003           [Page 11] 

6.4.2 Premium Distinguished Traffic Delay

   Definition:
      Premium
     Distinguished traffic delay is the forwarding time latency [2] of a premium distinguished
     data packet passing through a resource reservation capable router. the tested router device.

   Discussion:
      Premium
     Distinguished traffic packets must be classified first in order to
     assign the network resources dedicated to the flow. The time of
     the classification is added to the usual forwarding time
     (including the queuing) that a router would spend on the packet
     without any resource reservation capability. This classification
     procedure might be quite time consuming in routers with vast
     amounts of reservation states.

     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 distinguished traffic
     delay metric reflects is an indicator of the influence the two planes have
     on each other.

   Issues:
     Queuing of the incoming data packets in routers might bias this
     metric, measurement procedures have to consider this effect.

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

6.4.3 Best-effort Traffic Delay

   Definition:
     Best-effort traffic delay is the forwarding time latency of a best-effort data
     packet passing through a resource reservation capable router. traversing the tested router device.

   Discussion:
      Marking
     If the premium traffic packets also marks processing power of the best-effort
      traffic packets via router is shared between the
     control and data plane, then the processing of signaling messages
     may have an impact on the lack data forwarding performance of marking. the
     router. In this case the
      detection of the best-effort packets traffic delay metric is straightforward, so an
     indicator of the
      classification algorithms do not have any influence on the best-

Feher, Cselenyi, Korn          Expires May 2003                [Page 12] 
      effort traffic. However, the processing power sharing between two planes have on each other.

   Issues:
     Queuing of the
      control and incoming data plane might still cause delays packets in the forwarding
      procedure of each packet. routers might bias this
     metric as well, so measurement procedures have to consider this
     effect.

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

Feher, Nemeth, Korn, Cselenyi  Expires December 2003           [Page 12] 

6.4.4 Signaling Message Loss

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

   Discussion:
     This definition gives the same value as the ratio of the lost and
     the expected messages. The reason for choosing the given
     definition is that the number of lost messages cannot be measured
     directly.

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

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

   Issues:
      Sometimes it may

     During the measurements one must be hard able to determine whether a
     signaling message is still in the queues of the router or whether if it
     has already been dropped. For this reason we define that a signaling
     message
      is as lost if there is no appearing forwarded signaling message is emitted
     within a reasonable reasonably long time period. This time period should be
      adjusted to the actual resource reservation protocol and might
      also depend on the type of the message, too. For example, in the
      case of soft-state resource reservation capable routers the
      measurer may wait as much as the refresh period to detect is defined along
     with the loss
      of a signaling message. benchmarking methodology.

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

6.4.5 Session Refreshing Maintenance Capacity

   Definition:
     The session refreshing maintenance capacity metric is applied for used in the case of
     soft-state resource reservation capable routers only and tells protocols only. It gives the ratio
     of the truly refreshed reservation number of QoS sessions actually maintained and the number
     of QoS sessions that should be refreshed have been maintained during one
     refresh period.

   Discussion:
     For soft-state protocols maintaining a QoS session means
     refreshing the reservation states associated with it.

Feher, Cselenyi, Korn Nemeth, Korn, Cselenyi  Expires May December 2003           [Page 13] 
   Discussion: 
     When a soft-state resource reservation capable router is
     overloaded, it may happen that the router is not able to refresh
     all the registered reservation sessions having no states, because it does not have
     the time to run the
      session state refresh task. In this case sooner or
     later the resource
      reservation some QoS sessions over the session refresh capacity are dropped will be lost even if the resource reservation end-points are endpoints still refreshing
      them.
     require their maintenance.

     The session refreshing maintenance capacity sounds out the limit maximal number of
     QoS sessions that the router is capable of maintaining.

   Issues:
     In the case of soft-state resource reservation session number protocols a router
     that fails to maintain a QoS session will not generate refresh
     signaling messages either. This has direct consequences on the router is capable to
      maintain.
     signaling message loss metric.

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

6.4.6

6.5 Scalability Limit

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

   Discussion:
     All existing routers have finite buffer memory and finite
     processing power. In the steady state of the router, the buffer
     memories are not fully utilized and the processing power is enough
     to cope with all tasks running on the router. As the router load
     increases the buffers are starting to fill up and/or 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, thus the router is forced to drop the a
     packet or the an 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) QoS
     session maintenance) loss occurs.

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

Feher, Nemeth, Korn, Cselenyi  Expires December 2003           [Page 14] 

7. Security Considerations

   As this document is solely for providing only provides 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] it.

8. Acknowledgement Acknowledgements

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

9. References

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

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

   [3]

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

   [4]

   [3]  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

   [4]  R. Hancock (ed.), et. al., "Next Steps in IP Networks," Vancouver, IEEE Real-
        Time Technology and Applications Symposium, June 1999

   [6] Signaling: Framework",
        IETF draft: draft-ietf-nsis-fw-02.txt (work in progress), 2003

   [5]  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]

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

   [8]

   [7]  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

   [8]  J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I.
        Cselënyi, M. Maliosz, "Boomerang : A Simple Protocol for
        Resource Reservation in IP Networks", Vancouver, IEEE Real-Time
        Technology and Applications Symposium, June 1999

   [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

Feher, Nemeth, Korn, Cselenyi  Expires December 2003           [Page 15] 
   [10] J. Manner (ed.), X. Fu (ed.), "Analysis of Existing Quality of
        Service Signaling Protocols", IETF draft: draft-ietf-nsis-
        signalling-analysis-01.txt (work in progress), 2003

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

   [11] K. Nichols et al., "Definition

   [12] F. Baker,C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation
        of the Differentiated Services
        Field (DS Field) in the RSVP for IPv4 and IPv6 Headers", RFC 2474

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

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

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

10.
        2001

   Authors' Addresses

   Gabor Feher
   Budapest University of Technology and Economics (BUTE)
   Department of Telecommunications and Telematics Mediainformatics
   Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
   Phone: +36 1 463-1538
   Email: feher@ttt-atm.ttt.bme.hu

   Istvan Cselenyi
   Telia Research AB
   Vitsandsgatan 9B
   SE 12386, Farsta
   SWEDEN, Gabor.Feher@tmit.bme.hu

   Krisztian Nemeth
   Budapest University of Technology and Economics
   Department of Telecommunications and Mediainformatics
   Magyar Tudosok krt. 2, H-1117, Budapest, Hungary
   Phone: +46 8 713-8173 +36 1 463-1565
   Email: istvan.i.cselenyi@telia.se Krisztian.Nemeth@tmit.bme.hu

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

   Istvan Cselenyi
   TeliaSonera International Carrier
   Vaci ut 22-24, H-1132 Budapest, Hungary
   Phone: +36 1 412-2705
   Email: Istvan.Cselenyi@teliasonera.com

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