IPPM T. Zhou, Ed.
Internet-Draft G. Fioccola
Intended status: Standards Track ZB. Li
Expires: January 3, 2020 Huawei
S. Lee
LG U+
M. Cociglio
Telecom Italia
ZQ. Li
China Mobile
July 2, 2019
Enhanced Alternate Marking Method
draft-zhou-ippm-enhanced-alternate-marking-03
Abstract
This document defines data fields for the alternate marking with
enough space. More information can be considered within the
alternate marking field to facilitate the efficiency and ease the
deployment.
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 3, 2020.
Zhou, Ed., et al. Expires January 3, 2020 [Page 1]
Internet-Draft enhanced-alternate-marking July 2019
Copyright Notice
Copyright (c) 2019 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. Implementing Multipoint Alternate Marking . . . . . . . . . . 4
3.1. PBT vs IOAM . . . . . . . . . . . . . . . . . . . . . . . 4
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The Alternate Marking [RFC8321] technique is an hybrid performance
measurement method, per [RFC7799] classification of measurement
methods. Because this method is based on marking consecutive batches
of packets. It can be used to measure packet loss, latency, and
jitter on live traffic.
For the basic Alternate Marking method, bits are needed to record the
mark. However, in some protocols, no additional bit can be used,
which blocks the wide deployment of the alternate marking technique.
And the basic Alternate Marking method is limited with the
scalability for further extension, i.e, more measurements in addition
to existing use.
This document defines data fields for the alternate marking with
enough space. More information can be considered within the
Zhou, Ed., et al. Expires January 3, 2020 [Page 2]
Internet-Draft enhanced-alternate-marking July 2019
alternate marking field to facilitate the efficiency and ease the
deployment.
Specifically, the flow identifier is applied as an enhancement for
the basic Alternate Marking when determining packet loss and packet
delay measurement. The flow identifier helps the data plane to
identify the specific flow, hence to do the processing with respect
to the Alternate Marking. It also simplifies the export by directly
being encapsulated as the index for the associated metrics.
PBT-M [I-D.song-ippm-postcard-based-telemetry] is an variation of
Postcard-based Telemetry (PBT) with packet Marking. One marking bit
is set in the user packet at the path head node, if its path-
associated data need to be collected. At each PBT-aware node, if the
mark is detected, a postcard (i.e., the dedicated telemetry packet
triggered by a marked user packet) is generated and sent to a
collector. The postcard contains the data requested by the
management plane. As an example, the requested data can be
configured by the management plane through data set templates (as in
IPFIX [RFC7011]). This alternate marking bit can choose user packet
on demand, e.g., periodically or triggered by condition meet, for
telemetry.
2. Data Fields Format
The following figure shows the data fields format for enhanced
alternate marking. This data is expected to be encapuslated to
specific transports.
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
+---------------------------------------+-+-+-+-----------------+
| FlowID |L|D|M| Reserved |
+---------------------------------------+-+-+-+-----------------+
where:
o FlowID - 20 bits unsigned integer. Flow identifier field is to
uniquely identify a monitored flow within the measurement domain.
The field is set at the engress node. The FlowID can be uniformly
assigned by the central controller or algorithmically generated by
the engress node. The latter approach cannot guarantee the
uniqueness of FlowID, yet the conflict probability is small due to
the large FlowID space.
o L - Loss flag as defined in [RFC8321];
o D - Delay flag as defined in [RFC8321];
Zhou, Ed., et al. Expires January 3, 2020 [Page 3]
Internet-Draft enhanced-alternate-marking July 2019
o M - Marking bit as defined in PBT-M
[I-D.song-ippm-postcard-based-telemetry];
o Reserved - is reserved for further use. These bits MUST be set to
zero.
3. Implementing Multipoint Alternate Marking
There are some considerations to do on how to manage the general
Multipoint Alternate Marking application in order to get more
adaptable performance measurement.
[I-D.ietf-ippm-multipoint-alt-mark] introduces the network clustering
approach for Alternate Marking: the network clusters partition can be
done at different levels to perform the needed degree of detail. The
Network Management can use an intelligent strategy: it can start
without examining in depth, and, in case of problems (i.e. measured
packet loss or too high delay), various filtering criteria can be
specified in order to perform a detailed analysis by using different
combination of clusters or, at the limit, a per-flow measurement.
3.1. PBT vs IOAM
In theory, both IOAM ([I-D.ietf-ippm-ioam-data]) and PBT
([I-D.song-ippm-postcard-based-telemetry]) could include the base
Alternate Marking method. In practice, PBT-M supports one bit to
encode the alternate marking method. But the more general
implementation of Multipoint Alternate Marking, described in
[I-D.ietf-ippm-multipoint-alt-mark], needs a centralized Data
Collector and Network Management to allow the intelligent and
flexible Alternate Marking algorithm. For this purpose, the PostCard
based Telemetry Header can really be useful.
[I-D.song-ippm-postcard-based-telemetry] introduces the architecture
to directly export the telemetry data from network nodes to a
collector through separated OAM packets called postcards.
The overall architecture of PBT and the closed loop between Nodes,
Telemetry Data Collector and Network Management enables exactly the
application of the network clustering approach for Alternate Marking.
4. Implementation Status
[Note: This entire section should be removed by RFC Editor before the
RFC publication.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Zhou, Ed., et al. Expires January 3, 2020 [Page 4]
Internet-Draft enhanced-alternate-marking July 2019
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist. According to RFC 7942, "this will allow reviewers and working
groups to assign due consideration to documents that have the benefit
of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this
information as they see fit".
Huawei implemented the proposal described in this document based on
the NE40E router. The device can process the data fields in the
network processor in the fast path. Together with Huawei NCE
controller, the solution can provide very high precision per hop
packet loss detection and delay measurement. The product is ready
for MPLS based network and tested with LG U+, China Mobile and China
Unicom in mobile backhaul. The IPv6 and SRv6 based demonstration is
also implemented. Please contact Tianran Zhou
(zhoutianran@huawei.com) for the details.
5. Security Considerations
TBD
6. IANA Considerations
This document has no request to IANA.
7. Acknowledgements
The authors of this document would like to thank Haoyu Song for the
PBT-M contribution.
8. References
8.1. Normative References
[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>.
Zhou, Ed., et al. Expires January 3, 2020 [Page 5]
Internet-Draft enhanced-alternate-marking July 2019
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[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>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[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>.
8.2. Informative References
[I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-05 (work in progress), March 2019.
[I-D.ietf-ippm-multipoint-alt-mark]
Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto,
"Multipoint Alternate Marking method for passive and
hybrid performance monitoring", draft-ietf-ippm-
multipoint-alt-mark-02 (work in progress), July 2019.
[I-D.song-ippm-postcard-based-telemetry]
Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee,
"Postcard-based On-Path Flow Data Telemetry", draft-song-
ippm-postcard-based-telemetry-04 (work in progress), June
2019.
Authors' Addresses
Zhou, Ed., et al. Expires January 3, 2020 [Page 6]
Internet-Draft enhanced-alternate-marking July 2019
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
Zhenbin Li
Huawei
156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.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 3, 2020 [Page 7]
Internet-Draft enhanced-alternate-marking July 2019
Zhenqiang Li
China Mobile
Beijing
China
Email: lizhenqiang@chinamobile.com
Zhou, Ed., et al. Expires January 3, 2020 [Page 8]