Pascal, Anand:
What I would propose is SF1 for this purpose.
Regards,
Diego
2016-05-19 8:48 GMT-04:00 Pascal Thubert (pthubert) <[email protected]>:
> I like this view, Anand.
>
>
>
> Can we achieve that without getting complex?
>
>
>
> Pascal
>
>
>
> *From:* S.V.R.Anand [mailto:[email protected]]
> *Sent:* jeudi 19 mai 2016 08:17
> *To:* Pascal Thubert (pthubert) <[email protected]>; Prof. Diego Dujovne
> <[email protected]>
> *Cc:* [email protected]; [email protected]
>
> *Subject:* Re: [6tisch] My adoption-time review of SFO
>
>
>
> Hi Pascal,
>
> I agree with your view. We certainly seem to require a service sub-layer
> that
> provides link layer abstraction by offering ways of obtaining links with
> desired properties that the user might want.
>
> For instance, the user might want to ask this sub-layer for a provision of
> desired number of links being made available at certain time intervals. The
> time intervals can be specified, say, in terms of delay bounds. One can use
> this link layer feature for several possible use cases, including (i)
> meeting
> delay requirements at coarse or fine grain level (ii) power savings (iii)
> improving data aggregation and so forth. The mapping of this requirement to
> precise cell management functionality will then be handled by the lower
> layer
> 6P and SF mechanisms.
>
> I am not sure how we can fit the above sub-layer in the current scheme of
> things. Let me know if I am making sense.
>
> Anand
>
> On Friday 13 May 2016 09:20 PM, Pascal Thubert (pthubert) wrote:
>
> Hell Diego,
>
>
>
> My point is that a SF should operate on a number of units of
> transmissions, which happen to be cells in our case.
>
> SF should indicate to 6top that there is a need to change for more of less
> of these units.
>
> But the fact that one of these units is mapped to a particular slot offset
> / channel offset should not be its business. I see it as a layer violation…
>
> What if for instance the SF is in the root? Should it really manage down
> to the cell?
>
>
>
> Pascal
>
>
>
> *From:* Prof. Diego Dujovne [mailto:[email protected]
> <[email protected]>]
> *Sent:* vendredi 13 mai 2016 17:08
> *To:* Pascal Thubert (pthubert) <[email protected]> <[email protected]>
> *Cc:* [email protected]; [email protected]
> *Subject:* Re: [6tisch] My adoption-time review of SFO
>
>
>
> Dear all,
>
> During today's webex call, I presented a slide where
>
> the comments below were going to be addressed on the next
>
> version of the draft.
>
> However, I raised the point about:
>
> Ø 4. Rules for CellList
>
>
>
> Why is this here? Which cell are allocated is not SF0 ‘s business, is it?
> OTOH, the semantics of the ADD that is mentioned should be somewhere, and I
> think, in this document.
>
>
>
>
>
> -> This section is recommended by the 6top-protocol draft, and AFAIK it
> defines which cells are offered and which are selected for allocation.
>
>
>
>
>
> Ø 7. Node Behavior at Boot
>
>
>
> Again this is describing 6P not SF0 behavior. Note that the clear should
> be done at link up in case
>
>
>
> -> This section is also recommended by the 6top-protocol draft, and it
> should include any type of pre-configuration and expected initial state on
> the SF.
>
> -> From the comment from Pascal on today's webex: "What if a node has a
> big storage and it can keep all configuration after a crash?" The SF can
>
> use that info to reconstruct all the configuration and recover instead of
> issuing a clear command. However, there must be a timeout period for
> recover;
> if this timeout expires, then all the cells from the crashed node shall be
> released.
>
>
>
>
> Rules for CellList and Node Behaviour at boot are
> recommended on Sec. 5.3 of draft-ietf-6tisch-6top-
> protocol-00
>
>
>
> 2016-04-18 13:48 GMT-03:00 Pascal Thubert (pthubert) <[email protected]>:
>
> Dear authors:
>
>
>
> Please find my review of the SF0 draft; but since last call is pending
> please do not make **any** changes till after draft-ietf-*- 00 is
> published.
>
>
>
>
>
>
>
> Ø This document addresses the requirements for a scheduling function
>
> listed in [I-D.wang-6tisch-6top-sublayer
> <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#ref-I-D.wang-6tisch-6top-sublayer>],
> Section 4.2, and follows
>
> the recommended outline from Section 4.3
> <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#section-4.3>.
>
>
>
> I would expect that this doc is the reference for SF and is the one that
> requests the creation of the SF registry by IANA (text to be added in the
> IANA section).
>
> This reference to sublayer should go away since we are not promoting the
> draft at the moment – or should we be doing so?
>
>
>
>
>
>
>
> Ø
>
> Ø 3.1. SF0 Triggering Events
>
> Ø
>
> Ø We RECOMMEND SF0 to be triggered at least by the following events:
>
>
>
> The term ‘We’ is probably inappropriate. Better formulate this like “ It
> is RECOMMENDED that…”
>
>
>
> Also shouldn’t there be an event when:
>
>
>
> - Connectivity to the neighbor is lost. A L3 Link down event
> should free up resources. The question for 6P is how both sides agree at
> the same time that the link is down.
>
> - A threshold of unused time slots is reached so they should be
> freed
>
>
>
>
>
> Ø 6. If the RAB is less than the Minimum Remaining Bandwidth (MRB),
>
> Add MRB to the NOB: NOB=NOB+MRB
>
>
>
> Shouldn’t this be
>
> NOB=MRB
>
>
>
>
>
>
>
> Ø 4. Rules for CellList
>
>
>
> Why is this here? Which cell are allocated is not SF0 ‘s business, is it?
> OTOH, the semantics of the ADD that is mentioned should be somewhere, and I
> think, in this document.
>
>
>
>
>
> Ø 7. Node Behavior at Boot
>
>
>
> Again this is describing 6P not SF0 behavior. Note that the clear should
> be done at link up in case
>
>
>
>
>
>
>
>
>
> Ø 11. Examples
>
> Ø
>
> Ø TODO
>
> Ø
>
> Ø 12. Implementation Status
>
>
>
> These sections probably belong to annexes
>
>
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
> --
>
> 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
>
>
>
>
> _______________________________________________
>
> 6tisch mailing list
>
> [email protected]
>
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
--
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
