draft-ietf-detnet-architecture-04.txt   draft-ietf-detnet-architecture-05.txt 
DetNet N. Finn DetNet N. Finn
Internet-Draft Huawei Technologies Co. Ltd Internet-Draft Huawei
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: May 3, 2018 Cisco Expires: November 2, 2018 Cisco
B. Varga B. Varga
J. Farkas J. Farkas
Ericsson Ericsson
October 30, 2017 May 1, 2018
Deterministic Networking Architecture Deterministic Networking Architecture
draft-ietf-detnet-architecture-04 draft-ietf-detnet-architecture-05
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 rapidly change with the explicit routes for DetNet flows that do not rapidly change with the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 May 3, 2018. This Internet-Draft will expire on November 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 33 skipping to change at page 2, line 33
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 TSN to DetNet dictionary . . . . . . . . . . . . 6 2.2. IEEE 802 TSN to DetNet dictionary . . . . . . . . . . . . 6
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 . . . . . . . . . . 7
3.2. Mechanisms to achieve DetNet Qos . . . . . . . . . . . . 9 3.2. Mechanisms to achieve DetNet Qos . . . . . . . . . . . . 9
3.2.1. Congestion protection . . . . . . . . . . . . . . . . 9 3.2.1. Congestion protection . . . . . . . . . . . . . . . . 9
3.2.2. Explicit routes . . . . . . . . . . . . . . . . . . . 9 3.2.2. Explicit routes . . . . . . . . . . . . . . . . . . . 9
3.2.3. Jitter Reduction . . . . . . . . . . . . . . . . . . 10 3.2.3. Jitter Reduction . . . . . . . . . . . . . . . . . . 10
3.2.4. Packet Replication and Elimination . . . . . . . . . 11 3.2.4. Packet Replication and Elimination . . . . . . . . . 11
3.3. Secondary goals for DetNet . . . . . . . . . . . . . . . 12 3.2.5. Packet encoding for service protection . . . . . . . 12
3.3.1. Coexistence with normal traffic . . . . . . . . . . . 12 3.3. Secondary goals for DetNet . . . . . . . . . . . . . . . 13
3.3.1. Coexistence with normal traffic . . . . . . . . . . . 13
3.3.2. Fault Mitigation . . . . . . . . . . . . . . . . . . 13 3.3.2. Fault Mitigation . . . . . . . . . . . . . . . . . . 13
4. DetNet Architecture . . . . . . . . . . . . . . . . . . . . . 14 4. DetNet Architecture . . . . . . . . . . . . . . . . . . . . . 14
4.1. DetNet stack model . . . . . . . . . . . . . . . . . . . 14 4.1. DetNet stack model . . . . . . . . . . . . . . . . . . . 14
4.1.1. Representative Protocol Stack Model . . . . . . . . . 14 4.1.1. Representative Protocol Stack Model . . . . . . . . . 14
4.1.2. DetNet Data Plane Overview . . . . . . . . . . . . . 16 4.1.2. DetNet Data Plane Overview . . . . . . . . . . . . . 16
4.1.3. Network reference model . . . . . . . . . . . . . . . 18 4.1.3. Network reference model . . . . . . . . . . . . . . . 18
4.2. DetNet systems . . . . . . . . . . . . . . . . . . . . . 19 4.2. DetNet systems . . . . . . . . . . . . . . . . . . . . . 19
4.2.1. End system . . . . . . . . . . . . . . . . . . . . . 19 4.2.1. End system . . . . . . . . . . . . . . . . . . . . . 19
4.2.2. DetNet edge, relay, and transit nodes . . . . . . . . 20 4.2.2. DetNet edge, relay, and transit nodes . . . . . . . . 20
4.3. DetNet flows . . . . . . . . . . . . . . . . . . . . . . 21 4.3. DetNet flows . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 6, line 9 skipping to change at page 6, line 11
participates in the DetNet service layer. It typically participates in the DetNet service layer. It typically
incorporates DetNet transport layer functions as well, in incorporates DetNet transport layer functions as well, in
which case it is collocated with a transit node. which case it is collocated with a transit node.
reservation reservation
A trail of configuration between source to destination(s) A trail of configuration between source to destination(s)
through transit nodes and subnets associated with a DetNet through transit nodes and subnets associated with a DetNet
flow, to provide congestion protection. flow, to provide congestion protection.
DetNet service layer DetNet service layer
The layer at which service protection is provided, packet The layer at which service protection is provided, either
sequencing, replication, and elimination (Section 3.2.4) or packet sequencing, replication, and elimination
packet encoding. (Section 3.2.4) or packet encoding (Section 3.2.5).
source source
An end system capable of sourcing a DetNet flow. An end system capable of sourcing 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
links and/or sub-networks to provide paths for DetNet service links and/or sub-networks to provide paths for DetNet service
layer functions. Optionally provides congestion protection layer functions. Optionally provides congestion protection
over those paths. An MPLS LSR is an example of a DetNet over those paths. An MPLS LSR is an example of a DetNet
skipping to change at page 8, line 6 skipping to change at page 8, line 6
(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
these losses. The mechanisms employed are constrained by the these losses. The mechanisms employed are constrained by the
requirement to meet the users' latency requirements. Packet requirement to meet the users' latency requirements. Packet
replication and elimination (Section 3.2.4) is described in this replication and elimination (Section 3.2.4) and packet encoding
document to provide service protection; others may be found. This (Section 3.2.5) are described in this document to provide service
mechanism distributes the contents of DetNet flows over multiple protection; others may be found. This mechanism distributes the
paths in time and/or space, so that the loss of some of the paths contents of DetNet flows over multiple paths in time and/or space, so
does need not cause the loss of any packets. The paths are typically that the loss of some of the paths does need not cause the loss of
(but not necessarily) explicit routes, so that they cannot suffer any packets. The paths are typically (but not necessarily) explicit
temporary interruptions caused by the reconvergence of routing or routes, so that they cannot suffer temporary interruptions caused by
bridging protocols. the reconvergence of routing or bridging protocols.
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
skipping to change at page 10, line 11 skipping to change at page 10, line 11
wiring. As an additional benefit, ring topologies can often utilize wiring. As an additional benefit, ring topologies can often utilize
different topology management protocols than those used for a mesh different topology management protocols than those used for a mesh
network, with a consequent reduction in the response time to topology network, with a consequent reduction in the response time to topology
changes. Of course, this comes at some cost in terms of increased changes. Of course, this comes at some cost in terms of increased
hop count, and thus latency, for the typical path. hop count, 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.4) over network topology events. Service protection (Section 3.2.4 or
explicit routes provides a high likelihood of continuous Section 3.2.5) over explicit routes provides a high likelihood of
connectivity. Explicit routes are commonly used in MPLS TE LSPs. continuous connectivity. Explicit routes are commonly used in MPLS
TE LSPs.
3.2.3. Jitter Reduction 3.2.3. Jitter Reduction
A core objective of DetNet is to enable the convergence of Non-IP A core objective of DetNet is to enable the convergence of Non-IP
networks onto a common network infrastructure. This requires the networks onto a common network infrastructure. This requires the
accurate emulation of currently deployed mission-specific networks, accurate emulation of currently deployed mission-specific networks,
which typically rely on point-to-point analog (e.g. 4-20mA which typically rely on point-to-point analog (e.g. 4-20mA
modulation) and serial-digital cables (or buses) for highly reliable, modulation) and serial-digital cables (or buses) for highly reliable,
synchronized and jitter-free communications. While the latency of synchronized and jitter-free communications. While the latency of
analog transmissions is basically the speed of light, legacy serial analog transmissions is basically the speed of light, legacy serial
skipping to change at page 12, line 40 skipping to change at page 12, line 40
typical routing and bridging protocols. typical routing and bridging protocols.
If packet replication and elimination is used over paths providing If packet replication and elimination is used over paths providing
congestion protection (Section 3.2.1), and member flows that take congestion protection (Section 3.2.1), and member flows that take
different-length paths through the network are combined, a merge different-length paths through the network are combined, a merge
point may require extra buffering to equalize the delays over the point may require extra buffering to equalize the delays over the
different paths. This equalization ensures that the resultant different paths. This equalization ensures that the resultant
compound flow will not exceed its contracted bandwidth even after one compound flow will not exceed its contracted bandwidth even after one
or the other of the paths is restored after a failure. or the other of the paths is restored after a failure.
3.2.5. Packet encoding for service protection
There are methods for using multiple paths to provide service
protection that involve encoding the information in a packet
belonging to a DetNet flow into multiple transmission units,
combining information from multiple packets into any given
transmission unit. Such techniques, also known as "network coding",
can be used as a DetNet service protection technique.
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 coesistence with other QoS mechanisms Section 3.3.1 and including coesistence 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
skipping to change at page 14, line 12 skipping to change at page 14, line 23
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
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, a work in One may compare it to that in [IEEE802.1CB], Annex C.
progress.
DetNet data plane protocol stack DetNet data plane protocol stack
| 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 |
+----------------------+ +-----------------------+ +----------------------+ +-----------------------+
| Service layer | | Service layer | | Service layer | | Service layer |
| Packet sequencing | | Duplicate elimination | | Packet sequencing | | Duplicate elimination |
skipping to change at page 36, line 7 skipping to change at page 36, line 7
artnum/046615!opendocument>. artnum/046615!opendocument>.
[I-D.dt-detnet-dp-alt] [I-D.dt-detnet-dp-alt]
Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., Korhonen, J., Farkas, J., Mirsky, G., Thubert, P.,
Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol
and Solution Alternatives", draft-dt-detnet-dp-alt-04 and Solution Alternatives", draft-dt-detnet-dp-alt-04
(work in progress), September 2016. (work in progress), September 2016.
[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-12 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
in progress), August 2017. in progress), November 2017.
[I-D.ietf-6tisch-tsch] [I-D.ietf-6tisch-tsch]
Watteyne, T., Palattella, M., and L. Grieco, "Using Watteyne, T., Palattella, M., and L. Grieco, "Using
IEEE802.15.4e TSCH in an IoT context: Overview, Problem IEEE802.15.4e TSCH in an IoT context: Overview, Problem
Statement and Goals", draft-ietf-6tisch-tsch-06 (work in Statement and Goals", draft-ietf-6tisch-tsch-06 (work in
progress), March 2015. progress), March 2015.
[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-02 (work Statement", draft-ietf-detnet-problem-statement-03 (work
in progress), September 2017. in progress), March 2018.
[I-D.ietf-detnet-use-cases] [I-D.ietf-detnet-use-cases]
Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., Grossman, E., "Deterministic Networking Use Cases", draft-
Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., ietf-detnet-use-cases-15 (work in progress), April 2018.
Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana,
X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D.,
Geng, X., Dujovne, D., and M. Seewald, "Deterministic
Networking Use Cases", draft-ietf-detnet-use-cases-13
(work in progress), September 2017.
[I-D.ietf-roll-rpl-industrial-applicability] [I-D.ietf-roll-rpl-industrial-applicability]
Phinney, T., Thubert, P., and R. Assimiti, "RPL Phinney, T., Thubert, P., and R. Assimiti, "RPL
applicability in industrial networks", draft-ietf-roll- applicability in industrial networks", draft-ietf-roll-
rpl-industrial-applicability-02 (work in progress), rpl-industrial-applicability-02 (work in progress),
October 2013. October 2013.
[I-D.svshah-tsvwg-deterministic-forwarding] [I-D.svshah-tsvwg-deterministic-forwarding]
Shah, S. and P. Thubert, "Deterministic Forwarding PHB", Shah, S. and P. Thubert, "Deterministic Forwarding PHB",
draft-svshah-tsvwg-deterministic-forwarding-04 (work in draft-svshah-tsvwg-deterministic-forwarding-04 (work in
skipping to change at page 37, line 11 skipping to change at page 37, line 6
Time-Sensitive Applications in Bridged Local Area Time-Sensitive Applications in Bridged Local Area
Networks", 2011, Networks", 2011,
<http://ieeexplore.ieee.org/document/5741898/>. <http://ieeexplore.ieee.org/document/5741898/>.
[IEEE802.1BA-2011] [IEEE802.1BA-2011]
IEEE, "IEEE Std 802.1BA Audio Video Bridging (AVB) IEEE, "IEEE Std 802.1BA Audio Video Bridging (AVB)
Systems", 2011, Systems", 2011,
<http://ieeexplore.ieee.org/document/6032690/>. <http://ieeexplore.ieee.org/document/6032690/>.
[IEEE802.1CB] [IEEE802.1CB]
IEEE, "Frame Replication and Elimination for Reliability IEEE, "IEEE Std 802.1CB Frame Replication and Elimination
(IEEE Draft P802.1CB)", 2017, for Reliability", 2017,
<http://www.ieee802.org/1/files/private/cb-drafts/>. <http://www.ieee802.org/1/files/private/cb-drafts/>.
[IEEE802.1Q-2014] [IEEE802.1Q-2014]
IEEE, "IEEE Std 802.1Q Bridges and Bridged Networks", IEEE, "IEEE Std 802.1Q Bridges and Bridged Networks",
2014, <http://ieeexplore.ieee.org/document/6991462/>. 2014, <http://ieeexplore.ieee.org/document/6991462/>.
[IEEE802.1Qbu] [IEEE802.1Qbu]
IEEE, "IEEEE Std 802.1Qbu Bridges and Bridged Networks - IEEE, "IEEEE Std 802.1Qbu Bridges and Bridged Networks -
Amendment 26: Frame Preemption", 2016, Amendment 26: Frame Preemption", 2016,
<http://ieeexplore.ieee.org/document/7553415/>. <http://ieeexplore.ieee.org/document/7553415/>.
skipping to change at page 40, line 17 skipping to change at page 40, line 17
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
[TEAS] IETF, "Traffic Engineering Architecture and Signaling", [TEAS] IETF, "Traffic Engineering Architecture and Signaling",
<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 Technologies Co. Ltd Huawei
3755 Avocado Blvd. 3755 Avocado Blvd.
PMB 436 PMB 436
La Mesa, California 91941 La Mesa, California 91941
US US
Phone: +1 925 980 6430 Phone: +1 925 980 6430
Email: norman.finn@mail01.huawei.com Email: norman.finn@mail01.huawei.com
Pascal Thubert Pascal Thubert
Cisco Systems Cisco Systems
 End of changes. 17 change blocks. 
38 lines changed or deleted 43 lines changed or added

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