draft-ietf-detnet-problem-statement-03.txt   draft-ietf-detnet-problem-statement-04.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: September 19, 2018 Cisco Expires: December 8, 2018 Cisco
March 18, 2018 June 6, 2018
Deterministic Networking Problem Statement Deterministic Networking Problem Statement
draft-ietf-detnet-problem-statement-03 draft-ietf-detnet-problem-statement-04
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 properties multi-hop paths for characterized flows with deterministic 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 September 19, 2018. This Internet-Draft will expire on December 8, 2018.
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 19 skipping to change at page 2, line 19
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Supported topologies . . . . . . . . . . . . . . . . . . 6 3.1. Supported topologies . . . . . . . . . . . . . . . . . . 6
3.2. Flow Characterization . . . . . . . . . . . . . . . . . . 6 3.2. Flow Characterization . . . . . . . . . . . . . . . . . . 6
3.3. Centralized Path Computation and Installation . . . . . . 6 3.3. Centralized Path Computation and Installation . . . . . . 6
3.4. Distributed Path Setup . . . . . . . . . . . . . . . . . 7 3.4. Distributed Path Setup . . . . . . . . . . . . . . . . . 7
3.5. Duplicated data format . . . . . . . . . . . . . . . . . 8 3.5. Duplicated data format . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . 9 7. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Deterministic Networking Use Cases [I-D.ietf-detnet-use-cases] The Deterministic Networking Use Cases [I-D.ietf-detnet-use-cases]
document illustrates that beyond the classical case of industrial document illustrates that beyond the classical case of industrial
automation and control systems (IACS), there are in fact multiple automation and control systems (IACS), there are in fact multiple
industries with strong and yet relatively similar needs for industries with strong and yet relatively similar needs for
deterministic network services with latency guarantees and ultra-low deterministic network services with latency guarantees and ultra-low
packet loss. packet loss.
skipping to change at page 4, line 6 skipping to change at page 4, line 6
dramatically over the last 30-40 years. Video and audio dramatically over the last 30-40 years. Video and audio
entertainment, and control systems for machinery, manufacturing entertainment, and control systems for machinery, manufacturing
processes, and vehicles are also ubiquitous, and are now based almost processes, and vehicles are also ubiquitous, and are now based almost
entirely on digital technologies. Over the past 10 years, engineers entirely on digital technologies. Over the past 10 years, engineers
in these fields have come to realize that significant advantages in in these fields have come to realize that significant advantages in
both cost and in the ability to accelerate growth can be obtained by both cost and in the ability to accelerate growth can be obtained by
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 that use special-purpose fieldbus technologies (HDMI, applications with critical timing and reliability issues that
CANbus, ProfiBus, etc... even RS-232!) to packet technologies in currently use special-purpose fieldbus technologies (HDMI, CANbus,
general, and the Internet Protocol in particular, and to support both ProfiBus, etc... even RS-232!) to packet technologies in general, and
these new applications, and existing packet network applications, the Internet Protocol in particular, and to support both these new
over the same physical network. applications, and existing packet network applications, over the same
physical network.
Considerable experience ([ODVA]/[EIP],[AVnu], Considerable experience ([ODVA]/[EIP],[AVnu],
[Profinet],[HART],[IEC62439], [ISA100.11a] and [WirelessHART], [Profinet],[HART],[IEC62439], [ISA100.11a] and [WirelessHART],
etc...) has shown that these applications need a some or all of a etc...) has shown that these applications need a some or all of a
suite of features that includes: 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 critical 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-
to-end across the network; sometimes a tight jitter is to-end across the network; sometimes a tight jitter is
required as well; required as well;
* Need a packet loss ratio beyond the classical range for a * Need a packet loss ratio beyond the classical range for a
particular medium, in the range of 10^-9 to 10^-12, or better, particular medium, in the range of 10^-9 to 10^-12, or better,
on Ethernet, and in the order of 10^-5 in Wireless Sensor Mesh on Ethernet, and in the order of 10^-5 in Wireless Sensor Mesh
skipping to change at page 6, line 24 skipping to change at page 6, line 24
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 and 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 of 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
seu th epath 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
characteristics such as periodicity and burstiness. Before a path characteristics such as periodicity and burstiness. Before a path
can be established to serve them, the expression of those can be established to serve them, the expression of those
characteristics, and how the network can serve them, for instance in characteristics, and how the network can serve them, for instance in
shaping and forwarding operations, must be specified. shaping and forwarding operations, must be specified.
3.3. Centralized Path Computation and Installation 3.3. Centralized Path Computation and Installation
skipping to change at page 7, line 46 skipping to change at page 7, line 46
To enable a RSVP-TE like functionality, the following steps would To enable a RSVP-TE like functionality, the following steps would
take place: take place:
1. Neighbors and their capabilities are discovered and exposed to 1. Neighbors and their capabilities are discovered and exposed to
compute a path that fits the DetNet constraints, typically of compute a path that fits the DetNet constraints, typically of
latency, time precision and resource availability. latency, time precision and resource availability.
2. A constrained path is calculated with an improved version of CSPF 2. A constrained path is calculated with an improved version of CSPF
that is aware of DetNet. that is aware of DetNet.
3. The path is installed using RSVP-TE, associated with flow 3. The path may be installed using a control protocol such as RSVP-
identification, per-hop behavior such as replication and TE, associated with flow identification, per-hop behavior such as
elimination, blocked resources, and flow timing information. Packet Replication and Elimination, blocked resources, and flow
timing information. Alternatively, the routing and flow
information may be placed in-band in the packet, e.g., using
Segment Routing, in which case the packet is routed along a
prescribed source route path following forwarding indications
that are present in the packet.
4. Traffic flows are transported through the MPLS-TE tunnel, using 4. Traffic flows are transported through the MPLS-TE tunnel, using
the reserved resources for this flow at each hop. the reserved resources for this flow at each hop.
3.5. Duplicated data format 3.5. Duplicated data format
In some cases the duplication and elimination of packets over non- In some cases the duplication and elimination of packets over non-
congruent paths is required to achieve a sufficiently high delivery congruent paths is required to achieve a sufficiently high delivery
ratio to meet application needs. In these cases, a small number of ratio to meet application needs. In these cases, a small number of
packet formats and supporting protocols are required (preferably, packet formats and supporting protocols are required (preferably,
skipping to change at page 8, line 42 skipping to change at page 8, line 47
resources such as Ethernet trunks and radio spectrum. The resources such as Ethernet trunks and radio spectrum. The
requirement is that there is no possible data leak from and into a requirement is that there is no possible data leak from and into a
deterministic flow, and in a more general fashion there is no deterministic flow, and in a more general fashion there is no
possible influence whatsoever from the outside on a deterministic possible influence whatsoever from the outside on a deterministic
flow. The expectation is that physical resources are effectively flow. The expectation is that physical resources are effectively
associated with a given flow at a given point of time. In that associated with a given flow at a given point of time. In that
model, Time Sharing of physical resources becomes transparent to the model, Time Sharing of physical resources becomes transparent to the
individual flows which have no clue whether the resources are used by individual flows which have no clue whether the resources are used by
other flows at other times. other flows at other times.
Security must cover: The overall security of a deterministic system must cover:
o the protection of the signaling protocol o the protection of the signaling protocol
o the authentication and authorization of the controlling nodes o the authentication and authorization of the controlling nodes
o the identification and shaping of the flows o the identification and shaping of the flows
o the isolation of flows from leakage and other influences from any o the isolation of flows from leakage and other influences from any
activity sharing physical resources. activity sharing physical resources.
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
skipping to change at page 9, line 11 skipping to change at page 9, line 15
o the isolation of flows from leakage and other influences from any o the isolation of flows from leakage and other influences from any
activity sharing physical resources. activity sharing physical resources.
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, Jouni Korhonen, Erik Nordmark, The authors wish to thank Lou Berger, Stewart Bryant, Janos Farkas,
George Swallow, Rudy Klecka, Anca Zamfir, David Black, Thomas Andrew Malis, Jouni Korhonen, Erik Nordmark, George Swallow, Rudy
Watteyne, Shitanshu Shah, Craig Gunther, Rodney Cummings, Wilfried Klecka, Anca Zamfir, David Black, Thomas Watteyne, Shitanshu Shah,
Steiner, Marcel Kiessling, Karl Weber, Ethan Grossman, Patrick Kiran Makhijani, Craig Gunther, Rodney Cummings, Wilfried Steiner,
Wetterwald, Subha Dhesikan, Rudy Klecka and Pat Thaler for their Marcel Kiessling, Karl Weber, Ethan Grossman, Patrick Wetterwald,
various contribution to this work. Subha Dhesikan, Rudy Klecka and Pat Thaler 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 9, line 41 skipping to change at page 9, line 46
<http://www.odva.org/Portals/0/Library/ <http://www.odva.org/Portals/0/Library/
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-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-14 (work in progress), February ietf-detnet-use-cases-16 (work in progress), May 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. 12 change blocks. 
25 lines changed or deleted 30 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/