[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

IP Performance Measurement (ippm)                            B. Trammell
Internet-Draft                                                ETH Zurich
Intended status: Informational                                  L. Zheng
Expires: August 18, 2014                                          Huawei
                                                                S. Silva
                                                                  LACNIC
                                                              M. Bagnulo
                                                                    UC3M
                                                       February 14, 2014


                 Hybrid Measurement using IPPM Metrics
                    draft-trammell-ippm-hybrid-ps-01

Abstract

   Hybrid measurement is the combination of metrics derived from passive
   and active measurement to produce a measurement result.  This
   document discusses use cases for hybrid measurement using metrics
   defined within the IPPM framework, and discusses requirements for the
   definition of passive methodologies for selected IPPM metrics.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 18, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Trammell, et al.         Expires August 18, 2014                [Page 1]


Internet-Draft             Hybrid Measurement              February 2014


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   Hybrid measurement is the combination of metrics derived from passive
   and active measurement to produce a measurement result.  This
   combination can be either spatial or temporal.  For example, one way
   delay to a given endpoint could be derived from passive measurements
   from a sample of remote endpoints with which traffic is frequently
   exchanged, and supplemented with active measurements from endpoints
   with less frequent traffic, to build a "delay map" to a certain point
   in the network.  On the temporal side, loss or delay metrics could be
   passively measured and stored over time to provide a baseline against
   which actively-measured loss or delay metrics could be compared
   during troubleshooting, in order to determine whether a specific path
   or path segment is contributing to an observed performance problem.

   The IPPM working group has produced a framework [RFC2330] for and
   rich set of well-defined metrics (e.g. [RFC2679], [RFC2680]) for IP
   performance measurement using active methods, and protocols for
   measuring them.  These metrics could form the basis of a platform for
   hybrid measurement, provided that passively-derived metrics were
   defined to compatible with the corresponding actively-derived
   metrics; or alternately, provided that methodologies for passive
   measurement can be defined for each of the existing active metrics to
   be used, such that those methodologies produce values for the metrics
   equivalent to the active methodology for the same metric parameters,
   given some assumptions about the packet stream to be observed to
   perform the passive measurement, and given tolerances for uncertainty
   in the results.

2.  Problem Statement

   Complicating the definition of hybrid measurements is that passive
   measurement must make do with the traffic that is observable, while
   active measurement has some control over the traffic observed.
   Measurements for some set of parameters are not possible if no
   suitable traffic is observed, and the timing of the measurement
   cannot be controlled.  Placement of the observation points for
   passive measurement along a path additionally introduces uncertainty
   in the results.  For example, passive one-way delay measurement could
   be performed using two measurement points, one close to each
   endpoint, with synchronized clocks, comparing the observation times
   of packets via their hashes.  This will not produce a value which is



Trammell, et al.         Expires August 18, 2014                [Page 2]


Internet-Draft             Hybrid Measurement              February 2014


   directly comparable to a Type-P-One-way-Delay measured as specified
   in section 3.6 of [RFC2679], because it will not account for the one-
   way-delay from the source to the source-side observation point, or
   from the destination-side observation point to the destination.  Any
   specification of hybrid measurement using IPPM metrics must handle
   these complications.

   The proposed specification entails:

   o  Definition of scenarios and requirements for hybrid measurement.

   o  Selection of existing IPPM metrics to be used for the active side
      of hybrid measurements to meet these requirements.

   o  Definition of equivalent passive measurement methodologies for
      each selected metric, specifically addressing the assumptions
      about the observed packet stream which must hold for the metric to
      be valid, and with a specific allowance for the measurement and/or
      estimation of uncertainty due to uncontrollable conditions or
      observation point placement.

   o  Definition of metrics based on these passive methodologies, or
      modification of the definition of existing metrics to add passive
      methodologies.

   o  Definition of methods for comparison between active and passive
      metrics allowing for estimated uncertainty.

   o  Definition of methods for spatial and temporal composition of
      active and passive metrics together allowing for estimated
      uncertainty.

3.  Selected IPPM Metrics

   [EDITOR'S NOTE: this section will contain information on the metrics
   selected for passive measurement, and initial discussion of passive
   measurement methodologies for them.  Metric definition will
   presumably be left for a future document.]

3.1.  Packet Loss

   In order to perform packet loss measurements on a live traffic flow,
   different approaches exist.  An approach is to count the number of
   packets sent on one end, and the number of packets received on the
   other end.  Packet loss over a path is the difference between the
   number of packets transmitted at the starting interface of the path
   and received at the ending interface of this path.




Trammell, et al.         Expires August 18, 2014                [Page 3]


Internet-Draft             Hybrid Measurement              February 2014


3.1.1.  Passive Measurement Method

   In order to count the number of packets sent and received and to
   compare two counters, it is required that the two counters refer
   exactly to the same set of packets.  One difficulty is it is hard to
   determine exactly when to read the counter since a flow is
   continuous.  A possible solution is to virtually split the flow in
   consecutive blocks by periodically inserting a delimiting packet, so
   that each counter refers exactly to the same block of packets.
   However, delimiting the flow using specific packets requires
   generating additional packets within the flow and requires the
   equipment to be able to process those packets.  In addition, the
   method is vulnerable to out of order reception and the loss of
   delimiting packets.

   An existing method by "coloring" IP packets for performance
   measurement is introduced in [I-D.tempia-opsawg-p3m].  This "colored"
   based approach doesn't use delimiting packets.  Instead, it "colours"
   the packets so that the packets belonging to the same block will have
   the same "colour", while consecutive blocks will have different
   colours.  Each change of colour represents a sort of auto-
   synchronization signal that guarantees the consistency of
   measurements taken by different devices along the path.

3.2.  One-way Delay

   IPPM has defined a protocol for active one way delay measurement
   OWAMP in [RFC4656] It consists of a control protocol for negotiating
   measurement sessions and a data plane protocol for test packets.
   OWAMP is an active protocol meaning that the one delay is measured
   for artificial packets the are generated for this purpose.

   It would be natural to pursue passive and/or hybrid approaches for
   measuring one way delay.  In this case, the goal would be to measure
   one way delay for packets that are flowing through the network.  This
   can be achieved by defining two observation points that will record
   the packets they see and the corresponding timestamps.  This
   information will be used to determine the one way delay of the
   observed packets, similarly than in the active measurement approach.
   In order to do that, it is necessary to identify which packets are
   the ones that the measurement will be performed with.  One way to do
   this is to define a certain flow of packets and then record some
   fields of the packets that are unlikely to change during its journey
   through their journey between the observation points.  One the
   packets have been properly identified, and the timestamp information
   about them has been recorded in the observation points, it should be
   possible to calculate the one way delay for the observed packets.




Trammell, et al.         Expires August 18, 2014                [Page 4]


Internet-Draft             Hybrid Measurement              February 2014


   If defining a passive metric for one way delay is deemed interesting,
   it would be then needed to perform a gap analysis for the additional
   protocols that are needed for this.  As the passive approach would
   also need to negotiate measurement sessions, it may be worth
   exploring the re use of OWAMP for this.  Similarly, both observation
   points should agree what packet flow will be used for the
   measurement, so additional negotiation is needed.  Finally, IPFIX
   could be used to report the results so that the actual delay can be
   calculated.

   An additional exercise that would be then relevant is to understand
   how comparable are measurements obtained through the active and
   passive measurements.  In particular, depending on the packet
   frequency, it may or may not be possible to achieve the different
   packet streams available in active measurements.

   A hybrid approach for measuring one way delay seems attractive as it
   would be possible to measure reliably one way delay reusing the
   packets available in the network when they exist and generating
   artificial traffic when they don't exist.  This requires careful
   consideration in order to obtain the desired packet streams and it is
   likely to require additional control protocol to specific the hybrid
   measurement.

3.3.  Round-trip Delay

   Round-trip delay is used to measure the expected time for network
   interaction between two hosts on a network; conceptually, it is
   equivalent to Delay in each direction between the two hosts.

   Active measurement of round-trip delay as defined in [RFC2681]
   requires the observation of test packets transmitted in both
   directions between two endpoints across a network, a "source" host,
   which sends the first packet, and a "destination" host, which
   receives the first test packet and sends a test packet back to the
   source in reply.  The round-trip delay is then calculated as the
   difference between the time at which the reply is received at the
   source and the time at which the original test packet was sent from
   this same source.

   IPPM has defined the Two-Way Active Measurement Protocol (TWAMP)
   [RFC5357] for round trip delay measurement.  TWAMP is essentially an
   extension of OWAMP for the IPPM round-trip delay metric.  Like OWAMP,
   TWAMP consists of a control protocol to negotiate active performance
   measurement sessions, and a test protocol for transmission of actual
   test packets.





Trammell, et al.         Expires August 18, 2014                [Page 5]


Internet-Draft             Hybrid Measurement              February 2014


   TWAMP is defined for active performance metrics, which means that the
   Round-trip delay is measured for packets the are generated
   specifically for this purpose.

3.3.1.  Passive Measurement Method

   The passive approach for measuring Round-trip delay would consist on
   measuring this delay for existent packets in contrast with the active
   approach in which test packets are generated.  Similarly to the
   method used for measuring One-way Delay, for Round-trip Delay it
   would be needed to define two observation points that will record the
   packets they see and the corresponding timestamps.

   The procedure for passive measurement of round-trip delay is similar
   to the procedure for active measurement: a packet sent from a source
   to a destination is recorded; that packet causes the destination to
   send a reply back to the source.  This reply is also recorded.  The
   packets are identifiable at the source in order to correlate each
   packet of the round trip in order to calculate a delay.

   There are two potential architectures here; one utilizing a source
   Observation Point (OP) placed topologically close to the source of
   traffic, and one utilizing an additional destination OP placed
   topologically close to the destination of traffic.

   In order to be able to measure the Round-trip Delay of the observed
   packets, it would be necessary to identify which packets will be used
   to perform the measurement.

4.  Methodology

   For certain performance metrics, many passive measurement
   methodologies may exist.  This section give the fuctional reqirements
   and design considerations of the passive measurement methodology.

4.1.  Measurement Session Management

   A measurement session refers to the period of time in which
   measurement for certain performance metrics is enabled over a
   forwarding path.  When an interface on the measurement node is
   activated, the interfaces start collecting statistics.  When both the
   upstream and downstream measurement interfaces are activated, the
   measurement session starts.  During a measurement session, data from
   two active interfaces are periodically collected and the performance
   metrics, such as loss rate or delay, are derived.  A measurement
   session SHOULD be started either proactively or on demand.





Trammell, et al.         Expires August 18, 2014                [Page 6]


Internet-Draft             Hybrid Measurement              February 2014


4.1.1.  Measurement Configuration

   A measurement session can be configured statically.  In this case,
   network operators activate the two interfaces or configure their
   parameter settings on the relevant nodes either manually or
   automatically through agents of network management system (NMS).
   Alternatively, a measurement session can be configured dynamically.
   In this case, an interface may coordinate another interface on its
   forwarding path to start or stop a session.  Accordingly, the format
   and process routines of the measurement session control packets need
   to be specified.  The delivery of such packets SHOULD be reliable and
   it MUST be possible to secure the delivery of such packets.

4.2.  Measurement Result Report

   Performance reports contain streams of measurement data over a period
   of time.  A data collection agent MAY actively poll the monitoring
   nodes and collect the measurement reports from all active interfaces.
   Alternatively, the monitoring nodes might be configured to upload the
   reports to the specific data collection agents once the data become
   available.  To save bandwidth, the content of the reports might be
   aggregated and compressed.  The period of reporting SHOULD be able to
   be configured or controlled by rate limitation mechanisms.

4.3.  Synchronization

   During a measurement session, data from the active upstream and
   downstream interfaces are periodically collected and the performance
   metrics are derived.  Certain synchronization mechenism is required
   to ensure the data are correlated.  This may further requires that
   the upstream and downstream interfaces having a certain time
   synchronization capability (e.g., supporting the Network Time
   Protocol (NTP) [RFC5905], or the IEEE 1588 Precision Time Protocol
   (PTP) [IEEE1588].)  For packet delay measurement, this requirement
   for time synchronization is already present.

4.4.  Scalability

   The measurement methodology MUST be scalable.  A service provider
   production network usually comprises of thousands of nodes.  Given
   the scale, the collecting, processing and reporting overhead of
   performance measurement data SHOULD NOT overwhelm either monitoring
   nodes or management nodes.  The volume of reporting traffic should be
   reasonable and not cause any network congestion.







Trammell, et al.         Expires August 18, 2014                [Page 7]


Internet-Draft             Hybrid Measurement              February 2014


4.5.  Robustness

   The measurements MUST be independent of the failure of the underlying
   network.  For example, the correct measurement result SHOULD be
   generated even if some measurement coordinating packets are lost;
   invalid performance reports should be able to be identified in case
   that the underlying network is undergoing drastic changes.  If
   dynamic measurement configuration is supported, the delivery of
   measurement session control packets SHOULD be reliable so that the
   measurement sessions can be started, ended and performed in a
   predictable manner.

4.6.  Security

   The measurement methodology MUST not impose security risks on the
   network.  For example, the monitoring nodes should be prevented from
   being exploited by third parties to control measurement sessions
   arbitrarily, which might make the nodes vulnerable for DDoS attacks.
   If dynamic configuration is supported, the measurement session
   control packets need to be encrypted and authenticated.

5.  Security Considerations

   [EDITOR'S NOTE: this section will discuss general security
   considerations of using passive measurement for performance, both on
   the potential for attacks against the measurement system as well as
   the potential for privacy or security threats posed by the
   measurement system itself.]

6.  IANA Considerations

   This document contains no considerations for IANA.

7.  References

7.1.  Normative References

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330, May
              1998.

7.2.  Informative References

   [I-D.tempia-opsawg-p3m]
              Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda,
              "A packet based method for passive performance
              monitoring", draft-tempia-opsawg-p3m-04 (work in
              progress), February 2014.



Trammell, et al.         Expires August 18, 2014                [Page 8]


Internet-Draft             Hybrid Measurement              February 2014


   [RFC2679]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
              Delay Metric for IPPM", RFC 2679, September 1999.

   [RFC2680]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
              Packet Loss Metric for IPPM", RFC 2680, September 1999.

   [RFC2681]  Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
              Delay Metric for IPPM", RFC 2681, September 1999.

   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protocol
              (OWAMP)", RFC 4656, September 2006.

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, October 2008.

Authors' Addresses

   Brian Trammell
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   Email: trammell@tik.ee.ethz.ch


   Lianshu Zheng
   Huawei Technologies
   China

   Email: vero.zheng@huawei.com


   Sofia Silva
   LACNIC
   Uruguay

   Email: sofia@lacnic.net










Trammell, et al.         Expires August 18, 2014                [Page 9]


Internet-Draft             Hybrid Measurement              February 2014


   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes
   Spain

   Email: bagnulo@it.uc3m.es












































Trammell, et al.         Expires August 18, 2014               [Page 10]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/