IPPM T. Zhou, Ed.
Internet-Draft G. Fioccola
Intended status: Standards Track Huawei
Expires: 2 September 2023 Y. Liu
China Mobile
M. Cociglio
Telecom Italia
S. Lee
LG U+
W. Li
Huawei
1 March 2023
Enhanced Alternate Marking Method
draft-zhou-ippm-enhanced-alternate-marking-12
Abstract
This document extends the IPv6 Alternate Marking Option to provide
enhanced capabilities and allow advanced functionalities. With this
extension, it can be possible to perform thicker packet loss
measurements and more dense delay measurements with no limitation for
the number of concurrent flows under monitoring.
Status of This Memo
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 2 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhou, et al. Expires 2 September 2023 [Page 1]
Internet-Draft enhanced-alternate-marking March 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Data Fields Format . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The Alternate Marking [RFC9341] and Multipoint Alternate Marking
[RFC9342] define the Alternate Marking technique that is a hybrid
performance measurement method, per [RFC7799] classification of
measurement methods. This method is based on marking consecutive
batches of packets and it can be used to measure packet loss,
latency, and jitter on live traffic.
The IPv6 AltMark Option [RFC9343] applies the Alternate Marking
Method to IPv6, and defines an Extension Header Option to encode the
Alternate Marking Method for both the Hop-by-Hop Options Header and
the Destination Options Header. Similarly, SRv6 AltMark
[I-D.fz-spring-srv6-alt-mark] defines how Alternate Marking data is
carried as a TLV in the Segment Routing Header.
While the IPv6 AltMark Option implements the basic alternate marking
methodology, this document defines extended data fields for the
AltMark Option and provides enhanced capabilities to overcome some
challenges and enable future proof applications.
It is worth mentioning that the enhanced capabilities are intended
for further use and are optional.
Some possible enhanced applications MAY be:
Zhou, et al. Expires 2 September 2023 [Page 2]
Internet-Draft enhanced-alternate-marking March 2023
1. thicker packet loss measurements: the single marking method of
the base AltMark Option can be extended with additional marking
bits in order to get shortest marking periods under the same
timing conditions.
2. more dense delay measurements: than double marking method of the
base AltMark Option can be extended with additional marking bits
in order to identify down to each packet as delay sample.
3. increase the number of concurrent flows under monitoring: if the
20-bit FlowMonID is set independently and pseudo randomly, there
is a 50% chance of collision for 1206 flows. The size of
FlowMonIDcan can be extended to raise the entropy and therefore
to increase the number of concurrent flows that can be monitored.
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Data Fields Format
The Data Fields format is represented in Figure 1. A 4-bit
NH(NextHeader) field is allocated from the Reserved field of IPv6
AltMark Option [RFC9343]. It is worth highlighting that remaining
bits of the former Reserved field continue to be reserved.
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
+---------------------------------------+-+-+-----------+-------+
| FlowMonID |L|D| Reserved | NH |
+---------------------------------------+-+-+-----------+-------+
Figure 1: Data fields indicator for enhanced capabilities
The NH (NextHeader) field is used to indicate the extended data
fields which are used for enhanced capabilities:
* NextHeader value of 0x00 is reserved for backward compatibility.
It means that there is no extended data field attached.
* NextHeader values of 0x01-0x08 are reserved for private use or for
experimentation.
Zhou, et al. Expires 2 September 2023 [Page 3]
Internet-Draft enhanced-alternate-marking March 2023
* NextHeader value of 0x09 indicates the extended data fields. The
format is showed in Figure 2.
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
+---------------------------------------+-------+-------+-------+
| FlowMonID Ext | Flag | Len | R |
+-------------------------------+-------+-------+-------+-------+
| MetaInfo | Padding (variable) |
+-------------------------------+-------------------------------+
// Padding (variable) //
+-------------------------------+-------------------------------+
Figure 2: Data fields extension for enhanced alternate marking
where:
* FlowMonID Ext - 20 bits unsigned integer. This is used to extend
the FlowMonID in order to reduce the conflict when random
allocation is applied. The disambiguation of the FlowMonID field
is discussed in IPv6 AltMark Option [RFC9343].
* Flag - A 4-bit flag to indicate the special purpose usage (see
below).
* Len - Length. It indicates the length of the enhanced alternate
marking extension in bytes.
* R - Reserved for further use. These bits MUST be set to zero on
transmission and ignored on receipt.
* MetaInfo - A 16-bit Bitmap to indicate more meta data attached for
the enhanced function (see below).
* Padding - These bits MUST be set to zero when not being used.
The Flag is defined in Figure 3 as:
bit 0: Measurement mode, M bit. If M=0, it indicates that it is
for hop-by-hop monitoring. If M=1, it indicates that it is for
end-to-end monitoring.
bit 2: Flow direction identification, F bit. This flag is used in
the case backward direction flow monitoring is requested to be set
up automatically. If F=1, it indicates that the flow direction is
forward. If F=0, it indicates that the flow direction is
backward.
Zhou, et al. Expires 2 September 2023 [Page 4]
Internet-Draft enhanced-alternate-marking March 2023
bit 1 and bit 3: Reserved (shown as R). These bits MUST be set to
zero and ignored on receipt.
0 1 2 3
+-------+
|M|R|F|R|
+-------+
Figure 3: Flag data field
The MetaInfo is defined in the following Figure 4 as a bit map:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-------------------------------+
| MetaInfo |
+-------------------------------+
Figure 4: MetaInfo data field
bit 0: if set to 1, it indicates a 6 bytes Timestamp that is
attached as Padding after the MetaInfo. Timestamp(s) stands for
the number of seconds in the timestamp. It will overwrite the
Padding after MetaInfo. Timestamp(ns) stands for the number of
sub-seconds in the timestamp with the unit of nano second. This
Timestamp is filled by the encapsulation node, and is taken all
the way to the decapsulation node. So that all the intermediate
nodes could compare it with its local time, and measure the one
way delay.
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
+-------------------------------+
| Timestamp(s) |
+-------------------------------+-------------------------------+
| Timestamp(ns) |
+---------------------------------------------------------------+
Figure 5: Timestamp data field
bit 1: if set to 1, it indicates the control information with the
following data format that is attached as Padding after the
MetaInfo:
Zhou, et al. Expires 2 September 2023 [Page 5]
Internet-Draft enhanced-alternate-marking March 2023
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
+---------------+---------------+-----------+-------------------+
| DIP Mask | SIP Mask | Control | Period |
+---------------+---------------+-----------+-------------------+
Figure 6: Control words for backward direction flow monitoring
This is used to set up the backward direction flow monitoring.
Where:
DIP Mask: it is the length of the destination IP prefix.
SIP Mask: it is the length of the source IP prefix.
Control: it indicates more match fields to set up the backward
direction flow monitoring.
Period: it indicates the alternate marking period with the unit
of second.
bit 2: if set to 1, it indicates a 4 bytes Sequence number with
the following data format that is attached as Padding after the
MetaInfo. The unique Sequence could be used to detect the out-of-
order packets, in addition to the normal loss measurement. More
over, the Sequence can be used together with the latency
measurement, so as to get the per packet timestamp.
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
+---------------------------------------------------------------+
| Sequence |
+---------------------------------------------------------------+
Figure 7: Sequence number data field
It is worth noting that the meta data information forming the Padding
and specified above in Figure 5, Figure 6 and Figure 7 must be
ordered according to the order of the MetaInfo bits.
3. Security Considerations
IPv6 AltMark Option [RFC9343] analyzes different security concerns
and related solutions. These aspects are valid and applicable also
to this document. In particular the fundamental security requirement
is that Alternate Marking MUST only be applied in a specific limited
domain, as also mentioned in [RFC8799].
Zhou, et al. Expires 2 September 2023 [Page 6]
Internet-Draft enhanced-alternate-marking March 2023
4. IANA Considerations
This document has no request to IANA.
5. Acknowledgements
The authors would like to thank Adrian Farrel for the comments and
review of this document.
6. References
6.1. Normative References
[I-D.fz-spring-srv6-alt-mark]
Fioccola, G., Zhou, T., and M. Cociglio, "Segment Routing
Header encapsulation for Alternate Marking Method", Work
in Progress, Internet-Draft, draft-fz-spring-srv6-alt-
mark-04, 31 January 2023,
<https://datatracker.ietf.org/doc/html/draft-fz-spring-
srv6-alt-mark-04>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
DOI 10.17487/RFC9342, December 2022,
<https://www.rfc-editor.org/info/rfc9342>.
[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/info/rfc9343>.
6.2. Informative References
Zhou, et al. Expires 2 September 2023 [Page 7]
Internet-Draft enhanced-alternate-marking March 2023
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
Authors' Addresses
Tianran Zhou (editor)
Huawei
156 Beiqing Rd.
Beijing
100095
China
Email: zhoutianran@huawei.com
Giuseppe Fioccola
Huawei
Riesstrasse, 25
80992 Munich
Germany
Email: giuseppe.fioccola@huawei.com
Yisong Liu
China Mobile
Beijing
China
Email: liuyisong@chinamobile.com
Mauro Cociglio
Telecom Italia
Email: mauro.cociglio@outlook.com
Shinyoung Lee
LG U+
71, Magokjungang 8-ro, Gangseo-gu
Seoul
Republic of Korea
Email: leesy@lguplus.co.kr
Zhou, et al. Expires 2 September 2023 [Page 8]
Internet-Draft enhanced-alternate-marking March 2023
Weidong Li
Huawei
156 Beiqing Rd.
Beijing
100095
China
Email: poly.li@huawei.com
Zhou, et al. Expires 2 September 2023 [Page 9]