A
Multi-Path Concurrent Measurement Protocol for IPPMHuaweiBeijingChinadangjuanna@huawei.comChina TelecomBeijingChinawangjl1.bri@chinatelecom.cnThis test method can test multi-paths concurrently between two edge
nodes. This document details Multi-Path Concurrent Measurement Protocol
(MPCMP).In load-balancing scenario, there are multiple paths adopted between
two edge nodes. The traffic from the Scr node to the Dst node is
required to be steered into to the specific path/paths basing on the SLA
information of each path. In the traditional method, the paths are
measured separately. If you want to ensure that the data obtained by the
test is available and accurate, then the test start and end points of
this set of Paths must be consistent.The Multi-Path Concurrent Measurement Protocol (MPCMP) 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
saves the number of test messages and reduces the load on the
network.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.Mutiple PathsThere 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 or tunnel.ConcurrentIn order to ensure comparability between multiple paths,
the test start point and the test end point are required to be
synchronized.The Multi-Path Concurrent Measurement Protocol (MPCMP) is an open
protocol for measurement of multi-paths metrics.MPCMP can be embedded into a variety of transports such as NSH,
Segment Routing, VxLAN, native IPv6 (via extension header), or IPv4.This section defines path header and associated data types required
for MPCMP.Session ID: A set of load sharing pathsPath 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 typeBit 1 Identify the response typeReservedTransaction 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.
Therefore, the message format is defined as follows.The measurement packet format of a path is as follows.The field of PathN Edge-to-Edge Option Data can refer to Edge-to-Edge
Option Data of .The response type message format is as follows. It suppose there are
N paths between two points.Long-term measurementThe receiver can wait until it receives all measurement
requests of a set of path and then responds.Short-term measurementThe 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.The measurement message format defined by this document can be
extended based on various measurement methods.A new type is added in IOAM-E2E-Type of IOAM Edge-to-Edge Option
header 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 .MPCMP nodes collect information for packets traversing a domain that
supports MPCMP. MPCMP process the information further and export the
information using e.g., IPFIX. Raw data export of IOAM data using IPFIX
is discussed in .This document requests the following IANA Actions.IOAM E2E Type Registry:Bit 4 Multiple ways measurementThe Proof of Transit option (Section Section 4.3 In-situ OAM ) is used for
verifying the path of data packets.TBDA Variety of TransportsIOAM Edge-to-Edge OptionSegment Routing Policy ArchitectureVirtual eXtensible Local Area Network (VXLAN)In-situ OAM raw data export with IPFIX