Dear all:
To address one issue about TCP/PCEP etc..., I suggest to change the stack
representation as follows
+-----+-----+
| PCEP|TEAS/|
| PCE |CCAMP|
+-----+-----+-----+-----+-------+-----+
| (COMI) |PANA |6LoWPAN| RPL |
| CoAP / DICE | ACE | ND | |
+-----+-----+-----+-----+-------+-----+
| UDP | ICMP |
+-----+-----+-----+-----+-------+-----+-----+
| IPv6 |
+-------------------------------------------+
| 6LoWPAN adaptation and compression (HC) |
+-------------------------------------------+
| 6top |
+-------------------------------------------+
| IEEE802.15.4e TSCH |
+-------------------------------------------+
I’m trying to illustrate that whatever DetNet comes up with, we will need some
conversion into COMI for whatever PCE/TEAS/CCAMP interactions.
Advice is needed: Is this readable or would you have an alternate view to
propose?
Cheers,
Pascal
> -----Original Message-----
> From: 6tisch [mailto:[email protected]] On Behalf Of 6tisch issue
> tracker
> Sent: mardi 7 avril 2015 09:08
> To: [email protected]; Shwetha Bhandari (shwethab)
> Cc: [email protected]
> Subject: [6tisch] #35 (architecture): Last call comments: editorial
>
> #35: Last call comments: editorial
>
> '''Chonggang:'''
>
> · pp. 3, 2nd paragraph, “…control operations such industrial
> automation…”
> ---> ““…control operations such as industrial automation…”
> · pp.3, 3rd paragraph, “…timeSlotted Channel Hopping …” ---> “…Time
> Slotted Channel Hopping…”
> · pp.3, 4th paragraph, the fulling spelling of TSN was givning in
> the 2nd
> paragraph. Then, please put the acronym TSN in the 2nd paragraph ·
> pp.3,
> both “deterministic” and “Deterministic” are used in a few places. Better use
> one form if they mean the same thing throughout the draft.
> · pp.4, 2nd paragraph “Route Computation may be achieved in a
> centralized fashion by a Path Computation Element (PCE), in a distributed
> fashion using the Routing Protocol for Low Power and Lossy Networks (RPL)
> [RFC6550], or in a mixed mode”, o Is RPL claim to be a distributed route
> computation? I believe in the non-storing mode, the root calculates the route
> and use source routing to route the packet to the destination.
> · pp.4, last two paragraphs from the bottom and a few other place
> in the
> draft, “…neighbor Discovery…” ---> “… Neighbor Discovery…”
> · pp. 5, section 3, 1st paragraph, “Some aspects of this
> architecture derive
> from existing industrial standards for Process Control by its focus on
> Deterministic Networking, in particular with the use of the IEEE802.15.4e
> [IEEE802154e] TSCH MAC and a centralized PCE.”
> o What are the “existing industrial standard”? WirelessHart? Certain
> references would help.
> · pp.6, the title of Figure could be more complete by saying
> something like
> “Figure 1, Basic Configuration of 6TiSCH Network”
> · pp. 6, the paragraph under Fig. 1, “neighbor Devices” --->
> “neighbor
> devices”
> · pp.6, 2nd paragraph from the bottom, “LLN Border Router (LBR)”
> were mentioned twice in one sentence.
> · pp.8, Figure 3, suggest changing its title to “6TiSCH Protocol
> Stack”
> · pp.8, Figure 3, “6LoWPAN HC” shows between IPv6 and 6top. It is
> correct
> but it could imply that only HC is used there – which is not true.
> Suggest changing 6LoWPAN HC to something like “6LoWPAN (e.g. adaptation,
> header compression)”
> · pp.9, the 4th paragraph, “join process” was introduced all of a
> sudden.
> Wonder if it could read more smoothly by briefly mentioning these concepts
> (e.g. neighbor discovery, join process, track reservation, 6top, packet
> forwarding, etc.) together and their relationship from architectural
> perspective
> somewhere in Section 4 (e.g. at the beginning?).
> · pp.9, 3rd paragraph, “TEAS protocol will be required to expose
> the device
> capabilities and the network peerings to the PCE, and a protocol such as a
> lightweight PCEP or an adaptation of CCAMP G-MPLS formats and procedures
> will be used to publish the tracks, computed by the PCE, to the devices.”
> · Can you put the reference about “TEAS” and “CCAMP”?
> · pp.10, 2nd paragraph, “should be portable only other LLN link
> types”. It
> reads a little awkward and maybe some words missing around “only”
> · pp.10, 2nd paragraph, “A new version of the standard is expected
> in
> 2015”. What’s “the standard” refer to?
> · pp.10, 4th paragraph, do you want to add a reference for
> ISA100.20?
> · pp.16, 4th paragraph, “motes” was used. Can we change it to
> devices or
> nodes to make terms more consistent?
> · pp.17, 2nd paragraph, “but also allows an upper layer like RPL.”
> This sentence seems not finished
> · pp.18, 2nd paragraph, “that is is not capable of”. One “is”
> should be removed.
> · pp.19, the last paragraph, “an higher layer” ---> “a higher layer”
> · pp.19, the last paragraph, “DSCP can therefore be used”. Suggest
> giving
> the full spelling and reference to DSCP or removing this sentence.
> · pp.19, 5th paragraph, “A 6TISCH Instance is associated to one
> slotFrame.”, · Wonder what is a 6TiSCH Instance? Why associate to
> only
> “one”
> Slotframe? In previous paragraph, it mentions “Multiple slotFrames can
> coexist
> in a node schedule”.
> · pp.21, section 9, both “Static Scheduling” and “Minimal Static
> Scheduling”
> are used. Are they the same?
> · pp.22, 1st paragraph, “This scheduled can be” ---> “This schedule
> can be”
> · pp.24, section 10.1, 1st paragraph, “A bundle of cells set to
> receive (RX-
> cells) is uniquely paired to a bundle of cells that are set to transmit
> (TX-cells),
> representing a layer-2 forwarding state that can be used regardless of the
> network layer protocol.”
> · Is a Track uni-directional or bi-directional? Is there any ACK
> for the
> transmission?
> · pp.27, Figure 6, suggest adding what is the value “set dmac to”
> and “restore dmac”
> · pp.27, section 10.1.3, 1st paragraph, “If the tunnel egress point
> does not
> have a MAC address that matches the configuration, the Track installation
> fails.”, · Wonder if it is ingress point or egress point that
> installs the Track
> · pp.30, 1st paragraph, “Centralized routes can for example
> computed”.
> The word “be” was missing.
> · pp.30, section 11, it will be helpful if the difference between
> routing
> discussed in this section and forwarding discussed in section 10 could be
> clarified a little bit
>
>
> ----
>
>
> Anand:
>
>
> There is just one observation which I could not resist mentioning. It has
> to do
> with the coupling of real-time application demands with the rest of the
> architecture. There could be application specific "time critical and sudden"
> events that might call for on-demand resource allocation.
> While we can delegate such an event handling to NME and PCE, perhaps,
> bringing in an application awareness to the overall architecture might be
> useful
> so that we are not leaving out this possible scenario.
>
> ----
>
>
> Maria Rita:
> pag 8 LLN odes -> LLN nodes
> pag. 19 6TISCH -> 6TiSCH
> pag 23 as started -> has started
> pag 19 in the definition of CDU matrix, I would specify height and width,
> and
> after the timeslot duration (in the current version timeslot duration is in
> the
> middle, and it makes a bit hard to read and clearly understand the CDU matrix
> structure) pag 7 are we sure we want to mention in the next round of the
> document we will have evaluated PANA applicability? we may need/want to
> publish the second part of the architecture before that, we don’t know yet.
> So,
> we could skip that, if you agree.
>
>
> ----
>
> Rouhollah:
>
> Page 7 first paragraph. LLN odes
> Page 9 end of third paragraph. foster
>
> 1-Do registration phase may work properly when network builds up, if when
> RPL tree grows up and extends like a complete tree (I mean in distributed
> manner). Maybe some additional controls needed later?
>
> 2-Do you think DICE(figure 3. page 7) should be defined in the Terminology
> draft.
>
> Typos:
> Page 21. scheduled
>
>
> ----
>
> Guillaume:
>
> 1) The term reallocation/relocation of cells :
> 8.1 p16 a cell reallocation
> differs from
> 9.2 p22 the relocation of a soft cell / relocation is done => I am not sure
> if
> there has been a discussion on this term, but I vote for reallocation.
>
> 2) 8.2 p16 a set of quality metrics (RSSI, LQI) I think you cannot be
> specific to
> just two metrics (RSSI, LQI).
> The words "a set of" allows to define more metrics. And I think it is fine.
> => what do you think of : "a set of quality metrics (e.g. RSSI, LQI, etc.)
> " ?
>
> 3) 8.2 p16 and used to compute a Rank Increment The statistics of 6top may
> have other usages than incrementing the ranks, for upper layers, and for
> resource management.
> => what about : "and used for instance to compute" ?
>
> 4) 10.2 p28 : a degree of flow control base on => I think it should be
> "based
> on".
>
> 5) (Already pointed out) 11 p 30 Centralized routes con for example computed
> => be computed
>
>
> ----
>
> Jonathan Simon:
> 13 - Sending link-layer frames in the clear in the initial stage of joining
> is not
> providing any benefit. We should always use authentication, even if the key
> is
> not secret, as it provides the ability to reject similar frames from other
> 802.15.4-based protocols. It also isn’t necessary to discuss such a detail
> here.
>
> 13.1 -
> * "Triage" - So the JCE decides which nodes are more important and assigns
> resources to them first? How? Note this term is not used in draft-
> richardson-
> 6tisch-security-architecture-02.
> * "arbitrage" should be “arbitrate”
>
> Other than that, it seem to be capturing the overall spirit of the security
> architecture and highlights the open areas of security discussion, e.g. that
> PANA
> is an open issue.
>
> Couple minor points:
>
> 1) Introduction and 3) Application and Goals sections need review. They
> kind of
> wander all over the place.
>
> 5.1) What does "volume" mean in this context? Is this referring to other as
> yet
> defined documents, or later revisions of this document?
>
>
> ----
>
> Rene:
> One note: the second para of Clause 13 seems out of place and should be
> removed.
>
>
> ----
>
> --
> -------------------------+----------------------------------------------
> -------------------------+---
> Reporter: | Owner: draft-ietf-6tisch-
> [email protected]<mailto:[email protected]> |
> [email protected]<mailto:[email protected]>
> Type: defect | Status: new
> Priority: minor | Milestone:
> Component: | Version:
> architecture | Keywords:
> Severity: In WG Last |
> Call |
> -------------------------+----------------------------------------------
> -------------------------+---
>
> Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/35>
> 6tisch <http://tools.ietf.org/6tisch/>
>
> _______________________________________________
> 6tisch mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
