Re: [Detnet-dp-dt] Integrating DetNet service model into architecture

[Balázs Varga A <[e-mail]>]

Hi Norm,

Thanks.
1. detnet-t-flow, detnet-s-flow, detnet-st-flow: Agree, that is better terminology.
2, "Deterministic connectivity service": that is my bad English, sorry for the confusing texting.
My understanding is same as your described below.
3, Chapters proposals: OK with me.

I will provide a proposed change based on your comments.

Cheers
Bala'zs

From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Norman Finn
Sent: Saturday, February 25, 2017 12:41 AM
To: Balázs Varga A <[e-mail]>
Cc: [e-mail]
Subject: [Detnet-dp-dt] Integrating DetNet service model into architecture

Balázs,

Some questions/comments about text to be carried to the architecture document.

1. DetNet-s-flow and figure 2:

Why "some DetNet service layer"?  I find that confusing.  Why not:

   detnet-t-flow:  Only requires the congestion / latency features of the Detnet transport layer.

   detnet-s-flow:  Only requires the replication/elimination feature of the DetNet service layer.

   detnet-st-flow:  Requires both.

(Feel free to use different terminology; I'm just trying to understand why the need for ambiguity.)

Similarly, we can classify end systems as being t-aware, s-aware, both, or neither.  Note some known use cases:

  unaware:   The classic case requiring network proxies.
  t-aware:   An extant AVB system.  It knows about TSN, SRP, and 0 congestion, but not about replication/elimination.
  PRP/HSR:   An extant IEC 62439-3 system.  It supplies sequence numbers, but doesn't know about 0 congestion loss.
  st-aware:  A real DetNet end station.

I would suggest altering your figure 2 to be a tree, so that it doesn't look like a protocol stack.  That may be confusing.

The opening sentence of your section 4 makes me a little nervous.  While it is true that, in order to provide DetNet services, the network often (though certainly not in all cases) needs to pin down paths.  The phrase "Deterministic connectivity service" seems to me to say that we provide connectivity separately from the non-deterministic network, and that is definitely not true, at least in my mind.  Two DetNet end stations have exactly the same connectivity for DetNet as for non-DetNet packets.  in many applications, they will need to discover each other, either using broadcasts, multicasts, a connection server, or administrative commands.  A DetNet source may only know a destination IP address for its DetNet flow, and not concern itself at the application layer whether it is connected through a bridge, a router, or a direct connect.  Two DetNet stations may exchange all kinds of non-DetNet traffic intermixed with some number of DetNet flows.  I'm not ruling out a special virtual port on a DetNet host just for one DetNet stream, providing special connectivity, etc. -- a virtual Ethernet link -- but that's what I think of when I read, "Deterministic connectivity service."

In other words, our service is a QoS service, not a connectivity service.  We often need connectivity services such as nailed down paths in order to provide that QoS.

2. Where to put this stuff in the document.

You suggested putting your stuff deep inside clause 4.  I think you could just add "End system", "DetNet transport layer" and "DetNet service layer" sections at the 4.x level.  You should have references to them from 3.1 (that doesn't mention transport layer now, and it should), 3.4, and 4.1.3.

THANKS!

-- Norm