draft-ietf-detnet-bounded-latency-04.txt   draft-ietf-detnet-bounded-latency-05.txt 
DetNet N. Finn DetNet N. Finn
Internet-Draft Huawei Technologies Co. Ltd Internet-Draft Huawei Technologies Co. Ltd
Intended status: Informational J-Y. Le Boudec Intended status: Informational J-Y. Le Boudec
Expires: September 23, 2021 E. Mohammadpour Expires: October 17, 2021 E. Mohammadpour
EPFL EPFL
J. Zhang J. Zhang
Huawei Technologies Co. Ltd Huawei Technologies Co. Ltd
B. Varga B. Varga
J. Farkas J. Farkas
Ericsson Ericsson
March 22, 2021 April 15, 2021
DetNet Bounded Latency DetNet Bounded Latency
draft-ietf-detnet-bounded-latency-04 draft-ietf-detnet-bounded-latency-05
Abstract Abstract
This document references specific queuing mechanisms, defined in This document references specific queuing mechanisms, defined in
other documents, that can be used to control packet transmission at other documents, that can be used to control packet transmission at
each output port and achieve the DetNet qualities of service. This each output port and achieve the DetNet qualities of service. This
document presents a timing model for sources, destinations, and the document presents a timing model for sources, destinations, and the
DetNet transit nodes that relay packets that is applicable to all of DetNet transit nodes that relay packets that is applicable to all of
those referenced queuing mechanisms. Using the model presented in those referenced queuing mechanisms. Using the model presented in
this document, it should be possible for an implementor, user, or this document, it should be possible for an implementor, user, or
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 23, 2021. This Internet-Draft will expire on October 17, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
4.3. Ingress considerations . . . . . . . . . . . . . . . . . 10 4.3. Ingress considerations . . . . . . . . . . . . . . . . . 10
4.4. Interspersed DetNet-unaware transit nodes . . . . . . . . 11 4.4. Interspersed DetNet-unaware transit nodes . . . . . . . . 11
5. Achieving zero congestion loss . . . . . . . . . . . . . . . 11 5. Achieving zero congestion loss . . . . . . . . . . . . . . . 11
6. Queuing techniques . . . . . . . . . . . . . . . . . . . . . 12 6. Queuing techniques . . . . . . . . . . . . . . . . . . . . . 12
6.1. Queuing data model . . . . . . . . . . . . . . . . . . . 13 6.1. Queuing data model . . . . . . . . . . . . . . . . . . . 13
6.2. Frame Preemption . . . . . . . . . . . . . . . . . . . . 15 6.2. Frame Preemption . . . . . . . . . . . . . . . . . . . . 15
6.3. Time Aware Shaper . . . . . . . . . . . . . . . . . . . . 15 6.3. Time Aware Shaper . . . . . . . . . . . . . . . . . . . . 15
6.4. Credit-Based Shaper with Asynchronous Traffic Shaping . . 16 6.4. Credit-Based Shaper with Asynchronous Traffic Shaping . . 16
6.4.1. Delay Bound Calculation . . . . . . . . . . . . . . . 18 6.4.1. Delay Bound Calculation . . . . . . . . . . . . . . . 18
6.4.2. Flow Admission . . . . . . . . . . . . . . . . . . . 19 6.4.2. Flow Admission . . . . . . . . . . . . . . . . . . . 19
6.5. IntServ . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.5. Guaranteed-Service IntServ . . . . . . . . . . . . . . . 20
6.6. Cyclic Queuing and Forwarding . . . . . . . . . . . . . . 21 6.6. Cyclic Queuing and Forwarding . . . . . . . . . . . . . . 21
7. Example application on DetNet IP network . . . . . . . . . . 22 7. Example application on DetNet IP network . . . . . . . . . . 22
8. Security considerations . . . . . . . . . . . . . . . . . . . 24 8. Security considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
skipping to change at page 9, line 28 skipping to change at page 9, line 28
flow traverses one DetNet transit node. flow traverses one DetNet transit node.
4.2.1. Per-flow queuing mechanisms 4.2.1. Per-flow queuing mechanisms
With such mechanisms, each flow uses a separate queue inside every With such mechanisms, each flow uses a separate queue inside every
node. The service for each queue is abstracted with a guaranteed node. The service for each queue is abstracted with a guaranteed
rate and a latency. For every DetNet flow, a per-node delay bound as rate and a latency. For every DetNet flow, a per-node delay bound as
well as an end-to-end delay bound can be computed from the traffic well as an end-to-end delay bound can be computed from the traffic
specification of this DetNet flow at its source and from the values specification of this DetNet flow at its source and from the values
of rates and latencies at all nodes along its path. The per-flow of rates and latencies at all nodes along its path. The per-flow
queuing is used in IntServ. Details of calculation for IntServ are queuing is used in Guaranteed-Service IntServ. Details of
described in Section 6.5. calculation for Guaranteed-Service IntServ are described in
Section 6.5.
4.2.2. Aggregate queuing mechanisms 4.2.2. Aggregate queuing mechanisms
With such mechanisms, multiple flows are aggregated into macro-flows With such mechanisms, multiple flows are aggregated into macro-flows
and there is one FIFO queue per macro-flow. A practical example is and there is one FIFO queue per macro-flow. A practical example is
the credit-based shaper defined in section 8.6.8.2 of [IEEE8021Q] the credit-based shaper defined in section 8.6.8.2 of [IEEE8021Q]
where a macro-flow is called a "class". One key issue in this where a macro-flow is called a "class". One key issue in this
context is how to deal with the burstiness cascade: individual flows context is how to deal with the burstiness cascade: individual flows
that share a resource dedicated to a macro-flow may see their that share a resource dedicated to a macro-flow may see their
burstiness increase, which may in turn cause increased burstiness to burstiness increase, which may in turn cause increased burstiness to
skipping to change at page 16, line 29 skipping to change at page 16, line 29
priority. Flows of classes A and B are together referred as AVB priority. Flows of classes A and B are together referred as AVB
flows. This model is a subset of Time-Sensitive Networking as flows. This model is a subset of Time-Sensitive Networking as
described next. described next.
Based on the timing model described in Figure 1, the contention Based on the timing model described in Figure 1, the contention
occurs only at the output port of a DetNet transit node; therefore, occurs only at the output port of a DetNet transit node; therefore,
the focus of the rest of this subsection is on the regulator and the focus of the rest of this subsection is on the regulator and
queuing subsystem in the output port of a DetNet transit node. Then, queuing subsystem in the output port of a DetNet transit node. Then,
the input flows are identified using the information in (Section 5.1 the input flows are identified using the information in (Section 5.1
of [RFC8939]). Then they are aggregated into eight macro flows based of [RFC8939]). Then they are aggregated into eight macro flows based
on their traffic classes. We refer to each macro flow as a class. on their DetNet flow aggregate. We refer to each macro flow as a
The output port performs aggregate scheduling with eight queues class. The output port performs aggregate scheduling with eight
(queuing subsystems): one for CDT, one for class A flows, one for queues (queuing subsystems): one for CDT, one for class A flows, one
class B flows, and five for BE traffic denoted as BE0-BE4. The for class B flows, and five for BE traffic denoted as BE0-BE4. The
queuing policy for each queuing subsystem is FIFO. In addition, each queuing policy for each queuing subsystem is FIFO. In addition, each
node output port also performs per-flow regulation for AVB flows node output port also performs per-flow regulation for AVB flows
using an interleaved regulator (IR), called Asynchronous Traffic using an interleaved regulator (IR), called Asynchronous Traffic
Shaper [IEEE8021Qcr]. Thus, at each output port of a node, there is Shaper [IEEE8021Qcr]. Thus, at each output port of a node, there is
one interleaved regulator per-input port and per-class; the one interleaved regulator per-input port and per-class; the
interleaved regulator is mapped to the regulator depicted in interleaved regulator is mapped to the regulator depicted in
Figure 1. The detailed picture of scheduling and regulation Figure 1. The detailed picture of scheduling and regulation
architecture at a node output port is given by Figure 4. The packets architecture at a node output port is given by Figure 4. The packets
received at a node input port for a given class are enqueued in the received at a node input port for a given class are enqueued in the
respective interleaved regulator at the output port. Then, the respective interleaved regulator at the output port. Then, the
skipping to change at page 20, line 29 skipping to change at page 20, line 29
flow. Similarly, when an AVB flow leaves the network, all flow. Similarly, when an AVB flow leaves the network, all
variables R_acc and b_acc along its path must be decremented variables R_acc and b_acc along its path must be decremented
to reflect the removal of the flow. to reflect the removal of the flow.
The choice of the static values of R and b_t at all nodes and classes The choice of the static values of R and b_t at all nodes and classes
must be done in a prior configuration phase; R controls the bandwidth must be done in a prior configuration phase; R controls the bandwidth
allocated to this class at this node, b_t affects the delay bound and allocated to this class at this node, b_t affects the delay bound and
the buffer requirement. R must satisfy the constraints given in the buffer requirement. R must satisfy the constraints given in
Annex L.1 of [IEEE8021Q]. Annex L.1 of [IEEE8021Q].
6.5. IntServ 6.5. Guaranteed-Service IntServ
Integrated service (IntServ) is an architecture that specifies the Guaranteed-Service Integrated service (IntServ) is an architecture
elements to guarantee quality of service (QoS) on networks [RFC2212]. that specifies the elements to guarantee quality of service (QoS) on
networks [RFC2212].
The flow, at the source, has a leaky bucket arrival curve with two The flow, at the source, has a leaky bucket arrival curve with two
parameters r as rate and b as bucket size, i.e., the amount of bits parameters r as rate and b as bucket size, i.e., the amount of bits
entering a node within a time interval t is bounded by r t + b. entering a node within a time interval t is bounded by r t + b.
If a resource reservation on a path is applied, a node provides a If a resource reservation on a path is applied, a node provides a
guaranteed rate R and maximum service latency of T. This can be guaranteed rate R and maximum service latency of T. This can be
interpreted in a way that the bits might have to wait up to T before interpreted in a way that the bits might have to wait up to T before
being served with a rate greater or equal to R. The delay bound of being served with a rate greater or equal to R. The delay bound of
the flow traversing the node is T + b / R. the flow traversing the node is T + b / R.
Consider an IntServ path including a sequence of nodes, where the Consider a Guaranteed-Service IntServ path including a sequence of
i-th node provides a guaranteed rate R_i and maximum service latency nodes, where the i-th node provides a guaranteed rate R_i and maximum
of T_i. Then, the end-to-end delay bound for a flow on this can be service latency of T_i. Then, the end-to-end delay bound for a flow
calculated as sum(T_i) + b / min(R_i). on this can be calculated as sum(T_i) + b / min(R_i).
If more information about the flow is known, e.g. the peak rate, the The provided delay bound is based on a simple case of Guaranteed-
delay bound is more complicated; the detail is available in Service IntServ where only a guaranteed rate and maximum service
latency and a leaky bucket arrival curve are available. If more
information about the flow is known, e.g. the peak rate, the delay
bound is more complicated; the detail is available in [RFC2212] and
Section 1.4.1 of [NetCalBook]. Section 1.4.1 of [NetCalBook].
6.6. Cyclic Queuing and Forwarding 6.6. Cyclic Queuing and Forwarding
Annex T of [IEEE8021Q] describes Cyclic Queuing and Forwarding (CQF), Annex T of [IEEE8021Q] describes Cyclic Queuing and Forwarding (CQF),
which provides bounded latency and zero congestion loss using the which provides bounded latency and zero congestion loss using the
time-scheduled gates of [IEEE8021Q] section 8.6.8.4. For a given time-scheduled gates of [IEEE8021Q] section 8.6.8.4. For a given
class of DetNet flows, a set of two or more buffers is provided at class of DetNet flows, a set of two or more buffers is provided at
the output queue layer of Figure 3. A cycle time T_c is configured the output queue layer of Figure 3. A cycle time T_c is configured
for each class of DetNet flows c, and all of the buffer sets in a for each class of DetNet flows c, and all of the buffer sets in a
skipping to change at page 22, line 18 skipping to change at page 22, line 22
DetNet flow does not, itself, employ CQF. Since there are no per- DetNet flow does not, itself, employ CQF. Since there are no per-
flow parameters in the CQF technique, per-hop configuration is not flow parameters in the CQF technique, per-hop configuration is not
required in the CQF forwarding nodes. required in the CQF forwarding nodes.
7. Example application on DetNet IP network 7. Example application on DetNet IP network
This section provides an example application of this document on a This section provides an example application of this document on a
DetNet-enabled IP network. Consider Figure 5, taken from Section 3 DetNet-enabled IP network. Consider Figure 5, taken from Section 3
of [RFC8939], that shows a simple IP network: of [RFC8939], that shows a simple IP network:
o The end-system 1 implements IntServ as in Section 6.5 between o The end-system 1 implements Guaranteed-Service IntServ as in
itself and relay node 1. Section 6.5 between itself and relay node 1.
o Sub-network 1 is a TSN network. The nodes in subnetwork 1 o Sub-network 1 is a TSN network. The nodes in subnetwork 1
implement credit-based shapers with asynchronous traffic shaping implement credit-based shapers with asynchronous traffic shaping
as in Section 6.4. as in Section 6.4.
o Sub-network 2 is a TSN network. The nodes in subnetwork 2 o Sub-network 2 is a TSN network. The nodes in subnetwork 2
implement cyclic queuing and forwarding with two buffers as in implement cyclic queuing and forwarding with two buffers as in
Section 6.6. Section 6.6.
o The relay nodes 1 and 2 implement credit-based shapers with o The relay nodes 1 and 2 implement credit-based shapers with
 End of changes. 12 change blocks. 
22 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/