]> Huawei

China zhangli344@huawei.com

Huawei

China zhoutianran@huawei.com

CAICT

China majunfeng@caict.ac.cn

OPS Area IPPM Working Group IOAM Active measurement Active measurements are typically used to collect the information of a specific path. However, when using active measurement mechanisms in a multi-path topology, the default forwarding behavior is to go through one path. So, it cannot collect the information of all the paths at one time. This document extends IOAM Trace Option with a multi-path flag to simplify multi-path IOAM active measurement, which promotes the information collection and topology restoration of a multi-path topology. It can help the operators to know the performance of network comprehensively and efficiently.

Introduction In situ Operations, Administration, and Maintenance (IOAM) collects OAM information within the packet while the packet traverses a particular network domain. IOAM is used to complement mechanisms, such as Ping or Traceroute. defines the Active flag to indicate that a packet is used for active measurement and should be terminated by the decapsulating node. It also provides two active measurement use cases where the Active flag could be used. However, active measurements are typically used to collect the information of a specific path, when using active measurement mechanisms in a multi-path topology (there are multiple paths from the source node to the destination node and ECMP, UCMP or other multi-path routing strategy is used.), the default forwarding behavior is to go through one path. So, it can’t collect all the path’s information from source node to destination node . An example of active measurement in a multi-path topology is shown as follow:

A multi-path topology | N2 | | N7 |---->| N8 | +------+ +------+\ /+------+ +------+ Encapsulating \ +------+ +------+ / Decapsulating Node \| N4 |-------> | N6 |/ Node +------+ +------+ <----------------------------IOAM-Domain-------------------------------> ]]>

In , node N1 is Encapsulating node, node N8 is the Decapsulating node, N2-N7 are transit node. Equal-Cost Multiple Path (ECMP) is applied in this topology. So, there are two paths form N1 to N8, one is N1-N2-N3-N5-N7-N8, and the other is N1-N2-N4-N6-N7-N8. When N1 use IOAM probe packets or replicated data packets to measure the paths performance, the packets are forwarded along one of the paths (for example N1-N2-N4-N6-N7-N8), then the analyzer just can get one of the paths information, however the traffic packets are forwarded in all paths. Although the IPv6 flow label and MPLS entropy label can be constructed variously according to the paths information to make packets go through all paths, but in some scenarios, it is hard to get all the available paths in advance. This document extends IOAM Trace Option with a multi-path flag to simplify multi-path IOAM active measurement, which can promote the information collection and topology restoration of a multi-path topology without knowing all the available paths in advance.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology The abbreviations used in this document are: ECMP: Equal-Cost Multiple Path UCMP: Unequal-Cost Multiple Path IOAM: In situ Operations, Administration, and Maintenance

IOAM extension The format of IOAM Pre-allocated and Incremental Trace-Option header defined in is shown as follows:

IOAM Pre-allocated and Incremental Trace-Option Header

This document defines a new flag X in the Flags field: Bit X “Multipath” (M-bit): When set, the Multi-path flag indicates that when an active measurement packet arrives at a node which has multiple paths to the destination, the packet will be duplicated to every interface which can reach the destination.

Multi-path Measurement Procedures This section describes the procedures of Encapsulating node, transit node, and Decapsulating node.

Encapsulating Node Procedures The Encapsulating node should generates probe packets with a Trace Option that has its Active flag and Multipath flag set. The probe packets could be generated independently or replicated from some of the en-route data packets and should be terminated by the Decapsulating node.

Transit Node Procedures

Packet Operation When the transit node receives a probe packet with the IOAM trace option, it should add its node ID, ingress interface ID, and egress interface ID to the IOAM trace option of the probe packet. For details about the content format, see section 4.4.2 of .

Packet Forwarding When a transit node with multiple paths to the Destination node receives a packet with a Trace Option that has its Active flag and Multipath flag set, it SHOULD duplicate the packet to each egress interface that can reach the Destination node. When the transit node has only one path to the destination node, it just needs to forward the packet it received to the egress interface. If the Active flag is reset or the Multipath flag is reset, then the transit node MUST not duplicate the packet.

Decapsulating Node Procedures When a Decapsulating node receives a probe packet with the IOAM tarce option, it needs to add its node ID, ingress interface ID to the IOAM trace option of the probe packet. Then the Decapsulating node need to export the IOAM data to the analyzer.

IANA Considerations This document requests IANA to allocate a bit from the "IOAM Trace-Flags" registry:

Value	Description	Reference
Bit X	Multi-path Bit	This document

Security Considerations The security considerations of IOAM Active flag are discussed in , the solutions mitigating the attacks mentioned in are also applicable in this document. In addition, the duplication of probe packets may lead to other risks. When there is a loop in the topology, the probe packets may be replicated repeatedly. Even there is no loop in the topology, an attacker can replicate a lot of packets by setting the Multi-path flag in en-route packets, causing bandwidth degradation. In order to mitigate the possible attacks, the IOAM enabled nodes should be able to:

• Limit the generation rate of IOAM probe packets with the Multi-path flag.
• Limit the maximum number of packet replication times, this could be realized by defining an Opaque State Snapshot filed in the Trace Option. The value of this field should decrease by one when a node duplicates the probe packet. The initial value of this field is set by the Encapsulating node, when its value decreases to zero, then the packet MUST not be duplicated anymore.

References Normative References In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in packets while they traverse a path between two points in the network. This document defines two new flags in the IOAM Trace Option headers, specifically the Loopback and Active flags. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets.

Acknowledgements The authors would like to thank Ernesto Ruffini, Thomas Graf, Greg Mirsky for the valuable comments to this work.