IPPM T. Zhou, Ed.
Internet-Draft G. Fioccola
Intended status: Standards Track Huawei
Expires: January 12, 2022 Y. Liu
China Mobile
S. Lee
LG U+
M. Cociglio
Telecom Italia
W. Li
Huawei
July 11, 2021
Enhanced Alternate Marking Method
draft-zhou-ippm-enhanced-alternate-marking-07
Abstract
This document extends the IPv6 Alternate Marking Option, defined in
IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark], to provide the
enhanced capabilities and allow advanced functionalities.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 January 12, 2022.
Zhou, Ed., et al. Expires January 12, 2022 [Page 1]
Internet-Draft enhanced-alternate-marking July 2021
Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Data Fields Format . . . . . . . . . . . . . . . . . . . . . 3
3. Enhanced Alternate Marking capabilities . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The Alternate Marking [RFC8321] and Multipoint Alternate Marking
[RFC8889] define the Alternate Marking technique that is an 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.
IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] applies the
Alternate Marking Method to the IPv6 protocol, and defines Extension
Header Option to encode Alternate Marking Method for both Hop-by-Hop
Options Header and Destination Options Header. Similarly, SRv6
AltMark [I-D.fz-spring-srv6-alt-mark] defines how Alternate Marking
data is carried as SRH TLV.
While the AltMark Option implements the basic alternate marking
method, this document defines the extended data fields for the
AltMark Option and provides the enhanced capabilities.
Zhou, Ed., et al. Expires January 12, 2022 [Page 2]
Internet-Draft enhanced-alternate-marking July 2021
It is worth mentioning that the enhanced capabilities are intended
for further use and are optional.
2. Data Fields Format
The Data Fields format is represented in the next figure. An 8 bits
NextHeader field is allocated from the Reserved field of IPv6 AltMark
Option [I-D.ietf-6man-ipv6-alt-mark].
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| R | NextHeader |
+---------------------------------------+-+-+---+---------------+
The NextHeader field is used to indicate the extended data fields
which are used for enhanced capabilities. When the NextHeader is 0,
there is no extended data field attached. Value 1-8 are reserved for
private use.
The following figure shows the extended data fields format when the
NextHeader value is 9.
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 | R |
+---------------------------------------------------------------+
where:
o FlowMonID Ext - 20 bits unsigned integer. This is used to extend
the FlowMonID to reduce the conflict when random allocation is
applied. The disambiguation of the FlowMonID field is discussed
in IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark].
o Flag - A 4 bits flag to indicate the special purpose usage.
o Len - Length. It indicates the length of extension headers.
o MetaInfo - A 16 bits Bitmap to indicate more meta data attached
for the enhanced function.
o R - Reserved for further use. These bits MUST be set to zero.
Zhou, Ed., et al. Expires January 12, 2022 [Page 3]
Internet-Draft enhanced-alternate-marking July 2021
The Flag is defined as follows:
o bit 1 - Flow direction identification, F bit. F=1, indicates that
the flow direction is forward. F=0, indicates the flow direction
is backward.
o bit 3 - Measurement mode, M bit. M=1, indicates that it is for
hop-by-hop monitoring. M=0, indicates that it is for end-to-end
monitoring.
o others - Reserved.
3. Enhanced Alternate Marking capabilities
The extended data fields presented in the previous section can be
used for several uses. Some possible applications can be:
1. shortest marking periods of single marking method for thicker
packet loss measurements.
2. more dense delay measurements than double marking method (down to
each packet).
3. increase the entropy of flow monitoring identifier by extending
the size of FlowMonID.
4. automatically set up the backward direction flow monitoring.
5. and so on.
4. Security Considerations
IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] 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 be applied in a
specific limited domain, as also mentioned in [RFC8799].
5. IANA Considerations
This document has no request to IANA.
6. References
Zhou, Ed., et al. Expires January 12, 2022 [Page 4]
Internet-Draft enhanced-alternate-marking July 2021
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", draft-
fz-spring-srv6-alt-mark-00 (work in progress), January
2021.
[I-D.ietf-6man-ipv6-alt-mark]
Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate Marking Method",
draft-ietf-6man-ipv6-alt-mark-04 (work in progress), March
2021.
[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>.
[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>.
6.2. Informative References
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[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>.
[RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto,
"Multipoint Alternate-Marking Method for Passive and
Hybrid Performance Monitoring", RFC 8889,
DOI 10.17487/RFC8889, August 2020,
<https://www.rfc-editor.org/info/rfc8889>.
Authors' Addresses
Zhou, Ed., et al. Expires January 12, 2022 [Page 5]
Internet-Draft enhanced-alternate-marking July 2021
Tianran Zhou
Huawei
156 Beiqing Rd.
Beijing 100095
China
Email: zhoutianran@huawei.com
Giuseppe Fioccola
Huawei
Riesstrasse, 25
Munich 80992
Germany
Email: giuseppe.fioccola@huawei.com
Yisong Liu
China Mobile
Beijing
China
Email: liuyisong@chinamobile.com
Shinyoung Lee
LG U+
71, Magokjungang 8-ro, Gangseo-gu
Seoul
Republic of Korea
Email: leesy@lguplus.co.kr
Mauro Cociglio
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: mauro.cociglio@telecomitalia.it
Zhou, Ed., et al. Expires January 12, 2022 [Page 6]
Internet-Draft enhanced-alternate-marking July 2021
Weidong Li
Huawei
156 Beiqing Rd.
Beijing 100095
China
Email: poly.li@huawei.com
Zhou, Ed., et al. Expires January 12, 2022 [Page 7]