draft-ietf-detnet-architecture-06.txt   draft-ietf-detnet-architecture-07.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: December 30, 2018 Cisco Expires: February 4, 2019 Cisco
B. Varga B. Varga
J. Farkas J. Farkas
Ericsson Ericsson
June 28, 2018 August 3, 2018
Deterministic Networking Architecture Deterministic Networking Architecture
draft-ietf-detnet-architecture-06 draft-ietf-detnet-architecture-07
Abstract Abstract
Deterministic Networking (DetNet) provides a capability to carry Deterministic Networking (DetNet) provides a capability to carry
specified unicast or multicast data flows for real-time applications specified unicast or multicast data flows for real-time applications
with extremely low data loss rates and bounded latency. Techniques with extremely low data loss rates and bounded latency. Techniques
used include: 1) reserving data plane resources for individual (or used include: 1) reserving data plane resources for individual (or
aggregated) DetNet flows in some or all of the intermediate nodes aggregated) DetNet flows in some or all of the intermediate nodes
(e.g., bridges or routers) along the path of the flow; 2) providing (e.g., bridges or routers) along the path of the flow; 2) providing
explicit routes for DetNet flows that do not immediately change with explicit routes for DetNet flows that do not immediately change with
the network topology; and 3) distributing data from DetNet flow the network topology; and 3) distributing data from DetNet flow
packets over time and/or space to ensure delivery of each packet's packets over time and/or space to ensure delivery of each packet's
data' in spite of the loss of a path. data in spite of the loss of a path.
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 December 30, 2018. This Internet-Draft will expire on February 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 3, line 4 skipping to change at page 3, line 4
4.3. DetNet flows . . . . . . . . . . . . . . . . . . . . . . 23 4.3. DetNet flows . . . . . . . . . . . . . . . . . . . . . . 23
4.3.1. DetNet flow types . . . . . . . . . . . . . . . . . . 23 4.3.1. DetNet flow types . . . . . . . . . . . . . . . . . . 23
4.3.2. Source transmission behavior . . . . . . . . . . . . 23 4.3.2. Source transmission behavior . . . . . . . . . . . . 23
4.3.3. Incomplete Networks . . . . . . . . . . . . . . . . . 25 4.3.3. Incomplete Networks . . . . . . . . . . . . . . . . . 25
4.4. Traffic Engineering for DetNet . . . . . . . . . . . . . 25 4.4. Traffic Engineering for DetNet . . . . . . . . . . . . . 25
4.4.1. The Application Plane . . . . . . . . . . . . . . . . 25 4.4.1. The Application Plane . . . . . . . . . . . . . . . . 25
4.4.2. The Controller Plane . . . . . . . . . . . . . . . . 26 4.4.2. The Controller Plane . . . . . . . . . . . . . . . . 26
4.4.3. The Network Plane . . . . . . . . . . . . . . . . . . 26 4.4.3. The Network Plane . . . . . . . . . . . . . . . . . . 26
4.5. Queuing, Shaping, Scheduling, and Preemption . . . . . . 27 4.5. Queuing, Shaping, Scheduling, and Preemption . . . . . . 27
4.6. Service instance . . . . . . . . . . . . . . . . . . . . 28 4.6. Service instance . . . . . . . . . . . . . . . . . . . . 28
4.7. Flow identification at technology borders . . . . . . . . 29 4.7. Flow identification at technology borders . . . . . . . . 30
4.7.1. Exporting flow identification . . . . . . . . . . . . 29 4.7.1. Exporting flow identification . . . . . . . . . . . . 30
4.7.2. Flow attribute mapping between layers . . . . . . . . 31 4.7.2. Flow attribute mapping between layers . . . . . . . . 31
4.7.3. Flow-ID mapping examples . . . . . . . . . . . . . . 32 4.7.3. Flow-ID mapping examples . . . . . . . . . . . . . . 32
4.8. Advertising resources, capabilities and adjacencies . . . 34 4.8. Advertising resources, capabilities and adjacencies . . . 34
4.9. Scaling to larger networks . . . . . . . . . . . . . . . 34 4.9. Scaling to larger networks . . . . . . . . . . . . . . . 35
4.10. Compatibility with Layer-2 . . . . . . . . . . . . . . . 34 4.10. Compatibility with Layer-2 . . . . . . . . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
9. Informative References . . . . . . . . . . . . . . . . . . . 36 9. Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Deterministic Networking (DetNet) is a service that can be offered by Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows. DetNet provides these flows with a network to DetNet flows. DetNet provides these flows with
extremely low packet loss rates and assured maximum end-to-end extremely low packet loss rates and assured maximum end-to-end
delivery latency. This is accomplished by dedicating network delivery latency. This is accomplished 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. DetNet packets.
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. That is,
the presence of DetNet flows does not preclude non-DetNet flows, and the presence of DetNet flows does not preclude non-DetNet flows, and
the benefits offered DetNet flows should not, except in extreme the benefits offered DetNet flows should not, except in extreme
cases, prevent existing QoS mechanisms from operating in a normal cases, prevent existing QoS mechanisms from operating in a normal
fashion, subject to the bandwidth required for the DetNet flows. A fashion, subject to the bandwidth required for the DetNet flows. A
single source-destination pair can trade both DetNet and non-DetNet single source-destination pair can trade both DetNet and non-DetNet
flows. End systems and applications need not instantiate special flows. End systems and applications need not instantiate special
interfaces for DetNet flows. Networks are not restricted to certain interfaces for DetNet flows. Networks are not restricted to certain
topologies; connectivity is not restricted. Any application that topologies; connectivity is not restricted. Any application that
generates a data flow that can be usefully characterized as having a generates a data flow that can be usefully characterized as having a
maximum bandwidth should be able to take advantage of DetNet, as long maximum bandwidth should be able to take advantage of DetNet, as long
as the necessary resources can be reserved. Reservations can be made as the necessary resources can be reserved. Reservations can be made
by the application itself, via network management, by an applications by the application itself, via network management, by an
controller, or by other means, e.g., a dynamic control plane (e.g., application's controller, or by other means, e.g., a dynamic control
[RFC2205]). plane (e.g., [RFC2205]).
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 relay and transit nodes. The means used to achieve time among relay and transit nodes. The means used to achieve time
synchronization are not addressed in this document. DetNet should synchronization are not addressed in this document. DetNet can
accommodate various synchronization techniques and profiles that are accommodate various time synchronization techniques and profiles that
defined elsewhere to solve exchange time in different market are defined elsewhere to address the needs of different market
segments. segments.
2. Terminology 2. Terminology
2.1. Terms used in this document 2.1. Terms used in this document
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
skipping to change at page 6, line 23 skipping to change at page 6, line 23
Ordering Functions. Ordering Functions.
POF A Packet Ordering Function (POF) re-orders packets within a POF A Packet Ordering Function (POF) re-orders packets within a
DetNet flow that are received out of order. This function DetNet flow that are received out of order. This function
can be implemented by an edge node, a relay node, or an end can be implemented by an edge node, a relay node, or an end
system. system.
reservation reservation
The set of resources allocated between a source and one or The set of resources allocated between a source and one or
more destinations through transit nodes and subnets more destinations through transit nodes and subnets
associated with a DetNet flow, to provide the expected DetNet associated with a DetNet flow, to provide the provisioned
Service. DetNet service.
DetNet service layer DetNet service layer
The layer at which A DetNet Service, such as congestion or The layer at which A DetNet service, e.g., service protection
service protection is provided. 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 transit node DetNet transit node
A node operating at the DetNet transport layer, that utilizes A node operating at the DetNet transport layer, that utilizes
link layer and/or network layer switching across multiple link layer and/or network layer switching across multiple
skipping to change at page 7, line 17 skipping to change at page 7, line 17
relay system relay system
The IEEE 802.1 term for a DetNet intermediate node. The IEEE 802.1 term for a DetNet intermediate node.
Stream Stream
The IEEE 802.1 term for a DetNet flow. The IEEE 802.1 term for a DetNet flow.
Talker Talker
The IEEE 802.1 term for the source of a DetNet flow. The IEEE 802.1 term for the source of a DetNet flow.
bridged path
A VLAN bridge uses the VLAN ID and the destination MAC
address to select the outbound port hence the path for a
frame.
3. Providing the DetNet Quality of Service 3. Providing the DetNet Quality of Service
3.1. Primary goals defining the DetNet QoS 3.1. Primary goals defining the DetNet QoS
The DetNet Quality of Service can be expressed in terms of: The DetNet Quality of Service can be expressed in terms of:
o Minimum and maximum end-to-end latency from source to destination; o Minimum and maximum end-to-end latency from source to destination;
timely delivery, and bounded jitter (packet delay variation) timely delivery, and bounded jitter (packet delay variation)
derived from these constraints. derived from these constraints.
o Probability of loss of a packet, under various assumptions as to o Packet loss ratio, under various assumptions as to the operational
the operational states of the nodes and links. If packet states of the nodes and links.
replication is used to reduce the probability of packet loss, then
a related property is the probability (may be zero) of delivery of
a duplicate packet. Duplicate packet delivery is an inherent risk
in highly reliable and/or broadcast transmissions.
o An upper bound on out-of-order packet delivery. It is worth o An upper bound on out-of-order packet delivery. It is worth
noting that some DetNet applications are unable to tolerate any noting that some DetNet applications are unable to tolerate any
out-of-order delivery. out-of-order delivery.
It is a distinction of DetNet that it is concerned solely with worst- It is a distinction of DetNet that it is concerned solely with worst-
case values for the end-to-end latency, jitter, and misordering. case values for the end-to-end latency, jitter, and misordering.
Average, mean, or typical values are of little interest, because they Average, mean, or typical values are of little interest, because they
do not affect the ability of a real-time system to perform its tasks. do not affect the ability of a real-time system to perform its tasks.
In general, a trivial priority-based queuing scheme will give better In general, a trivial priority-based queuing scheme will give better
skipping to change at page 8, line 12 skipping to change at page 7, line 52
Three techniques are used by DetNet to provide these qualities of Three techniques are used by DetNet to provide these qualities of
service: service:
o Congestion protection (Section 3.2.1). o Congestion protection (Section 3.2.1).
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).
Congestion protection operates by allocating resources along the path Congestion protection operates by allocating resources along the path
of a DetNet Flow, e.g., buffer space or link bandwidth. Congestion of a DetNet flow, e.g., buffer space or link bandwidth. Congestion
protection greatly reduces, or even eliminates entirely, packet loss protection greatly reduces, or even eliminates entirely, packet loss
due to output packet congestion within the network, but it can only due to output packet congestion within the network, but it can only
be supplied to a DetNet flow that is limited at the source to a be supplied to a DetNet flow that is limited at the source to a
maximum packet size and transmission rate. maximum packet size and transmission rate. Note that congestion
protection provided via congestion detection and notification is
explicitly excluded from consideration in DetNet, as it serves a
different set of applications.
Congestion protection addresses two of the DetNet QoS requirements: Congestion protection 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, congestion protection necessarily results in amount of buffer space, congestion protection necessarily results in
a maximum end-to-end latency. It also addresses the largest a maximum end-to-end latency. It also addresses the largest
contribution to packet loss, which is buffer congestion. contribution to packet loss, which is buffer congestion.
After congestion, the most important contributions to packet loss are After congestion, the most important contributions to packet loss are
typically from random media errors and equipment failures. Service typically from random media errors and equipment failures. Service
protection is the name for the mechanisms used by DetNet to address protection is the name for the mechanisms used by DetNet to address
skipping to change at page 9, line 4 skipping to change at page 8, line 47
These three techniques can be applied independently, giving eight These three techniques can be applied independently, giving eight
possible combinations, including none (no DetNet), although some possible combinations, including none (no DetNet), although some
combinations are of wider utility than others. This separation keeps combinations are of wider utility than others. This separation keeps
the protocol stack coherent and maximizes interoperability with the protocol stack coherent and maximizes interoperability with
existing and developing standards in this (IETF) and other Standards existing and developing standards in this (IETF) and other Standards
Development Organizations. Some examples of typical expected Development Organizations. Some examples of typical expected
combinations: combinations:
o Explicit routes plus service protection are exactly the techniques o Explicit routes plus service protection are exactly the techniques
employed by seamless redundancy mechanisms applied on a ring employed by seamless redundancy mechanisms applied on a ring
topology as described, e.g., in [IEEE802.1CB]. In this case, topology as described, e.g., in [IEC62439-3-2016]. In this
explicit routes are achieved by limiting the physical topology of example, explicit routes are achieved by limiting the physical
the network to a ring. Sequentialization, replication, and topology of the network to a ring. Sequentialization,
duplicate elimination are facilitated by packet tags added at the replication, and duplicate elimination are facilitated by packet
front or the end of Ethernet frames. tags added at the front or the end of Ethernet frames. [RFC8227]
provides another example in the context of MPLS.
o Congestion protection alone is offered by IEEE 802.1 Audio Video o Congestion protection alone is offered by IEEE 802.1 Audio Video
bridging [IEEE802.1BA]. As long as the network suffers no bridging [IEEE802.1BA]. As long as the network suffers no
failures, zero congestion loss can be achieved through the use of failures, zero congestion loss can be achieved through the use of
a reservation protocol (MSRP [IEEE802.1Q]), shapers in every a reservation protocol (MSRP [IEEE802.1Q-2018]), shapers in every
bridge, and proper dimensioning. bridge, and proper dimensioning.
o Using all three together gives maximum protection. o Using all three together gives maximum protection.
There are, of course, simpler methods available (and employed, today) There are, of course, simpler methods available (and employed, today)
to achieve levels of latency and packet loss that are satisfactory to achieve levels of latency and packet loss that are satisfactory
for many applications. Prioritization and over-provisioning is one for many applications. Prioritization and over-provisioning is one
such technique. However, these methods generally work best in the such technique. However, these methods generally work best in the
absence of any significant amount of non-critical traffic in the absence of any significant amount of non-critical traffic in the
network (if, indeed, such traffic is supported at all), or work only network (if, indeed, such traffic is supported at all), or work only
skipping to change at page 11, line 27 skipping to change at page 11, line 27
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.
Service protection may provide a mechanism to support in-order DetNet Packet Ordering Functionality (POF) (Section 3.2.2.2) can be
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 layer includes the packet replication (PRF), the The DetNet service layer includes the packet replication (PRF), the
packet elimination (PEF), and the packet ordering functionality (POF) packet elimination (PEF), and the packet ordering functionality (POF)
for use in DetNet edge, relay node, and end system packet processing. for use in DetNet edge, relay node, and end system packet processing.
Either of these functions can be enabled in a DetNet edge node, relay Either of these functions can be enabled in a DetNet edge node, relay
skipping to change at page 13, line 46 skipping to change at page 13, line 46
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.
3.2.3. Explicit routes 3.2.3. Explicit routes
In networks controlled by typical dynamic control protocols such as In networks controlled by typical dynamic control protocols such as
IS-IS or OSPF, a network topology event in one part of the network IS-IS or OSPF, a network topology event in one part of the network
can impact, at least briefly, the delivery of data in parts of the can impact, at least briefly, the delivery of data in parts of the
network remote from the failure or recovery event. Even the use of network remote from the failure or recovery event. Even the use of
redundant paths through a network defined, e.g., by [RFC6372] do not redundant paths through a network defined, e.g., as defined by
eliminate the chances of packet loss. Furthermore, out-of-order [RFC6372] do not eliminate the chances of packet loss. Furthermore,
packet delivery can be a side effect of route changes. out-of-order packet delivery can be a side effect of route changes.
Many real-time networks rely on physical rings or chains of two-port Many real-time networks rely on physical rings of two-port devices,
devices, with a relatively simple ring control protocol. This with a relatively simple ring control protocol. This supports
supports redundant paths for service protection with a minimum of redundant paths for service protection with a minimum of wiring. As
wiring. As an additional benefit, ring topologies can often utilize an additional benefit, ring topologies can often utilize different
different topology management protocols than those used for a mesh topology management protocols than those used for a mesh network,
network, with a consequent reduction in the response time to topology with a consequent reduction in the response time to topology changes.
changes. Of course, this comes at some cost in terms of increased Of course, this comes at some cost in terms of increased hop count,
hop count, 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 various continuous connectivity. Explicit routes can be established in
ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR) various ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR)
[I-D.ietf-spring-segment-routing], via a Software Defined Networking [RFC8402], via a Software Defined Networking approach [RFC7426], with
approach [RFC7426], with IS-IS [RFC7813], etc. Explicit routes are IS-IS [RFC7813], etc. Explicit routes are typically used in MPLS TE
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, also applies to service irrespective of the distribution method used, and also applies to
protection over explicit routes. As described in Section 3.2.2.1, service protection over explicit routes. As described in
out-of-order packets influence the jitter of a flow and impact the Section 3.2.2.1, out-of-order packets influence the jitter of a flow
amount of buffering needed to process the data; therefore, DetNet and impact the amount of buffering needed to process the data;
service includes maximum allowed misordering as a constraint. The therefore, DetNet service includes maximum allowed misordering as a
use of explicit routes helps to provide in-order delivery because constraint. The use of explicit routes helps to provide in-order
there is no immediate route change with the network topology, but the delivery because there is no immediate route change with the network
changes are plannable as they are between the different explicit topology, but the changes are plannable as they are between the
routes. different explicit routes.
3.3. Secondary goals for DetNet 3.3. Secondary goals for DetNet
Many applications require DetNet to provide additional services, Many applications require DetNet to provide additional services,
including coexistence with other QoS mechanisms Section 3.3.1 and including coexistence with other QoS mechanisms Section 3.3.1 and
protection against misbehaving transmitters Section 3.3.2. protection against misbehaving transmitters Section 3.3.2.
3.3.1. Coexistence with normal traffic 3.3.1. Coexistence with normal traffic
A DetNet network supports the dedication of a high proportion (e.g. A DetNet network supports the dedication of a high proportion (e.g.
75%) of the network bandwidth to DetNet flows. But, no matter how 75%) of the network bandwidth to DetNet flows. But, no matter how
much is dedicated for DetNet flows, it is a goal of DetNet to coexist much is dedicated for DetNet flows, it is a goal of DetNet to coexist
with existing Class of Service schemes (e.g., DiffServ). It is also with existing Class of Service schemes (e.g., DiffServ). It is also
important that non-DetNet traffic not disrupt the DetNet flow, of important that non-DetNet traffic not disrupt the DetNet flow, of
course (see Section 3.3.2 and Section 5). For these reasons: course (see Section 3.3.2 and Section 5). For these reasons:
o Bandwidth (transmission opportunities) not utilized by a DetNet o Bandwidth (transmission opportunities) not utilized by a DetNet
flow are available to non-DetNet packets (though not to other flow is available to non-DetNet packets (though not to other
DetNet flows). DetNet flows).
o DetNet flows can be shaped or scheduled, in order to ensure that o DetNet flows can be shaped or scheduled, in order to ensure that
the highest-priority non-DetNet packet is also ensured a worst- the highest-priority non-DetNet packet is also ensured a worst-
case latency (at any given hop). case latency (at any given hop).
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
skipping to change at page 16, line 9 skipping to change at page 16, line 9
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
functions (e.g. [RFC2475]) and separating flows into per-flow rate- functions (e.g. [RFC2475]) and separating flows into per-flow rate-
limited queues. 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
layers in the protocol stack: the DetNet service layer and the DetNet
transport layer. The DetNet service layer provides DetNet service,
e.g., service protection, to higher layers in the protocol stack and
applications. The DetNet transport layer supports DetNet service in
the underlying network, e.g., by providing explicit routes and
congestion protection to DetNet flows.
4.1.1. Representative Protocol Stack Model 4.1.1. Representative Protocol Stack Model
Figure 2 illustrates a conceptual DetNet data plane layering model. Figure 2 illustrates a conceptual DetNet data plane layering model.
One may compare it to that in [IEEE802.1CB], Annex C. One may compare it to that in [IEEE802.1CB], Annex C.
| packets going | ^ packets coming ^ | packets going | ^ packets coming ^
v down the stack v | up the stack | v down the stack v | up the stack |
+----------------------+ +-----------------------+ +----------------------+ +-----------------------+
| Source | | Destination | | Source | | Destination |
+----------------------+ +-----------------------+ +----------------------+ +-----------------------+
skipping to change at page 18, line 4 skipping to change at page 18, line 12
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.
Congestion protection Congestion protection
The DetNet transport layer provides congestion protection. The DetNet transport layer provides congestion protection.
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 layers, these can are typically provided by underlying subnet layers, these can
be closely associated with the means of providing paths for be closely associated with the means of providing paths for
DetNet flows (e.g., MPLS LSPs or bridged paths), the path and DetNet flows, the path and the congestion protection are
the congestion protection are conflated in this figure. conflated in this figure.
Explicit routes Explicit routes
The DetNet transport layer provides mechanisms to ensure that The DetNet transport layer provides mechanisms to ensure that
fixed paths are provided for DetNet flows. These explicit fixed paths are provided for DetNet flows. These explicit
paths avoid the impact of network convergence. 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
Figure 2; it may reside in any number of the layers. OAM can involve Figure 2; it may reside in any number of the layers. OAM can involve
specific tagging added in the packets for tracing implementation or specific tagging added in the packets for tracing implementation or
network configuration errors; traceability enables to find whether a network configuration errors; traceability enables to find whether a
packet is a replica, which relay node performed the replication, and packet is a replica, which relay node performed the replication, and
which segment was intended for the replica. which segment was intended for the replica. Active and hybrid OAM
methods require additional bandwidth to perform fault management and
performance monitoring of the DetNet domain. OAM may, for instance,
generate special test probes or add OAM information 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 and nodes, i.e., edge nodes, relay nodes and collectively systems and nodes, i.e., edge nodes, relay nodes and collectively
deliver DetNet services. DetNet enabled nodes are interconnected via deliver DetNet services. DetNet enabled nodes are interconnected via
skipping to change at page 20, line 42 skipping to change at page 20, line 42
| | | | | | | ___/ \ | | | | | | | | ___/ \ |
| +--+-+ +----+ | +----+ | / \_ | | +--+-+ +----+ | +----+ | / \_ |
\ | | | | | / \ | \ | | | | | / \ |
\ | +----+ +--+-+ +--+PE |------ U-----+ \ | +----+ +--+-+ +--+PE |------ U-----+
\ | | | | | | | | | \_ _/ \ | | | | | | | | | \_ _/
\ +---+ P +----+ P +--+ +----+ | \____/ \ +---+ P +----+ P +--+ +----+ | \____/
\___ | | | | / \___ | | | | /
\ +----+__ +----+ DetNet-1 DetNet-2 \ +----+__ +----+ DetNet-1 DetNet-2
| \_____/ \___________/ | | \_____/ \___________/ |
| | | |
| | 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-UNIs ("U" in Figure 5) are assumed in this document to be
packet-based reference points and provide connectivity over the packet-based reference points and provide connectivity over the
packet network. A DetNet-UNI may provide multiple functions, e.g., packet network. A DetNet-UNI may provide multiple functions, e.g.,
it may add networking technology specific encapsulation to the DetNet it may add networking technology specific encapsulation to the DetNet
flows if necessary; it may provide status of the availability of the flows if necessary; it may provide status of the availability of the
skipping to change at page 22, line 35 skipping to change at page 22, line 35
v v
DetNet st-aware DetNet st-aware
End system End system
Figure 6: Categorization of end systems Figure 6: Categorization of end systems
Note some known use case examples for end systems: Note some known use case examples for end systems:
o DetNet unaware: The classic case requiring service proxies. o DetNet unaware: The classic case requiring service proxies.
o DetNet t-aware: An extant TSN system. It knows about some TSN o DetNet t-aware: A DetNet transport-aware system. It knows about
functions (e.g., reservation), but not about service protection. some TSN functions (e.g., reservation), but not about service
protection.
o DetNet s-aware: An extant IEC 62439-3 system. It supplies o DetNet s-aware: A DetNet service-aware system. It supplies
sequence numbers, but doesn't know about zero congestion loss. sequence numbers, but doesn't know about zero congestion loss.
o DetNet st-aware: A full functioning DetNet end system, it has o DetNet st-aware: A full functioning DetNet end system, it has
DetNet functionalities and usually the same forwarding paradigm as DetNet functionalities and usually the same forwarding paradigm as
the connected DetNet domain. It can be treated as an integral the connected DetNet domain. It can be treated as an integral
part of the DetNet domain. part of the DetNet domain.
4.2.2. DetNet edge, relay, and transit nodes 4.2.2. DetNet edge, relay, and transit nodes
As shown in Figure 3, DetNet edge nodes providing proxy service and As shown in Figure 3, DetNet edge nodes providing proxy service and
skipping to change at page 26, line 13 skipping to change at page 26, line 13
nodes. nodes.
4.4.2. The Controller Plane 4.4.2. The Controller Plane
The Controller Plane corresponds to the aggregation of the Control The Controller Plane corresponds to the aggregation of the Control
and Management Planes in [RFC7426], though Common Control and and Management Planes in [RFC7426], though Common Control and
Measurement Plane (CCAMP) [CCAMP] makes an additional distinction Measurement Plane (CCAMP) [CCAMP] makes an additional distinction
between management and measurement. When the logical separation of between management and measurement. When the logical separation of
the Control, Measurement and other Management entities is not the Control, Measurement and other Management entities is not
relevant, the term Controller Plane is used for simplicity to relevant, the term Controller Plane is used for simplicity to
represent them all, and the term controller plane entity (CPE) refers represent them all, and the term Controller Plane Function (CPF)
to any device operating in that plane, whether is it a Path refers to any device operating in that plane, whether is it a Path
Computation entity, or a Network Management entity (NME)), or a Computation Element (PCE) [RFC4655], or a Network Management entity
distributed control plane. The Path Computation Element (PCE) (NME), or a distributed control plane. The CPF is a core element of
[RFC4655] is a core element of a controller, in charge of computing a controller, in charge of computing Deterministic paths to be
Deterministic paths to be applied in the Network Plane. applied in the Network Plane.
A (Northbound) Service Interface enables applications in the A (Northbound) Service Interface enables applications in the
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 PCE(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 intermediate nodes for as Per-Flow Per-Hop Behaviors installed in the intermediate nodes for
each individual flow. The PCEs place each flow along a deterministic each individual flow. The CPFs place each flow along a deterministic
sequence of intermediate nodes so as to respect per-flow constraints sequence of intermediate nodes so as to respect per-flow constraints
such as security and latency, and optimize the overall result for such as security and latency, and optimize the overall result for
metrics such as an abstract aggregated cost. The deterministic metrics such as an abstract aggregated cost. The deterministic
sequence can typically be more complex than a direct sequence and sequence can typically be more complex than a direct sequence and
include redundancy path, with one or more packet replication and include redundancy path, with one or more packet replication and
elimination points. elimination points.
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 (control plane) 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
end systems, which are typically IP hosts, and intermediate nodes, end systems, which are typically IP hosts, and intermediate nodes,
which are typically IP routers and switches. Network-to-Network which are typically IP routers and switches. Network-to-Network
Interfaces such as used for Traffic Engineering path reservation in Interfaces such as used for Traffic Engineering path reservation in
[RFC5921], as well as User-to-Network Interfaces (UNI) such as [RFC5921], as well as User-to-Network Interfaces (UNI) such as
provided by the Local Management Interface (LMI) between network and provided by the Local Management Interface (LMI) between network and
end systems, are both part of the Network Plane, both in the control end systems, are both part of the Network Plane, both in the control
plane and the data plane. plane and the data plane.
A Southbound (Network) Interface enables the entities in the A Southbound (Network) Interface enables the entities in the
Controller Plane to communicate with devices in the Network Plane as Controller Plane to communicate with devices in the Network Plane as
illustrated in Figure 7. This interface leverages and extends TEAS illustrated in Figure 7. This interface leverages and extends TEAS
to describe the physical topology and resources in the Network Plane. to describe the physical topology and resources in the Network Plane.
End End End End
System System System System
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
CPE CPE CPE CPE CPF CPF CPF CPF
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
intermediate intermed. intermed. intermed. intermediate intermed. intermed. intermed.
Node Node Node Node Node Node Node Node
NIC NIC NIC NIC
intermediate intermed. intermed. intermed. intermediate intermed. intermed. intermed.
Node Node Node Node Node Node Node Node
Figure 7: Northbound and Southbound interfaces Figure 7: Northbound and Southbound interfaces
The intermediate nodes (and eventually the end systems NIC) expose The intermediate nodes (and eventually the end systems NIC) expose
their capabilities and physical resources to the controller (the their capabilities and physical resources to the controller (the
CPE), and update the CPEs with their dynamic perception of the CPF), and update the CPFs with their dynamic perception of the
topology, across the Southbound Interface. In return, the CPEs set topology, across the Southbound Interface. In return, the CPFs set
the per-flow paths up, providing a Flow Characterization that is more the per-flow paths up, providing a Flow Characterization that is more
tightly coupled to the intermediate node Operation than a TSpec. tightly coupled to the intermediate node Operation than a TSpec.
At the Network plane, intermediate nodes may exchange information At the Network plane, intermediate nodes may exchange information
regarding the state of the paths, between adjacent systems and regarding the state of the paths, between adjacent systems and
eventually with the end systems, and forward packets within eventually with the end systems, and forward packets within
constraints associated to each flow, or, when unable to do so, constraints associated to each flow, or, when unable to do so,
perform a last resort operation such as drop or declassify. perform a last resort operation such as drop or declassify.
This document focuses on the Southbound interface and the operation This document focuses on the Southbound interface and the operation
skipping to change at page 28, line 17 skipping to change at page 28, line 17
transit node to the end-to-end latency, to compute the amount of transit node to the end-to-end latency, to compute the amount of
buffer space required in each transit node for each incremental buffer space required in each transit node for each incremental
DetNet flow, and most importantly, to translate from a flow DetNet flow, and most importantly, to translate from a flow
specification to a set of values for the managed objects that control specification to a set of values for the managed objects that control
each relay or end system. For example, the IEEE 802.1 WG has each relay or end system. For example, the IEEE 802.1 WG has
specified (and is specifying) a set of queuing, shaping, and specified (and is specifying) a set of queuing, shaping, and
scheduling algorithms that enable each transit node (bridge or scheduling algorithms that enable each transit node (bridge or
router), and/or a central controller, to compute these values. These router), and/or a central controller, to compute these values. These
algorithms include: algorithms include:
o A credit-based shaper [IEEE802.1Q] Clause 34. o A credit-based shaper [IEEE802.1Qav] (superseded by
[IEEE802.1Q-2018]).
o Time-gated queues governed by a rotating time schedule, o Time-gated queues governed by a rotating time schedule,
synchronized among all transit nodes [IEEE802.1Qbv]. synchronized among all transit nodes [IEEE802.1Qbv] (superseded by
[IEEE802.1Q-2018]).
o Synchronized double (or triple) buffers driven by synchronized o Synchronized double (or triple) buffers driven by synchronized
time ticks. [IEEE802.1Qch]. time ticks. [IEEE802.1Qch] (superseded by [IEEE802.1Q-2018]).
o Pre-emption of an Ethernet packet in transmission by a packet with o Pre-emption of an Ethernet packet in transmission by a packet with
a more stringent latency requirement, followed by the resumption a more stringent latency requirement, followed by the resumption
of the preempted packet [IEEE802.1Qbu], [IEEE802.3br]. of the preempted packet [IEEE802.1Qbu] (superseded by
[IEEE802.1Q-2018]), [IEEE802.3br] (superseded by
[IEEE802.3-2018]).
While these techniques are currently embedded in Ethernet [IEEE802.3] While these techniques are currently embedded in Ethernet
and bridging standards, we can note that they are all, except perhaps [IEEE802.3-2018] and bridging standards, we can note that they are
for packet preemption, equally applicable to other media than all, except perhaps for packet preemption, equally applicable to
Ethernet, and to routers as well as bridges. Other media may have other media than Ethernet, and to routers as well as bridges. Other
its own methods, see, e.g., [I-D.ietf-6tisch-architecture], media may have its own methods, see, e.g.,
[RFC7554]. DetNet may include such definitions in the future, or may [I-D.ietf-6tisch-architecture], [RFC7554]. DetNet may include such
define how these techniques can be used by DetNet nodes. 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 node to A Service instance represents all the functions required on a node to
allow the end-to-end service between the UNIs. 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
participating in DetNet communication may require connectivity before participating in DetNet communication may require connectivity before
setting up an App-flow that requires the DetNet service. Such a setting up an App-flow that requires the DetNet service. Such a
connectivity related service instance and the one dedicated for connectivity related service instance and the one dedicated for
DetNet service share the same access. Packets belonging to a DetNet DetNet service share the same access. Packets belonging to a DetNet
flow are selected by a filter configured on the access ("F1" and flow are selected by a filter configured on the access ("F1" and
"F2"). As a result, data flow specific access ("access-A + F1" and "F2"). As a result, data flow specific access ("access-A + F1" and
"access-B + F2") are terminated in the flow specific service instance "access-B + F2") are terminated in the flow specific service instance
("SI-1" and "SI-2"). A tunnel is used to provide connectivity ("SI-1" and "SI-2"). A tunnel is used to provide connectivity
skipping to change at page 29, line 38 skipping to change at page 29, line 43
The tunnel between the service instances may have some special The tunnel between the service instances may have some special
characteristics. For example, in case of a DetNet L3 service, there characteristics. For example, in case of a DetNet L3 service, there
are differences in the usage of the PW for DetNet traffic compared to are differences in the usage of the PW for DetNet traffic compared to
the network model described in [RFC6658]. In the DetNet scenario, the network model described in [RFC6658]. In the DetNet scenario,
the PW is likely to be used exclusively by the DetNet flow, whereas the PW is likely to be used exclusively by the DetNet flow, whereas
[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
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
skipping to change at page 31, line 26 skipping to change at page 31, line 36
(e.g., two LSRs are interconnected by a L2 bridged domain, etc.). (e.g., two LSRs are interconnected by a L2 bridged domain, etc.).
The three representative forwarding methods considered for The three representative forwarding methods considered for
deterministic networking are: deterministic networking are:
o IP routing o IP routing
o MPLS label switching o MPLS label switching
o Ethernet bridging o Ethernet bridging
A packet with corresponding Flow-IDs is illustrated in Figure 9. A packet with corresponding Flow-IDs is illustrated in Figure 9,
which also indicates where each Flow-ID can be added or removed.
add/remove add/remove add/remove add/remove
Eth Flow-ID IP Flow-ID Eth Flow-ID IP Flow-ID
| | | |
v v v v
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| | | | | | | | | |
| Eth | MPLS | IP | Application data | | Eth | MPLS | IP | Application data |
| | | | | | | | | |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
skipping to change at page 36, line 19 skipping to change at page 37, line 17
[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-14 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work
in progress), April 2018. in progress), April 2018.
[I-D.ietf-detnet-dp-sol-ip] [I-D.ietf-detnet-dp-sol-ip]
IETF, "DetNet IP Data Plane Encapsulation", July 2018, Korhonen, J. and B. Varga, "DetNet IP Data Plane
<https://datatracker.ietf.org/doc/ Encapsulation", draft-ietf-detnet-dp-sol-ip-00 (work in
draft-ietf-detnet-dp-sol-ip/>. progress), July 2018.
[I-D.ietf-detnet-dp-sol-mpls] [I-D.ietf-detnet-dp-sol-mpls]
IETF, "DetNet MPLS Data Plane Encapsulation", July 2018, Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
<https://datatracker.ietf.org/doc/ Encapsulation", draft-ietf-detnet-dp-sol-mpls-00 (work in
draft-ietf-detnet-dp-sol-mpls/>. progress), July 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-05 (work Statement", draft-ietf-detnet-problem-statement-06 (work
in progress), June 2018. in progress), July 2018.
[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-17 (work in progress), June 2018. ietf-detnet-use-cases-17 (work in progress), June 2018.
[I-D.ietf-spring-segment-routing] [IEC62439-3-2016]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., International Electrotechnical Commission (IEC) TC 65/SC
Litkowski, S., and R. Shakir, "Segment Routing 65C - Industrial networks, "IEC 62439-3:2016 Industrial
Architecture", draft-ietf-spring-segment-routing-15 (work communication networks - High availability automation
in progress), January 2018. networks - Part 3: Parallel Redundancy Protocol (PRP) and
High-availability Seamless Redundancy (HSR)", 2016,
<https://webstore.iec.ch/publication/24447>.
[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 Frame IEEE Standards Association, "IEEE Std 802.1CB-2017 Frame
Replication and Elimination for Reliability", 2017, Replication and Elimination for Reliability", 2017,
<http://www.ieee802.org/1/files/private/cb-drafts/>. <https://ieeexplore.ieee.org/document/8091139/>.
[IEEE802.1Q] [IEEE802.1Q-2018]
IEEE Standards Association, "IEEE Std 802.1Q-2018 Bridges IEEE Standards Association, "IEEE Std 802.1Q-2018 Bridges
and Bridged Networks", 2018, and Bridged Networks", 2018,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/802.1Q-2018.html>. standard/802.1Q-2018.html>.
[IEEE802.1Qav]
IEEE Standards Association, "IEEE Std 802.1Qav-2009
Bridges and Bridged Networks - Amendment 12: Forwarding
and Queuing Enhancements for Time-Sensitive Streams",
2009, <https://ieeexplore.ieee.org/document/5375704/>.
[IEEE802.1Qbu] [IEEE802.1Qbu]
IEEE Standards Association, "IEEE Std 802.1Qbu-2016 IEEE Standards Association, "IEEE Std 802.1Qbu-2016
Bridges and Bridged Networks - Amendment 26: Frame Bridges and Bridged Networks - Amendment 26: Frame
Preemption", 2016, Preemption", 2016,
<https://ieeexplore.ieee.org/document/7553415/>. <https://ieeexplore.ieee.org/document/7553415/>.
[IEEE802.1Qbv] [IEEE802.1Qbv]
IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE Standards Association, "IEEE Std 802.1Qbv-2015
Bridges and Bridged Networks - Amendment 25: Enhancements Bridges and Bridged Networks - Amendment 25: Enhancements
for Scheduled Traffic", 2015, for Scheduled Traffic", 2015,
<https://ieeexplore.ieee.org/document/7572858/>. <https://ieeexplore.ieee.org/document/7572858/>.
[IEEE802.1Qch] [IEEE802.1Qch]
IEEE Standards Association, "IEEE Std 802.1Qbv-2015 IEEE Standards Association, "IEEE Std 802.1Qch-2017
Bridges and Bridged Networks - Amendment 29: Cyclic Bridges and Bridged Networks - Amendment 29: Cyclic
Queuing and Forwarding", 2017, Queuing and Forwarding", 2017,
<https://standards.ieee.org/findstds/ <https://ieeexplore.ieee.org/document/7961303/>.
standard/802.1Qch-2017.html>.
[IEEE802.1TSNTG] [IEEE802.1TSNTG]
IEEE Standards Association, "IEEE 802.1 Time-Sensitive IEEE Standards Association, "IEEE 802.1 Time-Sensitive
Networking Task Group", 2013, Networking Task Group", 2013,
<http://www.ieee802.org/1/tsn>. <http://www.ieee802.org/1/tsn>.
[IEEE802.3] [IEEE802.3-2018]
IEEE Standards Association, "IEEE Std 802.3-2015 Standard IEEE Standards Association, "IEEE Std 802.3-2018 Standard
for Ethernet", 2015, for Ethernet", 2018, <http://standards.ieee.org/findstds/
<http://ieeexplore.ieee.org/document/7428776/>. standard/802.3-2018.html>.
[IEEE802.3br] [IEEE802.3br]
IEEE Standards Association, "IEEE Std 802.3br-2016 IEEE Standards Association, "IEEE Std 802.3br-2016
Standard for Ethernet Amendment 5: Specification and Standard for Ethernet Amendment 5: Specification and
Management Parameters for Interspersing Express Traffic", Management Parameters for Interspersing Express Traffic",
2016, <http://ieeexplore.ieee.org/document/7900321/>. 2016, <http://ieeexplore.ieee.org/document/7900321/>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
skipping to change at page 39, line 16 skipping to change at page 40, line 22
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>.
[RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J.
Dong, "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for
Ring Topology", RFC 8227, DOI 10.17487/RFC8227, August
2017, <https://www.rfc-editor.org/info/rfc8227>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[TEAS] IETF, "Traffic Engineering Architecture and Signaling [TEAS] IETF, "Traffic Engineering Architecture and Signaling
Working Group", Working Group",
<https://datatracker.ietf.org/doc/charter-ietf-teas/>. <https://datatracker.ietf.org/doc/charter-ietf-teas/>.
Authors' Addresses Authors' Addresses
Norman Finn Norman Finn
Huawei Huawei
3755 Avocado Blvd. 3755 Avocado Blvd.
PMB 436 PMB 436
 End of changes. 59 change blocks. 
131 lines changed or deleted 162 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/