Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation GroupChina MobileNo. 29 Finance AvenueXicheng DistrictBeijingChinali_zhenqiang@hotmail.comHuaweiChinazhoutianran@huawei.comZTE Corp.Chinaguo.jun2@zte.com.cnEricssonUnited States of Americagregimirsky@gmail.comCisco Systems, Inc.Canadargandhi@cisco.com
Transport Area
IPPMSTAMPPerformance MeasurementLAGMicro SessionThis document extends Simple Two-way Active Measurement Protocol
(STAMP) to implement performance measurement on every member link of a
Link Aggregation Group (LAG). Knowing the measured metrics of each
member link of a LAG enables operators to enforce a performance-based
traffic steering policy across the member links.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
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
() 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.
Table of Contents
. Introduction
. Requirements Language
. Micro Sessions on a LAG
. Member Link Validation
. Micro-session ID TLV
. Micro STAMP-Test Procedures
. Applicability
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionA Link Aggregation Group (LAG), as defined in , provides mechanisms to combine multiple physical
links into a single logical link. This logical link offers higher
bandwidth and better resiliency because, if one of the physical member
links fails, the aggregate logical link can continue to forward traffic
over the remaining operational physical member links.Usually, when forwarding traffic over a LAG, a hash-based mechanism is
used to load balance the traffic across the LAG member links. The link
delay might vary between member links because of different transport
paths, especially when a LAG is used in a wide area network. To provide
low-latency service for time-sensitive traffic, we need to explicitly steer
the traffic across the LAG member links based on the link delay, loss,
and so on. That requires a solution to measure the performance metrics
of each member link of a LAG. Hence, the measured performance metrics
can work together with Layer 2 bundle member link
attributes advertisement for traffic steering.According to the classifications in , Simple Two-way Active Measurement Protocol
(STAMP) is an active measurement method, and it can complement
passive and hybrid methods. It provides a mechanism to measure both
one-way and round-trip performance metrics, like delay, delay variation,
and packet loss. A STAMP test session over the LAG can be used to measure the
performance of a member link using a specially constructed 5-tuple. The session can be used to measure
an average of some or all member links of the LAG by varying one or more elements of that
5-tuple. However, without the knowledge of each member link, a STAMP test
session cannot measure the performance of every physical member
link.This document extends STAMP to implement performance measurement on
every member link of a LAG. It can provide the same metrics as One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
can measure, such as delay, jitter, and packet loss.Requirements LanguageThe 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.Micro Sessions on a LAGThis document addresses the scenario where a LAG directly connects
two nodes. An example of this is in , where the LAG consisting
of four links connects nodes A and B. The goal is to measure the
performance of each link of the LAG.Performance Measurement on a LAG +---+ +---+
| |-----------------------| |
| A |-----------------------| B |
| |-----------------------| |
| |-----------------------| |
+---+ +---+
To measure the performance metrics of every member link of a LAG,
multiple sessions (one session for each member link) need to be
established between the two endpoints that are connected by the LAG.
These sessions are called "micro sessions" in the remainder of this
document. Although micro sessions are in fact STAMP sessions established
on member links of a LAG, test packets of micro sessions MUST carry
member link information for validation.All micro sessions of a LAG share the same Sender IP Address and
Receiver IP Address. As for the UDP port, the micro sessions
may share the same Sender Port and Receiver Port pair or each micro
session may be configured with a different Sender Port and Receiver Port
pair. From the operational point of view, the former is simpler and
is RECOMMENDED.Test packets of a micro session MUST carry the member link
information for validation checks. For example, when a micro STAMP
Session-Sender receives a reflected test packet, it checks whether the
test packet is from the expected member link. The member link
information is encoded in the Micro-session ID TLV introduced in ,
which also provides a detailed description about member link
validation.A micro STAMP Session-Sender MAY include the Follow-Up Telemetry TLV to request information
from the micro Session-Reflector. This timestamp might be important for
the micro Session-Sender, as it improves the accuracy of network delay
measurement by minimizing the impact of egress queuing delays on the
measurement.Member Link ValidationTest packets MUST carry member link information in the Micro-session ID
TLV introduced in this section for validation checks. The micro
Session-Sender verifies whether the test packet is received from the
expected member link. It also verifies whether the packet is sent from
the expected member link at the Reflector side. The micro
Session-Reflector verifies whether the test packet is received from the
expected member link.Micro-session ID TLVThe STAMP TLV mechanism extends STAMP
test packets with one or more optional TLVs. This document defines the
TLV Type (value 11) for the Micro-session ID TLV that carries the
micro STAMP Session-Sender member link identifier and
Session-Reflector member link identifier in the Sender Micro-session ID
field and the Reflector Micro-session ID field, respectively. The format of
the Micro-session ID TLV is shown as follows:Micro-session ID TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type = 11 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Micro-session ID | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 octet in length):
This field is defined to indicate this TLV
is a Micro-session ID TLV. Value 11 has been allocated by IANA
().
Length (2 octets in length):
This field is defined to carry the length
of the Value field in octets. The Length field value MUST be
4.
Sender Micro-session ID (2 octets in length):
This field is defined
to carry the LAG member link identifier of the Sender side. In the
future, it may be used generically to cover use cases beyond LAGs.
The value of this field MUST be unique within a STAMP session at
the Session-Sender.
Reflector Micro-session ID (2 octets in length):
This field is
defined to carry the LAG member link identifier of the Reflector
side. In the future, it may be used generically to cover use cases
beyond LAGs. The value of this field MUST be unique within a STAMP
session at the Session-Reflector.
Micro STAMP-Test ProceduresThe micro STAMP-Test reuses the procedures as defined in Section
of
STAMP with the following
additions.The micro STAMP Session-Sender MUST send the micro STAMP-Test
packets over the member link with which the session is associated. The
mapping between a micro STAMP session and the Sender/Reflector member
link identifiers can be configured by augmenting the STAMP
YANG. The detailed augmentation is not in the scope of this
document.When sending a test packet, the micro STAMP Session-Sender MUST set
the Sender Micro-session ID field with the member link identifier
associated with the micro STAMP session. If the Session-Sender knows
the Reflector member link identifier, the Reflector Micro-session ID
field MUST be set. Otherwise, the Reflector Micro-session ID field
MUST be zero. The Reflector member link identifier can be obtained
from preconfiguration or learned from data plane (e.g., the reflected
test packet). This document does not specify the way to obtain the
Reflector member link identifier.When the micro STAMP Session-Reflector receives a test packet, if
the Reflector Micro-session ID is not zero, the micro STAMP
Session-Reflector MUST use the Reflector member link identifier to
check whether it is associated with the micro STAMP session. If the
validation fails, the test packet MUST be discarded. If the Reflector
Micro-session ID is zero, it will not be verified. If all validations
passed, the Session-Reflector sends a reflected test packet to the
Session-Sender. The micro STAMP Session-Reflector MUST put the Sender
and Reflector member link identifiers that are associated with the
micro STAMP session in the Sender Micro-session ID and Reflector
Micro-session ID fields, respectively. The Sender member link
identifier is copied from the received test packet.When receiving a reflected test packet, the micro Session-Sender
MUST use the Sender Micro-session ID to validate whether the reflected
test packet is correctly received from the expected member link. If
the validation fails, the test packet MUST be discarded. The micro
Session-Sender MUST use the Reflector Micro-session ID to validate the
Reflector's behavior. If the validation fails, the test packet MUST be
discarded.Two modes of the STAMP Session-Reflector, stateless and stateful,
characterize the expected behavior as described in Section of STAMP. The micro STAMP-Test also supports both
stateless and stateful modes. However, the micro STAMP-Test does not
introduce any additional state to STAMP, i.e., any procedure with
regard to the Micro-session ID is stateless.ApplicabilityThe micro STAMP Session-Sender sends micro Session-Sender packets
with the Micro-session ID TLV. The micro Session-Reflector checks
whether a test packet is received from the member link associated with
the correct micro STAMP session if the Reflector Micro-session ID field
is set. When reflecting, the micro STAMP Session-Reflector copies the
Sender Micro-session ID from the received micro Session-Sender packet to
the micro Session-Reflector packet and sets the Reflector Micro-session
ID field with the member link identifier that is associated with the
micro STAMP session. When receiving the micro Session-Reflector packet,
the micro Session-Sender uses the Sender Micro-session ID to check
whether the packet is received from the member link associated with the
correct micro STAMP session. The micro Session-Sender also use the
Reflector Micro-session ID to validate the Reflector's behavior.IANA ConsiderationsIANA has allocated the following STAMP
TLV Type for the Micro-session ID TLV in the "STAMP TLV Types" registry :
New STAMP TLV Type
Value
Description
Reference
11
Micro-session ID
This Document
Security ConsiderationsThe STAMP extension defined in this document is intended for
deployment in the LAG scenario where Session-Sender and Session-Reflector
are directly connected. As such, it's assumed that a node involved in
a STAMP operation has previously verified the integrity of the
LAG connection and the identity of its one-hop-away peer node.This document does not introduce any additional security issues, and
the security mechanisms defined in and apply in this document.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn 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.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Simple Two-Way Active Measurement ProtocolThis document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.Simple Two-Way Active Measurement Protocol Optional ExtensionsThis document describes optional extensions to Simple Two-way Active Measurement Protocol (STAMP) that enable measurement of performance metrics. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762.Informative ReferencesIEEE Standard for Local and Metropolitan Area Networks -- Link AggregationIEEEA One-way Active Measurement Protocol (OWAMP)The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]A Two-Way Active Measurement Protocol (TWAMP)The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]Active and Passive Metrics and Methods (with Hybrid Types In-Between)This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.Advertising Layer 2 Bundle Member Link Attributes in IS-ISThere are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required.This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members.Simple Two-way Active Measurement Protocol (STAMP) Data ModelEricssonZTE Corp.EricssonCiscoThis document specifies the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG.Work in ProgressAcknowledgementsThe authors would like to thank , , , , and for the valuable comments to this work.Authors' AddressesChina MobileNo. 29 Finance AvenueXicheng DistrictBeijingChinali_zhenqiang@hotmail.comHuaweiChinazhoutianran@huawei.comZTE Corp.Chinaguo.jun2@zte.com.cnEricssonUnited States of Americagregimirsky@gmail.comCisco Systems, Inc.Canadargandhi@cisco.com