idnits 2.17.1 draft-ietf-bmwg-benchres-term-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7620 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '11' is defined on line 772, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '3') == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-fw (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' == Outdated reference: A later version (-05) exists of draft-ietf-nsis-signalling-analysis-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-signalling-analysis (ref. '10') Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Working Group Gabor Feher, BUTE 3 INTERNET-DRAFT Krisztian Nemeth, BUTE 4 Expiration Date: December 2003 Andras Korn, BUTE 5 Istvan Cselenyi, TeliaSonera 7 June 2003 9 Benchmarking Terminology for Routers Supporting Resource Reservation 10 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft shadow directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This memo provides information for the Internet community. This memo 34 does not specify an Internet standard of any kind. Distribution of 35 this memo is unlimited. 37 2. Table of contents 39 1. Status of this Memo.............................................1 40 2. Table of contents...............................................1 41 3. Abstract........................................................2 42 4. Introduction....................................................2 43 5. Existing definitions............................................3 44 6. Definition of Terms.............................................3 45 6.1 Traffic Flow Types..........................................3 46 6.1.1 Data Flow..............................................3 47 6.1.2 Distinguished Data Flow................................4 48 6.1.3 Best-Effort Data Flow..................................4 49 6.2 Resource Reservation Protocol Basics........................5 50 6.2.1 QoS Session............................................5 51 6.2.2 Resource Reservation Protocol..........................6 52 6.2.3 Resource Reservation Capable Router....................6 53 6.2.4 Reservation State......................................6 54 6.2.5 Resource Reservation Protocol Orientation..............7 55 6.3 Router Load Factors.........................................8 56 6.3.1 Best-Effort Traffic Load Factor........................8 57 6.3.2 Distinguished Traffic Load Factor......................9 58 6.3.3 Session Load Factor....................................9 59 6.3.4 Signaling Intensity Load Factor.......................10 60 6.3.5 Signaling Burst Load Factor...........................10 61 6.4 Performance Metrics........................................11 62 6.4.1 Signaling Message Handling Time.......................11 63 6.4.2 Distinguished Traffic Delay...........................12 64 6.4.3 Best-effort Traffic Delay.............................12 65 6.4.4 Signaling Message Loss................................13 66 6.4.5 Session Maintenance Capacity..........................13 67 6.5 Scalability Limit..........................................14 68 7. Security Considerations........................................15 69 8. Acknowledgements...............................................15 70 9. References.....................................................15 72 3. Abstract 74 The purpose of this document is to define terminology specific to the 75 benchmarking of the resource reservation signaling of IP routers. 76 These terms can be used in additional documents that define 77 benchmarking methodologies for routers that support resource 78 reservation or reporting formats for the benchmarking measurements. 80 4. Introduction 82 Signaling based resource reservation (e.g. via RSVP [1]) is an 83 important part of the different QoS provisioning approaches. 84 Therefore network operators who are planning to deploy signaling 85 based resource reservation may want to scrutinize the scalability 86 limitations of reservation capable routers and the impact of 87 signaling on their data forwarding performance. 89 An objective way of quantifying the scalability constraints of QoS 90 signaling is to perform measurements on routers that are capable of 91 resource reservation. This document defines terminology for a 92 specific set of tests that vendors or network operators can carry out 93 to measure and report the signaling performance characteristics of 94 router devices that support resource reservation protocols. The 95 results of these tests provide comparable data for different 96 products, and thus support the decision process before purchase. 97 Moreover, these measurements provide input characteristics for the 98 dimensioning of a network in which resources are provisioned 99 dynamically by signaling. Finally, the tests are applicable for 100 characterizing the impact of the resource reservation signaling on 101 the forwarding performance of the routers. 103 This benchmarking terminology document is based on the knowledge 104 gained by examination of (and experimentation with) different 105 resource reservation protocols: the IETF standard RSVP [1] and 106 several experimental ones, such as YESSIR [5], ST2+ [6], SDP [7], 107 Boomerang [8] and Ticket [9]. Some of these protocols are also 108 analyzed in an IETF NSIS working group draft [10]. Although the 109 authors are only aware of resource reservation capable router 110 products that interpret RSVP, this document defines terms that are 111 valid in general and not restricted to any of the above listed 112 protocols. 114 In order to avoid any confusion we would like to emphasize that this 115 terminology considers only signaling protocols that provide IntServ 116 resource reservation; the DiffServ world, for example, is out of our 117 scope. 119 5. Existing definitions 121 RFC 1242 "Benchmarking Terminology for Network Interconnect 122 Devices" [2] and RFC 2285 "Benchmarking Terminology for LAN Switching 123 Devices" [3] contains discussions and definitions for a number of 124 terms relevant to the benchmarking of signaling performance of 125 reservation capable routers and should be consulted before attempting 126 to make use of this document. 128 Additionally, throughout this document, an attempt is being made to 129 define terminology in a way that is consistent with the terms used by 130 Next Steps in Signaling working group laid out in [4]. 132 For the sake of clarity and continuity this document adopts the 133 template for definitions set out in Section 2 of RFC 1242. 134 Definitions are indexed and grouped together into different sections 135 for ease of reference. 137 6. Definition of Terms 139 6.1 Traffic Flow Types 141 This group of definitions describes traffic flow types forwarded by 142 resource reservation capable routers. 144 6.1.1 Data Flow 146 Definition: 147 A data flow is a stream of data packets from one sender to one or 148 more receivers, where each packet has a flow identifier unique to 149 the flow. 151 Discussion: 152 The flow identifier can be an arbitrary subset of the packet 153 header fields that uniquely distinguishes the flow from others. 154 The 5-tuple "source address; source port; destination address; 155 destination port; protocol number" is most commonly used for this 156 purpose (where port number are applicable). For more comment on 157 flow identification refer to [4]. 159 The flow identification can be time- and/or resource-consuming, 160 but this can sometimes be avoided as routers do not necessarily 161 have to classify every packet. Instead, packets that should be 162 classified by routers can be marked with special flags that 163 routers understand. One existing marking approach is to use the 164 ToS field of the IP header. Naturally, unmarked packets are not 165 classified by routers and this way valuable resources can be 166 saved. 168 6.1.2 Distinguished Data Flow 170 Definition: 171 Distinguished data flows are flows that resource reservation 172 capable routers intentionally treat better or worse than 173 "ordinary" data flows, according to a QoS agreement defined for 174 the distinguished flow. 176 Discussion: 177 Packets of distinguished data flows are marked so that the routers 178 that forward them know they require differentiated treatment. 179 Routers classify these incoming packets and identify the data flow 180 they belong to. 182 The most common usage of the distinguished data flow is to get 183 higher priority treatment than that of best-effort data flows (see 184 the next definition) flows. In these cases, a distinguished data 185 flow is sometimes referred to as a "premium data flow". 186 Theoretically, it is possible to require worse treatment than that 187 of best-effort flows, however this is practically never done in 188 IntServ networks. 190 6.1.3 Best-Effort Data Flow 192 Definition: 193 Best-effort data flows are flows that are not treated in any 194 special manner by resource reservation capable routers; thus, 195 their packets are served (forwarded) in some default way. 197 Discussion: 198 "Best-effort" means that the router makes its best effort to 199 forward the data packet quickly and safely, but does not guarantee 200 anything (e.g. delay or loss probability). This type of traffic is 201 the most common in today's Internet. 203 In the case of best-effort data flow the packets are not specially 204 marked and thus they are not classified by the routers. 206 6.2 Resource Reservation Protocol Basics 208 This group of definitions applies to signaling based resource 209 reservation protocols implemented by IP router devices. 211 6.2.1 QoS Session 213 Definition: 214 A QoS session is an application layer concept, shared between a 215 set of network nodes, that pertains to a specific set of data 216 flows. The information associated with the session includes the 217 data required to identify the set of data flows in addition to a 218 specification of the QoS treatment they require. 220 Discussion: 221 A QoS session is an end-to-end relationship. Whenever end-nodes 222 decide to obtain special QoS treatment for their data 223 communication, they set up a QoS session; as part of the process, 224 they or their proxies make a QoS agreement with the network, 225 specifying their data flows and the QoS treatment that the flows 226 require. 228 It is possible for the same QoS session to span multiple network 229 domains that have different resource provisioning architectures. 230 In this document, however, we only deal with the case where the 231 QoS session is realized over an IntServ architecture. It is 232 assumed that sessions will be established using signaling messages 233 of a resource reservation protocol. 235 QoS sessions must have unique identifiers; it must be possible to 236 determine which QoS session a given signaling message pertains to. 237 Therefore, each signaling message should include the identifier of 238 its corresponding session. As an example, in the case of RSVP, the 239 "session specification" identifies the QoS session plus refers to 240 the data flow; the "flowspec" specifies the desired QoS treatment 241 and the "filter spec" defines the subset of data packets in the 242 data flow that receive the QoS defined by the flowspec. 244 QoS sessions can be unicast or multicast depending on the number 245 of participants. In a multicast group there can be several data 246 traffic sources and destinations. Here the QoS agreement does not 247 have to be the same for each branch of the multicast tree 248 forwarding the data flow of the group. Instead, a dedicated 249 network resource in a router can be shared among many traffic 250 sources from the same multicast group (e.g. multicast reservation 251 styles in the case of RSVP). 253 Issues: 254 Even though QoS sessions are considered to be unique, resource 255 reservation capable routers might aggregate them and allocate 256 network resources to these aggregated sessions at once. The 257 aggregation can be based on similar data flow attributes (e.g. 259 similar destination addresses) or it can combine arbitrary 260 sessions as well. While reservation aggregation significantly 261 lightens the signaling processing task of a resource reservation 262 capable router, it also requires the administration of the 263 aggregated QoS sessions and might also lead to the violation of 264 the quality guaranties referring to individual data flows within 265 an aggregation [12]. 267 6.2.2 Resource Reservation Protocol 269 Definition: 270 Resource reservation protocols define signaling messages and 271 message processing rules used to control resource allocation in 272 IntServ architectures. 274 Discussion: 275 It is the signaling messages of a resource reservation protocol 276 that carry the information related to QoS sessions. This 277 information includes a session identifier, the actual QoS 278 parameters, and possibly flow descriptors. 280 The message processing rules of the signaling protocols ensure 281 that signaling messages reach all network nodes concerned. Some 282 resource reservation protocols (e.g. RSVP) are only concerned with 283 this, i.e. carrying the QoS-related information to all the 284 appropriate network nodes, without being aware of its content. 285 This approach allows changing the way the QoS parameters are 286 described and provisioning is done without the need to change the 287 protocol itself. 289 6.2.3 Resource Reservation Capable Router 291 Definition: 292 A router is resource reservation capable (it supports resource 293 reservation) if it is able to interpret signaling messages of a 294 resource reservation protocol and based on these messages is able 295 to adjust the management of its flow classifiers and network 296 resources so as to conform with the content of the messages 298 Discussion: 299 Routers capture signaling messages and manipulates reservation 300 states and/or reserved network resources according to the content 301 of the messages. This ensures that the flows are treated as their 302 specified QoS requirements indicate. 304 6.2.4 Reservation State 306 Definition: 307 A reservation state is the set of entries in the router�s memory 308 that contain all relevant information about a given QoS session 309 registered with the router. 311 Discussion: 312 States are needed because IntServ related resource reservation 313 protocols require the routers to keep track of QoS session and 314 data-flow-related metadata. The reservation state includes the 315 parameters of the QoS treatment; the description of how and where 316 to forward the incoming signaling messages; refresh timing 317 information; etc. 319 Based on how reservation states are stored in a reservation 320 capable router, the routers can be categorized into two classes: 322 Hard-state resource reservation protocols (e.g. ST2 [6]) require 323 routers to store the reservation states permanently, established 324 by a set-up signaling primitive, until the router is explicitly 325 informed that the QoS session is canceled. 327 There are also soft-state resource reservation capable routers, 328 where there are no permanent reservation states, and each state 329 has to be regularly refreshed by appropriate refresh signaling 330 messages. If no refresh signaling message arrives during a certain 331 period then the router stops the maintenance of the QoS session 332 assuming that the end-points do not intend to keep the session up 333 any longer or the communication lines are broken somewhere along 334 the data path. This feature makes soft-state resource reservation 335 capable routers more robust than hard-state routers, since no 336 failures can cause permanent resources to stay permanently stuck 337 in the routers. 339 Issues: 340 Based on the initiating point of the refresh messages, soft-state 341 resource reservation protocols can be divided into two groups. 342 First, there are protocols where it is the responsibility of the 343 end-points or their proxies to initiate refresh messages. These 344 messages are forwarded along the path of the data flow refreshing 345 the corresponding reservation states in each router affected by 346 the flow. Secondly, there are other protocols, where routers and 347 end-points have their own schedule for the reservation state 348 refreshes and they signal these refreshes to the neighboring 349 routers. 351 6.2.5 Resource Reservation Protocol Orientation 353 Definition: 354 The orientation of a resource reservation protocol tells which end 355 of the protocol communication initiates the allocation of the 356 network resources. Thus, the protocol can be sender or receiver 357 initiated, depending on the location of the data flow source 358 (sender) and destination (receiver) compared to the reservation 359 initiator. 361 Discussion: 362 In the case of sender-initiated protocols the resource reservation 363 propagates the same directions as of the data flow. Consequently, 364 in the case of receiver-initiated protocols the signaling messages 365 reserving resources are forwarded backward on the path of the data 366 flow. Due to the asymmetric routing nature of the Internet, in 367 this latter case, the path of the desired data flow should be 368 known before the reservation initiator would be able to send the 369 resource allocation messages. For example in the case of RSVP, the 370 RSVP PATH message [1], traveling from the data flow sources 371 towards the destinations, first marks the path of the data flow on 372 which the resource allocation messages will travel backward. 374 This definition considers only protocols that reserve resources 375 for just one data flow between the end-nodes. The reservation 376 orientation of protocols reserving more than one data flow is not 377 defined here. 379 Issues: 380 The location of the reservation initiator affects the basics of 381 the resource reservation protocols and therefore it is an 382 important design decision. In the case of multicast QoS sessions, 383 the sender-oriented protocols require the traffic sources to 384 maintain a list of receivers and send their allocation messages 385 considering the different requirements of the receivers. Using 386 multicast QoS sessions, the receiver-oriented protocols give the 387 chance to the receivers to place their own resource allocation 388 requests and thus ease the task of the sources. 390 6.3 Router Load Factors 392 The router load expressing the utilization the device naturally 393 affects the performance of the router. During the benchmarking 394 process several load conditions have to be examined. 396 This group of definitions describes different load components that 397 impact only a specific part of the resource reservation capable 398 router. 400 6.3.1 Best-Effort Traffic Load Factor 402 Definition: 403 The best-effort traffic load factor is defined as the volume of 404 the best-effort data traffic that traverses the router in a 405 second. 407 Discussion: 408 Forwarding the best-effort data packets, which requires obtaining 409 the routing information and transferring the data packet between 410 network interfaces, requires processing power, which is expressed 411 by this load factor. 413 Issues: 414 The same amount of data segmented into differently sized packets 415 causes different amounts of load on the router, which has to be 416 considered during the benchmarking measurements. 418 Measurement unit: 419 bits per second (bps) 421 6.3.2 Distinguished Traffic Load Factor 423 Definition: 424 The distinguished traffic load factor is defined as the volume of 425 the distinguished data traffic that traverses the router in a 426 second. 428 Discussion: 429 Similarly to the best-effort data, forwarding the distinguished 430 data packets requires obtaining the routing information and 431 transferring the data packet between network interfaces. However, 432 in this case packets have to be classified as well, which requires 433 additional processing capacity. 435 Issues: 436 Just as in the best-effort case, the same amount of data segmented 437 into differently sized packets causes different amounts of load on 438 the router, which has to be considered during the benchmarking 439 measurements. 441 Measurement unit: 442 bits per second (bps) 444 6.3.3 Session Load Factor 446 Definition: 447 The session load factor is the number of QoS sessions the router 448 is keeping track of. 450 Discussion: 451 Resource reservation capable routers maintain reservation states 452 keeping track of the QoS sessions. Obviously, the more reservation 453 states are registered with the router, the more complex the 454 traffic classification becomes, and the longer time it takes to 455 look up the corresponding resource reservation sate. Moreover, not 456 only the traffic flows, but also the signaling messages that 457 control the reservation states have to be identified first, before 458 taking any other action. This kind of classification also means 459 extra work for the router. 461 In the case of soft-state resource reservation protocols, the 462 session load also affects reservation state maintenance. For 463 example, the maintenance of timers that watchdog the reservation 464 state refreshes may cause further load on the router. 466 Measurement unit: 467 This factor is measured by the number of QoS sessions impacting 468 the router, thus it has no unit. 470 6.3.4 Signaling Intensity Load Factor 472 Definition: 473 The signaling intensity load factor is defined as the number of 474 signaling messages that hit the router during one second. 476 Discussion: 477 The processing of signaling messages requires processor power that 478 raises the load on the control plane of the router. 480 In routers where the control plane and the data plane are not 481 totally independent (e.g. certain parts of the tasks are served by 482 the same processor; or the architecture has common memory buffers, 483 transfer buses or any other resources) the signaling load can have 484 an impact on the router's packet forwarding performance as well. 486 Naturally, just as everywhere else in this document, the term 487 "signaling messages" refer only to the resource reservation 488 protocol related primitives. 490 Issues: 491 Most of the resource reservation protocols have several protocol 492 primitives realized by different signaling message types. Each of 493 these message types may require a different amount of processing 494 power from the router. This fact has to be considered during the 495 benchmarking measurements. 497 Measurement unit: 498 The unit of this factor is 1/second. 500 6.3.5 Signaling Burst Load Factor 502 Definition: 503 The signaling burst load factor is defined as the number of 504 signaling messages that arrive to one input port of the router 505 back-to-back [2], causing persistent load on the signaling message 506 handler. 508 Discussion: 509 The definition focuses on one input port only. A set of messages 510 arriving at different ports, but with such a timing that would be 511 a burst if the messages arrived at the same port, is not 512 considered to be a burst. The reason for this is that it is not 513 guaranteed at a black-box test that this would have the same 514 effect on the router as a burst (incoming at the same interface) 515 has. 517 This definition conforms to the burst definition given in [3]. 519 Issues: 520 Most of the resource reservation protocols have several protocol 521 primitives realized by different signaling message types. Bursts 522 built up of different messages may have a different effect on the 523 router. Consequently, during measurements the content of the burst 524 has to be considered as well. 526 Measurement unit: 527 This load factor is measured by the number of messages in the 528 burst, thus it has no unit. 530 6.4 Performance Metrics 532 This group of definitions is a collection of measurable quantities 533 that describe the impact the different load components have on the 534 router. 536 6.4.1 Signaling Message Handling Time 538 Definition: 539 The signaling message handling time (or, in short, signal handling 540 time) is the latency [2] of a signaling message passing through 541 the router. 543 Discussion: 544 The router interprets the signaling messages, acts based on their 545 content and usually forwards them in an unmodified or modified 546 form. Thus the message handling time is usually longer than the 547 forwarding time of data packets of the same size. 549 There might be signaling message primitives, however, that are 550 drained or generated by the router, like certain refresh messages. 551 In this case the signal handling time is immeasurable, therefore 552 it is not defined for such messages. 554 In the case of signaling messages that carry information 555 pertaining to multicast flows, the router might issue multiple 556 signaling messages after processing them. In this case, by 557 definition, the signal handling time is the latency between the 558 incoming signaling message and the last signaling message related 559 to the received one. 561 The signal handling time may be dependent on the type of the 562 signaling message. For example, it usually takes a shorter time 563 for the router to remove a reservation state than to set it up. 564 This fact has to be considered during the benchmarking process. 566 The signal handling time is an important characteristic as it 567 directly affects the setup time of a QoS session. 569 Measurement unit: 570 The unit of the signaling message handling time is the second. 572 6.4.2 Distinguished Traffic Delay 574 Definition: 575 Distinguished traffic delay is the latency [2] of a distinguished 576 data packet passing through the tested router device. 578 Discussion: 579 Distinguished traffic packets must be classified first in order to 580 assign the network resources dedicated to the flow. The time of 581 the classification is added to the usual forwarding time 582 (including the queuing) that a router would spend on the packet 583 without any resource reservation capability. This classification 584 procedure might be quite time consuming in routers with vast 585 amounts of reservation states. 587 There are routers where the processing power is shared between the 588 control plane and the data plane. This means that the processing 589 of signaling messages may have an impact on the data forwarding 590 performance of the router. In this case the distinguished traffic 591 delay metric is an indicator of the influence the two planes have 592 on each other. 594 Issues: 595 Queuing of the incoming data packets in routers might bias this 596 metric, measurement procedures have to consider this effect. 598 Measurement unit: 599 The unit of the distinguished traffic delay is the second. 601 6.4.3 Best-effort Traffic Delay 603 Definition: 604 Best-effort traffic delay is the latency of a best-effort data 605 packet traversing the tested router device. 607 Discussion: 608 If the processing power of the router is shared between the 609 control and data plane, then the processing of signaling messages 610 may have an impact on the data forwarding performance of the 611 router. In this case the best-effort traffic delay metric is an 612 indicator of the influence the two planes have on each other. 614 Issues: 615 Queuing of the incoming data packets in routers might bias this 616 metric as well, so measurement procedures have to consider this 617 effect. 619 Measurement unit: 620 The unit of the best-effort traffic delay is the second. 622 6.4.4 Signaling Message Loss 624 Definition: 625 Signaling message loss is the ratio of the actual and the expected 626 number of signaling messages leaving a resource reservation 627 capable router, subtracted from one. 629 Discussion: 630 This definition gives the same value as the ratio of the lost and 631 the expected messages. The reason for choosing the given 632 definition is that the number of lost messages cannot be measured 633 directly. 635 There are certain types of signaling messages that are required to 636 be forwarded by reservation capable routers as soon as their 637 processing is finished. However, due to the high router load or 638 for other reasons, the forwarding or even the processing of these 639 signaling messages might be canceled. To characterize such 640 situations we introduce the signaling message loss metric 641 expressing the ratio of the signaling messages that actually have 642 left the router and those ones that were expected to leave the 643 router. 645 Since the most frequent reason for signaling message loss is high 646 router load, this metric is suitable for sounding out the 647 scalability limits of resource reservation capable routers. 649 During the measurements one must be able to determine whether a 650 signaling message is still in the queues of the router or if it 651 has already been dropped. For this reason we define a signaling 652 message as lost if no forwarded signaling message is emitted 653 within a reasonably long time period. This period is defined along 654 with the benchmarking methodology. 656 Measurement unit: 657 This measure has no unit; it is expressed as a real number, which 658 is between zero and one, including the limits. 660 6.4.5 Session Maintenance Capacity 662 Definition: 663 The session maintenance capacity metric is used in the case of 664 soft-state resource reservation protocols only. It gives the ratio 665 of the number of QoS sessions actually maintained and the number 666 of QoS sessions that should have been maintained during one 667 refresh period. 669 Discussion: 670 For soft-state protocols maintaining a QoS session means 671 refreshing the reservation states associated with it. 673 When a soft-state resource reservation capable router is 674 overloaded, it may happen that the router is not able to refresh 675 all the registered reservation states, because it does not have 676 the time to run the state refresh task. In this case sooner or 677 later some QoS sessions will be lost even if the endpoints still 678 require their maintenance. 680 The session maintenance capacity sounds out the maximal number of 681 QoS sessions that the router is capable of maintaining. 683 Issues: 684 In the case of soft-state resource reservation protocols a router 685 that fails to maintain a QoS session will not generate refresh 686 signaling messages either. This has direct consequences on the 687 signaling message loss metric. 689 Measurement unit: 690 This measure has no unit; it is expressed as a real number, which 691 is between zero and one (including the limits). 693 6.5 Scalability Limit 695 Definition: 696 The scalability limit is the threshold between the steady state 697 and the overloaded state of the device under test. 699 Discussion: 700 All existing routers have finite buffer memory and finite 701 processing power. In the steady state of the router, the buffer 702 memories are not fully utilized and the processing power is enough 703 to cope with all tasks running on the router. As the router load 704 increases the buffers are starting to fill up and/or the router 705 has to postpone more and more tasks. However, there is a certain 706 point where no more buffer memory is available, or a task cannot 707 be postponed any longer; thus the router is forced to drop a 708 packet or an activity. This way the overloaded state of the 709 resource reservation capable router can be recognized by the fact 710 that some kind of data (signaling or packet) or task (e.g. QoS 711 session maintenance) loss occurs. 713 The scalability limit of the router is the particular critical 714 load condition when the router is still in the steady state but 715 the smallest amount of additional load would drive it to the 716 overloaded state. 718 7. Security Considerations 720 As this document only provides terminology and describes neither a 721 protocol nor an implementation, there are no security considerations 722 associated with it. 724 8. Acknowledgements 726 We would like to thank the following individuals for their help in 727 the research and development work, which contributed to form this 728 document: Joakim Bergkvist and Norbert Vegh from Telia Research AB, 729 Sweden; Balazs Szabo, Gabor Kovacs and Peter Vary from the High Speed 730 Networks Laboratory, Budapest University of Technology and Economics, 731 Hungary. 733 9. References 735 [1] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) - 736 Version 1 Functional Specification", RFC 2205, September 1997. 738 [2] S. Bradner, "Benchmarking Terminology for Network 739 Interconnection Devices", RFC 1242, July 1991 741 [3] R. Mandeville, "Benchmarking Terminology for LAN Switching 742 Devices", RFC 2285, February 1998 744 [4] R. Hancock (ed.), et. al., "Next Steps in Signaling: Framework", 745 IETF draft: draft-ietf-nsis-fw-02.txt (work in progress), 2003 747 [5] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism 748 for the Internet", Computer Communication Review, on-line 749 version, volume 29, number 2, April 1999 751 [6] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 752 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 753 1995 755 [7] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated 756 Reservation in the Internet", Journal on High Speed Networks, 757 Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998 759 [8] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I. 760 Csel�nyi, M. Maliosz, "Boomerang : A Simple Protocol for 761 Resource Reservation in IP Networks", Vancouver, IEEE Real-Time 762 Technology and Applications Symposium, June 1999 764 [9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight 765 Resource Reservation for Unicast IP Traffic", International WS 766 on QoS'98, IWQoS'98, May 18-20, 1998 768 [10] J. Manner (ed.), X. Fu (ed.), "Analysis of Existing Quality of 769 Service Signaling Protocols", IETF draft: draft-ietf-nsis- 770 signalling-analysis-01.txt (work in progress), 2003 772 [11] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", 773 RFC 2210, September 1997 775 [12] F. Baker,C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation 776 of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 777 2001 779 Authors' Addresses 781 Gabor Feher 782 Budapest University of Technology and Economics 783 Department of Telecommunications and Mediainformatics 784 Magyar Tudosok krt. 2, H-1117, Budapest, Hungary 785 Phone: +36 1 463-1538 786 Email: Gabor.Feher@tmit.bme.hu 788 Krisztian Nemeth 789 Budapest University of Technology and Economics 790 Department of Telecommunications and Mediainformatics 791 Magyar Tudosok krt. 2, H-1117, Budapest, Hungary 792 Phone: +36 1 463-1565 793 Email: Krisztian.Nemeth@tmit.bme.hu 795 Andras Korn 796 Budapest University of Technology and Economics 797 Institute of Mathematics, Department of Analysis 798 Egry Jozsef u. 2, H-1111 Budapest, Hungary 799 Phone: +36 1 463-2475 800 Email: Korn@math.bme.hu 802 Istvan Cselenyi 803 TeliaSonera International Carrier 804 Vaci ut 22-24, H-1132 Budapest, Hungary 805 Phone: +36 1 412-2705 806 Email: Istvan.Cselenyi@teliasonera.com