Hi Satish,
Yes, I agree with your point!
As Pascal remarked in response to my mail, we need to come up with an
approach that is less complex.
Anand
On Friday 20 May 2016 08:35 AM, Satish Anamalamudi (Satish Anamalamudi)
wrote:
Hello everyone,
It’s good to manage the cell information<slotoffset, channeloffset> in
a separate module(namely “tisch cell management”) instead of naming it
as “SF1”. In the future, probably more SFx may be developed. In that
case, Cell management module can provide the cell information to
specific Scheduling Function (SFx).
SFx naming will be good to trigger scheduling functionalities for
different traffic flows. If we make use of SFx extension for cell
information then it may be confusing with traffic flows in the future.
What do you think ?
With Regards,
Satish.
*From:*6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Prof.
Diego Dujovne
*Sent:* 2016年5月19日21:40
*To:* Pascal Thubert (pthubert)
*Cc:* 6tisch@ietf.org; S.V.R.Anand;
draft-dujovne-6tisch-6top-...@tools.ietf.org
*Subject:* Re: [6tisch] My adoption-time review of SFO
Pascal, Anand:
What I would propose is SF1 for this purpose.
Regards,
Diego
2016-05-19 8:48 GMT-04:00 Pascal Thubert (pthubert)
<pthub...@cisco.com <mailto:pthub...@cisco.com>>:
I like this view, Anand.
Can we achieve that without getting complex?
Pascal
*From:*S.V.R.Anand [mailto:an...@ece.iisc.ernet.in
<mailto:an...@ece.iisc.ernet.in>]
*Sent:* jeudi 19 mai 2016 08:17
*To:* Pascal Thubert (pthubert) <pthub...@cisco.com
<mailto:pthub...@cisco.com>>; Prof. Diego Dujovne
<diego.dujo...@mail.udp.cl <mailto:diego.dujo...@mail.udp.cl>>
*Cc:* 6tisch@ietf.org <mailto:6tisch@ietf.org>;
draft-dujovne-6tisch-6top-...@tools.ietf.org
<mailto:draft-dujovne-6tisch-6top-...@tools.ietf.org>
*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:diego.dujo...@mail.udp.cl]
*Sent:* vendredi 13 mai 2016 17:08
*To:* Pascal Thubert (pthubert) <pthub...@cisco.com>
<mailto:pthub...@cisco.com>
*Cc:* draft-dujovne-6tisch-6top-...@tools.ietf.org
<mailto:draft-dujovne-6tisch-6top-...@tools.ietf.org>;
6tisch@ietf.org <mailto:6tisch@ietf.org>
*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)
<pthub...@cisco.com <mailto:pthub...@cisco.com>>:
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 fromSection 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
6tisch@ietf.org <mailto:6tisch@ietf.org>
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 <http://www.ingenieria.udp.cl>
(56 2) 676 8125
_______________________________________________
6tisch mailing list
6tisch@ietf.org <mailto:6tisch@ietf.org>
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 <http://www.ingenieria.udp.cl>
(56 2) 676 8125
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
