Thực hiện chất lượng dịch vụ trong các mạng IP (P7)

This chapter deals with themeans of monitoring service quality, the analysis methods applied to measurement data, and examples of network performanceoptimization based on processed measu

Measurements

NOIAYTON (Know thyself; Inscription on the fa¸cade of Apollo’s temple in Delphi)

The traffic engineering process for IP networks includes obtainingfeedback from the network as the basis of assessing the need

to modify transport network parameters and to optimize itsbehaviour Obtaining information in precise and meaningful form

is imperative for being able to make the right adjustments toimprove the network performance This chapter deals with themeans of monitoring service quality, the analysis methods applied

to measurement data, and examples of network performanceoptimization based on processed measurement information

A formulation of the goals and methods of traffic engineeringmeasurements in IP networks has been given in a recent Inter-

to the topic in this chapter, quoting other sources and addingissues specific to multi-service networks as necessary In the draft,ISPs are singled out as one likely user for the methods presented.The scope of the conceptual framework development therein isintra-domain operations, but the definitions are intended to betransferable also across operator domain boundaries As such,

Implementing Service Quality in IP Networks Vilho R¨ais¨anen

 2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

they should be applicable to different per-domain technologies aswell The need for consistency, precision and effectiveness of trafficengineering methods is cited as the reason for applying an over-arching framework for traffic engineering The ultimate goal ofmeasurements is to serve the needs of the traffic engineering pro-cess, including forecasting, planning, dimensioning, control, andperformance monitoring.

The major tasks of traffic engineering measurements are defined

• traffic characterization;

• network monitoring;

• traffic control

These will be discussed in more detail later in this chapter Let

us note in passing again that in multi-service networks, the acterization, monitoring, and traffic control tasks may need to beapplied to multiple traffic aggregates on individual links

char-Three approximate timescales pertaining to the use of data

• Months or longer This timescale relates to network planning and

upgrading Forecast traffic volumes per service class are tant here

impor-• Hours to days Capacity management is the primary use of

mea-surement data at these timescales Meamea-surement data could beused to control default routing of traffic aggregates and resourceallocation in network nodes

• Minutes or less This timescale belongs to real-time control of the

traffic aggregates to circumvent congestion is cited

As we shall see later, measurements dealing with differenttimescales have different requirements and analyses associatedwith them Some general requirements for measurements are:

• Accuracy in capturing important phenomena at different timescales.

The shortest timescale of relevance to network performance

on the timescale of interest must be known and themeasurement methods should be chosen accordingly In a multi-service network, the required accuracy may be different for

7.1 TRAFFIC CHARACTERIZATION 213

different traffic aggregates For example, millisecond-accuracymeasurements for delay may be desirable for VoIP, but notnecessary for best-effort traffic

• Network performance should not be degraded by measurements This

applies both to the elements being measured as well as the effect

of measurements and transferring of measurement data to thenormal operation of a production network Interestingly, this

is an issue not only for active measurements but passive ones

as well

• The amount of data generated should be moderate.

Regarding the last two points, these issues are typically morechallenging in a multi-service network than in a best-effortnetwork, since there may be multiple quality support aggregatesinvolved for each link Subsequently, both performing the actualmeasurements and transmitting measurement data in such a way

as not to interfere with the normal network operation need to becarefully planned

Next, we shall take a look at the three tasks of traffic engineering

and then will discuss the definition of measured characteristics,sources of information, measurement methods, and the requiredmeasurement infrastructure in general The present chapter will

be concluded with case studies

Traffic characterization is the first task of traffic engineering

• Identifying variations in traffic patterns using statistical analysis,including development of traffic profiles to capture daily,weekly, or seasonal variations

• Determining traffic distributions in the network on the basis offlows, interfaces, links, nodes, node-pairs, paths, or destinations

• Estimation of the traffic load according to service classes indifferent routers and the network

• Observing trends for traffic growth and forecasting of trafficdemands

The determination of traffic distributions in the network is partlyrelated to the estimation of traffic matrix discussed in Chapter 4.

In other words, direct measurement can be used to obtain thetopological distribution of traffic in the network However, per-link volumes need to be linked to traffic aggregates entering andexiting the network domain in order to influence the distributionwith routing control

For a best-effort IP network domain, traffic pattern variationsmay relate to changes in the composition of protocol types in thetotality of traffic, as well as information about traffic volumes intopological context In multi-service networks, such informationshould be available per service quality support aggregate

In a multi-service network with service mapping ontoservice quality support aggregates on the network edge, trafficengineering benefits from the ability to compare characterizations

of both incoming service types and service quality supportaggregates, side by side Such a comparison makes it possible toeffectively evaluate the suitability of both the service/aggregatemapping at the network edge, and the service quality support foraggregates in the network core (see Figure 7.1)

Depending on the measurement methods, discussed in moredetail below, modelling of data may be needed to interpretthe results in a context relevant for traffic engineering Formodelling, the alternatives are fitting of measurement resultsinto an existing model and providing generic modelling formeasurement results without reference to the use context Incertain situations modelling has a risk associated with it, since

it makes assumptions about what the results should look like.Thus, when modelling is used, consistency checks should beconstructed to check that the situation in the measured network

ER

Service distribution

Traffic load for service support aggregates

Figure 7.1 Modelling both incoming services at the network edge and loads of service quality support bearers in the network core

7.1 TRAFFIC CHARACTERIZATION 215

is consistent with the assumptions made in the model Anotheruseful technique is computation of the same characteristics usingmultiple different methods

but non-stationary; traffic can be heavy-tailed and have strongcorrelations at short timescales This is often the case in best-effort Internet with no per-flow policing The suggestion of theInternet draft is to use decomposition of measurement resultsinto stationary and trend parts Obviously the stationary partalso needs to account for diurnal variations in traffic intensity.Regarding the scope of this book, this breakdown should bepossible per service quality support aggregate A more fine-grained temporal classification of the problem area of trafficdecomposition could be as follows:

• trend prediction (days or longer periods of time) This timescale

is relevant for capacity management in traffic engineering

• busy-hour traffic characterization;

• statistics and correlation at the timescale of seconds

The reported measurement data should be associated withinformation on the scale of applicability, partly stemming fromthe details of the actual measurement This requirement is validirrespective of the possible use of modelling as a part of themeasurement An example used in the cited draft, modelling offlow burstiness can be performed by fitting measurement resultsinto a token bucket model as the probability that a flow can

be accommodated by the token bucket, as estimated from ameasurement The result, in general, can be dependent on thelength of the measurement period Thus, a full description ofmeasurements in this case is as follows:

• token bucket rate;

• token bucket depth;

• probability;

• timescale of applicability

The timescale is of importance especially when dealing with similar traffic patterns, where the average magnitude of variationsranges with the length of the observation period

• Monitoring the continuity and quality of network services,

to ensure that service quality objectives are met fortraffic aggregates Further, goals include verification of theperformance of delivered services

• Evaluating the effectiveness of traffic engineering policies,

or triggering certain policy-based actions (such as alarmgeneration, or path pre-emption) upon threshold crossing; thismay make use of past performance data, in addition to latestmeasurement results

• Verifying peering agreements (SLAs) between service providers

by monitoring/measuring the traffic flows over interconnectinglinks at border routers This includes the estimation of inter-and intra-network traffic, as well as originating, terminating,and transit traffic that are being exchanged between peers.Performance monitoring, meaning continuous monitoring ofthe performance of network elements to ensure that theyare performing correctly, is a central part of performancemanagement Possible reasons for suboptimal service performanceinclude route flapping, congestion, hardware or software failures,and element misconfiguration

In a multi-service network domain, the above goals need to beimplemented for the different service quality support aggregates.This sets higher requirements for the measurement infrastructure.For example, one needs to be able to detect the malfunctioning

at the granularity of individual service quality support classes.Similarly, the triggering of traffic engineering actions needs towork reliably in the multi-service case

Obtaining data for various subtasks of network monitoring is atrade-off between the number of different measurement types andaccuracy for individual monitoring purposes It is clearly desirable

to derive multiple levels of performance characteristics from asingle set of measurement data, if the methods for performing thisare known and sufficient processing power for this is available.Alas, both conditions are not always found Especially for new

7.2 NETWORK MONITORING 217

types of services, the analysis methods for obtaining servicequality description may not yet be available If services need to becreated quickly for commercial reasons, the very act of configuringmeasurements using low-level data sources may be too time-consuming and it may be easier to perform using separate service-level measurements Later, when the behaviour of the network

is understood better and on more quantitative level, the specific performance data can possibly be extracted from a smallernumber of measurements

service-The scheduling of measurements is part of the networkmonitoring task One important concept here is the temporal

distance between successive measurements, known as the out period The length of the read-out period should be sufficiently

read-short to prevent momentary variations from being averaged out,but long enough to avoid disturbing the router In a multi-service network, the measurement scheduling periods need totake into account different service quality support types Formeasurements directly addressing the service level performance of

a particular service support aggregate, the actual lengths of out periods may be different from each other For measurements,the results of which are used for assessing the performance

read-of multiple types read-of services, on the other hand, the length

of the read-out period may be determined by the strictestreporting requirement

An important part of network monitoring is presenting themeasurement data within the right context Taking the load as

an example, in a simple routed IP network, load levels might

be collected per link, out of which a meaningful traffic matrixneeds to be constructed If MPLS is in use, however, also loadlevels per LSP are of interest If a single LSP is shared by multipletraffic aggregates, load levels per DSCP/LSP combination would

be useful information for traffic engineering purposes A routercan belong to multiple such contexts As an example, an MPLS-capable DiffServ router could perform monitoring both per LSP,

as well as per network interface

7.2.1 Troubleshooting measurements for services

Troubleshooting-type measurements for service quality can beused as necessary to complement data from normal “traffic

engineering” type measurements Troubleshooting measurementscan be based on testing the actual service performance eitherusing realistic protocols is an emulation of application stream,

or otherwise measuring the quality of a traffic aggregateused as a bearer for applications Application emulation – typetroubleshooting measurements can be performed end-to-end, per-domain, or narrowed down on smaller areas to identify potentialproblem locations For non-end-to-end measurements, one needs

to be careful in interpreting the measurement results in terms

of impact on end-to-end performance, as has been discussed inChapter 5

Making an ICMP PING test for a route or for a LSP is an example

of a simple test of the ability of an aggregate to transfer any data.Such tests could be carried out periodically to verify the opera-tional status of routes or LSPs

An example of an application emulation troubleshooting surement is transmission of emulated VoIP stream between twolaptops, and measuring delay time series and packet loss charac-teristics from the stream The emulation produces correct streammetrics (packet sizes and transmission intervals can be chosen

mea-to correspond mea-to a realistic codec) and uses the same four est OSI layers for the measurement stream as a VoIP applica-tion (UDP/IP/LL/PHY) As with active measurements in general,ICMP PING and traceroute may not yield correct delays due topossibly different PDU treatment in routers for ICMP and L3+traffic Keeping in mind the related discussion in previous chap-ters, all measurements also take into account the possible effects

low-of measurement endpoints

An example of an end-to-end test is verifying the signalling formance of a SIP proxy by using a SIP client, which is able to timethe individual signalling events In this case, provided that theendpoints (client and SIP proxy) are operating correctly, such a testshows an example of the effect of network performance to end-to-end application performance Similarly, assessing end-to-end VoIPperformance could be based on transmission of reference samplesover the network using actual VoIP terminal applications havinghooks to provide application-level performance characteristics

per-A possible set-up and its relation to traffic engineering surements in a domain are illustrated in Figure 7.2 The serviceflow emulation measurements can be made on the same route

mea-as the traffic engineering memea-asurements, but may be expressly

SIP proxy Terminal

Testing of signalling performance

Terminal Testing of voice quality

Figure 7.2 Traffic engineering measurements (left) and different types of troubleshooting-type measurements (right)

designed to test the performance relevant to the tested tion An example of this is performing active measurements with

applica-20 ms inter-packet separation to probe timescales of performance,which are relevant for the AMR codec

The third task of traffic engineering measurements, traffic control,

is related to interfacing of the control part of traffic engineering

subtasks are:

• Adaptively optimizing network performance in response to work events Rerouting around points of congestion or failure

net-in the network is given as example of this

• Providing a feedback mechanism in the reverse flow messaging

of RSVP-TE or CR-LDP signalling in MPLS to report on actualtopology state information such as link bandwidth availability

• Support of measurement-based admission control, i.e., by dicting the future demands of the aggregate of existing flows sothat admission decisions can be made on new flows

pre-The examples listed above relate to routing control and admissioncontrol means of service quality control More generally, theexamples are partly overlapping with activities in the trafficengineering process, which take measurements as input Routingcontrol above is an example of this Another example could be us-ing measurements for triggering configuration optimization and

reconfiguration of DiffServ parameters in the network elementsusing policy management Other aspects of traffic control, asexemplified by the list above, fall within shorter timescales thanwhat is relevant for the entire measure-model-reconfigure loop.Direct measurement-based feedback to admission control is anexample of such shorter timescale processes.

Further examples of traffic control include:

• Triggering of reconfiguration of policing at the network edge

• Adjustments of link costs in link-state routing protocols based

on measurements This requires a management interface to linkcost computation in routers

The first of these two examples is more clearly within the cation of the traffic engineering loop, requiring configuration ofmultiple network elements The reaction to a certain set of mea-surement results could still be preconfigured, avoiding the need

appli-to perform a full modelling step Some aspects of dynamic fic control falling within the concept of bandwidth brokers arediscussed in the following chapter

traf-It should be noted that in traffic control, modelling of system

level behaviour is needed The means for this have been discussed

in Chapter 5 Modelling of system behaviour should be contrasted

with modelling of data in the traffic characterization task, the latter

providing input for the former

The measured characteristics, in all, span multiple scopes Ageneral goal of Service Level Agreements, the characteristicsshould be to use system-level characteristics that are independent

of protocols and platforms, and be uniform across operator

Per-Domain Behaviours [RFC3086] mentioned in the last chapter Morefine-grained characteristics are needed for detailed performanceinformation

The classification used in this chapter is as follows: tics can be measured at service level, packet or traffic aggregatelevel, or with network element granularity Examples of charac-teristics at each of these levels are given below

characteris-7.4 DEFINITION OF MEASURED CHARACTERISTICS 221

• Service level:

– Service availability and continuity.

– Average holding time Typically computed for a flow at the

net-work edge Holding time of certain types of long-lived serviceinstances may also reflect network reliability

– Service response time This is also relevant for individual

ser-vice instances

The above service level characteristics can be measured directly,when passive monitoring of production streams is feasible andtechnically possible Service-specific data can also be obtained fromappropriate service elements An example of the latter could bequerying SIP proxy for information about call statistics When theSIP proxy is outside of the network operator’s domain, delivery

of such information could be part of the Service Level Agreement.Service response time can also be estimated with application-levelmeasurement, in which case modelling may be necessary

• Packet/aggregate level:

– Bandwidth availability Can be used for traffic control using

mul-tiple routes for a single traffic aggregate, measurement-basedadmission control (MBAC), or adjusting admission control orservice quality support instantiation policy, for example

sustainable rate of packet transfer with which the service ity support objectives are met with

qual-– Delay One-way or two-way measurements are possible for

active measurements, two-point sampling using passive itoring for non-encrypted flows with sequence numberspossible

mon-– Delay variation Different measurements possible (one-point

vs two-point) [RFC3432, I.380]

– Packet loss Depends on the protocol layer Some of the loss

for non-SLA-conformant packets may arise at network edge

– Statistics on erroneous PDUs.

Model-based measurements may be useful in this category in imizing measurement overhead, provided that the effect of fittingthe results into a model on the results is properly understood

min-• Network element/link level

– Traffic volume The share of offered traffic for the measured

entity minus the effect of network condition, congestion, andother effects

– Resource usage Link utilization, buffer occupancy, CPU load,

and memory usage

– Traffic aggregate level statistics.

Measurement results in this category are obtained by direct polling

of elements or by a reporting interface to the measuring device(network element or probe) In multi-service environment, resultsfor multiple traffic aggregates per network interface are typicallyneeded

Measured characteristics are called entities in the terminology of

service-level characteristics

Characteristics being statistical in nature, only estimates can

be obtained, as discussed in [SMH01] When the dynamics andthe characteristics of the associated phenomena are well enoughknown, model-based measurements can enhance the accuracy ofthe estimators

Physically, measurement data can be obtained from network ments and measurement probes Network elements, in turn, can

ele-be IP or link layer devices such as routers, or service elements such

as HTTP servers or SIP proxies For a transport network operator,direct access to all service elements is not always possible, butservice usage information could be included into a SLA

Let us next attempt to make overview of the measurement faces The interfaces will be discussed in more depth in Section 7.6.From the network elements, data can be fetched using a vendor-proprietary interface (for example, command line interface), or astandardized interface such as Simple Network Management Pro-tocol (SNMP) The data available in the network element can be in

inter-7.5 SOURCES OF MEASUREMENT DATA 223

the form of proprietary counters, or standard MIBs The cation between the management system and network element can

communi-be based on polling of the elements by the management systems,and on elements sending SNMP trap messages to the managementsystem in predefined conditions

Probes can be of an active or passive type, the former ing production traffic in the network, the latter transmitting probestreams in the network The Remote Monitoring (RMON) MIB[RFC2819] is a possible interface with regard to passive probes, notrequiring constant connection between the probe and the manage-ment system IETF is also currently in the process of standardizingthe IP flow information exporting protocol that could be useful forthis purpose For active probes and two-point passive measure-ments, standardization work is ongoing

monitor-7.5.2 Measured characteristics

Typical examples of measured characteristics are given below:

• Element-specific For example, CPU loads.

• Packet statistics Lengths of packets, number of packets,

cor-rupted packets For passive monitoring, also the time the packetwas received

• Flow Source and destination addresses, port numbers,

proto-cols, time of start and end of a flow, packet count, IP version(IPv4/IPv6) When the application flows are encrypted, obtain-ing of some of the information may be limited

• Traffic aggregate Example characteristics are per-aggregate buffer

occupancy levels, offered traffic and goodput, and packet lossstatistics

• Service event Example characteristics include end availability,

user identity, invocation time, and service-specific parameters

• Per link Relevant characteristics include overall link utilization

statistics and packet loss rate

• Per node pair Delay, delay variation, packet loss, packet loss

correlation

relating measured characteristics (entities) and measured objects(bases) is given there

Some of the measurement types require information that is tained by combining per-element or per-probe measurement data

ob-Table 7.1 Relation of measured characteristics and measured objects Bases

Entities

Flow (Passive)

Interface, node (Passive)

Node pair (Active &

passive)

Path (Active & passive)

(2) These are one-point measurements.

(3) As a starting point, statistics collected by passive measurement through the MPLS traffic engineering MIBs may be used.

(4) Active measurements based on IPPM metrics are currently in use for node-pairs; they may be also applied to paths, but without means of controlling the routing no one-to- one correspondence necessarily exists.

(5) Besides active measurements based on IPPM methodologies, path loss may possibly

be inferred from the difference between ingress and egress traffic statistics at the two endpoints of a path However, such inference for the cumulative losses between a given node pair over multiple routes may be less useful, since different routes may have different loss characteristics Also, loss of even one source (network element) of packet loss information along the measured path results in incorrect statistics on the domain level.

In service level elements, relevant counters depend on the vice in question Typical generally interesting characteristics are

ser-• total number of service requests per measurement period;

• number of successful service requests per measurement period;

• number of non-successful service requests per measurementperiod;

• CPU load of the service element

MIB support for service depends on service details Some aspects

of application performance measurements have been specified in[RFC2564]

7.6 MEASUREMENT METHODS 225

Service level measurements can be performed per service type,

or per service quality support aggregate In the latter case, themeasurement with a selected service type probes the performance

of the service quality support aggregate Measuring per servicetype end-to-end provides results, which are easiest to relate to enduser experience When the network operator is providing servicequality support in the form of aggregates, most likely aggregatelevel measurements are used

Different measurement methods were enumerated in the context

of traffic engineering earlier Let us take another look at them now,from the point of view of what is being measured Higher-levelperformance characterizations can be obtained by combining per-element data, possibly using some sort of system modelling inthe process

A subset of IP-level characteristics can be available in any IPdevice such as a router, depending on the set of counters available.The palette of available characteristics (and counters) may depend

on the operating environment of the device – indeed, it is the basicidea of DiffServ to keep complex per-flow operations at the edge

of the network

Service-level characteristics, on the other hand, may be able from service support elements such as HTTP servers or SIPproxies, provided that the element has suitable counters and mea-surement interfaces.

avail-The second method, devices reporting predefined conditionsbeing met in the network elements, again requires adequate coun-ters to be present in the network elements, in addition to theability to locally monitor the status of these counters and detectingwhen the predefined condition has been met The condition can

be related to the measured characteristics, or to clock reading, forexample

In addition to counters relating to the monitored characteristics,

a representation of measurement information (information model)

is required The representation can be vendor-specific, or dard such as a MIB developed for that purpose Obviously, anopen standard interface reduces dependency from a single vendor.There may be special circumstances where it is not meaningful todevelop a standard MIB or PIB, however

stan-Second, an interface between the performance monitoring entityand the network element is required The polling interface can

be vendor-specific, or standards-based, the latter including SNMPand COPS The notification interface can be based on SNMP traps,COPS, or vendor-specific protocol interface The assumptionsbehind the SNMP notification model may not always be valid.The counters possibly need to be activated by a managementsystem, and may have parameters to be configured, such as con-stants used in computing a moving average The managementinterface for configuring normal counters can be vendor-specificCLI, SNMP or COPS, for example In the case of notifications, alsoconditions need to be configured, which can be expressed in theform of rules

Finally, a schedule for reading out the counters from networkelements is needed for the polling scheme The scheduling ofcounter read-outs may depend on diurnal and weekly variations

of traffic Traffic volumes and element loading due to polling need

to be checked, especially when multiple performance monitoringentities are polling the routers for information

In the case of notifications, a configuration interface is needed, fordefining the condition triggering the notification, and for specifyingthe receiver of the notification Resiliency considerations may lead

to specifying back-up receivers if the primary target is unavailable

in question and on the aggregation level The capability of forming such an inference may be limited due to factors such asencryption, and may be ethically and/or legally problematic fromprivacy viewpoint.

per-The actual monitoring can be performed in two basic ways:

1 Using link interface device counters in a network element such

as an IP router

2 Using a separate device for monitoring link status In somecases, the device can be as simple as a FreeBSD or Linux hostrunning suitable analysis application using raw socket interfacetowards the link

Again, both polling and notification interfaces are in general sible, depending on the link layer hardware

pos-The central issues relating to being able to use counters of work elements have been dealt with in Section 7.6.1 If flow orservice-based monitoring needs to be performed on an IP device,additional processing capacity as well as the relevant data storageand data export capabilities and interfaces may be needed.When separate devices are used for monitoring a link, the hard-ware performance of the network interface device may need to

net-be non-trivially high in case it is used for operations ing individual flows in links of high capacity When flow andservice-based monitoring is performed, the information modelsand configuration system must be suitable for using this kind ofinformation, and need to be able to cope with potentially largeamounts of data per time unit

concern-Link monitoring may not be always active In this case, ing of monitoring and the means of activating and deactivating

schedul-measurements need to be defined Activation of schedul-measurements can

be performed in a centralized way, or by defining the ment schedule in actual network elements The explicit activation

measure-of a particular measurement type may be triggered by other surements, or be performed because of other traffic engineeringreasons The configuration of scheduled measurements could beperformed using a suitable interface towards elements that havethe necessary capability

mea-7.6.3 Monitoring a route or node pair

Monitoring of a route can relate to packet, flow, traffic aggregate,

or service level characteristics At least the following methods arepossible here:

• Querying service elements Certain kinds of service elementsknow the endpoints of the service events, and may have infor-mation about routing of individual service instances and serviceevents If this does not uniquely pin down the routing, rout-ing table monitoring information can be used to supplementthe data

• Performing two-point link or element monitoring and ing the results

combin-• Performing one-point monitoring supplemented with routinginformation

• Active measurements on the route

For actual service instantiation on a route, using data obtainedwith querying service elements probably yields the best results.For monitoring traffic using a traffic aggregate two-point mon-itoring is probably the most reliable method The data obtainablewith this method are subject to the potential limitations mentioned

be used, depending on the stability of routing

For monitoring service quality support of traffic aggregates, activemeasurements are a viable option These are especially useful formeasuring delay, delay variation, and packet loss statistics relat-ing to a traffic aggregate The use of two-point link monitoring

7.6 MEASUREMENT METHODS 229

for these purposes requires that there is at least one stream in themonitored traffic aggregate which has sequence numbers stampedonto its packets This is the case for non-encrypted RTP streams,for example Measurement of delay is technically challenging withtwo-point monitoring only, as the arrival times of packets in thetwo points need to be recorded very accurately Additionally, theproperties of the measurement stream can usually be defined moreprecisely for active measurements than for a randomly monitoredstream Active measurements can be used to test whether a route or

an LSP is operational Active measurements can be measurements

of statistics of the traffic aggregate (delays, packet losses, etc.), orcan emulate the actual service instances, including at least a part

of the protocol stack used by real applications A few examples areprovided in Table 7.2

The management tasks related to monitoring of a route includeselection of endpoints for the measurement, and possible scheduling

of measurements For active and two-point link monitoring, routeselection involves two actual measurement entities The entities can

be “measurement agents”, that is, pieces of software in network ments For service element querying, and one-point measurementschemes, the endpoint selection may be more akin to data mining

ele-As with link monitoring, the scheduling can be done by the ing entities themselves or by the centralized performance monitor-ing system

measur-Table 7.2 Examples of active measurement types

Service quality

support aggregate

performance

Poisson-distributed transmission of packets.

Defined by IPPM working group.

Periodic streams Defined by IPPM working

group.

ICMP ping Results may differ from

application performance.

Service emulation HTTP query

Emulation of VoIP media stream