IPv6 Application of the Alternate Marking Method
draft-fz-6man-ipv6-alt-mark-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Giuseppe Fioccola , Tianran Zhou , Mauro Cociglio | ||
| Last updated | 2019-07-22 | ||
| Replaces | draft-fioccola-v6ops-ipv6-alt-mark | ||
| Replaced by | draft-ietf-6man-ipv6-alt-mark, RFC 9343 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fz-6man-ipv6-alt-mark-00
6MAN Working Group G. Fioccola
Internet-Draft T. Zhou
Intended status: Standards Track Huawei
Expires: January 23, 2020 M. Cociglio
Telecom Italia
July 22, 2019
IPv6 Application of the Alternate Marking Method
draft-fz-6man-ipv6-alt-mark-00
Abstract
This document describes how the alternate marking method in [RFC8321]
and [I-D.ietf-ippm-multipoint-alt-mark] can be used as the passive
performance measurement method in an IPv6 domain and reports
implementation considerations. It proposes how to define a new
encapsulation header to encode alternate marking technique.
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 23, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fioccola, et al. Expires January 23, 2020 [Page 1]
Internet-Draft IPv6 with AMM July 2019
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. IPv6 application of Alternate Marking . . . . . . . . . . . . 3
3. IPv6 Extension Headers as Marking Field . . . . . . . . . . . 3
3.1. Definition of the AltMark Extension Header . . . . . . . 3
3.1.1. Data Fields Format . . . . . . . . . . . . . . . . . 4
3.1.2. AltMark: Destination Option and Hop-by-Hop Option . . 5
4. Alternate Marking Method Operation . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
[RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe passive
performance measurement method, which can be used to measure packet
loss, latency and jitter on live traffic. Since this method is based
on marking consecutive batches of packets, the method often referred
as Alternate Marking Method.
This document defines how the alternate marking method can be used to
measure packet loss and delay metrics of IPv6 and SRv6.
The IPv6 Header Format defined in [RFC8200] introduces the format of
the IPv6 addresses, the Extension Headers in the base IPv6 Header and
the availability of a 20-bit flow label, that can be considered for
the application of the Alternate Marking methodology. In this
respect, [I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary on the
possible implementation options for the application of the alternate
marking method in an IPv6 domain.
[I-D.zhou-ippm-enhanced-alternate-marking] defines the data field for
the alternate marking in order to generalize its application. More
Fioccola, et al. Expires January 23, 2020 [Page 2]
Internet-Draft IPv6 with AMM July 2019
information can be considered within the alternate marking field to
facilitate the efficiency and ease the deployment.
For the overall application of the methodology
[I-D.song-ippm-postcard-based-telemetry] introduces a new approach
named Postcard-Based Telemetry (PBT). It includes alternative ways
which can collect the same data of In-band OAM
([I-D.ietf-ippm-ioam-data]) but avoid or mitigate the In-band OAM
issues. There are two variations of PBT: PBT-M and PBT-I. PBT-M
marks the user packets (set one bit) or configure the flow filter to
invoke the data collection. At each PBT-aware node, if the mark is
detected, a postcard is generated and sent to a collector. Instead,
PBT-I can be seen as a trade-off between IOAM and PBT-M. It needs to
add a fixed length instruction header to user packets for OAM data
collection, called Per-Hop Postcard (PHP), but, unlike IOAM, data are
exported through dedicated postcards.
Both PBT-M and PBT-I variations can allow the implementation of
[RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] and this is also
discussed in [I-D.zhou-ippm-enhanced-alternate-marking].
2. IPv6 application of Alternate Marking
The application of the alternate marking requires a marking field.
Several alternatives have been analysed in
[I-D.fioccola-v6ops-ipv6-alt-mark] (Extension Header, IPv6 Address,
Flow Label). Anyway the best choice would be the use of an Extension
Header (EH).
3. IPv6 Extension Headers as Marking Field
A new type of EH can be defined for this scope. In this way there is
enough space to implement and optimize the deployment of the
Alternate Marking method.
A possibility can be to use a Destination or a Hop-By-Hop(HBH)
Extension Header(EH). The assumption is that an EH with an alternate
marking measurement option can be defined. The router processing can
be easily optimized to handle this use case.
3.1. Definition of the AltMark Extension Header
The desired choice is to define a new Extension Header.
[I-D.zhou-ippm-enhanced-alternate-marking] generalizes the data
fields for the alternate marking method and inspired the layout.
Fioccola, et al. Expires January 23, 2020 [Page 3]
Internet-Draft IPv6 with AMM July 2019
3.1.1. Data Fields Format
The following figure shows the data fields format for enhanced
alternate marking. This data is expected to be encapsulated to
specific transports, in this case the IPv6 Option Header named
AltMark.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowID |L|D|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
o Option Type - 8 bit identifier of the type of option. It needs to
be allocated.
o Opt Data Len - 8 bit unsigned integer. Length of the Option Data
field of this option, in octets.
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 ingress node. The FlowID can be uniformly
assigned by the central controller or algorithmically generated by
the ingress 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];
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.
Note that PBT-I [I-D.song-ippm-postcard-based-telemetry] can also be
used and the marking fields, in this case, are included in the PHP
Header Format as described in
[I-D.song-ippm-postcard-based-telemetry].
Fioccola, et al. Expires January 23, 2020 [Page 4]
Internet-Draft IPv6 with AMM July 2019
3.1.2. AltMark: Destination Option and Hop-by-Hop Option
Using a new EH assumes that all routers in the domain support this
type of headers, but, beyond backward compatibility, the new AltMark
Option Layout seems the best way to implement the Alternate Marking
method.
It is important to highlight that the Option Layout can be used both
as Destination Option and as Hop-By-Hop Option depending on the Use
Cases. In general, it is needed to perform end-to-end or hop-by-hop
measurements, and the alternate marking methodology in [RFC8321]
allows, by definition, both end-to-end and hop-by-hop performance
measurements.
4. Alternate Marking Method Operation
[RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe in detail
the methodology.
5. Security Considerations
tbc
6. IANA Considerations
The option type should be assigned in IANA's "Destination Options and
Hop-by-Hop Options" registry.
7. Acknowledgements
tbc
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>.
8.2. Informative References
[I-D.fioccola-v6ops-ipv6-alt-mark]
Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6
Performance Measurement with Alternate Marking Method",
draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress),
June 2018.
Fioccola, et al. Expires January 23, 2020 [Page 5]
Internet-Draft IPv6 with AMM July 2019
[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-06 (work in progress), July 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.
[I-D.zhou-ippm-enhanced-alternate-marking]
Zhou, T., Fioccola, G., Li, Z., Lee, S., Cociglio, M., and
Z. Li, "Enhanced Alternate Marking Method", draft-zhou-
ippm-enhanced-alternate-marking-03 (work in progress),
July 2019.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[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>.
Authors' Addresses
Giuseppe Fioccola
Huawei
Riesstrasse, 25
Munich 80992
Germany
Email: giuseppe.fioccola@huawei.com
Fioccola, et al. Expires January 23, 2020 [Page 6]
Internet-Draft IPv6 with AMM July 2019
Tianran Zhou
Huawei
156 Beiqing Rd.
Beijing 100095
China
Email: zhoutianran@huawei.com
Mauro Cociglio
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: mauro.cociglio@telecomitalia.it
Fioccola, et al. Expires January 23, 2020 [Page 7]