Subject: Re: [Detnet] New Proposed Charter

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 May 2015 10:03:03 +0000

Hello Ethan:

Please see below:
 
> Nice to see y'all at the TSNA conference. Here are a couple of minor
> comment/questions on the charter below.
> 
> In the descriptions below the requirement phrasing is something like "extremely
> low packet loss rates, guaranteed finite latency, and low jitter". There is no
> mention of guaranteed/reserved bandwidth. Should that be in there or is it
> implied by the above items?

Let me add this.

> 
> Similarly, although I understand that we are leaving timing to others, it seems
> like a key part of determinism is timing, so maybe some kind of reference to
> timing requirements belongs in this statement, even if accompanied by our
> disclaimer saying that we're leaving that topic to others?
 
There was a lot of clean up since the earlier charter, a lot about removing information that did not effectively point on work to be done at the IETF.
Certainly time will flow in the path setup, but mentioning it there may lead people into thinking that we need more work at the IETF that we can effectively achieve.
The current text is good at focusing on the tasks to be done here, and I would not add to it. But others might think otherwise? 

> Also I had previously understood that we were initially stating requirements to
> IETF and not proposing a specific solution or architecture, yet it sounds from
> below like we are very much tied to AVB/TSN. Is that a given now, or do we
> need to dial that back?

Could you please rephrase? My French sees its limits here; what I can communicate is that the IETF will not form a group to spend 2 years delivering requirements.
The requirements are useful for our public perception, but we all know we need this stuff, and we must start doing it so as to produce implementable specs within 2-3 years.
The deliverables derive from that line of thought. And yes, we want to inherit the model of queues, buffers, precise timing,  and central controller from the IEEE TSN work.

> Minor fussy item: There are two similar but slightly different phrases: "extremely
> low packet loss rates, guaranteed finite latency, and low jitter" and "bounded
> latency, very low loss, and a very narrow jitter". My sense is that the distinctions
> made between them are not meaningful but cause one to have to think about
> whether they are, so I would suggest we make them identical?

I'll avoid repeating.

Please see below or at https://bitbucket.org/detnet/docs/src/6c8cc07b4007a94f5de2860dd32a2cb3b2311df2/detnet%20charter.txt?at=master :

------------ 

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., continuous 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 Information Technology/Information and Communications Technology (IT/ICT), focusing on highly secure, reliable and deterministic networks, with limited scalability over a bounded area. 

In OT environments, deterministic networks are characterized as providing a guaranteed bandwidth with extremely low packet loss rates, bounded latency, and low jitter.

In parallel, the need for determinism in professional and home audio/video markets drove the formation of the Audio/Video Bridging (AVB) standards efforts in IEEE 802.1. With the demand for connectivity and multimedia in transportation, AVB is being evaluated for application in vehicle head units, rear seat entertainment modules, amplifiers, camera modules, and engine control systems. Automotive AVB networks share the OT requirements for deterministic networks characteristics.

This wider application scope for deterministic networks has led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive Networking (TSN) Task Group (TG), covering industrial and vehicular applications. The networks in consideration are extending beyond the LAN boundaries and require secure deterministic forwarding and connectivity over a Layer 2/Layer 3 network. The properties of deterministic networks will have specific requirements for the use of  routed networks to support these applications.

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

The deterministic networking Working Group (detnet) will focus on the establishment and maintenance of deterministic paths over Layer-2 Bridged and Layer-3 routed segments. The Working Group will focus on Layer 3 aspects in support of deterministic applications.  The group will collaborate with IEEE802.1TSN, which is responsible for Layer-2 operations, to define a common architecture to support IEEE802.1TSN applications. For the common architecture, a number of elements such as the IEEE802.1TSN host operation should be agnostic to the choice of network used for the connectivity. 

The Working Group will specify an overall architecture that encompasses the data plane, OAM, management, control, and security aspects that are required to enable a multi-hop path, and forwarding along that path, with the deterministic properties of controlled latency, low packet loss, ultra-low jitter, and high reliability. The work will apply 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 encapsulation of frames, 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 considerations such as transport protocols. Candidate Layer 3 data plane technologies include: IPv4, IPv6, MPLS. This work focuses on the data plane and does not depend on the path setup protocol that will be used. The data plane will be compatible with the work done in IEEE801.1TSN.

The WG will coordinate with other relevant IETF Working Groups, including CCAMP, PCE, PALS, TEAS, TSVWG, and 6TisSCH. As the work progresses, requirements may be provided to the responsible Working Group, e.g. PCE, TEAS, and CCAMP, with detnet acting as a focal point to maintain the consistency of the overall architecture. The WG will liaise with appropriate groups in IEEE.

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

- Deliverables:

  * Problem statement: This document will identify the deployment environment and deterministic network requirements which need to be supported.

  * Overall architecture: This document encompasses the data plane, OAM, management, control, and security aspects.

  * Data plane specification: Document a data plane method of flow identification and packet forwarding over Layer 3. 
  
  * Data flow information model: This document will be for use by a flow reservation protocol or by YANG data models. The model should be independent from the protocol(s) used to control the flows (e.g. PCEP or GMPLS).
  
  * Identification of additional YANG augmentations: This document will cover device and link capabilities (feature support) and resources (e.g. buffers, bandwidth) for use in device configuration and status reporting. Such information may also be used when advertising the deterministic network elements to a control plane. The model should be independent from the protocol(s) that may be used to advertise this information (e.g. ISIS or GMPLS extensions).This deliverable will be coordinated with the working groups that define the base models.

What do you think?

Pascal

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 12 May 2015 18:13:53 +0000

Thanks Pascal, you have addressed my concerns. 
Best,
Ethan.

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Tuesday, May 12, 2015 3:03 AM
To: Grossman, Ethan A.; [email-masked]
Subject: RE: New Proposed Charter

Hello Ethan:

Please see below:
 
> In the descriptions below the requirement phrasing is something like 
> "extremely low packet loss rates, guaranteed finite latency, and low 
> jitter". There is no mention of guaranteed/reserved bandwidth. Should 
> that be in there or is it implied by the above items?

Let me add this.

> 
> Similarly, although I understand that we are leaving timing to others, 
> it seems like a key part of determinism is timing, so maybe some kind 
> of reference to timing requirements belongs in this statement, even if 
> accompanied by our disclaimer saying that we're leaving that topic to others?

> Also I had previously understood that we were initially stating 
> requirements to IETF and not proposing a specific solution or 
> architecture, yet it sounds from below like we are very much tied to 
> AVB/TSN. Is that a given now, or do we need to dial that back?

> Minor fussy item: There are two similar but slightly different 
> phrases: "extremely low packet loss rates, guaranteed finite latency, 
> and low jitter" and "bounded latency, very low loss, and a very narrow 
> jitter". My sense is that the distinctions made between them are not 
> meaningful but cause one to have to think about whether they are, so I would suggest we make them identical?

I'll avoid repeating.

------------ 

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

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

- Deliverables:

  

What do you think?

Pascal