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

Versions: 00 01 02 03

Network Working Group                                       D. Dang, Ed.
Internet-Draft                                                    Huawei
Intended status: Informational                                   W. Wang
Expires: November 14, 2020                                 China Telecom
                                                                  W. LEE
                                                                   LG U+
                                                            May 13, 2020


               Multi-Path Concurrent Measurement for IPPM
              draft-dang-ippm-multiple-path-measurement-03

Abstract

   This test method can test multi-paths concurrently from one edge node
   to another edge node.  This document details Multi-Path Concurrent
   Measurement (MPCM).

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 November 14, 2020.

Copyright Notice

   Copyright (c) 2020 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
   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




Dang, et al.            Expires November 14, 2020               [Page 1]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology & Abbreviations . . . . . . . . . . . . . . .   3
   2.  Overview of MPCM  . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Principle . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.1.  Single Path Measurement . . . . . . . . . . . . . . .   4
       2.1.2.  Multiple Path Measurement . . . . . . . . . . . . . .   6
   3.  MPCM-Test Packet Format and Content . . . . . . . . . . . . .   7
   4.  Expansion based on various measurement methods  . . . . . . .  10
     4.1.  IOAM  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Data Export . . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   As we know, the current network has been already being in load
   balancing mode, however it is partially congested.  In other words,
   from the same source node to the same destination node, some paths
   have been congested to cause a decline in service quality, but some
   paths carry less traffic and are lightly loaded.  To solve the
   problem of unbalanced network load[draft-liu-ican], the first is to
   have the ability to detect the quality of the load sharing paths.
   And then the traffic from the Scr node to the Dst node is required to
   be steered from the congested paths into the lightly loaded path/
   paths basing on the SLA's requirement.  So it's necessary to measure
   the multi-paths in load-balancing mode.

   In the traditional method, the paths are measured separately because
   they aren't maintained by the path group.  If the multiple load
   sharing paths are required to be selected based on the SLA
   information, the measured SLA information needs to be comparable.  If
   you want to ensure that the data obtained by the test is available
   and accurate, the multi-paths are required to maintain by the path
   group in order that the test start and end points must be same.

   For example, the low latency services require millisecond delays.  If
   the start time and the end time aren't same, the measured data may
   not be in one test cycle, and the accuracy of this data is relatively
   low and the data cannot be comparedFigure 1.



Dang, et al.            Expires November 14, 2020               [Page 2]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


            Path1
      +-+-+-+-+-+-+-+-+
      |               |
      +-+-+-+-+-+-+-+-+

                                   Path2
                             +-+-+-+-+-+-+-+-+
                             |               |
                             +-+-+-+-+-+-+-+-+

                    Path3
             +-+-+-+-+-+-+-+-+
             |               |
             +-+-+-+-+-+-+-+-+

 -----------------------------------------------------------------------
  0                                           t

              Figure 1: Measured Data in the Different Cycles

   The Multi-Path Concurrent Measurement (MPCM) is required, which can
   be used bi-directionally to concurrently measure multi-paths metrics
   between two network elements.  At the same time, this method also
   consider saving the number of test messages to reduces the load on
   the network.

1.1.  Requirements Language

   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.

1.2.  Terminology & Abbreviations

   o  Muti-paths

      *  There are multiple paths between two nodes in the network.
         These paths may be equal-cost multi-path (ECMP) mode or
         unequal-cost multiple (UCMP) mode.  In a real network, they
         might be one [draft-ietf-spring-segment-routing-policy] or
         [RFC7348] tunnel group.

   o  Concurrent

      *  In order to ensure comparability between multiple paths, the
         test start point and the test end point are required to be
         same.




Dang, et al.            Expires November 14, 2020               [Page 3]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


2.  Overview of MPCM

   The Multi-Path Concurrent Measurement (MPCM) is the way of
   measurement of multi-paths metrics.

   MPCM can be embedded into a variety of transports such as NSH,
   Segment Routing, VxLAN, native IPv6 (via extension header), or IPv4.

2.1.  Principle

   To complete the target scenario, we need to optimize the single-path
   measurement mechanism, and then further diffuse the single-path
   measurement mechanism to multiple-path.

   1.  For a single tunnel, the Dst needs to know when to start timing
   in order to delimit.  The Dst needs to solve various problems such as
   congestion and discarding of measurement packets.  Therefore, the Dst
   needs to initiate a periodic response.

   2.  For multiple paths, the Dst needs to respond one measurement
   message with multiple path information in its specific time, solving
   the problems such as inconsistent initiation of any path,
   inconsistent measurement periods, clock drift, and different delays.

2.1.1.  Single Path Measurement

              |-----ti-----|-----ti-----|-----ti-----|
              t0           t1           t2
      Src    -----------------------------------------
               |             \             \
               |               \             \
               |                 \             \
               |                   \             \
      Dst    -----------------------------------------
              t0'                  t1'           t2'


                     Figure 2: Single path measurement

   A path between Scr node and Dst node in the network to obtain
   measurement results at equal intervals is as follows:

   1) Set the measurement interval ti.

   a) Before the test starts, the Scr sends a protocol packet to the Dst
   and sets the test interval ti.





Dang, et al.            Expires November 14, 2020               [Page 4]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


   b) After receiving the protocol message, the Dst sets the test
   interval ti for the Scr and Dst, and replies to the Scr to confirm
   that the setting is successful.  The congestion at the Dst will be
   counted at intervals ti.

   c) After receiving the interval setting successfully, the Scr starts
   to start measurement.

   2) The Scr sends the first delimited message, which includes the
   sending timestamp t0, and starts to count the data packets sent.

   3) After receiving the first delimited message, the Dst end stamps
   the time stamp t0 'and starts to count the received data messages.

   4) The Scr sends the second delimited message at time t1, where t1 =
   t0 + ti, the message includes the sending timestamp t1, and counts
   the number of data packets sent.  The first delimited message uses
   high priority, and the second delimited message uses normal priority.
   Because the second delimitation message has a low priority and a
   large queuing delay, the interval between the first delimitation
   message and the second delimitation message shall become larger at
   the Dest.

   5) At the time t0 '+ ti, the Dst counts the number of packets
   received between t0' and t0 '+ ti, and sends the message back to the
   Src with the number of packets, the sending time t0 and the receiving
   time t0'.  If the delimitation message has not been received at t0' +
   2 * ti time, the Dst repeats the previous actions, and so on.

   6) When the second delimited message arrives at the Dst, the Dst
   counts the number of packets received between t0 'and t1' at t1
   'time, and sends the message back to the Src with the number of
   packets, the packet sending time t0 and the packet receiving time t0
   '.

   7) After t1 ', the sending time in the message from the Dst is
   updated to t1, and the receiving time in the message from the Dst is
   updated to t1'.  The number of packets is still the number of packets
   received within ti time.

   8) Assuming that t1' is between t0' + (x-1) * ti and t0' + x * ti,
   then the congestion in the interval ti is calculated in two parts.
   The first part is from t0 '+ (x-1) * ti to t1', The statistics
   packets sent at t1' must include the packet statistics and time t0';
   the second part is from t1 'to t0' + x * ti, t0 '+ x * ti need to
   include the packet statistics and t1'.

   9) Repeat the above steps.



Dang, et al.            Expires November 14, 2020               [Page 5]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


2.1.2.  Multiple Path Measurement

              | <-----------> |  <------------>| <------------> |
              |      Ti       |      Ti        |      Ti        |
       Path1  | m1        m2  |    m3          | m4     m5      |       m6
      ---------------------------------------------------------------
              |               |                |                |
       Path2  |          m1   |    m2           m3      m4      |   m5
      --------------------------------------+------------------------
              |               |                |                |
       Path3  | m1     m2    m3         m4     |    m5          | m6
      --------+---------------+----------------+----------------+----

                    Figure 3: Multiple path measurement

   There are multiple paths in the tunnel between Src node and Dst nodes
   in the network.  This method is mainly implemented at the Dst.

   1) Set the measurement interval ti.

   a) Before the test starts, the Src sends a protocol packet to the
   Dst, setting the number of paths and the measurement interval ti.
   The measurement result of each path is a message with measurement
   data.

   b) After receiving the protocol message, the Dst sets the number of
   paths and measurement interval ti, and replies to the source to
   confirm the successful setting.

   c) After receiving the message with the number of paths and
   measurement interval, the Src starts to start measurement.

   2) On each path, the Src continuously sends measurement packets, and
   the Dst continuously calculates the measurement results at intervals
   ti.

   3) The Dst collects the measurement results of each path at intervals
   ti after the earliest measurement result of multiple paths is came
   out.

   4) The results of multiple paths in the same interval time ti are
   counted as a group.  If there is no measured results on the specific
   path in the interval ti, the relevant information is set 0 in the
   group results.  A set of measurement results packaged of multiple
   paths are taken back to the Src.

   5) The measurement results of multiple paths on the Dst are
   continuously packaged at intervals ti and sent back to the Src. The



Dang, et al.            Expires November 14, 2020               [Page 6]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


   packaged message carries the sequence number within the message to
   prevent out of order.

3.  MPCM-Test Packet Format and Content

   This section defines path header and associated data types required
   for MPCM.

   Firstly one path packet formatFigure 4 of multi-path can be defined.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Session ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Path ID            |         Path-E2E-Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags   |          Transaction ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 4: MPCM Path header

   o  Session ID: A set of load sharing paths

   o  Path ID: One path of the session.

   o  Path-E2E-Type: A 16-bit identifier which Indicates whether the
      packet type is a send message or a request message.

   o  Flags: 8-bit field.  Identify the query or response type.
      Following flags are defined:

      *  Bit 0 Identify the query type

      *  Bit 1 Identify the response type

      *  Reserved

   o  Transaction ID: 16-bit identifier of one measurement transaction.
      The sender and receiver to identify measurement transactions based
      on Transaction ID.

   When a measurement is for a set of paths, each query message is made
   for each path, but only one unified response message repliesFigure 5.







Dang, et al.            Expires November 14, 2020               [Page 7]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


      Sender                                  Receiver
        |                                        |
        |        Query message of Path1          |
        | -------------------------------------->|
        |        Query message of Path2          |
        |--------------------------------------->|
        |                  ...                   |
        |                  ...                   |
        |        Query message of PathN          |
        |--------------------------------------->|
        |                                        |
        |                                        |
        |                                        |
        |                                        |
        |                                        |
        |  Response message of All multi-paths   |
        |<---------------------------------------|
        |                                        |
        |                                        |

                   Figure 5: Query and Response message

   The measurement response packet format of a path is as
   followsFigure 6.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                E2E PathN Option Header                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |             PathN Edge-to-Edge Option Data                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 6: Query message

   The field of PathN Edge-to-Edge Option Data can refer to Edge-to-Edge
   Option Data of [draft-ietf-ippm-ioam-data-04].

   It suppose there are N paths between two points.The measurement
   response packet format of multi-paths is as followsFigure 6.









Dang, et al.            Expires November 14, 2020               [Page 8]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                E2E Path1 Option Header                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |             Path1 Edge-to-Edge Option Data                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
      ~                             ...                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
      |                                                               |
      |                E2E PathN-1 Option Header                      |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |             PathN-1 Edge-to-Edge Option Data                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                  E2E PathN Option Header                      |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |               PathN Edge-to-Edge Option Data                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 7: Response message

   o  Long-term measurement

      *  The receiver can wait until it receives all measurement
         requests of a set of path and then responds.

   o  Short-term measurement

      *  The Sender can query once t.

      *  The receiver can reply once t.

   The overall solution needs to consider two methods of long-period
   measurement and short-period measurement.








Dang, et al.            Expires November 14, 2020               [Page 9]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


4.  Expansion based on various measurement methods

   The measurement message format defined by this document can be
   extended based on various measurement methods.

4.1.  IOAM

   A new type may be added in IOAM-E2E-Type of IOAM Edge-to-Edge Option
   header[draft-ietf-ippm-ioam-data-04-section4.4] as follow.

   o  Bit 4: Multiple paths measurement.

   This bit is set by the headend node if Multi-Path Concurrent
   Measurement is activated.

   A common registry is maintained for IOAM-Types, see Section 6.

   For path-based quality measurements, there is no need to measure each
   message because the large-scale deployment consumes too much network
   resources.  Here, the way of periodic measurement is recommended.In a
   period, if there is a packet, the appropriate packet is selected to
   be inserted into the iOAM packet; if there is no packet, a
   measurement packet is directly generated[draft-dang-ippm-congestion].

5.  Data Export

   MPCM nodes collect information for packets traversing a domain that
   supports MPCM.  MPCM process the information further and export the
   information using e.g., IPFIX.  Raw data export of IOAM data using
   IPFIX is discussed in [draft-spiegel-ippm-ioam-rawexport-00].

6.  IANA Considerations

   This document requests the following IANA Actions.

   IOAM E2E Type Registry:

   Bit 4 Multiple ways measurement

7.  Security Considerations

   The Proof of Transit option (Section Section 4.3 In-situ OAM
   [draft-ietf-ippm-ioam-data-04-section4.4]) is used for verifying the
   path of data packets.







Dang, et al.            Expires November 14, 2020              [Page 10]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


8.  Acknowledgements

   TBD

9.  Normative References

   [draft-dang-ippm-congestion]
              "A One-Path Congestion Metric for IPPM",
              <https://tools.ietf.org/html/draft-dang-ippm-congestion-
              02>.

   [draft-ietf-ippm-ioam-data-04]
              "A Variety of Transports",
              <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-
              data/>.

   [draft-ietf-ippm-ioam-data-04-section4.4]
              "IOAM Edge-to-Edge Option",
              <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-
              data/>.

   [draft-ietf-spring-segment-routing-policy]
              "Segment Routing Policy Architecture",
              <https://tools.ietf.org/html/draft-ietf-spring-segment-
              routing-policy-02>.

   [draft-liu-ican]
              "Instant Congestion Assessment Network (iCAN) for Traffic
              Engineering", <https://tools.ietf.org/html/draft-dang-
              ippm-congestion-02>.

   [draft-spiegel-ippm-ioam-rawexport-00]
              "In-situ OAM raw data export with IPFIX",
              <https://tools.ietf.org/html/draft-spiegel-ippm-ioam-
              rawexport-00>.

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

   [RFC7348]  "Virtual eXtensible Local Area Network (VXLAN)",
              <https://datatracker.ietf.org/doc/rfc7348/>.








Dang, et al.            Expires November 14, 2020              [Page 11]


Internet-Draft Multi-Path Concurrent Measurement for IPPM       May 2020


Authors' Addresses

   Joanna Dang (editor)
   Huawei
   Beijing
   China

   Email: dangjuanna@huawei.com


   Jianglong
   China Telecom
   Beijing
   China

   Email: wangjl50@chinatelecom.cn


   Shinyoung
   LG U+
   Seoul
   Korea

   Email: leesy@lguplus.co.kr



























Dang, et al.            Expires November 14, 2020              [Page 12]


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