Traffic Engineering Working Group                           Wai Sum Lai
Internet Draft                                                AT&T Labs
Document: <draft-ietf-tewg-measure-05.txt> <draft-ietf-tewg-measure-06.txt>
Category: Informational                                Richard W. Tibbs
                                                    Oak City Networks &
                                                              Solutions

                                                  Steven Van den Berghe
                                                  Ghent University/IMEC

                                                           Febuary

                                                              July 2003

         A Framework

         Requirements for Internet Traffic Engineering Measurement

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1.

Abstract

   In this document, a measurement framework we identify requirements for supporting the
   traffic engineering of IP networks is presented.  Uses of networks.  Requirements for traffic
   measurement in service provider environments are described, presented and
   issues related to time scale
   justified, and read-out period related issues are discussed.
   Different measurement types are classified, with each being
   specified as a meaningful combination

   Highlights of a measurement entity and a
   measurement basis.

   For interoperable compatibility, uniform definitions across vendors
   and operators must be ensured, e.g., in the distinction between
   offered load and achieved throughput. requirements are:
   1. To aid network dimensioning, mechanisms to collect node-pair-based node-pair-
   based traffic data should be
   developed are required to facilitate the derivation of per-service-class per-
   service-class traffic matrix statistics.
   2. For service assurance, there is a need for the use of higher-order statistics. statistics is
   required.
   3. To preserve representative traffic detail at manageable sample
   volumes, there is a need for packet-
   sampled measurements. packet-sampled measurements are required.
   4. To manage large volume volumes of measured data, use of bulk transfer
   and filtering/aggregation mechanisms may be
   appropriate. are required.

Table of Contents

   Status of this Memo................................................1
   1. Abstract........................................................1
   2.
   Abstract...........................................................1
   Conventions used in this document...............................2
   3. document..................................3
   1. Introduction....................................................3
   2. Conclusions and Recommendations.................................4
   3. Requirements for TE Measurement and Its Uses....................4
   3.1 Requirements for Traffic characterization......................5
   3.2 Requirements for Network monitoring............................5
   3.3 Requirements for Traffic Matrix Statistics.....................6
   3.4 Requirements for Performance Monitoring........................6
   3.5 Requirements for Path Characterization.........................7
   4. Terminology.....................................................4 Requirements Summary for TE Measurement Types...................7
   4.1 Measurement types related to traffic or performance............8
   4.2 Measurement types related to resource usage....................8
   5. Requirements for a TE Measurement Information Model.............9
   6. Measurement Definitions........................................11
   6.1 Active, passive measurements...................................4
   4.2 measurements..................................11
   6.2 Route, path....................................................5
   4.3 path...................................................11
   6.3 Throughput, traffic volume.....................................5
   5. Uses of Traffic Measurement.....................................6
   5.1 Traffic characterization.......................................6
   5.2 Network monitoring.............................................6
   5.3 Traffic control................................................7
   6. Time Scales for Network Operations..............................7
   7. Read-Out Periods................................................8
   7.1 Data Reduction.................................................8
   7.2 Measurement Interval...........................................9
   7.3 Summarization..................................................9
   7.4 Sampling Issues................................................9
   8. volume....................................11
   APPENDICES........................................................12
   APPENDIX A........................................................12
   A. Measurement Bases..............................................10
   8.1 Flow-based....................................................11
   8.2 Bases..............................................12
   A.1 Flow-based....................................................14
   A.2 Interface-based, link-based, node-based.......................12
   8.3 Node-pair-based...............................................12
   8.4 Path-based....................................................13
   9. node-based.......................14
   A.3 Node-pair-based...............................................15
   A.4 Path-based....................................................15
   APPENDIX B........................................................16
   B. Measurement Entities...........................................13
   9.1 Entities...........................................16
   B.1 Entities related to traffic and performance...................13
   9.2 performance...................16
   B.2 Entities related to establishment of connection or path.......16
   10. Measurement Types.............................................16
   10.1 Measurement types related to traffic or performance..........16
   10.2 Measurement types related to resource usage..................17
   11. Traffic Matrix Statistics.....................................18
   12. Performance Monitoring........................................19
   13. path.......18
   APPENDIX C........................................................18
   C. Packet Sampling...............................................20
   14. Statistical Estimation Sampling and Information Modeling...............20
   14.1 Estimation.................................18
   C.1 Packet Sampling...............................................19
   C.2 Sampling Issues...............................................19
   C.3 Engineering methods for statistical estimation of measures...21
   14.2 TE Measure Information Modeling..............................21
   15. Conclusions and Recommendations...............................24 measures....20
   APPENDIX D........................................................20
   D. Read-Out Periods...............................................20
   D.1 Data Reduction................................................21
   D.2 Measurement Interval..........................................21
   D.3 Summarization.................................................21
   APPENDIX E........................................................22
   E. Time Scales for Network Operations.............................22
   APPENDIX F........................................................23
   F. Use of Traffic Measurement for Traffic control.................23
   16. Security Considerations.......................................24 Considerations.......................................23
   17. References....................................................24 References....................................................23
   18. Intellectual Property Statement...............................27 Statement...............................26
   19. Acknowledgments...............................................27 Acknowledgments...............................................26
   20. Author's Addresses............................................27 Addresses............................................26
   Full Copyright Statement..........................................28

2. Statement..........................................27

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119.

3.

1. Introduction

   This document describes a framework

   In this document, we identify requirements for Internet supporting IP network
   traffic engineering
   measurement, with the objective of providing principles (TE) [1].  Requirements for the
   development of a set of measurement systems to support the traffic
   engineering of IP networks [1].  A major goal is to provide the
   scope of measurements involved measurement
   in service provider environments are presented and outline a context for
   establishing operator-, platform-, protocol-, justified, and vendor-neutral
   traffic measurement standards.
   related issues are discussed.  To achieve multi-vendor inter-
   operability, it is critical aid network dimensioning,
   mechanisms to minimize collect node-pair-based traffic data are required to
   facilitate the possibilities derivation of
   inconsistencies arising from, e.g., differing statistical
   definitions, overlapping data collection, processing per-service-class traffic matrix
   statistics.  For service assurance, the use of higher-order
   statistics is required.  To preserve representative traffic detail
   at different
   protocol levels, manageable sample volumes, packet-sampled measurements are
   required.  To manage large volumes of measured data, use of bulk
   transfer and similar inconsistencies by different vendors or
   network operators.

   The need filtering/aggregation mechanisms are required.

   Requirements for a common framework, including identification,
   principles and scope of measurements, is TE measurement are motivated by the needs for
   consistency, precision, and effectiveness of the overall traffic
   engineering TE
   function.  Traffic engineering  TE includes measurements, forecasting, planning,
   dimensioning, control, and performance monitoring.  From this perspective, the purpose of this document is
   to set principles of  TE measurement in place that assure the quality of
   the other aspects of traffic engineering.  Intended as
   plays a framework
   document, our goal is key role to describe assure the overall traffic and
   performance measurement process at a high level.  We point to
   objectives that a comprehensive set of measurement standards should
   achieve.  We also list brief informal definitions for most
   measurements quality of interest, but leaving exhaustive and precise
   definitions and standards to the documents cited or subsequent
   documents to be developed by other working groups.

   The scope of this document is limited to those aspects of
   measurement pertaining to intra-domain operations, i.e., within a
   given autonomous system.  However, measurements on its boundary with
   other domains are taken into consideration as well.  The focus is
   primarily on traffic engineering in Internet service provider
   environments.

   In this document, uses TE.

   Uses of traffic measurement in traffic characterization, network
   monitoring, and traffic control are first described.  Depending on
   the network operations to be performed in these tasks, three
   different time scales can be identified, ranging from months,
   through days or hours, to minutes or less.  To support these
   operations, traffic measurement must be able to capture accurately,
   within a given confidence interval, the traffic variations and peaks
   without degrading network performance and without generating an
   immense amount of data.  As one consequence of the need to avoid
   network performance degradation, specification of a suitable read-out read-
   out period for each service class for traffic (i.e., summarization or aggregation interval) is
   essential.  Other principles such as concise
   representation of measurements are identified as well.

   Traffic measurement can be performed on the basis of flows,
   interfaces, links, nodes, node-pairs, or paths.  Based on these
   objects, different measurement entities can be defined, such as
   traffic volume, average holding time, bandwidth availability,
   throughput, delay, delay variation, packet loss, and resource usage.
   Using these measured traffic data, in conjunction with other network
   data such as topological data and router configuration data, traffic
   matrix and other relevant statistics can be derived for traffic
   engineering TE purposes.  Traffic load measurement also plays a key
   role in network performance management.

   In addition to these capabilities, functions of a measurement system
   should also include data storage, data processing, statistics
   generation and reporting.  However, these aspects are outside the
   scope of this document.

   Also,

   IP multicast traffic measurement is not explicitly addressed in this
   document.  Nonetheless, given additional elaboration on tree-based
   measurement principles, most of the considerations for different
   measurement types (to be discussed in Sections 8 (see Appendices A and 9) B) could be applied to IP
   multicast traffic.  Such elaboration may be dealt with in a
   subsequent document for specific IP multicast-
   inferred multicast-inferred Internet
   traffic measurement.

   As a framework, this document is mainly concerned with a discussion
   of various technical issues surrounding traffic measurement,
   particularly in the area of statistical traffic load estimation for
   traffic engineering purposes.  As far as possible and to avoid
   duplication of effort, relevant

   Relevant work done in measurements by other 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
     framework document [2] and the associated documents on individual
     metrics [3, 4, 5, 6, 7, 8, 9, 10] 10, 11]

   . ITU-T: Recommendation I.380/Y.1540 [11] [12] and Recommendation Y.1541
     [12]

4. Terminology

   The intent of this section is not to provide definition or
   description of terms used
     [13]

2. Conclusions and Recommendations

   Requirements are given in this document.  Rather, it is to
   highlight the difference in usage document for traffic metrics needed
   for successful TE.  Principles of closely related terms.

4.1 Active, passive measurements

   These terms are used best practice in the sense of [2].  In an active measurement,
   test packets, or probes, traffic
   characterization and performance characterization are injected into described in
   the network.  Data
   collected about these packets are taken as representative Appendices.  For interoperable compatibility and consistency,
   requirements for traffic measurement recommended for standardization
   include:

   (1) Requirements for specific TE measurements

   . Node-pair-based traffic data to derive per-service-class traffic
     matrix statistics, including statistics of the
   behavior carried load and
     offered load (Sections 3.3 and Appendix A)
   . Statistics of the network.  Passive measurements are in-service, non-
   intrusive, achieved performance and so can be performed directly on the user traffic.

4.2 Route, path throughput (Section 3.4)
   . A route is any unidirectional sequence of nodes and links, for
   sending packets from a source node to a destination node.  A path
   refers to an MPLS tunnel, i.e., a label-switched path (LSP) [13],
   this LSP possibly being a traffic-engineered LSP.  Measurements on
   non-traffic-engineered LSPs may be collected to support the possible
   future traffic-engineering of those LSPs.  (Note:  What is defined
   as a route here is referred to as a path in [2].  The route/path
   distinction is made here to facilitate applications to MPLS.)

   It should be pointed out that there are also methods for creating
   paths with other technologies such as frame relay or ATM.  The
   measurement described in this document may apply to these
   technologies with suitable adaptation.  To simplify description,
   reference is made to MPLS only in what follows.

4.3 Throughput, traffic volume

   Both quantities can be applied to a network, a network segment, or
   an individual network element.  Thus, measurement points need to be
   appropriately defined when a specific measurement is to be performed
   (e.g., from a given ingress node to another egress or a set of
   egress nodes).

   Throughput of a network, as a measure of delivered performance,
   refers to the maximum sustainable rate of transferring packets
   successfully across the network, under given network conditions,
   e.g., a given traffic mix, while meeting quality of service (QoS)
   objectives.  This usage is consistent with the definition of
   throughput for a network interconnect device as specified in [14].
   For real-time network control, active measurement of throughput by
   probing may be used to determine the currently available capacity of
   a network to carry additional traffic.  (Note: Goodput is a related
   term referring to a proportion of the traffic successfully
   transmitted; similarly, badput refers to a proportion of the traffic
   lost or being corrupted.)

   Traffic volume, reflecting the traffic carried, is the amount of
   traffic measured during a given period of time.  Passive measurement
   of the traffic volume is usually used to estimate the long-term
   offered traffic for the purposes of network dimensioning in the
   capacity-management and network-planning processes (see the Section
   on Time Scales for Network Operations).  A network should be
   properly dimensioned so that its throughput is adequate to handle
   the expected traffic volume.  Hence, traffic volume measurement
   should be performed on a regular basis.

   Throughput at a cross-section, or specific point in the network, is
   expressed in terms of number of data units per time unit.  Traffic
   volume is expressed in data units with reference to a read-out
   period (see the Section on Read-Out Periods).  For transmission
   systems, the data unit is usually a multiple of either bits or
   bytes.  For processing systems, the data unit is usually a multiple
   of packets.

5. Uses of Traffic Measurement

   Traffic measurement is used to collect traffic data for the
   following purposes:
   . Traffic characterization and capacity planning
   . Network monitoring
   . Traffic control

5.1 Traffic characterization

   . Identifying traffic patterns, particularly traffic peak patterns,
     and their variations in statistical analysis; this includes
     developing traffic profiles to capture daily, weekly, or seasonal
     variations.
   . Determining traffic distributions in the network on the basis of
     flows, interfaces, links, nodes, node-pairs, paths, or
     destinations.
   . Estimation of the traffic load according to service classes in
     different routers and the network.
   . Observing trends for traffic growth and forecasting of traffic
     demands.

   For example, traffic engineering measurements are usually used to
   determine the statistical moments of a traffic flow.  As suggested
   in [15], 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

   . Determining the operational state of the network, including fault
     detection.
   . Monitoring the continuity and quality of network services, to
     ensure that QoS/CoS objectives are met for various classes of
     traffic, to verify the performance of delivered services, or to
     serve as a means of sectionalizing performance issues seen by a
     customer.  [Note 1.  QoS reflects the performance perceivable by a
     user of a service, while CoS (class of service) is used by a
     service provider for internal design and operation of a network.]
     [Note 2.  Mechanisms for monitoring service continuity may be
     service-specific and are not discussed here.]
   . Evaluating the effectiveness of traffic engineering policies, or
     triggering certain policy-based actions (such as alarm generation,
     or path preemption) upon threshold crossing; this may be based on
     the use of performance history data.

   . Verifying peering agreements between service providers by
     monitoring/measuring the traffic flows over interconnecting links
     at border routers (note that peers are in general not willing to
     divulge detailed traffic picture inside their autonomous systems);
     this includes the estimation of inter- and intra-domain traffic,
     as well as originating, terminating, and transit traffic that are
     being exchanged between peers.

   An example of using traffic measurements in this area might be
   monitoring packet loss rates at various points in a network to
   detect apparent link failure.  Another example is monitoring the QoS
   at peering points to ensure that peering agreements are met.

5.3 Traffic control

   . Adaptively optimizing network performance in response to network
     events, e.g., rerouting to work around congestion or failures.
   . Providing a feedback mechanism in the reverse flow messaging of
     RSVP-TE [16] or CR-LDP [17] signaling in MPLS to report on actual
     topology state information such as link bandwidth availability.
     (An example of such a feedback mechanism is described in [18].  As
     described therein, care should be exercised to ensure network
     stability and consistency for any mechanism that makes direct
     operational use of measurement (e.g., to use as feedback into path
     computation).  However, such issues will not be dealt with here as
     this framework document is mainly concerned with the definitions
     and principles of measurements, rather than their usage to
     subsequently ensure other network features such as accurate
     bandwidth allocation.)
   . Support of measurement-based admission control, i.e., by
     predicting the future demands of the aggregate of existing 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

   The information collected by traffic measurement can be provided to
   the end user or application either in real time, or for record
   (i.e., data retention) in non-real time, depending on the activities
   to be performed and the network actions to be taken.  Traffic
   control will generally require real-time information.  For network
   planning and capacity management as described below, information may
   be provided in non-real time after the processing of raw data.

   Broadly speaking, the following three time scales can be classified,
   according to the use of observed traffic information for network
   operations [15].

   Network planning
   Information that changes on the order of months is used to make
   traffic forecasts as a basis for network extensions and long-term
   network configuration.  That is, for planning the topology of the
   network, planning alternative routes to survive failures or
   determining where capacity must be augmented in advance of projected
   traffic growth.  Long-term planning includes the selection and
   timing of the introduction of new architectures, technologies and
   vendors, in alignment with financial forecasts and market
   assessments.

   Capacity management
   Intermediate-scale (e.g., six months or less) capacity planning
   deals with detailed implementation of the build plan, short-lead-
   time activities and out-of-plan events.  It typically uses a
   rolling-month forecast of traffic and demand.  Information that
   changes on the order of days or hours is used to manage the deployed
   facilities, by taking appropriate maintenance or engineering actions
   to optimize utilization.  For example, new MPLS paths may be set up
   or existing paths modified while meeting service level agreements.
   Also, load balancing may be performed, or traffic may be rerouted
   for re-optimization after a failure.

   Real-time network control
   Information that changes on the order of minutes or less is used to
   adapt to the current network conditions in near real time.  Thus, to
   combat localized congestion, traffic management actions may perform
   temporary rerouting to redistribute the load.  Upon detecting a
   failure, traffic may be diverted to pre-established, secondary
   routes until more optimized routes can be arranged.

7. Read-Out Periods

   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
   minimize the amount of data to be collected, and to condense the
   collected data by periodic summarization over read-out periods.

7.1 Data Reduction

   Techniques to manage large volumes of measured data are needed to
   prevent network performance from being adversely affected by the
   unnecessarily excessive loading of router control processors, router
   memories, transmission facilities, and the administrative support
   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.

7.2 Measurement Interval

   A measurement interval is the time interval over which measurements
   are taken.  Some traffic data must be collected continuously, while
   others by sampling, or on a scheduled basis.  For example, peak
   loads and peak periods can be identified only by continuous
   measurement as traffic typically fluctuates irregularly during the
   whole day.  If traffic variations are regular and predictable, it
   may be possible to measure the expected normal load on pre-
   determined portions of the day.  Such duration of peak traffic is
   referred to as a busy period.  Special studies on selected segments
   of the network may be conducted on a scheduled basis.  Occasionally
   unexpected events or other decision support needs may arise that
   require ad-hoc, unscheduled measurement, with standardized method to detect and record label binding changes
     for LDP-signaled label-switched paths, at the involvement ingress-egress pair
     level (Section 3.5)

   (2) Requirements for traffic data collection methods

   . Standardization of the
   network operator, and in such a case measurements may be activated
   manually.  For instance, active throughput measurement may be used definitions and sampling methods,
     to identify alternate routes for spreading achieve uniformity across vendors and operators, and to
     preserve sufficient traffic detail at manageable sample volumes
     (Section 6 and Appendix C)
   . Higher-order statistics to avoid future
   periods of network congestion, based on observations of current
   local congestion events.

7.3 Summarization

   A measurement interval consists of a sequence of consecutive read-
   out periods.  Summarization is usually done by integrating the raw
   data over a pre-specified read-out period.  The granularity of this
   period must be suitably chosen.  It should be short enough facilitate service assurance (Section
     3.1)
   . Offline bulk file transfer and standardized filtering/aggregation
     mechanisms to
   capture, with acceptable accuracy, the bursty nature manage large volumes of the traffic,
   i.e., the measured traffic variations data
     (Section 5 and peaks.  Since measurements
   represent Appendix D)
   . Linkage between policy mechanisms and TE measurement, possibly
     triggered by a load measurement-driven event notification (Section 5)
   . Standardization of information models for the router (if third-party TE measurement (Section
     5)

3. Requirements for TE Measurement and Its Uses
   TE measurement devices
   are not employed), the read-out period should not be so short that
   router performance is degraded while a voluminous quantity of data is produced.   Also, read-out may be started when the measured used to collect traffic data
   exceeds a preset threshold, or when for the space allocated following
   purposes:
   . Traffic characterization
   . Network monitoring
   . Traffic matrix Statistics
   . Performance monitoring
   . Path characterization

3.1 Requirements for
   temporarily holding the data in a router is exhausted.

   For a multi-service IP network, each Traffic characterization

   . Requirement 1: Standardization of higher-order statistics to
     facilitate service typically has its own assurance.
   . Requirement 2: Identifying traffic characteristics patterns, particularly traffic
     peak patterns, and performance objectives.  To ensure that
   CoS-specific features are reflected their variations in statistical analysis; this
     includes developing traffic profiles to capture daily, weekly, or
     seasonal variations.
   . Requirement 3: Determining traffic distributions in the measurement process,
   different read-out periods may be needed for different classes network on
     the basis of
   service.

7.4 Sampling Issues

   The concept flows, interfaces, links, nodes, node-pairs, paths,
     or destinations.  (These bases are discussed in Appendix A.)
   . Requirement 4: Estimation of read-out periods applies to both active and passive
   measurements.  This concept is consistent with the sampling issues
   for a series of measurements as developed traffic load according to service
     classes in [2], for example.  See
   sections 10 different routers and 11 of that document the network.
   . Requirement 5: Observing trends for important distinctions
   between "singletons, samples, traffic growth and statistics."  The procedure forecasting
     of
   Poisson sampling, for traffic demands.

   For example, may be used within a read-out period
   to select a subset of total packet events that are chosen as the
   sample.  Then a statistic (e.g., mean or variance) TE can be computed
   over that sample and associated with use measurements to determine the read-out period.  Although
   [2] does not discuss traffic volume measures such as statistical
   moments of a traffic
   matrix, the same sampling issues arise for flow.  As suggested in [14], given the traffic matrix and
   other passive measurements.

8. Measurement Bases

   Measurements can be classified time
   series of packet arrivals, a suitable parametric stochastic model
   based on the basis of where, mean and at which
   level variance of aggregation the traffic data are gathered. time series can be
   constructed.  This traffic model is similar
   to then used in the concept of a *population ensuing phases
   of interest* TE, such as specified in ITU-T
   Recommendation I.380/Y.1540.  As defined therein, this refers to a
   set of packets, possibly relative link dimensioning to a particular pair of source and
   destination hosts, meet service objectives.

3.2 Requirements for Network monitoring

   . Requirement 1: Determining the purposes operational state of defining performance
   parameters.  However, measurement bases as used here may not have
   any association with a source-destination pair.  This is to be
   described in more details below.  Currently, the different
   measurement bases to be defined below have not been explicitly
   specified in the IPPM Framework [2].

   In this document, network,
     including fault detection.
   . Requirement 2: Monitoring the focus is on service providers as organizations
   requiring traffic continuity and performance measurements.  (However, customer-
   based measurements quality of enterprise networks may have similar issues.)
   Service providers will make decisions on how network
     services, to perform the
   measurements needed, and there ensure that QoS/CoS objectives are met for various tradeoffs involved.  One
   option is
     classes of traffic, to obtain the measurements directly from the network
   elements themselves, e.g., via SNMP (Simple Network Management
   Protocol).  Collecting the measurements on verify the operational network
   elements such performance of delivered
     services, or to serve as routers is sometimes a means of sectionalizing performance concern.
   Currently, there is
     issues seen by a number of third-party measurement/monitoring
   products available.  Hence, another option is to deploy such
   equipment, which might have customer.  [Note 1.  QoS reflects the performance advantages but also
   introduces additional cost.

   Regardless
     perceivable by a user of the type a service, while CoS (class of measurement source, either service)
     is used by a network
   element or service provider for internal design and operation of
     a third-party product, measurements should network.]  [Note 2.  Mechanisms for monitoring service
     continuity may be collected,
   as far service-specific and are not discussed here.]
   . Requirement 3: Evaluating the effectiveness of TE policies, or
     triggering certain policy-based actions (such as possible, alarm generation,
     or path preemption) upon threshold crossing; this may be based on
     the use of performance history data.
   . Requirement 4: Verifying peering agreements between service
     providers by a measurement source without requiring
   coordination with other measurement sources.  Thus, it is desirable
   to perform those measurements monitoring/measuring the traffic flows over
     interconnecting links at border routers (note that do peers are in
     general not require willing to divulge detailed traffic picture inside
     their autonomous systems); this includes the use estimation of
   specialized inter-
     and intra-domain traffic, as well as originating, terminating, and
     transit traffic that are being exchanged between peers.

   An example of using TE measurements in this area might be monitoring equipment connected to the network
   packet loss rates at
   multiple locations.  While each measurement source may act
   autonomously with regard to taking measurements, various points in a network operator
   may specify some network-wide policy regarding measurement
   scheduling.  Such policy to detect apparent
   link failure.  Another example is observing traffic at peering
   points to ensure that peering agreements are met.

3.3 Requirements for Traffic Matrix Statistics

   Requirement 1
   Standardization of node-pair-based traffic data to derive per-
   service-class traffic matrix statistics, including statistics of
   carried load and offered load.

   An important set of data for TE is point-to-point or point-to-
   multipoint demands.  This data may be, say, the use be of significant use in the same time
   provisioning of
   day, traffic-engineered intra-domain paths and external
   peering in the same measurement interval, or measurement intervals that
   are multiples of each other (e.g., nested intervals with
   synchronized boundaries).  A schedule therefore should include such
   time information existing network, as well as planning for the start, the duration,
   placement and periodicity of a
   certain measurement.  Also note that the accuracy sizing of new links, routers, or peers.

   In current practice, estimates for traffic
   measurement is highly dependent on the synchronization capabilities
   of the measurement devices that will be involved in the measurement
   procedures.  While synchronization issues demands are out usually
   determined from a combination of traffic projections, customer
   prescriptions, and service level agreements.  Using the scope facilities
   of
   this document, they should be explicitly addressed whenever a
   measurement campaign SNMP (Simple Network Management Protocol), it is not easy to be launched, whatever its scope and its
   frequency.

   The following measurement bases are considered in this document:
   . Flow-based
   . Interface-based, link-based, node-based
   . Node-pair-based
   . Path-based

   Generally speaking, for
   obtain network-wide traffic engineering purposes, passive demands from the local interface
   measurements taken by different IP routers.  As explained in [15,
   16], information from diverse network measurements, including flow-
   based measurements, and various topological data and router
   configuration files are mostly used.  However, as needed to be described later infer the traffic volume.

   Some shortcomings in today's method to derive traffic matrix
   statistics as above include the "Measurement Types" section, volume of data from flow-based
   measurement, the above measurement bases may
   result in active or passive measurements.  For example, an active
   measurement may be lack of sufficient routing control information, and
   the need to correlate data from a two-point delay metric such as type-P-one-way-
   delay defined in [4], variety of sources.  To avoid some
   of these deficiencies and obtained to take advantage of the routing control
   offered by time-stamping probe packets at
   selected ingress and egress points; a MPLS, node-pair-based passive measurement may should be to
   obtain packet inter-arrival times by time-stamping successive
   packets
   developed.

3.4 Requirements for Performance Monitoring

   Requirement 1
   Standardization of the traffic at a selected point in the network.  Note
   that both active statistics of achieved performance and passive measurements are subject
   throughput.

   Requirement 2
   Performance monitoring as a means to trigger LSP restoration
   activities.

   A major component of performance management is performance
   monitoring, i.e., continuous real-time monitoring of the same
   sampling and time-source accuracy concerns.

   MPLS has certain advantages when compared with conventional IP
   networks, from the perspective quality or
   health of the difficulty involved in
   obtaining unambiguous measurements.  As different service providers
   will adopt different technologies, technology-neutral solutions network and its various elements to
   the problem ensure a
   sustained, uninterrupted delivery of obtaining measurements are presented as far as
   possible.

   Applicability quality service.

   General aspects of traffic measurements required to support the derivation of traffic
   matrix statistics operation,
   administration, and maintenance of a network are outside the scope
   of this document (see [17, 18, 19, 20] for a discussion of MPLS
   OAM).  However, performance monitoring are to be described in
   later sections.

8.1 Flow-based

   This is conceptually similar to required for TE
   measurement since monitoring the call detail record (CDR) in
   circuit-switched telecommunications networks.  It quality of delivered services is primarily used
   on interfaces at access routers, edge routers, or aggregation
   routers, rather than on backbone routers in
   essential feedback to the core network.  Like
   CDR measurements, flow-based records are used TE function.

   This requires the use of measurement, either passively or actively,
   to collect detailed information about a flow.  This includes such information as source
   and destination IP addresses/port numbers, protocol, type the operational state of
   service, timestamps for the start network
   and end of a flow, packet count,
   octet count, etc.

   As flow is to track its performance.  For a fine-grained object, measuring every flow that passes
   through all discussion of passive
   monitoring and the edge devices may not be scalable or feasible.
   Hence, per-flow data are usually used use of synthetic traffic sources in active
   probing, see [21, 22].

   Performance degradation can occur as a special study conducted
   on a non-continuous schedule and on selected routers only.  Sampling result of flow-based measurements routing
   instability, congestion, or failure of network components.  Periods
   of congestion may also be needed to reduce both detected when the
   amount resource usage of data collected and the associated overhead.

8.2 Interface-based, link-based, node-based

   While active measurements are often not useful at a single point,
   passive measurements can be taken at each network element.  For
   example, SNMP uses passive monitoring to collect raw data on an
   interface at an edge
   segment consistently exceeds a certain threshold, or backbone router.  These data are stored in
   MIBs (Management Information Bases) and include counts on when the cross-
   router delay is unexpectedly high.  Unexpected excessive loss of
   packets or throughput drops may be used as a means of fault
   detection, and octets sent/received, packet discards, errored packets.  Such
   measurements may have result in restoration activities.

3.5 Requirements for Path Characterization

   Requirement 1
   Standardization of a method to detect and record label binding
   changes for LDP-signaled label-switched paths, at the disadvantage that ingress-egress
   pair level.

   In the identity case of each
   flow hop-by-hop routed label-switched paths that are
   established by Label Distribution Protocol (LDP) signaling, there is lost.

   To reduce the overhead in managing multiple links
   no explicit binding between path end points.  This will result in
   the use of different label bindings at both the same ingress and egress points, there
   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, 26], a mechanism is proposal
   needed to aggregate links 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.

   Internet utilities such as ping and traceroute have been useful to
   help diagnose network optimization [19].  Component links problems and performance debugging.  Utilities
   with similar functions would be essential for path-oriented
   operations like in such MPLS.  This would include the capability to list,
   at any time, (1) for a *bundled link*
   will have given path, all the same routing constraints, resource classes, nodes traversed by it,
   and
   attributes.  Multiple links are treated as (2) for a single IP link.
   Traffic measurements, such as bandwidth availability, throughput,
   etc., should consider given node, all the measurement implications paths originating from it,
   transiting through it, and/or terminating on it.  A proposal for bundled
   links,
   path tracing is described in [24].  A proposal to establish basic
   MPLS data plane liveness is described in [25].

4. Requirements Summary for TE Measurement Types
   A measurement type is a meaningful and should not inhibit link bundling.  (For example, measurable combination of a single
   IP link may presumably be referenced as
   measurement basis (Appendix A) and a pair measurement entity (Appendix
   B).  Two sets of IP addresses that
   are assigned to both extremities measurement types, organized in the form of
   matrices, are presented in the link.  An implicit issue
   that may need to be resolved relates following two subsections.

4.1 Measurement types related to traffic or performance

   The following measurement matrix summarizes the exact characterization
   of the measurement types
   related to traffic that will be conveyed in each component link, since a
   couple of IP addresses may not or performance.  Potentially, there can be sufficient for such link-based
   measurement.)  Also, one
   such measurements should matrix for each service class.

            Bases:     Flow     Interface,   Node Pair      Path
                                   Node
  Entities:          (passive)   (passive)     (both)      (both)

  Traffic Volume        x(1)         x          x(3)        x(3)
  Avg. Hold. Time        x                                  x(3)
  Avail. Bandwidth                   x                      x(3)
  Throughput             x                      x(4)        x(4)
  Delay                             x(2)        x(4)        x(4)
  Delay Variation                   x(2)        x(4)        x(4)
  Packet Loss            x           x          x(5)        x(5)

   Notes:
   (1) This measurement type can be protocol
   independent and media independent used to ensure portability and
   commonality in the derive flow size
   statistics.
   (2) These are 1-point measurements.

8.3 Node-pair-based

   Active measurements  For a discussion on 1-point
   packet delay variation, see [12], Appendix II.
   (3) As a starting point, statistics collected by probing, as specified in passive measurement
   through the MIBs useful for TE [26, 27, 28] may be used.
   (4) Active measurements based on IPPM framework metrics are currently in use
   for example, can node-pairs; they may be conducted between each pair of (major) routing
   hubs developed for determining edge-to-edge performance of a core network.
   This complements the passive measurements of the previous sub-
   section, which provide local views of the performance of individual
   network elements.

   In contrast to performance statistics, traffic loading statistics
   require passive paths.
   (5) Besides active measurements of based on IPPM, path loss may
   possibly be inferred from the actual traffic.  In circuit-
   switched telecommunications networks, each established call has an
   associated source/destination node-pair.  By maintaining a set of
   node-pair data registers [usage, call attempts (so-called "peg
   count" in telephony operation difference between ingress and management), overflow, etc.] in
   each switch, node-pair-based measurements for egress
   traffic statistics at the two endpoints of a path.  However, such as
   inference for the load cumulative losses between a given node pair are taken directly.  In
   IP networks, currently such node-pair-based measurements are
   difficult to establish due over
   multiple routes may be less useful, since different routes may have
   different loss characteristics.

4.2 Measurement types related to resource usage

   Another measurement matrix summarizes measurement types comprising
   the dynamic and asymmetric properties
   of IP routing.  However, it is possible to infer them from flow-
   based passive measurements and other different usage, one for each network information, resource object such as
   routing table snapshots.  A problem with this approach is that flow-
   based measurement data are voluminous.  Also, another problem that
   must be accounted for is the routing changes among the multiple
   routes due to, e.g., a change in the configuration of intra-domain
   routing, or a change in inter-domain policies made
   router (processor and memory), link, and buffer, by another
   autonomous system.  This is further discussed in the Section on
   Traffic Matrix Statistics.

8.4 Path-based different
   classes of traffic:

   . control (e.g., routing control) traffic
   . signaling traffic
   . user traffic from different service classes

                        Bases:   Node     Link    Buffer
           Entities:
           Control Util.           x        x        x
           Signaling Util.         x        x        x
           Service Class Util.     x        x        x

   The ability amount of MPLS to use fixed preferred paths for routing
   traffic, so-called "route pinning" (or "path pinning", using control and signaling traffic carried by a network is
   a function of many factors.  To name a few, they include the
   definitions size
   and topology of Section 4.2), gives the means to develop path-based
   measurements.  This may enable network, the development control and signaling protocols
   used, the amount of methodologies for user traffic carried, the number of failure
   events, etc.  Also, flooding of link-state advertisement (LSA)
   messages in Interior Gateway Protocols (IGP, such functions as admission OSPF or IS-IS)
   may cause significant routing control and performance verification of
   delivered service.

   Like a flow, a path is associated with traffic during events such as
   an LSA storm as a pair result of nodes.  However,
   path is a more coarse-grained object than flow, as paths are usually
   used failures due to carry aggregated fiber cuts or failed
   power supply.  The above utilization measurements for control and
   signaling traffic (from different flows).  In
   addition, when routing changes occur, are intended to help develop guidelines for the amount
   proper dimensioning and apportionment of network resources so that a
   given level of user traffic to can be
   carried by adequately supported.

5. Requirements for a path will either not be affected or be merged with TE Measurement Information Model

   Requirement 1
   Standardization of an information model for TE measurement.

   Requirement 2
   Standardization of offline bulk file transfer and standardized
   filtering/aggregation mechanisms to manage large volumes of measured
   traffic data (see Appendix D for further discussion).

   Several approaches and options for repository technology are now
   broadly discussed.  Relationships between TE measure information
   models on other information models (e.g., the COPS Policy Information
   Base, PIB) that drive network outcomes are of another path.  Because particular importance.
   For an example of these properties, path-based
   measurements are more scalable and may a PIB, see [29].

   Linkages should be used considered between policy mechanisms and TE
   measures.  This is useful because, while policy-driven networking is
   well-developed between the policy repositories, policy decision
   points and policy enforcement points, policy content is very likely
   the output of TE applications [30].  **Since TE applications are
   dependent upon TE measures, it is advantageous to provide more
   readily an accurate, network-wide, view of
   traceability between the traffic demands.  For
   example, measures and the traffic between engineering changes made as
   a given pair consequence of nodes may be inferred
   from the aggregate them.**  An example of the traffic carried by all paths either
   terminated by or passed through the same node-pair.

9. Measurement Entities

   A measurement entity defines what is measured: it is a quantity for
   which data collection must client application that
   might be performed with driven by TE measures through a certain measurement.
   A measurement type can be specified PIB is found in [31, 32].

   Measures (represented by their estimates) should be centrally stored
   and collected in a (meaningful) combination logical sense.  This does not preclude distributed
   storage for purposes of
   a measurement entity with the measurement basis described in volume management or security/survivability,
   but alludes to the
   previous section.

   An important issue with any measurement is measurement precision
   and/or accuracy.  However, this issue is not dealt with here since
   each measurement type will potentially have its own unique
   requirements.  For example, see [4], Section 3.7, need for a discussion
   on error issues consistent retrieval mechanism (e.g.,
   NFS).  Two methods are: (1) extend MIBs with new definitions for one-way delay.

9.1 Entities related to traffic TE
   measure estimates or extend PIBs with new objects and performance

   Some of use the measurement entities listed below, COPS
   feedback extensions to get statistics stored at the policy
   enforecement points, and (2) create data depositories through more
   centralized facilities, such as throughput,
   delay, delay variation, relational databases or LDAP (see
   [29]).  Both methods have merits as collection processes for TE
   measures, and packet loss, 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
   applications to retrieve data from the
   respective IPPM performance metrics or the I.380/Y.1540 performance
   parameters.

   . Traffic volume (mean and variance, network elements being
   measured.  This is inherently "vendor-neutral," allowing commonly
   defined TE measurements to be stored for retrieval in number a common MIB
   definition, regardless of bits, bytes, network element vendor, technology or
     packets transferred, other
   differences.

   A centralized data storage facility has the advantage that TE
   applications (such as counted over a given time interval), on a
     per service class basis, at various aggregation levels (IP address
     prefix, interface, link, node, node-pair, path, network edge,
     customer, offline and online TE, or autonomous system)
     Note:  (1) This measurement-based
   admission control) can be performed without invasive retrieval of
   data from network-wide MIBs.

   It is possible that both the distributed MIB-based and centralized
   repository-based approaches (or another approach altogether) should
   be considered jointly.  However, this is not mandatory: TE systems
   could rely solely on events from distributed measurement points,
   e.g., based on threshold checking in every device.  Even in this
   case, a centralized storage should be in place to log these events so
   to provide a measurement for linkage between the traffic carried by a
     network, a network segment, or an individual network element; observed behavior and resulting
   configuration.

   Although this document focuses on the motivation for providing TE
   measurement information, it is used assumed that this information should
   be provided to derive the carried load or carried traffic intensity
     [20].  When measured during participating devices by means of a communication
   protocol that would be used between the busy period, this aforementioned participating
   devices and a presumably centralized entity is
     normally used to estimate that would aim at
   storing, maintaining and updating this information, as well as
   making appropriate decisions at the traffic offered.  However, right time and under various
   conditions.

   This communication protocol should have the
     estimation procedure following
   characteristics:

   1. The protocol should take into account such factors as
     congestion, which may result in make use of a decreased volume reliable transport mode, given
   the importance of carried
     traffic.  In addition, congestion may lead configuration information.
   2. The protocol architecture should provide a means for dynamically
   provisioning the configuration information to user behavior such
     as reattempt or abandonment, which the participating
   devices, so that it may affect introduce/contribute to a high level of
   automation in the actual traffic
     offered.  (2) To reduce uncertainty in traffic estimation, second-
     order measures TE measurement operation.
   3. The protocol should support one or more reporting mechanisms that
   may need to be developed.  Beyond used for statistical information retrieval.  Reporting
   mechanisms can be either polling-based (explicit requests) or event-
   based (asynchronous reports).
   4. The protocol should support the use of
     variance appropriate security mechanisms
   to provide some guarantees as far as in current practice, further study is needed for the
     feasibility preservation of the
   confidentiality of other second-order techniques.  (3) the configuration information is concerned.
   5. The protocol should support reporting at regular intervals, and
   can optionally support asynchronous conditional reporting (e.g.,
   whenever a value crosses a threshold).

6. Measurement Definitions

   Requirement 1
   Standardization of measurement definitions and sampling methods, to
   achieve uniformity across vendors and operators and to preserve
   sufficient traffic volumes over interconnecting links detail at border routers can
     be used manageable sample volumes.

   It is critical to estimate minimize the traffic exchange between peers for
     contract verification.

   . Average holding time (e.g., flow duration or lifetime, duration possibilities of
     an MPLS path), on a per service class basis
     Note:  (1) When MPLS traffic engineering is used, this is inconsistencies
   arising from, e.g., differing statistical definitions, overlapping
   data collection, processing at different protocol levels, and
   similar
     to call holding time in telecommunications networks.  Call
     attempts, usage, inconsistencies by different vendors or network operators.
   Uniform measurement definitions across vendors and call holding time are three busy-hour
     entities that operators should
   be independently measured for both call-
     dependent enforced as far as possible.

   As this is a requirements document and load-dependent engineering.  This not a document for
   measurement definitions, the intent of this section is important
     especially when not to
   provide definition of terms used.  Rather, it is to highlight the call busy hour
   difference in usage of closely related terms and the load busy hour during a
     day describe terms used
   herein.  Nor is this section exhaustive, since needs for other
   measures may arise in practice (for examples of other closely-
   related metrics see [33]).

6.1 Active, passive measurements

   These terms are non-coincident, due to used in the hour-to-hour variation sense of call
     holding times.  (2) The holding time statistics [2].  In an active measurement,
   test packets, or probes, are injected into the network.  Data
   collected about these packets are taken as representative of long-living
     static paths reflect the effect
   behavior of network equipment failures,
     link outages, or scheduled maintenance, the network.  Passive measurements are in-service, non-
   intrusive, and hence may so can be used performed directly on the user traffic.
   For a discussion of sampling issues related to
     derive information about up-time or service availability.  (3) It both active and
   passive measurements, see Appendix C.

6.2 Route, path

   A route is desirable any unidirectional sequence of nodes and links, for
   sending packets from a source node to a destination node.  A path
   refers to an MPLS tunnel, i.e., a label-switched path (LSP) [34],
   this LSP possibly being a traffic-engineered LSP.  Measurements on
   non-traffic-engineered LSPs may be able collected to gather, by passive means, support the up-time
     durations for each pair possible
   future traffic-engineering of label bindings in the label-forwarding
     information base for labels distributed by different protocols
     (such those LSPs.  (Note:  What is defined
   as LDP, RSVP-TE, MP-BGP, or BGP).  Then, the derivation of
     LSP average holding time does not need a route here is referred to be finely correlated
     with network events such as link/node failures.

   . Available bandwidth of a link or path - useful for load balancing,
     measurement-based admission control in [2].  The route/path
   distinction is made here to determine the feasibility
     of creating a new MPLS tunnel (real-time information can facilitate applications to MPLS.)

   It should be used pointed out that there are also methods for dynamic establishment)

   . Throughput (in bits per second, bytes per second, or packets per
     second)
     Note:  (1) This creating
   paths with other technologies such as frame relay or ATM.  The
   measurement described in this document may apply to these
   technologies with suitable adaptation.  To simplify description,
   reference is the rate at which a given amount of made to MPLS only in what follows.

6.3 Throughput, traffic
     excluding lost, misdelivered, or errored packets, that passes
     between a set of end points, where end points volume
   Both quantities can be logically or
     physically defined.  The condition of the applied to a network, e.g., normal a network segment, or
     high load, under which the
   an individual network element.  Thus, measurement is taken should points need to be noted.
     (2) The protocol level at which
   appropriately defined when a throughput specific measurement is taken
     must be specified, as the packet payload and packet overheads are
     protocol dependent.  (3) The average packet size may to be inferred performed
   (e.g., from a given ingress node to another egress or a set of
   egress nodes).

   Throughput of a network, as a measure of delivered performance,
   refers to the bit rate and packet maximum sustainable rate measurements, when performed on of transferring packets
   successfully across the basis network, under given network conditions,
   e.g., a given traffic mix, while meeting quality of an individual router. service (QoS)
   objectives.  This quantity usage is useful to
     gauge router performance, since router operations are typically
     packet-oriented and small packets are more processing-intensive.

   . Delay (e.g., cross-router delay from node-based consistent with the definition of
   throughput for a network interconnect device as specified in [35].
   For real-time network control, active measurement of throughput by
   probing may be used to measure queueing delay within determine the currently available capacity of
   a network to carry additional traffic.  (Note: Goodput is a related
   term referring to a proportion of the traffic successfully
   transmitted; similarly, badput refers to a router; end-to-end one-way
     or round-trip packet delay can be obtained by node-pair-based
     measurement)
     Note: The condition proportion of the network, e.g., normal traffic
   lost or high load,
     under which being corrupted.)

   Traffic volume, reflecting the measurement traffic carried, is taken should be noted.  This the amount of
   traffic measured during a given period of time.  Passive measurement
   of the traffic volume is
     useful to determine if delay objectives are met.

   . Delay variation
     Note:  There are several methods usually used to measure this quantity as
     specified estimate the long-term
   offered traffic for the purposes of network dimensioning in ITU-T the
   capacity-management and IPPM.  (1) In Y.1540, measurements are
     defined network-planning processes (see Appendix E
   on Time Scales for both 2-point and 1-point IP packet delay variation.
     However, 2-points methods are being specified as normative.  (2)
     In IPPM [9], Network Operations).  A network should be
   properly dimensioned so that its throughput is adequate to handle
   the concept of expected traffic volume.  Hence, traffic volume measurement
   should be performed on a selection function is introduced
     that allows for regular basis.

   Throughput at a cross-section, or specific point in the explicit designation network, is
   expressed in terms of selected packets whose
     one-way delay values are compared number of data units per time unit.  Traffic
   volume is expressed in data units with reference to compute one-way delay
     variation. a read-out
   period (see Appendix D on Read-Out Periods).  For example, to define transmission
   systems, the data unit is usually a method multiple of measurement, either bits or
   bytes.  For processing systems, the data unit is usually a
     selection function multiple
   of packets.

APPENDICES

APPENDIX A

A. Measurement Bases

   Measurements can be specified classified on the basis of where, and at which
   level of aggregation the traffic data are gathered.  This is similar
   to select the consecutive
     packets within concept of a *population of interest* as specified interval, or in ITU-T
   Recommendation I.380/Y.1540.  As defined therein, this refers to select the maximum and
     minimum one-way delays within a specified interval.

   . Packet loss
     Note:  (1) While packet losses due
   set of packets, possibly relative to transmission and/or protocol
     errors a particular pair of source and
   destination hosts, for the purposes of defining performance
   parameters.  However, measurement bases as used here may not have
   any association with a source-destination pair.  This is to be traffic related, unexpected excessive loss may
   described in more details below.  Currently, the different
   measurement bases to be used as a means of fault detection.  (2) defined below have not been explicitly
   specified in the IPPM Framework [2].

   In most active
     measurements, this document, the cause of packet loss focus is not distinguished.
     However, it on service providers as organizations
   requiring traffic and performance measurements.  (However, customer-
   based measurements of enterprise networks may be desirable have similar issues.)
   Service providers will make decisions on how to distinguish (e.g., by passive
     means) packet losses due perform the
   measurements needed, and there are various tradeoffs involved.  One
   option is to policing or obtain the measurements directly from the network congestion.  The
     former
   elements themselves, e.g., via SNMP.  Collecting the measurements on
   the operational network elements such as routers is sometimes a result
   performance concern.  Currently, there is a number of user violation third-party
   measurement/monitoring products available.  Hence, another option is
   to deploy such equipment, which might have performance advantages
   but also introduces additional cost.

   Regardless of service contract and the type of measurement source, either a network operator
   element or a third-party product, measurements should not be penalized for it.  The latter,
     whether intentional or unintentional, is caused by network
     conditions such collected,
   as buffer overflow, router forwarding process
     busy, and may not be the user's fault.  When policing is done far as possible, by a
     network, measurement of non-conforming packets at the edge
     provides an indication on the extent source without requiring
   coordination with other measurement sources.  Thus, it is desirable
   to which perform those measurements that do not require the network is
     carrying this type use of packets (which can potentially be dropped if
   specialized monitoring equipment connected to the network gets congested).  Loss due at
   multiple locations.  While each measurement source may act
   autonomously with regard to congestion taking measurements, a network operator
   may specify some network-wide policy regarding measurement
   scheduling.  Such policy may be, say, the use of any packets,
     including loss the same time of non-conforming packets, is a useful measure in
     traffic engineering to account for resource management.  (3) Long-
     term averages can be measured by
   day, the I.380/Y.1540 IP packet loss
     ratio same measurement interval, or by measurement intervals that
   are multiples of each other (e.g., nested intervals with
   synchronized boundaries).  A schedule therefore should include such
   time information as the IPPM Poisson sampling start, the duration, and periodicity of one-way loss.  However,
     during a
   certain measurement.  Also note that the accuracy of traffic
   measurement is highly dependent on the synchronization capabilities
   of the measurement devices that will be involved in the convergence times associated with routing updating, measurement
   procedures.  While synchronization issues are out of the
     loss may scope of
   this document, they should be high enough as to cause service unavailability.  This
     effect needs explicitly addressed whenever a
   measurement campaign is to be captured launched, whatever its scope and statistics such as loss patterns,
     burst loss, its
   frequency.

   The following measurement bases are considered in this document:
   . Flow-based
   . Interface-based, link-based, node-based
   . Node-pair-based
   . Path-based

   Passive measurements are prevalent today for TE purposes.  However,
   the above measurement bases may result in active or severe loss ratio passive
   measurements.  For example, an active measurement may be useful.

   . Resource usage, a two-point
   delay metric such as link/router utilization, buffer occupancy
     (e.g., fraction of arriving type-P-one-way-delay defined in [4], and
   obtained by time-stamping probe packets finding the buffer above at selected ingress and
   egress points; a
     given set passive measurement may be to obtain packet inter-
   arrival times by time-stamping successive packets of thresholds)
     Note:  (1) Depending on the architecture of traffic at
   a router, router
     utilization measurements may include processor and memory (e.g.,
     forwarding tables) utilization for each of selected point in the line cards and/or network.  Note that both active and passive
   measurements are subject to the central unit.  (2) Trigger points may be set when resource
     usage consistently exceeds a same sampling and time-source
   accuracy concerns.

   MPLS has certain threshold.

9.2 Entities related to establishment advantages when compared with conventional IP
   networks, from the perspective of connection or path

   Where connection admission control is used, a measurement entity for
   monitoring network performance may be the proportion difficulty involved in
   obtaining unambiguous measurements.  **As different service
   providers will adopt different technologies, technology-neutral
   solutions to the problem of connections
   denied admission.  Also, it may be useful obtaining measurements are needed as far
   as possible.**

   Applicability of traffic measurements to score the requested
   bandwidth within the derivation of traffic parameters for the setup request.
   Corresponding
   matrix statistics and performance monitoring has been described in
   Section 3.

A.1 Flow-based

   This is conceptually similar to the number of call attempts (i.e., peg count) detail record (CDR) in
   circuit-switched telecommunications networks, the number of connection requests, the
   number of flows, etc., may be measured networks.  It is primarily used
   on interfaces at access routers, edge routers, or aggregation
   routers, rather than on backbone routers in given read-out periods to
   characterize the traffic.

   To characterize paths core network.  Like
   CDR measurements, flow-based records are used to collect detailed
   information about a flow.  This includes such information as source
   and destination IP addresses/port numbers, protocol, type of
   service, timestamps for MPLS traffic engineering, the following
   measurement entities may possibly be defined: path setup delay, path
   setup error probability, path setup denial (blocking) probability,
   path release delay, path disconnect probability, path restoration
   time.  However, note start and end of a flow, packet count,
   octet count, etc.

   As flow is a fine-grained object, measuring every flow that path establishment passes
   through all the edge devices may not be dependent on
   routing and signaling protocols, in particular, whether preemption
   or fast-reroute restoration capability is used scalable or not. feasible.
   Hence,
   further investigation is per-flow data are usually used in a special study conducted
   on a non-continuous schedule and on selected routers only.  Sampling
   of flow-based measurements may also be needed to determine if reduce both the
   amount of data collected and how these
   measurement entities the associated overhead.

A.2 Interface-based, link-based, node-based

   While active measurements are to be defined.

10. Measurement Types

   A measurement matrix often not useful at a single point,
   passive measurements can be defined wherein each column represents a
   measurement basis and taken at each row represents a measurement entity.  An
   entry in this measurement matrix, corresponding network element.  For
   example, SNMP uses passive monitoring to a meaningful and
   measurable combination of collect raw data on an entity
   interface at an edge or backbone router.  These data are stored in
   MIBs (Management Information Bases) and a basis, defines a
   particular measurement type.  For each measurement type, there
   should be a set of measurement points specified to bound include counts on packets
   and octets sent/received, packet discards, errored packets.  Such
   measurements may have the network
   segment for disadvantage that the purposes identity of taking measurement.  A measurement point
   may be each
   flow is lost.

   To reduce the physical boundary overhead in managing multiple links between a node and an adjacent link, or the logical interface between two protocol layers same
   ingress and egress points, there is proposal to aggregate links for
   network optimization [36].  Component links in such a protocol
   stack.

10.1 Measurement types related to traffic or performance

   The following measurement matrix illustrates some of bundled link
   will have the measurement
   types related to traffic or performance.  Potentially, there can be
   one same routing constraints, resource classes, and
   attributes.  Multiple links are treated as a single IP link.
   Traffic measurements, such matrix for each service class.  Since this table is as bandwidth availability, throughput,
   etc., should consider the measurement implications for
   illustration purposes, it is bundled
   links, and should not necessary for inhibit link bundling.  (For example, a service provider single
   IP link may presumably be referenced as a pair of IP addresses that
   are assigned to
   implement all both extremities of the measurement types below.

            Bases:     Flow     Interface,   Node Pair      Path
                                   Node
  Entities:          (passive)   (passive)     (both)      (both)
  Traffic Volume        x(1)         x          x(3)        x(3)
  Avg. Hold. Time        x                                  x(3)
  Avail. Bandwidth                   x                      x(3)
  Throughput                                    x(4)        x(4)
  Delay                             x(2)        x(4)        x(4)
  Delay Variation                   x(2)        x(4)        x(4)
  Packet Loss                        x          x(5)        x(5)

   Notes:
   (1) This measurement type can link.  An implicit issue
   that may need to be used resolved relates to derive flow size
   statistics.
   (2) These are 1-point measurements.  For a discussion on 1-point
   packet delay variation, see [11], Appendix II.
   (3) As a starting point, statistics collected by passive measurement
   through the MIBs useful for exact characterization
   of the traffic engineering [21, 22, 23] that will be conveyed in each component link, since a
   couple of IP addresses may not be
   used.
   (4) sufficient for such link-based
   measurement.)  Also, such measurements should be protocol
   independent and media independent to ensure portability and
   commonality in the measurements.

A.3 Node-pair-based

   Active measurements based on IPPM metrics are currently by probing, as specified in use the IPPM framework
   for node-pairs; they may example, can be developed conducted between each pair of (major) routing
   hubs for paths.
   (5) Besides active determining edge-to-edge performance of a core network.
   This complements the passive measurements based on IPPM, path loss may
   possibly be inferred from of the difference between ingress previous sub-
   section, which provide local views of the performance of individual
   network elements.

   In contrast to performance statistics, traffic loading statistics
   require passive measurements of the actual traffic.  In circuit-
   switched telecommunications networks, each established call has an
   associated source/destination node-pair.  By maintaining a set of
   node-pair data registers [usage, call attempts (so-called "peg
   count" in telephony operation and egress management), overflow, etc.] in
   each switch, node-pair-based measurements for traffic statistics at the two endpoints of a path.  However,
   such
   inference for as the cumulative losses load between a given node pair over
   multiple routes may be less useful, since different routes may have
   different loss characteristics.

10.2 Measurement types related are taken directly.  In
   IP networks, currently such node-pair-based measurements are
   difficult to resource usage

   Another measurement matrix can be constructed for resource
   consumption.  This leads establish due to a set of measurement types comprising the different usage, one for each dynamic and asymmetric properties
   of IP routing.  However, it is possible to infer them from flow-
   based passive measurements and other network resource object information, such as
   router (processor and memory), link, and buffer,
   routing table snapshots.  A problem with this approach is that flow-
   based measurement data are voluminous.  Also, another problem that
   must be accounted for is the routing changes among the multiple
   routes due to, e.g., a change in the configuration of intra-domain
   routing, or a change in inter-domain policies made by different
   classes another
   autonomous system.  These issues were discussed in Section 3.4 on
   Traffic Matrix Statistics.

A.4 Path-based

   The ability of traffic:

   . control (e.g., MPLS to use fixed preferred paths for routing control) traffic
   . signaling traffic
   . user traffic from different service classes

                        Bases:   Node     Link    Buffer
           Entities:
           Control Util.           x        x        x
           Signaling Util.         x        x        x
           Service Class Util.     x        x        x

   The amount
   gives the means to develop path-based measurements.  This may enable
   the development of methodologies for such functions as admission
   control and signaling traffic carried by performance verification of delivered service.

   Like a network flow, a path is associated with a function pair of many factors.  To name nodes.  However,
   path is a few, they include the size
   and topology of the network, the control and signaling protocols
   used, more coarse-grained object than flow, as paths are usually
   used to carry aggregated traffic (from different flows).  In
   addition, when routing changes occur, the amount of user traffic carried, the number to be
   carried by a path will either not be affected or be merged with that
   of failure
   events, etc.  Also, flooding another path.  Because of link-state advertisement (LSA)
   messages in Interior Gateway Protocols (IGP, such as OSPF or IS-IS) these properties, path-based
   measurements are more scalable and may cause significant routing control traffic during events such as be used to provide more
   readily an LSA storm as a result accurate, network-wide, view of failures due to fiber cuts or failed
   power supply.  The above utilization measurements for control and
   signaling the traffic are intended to help develop guidelines for demands.  For
   example, the
   proper dimensioning and apportionment of network resources so that traffic between a given level pair of user nodes may be inferred
   from the aggregate of the traffic carried by all paths either
   terminated by or passed through the same node-pair.

APPENDIX B

B. Measurement Entities

   A measurement entity defines what is measured: it is a quantity for
   which data collection must be performed with a certain measurement.
   A measurement type can be adequately supported.  As specified by a (meaningful) combination of
   a measurement entity with the
   primary focus here measurement basis described in
   Appendix A.

   An important issue with any measurement is measurement precision
   and/or accuracy.  However, this issue is not dealt with here since
   each measurement type will potentially have its own unique
   requirements.  For example, see [4], Section 3.7, for a discussion
   on user error issues for one-way delay.

B.1 Entities related to traffic measurements, the additional
   needs and properties performance

   Some of control the measurement entities listed below, such as throughput,
   delay, delay variation, and signaling traffic measurements packet loss, are beyond related to the scope of this document.

11. Traffic Matrix Statistics

   An important set of data for traffic engineering is point-to-point
   respective IPPM performance metrics or point-to-multipoint demands.  This data may be of significant use
   in the provisioning of traffic-engineered intra-domain paths I.380/Y.1540 performance
   parameters.

   . Traffic volume (mean and
   external peering variance, in the existing network, as well as planning for
   the placement and sizing number of new links, routers, bits, bytes, or peers.

   In current practice, estimates
     packets transferred, as counted over a given time interval), on a
     per service class basis, at various aggregation levels (IP address
     prefix, interface, link, node, node-pair, path, network edge,
     customer, or autonomous system)
     Note:  (1) This is a measurement for the traffic demands are usually
   determined from carried by a combination of traffic projections, customer
   prescriptions, and service level agreements.  Under existing mode of
   operation,
     network, a network segment, or an individual network element; it
     is not easy used to obtain network-wide derive the carried load or carried traffic demands
   from intensity
     [37].  When measured during the local interface measurements taken by different IP routers.
   As explained in [24, 25], information from diverse network
   measurements and various configuration files are needed busy period, this entity is
     normally used to estimate the traffic offered.  However, the
     estimation procedure should take into account such factors as
     congestion, which may result in a decreased volume of carried
     traffic.  In addition, congestion may lead to infer the
   traffic volume.  Besides raw measurement data, additional
   information user behavior such
     as topological data and router configuration data
   are required reattempt or abandonment, which may affect the actual traffic
     offered.  (2) To reduce uncertainty in traffic estimation, second-
     order measures may need to obtain a network view.  Furthermore, destination-
   based IP routing and forwarding provides a network operator with
   primitive and limited control over be developed.  Beyond the routing use of traffic flows.
   This necessitates
     variance as in current practice, further study is needed for the association
     feasibility of a time sequence other second-order techniques.  (3) Measurement of forwarding
   tables from different
     traffic volumes over interconnecting links at border routers to reconstruct the different routes can
     be used by the network over time. By using this auxiliary information,
   together with flow-based measurements, the above-cited references
   describe how to determine estimate the traffic volume from exchange between peers for
     contract verification.

   . Average holding time (e.g., flow duration or lifetime, duration of
     an ingress link to MPLS path), on a set of egress links by validating and joining various data sets
   together.

   As described in Section 8.3, some shortcomings per service class basis
     Note:  (1) When MPLS TE is used, this is similar to call holding
     time in today's method telecommunications networks.  Call attempts, usage, and
     call holding time are three busy-hour entities that should be
     independently measured for both call-dependent and load-dependent
     engineering.  This is important especially when the call busy hour
     and the load busy hour during a day are non-coincident, due to
   derive traffic matrix the
     hour-to-hour variation of call holding times.  (2) The holding
     time statistics as above include the volume of data
   from flow-based measurement, long-living static paths reflect the lack effect of sufficient routing control
   information,
     network equipment failures, link outages, or scheduled
     maintenance, and the need to correlate data from a variety of
   sources.  The routing control offered by MPLS can hence may be used to avoid
   some derive information about up-
     time or service availability.  (3) It is desirable to be able to
     gather, by passive means, the up-time durations for each pair of these deficiencies.  To take advantage
     label bindings in the label-forwarding information base for labels
     distributed by different protocols (such as LDP, RSVP-TE, MP-BGP,
     or BGP).  Then, the derivation of this capability,
   path-based passive measurement should LSP average holding time does
     not need to be developed.  Furthermore, finely correlated with network events such as
   explained in Section 8.4 (Path-based Measurement Bases), by
   aggregating
     link/node failures.  (Note that routers measure only the appropriate set holding
     times, with their averages being typically computed offline.)

   . Available bandwidth of path-based traffic data, a link or path - useful for load balancing,
     measurement-based admission control to determine the
   corresponding node-pair-based traffic data feasibility
     of creating a new MPLS tunnel (real-time information can be obtained.  This
   will facilitate the derivation of traffic matrix statistics,
   possibly used
     for dynamic establishment)
     For more information on a available bandwidth see [38].

   . Throughput (in bits per service class basis.  Note that in second, bytes per second, or packets per
     second)
     Note:  (1) This is the case rate at which a given amount of
   hop-by-hop routed label-switched paths traffic
     excluding lost, misdelivered, or errored packets, that are established by Label
   Distribution Protocol (LDP) signaling, there is no explicit binding passes
     between path a set of end points, where end points.  This will result in the use points can be logically or
     physically defined.  The condition of different
   label bindings at both the ingress and egress nodes over time network, e.g., normal or
     high load, under which the measurement is taken should be noted.
     (2) The protocol level at which a throughput measurement is taken
     must be specified, as
   network topology changes.  Although the forwarding equivalence class
   (FEC) to label binding information already exists in packet payload and packet overheads are
     protocol dependent.  (3) The average packet size may be inferred
     from the MPLS FTN bit rate and LSR MIBs [26, 21], a mechanism packet rate measurements, when performed on
     the basis of an individual router.  This quantity is needed useful to keep track of
   binding changes.  An example of such a mechanism
     gauge router performance, since router operations are typically
     packet-oriented and small packets are more processing-intensive.

   . Delay (e.g., cross-router delay from node-based measurement may be the periodic
   exchange of FEC
     used to label binding information for each ingress-egress
   pair.

   Besides traffic engineering, measure queueing delay within a major application of MPLS is the
   support of network-based virtual private networks (VPNs).  A VPN router; end-to-end one-way
     or round-trip packet delay can be an enterprise network obtained by node-pair-based
     measurement)
     Note: The condition of the network, e.g., normal or a carrier's carrier network.  It is not high load,
     under which the purpose of this document to discuss VPNs.  However, it measurement is
   relevant taken should be noted.  This is
     useful to highlight the use of traffic determine if delay objectives are met.

   . Delay variation
     Note:  There are several methods to measure this quantity as
     specified in ITU-T and IPPM.  (1) In Y.1540, measurements to maintain
   proper engineering are
     defined for both 2-point and performance of MPLS tunnels in 1-point IP packet delay variation.
     However, 2-points methods are being specified as normative.  (2)
     In IPPM [9], the support concept of
   VPNs between VPN sites.  This would include also the support a selection function is introduced
     that allows for
   MPLS-based pseudo-wire connections as developed by the PWE3 Working
   Group [27]. explicit designation of selected packets whose
     one-way delay values are compared to compute one-way delay
     variation.  For example, path-based measurement by to define a network
   operator on behalf of the VPN customers facilitates the estimation method of measurement, a
     selection function can be specified to select the traffic offered by these VPNs.

12. Performance Monitoring

   General aspects of measurements required consecutive
     packets within a specified interval, or to support select the operation,
   administration, maximum and maintenance of
     minimum one-way delays within a network are outside the scope
   of this document (see [28, 29, 30] for specified interval.

   . Packet loss
     Note:  (1) While packet losses due to transmission and/or protocol
     errors may not be traffic related, unexpected excessive loss may
     be used as a discussion of MPLS OAM).
   The focus means of fault detection.  (2) In most active
     measurements, the measurements here cause of packet loss is only on operations related not distinguished.
     However, it may be desirable to
   traffic engineering and distinguish (e.g., by passive
     means) packet losses due to policing or network performance management.

   A major component of performance management congestion.  The
     former is performance
   monitoring, i.e., continuous real-time monitoring a result of the quality or
   health user violation of service contract and the
     network operator should not be penalized for it.  The latter,
     whether intentional or unintentional, is caused by network
     conditions such as buffer overflow, router forwarding process
     busy, and its various elements to ensure may not be the user's fault.  When policing is done by a
   sustained, uninterrupted delivery
     network, measurement of quality service.  This requires non-conforming packets at the use of measurement, either passively or actively, edge
     provides an indication on the extent to collect
   information about which the operational state network is
     carrying this type of the packets (which can potentially be dropped if
     network and gets congested).  Loss due to track
   its performance.  For a discussion congestion of passive monitoring and the use any packets,
     including loss of synthetic traffic sources non-conforming packets, is a useful measure in active probing, see [31].  Alarms
   may
     TE to account for resource management.  (3) Long-term averages can
     be generated when measured by the state of a network element exceeds
   prescribed thresholds.

   Performance degradation can occur as a result I.380/Y.1540 IP packet loss ratio or by the
     IPPM Poisson sampling of one-way loss.  However, during the
     convergence times associated with routing
   instability, congestion, updating, the loss may
     be high enough as to cause service unavailability.  This effect
     needs to be captured and statistics such as loss patterns, burst
     loss, or failure of network components.  Periods
   of congestion severe loss ratio may be detected when the resource usage useful.

   . Resource usage, such as link/router utilization, buffer occupancy
     (e.g., fraction of arriving packets finding the buffer above a network
   segment consistently exceeds a certain threshold, or when
     given set of thresholds)
     Note:  (1) Depending on the cross- architecture of a router, router delay is unexpectedly high.  Unexpected excessive loss
     utilization measurements may include processor and memory (e.g.,
     forwarding tables) utilization for each of the line cards and/or
     the central unit.  (2) Trigger points may be set when resource
     usage consistently exceeds a certain threshold.

B.2 Entities related to establishment of
   packets connection or throughput drops path

   Where connection admission control is used, a measurement entity for
   monitoring network performance may be used as a means the proportion of fault
   detection, and connections
   denied admission.  Also, it may result in restoration activities.

   Internet utilities such as ping and traceroute have been be useful to
   help diagnose network problems and performance debugging.  Utilities
   with similar functions would be essential score the requested
   bandwidth within the traffic parameters for path-oriented
   operations like in MPLS.  This would include the capability setup request.
   Corresponding to list,
   at any time, (1) for a given path, all the nodes traversed by it,
   and (2) for a given node, all number of call attempts (i.e., peg count) in
   telecommunications networks, the paths originating from it,
   transiting through it, and/or terminating on it.  A proposal for
   path tracing is described number of connection requests, the
   number of flows, etc., may be measured in [32].  A proposal given read-out periods to establish basic
   MPLS data plane liveness is described in [33].

13.
   characterize the traffic.

APPENDIX C

C. Packet Sampling and Estimation

C.1 Packet Sampling

   A wide spectrum of operational applications can be built on traffic
   measurement.  However, different applications usually require
   traffic measurements at different levels of temporal and spatial
   granularity.  To achieve an effective tradeoff between
   implementation complexity and the range of operational tasks to be
   enabled, a passive measurement framework based on packet sampling is
   proposed in [34]. [39].

   The use of packet sampling has two motivations.  First, the enormous
   volumes of traffic require that some form of data reduction to be
   used.  Second, simple data reduction by aggregation at the
   measurement point will not provide sufficiently detailed views for
   all network management applications or exploratory studies.  For
   this reason, packet sampling is proposed as a means to reduce data
   volume while still retaining representative detail.

   The primary aim of the proposal [34] [39] is to define a minimal set of
   primitive packet selection operations out of which all sampling
   operations that are necessary to support measurement-based
   applications can be composed.  Operations currently under
   consideration include filtering and statistical sampling, and also
   hash-based packet selection, a method that can be used to support
   the determination of spatial traffic flows across a domain [35]. [40].
   Whichever method is used, the interpretation of the stream of
   measurements arising from sampled packets must be both transparent
   and standard.  Other goals are to specify a means to format and
   export measurements, and a means to manage the configuration of the
   sampling and export operations.

   The proposal positions these functions to provide a basic packet
   sampled measurement service to higher level "consumers."  A typical
   consumer is a network management application that sits behind a
   remote measurement collector.  Such measurements can support
   applications for a number of tasks: troubleshooting, demand
   characterization, scenario evaluation and what-ifs.  Another type of
   consumer is a higher level on-router measurement application.  One
   potential class of examples is composite measurements (e.g., inter-
   packet delay statistics) formed from a number number of individual packet
   measurements.  Another class is network security applications, e.g.,
   IP traceback [41].  For some applications, the ability to have low
   latency between packet measurement and reporting will be
   particularly useful.

C.2 Sampling Issues

   The concept of read-out periods applies to both active and passive
   measurements.  This concept is consistent with the sampling issues
   for a series of measurements as developed in [2], for example.  See
   sections 10 and 11 of that document for important distinctions
   between "singletons, samples, and statistics."  The procedure of
   Poisson sampling, for example, may be used within a read-out period
   to select a subset of individual total packet
   measurements.  Another class is network security applications, e.g.,
   IP traceback [36].  For some applications, events that are chosen as the ability to have low
   latency between packet measurement and reporting will
   sample.  Then a statistic (e.g., mean or variance) can be
   particularly useful.

14. Statistical Estimation computed
   over that sample and Information Modeling

   This section deals associated with engineering methods in statistical
   estimation, as well the read-out period.  Although
   [2] does not discuss traffic volume measures such as a traffic
   matrix, the need for an information model and
   associated repository schema same sampling issues arise for the traffic matrix and
   other passive measurements.

14.1

C.3 Engineering methods for statistical estimation of measures

   The use of the well-established methods of optimal estimation [37,
   38, 39, 40] [42,
   43, 44, 45] to obtain estimates of the measures for TE is
   recommended.  This draws upon several facts:

   . Internet traffic is inherently band-limited, but non-stationary;
   . Internet traffic may be heavy-tailed and possess strong short-term
     correlations;
   . A stationary, band-limited process can be approximated arbitrarily
     closely by optimal estimation methods based on a finite number of
     past samples.

   Standard procedures for de-trending the raw data to provide "trend +
   stationary" decompositions should be adopted.  An example is the use
   of Autoregressive Integrated Moving Average (ARIMA) models, where
   first differences are applied to the raw (non-stationary) data,
   yielding a stationary derived process.  Then, the methods of optimal
   estimation can be applied in a practical setting (e.g., finite sample
   counts) to the derived stationary process to produce quality
   estimates of the measures defined herein.  As the original raw
   process may be any of the measurements discussed in this document,
   the above procedure may be applied without loss of generality to
   measures of delay, loss, or complex measures of network state such as
   path characteristics, etc.

   In addition, these methods need to be applied across multiple time-
   scales, so that TE applications can work with measures related to:
   . long-term trends over days, weeks, and months;
   . busy-hour characterizations; and
   . statistics and correlation properties on the order of seconds [41]. [46].

   The above estimation procedures apply equally to traffic workload,
   traffic performance, traffic workload,
   traffic performance, or other estimates of network state, such as the
   state of routes.

APPENDIX D

D. Read-Out Periods

   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
   minimize the amount of data to be collected, and to condense the
   collected data by periodic summarization over read-out periods.

D.1 Data Reduction

   Techniques to manage large volumes of measured data are needed to
   prevent network performance from being adversely affected by the
   unnecessarily excessive loading of router control processors, router
   memories, transmission facilities, and the administrative support
   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 other estimates to aggregate flows into suitable classes with the
   corresponding aggregation of network state, such statistics.  These types of data
   reduction may be used as an appropriate or acceptable means for
   pruning down the
   state overall volume of routes.

14.2 traffic data that a TE Measure Information Modeling

   An information model system may
   ultimately have to store, maintain, and process.

D.2 Measurement Interval

   A measurement interval is valuable for organizing data generated
   through the estimation process.  Measures time interval over which measurements
   are taken.  Some traffic data must be associated with collected continuously, while
   others by sampling, or on a
   large, scheduled basis.  For example, peak
   loads and sometimes complicated set of attributes (e.g., as simple
   as an IP address of a peak periods can be identified only by continuous
   measurement point, or as complex as traffic typically fluctuates irregularly during the path of
   a round-trip measurement).  Information models exist that richly
   describe network elements
   whole day.  If traffic variations are regular and their configuration [42].  These models
   have been extended predictable, it
   may be possible to include policy mechanisms [43].  Specifications
   for flows have been developed for network resource allocation
   purposes [44].  No centralized information model exists that can
   completely describe many measure the expected normal load on pre-
   determined portions of the TE measures defined herein.
   Therefore, necessary integrating information models day.  Such duration of peak traffic is
   referred to as a busy period.  Special studies on selected segments
   of the network may be conducted on a scheduled basis.  Occasionally
   unexpected events or other decision support needs may arise that make maximal
   reuse
   require ad-hoc, unscheduled measurement, with the involvement of pre-existing work the
   network operator, and in such a case measurements may need to be developed activated
   manually.  For instance, active throughput measurement may be used
   to identify alternate routes for TE measures.

   As a brief example spreading traffic to avoid future
   periods of the limitations network congestion, based on observations of current
   local congestion events.

D.3 Summarization

   A measurement interval consists of existing information models,
   consider RFC 1363 [44] as a model for sequence of consecutive read-
   out periods.  Summarization is usually done by integrating the raw
   data over a traffic flow. pre-specified read-out period.  The granularity of this
   period must be suitably chosen.  It can should be
   described as collection of attributes defining traffic offered load,
   performance short enough to be delivered (a goal), and the assurance level (risk)
   associated
   capture, with acceptable accuracy, the bursty nature of the traffic,
   i.e., the actual performance obtained.  The traffic offered
   load is specified via an envelope described by a token bucket concept
   (token bucket rate, bucket size) variations and peaks.  Since measurements
   represent a maximum transmission rate.

   This model, while clearly intended load for description of what a network
   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
   and size y with probability 0.999."  Note router (if third-party measurement devices
   are not employed), the read-out period should not be so short that
   router performance is degraded while a probability
   statement must be added to complete the characterization.  This type voluminous quantity of specification data
   is known as (sigma, rho) in the literature. produced.   Also,
   note that adopting such an information model for flows lacks any
   flexibility to specify time scale, or more detailed second-order
   statistics.

   Similar limitations exist with respect to delivered performance
   specification in RFC1363, and read-out may be started when the text of measured data
   exceeds a preset threshold, or when the RFC is quick to point
   out, space allocated for example, that
   temporarily holding the "loss model data in a router is crude." exhausted.

   For these reasons, a multi-service IP network, each service typically has its own
   traffic characteristics and others, an appropriate information model is performance objectives.  To ensure that
   CoS-specific features are reflected in the measurement process,
   different read-out periods may be needed for TE
   measures that can support uniformity different classes of data definition in subsequent
   TE applications.

   Several approaches and options
   service.

APPENDIX E

E. Time Scales for repository technology are now
   broadly discussed.  Relationships between TE measure Network Operations

   The information
   models collected by traffic measurement can be provided to
   the end user or application either in real time, or for record
   (i.e., data retention) in non-real time, depending on other information models (e.g., the COPS Policy Information
   Base, PIB) that drive network outcomes are of particular importance.
   For an example of a PIB, see [45].

   Linkages may need activities
   to be considered between policy mechanisms and TE
   measures.  This is useful because, while policy-driven networking is
   well-developed between the policy repositories, policy decision
   points performed and policy enforcement points, policy content is very likely the output of TE applications [46].  Since TE applications are
   dependent upon TE measures, it is advantageous network actions to provide
   traceability between the measures be taken.  Traffic
   control will generally require real-time information.  For network
   planning and the engineering changes made capacity management as
   a consequence of them.  An example of a client application that might
   be driven by TE measures through a PIB is found in [47, 48].

   Measures (represented by their estimates) should described below, information may
   be centrally stored
   and collected in a logical sense.  This does not preclude distributed
   storage for purposes provided in non-real time after the processing of volume management or security/survivability,
   but alludes raw data.

   Broadly speaking, the following three time scales can be classified,
   according to the need for a consistent retrieval mechanism (e.g.,
   NFS).  Two methods are: (1) extend MIBs with new definitions use of observed traffic information for TE
   measure estimates, and (2) create data depositories through more
   centralized facilities, such as PIB repositories network
   operations [14].

   Network planning
   Information that can be accessed
   via LDAP (see [45]).  Both methods have merits changes on the order of months is used to make
   traffic forecasts as collection
   processes for TE measures, and are simple examples spanning a wide
   spectrum of solutions.  These two methods are discussed here basis for
   expository purposes, not to exclude other solutions.

   Using MIBs allows well-established SNMP protocol network extensions and related
   applications to retrieve data from the long-term
   network elements being
   measured.  This is inherently "vendor-neutral," allowing commonly
   defined TE measurements configuration.  That is, for planning the topology of the
   network, planning alternative routes to survive failures or
   determining where capacity must be stored for retrieval augmented in a common MIB
   definition, regardless advance of network element vendor, technology projected
   traffic growth.  Long-term planning includes the selection and
   timing of the introduction of new architectures, technologies and
   vendors, in alignment with financial forecasts and market
   assessments.

   Capacity management
   Intermediate-scale (e.g., six months or other
   differences.  Measurements from individual network elements
   (interfaces, routers, etc.) can be obtained "locally," if measures
   from a single network element are sufficient for a given TE
   application.  However, if less) capacity planning
   deals with detailed implementation of the build plan, short-lead-
   time activities and out-of-plan events.  It typically uses a network-wide view
   rolling-month forecast of traffic and demand.  Information that
   changes on the measurements is
   desired, the drawback order of a MIB-based approach days or hours is that the data must
   be retrieved from each element over used to manage the network.  As experience
   attests, this approach sometimes generates significant SNMP traffic,
   and during periods of high congestion (when measurements deployed
   facilities, by taking appropriate maintenance or engineering actions
   to optimize utilization.  For example, new MPLS paths may be quite
   important) SNMP set up
   or existing paths modified while meeting service level agreements.
   Also, load balancing may not reliably fetch the measurement data. Finally,
   a MIB-based approach be performed, or traffic may be difficult to implement rerouted
   for various two-
   point measurements, such as end-to-end, or round-trip delay and delay
   variation.  Such measurements are not related to re-optimization after a single failure.

   Real-time network
   element, and somewhat heuristic practices (e.g., storing end-to-end
   delay measurements in MIBs located control
   Information that changes on source address elements, etc.)
   are required.

   An LDAP repository approach centralizes the data storage.  This has the advantage that TE applications (such as offline and online TE, order of minutes or
   measurement-based admission control) can less is used to
   adapt to the current network conditions in near real time.  Thus, to
   combat localized congestion, traffic management actions may perform
   temporary rerouting to redistribute the load.  Upon detecting a
   failure, traffic may be performed, and policy
   database content diverted to pre-established, secondary
   routes until more optimized routes can be updated without invasive retrieval arranged.

APPENDIX F

F. Use of data
   from network-wide MIBs.  Further, traceability can be established
   between the TE measurements in an LDAP repository, Traffic Measurement for Traffic control

   Destination-based per-hop IP routing and the associated
   policy content derived from them.

   It is possible that both the MIB-based forwarding provides a
   network operator with primitive and LDAP-based (or another
   approach altogether) should be considered jointly.

   Although this document focuses on limited control over the motivation for providing routing
   of traffic measurement information, it is assumed that this information
   should be provided to the participating devices flows.  The routing control offered by means of a
   communication protocol that would MPLS can be used between
   to avoid some of the aforementioned
   participating devices and a presumably centralized entity that would
   aim at storing, maintaining and updating deficiencies of IP routing.  In this information, as well
   as making appropriate decisions at the right time and under various
   conditions.

   This communication protocol should have the following
   characteristics:

   1. The protocol should make context, a
   primary use of a reliable transport mode, given traffic measurement is to engineer the importance use of configuration information.
   2. The protocol architecture should provide a means label-
   switched paths to achieve service goals for dynamically
   provisioning the configuration information network.

   Examples of traffic control are:
   . Adaptively optimizing network performance in response to the participating
   devices, so that it may introduce/contribute network
     events, e.g., rerouting to work around congestion or failures.
   . Providing a high level of
   automation feedback mechanism in the reverse flow messaging of
     RSVP-TE [47] or CR-LDP [48] signaling in MPLS to report on actual traffic measurement operation.
   3. The protocol should support
     topology state information such as link bandwidth availability.
     (An example of such a reporting feedback mechanism that may be
   used for statistical information retrieval.

   4. The protocol is described in [49];
     however, care should support the appropriate security mechanisms be exercised to provide some guarantees as far as the preservation ensure network stability and
     consistency for any mechanism that makes direct operational use of
     measurement.)
   . Support of measurement-based admission control, adaptive resource
     management, or other techniques, e.g., by predicting the
   confidentiality future
     demands of the configuration information is concerned.

15. Conclusions and Recommendations

   This document is intended as a framework for traffic metrics needed
   for successful TE.  Principles aggregate of best practice in traffic
   characterization and performance characterization are described.
   For interoperable compatibility, basic areas existing flows so that admission
     decisions can be made on new flows.

   An example of traffic measurement
   recommended for standardization include:

   (1) Specific TE measurements

   . Use of node-pair-based used to enable a traffic data control
   mechanism is to configure policing mechanisms in response to derive per-service-class traffic matrix statistics
   . Statistics of carried
   load versus and performance
   . measurements.  A standardized mechanism network operator could
   selectively throttle low-priority flows to detect improve near-real-time
   performance of higher-priority flows, and record label binding
     changes for LDP-signaled label-switched paths, maintain tighter QoS
   envelopes.  Another example would be to facilitate the
     collection of node-pair-based traffic data

   (2) Traffic data collection methods

   . Need for uniform use measurement definitions across vendors and
     operators
   . Distinction between traffic offered load versus achieved
     throughput
   . Need for higher-order statistics for service assurance
   . Need results for packet-sampled measurements that preserve representative
     traffic detail at manageable sample volumes
   . Need
   feedback into IGP routing decisions, e.g., for offline bulk file transfer and standardized
     filtering/aggregation mechanisms to manage large volumes of
     measured traffic data adjusting the link
   weights based on them.

16. Security Considerations

   The principles and concepts related to Internet traffic measurement
   as discussed in this document do not by themselves affect the
   security of the Internet.  However, it is assumed that any
   measurement systems that are developed or deployed by a service
   provider are responsible for providing sufficient data integrity
   (e.g., to prevent forgery of measurement records) and
   confidentiality (e.g., by restricting attention only to the packet
   headers of interest).  It is also assumed that a service provider
   will take proper precautions to ensure that access to its
   measurement systems and all associated data is secure by using
   appropriate authentication techniques.  Methods to achieve these
   security considerations are not addressed in this document.

17. References
   Normative References

   References 1, 2, and 13 34 below are considered normative.

   Informative References

   1  D.O. Awduche, A. Chiu, A. Elwalid, I. Widjaja, and X. Xiao,
      "Overview and Principles of Internet Traffic Engineering," RFC
      3272, May 2002.
   2  V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for IP
      Performance Metrics," RFC 2330, May 1998.
   3  J. Mahdavi and V. Paxson, "IPPM Metrics for Measuring
      Connectivity," RFC 2678, September 1999.
   4  G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay Metric
      for IPPM," RFC 2679, September 1999.
   5  G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Packet Loss
      Metric for IPPM," RFC 2680, September 1999.
   6  G. Almes, S. Kalidindi, and M. Zekauskas, "A Round-trip Delay
      Metric for IPPM," RFC 2681, September 1999.
   7  M. Mathis and M. Allman, "A Framework for Defining Empirical Bulk
      Transfer Capacity Metrics," RFC 3148, July 2001.
   8  R. Koodli and R. Ravikanth, "One-way Loss Pattern Sample
      Metrics," RFC 3357, August 2002.
   9  C. Demichelis and P. Chimento, "IP Packet Delay Variation Metric
      for IP Performance Metrics (IPPM)," RFC 3393, November 2002.
   10 V. Raisanen, G. Grotefeld, and A. Morton, "Network performance
      measurement with periodic streams," RFC 3432, November 2002.
   11 H. Uijterwaal and M. Kaeo, "One-way Metric Applicability
      Statement," Internet-Draft, Work in Progress, November 2002.
   12 ITU-T Recommendation I.380/Y.1540, "Internet Protocol Data
      Communication Service -- IP Packet Transfer and Availability
      Performance Parameters," First Issued February 1999, Revised
      December 2002.
   12 ITU-T Recommendation Y.1541, "Network Performance Objectives for
      IP-Based Services," May 2002.
   13 E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label
      Switching Architecture," RFC 3031, January 2001.
   14 S. Bradner (Editor), "Benchmarking Terminology ITU-T Recommendation Y.1541, "Network Performance Objectives for Network
      Interconnection Devices," RFC 1242, July 1991.
   15
      IP-Based Services," May 2002.
   14 G. Ash, "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM-
      Based Multiservice Networks," Internet-Draft, Work in Progress,
      October 2001.
   16 D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G.
      Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209,
      December 2001.
   17 B. Jamoussi (Editor), "Constraint-Based LSP Setup using LDP," RFC
      3212, January 2002.
   18 P. Ashwood-Smith, B. Jamoussi, D. Fedyk, and D. Skalecki,
      "Improving Topology Data Base Accuracy with Label Switched Path
      Feedback in Constraint Based Label Distribution Protocol,"
      Internet-Draft, Work in Progress, November 2002.
   19 K. Kompella, Y. Rekhter, and L. Berger, "Link Bundling in MPLS
      Traffic Engineering," Internet-Draft, Work in Progress, February
      2001.
   20 W.S. Lai, "Traffic Measurement for Dimensioning and Control of IP
      Networks," Internet Performance and Control of Network Systems II
      Conference, SPIE Proceedings, Vol. 4523, Denver, Colorado, 21-22
      August 2001, pp. 359-367.
   21 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.
   22 C. Srinivasan, A. Viswanathan, and T.D. Nadeau, "Multiprotocol
      Label Switching (MPLS) Traffic Engineering Management Information
      Base," Internet-Draft, Work in Progress, January 2002.
   23 K. Kompella, "A Traffic Engineering MIB," Internet-Draft, Work in
      Progress, September 2002.
   24
   15 A. Feldmann, A. Greenberg, C. Lund, N. Reingold, J. Rexford, and
      F. True, "Deriving Traffic Demands for Operational IP Networks:
      Methodology and Experience," Proc. ACM SIGCOMM 2000, Stockholm,
      Swedan.
   25
   16 A. Feldmann, A. Greenberg, C. Lund, N. Reingold, and J. Rexford,
      "NetScope: Traffic Engineering for IP Networks," IEEE Network,
      March/April 2000.
   26
   17 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.
   27 P. Pate, X. Xiao, T. So, A. Malis, T. Nadeau, S. Bryant, C.
      White, K. Kompella, M. Morrow, G. Swallow, and T. Johnson, "Framework D. Allan, " OAM
      Requirements for Pseudo Wire
      Emulation Edge-to-Edge (PWE3)," MPLS Networks," Internet-Draft, Work in Progress,
      June 2002.
   28
      Progress.
   18 N. Harrison, P. Willis, S. Davari, E. Cuevas, B. Mack-Crane, E.
      Franze, H. Ohta, T. So, S. Goldfless, and F. Chen, "Requirements
      for OAM in MPLS Networks," Internet-Draft, Work in Progress, May
      2001.
   29

   19 ITU-T Draft Recommendation Y.1710, "Requirements for OAM
      Functionality for MPLS Networks," May 2001.
   30
   20 ITU-T Draft Recommendation Y.1711, "OAM Mechanisms for MPLS
      Networks," May 2001.
   31
   21 S. Waldbusser, R.G. Cole, R. Dietz, C. Kalbfleisch, and D. Romascanu, "A
      Framework "An
      Introduction to the RMON Family of MIB Modules," Internet-Draft,
      Work in Progress, Jan 2003.
   22 C. Kalbfleisch, R.G. Cole, and D. Romascanu, "Definition of
      Managed Objects for Synthetic Sources for Performance Monitoring," Monitoring
      Algorithms," Internet-Draft, Work in Progress, May 2001.
   32 Sept 2002.
   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 R. Bonica, K. Kompella, and D. Meyer, "Tracing Requirements for
      Generic Tunnels," Internet-Draft, Work in Progress, August 2002.
   25 K. Kompella, P. Pan, N. Sheth, D. Cooper, G. Swallow, S. Wadhwa,
      and R. Bonica, "Detecting MPLS Data Plane Liveness," Internet-
      Draft, Work in Progress, October 2002.
   26 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.
   27 C. Srinivasan, A. Viswanathan, and T.D. Nadeau, "Multiprotocol
      Label Switching (MPLS) Traffic Engineering Management Information
      Base," Internet-Draft, Work in Progress, January 2002.
   28 K. Kompella, "A Traffic Engineering MIB," Internet-Draft, Work in
      Progress, September 2002.
   29 R. Yavatkar, D. Pendarakis, and R. Guerin, "A Framework for
      Policy-based Admission Control," RFC 2753, January 2000.
   30 D. Rawlins, A. Kulkarni, M. Bokaemper, and K.H. Chan, "Framework
      for Policy Usage Feedback for Common Open Policy Service with
      Policy Provisioning (COPS-PR)," Internet-Draft, Work in Progress,
      December 2002.
   31 C. Jacquenet, "An IP Forwarding Policy Information Base,"
      Internet-Draft, Work in Progress, January 2003.
   32 C. Jacquenet, "A COPS client-type for IP traffic engineering,"
      Internet-Draft, Work in Progress, January 2003.
   33 S. Sen and J. Wang, "Analyzing Peer-to-Peer traffic Across Large
      Networks," Internnet Measurement Workshop, 2002.
   34 E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label
      Switching Architecture," RFC 3031, January 2001.
   35 S. Bradner (Editor), "Benchmarking Terminology for Network
      Interconnection Devices," RFC 1242, July 1991.
   36 K. Kompella, P. Pan, N. Sheth, D. Cooper, G. Swallow, S. Wadhwa, Y. Rekhter, and R. Bonica, "Detecting L. Berger, "Link Bundling in MPLS Data Plane Liveness," Internet-
      Draft,
      Traffic Engineering," Internet-Draft, Work in Progress, October 2002.
   34 February
      2001.
   37 W.S. Lai, "Traffic Measurement for Dimensioning and Control of IP
      Networks," Internet Performance and Control of Network Systems II
      Conference, SPIE Proceedings, Vol. 4523, Denver, Colorado, 21-22
      August 2001, pp. 359-367.

   38 M. Jain and C. Dovrolis, "End-to-End Available Bandwidth:
      Measurement Methodology, Dynamics, and Relation with TCP
      Throughput," Proc. ACM SIGCOMM'2002, August 19-23, 2002,
      Pittsburgh, Pennsylvania.
   39 N.G. Duffield (Editor), "A Framework for Passive Packet
      Measurement," Internet-Draft, Work in Progress, September 2002.
   35
   40 N.G. Duffield and M. Grossglauser, "Trajectory Sampling for
      Direct Traffic Observation," IEEE/ACM Trans. on Networking, 9(3),
      pp. 280-292, June 2001.
   36
   41 C. Partridge, C. Jones, D. Waitzman, and A. Snoeren, "New
      Protocols to Support Internet Traceback," Internet-Draft, Work in
      Progress, November 2001.
   37
   42 S. Haykin, Ed., "Kalman Filtering and Neural Networks," Wiley
      Interscience, 2001.

   38
   43 A. Papoulis, "Probability, Random Variables and Stochastic
      Processes," 3rd Ed., McGraw-Hill, 1991.
   39
   44 A. Gelb, Ed., "Applied Optimal Estimation," MIT Press, 1974.
   40
   45 I. R. Petersen, V. A. Ugrinovskii, A. V. Savkin, "Robust Control
      Design Using H<\infinity> Methods," Springer, 2000.
   41
   46 V. Bolotin, J. Coombs-Reyes, D. Heyman, Y. Levy, and D. Liu, "IP
      Traffic Characterization for Planning and Control," Proc. ITC16,
      Edinburgh, Scotland, June 1999.
   42 Distributed Management Task Force (DMTF) Common Information Model
      (CIM), www.dmtf.org
   43 B. Moore, E. Ellesson, and J. Strassner, "Policy Core Information
      Model -- Version 1 Specification," RFC 3060, February 2001.
   44 C. Partridge, "A Proposed Flow Specification," RFC 1363,
      September 1992.
   45 R. Yavatkar,
   47 D. Pendarakis, Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and R. Guerin, "A Framework G.
      Swallow, "RSVP-TE: Extensions to RSVP for
      Policy-based Admission Control," LSP Tunnels," RFC 2753, 3209,
      December 2001.
   48 B. Jamoussi (Editor), "Constraint-Based LSP Setup using LDP," RFC
      3212, January 2000.
   46 2002.
   49 P. Ashwood-Smith, B. Jamoussi, D. Rawlins, A. Kulkarni, M. Bokaemper, Fedyk, and K.H. Chan, "Framework
      for Policy Usage Feedback for Common Open Policy Service D. Skalecki,
      "Improving Topology Data Base Accuracy with
      Policy Provisioning (COPS-PR)," Internet-Draft, Work in Progress,
      December 2002.
   47 C. Jacquenet, "An IP Forwarding Policy Information Base,"
      Internet-Draft, Work Label Switched Path
      Feedback in Progress, January 2003.
   48 C. Jacquenet, "A COPS client-type for IP traffic engineering," Constraint Based Label Distribution Protocol,"
      Internet-Draft, Work in Progress, January 2003. November 2002.

18. Intellectual Property Statement

   AT&T Corp. may own intellectual property applicable to packet
   sampling as presented in references [34, 35] [39, 40] and summarized in
   Section 13.
   Appendix C.1.  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

   Thanks to the inputs from Gerald Ash, Jim Boyle, Robert Cole,
   Enrique Cuevas, Ruediger Geib, Christian Jacquenet, Merike Kaeo, Ed
   Kern, Spyros Kontogiorgis, Alfred Morton, Thomas Nadeau, Dimitri
   Papadimitriou, Moshe Segal, Jing Shen, Bert Wijnen, Raymond Zhang,
   and the Scampi and Tequila
   project. projects.  Special thanks to Blaine
   Christian for starting this work and contributing to the initial
   versions.  Nick Duffield provided
   section 13 Appendix C.1 on packet sampling.

20. Author's Addresses
   Wai Sum Lai
   AT&T Labs
   Room D5-3D18
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1 732-420-3712
   Email: wlai@att.com

   Richard W. Tibbs
   Oak City Networks & Solutions
   304 Harvey St.
   Radford, VA 24141, USA
   Phone: +1 540 639 2145
   Email: drtibbs@oakcitysolutions.com

   Steven Van den Berghe
   Ghent University/IMEC
   St. Pietersnieuwsstraat 41
   B-9000 Ghent, Belgium
   Phone: ++32 9 267 35 264 99 86
   E-mail: steven.vandenberghe@intec.rug.ac.be steven.vandenberghe@intec.ugent.be

Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.