[Detnet] DetNet tentative charter

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear all:

DetNet met at the last 3 IETFs, first as an informal session, then as a non-WG-forming BoF, and then as guests to 6TiSCH and PCE. We had numerous corridor meetings in Dallas. Sadly, we could not talk at CCAMP and TEAS due to agenda collisions.

In all these fora and the DetNet ML, we had extensive discussions on the work that needs to be done and a potential charter. We found that:
- DetNet is an explicit requirement for 6TiSCH, but 6TiSCH is not ready to take that work in:
https://tools.ietf.org/html/draft-ietf-6tisch-architecture
https://tools.ietf.org/html/draft-wang-6tisch-track-use-cases

- There is a gap between what exist groups provide and what's needed as detailed in the charter. We started a gap analysis, and really need some work there:
https://tools.ietf.org/html/draft-dujovne-detnet-gap-analysis

And we have authored a number of drafts which cover the first items listed therein, some of them in great shape already:
https://tools.ietf.org/html/draft-finn-detnet-architecture
https://tools.ietf.org/html/draft-finn-detnet-problem-statement
https://tools.ietf.org/html/draft-gunther-detnet-proaudio-req
https://tools.ietf.org/html/draft-wetterwald-detnet-utilities-reqs
Note: we are missing industrial automation requirements though we have https://tools.ietf.org/html/draft-wang-6tisch-track-use-cases and http://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability with relevant information

I'd wish to use this thread to complete the work on the charter, and will start a different thread on what still needs to be done to ask for a WG forming BoF in Prague.

Please have a close look at the text below, which is the state at which we left the charter discussion earlier. Comments welcome!


detnet: "deterministic networking"

Background on deterministic networking
--------------------------------------

Operational Technology (OT) refers to industrial networks that are typically used for monitoring systems and supporting control loops, as well as movement detection systems for use in process control (i.e., process manufacturing) and factory automation (i.e., discrete manufacturing). Due to its different goals, OT has evolved in parallel but in a manner that is radically different from IT/ICT, focusing on highly secure, reliable and deterministic networks, with limited scalability over a bounded area.

The convergence of IT and OT technologies, also called the Industrial Internet, represents a major evolution for both sides. The work has already started; in particular, the industrial automation space has been developing a number of Ethernet-based replacements for existing digital control systems, often not packet-based (fieldbus technologies). These replacements are meant to provide similar behavior as the incumbent protocols, and their common focus is to transport a fully characterized flow over a well-controlled environment (i.e., a factory floor), with a bounded latency, extraordinarily low frame loss, and a very narrow jitter. Examples of such protocols include PROFINET, ODVA Ethernet/IP, and EtherCAT.

In parallel, the need for determinism in professional and home audio/video markets drove the formation of the Audio/Video Bridging (AVB) standards efforts of IEEE 802.1. With the explosion of demand for connectivity and multimedia in transportation in general, AVB has also become one of the hottest topics in the automotive industry, finding current application in vehicle head units, rear seat entertainment modules, amplifiers, and camera modules, with engine control systems to follow soon. Thus automotive AVB networks share the requirement for extremely low packet loss rates, guaranteed finite latency, and low jitter.

Other instances of in-vehicle deterministic networks have arisen as well for control networks in cars, trains and buses, as well as avionics, with, for instance, the mission-critical Avionics Full-Duplex Switched Ethernet (AFDX) that was designed as part of the ARINC 664 standards. Existing automotive control networks such as the LIN, CAN and FlexRay standards were not designed to cover these increasing demands in terms of bandwidth and scalability that we see with various kinds of Driver Assistance Systems (DAS) and new multiplexing technologies based on Ethernet are now getting traction.

The generalization of the needs for more deterministic networks have led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive Networking (TSN) Task Group (TG), with a much-expanded constituency from the industrial and vehicular markets. Along with this expansion, the networks in consideration are becoming larger and structured, requiring deterministic forwarding beyond the LAN boundaries. For instance, Industrial Automation segregates the network along the broad lines of the Purdue Enterprise Reference Architecture (PERA), using different technologies at each level, and public infrastructures such as Electricity Automation require deterministic properties over the Wide Area. The realization is now coming that the convergence of IT and OT networks requires Layer-3, as well as Layer-2, capabilities.

In order to serve this extended requirement, the IETF and the IEEE must collaborate and define an abstract model that can be applicable both at Layer-2 and Layer-3, and along segments of different technologies. With this new work, a path may span, for instance, across a (limited) number of 802.1 bridges and then a (limited) number of IP routers. In that example, the IEEE802.1 bridges may be operating at Layer-2 over Ethernet whereas the IP routers may be 6TiSCH nodes operating at Layer-2 and/or Layer-3 over the IEEE802.15.4e MAC. The proposed model should enable a fully scheduled operation orchestrated by a central controller, as well as 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.

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 such as TEAS, CCAMP, PCE, MPLS and 6TiSCH, 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 precise timing and 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. 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, and an existing path may be moved or removed.


WG description
--------------

The deterministic networking Working Group (detnet) will focus on the establishment and maintenance of multi-hop paths over Layer-2 Bridged and Layer-3 routed segments. Though only Layer-3 operations will be specified by the WG as Standard Track documents, the group will collaborate with IEEE802.1TSN, which designs the Layer-2 operations, to define a common paradigm, leveraging cross-participation and liaison work to maintain consistency. In that common paradigm, a number of elements such as the host operation should be agnostic to the organization of the multi-hop path.

The Working Group will initially consider a centralized model where the control and data planes are decoupled, and refer to the general Software Defined Networking (SDN) model of an application layer, a control layer, and a network infrastructure layer, separated by APIs. DetNet will propose standards for the network infrastructure and its APIs, only. The considered network will initially be of a moderate size, composed of mixed Layer-2 / Layer-3 sub-networks of IEEE802.1 bridges, routers, and hosts. A single administrative domain such as a campus, a Small/Home office Network, or a controlled Wide Area Network will be assumed to start with, and approaches that can be applied to the Internet at large will be favored.

The Working Group will initially specify the protocol elements that are required to enable an multi-hop path, and forward along that path with the deterministic properties of controlled latency, low packet loss, ultra-low jitter, and high reliability. The work will apply to and only to flows that can be characterized in a manner that allows the network to 1) reserve the appropriate resources for the flows in advance, and 2) release/reuse the resources when they are no more required. The work will cover the characterization of flows, the tagging of packets, the required forwarding behaviors, as well as the state that may need to be established in intermediate nodes; it will not include end-to-end consideration such as transport protocols. This work focuses on flows and does not depend on the path setup protocol that will be selected. The data models and flow tagging should be compatible with the similar work done at IEEE801.1TSN so they could be either directly usable at both layers, or mappable in an unambiguous fashion.

The WG will interface with other appropriate groups in the IETF in the Internet (e.g. 6TiSCH), Transport (e.g. TSVWG), Operations and Management, Routing and Security areas. As the work progresses, work items would be suggested to PCE, TEAS, and CCAMP, and some of the items initially considered in detnet may be transferred to those working groups as deemed appropriate by all parties, with detnet acting as a focal point to maintain the consistency of the overall architecture.


Work Items
----------

- Deliverables:

  * An analysis of the needs in various deployment environments. 3-4 informational track requirement documents which could include factory automation, grid automation, avionics and audio/video in professional studios and/or automotive applications.

  * A generic problem statement including an analysis of the proposed solutions of the related work at IEEE802.1TSN.

  * An architecture detailing the preferred approach and its interaction with the related work at IEEE802.1TSN.

  * A standards track data flow characterization model document for use in flow reservation protocol. The model should be independent from the protocol(s) used to deploy the flows (e.g. an evolution of PCEP or CCAMP).

  * A standards track data model document describing device and links capabilities (feature support) and resources (buffers, bandwidth...) for use in advertising the deterministic network elements to the controller plane. The model should be independent from the protocol(s) that are used to notify the controller (e.g. ISIS or TEAS extensions).

  * A standards track flow identification document for use in packet forwarding, with the specific application to at least classical IP, 6TiSCH track forwarding, and MPLS.

  * A standards track data model for the abstract state to be installed in the forwarding device and the associated packet forwarding behavior.

  Based on that work, DetNet will study the gap between the needs in those models and the protocol elements that are available at the IETF, and suggest further work for extensions where needed.




Cheers,

Pascal