Subject: Re: [Detnet] Gap analysis

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 9 Mar 2015 20:49:06 -0300

Pascal, All,
                I have submitted a draft with the results of the former
discussion about the Gap Analysis for DetNet.
                Regards,

                                  Diego Dujovne

2015-02-24 6:40 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]>:

> 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,
>
>            I´m currently working on a Gap analysis for
> DetNet. I have some preliminary questions though:
>
> Fantastic!
>
>
>
> - 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?
>
>
>
> This is certainly in scope and we can start there.
>
>
>
> - 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)
>
>
>
> - 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.
>
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> - 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?
>
>
>
> 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
> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
> Facultad de Ingeniería UDP
> www.ingenieria.udp.cl
> (56 2) 676 8125
>

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