Subject: Re: [Detnet] new proposed charter

From: "Maik Seewald (maseewal)" <[email-masked]>
Date: Mon, 4 May 2015 05:59:31 +0000

Patrick, one comment regarding the background. In case you are planning to
cover the utility/power system domain within the OT space as well, I
propose to add the use case and terminus ³protection".
Within this domain, we typically talk about monitoring, protection, and
control as 3 core use cases with different objectives and requirements.
Thanks.
Mike

On 30.04.15 23:59, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

>Dear all:
>
>After discussion with some of the ADs (huge, huge thanks there!) and
>among yourselves, you have shortened the proposed charter to be more
>scoped and focused to achievable deliverables.
>We now have a clear line of work in front of us. The only thing that can
>really block this work at this point is the lack of visible activity.
>Please remember, participation to the IETF work is free and personal.
>We do need you guys to chime in, whether it is to comment and improve the
>text, or simply express support that the work needs to happen and that
>you are willing to contribute.
>
>The proposed new text reads as follows:
>
>"
>
>
>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 Information
>Technology/Information and Communications Technology (IT/ICT), focusing
>on highly secure, reliable and deterministic networks, with limited
>scalability over a bounded area. Deterministic networks are characterized
>as having a bounded latency, very low loss, and a very narrow 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 extremely low packet loss rates, guaranteed finite
>latency, and low jitter.
>
>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 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 p
> lane 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 and other Standards Development Organizations
>(SDOs).
>
>
>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.
>"
>
>Cheers,
>
>Pascal and Jouni
>
>_______________________________________________
>detnet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/detnet

---

From: "Sexton, Daniel W (GE Global Research)" <[email-masked]>
Date: Mon, 4 May 2015 12:52:45 +0000

Pascal,
One of the techniques currently used in OT is to physically isolate the critical networks such that they can provide deterministic behavior there are a few exceptions to this where either proprietary techniques or techniques outside of the domain of IEEE802.1 have been implemented to achieve deterministic behaviors  to coexist with non-deterministic traffic. In my mind, IEEE802.1 is dealing with the L2 aspects of determinism in a network of mixed traffic types where as DETNET must deal with the that deterministic traffic in the wild. Security then becomes an over-riding concern, where physical network isolation provided a layer of defense, that will no longer be the case one we cross the boundary to L3. In your third paragraph I would place more emphasis on this point by simply adding the words physical and secure to the following sentence: "The networks in consideration are extending beyond the physical LAN boundaries and require secure deterministic forwarding and connectivity over a Layer 2/Layer 3 network."

Daniel Sexton
GE Global Research
One Research Circle
Niskayuna, NY
12309
O: 518-387-4121
M:518-424-5728
DC:*833-4121

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, April 30, 2015 6:00 PM
To: [email-masked]
Subject: [Detnet] new proposed charter

Dear all:

After discussion with some of the ADs (huge, huge thanks there!) and among yourselves, you have shortened the proposed charter to be more scoped and focused to achievable deliverables. 
We now have a clear line of work in front of us. The only thing that can really block this work at this point is the lack of visible activity. Please remember, participation to the IETF work is free and personal.
We do need you guys to chime in, whether it is to comment and improve the text, or simply express support that the work needs to happen and that you are willing to contribute. 

"

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 Information Technology/Information and Communications Technology (IT/ICT), focusing on highly secure, reliable and deterministic networks, with limited scalability over a bounded area. Deterministic networks are characterized as having a bounded latency, very low loss, and a very narrow 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 extremely low packet loss rates, guaranteed finite latency, and low jitter.

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 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 p  lane 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 and other Standards Development Organizations (SDOs).

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.
"

Cheers,

Pascal and Jouni

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 May 2015 15:06:02 +0000

Dear all:

I incorporated Dan's comment about security (thanks Dan!) :

Also I talked with our A-Ds and understand that the problem statement is our first deliverable and it should be out quickly. 

We are still welcome to make that more than one doc, e.g. turn the requirement drafts in RFCs as initially intended, but that should not delay the completion of that task. 

An alternate is for requirement drafts is to turn them in applicability statements. There is not a huge gap between the two, and it would probably be more useful if we consider the overall production of our group.

Charter is now:

"

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 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:

  

Cheers,

Pascal and Jouni

---

From: "Patrick Wetterwald (pwetterw)" <[email-masked]>
Date: Thu, 21 May 2015 14:25:51 +0000

Pascal,

I think it may be good to add a small sentence after the first paragraph
on smart grid. This market will use this technology as well. Here is my
proposal for the sentence:

"In the same way, Industry related to the production, the transport and
the distribution of the electricity (Smart Grid) shares the same
requirements for deterministic networking.²

Last question is the transportation market (planes, spacecrafts, trains)
included in the second paragraph (AVB) or do we want to be more specific?

Thanks,

Patrick

On 04/05/15 17:06, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

>Also I talked with our A-Ds and understand that the problem statement is
>our first deliverable and it should be out quickly.
>
>We are still welcome to make that more than one doc, e.g. turn the
>requirement drafts in RFCs as initially intended, but that should not
>delay the completion of that task.
>
>An alternate is for requirement drafts is to turn them in applicability
>statements. There is not a huge gap between the two, and it would
>probably be more useful if we consider the overall production of our
>group.
>
>Charter is now:
>
>"
>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 data plane will be compatible with the work done in IEEE801.1TSN.
>
>appropriate groups in IEEE.
>
>
>Work Items     
>----------
>
>- Deliverables:
>   
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 May 2015 15:42:02 +0000

Hello Patrick,

Could you please be more specific about " shares the same requirements for deterministic networking." ? 
I's like to see what is at stake if deterministic guarantees are not ensured, e.g. damage on property, black out, things like that?

There are at least 3 networks in a planes, and at least 2 of them need deterministic.
But then we cannot write a book in the charter so maybe we can keep it at that : )

What do others think?

Pascal

> From: Patrick Wetterwald (pwetterw)
> Sent: jeudi 21 mai 2015 16:26
> To: Pascal Thubert (pthubert); Sexton, Daniel W (GE Global Research);
> [email-masked]
> Subject: Re: [Detnet] FW: new proposed charter
> 
> Pascal,
> 
> I think it may be good to add a small sentence after the first paragraph on smart
> grid. This market will use this technology as well. Here is my proposal for the
> sentence:
> 
> "In the same way, Industry related to the production, the transport and the
> distribution of the electricity (Smart Grid) shares the same requirements for
> deterministic networking.²
> 
> 
> Last question is the transportation market (planes, spacecrafts, trains) included
> in the second paragraph (AVB) or do we want to be more specific?
> 
> Thanks,
> 
> Patrick
> 
> 
> 
> >Also I talked with our A-Ds and understand that the problem statement
> >is our first deliverable and it should be out quickly.
> >
> >scalability over a bounded area. Deterministic networks are
> >characterized as having a bounded latency, very low loss, and a very narrow
> jitter.
> >
> >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 extremely low packet loss rates,
> >guaranteed finite latency, and low jitter.
> >
> >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
> >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 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:
> >
> >
> >  * Overall architecture: This document encompasses the data plane,
> >OAM, management, control, and security aspects.
> >
> >  * 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).
> >
> >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.
> >"
> >
> >
> >Cheers,
> >
> >Pascal and Jouni
> >

---

From: "Maik Seewald (maseewal)" <[email-masked]>
Date: Thu, 21 May 2015 15:48:15 +0000

Pascal, let me chime in here:
The key use cases in power automation where determinism is needed is
protection. Protection is a complete domain within power automation.
These functions are key to protect primary equipment (transformer, lines)
and people from (physical) damage.
Cheers. Mike

On 21.05.15 17:42, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

>I's like to see what is at stake if deterministic guarantees are not
>ensured, e.g. damage on property, black out, things like that?
>
>>the