idnits 2.17.1 draft-ietf-bmwg-dsmterm-02.txt: 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: ---------------------------------------------------------------------------- == 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 Abstract 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 32 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2001) is 8198 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: '4' is defined on line 1012, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jerry Perser 3 INTERNET-DRAFT Spirent 4 Expires in: May 2002 David Newman 5 Network Test 6 Sumit Khurana 7 Telcordia 8 Shobha Erramilli 9 QNetworx 10 Scott Poretsky 11 Avici Systems 12 November 2001 14 Terminology for Benchmarking Network-layer 15 Traffic Control Mechanisms 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet- 32 Drafts as reference material or to cite them other than as "work 33 in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Table of Contents 43 1. Introduction .............................................. 2 44 2. Existing definitions ...................................... 3 45 3. Term definitions ............................................3 46 3.1 Configuration Terms 47 3.1.1 Classification .........................................3 48 3.1.2 Codepoint Set ..........................................4 49 3.1.3 Congestion .............................................4 50 3.1.4 Congestion Management ..................................5 51 3.2 Vectors ....................................................6 52 3.2.1 Intended Vector ........................................6 53 Network-layer Traffic Control Mechanisms 55 3.2.2 Offered Vector .........................................6 56 3.2.3 Expected Vectors 57 3.2.3.1 Expected Forwarding Vector ...........................7 58 3.2.3.2 Expected Loss Vector .................................8 59 3.2.3.3 Expected Sequence Vector .............................8 60 3.2.3.4 Expected Delay Vector ................................9 61 3.2.3.5 Expected Jitter Vector ..............................10 62 3.2.4 Output Vectors 63 3.2.4.1 Forwarding Vector ...................................11 64 3.2.4.2 Loss Vector .........................................11 65 3.2.4.3 Sequence Vector .....................................12 66 3.2.4.4 Delay Vector ........................................13 67 3.2.4.5 Jitter Vector .......................................14 68 3.3 Measurement Terms 69 3.3.1 Channel Capacity ......................................15 70 3.3.2 Conforming ............................................15 71 3.3.3 Nonconforming .........................................16 72 3.3.4 Delay .................................................16 73 3.3.5 Flow ..................................................17 74 3.3.6 Stream ................................................18 75 3.3.7 Test Sequence number ..................................19 76 3.3.8 Undifferentiated Response .............................19 77 4. Security Considerations ....................................20 78 5. References .................................................20 79 6. Author's Address ...........................................21 80 7. Full Copyright Statement ...................................22 82 1. Introduction 84 This document describes terminology for the benchmarking of 85 devices that implement traffic control based on IP precedence or 86 diff-serv code point criteria. 88 New terminology is needed because most existing measurements 89 assume the absence of congestion and only a single per-hop- 90 behavior. This document introduces several new terms that will 91 allow measurements to be taken during periods of congestion. 93 Another key difference from existing terminology is the definition 94 of measurements as observed on egress as well as ingress of a 95 device/system under test. Again, the existence of congestion 96 requires the addition of egress measurements as well as those 97 taken on ingress; without observing traffic leaving a 98 device/system it is not possible to say whether traffic-control 99 mechanisms effectively dealt with congestion. 101 The principal measurements introduced in this document are vectors 102 for rate, delay, and jitter, all of which can be observed with or 103 without congestion of the DUT/SUT. 105 Network-layer Traffic Control Mechanisms 107 This document describes only those terms relevant to measuring 108 behavior of a device or a group of devices using one of these two 109 mechanisms. End-to-end and service-level measurements are beyond 110 the scope of this document. 112 2. Existing definitions 114 RFC 1242 "Benchmarking Terminology for Network Interconnect 115 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 116 Devices" should be consulted before attempting to make use of this 117 document. 119 RFC 2474 "Definition of the Differentiated Services Field (DS 120 Field) in the IPv4 and IPv6 Headers" section 2, contains 121 discussions of a number of terms relevant to network-layer traffic 122 control mechanisms and should also be consulted. 124 For the sake of clarity and continuity this RFC adopts the 125 template for definitions set out in Section 2 of RFC 1242. 126 Definitions are indexed and grouped together in sections for ease 127 of reference. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 130 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 RFC 2119. 134 3. Term definitions 136 3.1 Configuration Terms 138 3.1.1 Classification 140 Definition: 141 Selection of packets based on the contents of packet header 142 according to defined rules. 144 Discussion: 145 Packets can be selected based on the DS field or IP 146 Precedence in the packet header. Classification can also be 147 based on Multi-Field (MF) criteria such as IP Source and 148 destination addresses, protocol and port number. 150 Classification determines the per-hop behaviors and traffic 151 conditioning functions such as shaping and dropping that are 152 to be applied to the packet. 154 Measurement units: 156 Network-layer Traffic Control Mechanisms 158 n/a 160 Issues: 162 See Also: 164 3.1.2 Codepoint Set 166 Definition: 167 The set of all DS Code-points or IP precedence values used 168 during the test duration. 170 Discussion: 171 Describes all the code-point markings associated with packets 172 that are input to the DUT/SUT. For each entry in the 173 codepoint set, there are associated vectors describing the 174 rate of traffic containing that particular DSCP or IP 175 precedence value. 177 The treatment that a packet belonging to a particular code- 178 point gets is subject to the DUT classifying packets to map 179 to the correct PHB. Moreover, the forwarding treatment in 180 general is also dependent on the complete set of offered 181 vectors. 183 Measurement Units: 184 n/a 186 See Also: 188 3.1.3 Congestion 190 Definition: 191 A condition in which one or more egress interfaces are 192 offered more packets than are forwarded at any given instant. 194 Discussion: 195 This condition is a superset of the overload definition [2]. 196 The overload definition assumes the congestion is introduced 197 strictly by the tester on ingress of a DUT/SUT. That may or 198 may not be the case here. 200 Another difference is that with multiple-DUT measurements, 201 congestion may occur at multiple points. For example, 202 multiple edge devices collectively may congest a core device. 203 In contrast, overload [1] deals only with overload on 204 ingress. 206 Network-layer Traffic Control Mechanisms 208 Ingress observations alone are not sufficient to cover all 209 cases in which congestion may occur. A device with an 210 infinite amount of memory could buffer an infinite amount of 211 packets, and eventually forward all of them. However, these 212 packets may or may not be forwarded during the test duration. 213 Even though ingress interfaces accept all packets without 214 loss, this hypothetical device may still be congested. 216 The definition presented here explicitly defines congestion 217 as an event observable on egress interfaces. Regardless of 218 internal architecture, any device that cannot forward packets 219 on one or more egress interfaces is congested. 221 Measurement units: 223 n/a 225 Issues: 227 See Also: 229 3.1.4 Congestion Management 231 Definition: 232 An implementation of one or more per-hop-behaviors to avoid 233 or minimize the condition of congestion. 235 Discussion: 236 Congestion management may seek either to control congestion 237 or avoid it altogether. Such mechanisms classify packets 238 based upon IP Precedence or DSCP settings in a packet's IP 239 header. 241 Congestion avoidance mechanisms seek to prevent congestion 242 before it actually occurs. 244 Congestion control mechanisms gives one or more service 245 classes preferential treatment over other classes during 246 periods of congestion. 248 Measurement units: 250 n/a 252 Issues: 254 See Also: 256 Network-layer Traffic Control Mechanisms 258 3.2 Vectors 259 A vector is a group of packets all containing a specific DSCP 260 or IP precedence value. Vectors are expressed as a pair of 261 numbers. The first is being the particular diff-serv value. 262 The second is the metric expressed as a rate, loss 263 percentage, delay, or jitter. 265 3.2.1 Intended Vector 267 Definition: 269 A vector describing the rate at which packets having a 270 specific code-point (or IP precedence) that an external 271 source attempts to transmit to a DUT/SUT. 273 Discussion: 274 Intended loads across the different code-point classes 275 determine the metrics associated with a specific code-point 276 traffic class. 278 Measurement Units: 279 N-octets packets per second 281 Issues: 283 See Also: 284 Offered Vector 285 Expected Forwarding Vector 286 Expected Loss Vector 287 Expected Sequence Vector 288 Expected Delay Vector 289 Expected Jitter Vector 290 Forwarding Vector 291 Loss Vector 293 3.2.2 Offered Vector 295 Definition: 296 A vector describing the measured rate at which packets having 297 a specific DSCP or IP precedence value are offered to the 298 DUT/SUT. 300 Discussion: 301 Offered loads across the different code-point classes, 302 constituting a code-point set, determine the metrics 303 associated with a specific code-point traffic class. 305 Measurement Units: 306 N-octets packets per second 307 Network-layer Traffic Control Mechanisms 309 Issues: 310 Packet size. 312 See Also: 313 Expected Forwarding Vector 314 Expected Loss Vector 315 Expected Sequence Vector 316 Expected Delay Vector 317 Expected Jitter Vector 318 Forwarding Vector 319 Codepoint Set 321 3.2.3 Expected Vectors 323 3.2.3.1 Expected Forwarding Vector 325 Definition: 326 A vector describing the expected output rate of packets 327 having a specific DSCP or IP precedence value. The value is 328 dependent on the set of offered vectors and configuration of 329 the DUT. 331 Discussion: 332 The DUT is configured in a certain way in order that service 333 differentiation occurs for behavior aggregates when a 334 specific traffic mix consisting of multiple behavior 335 aggregates is applied. This term attempts to capture the 336 expected forwarding behavior, for which the device is 337 configured, when subjected to a certain offered load. 339 The actual algorithms or mechanism, that the DUT uses to 340 achieve service differentiation, is not important in 341 describing the expected vector. 343 Measurement units: 344 N-octet packets per second 346 Issues: 348 See Also: 349 Intended Vector 350 Offered Vector 351 Output Vectors 352 Expected Loss Vector 353 Expected Sequence Vector 354 Expected Delay Vector 355 Expected Jitter Vector 356 Network-layer Traffic Control Mechanisms 358 3.2.3.2 Expected Loss Vector 360 Definition: 361 A vector describing the percentage of packets, having a 362 specific DSCP or IP precedence value, that should not be 363 forwarded. The value is dependent on the set of offered 364 vectors and configuration of the DUT. 366 Discussion: 367 The DUT is configured in a certain way in order that service 368 differentiation occurs for behavior aggregates when a 369 specific traffic mix consisting of multiple behavior 370 aggregates is applied. This term attempts to capture the 371 expected loss behavior, for which the device is configured, 372 when subjected to a certain offered load. 374 The actual algorithms or mechanism, that the DUT uses to 375 achieve service differentiation, is not important in 376 describing the expected loss vector. 378 Measurement Units: 379 Percentage of intended packets that are expected to be 380 dropped. 382 Issues: 384 See Also: 385 Intended Vector 386 Offered Vector 387 Expected Forwarding Vector 388 Expected Sequence Vector 389 Expected Delay Vector 390 Expected Jitter Vector 392 3.2.3.3 Expected Sequence Vector 394 Definition: 395 A vector describing the expected sequencing of packets having 396 a specific DSCP or IP precedence value. The value is 397 dependent on the set of offered vectors and configuration of 398 the DUT. 400 Discussion: 401 The DUT is configured in a certain way in order that service 402 differentiation occurs for behavior aggregates when a 403 specific traffic mix consisting of multiple behavior 404 aggregates is applied. This term attempts to capture the 405 expected sequence behavior, for which the device is 406 configured, when subjected to a certain offered load. 408 Network-layer Traffic Control Mechanisms 410 The actual algorithms or mechanism, that the DUT uses to 411 achieve service differentiation, is not important in 412 describing the expected vector. 414 Measurement Units: 415 N-octet packets per second 417 Issues: 419 See Also: 420 Intended Vector 421 Offered Vector 422 Output Vectors 423 Expected Loss Vector 424 Expected Forwarding Vector 425 Expected Delay Vector 426 Expected Jitter Vector 428 3.2.3.4 Expected Delay Vector 430 Definition: 431 A vector describing the expected delay for packets having a 432 specific DSCP or IP precedence value. The value is dependent 433 on the set of offered vectors and configuration of the DUT. 435 Discussion: 436 The DUT is configured in a certain way in order that service 437 differentiation occurs for behavior aggregates when a 438 specific traffic mix consisting of multiple behavior 439 aggregates is applied. This term attempts to capture the 440 expected delay behavior, for which the device is configured, 441 when subjected to a certain offered load. 443 The actual algorithms or mechanism, that the DUT uses to 444 achieve service differentiation, is not important in 445 describing the expected delay vector. 447 Measurement units: 449 Seconds. 451 Issues: 453 See Also: 454 Intended Vector 455 Offered Vector 456 Output Vectors 457 Expected Loss Vector 458 Expected Sequence Vector 459 Expected Forwarding Vector 460 Expected Jitter Vector 461 Network-layer Traffic Control Mechanisms 463 3.2.3.5 Expected Jitter Vector 465 Definition: 466 A vector describing the expected variation in the delay of 467 packet arrival times for packets having specific DSCP or IP 468 precedence value. The value is dependent on the set of 469 offered vectors and configuration of the DUT. 471 Discussion: 472 Jitter is the absolute value of the difference between the 473 delay measurement of two packets belonging to the same 474 stream. 476 The jitter between two consecutive packets in a stream is 477 reported as the "instantaneous jitter". Instantaneous jitter 478 can be expressed as |D(i) - D(i-1)| where D equals the delay 479 and i is the test sequence number. Packets lost are not 480 counted in the jitter measurement. 482 Average Jitter is the average of the instantaneous jitter 483 measured during the test duration. 485 Peak-to-peak jitter is the maximum delay minus the minimum 486 delay of the packets forwarded by the DUT/SUT. 488 Measurement units: 489 Seconds (instantaneous) 490 Seconds P-P (peak to peak) 491 Seconds Avg (average) 493 Issues: 495 See Also: 496 Intended Vector 497 Offered Vector 498 Output Vectors 499 Expected Loss Vector 500 Expected Sequence Vector 501 Expected Delay Vector 502 Expected Forwarding Vector 504 3.2.4 Output Vectors 505 Network-layer Traffic Control Mechanisms 507 3.2.4.1 Forwarding Vector 509 Definition: 510 The number of packets per second for all packets containing a 511 specific DSCP or IP precedence value that a device can be 512 observed to successfully transmit to the correct destination 513 interface in response to an offered vector. 515 Discussion: 516 Forwarding Vector is expressed as pair of numbers. Both the 517 specific DSCP (or IP precedence) value AND the packets per 518 second value combine to make a vector. 520 The Forwarding Vector represents packet rate based on its 521 specific DSCP (or IP precedence) value. It is not 522 necessarily based on a stream or flow. The Forwarding Vector 523 may be expressed as per port of the DUT/SUT. However, it must 524 be consistent with the Expected Forwarding Vector. 526 Forwarding Vector is a per-hop measurement. The DUT/SUT may 527 change the specific DSCP (or IP precedence) value for a 528 multiple-hop measurement. 530 Measurement units: 531 N-octet packets per second 533 Issues: 535 See Also: 536 Intended Vector 537 Offered Vector 538 Expected Vectors 539 Loss Vector 540 Sequence Vector 541 Delay Vector 542 Jitter Vector 544 3.2.4.2 Loss Vector 546 Definition: 547 The percentage of packets containing specific DSCP or IP 548 precedence value that a DUT/SUT did not transmit to the 549 correct destination interface in response to an offered 550 vector. 552 Discussion: 553 Loss Vector is expressed as pair of numbers. Both the 554 specific DSCP (or IP precedence) value AND the percentage 555 value combine to make a vector. 557 Network-layer Traffic Control Mechanisms 559 The Loss Vector represents percentage based on a specific 560 DSCP or IP precedence value. It is not necessarily based on 561 a stream or flow. The Loss Vector may be expressed as per 562 port of the DUT/SUT. However, it must be consistent with the 563 Expected Loss Vector 565 Loss Vector is a per-hop measurement. The DUT/SUT may change 566 the specific DSCP or IP precedence value for a multiple-hop 567 measurement. 569 Measurement Units: 570 Percentage of offered packets that are not forwarded. 572 Issues: 574 See Also: 575 Intended Vector 576 Offered Vector 577 Expected Vectors 578 Forwarding Vector 579 Sequence Vector 580 Delay Vector 581 Jitter Vector 583 3.2.4.3 Sequence Vector 585 Definition: 586 The number of packets per second for all packets containing a 587 specific DSCP or IP precedence value that a device can be 588 observed to transmit out of sequence to the correct 589 destination interface in response to an offered vector. 591 Discussion: 592 Sequence Vector is expressed as pair of numbers. Both the 593 specific DSCP (or IP precedence) value AND the packets per 594 second value combine to make a vector. 596 The Sequence Vector represents packet rate based on its 597 specific DSCP or IP precedence value. It is not necessarily 598 based on a stream or flow. The Sequence Vector may be 599 expressed as per port of the DUT/SUT. However, it must be 600 consistent with the Expected Sequence Vector. 602 Sequence Vector is a per-hop measurement. The DUT/SUT may 603 change the specific DSCP or IP precedence value for a 604 multiple-hop measurement. 606 Measurement Units: 607 N-octet packets per second 609 Issues: 611 Network-layer Traffic Control Mechanisms 613 See Also: 614 Intended Vector 615 Offered Vector 616 Expected Vectors 617 Loss Vector 618 Forwarding Vector 619 Delay Vector 620 Jitter Vector 622 3.2.4.4 Delay Vector 624 Definition: 625 The delay for packets containing specific DSCP or IP 626 precedence value that a device can be observed to 627 successfully transmit to the correct destination interface in 628 response to an offered vector. 630 Discussion: 631 Delay vector is expressed as pair of numbers. Both the 632 specific DSCP (or IP precedence) value AND delay value 633 combine to make a vector. 635 The Delay Vector represents delay on its specific DSCP or IP 636 precedence value. It is not necessarily based on a stream or 637 flow. The Delay vector may be expressed as per port of the 638 DUT/SUT. However, it must be consistent with the Expected 639 Delay vector. 641 Delay vector is measured similarly regardless of the type of 642 DUT/SUT. Latency [1] require some knowledge of whether the 643 DUT/SUT is a "store and forward" or a "bit forwarding" 644 device. The fact that a DUT/SUT's technology has a lower 645 delay than another technology should be visible. 647 Delay Vector is a per-hop measurement. The DUT/SUT may 648 change the specific DSCP or IP precedence value for a 649 multiple-hop measurement. 651 Delay vector can be obtained at any offered load. Recommend 652 at or below the channel capacity in the absence of 653 congestion. For congested delay, run the offered load above 654 the channel capacity. 656 Measurement Units: 657 seconds 659 Issues: 661 See Also: 662 Delay 663 Network-layer Traffic Control Mechanisms 665 Intended Vector 666 Offered Vector 667 Expected Delay Vector 668 Loss Vector 669 Forwarding Vector 670 Jitter Vector 672 3.2.4.5 Jitter Vector 674 Definition: 675 The variation in the delay for packets containing specific 676 DSCP or IP precedence value that a device can be observed to 677 successfully transmit to the correct destination interface in 678 response to an offered vector. 680 Discussion: 681 Jitter is the absolute value of the difference between the 682 delay measurement of two packets belonging to the same 683 stream. 685 Jitter vector is expressed as pair of numbers. Both the 686 specific DSCP (or IP precedence) value AND jitter value 687 combine to make a vector. 689 The jitter between two consecutive packets in a stream is 690 reported as the "instantaneous jitter". Instantaneous jitter 691 can be expressed as |D(i) - D(i-1)| where D equals the delay 692 and i is the test sequence number. Packets lost are not 693 counted in the jitter measurement. 695 Jitter vector is a per-hop measurement. The DUT/SUT may 696 change the specific DSCP or IP precedence value for a 697 multiple-hop measurement. 699 Average Jitter is the average of the instantaneous jitter 700 measured during the test duration. 702 Peak-to-peak Jitter is the maximum delay minus the minimum 703 delay of the packets forwarded by the DUT/SUT. 705 Measurement units: 706 Seconds (instantaneous) 707 Seconds P-P (peak to peak) 708 Seconds Avg (average) 710 Issues: 712 See Also: 713 Intended Vector 714 Offered Vector 715 Expected Vectors 716 Network-layer Traffic Control Mechanisms 718 Loss Vector 719 Sequence Vector 720 Delay Vector 721 Forwarding Vector 723 3.3 Measurement Terms 725 3.3.1 Channel Capacity 727 Definition: 728 The maximum forwarding rate [2] at which none of the offered 729 packets are dropped by the DUT/SUT. 731 Discussion: 732 Channel capacity measures the packet rate at the egress 733 interface(s) of the DUT/SUT. In contrast, throughput as 734 defined in RFC 1242 measures the packet rate is based on the 735 ingress interface(s) of the DUT/SUT. 737 Ingress-based measurements do not account for congestion of 738 the DUT/SUT. Channel capacity, as an egress measurement, does 739 take congestion into account. 741 Understanding channel capacity is a necessary precursor to 742 any measurement involving congestion. Throughput numbers can 743 be higher than channel capacity because of queueing. 745 This measurement differs from forwarding rate at maximum 746 offered load (FRMOL) [2] in that it is intolerant of loss. 748 Measurement units: 750 N-octet packets per second 752 Issues: 754 See Also: 755 Throughput [1] 756 Forwarding Rate at Maximum Offered Load [2] 758 3.3.2 Conforming 760 Definition: 761 Packets which lie within specific rate, delay, or jitter 762 bounds. 764 Discussion: 765 A DUT/SUT may be configured to allow a given traffic class to 766 consume a given amount of bandwidth, or to fall within 767 Network-layer Traffic Control Mechanisms 769 predefined delay or jitter boundaries. All packets that lie 770 within specified bounds are then said to be conforming, 771 whereas those outside the bounds are nonconforming. 773 Measurement units: 775 n/a 777 Issues: 779 See Also: 780 Expected Vector 781 Forwarding Vector 782 Offered Vector 783 Nonconforming 785 3.3.3 Nonconforming 787 Definition: 788 Packets that do not lie within specific rate, delay, or 789 jitter bounds. 791 Discussion: 792 A DUT/SUT may be configured to allow a given traffic class to 793 consume a given amount of bandwidth, or to fall within 794 predefined delay or jitter boundaries. All packets that do 795 not lie within these bounds are then said to be 796 nonconforming. 798 Measurement units: 800 n/a 802 Issues: 804 See Also: 805 Expected Vector 806 Forwarding Vector 807 Offered Vector 808 Conforming 810 3.3.4 Delay 812 Definition: 813 The time interval starting when the last bit of the input IP 814 packets reaches the input port of the DUT/SUT and ending when 815 the last bit of the output IP packets is seen on the output 816 port of the DUT/SUT. 818 Discussion: 820 Network-layer Traffic Control Mechanisms 822 Delay is measured the same regardless of the type of DUT/SUT. 823 Latency [1] require some knowledge of whether the DUT/SUT is 824 a "store and forward" or a "bit forwarding" device. The fact 825 that a DUT/SUT's technology has a lower delay than another 826 technology should be visible. 828 By specifying the metric to be inside the Internet protocol, 829 the tester is relieved from specifying the start/end for 830 every data link layer protocol that IP runs on. This avoids 831 determining if the start/end delimiter are included in the 832 frame. Also heterogeneous data link protocol can be used in 833 a test. 835 The measurement point at the end is closely simulates the way 836 an internet datagram is processed. An internet datagram is 837 not passed up or down the stack unless it is complete. 838 Completion occurs once the last bit of the IP packet has been 839 received. 841 Delay can be run at any offered load. Recommend at or below 842 the channel capacity for non-congested delay. For congested 843 delay, run the offered load above the channel capacity. 845 Measurement units: 847 Seconds. 849 Issues: 851 See Also: 852 Latency [1] 854 3.3.5 Flow 856 Definition: 857 A flow is a one or more of packets sharing a common intended 858 pair of source and destination interfaces. 860 Discussion: 861 Packets are grouped by the ingress and egress interfaces they 862 use on a given DUT/SUT. 864 A flow can contain multiple source IP addresses and/or 865 destination IP addresses. All packets in a flow must enter 866 on the same ingress interface and exit on the same egress 867 interface, and have some common network layer content. 869 Microflows [3] are a subset of flows. As defined in [3], 870 microflows require application-to-application measurement. In 871 contrast, flows use lower-layer classification criteria. 872 Since this document focuses on network-layer classification 873 Network-layer Traffic Control Mechanisms 875 criteria, we concentrate here on the use of network-layer 876 identifiers in describing a flow. Flow identifiers also may 877 reside at the data-link, transport, or application layers of 878 the ISO model. However, identifiers other than those at the 879 network layer are out of scope for this document. 881 A flow may contain a single code point/IP precedence value or 882 may contain multiple values destined for a single egress 883 interface. This is determined by the test methodology. 885 Measurement units: 887 n/a 889 Issues: 891 See Also: 892 Microflow [3] 893 Streams 895 3.3.6 Stream 897 Definition: 898 A group of packets tracked as a single entity by the traffic 899 receiver. A stream may share a common content such as type 900 (IP, UDP), packet size, or payload. 902 Discussion: 903 Streams are tracked by Test sequence number or "unique 904 signature field" (RFC 2889). Streams define how individual 905 packet's statistics are grouped together to form an 906 intelligible summary. 908 Common stream groupings would be by egress interface, 909 destination address, source address, DSCP, or IP precedence. 910 A stream using Test sequence numbers can track the ordering 911 of packets as they transverse the DUT/SUT. 913 Streams are not restricted to a pair of source and 914 destination interfaces as long as all packets are tracked as 915 a single entity. A mulitcast stream can be forward to 916 multiple destination interfaces. 918 Measurement units: 920 n/a 922 Issues: 924 Network-layer Traffic Control Mechanisms 926 See Also: 927 Flow 928 MicroFlow [3] 929 Test sequence number 931 3.3.7 Test Sequence number 933 Definition: 934 A field in the IP payload portion of the packet that is used 935 to verify the order of the packets on the egress of the 936 DUT/SUT. 938 Discussion: 939 The traffic generator sets the Test sequence number value and 940 the traffic receiver checks the value upon receipt of the 941 packet. The traffic generator changes the value on each 942 packet transmitted based on an algorithm agreed to by the 943 traffic receiver. 945 The traffic receiver keeps track of the sequence numbers on a 946 per stream basis. In addition to number of received packets, 947 the traffic receiver may also report number of in-sequence 948 packets, number of out-sequence packets, number of duplicate 949 packets, and number of reordered packets. 951 The recommended algorithm to use to change the sequence 952 number on sequential packets is an incrementing value. 954 Measurement units: 956 n/a 958 Issues: 960 See Also: 961 Stream 963 3.3.8 Undifferentiated Response 965 Definition: 966 The vector(s) obtained when mechanisms used to support diff- 967 serv or IP precedence are disabled. 969 Discussion: 970 Enabling diff-serv or IP precedence mechanisms may impose 971 additional processing overhead for packets. This overhead may 972 degrade performance even when traffic belonging to only one 973 class, the best-effort class, is offered to the device. 975 Network-layer Traffic Control Mechanisms 977 Measurements with "undifferentiated response" should be made 978 to establish a baseline. 980 The vector(s) obtained with DSCPs or IP precedence enabled 981 can be compared to the undifferentiated response to determine 982 the effect of differentiating traffic. 984 Measurement units: 986 n/a 988 4. Security Considerations 990 Documents of this type do not directly affect the security of 991 the Internet or of corporate networks as long as benchmarking 992 is not performed on devices or systems connected to operating 993 networks. 995 Packets with unintended and/or unauthorized DSCP or IP 996 precedence values may present security issues. Determining 997 the security consequences of such packets is out of scope for 998 this document. 1000 5. References 1002 [1] Bradner, S., Editor, "Benchmarking Terminology for 1003 Network Interconnection Devices", RFC 1242, July 1991. 1005 [2] Mandeville, R., "Benchmarking Terminology for LAN 1006 Switching Devices", RFC 2285, February 1998. 1008 [3] K. Nichols, S. Blake, F. Baker, D. Black,"Definition of 1009 the Differentiated Services Field (DS Field) in the IPv4 1010 and IPv6 Headers", RFC 2474, December 1998. 1012 [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 1013 Weiss, "An Architecture for Differentiated Services", RFC 1014 2475, December 1998. 1016 Network-layer Traffic Control Mechanisms 1018 6. Authors' Address 1020 Jerry Perser 1021 Spirent Communications 1022 26750 Agoura Road 1023 Calabasas, CA 91302 1024 USA 1026 Phone: + 1 818 676 2300 1027 EMail: jerry.perser@spirentcom.com 1029 David Newman 1030 Network Test 1031 31324 Via Colinas, Suite 113 1032 Westlake Village, CA 91362 1033 USA 1035 Phone: + 1 818 889 0011, x10 1036 EMail: dnewman@networktest.com 1038 Sumit Khurana 1039 Telcordia Technologies 1040 445 South Street 1041 Morristown, NJ 07960 1042 USA 1044 Phone: + 1 973 829 3170 1045 EMail: sumit@research.telcordia.com 1047 Shobha Erramilli 1048 QNetworx Inc 1049 1119 Campus Drive West 1050 Morganville NJ 07751 1051 USA 1053 Phone: 1054 EMail: shobha@qnetworx.com 1056 Scott Poretsky 1057 Avici Systems 1058 101 Billerica Ave_Building #6 1059 N. Billerica, MA 01862 1060 USA 1062 Phone: + 1 978 964 2287 1063 EMail: sporetsky@avici.com 1064 Network-layer Traffic Control Mechanisms 1066 7. Full Copyright Statement 1068 Copyright (C) The Internet Society (1998). All Rights 1069 Reserved. 1071 This document and translations of it may be copied and 1072 furnished to others, and derivative works that comment on or 1073 otherwise explain it or assist in its implementation may be 1074 prepared, copied, published and distributed, in whole or in 1075 part, without restriction of any kind, provided that the 1076 above copyright notice and this paragraph are included on all 1077 such copies and derivative works. However, this document 1078 itself may not be modified in any way, such as by removing 1079 the copyright notice or references to the Internet Society or 1080 other Internet organizations, except as needed for the 1081 purpose of developing Internet standards in which case the 1082 procedures for copyrights defined in the Internet Standards 1083 process must be followed, or as required to translate it into 1084 languages other than English. 1086 The limited permissions granted above are perpetual and will 1087 not be revoked by the Internet Society or its successors or 1088 assigns. This document and the information contained herein 1089 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 1090 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1091 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1092 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1093 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1094 FITNESS FOR A PARTICULAR PURPOSE.