draft-ietf-tewg-measure-03.txt   draft-ietf-tewg-measure-04.txt 
Traffic Engineering Working Group Wai Sum Lai Traffic Engineering Working Group Wai Sum Lai
Internet Draft AT&T Labs Internet Draft AT&T Labs
Document: <draft-ietf-tewg-measure-03.txt> Document: <draft-ietf-tewg-measure-04.txt>
Category: Informational Blaine Christian Category: Informational Richard W. Tibbs
UUNET
Richard W. Tibbs
Oak City Networks & Oak City Networks &
Solutions Solutions
Steven Van den Berghe Steven Van den Berghe
Ghent University/IMEC Ghent University/IMEC
September 2002 January 2003
A Framework for Internet Traffic Engineering Measurement A Framework for Internet Traffic Engineering Measurement
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 16 skipping to change at page 2, line 13
detail at manageable sample volumes, there is a need for packet- detail at manageable sample volumes, there is a need for packet-
sampled measurements. To manage large volume of measured data, use sampled measurements. To manage large volume of measured data, use
of bulk transfer and filtering/aggregation mechanisms may be of bulk transfer and filtering/aggregation mechanisms may be
appropriate. appropriate.
Table of Contents Table of Contents
Status of this Memo................................................1 Status of this Memo................................................1
1. Abstract........................................................1 1. Abstract........................................................1
2. Conventions used in this document...............................2 2. Conventions used in this document...............................2
3. Introduction....................................................3 3. Introduction....................................................2
4. Terminology.....................................................4 4. Terminology.....................................................4
4.1 Route, path....................................................4 4.1 Route, path....................................................4
4.2 Throughput, traffic volume.....................................4 4.2 Throughput, traffic volume.....................................4
5. Uses of Traffic Measurement.....................................5 5. Uses of Traffic Measurement.....................................5
5.1 Traffic characterization.......................................5 5.1 Traffic characterization.......................................5
5.2 Network monitoring.............................................6 5.2 Network monitoring.............................................6
5.3 Traffic control................................................6 5.3 Traffic control................................................6
6. Time Scales for Network Operations..............................6 6. Time Scales for Network Operations..............................7
7. Read-Out Periods................................................7 7. Read-Out Periods................................................7
8. Measurement Bases...............................................8 8. Measurement Bases...............................................9
8.1 Flow-based.....................................................9 8.1 Flow-based....................................................10
8.2 Interface-based, link-based, node-based........................9 8.2 Interface-based, link-based, node-based.......................10
8.3 Node-pair-based...............................................10 8.3 Node-pair-based...............................................11
8.4 Path-based....................................................10 8.4 Path-based....................................................11
9. Measurement Entities...........................................11 9. Measurement Entities...........................................12
9.1 Entities related to traffic and performance...................11 9.1 Entities related to traffic and performance...................12
9.2 Entities related to establishment of connection or path.......13 9.2 Entities related to establishment of connection or path.......14
10. Measurement Types.............................................13 10. Measurement Types.............................................15
10.1 Measurement types related to traffic or performance..........14 10.1 Measurement types related to traffic or performance..........15
10.2 Measurement types related to resource usage..................14 10.2 Measurement types related to resource usage..................16
11. Traffic Matrix Statistics.....................................15 11. Traffic Matrix Statistics.....................................16
12. Performance Monitoring........................................16 12. Performance Monitoring........................................17
13. Packet Sampling...............................................17 13. Packet Sampling...............................................18
14. Statistical Estimation and Information Modeling...............18 14. Statistical Estimation and Information Modeling...............19
14.1 Engineering methods for statistical estimation of measures...18 14.1 Engineering methods for statistical estimation of measures...19
14.2 TE Measure Information Modeling..............................18 14.2 TE Measure Information Modeling..............................20
15. Conclusions and Recommendations...............................20 15. Conclusions and Recommendations...............................22
16. Security Considerations.......................................21 16. Security Considerations.......................................22
17. References....................................................21 17. References....................................................22
18. Intellectual Property Statement...............................23 18. Intellectual Property Statement...............................25
19. Acknowledgments...............................................24 19. Acknowledgments...............................................25
20. Author's Addresses............................................24 20. Author's Addresses............................................25
Full Copyright Statement..........................................24 Full Copyright Statement..........................................25
2. Conventions used in this document 2. Conventions used in this document
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119. this document are to be interpreted as described in RFC-2119.
3. Introduction 3. Introduction
This document describes a framework for Internet traffic engineering This document describes a framework for Internet traffic engineering
measurement, with the objective of providing principles for the measurement, with the objective of providing principles for the
development of a set of measurement systems to support the traffic development of a set of measurement systems to support the traffic
engineering of IP-based networks [1]. A major goal is to provide engineering of IP-based networks [1]. A major goal is to provide
guidance for establishing protocol-independent and platform-neutral the scope of measurements involved and outline a context for
traffic measurement standards to achieve multi-vendor inter- establishing operator-, platform-, protocol-, and vendor-neutral
operability. It is critical to minimize the possibilities of traffic measurement standards. To achieve multi-vendor inter-
operability, it is critical to minimize the possibilities of
inconsistencies arising from, e.g., differing statistical inconsistencies arising from, e.g., differing statistical
definitions, overlapping data collection, processing at different definitions, overlapping data collection, processing at different
protocol levels, and similar inconsistencies by different vendors or protocol levels, and similar inconsistencies by different vendors or
network operators. network operators.
The need for a common framework, including detailed definitions for The need for a common framework, including identification,
measurements, is motivated by the needs for consistency, precision, principles and scope of measurements, is motivated by the needs for
and effectiveness of the overall traffic engineering function. consistency, precision, and effectiveness of the overall traffic
Traffic engineering includes measurements, forecasting, planning, engineering function. Traffic engineering includes measurements,
dimensioning, control, and performance monitoring. From this forecasting, planning, dimensioning, control, and performance
perspective, the purpose of this document is to set principles of monitoring. From this perspective, the purpose of this document is
measurement in place that assure the quality of the other aspects of to set principles of measurement in place that assure the quality of
traffic engineering. the other aspects of traffic engineering. Intended as a framework
document, our goal is to describe the overall traffic and
performance measurement process at a high level. We point to
objectives that a comprehensive set of measurement standards should
achieve. We also list brief informal definitions for most
measurements of interest, but leaving exhaustive and precise
definitions and standards to the documents cited or subsequent
documents to be developed by other working groups.
The scope of this document is limited to those aspects of The scope of this document is limited to those aspects of
measurement pertaining to intra-domain operations, i.e., within a measurement pertaining to intra-domain operations, i.e., within a
given autonomous system. However, measurements on its boundary with given autonomous system. However, measurements on its boundary with
other domains are included as well. The focus is primarily on other domains are included as well. The focus is primarily on
traffic engineering in Internet service provider environments. traffic engineering in Internet service provider environments.
In this document, uses of traffic measurement in traffic In this document, uses of traffic measurement in traffic
characterization, network monitoring, and traffic control are first characterization, network monitoring, and traffic control are first
described. Depending on the network operations to be performed in described. Depending on the network operations to be performed in
skipping to change at page 4, line 4 skipping to change at page 4, line 8
representation of measurements are identified as well. representation of measurements are identified as well.
Traffic measurement can be performed on the basis of flows, Traffic measurement can be performed on the basis of flows,
interfaces, links, nodes, node-pairs, or paths. Based on these interfaces, links, nodes, node-pairs, or paths. Based on these
objects, different measurement entities can be defined, such as objects, different measurement entities can be defined, such as
traffic volume, average holding time, bandwidth availability, traffic volume, average holding time, bandwidth availability,
throughput, delay, delay variation, packet loss, and resource usage. throughput, delay, delay variation, packet loss, and resource usage.
Using these measured traffic data, in conjunction with other network Using these measured traffic data, in conjunction with other network
data such as topological data and router configuration data, traffic data such as topological data and router configuration data, traffic
matrix and other relevant statistics can be derived for traffic matrix and other relevant statistics can be derived for traffic
engineering purposes. Traffic measurement also plays a key role in engineering purposes. Traffic load measurement also plays a key
network performance management. role in network performance management.
In addition to these capabilities, functions of a measurement system In addition to these capabilities, functions of a measurement system
should also include data storage, data processing, statistics should also include data storage, data processing, statistics
generation and reporting. However, these aspects are outside the generation and reporting. However, these aspects are outside the
scope of this document. scope of this document.
As a framework, this document is mainly concerned with a discussion As a framework, this document is mainly concerned with a discussion
of various technical issues surrounding traffic measurement, of various technical issues surrounding traffic measurement,
particularly in the area of statistical traffic load estimation for particularly in the area of statistical traffic load estimation for
traffic engineering purposes. As far as possible and to avoid traffic engineering purposes. As far as possible and to avoid
skipping to change at page 5, line 20 skipping to change at page 5, line 24
Traffic volume, as a measure of the traffic carried, characterizes Traffic volume, as a measure of the traffic carried, characterizes
the level of traffic that a network is designed to support. the level of traffic that a network is designed to support.
Passive, i.e., in-service non-intrusive, measurement of the traffic Passive, i.e., in-service non-intrusive, measurement of the traffic
volume is usually used to estimate the long-term offered traffic for volume is usually used to estimate the long-term offered traffic for
the purposes of network dimensioning in the capacity-management and the purposes of network dimensioning in the capacity-management and
network-planning processes (see the Section on Time Scales for network-planning processes (see the Section on Time Scales for
Network Operations). A network should be properly dimensioned so Network Operations). A network should be properly dimensioned so
that its throughput is adequate to handle the expected traffic that its throughput is adequate to handle the expected traffic
volume. volume.
Throughput is expressed in terms of number of data units per time Throughput at a cross-section, or specific point in the network, is
unit. Traffic volume is expressed in data units with reference to a expressed in terms of number of data units per time unit. Traffic
read-out period (see the Section on Read-Out Periods). For volume is expressed in data units with reference to a read-out
transmission systems, the data unit is usually a multiple of either period (see the Section on Read-Out Periods). For transmission
bits or bytes. For processing systems, the data unit is usually a systems, the data unit is usually a multiple of either bits or
multiple of packets. bytes. For processing systems, the data unit is usually a multiple
of packets.
5. Uses of Traffic Measurement 5. Uses of Traffic Measurement
Traffic measurement is used to collect traffic data for the Traffic measurement is used to collect traffic data for the
following purposes: following purposes:
. Traffic characterization . Traffic characterization and capacity planning
. Network monitoring . Network monitoring
. Traffic control . Traffic control
5.1 Traffic characterization 5.1 Traffic characterization
. Identifying traffic patterns, particularly traffic peak patterns, . Identifying traffic patterns, particularly traffic peak patterns,
and their variations in statistical analysis; this includes and their variations in statistical analysis; this includes
developing traffic profiles to capture daily, weekly, or seasonal developing traffic profiles to capture daily, weekly, or seasonal
variations. variations.
. Determining traffic distributions in the network on the basis of . Determining traffic distributions in the network on the basis of
skipping to change at page 6, line 22 skipping to change at page 6, line 26
serve as a means of sectionalizing performance issues seen by a serve as a means of sectionalizing performance issues seen by a
customer. [QoS reflects the performance perceivable by a user of customer. [QoS reflects the performance perceivable by a user of
a service, while GoS (grade of service) is used by a service a service, while GoS (grade of service) is used by a service
provider for internal design and operation of a network.] provider for internal design and operation of a network.]
. Evaluating the effectiveness of traffic engineering policies, or . Evaluating the effectiveness of traffic engineering policies, or
triggering certain policy-based actions (such as alarm generation, triggering certain policy-based actions (such as alarm generation,
or path preemption) upon threshold crossing; this may be based on or path preemption) upon threshold crossing; this may be based on
the use of performance history data. the use of performance history data.
. Verifying peering agreements between service providers by . Verifying peering agreements between service providers by
monitoring/measuring the traffic flows over interconnecting links monitoring/measuring the traffic flows over interconnecting links
at border routers; this includes the estimation of inter- and at border routers (note that peers are in general not willing to
intra-network traffic, as well as originating, terminating, and divulge detailed traffic picture inside their autonomous systems);
transit traffic that are being exchanged between peers. this includes the estimation of inter- and intra-network traffic,
as well as originating, terminating, and transit traffic that are
being exchanged between peers.
An example of using traffic measurements in this area might be An example of using traffic measurements in this area might be
monitoring packet loss rates at various points in a network to monitoring packet loss rates at various points in a network to
detect apparent link failure. Another example is monitoring the QoS detect apparent link failure. Another example is monitoring the QoS
delivered to external peers by an autonomous system to ensure that delivered to external peers by an autonomous system to ensure that
peering agreements are met. peering agreements are met.
5.3 Traffic control 5.3 Traffic control
. Adaptively optimizing network performance in response to network . Adaptively optimizing network performance in response to network
skipping to change at page 7, line 18 skipping to change at page 7, line 25
Broadly speaking, the following three time scales can be classified, Broadly speaking, the following three time scales can be classified,
according to the use of observed traffic information for network according to the use of observed traffic information for network
operations [15]. operations [15].
Network planning Network planning
Information that changes on the order of months is used to make Information that changes on the order of months is used to make
traffic forecasts as a basis for network extensions and long-term traffic forecasts as a basis for network extensions and long-term
network configuration. That is, for planning the topology of the network configuration. That is, for planning the topology of the
network, planning alternative routes to survive failures or network, planning alternative routes to survive failures or
determining where capacity must be augmented in advance of projected determining where capacity must be augmented in advance of projected
traffic growth. Forecasting and planning may also lead to the traffic growth. Long-term planning includes the selection and
introduction of new technology and architecture. timing of the introduction of new architectures, technologies and
vendors, in alignment with financial forecasts and market
assessments.
Capacity management Capacity management
Information that changes on the order of days or hours is used to Intermediate-scale (e.g., six months or less) capacity planning
manage the deployed facilities, by taking appropriate maintenance or deals with detailed implementation of the build plan, short-lead-
engineering actions to optimize utilization. For example, new MPLS time activities and out-of-plan events. It typically uses a
tunnels may be set up or existing tunnels modified while meeting rolling-month forecast of traffic and demand. Information that
service level agreements. Also, load balancing may be performed, or changes on the order of days or hours is used to manage the deployed
traffic may be rerouted for re-optimization after a failure. facilities, by taking appropriate maintenance or engineering actions
to optimize utilization. For example, new MPLS tunnels may be set
up or existing tunnels modified while meeting service level
agreements. Also, load balancing may be performed, or traffic may
be rerouted for re-optimization after a failure.
Real-time network control Real-time network control
Information that changes on the order of minutes or less is used to Information that changes on the order of minutes or less is used to
adapt to the current network conditions in near real time. Thus, to adapt to the current network conditions in near real time. Thus, to
combat localized congestion, traffic management actions may perform combat localized congestion, traffic management actions may perform
temporary rerouting to redistribute the load. Upon detecting a temporary rerouting to redistribute the load. Upon detecting a
failure, traffic may be diverted to pre-established, secondary failure, traffic may be diverted to pre-established, secondary
routes until more optimized routes can be arranged. routes until more optimized routes can be arranged.
7. Read-Out Periods 7. Read-Out Periods
skipping to change at page 8, line 12 skipping to change at page 8, line 24
means for pruning down the overall volume of traffic data that a TE means for pruning down the overall volume of traffic data that a TE
system may ultimately have to store, maintain, and process. system may ultimately have to store, maintain, and process.
A measurement interval is the time interval over which measurements A measurement interval is the time interval over which measurements
are taken. Some traffic data must be collected continuously, while are taken. Some traffic data must be collected continuously, while
others by sampling, or on a scheduled basis. For example, peak others by sampling, or on a scheduled basis. For example, peak
loads and peak periods can be identified only by continuous loads and peak periods can be identified only by continuous
measurement as traffic typically fluctuates irregularly during the measurement as traffic typically fluctuates irregularly during the
whole day. If traffic variations are regular and predictable, it whole day. If traffic variations are regular and predictable, it
may be possible to measure the expected normal load on pre- may be possible to measure the expected normal load on pre-
determined portions of the day. This requires the definition of a determined portions of the day. Such duration of peak traffic is
busy period. Special studies on selected segments of the network referred to as a busy period. Special studies on selected segments
may be conducted on a scheduled basis. Active measurement, with the of the network may be conducted on a scheduled basis. Occasionally
involvement of network operator, may be activated manually. For unexpected events or other decision support needs may arise that
instance, active throughput measurement may be used to identify require ad-hoc, unscheduled measurement, with the involvement of
alternate routes during periods of network congestion. network operator, and in such a case measurements may be activated
manually. For instance, active throughput measurement may be used
to identify alternate routes for spreading traffic during periods of
network congestion.
A measurement interval consists of a sequence of consecutive read- A measurement interval consists of a sequence of consecutive read-
out periods. Summarization is usually done by integrating the raw out periods. Summarization is usually done by integrating the raw
data over a pre-specified read-out period. The granularity of this data over a pre-specified read-out period. The granularity of this
period must be suitably chosen. It should be short enough to period must be suitably chosen. It should be short enough to
capture, with acceptable accuracy, the bursty nature of the traffic, capture, with acceptable accuracy, the bursty nature of the traffic,
i.e., the traffic variations and peaks. Since measurements i.e., the traffic variations and peaks. Since measurements
represent a load for the router, the read-out period should not be represent a load for the router (if third-party measurement devices
so short that router performance is degraded while a voluminous are not employed), the read-out period should not be so short that
quantity of data is produced. Also, read-out may be started when router performance is degraded while a voluminous quantity of data
the measured data exceeds a preset threshold, or when the space is produced. Also, read-out may be started when the measured data
allocated for temporarily holding the data in a router is exhausted. exceeds a preset threshold, or when the space allocated for
temporarily holding the data in a router is exhausted.
For a multi-service IP-based network, each service typically has its For a multi-service IP-based network, each service typically has its
own traffic characteristics and performance objectives. To ensure own traffic characteristics and performance objectives. To ensure
that service-specific features are reflected in the measurement that service-specific features are reflected in the measurement
process, different read-out periods may be needed for different process, different read-out periods may be needed for different
classes of service. classes of service.
The concept of read-out periods applies to both active and passive
measurements. This concept is consistent with the sampling issues
for a series of measurements as developed in [2], for example. See
sections 10 and 11 of that document for important distinctions
between "singletons, samples, and statistics." The procedure of
Poisson sampling, for example, may be used within a read-out period
to select a subset of total packet events that are chosen as the
sample. Then a statistic (e.g., mean or variance) can be computed
over that sample and associated with the read-out period. Although
[2] does not discuss traffic volume measures such as a traffic
matrix, the same sampling issues arise for the traffic matrix and
other passive measurements.
8. Measurement Bases 8. Measurement Bases
Measurements can be classified on the basis of where, and at which Measurements can be classified on the basis of where, and at which
level the traffic data are gathered and aggregated. This is similar level of aggregation the traffic data are gathered. This is similar
to the concept of a *population of interest* as specified in ITU-T to the concept of a *population of interest* as specified in ITU-T
Recommendation I.380/Y.1540. As defined therein, this refers to a Recommendation I.380/Y.1540. As defined therein, this refers to a
set of packets, possibly relative to a particular pair of source and set of packets, possibly relative to a particular pair of source and
destination hosts, for the purposes of defining performance destination hosts, for the purposes of defining performance
parameters. However, measurement bases as used here may not have parameters. However, measurement bases as used here may not have
any association with a source-destination pair. any association with a source-destination pair.
In this document, customer-based measurements are not considered. In this document, the focus is on service providers as organizations
requiring traffic and performance measurements. (However, customer-
based measurements of enterprise networks may have similar issues.)
Service providers will make decisions on how to perform the Service providers will make decisions on how to perform the
measurements needed, and there are various tradeoffs involved. One measurements needed, and there are various tradeoffs involved. One
option is to obtain the measurements directly from the network option is to obtain the measurements directly from the network
elements themselves, e.g., via SNMP (Simple Network Management elements themselves, e.g., via SNMP (Simple Network Management
Protocol). Collecting the measurements on the operational network Protocol). Collecting the measurements on the operational network
elements such as routers is sometimes a performance concern. elements such as routers is sometimes a performance concern.
Currently, there are a number of third-party measurement/monitoring Currently, there are a number of third-party measurement/monitoring
products available. Hence, another option is to deploy such products available. Hence, another option is to deploy such
equipment, which might have performance advantages but also equipment, which might have performance advantages but also
introduces additional cost. introduces additional cost.
skipping to change at page 9, line 29 skipping to change at page 10, line 7
synchronized boundaries). A schedule therefore should include such synchronized boundaries). A schedule therefore should include such
time information as the start, the duration, and periodicity of a time information as the start, the duration, and periodicity of a
certain measurement. certain measurement.
The following measurement bases are considered in this document: The following measurement bases are considered in this document:
. Flow-based . Flow-based
. Interface-based, link-based, node-based . Interface-based, link-based, node-based
. Node-pair-based . Node-pair-based
. Path-based . Path-based
Generally speaking, for traffic engineering purposes, passive
measurements are mostly used. However, as to be described later in
the "Measurement Types" section, the above measurement bases may
result in active or passive measurements. For example, an active
measurement may be a two-point delay metric such as type-P-one-way-
delay defined in [4], and obtained by time-stamping probe packets at
selected ingress and egress points; a passive measurement may be to
obtain packet inter-arrival times by time-stamping at a selected
point in the network successive packets of the offered traffic.
Note that both active and passive measurements are subject to the
same sampling and time-source accuracy concerns.
MPLS has certain advantages when compared with conventional IP
networks, from the perspective of the difficulty involved in
obtaining unambiguous measurements. As different service providers
will adopt different technologies, technology-neutral solutions to
the problem of obtaining measurements are presented as far as
possible.
Applicability of traffic measurements to the derivation of traffic
matrix statistics and performance monitoring are to be described in
later sections.
8.1 Flow-based 8.1 Flow-based
This is conceptually similar to the call detail record (CDR) in This is conceptually similar to the call detail record (CDR) in
circuit-switched telecommunications networks. It is primarily used circuit-switched telecommunications networks. It is primarily used
on interfaces at access routers, edge routers, or aggregation on interfaces at access routers, edge routers, or aggregation
routers where traffic originates or terminates, rather than on routers where traffic originates or terminates, rather than on
backbone routers in the core network. Like CDR measurements, flow- backbone routers in the core network. Like CDR measurements, flow-
based records are used to collect detailed information about a flow. based records are used to collect detailed information about a flow.
This includes such information as source and destination IP This includes such information as source and destination IP
addresses/port numbers, protocol, type of service, timestamps for addresses/port numbers, protocol, type of service, timestamps for
skipping to change at page 9, line 50 skipping to change at page 10, line 51
As flow is a fine-grained object, measuring every flow that passes As flow is a fine-grained object, measuring every flow that passes
through all the edge devices may not be scalable or feasible. through all the edge devices may not be scalable or feasible.
Hence, per-flow data are usually used in a special study conducted Hence, per-flow data are usually used in a special study conducted
on a non-continuous schedule and on selected routers only. Sampling on a non-continuous schedule and on selected routers only. Sampling
of flow-based measurements may also be needed to reduce both the of flow-based measurements may also be needed to reduce both the
amount of data collected and the associated overhead. amount of data collected and the associated overhead.
8.2 Interface-based, link-based, node-based 8.2 Interface-based, link-based, node-based
Passive measurement can be taken at each network element. For While active measurements are often not useful at a single point,
passive measurements can be taken at each network element. For
example, SNMP uses passive monitoring to collect raw data on an example, SNMP uses passive monitoring to collect raw data on an
interface at an edge or backbone router. These data are stored in interface at an edge or backbone router. These data are stored in
MIBs (Management Information Bases) and include counts on packets MIBs (Management Information Bases) and include counts on packets
and octets sent/received, packet discards, errored packets. and octets sent/received, packet discards, errored packets. Such
measurements may have the disadvantage that the identity of each
flow is lost.
To reduce the overhead in managing multiple links between the same To reduce the overhead in managing multiple links between the same
ingress and egress points, there is proposal to aggregate links for ingress and egress points, there is proposal to aggregate links for
network optimization [16]. Component links in such a *bundled link* network optimization [16]. Component links in such a *bundled link*
will have same routing constraints, resource classes, and will have the same routing constraints, resource classes, and
attributes. Multiple links are treated as a single IP link. attributes. Multiple links are treated as a single IP link.
Traffic measurements, such as bandwidth availability, throughput, Traffic measurements, such as bandwidth availability, throughput,
should consider the measurements for bundled links. Also, such etc., should consider the measurement implications for bundled
links, and should not inhibit link bundling. Also, such
measurements should be protocol independent and media independent to measurements should be protocol independent and media independent to
ensure portability and commonality in the measurements. ensure portability and commonality in the measurements.
8.3 Node-pair-based 8.3 Node-pair-based
Active measurements by probing, as specified in the IPPM framework, Active measurements by probing, as specified in the IPPM framework
can be conducted between each pair of major routing hubs for for example, can be conducted between each pair of major routing
determining edge-to-edge performance of a core network. This hubs for determining edge-to-edge performance of a core network.
complements the passive measurements of the previous sub-section, This complements the passive measurements of the previous sub-
which provide local views of the performance of individual network section, which provide local views of the performance of individual
elements. network elements.
In telecommunications networks, each established call has an In contrast to performance statistics, traffic loading statistics
associated node-pair. By maintaining a set of node-pair data require passive measurements of the actual traffic. In circuit-
registers (usage, peg count, overflow, etc) in each switch, node- switched telecommunications networks, each established call has an
pair-based measurements for traffic statistics such as the load associated source/destination node-pair. By maintaining a set of
between a given node pair are taken directly. In contrast, in IP- node-pair data registers (usage, peg count, overflow, etc) in each
based networks, currently such kind of node-pair-based measurements switch, node-pair-based measurements for traffic statistics such as
cannot be taken directly. However, it is possible to infer them the load between a given node pair are taken directly. In IP-based
from flow-based passive measurements and other network information. networks, currently such node-pair-based measurements are difficult
A problem with this approach is that flow-based measurement data are to establish due to the dynamic and asymmetric properties of IP
voluminous. Also, another problem that must be accounted for is the routing. However, it is possible to infer them from flow-based
routing changes among the multiple routes due to, e.g., a change in passive measurements and other network information, such as routing
the configuration of intradomain routing, or a change in interdomain table snapshots. A problem with this approach is that flow-based
policies made by another autonomous system. This is further measurement data are voluminous. Also, another problem that must be
discussed in the Section on Traffic Matrix Statistics. accounted for is the routing changes among the multiple routes due
to, e.g., a change in the configuration of intradomain routing, or a
change in interdomain policies made by another autonomous system.
This is further discussed in the Section on Traffic Matrix
Statistics.
8.4 Path-based 8.4 Path-based
The ability of MPLS to use fixed preferred paths for routing The ability of MPLS to use fixed preferred paths for routing
traffic, so-called route pinning, gives the means to develop path- traffic, so-called route pinning, gives the means to develop path-
based measurements. This may enable the development of based measurements. This may enable the development of
methodologies for such functions as admission control and methodologies for such functions as admission control and
performance verification of delivered service. performance verification of delivered service.
Like a flow, a path is associated with a pair of nodes. However, Like a flow, a path is associated with a pair of nodes. However,
path is a more coarse-grained object than flow, as paths are usually path is a more coarse-grained object than flow, as paths are usually
used to carry aggregated traffic. In addition, when routing changes used to carry aggregated traffic. In addition, when routing changes
occur, the amount of traffic to be carried by a path will either not occur, the amount of traffic to be carried by a path will either not
be affected or be merged with that of another path. Because of be affected or be merged with that of another path. Because of
these properties, path-based measurements are more scalable and may these properties, path-based measurements are more scalable and may
be used to provide more readily an accurate, network-wide, view of be used to provide more readily an accurate, network-wide, view of
the traffic demands. For example, the traffic between a given pair the traffic demands. For example, the traffic between a given pair
of nodes may be inferred from the aggregate of the traffic carried of nodes may be inferred from the aggregate of the traffic carried
by the all the paths either terminated by or passed through the same by all paths either terminated by or passed through the same node-
node-pair. pair.
9. Measurement Entities 9. Measurement Entities
A measurement entity defines what is measured: it is a quantity for A measurement entity defines what is measured: it is a quantity for
which data collection must be performed with a certain measurement. which data collection must be performed with a certain measurement.
A measurement type can be specified by a (meaningful) combination of A measurement type can be specified by a (meaningful) combination of
a measurement entity with the measurement basis described in the a measurement entity with the measurement basis described in the
previous section. previous section.
9.1 Entities related to traffic and performance 9.1 Entities related to traffic and performance
skipping to change at page 11, line 35 skipping to change at page 12, line 43
Note: (1) This is a measurement for the traffic carried by a Note: (1) This is a measurement for the traffic carried by a
network, a network segment, or an individual network element; it network, a network segment, or an individual network element; it
is used to derive the carried load or carried traffic intensity is used to derive the carried load or carried traffic intensity
[17]. When measured during the busy period, this entity is [17]. When measured during the busy period, this entity is
normally used to estimate the traffic offered. However, the normally used to estimate the traffic offered. However, the
estimation procedure should take into account such factors as estimation procedure should take into account such factors as
congestion, which may result in decreased carried traffic. In congestion, which may result in decreased carried traffic. In
addition, congestion may lead to user behavior such as reattempt addition, congestion may lead to user behavior such as reattempt
or abandonment, which may affect the actual traffic offered. (2) or abandonment, which may affect the actual traffic offered. (2)
To reduce uncertainty in traffic estimation, second-order measures To reduce uncertainty in traffic estimation, second-order measures
may need to be developed. (3) Measurement of traffic volumes over may need to be developed. Beyond the use of variance as in
interconnecting links at border routers can be used to estimate current practice, further study is needed for the feasibility of
the traffic exchange between peers for contract verification. other second-order techniques. (3) Measurement of traffic volumes
over interconnecting links at border routers can be used to
estimate the traffic exchange between peers for contract
verification.
. Average holding time (e.g., flow duration or lifetime, duration of . Average holding time (e.g., flow duration or lifetime, duration of
an MPLS path), on a per service class basis an MPLS path), on a per service class basis
Note: (1) This is similar to call holding time in Note: (1) When MPLS traffic engineering is used, this is similar
telecommunications networks. Peg count, usage, and call holding to call holding time in telecommunications networks. Peg count,
time are three busy-hour entities that should be independently usage, and call holding time are three busy-hour entities that
measured for both call-dependent and load-dependent engineering. should be independently measured for both call-dependent and load-
This is important especially when the call busy hour and the load dependent engineering. This is important especially when the call
busy hour during a day are non-coincident, due to the hour-to-hour busy hour and the load busy hour during a day are non-coincident,
variation of call holding times. (2) The holding time statistics due to the hour-to-hour variation of call holding times. (2) The
of long-living static paths reflect the effect of network holding time statistics of long-living static paths reflect the
equipment failures, link outages, or scheduled maintenance, and effect of network equipment failures, link outages, or scheduled
hence may to used to derive information about up-time or service maintenance, and hence may to used to derive information about up-
availability. time or service availability.
. Available bandwidth of a link or path - useful for load balancing, . Available bandwidth of a link or path - useful for load balancing,
measurement-based admission control to determine the feasibility measurement-based admission control to determine the feasibility
of creating a new MPLS tunnel (real-time information can be used of creating a new MPLS tunnel (real-time information can be used
for dynamic establishment) for dynamic establishment)
. Throughput (in bits per second, bytes per second, or packets per . Throughput (in bits per second, bytes per second, or packets per
second) second)
Note: (1) This is a measure of the "goodput." That is, the rate Note: (1) This is a measure of the "goodput." That is, the rate
at which a given amount of traffic excluding lost, misdelivered, at which a given amount of traffic excluding lost, misdelivered,
or errored packets, that passes between a set of end points, where or errored packets, that passes between a set of end points, where
end points can be logically or physically defined. The condition end points can be logically or physically defined. The condition
of the network, e.g., normal or high load, under which the of the network, e.g., normal or high load, under which the
measurement is taken should be noted. (2) The protocol level at measurement is taken should be noted. (2) The protocol level at
which a throughput measurement is taken must be specified, as the which a throughput measurement is taken must be specified, as the
packet payload and packet overheads are protocol dependent. (3) packet payload and packet overheads are protocol dependent. (3)
skipping to change at page 12, line 15 skipping to change at page 13, line 27
second) second)
Note: (1) This is a measure of the "goodput." That is, the rate Note: (1) This is a measure of the "goodput." That is, the rate
at which a given amount of traffic excluding lost, misdelivered, at which a given amount of traffic excluding lost, misdelivered,
or errored packets, that passes between a set of end points, where or errored packets, that passes between a set of end points, where
end points can be logically or physically defined. The condition end points can be logically or physically defined. The condition
of the network, e.g., normal or high load, under which the of the network, e.g., normal or high load, under which the
measurement is taken should be noted. (2) The protocol level at measurement is taken should be noted. (2) The protocol level at
which a throughput measurement is taken must be specified, as the which a throughput measurement is taken must be specified, as the
packet payload and packet overheads are protocol dependent. (3) packet payload and packet overheads are protocol dependent. (3)
The average packet size may be inferred from the bit rate and The average packet size may be inferred from the bit rate and
packet rate measurements. This quantity is useful to gauge router packet rate measurements, when performed on the basis of an
individual router. This quantity is useful to gauge router
performance, since router operations are typically packet-oriented performance, since router operations are typically packet-oriented
and small packets are more processing-intensive. and small packets are more processing-intensive.
. Delay (e.g., cross-router delay from node-based measurement may be . Delay (e.g., cross-router delay from node-based measurement may be
used to measure queueing delay within a router; end-to-end one-way used to measure queueing delay within a router; end-to-end one-way
or round-trip packet delay can be obtained by node-pair-based or round-trip packet delay can be obtained by node-pair-based
measurement) measurement)
Note: The condition of the network, e.g., normal or high load, Note: The condition of the network, e.g., normal or high load,
under which the measurement is taken should be noted. This is under which the measurement is taken should be noted. This is
useful to determine if delay objectives are met. useful to determine if delay objectives are met.
skipping to change at page 12, line 46 skipping to change at page 14, line 6
method and the average delay of the population of packets in the method and the average delay of the population of packets in the
second method. The third alternative, interval-based method, second method. The third alternative, interval-based method,
measures the percentage of packets with delay variations that fall measures the percentage of packets with delay variations that fall
outside some pre-specified delay variation interval. Finally, the outside some pre-specified delay variation interval. Finally, the
quantile-based method measures the distance (in time units) quantile-based method measures the distance (in time units)
between pre-selected quantiles, e.g., 99.5 percentile and 0.5 between pre-selected quantiles, e.g., 99.5 percentile and 0.5
percentile, of the delay variation distribution. This method is percentile, of the delay variation distribution. This method is
tighter than the interval-based method since it bounds the tail of tighter than the interval-based method since it bounds the tail of
the delay variation distribution. In Y.1541, additional the delay variation distribution. In Y.1541, additional
considerations and more alternatives of delay variations are considerations and more alternatives of delay variations are
described. (2) In IPPM [8], the concept of a selection function described. (2) In IPPM [9], the concept of a selection function
is introduced that allows for the explicit designation of selected is introduced that allows for the explicit designation of selected
packets whose one-way delay values are compared to compute one-way packets whose one-way delay values are compared to compute one-way
delay variation. For example, a selection function can be defined delay variation. For example, to define a method of measurement,
to select the consecutive packets within a specified interval, or a selection function can be specified to select the consecutive
to select the maximum and minimum one-way delays within a packets within a specified interval, or to select the maximum and
specified interval. minimum one-way delays within a specified interval.
. Packet loss . Packet loss
Note: (1) While packet losses due to transmission and/or protocol Note: (1) While packet losses due to transmission and/or protocol
errors may not be traffic related, unexpected excessive loss may errors may not be traffic related, unexpected excessive loss may
be used as a means of fault detection. (2) Packet losses due to be used as a means of fault detection. (2) Packet losses due to
policing or network congestion should be distinguished. The policing or network congestion should be distinguished. The
former is a result of user violation of service contract and the former is a result of user violation of service contract and the
network operator should not be penalized for it. The latter, network operator should not be penalized for it. The latter,
whether intentional or unintentional, is caused by network whether intentional or unintentional, is caused by network
conditions such as buffer overflow, router forwarding process conditions such as buffer overflow, router forwarding process
skipping to change at page 13, line 46 skipping to change at page 15, line 5
Where connection admission control is used, a measurement entity for Where connection admission control is used, a measurement entity for
monitoring network performance may be the proportion of connections monitoring network performance may be the proportion of connections
denied admission. Also, it may be useful to score the requested denied admission. Also, it may be useful to score the requested
bandwidth within the traffic parameters for the setup request. bandwidth within the traffic parameters for the setup request.
Corresponding to the number of call attempts (i.e., peg count) in Corresponding to the number of call attempts (i.e., peg count) in
telecommunications networks, the number of connection requests, the telecommunications networks, the number of connection requests, the
number of flows, etc., may be measured in given read-out periods to number of flows, etc., may be measured in given read-out periods to
characterize the traffic. characterize the traffic.
To characterize paths, the following measurement entities may be To characterize paths for MPLS traffic engineering, the following
defined: path setup delay, path setup error probability, path setup measurement entities may be defined: path setup delay, path setup
denial (blocking) probability, path release delay, path disconnect error probability, path setup denial (blocking) probability, path
probability, path restoration time. release delay, path disconnect probability, path restoration time.
10. Measurement Types 10. Measurement Types
A measurement matrix can be defined wherein each column represents a A measurement matrix can be defined wherein each column represents a
measurement basis and each row represents a measurement entity. An measurement basis and each row represents a measurement entity. An
entry in this measurement matrix, corresponding to a meaningful and entry in this measurement matrix, corresponding to a meaningful and
measurable combination of an entity and a basis, defines a measurable combination of an entity and a basis, defines a
particular measurement type. For each measurement type, there particular measurement type. For each measurement type, there
should be a set of measurement points specified to bound the network should be a set of measurement points specified to bound the network
segment for the purposes of taking measurement. A measurement point segment for the purposes of taking measurement. A measurement point
may be the physical boundary between a node and an adjacent link, or may be the physical boundary between a node and an adjacent link, or
the logical interface between two protocol layers in a protocol the logical interface between two protocol layers in a protocol
stack. stack.
10.1 Measurement types related to traffic or performance 10.1 Measurement types related to traffic or performance
The following measurement matrix illustrates some of the measurement The following measurement matrix illustrates some of the measurement
types related to traffic or performance. Potentially, there can be types related to traffic or performance. Potentially, there can be
one such matrix for each service class. one such matrix for each service class. Since this table is for
illustration purposes, it is not necessary for a service provider to
implement all the measurement types below.
Bases: Flow Interface, Node Pair Path Bases: Flow Interface, Node Pair Path
Node Node
Entities: (passive) (passive) (both) (both) Entities: (passive) (passive) (both) (both)
Traffic Volume x(1) x x(3) x(3) Traffic Volume x(1) x x(3) x(3)
Avg. Hold. Time x x(3) Avg. Hold. Time x x(3)
Avail. Bandwidth x x(3) Avail. Bandwidth x x(3)
Throughput x(4) x(4) Throughput x(4) x(4)
Delay x(2) x(4) x(4) Delay x(2) x(4) x(4)
Delay Variation x(2) x(4) x(4) Delay Variation x(2) x(4) x(4)
skipping to change at page 15, line 54 skipping to change at page 17, line 15
based routing/forwarding in IGP provides a network operator with based routing/forwarding in IGP provides a network operator with
primitive and limited control over the routing of traffic flows. primitive and limited control over the routing of traffic flows.
This necessitates the association of a time sequence of forwarding This necessitates the association of a time sequence of forwarding
tables from different routers to reconstruct the different routes tables from different routers to reconstruct the different routes
used by the network over time. By using this auxiliary information, used by the network over time. By using this auxiliary information,
together with flow-based measurements, the above-cited references together with flow-based measurements, the above-cited references
describe how to determine the traffic volume from an ingress link to describe how to determine the traffic volume from an ingress link to
a set of egress links by validating and joining various data sets a set of egress links by validating and joining various data sets
together. together.
Some shortcomings in today's method to derive traffic matrix As described in Section 8.3, some shortcomings in today's method to
statistics as above include the volume of data from flow-based derive traffic matrix statistics as above include the volume of data
measurement, the lack of sufficient routing control information, and from flow-based measurement, the lack of sufficient routing control
the need to correlate data from a variety of sources. The routing information, and the need to correlate data from a variety of
control offered by MPLS can be used to avoid some of these sources. The routing control offered by MPLS can be used to avoid
deficiencies. To take advantage of this capability, path-based some of these deficiencies. To take advantage of this capability,
passive measurement should be developed. Furthermore, as explained path-based passive measurement should be developed. Furthermore, as
in the Section on Path-based Measurement Bases, by aggregating the explained in the Section on Path-based Measurement Bases, by
appropriate set of path-based traffic data, the corresponding node- aggregating the appropriate set of path-based traffic data, the
pair-based traffic data can be obtained. This will facilitate the corresponding node-pair-based traffic data can be obtained. This
derivation of traffic matrix statistics, possibly on a per service will facilitate the derivation of traffic matrix statistics,
class basis. Note that in the case of hop-by-hop routed label- possibly on a per service class basis. Note that in the case of
switched paths that are established by Label Distribution Protocol hop-by-hop routed label-switched paths that are established by Label
(LDP) signaling, there is no explicit binding between path end Distribution Protocol (LDP) signaling, there is no explicit binding
points. This will result in the use of different label bindings at between path end points. This will result in the use of different
both the ingress and egress nodes over time as network topology label bindings at both the ingress and egress nodes over time as
changes. Although the forwarding equivalence class (FEC) to label network topology changes. Although the forwarding equivalence class
binding information already exists in the MPLS FTN and LSR MIBs [23, (FEC) to label binding information already exists in the MPLS FTN
18], a mechanism is needed to keep track of binding changes. An and LSR MIBs [23, 18], a mechanism is needed to keep track of
example of such a mechanism may be the periodic exchange of FEC to binding changes. An example of such a mechanism may be the periodic
label binding information for each ingress-egress pair. exchange of FEC to label binding information for each ingress-egress
pair.
Besides traffic engineering, a major application of MPLS is the Besides traffic engineering, a major application of MPLS is the
support of network-based virtual private networks (VPNs). A VPN can support of network-based virtual private networks (VPNs). A VPN can
be an enterprise network or a carrier's carrier network. It is not be an enterprise network or a carrier's carrier network. It is not
the purpose of this document to discuss VPNs. However, it is the purpose of this document to discuss VPNs. However, it is
relevant to highlight the use of traffic measurements to maintain relevant to highlight the use of traffic measurements to maintain
proper engineering and performance of MPLS tunnels in the support of proper engineering and performance of MPLS tunnels in the support of
VPNs between VPN sites. This would include also the support for VPNs between VPN sites. This would include also the support for
MPLS-based pseudo-wire connections as developed by the PWE3 Working MPLS-based pseudo-wire connections as developed by the PWE3 Working
Group [24]. For example, path-based measurement by a network Group [24]. For example, path-based measurement by a network
skipping to change at page 17, line 6 skipping to change at page 18, line 20
information about the operational state of the network and to track information about the operational state of the network and to track
its performance. For a discussion of passive monitoring and the use its performance. For a discussion of passive monitoring and the use
of synthetic traffic sources in active probing, see [28]. Alarms of synthetic traffic sources in active probing, see [28]. Alarms
may be generated when the state of a network element exceeds may be generated when the state of a network element exceeds
prescribed thresholds. prescribed thresholds.
Performance degradation can occur as a result of routing Performance degradation can occur as a result of routing
instability, congestion, or failure of network components. Periods instability, congestion, or failure of network components. Periods
of congestion may be detected when the resource usage of a network of congestion may be detected when the resource usage of a network
segment consistently exceeds a certain threshold, or when the cross- segment consistently exceeds a certain threshold, or when the cross-
router delay is unexpectedly high. After the identification of a router delay is unexpectedly high. Unexpected excessive loss of
hot spot, active throughput measurement may be used to seek out packets or throughput drops may be used as a means of fault
alternate routes for congestion bypass. Unexpected excessive loss
of packets or throughput drops may be used as a means of fault
detection, and may result in restoration activities. detection, and may result in restoration activities.
Internet utilities such as ping and traceroute have been useful to Internet utilities such as ping and traceroute have been useful to
help diagnose network problems and performance debugging. Utilities help diagnose network problems and performance debugging. Utilities
with similar functions would be essential for path-oriented with similar functions would be essential for path-oriented
operations like in MPLS. This would include the capability to list, operations like in MPLS. This would include the capability to list,
at any time, (1) for a given path, all the nodes traversed by it, at any time, (1) for a given path, all the nodes traversed by it,
and (2) for a given node, all the paths originating from it, and (2) for a given node, all the paths originating from it,
transiting through it, and/or terminating on it. A proposal for transiting through it, and/or terminating on it. A proposal for
route tracing is described in [29]. route tracing is described in [29].
skipping to change at page 21, line 19 skipping to change at page 22, line 29
. Use of node-pair-based traffic data to derive per-service-class . Use of node-pair-based traffic data to derive per-service-class
traffic matrix statistics traffic matrix statistics
. Statistics of carried load versus performance . Statistics of carried load versus performance
. A standardized mechanism to detect and record label binding . A standardized mechanism to detect and record label binding
changes for LDP-signaled label-switched paths, to facilitate the changes for LDP-signaled label-switched paths, to facilitate the
collection of node-pair-based traffic data collection of node-pair-based traffic data
(2) traffic data collection methods (2) traffic data collection methods
. Need for uniform definitions across vendors and operators . Need for uniform measurement definitions across vendors and
operators
. Distinction between traffic offered load versus achieved . Distinction between traffic offered load versus achieved
throughput throughput
. Need for higher-order statistics for service assurance . Need for higher-order statistics for service assurance
. Need for packet-sampled measurements that preserve representative . Need for packet-sampled measurements that preserve representative
traffic detail at manageable sample volumes traffic detail at manageable sample volumes
. Need for offline bulk file transfer and standardized . Need for offline bulk file transfer and standardized
filtering/aggregation mechanisms to manage large volumes of filtering/aggregation mechanisms to manage large volumes of
measured traffic data measured traffic data
16. Security Considerations 16. Security Considerations
The principles and concepts related to Internet traffic measurement The principles and concepts related to Internet traffic measurement
as discussed in this document do not by themselves affect the as discussed in this document do not by themselves affect the
security of the Internet. However, it is assumed that any security of the Internet. However, it is assumed that any
measurement systems that are developed or deployed by a service measurement systems that are developed or deployed by a service
provider are responsible for providing sufficient data integrity and provider are responsible for providing sufficient data integrity
confidentiality. It is also assumed that a service provider will (e.g., to prevent forgery of measurement records) and
take proper precautions to ensure that access to its measurement confidentiality (e.g., by restricting attention only to the packet
systems and all associated data is secure. Methods to achieve these headers of interest). It is also assumed that a service provider
will take proper precautions to ensure that access to its
measurement systems and all associated data is secure by using
appropriate authentication techniques. Methods to achieve these
security considerations are not addressed in this document. security considerations are not addressed in this document.
17. References 17. References
Normative References Normative References
References 1, 2, and 13 below are considered normative. References 1, 2, and 13 below are considered normative.
Informative References Informative References
1 D.O. Awduche, A. Chiu, A. Elwalid, I. Widjaja, and X. Xiao, 1 D.O. Awduche, A. Chiu, A. Elwalid, I. Widjaja, and X. Xiao,
"Overview and Principles of Internet Traffic Engineering," RFC "Overview and Principles of Internet Traffic Engineering," RFC
3272, May 2002. 3272, May 2002.
2 V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for IP 2 V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for IP
skipping to change at page 22, line 16 skipping to change at page 23, line 28
for IPPM," RFC 2679, September 1999. for IPPM," RFC 2679, September 1999.
5 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss 5 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss
Metric for IPPM," RFC 2680, September 1999. Metric for IPPM," RFC 2680, September 1999.
6 G. Almes, S. Kalidindi, and M. Zekauskas, "A Round-trip Delay 6 G. Almes, S. Kalidindi, and M. Zekauskas, "A Round-trip Delay
Metric for IPPM," RFC 2681, September 1999. Metric for IPPM," RFC 2681, September 1999.
7 M. Mathis and M. Allman, "A Framework for Defining Empirical Bulk 7 M. Mathis and M. Allman, "A Framework for Defining Empirical Bulk
Transfer Capacity Metrics," RFC 3148, July 2001. Transfer Capacity Metrics," RFC 3148, July 2001.
8 R. Koodli and R. Ravikanth, "One-way Loss Pattern Sample 8 R. Koodli and R. Ravikanth, "One-way Loss Pattern Sample
Metrics," RFC 3357, August 2002. Metrics," RFC 3357, August 2002.
9 C. Demichelis and P. Chimento, "IP Packet Delay Variation Metric 9 C. Demichelis and P. Chimento, "IP Packet Delay Variation Metric
for IPPM," Internet-Draft, Work in Progress, August 2002. for IP Performance Metrics (IPPM)," RFC 3393, November 2002.
10 V. Raisanen, G. Grotefeld, and A. Morton, "Network performance 10 V. Raisanen, G. Grotefeld, and A. Morton, "Network performance
measurement for periodic streams," Internet-Draft, Work in measurement with periodic streams," RFC 3432, November 2002.
Progress, August 2002.
11 ITU-T Recommendation I.380/Y.1540, "Internet Protocol Data 11 ITU-T Recommendation I.380/Y.1540, "Internet Protocol Data
Communication Service -- IP Packet Transfer and Availability Communication Service -- IP Packet Transfer and Availability
Performance Parameters," February 1999. Performance Parameters," February 1999.
12 ITU-T Recommendation Y.1541, "Network Performance Objectives for 12 ITU-T Recommendation Y.1541, "Network Performance Objectives for
IP-Based Services," May 2002. IP-Based Services," May 2002.
13 E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label 13 E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label
Switching Architecture," RFC 3031, January 2001. Switching Architecture," RFC 3031, January 2001.
14 S. Bradner (Editor), "Benchmarking Terminology for Network 14 S. Bradner (Editor), "Benchmarking Terminology for Network
Interconnection Devices," RFC 1242, July 1991. Interconnection Devices," RFC 1242, July 1991.
15 G. Ash, "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM- 15 G. Ash, "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM-
skipping to change at page 24, line 7 skipping to change at page 25, line 22
18. Intellectual Property Statement 18. Intellectual Property Statement
AT&T Corp. may own intellectual property applicable to packet AT&T Corp. may own intellectual property applicable to packet
sampling as presented in references [30, 31] and summarized in sampling as presented in references [30, 31] and summarized in
Section 13. AT&T is currently reviewing its licensing intent Section 13. AT&T is currently reviewing its licensing intent
relative to the Intellectual Property and will notify the IETF when relative to the Intellectual Property and will notify the IETF when
AT&T has made a determination of that intent. AT&T has made a determination of that intent.
19. Acknowledgments 19. Acknowledgments
The support of Gerald Ash on this work and his comments are much Thanks to the inputs from Gerald Ash, Jim Boyle, Robert Cole,
appreciated. Also, thanks to the inputs from Jim Boyle, Robert Enrique Cuevas, Merike Kaeo, Ed Kern, Spyros Kontogiorgis, Alfred
Cole, Enrique Cuevas, Alfred Morton, Thomas Nadeau, Moshe Segal, Morton, Thomas Nadeau, Moshe Segal, Bert Wijnen, and the Tequila
Bert Wijnen, and the Tequila project. Nick Duffield contributed project. Special thanks to Blaine Christian for starting this work
and contributing to the initial versions. Nick Duffield provided
section 13 on packet sampling. section 13 on packet sampling.
20. Author's Addresses 20. Author's Addresses
Wai Sum Lai Wai Sum Lai
AT&T Labs AT&T Labs
Room D5-3D18 Room D5-3D18
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1 732-420-3712 Phone: +1 732-420-3712
Email: wlai@att.com Email: wlai@att.com
Blaine Christian
UUNET
Room D1-2-737
22001 Loudoun County Parkway
Ashburn, VA 20147, USA
Phone: +1 703-206-5600
Email: Blaine@uu.net
Richard W. Tibbs Richard W. Tibbs
Oak City Networks & Solutions Oak City Networks & Solutions
P.O. Box 10292 304 Harvey St.
Raleigh, NC 27605, USA Radford, VA 24141, USA
Phone: +1 919-510-9551 Phone: +1 540 639 2145
Email: drtibbs@oakcitysolutions.com Email: drtibbs@oakcitysolutions.com
Steven Van den Berghe Steven Van den Berghe
Ghent University/IMEC Ghent University/IMEC
St. Pietersnieuwsstraat 41 St. Pietersnieuwsstraat 41
B-9000 Ghent, Belgium B-9000 Ghent, Belgium
Phone: ++32 9 267 35 86 Phone: ++32 9 267 35 86
E-mail: steven.vandenberghe@intec.rug.ac.be E-mail: steven.vandenberghe@intec.rug.ac.be
Full Copyright Statement Full Copyright Statement
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/