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

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 May 7, 2020.

Copyright Notice

Copyright (c) 2019 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 1.2. Terminology & Abbreviations
• 2. Overview of MPCM
• 3. MPCM-Test Packet Format and Content
• 4. Expansion based on various measurement methods
• 4.1. IOAM
• 5. Data Export
• 6. IANA Considerations
• 7. Security Considerations
• 8. Acknowledgements
• 9. Normative References
• Authors' Addresses

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.

           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

• 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.
• Concurrent
  • In order to ensure comparability between multiple paths, the test start point and the test end point are required to be same.

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.

3. MPCM-Test Packet Format and Content

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

Firstly one path packet formatFigure 2 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 2: MPCM Path header

Figure 3.

• Session ID: A set of load sharing paths
• Path ID: One path of the session.
• Path-E2E-Type: A 16-bit identifier which Indicates whether the packet type is a send message or a request message.
• 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
• 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 replies

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

Figure 3: Query and Response message

Figure 4.

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

Figure 4: 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 4.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                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 5: Response message

• Long-term measurement
  • The receiver can wait until it receives all measurement requests of a set of path and then responds.
• 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.

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.

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

8. Acknowledgements

TBD

9. Normative References

Authors' Addresses