Skip to main content

Hybrid Two-Step Performance Measurement Method
draft-mirsky-ippm-hybrid-two-step-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Greg Mirsky , Wang Lingqiang , Guo Zhui
Last updated 2018-02-27
Replaced by draft-ietf-ippm-hybrid-two-step
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-mirsky-ippm-hybrid-two-step-00
IPPM Working Group                                             G. Mirsky
Internet-Draft                                                 ZTE Corp.
Intended status: Informational                              W. Lingqiang
Expires: August 31, 2018                                         G. Zhui
                                                         ZTE Corporation
                                                       February 27, 2018

             Hybrid Two-Step Performance Measurement Method
                  draft-mirsky-ippm-hybrid-two-step-00

Abstract

   Development of and advancements in automation of network operations
   brought new requirements toward measurement methodology.  Among them
   is ability to collect the instant telemetry as the packet being
   processed by the networking elements along its path through the
   domain.  This document introduces new hybrid measurement method,
   referred to as hybrid two-step, as it separates act of measuring and/
   or calculating performance metric from the act of collecting and
   transporting telemetry.

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 https://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 31, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Mirsky, et al.           Expires August 31, 2018                [Page 1]
Internet-Draft               Hybrid Two-Step               February 2018

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Problem Overview  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Successful resolution of challenges of automated network operation,
   as part of overall life-cycle service orchestration, relies on
   collection of accurate and timely information that reflects the state
   of network elements on unprecedented massive, even grandiose scale.
   Because analysis and action upon the it requires considerable
   computing and storage resources, the network state information, also
   referred to as telemetry, is unlikely to be processed by network
   elements themselves but will be relayed into data lakes.  The process
   of producing telemetry information, collecting and transporting it
   for post-processing should equally work with data flows and specially
   inserted in the network test packets.  Per [RFC7799] classification
   such process classified as hybrid measurement method.

   Several technical methods were proposed to enable collection of
   telemetry information instantaneous to the packet processing.  Among
   them [P4.INT] and [I-D.ietf-ippm-ioam-data].

   This document introduces new hybrid measurement method, referred to
   as Hybrid Two-step (HTS), that it separates measuring and/or
   calculating performance metric from the collecting and transporting
   telemetry.  The hybrid two-step method extends two-step mode of
   Residence Time Measurement (RTM) defined in [RFC8169] to on-path
   telemetry collection and transport.

Mirsky, et al.           Expires August 31, 2018                [Page 2]
Internet-Draft               Hybrid Two-Step               February 2018

2.  Conventions used in this document

2.1.  Terminology

   RTM Residence Time Measurement

   ECMP Equal Cost Multipath

   MTU Maximum Transmission Unit

   HTS Hybrid Two-step

2.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Problem Overview

   Performance measurements are meant to provide data that characterize
   conditions experienced by data in the network and possibly trigger
   operations to re-route flows, allocate additional or free excess of
   resources.  All changes to the network depend on the quality of
   collected data and calculated based on its performance metrics.  The
   quality of measurements defined not only by resolution but by how
   consistent are performed measurements, how predictable is the moment
   of measurement making, of obtaining the data.  Consider case of delay
   measurement that relies on collection of time of packet arrival at
   the ingress interface and time of packet transmission at egress
   interface.  The ideal method may read wall clock value as the very
   first octet of the packet being received at ingress, and another
   value, as the first octet being transmitted.  That way all nodal
   processing delays be accounted for as this method excludes packet
   queuing.  But if the measurement method requires the original packet
   to carry either both time values of the calculated delay value, then
   the packet must be modified on-the-fly, while being transmitted.  And
   that task may become even more challenging if the packet is
   encrypted.  As result, at egress time may be obtained before the
   packet transmission begins, thus leaving variable delays unmeasured.
   Similar problem may cause lower quality of, for example, information
   that characterizes utilization of the egress interface.  If unable to
   obtain the data consistently, without variable delays for additional
   processing, information may not accurately reflect the state at the
   egress interface.  To mitigate this problem [RFC8169] defined RTM
   two-step mode.

Mirsky, et al.           Expires August 31, 2018                [Page 3]
Internet-Draft               Hybrid Two-Step               February 2018

   Another challenge facing methods that collect telemetry into the
   actual data packet is risk of exceeding size of Maximum Transmission
   Unit (MTU), particularly if the packet traverses overlay domains or
   VPNs.  Since the fragmentation is not available at the transport
   network, operators may have to reduce MTU size advertised to client
   layer or risk missing telemetry data for the part, most probably the
   latter part, of the path.

4.  Theory of Operation

   HTS method consists of the two phases:

   o  performing a measurement or obtaining telemetry information, one
      or more than one type, on a node;

   o  collecting and transporting the measurement.

   HTS uses HTS Control message to define types of measurement or
   telemetry data collection requested from a node.  HTS Control message
   may be inserted into the data packet, as meta-data or shim, or be
   transmitted in the specially constructed test packet.

   To collect measurement and telemetry data from the nodes HTS method
   uses the follow-up packet.  The node that creates the HTS Control
   message also originates the HTS follow-up packet.  The follow-up
   packet contains characteristic information, copied from the data
   packet, sufficient for participating nodes to associate it with the
   original packet.  Exact composition of the characteristic information
   is specific for each transport network and its definition is outside
   the scope of this document.  The follow-up packet also uses the same
   encapsulation as the data packet.  If not payload but only network
   information used to load-balance flows in equal cost multipath
   (ECMP), use of the network encapsulation identical to the data packet
   should guarantee that the follow-up packet remains in-band, i.e.
   traverses the same set of network elements, with the original data
   packet.  Only one outstanding follow-up packet may be on the node for
   the given path.  That means that if the node receives HTS Control
   message for the flow on which it still waits for the follow-up packet
   to the previous HTS Control message, the node will originate the
   follow-up packet to transport the former set of the telemetry data
   and transmit it before it transmits the follow-up packet with the
   latest set of telemetry information.

5.  IANA Considerations

   This document doesn't have any IANA requirements.  The section may be
   deleted before the publication.

Mirsky, et al.           Expires August 31, 2018                [Page 4]
Internet-Draft               Hybrid Two-Step               February 2018

6.  Security Considerations

   Nodes that practice HTS method are presumed to share a trust model
   that depends on the existence of a trusted relationship among them.
   This is necessary as these nodes are expected to correctly modify
   specific content of the data in the follow-up packet, and degree to
   which HTS measurement is useful for network operation depends on this
   ability.  In practice, this means that those portions of messages
   that contain the telemetry data cannot be covered by either
   confidentiality or integrity protection.  Though there are methods
   that make it possible in theory to provide either or both such
   protections and still allow for intermediate nodes to make detectable
   but authenticated modifications, such methods do not seem practical
   at present, particularly for protocols that used to measure latency
   and/or jitter.

   The ability to potentially authenticate and/or encrypt the telemetry
   data for scenarios both with and without participation of
   intermediate nodes that participate in HTS measurement is left for
   further study.

   While it is possible for a supposed compromised node to intercept and
   modify the telemetry information in the follow-up packet, this is an
   issue that exists for nodes in general - for any and all data that
   may be carried over the particular networking technology - and is
   therefore the basis for an additional presumed trust model associated
   with existing network.

7.  Acknowledgements

   TBD

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Mirsky, et al.           Expires August 31, 2018                [Page 5]
Internet-Draft               Hybrid Two-Step               February 2018

8.2.  Informative References

   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
              P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields
              for In-situ OAM", draft-ietf-ippm-ioam-data-01 (work in
              progress), October 2017.

   [P4.INT]   "In-band Network Telemetry (INT)", P4.org Specification,
              October 2017.

   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
              May 2016, <https://www.rfc-editor.org/info/rfc7799>.

   [RFC8169]  Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
              and A. Vainshtein, "Residence Time Measurement in MPLS
              Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017,
              <https://www.rfc-editor.org/info/rfc8169>.

Authors' Addresses

   Greg Mirsky
   ZTE Corp.

   Email: gregimirsky@gmail.com

   Wang Lingqiang
   ZTE Corporation
   No 19 ,East Huayuan Road
   Beijing   100191
   P.R.China

   Phone: +86 10 82963945
   Email: wang.lingqiang@zte.com.cn

   Guo Zhui
   ZTE Corporation
   No 19 ,East Huayuan Road
   Beijing   100191
   P.R.China

   Phone: +86 10 82963945
   Email: guo.zhui@zte.com.cn

Mirsky, et al.           Expires August 31, 2018                [Page 6]