Enhanced Alternate Marking Method

Abstract

This document extends the IPv6 Alternate Marking Option to provide enhanced capabilities and allow advanced functionalities. With this extension, it can be possible to perform thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring.¶

1. Introduction

The Alternate Marking [RFC9341] and Multipoint Alternate Marking [RFC9342] define the Alternate Marking technique that is a hybrid performance measurement method, per [RFC7799] classification of measurement methods. This method is based on marking consecutive batches of packets and it can be used to measure packet loss, latency, and jitter on live traffic.¶

The IPv6 AltMark Option [RFC9343] applies the Alternate Marking Method to IPv6, and defines an Extension Header Option to encode the Alternate Marking Method for both the Hop-by-Hop Options Header and the Destination Options Header.¶

While the IPv6 AltMark Option implements the basic alternate marking methodology, this document defines extended data fields for the AltMark Option and provides enhanced capabilities to overcome some challenges and enable future proof applications.¶

It is worth mentioning that the enhanced capabilities are intended for further use and are optional.¶

Some possible enhanced applications MAY be:¶

1. thicker packet loss measurements: the single marking method of the base AltMark Option can be extended with additional marking bits in order to get shortest marking periods under the same timing conditions.¶

2. more dense delay measurements: than double marking method of the base AltMark Option can be extended with additional marking bits in order to identify down to each packet as delay sample.¶

3. increase the number of concurrent flows under monitoring: if the 20-bit FlowMonID is set independently and pseudo randomly, there is a 50% chance of collision for 1206 flows. The size of FlowMonIDcan can be extended to raise the entropy and therefore to increase the number of concurrent flows that can be monitored.¶

2. Data Fields Format

The Data Fields format is represented in Figure 1. A 5-bit NH(NextHeader) field is allocated from the Reserved field of IPv6 AltMark Option [RFC9343]. It is worth highlighting that remaining bits of the former Reserved field continue to be reserved.¶

 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
+---------------------------------------+-+-+---------+---------+
|           FlowMonID                   |L|D| Reserved|    NH   |
+---------------------------------------+-+-+---------+---------+

The NH (NextHeader) field is used to indicate the extended data fields which are used for enhanced capabilities:¶

• NextHeader value of 0 is reserved for backward compatibility. It means that there is no extended data field attached.¶

• NextHeader values of 1-15 are reserved for private use or for experimentation.¶

• NextHeader value of 16-31 indicates the extended data fields that should be defined in IETF. This document specifies the extended data fields when the NextHeader is 16. The format is shown in Figure 2.¶

 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
+---------------------------------------+-+-----+---+-----------+
|           FlowMonID Ext               |F|  P  | M |  Reserved |
+-------------------------------+-------+-+-----+---+-----------+
|           MetaInfo            |            Padding            |
+-------------------------------+-------------------------------+

where:¶

• FlowMonID Ext - 20 bits unsigned integer. This is used to extend the FlowMonID in order to reduce the conflict when random allocation is applied. The disambiguation of the FlowMonID field is discussed in IPv6 AltMark Option [RFC9343].¶

• F - The flag to enable the automatic backward flow monitoring. If F=1, it indicates the egress node to setup the backward flow monitoring automatically based on 5 tuple of the forward flow.¶

• P - It indicates period of the alternate marking.¶

  • 000: 1s¶

  • 001: 10s¶

  • 010: 30s¶

  • 011: 60s¶

  • 100: 300s¶

  M - It indicates the measurement mode.¶

  • 00: Reserved;¶

  • 01: Edge to edge mode;¶

  • 10: Hop by hop mode;¶

  • 11: Reserved.¶

• MetaInfo - A 16-bit Bitmap to indicate more meta data attached for the enhanced function (see below).¶

• Padding - These bits MUST be set to zero when not being used.¶

The MetaInfo is defined in the following Figure 4 as a bit map:¶

bit 0: If set to 1, it indicates a 6 bytes Timestamp that is attached after the MetaInfo. Timestamp(s) stands for the number of seconds in the timestamp. It will overwrite the Padding after MetaInfo. Timestamp(ns) stands for the number of sub-seconds in the timestamp with the unit of nano second. This Timestamp is filled by the encapsulation node, and is taken all the way to the decapsulation node. So that all the intermediate nodes could compare it with its local time, and measure the one way delay.¶

 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
                                +-------------------------------+
                                |    Timestamp(s)               |
+-------------------------------+-------------------------------+
|                 Timestamp(ns)                                 |
+---------------------------------------------------------------+

bit 1: If set to 1, it indicates more detailed control information with the following data format that is attached after the MetaInfo:¶

 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
+---------------+---------------+-----------+-------------------+
|  DIP Mask     |  SIP Mask     |P|I|O|V|S|T|    Period         |
+---------------+---------------+-----------+-------------------+

This is used to set up the backward direction flow monitoring. Where:¶

• DIP Mask: The length of the destination IP prefix used to match the flow.¶

• SIP Mask: The length of the source IP prefix used to match the flow.¶

• P bit: If set to 1, it indicates to match the flow using the protocol identifier in the trigger packet.¶

• I bit: If set to 1, it indicates to match the source port.¶

• O bit: If set to 1, it indicates to match the destination port.¶

• V bit: If set to 1, the egress node will automatically set up reverse direction monitoring, and allocate a FlowMonID.¶

• S bit: If set to 1, it indicates to match the DSCP.¶

• T bit: Used to control the scope of tunnel measurement. T=1 means meausre between Network-to-Network Interfaces (i.e., NNI to NNI). T=0 means measure between User-to-Network Interfaces (i.e., UNI to UNI).¶

• Period: it indicates the alternate marking period with the unit of second.¶

bit 2: If set to 1, it indicates a 4 bytes Sequence number with the following data format that is attached after the MetaInfo. The unique Sequence could be used to detect the out-of-order packets, in addition to the normal loss measurement. More over, the Sequence can be used together with the latency measurement, so as to get the per packet timestamp.¶

 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
+---------------------------------------------------------------+
|                          Sequence                             |
+---------------------------------------------------------------+

It is worth noting that the meta data information forming the Padding and specified above in Figure 3, Figure 4 and Figure 5 must be ordered according to the order of the MetaInfo bits.¶

6. References