--- 1/draft-ietf-detnet-problem-statement-04.txt 2018-06-22 03:13:08.731042781 -0700 +++ 2/draft-ietf-detnet-problem-statement-05.txt 2018-06-22 03:13:08.759043455 -0700 @@ -1,42 +1,42 @@ detnet N. Finn Internet-Draft Huawei Technologies Co. Ltd Intended status: Informational P. Thubert -Expires: December 8, 2018 Cisco - June 6, 2018 +Expires: December 24, 2018 Cisco + June 22, 2018 Deterministic Networking Problem Statement - draft-ietf-detnet-problem-statement-04 + draft-ietf-detnet-problem-statement-05 Abstract 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 December 8, 2018. + This Internet-Draft will expire on December 24, 2018. 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 @@ -111,52 +111,53 @@ flows. 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 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 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, duplication 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. + 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 declassification and drop. 2. On Deterministic Networking The Internet is not the only digital network that has grown dramatically over the last 30-40 years. Video and audio entertainment, and control systems for machinery, manufacturing processes, and vehicles are also ubiquitous, and are now based almost entirely on digital technologies. Over the past 10 years, engineers in these fields have come to realize that significant advantages in both cost and in the ability to accelerate growth can be obtained by 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. + The goals of Deterministic Networking (DetNet) 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. 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: 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. @@ -261,36 +262,36 @@ 3.2. Flow Characterization Deterministic forwarding can only apply on flows with well-defined characteristics such as periodicity and burstiness. Before a path can be established to serve them, the expression of those characteristics, and how the network can serve them, for instance in shaping and forwarding operations, must be specified. 3.3. Centralized Path Computation and Installation - A centralized routing model, such as provided with a PCE, enables - global and per-flow optimizations. The model is attractive but a - number of issues are left to be solved. In particular: + A centralized routing model, such as provided with a Path Computation + Element (PCE) (see [RFC4655]), enables global and per-flow + optimizations. The model is attractive but a number of issues are + left to be solved. In particular: o whether and how the path computation can be installed by 1) an end device or 2) a Network Management entity, o and how the path is set up, either by installing state at each hop with a direct interaction between the forwarding device and the PCE, or along a path by injecting a source-routed request at one end of the path following classical Traffic Engineering (TE) models. - To enable a centralized model, DetNet should produce the complete SDN - architecture with describes at a high level the interaction and data - models to: + To enable a centralized model, DetNet should produce a description of + the high level interaction and data models to: o report the topology and device capabilities to the central controller; o establish a direct interface between the centralized PCE to each device under its control in order to enable a vertical signaling o request a path setup for a new flow with particular characteristics over the service interface and control it through its life cycle; @@ -316,34 +317,35 @@ 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 take place: 1. Neighbors and their capabilities are discovered and exposed to compute a path that fits the DetNet constraints, typically of latency, time precision and resource availability. - 2. A constrained path is calculated with an improved version of CSPF - that is aware of DetNet. + 2. A constrained path is calculated with an improved version of + Constrained Shortest Path First (CSPF) that is aware of DetNet. 3. The path may be installed using a control protocol such as RSVP- TE, associated with flow identification, per-hop behavior such as 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. + timing information. In that case, traffic flows can be + transported through an MPLS-TE tunnel, using the reserved + resources for this flow at each hop. - 4. Traffic flows are transported through the MPLS-TE tunnel, using - the reserved resources for this flow at each hop. + 4. Alternatively, the routing and flow information may be placed in- + band in the IP packet, e.g., using Segment Routing and/or IPv6 + Routing and Option Headers, in which case the packet is routed + along a prescribed source route path following forwarding + indications that are present in the packet. 3.5. Duplicated data format In some cases the duplication and elimination of packets over non- congruent paths is required to achieve a sufficiently high delivery ratio to meet application needs. In these cases, a small number of packet formats and supporting protocols are required (preferably, just one) to serialize the packets of a DetNet stream at one point in the network, replicate them at one or more points in the network, and discard duplicates at one or more other points in the network, @@ -373,20 +375,22 @@ associated with a given flow at a given point of time. In that model, Time Sharing of physical resources becomes transparent to the individual flows which have no clue whether the resources are used by other flows at other times. The overall security of a deterministic system must cover: o the protection of the signaling protocol o the authentication and authorization of the controlling nodes + including plug-and-play participating end systems. + o the identification and shaping of the flows o the isolation of flows from leakage and other influences from any activity sharing physical resources. 5. IANA Considerations This document does not require an action from IANA. 6. Acknowledgments @@ -453,20 +457,25 @@ [Profinet] http://us.profinet.com/technology/profinet/, "PROFINET is a standard for industrial networking in automation.", . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . + [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation + Element (PCE)-Based Architecture", RFC 4655, + DOI 10.17487/RFC4655, August 2006, + . + [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, . [WirelessHART] www.hartcomm.org, "Industrial Communication Networks - Wireless Communication Network and Communication Profiles - WirelessHART - IEC 62591", 2010. Authors' Addresses