Self-Contained Alternate-Marking Mechanism for Performance Monitoring in High-Quality Network

The network operators are planning to provide network services with higher quality than the traditional BE (Best Effort) service, such as the DetNet service and the Network Slicing service. In these practices, it is important to monitor the performance of the service, such as the packet loss, delay, and jitter of the flow with guaranteed quality. In , an alternate-marking method for passive and hybrid performance monitoring is proposed. It marks the packet by using one or more bits in the packet headers, and collects the number of packets in a block sent on one end and the number of packets in the same block received on the other end. Finally, the two values are compared and accordingly, the packet loss of the flow are computed. The alternate-marking method is potential applied to any kind of packet-based traffic, and easy to implement. However, a controller or NMS needs to collect the information from the coloring point and the monitoring point, and correlate the two pieces of information by using the same block ID. It is hard to make it an end-to-end solution because the client is not in the scope. In this document, we propose a method that can involve the client in based on some extensions to the alternate-marking (coloring) technique. In this method, the block information is serialized and encoded in the packets of the block by the client. Then, the monitoring points can recover the information from the received packets, such as the block ID, number of packets in the block, timestamps in the packet, and compute the target measurement values.

As described in , the alternate-marking method is based on the “block”, which represents a measurable entity unambiguously recognizable by all network devices along the path. In the alternate-marking (coloring) technique, the coloring point creates packet blocks, colors the packets in the block, and reports information including block ID to the controller or the NMS. The monitoring points recognize the coloring information, record some needed information and report it to the controller or the NMS.

Figure 1: Mechanism in the traditional alternate-marking method ]]> For example, if some packets are lost in the network, the packet numbers of the same block will be different between the coloring point and the monitoring point. If we need to compute the delay or jitter of the flow, the coloring point and the monitoring point can also report the timestamps of the packets in the block to the controller or NMS. Traffic coloring can be implemented by setting a specific bit in the packet header and changing the value of that bit periodically. Thus, we only need two colors, and the packets belonging to the same block have the same color, whilst consecutive blocks will have different colors. When the color changes, the previous block terminates and the new one begins. Two mechanisms of switching color are introduced in . The first one is to switch the color after a fixed number of packets. The second one is to switch according to a fixed timer. For example, the timer may be 5 minutes.

To make the block information self-contained in the block, we need to occupy another specific bit to encode the block information. Thus, the client in the proposed mechanism needs not to report anything to the controller or NMS, and the monitoring points can compute target measurement values themselves and report any problem if needed. For example, we assume the fixed timer mechanism is used, and there are about 300 packets in a block. In the client, each packet carries one bit of the block information. Thus, if all the packets are received orderly, a monitoring point can recover the block information encoded in those 300 packets.

Figure 2: Mechanism in the self-contained alternate-marking method ]]> The block information can include the block ID (32 bits), CRC (32bits), and some TLVs as described below. TLV 1 may be the interval of the block (32bits). TLV 2 may be the packet number of the last block (32bits). TLV 3 may be the timestamp of the first packet in the block (32bits). The encoding of the block information is done in the client, and the monitoring points need to understand the meaning of the encoding.

As described in the last section, we assume that all the packets in a block are received in the monitoring point orderly. Normally, it is hard for the IP network with a relatively high packet loss rate. However, the situation may be much better in the DetNet service or the Network Slicing service, for which no or few packets would be lost. Meanwhile, an additional recovery block may also appear after several blocks, in which we will encode recovery information for the past several blocks, instead of the block information. Other fault tolerance mechanisms can also be considered. Another problem is similar to the situation in . It is whether we can find at least two reserved bits in the packet header to encode the coloring information and the block information. The detailed analysis can be found in that document.

TBD.