Internet DRAFT - draft-chen-detnet-loss-delay
draft-chen-detnet-loss-delay
Network Working Group M. Chen
Internet-Draft A. Malis
Intended status: Standards Track Huawei
Expires: April 26, 2019 October 23, 2018
DetNet Packet Loss and Delay Performance Measurement
draft-chen-detnet-loss-delay-01
Abstract
Deterministic Networking (DetNet) is defined to provide end-to-end
bounded latency and extremely low packet loss rates for critical
flows. It's important to measure and monitor the packet loss rates
and end-to-end delay and delay variation of a DetNet flow path, which
allows evaluation of whether the Service Level Agreements (SLA) of
the provided DetNet services are satisfied. These metrics are also
useful in network/traffic planning, trouble shooting, and network
performance evaluation.
This document defines protocol mechanisms to support passive
Performance Measurement (PM) for DetNet service.
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
BCP14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 April 26, 2019.
Chen & Malis Expires April 26, 2019 [Page 1]
Internet-Draft DetNet PM October 2018
Copyright Notice
Copyright (c) 2018 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. DetNet Control Word based PM . . . . . . . . . . . . . . . . 3
2.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 4
2.2. Packet Delay Measurement . . . . . . . . . . . . . . . . 5
2.3. Alternative Solutions to the "D/L" Bits . . . . . . . . . 6
3. PM for IP-based Encapsulation . . . . . . . . . . . . . . . . 6
4. Extensions to RFC6374 . . . . . . . . . . . . . . . . . . . . 7
4.1. Measurement Interval TLV . . . . . . . . . . . . . . . . 7
4.2. DetNet Control Word TLV . . . . . . . . . . . . . . . . . 7
4.3. Service Label TLV . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Deterministic Networking (DetNet) [I-D.ietf-detnet-architecture] can
provide end-to-end bounded latency and extremely low packet loss
rates for critical flows. This achieved by dedicating network
resources (e.g., link bandwidth and queue buffering) to DetNet flows,
and by replicating packets along multiple paths.
It's important to measure and monitor the packet loss rate and one-
way delay and delay variation of a DetNet flow path in order to
evaluate whether the Service Level Agreements (SLA) of the provided
DetNet services are satisfied. These metrics are also useful in
Chen & Malis Expires April 26, 2019 [Page 2]
Internet-Draft DetNet PM October 2018
network/traffic planning, troubleshooting, and network performance
evaluation.
As defined in [RFC7799], performance measurement can be classified
into Active, Passive and Hybrid measurement. Active measurement is
performed by injecting Operations, Administration, and Maintenance
(OAM) packets to the network to estimate the performance of the
network by measuring the performance of the OAM packets. However,
adding extra traffic can affect the quantities to be measured to some
degree. On the other hand, passive measurement monitors the actual
service traffic, rather than injecting OAM packets to estimate the
traffic performance. Therefore, Passive performance measurement will
not affect the behavior of the real DetNet service, and also provide
more accurate measurement results. Accordingly, this document
defines protocol mechanisms to support Passive PM for DetNet
services.
DetNet defines two encapsulations, an MPLS-based encapsulation
[I-D.ietf-detnet-dp-sol-mpls], and an IP-based encapsulation
[I-D.ietf-detnet-dp-sol-ip]. For the MPLS based encapsulation, a
service layer is introduced, which is supported by a DetNet Service
Label (S-Label) and a DetNet Control Word (d-CW). The S-Label is
used to identify a DetNet flow. The d-CW contains a sequence number
that is designed for supporting the Packet Replication, Elimination,
and Ordering Functions (PREOF). When perform packet loss and delay
measurements, the sequence number can be used for packet accounting
and packet count/timestamp correlation as well.
[RFC6374] defines Loss Measurement (LM) and Delay Measurement (DM)
messages to communicate packet counts, timestamps, and other relevant
information between Measurement Points (MPs). This document defines
three new TLVs to the [RFC6374] LM message and DM messages. Which
are used for communicating the correlation information (e.g.,
sequence number, measurement interval, and service label) that
enables the packet loss and packet delay calculation. The detailed
definitions of these new TLVs are described in Section 3.
2. DetNet Control Word based PM
As discussed above, MPLS-based DetNet encapsulation introduces an
S-Label and a d-CW. This document defines two new flags in the d-CW
(as shown in Figure 1). The L bit is defined to indicate whether the
loss measurement is enabled, and the D bit is defined to indicate
whether the delay measurement is enabled.
Chen & Malis Expires April 26, 2019 [Page 3]
Internet-Draft DetNet PM October 2018
+-----------------+
~ IP/MPLS Tunnel ~
+-----------------+ <--\
| Service Label | |
+-----------------+ +-- Service Layer Header
+----| Control Word | |
| +-----------------+ <--/
| | Payload |
| +-----------------+
|
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+--->|0 0 0 0|L|D| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DetNet Control Word
Where:
o L bit: Loss measurement indicator; 1 means the loss measurement is
enabled, otherwise the loss measurement is not enabled.
o D bit: Delay measurement indicator;1 means the delay measurement
is enabled, otherwise the delay measurement is not enabled. When
a node receive a packet with D bit set, it will timestamp the
packet and copy it for further PM processing.
2.1. Packet Loss Measurement
Assume a DetNet service path between node A and node B, where node A
is the ingress node, and node B is the egress node. To measure the
number of packets transmitted at node A but not received at node B
within a measurement interval, there needs a way to determine which
packets belong to which measurement interval. [RFC6374] uses OAM
packets to demarcate different measurement intervals. However, an
OAM packet-based solution cannot work when there is packet mis-
ordering. This document uses the sequence number to determine to
which measurement interval a packet belongs. Specifically, the
measurement interval number is calculated as the modulo of the
sequence number and a pre-configured constant.
o Measurement Interval = "Sequence Number" mod "Pre-configured
constant".
With this, the ingress and egress nodes can use the sequence number
of a packet to calculate the measurement interval number. The
packets with same interval number belong to the same measurement
interval. Then the packet loss can be calculated as below:
Chen & Malis Expires April 26, 2019 [Page 4]
Internet-Draft DetNet PM October 2018
Loss[n] = A_TxP[n] - B_RxP[n], where:
o A_TxP[n] is the number of packets transmitted at node A within the
No. "n" measurement interval;
o B_RxP[n] is the number of packets received at node B within the
No. "n" measurement interval;
If the calculation is performed at one side of the path, the A_TxP[n]
or B_RxP[n] needs to be sent to the other side. The Loss Measurement
(LM) message defined in [RFC6374] is used to communicate the counts,
in order to correlate the counts from the ingress node with the
counts from the egress node. The extensions to [RFC6374] to
communicate the measurement interval are defined in Section 3.
If the calculation is performed at a centralized controller, then the
A_TxP[n] and B_RxP[n] need to be sent to the controller. The
mechanism for sending counts to a centralized controller is out side
the scope of this document.
2.2. Packet Delay Measurement
To measure the delay of a packet, the D bit of the d-CW MUST be set.
At the ingress node, record the time when sending the packet, with
the timestamp indexed by the sequence number. At the egress node,
when receiving a packet with D bit set, record the time when the
packet was received, with the timestamp indexed by the sequence
number. Then, with the timestamps from the ingress and egress nodes,
and the sequence number, the packet delay can be calculated as below:
Delay[n] = B_RxT[n] - A_TxT[n], where:
o B_RxT[n] identifies the timestamp at node B when receiving the No.
"n" packet;
o A_TxT[n] identifies the timestamp at node A when sending the No.
"n" packet;
Similar to loss measurement, the Delay Measurement (DM) message
defined in [RFC6374] is used to communicate the timestamps when
calculation is performed at either side of a DetNet service path. In
order to correlate the timestamps from the ingress node with the
timestamps from the egress node, extensions to [RFC6374] to
communicate the sequence number and other relevant information are
needed. The detailed definitions of these extensions are described
in Section 3.
Chen & Malis Expires April 26, 2019 [Page 5]
Internet-Draft DetNet PM October 2018
The mechanism for sending timestamps to a centralized controller is
out side the scope of this document.
2.3. Alternative Solutions to the "D/L" Bits
Configuration can be used to indicate whether the delay and/or loss
measurements are enabled on a specific DetNet service flow. This can
be done by through the DetNet configuration model
[I-D.geng-detnet-conf-yang], a PCEP extension, a Command Line
Interface (CLI), or other means.
Another way is to use the signalling protocol as the enabler of
performance measurement. More detail will be added in the future.
[Editor notes:
This document introduces three ways (as summarized below) to enable
PM on a DetNet flow. We'd like to solicit more inputs and comments
from the WG:
1. Indicated by the "D/L" bits: A straightforward way to indicate
when to measure, which packets to measured. The cost is to take
two bits (or at least one bit) away from the sequence number.
2. Configured by CLI or YANG: Normally, it's easy to enable/disable
PM on a DetNet flow. The receiving node may take more time
(e.g., by matching a local configuration item to determine) to
determine whether a packet should be counted, whether a packet
should be timestamped. And it is difficult to support if only
partial packets of a flow need to be measured. This is a common
case for packet delay measurement, where sample measurement is
acceptable and reasonable.
3. Signalled by control protocol: The pros and cons similar to
option 2.
]
3. PM for IP-based Encapsulation
For IP-based encapsulation, since there is no service layer, the d-
CW-based solution as defined in Section 2 can not be applied. The
marking-based solution defined in [RFC8321] can be used. More detail
will be added in future versions.
Chen & Malis Expires April 26, 2019 [Page 6]
Internet-Draft DetNet PM October 2018
4. Extensions to RFC6374
[RFC6374] defines how to communicate the packet counts and timestamps
between measurement points. In order to support passive PM, this
document defines several new TLVs to carry the correlation
information. The correlation information can be used to determine
with which DetNet service path a packet count/timestamp correlates,
and with which measurement interval a packet count correlates, and
with which packet a timestamp correlates.
Three new TLVs to LM and DM messages [RFC6374] are defined in the
following sub-sections.
4.1. Measurement Interval TLV
This document defines a new TLV which is referred to as Measurement
Interval TLV to Loss Measurement message [RFC6374]. The Measurement
Interval TLV carries the measurement interval that is used to
correlate the packet counts from the ingress node with the packet
counts from the egress nodes. Then the packet loss can be calculated
as described in Section 2.
The format of the Measurement Interval TLV is as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Measurement Interval TLV
Where:
o The Type field is two octets in length, and the value is TBD1.
o The Length field is two octets in length, with a value is 4,
indicating the length of the Measurement Interval field.
o The Measurement Interval field is 4 octets in length, and carries
the measurement interval.
4.2. DetNet Control Word TLV
This document defines a new TLV which is referred to as DetNet
Control Word TLV to Delay Measurement message [RFC6374]. The
sequence number of the d-CW is used to correlate the timestamps from
Chen & Malis Expires April 26, 2019 [Page 7]
Internet-Draft DetNet PM October 2018
the ingress node with the timestamp from the egress node. Then the
packet delay can be calculated as described in Section 2.
The format of the DetNet Control Word TLV is as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetNet Control Word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DetNet Control Word TLV
Where:
o The Type field is two octets in length, and the value is TBD2.
o The Length field is two octets in length, with a value is 4,
indicating the length of the DetNet Control Word field.
o The DetNet Control Word is 4 octets in length.
4.3. Service Label TLV
This document defines a new TLV which is referred to as Service Label
TLV to Loss Measurement message and Delay Measurement message
[RFC6374]. The Service Label TLV carries the DetNet S-Label that is
allocated by the receiving node to the DetNet service path that is
being measured. Here, the receiving node can be the egress node, or
an relay node. The S-Label is used to determine to which DetNet
service path the packet counts/timestamps belong.
The format of the Service Label TLV is as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Service Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Service Label TLV
Where:
o The Type field is two octets in length, and the value is TBD3.
Chen & Malis Expires April 26, 2019 [Page 8]
Internet-Draft DetNet PM October 2018
o The Length field is two octets in length, with a value is 4,
indicating the length of the Reserved and the Service Label
fields.
o The Service Label field is 20-bit in length.
5. IANA Considerations
IANA is requested to allocate the following TLV types from the "MPLS
Loss/Delay Measurement TLV Object" sub-registry of the "Generic
Associated Channel (G-ACh) Parameters" registry:
Type Description Reference
---- --------------------------------- ---------
TBD1 Measurement Interval This document
TBD2 DetNet Control Word This document
TBD3 DetNet Service Label This document
6. Security Considerations
This document enables the use of Passive monitoring to determine the
SLA conformance of DetNet service flows, and does not introduce any
additional Active monitoring packets to the network. As a result,
this document introduces no new security considerations beyond those
already described in Section 8 of [RFC6374] and Section 5 of
[RFC7799].
7. Acknowledgements
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>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<https://www.rfc-editor.org/info/rfc6374>.
[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>.
Chen & Malis Expires April 26, 2019 [Page 9]
Internet-Draft DetNet PM October 2018
8.2. Informative References
[I-D.geng-detnet-conf-yang]
Geng, X., Chen, M., Li, Z., and R. Rahman, "DetNet
Configuration YANG Model", draft-geng-detnet-conf-yang-06
(work in progress), October 2018.
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-09 (work in progress), October 2018.
[I-D.ietf-detnet-dp-sol-ip]
Korhonen, J. and B. Varga, "DetNet IP Data Plane
Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in
progress), October 2018.
[I-D.ietf-detnet-dp-sol-mpls]
Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in
progress), October 2018.
[I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-19 (work in progress), October 2018.
[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>.
[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
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
Andrew G. Malis
Huawei
Email: agmalis@gmail.com
Chen & Malis Expires April 26, 2019 [Page 10]
