--- 1/draft-ietf-detnet-problem-statement-07.txt 2018-12-06 03:13:36.619885147 -0800 +++ 2/draft-ietf-detnet-problem-statement-08.txt 2018-12-06 03:13:36.651885915 -0800 @@ -1,19 +1,19 @@ DetNet N. Finn Internet-Draft Huawei Technologies Co. Ltd Intended status: Informational P. Thubert -Expires: April 6, 2019 Cisco - October 3, 2018 +Expires: June 9, 2019 Cisco + December 6, 2018 Deterministic Networking Problem Statement - draft-ietf-detnet-problem-statement-07 + draft-ietf-detnet-problem-statement-08 Abstract This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -81,54 +81,55 @@ LAN boundaries. For instance, IACS segregates the network along the broad lines of the Purdue Enterprise Reference Architecture (PERA) [ISA95], typically using deterministic local area networks for level 2 control systems, whereas public infrastructures such as Electricity Automation require deterministic properties over the Wide Area. The realization is now coming that the convergence of IT and Operational Technology (OT) networks requires Layer-3, as well as Layer-2, capabilities. While the initial user base has focused almost entirely on Ethernet - physical media and Ethernet-based bridging protocol (from several - Standards Development Organizations), the need for Layer-3 expressed - above, must not be confined to Ethernet and Ethernet-like media, and - while such media must be encompassed by any useful Deterministic + physical media and Ethernet-based bridging protocol from several + Standards Development Organizations, the need for Layer-3 expressed + above, must not be confined to Ethernet and Ethernet-like media. + While such media must be encompassed by any useful Deterministic Networking (DetNet) Architecture, cooperation between IETF and other 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 particular, provide an obvious starting point for a DetNet architecture, we must not assume that these other SDOs' work confines the space in which the DetNet architecture progresses. The properties of deterministic networks will have specific requirements for the use of routed networks to support these applications and a new model must be proposed to integrate determinism in IT technology. The proposed model should enable a fully scheduled operation orchestrated by a central controller, and may support a more distributed operation with probably lesser capabilities. In any fashion, the model should not compromise the ability of a network to keep carrying the sorts of traffic that is already carried today in conjunction with new, more deterministic flows. Forward note: The DetNet Architecture [I-D.ietf-detnet-architecture] is the document produced by the DetNet WG to describe that model. - Once the abstract model is agreed upon, the IETF will need to specify - the signaling elements to be used to establish a path and the tagging - elements to be used identify the flows that are to be forwarded along - that path. The IETF will also need to specify the necessary + At the time of this writing, the expectation is that once the + abstract model is agreed upon, the IETF will specify the signaling + elements to be used to establish a path and the tagging elements to + 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 technologies, to implement the selected model. - As a result of this work, it will be possible to establish a multi- - hop path over the IP or MPLS network, for a particular flow with - given timing and precise throughput requirements, and carry this + A desirable outcome of the work is the capability to establish a + multi-hop path over the IP or MPLS network, for a particular flow + with given timing and precise throughput requirements, and carry this particular flow along the multi-hop path with such characteristics as low latency and ultra-low jitter, reordering and/or replication and elimination of packets over non-congruent paths for a higher delivery ratio, and/or zero congestion loss, regardless of the amount of other flows in the network. Depending on the network capabilities and on the current state, 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 removed, and DetNet flows exceeding their contract may face packet @@ -146,28 +147,28 @@ basing all of these disparate digital technologies on packet networks. The goals of Deterministic Networking are to enable the migration of applications with critical timing and reliability issues that currently use special-purpose fieldbus technologies (HDMI, CANbus, ProfiBus, etc... even RS-232!) to packet technologies in general, and the Internet Protocol in particular, and to support both these new applications, and existing packet network applications, over the same 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 deterministic flows. - Considerable experience ([ODVA]/[EIP],[AVnu], - [Profinet],[HART],[IEC62439], [ISA100.11a] and [WirelessHART], - etc...) has shown that these applications need a some or all of a - suite of features that includes: + Considerable experience from automation and professional audio/video + networks (e.g., [ODVA]/[EIP], [AVnu], [Profinet], [HART], [IEC62439], + [ISA100.11a] and [WirelessHART]) has shown that these applications + need a some or all of a suite of features that includes: 1. Time synchronization of all host and network nodes (routers and/ or bridges), accurate to something between 10 nanoseconds and 10 microseconds, depending on the application. 2. Support for Deterministic packet flows that: * Can be unicast or multicast; * Need absolute guarantees of minimum and maximum latency end- @@ -250,23 +251,23 @@ 3.1. Supported topologies In some use cases, the end point which run the application is involved in the deterministic networking operation, for instance by controlling certain aspects of its throughput such as rate or precise time of emission. In that case, the deterministic path is end-to-end from application host to application host. 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 - end-to-end of a tunnel. + end-to-end or a tunnel. While it is clear that DetNet does not aim at setting up deterministic paths over the global Internet, there is still a lack 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 set the path up, whether it is centralized or distributed. 3.2. Flow Characterization Deterministic forwarding can only apply on flows with well-defined @@ -306,23 +307,27 @@ o support for life cycle management for a path (instantiate/modify/update/delete) o support for adaptability to cope with various events such as loss of a link, etc... o expose the status of the path to the end devices (UNI interface) 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 Whether a distributed alternative without a PCE can be valuable could be studied as well. Such an alternative could for instance inherit from the Resource ReSerVation Protocol [RFC3209] (RSVP-TE) flows. But the focus of the work should be to deliver the centralized approach first. To enable a RSVP-TE like functionality, the following steps would @@ -392,27 +397,28 @@ The specific threats against DetNet are further discussed in the DetNet Security Considerations [I-D.ietf-detnet-security] document. 5. IANA Considerations This document does not require an action from IANA. 6. Acknowledgments - The authors wish to thank Lou Berger, Stewart Bryant, Janos Farkas, - Andrew Malis, Jouni Korhonen, Erik Nordmark, George Swallow, Lou - Berger, Ines Robles, Shwetha Bhandari, Rudy Klecka, Anca Zamfir, - David Black, Thomas Watteyne, Shitanshu Shah, Kiran Makhijani, Craig - Gunther, Rodney Cummings, Wilfried Steiner, Marcel Kiessling, Karl - Weber, Ethan Grossman, Patrick Wetterwald, Subha Dhesikan, Rudy - Klecka and Pat Thaler for their various contributions to this work. + The authors wish to thank Lou Berger, Pat Thaler, Jouni Korhonen, + Janos Farkas, Stewart Bryant, Andrew Malis, Ethan Grossman, Patrick + Wetterwald, Subha Dhesikan, Matthew Miller, Erik Nordmark, George + Swallow, Rodney Cummings, Ines Robles, Shwetha Bhandari, Rudy Klecka, + Anca Zamfir, David Black, Thomas Watteyne, Shitanshu Shah, Kiran + Makhijani, Craig Gunther, Warren Kumari, Wilfried Steiner, Marcel + Kiessling, Karl Weber, Alissa Cooper, and Benjamin Kaduk for their + various contributions to this work. 7. Informative References [AVnu] http://www.avnu.org/, "The AVnu Alliance tests and certifies devices for interoperability, providing a simple and reliable networking solution for AV network implementation based on the IEEE Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN) standards.". [EIP] http://www.odva.org/, "EtherNet/IP provides users with the @@ -424,32 +430,31 @@ Publications_Numbered/ PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf>. [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, a group of specifications for industrial process and control devices administered by the HART Foundation". [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "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] Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, J., Austad, H., Stanton, K., and N. Finn, "Deterministic 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] Grossman, E., "Deterministic Networking Use Cases", draft- - ietf-detnet-use-cases-18 (work in progress), September - 2018. + ietf-detnet-use-cases-19 (work in progress), October 2018. [IEC62439] IEC, "Industrial communication networks - High availability automation networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR) - IEC62439-3", 2012, . [IEEE802.1TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive