| Internet-Draft | An In Situ Operations, Administration, a | February 2024 |
| Zhang & Zhou | Expires 31 August 2024 | [Page] |
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 can promote the information collection and topology restoration of a multi-path topology.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 31 August 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
[RFC9322] provides three kinds of active measurements using IOAM, and defines a Active flag to indicate that a packet is used for active measurement.¶
[I-D.gandhi-ippm-stamp-ext-hdr] extends STAMP[RFC8762] to reflect any IPv6 options and MPLS Network Action Sub-Stacks for hop-by-hop and edge-to-edge active measurements. In section 4 of [I-D.gandhi-ippm-stamp-ext-hdr], it provides an example of reflecting IOAM data fields, in which the IPv6 options with IOAM option-types is carried in the STAMP Session-Sender and Session-Reflector test packets.¶
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 form 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 form source node to destination node . An example of active measurement in a multi-path topology is shown as follow:¶
+------+ +------+
/| N3 |---------| N5 |\
/ +------+ +------+ \
+------+ +------+/ \+------+ +------+
| N1 |--->| N2 | | N7 |---->| N8 |
+------+ +------+\ /+------+ +------+
SRC \ +------+ +------+ / DST
\| N4 |-------> | N6 |/
+------+ +------+
In Figure 1, node N1 is the source node, node N8 is the destination node, N2-7 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 active measurement to measure the path performance, the probe packet is forwarded along one of the paths (for example N1-N2-N4-N6-N7-N8), then the source node or controller just can get one path’s information, however the data packets are forwarded in all paths.¶
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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document defines a new flag in the Pre-allocated and Incremental Trace options:¶
Bit X “Multipath” (M-bit): When set, the Multi-path flag indicates that when an active measurement packet arrives a node which has multiple paths to the destination, the packet will be copied to every path.¶
Active measurement methods [RFC7799] make use of synthetically generated packets to facilitate measurement. This section presents use cases of multi-path active measurement using the IOAM Multi-path flag.¶
The Multi-path flag indicates that an active measurement packet is used for multi-path active measurement. An IOAM Transit node that receives a packet with the Multi-path flag set in one of its Trace options must copy the packet to every path that can reach the destination node. The Multi-path flag is intended to record every path’s information by one active measurement packet in multi-path topology.¶
An example of an IOAM deployment scenario is illustrated in Figure 2. The figure depicts two endpoints: An Encapsulating node and a Decapsulating node. The data traffic from the Encapsulating node to the Decapsulating node is forwarded through four transit nodes. There are two routing paths from Encapsulating node to the Decapsulating node.¶
+--------+
/| N3 |\
/ +--------+ \
+--------+ +--------+/ Transit \+--------+ +--------+
| N1 |-----| N2 | Node | N5 |-----| N6 |
+--------+ +--------+\ /+--------+ +--------+
Encapsulating Transit \ +--------+ / Transit Decapsulating
Node Node \| N4 |/ Node Node
+--------+
Transit
Node
<---------------------- IOAM-Domain ------------------------>
In Figure 2, Probe packets are generated and transmitted by the IOAM Encapsulating node and are expected to be terminated by the Decapsulating node. The Encapsulating node generates Probe packets include a Trace Option that has its Multi-path flag set, indicating that these are multi-path probe packets.¶
When a multi-path probe packet arrives at N2, N2 find that there are two paths to the Decapsulating node, then it will copy the packet to each outgoing interface of the two paths and add its information to the IOAM Trace Option. It should be noted that Node Identification and outgoing interface Identification of N2 are mandatory for path recovering, other node data defined in section 4.1.1 of [RFC9197] are optional.¶
The following transit nodes just add its node data to the IOAM Trace Option as described in section 4 of [RFC9197].¶
When a probe packet arrives at Decapsulating node, the Decapsulating node will extract the encapsulated node data along the path from the probe packet and exports the associated data to the controller.¶
The controller will restore all path information based on the exported data form Decapsulating node.¶
A “STAMP Topology” is shown in Figure 3. Node S1 is a session sender, node R1 is a session reflector, node M1, M2, M3 and M4 are midpoint node.¶
+----+
// | M2 | \\
// +----+ \\
+----+Test Packet+----+ +----+ +----+
| | - - - - ->| | | |- - - - - >| |
| S1 |===========| M1 | | M4 |===========| R1 |
| |<- - - - - | | | |<- - - - - | |
+----+ +----+ +----+ Reply Test+----+
\\ +----+ // Packet
\\ | M3 | //
+----+
STAMP Session-Sender STAMP Session-Reflector
The STAMP Session Sender S1 initiates a Session-Sender test packet with an IPv6 IOAM option and has its Multi-path flag set.¶
When the Session-Sender test packet arrives at M1, M1 find that there are two paths to R1, then it will copy the packet to each outgoing interface of the two paths and add its information to the IOAM Trace Option.¶
The following transit nodes just add its node data to the IOAM Trace Option as described in the section 4 of [RFC9197].¶
When the probe packet arrives at R1, it MUST copy the entire IPv6 option including the header into the STAMP "Reflected IPv6 Option Data" TLV in Session-Reflector payload. The Session-Reflector also MUST add the matching IPv6 option in the IPv6 header of the Session-Reflector test packet and reset the Multi-path flag of IOAM option.¶
Based on the above procedures, the multi-path information collected by IOAM data fields is reflected to the Sender where the Sender can use that information to support the hop-by-hop and edge-to-edge measurement use-cases.¶
This document defines a new bit in the registry "IOAM Trace-Flags" registry as follows:¶
| Value | Description | Reference |
|---|---|---|
| Bit X | Multipath Flag | This |
The security considerations described in [RFC9197] apply to the extensions defined in this document as well. This document does not raise new security issues.¶