idnits 2.17.1 draft-ietf-bmwg-dsmterm-04.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 46 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 20 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 (October 2002) is 7836 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 1431, 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') ** Obsolete normative reference: RFC 2598 (ref. '5') (Obsoleted by RFC 3246) -- Unexpected draft version: The latest known version of draft-ietf-ippm-ipdv is -09, but you're referring to -10. ** Obsolete normative reference: RFC 1889 (ref. '7') (Obsoleted by RFC 3550) ** Downref: Normative reference to an Informational RFC: RFC 1254 (ref. '8') Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 3 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: April 2003 David Newman 5 Network Test 6 Sumit Khurana 7 Telcordia 8 Shobha Erramilli 9 QNetworx 10 Scott Poretsky 11 Avici Systems 12 October 2002 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.1.5 Flow ...................................................6 52 3.2 Measurement Terms 53 Network-layer Traffic Control Mechanisms 55 3.2.1 Channel Capacity .......................................7 56 3.2.2 Conforming .............................................7 57 3.2.3 Nonconforming ..........................................8 58 3.2.4 Delay ..................................................8 59 3.2.5 Jitter .................................................9 60 3.2.6 Undifferentiated Response .............................10 61 3.3 Sequence Tracking 62 3.3.1 In-sequence Packet ....................................10 63 3.3.2 Out-of-order Packet ...................................11 64 3.3.3 Duplicate Packet ......................................11 65 3.3.4 Stream ................................................12 66 3.3.5 Test Sequence number .................................12 67 3.4 Vectors ...................................................13 68 3.4.1 Intended Vector .......................................13 69 3.4.2 Offered Vector ........................................14 70 3.4.3 Expected Vectors 71 3.4.3.1 Expected Forwarding Vector ........................14 72 3.4.3.2 Expected Loss Vector ..............................15 73 3.4.3.3 Expected Sequence Vector ..........................16 74 3.4.3.4 Expected Instantaneous Delay Vector ...............16 75 3.4.3.5 Expected Average Delay Vector .....................17 76 3.4.3.6 Expected Maximum Delay Vector .....................17 77 3.4.3.7 Expected Minimum Delay Vector .....................18 78 3.4.3.8 Expected Instantaneous Jitter Vector ..............19 79 3.4.3.9 Expected Average Jitter Vector ....................19 80 3.4.3.10 Expected Peak-to-peak Jitter Vector ..............20 81 3.4.4 Output Vectors 82 3.4.4.1 Forwarding Vector .................................21 83 3.4.4.2 Loss Vector .......................................21 84 3.4.4.3 Sequence Vector ...................................22 85 3.4.4.4 Instantaneous Delay Vector ........................23 86 3.4.4.5 Average Delay Vector ..............................24 87 3.4.4.6 Maximum Delay Vector ..............................25 88 3.4.4.7 Minimum Delay Vector ..............................25 89 3.4.4.8 Instantaneous Jitter Vector .......................26 90 3.4.4.9 Average Jitter Vector .............................27 91 3.4.4.10 Peak-to-peak Jitter Vector .......................28 92 4. Security Considerations ....................................29 93 5. References .................................................29 94 6. Author's Address ...........................................30 95 7. Full Copyright Statement ...................................31 97 1. Introduction 99 This document describes terminology for the benchmarking of 100 devices that implement traffic control based on IP precedence or 101 diff-serv code point criteria. 103 New terminology is needed because most existing measurements 104 assume the absence of congestion and only a single per-hop- 105 Network-layer Traffic Control Mechanisms 107 behavior. This document introduces several new terms that will 108 allow measurements to be taken during periods of congestion. 110 Another key difference from existing terminology is the definition 111 of measurements as observed on egress as well as ingress of a 112 device/system under test. Again, the existence of congestion 113 requires the addition of egress measurements as well as those 114 taken on ingress; without observing traffic leaving a 115 device/system it is not possible to say whether traffic-control 116 mechanisms effectively dealt with congestion. 118 The principal measurements introduced in this document are vectors 119 for rate, delay, and jitter, all of which can be observed with or 120 without congestion of the DUT/SUT. 122 This document describes only those terms relevant to measuring 123 behavior of a device or a group of devices using one of these two 124 mechanisms. End-to-end and service-level measurements are beyond 125 the scope of this document. 127 2. Existing definitions 129 RFC 1242 "Benchmarking Terminology for Network Interconnect 130 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 131 Devices" should be consulted before attempting to make use of this 132 document. 134 RFC 2474 "Definition of the Differentiated Services Field (DS 135 Field) in the IPv4 and IPv6 Headers" section 2, contains 136 discussions of a number of terms relevant to network-layer traffic 137 control mechanisms and should also be consulted. 139 For the sake of clarity and continuity this RFC adopts the 140 template for definitions set out in Section 2 of RFC 1242. 141 Definitions are indexed and grouped together in sections for ease 142 of reference. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 145 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in 147 RFC 2119. 149 3. Term definitions 151 3.1 Configuration Terms 153 3.1.1 Classification 155 Definition: 157 Network-layer Traffic Control Mechanisms 159 Selection of packets based on the contents of packet header 160 according to defined rules. 162 Discussion: 163 Packets can be selected based on the DS field or IP 164 Precedence in the packet header. Classification can also be 165 based on Multi-Field (MF) criteria such as IP Source and 166 destination addresses, protocol and port number. 168 Classification determines the per-hop behaviors and traffic 169 conditioning functions such as shaping and dropping that are 170 to be applied to the packet. 172 Measurement units: 173 n/a 175 See Also: 177 3.1.2 Codepoint Set 179 Definition: 180 The set of all DS Code-points or IP precedence values used 181 during the test duration. 183 Discussion: 184 Describes all the code-point markings associated with packets 185 that are input to the DUT/SUT. For each entry in the 186 codepoint set, there are associated vectors describing the 187 rate of traffic, delay, loss, or jitter containing that 188 particular DSCP or IP precedence value. 190 The treatment that a packet belonging to a particular code- 191 point gets is subject to the DUT classifying packets to map 192 to the correct PHB. Moreover, the forwarding treatment in 193 general is also dependent on the complete set of offered 194 vectors. 196 Measurement Units: 197 n/a 199 See Also: 201 3.1.3 Congestion 203 Definition: 204 A condition in which one or more egress interfaces are 205 offered more packets than are forwarded. 207 Discussion: 209 Network-layer Traffic Control Mechanisms 211 This condition is a superset of the overload definition [2]. 212 The overload definition assumes the congestion is introduced 213 strictly by the tester on ingress of a DUT/SUT. That may or 214 may not be the case here. 216 Another difference between congestion and overload occurs 217 when the SUT comprises multiple elements, in that congestion 218 may occur at multiple points. Consider an SUT comprising 219 multiple edge devices exchanging traffic with a single core 220 device. Depending on traffic patterns, the edge devices may 221 induce congestion on multiple egress interfaces on the core 222 device. In contrast, overload [1] deals only with overload on 223 ingress. 225 Throughput [1] defines the lower boundary of congestion. 226 Throughput is the maximum offered rate with no congestion. 227 At offered rates above throughput, the DUT/SUT is considered 228 congested. 230 Ingress observations alone are not sufficient to cover all 231 cases in which congestion may occur. A device with an 232 infinite amount of memory could buffer an infinite amount of 233 packets, and eventually forward all of them. However, these 234 packets may or may not be forwarded during the test duration. 235 Even though ingress interfaces accept all packets without 236 loss, this hypothetical device may still be congested. 238 The definition presented here explicitly defines congestion 239 as an event observable on egress interfaces. Regardless of 240 internal architecture, any device that cannot forward packets 241 on one or more egress interfaces is congested. 243 Measurement units: 244 none 246 See Also: 247 Gateway Congestion Control Survey [8] 249 3.1.4 Congestion Management 251 Definition: 252 An implementation of one or more per-hop-behaviors to avoid 253 or minimize the condition of congestion. 255 Discussion: 256 Congestion management may seek either to control congestion 257 or avoid it altogether. Such mechanisms classify packets 258 based upon IP Precedence or DSCP settings in a packet's IP 259 header. 261 Network-layer Traffic Control Mechanisms 263 Congestion avoidance mechanisms seek to prevent congestion 264 before it actually occurs. 266 Congestion control mechanisms gives one or flows (with a 267 discrete IP Precedence or DSCP value) preferential treatment 268 over other classes during periods of congestion. 270 Measurement units: 271 n/a 273 See Also: 275 3.1.5 Flow 277 Definition: 278 A flow is a one or more of packets sharing a common intended 279 pair of source and destination interfaces. 281 Discussion: 282 Packets are grouped by the ingress and egress interfaces they 283 use on a given DUT/SUT. 285 A flow can contain multiple source IP addresses and/or 286 destination IP addresses. All packets in a flow must enter 287 on the same ingress interface and exit on the same egress 288 interface, and have some common network layer content. 290 Microflows [3] are a subset of flows. As defined in [3], 291 microflows require application-to-application measurement. In 292 contrast, flows use lower-layer classification criteria. 293 Since this document focuses on network-layer classification 294 criteria, we concentrate here on the use of network-layer 295 identifiers in describing a flow. Flow identifiers also may 296 reside at the data-link, transport, or application layers of 297 the ISO model. However, identifiers other than those at the 298 network layer are out of scope for this document. 300 A flow may contain a single code point/IP precedence value or 301 may contain multiple values destined for a single egress 302 interface. This is determined by the test methodology. 304 Measurement units: 305 n/a 307 See Also: 308 Microflow [3] 309 Streams 310 Network-layer Traffic Control Mechanisms 312 3.2 Measurement Terms 314 3.2.1 Channel Capacity 316 Definition: 317 The maximum forwarding rate [2] at which none of the offered 318 packets are dropped by the DUT/SUT. 320 Discussion: 321 Channel capacity measures the packet rate at the egress 322 interface(s) of the DUT/SUT. In contrast, throughput as 323 defined in RFC 1242 measures the packet rate is based on the 324 ingress interface(s) of the DUT/SUT. 326 Ingress-based measurements do not account for congestion of 327 the DUT/SUT. Channel capacity, as an egress measurement, does 328 take congestion into account. 330 Understanding channel capacity is a necessary precursor to 331 any measurement involving congestion. Throughput numbers can 332 be higher than channel capacity because of queueing. 334 This measurement differs from forwarding rate at maximum 335 offered load (FRMOL) [2] in that it is intolerant of loss. 337 Measurement units: 338 N-octet packets per second 340 See Also: 341 Throughput [1] 342 Forwarding Rate at Maximum Offered Load [2] 344 3.2.2 Conforming 346 Definition: 347 Packets which lie within specific rate, delay, or jitter 348 bounds. 350 Discussion: 351 A DUT/SUT may be configured to allow a given traffic class to 352 consume a given amount of bandwidth, or to fall within 353 Network-layer Traffic Control Mechanisms 355 predefined delay or jitter boundaries. All packets that lie 356 within specified bounds are then said to be conforming, 357 whereas those outside the bounds are nonconforming. 359 Measurement units: 360 n/a 362 See Also: 363 Expected Vector 364 Forwarding Vector 365 Offered Vector 366 Nonconforming 368 3.2.3 Nonconforming 370 Definition: 371 Packets that do not lie within specific rate, delay, or 372 jitter bounds. 374 Discussion: 375 A DUT/SUT may be configured to allow a given traffic class to 376 consume a given amount of bandwidth, or to fall within 377 predefined delay or jitter boundaries. All packets that do 378 not lie within these bounds are then said to be 379 nonconforming. 381 Measurement units: 382 n/a 384 See Also: 385 Expected Vector 386 Forwarding Vector 387 Offered Vector 388 Conforming 390 3.2.4 Delay 392 Definition: 393 The time interval starting when the last bit of the input IP 394 packet reaches the input port of the DUT/SUT and ending when 395 the last bit of the output IP packet is seen on the output 396 port of the DUT/SUT. 398 Discussion: 399 Delay is measured the same regardless of the type of DUT/SUT. 400 Latency [1] require some knowledge of whether the DUT/SUT is 401 a "store and forward" or a "bit forwarding" device. The fact 402 that a DUT/SUT's technology has a lower delay than another 403 technology should be visible. 405 Network-layer Traffic Control Mechanisms 407 By specifying the metric to be inside the Internet protocol, 408 the tester is relieved from specifying the start/end for 409 every data link layer protocol that IP runs on. This avoids 410 determining if the start/end delimiters are included in the 411 frame. Also heterogeneous data link protocol can be used in 412 a test. 414 The measurement point at the end closely simulates the way an 415 internet datagram is processed. An internet datagram is not 416 passed up or down the stack unless it is complete. 417 Completion occurs once the last bit of the IP packet has been 418 received. 420 Delay can be run at any offered load. Recommend at or below 421 the channel capacity for non-congested delay. For congested 422 delay, run the offered load above the channel capacity. 424 Measurement units: 425 Seconds. 427 See Also: 428 Latency [1] 430 3.2.5 Jitter 432 Definition: 433 The absolute value of the difference between the arrival 434 delay of two consecutive packets belonging to the same 435 stream. 437 Discussion: 438 The delay fluctuation between two consecutive packets in a 439 stream is reported as the jitter. Jitter can be expressed as 440 |D(i) - D(i-1)| where D equals the delay and i is the test 441 sequence number. The measurement does not include lost 442 packets. 444 Jitter can be determined by the ipdv [6] (IP Delay Variation) 445 by taking the absolute value of the ipdv. The two metrics 446 will produce different mean values. _Mean Jitter_ will 447 produce a positive value, where the _mean ipdv_ is typically 448 zero. 450 Measurement units: 451 Seconds 453 See Also: 454 Jitter variation [5] 455 ipdv [6] 456 interarrival jitter [7] 457 Network-layer Traffic Control Mechanisms 459 3.2.6 Undifferentiated Response 461 Definition: 462 The vector(s) obtained when mechanisms used to support diff- 463 serv or IP precedence are disabled. 465 Discussion: 466 Enabling diff-serv or IP precedence mechanisms may impose 467 additional processing overhead for packets. This overhead may 468 degrade performance even when traffic belonging to only one 469 class, the best-effort class, is offered to the device. 471 Measurements with "undifferentiated response" should be made 472 to establish a baseline. 474 The vector(s) obtained with DSCPs or IP precedence enabled 475 can be compared to the undifferentiated response to determine 476 the effect of differentiating traffic. 478 Measurement units: 479 n/a 481 3.3 Sequence Tracking 483 3.3.1 In-sequence Packet 485 Definition: 486 A received packet with the expected Test Sequence number. 488 Discussion: 489 In-sequence is done on a stream level. As packets are 490 received on a stream, each packet's Test Sequence number is 491 compared with the previous packet. Only packets that match 492 the expected are considered in-sequence. 494 Packets that do not match the expected Test Sequence number 495 are counted as _not in-sequence_ or out-of-sequence. Every 496 packet that is received is either in-sequence or out-of- 497 sequence. Subtracting the in-sequence from the received 498 packets (for that stream) can derive the out-of-sequence 499 count. 501 Two types of events will prevent the in-sequence from 502 incrementing: packet loss and reordered packets. 504 Measurement units: 505 Packet count 506 Network-layer Traffic Control Mechanisms 508 See Also: 509 Stream 510 Test Sequence number 512 3.3.2 Out-of-order Packet 514 Definition: 515 A received packet with a Test Sequence number less that 516 expected. 518 Discussion: 519 As a stream of packets enter a DUT/SUT, they include a Stream 520 Test Sequence number indicating the order the packets were 521 sent to the DUT/SUT. On exiting the DUT/SUT, these packets 522 may arrive in a different order. Each packet that was re- 523 ordered is counted as an Out-of-order Packet. 525 Certain streaming protocol (such as TCP) require the packets 526 to be in a certain order. Packets outside this are dropped 527 by the streaming protocols even though there were properly 528 received by the IP layer. The type of reordering tolerated 529 by a streaming protocol varies from protocol to protocol, and 530 also by implementation. 532 Out-of-order Packet count is based on the worst case 533 streaming protocol. It allows for no reordering. 535 Packet loss does not affect the Out-of-order Packet count. 536 Only packets that were not received in the order that they 537 were transmitted. 539 Measurement units: 540 Packet count 542 See Also: 543 Stream 544 Test Sequence number 546 3.3.3 Duplicate Packet 548 Definition: 549 A received packet with a Test Sequence number matching a 550 previously received packet. 552 Discussion: 554 Measurement units: 555 Packet count 556 Network-layer Traffic Control Mechanisms 558 See Also: 559 Stream 560 Test Sequence number 562 3.3.4 Stream 564 Definition: 565 A group of packets tracked as a single entity by the traffic 566 receiver. A stream may share a common content such as type 567 (IP, UDP), packet size, or payload. 569 Discussion: 570 Streams are tracked by test sequence number or "unique 571 signature field" (RFC 2889). Streams define how individual 572 packet's statistics are grouped together to form an 573 intelligible summary. 575 Common stream groupings would be by egress interface, 576 destination address, source address, DSCP, or IP precedence. 577 A stream using test sequence numbers can track the ordering 578 of packets as they transverse the DUT/SUT. 580 Streams are not restricted to a pair of source and 581 destination interfaces as long as all packets are tracked as 582 a single entity. A mulitcast stream can be forward to 583 multiple destination interfaces. 585 Measurement units: 586 n/a 588 See Also: 589 Flow 590 MicroFlow [3] 591 Test sequence number 593 3.3.6 Test Sequence number 595 Definition: 596 A field in the IP payload portion of the packet that is used 597 to verify the order of the packets on the egress of the 598 DUT/SUT. 600 Discussion: 601 The traffic generator sets the test sequence number value and 602 the traffic receiver checks the value upon receipt of the 603 packet. The traffic generator changes the value on each 604 Network-layer Traffic Control Mechanisms 606 packet transmitted based on an algorithm agreed to by the 607 traffic receiver. 609 The traffic receiver keeps track of the sequence numbers on a 610 per stream basis. In addition to number of received packets, 611 the traffic receiver may also report number of in-sequence 612 packets, number of out-sequence packets, number of duplicate 613 packets, and number of reordered packets. 615 The recommended algorithm to use to change the sequence 616 number on sequential packets is an incrementing value. 618 Measurement units: 619 n/a 621 See Also: 622 Stream 624 3.4 Vectors 625 A vector is a group of packets all containing a specific DSCP 626 or IP precedence value. Vectors are expressed as a pair of 627 numbers. The first is being the particular diff-serv value. 628 The second is the metric expressed as a rate, loss 629 percentage, delay, or jitter. 631 3.4.1 Intended Vector 633 Definition: 635 A vector describing the rate at which packets having a 636 specific code-point (or IP precedence) that an external 637 source attempts to transmit to a DUT/SUT. 639 Discussion: 640 Intended loads across the different code-point classes 641 determine the metrics associated with a specific code-point 642 traffic class. 644 Measurement Units: 645 N-octets packets per second 647 See Also: 648 Offered Vector 649 Expected Forwarding Vector 650 Expected Loss Vector 651 Expected Sequence Vector 652 Expected Delay Vector 653 Expected Jitter Vector 654 Forwarding Vector 655 Network-layer Traffic Control Mechanisms 657 Loss Vector 659 3.4.2 Offered Vector 661 Definition: 662 A vector describing the measured rate at which packets having 663 a specific DSCP or IP precedence value are offered to the 664 DUT/SUT. 666 Discussion: 667 Offered loads across the different code-point classes, 668 constituting a code-point set, determine the metrics 669 associated with a specific code-point traffic class. 671 Measurement Units: 672 N-octets packets per second 674 See Also: 675 Expected Forwarding Vector 676 Expected Loss Vector 677 Expected Sequence Vector 678 Expected Delay Vector 679 Expected Jitter Vector 680 Forwarding Vector 681 Codepoint Set 683 3.4.3 Expected Vectors 685 3.4.3.1 Expected Forwarding Vector 687 Definition: 688 A vector describing the expected output rate of packets 689 having a specific DSCP or IP precedence value. The value is 690 dependent on the set of offered vectors and configuration of 691 the DUT. 693 Discussion: 694 The DUT is configured in a certain way in order that service 695 differentiation occurs for a particular DSCP or IP precedence 696 value when a specific traffic mix consisting of multiple 697 DSCPs or IP precedence values are applied. This term attempts 698 to capture the expected forwarding behavior when subjected to 699 a certain offered vectors. 701 The actual algorithm or mechanism the DUT uses to achieve 702 service differentiation is not important in describing the 703 expected forwarding vector. 705 Measurement units: 706 N-octet packets per second 707 Network-layer Traffic Control Mechanisms 709 See Also: 710 Intended Vector 711 Offered Vector 712 Output Vectors 713 Expected Loss Vector 714 Expected Sequence Vector 715 Expected Delay Vector 716 Expected Jitter Vector 718 3.4.3.2 Expected Loss Vector 720 Definition: 721 A vector describing the percentage of packets, having a 722 specific DSCP or IP precedence value, that should not be 723 forwarded. The value is dependent on the set of offered 724 vectors and configuration of the DUT. 726 Discussion: 727 The DUT is configured in a certain way in order that service 728 differentiation occurs for a particular DSCP or IP precedence 729 value when a specific traffic mix consisting of multiple 730 DSCPs or IP precedence values are applied. This term attempts 731 to capture the expected forwarding behavior when subjected to 732 a certain offered vectors. 734 The actual algorithm or mechanism the DUT uses to achieve 735 service differentiation is not important in describing the 736 expected loss vector. 738 Measurement Units: 739 Percentage of intended packets that are expected to be 740 dropped. 742 See Also: 743 Intended Vector 744 Offered Vector 745 Expected Forwarding Vector 746 Expected Sequence Vector 747 Expected Delay Vector 748 Expected Jitter Vector 750 3.2.3.3 Expected Sequence Vector 752 Definition: 754 Network-layer Traffic Control Mechanisms 756 A vector describing the expected in-sequence packets having a 757 specific DSCP or IP precedence value. The value is dependent 758 on the set of offered vectors and configuration of the DUT. 760 Discussion: 761 The DUT is configured in a certain way in order that service 762 differentiation occurs for a particular DSCP or IP precedence 763 value when a specific traffic mix consisting of multiple 764 DSCPs or IP precedence values are applied. This term attempts 765 to capture the expected forwarding behavior when subjected to 766 a certain offered vectors. 768 The actual algorithm or mechanism the DUT uses to achieve 769 service differentiation is not important in describing the 770 expected sequence vector. 772 Measurement Units: 773 N-octet packets per second 775 See Also: 776 Intended Vector 777 Offered Vector 778 Output Vectors 779 Expected Loss Vector 780 Expected Forwarding Vector 781 Expected Delay Vector 782 Expected Jitter Vector 784 3.4.3.4 Expected Instantaneous Delay Vector 786 Definition: 787 A vector describing the expected delay for packets having a 788 specific DSCP or IP precedence value. The value is dependent 789 on the set of offered vectors and configuration of the DUT. 791 Discussion: 792 The DUT is configured in a certain way in order that service 793 differentiation occurs for a particular DSCP or IP precedence 794 value when a specific traffic mix consisting of multiple 795 DSCPs or IP precedence values are applied. This term attempts 796 to capture the expected forwarding behavior when subjected to 797 a certain offered vectors. 799 The actual algorithm or mechanism the DUT uses to achieve 800 service differentiation is not important in describing the 801 expected delay vector. 803 Measurement units: 804 Seconds. 806 See Also: 808 Network-layer Traffic Control Mechanisms 810 Intended Vector 811 Offered Vector 812 Output Vectors 813 Expected Loss Vector 814 Expected Sequence Vector 815 Expected Forwarding Vector 816 Expected Jitter Vector 818 3.4.3.5 Expected Average Delay Vector 820 Definition: 821 A vector describing the expected average delay for packets 822 having a specific DSCP or IP precedence value. The value is 823 dependent on the set of offered vectors and configuration of 824 the DUT. 826 Discussion: 827 The DUT is configured in a certain way in order that service 828 differentiation occurs for a particular DSCP or IP precedence 829 value when a specific traffic mix consisting of multiple 830 DSCPs or IP precedence values are applied. This term attempts 831 to capture the expected forwarding behavior when subjected to 832 a certain offered vectors. 834 The actual algorithm or mechanism the DUT uses to achieve 835 service differentiation is not important in describing the 836 expected average delay vector. 838 Measurement units: 839 Seconds. 841 See Also: 842 Intended Vector 843 Offered Vector 844 Output Vectors 845 Expected Loss Vector 846 Expected Sequence Vector 847 Expected Forwarding Vector 848 Expected Jitter Vector 850 3.4.3.6 Expected Maximum Delay Vector 852 Definition: 853 A vector describing the expected maximum delay for packets 854 having a specific DSCP or IP precedence value. The value is 855 dependent on the set of offered vectors and configuration of 856 the DUT. 858 Discussion: 859 The DUT is configured in a certain way in order that service 860 differentiation occurs for a particular DSCP or IP precedence 861 Network-layer Traffic Control Mechanisms 863 value when a specific traffic mix consisting of multiple 864 DSCPs or IP precedence values are applied. This term attempts 865 to capture the expected forwarding behavior when subjected to 866 a certain offered vectors. 868 The actual algorithm or mechanism the DUT uses to achieve 869 service differentiation is not important in describing the 870 expected maximum delay vector. 872 Measurement units: 873 Seconds. 875 See Also: 876 Intended Vector 877 Offered Vector 878 Output Vectors 879 Expected Loss Vector 880 Expected Sequence Vector 881 Expected Forwarding Vector 882 Expected Jitter Vector 884 3.4.3.7 Expected Minimum Delay Vector 886 Definition: 887 A vector describing the expected minimum delay for packets 888 having a specific DSCP or IP precedence value. The value is 889 dependent on the set of offered vectors and configuration of 890 the DUT. 892 Discussion: 893 The DUT is configured in a certain way in order that service 894 differentiation occurs for a particular DSCP or IP precedence 895 value when a specific traffic mix consisting of multiple 896 DSCPs or IP precedence values are applied. This term attempts 897 to capture the expected forwarding behavior when subjected to 898 a certain offered vectors. 900 The actual algorithm or mechanism the DUT uses to achieve 901 service differentiation is not important in describing the 902 expected minimum delay vector. 904 Measurement units: 905 Seconds. 907 See Also: 908 Intended Vector 909 Offered Vector 910 Output Vectors 911 Expected Loss Vector 912 Expected Sequence Vector 913 Expected Forwarding Vector 914 Network-layer Traffic Control Mechanisms 916 Expected Jitter Vector 918 3.2.3.8 Expected Instantaneous Jitter Vector 920 Definition: 921 A vector describing the expected jitter between two 922 consecutive packets' arrival times having a specific DSCP or 923 IP precedence value. The value is dependent on the set of 924 offered vectors and configuration of the DUT. 926 Discussion: 927 Instantaneous Jitter is the absolute value of the difference 928 between the delay measurement of two packets belonging to the 929 same stream. 931 The delay fluctuation between two consecutive packets in a 932 stream is reported as the "Instantaneous Jitter". 933 Instantaneous Jitter can be expressed as |D(i) - D(i-1)| 934 where D equals the delay and i is the test sequence number. 935 Packets lost are not counted in the measurement. 937 Forwarding Vector may contain several Jitter Vectors. For n 938 packets received in a Forwarding Vector, there is a total of 939 (n-1) Instantaneous Jitter Vectors. 941 Measurement units: 942 Seconds 944 See Also: 945 Delay 946 Jitter 947 Offered Vector 948 Output Vectors 949 Expected Average Jitter Vector 950 Expected Peak-to-peak Jitter Vector 951 Stream 953 3.2.3.9 Expected Average Jitter Vector 955 Definition: 956 A vector describing the expected jitter in packet arrival 957 times for packets having specific DSCP or IP precedence 958 value. The value is dependent on the set of offered vectors 959 and configuration of the DUT. 961 Discussion: 962 Average Jitter Vector is the average of all the Instantaneous 963 Jitter Vectors measured during the test duration for the same 964 DSCP or IP precedence value. 966 Network-layer Traffic Control Mechanisms 968 Measurement units: 969 Seconds 971 See Also: 972 Intended Vector 973 Offered Vector 974 Output Vectors 975 Expected Instantaneous Jitter Vector 976 Expected Peak-to-peak Jitter Vector 978 3.2.3.10 Expected Peak-to-peak Jitter Vector 980 Definition: 981 A vector describing the expected maximum variation in the 982 delay of packet arrival times for packets having specific 983 DSCP or IP precedence value. The value is dependent on the 984 set of offered vectors and configuration of the DUT. 986 Discussion: 987 Peak-to-peak Jitter Vector is the maximum delay minus the 988 minimum delay of the packets (in a vector) forwarded by the 989 DUT/SUT. 991 Peak-to-peak Jitter is not derived from the Instantaneous 992 Jitter Vector. Peak-to-peak Jitter is based upon all the 993 packets during the test duration, not just two consecutive 994 packets. 996 Measurement units: 997 Seconds 999 See Also: 1000 Intended Vector 1001 Offered Vector 1002 Output Vectors 1003 Expected Instantaneous Jitter Vector 1004 Expected Average Jitter Vector 1006 3.4.4 Output Vectors 1008 3.4.4.1 Forwarding Vector 1009 Network-layer Traffic Control Mechanisms 1011 Definition: 1012 The number of packets per second for all packets containing a 1013 specific DSCP or IP precedence value that a device can be 1014 observed to successfully forward to the correct destination 1015 interface in response to an offered vector. 1017 Discussion: 1018 Forwarding Vector is expressed as pair of numbers. Both the 1019 specific DSCP (or IP precedence) value AND the packets per 1020 second value combine to make a vector. 1022 The Forwarding Vector represents packet rate based on its 1023 specific DSCP (or IP precedence) value. It is not 1024 necessarily based on a stream or flow. The Forwarding Vector 1025 may be expressed as per port of the DUT/SUT. However, it must 1026 be consistent with the Expected Forwarding Vector. 1028 Forwarding Vector is a per-hop measurement. The DUT/SUT may 1029 change the specific DSCP (or IP precedence) value for a 1030 multiple-hop measurement. 1032 Measurement units: 1033 N-octet packets per second 1035 See Also: 1036 Intended Vector 1037 Offered Vector 1038 Expected Vectors 1039 Loss Vector 1040 Sequence Vector 1041 Delay Vectors 1043 3.4.4.2 Loss Vector 1045 Definition: 1046 The percentage of packets containing specific DSCP or IP 1047 precedence value that a DUT/SUT did not transmit to the 1048 correct destination interface in response to an offered 1049 vector. 1051 Discussion: 1052 Loss Vector is expressed as pair of numbers. Both the 1053 specific DSCP (or IP precedence) value AND the percentage 1054 value combine to make a vector. 1056 The Loss Vector represents percentage based on a specific 1057 DSCP or IP precedence value. It is not necessarily based on 1058 a stream or flow. The Loss Vector may be expressed as per 1059 port of the DUT/SUT. However, it must be consistent with the 1060 Expected Loss Vector 1061 Network-layer Traffic Control Mechanisms 1063 Loss Vector is a per-hop measurement. The DUT/SUT may change 1064 the specific DSCP or IP precedence value for a multiple-hop 1065 measurement. 1067 Measurement Units: 1068 Percentage of offered packets that are not forwarded. 1070 See Also: 1071 Intended Vector 1072 Offered Vector 1073 Expected Vectors 1074 Forwarding Vector 1075 Sequence Vector 1076 Delay Vectors 1078 3.4.4.3 Sequence Vector 1080 Definition: 1081 The number of packets per second for all packets containing a 1082 specific DSCP or IP precedence value that a device can be 1083 observed to transmit in sequence to the correct destination 1084 interface in response to an offered vector. 1086 Discussion: 1087 Sequence Vector is expressed as pair of numbers. Both the 1088 specific DSCP (or IP precedence) value AND the packets per 1089 second value combine to make a vector. 1091 The Sequence Vector represents packet rate based on its 1092 specific DSCP or IP precedence value. It is not necessarily 1093 based on a stream or flow. The Sequence Vector may be 1094 expressed as per port of the DUT/SUT. However, it must be 1095 consistent with the Expected Sequence Vector. 1097 Sequence Vector is a per-hop measurement. The DUT/SUT may 1098 change the specific DSCP or IP precedence value for a 1099 multiple-hop measurement. 1101 Measurement Units: 1102 N-octet packets per second 1104 Issues: 1106 See Also: 1107 In-sequence Packet 1108 Intended Vector 1109 Offered Vector 1110 Expected Vectors 1111 Loss Vector 1112 Forwarding Vector 1113 Network-layer Traffic Control Mechanisms 1115 Delay Vectors 1117 3.4.4.4 Instantaneous Delay Vector 1119 Definition: 1120 The delay for a packet containing specific DSCP or IP 1121 precedence value that a device can be observed to 1122 successfully transmit to the correct destination interface in 1123 response to an offered vector. 1125 Discussion: 1126 Instantaneous Delay vector is expressed as pair of numbers. 1127 Both the specific DSCP (or IP precedence) value AND delay 1128 value combine to make a vector. 1130 The Instantaneous Delay Vector represents delay on its 1131 specific DSCP or IP precedence value. It is not necessarily 1132 based on a stream or flow. The Delay vector may be expressed 1133 as per port of the DUT/SUT. However, it must be consistent 1134 with the Expected Delay vectors. 1136 Instantaneous Delay Vector is a per-hop measurement. The 1137 DUT/SUT may change the specific DSCP or IP precedence value 1138 for a multiple-hop measurement. 1140 Instantaneous Delay vector can be obtained at any offered 1141 load. Recommend at or below the channel capacity in the 1142 absence of congestion. For congested delay, run the offered 1143 load above the channel capacity. 1145 Forwarding Vector may contain several Instantaneous Delay 1146 Vectors. For every packet received in a Forwarding Vector, 1147 there is a corresponding Instantaneous Delay Vector. 1149 Measurement Units: 1150 Seconds 1152 See Also: 1153 Delay 1154 Intended Vector 1155 Offered Vector 1156 Expected Delay Vectors 1157 Average Delay Vector 1158 Maximum Delay Vector 1159 Minimum Delay Vector 1161 3.4.4.5 Average Delay Vector 1163 Definition: 1165 Network-layer Traffic Control Mechanisms 1167 The average delay for packets containing specific DSCP or IP 1168 precedence value that a device can be observed to 1169 successfully transmit to the correct destination interface in 1170 response to an offered vector. 1172 Discussion: 1173 Average Delay vector is expressed as pair of numbers. Both 1174 the specific DSCP (or IP precedence) value AND delay value 1175 combine to make a vector. 1177 The Delay Vector represents delay on its specific DSCP or IP 1178 precedence value. It is not necessarily based on a stream or 1179 flow. The Delay vector may be expressed as per port of the 1180 DUT/SUT. However, it must be consistent with the Expected 1181 Delay vector. 1183 The Average Delay Vector is computed by averaging all the 1184 Instantaneous Delay Vectors for a given vector. 1186 Average Delay Vector is a per-hop measurement. The DUT/SUT 1187 may change the specific DSCP or IP precedence value for a 1188 multiple-hop measurement. 1190 Average Delay vector can be obtained at any offered load. 1191 Recommend at or below the channel capacity in the absence of 1192 congestion. For congested delay, run the offered load above 1193 the channel capacity. 1195 Measurement Units: 1196 Seconds 1198 See Also: 1199 Delay 1200 Intended Vector 1201 Offered Vector 1202 Expected Delay Vectors 1203 Instantaneous Delay Vector 1204 Maximum Delay Vector 1205 Minimum Delay Vector 1207 3.4.4.6 Maximum Delay Vector 1209 Definition: 1210 The maximum delay from all packets containing specific DSCP 1211 or IP precedence value that a device can be observed to 1212 successfully transmit to the correct destination interface in 1213 response to an offered vector. 1215 Discussion: 1217 Network-layer Traffic Control Mechanisms 1219 Maximum Delay vector is expressed as pair of numbers. Both 1220 the specific DSCP (or IP precedence) value AND delay value 1221 combine to make a vector. 1223 The Maximum Delay Vector represents delay on its specific 1224 DSCP or IP precedence value. It is not necessarily based on 1225 a stream or flow. The Maximum Delay vector may be expressed 1226 as per port of the DUT/SUT. However, it must be consistent 1227 with the Expected Delay vector. 1229 Maximum Delay Vector is based upon the maximum Instantaneous 1230 Delay Vector of all packets in a Forwarding Vector. 1232 Maximum Delay Vector is a per-hop measurement. The DUT/SUT 1233 may change the specific DSCP or IP precedence value for a 1234 multiple-hop measurement. 1236 Measurement Units: 1237 Seconds 1239 See Also: 1240 Delay 1241 Intended Vector 1242 Offered Vector 1243 Expected Delay Vectors 1244 Instantaneous Delay Vector 1245 Forwarding Vector 1246 Average Delay Vector 1247 Minimum Delay Vector 1249 3.4.4.7 Minimum Delay Vector 1251 Definition: 1252 The minimum delay from all packets containing specific DSCP 1253 or IP precedence value that a device can be observed to 1254 successfully transmit to the correct destination interface in 1255 response to an offered vector. 1257 Discussion: 1258 Delay vector is expressed as pair of numbers. Both the 1259 specific DSCP (or IP precedence) value AND delay value 1260 combine to make a vector. 1262 The Minimum Delay Vector represents delay on its specific 1263 DSCP or IP precedence value. It is not necessarily based on 1264 a stream or flow. The Minimum Delay vector may be expressed 1265 as per port of the DUT/SUT. However, it must be consistent 1266 with the Expected Delay vector. 1268 Minimum Delay Vector is based upon the minimum Instantaneous 1269 Delay Vector of all packets in a Forwarding Vector. 1271 Network-layer Traffic Control Mechanisms 1273 Minimum Delay Vector is a per-hop measurement. The DUT/SUT 1274 may change the specific DSCP or IP precedence value for a 1275 multiple-hop measurement. 1277 Minimum Delay vector can be obtained at any offered load. 1278 Recommend at or below the channel capacity in the absence of 1279 congestion. For congested delay, run the offered load above 1280 the channel capacity. 1282 Measurement Units: 1283 Seconds 1285 See Also: 1286 Delay 1287 Intended Vector 1288 Offered Vector 1289 Expected Delay Vectors 1290 Instantaneous Delay Vector 1291 Forwarding Vector 1292 Average Delay Vector 1293 Maximum Delay Vector 1295 3.4.4.8 Instantaneous Jitter Vector 1297 Definition: 1298 The jitter for two consecutive packets containing specific 1299 DSCP or IP precedence value that a device can be observed to 1300 successfully transmit to the correct destination interface in 1301 response to an offered vector. 1303 Discussion: 1304 Instantaneous Jitter is the absolute value of the difference 1305 between the delay measurement of two packets belonging to the 1306 same stream. 1308 Jitter vector is expressed as pair of numbers. Both the 1309 specific DSCP (or IP precedence) value AND jitter value 1310 combine to make a vector. 1312 The delay fluctuation between two consecutive packets in a 1313 stream is reported as the "Instantaneous Jitter". 1314 Instantaneous Jitter Vector can be expressed as |D(i) - D(i- 1315 1)| where D equals the delay and i is the test sequence 1316 number. Packets lost are not counted in the measurement. 1318 Instantaneous Jitter Vector is a per-hop measurement. The 1319 DUT/SUT may change the specific DSCP or IP precedence value 1320 for a multiple-hop measurement. 1322 Network-layer Traffic Control Mechanisms 1324 Forwarding Vector may contain several Instantaneous Jitter 1325 Vectors. For n packets received in a Forwarding Vector, 1326 there are exactly (n-1) Instantaneous Jitter Vectors. 1328 Measurement units: 1329 Seconds 1331 See Also: 1332 Delay 1333 Jitter 1334 Forwarding Vector 1335 Stream 1336 Expected Vectors 1337 Average Jitter Vector 1338 Peak-to-peak Jitter Vector 1340 3.4.4.9 Average Jitter Vector 1342 Definition: 1343 The average jitter for packets containing specific DSCP or IP 1344 precedence value that a device can be observed to 1345 successfully transmit to the correct destination interface in 1346 response to an offered vector. 1348 Discussion: 1349 Average Jitter Vector is the average of all the Instantaneous 1350 Jitter Vectors of the same DSCP or IP precedence value, 1351 measured during the test duration. 1353 Average Jitter vector is expressed as pair of numbers. Both 1354 the specific DSCP (or IP precedence) value AND jitter value 1355 combine to make a vector. 1357 Average Jitter vector is a per-hop measurement. The DUT/SUT 1358 may change the specific DSCP or IP precedence value for a 1359 multiple-hop measurement. 1361 Measurement units: 1362 Seconds 1364 See Also: 1365 Jitter 1366 Forwarding Vector 1367 Stream 1368 Expected Vectors 1369 Instantaneous Jitter Vector 1370 Peak-to-peak Jitter Vector 1372 3.4.4.10 Peak-to-peak Jitter Vector 1373 Network-layer Traffic Control Mechanisms 1375 Definition: 1376 The maximum possible variation in the delay for packets 1377 containing specific DSCP or IP precedence value that a device 1378 can be observed to successfully transmit to the correct 1379 destination interface in response to an offered vector. 1381 Discussion: 1382 Peak-to-peak Jitter Vector is the maximum delay minus the 1383 minimum delay of the packets (in a vector) forwarded by the 1384 DUT/SUT. 1386 Jitter vector is expressed as pair of numbers. Both the 1387 specific DSCP (or IP precedence) value AND jitter value 1388 combine to make a vector. 1390 Peak-to-peak Jitter is not derived from the Instantaneous 1391 Jitter Vector. Peak-to-peak Jitter is based upon all the 1392 packets during the test duration, not just two consecutive 1393 packets. 1395 Measurement units: 1396 Seconds 1398 See Also: 1399 Jitter 1400 Forwarding Vector 1401 Stream 1402 Expected Vectors 1403 Average Jitter Vector 1404 Peak-to-peak Jitter Vector 1405 Network-layer Traffic Control Mechanisms 1407 4. Security Considerations 1409 Documents of this type do not directly affect the security of 1410 the Internet or of corporate networks as long as benchmarking 1411 is not performed on devices or systems connected to 1412 production networks. 1414 Packets with unintended and/or unauthorized DSCP or IP 1415 precedence values may present security issues. Determining 1416 the security consequences of such packets is out of scope for 1417 this document. 1419 5. References 1421 [1] Bradner, S., Editor, "Benchmarking Terminology for 1422 Network Interconnection Devices", RFC 1242, July 1991. 1424 [2] Mandeville, R., "Benchmarking Terminology for LAN 1425 Switching Devices", RFC 2285, February 1998. 1427 [3] K. Nichols, S. Blake, F. Baker, D. Black,"Definition of 1428 the Differentiated Services Field (DS Field) in the IPv4 1429 and IPv6 Headers", RFC 2474, December 1998. 1431 [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 1432 Weiss, "An Architecture for Differentiated Services", RFC 1433 2475, December 1998. 1435 [5] V. Jacobson, K. Nichols, K. Poduri, _An Expedited 1436 Forwarding PHB_, RFC 2598, June 1999 1438 [6] C. Demichelis, P. Chimento, _IP Packet Delay Variation 1439 Metric for IPPM_, draft-ietf-ippm-ipdv-10.txt 1441 [7] H. Schulzrinne, GMD Fokus, S. Casner, R. Frederick, 1442 V. Jacobson, _RTP: A Transport Protocol for Real-Time 1443 Applications_, RFC 1889, January 1996 1445 [8] A. Mankin, K. Ramakrishnan, _Gateway Congestion Control 1446 Survey_, RFC 1254, August 1991 1447 Network-layer Traffic Control Mechanisms 1449 6. Authors' Address 1451 Jerry Perser 1452 Spirent Communications 1453 26750 Agoura Road 1454 Calabasas, CA 91302 1455 USA 1457 Phone: + 1 818 676 2300 1458 EMail: jerry.perser@spirentcom.com 1460 David Newman 1461 Network Test 1462 31324 Via Colinas, Suite 113 1463 Westlake Village, CA 91362 1464 USA 1466 Phone: + 1 818 889 0011, x10 1467 EMail: dnewman@networktest.com 1469 Sumit Khurana 1470 Telcordia Technologies 1471 445 South Street 1472 Morristown, NJ 07960 1473 USA 1475 Phone: + 1 973 829 3170 1476 EMail: sumit@research.telcordia.com 1478 Shobha Erramilli 1479 QNetworx Inc 1480 1119 Campus Drive West 1481 Morganville NJ 07751 1482 USA 1484 Phone: 1485 EMail: shobha@qnetworx.com 1487 Scott Poretsky 1488 Avici Systems 1489 101 Billerica Ave_Building #6 1490 N. Billerica, MA 01862 1491 USA 1493 Phone: + 1 978 964 2287 1494 EMail: sporetsky@avici.com 1495 Network-layer Traffic Control Mechanisms 1497 7. Full Copyright Statement 1499 Copyright (C) The Internet Society (1998). All Rights 1500 Reserved. 1502 This document and translations of it may be copied and 1503 furnished to others, and derivative works that comment on or 1504 otherwise explain it or assist in its implementation may be 1505 prepared, copied, published and distributed, in whole or in 1506 part, without restriction of any kind, provided that the 1507 above copyright notice and this paragraph are included on all 1508 such copies and derivative works. However, this document 1509 itself may not be modified in any way, such as by removing 1510 the copyright notice or references to the Internet Society or 1511 other Internet organizations, except as needed for the 1512 purpose of developing Internet standards in which case the 1513 procedures for copyrights defined in the Internet Standards 1514 process must be followed, or as required to translate it into 1515 languages other than English. 1517 The limited permissions granted above are perpetual and will 1518 not be revoked by the Internet Society or its successors or 1519 assigns. This document and the information contained herein 1520 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 1521 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1522 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1523 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1524 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1525 FITNESS FOR A PARTICULAR PURPOSE.