e
>
> *“before it is passed to the 6top sublayer where MSF can observe it.” Or
> something similar?*
>
>
>
> Otherwise, all good!
>
>
>
> Pascal
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang
> *Sent:* jeudi 12 décembre
6tisch <6tisch@ietf.org>
Subject: Re: [6tisch] MSF adapts to traffic only for secured packets
All,
The following is our internal discuss about this issue.
We will add the following text in "Security Consideration " section in MSF-09:
MSF adapts to traffics containing
All,
The following is our internal discuss about this issue.
We will add the following text in "Security Consideration " section in
MSF-09:
* MSF adapts to traffics containing packets from IP layer. It is
possible that the IP packet has a non-zero DSCP (Diffserv Code
Thank you, Tengfei.
> On Dec 6, 2019, at 22:49, Tengfei Chang wrote:
>
> Handling DSCP value will be a per-packet process. Can we pass DCSP value
> to the TSCH layer using the interface for transmission defined by
> IEEE802.15.4? I don't think so.
>
> TC: Not sure this is a standard way to
On Fri, Dec 6, 2019 at 9:31 PM Yasuyuki Tanaka
wrote:
> Hi Pascal, Tengfei,
>
> On 12/6/2019 6:48 PM, Tengfei Chang wrote:
> > Yes, MSF indeed aware of the routing information such as RPL parent, I
> > consider this is like an information stored at IPv6 layer that MSF can
> > read it from
Hi Pascal, Tengfei,
On 12/6/2019 6:48 PM, Tengfei Chang wrote:
Yes, MSF indeed aware of the routing information such as RPL parent, I
consider this is like an information stored at IPv6 layer that MSF can
read it from without touching the frame L2 payload.
In such sense, I could consider the
Yes I do
Regards,
Pascal
Le 6 déc. 2019 à 09:49, Tengfei Chang a écrit :
Pascal,
Yes, MSF indeed aware of the routing information such as RPL parent, I consider
this is like an information stored at IPv6 layer that MSF can read it from
without touching the frame L2 payload.
In such
Pascal,
Yes, MSF indeed aware of the routing information such as RPL parent, I
consider this is like an information stored at IPv6 layer that MSF can read
it from without touching the frame L2 payload.
In such sense, I could consider the DSCP value can be another information
stored at upper layer
Hi Malisa.
Thanks to your explanation, I get the point.
how could we ensure that the “acceptable” amount of unauthenticated traffic
that actually gets forwarded does not trigger cell allocation?
It'd be fine to trigger cell allocations by *acceptable* amount of
unauthenticated traffic if
The “join rate” parameter takes care that any single JP at the edge of the
network does not inject too much traffic. But this traffic is forwarded along
multiple hops towards the root, and therefore gets aggregated with (join)
traffic from other JPs in the network. The purpose of the traffic
Hello Tengfei
Architecturally speaking, MSF right now is used to allocate cells in the L3
bundle with a parent.
“
Layer-2 vs. Layer-3 bundle:
Bundles are associated for either Layer-2 (switching) or Layer-3 (routing)
forwarding operations. A pair of Layer-3 bundles (one for each direction)
Hi,
On 12/5/2019 5:17 PM, Tengfei Chang wrote:
Does anyone know other way to make the SF not adapt to unsecured traffic
without knowing upper layer field?
I have no idea...
Why can't the "join rate" avoid such undesired cell allocations? If the
join rate is properly configured, incoming
12 matches
Mail list logo
