Subject: [Detnet] Gap analysis

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 23 Feb 2015 21:25:42 +0000

Dear all,
           I´m currently working on a Gap analysis for
DetNet. I have some preliminary questions though:

- Are we targetting specific applicability areas, such
as Flow control systems and/or Real time control
systems on standard industrial plants, mission-critical
control systems?
- I have gone through the presentations from the detnet
BOF at IETF 91; I can deduce that we are targetting
a broader view (as Pascal mentioned in a former mail)
than 6TiSCH to cover a wider range of deterministic
networks (wider than what is covered by 6TiSCH)
which are not currently IP-enabled, including in-vehicle
networks, utility control long-range networks and
general purpose monitoring networks. Here I think
about the reverse of what I have observed on recent
commercial adaptations (Profibus, ModBus over IP).
- I can also think that the main gaps are on the
*scheduling management side (as 6TiSCH does)
*network management of timers, queue schedulers and
buffers
*anything else?

Thank you.

                                 Diego Dujovne

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 24 Feb 2015 09:40:08 +0000

Hello Diego:

I think that you can start with the well-understood 6TiSCH gap (industrial process control) and expand from there to others such as AVB and vehicule, with the aid of the group.

Please see below:

Dear all,

Fantastic!

control systems?

This is certainly in scope and we can start there.

- Yes but still 6tiSCH is a good start, mostly if you are presenting at a 6TiSCH session. 

The IETF will not be conformable if layer2 operations are discussed too much, since this is beyond our scope. It is really up to cross participation (which we do have) to ensure that the concepts that we manipulate are compatible with what IEEE is and will be doing.

- 6TiSCH needs to install tracks with all the Deterministic capabilities, scheduled transmissions, path and packet redundancy, etc… which means PCE/SDN operations

- And then we have identified the need to reuse opportunistically track slots to forward IPv6 packets and Link bundle slots to forward scheduled packets that missed their track, which means that IP has a role to play in the DetNet world.

Certainly what you’ll obtain applies to a larger world than 6TiSCH, but you’ll find in 6TiSCH most of the gap that DetNet in general will have.

The way we designed today, 6TiSCH tracks can carry any 802.15.4 packet, but will not allow opportunistic operations for non IP packets.

In general, if we tag Deterministic payload with MPLS and some variation of PRP, we can carry anything, and I think we should aim at that.

buffers

*anything else?

We need to decide if we want to work on the northbound interface. If we do, we need some abstraction of the TSPEC, and we need to describe the push model where the user agent / app requires a service implementing that TSPEC from the PCE (and then the PCE pushes the tracks onto the network over the southbound interface)

We certainly need to work on the southbound interface, 

- what adaptation of TEAS will carry the topology (neighbors, link quality, interference test..) as well as the capability (buffers, queues, timers) as seen by individual devices.

- what adaptation of CCAMP/RSVP-TE can be used to program individual tracks

- what adaptation of PCEP can be used to push a device schedule (PCE is currently not chartered to push things to individual nodes)

We need to formalize how a packet is identified as pertaining a certain track (I’d rather not use flow, the word is just too overloaded). Use of DiffServ/DSCP and of MPLS have to be evaluated, including G-MPLS for 6TiSCH.

Whether NVO3 and SFC may apply also has to be evaluated, and there is no PRP that I know of at the IETF, so this is probably to be done entirely by DetNet.

6TiSCH adds the notion of Generalized for both flow tagging and PRP. The flow (the track) can be determined from the timeslot in a G-MPLS fashion, and the PRP sequence number can be determined from the ASN.

And then we need to decide if we want an LMI (a UNI) between the first network device and the end point to indicate availability and other state information of a track.

Thank you.

Thank You!

                                 Diego Dujovne

-- 

DIEGO DUJOVNE