idnits 2.17.1 draft-ietf-bmwg-benchres-term-00.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. == 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 Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) 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 (July 2001) is 8320 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) -- Missing reference section? '1' on line 694 looks like a reference -- Missing reference section? '2' on line 698 looks like a reference -- Missing reference section? '5' on line 707 looks like a reference -- Missing reference section? '6' on line 712 looks like a reference -- Missing reference section? '7' on line 716 looks like a reference -- Missing reference section? '8' on line 720 looks like a reference -- Missing reference section? '9' on line 724 looks like a reference -- Missing reference section? '10' on line 728 looks like a reference -- Missing reference section? '3' on line 701 looks like a reference -- Missing reference section? '4' on line 704 looks like a reference -- Missing reference section? '11' on line 733 looks like a reference -- Missing reference section? '12' on line 736 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Gabor Feher, BUTE 3 INTERNET-DRAFT Istvan Cselenyi, TRAB 4 Expiration Date: January 2002 Andras Korn, BUTE 6 July 2001 8 Benchmarking Terminology for Routers Supporting Resource Reservation 9 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft shadow directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This memo provides information for the Internet community. This memo 33 does not specify an Internet standard of any kind. Distribution of 34 this memo is unlimited. 36 2. Table of contents 38 1. Status of this Memo.............................................1 39 2. Table of contents...............................................1 40 3. Abstract........................................................2 41 4. Introduction....................................................2 42 5. Existing definitions............................................3 43 6. Definition of Terms.............................................3 44 6.1 Resource Reservation Protocol Basics........................3 45 6.1.1 Resource Reservation Session...........................3 46 6.1.2 Multicast Resource Reservation Session.................4 47 6.1.3 Resource Reservation Capable Router....................4 48 6.1.4 Signaling End-point....................................5 49 6.1.5 Reservation Initiator..................................5 50 6.1.6 Reservation Session Maintenance........................6 51 6.1.7 Signaling Path.........................................7 52 6.2 Traffic Types...............................................8 53 6.2.1 Premium Traffic........................................8 54 6.2.2 Best-Effort Traffic....................................8 55 6.3 Router Load Types...........................................8 56 6.3.1 Session Load...........................................9 57 6.3.2 Signaling Load.........................................9 58 6.3.3 Signaling Burst.......................................10 59 6.4 Performance Metrics........................................10 60 6.4.1 Signaling Message Handling Time.......................10 61 6.4.2 Premium Traffic Delay.................................11 62 6.4.3 Best-effort Traffic Delay.............................12 63 6.4.4 Signaling Message Loss................................12 64 6.4.5 Scalability Limit.....................................13 65 7. Acknowledgement................................................13 66 8. References.....................................................14 67 9. Authors' Addresses:............................................14 69 3. Abstract 71 The purpose of this document is to define terminology specific to the 72 performance benchmarking of the resource reservation signaling of IP 73 routers. These terms are used in additional documents that define 74 benchmarking methodologies for routers supporting resource 75 reservation and define reporting formats for the benchmarking 76 measurements. 78 4. Introduction 80 The IntServ over DiffServ framework [1] outlines a heterogeneous 81 Quality of Service (QoS) architecture for multi domain Internet 82 services. Signaling based resource reservation (e.g. via RSVP [2]) is 83 an integral part of that model. While this significantly lightens the 84 load on most of the core routers, the performance of border routers 85 that handle the QoS signaling is still crucial. Therefore network 86 operators, who are planning to deploy this model, shall scrutinize 87 the scalability limitations in reservation capable routers and the 88 impact of signaling on the forwarding performance of the routers. 90 An objective way for quantifying the scalability constraints of QoS 91 signaling is to perform measurements on routers that are capable of 92 resource reservation. This document defines terminology for specific 93 set of tests that vendors or network operators can use to measure and 94 report the signaling performance characteristics of router devices 95 that support resource reservation protocols. The results of these 96 tests provide comparable data for different products supporting the 97 decision process before purchase. Moreover, these measurements 98 provide input characteristics for the dimensioning of a network in 99 which resources are provisioned dynamically by signaling. Finally, 100 the tests are applicable for characterizing the impact of the control 101 plane signaling on the forwarding performance of routers. 103 This benchmarking terminology document is based on the knowledge 104 gained by examination of (and experimentation with) several very 105 different resource reservation protocols: RSVP [2], Boomerang [5], 106 YESSIR [6], ST2+ [7], SDP [8], Ticket [9] and Load Control [10]. 108 Nevertheless, this document aspires to compose terms that are valid 109 in general and not restricted to these protocols. 111 5. Existing definitions 113 RFC 1242 [3] "Benchmarking Terminology for Network Interconnect 114 Devices" and RFC 2285 [4] "Benchmarking Terminology for LAN Switching 115 Devices" contains discussions and definitions for a number of terms 116 relevant to the benchmarking of signaling performance of reservation 117 capable routers and should be consulted before attempting to make use 118 of this document. 120 For the sake of clarity and continuity this document adopts the 121 template for definitions set out in Section 2 of RFC 1242. 122 Definitions are indexed and grouped together in sections for ease of 123 reference. 125 6. Definition of Terms 127 6.1 Resource Reservation Protocol Basics 129 This group of definitions applies to various signaling based resource 130 reservation protocols implemented on IP router devices. 132 6.1.1 Resource Reservation Session 134 Definition: 135 A resource reservation session (or shortly reservation) expresses 136 that routers along the data path between two network nodes apply 137 special QoS treatment to a certain traffic flow. 139 Discussion: 140 The QoS treatment is specified by giving the amount of networking 141 resources that are dedicated to the traffic flow during the length 142 of the reservation session. Depending on the protocol, there are 143 different approaches to define the network resource requirement of 144 a traffic flow. It can be described by high-level parameters, like 145 the required bandwidth, service class or the maximum traffic 146 delay; or it can be low-level information, like the parameters of 147 a leaky-bucket model of the traffic flow [11]. 149 Issues: 150 There are resource reservation protocols, where resource 151 dedications in a router are unique for each resource reservation 152 session. However, in this case the number of resource dedications 153 grows along with the number of sessions and working with huge 154 number of resource dedications raise problems (see Reservation 155 Session Maintenance). Therefore, many resource reservation 156 protocols allow to bunch different reservation sessions into one 157 aggregated session, which takes only one resource dedication for 158 the whole bunch. The aggregation can be based on the similar 159 attributes of the flows, (e.g. aggregation using DiffServ code- 160 points [12]) or it can combine arbitrary sessions as well. 162 See Also: 163 Reservation Session Maintenance 165 6.1.2 Multicast Resource Reservation Session 167 Definition: 168 A multicast resource reservation session (or, in short, multicast 169 reservation) denotes that certain QoS treatment is applied to the 170 packets of every traffic flow related to a multicast group. 172 Discussion: 173 Usually, there are several traffic sources and destinations in a 174 multicast group. In order to be able to guarantee the QoS 175 parameters for each packet of the multicast flow, every router 176 that forwards the multicast traffic must dedicate resources to the 177 flow. 179 Generally, there are two types of multicast resource reservations: 180 many-to-many and one-to-many multicast reservations. Those of the 181 first type allow traffic to be originated from several sources, 182 while those of the second type allow only one traffic source in 183 the whole multicast group and it should not change during the 184 lifetime of the session. In several cases, a many-to-many 185 multicast reservation session does not require the same amount of 186 resources reserved for every involved router. Depending on the 187 capabilities of the resource reservation protocol, the traffic 188 destinations in the multicast group may request different QoS 189 parameters. Moreover, beside the different QoS requirements, the 190 protocols may describe more than one reservation styles expressing 191 the resource reservation distribution among the involved routers. 192 (e.g. RSVP SE/WF/FF [2]) 194 Issues: 195 Naturally, many-to-many multicast reservation capable protocols 196 are bound to be more complex than one-to-many or non-multicast 197 protocols. Usually, the router has to be aware of the location of 198 the traffic sources and destinations participating in the 199 multicast reservation in the aspect of its network interfaces, 200 plus the resource requirements of the traffic destinations in 201 order to be able to calculate the right amount of resources 202 dedicated to the session. 204 6.1.3 Resource Reservation Capable Router 206 Definition: 207 By definition, a router is resource reservation capable - supports 208 resource reservation - if it understands a resource reservation 209 protocol that signals the set-up, tear-down and modification of 210 resource reservation sessions. 212 Discussion: 214 Resource reservation protocols define signaling messages that are 215 interpreted by resource reservation capable routers. The router 216 captures the signaling message and manipulates resource 217 reservation sessions according to the content of the message. In 218 addition, the protocol might declare to forward the signaling 219 message or an altered version of it to other routers as well. 221 Issues: 222 There are resource reservation protocols where routers are 223 required to initiate signaling messages besides the signaling 224 message forwarding. The benefits of such protocols are that 225 changes in resource reservation sessions can be signaled to other 226 routers immediately, even if the change is not caused by signaling 227 messages directly. In contrast, the message initiation takes time 228 that slows down the signaling message processing, so there are 229 protocols where routers communicate with each other using the 230 forwarded signaling messages. 232 6.1.4 Signaling End-point 234 Definition: 235 A signaling end-point is a network node capable of initiating and 236 terminating resource reservation sessions. 238 Discussion: 239 Typically, signaling end-points have a separate protocol stack 240 that is capable of generating and understanding the signaling 241 messages. However, in some special cases, the resource reservation 242 initiation is carried out without the notice of the signaling 243 terminating node. For example, the Boomerang resource reservation 244 protocol encapsulates the reservation requests in an ICMP Echo 245 message. This message is bounced back from the signaling 246 terminating network node and as a result the node becomes a 247 signaling end-point without understanding the reservation 248 protocol. 250 Reservation gateways are protocol translators that translate the 251 signaling messages of one resource reservation protocol into 252 messages of another resource reservation protocol. Thus the 253 reservation gateway represents two signaling end-points in one, as 254 it is both a signaling terminator and a signaling initiator. 256 6.1.5 Reservation Initiator 258 Definition: 259 The reservation initiator is the signaling end-point that 260 initiates the resource reservation session setup. 262 Discussion: 263 Resource reservation protocols can be classified depending on the 264 relationship between the reservation initiators and their role in 265 the traffic flow. 267 In the case of receiver-oriented protocols, the traffic 268 destinations, which are the receivers of the data traffic, 269 initiate the reservation session setup, unlike the sender-oriented 270 protocols where this is done by traffic sources. Moreover, there 271 are protocols where both the traffic source and destination can 272 act as the reservation initiator. 274 The importance of the reservation initiator orientation is only 275 dominant in case of multicast reservation sessions. Generally, in 276 multicast groups the number of traffic destinations changes more 277 frequently than the number of traffic sources. In this case, the 278 receiver-oriented protocols do not require the traffic sources to 279 change their states generating signaling messages when a new 280 traffic destination joins or an existing one leaves the group, 281 since the reservation session is managed by the traffic 282 destinations. 284 6.1.6 Reservation Session Maintenance 286 Definition: 287 Resource reservation protocols require the routers to maintain the 288 resource reservation sessions from the initiation until the 289 teardown of the session. This maintenance often involves the 290 regular checking and refreshing of the session. 292 Discussion: 293 Based on the approach of reservation session maintenance, resource 294 reservation protocols can be divided into two categories: soft- 295 state protocols and hard-state protocols. 297 In the case of hard-state protocols (e.g. ST2 [7]), the resource 298 reservation session established by a set-up signaling primitive is 299 permanent and is cancelled only when the corresponding tear-down 300 signaling primitive arrives to the router. Contrary, in the case 301 of the soft-state protocols there are no permanent resource 302 reservations. The resource reservation session have to be 303 regularly refreshed by appropriate signaling messages. No refresh 304 signaling message arrived during a certain period is assumed as 305 the indication that the resource reservation session is not 306 maintained by the signaling end-points any longer. In such case, 307 the router tears the session down waiting for no explicit request. 308 For this reason, soft-state protocols exhibit more robust behavior 309 than hard-state protocols, since no failures can cause permanent 310 resource stuck in the routers. 312 Issues: 313 Although soft-state protocols are more robust than hard-state 314 protocols, the frequent processing of refresh signaling messages 315 might cause serious increase in the router load. Moreover, session 316 maintenance mechanisms often use timers to watch the refresh 317 period expirations of the sessions. The maintenance of such timers 318 and the actions due to the expiration of such timers also 319 contributes to the router load. 321 In order to reduce the large number of refresh signaling message 322 processing overhead, the resource reservation protocol may support 323 various mechanisms to pack several refresh signaling messages into 324 one signaling message. 326 6.1.7 Signaling Path 328 Definition: 329 A signaling path is a sequence of network nodes and links along 330 which signaling messages travel from one signaling end-point to 331 the other. 333 Discussion: 334 In the case of sender-oriented protocols, the data traffic and the 335 signaling messages are addressed to the IP address of the 336 destination and therefore routed on the same path. Thus the 337 signaling messages are delivered to every router that handles the 338 traffic flow to which the reservation session refers. No more and 339 no fewer routers are affected. However, in the case of receiver- 340 oriented protocols, the reservation request and the data traffic 341 are forwarded in opposite directions. And since Internet routing 342 is not symmetric, it is not trivial that they go through the same 343 routers. To assure that the signaling messages reach every router 344 that handles the traffic flow from the source to the destination, 345 the traffic sources should issue a special message addressed to 346 the destinations marking the path for the reservation session. 347 Each router that receives the path dedicating signaling message 348 remembers the address of the node where the message came from, and 349 when a signaling message arrives carrying reservation information 350 it is forwarded to the address of the previous node. Thus the path 351 dedicating messages mark out a path along which the reservation 352 messages travel backward. 354 In the case of a multicast reservation session, the situation is 355 slightly more complicated. The signaling path is rather a 356 signaling mesh where the signaling messages travel from the 357 sources to the destinations. 359 Issues: 360 It is not unusual for routers to change their routing from time to 361 time. The reason for the change can be a failure of a neighboring 362 router or link. In case of route changes the data traffic will be 363 forwarded along a different path than the signaling messages used 364 in establishing the resource dedications for the reservation 365 session. In order to properly handle this situation, hard-state 366 protocols have to be much more sophisticated in order to detect 367 the route change and to re-reserve the resources on the new path. 368 However, soft-state protocols do not have to worry about such 369 situation, since the refresh messages can be used to set up the 370 reservation on the new path and the dedicated resources will 371 eventually disappear from routers of the obsoleted path. 373 6.2 Traffic Types 375 This group of definitions defines traffic types forwarded by resource 376 reservation capable routers. 378 6.2.1 Premium Traffic 380 Definition: 381 Premium traffic is a traffic type that the router distinguishes 382 from best-effort traffic (to be defined later) and forwards its 383 packets according to a QoS agreement. 385 Discussion: 386 Traffic that corresponds to a resource reservation session in the 387 router is premium traffic. The QoS treatment is defined in the 388 associated flow descriptor that is established by the signaling 389 messages during the reservation session setup. 391 The router may distinguish several types of premium traffic (e.g. 392 delay sensitive traffic, loss sensitive traffic, etc.). Different 393 types of premium traffic may receive different QoS treatment. 395 Issues: 396 The router has to identify every packet whether it has dedicated 397 resource or not. This can be done by either multi-field 398 classification [12] using the IP 5-tuple or behavior-aggregate 399 classification using the DSCP field. However, if a packet claims 400 that it has an associated resource reservation session in the 401 router, the router has to find the flow descriptor, which might be 402 time consuming in routers with vast amounts of resource 403 reservation sessions. 405 6.2.2 Best-Effort Traffic 407 Definition: 408 Best-effort traffic is a traffic type that has no reservation 409 entry in the router. 411 Discussion: 412 Traffic flows that do not require QoS guarantees along their path 413 are considered to be best-effort traffic. "Best-effort" means that 414 the router makes its best effort to forward every data packet, but 415 does not guarantee anything. This is the most common type of 416 traffic on today's Internet. (There may be scenarios where 417 resource reservation is done for BE traffic too, but those are 418 outside of the focus of this memo.) 420 6.3 Router Load Types 422 This group of definitions describes different load component types 423 that are independent of each other and impact only a specific part of 424 the resource reservation capable router's control plane. Arbitrary 425 router load can be derived from the combination of different amount 426 of such independent load components. 428 6.3.1 Session Load 430 Definition: 431 Session load is the load that manifests itself as the excess 432 processing power required to keep track of reservation sessions. 434 Discussion: 435 All signaling based resource reservation protocol implementation 436 employ a packet classifier algorithm that distinguishes the flows 437 having reservations in the router from the others that do not. 438 Therefore each implementation maintains a list of reservation 439 session descriptors that is instrumental in keeping track of the 440 resource reservation dedication. Obviously, the more reservation 441 sessions are set up on the router, the more complex traffic 442 classification becomes, and the more time it takes for the 443 classification algorithm to identify the session descriptor list. 445 Moreover, in most protocols, not only the traffic flows, but also 446 signaling messages that manipulate resource reservations on the 447 router have to identify themselves first, before taking any other 448 actions. This kind of classification gives extra work for the 449 router. 451 Session load also involves the duties related to reservation 452 session maintenance. The maintenance of timers that watchdog the 453 reservation session refreshes and the signaling of the reservation 454 session refresh may cause severe load on the router. Based on the 455 initiating point of the refresh messages, resource reservation 456 protocols can be divided into two groups. First, there are 457 protocols where it is the responsibility of the signaling end- 458 points to initiate refresh messages, which messages are forwarded 459 by the routers along the signaling path refreshing the 460 corresponding session. Second, there are other protocols, where 461 the session refresh happens between the two peering network nodes 462 from the signaling path only. In this latter case, the routers and 463 signaling end-points have their own schedule for the refresh 464 message initiation. The first approach lightens the load of the 465 session maintenance task; however, the second approach bears the 466 ability to adjust the signaling message traffic intensity along 467 the signaling path. 469 Measurement unit: 470 The session load is represented by the number of reservation 471 sessions in the router. 473 6.3.2 Signaling Load 475 Definition: 476 Signaling load is the load that manifests itself as the time 477 required to process the incoming signaling messages. 479 Discussion: 480 The processing of signaling messages requires processing power 481 that raises load on the control plane of the router. In the case 482 of routers where the control plane and the data plane are not 483 totally independent (e.g. certain parts of the tasks are served by 484 the same processor; or the architecture has common memory buffers 485 or transfer buses) the signaling load can have an impact on the 486 router's packet forwarding performance as well. 488 Most of the resource reservation protocols have several protocol 489 primitives realized by different signaling message types. Each of 490 these message types may require a different amount of processing 491 power from the router. 493 Measurement unit: 494 The signaling load is characterized by the signaling intensity, 495 which expresses how many signaling messages arrive to the router 496 within a time unit. The typical unit of the signaling intensity is 497 [1/s], which is the number of signaling messages that arrive 498 within one second. 500 6.3.3 Signaling Burst 502 Definition: 503 The signaling burst denotes a certain number of signaling messages 504 that arrive to the input port(s) of the router without 505 interruption, causing persistent load on the signaling message 506 handler. 508 Discussion: 509 Back-to-back signaling messages on one port of the router form a 510 typical signaling burst. However, other cases are imaginable, for 511 example when signaling messages arrive on different ports 512 simultaneously or with an overlap in time (i.e. when the tail of 513 one signaling message is behind the head of another one arriving 514 on another port). 516 Measurement unit: 517 The signaling burst is characterized by its length, which is the 518 number of messages that have arrived during the burst. 520 6.4 Performance Metrics 522 This group of definitions is a collection of the measurable effects 523 of the impact a resource reservation protocol has on the router 524 device it is running on. 526 6.4.1 Signaling Message Handling Time 528 Definition: 529 The signaling message handling time (or, in short, signal handling 530 time) is the time that a signaling message spends inside the 531 router before it is forwarded to the next node on the signaling 532 path. 534 Discussion: 535 Depending on the type of the signaling message, the router also 536 interprets the signaling messages, acts on them and forwards an 537 extended signaling message, which might contain information about 538 the result of the message processing. Thus the message handling 539 time is usually longer than forwarding time of data packets of the 540 same size. In addition, there might be also signaling message 541 primitives that are drained or generated by the router. Thus, the 542 signal handling time is defined as the time difference between the 543 time when a signaling message is received and the time the 544 corresponding processed signaling message is transmitted. If a 545 message is not forwarded on the router, the signal handling time 546 is immeasurable; therefore it is not defined for such messages. 548 In the case of signaling messages that carry information 549 pertaining to multicast flows, the router might issue multiple 550 signaling messages after processing. In this case, by definition, 551 the signal handling time is the time interval elapsed between the 552 arrival of the incoming signaling message and the departure of the 553 last signaling message related to the received one. 555 This metric depends on the load on the router, as other tasks may 556 limit the processing power available to signaling message 557 handling. In addition to the router load, the signal handling time 558 may also be dependent on the type of the signaling message. For 559 example, it usually takes a shorter time for the router to tear 560 down a resource reservation session than to set it up. 562 Issues: 563 In the case of soft-state protocols, where refresh messages are 564 exchanged between peering network nodes only (see Reservation 565 Session Maintenance) the incoming refresh messages are drained by 566 the router making impossible to measure the signaling message 567 handling time on them. 569 Signal handling time is an important characteristic as it directly 570 affects the setup time of a session. 572 Measurement unit: 573 The typical unit of the signaling message handling time is 574 microsecond. 576 6.4.2 Premium Traffic Delay 578 Definition: 579 Premium traffic delay is the forwarding time of a packet that 580 belongs to a premium traffic flow passing through a resource 581 reservation capable router. 583 Discussion: 585 Premium traffic packets must be classified first in order to find 586 the resources dedicated to the flow. The time of the 587 classification is added to the usual forwarding time that a router 588 would spend on the packet without any resource reservation 589 capability. 591 There are routers where the processing power is shared between the 592 control plane and the data plane. This means that the processing 593 of signaling messages may have an impact on the data forwarding 594 performance of the router. In this case the premium traffic delay 595 metric reflects the influence the two planes have on each other. 597 Measurement unit: 598 The typical unit of the premium traffic delay is the microsecond. 600 6.4.3 Best-effort Traffic Delay 602 Definition: 603 Best-effort traffic delay is the forwarding time of a packet that 604 does not belong to any premium traffic flow passing through a 605 resource reservation capable router. 607 Discussion: 608 It looks trivial that the classification algorithms do not have 609 any influence on the best-effort traffic. However, the processing 610 power sharing between the control and data plane may cause delays 611 in the forwarding procedure of each packet. 613 Measurement unit: 614 The typical unit of the best-effort traffic delay is microsecond. 616 6.4.4 Signaling Message Loss 618 Definition: 619 Signaling message loss is the ratio of the actual and the expected 620 number of signaling messages leaving a resource reservation 621 capable router subtracted from one. 623 Discussion: 624 There are certain types of signaling messages, which are required 625 to be forwarded by the router immediately when their processing is 626 finished. However, due to the high router load or for other 627 reasons, the forwarding or even the processing of the signaling 628 message might be canceled. To characterize such situations we 629 introduce the signaling message loss metric, which expresses the 630 ratio of the signaling messages that actually have left the router 631 and those ones that were expected to leave the router as a result 632 of the incoming signaling messages processing. 634 Since the most frequent reason for the signaling message loss is 635 the high router load, therefore this metric is suitable for 636 sounding out the scalability limits of resource reservation 637 capable routers. 639 Issues: 640 In the case of routers where network packets are queued in several 641 places, we have to be aware of that a signaling message may be 642 delayed seriously. Therefore, it may be hard or impossible to 643 determine whether the signaling message is still in the queues or 644 whether it was already dropped. By definition we say that a 645 signaling message is lost if there is no appearing forwarded 646 signaling message within a reasonable long time period. This time 647 period should be adjusted to the actual resource reservation 648 protocol (e.g. soft-state protocols may wait as much as the 649 refresh period to determine the loss of a signaling message) 651 Measurement unit: 652 Usually, we measure the signaling message loss over a longer 653 period of time and then we express it as a percentage value. 654 Besides, in many cases it is enough to know that there was 655 signaling loss. 657 6.4.5 Scalability Limit 659 Definition: 660 The scalability limit is the threshold between the steady state 661 and the overloaded state of the device under test. 663 Discussion: 664 All existing routers have finite buffer memory and finite 665 processing power. In the steady state of the router, the buffer 666 memories are not fully utilized and the processing power is enough 667 to cope with all tasks running on the router. As the router load 668 increases the router has to postpone more and more tasks. These 669 tasks (e.g. forwarding certain packets) are queued in the buffers, 670 and processed later. However, there is a certain point where no 671 more buffer memory is available; thus, the router becomes 672 overloaded and it is unable to store any more tasks for future 673 processing, so it is forced to drop them. Therefore the overloaded 674 state of the router can be recognized by the fact that some kind 675 of data (signaling or packet) loss occurs. A resource reservation 676 capable router may drop signaling messages, data packets or entire 677 resource reservation sessions. 679 The critical load condition when the router is still in the steady 680 state but the smallest amount of constant load increase would 681 drive it to the overloaded state is the scalability limit of the 682 router. 684 7. Acknowledgement 686 We would like to thank the following individuals for their help in 687 forming this document: Joakim Bergkvist and Norbert Vegh from Telia 688 Research AB, Sweden, Krisztian Nemeth, Balazs Szabo, Gabor Kovacs and 689 Peter Vary from High Speed Networks Laboratory of Budapest University 690 of Technology and Economics, Hungary. 692 8. References 694 [1] Y. Bernet, et. al., "A Framework For Integrated Services 695 Operation Over Diffserv Networks", Internet Draft, work in 696 progress, May 2000, 698 [2] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) - 699 Version 1 Functional Specification", RFC 2205, September 1997. 701 [3] S. Bradner, "Benchmarking Terminology for Network 702 Interconnection Devices", RFC 1242, July 1991 704 [4] R. Mandeville, "Benchmarking Terminology for LAN Switching 705 Devices", RFC 2285, February 1998 707 [5] J. Bergkvist, I. Cselenyi, D. Ahlard, "Boomerang - A Simple 708 Resource Reservation Framework for IP", Internet Draft, work in 709 progress, November 2000, 712 [6] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism 713 for the Internet", Computer Communication Review, on-line 714 version, volume 29, number 2, April 1999 716 [7] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 717 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 718 1995 720 [8] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated 721 Reservation in the Internet", Journal on High Speed Networks, 722 Special Issue on QoS Routing and Signaling, Vol 7 No 2, 1998 724 [9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight 725 Resource Reservation for Unicast IP Traffic", International WS 726 on QoS'98, IWQoS'98, May 18-20, 1998 728 [10] L. Westberg, Z. R. Turanyi, D. Partain, Load Control of Real- 729 Time Traffic, A Two-bit Resource Allocation Scheme, Internet 730 Draft, work in progress, , April 731 2000 733 [11] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", 734 RFC 2210, September 1997 736 [12] K. Nichols et al., "Definition of the Differentiated Services 737 Field (DS Field) in the IPv4 and IPv6 Headers ", RFC 2474 739 9. Authors' Addresses: 741 Gabor Feher 742 Budapest University of Technology and Economics (BUTE) 743 Department of Telecommunications and Telematics 744 Pazmany Peter Setany 1/D, H-1117, Budapest, Hungary 745 Phone: +36 1 463-3110 746 Email: feher@ttt-atm.ttt.bme.hu 748 Istvan Cselenyi 749 Telia Research AB 750 Vitsandsgatan 9B 751 SE 12386, Farsta 752 SWEDEN, 753 Phone: +46 8 713-8173 754 Email: istvan.i.cselenyi@telia.se 756 Andras Korn 757 Budapest University of Technology and Economics (BUTE) 758 Institute of Mathematics, Department of Analysis 759 Egry Jozsef u. 2, H-1111 Budapest, Hungary 760 Phone: +36 1 463-2475 761 Email: korn@math.bme.hu