Subject: [Detnet] Benoit Claise's Block on charter-ietf-detnet-00-00: (with BLOCK)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 03 Sep 2015 08:01:13 -0700

Benoit Claise has entered the following ballot position for
charter-ietf-detnet-00-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-detnet/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

- There is a tendency in our industry to capitalize word, and to overuse
acronyms:
    - Layer 2 Bridged and Layer 3
    - TSN
    - OAM

- I find the structure not ideal.
    Part 1 should express the motivation and high level intend
    Part 2, more details
    Part 3, out of scope, if any
    Part 4, deliverables
    Part 5, coordination

For example, the architecture is mentioned in multiple place

- "Identification of additional YANG augmentations:"
What does it mean? new YANG models, fine? This could be understood as
YANG language augmentations, which is a different story.

- "Any YANG work will be   coordinated with the working groups that
define the base models."
What are those base models?

- "The work will be   independent from the protocol(s) that may be used
to advertise this   information (e.g. IS-IS or GMPLS extensions)." Well,
you are in the YANG section, and YANG is bound to NETCONF/RESCONF.
"independent from the protocol(s) is for the information model
 
I have no objection to the work itself, but I believe that the charter
text should be improved. I started with a list of improvements, and in
the end, I started editing. There are still improvements to be made. I
guess that makes it a BLOCK. An 1:1 with Deborah should be the next
step.

===========================

The Deterministic Networking (DetNet) Working Group focuses on
deterministic data paths that operate over layer 2 bridged and layer 3
routed segments, where such paths can provide bounded latency, loss, and
packet delay variation (jitter). 

EXPLAIN IN ONE SENTENCE OR TWO THE MOTIVATION
Various industries, for example, professional audio, electrical 
utilities, building automation systems, wireless for industrial 
applications require this capability because...

The Working Group will collaborate with IEEE802.1 Time-Sensitive
Networking (TSN), 
which is responsible for layer 2 operations, to define a common
architecture 
for both layer 2 and layer 3. For this common architecture, a number of
elements 
such as the IEEE802.1 TSN host operation should be agnostic to the choice
of 
network used for the connectivity.

The work applies 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 longer required.  
The work covers 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.

Out of scope is the end-to-end considerations such the transport
protocols,
modification of Operations, Administration, and Maintenance (OAM), L3
forwarding 
and encapsulations, or control plane protocols. 

DetNet is chartered to work in the following areas:

 * Problem statement and requirements: These documents will not
necessarily 
   be published, but may be maintained in a draft form or on a
collaborative 
   Working Group wiki to support the efforts of the Working Group and
help new comers. 

 * An architecture that encompasses the data plane, OAM, management,
control, 
   and security aspects required to enable a multi-hop path, and
forwarding 
   along that path, with the deterministic properties of controlled
latency, 
   low packet loss, low packet delay variation, and high reliability. 
   As part of the overall architecture work, the working group will
document 
   which deployment environments and types of topologies that are within

   (or outside) the scope of the DetNet architecture.  

 * Data plane: This work will document a data plane method of flow
   identification and packet forwarding over Layer 3. Candidate Layer 3
data 
   plane technologies that may be used, without modification, include:
IPv4, 
   IPv6, MPLS. The data plane, which must be compatible with the work in

   IEEE802.1 TSN, is independent from any path setup protocol or
   mechanism. 

 * Data flow information model: This work will identify the information
   needed for flow establishment and control and be used by a
   reservation protocol or by YANG data models. The work will be
   independent from the protocol(s) used to control the flows
   (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS).

 * Identification of additional YANG augmentations: This work will
   document 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 work will be
   independent from the protocol(s) that may be used to advertise this
   information (e.g. IS-IS or GMPLS extensions). Any YANG work will be
   coordinated with the working groups that define the base models.
   THIS SECTION NEEDS CLARFIFICATION, BUT I NEED TO SPEAK TO DEBORAH
FIRST

The WG will coordinate with other relevant IETF Working Groups,
including CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, LIME, 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), specifically IEEE802.1 TSN.

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Thu, 3 Sep 2015 19:03:00 +0000

Regarding capitalization and acronyms, while I sympathize on capitalization in principle and prefer lower case, it is reasonable to use capitalization to indicate that a term has a special meaning beyond the dictionary definition of the word and to be consistent with common usage. 

Spot checking some other usage in IETF (e.g. some IS-IS and VPN RFCs), I find that Layer 2 and Layer 3 were uniformly capitalized. Are there counter examples? Lacking those, we should keep the capitalization to be consistent.

IEEE 802.1 defines Bridges and they examined the use of capitalization while doing the latest IEEE 802.1Q revision. They decided to capitalize Bridge to indicate that it is used with a special meaning, not the dictionary definition so we should keep it capitalized to match. 

Regarding acronyms, we should at least spell out acronyms at the first occurrence. Replace the first occurrences of the acronyms with Time Sensitive Networking (TSN) and Operations, Administration, and Maintenance (OAM).

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Thursday, September 03, 2015 8:01 AM
To: The IESG
Cc: [email-masked]
Subject: [Detnet] Benoit Claise's Block on charter-ietf-detnet-00-00: (with BLOCK)

 

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Sep 2015 12:54:31 +0000

Hi Benoit:

We used to have a part 1 called "Background on deterministic networking" in earlier versions of the charter:
https://bitbucket.org/pthubert/detnet/raw/af7ef7b9f5802aca0816fd1e184e57bff74045dd/detnet%20charter.txt

The section has been elided to focus on the WG itself as opposed to the context. Would you suggest we restore (some of) it?

For reference the text would say:

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

"

Cheers,

Pascal

> From: detnet [mailto:[email-masked]] On Behalf Of Pat (Patricia)
> Thaler
> Sent: jeudi 3 septembre 2015 21:03
> To: Benoit Claise (bclaise) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Detnet] Benoit Claise's Block on charter-ietf-detnet-00-00:
> (with BLOCK)
> 
> Regarding capitalization and acronyms, while I sympathize on capitalization
> in principle and prefer lower case, it is reasonable to use capitalization to
> indicate that a term has a special meaning beyond the dictionary definition
> of the word and to be consistent with common usage.
> 
> Spot checking some other usage in IETF (e.g. some IS-IS and VPN RFCs), I
> find that Layer 2 and Layer 3 were uniformly capitalized. Are there counter
> examples? Lacking those, we should keep the capitalization to be
> consistent.
> 
> IEEE 802.1 defines Bridges and they examined the use of capitalization while
> doing the latest IEEE 802.1Q revision. They decided to capitalize Bridge to
> indicate that it is used with a special meaning, not the dictionary definition
> so we should keep it capitalized to match.
> 
> Regarding acronyms, we should at least spell out acronyms at the first
> occurrence. Replace the first occurrences of the acronyms with Time
> Sensitive Networking (TSN) and Operations, Administration, and
> Maintenance (OAM).
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> 
> I have no objection to the work itself, but I believe that the charter text
> should be improved. I started with a list of improvements, and in the end, I
> started editing. There are still improvements to be made. I guess that
> makes it a BLOCK. An 1:1 with Deborah should be the next step.
> 
> EXPLAIN IN ONE SENTENCE OR TWO THE MOTIVATION Various industries,
> for example, professional audio, electrical utilities, building automation
> systems, wireless for industrial applications require this capability
> because...
> 
> Networking (TSN), which is responsible for layer 2 operations, to define a
> common architecture for both layer 2 and layer 3. For this common
> architecture, a number of elements such as the IEEE802.1 TSN host
> operation should be agnostic to the choice of network used for the
> connectivity.
> 
> The work applies 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
> The work covers the characterization of flows, the encapsulation of frames,
> the required forwarding behaviors, as well as the state that may need to be
> Out of scope is the end-to-end considerations such the transport protocols,
> forwarding and encapsulations, or control plane protocols.
> 
>    be published, but may be maintained in a draft form or on a collaborative
>    Working Group wiki to support the efforts of the Working Group and help
> new comers.
> 
>    and security aspects required to enable a multi-hop path, and forwarding
>    along that path, with the deterministic properties of controlled latency,
>    As part of the overall architecture work, the working group will document
>    identification and packet forwarding over Layer 3. Candidate Layer 3 data
> The WG will coordinate with other relevant IETF Working Groups, including
> CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, LIME, and 6TisSCH.
> As
> point to maintain the consistency of the overall architecture. The WG will
> liaise with appropriate groups in IEEE and other Standards Development
> Organizations (SDOs), specifically IEEE802.1 TSN.
> 
> 
> 
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 4 Sep 2015 09:12:45 -0400

Pascal,
    How about proposing a 1-3 sentence version?

Thanks,
Lou

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Sep 2015 15:53:30 +0000

Hello Benoit and Lou:

I agree with Benoit's point that we need more background. I condensed the original text into the below. What do you think?

Operational Technology (OT) refers to industrial-grade networks that are typically deployed to monitor and control critical installations and automated systems for such applications as industrial automation, professional and home audio/video, and control networks in vehicles. 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, and requires the internet technology to achieve similar deterministic behaviors as the incumbent OT serial (TDM) links and field buses which guarantee a bounded latency, an extraordinarily low frame loss, and a very narrow jitter. 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. At the same time, the model should not compromise the ability of a network to keep carrying best effort and traditional QoS-based traffic that is already carried today. 
 
All the best,

Pascal

> From: Lou Berger [mailto:[email-masked]]
> Sent: vendredi 4 septembre 2015 15:13
> To: Pascal Thubert (pthubert) <[email-masked]>; Benoit Claise
> (bclaise) <[email-masked]>
> Cc: Pat (Patricia) Thaler <[email-masked]>; [email-masked]; The
> IESG <[email-masked]>
> > We used to have a part 1 called "Background on deterministic
> networking" in earlier versions of the charter:
> >
> https://bitbucket.org/pthubert/detnet/raw/af7ef7b9f5802aca0816fd1e18
> 4e
> > 57bff74045dd/detnet%20charter.txt
> >
> > The section has been elided to focus on the WG itself as opposed to the
> context. Would you suggest we restore (some of) it?
> >
> > 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 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 pat  h may be moved or
> removed.
> >
> > "
> >
> > Cheers,
> >
> > Pascal
> >
> >> From: detnet [mailto:[email-masked]] On Behalf Of Pat
> >> (Patricia) Thaler
> >> Regarding capitalization and acronyms, while I sympathize on
> >> capitalization in principle and prefer lower case, it is reasonable
> >> to use capitalization to indicate that a term has a special meaning
> >> beyond the dictionary definition of the word and to be consistent with
> common usage.
> >>
> >> Spot checking some other usage in IETF (e.g. some IS-IS and VPN
> >> RFCs), I find that Layer 2 and Layer 3 were uniformly capitalized.
> >> Are there counter examples? Lacking those, we should keep the
> >> capitalization to be consistent.
> >>
> >> IEEE 802.1 defines Bridges and they examined the use of
> >> capitalization while doing the latest IEEE 802.1Q revision. They
> >> decided to capitalize Bridge to indicate that it is used with a
> >> special meaning, not the dictionary definition so we should keep it
> capitalized to match.
> >>
> >> Regarding acronyms, we should at least spell out acronyms at the
> >> first occurrence. Replace the first occurrences of the acronyms with
> >> Time Sensitive Networking (TSN) and Operations, Administration, and
> >> Maintenance (OAM).
> >>
> >> Subject: [Detnet] Benoit Claise's Block on charter-ietf-detnet-00-00:
> >> (with
> >> BLOCK)
> >>
> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >>
> >> I have no objection to the work itself, but I believe that the
> >> charter text should be improved. I started with a list of
> >> improvements, and in the end, I started editing. There are still
> >> improvements to be made. I guess that makes it a BLOCK. An 1:1 with
> Deborah should be the next step.
> >>
> >> deterministic data paths that operate over layer 2 bridged and layer
> >> 3 routed segments, where such paths can provide bounded latency,
> >> loss, and packet delay variation (jitter).
> >>
> >> EXPLAIN IN ONE SENTENCE OR TWO THE MOTIVATION Various
> industries, for
> >> example, professional audio, electrical utilities, building
> >> automation systems, wireless for industrial applications require this
> >> capability because...
> >>
> >> Networking (TSN), which is responsible for layer 2 operations, to
> >> define a common architecture for both layer 2 and layer 3. For this
> >> common architecture, a number of elements such as the IEEE802.1 TSN
> >> host operation should be agnostic to the choice of network used for
> >> the connectivity.
> >>
> >> allows the network to 1) reserve the appropriate resources for the
> >> flows in advance, and
> >> frames, the required forwarding behaviors, as well as the state that
> >> may need to be established in intermediate nodes.
> >>
> >> protocols, modification of Operations, Administration, and
> >> Maintenance (OAM), L3 forwarding and encapsulations, or control plane
> protocols.
> >>
> >> 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), specifically IEEE802.1 TSN.
> >>
> >>
> >>
> >>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 11 Sep 2015 16:08:32 +0000

Hi Pascal,

As Lou noted, we discussed with Benoit and added this sentence:
"Example applications for deterministic networks include professional and home audio/video, multimedia in transportation, engine control systems, and other general industrial and vehicular applications being consider by the IEEE 802.1 TSN Task Group."

Benoit has removed his objection (what you are seeing below (===) is his original objection). So all ok. We now only have Alia's block to address.

Thanks,
Deborah

-----Original Message-----
From: iesg [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, September 11, 2015 11:54 AM
To: Lou Berger; Benoit Claise (bclaise)
Cc: Pat (Patricia) Thaler; [email-masked]; The IESG
Subject: RE: [Detnet] Benoit Claise's Block on charter-ietf-detnet-00-00: (with BLOCK)

Hello Benoit and Lou:

 
All the best,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Sep 2015 16:16:32 +0000

Hello Deborah:

Maybe I misread the last mail from Benoit but it included this:

" EXPLAIN IN ONE SENTENCE OR TWO THE MOTIVATION Various industries, for example, professional audio, electrical utilities, building automation systems, wireless for industrial applications require this capability because...
"
That I did not feel was covered so I interpreted as a request to add a bit more intro than Lou's suggestion. I'm fine either way.

All the best,

Pascal

> From: BRUNGARD, DEBORAH A [mailto:[email-masked]]
> Sent: vendredi 11 septembre 2015 18:09
> To: Pascal Thubert (pthubert) <[email-masked]>; Lou Berger
> <[email-masked]>; Benoit Claise (bclaise) <[email-masked]>
> "Example applications for deterministic networks include professional and
> home audio/video, multimedia in transportation, engine control systems,
> and other general industrial and vehicular applications being consider by
> the IEEE 802.1 TSN Task Group."
> 
> Benoit has removed his objection (what you are seeing below (===) is his
> original objection). So all ok. We now only have Alia's block to address.
> 
> Thanks,
> Deborah
> 
> I agree with Benoit's point that we need more background. I condensed the
> original text into the below. What do you think?
> 
> 
> Operational Technology (OT) refers to industrial-grade networks that are
> typically deployed to monitor and control critical installations and
> automated systems for such applications as industrial automation,
> professional and home audio/video, and control networks in vehicles. Due
> 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, and requires the internet
> technology to achieve similar deterministic behaviors as the incumbent OT
> serial (TDM) links and field buses which guarantee a bounded latency, an
> extraordinarily low frame loss, and a very narrow jitter. 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. At the same time, the model
> should not compromise the ability of a network to keep carrying best effort
> and traditional QoS-based traffic that is already carried today.
> 
> All the best,
> 
> Pascal
> 
> > 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.
> > >
> > 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.
> > >
> > (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.
> > >
> > 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.
> > >
> > 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.
> > >
> > 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
> > 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 pat  h may be moved or removed.
> > >
> > > "
> > >
> > > Cheers,
> > >
> > > Pascal
> > >
> > >> first occurrence. Replace the first occurrences of the acronyms
> > >> with Time Sensitive Networking (TSN) and Operations,
> > >> Administration, and Maintenance (OAM).
> > >>
> > >> When responding, please keep the subject line intact and reply to
> > >> all email addresses included in the To and CC lines. (Feel free to
> > >> cut this introductory paragraph, however.)
> > >>
> > >>
> > >>
> > >> -------------------------------------------------------------------
> > >> --
> > >> -
> > >> BLOCK:
> > >> -------------------------------------------------------------------
> > >> --
> > >> -
> > >>
> > >> automation systems, wireless for industrial applications require
> > >> this capability because...
> > >>
> > >> The work applies 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
> > >> frames, the required forwarding behaviors, as well as the state
> > >> that may need to be established in intermediate nodes.
> > >>
> > >>    Working Group wiki to support the efforts of the Working Group
> > >> and help new comers.
> > >>
> > >>  * An architecture that encompasses the data plane, OAM,
> > >> management, control,
> > >> 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.