draft-ietf-tewg-measure-00.txt   draft-ietf-tewg-measure-01.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-00.txt> Document: <draft-ietf-tewg-measure-01.txt>
Category: Informational Blaine Christian Category: Informational Blaine Christian
UUNET UUNET
Richard W. Tibbs Richard W. Tibbs
OPNET Technologies Oak City Networks &
Solutions
Steven Van den Berghe Steven Van den Berghe
Ghent University/IMEC Ghent University/IMEC
August 2001 November 2001
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 1, line 49 skipping to change at page 1, line 50
1. Abstract 1. Abstract
In this document, a measurement framework for supporting the traffic In this document, a measurement framework for supporting the traffic
engineering of IP-based networks is presented. Uses of traffic engineering of IP-based networks is presented. Uses of traffic
measurement in service provider environments are described, and measurement in service provider environments are described, and
issues related to time scale and read-out period are discussed. issues related to time scale and read-out period are discussed.
Different measurement types are classified, with each being Different measurement types are classified, with each being
specified as a meaningful combination of a measurement entity and a specified as a meaningful combination of a measurement entity and a
measurement basis. measurement basis.
Table of Contents
Status of this Memo................................................1
1. Abstract........................................................1
2. Conventions used in this document...............................2
3. Introduction....................................................2
4. Terminology.....................................................4
4.1 Route, path....................................................4
4.2 Throughput, traffic volume.....................................4
5. Uses of Traffic Measurement.....................................5
5.1 Traffic characterization.......................................5
5.2 Network monitoring.............................................5
5.3 Traffic control................................................6
6. Time Scales for Network Operations..............................6
7. Read-Out Periods................................................7
8. Measurement Bases...............................................8
8.1 Flow-based.....................................................8
8.2 Interface-based, link-based, node-based........................9
8.3 Node-pair-based................................................9
8.4 Path-based....................................................10
9. Measurement Entities...........................................10
9.1 Entities related to traffic and performance...................10
9.2 Entities related to establishment of connection or path.......13
10. Measurement Types.............................................13
10.1 Measurement types related to traffic or performance..........13
10.2 Measurement types related to resource usage..................14
11. Traffic Matrix Statistics.....................................14
12. Performance Monitoring........................................15
13. Security Considerations.......................................16
14. References....................................................16
15. Acknowledgments...............................................18
16. Author's Addresses............................................18
Full Copyright Statement..........................................18
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 guidance for establishing protocol-independent and platform-neutral
traffic measurement standards to achieve multi-vendor inter- traffic measurement standards to achieve multi-vendor inter-
operability. It is critical to minimize the possibilities of operability. It is critical to minimize the possibilities of
inconsistencies arising from, e.g., overlapping data collecting and inconsistencies arising from, e.g., differing statistical
processing at various protocol levels, due to the use of different definitions, overlapping data collection, processing at different
measurement principles by different vendors or network operators. protocol levels, and similar inconsistencies by different vendors or
network operators.
The need for a common framework, including detailed definitions for
measurements, is motivated by the needs for consistency, precision,
and effectiveness of the overall traffic engineering function.
Traffic engineering includes measurements, forecasting, planning,
dimensioning, control, and performance monitoring. From this
perspective, the purpose of this document is to set principles of
measurement in place that assure the quality of the other aspects of
traffic engineering.
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, i.e., within a given measurement pertaining to intra-domain operations, i.e., within a
autonomous system as well as on its boundary with other domains. given autonomous system. However, measurements on its boundary with
The focus is primarily on traffic engineering in Internet service other domains are included as well. The focus is primarily on
provider environments. traffic engineering in Internet service provider environments.
In this document, the use of traffic measurement in traffic In this document, uses of traffic measurement in traffic
characterization, network monitoring, and traffic control is 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
these tasks, three different time scales can be identified, ranging these tasks, three different time scales can be identified, ranging
from months, through days or hours, to minutes or less. To support from months, through days or hours, to minutes or less. To support
these operations, traffic measurement must be able to capture these operations, traffic measurement must be able to capture
accurately, within a given confidence interval, the traffic accurately, within a given confidence interval, the traffic
variations and peaks without degrading network performance and variations and peaks without degrading network performance and
without generating an immense amount of data. Therefore, without generating an immense amount of data. As one consequence of
specification of a suitable read-out period for each service class the need to avoid network performance degradation, specification of
for traffic summarization is essential. a suitable read-out period for each service class for traffic
summarization is essential. Other principles such as concise
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 measurement also plays a key role in
network performance management. 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. As far of various technical issues surrounding traffic measurement,
as possible and to avoid duplication of effort, relevant work done particularly in the area of statistical traffic load estimation for
in this area by other standards organizations will be applied or traffic engineering purposes. As far as possible and to avoid
adapted, and references to them will be made. These include, in duplication of effort, relevant work done in measurements by other
particular, standards organizations will be applied or adapted, and references
to them will be made. These include, in particular,
. IP Performance Metrics (IPPM) Working Group of the IETF: its . IP Performance Metrics (IPPM) Working Group of the IETF: its
framework document [2] and the associated documents on individual framework document [2] and the associated documents on individual
metrics [3, 4, 5, 6, 7, 8, 9] metrics [3, 4, 5, 6, 7, 8, 9]
. ITU-T: Recommendation I.380/Y.1540 [10] and Draft Recommendation . ITU-T: Recommendation I.380/Y.1540 [10] and Draft Recommendation
Y.1541 [11] Y.1541 [11]
4. Terminology 4. Terminology
The intent of this section is not to provide definition or The intent of this section is not to provide definition or
description of terms used in this document. Rather, it is to description of terms used in this document. Rather, it is to
highlight the difference in usage of closely related terms. highlight the difference in usage of closely related terms.
4.1 Route, path 4.1 Route, path
skipping to change at page 4, line 22 skipping to change at page 5, line 17
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
. 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
flows, interfaces, links, nodes, node-pairs, paths, or flows, interfaces, links, nodes, node-pairs, paths, or
destinations destinations.
. estimation of the traffic load according to service classes in . Estimation of the traffic load according to service classes in
different routers and the network different routers and the network.
. observing trends for traffic growth and forecasting of traffic . Observing trends for traffic growth and forecasting of traffic
demands demands.
For example, traffic engineering measurements are usually used to
determine the statistical moments of a traffic flow. As suggested
in [14], given the time series of packet arrivals, a suitable
parametric stochastic model based on the mean and variance of the
time series can be constructed. This traffic model is then used in
the ensuing phases of traffic engineering, such as link dimensioning
to meet service objectives.
5.2 Network monitoring 5.2 Network monitoring
. determining the operational state of the network, including fault . Determining the operational state of the network, including fault
detection detection.
. monitoring the continuity and quality of network services, to . Monitoring the continuity and quality of network services, to
ensure that QoS/GoS objectives are met for various classes of ensure that QoS/GoS objectives are met for various classes of
traffic, to verify the performance of delivered services, or to traffic, to verify the performance of delivered services, or to
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 a customer. [QoS reflects the performance perceivable by a user of
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; this includes the estimation of inter- and
intra-network traffic, as well as originating, terminating, and intra-network traffic, as well as originating, terminating, and
transit traffic that are being exchanged between peers transit traffic that are being exchanged between peers.
An example of using traffic measurements in this area might be
monitoring packet loss rates at various points in a network to
detect apparent link failure. Another example is monitoring the QoS
delivered to external peers by an autonomous system to ensure that
peering agreements are met.
5.3 Traffic control 5.3 Traffic control
. adaptively optimizing network performance in response to network
events, e.g., rerouting to work around congestion or failures . Adaptively optimizing network performance in response to network
. providing a feedback mechanism in the reverse flow messaging of events, e.g., rerouting to work around congestion or failures.
. Providing a feedback mechanism in the reverse flow messaging of
RSVP-TE or CR-LDP signaling in MPLS to report on actual topology RSVP-TE or CR-LDP signaling in MPLS to report on actual topology
state information such as link bandwidth availability state information such as link bandwidth availability.
. support of measurement-based admission control, i.e., by . Support of measurement-based admission control, i.e., by
predicting the future demands of the aggregate of existing flows predicting the future demands of the aggregate of existing flows
so that admission decisions can be made on new flows so that admission decisions can be made on new flows.
An example of traffic engineering measurements used to effect a
traffic control mechanism is to configure policing mechanisms in
response to traffic load and performance measurements. A network
operator could selectively throttle low-priority flows to improve
near-real-time performance of higher-priority flows, and maintain
tighter QoS envelopes. Another example would be to use measurement
results for feedback into IGP routing decisions, e.g., for adjusting
the link weights based on them.
6. Time Scales for Network Operations 6. Time Scales for Network Operations
The information collected by traffic measurement can be provided to The information collected by traffic measurement can be provided to
the end user or application either in real time, or for record in the end user or application either in real time, or for record
non-real time, depending on the activities to be performed and the (i.e., data retention) in non-real time, depending on the activities
network actions to be taken. Traffic control will generally require to be performed and the network actions to be taken. Traffic
real-time information. For network planning and capacity management control will generally require real-time information. For network
as described below, information may be provided in non-real time planning and capacity management as described below, information may
after the processing of raw data. be provided in non-real time after the processing of raw data.
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 [14]. operations [14].
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
skipping to change at page 15, line 27 skipping to change at page 16, line 47
provider are responsible for providing sufficient data integrity and provider are responsible for providing sufficient data integrity and
confidentiality. It is also assumed that a service provider will confidentiality. It is also assumed that a service provider will
take proper precautions to ensure that access to its measurement take proper precautions to ensure that access to its measurement
systems and all associated data is secure. Methods to achieve these systems and all associated data is secure. Methods to achieve these
security considerations are not addressed in this document. security considerations are not addressed in this document.
14. References 14. 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," "Overview and Principles of Internet Traffic Engineering,"
Internet-Draft, Work in Progress, August 2001. Internet-Draft, Work in Progress, October 2001.
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
Performance Metrics," RFC 2330, May 1998. Performance Metrics," RFC 2330, May 1998.
3 J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring 3 J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring
Connectivity," RFC 2678, September 1999. Connectivity," RFC 2678, September 1999.
4 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay Metric 4 G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay Metric
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 C. Demichelis and P. Chimento, "IP Packet Delay Variation Metric 8 C. Demichelis and P. Chimento, "IP Packet Delay Variation Metric
for IPPM," Internet-Draft, Work in Progress, February 2001. for IPPM," Internet-Draft, Work in Progress, February 2001.
9 V. Raisanen and G. Grotefeld, "Network performance measurement 9 V. Raisanen and G. Grotefeld, "Network performance measurement
for periodic streams," Internet-Draft, Work in Progress, January for periodic streams," Internet-Draft, Work in Progress, January
2001. 2001.
10 ITU-T Recommendation I.380/Y.1540, "Internet Protocol Data 10 ITU-T Recommendation I.380/Y.1540, "Internet Protocol Data
skipping to change at page 15, line 48 skipping to change at page 17, line 17
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 C. Demichelis and P. Chimento, "IP Packet Delay Variation Metric 8 C. Demichelis and P. Chimento, "IP Packet Delay Variation Metric
for IPPM," Internet-Draft, Work in Progress, February 2001. for IPPM," Internet-Draft, Work in Progress, February 2001.
9 V. Raisanen and G. Grotefeld, "Network performance measurement 9 V. Raisanen and G. Grotefeld, "Network performance measurement
for periodic streams," Internet-Draft, Work in Progress, January for periodic streams," Internet-Draft, Work in Progress, January
2001. 2001.
10 ITU-T Recommendation I.380/Y.1540, "Internet Protocol Data 10 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.
11 ITU-T Draft Recommendation Y.1541, "Internet Protocol 11 ITU-T Draft Recommendation Y.1541, "Network Performance
Communication Service -- IP Performance Objectives," May 2001. Objectives for IP-Based Services," October 2001.
12 E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label 12 E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label
Switching Architecture," RFC 3031, January 2001. Switching Architecture," RFC 3031, January 2001.
13 S. Bradner (Editor), "Benchmarking Terminology for Network 13 S. Bradner (Editor), "Benchmarking Terminology for Network
Interconnection Devices," RFC 1242, July 1991. Interconnection Devices," RFC 1242, July 1991.
14 G. Ash, "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM- 14 G. Ash, "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM-
Based Multiservice Networks," Internet-Draft, Work in Progress, Based Multiservice Networks," Internet-Draft, Work in Progress,
March 2001. October 2001.
15 K. Kompella, Y. Rekhter, and L. Berger, "Link Bundling in MPLS 15 K. Kompella, Y. Rekhter, and L. Berger, "Link Bundling in MPLS
Traffic Engineering," Internet-Draft, Work in Progress, February Traffic Engineering," Internet-Draft, Work in Progress, February
2001. 2001.
16 W.S. Lai, "Traffic Measurement for Dimensioning and Control of IP 16 W.S. Lai, "Traffic Measurement for Dimensioning and Control of IP
Networks," Internet Performance and Control of Network Systems II Networks," Internet Performance and Control of Network Systems II
Conference, SPIE Proceedings Vol. 4523, Denver, Colorado, 21-22 Conference, SPIE Proceedings, Vol. 4523, Denver, Colorado, 21-22
August 2001. August 2001, pp. 359-367.
17 C. Srinivasan, A. Viswanathan, and T.D. Nadeau, "MPLS Label 17 C. Srinivasan, A. Viswanathan, and T.D. Nadeau, "MPLS Label
Switch Router Management Information Base Using SMIv2," Internet- Switch Router Management Information Base Using SMIv2," Internet-
Draft, Work in Progress, January 2001. Draft, Work in Progress, January 2001.
18 C. Srinivasan, A. Viswanathan, and T.D. Nadeau, "MPLS Traffic 18 C. Srinivasan, A. Viswanathan, and T.D. Nadeau, "Multiprotocol
Engineering Management Information Base Using SMIv2," Internet- Label Switching (MPLS) Traffic Engineering Management Information
Draft, Work in Progress, March 2001. Base," Internet-Draft, Work in Progress, August 2001.
19 K. Kompella, " A Traffic Engineering MIB," Internet-Draft, Work 19 K. Kompella, " A Traffic Engineering MIB," Internet-Draft, Work
in Progress, September 2000. in Progress, October 2001.
20 A. Feldmann, A. Greenberg, C. Lund, N. Reingold, J. Rexford, and 20 A. Feldmann, A. Greenberg, C. Lund, N. Reingold, J. Rexford, and
F. True, "Deriving Traffic Demands for Operational IP Networks: F. True, "Deriving Traffic Demands for Operational IP Networks:
Methodology and Experience," Proc. ACM SIGCOMM 2000, Stockholm, Methodology and Experience," Proc. ACM SIGCOMM 2000, Stockholm,
Swedan. Swedan.
21 A. Feldmann, A. Greenberg, C. Lund, N. Reingold, and J. Rexford, 21 A. Feldmann, A. Greenberg, C. Lund, N. Reingold, and J. Rexford,
"NetScope: Traffic Engineering for IP Networks," IEEE Network, "NetScope: Traffic Engineering for IP Networks," IEEE Network,
March/April 2000. March/April 2000.
22 N. Harrison, P. Willis, S. Davari, E. Cuevas, B. Mack-Crane, E. 22 N. Harrison, P. Willis, S. Davari, E. Cuevas, B. Mack-Crane, E.
Franze, H. Ohta, T. So, S. Goldfless, and F. Chen, "Requirements Franze, H. Ohta, T. So, S. Goldfless, and F. Chen, "Requirements
for OAM in MPLS Networks," Internet-Draft, Work in Progress, May for OAM in MPLS Networks," Internet-Draft, Work in Progress, May
skipping to change at page 17, line 18 skipping to change at page 18, line 37
Blaine Christian Blaine Christian
UUNET UUNET
Room D1-2-737 Room D1-2-737
22001 Loudoun County Parkway 22001 Loudoun County Parkway
Ashburn, VA 20147, USA Ashburn, VA 20147, USA
Phone: +1 703-206-5600 Phone: +1 703-206-5600
Email: Blaine@uu.net Email: Blaine@uu.net
Richard W. Tibbs Richard W. Tibbs
OPNET Technologies Oak City Networks & Solutions
200 Regency Forest Dr. P.O. Box 10292
Suite 150 Raleigh, NC 27605, USA
Cary, NC 27511, USA Phone: +1 919-510-9551
Phone: +1 919-461-2445 x227 Email: drtibbs@oakcitysolutions.com
Email: rtibbs@opnet.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/