In-situ OAM Data Validation Option

In-situ OAM (iOAM) records OAM information within user packets while the packets traverse a network. The data types and data formats for in-situ OAM data records have been defined in . We identify several scalability issues for implementing the current iOAM specification and propose solutions in this draft. iOAM can designate the flow to add the iOAM header and collect data on the flow forwarding path. The flow can have arbitrary granularity. However, processing the data can be a heavy burden for the network nodes, especially when some data needs to be calculated by the node (e.g., the transit delay). If the flow traffic is heavy, the node may not be able to handle the iOAM processing so many performance issues may occur, such as long latency and packet drop. Although it is good for the OAM applications to gain the detailed information on every packet at every node, in many cases, such information is often repetitive and redundant. The large quantity of data would also burden the management plane which needs to collect and stream the data for analytics. It is also possible that some nodes cannot provide the requested data at all or are unwilling to provide some data for security or privacy concerns. So a trade-off is needed to balance the performance impact and the data availability and completeness. We provide several motivating examples. To minimize the network impact, a network operator decides to collect the iOAM data only for initial and last flow packets (e.g., TCP packets with SYN, FIN, and RST flags). In another example, a head node alternates two iOAM headers with each requesting a subset of iOAM data. Hence, each node on the flow path only needs to handle partial data. The requests can be balanced without exhausting the network nodes. The above two cases can be realized by manipulating the iOAM header at the domain edge. It is also possible that a node is temporarily under heavy traffic load. It is in danger of dropping packets if it tries to satisfy all the iOAM data requests. In this case, it would rather deny some requests than drop user traffic. This case can be realized by adding some auxiliary fields in the iOAM header. More examples are listed in .

Based on the observation in Section 1, the source edge node should be able to define either the period or the probability to add the iOAM header to the selected flow packet. In this way, only a subset of the flow/sec packets would carry the OAM data, which not only reduces the overall iOAM data quantity but also reduces the processing work load of the network nodes.

It is possible that even an iOAM capable node will not add data to the node data list as requested. In some cases, a node can be too busy to handle the data request or some types of the requested data is not available. Therefore, we propose to add two bitmaps, a valid node bitmap and a valid data bitmap, to the iOAM specification. The Node Valid Bitmap (NVB) is inserted before the Node Data List as shown in . Each bit in the NVB corresponds to a hop on the packet's forwarding path. The bits are listed in the same order as the hop on the packet's forwarding path. The bitmap is cleared to all zero at first. If a hop can add data to the Node Data List, the corresponding bit in the NVB is set to 1. The bit location for a hop can be calculated from the length field (e.g, the bit index is equal to SSize-RHop).The valid node data items in the node data list is equal to the number of 1's in the NVB.

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Base OAM Trace Type |NodeLen| Flags | Octets-left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Valid Bitmap (NVB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Node Data List [] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In addition to NVB, for each node data in the node data list, a Data Valid Bitmap (DVB) is added before the node data. The number of bits in the DVB is equal to the number of 1's in the OAM Trace Type bitmaps (excluding the next trace type bitmap indicator bits). When the bit is set, the corresponding data is valid in the node; otherwise, the corresponding data is invalid so the management plane should ignore it after the data is collected. The size of the DVB can be padded to two or four bytes, which allow up to 16 or 32 types of data to be included in a node. The node data list format with the enhanced DVB is shown in .

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Valid Bitmap (DVB) | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Node Data List [i] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We give some examples to show the usefulness of in-situ OAM sampling and data validation features. An application needs to track a flow's forwarding path and knows the path will not change frequently, so it sets a low sampling rate to periodically insert the iOAM header to request the node ID. In a heterogeneous data plane, some nodes support to provide data x but the other nodes do not support it. However, an application is still interested in collecting data x if available. In this case, iOAM header can still be configured to ask for data x but the nodes that cannot provide the data simply invalidates it by resetting the corresponding bit in the valid data bitmap. Multiple sampling rate and multiple data request schema can be defined for a flow based on applications requirements and the data property, so for a flow packet, there can be no iOAM header or different iOAM headers. The node does not need to process all data all the time. For security reason, a node decides to not participate in the iOAM data collection. While it processes the other iOAM header fields as usual, it does not set the node valid bit in the Node Valid Bitmap and add node data to the Node Data List.

There is no extra security considerations beyond those have been identified by in-situ OAM protocol.

This memo includes no request to IANA.

We would like to thank Frank Brockners, Carlos Pignataro, Shwetha Bhandari, and Tal Mizrahi for helpful comments and suggestions.

The document is inspired by numerous discussions with James N. Guichard. He also provided significant comments and suggestions to help improve this document.