idnits 2.17.1 draft-ietf-bmwg-benchres-term-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 33. -- Found old boilerplate from RFC 3978, Section 5.5 on line 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 842. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 848. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 2005) is 7035 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) ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '2') Summary: 8 errors (**), 0 flaws (~~), 2 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: July 2005 Andras Korn, BUTE 5 Istvan Cselenyi, TeliaSonera 7 January 2005 9 Benchmarking Terminology for Routers Supporting Resource Reservation 10 12 Status of this Memo 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 By submitting this Internet-Draft, I certify that any applicable 31 patent or other IPR claims of which I am aware have been disclosed, 32 or will be disclosed, and any of which I become aware will be 33 disclosed, in accordance with RFC 3668. 35 Table of contents 37 Abstract...........................................................2 38 1. Introduction....................................................3 39 2. Existing definitions............................................3 40 3. Definition of Terms.............................................4 41 3.1 Traffic Flow Types..........................................4 42 3.1.1 Data Flow..............................................4 43 3.1.2 Distinguished Data Flow................................4 44 3.1.3 Best-Effort Data Flow..................................5 45 3.2 Resource Reservation Protocol Basics........................5 46 3.2.1 QoS Session............................................5 47 3.2.2 Resource Reservation Protocol..........................6 48 3.2.3 Resource Reservation Capable Router....................7 49 3.2.4 Reservation State......................................7 50 3.2.5 Resource Reservation Protocol Orientation..............8 51 3.3 Router Load Factors.........................................9 52 3.3.1 Best-Effort Traffic Load Factor........................9 53 3.3.2 Distinguished Traffic Load Factor......................9 54 3.3.3 Session Load Factor...................................10 55 3.3.4 Signaling Intensity Load Factor.......................10 56 3.3.5 Signaling Burst Load Factor...........................11 57 3.4 Performance Metrics........................................11 58 3.4.1 Signaling Message Handling Time.......................11 59 3.4.2 Distinguished Traffic Delay...........................12 60 3.4.3 Best-effort Traffic Delay.............................13 61 3.4.4 Signaling Message Loss................................13 62 3.4.5 Session Maintenance Capacity..........................14 63 3.5 Scalability Limit..........................................15 64 4. Security Considerations........................................16 65 5. IANA Considerations............................................16 66 6. Acknowledgements...............................................16 67 7. References.....................................................16 68 7.1 Normative References.......................................16 69 7.2 Informative References.....................................16 70 Authors' Addresses................................................17 71 Disclaimer of Validity............................................17 72 Copyright Notice..................................................18 73 Disclaimer........................................................18 75 Abstract 76 The purpose of this document is to define terminology specific to 77 the benchmarking of resource reservation signaling of Integrated 78 Services IP routers. These terms can be used in additional documents 79 that define benchmarking methodologies for routers that support 80 resource reservation or reporting formats for the benchmarking 81 measurements. 83 1. Introduction 85 Signaling based resource reservation (e.g. via RSVP [3]) is an 86 important part of the different QoS provisioning approaches. 87 Therefore network operators who are planning to deploy signaling 88 based resource reservation may want to scrutinize the scalability 89 limitations of reservation capable routers and the impact of 90 signaling on their data forwarding performance. 92 An objective way of quantifying the scalability constraints of QoS 93 signaling is to perform measurements on routers that are capable of 94 resource reservation. This document defines terminology for a 95 specific set of tests that vendors or network operators can carry 96 out to measure and report the signaling performance characteristics 97 of router devices that support resource reservation protocols. The 98 results of these tests provide comparable data for different 99 products, and thus support the decision process before purchase. 100 Moreover, these measurements provide input characteristics for the 101 dimensioning of a network in which resources are provisioned 102 dynamically by signaling. Finally, the tests are applicable for 103 characterizing the impact of the resource reservation signaling on 104 the forwarding performance of the routers. 106 This benchmarking terminology document is based on the knowledge 107 gained by examination of (and experimentation with) different 108 resource reservation protocols: the IETF standard RSVP [3] and 109 several experimental ones, such as YESSIR [5], ST2+ [6], SDP [7], 110 Boomerang [8] and Ticket [9]. Some of these protocols are also 111 analyzed in an IETF NSIS working group draft [10]. Although at the 112 moment the authors are only aware of resource reservation capable 113 router products that interpret RSVP, this document defines terms 114 that are valid in general and not restricted to any of the above 115 listed protocols. 117 In order to avoid any confusion we would like to emphasize that this 118 terminology considers only signaling protocols that provide IntServ 119 resource reservation; the DiffServ world, for example, is out of our 120 scope. 122 2. Existing definitions 124 RFC 1242 "Benchmarking Terminology for Network Interconnect 125 Devices" [1] and RFC 2285 "Benchmarking Terminology for LAN 126 Switching Devices" [2] contain discussions and definitions for a 127 number of terms relevant to the benchmarking of signaling 128 performance of reservation capable routers and should be consulted 129 before attempting to make use of this document. 131 Additionally, this document defines terminology in a way that is 132 consistent with the terms used by Next Steps in Signaling working 133 group laid out in [4]. 135 For the sake of clarity and continuity this document adopts the 136 template for definitions set out in Section 2 of RFC 1242. 137 Definitions are indexed and grouped together into different sections 138 for ease of reference. 140 3. Definition of Terms 142 3.1 Traffic Flow Types 144 This group of definitions describes traffic flow types forwarded by 145 resource reservation capable routers. 147 3.1.1 Data Flow 149 Definition: 150 A data flow is a stream of data packets from one sender to one or 151 more receivers, where each packet has a flow identifier unique to 152 the flow. 154 Discussion: 155 The flow identifier can be an arbitrary subset of the packet 156 header fields that uniquely distinguishes the flow from others. 157 For example, the 5-tuple "source address; source port; destination 158 address; destination port; protocol number" is commonly used for 159 this purpose (where port number are applicable). It is also 160 possible to take advantage of the Flow Label field of IPv6 161 packets. For more comment on flow identification refer to [4]. 163 The flow identification can be time- and/or resource-consuming, 164 but this can sometimes be avoided as routers do not necessarily 165 have to classify each packet. Instead, packets that should be 166 classified by routers can be marked with special flags that 167 routers understand. One existing marking approach is to use the 168 Type of Service (IPv4)/Traffic Class (IPv6) field of the IP 169 header. Naturally, unmarked packets are not classified by routers 170 and this way valuable resources can be saved. 172 3.1.2 Distinguished Data Flow 174 Definition: 175 Distinguished data flows are flows that resource reservation 176 capable routers intentionally treat better or worse than 177 "ordinary" data flows, according to a QoS agreement defined for 178 the distinguished flow. 180 Discussion: 181 Packets of distinguished data flows are marked so that the routers 182 that forward them know they require differentiated treatment. 183 Routers classify these incoming packets and identify the data flow 184 they belong to. 186 The most common usage of the distinguished data flow is to get 187 higher priority treatment than that of best-effort data flows (see 188 the next definition). In these cases, a distinguished data flow is 189 sometimes referred to as a "premium data flow". Nevertheless 190 theoretically it is possible to require worse treatment than that 191 of best-effort flows. 193 3.1.3 Best-Effort Data Flow 195 Definition: 196 Best-effort data flows are flows that are not treated in any 197 special manner by resource reservation capable routers; thus, 198 their packets are served (forwarded) in some default way. 200 Discussion: 201 "Best-effort" means that the router makes its best effort to 202 forward the data packet quickly and safely, but does not guarantee 203 anything (e.g. delay or loss probability). This type of traffic is 204 the most common in today's Internet. 206 The packets belonging to the best-effort data flows are not 207 specially marked and thus they are not classified by the routers. 209 3.2 Resource Reservation Protocol Basics 211 This group of definitions applies to signaling based resource 212 reservation protocols implemented by IP router devices. 214 3.2.1 QoS Session 216 Definition: 217 A QoS session is an application layer concept, shared between a 218 set of network nodes, that pertains to a specific set of data 219 flows. The information associated with the session includes the 220 data required to identify the set of data flows in addition to a 221 specification of the QoS treatment they require. 223 Discussion: 224 A QoS session is an end-to-end relationship. Whenever end-nodes 225 decide to obtain special QoS treatment for their data 226 communication, they set up a QoS session; as part of the process, 227 they or their proxies make a QoS agreement with the network, 228 specifying their data flows and the QoS treatment that the flows 229 require. 231 It is possible for the same QoS session to span multiple network 232 domains that have different resource provisioning architectures. 233 In this document, however, we only deal with the case where the 234 QoS session is realized over an IntServ architecture. It is 235 assumed that sessions will be established using signaling messages 236 of a resource reservation protocol. 238 QoS sessions must have unique identifiers; it must be possible to 239 determine which QoS session a given signaling message pertains to. 240 Therefore, each signaling message should include the identifier of 241 its corresponding session. As an example, in the case of RSVP, the 242 "session specification" identifies the QoS session plus refers to 243 the data flow; the "flowspec" specifies the desired QoS treatment 244 and the "filter spec" defines the subset of data packets in the 245 data flow that receive the QoS defined by the flowspec. 247 QoS sessions can be unicast or multicast depending on the number 248 of participants. In a multicast group there can be several data 249 traffic sources and destinations. Here the QoS agreement does not 250 have to be the same for each branch of the multicast tree 251 forwarding the data flow of the group. Instead, a dedicated 252 network resource in a router can be shared among many traffic 253 sources from the same multicast group (c.f. multicast reservation 254 styles in the case of RSVP). 256 Issues: 257 Even though QoS sessions are considered to be unique, resource 258 reservation capable routers might aggregate them and allocate 259 network resources to these aggregated sessions at once. The 260 aggregation can be based on similar data flow attributes (e.g. 261 similar destination addresses) or it can combine arbitrary 262 sessions as well. While reservation aggregation significantly 263 lightens the signaling processing task of a resource reservation 264 capable router, it also requires the administration of the 265 aggregated QoS sessions and might also lead to the violation of 266 the quality guaranties referring to individual data flows within 267 an aggregation [11]. 269 3.2.2 Resource Reservation Protocol 271 Definition: 272 Resource reservation protocols define signaling messages and 273 message processing rules used to control resource allocation in 274 IntServ architectures. 276 Discussion: 277 It is the signaling messages of a resource reservation protocol 278 that carry the information related to QoS sessions. This 279 information includes a session identifier, the actual QoS 280 parameters, and possibly flow descriptors. 282 The message processing rules of the signaling protocols ensure 283 that signaling messages reach all network nodes concerned. Some 284 resource reservation protocols (e.g. RSVP) are only concerned with 285 this, i.e. carrying the QoS-related information to all the 286 appropriate network nodes, without being aware of its content. 287 This latter approach allows changing the way the QoS parameters 288 are described, and different kind of provisioning can be realized 289 without the need to change the protocol itself. 291 3.2.3 Resource Reservation Capable Router 293 Definition: 294 A router is resource reservation capable (it supports resource 295 reservation) if it is able to interpret signaling messages of a 296 resource reservation protocol, and based on these messages is able 297 to adjust the management of its flow classifiers and network 298 resources so as to conform with the content of the messages. 300 Discussion: 301 Routers capture signaling messages and manipulate reservation 302 states and/or reserved network resources according to the content 303 of the messages. This ensures that the flows are treated as their 304 specified QoS requirements indicate. 306 3.2.4 Reservation State 308 Definition: 309 A reservation state is the set of entries in the router's memory 310 that contain all relevant information about a given QoS session 311 registered with the router. 313 Discussion: 314 States are needed because IntServ related resource reservation 315 protocols require the routers to keep track of QoS session and 316 data-flow-related metadata. The reservation state includes the 317 parameters of the QoS treatment; the description of how and where 318 to forward the incoming signaling messages; refresh timing 319 information; etc. 321 Based on how reservation states are stored in a reservation 322 capable router, the routers can be categorized into two classes: 324 Hard-state resource reservation protocols (e.g. ST2 [6]) require 325 routers to store the reservation states permanently, established 326 by a set-up signaling primitive, until the router is explicitly 327 informed that the QoS session is canceled. 329 There are also soft-state resource reservation capable routers, 330 where there are no permanent reservation states, and each state 331 has to be regularly refreshed by appropriate refresh signaling 332 messages. If no refresh signaling message arrives during a certain 333 period then the router stops the maintenance of the QoS session 334 assuming that the end-points do not intend to keep the session up 335 any longer or the communication lines are broken somewhere along 336 the data path. This feature makes soft-state resource reservation 337 capable routers more robust than hard-state routers, since no 338 failures can cause resources to stay permanently stuck in the 339 routers. (Note, it is still possible to have an explicit teardown 340 message in soft-state protocols for quicker resource release.) 342 Issues: 343 Based on the initiating point of the refresh messages, soft-state 344 resource reservation protocols can be divided into two groups. 345 First, there are protocols where it is the responsibility of the 346 end-points or their proxies to initiate refresh messages. These 347 messages are forwarded along the path of the data flow refreshing 348 the corresponding reservation states in each router affected by 349 the flow. Secondly, there are other protocols, where routers and 350 end-points have their own schedule for the reservation state 351 refreshes and they signal these refreshes to the neighboring 352 routers. 354 3.2.5 Resource Reservation Protocol Orientation 356 Definition: 357 The orientation of a resource reservation protocol tells which end 358 of the protocol communication initiates the allocation of the 359 network resources. Thus, the protocol can be sender or receiver 360 initiated, depending on the location of the data flow source 361 (sender) and destination (receiver) compared to the reservation 362 initiator. 364 Discussion: 365 In the case of sender-initiated protocols the resource reservation 366 propagates the same directions as of the data flow. Consequently, 367 in the case of receiver-initiated protocols the signaling messages 368 reserving resources are forwarded backward on the path of the data 369 flow. Due to the asymmetric routing nature of the Internet, in 370 this latter case, the path of the desired data flow should be 371 known before the reservation initiator would be able to send the 372 resource allocation messages. For example in the case of RSVP, the 373 RSVP PATH message, traveling from the data flow sources towards 374 the destinations, first marks the path of the data flow on which 375 the resource allocation messages will travel backward. 377 This definition considers only protocols that reserve resources 378 for just one data flow between the end-nodes. The reservation 379 orientation of protocols reserving more than one data flow is not 380 defined here. 382 Issues: 383 The location of the reservation initiator affects the basics of 384 the resource reservation protocols and therefore it is an 385 important design decision. In the case of multicast QoS sessions, 386 the sender-oriented protocols require the traffic sources to 387 maintain a list of receivers and send their allocation messages 388 considering the different requirements of the receivers. Using 389 multicast QoS sessions, the receiver-oriented protocols give the 390 chance to the receivers to manage their own resource allocation 391 requests and thus ease the task of the sources. 393 3.3 Router Load Factors 395 The router load expressing the utilization of the device naturally 396 affects the performance of the router. During the benchmarking 397 process several load conditions have to be examined. 399 This group of definitions describes different load components that 400 impact only a specific part of the resource reservation capable 401 router. 403 3.3.1 Best-Effort Traffic Load Factor 405 Definition: 406 The best-effort traffic load factor is defined as the volume of 407 the best-effort data traffic that traverses the router in a 408 second. 410 Discussion: 411 Forwarding the best-effort data packets, which requires obtaining 412 the routing information and transferring the data packet between 413 network interfaces, requires processing power, which is related to 414 this load factor. 416 Issues: 417 The same amount of data segmented into differently sized packets 418 causes different amounts of load on the router, which has to be 419 considered during the benchmarking measurements. 421 Measurement unit: 422 bits per second (bps) 424 3.3.2 Distinguished Traffic Load Factor 426 Definition: 427 The distinguished traffic load factor is defined as the volume of 428 the distinguished data traffic that traverses the router in a 429 second. 431 Discussion: 432 Similarly to the best-effort data, forwarding the distinguished 433 data packets requires obtaining the routing information and 434 transferring the data packet between network interfaces. However, 435 in this case packets have to be classified as well, which requires 436 additional processing capacity. 438 Issues: 439 Just as in the best-effort case, the same amount of data segmented 440 into differently sized packets causes different amounts of load on 441 the router, which has to be considered during the benchmarking 442 measurements. 444 Measurement unit: 445 bits per second (bps) 447 3.3.3 Session Load Factor 449 Definition: 450 The session load factor is the number of QoS sessions the router 451 is keeping track of. 453 Discussion: 454 Resource reservation capable routers maintain reservation states 455 keeping track of the QoS sessions. Obviously, the more reservation 456 states are registered with the router, the more complex the 457 traffic classification becomes, and the longer time it takes to 458 look up the corresponding resource reservation sate. Moreover, not 459 only the traffic flows, but also the signaling messages that 460 control the reservation states have to be identified first, before 461 taking any other action, and this kind of classification also 462 means extra work for the router. 464 In the case of soft-state resource reservation protocols, the 465 session load also affects reservation state maintenance. For 466 example, the supervision of timers that watchdog the reservation 467 state refreshes may cause further load on the router. 469 Measurement unit: 470 This factor is measured by the number of QoS sessions impacting 471 the router, thus it has no unit. 473 3.3.4 Signaling Intensity Load Factor 475 Definition: 476 The signaling intensity load factor is defined as the number of 477 signaling messages that hit the router during one second. 479 Discussion: 480 The processing of signaling messages requires processor power that 481 raises the load on the control plane of the router. 483 In routers where the control plane and the data plane are not 484 totally independent (e.g. certain parts of the tasks are served by 485 the same processor; or the architecture has common memory buffers, 486 transfer buses or any other resources) the signaling load can have 487 an impact on the router's packet forwarding performance as well. 489 Naturally, just as everywhere else in this document, the term 490 "signaling messages" refer only to the resource reservation 491 protocol related primitives. 493 Issues: 494 Most of the resource reservation protocols have several protocol 495 primitives realized by different signaling message types. Each of 496 these message types may require a different amount of processing 497 power from the router. This fact has to be considered during the 498 benchmarking measurements. 500 Measurement unit: 501 The unit of this factor is 1/second. 503 3.3.5 Signaling Burst Load Factor 505 Definition: 506 The signaling burst load factor is defined as the number of 507 signaling messages that arrive to one input port of the router 508 back-to-back ([1]), causing persistent load on the signaling 509 message handler. 511 Discussion: 512 The definition focuses on one input port only and does not 513 consider the traffic arriving at the other input ports. 514 As a consequence, a set of messages arriving at different ports, 515 but with such a timing that would be a burst if the messages 516 arrived at the same port, is not considered to be a burst. The 517 reason for this is that it is not guaranteed at a black-box test 518 that this would have the same effect on the router as a burst 519 (incoming at the same interface) has. 521 This definition conforms to the burst definition given in [2]. 523 Issues: 524 Most of the resource reservation protocols have several protocol 525 primitives realized by different signaling message types. Bursts 526 built up of different messages may have a different effect on the 527 router. Consequently, during measurements the content of the burst 528 has to be considered as well. 530 Measurement unit: 531 This load factor is measured by the number of messages in the 532 burst, thus it has no unit. 534 3.4 Performance Metrics 536 This group of definitions is a collection of measurable quantities 537 that describe the impact the different load components have on the 538 router. 540 3.4.1 Signaling Message Handling Time 542 Definition: 543 The signaling message handling time (or, in short, signal handling 544 time) is the latency ([1]) of a signaling message passing through 545 the router. 547 Discussion: 548 The router interprets the signaling messages, acts based on their 549 content and usually forwards them in an unmodified or modified 550 form. Thus the message handling time is usually longer than the 551 forwarding time of data packets of the same size. 553 There might be signaling message primitives, however, that are 554 drained or generated by the router, like certain refresh messages. 555 In this case the signal handling time is immeasurable, therefore 556 it is not defined for such messages. 558 In the case of signaling messages that carry information 559 pertaining to multicast flows, the router might issue multiple 560 signaling messages after processing them. In this case, by 561 definition, the signal handling time is the latency between the 562 incoming signaling message and the last outgoing signaling message 563 related to the received one. 565 The signal handling time is an important characteristic as it 566 directly affects the setup time of a QoS session. 568 Issues: 569 The signal handling time may be dependent on the type of the 570 signaling message. For example, it usually takes a shorter time 571 for the router to remove a reservation state than to set it up. 572 This fact has to be considered during the benchmarking process. 574 Measurement unit: 575 The unit of the signaling message handling time is the second. 577 3.4.2 Distinguished Traffic Delay 579 Definition: 580 Distinguished traffic delay is the latency ([1]) of a 581 distinguished data packet passing through the tested router 582 device. 584 Discussion: 585 Distinguished traffic packets must be classified first in order to 586 assign the network resources dedicated to the flow. The time of 587 the classification is added to the usual forwarding time 588 (including the queuing) that a router would spend on the packet 589 without any resource reservation capability. This classification 590 procedure might be quite time consuming in routers with vast 591 amounts of reservation states. 593 There are routers where the processing power is shared between the 594 control plane and the data plane. This means that the processing 595 of signaling messages may have an impact on the data forwarding 596 performance of the router. In this case the distinguished traffic 597 delay metric also indicates the influence the two planes have on 598 each other. 600 Issues: 601 Queuing of the incoming data packets in routers can bias this 602 metric, so the measurement procedures have to consider this 603 effect. 605 Measurement unit: 606 The unit of the distinguished traffic delay is the second. 608 3.4.3 Best-effort Traffic Delay 610 Definition: 611 Best-effort traffic delay is the latency of a best-effort data 612 packet traversing the tested router device. 614 Discussion: 615 If the processing power of the router is shared between the 616 control and data plane, then the processing of signaling messages 617 may have an impact on the data forwarding performance of the 618 router. In this case the best-effort traffic delay metric is an 619 indicator of the influence the two planes have on each other. 621 Issues: 622 Queuing of the incoming data packets in routers can bias this 623 metric as well, so measurement procedures have to consider this 624 effect. 626 Measurement unit: 627 The unit of the best-effort traffic delay is the second. 629 3.4.4 Signaling Message Loss 631 Definition: 632 Signaling message loss is the ratio of the actual and the expected 633 number of signaling messages leaving a resource reservation 634 capable router, subtracted from one. 636 Discussion: 637 This definition gives the same value as the ratio of the lost and 638 the expected messages. The reason for choosing the given 639 definition is that the number of lost messages cannot be measured 640 directly. 642 There are certain types of signaling messages that are required to 643 be forwarded by reservation capable routers as soon as their 644 processing is finished. However, due to the high router load or 645 for other reasons, the forwarding or even the processing of these 646 signaling messages might be canceled. There are other kinds of 647 signaling messages, that should have been generated by the router, 648 without any corresponding incoming message. In case of high router 649 load, it is possible that such a message never leaves the router. 650 To characterize these situations we introduce the signaling 651 message loss metric expressing the ratio of the signaling messages 652 that actually have left the router and those ones that were 653 expected to leave the router. 655 Since the most frequent reason for signaling message loss is high 656 router load, this metric is suitable for sounding out the 657 scalability limits of resource reservation capable routers. 659 During the measurements one must be able to determine whether a 660 signaling message is still in the queues of the router or if it 661 has already been dropped. For this reason we define a signaling 662 message as lost if no forwarded signaling message is emitted 663 within a reasonably long time period. This period is defined along 664 with the benchmarking methodology. 666 Measurement unit: 667 This measure has no unit; it is expressed as a real number, which 668 is between zero and one, including the limits. 670 3.4.5 Session Maintenance Capacity 672 Definition: 673 The session maintenance capacity metric is used in the case of 674 soft-state resource reservation protocols only. It is defined as 675 the ratio of the number of QoS sessions actually maintained and 676 the number of QoS sessions that should have been maintained during 677 one refresh period. 679 Discussion: 680 For soft-state protocols maintaining a QoS session means 681 refreshing the reservation states associated with it. 683 When a soft-state resource reservation capable router is 684 overloaded, it may happen that the router is not able to refresh 685 all the registered reservation states, because it does not have 686 the time to run the state refresh task. In this case sooner or 687 later some QoS sessions will be lost even if the endpoints still 688 require their maintenance. 690 The session maintenance capacity sounds out the maximal number of 691 QoS sessions that the router is capable of maintaining. 693 Issues: 694 The actual process of session maintenance is protocol and 695 implementation dependent, so is the method to examine that a 696 session is maintained or not. 698 In the case of soft-state resource reservation protocols a router 699 that fails to maintain a QoS session may not emit refresh 700 signaling messages either. This has direct consequences on the 701 signaling message loss metric. 703 Measurement unit: 704 This measure has no unit; it is expressed as a real number, which 705 is between zero and one (including the limits). 707 3.5 Scalability Limit 709 Definition: 710 The scalability limit of the router is the critical load 711 condition, when the router is still in the steady state but the 712 smallest amount of additional load would drive it to the 713 overloaded state. 715 Discussion: 716 All existing routers have finite buffer memory and finite 717 processing power. In the steady state of the router, the buffer 718 memories are not fully utilized and the processing power is enough 719 to cope with all tasks running on the router. As the router load 720 increases the buffers are starting to fill up and/or the router 721 has to postpone more and more tasks. However, there is a certain 722 point where no more buffer memory is available, or a task cannot 723 be postponed any longer; thus the router is forced to drop a 724 packet or an activity. This is the overloaded state of the 725 resource reservation capable router, which can be recognized by 726 the fact that some kind of data (signaling or packet) or task 727 (e.g. QoS session maintenance) loss occurs. 729 4. Security Considerations 731 As this document only provides terminology and describes neither a 732 protocol nor an implementation or a procedure, there are no security 733 considerations associated with it. 735 5. IANA Considerations 737 This document has no actions for IANA. 739 6. Acknowledgements 741 We would like to thank the following individuals for their help in 742 the research and development work, which contributed to form this 743 document: Joakim Bergkvist and Norbert Vegh from Telia Research AB, 744 Sweden; Balazs Szabo, Gabor Kovacs and Peter Vary from the High 745 Speed Networks Laboratory, Budapest University of Technology and 746 Economics, Hungary. 748 7. References 750 7.1 Normative References 752 [1] S. Bradner, "Benchmarking Terminology for Network 753 Interconnection Devices", RFC 1242, July 1991 755 [2] R. Mandeville, "Benchmarking Terminology for LAN Switching 756 Devices", RFC 2285, February 1998 758 7.2 Informative References 760 [3] B. Braden, Ed., et. al., "Resource Reservation Protocol (RSVP) 761 - Version 1 Functional Specification", RFC 2205, September 762 1997. 764 [4] R. Hancock, et al., "Next Steps in Signaling: Framework" 765 (draft-ietf-nsis-fw-07.txt) (Internet draft: work in progress), 766 November 2004 768 [5] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism 769 for the Internet", Computer Communication Review, on-line 770 version, volume 29, number 2, April 1999 772 [6] L. Delgrossi, L. Berger, "Internet Stream Protocol Version 2 773 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 774 1995 776 [7] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated 777 Reservation in the Internet", Journal on High Speed Networks, 778 Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998 780 [8] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I. 781 Cselenyi, M. Maliosz, "Boomerang : A Simple Protocol for 782 Resource Reservation in IP Networks", Vancouver, IEEE Real-Time 783 Technology and Applications Symposium, June 1999 785 [9] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight 786 Resource Reservation for Unicast IP Traffic", International WS 787 on QoS'98, IWQoS'98, May 18-20, 1998 789 [10] J. Manner, X. Fu, "Analysis of Existing Quality of Service 790 Signaling Protocols" (draft-ietf-nsis-signalling-analysis- 791 05.txt) (Internet draft: work in progress), December 2004 793 [11] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation 794 of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 795 2001 797 Authors' Addresses 799 Gabor Feher 800 Budapest University of Technology and Economics 801 Department of Telecommunications and Mediainformatics 802 Magyar Tudosok krt. 2, H-1117, Budapest, Hungary 803 Phone: +36 1 463-1538 804 Email: Gabor.Feher@tmit.bme.hu 806 Krisztian Nemeth 807 Budapest University of Technology and Economics 808 Department of Telecommunications and Mediainformatics 809 Magyar Tudosok krt. 2, H-1117, Budapest, Hungary 810 Phone: +36 1 463-1565 811 Email: Krisztian.Nemeth@tmit.bme.hu 813 Andras Korn 814 Budapest University of Technology and Economics 815 Institute of Mathematics, Department of Analysis 816 Egry Jozsef u. 2, H-1111 Budapest, Hungary 817 Phone: +36 1 463-2475 818 Email: Korn@math.bme.hu 820 Istvan Cselenyi 821 TeliaSonera International Carrier 822 Vaci ut 22-24, H-1132 Budapest, Hungary 823 Phone: +36 1 412-2705 824 Email: Istvan.Cselenyi@teliasonera.com 826 Disclaimer of Validity 828 The IETF takes no position regarding the validity or scope of any 829 Intellectual Property Rights or other rights that might be claimed 830 to pertain to the implementation or use of the technology 831 described in this document or the extent to which any license 832 under such rights might or might not be available; nor does it 833 represent that it has made any independent effort to identify any 834 such rights. Information on the IETF's procedures with respect to 835 rights in IETF Documents can be found in BCP 78 and BCP 79. 837 Copies of IPR disclosures made to the IETF Secretariat and any 838 assurances of licenses to be made available, or the result of an 839 attempt made to obtain a general license or permission for the use 840 of such proprietary rights by implementers or users of this 841 specification can be obtained from the IETF on-line IPR repository 842 at http://www.ietf.org/ipr. 844 The IETF invites any interested party to bring to its attention 845 any copyrights, patents or patent applications, or other 846 proprietary rights that may cover technology that may be required 847 to implement this standard. Please address the information to the 848 IETF at ietf-ipr@ietf.org. 850 Copyright Notice 852 Copyright (C) The Internet Society (2005). This document is 853 subject to the rights, licenses and restrictions contained in BCP 854 78, and except as set forth therein, the authors retain all their 855 rights. 857 Disclaimer 859 This document and the information contained herein are provided 860 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 861 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 862 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 863 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 864 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 865 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 866 PARTICULAR PURPOSE.