idnits 2.17.1 draft-ietf-bmwg-benchres-term-02.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 Introduction 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.) ** The document seems to lack an Authors' Addresses Section. ** 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 (November 2002) is 7823 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: '12' is defined on line 787, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 790, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2998 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2460 (ref. '12') (Obsoleted by RFC 8200) Summary: 12 errors (**), 0 flaws (~~), 4 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 Istvan Cselenyi, TRAB 4 Expiration Date: May 2003 Andras Korn, BUTE 6 November 2002 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 Unicast 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 Orientation................................5 50 6.1.6 Reservation Session State..............................6 51 6.1.7 Signaling Path.........................................7 52 6.2 Traffic Types...............................................8 53 6.2.1 Best-Effort Data Packets...............................8 54 6.2.2 Premium Data Packets...................................8 55 6.3 Router Load Types...........................................9 56 6.3.1 Traffic Load...........................................9 57 6.3.2 Session Load...........................................9 58 6.3.3 Signaling Load........................................10 59 6.3.4 Signaling Burst.......................................11 60 6.4 Performance Metrics........................................11 61 6.4.1 Signaling Message Handling Time.......................11 62 6.4.2 Premium Traffic Delay.................................12 63 6.4.3 Best-effort Traffic Delay.............................12 64 6.4.4 Signaling Message Loss................................13 65 6.4.5 Session Refreshing Capacity...........................13 66 6.4.6 Scalability Limit.....................................14 67 7. Security Considerations........................................14 68 8. Acknowledgement................................................15 69 9. References.....................................................15 70 10. Authors' Addresses............................................16 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 supporting resource 78 reservation and define reporting formats for the benchmarking 79 measurements. 81 4. Introduction 83 The IntServ over DiffServ framework [1] outlines a heterogeneous 84 Quality of Service (QoS) architecture for multi domain Internet 85 services. Signaling based resource reservation (e.g. via RSVP [2]) is 86 an integral part of that model. While this approach significantly 87 lightens the load on most of the core routers, the performance of 88 border routers that handle QoS signaling is still crucial. Therefore 89 network operators, who are planning to deploy this model, shall 90 scrutinize the scalability limitations of reservation capable routers 91 and the impact of signaling on the forwarding performance of the 92 routers. 94 An objective way for quantifying the scalability constraints of QoS 95 signaling is to perform measurements on routers that are capable of 96 resource reservation. This document defines terminology for specific 97 set of tests that vendors or network operators can use to measure and 98 report the signaling performance characteristics of router devices 99 that support resource reservation protocols. The results of these 100 tests provide comparable data for different products supporting the 101 decision process before purchase. Moreover, these measurements 102 provide input characteristics for the dimensioning of a network in 103 which resources are provisioned dynamically by signaling. Finally, 104 the tests are applicable for characterizing the impact of the 105 resource reservation signaling on the forwarding performance of the 106 routers. 108 This benchmarking terminology document is based on the knowledge 109 gained by examination of (and experimentation with) several very 110 different resource reservation protocols: RSVP [2], Boomerang [5], 111 YESSIR [6], ST2+ [7], SDP [8] and Ticket [9]. Nevertheless, this 112 document defines terms that are valid in general and not restricted 113 to these protocols. 115 5. Existing definitions 117 RFC 1242 [3] "Benchmarking Terminology for Network Interconnect 118 Devices" and RFC 2285 [4] "Benchmarking Terminology for LAN Switching 119 Devices" contains discussions and definitions for a number of terms 120 relevant to the benchmarking of signaling performance of reservation 121 capable routers and should be consulted before attempting to make use 122 of this document. 124 For the sake of clarity and continuity this document adopts the 125 template for definitions set out in Section 2 of RFC 1242. 126 Definitions are indexed and grouped together into different sections 127 for ease of reference. 129 6. Definition of Terms 131 6.1 Resource Reservation Protocol Basics 133 This group of definitions applies to various signaling based resource 134 reservation protocols implemented on IP router devices. 136 6.1.1 Unicast Resource Reservation Session 138 Definition: 139 The term unicast resource reservation session (or shortly 140 reservation session) expresses that two end-nodes explicitly 141 request the network nodes, which forward their data flow, to 142 assign special QoS treatment for data packets belonging to the 143 flow. 145 Discussion: 146 The QoS treatment is defined by specifying the amount of 147 networking resources that should be dedicated to the data flow 148 during the length of the reservation session. There are different 149 approaches, how to specify the network resource requirement of a 150 data flow. It can be described by high-level parameters, like the 151 required bandwidth or the maximum data delay; or it can be low- 152 level information, such as the parameters of a leaky-bucket model 153 describing the data flow [10]. 155 Reservation sessions must be uniquely registered in network nodes 156 assuring the QoS treatments. Practically, the transport address of 157 the destination end-node and the transport protocol of the 158 communication are sufficient to distinguish the reservations, 159 however in extreme cases the transport address of the source 160 should be included as well. 162 See Also: 163 Reservation Session State 165 6.1.2 Multicast Resource Reservation Session 167 Definition: 168 A multicast resource reservation session (or, in short, multicast 169 reservation session) denotes that end-nodes forming a multicast 170 group ask the network nodes, which forward the data packets of the 171 multicast group, to assign a certain QoS treatment to their data 172 traffic. 174 Discussion: 175 In a multicast group there can be several data traffic sources and 176 destinations. The required QoS treatment is specified the same way 177 as in the case of the unicast resource reservation sessions. In 178 the case of multicast reservations, however, unlike in the case of 179 unicast reservations, the amount of reserved network resources 180 does not have to be the same on each network node forwarding the 181 multicast data traffic. Multicast reservations must be registered 182 in network nodes forwarding the associated data traffic similarly 183 as it happens in the unicast case. 185 Generally, there are two types of multicast resource reservations: 186 many-to-many and one-to-many. Those of the first type allow 187 multicast data traffic to be originated from several sources, 188 while those of the second type permit only one fix data traffic 189 source in the whole multicast group that must not change during 190 the lifetime of the session. 192 6.1.3 Resource Reservation Capable Router 194 Definition: 195 A router is resource reservation capable -- supports resource 196 reservation -- if it understands a resource reservation protocol 197 that signals the set-up, tear-down and modification of resource 198 reservation sessions. 200 Discussion: 201 Resource reservation protocols define signaling messages that are 202 interpreted by resource reservation capable routers. The router 203 captures the signaling message and manipulates the resource 204 reservation sessions and/or the reserved network resources 205 according to the content of the message. 207 Issues: 208 Despite that resource reservation sessions are considered to be 209 unique, resource reservation capable routers might aggregate them 210 and allocate network resources to these aggregated sessions at 211 once. The aggregation can be based on similar flow attributes 212 (e.g. aggregation using DiffServ code-points [11]) or it can 213 combine arbitrary sessions as well. While reservation aggregation 214 significantly lightens the signaling processing task of a resource 215 reservation capable router, it also requires the administration of 216 the aggregated flows and might also lead to the violation of the 217 quality guaranties of individual reservations within an 218 aggregation. 220 6.1.4 Signaling End-point 222 Definition: 223 A signaling end-point is a network node capable of initiating and 224 terminating resource reservation sessions. 226 Discussion: 227 Besides traditional end-systems, there is also another type of 228 signaling end-point: the reservation gateways. Reservation 229 gateways translate the signaling messages of one resource 230 reservation protocol into messages of another resource reservation 231 protocol. Thus the reservation gateway represents two signaling 232 end-points in one, as it is both a signaling terminator and a 233 signaling initiator. 235 Issues: 236 Typically, signaling end-points have a dedicated protocol stack, 237 which interprets and generates the signaling messages. However, in 238 some special cases, the resource reservation initiation is carried 239 out without the notice of the signaling terminating node. For 240 example, the Boomerang resource reservation protocol encapsulates 241 the reservation requests in an ICMP Echo message. This message is 242 bounced back from the signaling terminating network node ("Far-End 243 Node") and as a result the node becomes a signaling end-point 244 without understanding the reservation protocol. 246 6.1.5 Reservation Orientation 248 Definition: 249 The reservation orientation tells which signaling end-point(s) 250 initiates the network resources allocation to obtain special QoS 251 treatment for the data traffic of the reservation session. 253 Discussion: 254 Resource reservation protocols can be classified into two groups 255 depending on the relationship between the reservation initiators 256 and their role in the data traffic flow. First, there are sender- 257 oriented protocols, where the source(s) of the reservation 258 session�s data traffic initiates the network resource allocation 259 message. Second, in the case of the receiver-oriented protocols, 260 the receiver(s) of the reservation session�s data traffic 261 initiates the resource allocation messages. Due to the asymmetric 262 routing nature of the Internet, in the latter case, the 263 receiver(s) should know the route(s) of the desired data traffic 264 before it would be able to send the resource allocation 265 message(s). For this reason, even in the second case, the first 266 signaling message(s) establishing the reservation session comes 267 from the source(s) of the data traffic marking the route(s) on 268 which the resource allocation message(s) might travel backward. 270 Issues: 271 The orientation of the reservation initiator affects the basics of 272 the resource reservation protocols and therefore it is an 273 important design decision. In the case of multicast reservation 274 sessions, the sender-oriented protocols require the traffic 275 sources to maintain a list of receivers and send their allocation 276 messages considering the requirements of the receivers. A less 277 polite, but less demanding solution is when the sources ignore the 278 QoS requirements of the receivers and send the allocation requests 279 at will. Using multicast reservation sessions, the receiver- 280 oriented protocols give the chance to the receivers to place their 281 own resource allocation requests and thus ease the task of the 282 sources. However, in this case the resource allocations must be 283 preceded by the marking of the data routes of the reservation 284 session (c.f. RSVP PATH message [2]). In case of large multicast 285 groups, enabling the receivers to specify their QoS requirements, 286 the receiver-oriented approach seems to be a better choice, 287 however in other cases the sender-oriented protocols promise less 288 complexity. 290 6.1.6 Reservation Session State 292 Definition: 293 A reservation session state is a holder for all the relevant 294 information about the corresponding reservation session registered 295 in the resource reservation capable router. 297 Discussion: 298 Resource reservation capable routers maintain reservation session 299 states to store information about the reservation session. This 300 information might include the QoS treatment that the reservation 301 session requires; the description of how and where to forward the 302 incoming signaling messages; policies regarding the QoS treatment 303 or the reservation session; timing information about the 304 reservation session; etc. 306 Based on how reservation session states are stored in a 307 reservation capable router, the routers can be categorized into 308 three classes: 310 Hard-state resource reservation capable routers (e.g. ST2 capable 311 routers [7]) store the reservation session states permanently, 312 established by a set-up signaling primitive, until a corresponding 313 tear-down signaling primitive arrives or until the router is 314 informed that the reservation session canceled. 316 There are also soft-state resource reservation capable routers, 317 where there are no permanent reservation session states, but each 318 state have to be regularly refreshed by appropriate refresh 319 signaling messages. If no refresh signaling message arrives during 320 a certain period then the router cancels the reservation session 321 assuming that the signaling end-points do not intend to keep up 322 the reservation session any longer or the communication lines are 323 broken somewhere along the data path. This feature makes soft- 324 state resource reservation capable routers more robust than hard- 325 state routers, since no failures can cause permanent resource 326 stuck in the routers. 328 Finally, there are stateless resource reservation capable routers 329 storing no information about the individual reservation sessions. 330 Without reservation session states the resource reservation 331 capabilities of such routers are limited, e.g. there is no support 332 for many-to-many multicast resource reservation sessions; and the 333 reservation session must be sender oriented. 335 Issues: 336 Although soft-state reservation capable routers are more robust 337 than hard-state ones, the frequent processing of refresh signaling 338 messages or the detection of the missing reservation session state 339 refreshes might cause serious increase in the router load, which 340 can be a base of the scalability problems. In order to decrease 341 the number of refresh signaling messages, the resource reservation 342 capable router might support various mechanisms to pack several 343 refresh signaling messages into one larger message. 345 6.1.7 Signaling Path 347 Definition: 348 A signaling path is a sequence of network nodes and links along 349 which signaling messages travel from one signaling end-point to 350 the other. 352 Discussion: 353 Resource reservation capable routers must assure that all other 354 router, which is responsible for handling the actual signaling 355 message, really receives that message. Therefore, routers forward 356 the signaling messages along the signaling path and each router, 357 affected by the message, processes it. 359 Usually signaling messages are immediately forwarded by resource 360 reservation capable routers towards the destination(s), spreading 361 the information as fast as possible. However, there might be 362 protocol messages that do not affect all the routers along the 363 signaling path, but only a subset of it (e.g. refresh messages in 364 RSVP). These kinds of signaling messages are terminated by routers 365 when they are not necessary anymore. 367 Issues: 368 Resource reservation capable routers must be prepared that there 369 are other routers along the signaling path unable to interpret the 370 actual resource reservation protocol. Even in this case the 371 signaling messages must be delivered to all corresponding resource 372 reservation capable routers (usually using some kind of 373 tunneling). 375 6.2 Traffic Types 377 This group of definitions defines traffic types forwarded by resource 378 reservation capable routers. 380 6.2.1 Best-Effort Data Packets 382 Definition: 383 Best-effort data packet is a packet that has no associated 384 resource reservation session in the routers and thus it is served 385 in the "default" way. 387 Discussion: 388 Data packets that do not require QoS guarantees along their path 389 are considered to be best-effort packets. "Best-effort" means that 390 the router makes its best effort to forward the data packet 391 quickly and safely, but does not guarantee anything (e.g. delay or 392 loss probability). This type of traffic is the most common type in 393 today's Internet. (There may be scenarios where resource 394 reservation is done even for best-effort traffic too, but those 395 are outside of the focus of this memo.) We will refer to the 396 traffic of the best-effort data packets shortly as best-effort 397 traffic. 399 6.2.2 Premium Data Packets 401 Definition: 402 Premium data packets are the packets that the resource reservation 403 capable router distinguishes from best-effort packets and forwards 404 them according to a QoS agreement. 406 Discussion: 407 Data packets that correspond to a resource reservation session in 408 the router are premium data packets. The QoS treatment is defined 409 in the associated resource reservation state (e.g. flow 410 descriptor) that is established by signaling messages during the 411 reservation session setup. 413 The router may distinguish several types of premium. Data packets 414 belonging to different types of premium traffic may receive 415 different QoS treatment. We will refer to the traffic of the 416 premium data packets shortly as premium traffic. 418 Issues: 419 The router has to identify every packet whether it belongs to any 420 resource reservation session or not. This can be done by either 421 multi-field classification [11] using the IP 5-tuple or the ToS 422 field in the header of the IP packet. However, if a packet has an 423 associated resource reservation session in the router, then the 424 corresponding resource reservation states describing the QoS 425 treatment has to be looked up. This look up procedure might be 426 quite time consuming in routers with vast amounts of resource 427 reservation sessions. 429 6.3 Router Load Types 431 This group of definitions describes different load component types 432 that impact only a specific part of the resource reservation capable 433 router. Categorizing the router load is crucial, since the 434 conventional router load metric expressing the processing power 435 utilization of the router does not characterize precisely enough a 436 the resource reservation capable router. In the case of routers 437 supporting resource reservations it is also important to know the 438 source of the processing power utilization. 440 6.3.1 Traffic Load 442 Definition: 443 Usually traffic load means the load that is raised by the data 444 traffic forwarding task of the router. However, we define the 445 traffic load as the volume of the input data traffic that causes 446 the router to be loaded. 448 Discussion: 449 It is obvious that forwarding the data packets, which requires 450 obtaining the routing information and transferring the data packet 451 between network interfaces, requires processing power. In general 452 router benchmarking measurements only this type of load is 453 considered as the source of the processing power utilization. 454 Although the traffic load is the dominant load component, 455 benchmarking routers supporting resource reservations must 456 consider other load components also in line with the resource 457 reservation handling. 459 Measurement unit: 460 The amount of the traffic load is represented by the volume of the 461 data traffic. The volume is measured by the transferred bits 462 during a second, i.e. the measurement unit is bit per seconds 463 (bps). 465 6.3.2 Session Load 467 Definition: 468 Similar to the traffic load, we define the session load as the 469 number of reservation sessions in the router. 471 Discussion: 472 Each resource reservation capable router that employs a packet 473 classifier algorithm distinguishing the flows referring to 474 reservation sessions maintains resource reservation session states 475 keeping track of the resource reservation dedication. Obviously, 476 the more reservation session states are set up on the router, the 477 more complex the traffic classification becomes, and the longer 478 time it takes to look up the corresponding resource reservation 479 session sate. 481 Moreover, in most protocols, not only the traffic flows, but also 482 the signaling messages that manipulate resource reservation 483 sessions on the router have to identify themselves first, before 484 taking any other actions. This kind of classification also gives 485 extra work to the router. 487 Issues: 488 In the case of soft-state resource reservation capable routers, 489 the session load also affects reservation session maintenance. The 490 maintenance of timers that watchdog the reservation session 491 refreshes and the refresh signaling messages may cause severe load 492 on the router. Based on the initiating point of the refresh 493 messages, resource reservation protocols can be divided into two 494 groups. First, there are protocols where it is the responsibility 495 of the signaling end-points to initiate refresh messages and these 496 messages are forwarded along the whole signaling path refreshing 497 the corresponding resource reservation session. Second, there are 498 other protocols, where the reservation session refresh happens 499 only between the two peering network nodes of the signaling path. 500 In this latter case, the routers and signaling end-points have 501 their own schedule for the refresh message initiation. The first 502 approach lightens the load of the session maintenance task; 503 however, the second approach bears the ability to adjust the 504 signaling intensity along the signaling path. 506 Measurement unit: 507 The session load is measured by the number of reservation sessions 508 in the router. 510 6.3.3 Signaling Load 512 Definition: 513 Similarly to the previous load types, the signaling load is 514 determined by the incoming signaling message intensity. 516 Discussion: 517 The processing of signaling messages requires processor power that 518 raises the load on the control plane of the router. In routers 519 where the control plane and the data plane are not totally 520 independent (e.g. certain parts of the tasks are served by the 521 same processor; or the architecture has common memory buffers or 522 transfer buses) the signaling load can have an impact on the 523 router's packet forwarding performance as well. 525 Most of the resource reservation protocols have several protocol 526 primitives realized by different signaling message types. Each of 527 these message types may require a different amount of processing 528 power from the router. 530 Measurement unit: 531 The signaling load is characterized by the signaling intensity, 532 which expresses how many signaling messages arrive to the router 533 within a second. Thus the unit of the signaling intensity is 534 [1/s]. 536 6.3.4 Signaling Burst 538 Definition: 539 The signaling burst denotes a certain number of signaling messages 540 that arrive to the input port(s) of the router back-to-back, 541 causing persistent load on the signaling message handler. 543 Discussion: 544 Back-to-back signaling messages on one port of the router form a 545 typical signaling burst. However, other cases are imaginable, for 546 example when signaling messages arrive on different ports 547 simultaneously or with an overlap in time (i.e. when the tail of 548 one signaling message is behind the head of another one arriving 549 on another port). 551 Measurement unit: 552 The signaling burst is characterized by its length, which is the 553 number of messages that have arrived within the burst. 555 6.4 Performance Metrics 557 This group of definitions is the collection of the measurable impacts 558 that a resource reservation protocol has over the tested router 559 device it is running on. 561 6.4.1 Signaling Message Handling Time 563 Definition: 564 The signaling message handling time (or, in short, signal handling 565 time) is the time that a signaling message spends inside the 566 router before it is forwarded to the next node on the signaling 567 path. 569 Discussion: 570 Depending on the type of the signaling message, the router also 571 interprets the signaling messages, acts on them and usually 572 forwards a modified signaling message. Thus the message handling 573 time is usually longer than forwarding time of data packets of the 574 same size. In addition, there might be also signaling message 575 primitives that are drained or generated by the router. Thus, the 576 signal handling time is defined as the time difference between the 577 time when a signaling message is received and the time the 578 corresponding processed signaling message is transmitted. If a 579 signaling message is not forwarded on the router (see Signaling 580 Path), the signal handling time is immeasurable; therefore it is 581 not defined for such messages. 583 In the case of signaling messages that carry information 584 pertaining to multicast flows, the router might issue multiple 585 signaling messages after processing. In this case, by definition, 586 the signal handling time is the time interval elapsed between the 587 arrival of the incoming signaling message and the departure of the 588 last signaling message related to the received one. 590 This metric depends on the load on the router, as other tasks may 591 limit the processing power available to signaling message 592 handling. In addition to the router load, the signal handling time 593 may also be dependent on the type of the signaling message. For 594 example, it usually takes a shorter time for the router to tear 595 down a resource reservation session than to set it up. 597 The signal handling time is an important characteristic as it 598 directly affects the setup time of a session. 600 Measurement unit: 601 The unit of the signaling message handling time is the second. 603 6.4.2 Premium Traffic Delay 605 Definition: 606 Premium traffic delay is the forwarding time of a premium data 607 packet passing through a resource reservation capable router. 609 Discussion: 610 Premium traffic packets must be classified first in order to 611 assign the network resources dedicated to the flow. The time of 612 the classification is added to the usual forwarding time 613 (including the queuing) that a router would spend on the packet 614 without any resource reservation capability. 616 There are routers where the processing power is shared between the 617 control plane and the data plane. This means that the processing 618 of signaling messages may have an impact on the data forwarding 619 performance of the router. In this case the premium traffic delay 620 metric reflects the influence the two planes have on each other. 622 Measurement unit: 623 The unit of the premium traffic delay is the second. 625 6.4.3 Best-effort Traffic Delay 627 Definition: 628 Best-effort traffic delay is the forwarding time of a best-effort 629 packet passing through a resource reservation capable router. 631 Discussion: 632 Marking the premium traffic packets also marks the best-effort 633 traffic packets via the lack of marking. In this case the 634 detection of the best-effort packets is straightforward, so the 635 classification algorithms do not have any influence on the best- 636 effort traffic. However, the processing power sharing between the 637 control and data plane might still cause delays in the forwarding 638 procedure of each packet. 640 Measurement unit: 641 The unit of the best-effort traffic delay is the second. 643 6.4.4 Signaling Message Loss 645 Definition: 646 Signaling message loss is the ratio of the actual and the expected 647 number of signaling messages leaving a resource reservation 648 capable router subtracted from one. 650 Discussion: 651 There are certain types of signaling messages required to be 652 forwarded by the resource reservation capable router immediately 653 when their processing is finished. However, due to the high router 654 load or for other reasons, the forwarding or even the processing 655 of these signaling messages might be canceled. To characterize 656 such situations we introduce the signaling message loss metric 657 expressing the ratio of the signaling messages that actually have 658 left the router and those ones that were expected to leave the 659 router as a result of the incoming sequence of signaling messages. 661 Since the most frequent reason for the signaling message loss is 662 the high router load, therefore this metric is suitable for 663 sounding out the scalability limits of resource reservation 664 capable routers. 666 Issues: 667 Sometimes it may be hard to determine whether a signaling message 668 is still in the queues of the router or whether it has already 669 been dropped. For this reason we define that a signaling message 670 is lost if there is no appearing forwarded signaling message 671 within a reasonable long time period. This time period should be 672 adjusted to the actual resource reservation protocol and might 673 also depend on the type of the message, too. For example, in the 674 case of soft-state resource reservation capable routers the 675 measurer may wait as much as the refresh period to detect the loss 676 of a signaling message. 678 Measurement unit: 679 This measure has no unit; it is expressed by a real number, which 680 is between zero and one (including the limits). 682 6.4.5 Session Refreshing Capacity 684 Definition: 685 The session refreshing capacity metric is applied for soft-state 686 resource reservation capable routers only and tells the ratio of 687 the truly refreshed reservation sessions and the number of 688 sessions that should be refreshed during one refresh period. 690 Discussion: 691 When a soft-state resource reservation capable router is 692 overloaded, it may happen that the router is not able to refresh 693 all the registered reservation sessions having no time to run the 694 session refresh task. In this case sooner or later the resource 695 reservation sessions over the session refresh capacity are dropped 696 even if the resource reservation end-points are still refreshing 697 them. 699 The session refreshing capacity sounds out the limit of the 700 resource reservation session number that the router is capable to 701 maintain. 703 Measurement unit: 704 This measure has no unit; it is expressed by a real number, which 705 is between zero and one (including the limits). 707 6.4.6 Scalability Limit 709 Definition: 710 The scalability limit is the threshold between the steady state 711 and the overloaded state of the device under test. 713 Discussion: 714 All existing routers have finite buffer memory and finite 715 processing power. In the steady state of the router, the buffer 716 memories are not fully utilized and the processing power is enough 717 to cope with all tasks running on the router. As the router load 718 increases the router has to postpone more and more tasks. These 719 tasks (e.g. forwarding certain packets) are queued in the buffers, 720 and processed later. However, there is a certain point where no 721 more buffer memory is available or a task cannot be postponed any 722 longer; thus, the router is forced to drop the packet or the 723 activity. This way the overloaded state of the resource 724 reservation capable router can be recognized by the fact that some 725 kind of data (signaling or packet) or task (e.g. refreshing) loss 726 occurs. 728 The critical load condition when the router is still in the steady 729 state but the smallest amount of constant load increase would 730 drive it to the overloaded state is the scalability limit of the 731 router. 733 7. Security Considerations 735 As this document is solely for providing terminology and describes 736 neither a protocol nor an implementation, there are no security 737 considerations associated with this document. 739 8. Acknowledgement 741 We would like to thank the following individuals for their help in 742 forming this document: Joakim Bergkvist and Norbert Vegh from Telia 743 Research AB, Sweden, Krisztian Nemeth, Balazs Szabo, Gabor Kovacs and 744 Peter Vary from the High Speed Networks Laboratory, Budapest 745 University of Technology and Economics, Hungary. 747 9. References 749 [1] Y. Bernet, et. al., "A Framework for Integrated Services 750 Operation over Diffserv Networks", RFC 2998, November 2000 752 [2] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) - 753 Version 1 Functional Specification", RFC 2205, September 1997. 755 [3] S. Bradner, "Benchmarking Terminology for Network 756 Interconnection Devices", RFC 1242, July 1991 758 [4] R. Mandeville, "Benchmarking Terminology for LAN Switching 759 Devices", RFC 2285, February 1998 761 [5] G. Feher, K. Nemeth, M. Maliosz, "Boomerang : A Simple Protocol 762 for Resource Reservation in IP Networks," Vancouver, IEEE Real- 763 Time Technology and Applications Symposium, June 1999 765 [6] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism 766 for the Internet", Computer Communication Review, on-line 767 version, volume 29, number 2, April 1999 769 [7] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 770 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 771 1995 773 [8] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated 774 Reservation in the Internet", Journal on High Speed Networks, 775 Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998 777 [9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight 778 Resource Reservation for Unicast IP Traffic", International WS 779 on QoS'98, IWQoS'98, May 18-20, 1998 781 [10] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", 782 RFC 2210, September 1997 784 [11] K. Nichols et al., "Definition of the Differentiated Services 785 Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474 787 [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 788 Specification", RFC 2460, December 1998 790 [13] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, 791 September 1981 792 10. Authors' Addresses 794 Gabor Feher 795 Budapest University of Technology and Economics (BUTE) 796 Department of Telecommunications and Telematics 797 Magyar Tudosok krt. 2, H-1117, Budapest, Hungary 798 Phone: +36 1 463-1538 799 Email: feher@ttt-atm.ttt.bme.hu 801 Istvan Cselenyi 802 Telia Research AB 803 Vitsandsgatan 9B 804 SE 12386, Farsta 805 SWEDEN, 806 Phone: +46 8 713-8173 807 Email: istvan.i.cselenyi@telia.se 809 Andras Korn 810 Budapest University of Technology and Economics (BUTE) 811 Institute of Mathematics, Department of Analysis 812 Egry Jozsef u. 2, H-1111 Budapest, Hungary 813 Phone: +36 1 463-2475 814 Email: korn@math.bme.hu