draft-ietf-tewg-measure-02.txt   draft-ietf-tewg-measure-03.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-02.txt> Document: <draft-ietf-tewg-measure-03.txt>
Category: Informational Blaine Christian Category: Informational Blaine Christian
UUNET UUNET
Richard W. Tibbs 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
March 2002 September 2002
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 6 skipping to change at page 2, line 6
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.
For interoperable compatibility, uniform definitions across vendors For interoperable compatibility, uniform definitions across vendors
and operators must be ensured, e.g., in the distinction between and operators must be ensured, e.g., in the distinction between
offered load and achieved throughput. To aid network dimensioning, offered load and achieved throughput. To aid network dimensioning,
mechanisms to collect node-pair-based traffic data should be mechanisms to collect node-pair-based traffic data should be
developed to facilitate the derivation of per-service-class traffic developed to facilitate the derivation of per-service-class traffic
matrix statistics. For service assurance, there is a need for the matrix statistics. For service assurance, there is a need for the
use of higher-order statistics. To preserve representative traffic use of higher-order statistics. To preserve representative traffic
detail at manageable sample volumes, there is a need for packet detail at manageable sample volumes, there is a need for packet-
sampled measurements. sampled measurements. To manage large volume of measured data, use
of bulk transfer and filtering/aggregation mechanisms may be
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....................................................2 3. Introduction....................................................3
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.............................................5 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..............................6
7. Read-Out Periods................................................7 7. Read-Out Periods................................................7
8. Measurement Bases...............................................8 8. Measurement Bases...............................................8
8.1 Flow-based.....................................................9 8.1 Flow-based.....................................................9
8.2 Interface-based, link-based, node-based........................9 8.2 Interface-based, link-based, node-based........................9
8.3 Node-pair-based...............................................10 8.3 Node-pair-based...............................................10
8.4 Path-based....................................................10 8.4 Path-based....................................................10
9. Measurement Entities...........................................10 9. Measurement Entities...........................................11
9.1 Entities related to traffic and performance...................11 9.1 Entities related to traffic and performance...................11
9.2 Entities related to establishment of connection or path.......13 9.2 Entities related to establishment of connection or path.......13
10. Measurement Types.............................................13 10. Measurement Types.............................................13
10.1 Measurement types related to traffic or performance..........13 10.1 Measurement types related to traffic or performance..........14
10.2 Measurement types related to resource usage..................14 10.2 Measurement types related to resource usage..................14
11. Traffic Matrix Statistics.....................................15 11. Traffic Matrix Statistics.....................................15
12. Performance Monitoring........................................16 12. Performance Monitoring........................................16
13. Packet Sampling...............................................16 13. Packet Sampling...............................................17
14. Statistical Estimation and Information Modeling...............17 14. Statistical Estimation and Information Modeling...............18
14.1 Engineering methods for statistical estimation of measures...17 14.1 Engineering methods for statistical estimation of measures...18
14.2 TE Measure Information Modeling..............................18 14.2 TE Measure Information Modeling..............................18
15. Conclusions and Recommendations...............................20 15. Conclusions and Recommendations...............................20
16. Security Considerations.......................................20 16. Security Considerations.......................................21
17. References....................................................20 17. References....................................................21
18. Acknowledgments...............................................22 18. Intellectual Property Statement...............................23
19. Author's Addresses............................................22 19. Acknowledgments...............................................24
Full Copyright Statement..........................................23 20. Author's Addresses............................................24
Full Copyright Statement..........................................24
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., 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
skipping to change at page 4, line 20 skipping to change at page 4, line 22
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
duplication of effort, relevant work done in measurements by other duplication of effort, relevant work done in measurements by other
standards organizations will be applied or adapted, and references standards organizations will be applied or adapted, and references
to them will be made. These include, in particular, 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, 10]
. ITU-T: Recommendation I.380/Y.1540 [10] and Draft Recommendation . ITU-T: Recommendation I.380/Y.1540 [11] and Recommendation Y.1541
Y.1541 [11] [12]
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
A route is any unidirectional sequence of nodes and links, for A route is any unidirectional sequence of nodes and links, for
sending packets from a source node to a destination node. A path sending packets from a source node to a destination node. A path
refers to an MPLS tunnel, i.e., a label-switched path [12]. refers to an MPLS tunnel, i.e., a label-switched path [13].
It should be pointed out that there are also methods for creating It should be pointed out that there are also methods for creating
paths with other technologies such as frame relay or ATM. The paths with other technologies such as frame relay or ATM. The
measurement described in this document may apply to these measurement described in this document may apply to these
technologies with suitable adaptation. To simplify description, technologies with suitable adaptation. To simplify description,
reference is made to MPLS only in what follows. reference is made to MPLS only in what follows.
4.2 Throughput, traffic volume 4.2 Throughput, traffic volume
Both quantities can be applied to a network, a network segment, or Both quantities can be applied to a network, a network segment, or
an individual network element. an individual network element.
Throughput of a network, as a measure of delivered performance, Throughput of a network, as a measure of delivered performance,
refers to the maximum sustainable rate of transferring packets refers to the maximum sustainable rate of transferring packets
successfully across the network, under given network conditions, successfully across the network, under given network conditions,
e.g., a given traffic mix, while meeting quality of service (QoS) e.g., a given traffic mix, while meeting quality of service (QoS)
objectives. This usage is consistent with the definition of objectives. This usage is consistent with the definition of
throughput for a network interconnect device as specified in [13]. throughput for a network interconnect device as specified in [14].
For real-time network control, active measurement of throughput by For real-time network control, active measurement of throughput by
probing may be used to determine the currently available capacity of probing may be used to determine the currently available capacity of
a network to carry additional traffic. (In an active measurement, a network to carry additional traffic. (In an active measurement,
test packets are injected into the network. Data collected about test packets are injected into the network. Data collected about
these packets are taken as representative of the behavior of the these packets are taken as representative of the behavior of the
network.) network.)
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
skipping to change at page 5, line 48 skipping to change at page 5, line 51
. 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 For example, traffic engineering measurements are usually used to
determine the statistical moments of a traffic flow. As suggested determine the statistical moments of a traffic flow. As suggested
in [14], given the time series of packet arrivals, a suitable in [15], given the time series of packet arrivals, a suitable
parametric stochastic model based on the mean and variance of the parametric stochastic model based on the mean and variance of the
time series can be constructed. This traffic model is then used in time series can be constructed. This traffic model is then used in
the ensuing phases of traffic engineering, such as link dimensioning the ensuing phases of traffic engineering, such as link dimensioning
to meet service objectives. 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 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
skipping to change at page 7, line 9 skipping to change at page 7, line 10
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 the end user or application either in real time, or for record
(i.e., data retention) in non-real time, depending on the activities (i.e., data retention) in non-real time, depending on the activities
to be performed and the network actions to be taken. Traffic to be performed and the network actions to be taken. Traffic
control will generally require real-time information. For network control will generally require real-time information. For network
planning and capacity management as described below, information may planning and capacity management as described below, information may
be provided in non-real time 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 [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. Forecasting and planning may also lead to the
introduction of new technology and architecture. introduction of new technology and architecture.
skipping to change at page 7, line 45 skipping to change at page 7, line 46
7. Read-Out Periods 7. Read-Out Periods
A measurement infrastructure must be able to scale with the size and A measurement infrastructure must be able to scale with the size and
the speed of a network as it evolves. Hence, it is important to the speed of a network as it evolves. Hence, it is important to
minimize the amount of data to be collected, and to condense the minimize the amount of data to be collected, and to condense the
collected data by periodic summarization. This is to prevent collected data by periodic summarization. This is to prevent
network performance from being adversely affected by the network performance from being adversely affected by the
unnecessarily excessive loading of router control processors, router unnecessarily excessive loading of router control processors, router
memories, transmission facilities, and the administrative support memories, transmission facilities, and the administrative support
systems. systems. For example, offline bulk file transfer may be used as a
method to manage large volumes of measured traffic data. Bulk
transfer from routers to collection devices can help reduce the
packet processing overhead experienced by using other management
interfaces. Also, data correlation or filtering rules may be set up
to suppress redundant data, or to aggregate flows into suitable
classes with the corresponding aggregation of statistics. These
types of data reduction may be used as an appropriate or acceptable
means for pruning down the overall volume of traffic data that a TE
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. This requires the definition of a
busy period. Special studies on selected segments of the network busy period. Special studies on selected segments of the network
skipping to change at page 9, line 43 skipping to change at page 9, line 54
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 Passive measurement 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. While and octets sent/received, packet discards, errored packets.
not intended for core network, RMON (Remote Network Monitoring) can
possibly be used in the access link of an Internet service provider
to provide managed Internet service to corporate LANs.
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 [15]. 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 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 should consider the measurements for bundled links. 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,
skipping to change at page 11, line 20 skipping to change at page 11, line 28
parameters. parameters.
. Traffic volume (mean and variance, in number of bits, bytes, or . Traffic volume (mean and variance, in number of bits, bytes, or
packets transferred, as counted over a given time interval), on a packets transferred, as counted over a given time interval), on a
per service class basis, at various aggregation levels (IP address per service class basis, at various aggregation levels (IP address
prefix, interface, link, node, node-pair, path, network edge, prefix, interface, link, node, node-pair, path, network edge,
customer, or autonomous system) customer, or autonomous system)
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
[16]. 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. (3) Measurement of traffic volumes over
interconnecting links at border routers can be used to estimate interconnecting links at border routers can be used to estimate
the traffic exchange between peers for contract verification. the traffic exchange between peers for contract verification.
skipping to change at page 14, line 25 skipping to change at page 14, line 33
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)
Packet Loss x x(5) x(5) Packet Loss x x(5) x(5)
Notes: Notes:
(1) This measurement type can be used to derive flow size (1) This measurement type can be used to derive flow size
statistics. statistics.
(2) These are 1-point measurements. (2) These are 1-point measurements.
(3) As a starting point, statistics collected by passive measurement (3) As a starting point, statistics collected by passive measurement
through the MPLS traffic engineering MIBs [17, 18, 19] may be used. through the MIBs useful for traffic engineering [18, 19, 20] may be
used.
(4) Active measurements based on IPPM metrics are currently in use (4) Active measurements based on IPPM metrics are currently in use
for node-pairs; they may be developed for paths. for node-pairs; they may be developed for paths.
(5) Besides active measurements based on IPPM, path loss may (5) Besides active measurements based on IPPM, path loss may
possibly be inferred from the difference between ingress and egress possibly be inferred from the difference between ingress and egress
traffic statistics at the two endpoints of a path. However, such traffic statistics at the two endpoints of a path. However, such
inference for the cumulative losses between a given node pair over inference for the cumulative losses between a given node pair over
multiple routes may be less useful, since different routes may have multiple routes may be less useful, since different routes may have
different loss characteristics. different loss characteristics.
10.2 Measurement types related to resource usage 10.2 Measurement types related to resource usage
skipping to change at page 15, line 29 skipping to change at page 15, line 39
or point-to-multipoint demands. This data is needed in the or point-to-multipoint demands. This data is needed in the
provisioning of intradomain routes and external peering in the provisioning of intradomain routes and external peering in the
existing network, as well as planning for the placement and sizing existing network, as well as planning for the placement and sizing
of new links, routers, or peers. of new links, routers, or peers.
In current practice, estimates for traffic demands are usually In current practice, estimates for traffic demands are usually
determined from a combination of traffic projections, customer determined from a combination of traffic projections, customer
prescriptions, and service level agreements. Under existing mode of prescriptions, and service level agreements. Under existing mode of
operation, it is not easy to obtain network-wide traffic demands operation, it is not easy to obtain network-wide traffic demands
from the local interface measurements taken by different IP routers. from the local interface measurements taken by different IP routers.
As explained in [20, 21], information from diverse network As explained in [21, 22], information from diverse network
measurements and various configuration files are needed to infer the measurements and various configuration files are needed to infer the
traffic volume. Besides raw measurement data, additional traffic volume. Besides raw measurement data, additional
information such as topological data and router configuration data information such as topological data and router configuration data
are required to obtain a network view. Furthermore, destination- are required to obtain a network view. Furthermore, destination-
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
skipping to change at page 15, line 55 skipping to change at page 16, line 13
statistics as above include the volume of data from flow-based statistics as above include the volume of data from flow-based
measurement, the lack of sufficient routing control information, and measurement, the lack of sufficient routing control information, and
the need to correlate data from a variety of sources. The routing the need to correlate data from a variety of sources. The routing
control offered by MPLS can be used to avoid some of these control offered by MPLS can be used to avoid some of these
deficiencies. To take advantage of this capability, path-based deficiencies. To take advantage of this capability, path-based
passive measurement should be developed. Furthermore, as explained passive measurement should be developed. Furthermore, as explained
in the Section on Path-based Measurement Bases, by aggregating the in the Section on Path-based Measurement Bases, by aggregating the
appropriate set of path-based traffic data, the corresponding node- appropriate set of path-based traffic data, the corresponding node-
pair-based traffic data can be obtained. This will facilitate the pair-based traffic data can be obtained. This will facilitate the
derivation of traffic matrix statistics, possibly on a per service derivation of traffic matrix statistics, possibly on a per service
class basis. class basis. Note that in the case of hop-by-hop routed label-
switched paths that are established by Label Distribution Protocol
(LDP) signaling, there is no explicit binding between path end
points. This will result in the use of different label bindings at
both the ingress and egress nodes over time as network topology
changes. Although the forwarding equivalence class (FEC) to label
binding information already exists in the MPLS FTN and LSR MIBs [23,
18], a mechanism is needed to keep track of binding changes. An
example of such a mechanism may be the periodic 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. Path-based be an enterprise network or a carrier's carrier network. It is not
measurement by a network operator on behalf of the VPN customers the purpose of this document to discuss VPNs. However, it is
facilitates the estimation of the traffic offered by these VPNs. relevant to highlight the use of traffic measurements to maintain
proper engineering and performance of MPLS tunnels in the support of
VPNs between VPN sites. This would include also the support for
MPLS-based pseudo-wire connections as developed by the PWE3 Working
Group [24]. For example, path-based measurement by a network
operator on behalf of the VPN customers facilitates the estimation
of the traffic offered by these VPNs.
12. Performance Monitoring 12. Performance Monitoring
General aspects of measurements required to support the operation, General aspects of measurements required to support the operation,
administration, and maintenance of a network are outside the scope administration, and maintenance of a network are outside the scope
of this document (see [22, 23, 24] for a discussion of MPLS OAM). of this document (see [25, 26, 27] for a discussion of MPLS OAM).
The focus of the measurements here is only on operations related to The focus of the measurements here is only on operations related to
traffic engineering and network performance management. traffic engineering and network performance management.
A major component of performance management is performance A major component of performance management is performance
monitoring, i.e., continuous real-time monitoring of the quality or monitoring, i.e., continuous real-time monitoring of the quality or
health of the network and its various elements to ensure a health of the network and its various elements to ensure a
sustained, uninterrupted delivery of quality service. This requires sustained, uninterrupted delivery of quality service. This requires
the use of measurement, either passively or actively, to collect the use of measurement, either passively or actively, to collect
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 [25]. 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. After the identification of a
hot spot, active throughput measurement may be used to seek out hot spot, active throughput measurement may be used to seek out
alternate routes for congestion bypass. Unexpected excessive loss alternate routes for congestion bypass. Unexpected excessive loss
of packets or throughput drops may be used as a means of fault 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 [26]. route tracing is described in [29].
13. Packet Sampling 13. Packet Sampling
A wide spectrum of operational applications can be built on traffic A wide spectrum of operational applications can be built on traffic
measurement. However, different applications usually require measurement. However, different applications usually require
traffic measurements at different levels of temporal and spatial traffic measurements at different levels of temporal and spatial
granularity. To achieve an effective tradeoff between granularity. To achieve an effective tradeoff between
implementation complexity and the range of operational tasks to be implementation complexity and the range of operational tasks to be
enabled, a passive measurement framework based on packet sampling is enabled, a passive measurement framework based on packet sampling is
proposed in [27]. proposed in [30].
The use of packet sampling has two motivations. First, the enormous The use of packet sampling has two motivations. First, the enormous
volumes of traffic require that some form of data reduction to be volumes of traffic require that some form of data reduction to be
used. Second, simple data reduction by aggregation at the used. Second, simple data reduction by aggregation at the
measurement point will not provide sufficiently detailed views for measurement point will not provide sufficiently detailed views for
all network management applications or exploratory studies. For all network management applications or exploratory studies. For
this reason, packet sampling is proposed as a means to reduce data this reason, packet sampling is proposed as a means to reduce data
volume while still retaining representative detail. volume while still retaining representative detail.
The primary aim of the proposal [27] is to define a minimal set of The primary aim of the proposal [30] is to define a minimal set of
primitive packet selection operations out of which all sampling primitive packet selection operations out of which all sampling
operations that are necessary to support measurement-based operations that are necessary to support measurement-based
applications can be composed. Operations currently under applications can be composed. Operations currently under
consideration include filtering and statistical sampling, and also consideration include filtering and statistical sampling, and also
hash-based packet selection, a method that can be used to support hash-based packet selection, a method that can be used to support
the determination of spatial traffic flows across a domain. the determination of spatial traffic flows across a domain [31].
Whichever method is used, the interpretation of the stream of Whichever method is used, the interpretation of the stream of
measurements arising from sampled packets must be both transparent measurements arising from sampled packets must be both transparent
and standard. Other goals are to specify a means to format and and standard. Other goals are to specify a means to format and
export measurements, and a means to manage the configuration of the export measurements, and a means to manage the configuration of the
sampling and export operations. sampling and export operations.
The proposal positions these function to provide a basic packet The proposal positions these function to provide a basic packet
sampled measurement service to higher level "consumers." A typical sampled measurement service to higher level "consumers." A typical
consumer is a network management application that sits behind a consumer is a network management application that sits behind a
remote measurement collector. Such measurements can support remote measurement collector. Such measurements can support
applications for a number of tasks: troubleshooting, demand applications for a number of tasks: troubleshooting, demand
characterization, scenario evaluation and what-ifs. Another type of characterization, scenario evaluation and what-ifs. Another type of
consumer is a higher level on-router measurement application. consumer is a higher level on-router measurement application.
One potential class of examples is composite measurements (e.g., One potential class of examples is composite measurements (e.g.,
interpacket delay statistics) formed from a number of individual interpacket delay statistics) formed from a number of individual
packet measurements. Another class is network security packet measurements. Another class is network security
applications, e.g., IP traceback [28]. For some applications, the applications, e.g., IP traceback [32]. For some applications, the
ability to have low latency between packet measurement and reporting ability to have low latency between packet measurement and reporting
will be particularly useful. will be particularly useful.
14. Statistical Estimation and Information Modeling 14. Statistical Estimation and Information Modeling
This section deals with engineering methods in statistical This section deals with engineering methods in statistical
estimation, as well as the need for an information model and estimation, as well as the need for an information model and
associated repository schema for the measurements. associated repository schema for the measurements.
14.1 Engineering methods for statistical estimation of measures 14.1 Engineering methods for statistical estimation of measures
The use of the well-established methods of optimal estimation [29, The use of the well-established methods of optimal estimation [33,
30, 31, 32] to obtain estimates of the measures for TE is 34, 35, 36] to obtain estimates of the measures for TE is
recommended. This draws upon several facts: recommended. This draws upon several facts:
. Internet traffic is inherently band-limited, but non-stationary; . Internet traffic is inherently band-limited, but non-stationary;
. Internet traffic may be heavy-tailed and possess strong short-term . Internet traffic may be heavy-tailed and possess strong short-term
correlations; correlations;
. A stationary, band-limited process can be approximated arbitrarily . A stationary, band-limited process can be approximated arbitrarily
closely by optimal estimation methods based on a finite number of closely by optimal estimation methods based on a finite number of
past samples. past samples.
Standard procedures for de-trending the raw data to provide "trend + Standard procedures for de-trending the raw data to provide "trend +
stationary" decompositions should be adopted. An example is the use stationary" decompositions should be adopted. An example is the use
of Autoregressive Integrated Moving Average (ARIMA) models, where of Autoregressive Integrated Moving Average (ARIMA) models, where
first differences are applied to the raw (non-stationary) data, first differences are applied to the raw (non-stationary) data,
yielding a stationary derived process. Then, the methods of optimal yielding a stationary derived process. Then, the methods of optimal
estimation can be applied in a practical setting (e.g., finite estimation can be applied in a practical setting (e.g., finite sample
sample counts) to the derived stationary process to produce quality counts) to the derived stationary process to produce quality
estimates of the measures defined herein. As the original raw estimates of the measures defined herein. As the original raw
process may be any of the measurements discussed in this document, process may be any of the measurements discussed in this document,
the above procedure may be applied without loss of generality to the above procedure may be applied without loss of generality to
measures of delay, loss, or complex measures of network state such measures of delay, loss, or complex measures of network state such as
as path characteristics, etc. path characteristics, etc.
In addition, these methods need to be applied across multiple time- In addition, these methods need to be applied across multiple time-
scales, so that TE applications can work with measures related to: scales, so that TE applications can work with measures related to:
. long-term trends over days, weeks, and months; . long-term trends over days, weeks, and months;
. busy-hour characterizations; and . busy-hour characterizations; and
. statistics and correlation properties on the order of seconds . statistics and correlation properties on the order of seconds [37].
[33].
The above estimation procedures apply equally to traffic workload, The above estimation procedures apply equally to traffic workload,
traffic performance, or other estimates of network state, such as traffic performance, or other estimates of network state, such as the
the state of routes. state of routes.
14.2 TE Measure Information Modeling 14.2 TE Measure Information Modeling
An information model is valuable for organizing data generated An information model is valuable for organizing data generated
through the estimation process. An information model is needed for through the estimation process. An information model is needed for
TE measures because a complete model does not exist for these TE measures because a complete model does not exist for these
measures. Measures must be associated with a large, and sometimes measures. Measures must be associated with a large, and sometimes
complicated set of attributes (e.g., as simple as an IP address of a complicated set of attributes (e.g., as simple as an IP address of a
measurement point, or as complex as the path of a round-trip measurement point, or as complex as the path of a round-trip
measurement). measurement).
Information models exist that richly describe network elements and Information models exist that richly describe network elements and
their configuration [34]. These models have been extended to their configuration [38]. These models have been extended to include
include policy mechanisms [35]. Specifications for flows have been policy mechanisms [39]. Specifications for flows have been developed
developed for network resource allocation purposes [36]. No for network resource allocation purposes [40]. No centralized
centralized information model exists that can completely describe information model exists that can completely describe many of the TE
many of the TE measures defined herein. Therefore, necessary measures defined herein. Therefore, necessary integrating
integrating information models that make maximal reuse of pre- information models that make maximal reuse of pre-existing work may
existing work may need to be developed for TE measures. need to be developed for TE measures.
As a brief example of the limitations of existing information As a brief example of the limitations of existing information models,
models, consider RFC 1363 [36] as a model for a traffic flow. It consider RFC 1363 [40] as a model for a traffic flow. It can be
can be described as collection of attributes defining traffic described as collection of attributes defining traffic offered load,
offered load, performance to be delivered (a goal), and the performance to be delivered (a goal), and the assurance level (risk)
assurance level (risk) associated with the actual performance associated with the actual performance obtained. The traffic offered
obtained. The traffic offered load is specified via an envelope load is specified via an envelope described by a token bucket concept
described by a token bucket concept (token bucket rate, bucket size) (token bucket rate, bucket size) and a maximum transmission rate.
and a maximum transmission rate.
This model, while clearly intended for description of what a network This model, while clearly intended for description of what a network
will tolerate of a flow, could also be used to describe a flow in a will tolerate of a flow, could also be used to describe a flow in a
TE measure sense, e.g., "a flow that lives within the token rate x TE measure sense, e.g., "a flow that lives within the token rate x
and size y with probability 0.999." Note that a probability and size y with probability 0.999." Note that a probability
statement must be added to complete the characterization. This type statement must be added to complete the characterization. This type
of specification is known as (sigma, rho) in the literature. Also, of specification is known as (sigma, rho) in the literature. Also,
note that adopting such an information model for flows lacks any note that adopting such an information model for flows lacks any
flexibility to specify time scale, or more detailed second-order flexibility to specify time scale, or more detailed second-order
statistics. statistics.
Similar limitations exist with respect to delivered performance Similar limitations exist with respect to delivered performance
specification in RFC1363, and the text of the RFC is quick to point specification in RFC1363, and the text of the RFC is quick to point
out, for example, that the "loss model is crude." For these out, for example, that the "loss model is crude." For these reasons,
reasons, and others, an appropriate information model is needed for and others, an appropriate information model is needed for TE
TE measures that can support uniformity of data definition in measures that can support uniformity of data definition in subsequent
subsequent TE applications. TE applications.
Several approaches and options for repository technology are now Several approaches and options for repository technology are now
broadly discussed. Relationships between TE measure information broadly discussed. Relationships between TE measure information
models on other information models (e.g., COPS) that drive network models on other information models (e.g., COPS) that drive network
outcomes are of particular importance. outcomes are of particular importance.
Linkages may need to be considered between policy mechanisms and TE Linkages may need to be considered between policy mechanisms and TE
measures. This is useful because, while policy-driven networking is measures. This is useful because, while policy-driven networking is
well-developed between the policy repositories, policy control well-developed between the policy repositories, policy control points
points and policy enforcement, policy content is very likely the and policy enforcement, policy content is very likely the output of
output of TE applications. Since TE applications are dependent upon TE applications. Since TE applications are dependent upon TE
TE measures, it is advantageous to provide traceability between the measures, it is advantageous to provide traceability between the
measures and the engineering changes made as a consequence of them. measures and the engineering changes made as a consequence of them.
Measures (represented by their estimates) should be centrally stored Measures (represented by their estimates) should be centrally stored
and collected. Two methods are: (1) extend MIBs with new and collected in a logical sense. This does not preclude distributed
definitions for TE measure estimates, and (2) create data storage for purposes of volume management or security/survivability,
depositories through more centralized facilities, such as LDAP but alludes to the need for a consistent retrieval mechanism (e.g.,
repositories. Both methods have merits as collection processes for NFS). Two methods are: (1) extend MIBs with new definitions for TE
TE measures. measure estimates, and (2) create data depositories through more
centralized facilities, such as LDAP repositories. Both methods have
merits as collection processes for TE measures, and are simple
examples spanning a wide spectrum of solutions. These two methods
are discussed here for expository purposes, not to exclude other
solutions.
Using MIBs allows well-established SNMP protocol and related Using MIBs allows well-established SNMP protocol and related
applications to retrieve data from the network elements being applications to retrieve data from the network elements being
measured. This is inherently "vendor-neutral," allowing commonly measured. This is inherently "vendor-neutral," allowing commonly
defined TE measurements to be stored for retrieval in a common MIB defined TE measurements to be stored for retrieval in a common MIB
definition, regardless of network element vendor, technology or definition, regardless of network element vendor, technology or other
other differences. Measurements from individual network elements differences. Measurements from individual network elements
(interfaces, routers, etc.) can be obtained "locally," if measures (interfaces, routers, etc.) can be obtained "locally," if measures
from a single network element are sufficient for a given TE from a single network element are sufficient for a given TE
application. However, if a network-wide view of the measurements is application. However, if a network-wide view of the measurements is
desired, the drawback of a MIB-based approach is that the data must desired, the drawback of a MIB-based approach is that the data must
be retrieved from each element over the network. As experience be retrieved from each element over the network. As experience
attests, this approach sometimes generates significant SNMP traffic, attests, this approach sometimes generates significant SNMP traffic,
and during periods of high congestion (when measurements may be and during periods of high congestion (when measurements may be quite
quite important) SNMP may not reliably fetch the measurement data. important) SNMP may not reliably fetch the measurement data. Finally,
Finally, a MIB-based approach may be difficult to implement for a MIB-based approach may be difficult to implement for various two-
various two-point measurements, such as end-to-end, or round-trip point measurements, such as end-to-end, or round-trip delay and delay
delay and delay variation. Such measurements are not related to a variation. Such measurements are not related to a single network
single network element, and somewhat heuristic practices (e.g., element, and somewhat heuristic practices (e.g., storing end-to-end
storing end-to-end delay measurements in MIBs located on source delay measurements in MIBs located on source address elements, etc.)
address elements, etc.) are required. are required.
An LDAP repository approach centralizes the data storage. This has An LDAP repository approach centralizes the data storage. This has
the advantage that TE applications (such as offline and online TE, the advantage that TE applications (such as offline and online TE, or
or measurement-based admission control) can be performed, and policy measurement-based admission control) can be performed, and policy
database content can be updated without invasive retrieval of data database content can be updated without invasive retrieval of data
from network-wide MIBs. Further, traceability can be established from network-wide MIBs. Further, traceability can be established
between the TE measurements in an LDAP repository, and the between the TE measurements in an LDAP repository, and the associated
associated policy content derived from them. policy content derived from them.
It is possible that both the MIB-based and LDAP-based (or another It is possible that both the MIB-based and LDAP-based (or another
approach altogether) should be considered jointly. approach altogether) should be considered jointly.
15. Conclusions and Recommendations 15. Conclusions and Recommendations
This document is intended as a framework for traffic metrics needed This document is intended as a framework for traffic metrics needed
for successful TE. Principles of best practice in traffic for successful TE. Principles of best practice in traffic
characterization and performance characterization are described. characterization and performance characterization are described.
For interoperable compatibility, basic areas of traffic measurement For interoperable compatibility, basic areas of traffic measurement
recommended for standardization include: recommended for standardization include:
. Need for uniform definitions across vendors and operators
. Distinction between traffic offered load versus achieved (1) specific TE measurements
throughput
. 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
changes for LDP-signaled label-switched paths, to facilitate the
collection of node-pair-based traffic data
(2) traffic data collection methods
. Need for uniform definitions across vendors and operators
. Distinction between traffic offered load versus achieved
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
filtering/aggregation mechanisms to manage large volumes of
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 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.
17. References 17. References
Normative References
References 1, 2, and 13 below are considered normative.
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," "Overview and Principles of Internet Traffic Engineering," RFC
Internet-Draft, Work in Progress, October 2001. 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
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 R. Koodli and R. Ravikanth, "One-way Loss Pattern Sample
for IPPM," Internet-Draft, Work in Progress, February 2001. Metrics," RFC 3357, August 2002.
9 V. Raisanen, G. Grotefeld, and A. Morton, "Network performance 9 C. Demichelis and P. Chimento, "IP Packet Delay Variation Metric
for IPPM," Internet-Draft, Work in Progress, August 2002.
10 V. Raisanen, G. Grotefeld, and A. Morton, "Network performance
measurement for periodic streams," Internet-Draft, Work in measurement for periodic streams," Internet-Draft, Work in
Progress, February 2002. Progress, August 2002.
10 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.
11 ITU-T Draft Recommendation Y.1541, "Network Performance 12 ITU-T Recommendation Y.1541, "Network Performance Objectives for
Objectives for IP-Based Services," October 2001. IP-Based Services," May 2002.
12 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.
13 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.
14 G. Ash, "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM- 15 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,
October 2001. October 2001.
15 K. Kompella, Y. Rekhter, and L. Berger, "Link Bundling in MPLS 16 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 17 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, pp. 359-367. August 2001, pp. 359-367.
17 C. Srinivasan, A. Viswanathan, and T.D. Nadeau, "MPLS Label
Switch Router Management Information Base Using SMIv2," Internet-
Draft, Work in Progress, January 2001.
18 C. Srinivasan, A. Viswanathan, and T.D. Nadeau, "Multiprotocol 18 C. Srinivasan, A. Viswanathan, and T.D. Nadeau, "Multiprotocol
Label Switching (MPLS) Label Switch Router (LSR) Management
Information Base," Internet-Draft, Work in Progress, January
2002.
19 C. Srinivasan, A. Viswanathan, and T.D. Nadeau, "Multiprotocol
Label Switching (MPLS) Traffic Engineering Management Information Label Switching (MPLS) Traffic Engineering Management Information
Base," Internet-Draft, Work in Progress, August 2001. Base," Internet-Draft, Work in Progress, January 2002.
19 K. Kompella, " A Traffic Engineering MIB," Internet-Draft, Work 20 K. Kompella, "A Traffic Engineering MIB," Internet-Draft, Work in
in Progress, October 2001. Progress, September 2002.
20 A. Feldmann, A. Greenberg, C. Lund, N. Reingold, J. Rexford, and 21 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.
22 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.
23 T.D. Nadeau, C. Srinivasan, and A. Viswanathan, "Multiprotocol
Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information
Base," Internet-Draft, Work in Progress, January 2002.
24 P. Pate, X. Xiao, T. So, A. Malis, T. Nadeau, S. Bryant, C.
White, K. Kompella, and T. Johnson, "Framework for Pseudo Wire
Emulation Edge-to-Edge (PWE3)," Internet-Draft, Work in Progress,
June 2002.
25 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
2001. 2001.
23 ITU-T Draft Recommendation Y.1710, "Requirements for OAM 26 ITU-T Draft Recommendation Y.1710, "Requirements for OAM
Functionality for MPLS Networks," May 2001. Functionality for MPLS Networks," May 2001.
24 ITU-T Draft Recommendation Y.1711, "OAM Mechanisms for MPLS 27 ITU-T Draft Recommendation Y.1711, "OAM Mechanisms for MPLS
Networks," May 2001. Networks," May 2001.
25 R.G. Cole, R. Dietz, C. Kalbfleisch, and D. Romascanu, "A 28 R.G. Cole, R. Dietz, C. Kalbfleisch, and D. Romascanu, "A
Framework for Synthetic Sources for Performance Monitoring," Framework for Synthetic Sources for Performance Monitoring,"
Internet-Draft, Work in Progress, May 2001. Internet-Draft, Work in Progress, May 2001.
26 R. Bonica, K. Kompella, and D. Meyer, "Tracing Requirements for 29 R. Bonica, K. Kompella, and D. Meyer, "Tracing Requirements for
Generic Tunnels," Internet-Draft, Work in Progress, February Generic Tunnels," Internet-Draft, Work in Progress, August 2002.
2001. 30 N.G. Duffield (Editor), "A Framework for Passive Packet
27 R. Bush, N.G. Duffield, A. Greenberg, M. Grossglauser, J. Measurement," Internet-Draft, Work in Progress, September 2002.
Rexford, "A Framework for Passive Packet Measurement," Internet- 31 N.G. Duffield and M. Grossglauser, "Trajectory Sampling for
Draft, Work in Progress, November 2001. Direct Traffic Observation," IEEE/ACM Trans. on Networking, 9(3),
28 C. Partridge, C. Jones, D. Waitzman, and A. Snoeren, "New pp. 280-292, June 2001.
32 C. Partridge, C. Jones, D. Waitzman, and A. Snoeren, "New
Protocols to Support Internet Traceback," Internet-Draft, Work in Protocols to Support Internet Traceback," Internet-Draft, Work in
Progress, November 2001. Progress, November 2001.
29 S. Haykin, Ed., "Kalman Filtering and Neural Networks," Wiley 33 S. Haykin, Ed., "Kalman Filtering and Neural Networks," Wiley
Interscience, 2001. Interscience, 2001.
30 A. Papoulis, "Probability, Random Variables and Stochastic 34 A. Papoulis, "Probability, Random Variables and Stochastic
Processes," 3rd Ed., McGraw-Hill, 1991. Processes," 3rd Ed., McGraw-Hill, 1991.
31 A. Gelb, Ed., "Applied Optimal Estimation," MIT Press, 1974. 35 A. Gelb, Ed., "Applied Optimal Estimation," MIT Press, 1974.
32 I. R. Petersen, V. A. Ugrinovskii, A. V. Savkin, "Robust Control 36 I. R. Petersen, V. A. Ugrinovskii, A. V. Savkin, "Robust Control
Design Using H<\infinity> Methods," Springer, 2000. Design Using H<\infinity> Methods," Springer, 2000.
33 V. Bolotin, J. Coombs-Reyes, D. Heyman, Y. Levy, and D. Liu, "IP 37 V. Bolotin, J. Coombs-Reyes, D. Heyman, Y. Levy, and D. Liu, "IP
Traffic Characterization for Planning and Control," Proc. ITC16, Traffic Characterization for Planning and Control," Proc. ITC16,
Edinburgh, Scotland, June 1999. Edinburgh, Scotland, June 1999.
34 Distributed Management Task Force (DMTF) Common Information Model 38 Distributed Management Task Force (DMTF) Common Information Model
(CIM), www.dmtf.org (CIM), www.dmtf.org
35 B. Moore, E. Ellesson, and J. Strassner, "Policy Core Information 39 B. Moore, E. Ellesson, and J. Strassner, "Policy Core Information
Model -- Version 1 Specification," RFC 3060, February 2001. Model -- Version 1 Specification," RFC 3060, February 2001.
36 C. Partridge, "A Proposed Flow Specification," RFC 1363, 40 C. Partridge, "A Proposed Flow Specification," RFC 1363,
September 1992. September 1992.
18. Acknowledgments 18. Intellectual Property Statement
AT&T Corp. may own intellectual property applicable to packet
sampling as presented in references [30, 31] and summarized in
Section 13. AT&T is currently reviewing its licensing intent
relative to the Intellectual Property and will notify the IETF when
AT&T has made a determination of that intent.
19. Acknowledgments
The support of Gerald Ash on this work and his comments are much The support of Gerald Ash on this work and his comments are much
appreciated. Also, thanks to the inputs from Robert Cole, Enrique appreciated. Also, thanks to the inputs from Jim Boyle, Robert
Cuevas, Alfred Morton, Moshe Segal, and the Tequila project. Nick Cole, Enrique Cuevas, Alfred Morton, Thomas Nadeau, Moshe Segal,
Duffield contributed section 13 on packet sampling. Bert Wijnen, and the Tequila project. Nick Duffield contributed
section 13 on packet sampling.
19. 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 Blaine Christian
 End of changes. 

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