draft-ietf-bmwg-dsmterm-13.txt | rfc4689.txt | |||
---|---|---|---|---|
Network Working Group Scott Poretsky | Network Working Group S. Poretsky | |||
INTERNET-DRAFT Reef Point Systems | Request for Comments: 4689 Reef Point Systems | |||
Expires in: December 2006 | Category: Informational J. Perser | |||
Jerry Perser | Veriwave | |||
Veriwave | S. Erramilli | |||
Telcordia | ||||
Shobha Erramilli | S. Khurana | |||
Telcordia | Motorola | |||
October 2006 | ||||
Sumit Khurana | ||||
Telcordia | ||||
June 2006 | ||||
Terminology for Benchmarking Network-layer | ||||
Traffic Control Mechanisms | ||||
<draft-ietf-bmwg-dsmterm-13.txt> | ||||
Intellectual Property Rights (IPR) statement: | ||||
By submitting this Internet-Draft, each author represents that any | ||||
applicable patent or other IPR claims of which he or she is aware | ||||
have been or will be disclosed, and any of which he or she becomes | ||||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
Status of this Memo | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as | ||||
Internet-Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | Terminology for Benchmarking Network-layer Traffic Control Mechanisms | |||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | Status of This Memo | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | This memo provides information for the Internet community. It does | |||
http://www.ietf.org/shadow.html. | not specify an Internet standard of any kind. Distribution of this | |||
memo is unlimited. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
This document describes terminology for the benchmarking of | ||||
devices that implement traffic control using packet classification | ||||
based on defined criteria. The terminology is to be applied to | ||||
measurements made on the data plane to evaluate IP traffic control | ||||
mechanisms. Rules for packet classification can be based on any | ||||
field in the IP header, such as DSCP, or field in the packet | ||||
payload, such as port number. | ||||
Network-layer Traffic Control Mechanisms | This document describes terminology for the benchmarking of devices | |||
that implement traffic control using packet classification based on | ||||
defined criteria. The terminology is to be applied to measurements | ||||
made on the data plane to evaluate IP traffic control mechanisms. | ||||
Rules for packet classification can be based on any field in the IP | ||||
header, such as the Differentiated Services Code Point (DSCP), or any | ||||
field in the packet payload, such as port number. | ||||
Table of Contents | Table of Contents | |||
1. Introduction .............................................. 3 | ||||
2. Existing definitions ...................................... 3 | ||||
3. Term definitions............................................4 | ||||
3.1 Configuration Terms | ||||
3.1.1 Classification.........................................4 | ||||
3.1.2 Codepoint Set..........................................4 | ||||
3.1.3 Forwarding Congestion..................................5 | ||||
3.1.4 Congestion Management..................................6 | ||||
3.1.5 Flow...................................................7 | ||||
3.2 Measurement Terms | ||||
3.2.1 Forwarding Capacity....................................7 | ||||
3.2.2 Conforming Packet......................................8 | ||||
3.2.3 Nonconforming Packet...................................9 | ||||
3.2.4 Forwarding Delay.......................................9 | ||||
3.2.5 Jitter................................................11 | ||||
3.2.6 Undifferentiated Response.............................11 | ||||
3.3 Sequence Tracking | ||||
3.3.1 In-sequence Packet....................................12 | ||||
3.3.2 Out-of-order Packet...................................12 | ||||
3.3.3 Duplicate Packet......................................13 | ||||
3.3.4 Stream................................................14 | ||||
3.3.5 Test Sequence number .................................15 | ||||
3.4 Vectors...................................................15 | ||||
3.4.1 Intended Vector.......................................15 | ||||
3.4.2 Offered Vector........................................16 | ||||
3.4.3 Expected Vectors......................................16 | ||||
3.4.4 Output Vectors........................................23 | ||||
4. IANA Considerations........................................31 | ||||
5. Security Considerations....................................31 | ||||
6. Acknowledgments............................................31 | ||||
7. References.................................................32 | ||||
8. Author's Address...........................................33 | ||||
9. Full Copyright Statement...................................34 | ||||
1. Introduction | 1. Introduction ....................................................2 | |||
2. Existing Definitions ............................................3 | ||||
3. Term Definitions ................................................4 | ||||
3.1. Configuration Terms ........................................4 | ||||
3.1.1. Classification ......................................4 | ||||
3.1.2. Codepoint Set .......................................4 | ||||
3.1.3. Forwarding Congestion ...............................5 | ||||
3.1.4. Congestion Management ...............................6 | ||||
3.1.5. Flow ................................................7 | ||||
3.2. Measurement Terms ..........................................7 | ||||
3.2.1. Forwarding Capacity .................................7 | ||||
3.2.2. Conforming Packet ...................................8 | ||||
3.2.3. Nonconforming Packet ................................9 | ||||
3.2.4. Forwarding Delay ....................................9 | ||||
3.2.5. Jitter .............................................11 | ||||
3.2.6. Undifferentiated Response ..........................11 | ||||
3.3. Sequence Tracking .........................................12 | ||||
3.3.1. Test Sequence Number ...............................12 | ||||
3.3.2. Stream .............................................12 | ||||
3.3.3. In-Sequence Packet .................................13 | ||||
3.3.4. Out-of-Order Packet ................................14 | ||||
3.3.5. Duplicate Packet ...................................14 | ||||
3.4. Vectors ...................................................15 | ||||
3.4.1. Intended Vector ....................................15 | ||||
3.4.2. Offered Vector .....................................16 | ||||
3.4.3. Expected Vectors ...................................16 | ||||
3.4.4. Output Vectors .....................................23 | ||||
4. Security Considerations ........................................30 | ||||
5. Acknowledgements ...............................................30 | ||||
6. References .....................................................31 | ||||
6.1. Normative References ......................................31 | ||||
6.2. Informative References ....................................31 | ||||
New terminology is needed because most existing measurements | 1. Introduction | |||
assume the absence of congestion and only a single per-hop- | ||||
behavior. This document introduces several new terms that will | ||||
allow measurements to be taken during periods of congestion. | ||||
Another key difference from existing terminology is the definition | New terminology is needed because most existing measurements assume | |||
of measurements as observed on egress as well as ingress of a | the absence of congestion and only a single per-hop behavior. This | |||
device/system under test. Again, the existence of congestion | document introduces several new terms that will allow measurements to | |||
requires the addition of egress measurements as well as those | be taken during periods of congestion. | |||
taken on ingress; without observing traffic leaving a | ||||
device/system it is not possible to say whether traffic-control | ||||
mechanisms effectively dealt with congestion. | ||||
Network-layer Traffic Control Mechanisms | Another key difference from existing terminology is the definition of | |||
measurements as observed on egress and ingress of a device/system | ||||
under test. Again, the existence of congestion requires the addition | ||||
of egress measurements, as well as of those taken on ingress; without | ||||
observing traffic leaving a device/system, it is not possible to say | ||||
whether traffic-control mechanisms effectively dealt with congestion. | ||||
The principal measurements introduced in this document are vectors | The principal measurements introduced in this document are vectors | |||
for rate, delay, and jitter, all of which can be observed with or | for rate, delay, and jitter, all of which can be observed with or | |||
without congestion of the Device Under Test (DUT)/ System Under | without congestion of the Device Under Test (DUT)/System Under Test | |||
Test (SUT). This document describes only those terms relevant to | (SUT). This document describes only those terms relevant to | |||
measuring behavior of a DUT or SUT at the Egress during periods of | measuring behavior of a DUT or SUT at the egress during periods of | |||
congestion. End-to-end and service-level measurements are beyond | congestion. End-to-end and service-level measurements are beyond the | |||
the scope of this document. | scope of this document. | |||
2. Existing definitions | 2. Existing Definitions | |||
RFC 1224 "Techniques for Managing Asynchronously Generated Alerts" | ||||
[St91] is used for 'Time with fine enough units to distinguish | ||||
between two events' | ||||
RFC 1242 "Benchmarking Terminology for Network Interconnect | RFC 1224, "Techniques for Managing Asynchronously Generated Alerts" | |||
Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching | [St91], is used for 'Time with fine enough units to distinguish | |||
Devices" should be consulted before attempting to make use of this | between two events'. | |||
document. | ||||
RFC 2474 "Definition of the Differentiated Services Field (DS | RFC 1242, "Benchmarking Terminology for Network Interconnect | |||
Field) in the IPv4 and IPv6 Headers" section 2, contains | Devices", and RFC 2285, "Benchmarking Terminology for LAN Switching | |||
discussions of a number of terms relevant to network-layer traffic | Devices", should be consulted before attempting to make use of this | |||
control mechanisms and should also be consulted. | document. | |||
For the sake of clarity and continuity this RFC adopts the | RFC 2474, "Definition of the Differentiated Services Field (DS Field) | |||
template for definitions set out in Section 2 of RFC 1242. | in the IPv4 and IPv6 Headers", section 2, contains discussions of a | |||
Definitions are indexed and grouped together in sections for ease | number of terms relevant to network-layer traffic control mechanisms | |||
of reference. | and should also be consulted. | |||
For the sake of clarity and continuity, this RFC adopts the template | ||||
for definitions set out in Section 2 of RFC 1242. Definitions are | ||||
indexed and grouped together in sections for ease of reference. | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in BCP 14, RFC 2119 | document are to be interpreted as described in BCP 14, RFC 2119 | |||
[Br97]. RFC 2119 defines the use of these key words to help make the | [Br97]. RFC 2119 defines the use of these key words to help make the | |||
intent of standards track documents as clear as possible. While this | intent of standards track documents as clear as possible. While this | |||
document uses these keywords, this document is not a standards track | document uses these keywords, this document is not a standards track | |||
document. | document. | |||
2.1 Frequently Used Acronyms | 2.1. Frequently Used Acronyms | |||
DA Destination Address | ||||
DS DiffServ | ||||
DSCP DiffServ Code Point | ||||
DUT Device Under Test | ||||
IP Internet Protocol | ||||
PHB Per Hop Behavior | ||||
SA Source Address | ||||
SUT System Under Test | ||||
Network-layer Traffic Control Mechanisms | ||||
3. Term definitions | DA Destination Address | |||
DS DiffServ | ||||
DSCP DiffServ Code Point | ||||
DUT Device Under Test | ||||
IP Internet Protocol | ||||
PHB Per Hop Behavior | ||||
SA Source Address | ||||
SUT System Under Test | ||||
3.1 Configuration Terms | 3. Term Definitions | |||
3.1.1 Classification | 3.1. Configuration Terms | |||
Definition: | 3.1.1. Classification | |||
Selection of packets according to defined rules. | ||||
Discussion: | Definition: | |||
Classification determines the per-hop behaviors and traffic | Selection of packets according to defined rules. | |||
conditioning functions such as shaping and dropping that | ||||
are to be applied to the packet. | ||||
Classification of packets can be made based on the DS field | Discussion: | |||
or IP Precedence in the packet header. Classification can | Classification determines the per-hop behaviors and traffic | |||
be based on other IP header fields such as IP Source | conditioning functions, such as shaping and dropping, that are to | |||
Address (SA), Destination Address (DA), and protocol, or | be applied to the packet. | |||
fields in the packet payload such as port number. | ||||
Classification can also be based on ingress interface. | ||||
It is possible to classify based on Multi-Field (MF) | ||||
criteria such as IP source and destination addresses, | ||||
protocol and port number. | ||||
Measurement units: n/a | Classification of packets can be based on the DS field or IP | |||
Precedence in the packet header. Classification can be based on | ||||
other IP header fields, such as IP Source Address (SA), | ||||
Destination Address (DA), and protocol, or on fields in the packet | ||||
payload, such as port number. Classification can also be based on | ||||
ingress interface. It is possible to base classification on | ||||
Multi-Field (MF) criteria such as IP source and destination | ||||
addresses, protocol, and port number. For further discussion of | ||||
packet classification and its network applications, see [Bl98]. | ||||
See Also: None | Measurement units: | |||
n/a | ||||
3.1.2 Codepoint Set | See Also: | |||
None | ||||
Definition: | 3.1.2. Codepoint Set | |||
The set of all DS Code-points or IP precedence values used | ||||
during the test duration. | ||||
Discussion: | Definition: | |||
Describes all the code-point markings associated with packets | The set of all DS Code-points or IP precedence values used during | |||
that are input to the DUT/SUT. For each entry in the | the test duration. | |||
codepoint set, there are associated vectors describing the | ||||
rate of traffic, delay, loss, or jitter containing that | ||||
particular DSCP or IP precedence value. | ||||
The treatment that a packet belonging to a particular code- | Discussion: | |||
point gets is subject to the DUT classifying packets to map | Describes all the code-point markings associated with packets that | |||
to the correct PHB. Moreover, the forwarding treatment in | are input to the DUT/SUT. For each entry in the codepoint set, | |||
general is also dependent on the complete set of offered | there are associated vectors describing the rate of traffic, | |||
vectors. | delay, loss, or jitter containing that particular DSCP or IP | |||
precedence value. | ||||
Measurement Units: n/a | The treatment that a packet belonging to a particular code-point | |||
gets is subject to the DUT classifying packets to map to the | ||||
correct PHB. Moreover, the forwarding treatment in general is | ||||
also dependent on the complete set of offered vectors. | ||||
See Also: None | Measurement Units: | |||
Network-layer Traffic Control Mechanisms | n/a | |||
3.1.3 Forwarding Congestion | See Also: | |||
None | ||||
Definition: | 3.1.3. Forwarding Congestion | |||
A condition in which one or more egress interfaces are | ||||
offered more packets than are forwarded. | ||||
Discussion: | Definition: | |||
This condition is a superset of the overload definition | A condition in which one or more egress interfaces are offered | |||
[Ma98]. Overload [Ma98] deals with overloading input and | more packets than are forwarded. | |||
output interfaces beyond the maximum transmission allowed by | ||||
the medium. Forwarding congestion does not assume ingress | ||||
interface overload as the only source of overload on output | ||||
interfaces. | ||||
Another difference between Forwarding Congestion and overload | Discussion: | |||
occurs when the SUT comprises multiple elements, in that | This condition is a superset of the overload definition [Ma98]. | |||
Forwarding Congestion may occur at multiple points. Consider | Overload [Ma98] deals with overloading input and output interfaces | |||
a SUT comprising multiple edge devices exchanging traffic | beyond the maximum transmission allowed by the medium. Forwarding | |||
with a single core device. Depending on traffic patterns, | congestion does not assume ingress interface overload as the only | |||
the edge devices may induce Forwarding Congestion on multiple | source of overload on output interfaces. | |||
egress interfaces on the core device. | ||||
Throughput [Br91] defines the lower boundary of Forwarding | Another difference between Forwarding Congestion and overload | |||
Congestion. Throughput is the maximum offered rate with no | occurs when the SUT comprises multiple elements, in that | |||
Forwarding Congestion. At offered rates above throughput, | Forwarding Congestion may occur at multiple points. Consider an | |||
the DUT/SUT is considered to be in a state of Forwarding | SUT comprising multiple edge devices exchanging traffic with a | |||
Congestion. | single core device. Depending on traffic patterns, the edge | |||
devices may induce Forwarding Congestion on multiple egress | ||||
interfaces on the core device. | ||||
Packet Loss, not increased Forwarding Delay, is the | Throughput [Br91] defines the lower boundary of Forwarding | |||
external observable metric used to indicate the condition | Congestion. Throughput is the maximum offered rate with no | |||
of Forwarding Congestion. Packet Loss is a deterministic | Forwarding Congestion. At offered rates above throughput, the | |||
indicator of Forwarding Congestion. The condition of | DUT/SUT is considered to be in a state of Forwarding Congestion. | |||
increased Forwarding Delay without Packet Loss is an | ||||
indicator of Forwarding Congestion known as Incipient | ||||
Congestion. Incipient Congestion is a non-deterministic | ||||
indicator of Forwarding Congestion [Fl93]. As stated in | ||||
[Ec98], RED [Br98] detects incipient congestion before the | ||||
buffer overflows, but the current Internet environment is | ||||
limited to packet loss as the mechanism for indicating | ||||
congestion to the end-nodes. [Ra99] implies that it is | ||||
impractical to build a black-box test to observe Incipient | ||||
Congestion. [Ra99] instead introduces Explicit Congestion | ||||
Notification (ECN) as a deterministic Black-Box method for | ||||
observing Incipient Congestion. [Ra99] is an Experimental | ||||
RFC with limited deployment, so ECN is not used for this | ||||
particular methodology. For the purpose of "black-box" | ||||
testing a DUT/SUT, this methodology uses Packet Loss as the | ||||
indicator of Forwarding Congestion. | ||||
Network-layer Traffic Control Mechanisms | Packet Loss, not increased Forwarding Delay, is the external | |||
observable metric used to indicate the condition of Forwarding | ||||
Congestion. Packet Loss is a deterministic indicator of | ||||
Forwarding Congestion. The condition of increased Forwarding | ||||
Delay without Packet Loss is an indicator of Forwarding Congestion | ||||
known as Incipient Congestion. Incipient Congestion is a non- | ||||
deterministic indicator of Forwarding Congestion [Fl93]. As | ||||
stated in [Ec98], RED [Br98] detects incipient congestion before | ||||
the buffer overflows, but the current Internet environment is | ||||
limited to packet loss as the mechanism for indicating congestion | ||||
to the end-nodes. [Ra99] implies that it is impractical to build | ||||
a black-box test to observe Incipient Congestion. [Ra99] instead | ||||
introduces Explicit Congestion Notification (ECN) as a | ||||
deterministic Black-Box method for observing Incipient Congestion. | ||||
[Ra99] is an Experimental RFC with limited deployment, so ECN is | ||||
not used for this particular methodology. For the purpose of | ||||
"black-box" testing a DUT/SUT, this methodology uses Packet Loss | ||||
as the indicator of Forwarding Congestion. | ||||
Ingress observations alone are not sufficient to cover all | Ingress observations alone are not sufficient to cover all cases | |||
cases in which Forwarding Congestion may occur. A device | in which Forwarding Congestion may occur. A device with an | |||
with an infinite amount of memory could buffer an infinite | infinite amount of memory could buffer an infinite number of | |||
number of packets, and eventually forward all of them. | packets and eventually forward all of them. However, these | |||
However, these packets may or may not be forwarded during | packets may or may not be forwarded during the test duration. | |||
the test duration. Congestion Collapse [Na84] is defined | Congestion Collapse [Na84] is defined as the state in which | |||
as the state in which buffers are full and all arriving | buffers are full and all arriving packets MUST be dropped across | |||
packets MUST be dropped across the network. Even though | the network. Even though ingress interfaces accept all packets | |||
ingress interfaces accept all packets without loss, | without loss, Forwarding Congestion is present in this | |||
Forwarding Congestion is present in this hypothetical | hypothetical device. | |||
device. | ||||
The definition presented here explicitly defines | The definition presented here explicitly defines Forwarding | |||
Forwarding Congestion as an event observable on egress | Congestion as an event observable on egress interfaces. | |||
interfaces. Regardless of internal architecture, any | Regardless of internal architecture, any device exhibiting Packet | |||
device exhibiting Packet Loss on one or more egress | Loss on one or more egress interfaces is experiencing Forwarding | |||
interfaces is experiencing Forwarding Congestion. | Congestion. | |||
Measurement units: | Measurement units: | |||
None | None | |||
See Also: | See Also: | |||
Gateway Congestion Control Survey [Ma91] | Gateway Congestion Control Survey [Ma91] | |||
3.1.4 Congestion Management | 3.1.4. Congestion Management | |||
Definition: | Definition: | |||
An implementation of one or more per-hop-behaviors to avoid | An implementation of one or more per-hop behaviors to avoid or | |||
or minimize the condition of congestion. | minimize the condition of congestion. | |||
Discussion: | Discussion: | |||
Congestion management may seek either to control congestion | Congestion management may seek either to control congestion or | |||
or avoid it altogether through Classification. | avoid it altogether through Classification. | |||
Congestion avoidance mechanisms seek to prevent congestion | Congestion avoidance mechanisms seek to prevent congestion before | |||
before it actually occurs. | it actually occurs. | |||
Congestion control mechanisms give one or more flows (with a | Congestion control mechanisms give one or more flows (with a | |||
discrete IP Precedence or DSCP value) preferential treatment | discrete IP Precedence or DSCP value) preferential treatment over | |||
over other classes during periods of congestion. | other classes during periods of congestion. | |||
Measurement units: | Measurement units: | |||
n/a | n/a | |||
See Also: | See Also: | |||
Classification | Classification | |||
Network-layer Traffic Control Mechanisms | ||||
3.1.5 Flow | 3.1.5. Flow | |||
Definition: | Definition: | |||
A flow is a one or more of packets sharing a common intended | A flow is one or more packets sharing a common intended pair of | |||
pair of ingress and egress interfaces. | ingress and egress interfaces. | |||
Discussion: | Discussion: | |||
Packets are grouped by the ingress and egress interfaces they | Packets are grouped by the ingress and egress interfaces they use | |||
use on a given DUT/SUT. | on a given DUT/SUT. | |||
A flow can contain multiple source IP addresses and/or | A flow can contain multiple source IP addresses and/or destination | |||
destination IP addresses. All packets in a flow MUST enter | IP addresses. All packets in a flow MUST enter on the same | |||
on the same ingress interface and exit on the same egress | ingress interface and exit on the same egress interface and have | |||
interface, and have some common network layer content. | some common network layer content. | |||
Microflows [Ni98] are a subset of flows. As defined in | Microflows [Ni98] are a subset of flows. As defined in [Ni98], | |||
[Ni98], microflows require application-to-application | microflows require application-to-application measurement. In | |||
measurement. In contrast, flows use lower-layer | contrast, flows use lower-layer classification criteria. Since | |||
classification criteria. Since this document focuses on | this document focuses on network-layer classification criteria, it | |||
network-layer classification criteria, we concentrate here on | concentrates here on the use of network-layer identifiers in | |||
the use of network-layer identifiers in describing a flow. | describing a flow. Flow identifiers also may reside at the data- | |||
Flow identifiers also may reside at the data-link, transport, | link, transport, or application layers of the OSI model. However, | |||
or application layers of the OSI model. However, identifiers | identifiers other than those at the network layer are out of scope | |||
other than those at the network layer are out of scope for | for this document. | |||
this document. | ||||
A flow may contain a single code point/IP precedence value or | A flow may contain a single code point/IP precedence value or may | |||
may contain multiple values destined for a single egress | contain multiple values destined for a single egress interface. | |||
interface. This is determined by the test methodology. | This is determined by the test methodology. | |||
Measurement units: | Measurement units: | |||
n/a | n/a | |||
See Also: | See Also: | |||
Microflow [Ni98] | Microflow [Ni98] | |||
Streams | Streams | |||
3.2 Measurement Terms | 3.2. Measurement Terms | |||
3.2.1 Forwarding Capacity | 3.2.1. Forwarding Capacity | |||
Definition: | Definition: | |||
The number of packets per second that a device can be | The number of packets per second that a device can be observed to | |||
observed to successfully transmit to the correct destination | transmit successfully to the correct egress interface in response | |||
interface in response to a specified offered load while the | to a specified offered load while the device drops none of the | |||
device drops none of the offered packets. | offered packets. | |||
Discussion: | Discussion: | |||
Forwarding Capacity measures the packet rate at the egress | Forwarding Capacity measures the packet rate at the egress | |||
interface(s) of the DUT/SUT. In contrast, throughput as | interface(s) of the DUT/SUT. In contrast, throughput (as defined | |||
defined in RFC 1242 measures the packet rate at the ingress | in RFC 1242) measures the packet rate at the ingress interface(s) | |||
interface(s) of the DUT/SUT. | of the DUT/SUT. | |||
Network-layer Traffic Control Mechanisms | Ingress-based measurements do not account for queuing of the | |||
DUT/SUT. Throughput rates can be higher than the Forwarding | ||||
Capacity because of queueing. The difference is dependent upon | ||||
test duration, packet rate, and queue size. Forwarding Capacity, | ||||
as an egress measurement, does take queuing into account. | ||||
Ingress-based measurements do not account for queuing of the | Understanding Forwarding Capacity is a necessary precursor to any | |||
DUT/SUT. Throughput rates can be higher than the Forwarding | measurement involving Traffic Control Mechanisms. The | |||
Capacity because of queueing. The difference is dependent | accompanying methodology document MUST take into consideration | |||
upon test duration, packet rate, and queue size. Forwarding | Forwarding Capacity when determining the expected forwarding | |||
Capacity, as an egress measurement, does take queuing into | vectors. When the sum of the expected forwarding vectors on an | |||
account. | interface exceeds the Forwarding Capacity, the Forwarding Capacity | |||
will govern the forwarding rate. | ||||
Understanding Forwarding Capacity is a necessary precursor to | This measurement differs from forwarding rate at maximum offered | |||
any measurement involving Traffic Control Mechanisms. The | load (FRMOL) [Ma98] in that the Forwarding Capacity requires zero | |||
accompanying methodology document MUST take into | loss. | |||
consideration Forwarding Capacity when determining the | ||||
expected forwarding vectors. When the sum of the expected | ||||
forwarding vectors on an interface exceeds the Forwarding | ||||
Capacity, the Forwarding Capacity will govern the forwarding | ||||
rate. | ||||
This measurement differs from forwarding rate at maximum | Measurement units: | |||
offered load (FRMOL) [Ma98] in that Forwarding Capacity | N-octet packets per second | |||
requires zero loss. | ||||
Measurement units: | See Also: | |||
N-octet packets per second | Throughput [Br91] | |||
Forwarding Rate at Maximum Offered Load [Ma98] | ||||
See Also: | 3.2.2. Conforming Packet | |||
Throughput [Br91] | ||||
Forwarding Rate at Maximum Offered Load [Ma98] | ||||
3.2.2 Conforming Packet | Definition: | |||
Packets that lie within specific rate, delay, or jitter bounds. | ||||
Definition: | Discussion: | |||
Packets which lie within specific rate, delay, or jitter | A DUT/SUT may be configured to allow a given traffic class to | |||
bounds. | consume a given amount of bandwidth, or to fall within predefined | |||
delay or jitter boundaries. All packets that lie within specified | ||||
bounds are then said to be conforming, whereas those outside the | ||||
bounds are nonconforming. | ||||
Discussion: | Measurement units: | |||
A DUT/SUT may be configured to allow a given traffic class to | n/a | |||
consume a given amount of bandwidth, or to fall within | ||||
predefined delay or jitter boundaries. All packets that lie | ||||
within specified bounds are then said to be conforming, | ||||
whereas those outside the bounds are nonconforming. | ||||
Measurement units: | See Also: | |||
n/a | Expected Vector | |||
Forwarding Vector | ||||
Offered Vector | ||||
Nonconforming | ||||
See Also: | 3.2.3. Nonconforming Packet | |||
Expected Vector | ||||
Forwarding Vector | ||||
Offered Vector | ||||
Nonconforming | ||||
Network-layer Traffic Control Mechanisms | ||||
3.2.3 Nonconforming Packet | Definition: | |||
Packets that do not lie within specific rate, delay, or jitter | ||||
bounds. | ||||
Definition: | Discussion: | |||
Packets that do not lie within specific rate, delay, or | A DUT/SUT may be configured to allow a given traffic class to | |||
jitter bounds. | consume a given amount of bandwidth, or to fall within predefined | |||
delay or jitter boundaries. All packets that do not lie within | ||||
these bounds are then said to be nonconforming. | ||||
Discussion: | Measurement units: | |||
A DUT/SUT may be configured to allow a given traffic class to | n/a | |||
consume a given amount of bandwidth, or to fall within | ||||
predefined delay or jitter boundaries. All packets that do | ||||
not lie within these bounds are then said to be | ||||
nonconforming. | ||||
Measurement units: | See Also: | |||
n/a | Expected Vector | |||
Forwarding Vector | ||||
Offered Vector | ||||
Conforming | ||||
See Also: | 3.2.4. Forwarding Delay | |||
Expected Vector | ||||
Forwarding Vector | ||||
Offered Vector | ||||
Conforming | ||||
3.2.4 Forwarding Delay | Definition: | |||
The time interval starting when the last bit of the input IP | ||||
packet is offered to the input port of the DUT/SUT and ending when | ||||
the last bit of the output IP packet is received from the output | ||||
port of the DUT/SUT. | ||||
Definition: | Discussion: | |||
The time interval starting when the last bit of the input IP | The delay time interval MUST be externally observed. The delay | |||
packet is offered to the input port of the DUT/SUT and ending | measurement MUST NOT include delays added by test bed components | |||
when the last bit of the output IP packet is received from | other than the DUT/SUT, such as propagation time introduced by | |||
the output port of the DUT/SUT. | cabling or non-zero delay added by the test instrument. | |||
Forwarding Delay differs from latency [Br91] and one-way delay | ||||
[Al99] in several key regards: | ||||
Discussion: | 1. Latency [Br91] assumes knowledge of whether the DUT/SUT uses | |||
The delay time interval MUST be externally observed. The | "store and forward" or "bit forwarding" technology. Forwarding | |||
delay measurement MUST NOT include delays added by test bed | Delay is the same metric, measured the same way, regardless of | |||
components other than the DUT/SUT, such as propagation time | the architecture of the DUT/SUT. | |||
introduced by cabling or non-zero delay added by the test | ||||
instrument. Forwarding Delay differs from latency [Br91] | ||||
and one-way delay [Al99] in several key regards: | ||||
1. Latency [Br91] assumes knowledge of whether the DUT/SUT | 2. Forwarding Delay is a last-in, last-out (LILO) measurement, | |||
uses "store and forward" or "bit forwarding" technology. | unlike the last-in, first-out method [Br91] or the first-in, | |||
Forwarding Delay is the same metric, measured the same way, | last-out method [Al99]. | |||
regardless of the architecture of the DUT/SUT. | ||||
2. Forwarding Delay is a last-in, last-out (LILO) | The LILO method most closely simulates the way a network-layer | |||
measurement, unlike the last-in, first-out method [Br91] or | device actually processes an IP datagram. IP datagrams are not | |||
the first-in, last-out method [Al99]. | passed up and down the stack unless they are complete, and | |||
processing begins only once the last bit of the IP datagram has | ||||
been received. | ||||
The LILO method most closely simulates the way a network- | Further, the LILO method has an additive property, where the | |||
layer device actually processes an IP datagram. IP datagrams | sum of the parts MUST equal the whole. This is a key | |||
are not passed up and down the stack unless they are | difference from [Br91] and [Al99]. For example, the delay | |||
complete, and processing begins only once the last bit of the | added by two DUTs MUST equal the sum of the delay of the DUTs. | |||
IP datagram has been received. | This may or may not be the case with [Br91] and [Al99]. | |||
Network-layer Traffic Control Mechanisms | 3. Forwarding Delay measures the IP datagram only, unlike [Br91], | |||
which also includes link-layer overhead. | ||||
Further, the LILO method has an additive property, where the | A metric focused exclusively on the Internet protocol relieves | |||
sum of the parts MUST equal the whole. This is a key | the tester from specifying the start/end for every link-layer | |||
difference from [Br91] and [Al99]. For example, the delay | protocol that IP runs on. This avoids the need to determine | |||
added by two DUTs MUST equal the sum of the delay of the | whether the start/stop delimiters are included. It also allows | |||
DUTs. This may or may not be the case with [Br91] and | the use of heterogeneous link-layer protocols in a test. | |||
[Al99]. | ||||
3. Forwarding Delay measures the IP datagram only, unlike | 4. Forwarding Delay can be measured at any offered load, whereas | |||
[Br91], which also includes link layer overhead. | the latency methodology [Br99] recommends measurement at, and | |||
only at, the throughput level. Comparing the Forwarding Delay | ||||
below the throughput to Forwarding Delay above the Forwarding | ||||
Capacity will give insight to the traffic control mechanisms. | ||||
A metric focused exclusively on the Internet protocol | For example, non-congested delay may be measured with an | |||
relieves the tester from specifying the start/end for every | offered load that does not exceed the Forwarding Capacity, | |||
link layer protocol that IP runs on. This avoids the need to | while congested delay may involve an offered load that exceeds | |||
determine whether the start/stop delimiters are included. It | the Forwarding Capacity. | |||
also allows the use of heterogeneous link layer protocols in | ||||
a test. | ||||
4. Forwarding Delay can be measured at any offered load, | Note: Forwarding Delay SHOULD NOT be used as an absolute | |||
whereas the latency methodology [Br99] recommends measurement | indicator of DUT/SUT Forwarding Congestion. While Forwarding | |||
at, and only at, the throughput level. Comparing the | Delay may rise when offered load nears or exceeds the | |||
Forwarding Delay below the throughput to Forwarding Delay | Forwarding Capacity, there is no universal point at which | |||
above the Forwarding Capacity will give insight to the | Forwarding Delay can be said to indicate the presence or | |||
traffic control mechanisms. | absence of Forwarding Congestion. | |||
For example, non-congested delay may be measured with an | Measurement units: | |||
offered load that does not exceed the Forwarding Capacity, | milliseconds | |||
while congested delay may involve an offered load that | ||||
exceeds Forwarding Capacity. | ||||
Note: Forwarding Delay SHOULD NOT be used as an absolute | See Also: | |||
indicator of DUT/SUT Forwarding Congestion. While Forwarding | Latency [Br91] | |||
Delay may rise when offered load nears or exceeds Forwarding | Latency [Al99] | |||
Capacity, there is no universal point at which Forwarding | One-way Delay [Br99] | |||
Delay can be said to indicate the presence or absence of | ||||
Forwarding Congestion. | ||||
Measurement units: | 3.2.5. Jitter | |||
milliseconds | ||||
See Also: | Definition: | |||
Latency [Br91] | The absolute value of the difference between the Forwarding Delay | |||
Latency [Al99] | of two consecutive received packets belonging to the same stream. | |||
One-way Delay [Br99] | ||||
Network-layer Traffic Control Mechanisms | ||||
3.2.5 Jitter | Discussion: | |||
The Forwarding Delay fluctuation between two consecutive received | ||||
packets in a stream is reported as the jitter. Jitter can be | ||||
expressed as |D(i) - D(i-1)|, where D equals the Forwarding Delay | ||||
and i is the order the packets were received. | ||||
Definition: | Under loss, jitter can be measured between non-consecutive test | |||
The absolute value of the difference between the arrival | sequence numbers. When IP Traffic Control Mechanisms are dropping | |||
delay of two consecutive received packets belonging to the | packets, fluctuating Forwarding Delay may be observed. Jitter | |||
same stream. | MUST be able to benchmark the delay variation independently of | |||
packet loss. | ||||
Discussion: | Jitter is related to the IPDV [De02] (IP Delay Variation) by | |||
The Forwarding Delay fluctuation between two consecutive | taking the absolute value of the ipdv. The two metrics will | |||
received packets in a stream is reported as the Jitter. | produce different mean values. Mean Jitter will produce a | |||
Jitter can be expressed as |D(i) - D(i-1)| where D equals | positive value, where the mean ipdv is typically zero. Also, IPDV | |||
the Forwarding Delay and i is the order the packets were | is undefined when one packet from a pair is lost. | |||
received. | ||||
Under loss, jitter can be measured between non-consecutive | Measurement units: | |||
test sequence numbers. When IP Traffic Control Mechanisms | milliseconds | |||
are dropping packets, fluctuating Forwarding Delay may be | ||||
observed. Jitter MUST be able to benchmark the delay | ||||
variation independent of packet loss. | ||||
Jitter is related to the IPDV [De02] (IP Delay Variation) by | See Also: | |||
taking the absolute value of the ipdv. The two metrics will | Forwarding Delay | |||
produce different mean values. Mean Jitter will produce a | Jitter variation [Ja99] | |||
positive value, where the mean ipdv is typically zero. Also, | ipdv [De02] | |||
IPDV is undefined when one packet from a pair is lost. | interarrival jitter [Sc96] | |||
Measurement units: | 3.2.6. Undifferentiated Response | |||
milliseconds | ||||
See Also: | Definition: | |||
Forwarding Delay | The vector(s) obtained when mechanisms used to support diff-serv | |||
Jitter variation [Ja99] | or IP precedence are disabled. | |||
ipdv [De02] | ||||
interarrival jitter [Sc96] | ||||
3.2.6 Undifferentiated Response | Discussion: | |||
Enabling diff-serv or IP precedence mechanisms may impose | ||||
additional processing overhead for packets. This overhead may | ||||
degrade performance even when traffic belonging to only one class, | ||||
the best-effort class, is offered to the device. Measurements | ||||
with "undifferentiated response" SHOULD be made to establish a | ||||
baseline. | ||||
Definition: | The vector(s) obtained with DSCP or IP precedence enabled can be | |||
The vector(s) obtained when mechanisms used to support | compared to the undifferentiated response to determine the effect | |||
diff-serv or IP precedence are disabled. | of differentiating traffic. | |||
Discussion: | Measurement units: | |||
Enabling diff-serv or IP precedence mechanisms may impose | n/a | |||
additional processing overhead for packets. This overhead | ||||
may degrade performance even when traffic belonging to only | ||||
one class, the best-effort class, is offered to the device. | ||||
Measurements with "undifferentiated response" SHOULD be made | ||||
to establish a baseline. | ||||
Network-layer Traffic Control Mechanisms | 3.3. Sequence Tracking | |||
The vector(s) obtained with DSCP or IP precedence enabled can | 3.3.1. Test Sequence Number | |||
be compared to the undifferentiated response to determine the | ||||
effect of differentiating traffic. | ||||
Measurement units: | Definition: | |||
n/a | A field in the IP payload portion of the packet that is used to | |||
verify the order of the packets on the egress of the DUT/SUT. | ||||
3.3 Sequence Tracking | Discussion: | |||
The traffic generator sets the test sequence number value. Upon | ||||
receipt of the packet, the traffic receiver checks the value. | ||||
The traffic generator changes the value on each packet transmitted | ||||
based on an algorithm agreed to by the traffic receiver. | ||||
3.3.1 In-sequence Packet | The traffic receiver keeps track of the sequence numbers on a | |||
per-stream basis. In addition to the number of received packets, | ||||
the traffic receiver may also report the number of in-sequence | ||||
packets, the number of out-of-sequence packets, the number of | ||||
duplicate packets, and the number of reordered packets. The | ||||
RECOMMENDED algorithm to change the sequence number on sequential | ||||
packets is an incrementing value. | ||||
Definition: | Measurement units: | |||
A received packet with the expected Test Sequence number. | n/a | |||
Discussion: | See Also: | |||
In-sequence is done on a stream level. As packets are | Stream | |||
received on a stream, each packets Test Sequence number is | ||||
compared with the previous packet. Only packets that match | ||||
the expected Test Sequence number are considered in-sequence. | ||||
Packets that do not match the expected Test Sequence number | 3.3.2. Stream | |||
are counted as "not in-sequence" or out-of-sequence. Every | ||||
packet that is received is either in-sequence or out-of- | ||||
sequence. Subtracting the in-sequence from the received | ||||
packets (for that stream), the tester can derive the | ||||
out-of-sequence count. | ||||
Two types of events will prevent the in-sequence from | Definition: | |||
incrementing: packet loss and reordered packets. | A group of packets tracked as a single entity by the traffic | |||
receiver. A stream MUST share common content, such as type (IP, | ||||
UDP), IP SA/DA, packet size, or payload. | ||||
Measurement units: | Discussion: | |||
Packet count | Streams are tracked by test sequence number or "unique signature | |||
field" [Ma00]. Streams define how individual packet statistics | ||||
are grouped together to form an intelligible summary. | ||||
See Also: | Common stream groupings would be by egress interface, destination | |||
Stream | address, source address, DSCP, or IP precedence. A stream using | |||
Test Sequence number | test sequence numbers can track the ordering of packets as they | |||
traverse the DUT/SUT. | ||||
3.3.2 Out-of-order Packet | Streams are not restricted to a pair of source and destination | |||
interfaces as long as all packets are tracked as a single entity. | ||||
A multicast stream can be forwarded to multiple destination | ||||
interfaces. | ||||
Definition: | Measurement units: | |||
A received packet with a sequence number less than | n/a | |||
the sequence number of a previously arriving packet. | ||||
Network-layer Traffic Control Mechanisms | See Also: | |||
Flow | ||||
Microflow [Ni98] | ||||
Test sequence number | ||||
Discussion: | 3.3.3. In-Sequence Packet | |||
As a stream of packets enters a DUT/SUT, they include a | ||||
Stream Test Sequence number indicating the order the packets | ||||
were sent to the DUT/SUT. On exiting the DUT/SUT, these | ||||
packets may arrive in a different order. Each packet that | ||||
was re-ordered is counted as an Out-of-order Packet. | ||||
Certain streaming protocol (such as TCP) require the packets | Definition: | |||
to be in a certain order. Packets outside this are dropped | A received packet with the expected Test Sequence number. | |||
by the streaming protocols even though there were properly | ||||
received by the IP layer. The type of reordering tolerated | ||||
by a streaming protocol varies from protocol to protocol, and | ||||
also by implementation. | ||||
Packet loss does not affect the Out-of-order Packet count. | Discussion: | |||
Only packets that were not received in the order that they | In-sequence is done on a stream level. As packets are received on | |||
were transmitted. | a stream, each packet's Test Sequence number is compared with the | |||
previous packet. Only packets that match the expected Test | ||||
Sequence number are considered in-sequence. | ||||
Measurement units: | Packets that do not match the expected Test Sequence number are | |||
packets | counted as "not in-sequence" or out-of-sequence. Every packet | |||
that is received is either in-sequence or out-of-sequence. | ||||
Subtracting the in-sequence from the received packets (for that | ||||
stream), the tester can derive the out-of-sequence count. | ||||
See Also: | Two types of events will prevent the in-sequence from | |||
Stream | incrementing: packet loss and reordered packets. | |||
Test Sequence number | ||||
Packet Reordering Metric for IPPM [Mo03] | ||||
3.3.3 Duplicate Packet | Measurement units: | |||
Packet count | ||||
Definition: | See Also: | |||
A received packet with a Test Sequence number matching a | Stream | |||
previously received packet. | Test Sequence number | |||
Discussion: | 3.3.4. Out-of-Order Packet | |||
A Duplicate Packet is a packet that the DUT/SUT has | ||||
successfully transmitted out an egress interface more than | ||||
once. The egress interface has previously forwarded this | ||||
packet. | ||||
A Duplicate Packet SHOULD be a bit for bit copy of an already | Definition: | |||
transmitted packet (including Test Sequence number). If the | A received packet with a sequence number less than the sequence | |||
Duplicate Packet traversed different paths through the | number of any previously arriving packet. | |||
DUT/SUT, some fields (such as TTL or checksum) may have | ||||
changed. | ||||
A multicast packet is not a Duplicate Packet by definition. | Discussion: | |||
For a given IP multicast group, a DUT/SUT SHOULD forward a | As a stream of packets enters a DUT/SUT, they include a Stream | |||
packet once on a given egress interface provided the path to | Test Sequence number indicating the order the packets were sent to | |||
one or more multicast receivers is through that interface. | the DUT/SUT. On exiting the DUT/SUT, these packets may arrive in | |||
Several egress interfaces will transmit the same packet, but | a different order. Each packet that was reordered is counted as | |||
only once per interface. | an Out-of-Order Packet. | |||
Network-layer Traffic Control Mechanisms | Certain streaming protocols (such as TCP) require the packets to | |||
be in a certain order. Packets outside this are dropped by the | ||||
streaming protocols even though they were properly received by the | ||||
IP layer. The type of reordering tolerated by a streaming | ||||
protocol varies from protocol to protocol, and also by | ||||
implementation. | ||||
To detect a Duplicate Packet, each offered packet to the | Packet loss does not affect the Out-of-Order Packet count. The | |||
DUT/SUT MUST contain a unique packet-by-packet identifier. | Out-of-Order Packet count is impacted only by packets that were | |||
not received in the order that they were transmitted. | ||||
Measurement units: | Measurement units: | |||
Packet count | packets | |||
See Also: | See Also: | |||
Stream | Stream | |||
Test Sequence number | Test Sequence number | |||
Packet Reordering Metric for IPPM [Mo03] | ||||
3.3.4 Stream | 3.3.5. Duplicate Packet | |||
Definition: | Definition: | |||
A group of packets tracked as a single entity by the traffic | A received packet with a Test Sequence number matching a | |||
receiver. A stream MUST share common content such as type | previously received packet. | |||
(IP, UDP), IP SA/DA, packet size, or payload. | ||||
Discussion: | Discussion: | |||
Streams are tracked by test sequence number or "unique | A Duplicate Packet is a packet that the DUT/SUT has successfully | |||
signature field" [Ma00]. Streams define how individual | transmitted out an egress interface more than once. The egress | |||
packets statistic are grouped together to form an | interface has previously forwarded this packet. | |||
intelligible summary. | ||||
Common stream groupings would be by egress interface, | A Duplicate Packet SHOULD be a bit-for-bit copy of an already | |||
destination address, source address, DSCP, or IP precedence. | transmitted packet (including Test Sequence number). If the | |||
A stream using test sequence numbers can track the ordering | Duplicate Packet traversed different paths through the DUT/SUT, | |||
of packets as they traverse the DUT/SUT. | some fields (such as TTL or checksum) may have changed. | |||
Streams are not restricted to a pair of source and | A multicast packet is not a Duplicate Packet by definition. For a | |||
destination interfaces as long as all packets are tracked as | given IP multicast group, a DUT/SUT SHOULD forward a packet once | |||
a single entity. A multicast stream can be forwarded to | on a given egress interface provided the path to one or more | |||
multiple destination interfaces. | multicast receivers is through that interface. Several egress | |||
interfaces will transmit the same packet, but only once per | ||||
interface. | ||||
Measurement units: | To detect a Duplicate Packet, each packet offered to the DUT/SUT | |||
n/a | MUST contain a unique packet-by-packet identifier. | |||
See Also: | Measurement units: | |||
Flow | Packet count | |||
Microflow [Ni98] | ||||
Test sequence number | ||||
Network-layer Traffic Control Mechanisms | ||||
3.3.5 Test Sequence Number | See Also: | |||
Definition: | Stream | |||
A field in the IP payload portion of the packet that is used | Test Sequence number | |||
to verify the order of the packets on the egress of the | ||||
DUT/SUT. | ||||
Discussion: | 3.4. Vectors | |||
The traffic generator sets the test sequence number value and | ||||
the traffic receiver checks the value upon receipt of the | ||||
packet. The traffic generator changes the value on each | ||||
packet transmitted based on an algorithm agreed to by the | ||||
traffic receiver. | ||||
The traffic receiver keeps track of the sequence numbers on a | A vector is a group of packets all matching a specific | |||
per stream basis. In addition to number of received packets, | classification criteria, such as DSCP. Vectors are | |||
the traffic receiver may also report the number of | identified by the classification criteria and benchmarking | |||
in-sequence packets, number of out-of-sequence packets, | metrics, such as a Forwarding Capacity, Forwarding Delay, | |||
number of duplicate packets, and number of reordered packets. | or Jitter. | |||
The RECOMMENDED algorithm to use to change the sequence | ||||
number on sequential packets is an incrementing value. | ||||
Measurement units: | 3.4.1. Intended Vector | |||
n/a | ||||
See Also: | Definition: | |||
Stream | A description of the configuration on an external source | |||
for the attempted rate of a stream transmitted to a DUT/SUT | ||||
matching specific classification rules. | ||||
3.4 Vectors | Discussion: | |||
A vector is a group of packets all matching a specific | The Intended Vector of a stream influences the benchmark | |||
classification criteria, such as DSCP. Vectors are | measurements. The Intended Vector is described by the | |||
identified by the classification criteria and benchmarking | classification criteria and attempted rate. | |||
metrics such as a Forwarding Capacity, Forwarding Delay, | ||||
or Jitter. | ||||
3.4.1 Intended Vector | Measurement Units: | |||
Definition: | N-bytes packets per second | |||
A description of the configuration on an external source | ||||
for the attempted rate of a stream transmitted to a DUT/SUT | ||||
matching specific classification rules. | ||||
Discussion: | See Also: | |||
The Intended Vector of a stream influences the benchmark | Stream | |||
measurements. The Intended Vector is described by the | Offered Vector | |||
classification criteria and attempted rate. | Forwarding Vector | |||
Measurement Units: | 3.4.2. Offered Vector | |||
N-bytes packets per second | ||||
See Also: | Definition: | |||
Stream | A description for the attempted rate of a stream offered to | |||
Offered Vector | a DUT/SUT matching specific classification rules. | |||
Forwarding Vector | ||||
Network-layer Traffic Control Mechanisms | ||||
3.4.2 Offered Vector | Discussion: | |||
The Offered Vector of a stream influences the benchmark | ||||
measurements. The Offered Vector is described by the | ||||
classification criteria and offered rate. | ||||
Definition: | Measurement Units: | |||
A description for the attempted rate of a stream offered to | N-bytes packets per second | |||
a DUT/SUT matching specific classification rules. | ||||
Discussion: | See Also: | |||
The Offered Vector of a stream influences the benchmark | Stream | |||
measurements. The Offered Vector is described by the | Intended Vector | |||
classification criteria and offered rate. | Forwarding Vector | |||
Measurement Units: | 3.4.3. Expected Vectors | |||
N-bytes packets per second | ||||
See Also: | 3.4.3.1. Expected Forwarding Vector | |||
Stream | ||||
Intended Vector | ||||
Forwarding Vector | ||||
3.4.3 Expected Vectors | Definition: | |||
3.4.3.1 Expected Forwarding Vector | A description of the expected output rate of packets matching a | |||
specific classification, such as DSCP. | ||||
Definition: | Discussion: | |||
A description of the expected output rate of packets | The value of the Expected Forwarding Vector is dependent on the | |||
matching a specific classification, such as DSCP. | set of offered vectors and Classification configuration on the | |||
DUT/SUT. The DUT is configured in a certain way so that | ||||
classification occurs when a traffic mix consisting of multiple | ||||
streams is applied. | ||||
Discussion: | This term captures the expected forwarding behavior from the DUT | |||
The value of the Expected Minimum Delay Vector is dependent | receiving multiple Offered Vectors. The actual algorithm or | |||
on the set of offered vectors and Classification | mechanism the DUT uses to achieve service differentiation is | |||
configuration on the DUT/SUT. The DUT is configured in a | implementation specific and is not important when describing the | |||
certain way in order that classification occurs when a | Expected Forwarding Vector. | |||
traffic mix consisting of multiple streams is applied. | ||||
This term captures the expected forwarding behavior from the | Measurement units: | |||
DUT receiving multiple Offered Vectors. The actual algorithm | N-octet packets per second | |||
or mechanism the DUT uses to achieve service differentiation | ||||
is implementation specific and not important when describing | ||||
the Expected Forwarding Vector. | ||||
Measurement units: | See Also: | |||
N-octet packets per second | Classification | |||
Stream | ||||
Intended Vector | ||||
Offered Vector | ||||
See Also: | 3.4.3.2. Expected Loss Vector | |||
Classification | ||||
Stream | ||||
Intended Vector | ||||
Offered Vector | ||||
Network-layer Traffic Control Mechanisms | ||||
3.4.3.2 Expected Loss Vector | Definition: | |||
A description of the percentage of packets having a specific | ||||
classification that should not be forwarded. | ||||
Definition: | Discussion: | |||
A description of the percentage of packets, having a | The value of the Expected Loss Vector is dependent on the set of | |||
specific classification that SHOULD NOT be forwarded. | offered vectors and Classification configuration on the DUT/SUT. | |||
The DUT is configured in a certain way so that classification | ||||
occurs when a traffic mix consisting of multiple streams is | ||||
applied. | ||||
Discussion: | This term captures the expected forwarding behavior from the DUT | |||
The value of the Expected Minimum Delay Vector is dependent | receiving multiple Offered Vectors. The actual algorithm or | |||
on the set of offered vectors and Classification | mechanism the DUT uses to achieve service differentiation is | |||
configuration on the DUT/SUT. The DUT is configured in a | implementation specific and is not important when describing the | |||
certain way in order that classification occurs when a | Expected Loss Vector. | |||
traffic mix consisting of multiple streams is applied. | ||||
This term captures the expected forwarding behavior from the | Measurement Units: | |||
DUT receiving multiple Offered Vectors. The actual algorithm | Percentage of intended packets expected to be dropped. | |||
or mechanism the DUT uses to achieve service differentiation | ||||
is implementation specific and not important when describing | ||||
the Expected Loss Vector. | ||||
Measurement Units: | See Also: | |||
Percentage of intended packets that is expected to be | Classification | |||
dropped. | Stream | |||
Intended Vector | ||||
Offered Vector | ||||
One-way Packet Loss Metric [Ka99] | ||||
See Also: | 3.4.3.3. Expected Sequence Vector | |||
Classification | ||||
Stream | ||||
Intended Vector | ||||
Offered Vector | ||||
One-way Packet Loss Metric [Ka99] | ||||
3.4.3.3 Expected Sequence Vector | Definition: | |||
A description of the expected in-sequence packets matching a | ||||
specific classification, such as DSCP. | ||||
Definition: | Discussion: | |||
A description of the expected in-sequence packets matching | The value of the Expected Sequence Vector is dependent on the set | |||
a specific classification, such as DSCP. | of offered vectors and Classification configuration on the | |||
DUT/SUT. The DUT is configured in a certain way so that | ||||
classification occurs when a traffic mix consisting of multiple | ||||
streams is applied. | ||||
Discussion: | This term captures the expected forwarding behavior from the DUT | |||
The value of the Expected Minimum Delay Vector is dependent | receiving multiple Offered Vectors. The actual algorithm or | |||
on the set of offered vectors and Classification | mechanism the DUT uses to achieve service differentiation is | |||
configuration on the DUT/SUT. The DUT is configured in a | implementation specific and is not important when describing the | |||
certain way in order that classification occurs when a | Expected Sequence Vector. | |||
traffic mix consisting of multiple streams is applied. | ||||
This term captures the expected forwarding behavior from the | Measurement Units: | |||
DUT receiving multiple Offered Vectors. The actual algorithm | N-octet packets per second | |||
or mechanism the DUT uses to achieve service differentiation | ||||
is implementation specific and not important when describing | ||||
the Expected Sequence Vector. | ||||
Network-layer Traffic Control Mechanisms | See Also: | |||
Classification | ||||
Stream | ||||
In-Sequence Packet | ||||
Intended Vector | ||||
Offered Vector | ||||
Measurement Units: | 3.4.3.4. Expected Delay Vector | |||
N-octet packets per second | ||||
See Also: | Definition: | |||
Classification | A description of the expected instantaneous Forwarding Delay for | |||
Stream | packets matching a specific classification, such as DSCP. | |||
In-Sequence Packet | ||||
Intended Vector | ||||
Offered Vector | ||||
3.4.3.4 Expected Delay Vector | Discussion: | |||
The value of the Expected Delay Vector is dependent on the set of | ||||
offered vectors and Classification configuration on the DUT/SUT. | ||||
The DUT is configured in a certain way so that classification | ||||
occurs when a traffic mix consisting of multiple streams is | ||||
applied. | ||||
Definition: | This term captures the expected forwarding behavior from the DUT | |||
A description of the expected instantaneous Forwarding | receiving multiple Offered Vectors. The actual algorithm or | |||
Delay for packets matching a specific classification, such | mechanism the DUT uses to achieve service differentiation is | |||
as DSCP. | implementation specific and is not important when describing the | |||
Expected Delay Vector. | ||||
Discussion: | Measurement units: | |||
The value of the Expected Minimum Delay Vector is dependent | milliseconds | |||
on the set of offered vectors and Classification | ||||
configuration on the DUT/SUT. The DUT is configured in a | ||||
certain way in order that classification occurs when a | ||||
traffic mix consisting of multiple streams is applied. | ||||
This term captures the expected forwarding behavior from the | See Also: | |||
DUT receiving multiple Offered Vectors. The actual algorithm | Classification | |||
or mechanism the DUT uses to achieve service differentiation | Stream | |||
is implementation specific and not important when describing | Forwarding Delay | |||
the Expected Delay Vector. | Intended Vector | |||
Offered Vector | ||||
Measurement units: | 3.4.3.5. Expected Average Delay Vector | |||
milliseconds | ||||
See Also: | Definition: | |||
Classification | A description of the expected average Forwarding Delay for packets | |||
Stream | matching a specific classification, such as DSCP. | |||
Forwarding Delay | ||||
Intended Vector | ||||
Offered Vector | ||||
3.4.3.5 Expected Average Delay Vector | Discussion: | |||
The value of the Expected Average Delay Vector is dependent on the | ||||
set of offered vectors and Classification configuration on the | ||||
DUT/SUT. The DUT is configured in a certain way so that | ||||
classification occurs when a traffic mix consisting of multiple | ||||
streams is applied. | ||||
Definition: | This term captures the expected forwarding behavior from the DUT | |||
A description of the expected average Forwarding Delay | receiving multiple Offered Vectors. The actual algorithm or | |||
for packets matching a specific classification, such as | mechanism the DUT uses to achieve service differentiation is | |||
DSCP. | implementation specific and is not important when describing the | |||
Expected Average Delay Vector. | ||||
Network-layer Traffic Control Mechanisms | Measurement units: | |||
milliseconds | ||||
Discussion: | See Also: | |||
The value of the Expected Minimum Delay Vector is dependent | Classification | |||
on the set of offered vectors and Classification | Stream | |||
configuration on the DUT/SUT. The DUT is configured in a | Forwarding Delay | |||
certain way in order that classification occurs when a | Intended Vector | |||
traffic mix consisting of multiple streams is applied. | Offered Vector | |||
Expected Delay Vector | ||||
This term captures the expected forwarding behavior from the | 3.4.3.6. Expected Maximum Delay Vector | |||
DUT receiving multiple Offered Vectors. The actual algorithm | ||||
or mechanism the DUT uses to achieve service differentiation | ||||
is implementation specific and not important when describing | ||||
the Expected Average Delay Vector. | ||||
Measurement units: | Definition: | |||
milliseconds | A description of the expected maximum Forwarding Delay for packets | |||
matching a specific classification, such as DSCP. | ||||
See Also: | Discussion: | |||
Classification | The value of the Expected Maximum Delay Vector is dependent on the | |||
Stream | set of offered vectors and Classification configuration on the | |||
Forwarding Delay | DUT/SUT. The DUT is configured in a certain way so that | |||
Intended Vector | classification occurs when a traffic mix consisting of multiple | |||
Offered Vector | streams is applied. | |||
Expected Delay Vector | ||||
3.4.3.6 Expected Maximum Delay Vector | This term captures the expected forwarding behavior from the DUT | |||
receiving multiple Offered Vectors. The actual algorithm or | ||||
mechanism the DUT uses to achieve service differentiation is | ||||
implementation specific and is not important when describing the | ||||
Expected Maximum Delay Vector. | ||||
Definition: | Measurement units: | |||
A description of the expected maximum Forwarding Delay | milliseconds | |||
for packets matching a specific classification, such as | ||||
DSCP. | ||||
Discussion: | See Also: | |||
The value of the Expected Minimum Delay Vector is dependent | Classification | |||
on the set of offered vectors and Classification | Stream | |||
configuration on the DUT/SUT. The DUT is configured in a | Forwarding Delay | |||
certain way in order that classification occurs when a | Intended Vector | |||
traffic mix consisting of multiple streams is applied. | Offered Vector | |||
Expected Delay Vector | ||||
This term captures the expected forwarding behavior from the | 3.4.3.7. Expected Minimum Delay Vector | |||
DUT receiving multiple Offered Vectors. The actual algorithm | ||||
or mechanism the DUT uses to achieve service differentiation | ||||
is implementation specific and not important when describing | ||||
the Expected Maximum Delay Vector. | ||||
Measurement units: | Definition: | |||
milliseconds | A description of the expected minimum Forwarding Delay for packets | |||
Network-layer Traffic Control Mechanisms | matching a specific classification, such as DSCP. | |||
See Also: | Discussion: | |||
Classification | The value of the Expected Minimum Delay Vector is dependent on the | |||
Stream | set of offered vectors and Classification configuration on the | |||
Forwarding Delay | DUT/SUT. The DUT is configured in a certain way so that | |||
Intended Vector | classification occurs when a traffic mix consisting of multiple | |||
Offered Vector | streams is applied. | |||
Expected Delay Vector | ||||
3.4.3.7 Expected Minimum Delay Vector | This term captures the expected forwarding behavior from the DUT | |||
receiving multiple Offered Vectors. The actual algorithm or | ||||
mechanism the DUT uses to achieve service differentiation is | ||||
implementation specific and is not important when describing the | ||||
Expected Minimum Delay Vector. | ||||
Definition: | Measurement units: | |||
A description of the expected minimum Forwarding Delay | milliseconds | |||
for packets matching a specific classification, such as | ||||
DSCP. | ||||
Discussion: | See Also: | |||
The value of the Expected Minimum Delay Vector is dependent | Classification | |||
on the set of offered vectors and Classification | Stream | |||
configuration on the DUT/SUT. The DUT is configured in a | Forwarding Delay | |||
certain way in order that classification occurs when a | Intended Vector | |||
traffic mix consisting of multiple streams is applied. | Offered Vector | |||
Expected Delay Vector | ||||
This term captures the expected forwarding behavior from the | 3.4.3.8. Expected Instantaneous Jitter Vector | |||
DUT receiving multiple Offered Vectors. The actual algorithm | ||||
or mechanism the DUT uses to achieve service differentiation | ||||
is implementation specific and not important when describing | ||||
the Expected Minimum Delay Vector. | ||||
Measurement units: | Definition: | |||
milliseconds | A description of the expected Instantaneous Jitter between two | |||
consecutive packets arrival times matching a specific | ||||
classification, such as DSCP. | ||||
See Also: | Discussion: | |||
Classification | Instantaneous Jitter is the absolute value of the difference | |||
Stream | between the Forwarding Delay measurement of two packets belonging | |||
Forwarding Delay | to the same stream. | |||
Intended Vector | ||||
Offered Vector | ||||
Expected Delay Vector | ||||
3.4.3.8 Expected Instantaneous Jitter Vector | The Forwarding Delay fluctuation between two consecutive packets | |||
in a stream is reported as the "Instantaneous Jitter". | ||||
Instantaneous Jitter can be expressed as |D(i) - D(i-1)|, where D | ||||
equals the Forwarding Delay and i is the test sequence number. | ||||
Packets lost are not counted in the measurement. | ||||
Definition: | The Forwarding Vector may contain several Jitter Vectors. For n | |||
A description of the expected instantaneous jitter between two | packets received in a Forwarding Vector, there is a total of (n-1) | |||
consecutive packets arrival times matching a specific | Instantaneous Jitter Vectors. | |||
classification, such as DSCP. | ||||
Discussion: | Measurement units: | |||
Instantaneous Jitter is the absolute value of the difference | milliseconds | |||
between the Forwarding Delay measurement of two packets | ||||
belonging to the same stream. | ||||
Network-layer Traffic Control Mechanisms | See Also: | |||
Classification | ||||
Stream | ||||
Jitter | ||||
Intended Vector | ||||
Offered Vector | ||||
The Forwarding Delay fluctuation between two consecutive | 3.4.3.9. Expected Average Jitter Vector | |||
packets in a stream is reported as the "Instantaneous | ||||
Jitter". Instantaneous Jitter can be expressed as | ||||
|D(i) - D(i-1)| where D equals the Forwarding Delay and i is | ||||
the test sequence number. Packets lost are not counted in | ||||
the measurement. | ||||
Forwarding Vector may contain several Jitter Vectors. For n | Definition: | |||
packets received in a Forwarding Vector, there is a total of | A description of the expected average jitter for packets arriving | |||
(n-1) Instantaneous Jitter Vectors. | in a stream matching a specific classification, such as DSCP. | |||
Measurement units: | Discussion: | |||
milliseconds | Average Jitter Vector is the average of all the Instantaneous | |||
Jitter Vectors measured during the test duration for the same | ||||
stream. | ||||
See Also: | The value of the Expected Average Jitter Vector is dependent on | |||
Classification | the set of offered vectors and Classification configuration on the | |||
Stream | DUT/SUT. The DUT is configured in a certain way so that | |||
Jitter | classification occurs when a traffic mix consisting of multiple | |||
Intended Vector | streams is applied. | |||
Offered Vector | ||||
3.4.3.9 Expected Average Jitter Vector | This term captures the expected forwarding behavior from the DUT | |||
receiving multiple Offered Vectors. The actual algorithm or | ||||
mechanism the DUT uses to achieve service differentiation is | ||||
implementation specific and is not important when describing the | ||||
Expected Average Jitter Vector. | ||||
Definition: | Measurement units: | |||
A description of the expected average jitter for packets | milliseconds | |||
arriving in a stream matching a specific classification, such | ||||
as DSCP. | ||||
Discussion: | See Also: | |||
Average Jitter Vector is the average of all the Instantaneous | Classification | |||
Jitter Vectors measured during the test duration for the same | Stream | |||
stream. | Jitter | |||
Intended Vector | ||||
Offered Vector | ||||
Expected Instantaneous Jitter Vector | ||||
The value of the Expected Average Jitter Vector is dependent | 3.4.3.10. Expected Peak-to-peak Jitter Vector | |||
on the set of offered vectors and Classification | ||||
configuration on the DUT/SUT. The DUT is configured in a | ||||
certain way in order that classification occurs when a | ||||
traffic mix consisting of multiple streams is applied. | ||||
This term captures the expected forwarding behavior from the | Definition: | |||
DUT receiving multiple Offered Vectors. The actual algorithm | A description of the expected maximum variation in the Forwarding | |||
or mechanism the DUT uses to achieve service differentiation | Delay of packet arrival times for packets arriving in a stream | |||
is implementation specific and not important when describing | matching a specific classification, such as DSCP. | |||
the Expected Average Jitter Vector. | ||||
Measurement units: | Discussion: | |||
milliseconds | Peak-to-peak Jitter Vector is the maximum Forwarding Delay minus | |||
Network-layer Traffic Control Mechanisms | the minimum Forwarding Delay of the packets (in a vector) | |||
forwarded by the DUT/SUT. | ||||
See Also: | Peak-to-peak Jitter is not derived from the Instantaneous Jitter | |||
Classification | Vector. Peak-to-peak Jitter is based upon all the packets during | |||
Stream | the test duration, not just two consecutive packets. | |||
Jitter | ||||
Intended Vector | ||||
Offered Vector | ||||
Expected Instantaneous Jitter Vector | ||||
3.4.3.10 Expected Peak-to-peak Jitter Vector | The value of the Expected Peak-to-peak Jitter Vector is dependent | |||
on the set of offered vectors and Classification configuration on | ||||
the DUT/SUT. The DUT is configured in a certain way so that | ||||
classification occurs when a traffic mix consisting of multiple | ||||
streams is applied. | ||||
Definition: | This term captures the expected forwarding behavior from the DUT | |||
A description of the expected maximum variation in the | receiving multiple Offered Vectors. The actual algorithm or | |||
Forwarding Delay of packet arrival times for packets | mechanism the DUT uses to achieve service differentiation is | |||
arriving in a stream matching a specific classification, | implementation specific and is not important when describing the | |||
such as DSCP. | Expected Peak-to-peak Jitter Vector. | |||
Discussion: | Measurement units: | |||
Peak-to-peak Jitter Vector is the maximum Forwarding Delay | milliseconds | |||
minus the minimum Forwarding Delay of the packets (in a | ||||
vector) forwarded by the DUT/SUT. | ||||
Peak-to-peak Jitter is not derived from the Instantaneous | See Also: | |||
Jitter Vector. Peak-to-peak Jitter is based upon all the | Classification | |||
packets during the test duration, not just two consecutive | Stream | |||
packets. | Jitter | |||
Intended Vector | ||||
Offered Vector | ||||
Expected Instantaneous Jitter Vector | ||||
Expected Average Jitter Vector | ||||
The value of the Expected Peak-to-peak Jitter Vector is | 3.4.4. Output Vectors | |||
dependent on the set of offered vectors and Classification | ||||
configuration on the DUT/SUT. The DUT is configured in a | ||||
certain way in order that classification occurs when a | ||||
traffic mix consisting of multiple streams is applied. | ||||
This term captures the expected forwarding behavior from the | 3.4.4.1. Forwarding Vector | |||
DUT receiving multiple Offered Vectors. The actual algorithm | ||||
or mechanism the DUT uses to achieve service differentiation | ||||
is implementation specific and not important when describing | ||||
the Expected Peak-to-peak Jitter Vector. | ||||
Measurement units: | Definition: | |||
milliseconds | The number of packets per second for a stream matching a specific | |||
classification, such as DSCP, that a DUT/SUT is measured to | ||||
forward to the correct destination interface successfully in | ||||
response to an offered vector. | ||||
See Also: | Discussion: | |||
Classification | Forwarding Vector is expressed as a combination of values: the | |||
Stream | classification rules AND the measured packets per second for the | |||
Jitter | stream matching the classification rules. Forwarding Vector is a | |||
Intended Vector | per-hop measurement. The DUT/SUT MAY remark the specific DSCP (or | |||
Offered Vector | IP precedence) value for a multi-hop measurement. The stream | |||
Expected Instantaneous Jitter Vector | remains the same. | |||
Expected Average Jitter Vector | ||||
Network-layer Traffic Control Mechanisms | ||||
3.4.4 Output Vectors | Measurement units: | |||
3.4.4.1 Forwarding Vector | N-octet packets per second | |||
Definition: | ||||
The number of packets per second for a stream matching a | ||||
specific classification, such as DSCP, that a DUT/SUT | ||||
is measured to successfully forward to the correct | ||||
destination interface in response to an offered vector. | ||||
Discussion: | See Also: | |||
Forwarding Vector is expressed as a combination of values: | Classification | |||
the classification rules AND the measured packets per | Stream | |||
second for the stream matching the classification rules. | Forwarding Capacity | |||
Forwarding Vector is a per-hop measurement. The DUT/SUT | Intended Vector | |||
MAY remark the specific DSCP (or IP precedence) value for | Offered Vector | |||
a multi-hop measurement. The stream remains the same. | Expected Vector | |||
Measurement units: | 3.4.4.2. Loss Vector | |||
N-octet packets per second | ||||
See Also: | Definition: | |||
Classification | The percentage of packets per second for a stream matching a | |||
Stream | specific classification, such as DSCP, that a DUT/SUT is measured | |||
Forwarding Capacity | not to transmit to the correct destination interface in response | |||
Intended Vector | to an offered vector. | |||
Offered Vector | ||||
Expected Vector | ||||
3.4.4.2 Loss Vector | Discussion: | |||
Definition: | Loss Vector is expressed as a combination of values: the | |||
The percentage of packets per second for a stream | classification rules AND the measured percentage value of packet | |||
matching a specific classification, such as DSCP, that | loss. Loss Vector is a per-hop measurement. The DUT/SUT MAY | |||
a DUT/SUT is measured to not transmit to the correct | remark the specific DSCP or IP precedence value for a multi-hop | |||
destination interface in response to an offered vector. | measurement. The stream remains the same. | |||
Discussion: | Measurement Units: | |||
Loss Vector is expressed as a combination of values: | Percentage of packets | |||
the classification rules AND the measured percentage | ||||
value of packet loss. Loss Vector is a per-hop | ||||
measurement. The DUT/SUT MAY remark the specific DSCP | ||||
or IP precedence value for a multi-hop measurement. | ||||
The stream remains the same. | ||||
Measurement Units: | See Also: | |||
Percentage of packets | Classification | |||
Stream | ||||
Intended Vector | ||||
Offered Vector | ||||
Expected Vector | ||||
One-way Packet Loss Metric [Ka99] | ||||
See Also: | 3.4.4.3. Sequence Vector | |||
Classification | ||||
Stream | ||||
Intended Vector | ||||
Offered Vector | ||||
Expected Vector | ||||
One-way Packet Loss Metric [Ka99] | ||||
Network-layer Traffic Control Mechanisms | ||||
3.4.4.3 Sequence Vector | Definition: | |||
Definition: | The number of packets per second for all packets in a stream | |||
The number of packets per second for all packets in a | matching a specific classification, such as DSCP, that a DUT/SUT | |||
stream matching a specific classification, such as DSCP, | is measured to transmit in sequence to the correct destination | |||
that a DUT/SUT is measured to transmit in sequence to the | interface in response to an offered vector. | |||
correct destination interface in response to an offered | ||||
vector. | ||||
Discussion: | Discussion: | |||
Sequence Vector is expressed as a combination of values: | Sequence Vector is expressed as a combination of values: the | |||
the classification rules AND the number of packets per | classification rules AND the number of packets per second that are | |||
second that are in-sequence. | in-sequence. | |||
Sequence Vector is a per-hop measurement. The DUT/SUT | Sequence Vector is a per-hop measurement. The DUT/SUT MAY remark | |||
MAY remark the specific DSCP or IP precedence value for | the specific DSCP or IP precedence value for a multi-hop | |||
a multi-hop measurement. The stream remains the same. | measurement. The stream remains the same. | |||
Measurement Units: | Measurement Units: | |||
N-octet packets per second | N-octet packets per second | |||
See Also: | See Also: | |||
Classification | Classification | |||
Stream | Stream | |||
In-sequence Packet | In-sequence Packet | |||
Intended Vector | Intended Vector | |||
Offered Vector | Offered Vector | |||
Expected Vector | Expected Vector | |||
3.4.4.4 Instantaneous Delay Vector | 3.4.4.4. Instantaneous Delay Vector | |||
Definition: | ||||
The instantaneous Forwarding Delay for a packet in a | ||||
stream matching a specific classification, such as DSCP, | ||||
that a DUT/SUT is measured to successfully transmit to the | ||||
correct destination interface in response to an offered | ||||
vector. | ||||
Discussion: | Definition: | |||
Instantaneous Delay Vector is expressed as a combination | The instantaneous Forwarding Delay for a packet in a stream | |||
of values: the classification rules AND Forwarding Delay. | matching a specific classification, such as DSCP, that a DUT/SUT | |||
For every packet received in a Forwarding Vector, there | is measured to transmit to the correct destination interface | |||
is a corresponding Instantaneous Delay Vector. | successfully in response to an offered vector. | |||
Instantaneous Delay Vector is a per-hop measurement. The | Discussion: | |||
DUT/SUT MAY remark the specific DSCP or IP precedence value | Instantaneous Delay Vector is expressed as a combination of | |||
for a multi-hop measurement. The stream remains the same. | values: the classification rules AND Forwarding Delay. For every | |||
packet received in a Forwarding Vector, there is a corresponding | ||||
Instantaneous Delay Vector. | ||||
Instantaneous Delay Vector can be obtained at any offered | Instantaneous Delay Vector is a per-hop measurement. The DUT/SUT | |||
load. It is RECOMMENDED to obtain this vector at or below | MAY remark the specific DSCP or IP precedence value for a multi- | |||
the Forwarding Capacity in the absence of Forwarding | hop measurement. The stream remains the same. | |||
Congestion. For congested Forwarding Delay, run the | ||||
offered load above the Forwarding Capacity. | ||||
Network-layer Traffic Control Mechanisms | Instantaneous Delay Vector can be obtained at any offered load. | |||
It is RECOMMENDED that this vector be obtained at or below the | ||||
Forwarding Capacity in the absence of Forwarding Congestion. For | ||||
congested Forwarding Delay, run the offered load above the | ||||
Forwarding Capacity. | ||||
Measurement Units: | Measurement Units: | |||
milliseconds | milliseconds | |||
See Also: | See Also: | |||
Classification | Classification | |||
Stream | Stream | |||
Forwarding Capacity | Forwarding Capacity | |||
Forwarding Delay | Forwarding Delay | |||
Intended Vector | Intended Vector | |||
Offered Vector | Offered Vector | |||
Expected Delay Vector | Expected Delay Vector | |||
3.4.4.5 Average Delay Vector | 3.4.4.5. Average Delay Vector | |||
Definition: | Definition: | |||
The average Forwarding Delay for packets in a stream | The average Forwarding Delay for packets in a stream matching a | |||
matching a specific classification, such as DSCP, that | specific classification, such as DSCP, that a DUT/SUT is measured | |||
a DUT/SUT is measured to successfully transmit to the | to transmit to the correct destination interface successfully in | |||
correct destination interface in response to an offered | response to an offered vector. | |||
vector. | ||||
Discussion: | Discussion: | |||
Average Delay Vector is expressed as combination of values: | Average Delay Vector is expressed as combination of values: the | |||
the classification rules AND average Forwarding Delay. | classification rules AND average Forwarding Delay. | |||
The average Forwarding Delay is computed by averaging all | The average Forwarding Delay is computed by averaging all the | |||
the Instantaneous Delay Vectors for a given stream. | Instantaneous Delay Vectors for a given stream. | |||
Average Delay Vector is a per-hop measurement. The DUT/SUT | Average Delay Vector is a per-hop measurement. The DUT/SUT MAY | |||
MAY remark the specific DSCP or IP precedence value for a | remark the specific DSCP or IP precedence value for a multi-hop | |||
multi-hop measurement. The stream remains the same. | measurement. The stream remains the same. | |||
Average Delay Vector can be obtained at any offered load. | Average Delay Vector can be obtained at any offered load. It is | |||
Recommend at or below the Forwarding Capacity in the | recommended that the offered load be at or below the Forwarding | |||
absence of congestion. For congested Forwarding Delay, run | Capacity in the absence of congestion. For congested Forwarding | |||
the offered load above the Forwarding Capacity. | Delay, run the offered load above the Forwarding Capacity. | |||
Measurement Units: | Measurement Units: | |||
milliseconds | milliseconds | |||
See Also: | See Also: | |||
Classification | Classification | |||
Stream | Stream | |||
Forwarding Capacity | Forwarding Capacity | |||
Forwarding Delay | Forwarding Delay | |||
Intended Vector | Intended Vector | |||
Offered Vector | Offered Vector | |||
Expected Delay Vector | Expected Delay Vector | |||
Instantaneous Delay Vector | Instantaneous Delay Vector | |||
Network-layer Traffic Control Mechanisms | ||||
3.4.4.6 Maximum Delay Vector | 3.4.4.6. Maximum Delay Vector | |||
Definition: | ||||
The maximum Forwarding Delay for packets in a stream | ||||
matching a specific classification, such as DSCP, that | ||||
a DUT/SUT is measured to successfully transmit to the | ||||
correct destination interface in response to an offered | ||||
vector. | ||||
Discussion: | Definition: | |||
Maximum Delay Vector is expressed as combination of values: | The maximum Forwarding Delay for packets in a stream matching a | |||
the classification rules AND maximum Forwarding Delay. | specific classification, such as DSCP, that a DUT/SUT is measured | |||
to transmit to the correct destination interface successfully in | ||||
response to an offered vector. | ||||
The maximum Forwarding Delay is computed by selecting the | Discussion: | |||
highest value from the Instantaneous Delay Vectors for a | Maximum Delay Vector is expressed as combination of values: the | |||
given stream. | classification rules AND maximum Forwarding Delay. | |||
Maximum Delay Vector is a per-hop measurement. The DUT/SUT | The maximum Forwarding Delay is computed by selecting the highest | |||
MAY remark the specific DSCP or IP precedence value for a | value from the Instantaneous Delay Vectors for a given stream. | |||
multi-hop measurement. The stream remains the same. | ||||
Maximum Delay Vector can be obtained at any offered load. | Maximum Delay Vector is a per-hop measurement. The DUT/SUT MAY | |||
Recommend at or below the Forwarding Capacity in the | remark the specific DSCP or IP precedence value for a multi-hop | |||
absence of congestion. For congested Forwarding Delay, run | measurement. The stream remains the same. | |||
the offered load above the Forwarding Capacity. | ||||
Measurement Units: | Maximum Delay Vector can be obtained at any offered load. It is | |||
milliseconds | recommended that the offered load be at or below the Forwarding | |||
Capacity in the absence of congestion. For congested Forwarding | ||||
Delay, run the offered load above the Forwarding Capacity. | ||||
See Also: | Measurement Units: | |||
Classification | milliseconds | |||
Stream | ||||
Forwarding Capacity | ||||
Forwarding Delay | ||||
Intended Vector | ||||
Offered Vector | ||||
Expected Delay Vector | ||||
Instantaneous Delay Vector | ||||
3.4.4.7 Minimum Delay Vector | See Also: | |||
Definition: | Classification | |||
The minimum Forwarding Delay for packets in a stream | Stream | |||
matching a specific classification, such as DSCP, that | Forwarding Capacity | |||
a DUT/SUT is measured to successfully transmit to the | Forwarding Delay | |||
correct destination interface in response to an offered | Intended Vector | |||
vector. | Offered Vector | |||
Expected Delay Vector | ||||
Instantaneous Delay Vector | ||||
Discussion: | 3.4.4.7. Minimum Delay Vector | |||
Minimum Delay Vector is expressed as a combination of | ||||
values: the classification rules AND maximum Forwarding | ||||
Delay. The minimum Forwarding Delay is computed by | ||||
selecting the highest value from the Instantaneous Delay | ||||
Vectors for a given stream. | ||||
Network-layer Traffic Control Mechanisms | Definition: | |||
The minimum Forwarding Delay for packets in a stream matching a | ||||
specific classification, such as DSCP, that a DUT/SUT is measured | ||||
to transmit to the correct destination interface successfully in | ||||
response to an offered vector. | ||||
Minimum Delay Vector is a per-hop measurement. The DUT/SUT | Discussion: | |||
MAY remark the specific DSCP or IP precedence value for a | Minimum Delay Vector is expressed as a combination of values: the | |||
multi-hop measurement. The stream remains the same. | classification rules AND minimum Forwarding Delay. The minimum | |||
Forwarding Delay is computed by selecting the lowest value from | ||||
the Instantaneous Delay Vectors for a given stream. | ||||
Minimum Delay Vector can be obtained at any offered load. | Minimum Delay Vector is a per-hop measurement. The DUT/SUT MAY | |||
Recommend at or below the Forwarding Capacity in the | remark the specific DSCP or IP precedence value for a multi-hop | |||
absence of congestion. For congested Forwarding Delay, run | measurement. The stream remains the same. | |||
the offered load above the Forwarding Capacity. | ||||
Measurement Units: | Minimum Delay Vector can be obtained at any offered load. It is | |||
milliseconds | recommended that the offered load be at or below the Forwarding | |||
Capacity in the absence of congestion. For congested Forwarding | ||||
Delay, run the offered load above the Forwarding Capacity. | ||||
See Also: | Measurement Units: | |||
Classification | milliseconds | |||
Stream | ||||
Forwarding Capacity | ||||
Forwarding Delay | ||||
Intended Vector | ||||
Offered Vector | ||||
Expected Delay Vector | ||||
3.4.4.8 Instantaneous Jitter Vector | See Also: | |||
Definition: | Classification | |||
The jitter for two consecutive packets in a | Stream | |||
stream matching a specific classification, such as DSCP, | Forwarding Capacity | |||
that a DUT/SUT is measured to successfully transmit to the | Forwarding Delay | |||
correct destination interface in response to an offered | Intended Vector | |||
vector. | Offered Vector | |||
Expected Delay Vector | ||||
Discussion: | 3.4.4.8. Instantaneous Jitter Vector | |||
Instantaneous Jitter is the absolute value of the difference | ||||
between the Forwarding Delay measurement of two packets | ||||
belonging to the same stream. | ||||
Jitter vector is expressed as pair of numbers. Both the | Definition: | |||
specific DSCP (or IP precedence) value AND jitter value | The jitter for two consecutive packets in a stream matching a | |||
combine to make a vector. | specific classification, such as DSCP, that a DUT/SUT is measured | |||
to transmit to the correct destination interface successfully in | ||||
response to an offered vector. | ||||
The Forwarding Delay fluctuation between two consecutive | Discussion: | |||
packets in a stream is reported as the "Instantaneous Jitter". | Instantaneous Jitter is the absolute value of the difference | |||
Instantaneous Jitter Vector can be expressed as | between the Forwarding Delay measurement of two packets belonging | |||
|D(i) - D(i-1)| where D equals the Forwarding Delay and i is | to the same stream. | |||
the test sequence number. Packets lost are not counted in | ||||
the measurement. | ||||
Instantaneous Jitter Vector is a per-hop measurement. The | The Instantaneous Jitter vector is expressed as a pair of numbers. | |||
DUT/SUT MAY remark the specific DSCP or IP precedence value | Both the specific DSCP (or IP precedence) value AND jitter value | |||
for a multi-hop measurement. The stream remains the same. | combine to make a vector. | |||
There may be several Instantaneous Jitter Vectors for a | The Forwarding Delay fluctuation between two consecutive packets | |||
single stream. For n packets measured, there may be (n-1) | in a stream is reported as the "Instantaneous Jitter". | |||
Instantaneous Jitter Vectors. | Instantaneous Jitter Vector can be expressed as |D(i) - D(i-1)|, | |||
where D equals the Forwarding Delay and i is the test sequence | ||||
number. Packets lost are not counted in the measurement. | ||||
Network-layer Traffic Control Mechanisms | The Instantaneous Jitter Vector is a per-hop measurement. The | |||
DUT/SUT MAY remark the specific DSCP or IP precedence value for a | ||||
multi-hop measurement. The stream remains the same. | ||||
Measurement units: | There may be several Instantaneous Jitter Vectors for a single | |||
milliseconds | stream. For n packets measured, there may be (n-1) Instantaneous | |||
Jitter Vectors. | ||||
See Also: | Measurement units: | |||
Classification | milliseconds | |||
Stream | ||||
Forwarding Delay | ||||
Jitter | ||||
Forwarding Vector | ||||
Expected Vectors | ||||
3.4.4.9 Average Jitter Vector | See Also: | |||
Classification | ||||
Stream | ||||
Forwarding Delay | ||||
Jitter | ||||
Forwarding Vector | ||||
Expected Vectors | ||||
Definition: | 3.4.4.9. Average Jitter Vector | |||
The average jitter for packets in a stream matching a | ||||
specific classification, such as DSCP, that a DUT/SUT is | ||||
measured to successfully transmit to the correct | ||||
destination interface in response to an offered vector. | ||||
Discussion: | Definition: | |||
Average jitter is calculated by the average of all the | The average jitter for packets in a stream matching a specific | |||
Instantaneous Jitter Vectors of the same stream measured | classification, such as DSCP, that a DUT/SUT is measured to | |||
during the test duration. Average Jitter Vector is | transmit to the correct destination interface successfully in | |||
expressed as a combination of values: the | response to an offered vector. | |||
classification rules AND average Jitter. | ||||
Average Jitter vector is a per-hop measurement. The | Discussion: | |||
DUT/SUT MAY remark the specific DSCP or IP precedence value | Average jitter is calculated by the average of all the | |||
for a multi-hop measurement. The stream remains the same. | Instantaneous Jitter Vectors of the same stream measured during | |||
the test duration. Average Jitter Vector is expressed as a | ||||
combination of values: the classification rules AND average | ||||
Jitter. | ||||
Measurement units: | Average Jitter Vector is a per-hop measurement. The DUT/SUT MAY | |||
milliseconds | remark the specific DSCP or IP precedence value for a multi-hop | |||
measurement. The stream remains the same. | ||||
See Also: | Measurement units: | |||
Classification | milliseconds | |||
Stream | ||||
Jitter | ||||
Forwarding Vector | ||||
Expected Vector | ||||
Instantaneous Jitter Vector | ||||
3.4.4.10 Peak-to-peak Jitter Vector | See Also: | |||
Classification | ||||
Stream | ||||
Jitter | ||||
Forwarding Vector | ||||
Expected Vector | ||||
Instantaneous Jitter Vector | ||||
Definition: | 3.4.4.10. Peak-to-peak Jitter Vector | |||
The maximum possible variation in the Forwarding Delay for | ||||
packets in a stream matching a specific classification, | ||||
such as DSCP, that a DUT/SUT is measured to successfully | ||||
transmit to the correct destination interface in response | ||||
to an offered vector. | ||||
Network-layer Traffic Control Mechanisms | Definition: | |||
The maximum possible variation in the Forwarding Delay for packets | ||||
in a stream matching a specific classification, such as DSCP, that | ||||
a DUT/SUT is measured to transmit to the correct destination | ||||
interface successfully in response to an offered vector. | ||||
Discussion: | Discussion: | |||
Peak-to-peak Jitter Vector is calculated by subtracting | Peak-to-peak Jitter Vector is calculated by subtracting the | |||
the maximum Forwarding Delay from the minimum Forwarding | maximum Forwarding Delay from the minimum Forwarding Delay of the | |||
Delay of the packets forwarded by the DUT/SUT. Jitter | packets forwarded by the DUT/SUT. Jitter vector is expressed as a | |||
vector is expressed as a combination of values: the | combination of values: the classification rules AND peak-to-peak | |||
classification rules AND peak-to-peak Jitter. | Jitter. | |||
Peak-to-peak Jitter is not derived from the Instantaneous | Peak-to-peak Jitter is not derived from the Instantaneous Jitter | |||
Jitter Vector. Peak-to-peak Jitter is based upon all the | Vector. Peak-to-peak Jitter is based upon all the packets during | |||
packets during the test duration, not just two consecutive | the test duration, not just two consecutive packets. | |||
packets. | ||||
Measurement units: | Measurement units: | |||
milliseconds | milliseconds | |||
See Also: | See Also: | |||
Jitter | Jitter | |||
Forwarding Vector | Forwarding Vector | |||
Stream | Stream | |||
Expected Vectors | Expected Vectors | |||
Instantaneous Jitter Vector | Instantaneous Jitter Vector | |||
Average Jitter Vector | Average Jitter Vector | |||
4. IANA Considerations | 4. Security Considerations | |||
This document requires no IANA considerations. | Documents of this type do not directly affect the security of the | |||
Internet or of corporate networks as long as benchmarking is not | ||||
performed on devices or systems connected to production networks. | ||||
5. Security Considerations | Packets with unintended and/or unauthorized DSCP or IP precedence | |||
values may present security issues. Determining the security | ||||
consequences of such packets is out of scope for this document. | ||||
Documents of this type do not directly affect the security of | 5. Acknowledgements | |||
the Internet or of corporate networks as long as benchmarking | ||||
is not performed on devices or systems connected to | ||||
production networks. | ||||
Packets with unintended and/or unauthorized DSCP or IP | The authors gratefully acknowledge the contributions of the IETF's | |||
precedence values may present security issues. Determining | Benchmarking Methodology Working Group members in reviewing this | |||
the security consequences of such packets is out of scope for | document. The authors would like to express our thanks to David | |||
this document. | Newman for his consistent and valuable assistance throughout the | |||
development of this document. The authors would also like to thank | ||||
Al Morton and Kevin Dubray for their ideas and support. | ||||
6. Acknowledgments | 6. References | |||
The authors gratefully acknowledge the contributions of the | 6.1. Normative References | |||
IETF's benchmarking working group members in reviewing this | ||||
document. The authors would like to express our thanks to | ||||
David Newman for his consistent and valuable assistance | ||||
throughout the development of this document. The authors | ||||
would also like to thank Al Morton (acmorton@att.com) and | ||||
Kevin Dubray (kdubray@juniper.net) for their ideas and | ||||
support. | ||||
Network-layer Traffic Control Mechanisms | [Br91] Bradner, S., "Benchmarking terminology for network | |||
interconnection devices", RFC 1242, July 1991. | ||||
7. References | [Br97] Bradner, S., "Key words for use in RFCs to Indicate | |||
7.1 Normative References | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[Br91] Bradner, S., "Benchmarking Terminology for Network | ||||
Interconnection Devices", RFC 1242, July 1991. | ||||
[Br97] Bradner, S., "Key words for use in RFCs to Indicate | [Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., | |||
Requirement Levels", RFC 2119, March 1997 | Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, | |||
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, | ||||
J., and L. Zhang, "Recommendations on Queue Management and | ||||
Congestion Avoidance in the Internet", RFC 2309, April 1998. | ||||
[Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B., | [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching | |||
Deering, S., Estrin, D., Floyd, S., Jacobson, V., | Devices", RFC 2285, February 1998. | |||
Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, | ||||
K., Shenker, S., Wroclawski, J. and L. Zhang, | ||||
"Recommendations on Queue Management and Congestion | ||||
Avoidance in the Internet", RFC 2309, April 1998. | ||||
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN | [Ni98] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition | |||
Switching Devices", RFC 2285, July 1998. | of the Differentiated Services Field (DS Field) in the IPv4 | |||
and IPv6 Headers", RFC 2474, December 1998. | ||||
[Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition | [St91] Steinberg, L., "Techniques for managing asynchronously | |||
of the Differentiated Services Field (DS Field) in the | generated alerts", RFC 1224, May 1991. | |||
IPv4 and IPv6 Headers", RFC 2474, December 1998. | ||||
[St91] Steinberg, L., "Techniques for Managing Asynchronously | 6.2. Informative References | |||
Generated Alerts", RC 1224, May 1991. | ||||
7.2 Informative References | [Al99] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay | |||
[Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay | Metric for IPPM", RFC 2679, September 1999. | |||
Metric for IPPM", RFC 2679, September 1999 | ||||
[Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and | |||
Weiss, W., "An Architecture for Differentiated Services", | W. Weiss, "An Architecture for Differentiated Service", RFC | |||
RFC 2475, December 1998. | 2475, December 1998. | |||
[Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for | [Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for | |||
Network Interconnect Devices", RFC 2544, March 1999 | Network Interconnect Devices", RFC 2544, March 1999. | |||
[De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation | [De02] Demichelis, C. and P. Chimento, "IP Packet Delay Variation | |||
Metric for IPPM", RFC 3393, November 2002 | Metric for IP Performance Metrics (IPPM)", RFC 3393, November | |||
2002. | ||||
[Ec98] http://www3.ietf.org/proceedings/98mar/ | [Ec98] http://www3.ietf.org/proceedings/98mar/98mar-edited-135.htm | |||
98mar-edited-135.htm | ||||
[Fl93] Floyd, S., and Jacobson, V., "Random Early Detection | [Fl93] Floyd, S., and Jacobson, V., "Random Early Detection gateways | |||
gateways for Congestion Avoidance", IEEE/ACM | for Congestion Avoidance", IEEE/ACM Transactions on | |||
Transactions on Networking, V.1 N.4, August 1993, p. | Networking, V.1 N.4, August 1993, p. 397-413. URL | |||
397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf". | "ftp://ftp.ee.lbl.gov/papers/early.pdf". | |||
[Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited | [Ja99] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, | |||
Forwarding PHB", RFC 2598, June 1999 | J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, | |||
"An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, | ||||
March 2002. | ||||
[Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way | [Ka99] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet | |||
Packet Loss Metric for IPPM", RFC 2680, September 1999 | Loss Metric for IPPM", RFC 2680, September 1999. | |||
Network-layer Traffic Control Mechanisms | ||||
[Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control | [Ma91] Mankin, A. and K. Ramakrishnan, "Gateway Congestion Control | |||
Survey", RFC 1254, August 1991 | Survey", RFC 1254, August 1991. | |||
[Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for | [Ma00] Mandeville, R. and J. Perser, "Benchmarking Methodology for | |||
LAN Switching Devices", RFC 2889, August 2000 | LAN Switching Devices", RFC 2889, August 2000. | |||
[Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, | [Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., | |||
S., Perser, J., "Packet Reordering Metric for IPPM", | Perser, J., "Packet Reordering Metric for IPPM", Work in | |||
Work in Progress | Progress. | |||
[Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", | [Na84] Nagle, J., "Congestion control in IP/TCP internetworks", RFC | |||
RFC 896, January 1984. | 896, January 1984. | |||
[Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add | [Ra99] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of | |||
Explicit Congestion Notification (ECN) to IP", RFC 2481, | Explicit Congestion Notification (ECN) to IP", RFC 3168, | |||
January 1999. | September 2001. | |||
[Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., | [Sc96] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, | |||
"RTP: A Transport Protocol for Real-Time Applications", | "RTP: A Transport Protocol for Real-Time Applications", STD | |||
RFC 1889, January 1996 | 64, RFC 3550, July 2003. | |||
8. Authors' Addresses | Authors' Addresses | |||
Jerry Perser | Jerry Perser | |||
Veriwave | Veriwave | |||
USA | 8770 SW Nimbus Ave. | |||
EMail: jperser@veriwave.com | Suite B | |||
Beaverton, OR 97008 USA | ||||
USA | ||||
Scott Poretsky | Phone: + 1 818 338 4112 | |||
Reef Point Systems | EMail: jerry@perser.org | |||
8 New England Executive Park | ||||
Burlington, MA 01803 | ||||
USA | ||||
Phone: + 1 508 439 9008 | ||||
EMail: sporetsky@reefpoint.com | ||||
Shobha Erramilli | Scott Poretsky | |||
Telcordia Technologies | Reef Point Systems | |||
331 Newman Springs Road | 8 New England Executive Park | |||
Red Bank, New Jersey 07701 | Burlington, MA 01803 | |||
USA | USA | |||
Email: shobha@research.telcordia.com | ||||
Sumit Khurana | Phone: + 1 508 439 9008 | |||
Telcordia Technologies | EMail: sporetsky@reefpoint.com | |||
445 South Street | ||||
Morristown, NJ 07960 | Shobha Erramilli | |||
USA | Telcordia Technologies | |||
Phone: + 1 973 829 3170 | 331 Newman Springs Road | |||
EMail: sumit@research.telcordia.com | Red Bank, New Jersey 07701 | |||
Network-layer Traffic Control Mechanisms | USA | |||
EMail: shobha@research.telcordia.com | ||||
Sumit Khurana | ||||
Motorola | ||||
7700 West Parmer Ln. | ||||
Austin, TX 78729 | ||||
USA | ||||
Phone: +1 512 996 6604 | ||||
Email: skhurana@motorola.com | ||||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
skipping to change at page 32, line 43 | skipping to change at page 34, line 42 | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at ietf- | this standard. Please address the information to the IETF at | |||
ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Acknowledgement | Acknowledgement | |||
Funding for the RFC Editor function is currently provided by the | ||||
Internet Society. | Funding for the RFC Editor function is provided by the IETF | |||
Administrative Support Activity (IASA). | ||||
End of changes. 319 change blocks. | ||||
1260 lines changed or deleted | 1167 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |