< draft-ietf-detnet-problem-statement-07.txt   draft-ietf-detnet-problem-statement-08.txt >
DetNet N. Finn DetNet N. Finn
Internet-Draft Huawei Technologies Co. Ltd Internet-Draft Huawei Technologies Co. Ltd
Intended status: Informational P. Thubert Intended status: Informational P. Thubert
Expires: April 6, 2019 Cisco Expires: June 9, 2019 Cisco
October 3, 2018 December 6, 2018
Deterministic Networking Problem Statement Deterministic Networking Problem Statement
draft-ietf-detnet-problem-statement-07 draft-ietf-detnet-problem-statement-08
Abstract Abstract
This paper documents the needs in various industries to establish This paper documents the needs in various industries to establish
multi-hop paths for characterized flows with deterministic multi-hop paths for characterized flows with deterministic
properties. properties.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 April 6, 2019. This Internet-Draft will expire on June 9, 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 2, line 47 skipping to change at page 2, line 47
LAN boundaries. For instance, IACS segregates the network along the LAN boundaries. For instance, IACS segregates the network along the
broad lines of the Purdue Enterprise Reference Architecture (PERA) broad lines of the Purdue Enterprise Reference Architecture (PERA)
[ISA95], typically using deterministic local area networks for level [ISA95], typically using deterministic local area networks for level
2 control systems, whereas public infrastructures such as Electricity 2 control systems, whereas public infrastructures such as Electricity
Automation require deterministic properties over the Wide Area. The Automation require deterministic properties over the Wide Area. The
realization is now coming that the convergence of IT and Operational realization is now coming that the convergence of IT and Operational
Technology (OT) networks requires Layer-3, as well as Layer-2, Technology (OT) networks requires Layer-3, as well as Layer-2,
capabilities. capabilities.
While the initial user base has focused almost entirely on Ethernet While the initial user base has focused almost entirely on Ethernet
physical media and Ethernet-based bridging protocol (from several physical media and Ethernet-based bridging protocol from several
Standards Development Organizations), the need for Layer-3 expressed Standards Development Organizations, the need for Layer-3 expressed
above, must not be confined to Ethernet and Ethernet-like media, and above, must not be confined to Ethernet and Ethernet-like media.
while such media must be encompassed by any useful Deterministic While such media must be encompassed by any useful Deterministic
Networking (DetNet) Architecture, cooperation between IETF and other Networking (DetNet) Architecture, cooperation between IETF and other
SDOs must not be limited to IEEE or IEEE 802. Furthermore, while the SDOs must not be limited to IEEE or IEEE 802. Furthermore, while the
work completed and ongoing in other SDOs, and in IEEE 802 in work completed and ongoing in other SDOs, and in IEEE 802 in
particular, provide an obvious starting point for a DetNet particular, provide an obvious starting point for a DetNet
architecture, we must not assume that these other SDOs' work confines architecture, we must not assume that these other SDOs' work confines
the space in which the DetNet architecture progresses. the space in which the DetNet architecture progresses.
The properties of deterministic networks will have specific The properties of deterministic networks will have specific
requirements for the use of routed networks to support these requirements for the use of routed networks to support these
applications and a new model must be proposed to integrate applications and a new model must be proposed to integrate
determinism in IT technology. The proposed model should enable a determinism in IT technology. The proposed model should enable a
fully scheduled operation orchestrated by a central controller, and fully scheduled operation orchestrated by a central controller, and
may support a more distributed operation with probably lesser may support a more distributed operation with probably lesser
capabilities. In any fashion, the model should not compromise the capabilities. In any fashion, the model should not compromise the
ability of a network to keep carrying the sorts of traffic that is ability of a network to keep carrying the sorts of traffic that is
already carried today in conjunction with new, more deterministic already carried today in conjunction with new, more deterministic
flows. Forward note: The DetNet Architecture flows. Forward note: The DetNet Architecture
[I-D.ietf-detnet-architecture] is the document produced by the DetNet [I-D.ietf-detnet-architecture] is the document produced by the DetNet
WG to describe that model. WG to describe that model.
Once the abstract model is agreed upon, the IETF will need to specify At the time of this writing, the expectation is that once the
the signaling elements to be used to establish a path and the tagging abstract model is agreed upon, the IETF will specify the signaling
elements to be used identify the flows that are to be forwarded along elements to be used to establish a path and the tagging elements to
that path. The IETF will also need to specify the necessary be used identify the flows that are to be forwarded along that path.
The expectation is also that IETF will specify the necessary
protocols, or protocol additions, based on relevant IETF protocols, or protocol additions, based on relevant IETF
technologies, to implement the selected model. technologies, to implement the selected model.
As a result of this work, it will be possible to establish a multi- A desirable outcome of the work is the capability to establish a
hop path over the IP or MPLS network, for a particular flow with multi-hop path over the IP or MPLS network, for a particular flow
given timing and precise throughput requirements, and carry this with given timing and precise throughput requirements, and carry this
particular flow along the multi-hop path with such characteristics as particular flow along the multi-hop path with such characteristics as
low latency and ultra-low jitter, reordering and/or replication and low latency and ultra-low jitter, reordering and/or replication and
elimination of packets over non-congruent paths for a higher delivery elimination of packets over non-congruent paths for a higher delivery
ratio, and/or zero congestion loss, regardless of the amount of other ratio, and/or zero congestion loss, regardless of the amount of other
flows in the network. flows in the network.
Depending on the network capabilities and on the current state, Depending on the network capabilities and on the current state,
requests to establish a path by an end-node or a network management requests to establish a path by an end-node or a network management
entity may be granted or rejected, an existing path may be moved or entity may be granted or rejected, an existing path may be moved or
removed, and DetNet flows exceeding their contract may face packet removed, and DetNet flows exceeding their contract may face packet
skipping to change at page 4, line 15 skipping to change at page 4, line 16
basing all of these disparate digital technologies on packet basing all of these disparate digital technologies on packet
networks. networks.
The goals of Deterministic Networking are to enable the migration of The goals of Deterministic Networking are to enable the migration of
applications with critical timing and reliability issues that applications with critical timing and reliability issues that
currently use special-purpose fieldbus technologies (HDMI, CANbus, currently use special-purpose fieldbus technologies (HDMI, CANbus,
ProfiBus, etc... even RS-232!) to packet technologies in general, and ProfiBus, etc... even RS-232!) to packet technologies in general, and
the Internet Protocol in particular, and to support both these new the Internet Protocol in particular, and to support both these new
applications, and existing packet network applications, over the same applications, and existing packet network applications, over the same
physical network. In other words, a Deterministic Network is physical network. In other words, a Deterministic Network is
backwards compatible with - capable of transporting - statistically backwards compatible with (capable of transporting) statistically
multiplexed traffic while preserving the properties of the accepted multiplexed traffic while preserving the properties of the accepted
deterministic flows. deterministic flows.
Considerable experience ([ODVA]/[EIP],[AVnu], Considerable experience from automation and professional audio/video
[Profinet],[HART],[IEC62439], [ISA100.11a] and [WirelessHART], networks (e.g., [ODVA]/[EIP], [AVnu], [Profinet], [HART], [IEC62439],
etc...) has shown that these applications need a some or all of a [ISA100.11a] and [WirelessHART]) has shown that these applications
suite of features that includes: need a some or all of a suite of features that includes:
1. Time synchronization of all host and network nodes (routers and/ 1. Time synchronization of all host and network nodes (routers and/
or bridges), accurate to something between 10 nanoseconds and 10 or bridges), accurate to something between 10 nanoseconds and 10
microseconds, depending on the application. microseconds, depending on the application.
2. Support for Deterministic packet flows that: 2. Support for Deterministic packet flows that:
* Can be unicast or multicast; * Can be unicast or multicast;
* Need absolute guarantees of minimum and maximum latency end- * Need absolute guarantees of minimum and maximum latency end-
skipping to change at page 6, line 24 skipping to change at page 6, line 24
3.1. Supported topologies 3.1. Supported topologies
In some use cases, the end point which run the application is In some use cases, the end point which run the application is
involved in the deterministic networking operation, for instance by involved in the deterministic networking operation, for instance by
controlling certain aspects of its throughput such as rate or precise controlling certain aspects of its throughput such as rate or precise
time of emission. In that case, the deterministic path is end-to-end time of emission. In that case, the deterministic path is end-to-end
from application host to application host. from application host to application host.
On the other end, the deterministic portion of a path may be a tunnel On the other end, the deterministic portion of a path may be a tunnel
between and ingress and an egress router. In any case, routers and between an ingress and an egress router. In any case, routers and
switches in between should not need to be aware whether the path is switches in between should not need to be aware whether the path is
end-to-end of a tunnel. end-to-end or a tunnel.
While it is clear that DetNet does not aim at setting up While it is clear that DetNet does not aim at setting up
deterministic paths over the global Internet, there is still a lack deterministic paths over the global Internet, there is still a lack
of clarity on the limits of a domain where a deterministic path can of clarity on the limits of a domain where a deterministic path can
be set up. These limits may depend in the technology that is used to be set up. These limits may depend in the technology that is used to
set the path up, whether it is centralized or distributed. set the path up, whether it is centralized or distributed.
3.2. Flow Characterization 3.2. Flow Characterization
Deterministic forwarding can only apply on flows with well-defined Deterministic forwarding can only apply on flows with well-defined
skipping to change at page 7, line 33 skipping to change at page 7, line 33
o support for life cycle management for a path o support for life cycle management for a path
(instantiate/modify/update/delete) (instantiate/modify/update/delete)
o support for adaptability to cope with various events such as loss o support for adaptability to cope with various events such as loss
of a link, etc... of a link, etc...
o expose the status of the path to the end devices (UNI interface) o expose the status of the path to the end devices (UNI interface)
o provide additional reliability through redundancy, in particular o provide additional reliability through redundancy, in particular
with packet replication and elimination; with packet Packet Replication, Elimination and Ordering Functions
(PREOF) where the former may generate an out-of-order delivery
that may need to be corrected corrected by the latter;
o indicate the flows and packet sequences in-band with the flows; o indicate the flows and packet sequences in-band with the flows,
this is needed for flows that require PREOF in order to isolate
duplicates and reorder in the end;
3.4. Distributed Path Setup 3.4. Distributed Path Setup
Whether a distributed alternative without a PCE can be valuable could Whether a distributed alternative without a PCE can be valuable could
be studied as well. Such an alternative could for instance inherit be studied as well. Such an alternative could for instance inherit
from the Resource ReSerVation Protocol [RFC3209] (RSVP-TE) flows. from the Resource ReSerVation Protocol [RFC3209] (RSVP-TE) flows.
But the focus of the work should be to deliver the centralized But the focus of the work should be to deliver the centralized
approach first. approach first.
To enable a RSVP-TE like functionality, the following steps would To enable a RSVP-TE like functionality, the following steps would
skipping to change at page 9, line 24 skipping to change at page 9, line 28
The specific threats against DetNet are further discussed in the The specific threats against DetNet are further discussed in the
DetNet Security Considerations [I-D.ietf-detnet-security] document. DetNet Security Considerations [I-D.ietf-detnet-security] document.
5. IANA Considerations 5. IANA Considerations
This document does not require an action from IANA. This document does not require an action from IANA.
6. Acknowledgments 6. Acknowledgments
The authors wish to thank Lou Berger, Stewart Bryant, Janos Farkas, The authors wish to thank Lou Berger, Pat Thaler, Jouni Korhonen,
Andrew Malis, Jouni Korhonen, Erik Nordmark, George Swallow, Lou Janos Farkas, Stewart Bryant, Andrew Malis, Ethan Grossman, Patrick
Berger, Ines Robles, Shwetha Bhandari, Rudy Klecka, Anca Zamfir, Wetterwald, Subha Dhesikan, Matthew Miller, Erik Nordmark, George
David Black, Thomas Watteyne, Shitanshu Shah, Kiran Makhijani, Craig Swallow, Rodney Cummings, Ines Robles, Shwetha Bhandari, Rudy Klecka,
Gunther, Rodney Cummings, Wilfried Steiner, Marcel Kiessling, Karl Anca Zamfir, David Black, Thomas Watteyne, Shitanshu Shah, Kiran
Weber, Ethan Grossman, Patrick Wetterwald, Subha Dhesikan, Rudy Makhijani, Craig Gunther, Warren Kumari, Wilfried Steiner, Marcel
Klecka and Pat Thaler for their various contributions to this work. Kiessling, Karl Weber, Alissa Cooper, and Benjamin Kaduk for their
various contributions to this work.
7. Informative References 7. Informative References
[AVnu] http://www.avnu.org/, "The AVnu Alliance tests and [AVnu] http://www.avnu.org/, "The AVnu Alliance tests and
certifies devices for interoperability, providing a simple certifies devices for interoperability, providing a simple
and reliable networking solution for AV network and reliable networking solution for AV network
implementation based on the IEEE Audio Video Bridging implementation based on the IEEE Audio Video Bridging
(AVB) and Time-Sensitive Networking (TSN) standards.". (AVB) and Time-Sensitive Networking (TSN) standards.".
[EIP] http://www.odva.org/, "EtherNet/IP provides users with the [EIP] http://www.odva.org/, "EtherNet/IP provides users with the
skipping to change at page 10, line 8 skipping to change at page 10, line 21
Publications_Numbered/ Publications_Numbered/
PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>. PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>.
[HART] www.hartcomm.org, "Highway Addressable Remote Transducer, [HART] www.hartcomm.org, "Highway Addressable Remote Transducer,
a group of specifications for industrial process and a group of specifications for industrial process and
control devices administered by the HART Foundation". control devices administered by the HART Foundation".
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-08 (work in progress), September 2018. detnet-architecture-09 (work in progress), October 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-02 (work in progress), April 2018. detnet-security-03 (work in progress), October 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-18 (work in progress), September ietf-detnet-use-cases-19 (work in progress), October 2018.
2018.
[IEC62439] [IEC62439]
IEC, "Industrial communication networks - High IEC, "Industrial communication networks - High
availability automation networks - Part 3: Parallel availability automation networks - Part 3: Parallel
Redundancy Protocol (PRP) and High-availability Seamless Redundancy Protocol (PRP) and High-availability Seamless
Redundancy (HSR) - IEC62439-3", 2012, Redundancy (HSR) - IEC62439-3", 2012,
<https://webstore.iec.ch/publication/7018>. <https://webstore.iec.ch/publication/7018>.
[IEEE802.1TSNTG] [IEEE802.1TSNTG]
IEEE Standards Association, "IEEE 802.1 Time-Sensitive IEEE Standards Association, "IEEE 802.1 Time-Sensitive
 End of changes. 16 change blocks. 
35 lines changed or deleted 40 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/