Subject: [Detnet] almost final charter proposal

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Sep 2014 14:40:44 +0000

Here we are after I applied comments by Erik, Shitanshu and Norm:

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 drove the formation of the Audio/Video Bridging (AVB) standards effort of IEEE 802.1, destined to the professional and home audio/video markets. While aimed at less critical applications than some industrial networks, AVB networks share the requirement for extremely low packet loss rates and guaranteed finite latency and jitter. Other instances of deterministic networks have arisen as well, for instance in the context of vehicles and avionics, such as the mission-critical "Avionics Full-Duplex Switched Ethernet" (AFDX), which was designed as part of the ARIC 664 standards.

The success of the 802.1 AVB standards in the professional studio environment and the needs of the industrial networking markets 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, and require 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 an 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 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 may be granted or rejected, and the associated reservation may be moved or cancelled.

WG description

The working Group 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.1 TSN, 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 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.
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, some of the items initially considered at detnet may be transferred to those working groups as deemed appropriate by all parties.

The WG will conclude this round with the selection of a solution paradigm and suggest a base protocol that can be applied or extended.
Work Items

- Deliverables:
  * An analysis of the requirements in a number of environments (3-4 drafts which could include factory automation, grid automation, vehicles/avionics and audio/video studios).

  * A general problem statement including an analysis of the proposed solutions of the related work at IEEE802.1TSN, with a status of the work done and left to be achieved, and the directions that are being taken.

  * A study of generic scoping. For IPv6, the study will include the definition of Link-Local, Realm-Local and Admin-Local scoped operation (per RFC 7346) where for instance the deterministic technology is consistent over a Link or a Realm Local Scope and achievable across technologies and layers over an Admin-Local scope. Similar scoping will be studied for IPv4.

  * A solution taxonomy, where potential solution paradigms will be explored, such as Peer-to-peer protocols (along the lines of MSRP or RSVP), Central controller (along the lines of SDN or PCE), Connection to Operations (Application) Controllers, Manual C  onfiguration, and Mixed scenarios, in relation to the IP generic scoping.

  ->  all those documents planned for informational track

  * A data model for flow characterization for use in flow reservation by the protocol(s) selected by the WG from the solution taxonomy (e.g. an evolution of PCEP or RSVP).

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

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

  -> those would be standard track, and the work would progress any identified dependency is resolved. This work focusses 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.

Milestones

TBD, probably all drafts to IESG one year after chartering

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Thu, 25 Sep 2014 15:00:16 +0000

Hello Pascal,
   The charter proposal you have outlined below looks very nice, please consider the following items in that context:
a. The influence of DETNET on OAM tools, in other words, an evaluation of the changes (if any) needed to the OAM toolkit to support deterministic flows.
     i. How would the forwarding model of deterministic flows influence the methods of fault monitoring/ isolation?
     ii. What is the influence of deterministic flows from the perspective of performance monitoring?
The above does not imply that the current tools are incapable of supporting these flows.
b. Do we need to explore interactions/ inter-working required (if any) between the  OAM operating at layer-2 and layer-3?
My suggestions are early thoughts and not conclusions, I look forward to feedback on the above points.
 
Thanks
Prasad 

From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, September 25, 2014 8:11 PM
To: [email-masked]
Subject: [Detnet] almost final charter proposal

 

WG description

Work Items     

- Deliverables:

  

 

 

Milestones

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Sep 2014 15:16:33 +0000

Hi Prasad:

I fully agree that this is highly related, and fully in line with the standard track work item of flow characterization.

a) seems to relate to work items. How would you see that, a separate work item, like a draft with an evaluation? Or a requirement draft to other WGs?
b) seems to relate to the IEEE/IETF collaboration, which will be at the paradigm level to start with? What should we be doing there, add OAM to the topics to be considered?

Thanks for all this,

Pascal

> -----Original Message-----
> From: Vengada Prasad Govindan (venggovi)
> Sent: jeudi 25 septembre 2014 17:00
> To: Pascal Thubert (pthubert); [email-masked]
> Subject: RE: almost final charter proposal
> 
> Hello Pascal,
>    The charter proposal you have outlined below looks very nice, please
> consider the following items in that context:
> a. The influence of DETNET on OAM tools, in other words, an evaluation of
> the changes (if any) needed to the OAM toolkit to support deterministic
> flows.
> b. Do we need to explore interactions/ inter-working required (if any)
> between the  OAM operating at layer-2 and layer-3?
> 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 drove the formation of the
> Audio/Video Bridging (AVB) standards effort of IEEE 802.1, destined to the
> professional and home audio/video markets. While aimed at less critical
> applications than some industrial networks, AVB networks share the
> requirement for extremely low packet loss rates and guaranteed finite
> latency and jitter. Other instances of deterministic networks have arisen as
> well, for instance in the context of vehicles and avionics, such as the mission-
> critical "Avionics Full-Duplex Switched Ethernet" (AFDX), which was designed
> as part of the ARIC 664 standards.
> 
> The success of the 802.1 AVB standards in the professional studio
> environment and the needs of the industrial networking markets 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, and require 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 an 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 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 may be granted or rejected,
> and the associated reservation may be moved or cancelled.
> 
> 
> WG description
> 
> 
> The working Group 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.1 TSN, 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 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.
> 
> 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, some of the items
> initially considered at detnet may be transferred to those working groups as
> deemed appropriate by all parties.
> 
> The WG will conclude this round with the selection of a solution paradigm
> and suggest a base protocol that can be applied or extended.
> 
> Work Items
> 
> 
> - Deliverables:
> 
>   * An analysis of the requirements in a number of environments (3-4 drafts
> which could include factory automation, grid automation, vehicles/avionics
> and audio/video studios).
> 
>   * A general problem statement including an analysis of the proposed
> solutions of the related work at IEEE802.1TSN, with a status of the work
> done and left to be achieved, and the directions that are being taken.
> 
>   * A study of generic scoping. For IPv6, the study will include the definition
> of Link-Local, Realm-Local and Admin-Local scoped operation (per RFC 7346)
> where for instance the deterministic technology is consistent over a Link or a
> Realm Local Scope and achievable across technologies and layers over an
> Admin-Local scope. Similar scoping will be studied for IPv4.
> 
>   * A solution taxonomy, where potential solution paradigms will be
> explored, such as Peer-to-peer protocols (along the lines of MSRP or RSVP),
> Central controller (along the lines of SDN or PCE), Connection to Operations
> (Application) Controllers, Manual C  onfiguration, and Mixed scenarios, in
> relation to the IP generic scoping.
> 
>   * A data model for flow characterization for use in flow reservation by the
> protocol(s) selected by the WG from the solution taxonomy (e.g. an
> evolution of PCEP or RSVP).
> 
>   * A data model for the state to be installed in the forwarding device and
> the associated packet forwarding behavior.
> 
>   * A flow identification for use in packet forwarding to identify a state, with
> the specific application to at least classical IP, 6TiSCH track forwarding, and
> MPLS.
> 
>   -> those would be standard track, and the work would progress any
> identified dependency is resolved. This work focusses 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.
> 
> 
> 
> Milestones
> 
>