| < draft-ietf-detnet-bounded-latency-09.txt | draft-ietf-detnet-bounded-latency-10.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: 20 August 2022 E. Mohammadpour | Expires: 10 October 2022 E. Mohammadpour | |||
| EPFL | EPFL | |||
| J. Zhang | J. Zhang | |||
| Huawei Technologies Co. Ltd | Huawei Technologies Co. Ltd | |||
| B. Varga | B. Varga | |||
| J. Farkas | ||||
| Ericsson | Ericsson | |||
| 16 February 2022 | 8 April 2022 | |||
| DetNet Bounded Latency | DetNet Bounded Latency | |||
| draft-ietf-detnet-bounded-latency-09 | draft-ietf-detnet-bounded-latency-10 | |||
| Abstract | Abstract | |||
| This document presents a timing model for sources, destinations, and | This document presents a timing model for sources, destinations, and | |||
| DetNet transit nodes. Using the model, it provides a methodology to | DetNet transit nodes. Using the model, it provides a methodology to | |||
| compute end-to-end latency and backlog bounds for various queuing | compute end-to-end latency and backlog bounds for various queuing | |||
| methods. The methodology can be used by the management and control | methods. The methodology can be used by the management and control | |||
| planes and by resource reservation algorithms to provide bounded | planes and by resource reservation algorithms to provide bounded | |||
| latency and zero congestion loss for the DetNet service. | latency and zero congestion loss for the DetNet service. | |||
| skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 41 ¶ | |||
| 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 20 August 2022. | This Internet-Draft will expire on 10 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 20 ¶ | skipping to change at page 2, line 20 ¶ | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 | |||
| 3. DetNet bounded latency model . . . . . . . . . . . . . . . . 4 | 3. DetNet bounded latency model . . . . . . . . . . . . . . . . 4 | |||
| 3.1. Flow admission . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Flow admission . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1.1. Static latency calculation . . . . . . . . . . . . . 5 | 3.1.1. Static latency-calculation . . . . . . . . . . . . . 5 | |||
| 3.1.2. Dynamic latency calculation . . . . . . . . . . . . . 6 | 3.1.2. Dynamic latency-calculation . . . . . . . . . . . . . 6 | |||
| 3.2. Relay node model . . . . . . . . . . . . . . . . . . . . 6 | 3.2. Relay node model . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4. Computing End-to-end Delay Bounds . . . . . . . . . . . . . . 9 | 4. Computing End-to-end Delay Bounds . . . . . . . . . . . . . . 9 | |||
| 4.1. Non-queuing delay bound . . . . . . . . . . . . . . . . . 9 | 4.1. Non-queuing delay bound . . . . . . . . . . . . . . . . . 9 | |||
| 4.2. Queuing delay bound . . . . . . . . . . . . . . . . . . . 10 | 4.2. Queuing delay bound . . . . . . . . . . . . . . . . . . . 10 | |||
| 4.2.1. Per-flow queuing mechanisms . . . . . . . . . . . . . 11 | 4.2.1. Per-flow queuing mechanisms . . . . . . . . . . . . . 11 | |||
| 4.2.2. Aggregate queuing mechanisms . . . . . . . . . . . . 11 | 4.2.2. Aggregate queuing mechanisms . . . . . . . . . . . . 11 | |||
| 4.3. Ingress considerations . . . . . . . . . . . . . . . . . 12 | 4.3. Ingress considerations . . . . . . . . . . . . . . . . . 12 | |||
| 4.4. Interspersed DetNet-unaware transit nodes . . . . . . . . 13 | 4.4. Interspersed DetNet-unaware transit nodes . . . . . . . . 13 | |||
| 5. Achieving zero congestion loss . . . . . . . . . . . . . . . 13 | 5. Achieving zero congestion loss . . . . . . . . . . . . . . . 13 | |||
| 6. Queuing techniques . . . . . . . . . . . . . . . . . . . . . 14 | 6. Queuing techniques . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 6.1. Queuing data model . . . . . . . . . . . . . . . . . . . 15 | 6.1. Queuing data model . . . . . . . . . . . . . . . . . . . 15 | |||
| 6.2. Frame Preemption . . . . . . . . . . . . . . . . . . . . 17 | 6.2. Frame Preemption . . . . . . . . . . . . . . . . . . . . 17 | |||
| 6.3. Time Aware Shaper . . . . . . . . . . . . . . . . . . . . 17 | 6.3. Time-Aware Shaper . . . . . . . . . . . . . . . . . . . . 17 | |||
| 6.4. Credit-Based Shaper with Asynchronous Traffic Shaping . . 18 | 6.4. Credit-Based Shaper with Asynchronous Traffic Shaping . . 18 | |||
| 6.4.1. Delay Bound Calculation . . . . . . . . . . . . . . . 20 | 6.4.1. Delay Bound Calculation . . . . . . . . . . . . . . . 20 | |||
| 6.4.2. Flow Admission . . . . . . . . . . . . . . . . . . . 21 | 6.4.2. Flow Admission . . . . . . . . . . . . . . . . . . . 21 | |||
| 6.5. Guaranteed-Service IntServ . . . . . . . . . . . . . . . 22 | 6.5. Guaranteed-Service IntServ . . . . . . . . . . . . . . . 22 | |||
| 6.6. Cyclic Queuing and Forwarding . . . . . . . . . . . . . . 23 | 6.6. Cyclic Queuing and Forwarding . . . . . . . . . . . . . . 23 | |||
| 7. Example application on DetNet IP network . . . . . . . . . . 24 | 7. Example application on DetNet IP network . . . . . . . . . . 24 | |||
| 8. Security considerations . . . . . . . . . . . . . . . . . . . 26 | 8. Security considerations . . . . . . . . . . . . . . . . . . . 26 | |||
| 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 27 | 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 | 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 28 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 28 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 1. Introduction | 1. Introduction | |||
| The ability for IETF Deterministic Networking (DetNet) or IEEE 802.1 | The ability for IETF Deterministic Networking (DetNet) or IEEE 802.1 | |||
| Time-Sensitive Networking [IEEE8021TSN] to provide the DetNet | Time-Sensitive Networking [IEEE8021TSN] to provide the DetNet | |||
| services of bounded latency and zero congestion loss depends upon A) | services of bounded latency and zero congestion loss depends upon | |||
| configuring and allocating network resources for the exclusive use of | ||||
| DetNet flows; B) identifying, in the data plane, the resources to be | ||||
| utilized by any given packet, and C) the detailed behavior of those | ||||
| resources, especially transmission queue selection, so that latency | ||||
| bounds can be reliably assured. | ||||
| As explained in [RFC8655], DetNet flows are characterized by 1) a | A) configuring and allocating network resources for the exclusive | |||
| maximum bandwidth, guaranteed either by the transmitter or by strict | use of DetNet flows; | |||
| input metering; and 2) a requirement for a guaranteed worst-case end- | ||||
| to-end latency. That latency guarantee, in turn, provides the | B) identifying, in the data plane, the resources to be utilized by | |||
| opportunity for the network to supply enough buffer space to | any given packet; | |||
| guarantee zero congestion loss. It is assumed in this document that | ||||
| the paths of DetNet flows are fixed. Before the transmission of a | C) the detailed behavior of those resources, especially | |||
| DetNet flow, it is possible to calculate end-to-end latency bounds | transmission queue selection, so that latency bounds can be | |||
| and the amount of buffer space required at each hop to ensure zero | reliably assured. | |||
| congestion loss; this can be used by the applications identified in | ||||
| [RFC8578]. | As explained in [RFC8655], DetNet flows are notably characterized by | |||
| 1. a maximum bandwidth, guaranteed either by the transmitter or by | ||||
| strict input metering; | ||||
| 2. a requirement for a guaranteed worst-case end-to-end latency. | ||||
| That latency guarantee, in turn, provides the opportunity for the | ||||
| network to supply enough buffer space to guarantee zero congestion | ||||
| loss. It is assumed in this document that the paths of DetNet flows | ||||
| are fixed. Before the transmission of a DetNet flow, it is possible | ||||
| to calculate end-to-end latency bounds and the amount of buffer space | ||||
| required at each hop to ensure zero congestion loss; this can be used | ||||
| by the applications identified in [RFC8578]. | ||||
| This document presents a timing model for sources, destinations, and | This document presents a timing model for sources, destinations, and | |||
| the DetNet transit nodes; using this model, it provides a methodology | the DetNet transit nodes; using this model, it provides a methodology | |||
| to compute end-to-end latency and backlog bounds for various queuing | to compute end-to-end latency and backlog bounds for various queuing | |||
| mechanisms that can be used by the management and control planes to | mechanisms that can be used by the management and control planes to | |||
| provide DetNet qualities of service. The methodology used in this | provide DetNet qualities of service. The methodology used in this | |||
| document account for the possibility of packet reordering within a | document account for the possibility of packet reordering within a | |||
| DetNet node. The bounds on the amount of packet reordering is out of | DetNet node. The bounds on the amount of packet reordering is out of | |||
| the scope of this document and can be found in | the scope of this document and can be found in | |||
| [PacketReorderingBounds]. Moreover, this document references | [PacketReorderingBounds]. Moreover, this document references | |||
| skipping to change at page 3, line 51 ¶ | skipping to change at page 4, line 10 ¶ | |||
| Using the model presented in this document, it is possible for an | Using the model presented in this document, it is possible for an | |||
| implementer, user, or standards development organization to select a | implementer, user, or standards development organization to select a | |||
| set of queuing mechanisms for each device in a DetNet network, and to | set of queuing mechanisms for each device in a DetNet network, and to | |||
| select a resource reservation algorithm for that network, so that | select a resource reservation algorithm for that network, so that | |||
| those elements can work together to provide the DetNet service. | those elements can work together to provide the DetNet service. | |||
| Section 7 provides an example application of the timing model | Section 7 provides an example application of the timing model | |||
| introduced in this document on a DetNet IP network with a combination | introduced in this document on a DetNet IP network with a combination | |||
| of different queuing mechanisms. | of different queuing mechanisms. | |||
| This document does not specify any resource reservation protocol or | This document does not specify any resource reservation protocol or | |||
| control plane function. It disregards the in-band packets that can | control plane function. It does not describe all of the requirements | |||
| be part of the stream such as OAM and necessary re-transmissions. It | for that protocol or control plane function. It does describe | |||
| does not describe all of the requirements for that protocol or | requirements for such resource reservation methods, and for queuing | |||
| control plane function. It does describe requirements for such | mechanisms that, if met, will enable them to work together. | |||
| resource reservation methods, and for queuing mechanisms that, if | ||||
| met, will enable them to work together. | ||||
| 2. Terminology and Definitions | 2. Terminology and Definitions | |||
| This document uses the terms defined in [RFC8655]. Moreover, the | This document uses the terms defined in [RFC8655]. Moreover, the | |||
| following terms are used in this document: | following terms are used in this document: | |||
| T-SPEC | T-SPEC | |||
| TrafficSpecification as defined in Section 5.5 of [RFC9016]. | TrafficSpecification as defined in Section 5.5 of [RFC9016]. | |||
| arrival curve | arrival curve | |||
| skipping to change at page 4, line 30 ¶ | skipping to change at page 4, line 36 ¶ | |||
| CQF | CQF | |||
| Cyclic Queuing and Forwarding. | Cyclic Queuing and Forwarding. | |||
| CBS | CBS | |||
| Credit-based Shaper. | Credit-based Shaper. | |||
| TSN | TSN | |||
| Time-Sensitive Networking. | Time-Sensitive Networking. | |||
| PROEF | PREOF | |||
| A collective name for Packet Replication, Elimination, and | A collective name for Packet Replication, Elimination, and | |||
| Ordering Functions. | Ordering Functions. | |||
| Packet Ordering Function (POF) | Packet Ordering Function (POF) | |||
| A function that reorders packets within a DetNet flow that are | A function that reorders packets within a DetNet flow that are | |||
| received out of order. This function can be implemented by a | received out of order. This function can be implemented by a | |||
| DetNet edge node, a DetNet relay node, or an end system. | DetNet edge node, a DetNet relay node, or an end system. | |||
| 3. DetNet bounded latency model | 3. DetNet bounded latency model | |||
| skipping to change at page 5, line 29 ¶ | skipping to change at page 5, line 36 ¶ | |||
| This paradigm can be implemented using peer-to-peer protocols or | This paradigm can be implemented using peer-to-peer protocols or | |||
| using a central controller. In some situations, a lack of resources | using a central controller. In some situations, a lack of resources | |||
| can require backtracking and recursing through the above list. | can require backtracking and recursing through the above list. | |||
| Issues such as service preemption of a DetNet flow in favor of | Issues such as service preemption of a DetNet flow in favor of | |||
| another, when resources are scarce, are not considered here. Also | another, when resources are scarce, are not considered here. Also | |||
| not addressed is the question of how to choose the path to be taken | not addressed is the question of how to choose the path to be taken | |||
| by a DetNet flow. | by a DetNet flow. | |||
| 3.1.1. Static latency calculation | 3.1.1. Static latency-calculation | |||
| The static problem: | The static problem: | |||
| Given a network and a set of DetNet flows, compute an end-to- | Given a network and a set of DetNet flows, compute an end-to- | |||
| end latency bound (if computable) for each DetNet flow, and | end latency bound (if computable) for each DetNet flow, and | |||
| compute the resources, particularly buffer space, required in | compute the resources, particularly buffer space, required in | |||
| each DetNet transit node to achieve zero congestion loss. | each DetNet transit node to achieve zero congestion loss. | |||
| In this calculation, all of the DetNet flows are known before the | In this calculation, all of the DetNet flows are known before the | |||
| calculation commences. This problem is of interest to relatively | calculation commences. This problem is of interest to relatively | |||
| static networks, or static parts of larger networks. It provides | static networks, or static parts of larger networks. It provides | |||
| skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 13 ¶ | |||
| flow with tighter constraints. | flow with tighter constraints. | |||
| This calculation may be more difficult to perform than the dynamic | This calculation may be more difficult to perform than the dynamic | |||
| calculation (Section 3.1.2), because the DetNet flows passing through | calculation (Section 3.1.2), because the DetNet flows passing through | |||
| one port on a DetNet transit node affect each other's latency. The | one port on a DetNet transit node affect each other's latency. The | |||
| effects can even be circular, from a node A to B to C and back to A. | effects can even be circular, from a node A to B to C and back to A. | |||
| On the other hand, the static calculation can often accommodate | On the other hand, the static calculation can often accommodate | |||
| queuing methods, such as transmission selection by strict priority, | queuing methods, such as transmission selection by strict priority, | |||
| that are unsuitable for the dynamic calculation. | that are unsuitable for the dynamic calculation. | |||
| 3.1.2. Dynamic latency calculation | 3.1.2. Dynamic latency-calculation | |||
| The dynamic problem: | The dynamic problem: | |||
| Given a network whose maximum capacity for DetNet flows is | Given a network whose maximum capacity for DetNet flows is | |||
| bounded by a set of static configuration parameters applied | bounded by a set of static configuration parameters applied | |||
| to the DetNet transit nodes, and given just one DetNet flow, | to the DetNet transit nodes, and given just one DetNet flow, | |||
| compute the worst-case end-to-end latency that can be | compute the worst-case end-to-end latency that can be | |||
| experienced by that flow, no matter what other DetNet flows | experienced by that flow, no matter what other DetNet flows | |||
| (within the network's configured parameters) might be created | (within the network's configured parameters) might be created | |||
| or deleted in the future. Also, compute the resources, | or deleted in the future. Also, compute the resources, | |||
| particularly buffer space, required in each DetNet transit | particularly buffer space, required in each DetNet transit | |||
| node to achieve zero congestion loss. | node to achieve zero congestion loss. | |||
| This calculation is dynamic, in the sense that DetNet flows can be | This calculation is dynamic, in the sense that DetNet flows can be | |||
| added or deleted at any time, with a minimum of computation effort, | added or deleted at any time, with a minimum of computation effort, | |||
| and without affecting the guarantees already given to other DetNet | and without affecting the guarantees already given to other DetNet | |||
| flows. | flows. | |||
| Dynamic latency calculation can be done based on the static one | Dynamic latency-calculation can be done based on the static one | |||
| described in Section 3.1.1; when a new DetNet flow is created or | described in Section 3.1.1; when a new DetNet flow is created or | |||
| deleted, the entire calculation for all DetNet flows is repeated. If | deleted, the entire calculation for all DetNet flows is repeated. If | |||
| an already-established DetNet flow would be pushed beyond its latency | an already-established DetNet flow would be pushed beyond its latency | |||
| requirements by the new DetNet flow, then the new DetNet flow can be | requirements by the new DetNet flow request, then the new DetNet flow | |||
| refused, or some other suitable action taken. | request can be refused, or some other suitable action taken. | |||
| The choice of queuing methods is critical to the applicability of the | The choice of queuing methods is critical to the applicability of the | |||
| dynamic calculation. Some queuing methods (e.g. CQF, Section 6.6) | dynamic calculation. Some queuing methods (e.g., CQF, Section 6.6) | |||
| make it easy to configure bounds on the network's capacity, and to | make it easy to configure bounds on the network's capacity, and to | |||
| make independent calculations for each DetNet flow. Some other | make independent calculations for each DetNet flow. Some other | |||
| queuing methods (e.g. strict priority with the credit-based shaper | queuing methods (e.g., strict priority with the credit-based shaper | |||
| defined in [IEEE8021Q] section 8.6.8.2) can be used for dynamic | defined in [IEEE8021Q] section 8.6.8.2) can be used for dynamic | |||
| DetNet flow creation, but yield poorer latency and buffer space | DetNet flow creation, but yield poorer latency and buffer space | |||
| guarantees than when that same queuing method is used for static | guarantees than when that same queuing method is used for static | |||
| DetNet flow creation (Section 3.1.1). | DetNet flow creation (Section 3.1.1). | |||
| 3.2. Relay node model | 3.2. Relay node model | |||
| A model for the operation of a DetNet transit node is required, in | A model for the operation of a DetNet transit node is required, in | |||
| order to define the latency and buffer calculations. In Figure 1 we | order to define the latency and buffer calculations. In Figure 1 we | |||
| see a breakdown of the per-hop latency experienced by a packet | see a breakdown of the per-hop latency experienced by a packet | |||
| skipping to change at page 7, line 25 ¶ | skipping to change at page 7, line 33 ¶ | |||
| 2,3 4 5 6 1 2,3 4 5 6 1 2,3 | 2,3 4 5 6 1 2,3 4 5 6 1 2,3 | |||
| 1: Output delay 4: Processing delay | 1: Output delay 4: Processing delay | |||
| 2: Link delay 5: Regulation delay | 2: Link delay 5: Regulation delay | |||
| 3: Frame preemption delay 6: Queuing delay | 3: Frame preemption delay 6: Queuing delay | |||
| Figure 1: Timing model for DetNet or TSN | Figure 1: Timing model for DetNet or TSN | |||
| In Figure 1, we see two DetNet transit nodes that are connected via a | In Figure 1, we see two DetNet transit nodes that are connected via a | |||
| link. In this model, the only queues, that we deal with explicitly, | link. In this model, the only queues, that we deal with explicitly, | |||
| are attached to the output port; other queues are modeled as | are attached to the output port; other queues are modeled as | |||
| variations in the other delay times. (E.g., an input queue could be | variations in the other delay times (e.g., an input queue could be | |||
| modeled as either a variation in the link delay (2) or the processing | modeled as either a variation in the link delay (2) or the processing | |||
| delay (4).) There are six delays that a packet can experience from | delay (4).) There are six delays that a packet can experience from | |||
| hop to hop. | hop to hop. | |||
| 1. Output delay | 1. Output delay | |||
| The time taken from the selection of a packet for output from a | The time taken from the selection of a packet for output from a | |||
| queue to the transmission of the first bit of the packet on the | queue to the transmission of the first bit of the packet on the | |||
| physical link. If the queue is directly attached to the physical | physical link. If the queue is directly attached to the physical | |||
| port, output delay can be a constant. But, in many | port, output delay can be a constant. But, in many | |||
| implementations, the queuing mechanism in a forwarding ASIC is | implementations, the queuing mechanism in a forwarding ASIC is | |||
| skipping to change at page 8, line 7 ¶ | skipping to change at page 8, line 11 ¶ | |||
| packet to the reception of the last bit, assuming that the | packet to the reception of the last bit, assuming that the | |||
| transmission is not suspended by a frame preemption event. This | transmission is not suspended by a frame preemption event. This | |||
| delay has two components, the first-bit-out to first-bit-in delay | delay has two components, the first-bit-out to first-bit-in delay | |||
| and the first-bit-in to last-bit-in delay that varies with packet | and the first-bit-in to last-bit-in delay that varies with packet | |||
| size. The former is typically measured by the Precision Time | size. The former is typically measured by the Precision Time | |||
| Protocol and is constant (see [RFC8655]). However, a virtual | Protocol and is constant (see [RFC8655]). However, a virtual | |||
| "link" could exhibit a variable link delay. | "link" could exhibit a variable link delay. | |||
| 3. Frame preemption delay | 3. Frame preemption delay | |||
| If the packet is interrupted in order to transmit another packet | If the packet is interrupted in order to transmit another packet | |||
| or packets, (e.g. [IEEE8023] clause 99 frame preemption) an | or packets, (e.g., [IEEE8023] clause 99 frame preemption) an | |||
| arbitrary delay can result. | arbitrary delay can result. | |||
| 4. Processing delay | 4. Processing delay | |||
| This delay covers the time from the reception of the last bit of | This delay covers the time from the reception of the last bit of | |||
| the packet to the time the packet is enqueued in the regulator | the packet to the time the packet is enqueued in the regulator | |||
| (queuing subsystem, if there is no regulator) as shown in | (queuing subsystem, if there is no regulator) as shown in | |||
| Figure 1. This delay can be variable, and depends on the details | Figure 1. This delay can be variable, and depends on the details | |||
| of the operation of the forwarding node. | of the operation of the forwarding node. | |||
| 5. Regulator delay | 5. Regulator delay | |||
| skipping to change at page 11, line 40 ¶ | skipping to change at page 11, line 40 ¶ | |||
| 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 | |||
| other flows downstream of this resource. Computing delay upper | other flows downstream of this resource. Computing delay upper | |||
| bounds for such cases is difficult, and in some conditions impossible | bounds for such cases is difficult, and in some conditions impossible | |||
| [CharnyDelay][BennettDelay]. Also, when bounds are obtained, they | [CharnyDelay][BennettDelay]. Also, when bounds are obtained, they | |||
| depend on the complete configuration, and must be recomputed when one | depend on the complete configuration, and must be recomputed when one | |||
| flow is added. (The dynamic calculation, Section 3.1.2.) | flow is added. (The dynamic calculation, Section 3.1.2.) | |||
| A solution to deal with this issue for the DetNet flows is to reshape | A solution to deal with this issue for the DetNet flows is to reshape | |||
| them at every hop. This can be done with per-flow regulators (e.g. | them at every hop. This can be done with per-flow regulators (e.g., | |||
| leaky bucket shapers), but this requires per-flow queuing and defeats | leaky bucket shapers), but this requires per-flow queuing and defeats | |||
| the purpose of aggregate queuing. An alternative is the interleaved | the purpose of aggregate queuing. An alternative is the interleaved | |||
| regulator, which reshapes individual DetNet flows without per-flow | regulator, which reshapes individual DetNet flows without per-flow | |||
| queuing ([SpechtUBS], [IEEE8021Qcr]). With an interleaved regulator, | queuing ([SpechtUBS], [IEEE8021Qcr]). With an interleaved regulator, | |||
| the packet at the head of the queue is regulated based on its (flow) | the packet at the head of the queue is regulated based on its (flow) | |||
| regulation constraints; it is released at the earliest time at which | regulation constraints; it is released at the earliest time at which | |||
| this is possible without violating the constraint. One key feature | this is possible without violating the constraint. One key feature | |||
| of per-flow or interleaved regulator is that, it does not increase | of per-flow or interleaved regulator is that, it does not increase | |||
| worst-case latency bounds [LeBoudecTheory]. Specifically, when an | worst-case latency bounds [LeBoudecTheory]. Specifically, when an | |||
| interleaved regulator is appended to a FIFO subsystem, it does not | interleaved regulator is appended to a FIFO subsystem, it does not | |||
| increase the worst-case delay of the latter; in Figure 1, when the | increase the worst-case delay of the latter; in Figure 1, when the | |||
| order of packets from output of queuing subsystem at node A to the | order of packets from output of queuing subsystem at node A to the | |||
| entrance of regulator at node B is preserved, then the regulator does | entrance of regulator at node B is preserved, then the regulator does | |||
| not increase the worst-case latency bounds; this is made possible if | not increase the worst-case latency bounds; this is made possible if | |||
| all the systems are FIFO or a DetNet packet-ordering function (POF) | all the systems are FIFO or a DetNet packet-ordering function (POF) | |||
| is implemented just before the regulator. This property does not | is implemented just before the regulator. This property does not | |||
| hold if packet reordering occurs from the output of a queuing | hold if packet reordering occurs from the output of a queuing | |||
| subsystem to the entrance of next downstream interleaved regulator, | subsystem to the entrance of next downstream interleaved regulator, | |||
| e.g. at a non-FIFO switching fabric. | e.g., at a non-FIFO switching fabric. | |||
| Figure 2 shows an example of a network with 5 nodes, aggregate | Figure 2 shows an example of a network with 5 nodes, aggregate | |||
| queuing mechanism and interleaved regulators as in Figure 1. An end- | queuing mechanism and interleaved regulators as in Figure 1. An end- | |||
| to-end delay bound for DetNet flow f, traversing nodes 1 to 5, is | to-end delay bound for DetNet flow f, traversing nodes 1 to 5, is | |||
| calculated as follows: | calculated as follows: | |||
| end_to_end_latency_bound_of_flow_f = C12 + C23 + C34 + S4 | end_to_end_latency_bound_of_flow_f = C12 + C23 + C34 + S4 | |||
| In the above formula, Cij is a bound on the delay of the queuing | In the above formula, Cij is a bound on the delay of the queuing | |||
| subsystem in node i and interleaved regulator of node j, and S4 is a | subsystem in node i and interleaved regulator of node j, and S4 is a | |||
| skipping to change at page 14, line 20 ¶ | skipping to change at page 14, line 20 ¶ | |||
| The backlog bound is counted in data units (bytes, or words of | The backlog bound is counted in data units (bytes, or words of | |||
| multiple bytes) that are relevant for buffer allocation. For every | multiple bytes) that are relevant for buffer allocation. For every | |||
| flow or an aggregate of flows, we need one buffer space for the | flow or an aggregate of flows, we need one buffer space for the | |||
| packet in transmission, plus space for the packets that are waiting | packet in transmission, plus space for the packets that are waiting | |||
| to be selected for output. | to be selected for output. | |||
| Let | Let | |||
| * total_in_rate be the sum of the line rates of all input ports that | * total_in_rate be the sum of the line rates of all input ports that | |||
| send traffic to this output port. The value of total_in_rate is | send traffic to this output port. The value of total_in_rate is | |||
| in data units (e.g. bytes) per second. | in data units (e.g., bytes) per second. | |||
| * nb_input_ports be the number input ports that send traffic to this | * nb_input_ports be the number input ports that send traffic to this | |||
| output port | output port | |||
| * max_packet_length be the maximum packet size for packets that may | * max_packet_length be the maximum packet size for packets that may | |||
| be sent to this output port. This is counted in data units. | be sent to this output port. This is counted in data units. | |||
| * max_delay456 be an upper bound, in seconds, on the sum of the | * max_delay456 be an upper bound, in seconds, on the sum of the | |||
| processing delay (4) and the queuing delays (5,6) for any packet | processing delay (4) and the queuing delays (5,6) for any packet | |||
| at this output port. | at this output port. | |||
| Then a bound on the backlog of traffic in the queue at this output | Then a bound on the backlog of traffic in the queue at this output | |||
| port is | port is | |||
| backlog_bound = (nb_input_ports * max_packet_length) + | backlog_bound = (nb_input_ports * max_packet_length) + | |||
| (total_in_rate * max_delay456) | (total_in_rate * max_delay456) | |||
| The above bound is over the backlog caused by the traffic entering | ||||
| the queue from the input ports of a DetNet node. If the DetNet node | ||||
| also generates packets (e.g., creation of new packets, replication of | ||||
| arriving packets), the bound must accordingly incorporate the | ||||
| introduced backlog. | ||||
| 6. Queuing techniques | 6. Queuing techniques | |||
| In this section, we present a general queuing data model as well as | In this section, we present a general queuing data model as well as | |||
| some examples of queuing mechanisms. For simplicity of latency bound | some examples of queuing mechanisms. For simplicity of latency bound | |||
| computation, we assume leaky-bucket arrival curve for each DetNet | computation, we assume leaky-bucket arrival curve for each DetNet | |||
| flow at source. Also, at each DetNet transit node, the service for | flow at source. Also, at each DetNet transit node, the service for | |||
| each queue is abstracted with a minimum guaranteed rate and a latency | each queue is abstracted with a minimum guaranteed rate and a latency | |||
| [NetCalBook]. | [NetCalBook]. | |||
| 6.1. Queuing data model | 6.1. Queuing data model | |||
| skipping to change at page 16, line 51 ¶ | skipping to change at page 16, line 51 ¶ | |||
| Ideally, neither of these actions are performed on DetNet packets. | Ideally, neither of these actions are performed on DetNet packets. | |||
| Full queues for DetNet packets occurs only when a DetNet flow is | Full queues for DetNet packets occurs only when a DetNet flow is | |||
| misbehaving, and the DetNet QoS does not include "yellow" service for | misbehaving, and the DetNet QoS does not include "yellow" service for | |||
| packets in excess of committed rate. | packets in excess of committed rate. | |||
| The queue assignment function can be quite complex, even in a bridge | The queue assignment function can be quite complex, even in a bridge | |||
| [IEEE8021Q], since the introduction of per-stream filtering and | [IEEE8021Q], since the introduction of per-stream filtering and | |||
| policing ([IEEE8021Q] clause 8.6.5.1). In addition to the Layer 2 | policing ([IEEE8021Q] clause 8.6.5.1). In addition to the Layer 2 | |||
| priority expressed in the 802.1Q VLAN tag, a DetNet transit node can | priority expressed in the 802.1Q VLAN tag, a DetNet transit node can | |||
| utilize any of the following information to assign a packet to a | utilize the information from the non-exhaustive list below to assign | |||
| particular queue: | a packet to a particular queue: | |||
| * Input port. | * Input port. | |||
| * Selector based on a rotating schedule that starts at regular, | * Selector based on a rotating schedule that starts at regular, | |||
| time-synchronized intervals and has nanosecond precision. | time-synchronized intervals and has nanosecond precision. | |||
| * MAC addresses, VLAN ID, IP addresses, Layer 4 port numbers, DSCP | * MAC addresses, VLAN ID, IP addresses, Layer 4 port numbers, DSCP | |||
| [RFC8939], [RFC8964]. | [RFC8939], [RFC8964]. | |||
| * The queue assignment function can contain metering and policing | * The queue assignment function can contain metering and policing | |||
| skipping to change at page 17, line 38 ¶ | skipping to change at page 17, line 38 ¶ | |||
| interrupted, and one for packets that can interrupt the interruptible | interrupted, and one for packets that can interrupt the interruptible | |||
| packets. Only one layer of frame preemption is supported -- a | packets. Only one layer of frame preemption is supported -- a | |||
| transmitter cannot have more than one interrupted frame in progress. | transmitter cannot have more than one interrupted frame in progress. | |||
| DetNet flows typically pass through the interrupting MAC. For those | DetNet flows typically pass through the interrupting MAC. For those | |||
| DetNet flows with T-SPEC, latency bounds can be calculated by the | DetNet flows with T-SPEC, latency bounds can be calculated by the | |||
| methods provided in the following sections that account for the | methods provided in the following sections that account for the | |||
| effect of frame preemption, according to the specific queuing | effect of frame preemption, according to the specific queuing | |||
| mechanism that is used in DetNet nodes. Best-effort queues pass | mechanism that is used in DetNet nodes. Best-effort queues pass | |||
| through the interruptible MAC, and can thus be preempted. | through the interruptible MAC, and can thus be preempted. | |||
| 6.3. Time Aware Shaper | 6.3. Time-Aware Shaper | |||
| In [IEEE8021Q], the notion of time-scheduling queue gates is | In [IEEE8021Q], the notion of time-scheduling queue gates is | |||
| described in section 8.6.8.4. On each node, the transmission | described in section 8.6.8.4. On each node, the transmission | |||
| selection for packets is controlled by time-synchronized gates; each | selection for packets is controlled by time-synchronized gates; each | |||
| output queue is associated with a gate. The gates can be either open | output queue is associated with a gate. The gates can be either open | |||
| or closed. The states of the gates are determined by the gate | or closed. The states of the gates are determined by the gate | |||
| control list (GCL). The GCL specifies the opening and closing times | control list (GCL). The GCL specifies the opening and closing times | |||
| of the gates. The design of GCL must satisfy the requirement of | of the gates. The design of GCL must satisfy the requirement of | |||
| latency upper bounds of all DetNet flows; therefore, those DetNet | latency upper bounds of all DetNet flows; therefore, those DetNet | |||
| flows that traverse a network that uses this kind of shaper must have | flows that traverse a network that uses this kind of shaper must have | |||
| skipping to change at page 19, line 50 ¶ | skipping to change at page 19, line 50 ¶ | |||
| are served by a transmission selection subsystem that serves packets | are served by a transmission selection subsystem that serves packets | |||
| from each class based on its priority. All subsystems are non- | from each class based on its priority. All subsystems are non- | |||
| preemptive. Guarantees for classes A and B traffic can be provided | preemptive. Guarantees for classes A and B traffic can be provided | |||
| only if CDT traffic is bounded; it is assumed that the CDT traffic | only if CDT traffic is bounded; it is assumed that the CDT traffic | |||
| has a leaky bucket arrival curve with two parameters r_h as rate and | has a leaky bucket arrival curve with two parameters r_h as rate and | |||
| b_h as bucket size, i.e., the amount of bits entering a node within a | b_h as bucket size, i.e., the amount of bits entering a node within a | |||
| time interval t is bounded by r_h * t + b_h. | time interval t is bounded by r_h * t + b_h. | |||
| Additionally, it is assumed that the classes A and B flows are also | Additionally, it is assumed that the classes A and B flows are also | |||
| regulated at their source according to a leaky bucket arrival curve. | regulated at their source according to a leaky bucket arrival curve. | |||
| At the source, the traffic satisfies its regulation constraint, i.e. | At the source, the traffic satisfies its regulation constraint, i.e., | |||
| the delay due to interleaved regulator at the source is ignored. | the delay due to interleaved regulator at the source is ignored. | |||
| At each DetNet transit node implementing an interleaved regulator, | At each DetNet transit node implementing an interleaved regulator, | |||
| packets of multiple flows are processed in one FIFO queue; the packet | packets of multiple flows are processed in one FIFO queue; the packet | |||
| at the head of the queue is regulated based on its leaky bucket | at the head of the queue is regulated based on its leaky bucket | |||
| parameters; it is released at the earliest time at which this is | parameters; it is released at the earliest time at which this is | |||
| possible without violating the constraint. | possible without violating the constraint. | |||
| The regulation parameters for a flow (leaky bucket rate and bucket | The regulation parameters for a flow (leaky bucket rate and bucket | |||
| size) are the same at its source and at all DetNet transit nodes | size) are the same at its source and at all DetNet transit nodes | |||
| skipping to change at page 21, line 13 ¶ | skipping to change at page 21, line 13 ¶ | |||
| If the flow is of class B: | If the flow is of class B: | |||
| R_B = I_B * (c-r_h)/ c | R_B = I_B * (c-r_h)/ c | |||
| T_B = (L_BE + L_A + L_nA * I_A/(c_h-I_A) + b_h + r_h * L_n/ | T_B = (L_BE + L_A + L_nA * I_A/(c_h-I_A) + b_h + r_h * L_n/ | |||
| c)/(c-r_h) | c)/(c-r_h) | |||
| where I_B is the idle slope for class B; L_A is the maximum packet | where I_B is the idle slope for class B; L_A is the maximum packet | |||
| length of class A; L_BE is the maximum packet length of class BE. | length of class A; L_BE is the maximum packet length of class BE. | |||
| Then, as discussed in Section 4.2.2; an interleaved regulators does | Then, as discussed in Section 4.2.2; an interleaved regulator does | |||
| not increase the delay bound of the upstream queuing subsystem; | not increase the delay bound of the upstream queuing subsystem; | |||
| therefore an end-to-end delay bound for a DetNet flow of class X (A | therefore an end-to-end delay bound for a DetNet flow of class X (A | |||
| or B) is the sum of d_X_i for all node i in the path the flow, where | or B) is the sum of d_X_i for all node i in the path the flow, where | |||
| d_X_i is the delay bound of queuing subsystem in node i which is | d_X_i is the delay bound of queuing subsystem in node i which is | |||
| computed as above. According to the notation in Section 4.2.2, the | computed as above. According to the notation in Section 4.2.2, the | |||
| delay bound of queuing subsystem in a node i and interleaved | delay bound of queuing subsystem in a node i and interleaved | |||
| regulator in node j, i.e., Cij, is: | regulator in node j, i.e., Cij, is: | |||
| Cij = d_X_i | Cij = d_X_i | |||
| More information of delay analysis in such a DetNet transit node is | More information of delay analysis in such a DetNet transit node is | |||
| described in [TSNwithATS]. | described in [TSNwithATS]. | |||
| 6.4.2. Flow Admission | 6.4.2. Flow Admission | |||
| The delay bound calculation requires some information about each | The delay bound calculation requires some information about each | |||
| node. For each node, it is required to know the idle slope of CBS | node. For each node, it is required to know the idle slope of CBS | |||
| for each class A and B (I_A and I_B), as well as the transmission | for each class A and B (I_A and I_B), as well as the transmission | |||
| rate of the output link (c). Besides, it is necessary to have the | rate of the output link (c). Besides, it is necessary to have the | |||
| information on each class, i.e. maximum packet length of classes A, | information on each class, i.e., maximum packet length of classes A, | |||
| B, and BE. Moreover, the leaky bucket parameters of CDT (r_h,b_h) | B, and BE. Moreover, the leaky bucket parameters of CDT (r_h,b_h) | |||
| must be known. To admit a flow/flows of classes A and B, their delay | must be known. To admit a flow/flows of classes A and B, their delay | |||
| requirements must be guaranteed not to be violated. As described in | requirements must be guaranteed not to be violated. As described in | |||
| Section 3.1, the two problems, static and dynamic, are addressed | Section 3.1, the two problems, static and dynamic, are addressed | |||
| separately. In either of the problems, the rate and delay must be | separately. In either of the problems, the rate and delay must be | |||
| guaranteed. Thus, | guaranteed. Thus, | |||
| The static admission control: | The static admission control: | |||
| The leaky bucket parameters of all class A or B flows are | The leaky bucket parameters of all class A or B flows are | |||
| known, therefore, for each class A or B flow f, a delay bound | known, therefore, for each class A or B flow f, a delay bound | |||
| skipping to change at page 23, line 23 ¶ | skipping to change at page 23, line 23 ¶ | |||
| the flow traversing the node is T + b / R. | the flow traversing the node is T + b / R. | |||
| Consider a Guaranteed-Service IntServ path including a sequence of | Consider a Guaranteed-Service IntServ path including a sequence of | |||
| nodes, where the i-th node provides a guaranteed rate R_i and maximum | nodes, where the i-th node provides a guaranteed rate R_i and maximum | |||
| service latency of T_i. Then, the end-to-end delay bound for a flow | service latency of T_i. Then, the end-to-end delay bound for a flow | |||
| on this can be calculated as sum(T_i) + b / min(R_i). | on this can be calculated as sum(T_i) + b / min(R_i). | |||
| The provided delay bound is based on a simple case of Guaranteed- | The provided delay bound is based on a simple case of Guaranteed- | |||
| Service IntServ where only a guaranteed rate and maximum service | Service IntServ where only a guaranteed rate and maximum service | |||
| latency and a leaky bucket arrival curve are available. If more | latency and a leaky bucket arrival curve are available. If more | |||
| information about the flow is known, e.g. the peak rate, the delay | information about the flow is known, e.g., the peak rate, the delay | |||
| bound is more complicated; the details are available in [RFC2212] and | bound is more complicated; the details are 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 | |||
| skipping to change at page 24, line 5 ¶ | skipping to change at page 24, line 5 ¶ | |||
| buffer1 transmits the packets received in cycle (i). The duration of | buffer1 transmits the packets received in cycle (i). The duration of | |||
| each cycle is T_c. | each cycle is T_c. | |||
| The cycle time T_c must be carefully chosen; it needs to be large | The cycle time T_c must be carefully chosen; it needs to be large | |||
| enough to accommodate all the DetNet traffic, plus at least one | enough to accommodate all the DetNet traffic, plus at least one | |||
| maximum packet (or fragment) size from lower priority queues, which | maximum packet (or fragment) size from lower priority queues, which | |||
| might be received within a cycle. Also, the value of T_c includes a | might be received within a cycle. Also, the value of T_c includes a | |||
| time interval, called dead time (DT), which is the sum of the delays | time interval, called dead time (DT), which is the sum of the delays | |||
| 1,2,3,4 defined in Figure 1. The value of DT guarantees that the | 1,2,3,4 defined in Figure 1. The value of DT guarantees that the | |||
| last packet of one cycle in a node is fully delivered to a buffer of | last packet of one cycle in a node is fully delivered to a buffer of | |||
| the next node is the same cycle. A two-buffer CQF is recommended if | the next node in the same cycle. A two-buffer CQF is recommended if | |||
| DT is small compared to T_c. For a large DT, CQF with more buffers | DT is small compared to T_c. For a large DT, CQF with more buffers | |||
| can be used and a cycle identification label can be added to the | can be used, and a cycle identification label can be added to the | |||
| packets. | packets. | |||
| The per-hop latency is determined by the cycle time T_c: a packet | The per-hop latency is determined by the cycle time T_c: a packet | |||
| transmitted from a node at a cycle (i), is transmitted from the next | transmitted from a node at a cycle (i), is transmitted from the next | |||
| node at cycle (i+1). Then, if the packet traverses h hops, the | node at cycle (i+1). Then, if the packet traverses h hops, the | |||
| maximum latency experienced by the packet is from the beginning of | maximum latency experienced by the packet is from the beginning of | |||
| cycle (i) to the end of cycle (i+h); also, the minimum latency is | cycle (i) to the end of cycle (i+h); also, the minimum latency is | |||
| from the end of cycle (i) before the DT, to the beginning of cycle | from the end of cycle (i) before the DT, to the beginning of cycle | |||
| (i+h). Then, the maximum latency is: | (i+h). Then, the maximum latency is: | |||
| skipping to change at page 26, line 25 ¶ | skipping to change at page 26, line 25 ¶ | |||
| Security aspects that are unique to DetNet are those whose aim is to | Security aspects that are unique to DetNet are those whose aim is to | |||
| provide the specific QoS aspects of DetNet, specifically bounded end- | provide the specific QoS aspects of DetNet, specifically bounded end- | |||
| to-end delivery latency and zero congestion loss. Achieving such | to-end delivery latency and zero congestion loss. Achieving such | |||
| loss rates and bounded latency may not be possible in the face of a | loss rates and bounded latency may not be possible in the face of a | |||
| highly capable adversary, such as the one envisioned by the Internet | highly capable adversary, such as the one envisioned by the Internet | |||
| Threat Model of BCP 72 [RFC3552] that can arbitrarily drop or delay | Threat Model of BCP 72 [RFC3552] that can arbitrarily drop or delay | |||
| any or all traffic. In order to present meaningful security | any or all traffic. In order to present meaningful security | |||
| considerations, we consider a somewhat weaker attacker who does not | considerations, we consider a somewhat weaker attacker who does not | |||
| control the physical links of the DetNet domain but may have the | control the physical links of the DetNet domain but may have the | |||
| ability to control some resources within the boundary of the DetNet | ability to control or change the behavior of some resources within | |||
| domain. | the boundary of the DetNet domain. | |||
| Latency bound calculations use parameters that reflect physical | Latency bound calculations use parameters that reflect physical | |||
| quantities. If an attacker finds a way to change the physical | quantities. If an attacker finds a way to change the physical | |||
| quantities, unknown to the control and management planes, the latency | quantities, unknown to the control and management planes, the latency | |||
| calculations fail and may result in latency violation and/or | calculations fail and may result in latency violation and/or | |||
| congestion losses. An example of such attacks is to make some | congestion losses. An example of such attacks is to make some | |||
| traffic sources under the control of the attacker send more traffic | traffic sources under the control of the attacker send more traffic | |||
| than their assumed T-SPECs. This type of attack is typically avoided | than their assumed T-SPECs. This type of attack is typically avoided | |||
| by ingress conditioning at the edge of a DetNet domain. However, it | by ingress conditioning at the edge of a DetNet domain. However, it | |||
| must be insured that such ingress conditioning is done per-flow and | must be insured that such ingress conditioning is done per-flow and | |||
| skipping to change at page 27, line 12 ¶ | skipping to change at page 27, line 12 ¶ | |||
| be detected only by their effects on latency bound violations and | be detected only by their effects on latency bound violations and | |||
| congestion losses, which do not occur in normal DetNet operation. | congestion losses, which do not occur in normal DetNet operation. | |||
| 9. IANA considerations | 9. IANA considerations | |||
| This document has no IANA actions. | This document has no IANA actions. | |||
| 10. Acknowledgement | 10. Acknowledgement | |||
| We would like to thank Lou Berger, Tony Przygienda, John Scudder, | We would like to thank Lou Berger, Tony Przygienda, John Scudder, | |||
| Watson Ladd, Yoshifumi Nishida, Ralf Weber, and Robert Sparks for | Watson Ladd, Yoshifumi Nishida, Ralf Weber, Robert Sparks, Gyan | |||
| their useful feedback on this document. | Mishra, Martin Duke, Eric Vyncke, Lars Eggert, Roman Danyliw, and | |||
| Paul Wouters for their useful feedback on this document. | ||||
| 11. References | 11. Contributors | |||
| 11.1. Normative References | RFC 7322 limits the number of authors listed on the front page to a | |||
| maximum of 5. The editor wishes to thank and acknowledge the | ||||
| following author for contributing text to this document | ||||
| Janos Farkas | ||||
| Ericsson | ||||
| Email: janos.farkas@ericsson.com | ||||
| 12. References | ||||
| 12.1. Normative References | ||||
| [IEEE8021Q] | [IEEE8021Q] | |||
| IEEE 802.1, "IEEE Std 802.1Q-2018: IEEE Standard for Local | IEEE 802.1, "IEEE Std 802.1Q-2018: IEEE Standard for Local | |||
| and metropolitan area networks - Bridges and Bridged | and metropolitan area networks - Bridges and Bridged | |||
| Networks", 2018, | Networks", 2018, | |||
| <http://ieeexplore.ieee.org/document/8403927>. | <https://ieeexplore.ieee.org/document/8403927>. | |||
| [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification | [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification | |||
| of Guaranteed Quality of Service", RFC 2212, | of Guaranteed Quality of Service", RFC 2212, | |||
| DOI 10.17487/RFC2212, September 1997, | DOI 10.17487/RFC2212, September 1997, | |||
| <https://www.rfc-editor.org/info/rfc2212>. | <https://www.rfc-editor.org/info/rfc2212>. | |||
| [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | |||
| and W. Weiss, "An Architecture for Differentiated | and W. Weiss, "An Architecture for Differentiated | |||
| Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, | Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, | |||
| <https://www.rfc-editor.org/info/rfc2475>. | <https://www.rfc-editor.org/info/rfc2475>. | |||
| skipping to change at page 28, line 16 ¶ | skipping to change at page 28, line 30 ¶ | |||
| S., and J. Korhonen, "Deterministic Networking (DetNet) | S., and J. Korhonen, "Deterministic Networking (DetNet) | |||
| Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January | Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January | |||
| 2021, <https://www.rfc-editor.org/info/rfc8964>. | 2021, <https://www.rfc-editor.org/info/rfc8964>. | |||
| [RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. | [RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. | |||
| Fedyk, "Flow and Service Information Model for | Fedyk, "Flow and Service Information Model for | |||
| Deterministic Networking (DetNet)", RFC 9016, | Deterministic Networking (DetNet)", RFC 9016, | |||
| DOI 10.17487/RFC9016, March 2021, | DOI 10.17487/RFC9016, March 2021, | |||
| <https://www.rfc-editor.org/info/rfc9016>. | <https://www.rfc-editor.org/info/rfc9016>. | |||
| 11.2. Informative References | 12.2. Informative References | |||
| [BennettDelay] | [BennettDelay] | |||
| J.C.R. Bennett, K. Benson, A. Charny, W.F. Courtney, and | J.C.R. Bennett, K. Benson, A. Charny, W.F. Courtney, and | |||
| J.-Y. Le Boudec, "Delay Jitter Bounds and Packet Scale | J.-Y. Le Boudec, "Delay Jitter Bounds and Packet Scale | |||
| Rate Guarantee for Expedited Forwarding", | Rate Guarantee for Expedited Forwarding", | |||
| <https://dl.acm.org/citation.cfm?id=581870>. | <https://dl.acm.org/citation.cfm?id=581870>. | |||
| [CharnyDelay] | [CharnyDelay] | |||
| A. Charny and J.-Y. Le Boudec, "Delay Bounds in a Network | A. Charny and J.-Y. Le Boudec, "Delay Bounds in a Network | |||
| with Aggregate Scheduling", <https://link.springer.com/ | with Aggregate Scheduling", <https://link.springer.com/ | |||
| skipping to change at page 28, line 39 ¶ | skipping to change at page 29, line 9 ¶ | |||
| [DelayAttack] | [DelayAttack] | |||
| S. Barreto, A. Suresh, and J.-Y. Le Boudec, "Cyber-attack | S. Barreto, A. Suresh, and J.-Y. Le Boudec, "Cyber-attack | |||
| on packet-based time synchronization protocols: The | on packet-based time synchronization protocols: The | |||
| undetectable Delay Box", | undetectable Delay Box", | |||
| <https://ieeexplore.ieee.org/document/7520408>. | <https://ieeexplore.ieee.org/document/7520408>. | |||
| [I-D.ietf-detnet-controller-plane-framework] | [I-D.ietf-detnet-controller-plane-framework] | |||
| A. Malis, X. Geng, M. Chen, F. Qin, and B. Varga, | A. Malis, X. Geng, M. Chen, F. Qin, and B. Varga, | |||
| "Deterministic Networking (DetNet) Controller Plane | "Deterministic Networking (DetNet) Controller Plane | |||
| Framework draft-ietf-detnet-controller-plane-framework- | Framework draft-ietf-detnet-controller-plane-framework- | |||
| 00", <https://datatracker.ietf.org/doc/html/draft-ietf- | 01", <https://datatracker.ietf.org/doc/html/draft-ietf- | |||
| detnet-controller-plane-framework>. | detnet-controller-plane-framework>. | |||
| [IEEE1588] IEEE Std 1588-2008, "IEEE Standard for a Precision Clock | [IEEE1588] IEEE Std 1588-2008, "IEEE Standard for a Precision Clock | |||
| Synchronization Protocol for Networked Measurement and | Synchronization Protocol for Networked Measurement and | |||
| Control Systems", 2008, | Control Systems", 2008, | |||
| <https://ieeexplore.ieee.org/document/4579760>. | <https://ieeexplore.ieee.org/document/4579760>. | |||
| [IEEE8021Qcr] | [IEEE8021Qcr] | |||
| IEEE 802.1, "IEEE P802.1Qcr: IEEE Draft Standard for Local | IEEE 802.1, "IEEE P802.1Qcr: Bridges and Bridged Networks | |||
| and metropolitan area networks - Bridges and Bridged | - Amendment: Asynchronous Traffic Shaping", 2017, | |||
| Networks - Amendment: Asynchronous Traffic Shaping", 2017, | <https://1.ieee802.org/tsn/802-1qcr/>. | |||
| <http://www.ieee802.org/1/files/private/cr-drafts/>. | ||||
| [IEEE8021TSN] | [IEEE8021TSN] | |||
| IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) | IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) | |||
| Task Group", <http://www.ieee802.org/1/>. | Task Group", <http://www.ieee802.org/1/>. | |||
| [IEEE8023] IEEE 802.3, "IEEE Std 802.3-2018: IEEE Standard for | [IEEE8023] IEEE 802.3, "IEEE Std 802.3-2018: IEEE Standard for | |||
| Ethernet", 2018, | Ethernet", 2018, | |||
| <http://ieeexplore.ieee.org/document/8457469>. | <http://ieeexplore.ieee.org/document/8457469>. | |||
| [LeBoudecTheory] | [LeBoudecTheory] | |||
| skipping to change at page 30, line 30 ¶ | skipping to change at page 31, line 4 ¶ | |||
| <https://dl.acm.org/doi/10.1145/3393691.3394206>. | <https://dl.acm.org/doi/10.1145/3393691.3394206>. | |||
| [TSNwithATS] | [TSNwithATS] | |||
| E. Mohammadpour, E. Stai, M. Mohiuddin, and J.-Y. Le | E. Mohammadpour, E. Stai, M. Mohiuddin, and J.-Y. Le | |||
| Boudec, "Latency and Backlog Bounds in Time-Sensitive | Boudec, "Latency and Backlog Bounds in Time-Sensitive | |||
| Networking with Credit Based Shapers and Asynchronous | Networking with Credit Based Shapers and Asynchronous | |||
| Traffic Shaping", | Traffic Shaping", | |||
| <https://ieeexplore.ieee.org/document/8493026>. | <https://ieeexplore.ieee.org/document/8493026>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Norman Finn | Norman Finn | |||
| Huawei Technologies Co. Ltd | Huawei Technologies Co. Ltd | |||
| 3101 Rio Way | 3101 Rio Way | |||
| Spring Valley, California 91977 | Spring Valley, California 91977 | |||
| United States of America | United States of America | |||
| Phone: +1 925 980 6430 | Phone: +1 925 980 6430 | |||
| Email: nfinn@nfinnconsulting.com | Email: nfinn@nfinnconsulting.com | |||
| Jean-Yves Le Boudec | Jean-Yves Le Boudec | |||
| EPFL | EPFL | |||
| IC Station 14 | IC Station 14 | |||
| CH-1015 Lausanne EPFL | CH-1015 Lausanne EPFL | |||
| Switzerland | Switzerland | |||
| Email: jean-yves.leboudec@epfl.ch | Email: jean-yves.leboudec@epfl.ch | |||
| Ehsan Mohammadpour | Ehsan Mohammadpour | |||
| EPFL | EPFL | |||
| IC Station 14 | IC Station 14 | |||
| CH-1015 Lausanne EPFL | CH-1015 Lausanne EPFL | |||
| Switzerland | Switzerland | |||
| Email: ehsan.mohammadpour@epfl.ch | Email: ehsan.mohammadpour@epfl.ch | |||
| Jiayi Zhang | Jiayi Zhang | |||
| Huawei Technologies Co. Ltd | Huawei Technologies Co. Ltd | |||
| Q27, No.156 Beiqing Road | Q27, No.156 Beiqing Road | |||
| Beijing | Beijing | |||
| 100095 | 100095 | |||
| China | China | |||
| Email: zhangjiayi11@huawei.com | Email: zhangjiayi11@huawei.com | |||
| Balázs Varga | Balázs Varga | |||
| Ericsson | Ericsson | |||
| Budapest | Budapest | |||
| Konyves Kálmán krt. 11/B | Konyves Kálmán krt. 11/B | |||
| 1097 | 1097 | |||
| Hungary | Hungary | |||
| Email: balazs.a.varga@ericsson.com | Email: balazs.a.varga@ericsson.com | |||
| János Farkas | ||||
| Ericsson | ||||
| Budapest | ||||
| Konyves Kálmán krt. 11/B | ||||
| 1097 | ||||
| Hungary | ||||
| Email: janos.farkas@ericsson.com | ||||
| End of changes. 47 change blocks. | ||||
| 76 lines changed or deleted | 92 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/ | ||||