draft-ietf-detnet-architecture-11.txt   draft-ietf-detnet-architecture-12.txt 
DetNet N. Finn DetNet N. Finn
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: August 10, 2019 Cisco Expires: September 10, 2019 Cisco
B. Varga B. Varga
J. Farkas J. Farkas
Ericsson Ericsson
February 6, 2019 March 9, 2019
Deterministic Networking Architecture Deterministic Networking Architecture
draft-ietf-detnet-architecture-11 draft-ietf-detnet-architecture-12
Abstract Abstract
This document provides the overall architecture for Deterministic This document provides the overall architecture for Deterministic
Networking (DetNet), which provides a capability to carry specified Networking (DetNet), which provides a capability to carry specified
unicast or multicast data flows for real-time applications with unicast or multicast data flows for real-time applications with
extremely low data loss rates and bounded latency within a network extremely low data loss rates and bounded latency within a network
domain. Techniques used include: 1) reserving data plane resources domain. Techniques used include: 1) reserving data plane resources
for individual (or aggregated) DetNet flows in some or all of the for individual (or aggregated) DetNet flows in some or all of the
intermediate nodes along the path of the flow; 2) providing explicit intermediate nodes along the path of the flow; 2) providing explicit
routes for DetNet flows that do not immediately change with the routes for DetNet flows that do not immediately change with the
network topology; and 3) distributing data from DetNet flow packets network topology; and 3) distributing data from DetNet flow packets
over time and/or space to ensure delivery of each packet's data in over time and/or space to ensure delivery of each packet's data in
spite of the loss of a path. DetNet operates at the IP layer and spite of the loss of a path. DetNet operates at the IP layer and
delivers service over sub-network technologies such as MPLS and IEEE delivers service over lower layer technologies such as MPLS and IEEE
802.1 Time-Sensitive Networking (TSN). 802.1 Time-Sensitive Networking (TSN).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 10, 2019. This Internet-Draft will expire on September 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terms used in this document . . . . . . . . . . . . . . . 4 2.1. Terms used in this document . . . . . . . . . . . . . . . 4
2.2. IEEE 802.1 TSN to DetNet dictionary . . . . . . . . . . . 7 2.2. IEEE 802.1 TSN to DetNet dictionary . . . . . . . . . . . 7
3. Providing the DetNet Quality of Service . . . . . . . . . . . 7 3. Providing the DetNet Quality of Service . . . . . . . . . . . 7
3.1. Primary goals defining the DetNet QoS . . . . . . . . . . 7 3.1. Primary goals defining the DetNet QoS . . . . . . . . . . 8
3.2. Mechanisms to achieve DetNet QoS . . . . . . . . . . . . 10 3.2. Mechanisms to achieve DetNet QoS . . . . . . . . . . . . 10
3.2.1. Resource allocation . . . . . . . . . . . . . . . . . 10 3.2.1. Resource allocation . . . . . . . . . . . . . . . . . 10
3.2.1.1. Eliminate contention loss . . . . . . . . . . . . 10 3.2.1.1. Eliminate contention loss . . . . . . . . . . . . 10
3.2.1.2. Jitter Reduction . . . . . . . . . . . . . . . . 10 3.2.1.2. Jitter Reduction . . . . . . . . . . . . . . . . 11
3.2.2. Service Protection . . . . . . . . . . . . . . . . . 11 3.2.2. Service Protection . . . . . . . . . . . . . . . . . 11
3.2.2.1. In-Order Delivery . . . . . . . . . . . . . . . . 11 3.2.2.1. In-Order Delivery . . . . . . . . . . . . . . . . 12
3.2.2.2. Packet Replication and Elimination . . . . . . . 12 3.2.2.2. Packet Replication and Elimination . . . . . . . 12
3.2.2.3. Packet encoding for service protection . . . . . 14 3.2.2.3. Packet encoding for service protection . . . . . 14
3.2.3. Explicit routes . . . . . . . . . . . . . . . . . . . 14 3.2.3. Explicit routes . . . . . . . . . . . . . . . . . . . 14
3.3. Secondary goals for DetNet . . . . . . . . . . . . . . . 15 3.3. Secondary goals for DetNet . . . . . . . . . . . . . . . 15
3.3.1. Coexistence with normal traffic . . . . . . . . . . . 15 3.3.1. Coexistence with normal traffic . . . . . . . . . . . 15
3.3.2. Fault Mitigation . . . . . . . . . . . . . . . . . . 16 3.3.2. Fault Mitigation . . . . . . . . . . . . . . . . . . 16
4. DetNet Architecture . . . . . . . . . . . . . . . . . . . . . 17 4. DetNet Architecture . . . . . . . . . . . . . . . . . . . . . 17
4.1. DetNet stack model . . . . . . . . . . . . . . . . . . . 17 4.1. DetNet stack model . . . . . . . . . . . . . . . . . . . 17
4.1.1. Representative Protocol Stack Model . . . . . . . . . 17 4.1.1. Representative Protocol Stack Model . . . . . . . . . 17
4.1.2. DetNet Data Plane Overview . . . . . . . . . . . . . 19 4.1.2. DetNet Data Plane Overview . . . . . . . . . . . . . 20
4.1.3. Network reference model . . . . . . . . . . . . . . . 21 4.1.3. Network reference model . . . . . . . . . . . . . . . 22
4.2. DetNet systems . . . . . . . . . . . . . . . . . . . . . 23 4.2. DetNet systems . . . . . . . . . . . . . . . . . . . . . 23
4.2.1. End system . . . . . . . . . . . . . . . . . . . . . 23 4.2.1. End system . . . . . . . . . . . . . . . . . . . . . 23
4.2.2. DetNet edge, relay, and transit nodes . . . . . . . . 24 4.2.2. DetNet edge, relay, and transit nodes . . . . . . . . 24
4.3. DetNet flows . . . . . . . . . . . . . . . . . . . . . . 24 4.3. DetNet flows . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1. DetNet flow types . . . . . . . . . . . . . . . . . . 24 4.3.1. DetNet flow types . . . . . . . . . . . . . . . . . . 25
4.3.2. Source transmission behavior . . . . . . . . . . . . 25 4.3.2. Source transmission behavior . . . . . . . . . . . . 25
4.3.3. Incomplete Networks . . . . . . . . . . . . . . . . . 26 4.3.3. Incomplete Networks . . . . . . . . . . . . . . . . . 27
4.4. Traffic Engineering for DetNet . . . . . . . . . . . . . 26 4.4. Traffic Engineering for DetNet . . . . . . . . . . . . . 27
4.4.1. The Application Plane . . . . . . . . . . . . . . . . 27 4.4.1. The Application Plane . . . . . . . . . . . . . . . . 28
4.4.2. The Controller Plane . . . . . . . . . . . . . . . . 27 4.4.2. The Controller Plane . . . . . . . . . . . . . . . . 28
4.4.3. The Network Plane . . . . . . . . . . . . . . . . . . 28 4.4.3. The Network Plane . . . . . . . . . . . . . . . . . . 29
4.5. Queuing, Shaping, Scheduling, and Preemption . . . . . . 29 4.5. Queuing, Shaping, Scheduling, and Preemption . . . . . . 30
4.6. Service instance . . . . . . . . . . . . . . . . . . . . 30 4.6. Service instance . . . . . . . . . . . . . . . . . . . . 31
4.7. Flow identification at technology borders . . . . . . . . 31 4.7. Flow identification at technology borders . . . . . . . . 32
4.7.1. Exporting flow identification . . . . . . . . . . . . 32 4.7.1. Exporting flow identification . . . . . . . . . . . . 32
4.7.2. Flow attribute mapping between layers . . . . . . . . 33 4.7.2. Flow attribute mapping between layers . . . . . . . . 34
4.7.3. Flow-ID mapping examples . . . . . . . . . . . . . . 34 4.7.3. Flow-ID mapping examples . . . . . . . . . . . . . . 35
4.8. Advertising resources, capabilities and adjacencies . . . 36 4.8. Advertising resources, capabilities and adjacencies . . . 36
4.9. Scaling to larger networks . . . . . . . . . . . . . . . 36 4.9. Scaling to larger networks . . . . . . . . . . . . . . . 37
4.10. Compatibility with Layer-2 . . . . . . . . . . . . . . . 36 4.10. Compatibility with Layer-2 . . . . . . . . . . . . . . . 37
5. Security Considerations . . . . . . . . . . . . . . . . . . . 37 5. Security Considerations . . . . . . . . . . . . . . . . . . . 37
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
9. Informative References . . . . . . . . . . . . . . . . . . . 38 9. Informative References . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document provides the overall architecture for Deterministic This document provides the overall architecture for Deterministic
Networking (DetNet), which provides a capability for the delivery of Networking (DetNet), which provides a capability for the delivery of
data flows with extremely low packet loss rates and bounded end-to- data flows with extremely low packet loss rates and bounded end-to-
end delivery latency. DetNet is for networks that are under a single end delivery latency. DetNet is for networks that are under a single
administrative control or within a closed group of administrative administrative control or within a closed group of administrative
control; these include campus-wide networks and private WANs. DetNet control; these include campus-wide networks and private WANs. DetNet
is not for large groups of domains such as the Internet. is not for large groups of domains such as the Internet.
DetNet operates at the IP layer and delivers service over sub-network DetNet operates at the IP layer and delivers service over lower layer
technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking
(TSN). DetNet accomplishes these goals by dedicating network (TSN). DetNet accomplishes these goals by dedicating network
resources such as link bandwidth and buffer space to DetNet flows resources such as link bandwidth and buffer space to DetNet flows
and/or classes of DetNet flows, and by replicating packets along and/or classes of DetNet flows, and by replicating packets along
multiple paths. Unused reserved resources are available to non- multiple paths. Unused reserved resources are available to non-
DetNet packets as long as all guarantees are fulfilled. DetNet packets as long as all guarantees are fulfilled.
The Deterministic Networking Problem Statement The Deterministic Networking Problem Statement
[I-D.ietf-detnet-problem-statement] introduces Deterministic [I-D.ietf-detnet-problem-statement] introduces Deterministic
Networking, and Deterministic Networking Use Cases Networking, and Deterministic Networking Use Cases
[I-D.ietf-detnet-use-cases] summarizes the need for it. See [I-D.ietf-detnet-use-cases] summarizes the need for it. See
[I-D.ietf-detnet-dp-sol-mpls] and [I-D.ietf-detnet-dp-sol-ip] for [I-D.ietf-detnet-dp-sol-mpls] and [I-D.ietf-detnet-dp-sol-ip] for
specific techniques that can be used to identify DetNet flows and specific techniques that can be used to identify DetNet flows and
assign them to specific paths through a network. assign them to specific paths through a network.
A goal of DetNet is a converged network in all respects. That is, A goal of DetNet is a converged network in all respects including the
the presence of DetNet flows does not preclude non-DetNet flows, and convergence of sensitive non-IP networks onto a common network
the benefits offered DetNet flows should not, except in extreme infrastructure. The presence of DetNet flows does not preclude non-
cases, prevent existing Quality of Service (QoS) mechanisms from DetNet flows, and the benefits offered DetNet flows should not,
operating in a normal fashion, subject to the bandwidth required for except in extreme cases, prevent existing Quality of Service (QoS)
the DetNet flows. A single source-destination pair can trade both mechanisms from operating in a normal fashion, subject to the
DetNet and non-DetNet flows. End systems and applications need not bandwidth required for the DetNet flows. A single source-destination
instantiate special interfaces for DetNet flows. Networks are not pair can trade both DetNet and non-DetNet flows. End systems and
restricted to certain topologies; connectivity is not restricted. applications need not instantiate special interfaces for DetNet
Any application that generates a data flow that can be usefully flows. Networks are not restricted to certain topologies;
characterized as having a maximum bandwidth should be able to take connectivity is not restricted. Any application that generates a
advantage of DetNet, as long as the necessary resources can be data flow that can be usefully characterized as having a maximum
reserved. Reservations can be made by the application itself, via bandwidth should be able to take advantage of DetNet, as long as the
network management, by an application's controller, or by other necessary resources can be reserved. Reservations can be made by the
means, e.g., a dynamic control plane (e.g., [RFC2205]). QoS application itself, via network management, by an application's
requirements of DetNet flows can be met if all network nodes in a controller, or by other means, e.g., a dynamic control plane (e.g.,
DetNet domain implement DetNet capabilities. DetNet nodes can be [RFC2205]). QoS requirements of DetNet flows can be met if all
interconnected with different sub-network technologies network nodes in a DetNet domain implement DetNet capabilities.
(Section 4.1.2), where the nodes of the subnet are not DetNet aware DetNet nodes can be interconnected with different sub-network
(Section 4.1.3). technologies (Section 4.1.2), where the nodes of the subnet are not
DetNet aware (Section 4.1.3).
Many applications that are intended to be served by Deterministic Many applications that are intended to be served by Deterministic
Networking require the ability to synchronize the clocks in end Networking require the ability to synchronize the clocks in end
systems to a sub-microsecond accuracy. Some of the queue control systems to a sub-microsecond accuracy. Some of the queue control
techniques defined in Section 4.5 also require time synchronization techniques defined in Section 4.5 also require time synchronization
among network nodes. The means used to achieve time synchronization among network nodes. The means used to achieve time synchronization
are not addressed in this document. DetNet can accommodate various are not addressed in this document. DetNet can accommodate various
time synchronization techniques and profiles that are defined time synchronization techniques and profiles that are defined
elsewhere to address the needs of different market segments. elsewhere to address the needs of different market segments.
skipping to change at page 4, line 44 skipping to change at page 4, line 45
The following terms are used in the context of DetNet in this The following terms are used in the context of DetNet in this
document: document:
allocation allocation
Resources are dedicated to support a DetNet flow. Depending Resources are dedicated to support a DetNet flow. Depending
on an implementation, the resource may be reused by non- on an implementation, the resource may be reused by non-
DetNet flows when it is not used by the DetNet flow. DetNet flows when it is not used by the DetNet flow.
App-flow App-flow
The native format of a DetNet flow. The payload (data) carried over a DetNet service.
DetNet compound flow and DetNet member flow DetNet compound flow and DetNet member flow
A DetNet compound flow is a DetNet flow that has been A DetNet compound flow is a DetNet flow that has been
separated into multiple duplicate DetNet member flows for separated into multiple duplicate DetNet member flows for
service protection at the DetNet service sub-layer. Member service protection at the DetNet service sub-layer. Member
flows are merged back into a single DetNet compound flow such flows are merged back into a single DetNet compound flow such
that there are no duplicate packets. "Compound" and "member" that there are no duplicate packets. "Compound" and "member"
are strictly relative to each other, not absolutes; a DetNet are strictly relative to each other, not absolutes; a DetNet
compound flow comprising multiple DetNet member flows can, in compound flow comprising multiple DetNet member flows can, in
turn, be a member of a higher-order compound. turn, be a member of a higher-order compound.
skipping to change at page 5, line 27 skipping to change at page 5, line 28
or destination at the DetNet service sub-layer. For example, or destination at the DetNet service sub-layer. For example,
it can include a DetNet service sub-layer proxy function for it can include a DetNet service sub-layer proxy function for
DetNet service protection (e.g., the addition or removal of DetNet service protection (e.g., the addition or removal of
packet sequencing information) for one or more end systems, packet sequencing information) for one or more end systems,
or starts or terminates resource allocation at the DetNet or starts or terminates resource allocation at the DetNet
forwarding sub-layer, or aggregates DetNet services into new forwarding sub-layer, or aggregates DetNet services into new
DetNet flows. It is analogous to a Label Edge Router (LER) DetNet flows. It is analogous to a Label Edge Router (LER)
or a Provider Edge (PE) router. or a Provider Edge (PE) router.
DetNet flow DetNet flow
A DetNet flow is a sequence of packets from one source to one A DetNet flow is a sequence of packets which conform uniquely
or more destinations, which conform uniquely to a flow to a flow identifier, and to which the DetNet service is to
identifier, and to which the DetNet service is to be be provided. It includes any DetNet headers added to support
provided. the DetNet service and forwarding sub-layers.
DetNet forwarding sub-layer DetNet forwarding sub-layer
The DetNet layer that optionally provides resource allocation DetNet functionality is divided into two sub-layers. One of
for DetNet flows over paths provided by the underlying them is the DetNet forwarding sub-layer, which optionally
network. provides resource allocation for DetNet flows over paths
provided by the underlying network.
DetNet intermediate node DetNet intermediate node
A DetNet relay node or DetNet transit node. A DetNet relay node or DetNet transit node.
DetNet node DetNet node
A DetNet edge node, a DetNet relay node, or a DetNet transit A DetNet edge node, a DetNet relay node, or a DetNet transit
node. node.
DetNet relay node DetNet relay node
A DetNet node including a service sub-layer function that A DetNet node including a service sub-layer function that
interconnects different DetNet forwarding sub-layer paths to interconnects different DetNet forwarding sub-layer paths to
provide service protection. A DetNet relay node participates provide service protection. A DetNet relay node participates
in the DetNet service sub-layer. It typically incorporates in the DetNet service sub-layer. It typically incorporates
DetNet forwarding sub-layer functions as well, in which case DetNet forwarding sub-layer functions as well, in which case
it is collocated with a transit node. it is collocated with a transit node.
DetNet service sub-layer DetNet service sub-layer
The DetNet sub-layer at which A DetNet service, e.g., service DetNet functionality is divided into two sub-layers. One of
protection is provided. them is the DetNet service sub-layer, at which a DetNet
service, e.g., service protection is provided.
DetNet service proxy DetNet service proxy
Maps between App-flows and DetNet flows. Maps between App-flows and DetNet flows.
DetNet source DetNet source
An end system capable of originating a DetNet flow. An end system capable of originating a DetNet flow.
DetNet system DetNet system
A DetNet aware end system, transit node, or relay node. A DetNet aware end system, transit node, or relay node.
"DetNet" may be omitted in some text. "DetNet" may be omitted in some text.
skipping to change at page 8, line 35 skipping to change at page 8, line 42
o Service protection (Section 3.2.2). o Service protection (Section 3.2.2).
o Explicit routes (Section 3.2.3). o Explicit routes (Section 3.2.3).
Resource allocation operates by assigning resources, e.g., buffer Resource allocation operates by assigning resources, e.g., buffer
space or link bandwidth, to a DetNet flow (or flow aggregate) along space or link bandwidth, to a DetNet flow (or flow aggregate) along
its path. Resource allocation greatly reduces, or even eliminates its path. Resource allocation greatly reduces, or even eliminates
entirely, packet loss due to output packet contention within the entirely, packet loss due to output packet contention within the
network, but it can only be supplied to a DetNet flow that is limited network, but it can only be supplied to a DetNet flow that is limited
at the source to a maximum packet size and transmission rate. As at the source to a maximum packet size and transmission rate. As
DetNet provides allocated resources (including provisioned capacity) DetNet flows are assumed to be rate-limited and DetNet is designed to
to DetNet flows the use of transport layer congestion control provide sufficient allocated resources (including provisioned
[RFC2914] by App-flows is explicitly not required. capacity), the use of transport layer congestion control [RFC2914]
for App-flows is not required; however, if resources are allocated
appropriately, use of congestion control should not impact
transmission negatively.
Resource allocation addresses two of the DetNet QoS requirements: Resource allocation addresses two of the DetNet QoS requirements:
latency and packet loss. Given that DetNet nodes have a finite latency and packet loss. Given that DetNet nodes have a finite
amount of buffer space, resource allocation necessarily results in a amount of buffer space, resource allocation necessarily results in a
maximum end-to-end latency. It also addresses contention related maximum end-to-end latency. It also addresses contention related
packet loss. packet loss.
Other important contribution to packet loss are random media errors Other important contribution to packet loss are random media errors
and equipment failures. Service protection is the name for the and equipment failures. Service protection is the name for the
mechanisms used by DetNet to address these losses. The mechanisms mechanisms used by DetNet to address these losses. The mechanisms
skipping to change at page 10, line 34 skipping to change at page 10, line 45
not expected to be responsive to implicit [RFC2914] or explicit not expected to be responsive to implicit [RFC2914] or explicit
congestion notification [RFC3168]. congestion notification [RFC3168].
Ensuring adequate buffering requires, in turn, that the source, and Ensuring adequate buffering requires, in turn, that the source, and
every DetNet node along the path to the destination (or nearly every every DetNet node along the path to the destination (or nearly every
node, see Section 4.3.3) be careful to regulate its output to not node, see Section 4.3.3) be careful to regulate its output to not
exceed the data rate for any DetNet flow, except for brief periods exceed the data rate for any DetNet flow, except for brief periods
when making up for interfering traffic. Any packet sent ahead of its when making up for interfering traffic. Any packet sent ahead of its
time potentially adds to the number of buffers required by the next time potentially adds to the number of buffers required by the next
hop DetNet node and may thus exceed the resources allocated for a hop DetNet node and may thus exceed the resources allocated for a
particular DetNet flow. particular DetNet flow. Furthermore, rate limiting, e.g., using
traffic policing and shaping functions, e.g., [RFC2475], at the
ingress of the DetNet domain must be applied. This is needed for
meeting the requirements of DetNet flows as well as for protecting
non-DetNet traffic from potentially misbehaving DetNet traffic
sources. Note that large buffers have some issues, see, e.g.,
[BUFFERBLOAT].
The low-level mechanisms described in Section 4.5 provide the The low-level mechanisms described in Section 4.5 provide the
necessary regulation of transmissions by an end system or DetNet node necessary regulation of transmissions by an end system or DetNet node
to provide resource allocation. The allocation of the bandwidth and to provide resource allocation. The allocation of the bandwidth and
buffers for a DetNet flow requires provisioning. A DetNet node may buffers for a DetNet flow requires provisioning. A DetNet node may
have other resources requiring allocation and/or scheduling, that have other resources requiring allocation and/or scheduling, that
might otherwise be over-subscribed and trigger the rejection of a might otherwise be over-subscribed and trigger the rejection of a
reservation. reservation.
3.2.1.2. Jitter Reduction 3.2.1.2. Jitter Reduction
A core objective of DetNet is to enable the convergence of sensitive A core objective of DetNet is to enable the convergence of sensitive
non-IP networks onto a common network infrastructure. This requires non-IP networks onto a common network infrastructure. This requires
the accurate emulation of currently deployed mission-specific the accurate emulation of currently deployed mission-specific
networks, which for example rely on point-to-point analog (e.g., networks, which for example rely on point-to-point analog (e.g.,
4-20mA modulation) and serial-digital cables (or buses) for highly 4-20mA modulation) and serial-digital cables (or buses) for highly
reliable, synchronized and jitter-free communications. While the reliable, synchronized and jitter-free communications. While the
latency of analog transmissions is basically the speed of light, latency of analog transmissions is basically the speed of light,
legacy serial links are usually slow (in the order of Kbps) compared legacy serial links are usually slow (in the order of Kbps) compared
to, say, GigE, and some latency is usually acceptable. What is not to, say, Gigabit Ethernet, and some latency is usually acceptable.
acceptable is the introduction of excessive jitter, which may, for What is not acceptable is the introduction of excessive jitter, which
instance, affect the stability of control systems. may, for instance, affect the stability of control systems.
Applications that are designed to operate on serial links usually do Applications that are designed to operate on serial links usually do
not provide services to recover the jitter, because jitter simply not provide services to recover the jitter, because jitter simply
does not exist there. DetNet flows are generally expected to be does not exist there. DetNet flows are generally expected to be
delivered in-order and the precise time of reception influences the delivered in-order and the precise time of reception influences the
processes. In order to converge such existing applications, there is processes. In order to converge such existing applications, there is
a desire to emulate all properties of the serial cable, such as clock a desire to emulate all properties of the serial cable, such as clock
transportation, perfect flow isolation and fixed latency. While transportation, perfect flow isolation and fixed latency. While
minimal jitter (in the form of specifying minimum, as well as minimal jitter (in the form of specifying minimum, as well as
maximum, end-to-end latency) is supported by DetNet, there are maximum, end-to-end latency) is supported by DetNet, there are
practical limitations on packet-based networks in this regard. In practical limitations on packet-based networks in this regard. In
general, users are encouraged to use, instead of, "do this when you general, users are encouraged to use a combination of:
get the packet," a combination of:
o Sub-microsecond time synchronization among all source and o Sub-microsecond time synchronization among all source and
destination end systems, and destination end systems, and
o Time-of-execution fields in the application packets. o Time-of-execution fields in the application packets.
Jitter reduction is provided by the mechanisms described in Jitter reduction is provided by the mechanisms described in
Section 4.5 that also provide resource allocation. Section 4.5 that also provide resource allocation.
3.2.2. Service Protection 3.2.2. Service Protection
Service protection aims to mitigate or eliminate packet loss due to Service protection aims to mitigate or eliminate packet loss due to
equipment failures, random media and/or memory faults. These types equipment failures, including random media and/or memory faults.
of packet loss can be greatly reduced by spreading the data over These types of packet loss can be greatly reduced by spreading the
multiple disjoint forwarding paths. Various service protection data over multiple disjoint forwarding paths. Various service
methods are described in [RFC6372], e.g., 1+1 linear protection. protection methods are described in [RFC6372], e.g., 1+1 linear
This section describes the functional details of an additional method protection. This section describes the functional details of an
in Section 3.2.2.2, which can be implemented as described in additional method in Section 3.2.2.2, which can be implemented as
Section 3.2.2.3 or as specified in [I-D.ietf-detnet-dp-sol-mpls] in described in Section 3.2.2.3 or as specified in
order to provide 1+n hitless protection. The appropriate service [I-D.ietf-detnet-dp-sol-mpls] in order to provide 1+n hitless
protection mechanism depends on the scenario and the requirements. protection. The appropriate service protection mechanism depends on
the scenario and the requirements.
3.2.2.1. In-Order Delivery 3.2.2.1. In-Order Delivery
Out-of-order packet delivery can be a side effect of service Out-of-order packet delivery can be a side effect of service
protection. Packets delivered out-of-order impact the amount of protection. Packets delivered out-of-order impact the amount of
buffering needed at the destination to properly process the received buffering needed at the destination to properly process the received
data. Such packets also influence the jitter of a flow. The DetNet data. Such packets also influence the jitter of a flow. The DetNet
service includes maximum allowed misordering as a constraint. Zero service includes maximum allowed misordering as a constraint. Zero
misordering would be a valid service constraint to reflect that the misordering would be a valid service constraint to reflect that the
end system(s) of the flow cannot tolerate any out-of-order delivery. end system(s) of the flow cannot tolerate any out-of-order delivery.
skipping to change at page 12, line 16 skipping to change at page 12, line 32
used to provide in-order delivery. used to provide in-order delivery.
3.2.2.2. Packet Replication and Elimination 3.2.2.2. Packet Replication and Elimination
This section describes a service protection method that sends copies This section describes a service protection method that sends copies
of the same packets over multiple paths. of the same packets over multiple paths.
The DetNet service sub-layer includes the packet replication (PRF), The DetNet service sub-layer includes the packet replication (PRF),
the packet elimination (PEF), and the packet ordering functionality the packet elimination (PEF), and the packet ordering functionality
(POF) for use in DetNet edge, relay node, and end system packet (POF) for use in DetNet edge, relay node, and end system packet
processing. Either of these functions can be enabled in a DetNet processing. These functions can be enabled in a DetNet edge node,
edge node, relay node or end system. The collective name for all relay node or end system. The collective name for all three
three functions is PREOF. The packet replication and elimination functions is Packet Replication, Elimination, and Ordering Functions
service protection method altogether involves four capabilities: (PREOF). The packet replication and elimination service protection
method altogether involves four capabilities:
o Providing sequencing information to the packets of a DetNet o Providing sequencing information to the packets of a DetNet
compound flow. This may be done by adding a sequence number or compound flow. This may be done by adding a sequence number or
time stamp as part of DetNet, or may be inherent in the packet, time stamp as part of DetNet, or may be inherent in the packet,
e.g., in a higher layer protocol, or associated to other physical e.g., in a higher layer protocol, or associated to other physical
properties such as the precise time (and radio channel) of properties such as the precise time (and radio channel) of
reception of the packet. This is typically done once, at or near reception of the packet. This is typically done once, at or near
the source. the source.
o The Packet Replication Function (PRF) replicates these packets o The Packet Replication Function (PRF) replicates these packets
into multiple DetNet member flows and typically sends them along into multiple DetNet member flows and typically sends them along
multiple different paths to the destination(s), e.g., over the multiple different paths to the destination(s), e.g., over the
explicit routes of Section 3.2.3. The location within a DetNet explicit routes of Section 3.2.3. The location within a DetNet
node, and the mechanism used for the PRF is implementation node, and the mechanism used for the PRF is left open for
specific. implementations.
o The Packet Elimination Function (PEF) eliminates duplicate packets o The Packet Elimination Function (PEF) eliminates duplicate packets
of a DetNet flow based on the sequencing information and a history of a DetNet flow based on the sequencing information and a history
of received packets. The output of the PEF is always a single of received packets. The output of the PEF is always a single
packet. This may be done at any DetNet node along the path to packet. This may be done at any DetNet node along the path to
save network resources further downstream, in particular if save network resources further downstream, in particular if
multiple Replication points exist. But the most common case is to multiple Replication points exist. But the most common case is to
perform this operation at the very edge of the DetNet network, perform this operation at the very edge of the DetNet network,
preferably in or near the receiver. The location within a DetNet preferably in or near the receiver. The location within a DetNet
node, and mechanism used for the PEF is implementation specific. node, and mechanism used for the PEF is left open for
implementations.
o The Packet Ordering Function (POF) uses the sequencing information o The Packet Ordering Function (POF) uses the sequencing information
to re-order a DetNet flow's packets that are received out of to re-order a DetNet flow's packets that are received out of
order. order.
The order in which a DetNet node applies PEF, POF, and PRF to a The order in which a DetNet node applies PEF, POF, and PRF to a
DetNet flow is implementation specific. DetNet flow is left open for implementations.
Some service protection mechanisms rely on switching from one flow to Some service protection mechanisms rely on switching from one flow to
another when a failure of a flow is detected. Contrarily, packet another when a failure of a flow is detected. Contrarily, packet
replication and elimination combines the DetNet member flows sent replication and elimination combines the DetNet member flows sent
along multiple different paths, and performs a packet-by-packet along multiple different paths, and performs a packet-by-packet
selection of which to discard, e.g., based on sequencing information. selection of which to discard, e.g., based on sequencing information.
In the simplest case, this amounts to replicating each packet in a In the simplest case, this amounts to replicating each packet in a
source that has two interfaces, and conveying them through the source that has two interfaces, and conveying them through the
network, along separate (SRLG disjoint) paths, to the similarly dual- network, along separate (Shared Risk Link Group (SRLG) disjoint)
homed destinations, that discard the extras. This ensures that one paths, to the similarly dual-homed destinations, that discard the
path remains, even if some DetNet intermediate node fails. The extras. This ensures that one path remains, even if some DetNet
sequencing information can also be used for loss detection and for intermediate node fails. The sequencing information can also be used
re-ordering. for loss detection and for re-ordering.
DetNet relay nodes in the network can provide replication and DetNet relay nodes in the network can provide replication and
elimination facilities at various points in the network, so that elimination facilities at various points in the network, so that
multiple failures can be accommodated. multiple failures can be accommodated.
This is shown in Figure 1, where the two relay nodes each replicate This is shown in Figure 1, where the two relay nodes each replicate
(R) the DetNet flow on input, sending the DetNet member flows to both (R) the DetNet flow on input, sending the DetNet member flows to both
the other relay node and to the end system, and eliminate duplicates the other relay node and to the end system, and eliminate duplicates
(E) on the output interface to the right-hand end system. Any one (E) on the output interface to the right-hand end system. Any one
link in the network can fail, and the DetNet compound flow can still link in the network can fail, and the DetNet compound flow can still
skipping to change at page 13, line 48 skipping to change at page 14, line 22
> > > > > > > > > node > > > > > > > > > > > > > > > > > node > > > > > > > >
Figure 1: Packet replication and elimination Figure 1: Packet replication and elimination
Packet replication and elimination does not react to and correct Packet replication and elimination does not react to and correct
failures; it is entirely passive. Thus, intermittent failures, failures; it is entirely passive. Thus, intermittent failures,
mistakenly created packet filters, or misrouted data is handled just mistakenly created packet filters, or misrouted data is handled just
the same as the equipment failures that are handled by typical the same as the equipment failures that are handled by typical
routing and bridging protocols. routing and bridging protocols.
If packet replication and elimination is used over paths with If member flows that take different-length paths through the network
resource allocation (Section 3.2.1), and member flows that take are combined, a merge point may require extra buffering to equalize
different-length paths through the network are combined, a merge the delays over the different paths. This equalization ensures that
point may require extra buffering to equalize the delays over the the resultant compound flow will not exceed its contracted bandwidth
different paths. This equalization ensures that the resultant even after one or the other of the paths is restored after a failure.
compound flow will not exceed its contracted bandwidth even after one The extra buffering can be also used to provide in-order delivery.
or the other of the paths is restored after a failure. The extra
buffering can be also used to provide in-order delivery.
3.2.2.3. Packet encoding for service protection 3.2.2.3. Packet encoding for service protection
There are methods for using multiple paths to provide service There are methods for using multiple paths to provide service
protection that involve encoding the information in a packet protection that involve encoding the information in a packet
belonging to a DetNet flow into multiple transmission units, belonging to a DetNet flow into multiple transmission units,
combining information from multiple packets into any given combining information from multiple packets into any given
transmission unit. Such techniques, also known as "network coding", transmission unit. Such techniques, also known as "network coding",
can be used as a DetNet service protection technique. can be used as a DetNet service protection technique.
skipping to change at page 14, line 44 skipping to change at page 15, line 16
and thus latency, for the typical path. and thus latency, for the typical path.
In order to get the advantages of low hop count and still ensure In order to get the advantages of low hop count and still ensure
against even very brief losses of connectivity, DetNet employs against even very brief losses of connectivity, DetNet employs
explicit routes, where the path taken by a given DetNet flow does not explicit routes, where the path taken by a given DetNet flow does not
change, at least immediately, and likely not at all, in response to change, at least immediately, and likely not at all, in response to
network topology events. Service protection (Section 3.2.2 or network topology events. Service protection (Section 3.2.2 or
Section 3.2.2.3) over explicit routes provides a high likelihood of Section 3.2.2.3) over explicit routes provides a high likelihood of
continuous connectivity. Explicit routes can be established in continuous connectivity. Explicit routes can be established in
various ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR) various ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR)
[RFC8402], via a Software Defined Networking approach [RFC7426], [RFC8402], via a Software Defined Networking approach [RFC8453], with
[RFC8453], and [RFC8453], with IS-IS [RFC7813], etc. Explicit routes IS-IS [RFC7813], etc. Explicit routes are typically used in MPLS TE
are typically used in MPLS TE LSPs. LSPs.
Out-of-order packet delivery can be a side effect of distributing a Out-of-order packet delivery can be a side effect of distributing a
single flow over multiple paths especially when there is a change single flow over multiple paths, especially when there is a change
from one path to another when combining the flow. This is from one path to another when combining the flow. This is
irrespective of the distribution method used, and also applies to irrespective of the distribution method used, and also applies to
service protection over explicit routes. As described in service protection over explicit routes. As described in
Section 3.2.2.1, out-of-order packets influence the jitter of a flow Section 3.2.2.1, out-of-order packets influence the jitter of a flow
and impact the amount of buffering needed to process the data; and impact the amount of buffering needed to process the data;
therefore, DetNet service includes maximum allowed misordering as a therefore, DetNet service includes maximum allowed misordering as a
constraint. The use of explicit routes helps to provide in-order constraint. The use of explicit routes helps to provide in-order
delivery because there is no immediate route change with the network delivery because there is no immediate route change with the network
topology, but the changes are plannable as they are between the topology, but the changes are plannable as they are between the
different explicit routes. different explicit routes.
skipping to change at page 15, line 44 skipping to change at page 16, line 17
case latency. case latency.
o When transmission opportunities for DetNet flows are scheduled in o When transmission opportunities for DetNet flows are scheduled in
detail, then the algorithm constructing the schedule should leave detail, then the algorithm constructing the schedule should leave
sufficient opportunities for non-DetNet packets to satisfy the sufficient opportunities for non-DetNet packets to satisfy the
needs of the users of the network. Detailed scheduling can also needs of the users of the network. Detailed scheduling can also
permit the time-shared use of buffer resources by different DetNet permit the time-shared use of buffer resources by different DetNet
flows. flows.
Starvation of non-DetNet traffic must be avoided, e.g., by traffic Starvation of non-DetNet traffic must be avoided, e.g., by traffic
policing functions (e.g., [RFC2475]). Thus, the net effect of the policing and shaping functions (e.g., [RFC2475]). Thus, the net
presence of DetNet flows in a network on the non-DetNet flows is effect of the presence of DetNet flows in a network on the non-DetNet
primarily a reduction in the available bandwidth. flows is primarily a reduction in the available bandwidth.
3.3.2. Fault Mitigation 3.3.2. Fault Mitigation
Robust real-time systems require to reduce the number of possible Robust real-time systems require reducing the number of possible
failures. Filters and policers should be used in a DetNet network to failures. Filters and policers should be used in a DetNet network to
detect if DetNet packets are received on the wrong interface, or at detect if DetNet packets are received on the wrong interface, or at
the wrong time, or in too great a volume. Furthermore, filters and the wrong time, or in too great a volume. Furthermore, filters and
policers can take actions to discard the offending packets or flows, policers can take actions to discard the offending packets or flows,
or trigger shutting down the offending flow or the offending or trigger shutting down the offending flow or the offending
interface. interface.
It is also essential that filters and service remarking be employed It is also essential that filters and service remarking be employed
at the network edge to prevent non-DetNet packets from being mistaken at the network edge to prevent non-DetNet packets from being mistaken
for DetNet packets, and thus impinging on the resources allocated to for DetNet packets, and thus impinging on the resources allocated to
skipping to change at page 16, line 46 skipping to change at page 17, line 13
latency) from end systems. latency) from end systems.
The mechanisms to support these requirements are both data plane and The mechanisms to support these requirements are both data plane and
implementation specific. Data plane specific solutions will be implementation specific. Data plane specific solutions will be
specified in the relevant data plane solution document. There also specified in the relevant data plane solution document. There also
exist techniques, at present and/or in various stages of exist techniques, at present and/or in various stages of
standardization, that can support these fault mitigation tasks that standardization, that can support these fault mitigation tasks that
deliver a high probability that misbehaving systems will have zero deliver a high probability that misbehaving systems will have zero
impact on well-behaved DetNet flows, except of course, for the impact on well-behaved DetNet flows, except of course, for the
receiving interface(s) immediately downstream of the misbehaving receiving interface(s) immediately downstream of the misbehaving
device. Examples of such techniques include traffic policing device. Examples of such techniques include traffic policing and
functions (e.g., [RFC2475]) and separating flows into per-flow rate- shaping functions (e.g., [RFC2475]) and separating flows into per-
limited queues. flow rate-limited queues.
4. DetNet Architecture 4. DetNet Architecture
4.1. DetNet stack model 4.1. DetNet stack model
DetNet functionality (Section 3) is implemented in two adjacent sub- DetNet functionality (Section 3) is implemented in two adjacent sub-
layers in the protocol stack: the DetNet service sub-layer and the layers in the protocol stack: the DetNet service sub-layer and the
DetNet forwarding sub-layer. The DetNet service sub-layer provides DetNet forwarding sub-layer. The DetNet service sub-layer provides
DetNet service, e.g., service protection, to higher layers in the DetNet service, e.g., service protection, to higher layers in the
protocol stack and applications. The DetNet forwarding sub-layer protocol stack and applications. The DetNet forwarding sub-layer
skipping to change at page 17, line 52 skipping to change at page 18, line 35
Not all sub-layers are required for any given application, or even Not all sub-layers are required for any given application, or even
for any given network. The functionality shown in Figure 2 is: for any given network. The functionality shown in Figure 2 is:
Application Application
Shown as "source" and "destination" in the diagram. Shown as "source" and "destination" in the diagram.
Packet sequencing Packet sequencing
As part of DetNet service protection, supplies the sequence As part of DetNet service protection, supplies the sequence
number for packet replication and elimination number for packet replication and elimination
(Section 3.2.2). Peers with Duplicate elimination. This (Section 3.2.2), thus peers with Duplicate elimination. This
sub-layer is not needed if a higher layer protocol is sub-layer is not needed if a higher layer protocol is
expected to perform any packet sequencing and duplicate expected to perform any packet sequencing and duplicate
elimination required by the DetNet flow replication. elimination required by the DetNet flow replication.
Duplicate elimination Duplicate elimination
As part of the DetNet service sub-layer, based on the As part of the DetNet service sub-layer, based on the
sequenced number supplied by its peer, packet sequencing, sequenced number supplied by its peer, packet sequencing,
Duplicate elimination discards any duplicate packets Duplicate elimination discards any duplicate packets
generated by DetNet flow replication. It can operate on generated by DetNet flow replication. It can operate on
member flows, compound flows, or both. The replication may member flows, compound flows, or both. The replication may
skipping to change at page 19, line 10 skipping to change at page 19, line 42
Packet decoding Packet decoding
As part of DetNet service protection, as an alternative to As part of DetNet service protection, as an alternative to
flow merging and duplicate elimination, packet decoding takes flow merging and duplicate elimination, packet decoding takes
packets from different DetNet member flows, and computes from packets from different DetNet member flows, and computes from
those packets the original DetNet packets from the compound those packets the original DetNet packets from the compound
flows input to packet encoding. Peers with Packet encoding. flows input to packet encoding. Peers with Packet encoding.
Resource allocation Resource allocation
The DetNet forwarding sub-layer provides resource allocation. The DetNet forwarding sub-layer provides resource allocation.
See Section 4.5. The actual queuing and shaping mechanisms See Section 4.5. The actual queuing and shaping mechanisms
are typically provided by underlying subnet, these can be are typically provided by underlying subnet. These can be
closely associated with the means of providing paths for closely associated with the means of providing paths for
DetNet flows, the path and the resource allocation are DetNet flows. The path and the resource allocation are
conflated in this figure. conflated in this figure.
Explicit routes Explicit routes
The DetNet forwarding sub-layer provides mechanisms to ensure The DetNet forwarding sub-layer provides mechanisms to ensure
that fixed paths are provided for DetNet flows. These that fixed paths are provided for DetNet flows. These
explicit paths avoid the impact of network convergence. explicit paths avoid the impact of network convergence.
Operations, Administration, and Maintenance (OAM) leverages in-band Operations, Administration, and Maintenance (OAM) leverages in-band
and out-of-band signaling that validates whether the service is and out-of-band signaling that validates whether the service is
effectively obtained within QoS constraints. OAM is not shown in effectively obtained within QoS constraints. OAM is not shown in
skipping to change at page 19, line 40 skipping to change at page 20, line 25
for instance, generate special test probes or add OAM information for instance, generate special test probes or add OAM information
into the data packet. into the data packet.
The packet sequencing and replication elimination functions at the The packet sequencing and replication elimination functions at the
source and destination ends of a DetNet compound flow may be source and destination ends of a DetNet compound flow may be
performed either in the end system or in a DetNet relay node. performed either in the end system or in a DetNet relay node.
4.1.2. DetNet Data Plane Overview 4.1.2. DetNet Data Plane Overview
A "Deterministic Network" will be composed of DetNet enabled end A "Deterministic Network" will be composed of DetNet enabled end
systems, DetNet edge nodes, DetNet relay nodes and collectively systems, DetNet edge nodes, and DetNet relay nodes, which
deliver DetNet services. DetNet relay and edge nodes are collectively deliver DetNet services. DetNet relay and edge nodes
interconnected via DetNet transit nodes (e.g., LSRs) which support are interconnected via DetNet transit nodes (e.g., LSRs) which
DetNet, but are not DetNet service aware. All DetNet nodes are support DetNet, but are not DetNet service aware. All DetNet nodes
connected to sub-networks, where a point-to-point link is also are connected to sub-networks, where a point-to-point link is also
considered as a simple sub-network. These sub-networks will provide considered as a simple sub-network. These sub-networks will provide
DetNet compatible service for support of DetNet traffic. Examples of DetNet compatible service for support of DetNet traffic. Examples of
sub-networks include MPLS TE, IEEE 802.1 TSN and OTN. Of course, sub-network technologies include MPLS TE, IEEE 802.1 TSN and OTN. Of
multi-layer DetNet systems may also be possible, where one DetNet course, multi-layer DetNet systems may also be possible, where one
appears as a sub-network, and provides service to, a higher layer DetNet appears as a sub-network, and provides service to, a higher
DetNet system. A simple DetNet concept network is shown in Figure 3. layer DetNet system. A simple DetNet concept network is shown in
Note that in this and following figures "Forwarding" and "Fwd" refer Figure 3. Note that in this and following figures "Forwarding" and
to the DetNet forwarding sub-layer, "Service" and "Svc" refer to the "Fwd" refer to the DetNet forwarding sub-layer, "Service" and "Svc"
DetNet service sub-layer, which are described in detail in refer to the DetNet service sub-layer, which are described in detail
Section 4.1. in Section 4.1.
TSN Edge Transit Relay DetNet TSN Edge Transit Relay DetNet
End System Node Node Node End System End System Node Node Node End System
+----------+ +.........+ +----------+ +----------+ +.........+ +----------+
| Appl. |<--:Svc Proxy:-- End to End Service -------->| Appl. | | Appl. |<--:Svc Proxy:-- End to End Service -------->| Appl. |
+----------+ +---------+ +---------+ +----------+ +----------+ +---------+ +---------+ +----------+
| TSN | |TSN| |Svc|<- DetNet flow --: Service :-->| Service | | TSN | |TSN| |Svc|<- DetNet flow --: Service :-->| Service |
+----------+ +---+ +---+ +--------+ +---------+ +----------+ +----------+ +---+ +---+ +--------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| |Forwarding| |Forwarding| |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +--.----.+ +-.-+ +-.-+ +---.------+ +-------.--+ +-.-+ +-.-+ +--.----.+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \ : Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +.......+ +-[ Sub ]-+ +........+ +-[ Sub ]-+ +.......+ +-[ Sub ]-+
[Network] [Network] [Network] [Network]
`-----' `-----' `-----' `-----'
Figure 3: A Simple DetNet Enabled Network Figure 3: A Simple DetNet Enabled Network
Distinguishing the function of two DetNet data plane sub-layers, the DetNet data plane is divided into two sub-layers: the DetNet service
DetNet service sub-layer and the DetNet forwarding sub-layer, helps sub-layer and the DetNet forwarding sub-layer. This helps to explore
to explore and evaluate various combinations of the data plane and evaluate various combinations of the data plane solutions
solutions available, some are illustrated in Figure 4. This available. Some of them are illustrated in Figure 4. This
separation of DetNet sub-layers, while helpful, should not be separation of DetNet sub-layers, while helpful, should not be
considered as formal requirement. For example, some technologies may considered as formal requirement. For example, some technologies may
violate these strict sub-layers and still be able to deliver a DetNet violate these strict sub-layers and still be able to deliver a DetNet
service. service.
. .
. .
+-----------------------------+ +-----------------------------+
| DetNet Service sub-layer | PW, UDP, GRE | DetNet Service sub-layer | PW, UDP, GRE
+-----------------------------+ +-----------------------------+
skipping to change at page 21, line 8 skipping to change at page 22, line 4
In some networking scenarios, the end system initially provides a In some networking scenarios, the end system initially provides a
DetNet flow encapsulation, which contains all information needed by DetNet flow encapsulation, which contains all information needed by
DetNet nodes (e.g., Real-time Transport Protocol (RTP) [RFC3550] DetNet nodes (e.g., Real-time Transport Protocol (RTP) [RFC3550]
based DetNet flow carried over a native UDP/IP network or based DetNet flow carried over a native UDP/IP network or
PseudoWire). In other scenarios, the encapsulation formats might PseudoWire). In other scenarios, the encapsulation formats might
differ significantly. differ significantly.
There are many valid options to create a data plane solution for There are many valid options to create a data plane solution for
DetNet traffic by selecting a technology approach for the DetNet DetNet traffic by selecting a technology approach for the DetNet
service sub-layer and also selecting a technology approach for the service sub-layer and also selecting a technology approach for the
DetNet forwarding sub-layer. There are a high number of valid DetNet forwarding sub-layer. There are a large number of valid
combinations. combinations.
One of the most fundamental differences between different potential One of the most fundamental differences between different potential
data plane options is the basic headers used by DetNet nodes. For data plane options is the basic headers used by DetNet nodes. For
example, the basic service can be delivered based on an MPLS label or example, the basic service can be delivered based on an MPLS label or
an IP header. This decision impacts the basic forwarding logic for an IP header. This decision impacts the basic forwarding logic for
the DetNet service sub-layer. Note that in both cases, IP addresses the DetNet service sub-layer. Note that in both cases, IP addresses
are used to address DetNet nodes. The selected DetNet forwarding are used to address DetNet nodes. The selected DetNet forwarding
sub-layer technology also needs to be mapped to the sub-net sub-layer technology also needs to be mapped to the sub-net
technology used to interconnect DetNet nodes. For example, DetNet technology used to interconnect DetNet nodes. For example, DetNet
skipping to change at page 22, line 35 skipping to change at page 23, line 5
| \_____/ \___________/ | | \_____/ \___________/ |
| | | |
| | End-to-End service | | | | | | End-to-End service | | | |
<-------------------------------------------------------------> <------------------------------------------------------------->
| | DetNet service | | | | | | DetNet service | | | |
| <------------------------------------------------> | | <------------------------------------------------> |
| | | | | | | | | | | |
Figure 5: DetNet Service Reference Model (multi-domain) Figure 5: DetNet Service Reference Model (multi-domain)
DetNet-UNIs ("U" in Figure 5) are assumed in this document to be DetNet User Network Interfaces (DetNet-UNIs) ("U" in Figure 5) are
packet-based reference points and provide connectivity over the assumed in this document to be packet-based reference points and
packet network. A DetNet-UNI may provide multiple functions, e.g., provide connectivity over the packet network. A DetNet-UNI may
it may add networking technology specific encapsulation to the DetNet provide multiple functions, e.g., it may add networking technology
flows if necessary; it may provide status of the availability of the specific encapsulation to the DetNet flows if necessary; it may
resources associated with a reservation; it may provide a provide status of the availability of the resources associated with a
synchronization service for the end system; it may carry enough reservation; it may provide a synchronization service for the end
signaling to place the reservation in a network without a controller, system; it may carry enough signaling to place the reservation in a
or if the controller only deals with the network but not the end network without a controller, or if the controller only deals with
systems. Internal reference points of end systems (between the the network but not the end systems. Internal reference points of
application and the NIC) are more challenging from control end systems (between the application and the NIC) are more
perspective and they may have extra requirements (e.g., in-order challenging from control perspective and they may have extra
delivery is expected in end system internal reference points, whereas requirements (e.g., in-order delivery is expected in end system
it is considered optional over the DetNet-UNI). internal reference points, whereas it is considered optional over the
DetNet-UNI).
4.2. DetNet systems 4.2. DetNet systems
4.2.1. End system 4.2.1. End system
The native data flow between the source/destination end systems is The traffic characteristics of an App-flow can be CBR (constant bit
referred to as application-flow (App-flow). The traffic rate) or VBR (variable bit rate) and can have Layer-1 or Layer-2 or
characteristics of an App-flow can be CBR (constant bit rate) or VBR Layer-3 encapsulation (e.g., TDM (time-division multiplexing),
(variable bit rate) and can have L1 or L2 or L3 encapsulation (e.g., Ethernet, IP). These characteristics are considered as input for
TDM (time-division multiplexing), Ethernet, IP). These resource reservation and might be simplified to ensure determinism
characteristics are considered as input for resource reservation and during packet forwarding (e.g., making reservations for the peak rate
might be simplified to ensure determinism during packet forwarding of VBR traffic, etc.).
(e.g., making reservations for the peak rate of VBR traffic, etc.).
An end system may or may not be DetNet forwarding sub-layer aware or An end system may or may not be DetNet forwarding sub-layer aware or
DetNet service sub-layer aware. That is, an end system may or may DetNet service sub-layer aware. That is, an end system may or may
not contain DetNet specific functionality. End systems with DetNet not contain DetNet specific functionality. End systems with DetNet
functionalities may have the same or different forwarding sub-layer functionalities may have the same or different forwarding sub-layer
as the connected DetNet domain. Categorization of end systems are as the connected DetNet domain. Categorization of end systems are
shown in Figure 6. shown in Figure 6.
End system End system
| |
skipping to change at page 24, line 42 skipping to change at page 25, line 22
to minimize the chances of packet loss and delay, and provision to minimize the chances of packet loss and delay, and provision
enough extra buffer space in the DetNet transit node following the enough extra buffer space in the DetNet transit node following the
DetNet-unaware network nodes to absorb the induced latency DetNet-unaware network nodes to absorb the induced latency
variations. variations.
4.3. DetNet flows 4.3. DetNet flows
4.3.1. DetNet flow types 4.3.1. DetNet flow types
A DetNet flow can have different formats while its packets are A DetNet flow can have different formats while its packets are
forwarded between the peer end systems. Therefore, the following forwarded between the peer end systems depending on the type of the
end systems. Corresponding to the end system types, the following
possible types / formats of a DetNet flow are distinguished in this possible types / formats of a DetNet flow are distinguished in this
document: document. The different flow types have different requirements to
DetNet nodes.
o App-flow: native format of the data carried over a DetNet flow. o App-flow: the payload (data) carried over a DetNet flow between
It does not contain any DetNet related attributes. DetNet unaware end systems. An app-flow does not contain any
DetNet related attributes and does not imply any specific
requirement on DetNet nodes.
o DetNet-f-flow: specific format of a DetNet flow. It only requires o DetNet-f-flow: specific format of a DetNet flow. It only requires
the resource allocation features provided by the DetNet forwarding the resource allocation features provided by the DetNet forwarding
sub-layer. sub-layer.
o DetNet-s-flow: specific format of a DetNet flow. It only requires o DetNet-s-flow: specific format of a DetNet flow. It only requires
the service protection feature ensured by the DetNet service sub- the service protection feature ensured by the DetNet service sub-
layer. layer.
o DetNet-sf-flow: specific format of a DetNet flow. It requires o DetNet-sf-flow: specific format of a DetNet flow. It requires
skipping to change at page 25, line 40 skipping to change at page 26, line 24
Asynchronous DetNet flows are characterized by: Asynchronous DetNet flows are characterized by:
o A maximum packet size; o A maximum packet size;
o An observation interval; and o An observation interval; and
o A maximum number of transmissions during that observation o A maximum number of transmissions during that observation
interval. interval.
These parameters, together with knowledge of the protocol stack used These parameters, together with knowledge of the protocol stack used
(and thus the size of the various headers added to a packet), limit (and thus the size of the various headers added to a packet), provide
the number of bit times per observation interval that the DetNet flow the bandwidth that is needed for the DetNet flow.
can occupy the physical medium.
The source is required not to exceed these limits in order to obtain The source is required not to exceed these limits in order to obtain
DetNet service. If the source transmits less data than this limit DetNet service. If the source transmits less data than this limit
allows, the unused resource such as link bandwidth can be made allows, the unused resource such as link bandwidth can be made
available by the DetNet system to non-DetNet packets as long as all available by the DetNet system to non-DetNet packets as long as all
guarantees are fulfilled. However, making those resources available guarantees are fulfilled. However, making those resources available
to DetNet packets in other DetNet flows would serve no purpose. to DetNet packets in other DetNet flows would serve no purpose.
Those other DetNet flows have their own dedicated resources, on the Those other DetNet flows have their own dedicated resources, on the
assumption that all DetNet flows can use all of their resources over assumption that all DetNet flows can use all of their resources over
a long period of time. a long period of time.
There is no expectation in DetNet for App-flows to be responsive to There is no expectation in DetNet for App-flows to be responsive to
implicit [RFC2914] or explicit congestion notification [RFC3168]. congestion control [RFC2914] or explicit congestion notification
The assumption is that a DetNet flow, to be useful, must be delivered [RFC3168]. The assumption is that a DetNet flow, to be useful, must
in its entirety. That is, while any useful application is written to be delivered in its entirety. That is, while any useful application
expect a certain number of lost packets, the real-time applications is written to expect a certain number of lost packets, the real-time
of interest to DetNet demand that the loss of data due to the network applications of interest to DetNet demand that the loss of data due
is a rare event. to the network is a rare event.
Although DetNet strives to minimize the changes required of an Although DetNet strives to minimize the changes required of an
application to allow it to shift from a special-purpose digital application to allow it to shift from a special-purpose digital
network to an Internet Protocol network, one fundamental shift in the network to an Internet Protocol network, one fundamental shift in the
behavior of network applications is impossible to avoid: the behavior of network applications is impossible to avoid: the
reservation of resources before the application starts. In the first reservation of resources before the application starts. In the first
place, a network cannot deliver finite latency and practically zero place, a network cannot deliver finite latency and practically zero
packet loss to an arbitrarily high offered load. Secondly, achieving packet loss to an arbitrarily high offered load. Secondly, achieving
practically zero packet loss for DetNet flows means that DetNet nodes practically zero packet loss for DetNet flows means that DetNet nodes
have to dedicate buffer resources to specific DetNet flows or to have to dedicate buffer resources to specific DetNet flows or to
skipping to change at page 28, line 16 skipping to change at page 28, line 48
Application Plane to communicate with the entities in the Controller Application Plane to communicate with the entities in the Controller
Plane as illustrated in Figure 7. Plane as illustrated in Figure 7.
One or more CPF(s) collaborate to implement the requests from the FME One or more CPF(s) collaborate to implement the requests from the FME
as Per-Flow Per-Hop Behaviors installed in the DetNet nodes for each as Per-Flow Per-Hop Behaviors installed in the DetNet nodes for each
individual flow. The CPFs place each flow along a deterministic individual flow. The CPFs place each flow along a deterministic
sequence of DetNet nodes so as to respect per-flow constraints such sequence of DetNet nodes so as to respect per-flow constraints such
as security and latency, and optimize the overall result for metrics as security and latency, and optimize the overall result for metrics
such as an abstract aggregated cost. The deterministic sequence can such as an abstract aggregated cost. The deterministic sequence can
typically be more complex than a direct sequence and include typically be more complex than a direct sequence and include
redundancy path, with one or more packet replication and elimination redundant paths, with one or more packet replication and elimination
points. Scaling to larger networks is discussed in Section 4.9. points. Scaling to larger networks is discussed in Section 4.9.
4.4.3. The Network Plane 4.4.3. The Network Plane
The Network Plane represents the network devices and protocols as a The Network Plane represents the network devices and protocols as a
whole, regardless of the Layer at which the network devices operate. whole, regardless of the Layer at which the network devices operate.
It includes Forwarding Plane (data plane), Application, and It includes Forwarding Plane (data plane), Application, and
Operational Plane (e.g., OAM) aspects. Operational Plane (e.g., OAM) aspects.
The network Plane comprises the Network Interface Cards (NIC) in the The network Plane comprises the Network Interface Cards (NIC) in the
skipping to change at page 30, line 34 skipping to change at page 31, line 7
a more stringent latency requirement, followed by the resumption a more stringent latency requirement, followed by the resumption
of the preempted packet [IEEE802.1Qbu] (superseded by of the preempted packet [IEEE802.1Qbu] (superseded by
[IEEE802.1Q-2018]), [IEEE802.3br] (superseded by [IEEE802.1Q-2018]), [IEEE802.3br] (superseded by
[IEEE802.3-2018]). [IEEE802.3-2018]).
While these techniques are currently embedded in Ethernet While these techniques are currently embedded in Ethernet
[IEEE802.3-2018] and bridging standards, we can note that they are [IEEE802.3-2018] and bridging standards, we can note that they are
all, except perhaps for packet preemption, equally applicable to all, except perhaps for packet preemption, equally applicable to
other media than Ethernet, and to routers as well as bridges. Other other media than Ethernet, and to routers as well as bridges. Other
media may have its own methods, see, e.g., media may have its own methods, see, e.g.,
[I-D.ietf-6tisch-architecture], [RFC7554]. DetNet may include such [I-D.ietf-6tisch-architecture], [RFC7554]. Further techniques are
definitions in the future, or may define how these techniques can be defined by the IETF, e.g., [RFC8289] and [RFC8033]. DetNet may
used by DetNet nodes. include such definitions in the future, or may define how these
techniques can be used by DetNet nodes.
4.6. Service instance 4.6. Service instance
A Service instance represents all the functions required on a DetNet A Service instance represents all the functions required on a DetNet
node to allow the end-to-end service between the UNIs. node to allow the end-to-end service between the UNIs.
The DetNet network general reference model is shown in Figure 8 for a The DetNet network general reference model is shown in Figure 8 for a
DetNet service scenario (i.e., between two DetNet-UNIs). In this DetNet service scenario (i.e., between two DetNet-UNIs). In this
figure, end systems ("A" and "B") are connected directly to the edge figure, end systems ("A" and "B") are connected directly to the edge
nodes of an IP/MPLS network ("PE1" and "PE2"). End systems nodes of an IP/MPLS network ("PE1" and "PE2"). End systems
skipping to change at page 32, line 4 skipping to change at page 32, line 34
[RFC6658] states: "The packet PW appears as a single point-to-point [RFC6658] states: "The packet PW appears as a single point-to-point
link to the client layer. Network-layer adjacency formation and link to the client layer. Network-layer adjacency formation and
maintenance between the client equipment will follow the normal maintenance between the client equipment will follow the normal
practice needed to support the required relationship in the client practice needed to support the required relationship in the client
layer ... This packet PseudoWire is used to transport all of the layer ... This packet PseudoWire is used to transport all of the
required Layer-2 and Layer-3 protocols between LSR1 and LSR2". required Layer-2 and Layer-3 protocols between LSR1 and LSR2".
Further details are network technology specific and can be found in Further details are network technology specific and can be found in
[I-D.ietf-detnet-dp-sol-mpls] and [I-D.ietf-detnet-dp-sol-ip]. [I-D.ietf-detnet-dp-sol-mpls] and [I-D.ietf-detnet-dp-sol-ip].
4.7. Flow identification at technology borders 4.7. Flow identification at technology borders
This section discusses what needs to be done at technology borders
including Ethernet as one of the technologies. Flow identification
for MPLS and IP data planes are described in
[I-D.ietf-detnet-dp-sol-mpls] and [I-D.ietf-detnet-dp-sol-ip],
respectively.
4.7.1. Exporting flow identification 4.7.1. Exporting flow identification
A DetNet node may need to map specific flows to lower layer flows (or A DetNet node may need to map specific flows to lower layer flows (or
Streams) in order to provide specific queuing and shaping services Streams) in order to provide specific queuing and shaping services
for specific flows. For example: for specific flows. For example:
o A non-IP, strictly L2 source end system X may be sending multiple o A non-IP, strictly L2 source end system X may be sending multiple
flows to the same L2 destination end system Y. Those flows may flows to the same L2 destination end system Y. Those flows may
include DetNet flows with different QoS requirements, and may include DetNet flows with different QoS requirements, and may
include non-DetNet flows. include non-DetNet flows.
skipping to change at page 36, line 19 skipping to change at page 37, line 9
Provisioning of DetNet requires knowledge about: Provisioning of DetNet requires knowledge about:
o Details of the DetNet system's capabilities that are required in o Details of the DetNet system's capabilities that are required in
order to accurately allocate that DetNet system's resources, as order to accurately allocate that DetNet system's resources, as
well as other DetNet systems' resources. This includes, for well as other DetNet systems' resources. This includes, for
example, which specific queuing and shaping algorithms are example, which specific queuing and shaping algorithms are
implemented (Section 4.5), the number of buffers dedicated for implemented (Section 4.5), the number of buffers dedicated for
DetNet allocation, and the worst-case forwarding delay and DetNet allocation, and the worst-case forwarding delay and
misordering. misordering.
o The dynamic state of a DetNet node's DetNet resources. o The actual state of a DetNet node's DetNet resources.
o The identity of the DetNet system's neighbors, and the o The identity of the DetNet system's neighbors, and the
characteristics of the link(s) between the DetNet systems, characteristics of the link(s) between the DetNet systems,
including the latency of the links (in nanoseconds). including the latency of the links (in nanoseconds).
4.9. Scaling to larger networks 4.9. Scaling to larger networks
Reservations for individual DetNet flows require considerable state Reservations for individual DetNet flows require considerable state
information in each DetNet node, especially when adequate fault information in each DetNet node, especially when adequate fault
mitigation (Section 3.3.2) is required. The DetNet data plane, in mitigation (Section 3.3.2) is required. The DetNet data plane, in
skipping to change at page 36, line 48 skipping to change at page 37, line 38
Standards providing similar capabilities for bridged networks (only) Standards providing similar capabilities for bridged networks (only)
have been and are being generated in the IEEE 802 LAN/MAN Standards have been and are being generated in the IEEE 802 LAN/MAN Standards
Committee. The present architecture describes an abstract model that Committee. The present architecture describes an abstract model that
can be applicable both at Layer-2 and Layer-3, and over links not can be applicable both at Layer-2 and Layer-3, and over links not
defined by IEEE 802. defined by IEEE 802.
DetNet enabled end systems and DetNet nodes can be interconnected by DetNet enabled end systems and DetNet nodes can be interconnected by
sub-networks, i.e., Layer-2 technologies. These sub-networks will sub-networks, i.e., Layer-2 technologies. These sub-networks will
provide DetNet compatible service for support of DetNet traffic. provide DetNet compatible service for support of DetNet traffic.
Examples of sub-networks include MPLS TE, 802.1 TSN, and a point-to- Examples of sub-network technologies include MPLS TE, 802.1 TSN, and
point OTN link. Of course, multi-layer DetNet systems may be a point-to-point OTN link. Of course, multi-layer DetNet systems may
possible too, where one DetNet appears as a sub-network, and provides be possible too, where one DetNet appears as a sub-network, and
service to, a higher layer DetNet system. provides service to, a higher layer DetNet system.
5. Security Considerations 5. Security Considerations
Security in the context of Deterministic Networking has an added Security considerations for DetNet are described in detail in
dimension; the time of delivery of a packet can be just as important [I-D.ietf-detnet-security]. This section considers exclusively
as the contents of the packet, itself. A man-in-the-middle attack, security considerations which are specific to the DetNet
for example, can impose, and then systematically adjust, additional architecture.
delays into a link, and thus disrupt or subvert a real-time
application without having to crack any encryption methods employed.
See [RFC7384] for an exploration of this issue in a related context.
Furthermore, in a control system where millions of dollars of Security aspects which are unique to DetNet are those whose aim is to
equipment, or even human lives, can be lost if the DetNet QoS is not provide the specific quality of service aspects of DetNet, which are
delivered, one must consider not only simple equipment failures, primarily to deliver data flows with extremely low packet loss rates
where the box or wire instantly becomes perfectly silent, but complex and bounded end-to-end delivery latency. A DetNet may be implemented
errors such as can be caused by software failures. Because there is using MPLS and/or IP (including both v4 and v6) technologies, and
essential no limit to the kinds of failures that can occur, thus inherits the security properties of those technologies at both
protecting against realistic equipment failures is indistinguishable, the data plane and the control plane.
in most cases, from protecting against malicious behavior, whether
accidental or intentional. See also Section 3.3.2.
Security must cover: Security considerations for DetNet are constrained (compared to, for
example, the open Internet) because DetNet is defined to operate only
within a single administrative domain (see Section 1). The primary
considerations are to secure the request and control of DetNet
resources, maintain confidentiality of data traversing the DetNet,
and provide the availability of the DetNet quality of service.
o the protection of the signaling protocol To secure the request and control of DetNet resources, authentication
and authorization can be used for each device connected to a DetNet
domain, most importantly to network controller devices. Control of a
DetNet network may be centralized or distributed (within a single
administrative domain). In the case of centralized control,
precedent for security considerations as defined for Abstraction and
Control of Traffic Engineered Networks (ACTN) can be found in
[RFC8453], Section 9. In the case of distributed control protocols,
DetNet security is expected to be provided by the security properties
of the protocols in use. In any case, the result is that
manipulation of administratively configurable parameters is limited
to authorized entities.
o the authentication and authorization of the controlling systems To maintain confidentiality of data traversing the DetNet,
application flows can be protected through whatever means is provided
by the underlying technology. For example, encryption may be used,
such as that provided by IPSec [RFC4301] for IP flows and by MACSec
[IEEE802.1AE-2018] for Ethernet (Layer-2) flows.
o the identification and shaping of the DetNet flows DetNet flows are identified on a per-flow basis, which may provide
attackers with additional information about the data flows (when
compared to networks that do not include per-flow identification).
This is an inherent property of DetNet which has security
implications that should be considered when determining if DetNet is
a suitable technology for any given use case.
Security considerations for DetNet are described in detail in To provide uninterrupted availability of the DetNet quality of
[I-D.ietf-detnet-security]. service, provisions can be made against DOS attacks and delay
attacks. To protect against DOS attacks, excess traffic due to
malicious or malfunctioning devices can be prevented or mitigated,
for example through the use of traffic admission control applied at
the input of a DetNet domain, as described in Section 3.2.1, and
through the fault mitigation methods described in Section 3.3.2. To
prevent DetNet packets from being delayed by an entity external to a
DetNet domain, DetNet technology definition can allow for the
mitigation of Man-In-The-Middle attacks, for example through use of
authentication and authorization of devices within the DetNet domain.
Because DetNet mechanisms or applications that rely on DetNet can
make heavy use of methods that require precise time synchronization,
the accuracy, availability, and integrity of time synchronization is
of critical importance. Extensive discussion of this topic can be
found in [RFC7384].
DetNet use cases are known to have widely divergent security
requirements. The intent of this section is to provide a baseline
for security considerations which are common to all DetNet designs
and implementations, without burdening individual designs with
specifics of security infrastructure which may not be germane to the
given use case. Designers and implementers of DetNet systems are
expected to take use case specific considerations into account in
their DetNet designs and implementations.
6. Privacy Considerations 6. Privacy Considerations
DetNet is provides a Quality of Service (QoS), and as such, does not DetNet provides a Quality of Service (QoS), and as such, is not
directly raise any new privacy considerations. expected to directly raise any new privacy considerations, the
generic considerations for such mechanisms apply. In particular,
such markings allow for an attacker to correlate flows or to select
particular types of flow for more detailed inspection.
However, the requirement for every (or almost every) node along the However, the requirement for every (or almost every) node along the
path of a DetNet flow to identify DetNet flows may present an path of a DetNet flow to identify DetNet flows may present an
additional attack surface for privacy, should the DetNet paradigm be additional attack surface for privacy, should the DetNet paradigm be
found useful in broader environments. found useful in broader environments.
7. IANA Considerations 7. IANA Considerations
This document does not require an action from IANA. This document does not require an action from IANA.
8. Acknowledgements 8. Acknowledgements
The authors wish to thank Lou Berger, David Black, Stewart Bryant, The authors wish to thank Lou Berger, David Black, Stewart Bryant,
Rodney Cummings, Ethan Grossman, Craig Gunther, Marcel Kiessling, Rodney Cummings, Ethan Grossman, Craig Gunther, Marcel Kiessling,
Rudy Klecka, Jouni Korhonen, Erik Nordmark, Shitanshu Shah, Wilfried Rudy Klecka, Jouni Korhonen, Erik Nordmark, Shitanshu Shah, Wilfried
Steiner, George Swallow, Michael Johas Teener, Pat Thaler, Thomas Steiner, George Swallow, Michael Johas Teener, Pat Thaler, Thomas
Watteyne, Patrick Wetterwald, Karl Weber, Anca Zamfir, for their Watteyne, Patrick Wetterwald, Karl Weber, Anca Zamfir, for their
various contribution with this work. various contributions to this work.
9. Informative References 9. Informative References
[BUFFERBLOAT]
Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in
the Internet", January 2012.
[CCAMP] IETF, "Common Control and Measurement Plane Working [CCAMP] IETF, "Common Control and Measurement Plane Working
Group", Group",
<https://datatracker.ietf.org/doc/charter-ietf-ccamp/>. <https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-19 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work
in progress), December 2018. in progress), March 2019.
[I-D.ietf-detnet-dp-sol-ip] [I-D.ietf-detnet-dp-sol-ip]
Korhonen, J. and B. Varga, "DetNet IP Data Plane Korhonen, J. and B. Varga, "DetNet IP Data Plane
Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in Encapsulation", draft-ietf-detnet-dp-sol-ip-01 (work in
progress), October 2018. progress), October 2018.
[I-D.ietf-detnet-dp-sol-mpls] [I-D.ietf-detnet-dp-sol-mpls]
Korhonen, J. and B. Varga, "DetNet MPLS Data Plane Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in Encapsulation", draft-ietf-detnet-dp-sol-mpls-01 (work in
progress), October 2018. progress), October 2018.
[I-D.ietf-detnet-problem-statement] [I-D.ietf-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", draft-ietf-detnet-problem-statement-09 (work Statement", draft-ietf-detnet-problem-statement-09 (work
in progress), December 2018. in progress), December 2018.
[I-D.ietf-detnet-security] [I-D.ietf-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
J., Austad, H., Stanton, K., and N. Finn, "Deterministic J., Austad, H., Stanton, K., and N. Finn, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf- Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-03 (work in progress), October 2018. detnet-security-04 (work in progress), March 2019.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft- Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-20 (work in progress), December ietf-detnet-use-cases-20 (work in progress), December
2018. 2018.
[IEC62439-3-2016] [IEC62439-3-2016]
International Electrotechnical Commission (IEC) TC 65/SC International Electrotechnical Commission (IEC) TC 65/SC
65C - Industrial networks, "IEC 62439-3:2016 Industrial 65C - Industrial networks, "IEC 62439-3:2016 Industrial
communication networks - High availability automation communication networks - High availability automation
networks - Part 3: Parallel Redundancy Protocol (PRP) and networks - Part 3: Parallel Redundancy Protocol (PRP) and
High-availability Seamless Redundancy (HSR)", 2016, High-availability Seamless Redundancy (HSR)", 2016,
<https://webstore.iec.ch/publication/24447>. <https://webstore.iec.ch/publication/24447>.
[IEEE802.1AE-2018]
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
Security (MACsec)", 2018,
<https://ieeexplore.ieee.org/document/8585421>.
[IEEE802.1BA] [IEEE802.1BA]
IEEE Standards Association, "IEEE Std 802.1BA-2011 Audio IEEE Standards Association, "IEEE Std 802.1BA-2011 Audio
Video Bridging (AVB) Systems", 2011, Video Bridging (AVB) Systems", 2011,
<https://ieeexplore.ieee.org/document/6032690/>. <https://ieeexplore.ieee.org/document/6032690/>.
[IEEE802.1CB] [IEEE802.1CB]
IEEE Standards Association, "IEEE Std 802.1CB-2017 Frame IEEE Standards Association, "IEEE Std 802.1CB-2017 Frame
Replication and Elimination for Reliability", 2017, Replication and Elimination for Reliability", 2017,
<https://ieeexplore.ieee.org/document/8091139/>. <https://ieeexplore.ieee.org/document/8091139/>.
skipping to change at page 40, line 49 skipping to change at page 42, line 45
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<https://www.rfc-editor.org/info/rfc5921>. <https://www.rfc-editor.org/info/rfc5921>.
skipping to change at page 41, line 46 skipping to change at page 43, line 46
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>. <https://www.rfc-editor.org/info/rfc7554>.
[RFC7813] Farkas, J., Ed., Bragg, N., Unbehagen, P., Parsons, G., [RFC7813] Farkas, J., Ed., Bragg, N., Unbehagen, P., Parsons, G.,
Ashwood-Smith, P., and C. Bowers, "IS-IS Path Control and Ashwood-Smith, P., and C. Bowers, "IS-IS Path Control and
Reservation", RFC 7813, DOI 10.17487/RFC7813, June 2016, Reservation", RFC 7813, DOI 10.17487/RFC7813, June 2016,
<https://www.rfc-editor.org/info/rfc7813>. <https://www.rfc-editor.org/info/rfc7813>.
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>.
[RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J. [RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J.
Dong, "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Dong, "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for
Ring Topology", RFC 8227, DOI 10.17487/RFC8227, August Ring Topology", RFC 8227, DOI 10.17487/RFC8227, August
2017, <https://www.rfc-editor.org/info/rfc8227>. 2017, <https://www.rfc-editor.org/info/rfc8227>.
[RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J.
Iyengar, Ed., "Controlled Delay Active Queue Management",
RFC 8289, DOI 10.17487/RFC8289, January 2018,
<https://www.rfc-editor.org/info/rfc8289>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. <https://www.rfc-editor.org/info/rfc8453>.
 End of changes. 71 change blocks. 
203 lines changed or deleted 297 lines changed or added

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