►
From YouTube: IETF111-6LO-20210728-2130
Description
6LO meeting session at IETF111
2021/07/28 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
Okay,
hello,
everyone.
I
hope
you
can
hear
me
correctly.
Welcome
to
the
meeting
of
the
sixth
law
working
group.
My
name
is
carlos
gomez.
The
other
chair
is
shreta
bandari,
our
responsible
ad
is
eric
cline.
We
hope
eric
will
join
soon
and
for
today
we
have
one
minute
taker.
Georgia's
papadopoulos.
Kindly
will
help
in
taking
minutes.
However,
is
there
anyone
else
who
would
maybe
like
to
volunteer
to
help
georgios
in
taking
minutes.
A
A
This
is
the
agenda
for
today.
The
first
slot
is
the
usual
chairs,
introduction
and
presentation
of
draft
status.
So
this
is
the
presentation
that's
currently
in
progress
and
well
after
that
there
will
be
the
presentation
of
the
last
update
of
the
applicability
and
use
cases
draft
that
will
be
followed
by
the
presentation
of
a
new
draft
entitled
transmission
of
she
compressed
package
over
ieee
2.15.4.
A
A
A
The
next
document
is
ipv6
measure
for
blinks.
This
document
was
also
evaluated
by
the
asg
and
there
was
after
revision.
Nine
there
was
one
outstanding
discuss
and
the
authors
updated
the
document
and
the
discuss
was
clear.
So
currently,
there
are
no
more
remaining
discuss
bullets.
However,
there
were
recently
some
isg
members
who
stepped
down
so
as
a
result,
now
we
need
to
have
few
more
ballots
to
get
the
approval
of
the
document
and
we
expect
to
have
such
ballots
in
august
or
perhaps
early
september.
A
Then
the
next
working
group
document
is
ipv6
over
plc.
This
document
entered
the
isg
evaluation
stayed
quite
recently
just
around
one
week
ago,
and
it
is
on
the
agenda
for
the
delta
for
the
12th
of
august.
So
in
about
a
couple
of
weeks,
we
expect
to
receive
the
feedback
from
the
isg
on
the
last
working
group
document.
Is
the
six
loan
use
cases
draft?
A
A
C
C
Yes,
this
is
the
history
and
status.
You
know
we
have
two
working
group
last
call.
So
in
the
last
meeting,
based
on
the
10th
revision,
we
will
try
to
reserve
the
comment
from
the
second
working
group
last
call,
so
I
believe
that
we
resolved
a
lot
of
the
comment
from
the
second
working
last
course,
but
there
are
the
remaining
comments
after
the
second
working
group
last
call.
So
in
this
meeting
I
will
try
to
resolve
the
other
remaining
comment.
C
Next
page,
please,
yes,
so
this
update
after
last
meeting.
So
after
last
meeting,
we
got
two
comments.
That
is
a
comment
from
hero
kevin
and
the
other
is
to
comment
from
the
direct.
So
I
would
like
thanks
to
them.
The
first
comment
from
fellow
company
is
I
received
that
after
submission
of
the
previous
thread,
so
I
don't
have
any
time
to
reflect
this
command
in
the
threads
so
document
from
parallel
convenience
are
the
poll.
C
C
So
this
document
should
also
note
that
in
some
ideal
standards
in
the
poll
networks,
those
might
not
be
needed
and
the
method
provided
by
the
I
triple
standard
error
pt9
could
also
be
used.
So
actually
I
have
no
knowledge
of
the
identical
standard
error,
error
259,
but
I
studied-
and
I
investigated
the
I
triple
standard
error
wt9
as
I
believe
that
document
from
tarot
cabinet
is
correct.
So
I
changed
the
text.
As
you
can
see,
it
is
noted
that
I
triple
standard
error.
C
C
So
I'll
note
that
the
standard
between
the
i33
and
the
standard
number
and
that
there
is
no
period
after
the
standard,
so
I
checked
the
draft
and
I
found
that
there
are
some
expression.
So
in
the
fourth
text
I
changed
it.
I
triple
send
that
the
port
to
I
triple
a
standard
error
to
the
from
the
poll,
and
I
also
changed
as
he
recommended.
C
C
The
final
comment
is
there:
removing
on
express
external
standard,
it
is
related
to
the
threat
or
text.
So
he
says
that
I'm
not
sure
current
thread
group
used
either
for
standard
error,
54
26
anymore.
There
is
any
picture
that
was
there
in
26th,
but
which
are
not
no
longer
in
your
new
version,
so
he
suggests
to
delete
the
sentence.
C
So
I
3
standard
15.4
26
and
it
replied
to
the
poll.
2015
version
of
the
specifications
are
used
by
thread,
so
I
delete
the
sentence.
Okay.
Next,
please
please
it
is
the
command
prompt
red.
Yes,
it
is
the
sun,
the
miner
typo,
so
I
changed
it.
I
built
standard
1901
and
I
changed
to
either
blue
standard
1901.1
and
1901.2.
C
C
C
D
It
should
be
out
like
in
a
couple
of
months
it
it
doesn't
have
any
the
the
fragmentation
of
that
kind
of
things
are
actually
the
same.
The
major
difference
is
that
there
is
actually
no
support
for
15
for
y,
which
is
adding
algorithms
multiple.
You
know
different
key
cryptographic,
algorithms
for
15
for
and
allows
negotiation
of
those
two.
E
A
A
First
of
all,
let's
take
a
look
at
the
motivation
for
this
draft.
As
this
working
group
knows
very
well,
rfc
6282
has
been
the
basis
for
header
compression
in
six
load
band
and
also
in
six
low.
This
rfc
was
designed
for
15.4
as
the
target
technology,
and
it
has
been
adapted
or
reused
quite
extensively
for
relatively
similar
iot
technologies.
A
So,
with
this
rfc,
it
is
possible
to
compress
a
typical
48,
byte,
ipv6
udp
header,
down
to
a
size
of
7
bytes,
that's
in
the
best
case
with
global
addresses
and
on
the
other
hand,
last
year
there
was
the
publication
of
rc8724,
which
is
a
product
of
the
lp1
working
group.
It's
also
known
as
chic,
which
is
a
framework
which
provides
an
additional
layer
functionality.
A
So
if
we
focus
on
header
compression
chic
is
capable
of
compressing
a
48
byte,
ipv6
udp
header
down
to
a
size
of,
for
example,
just
one
byte
again
in
the
best
case
with
global
addresses,
and
it
is
based
on
the
use
of
static
context
and
the
technique
here
is
exploiting
a
priori
knowledge
of
header
field
values.
Next,
please.
A
We
may
also
consider
an
application
layer
protocol
on
top
of
ipv6
udp,
like
in
this
case
coap
and
well.
There
is
no
specific
signal,
pan
header
compression
for
co-op,
so
in
that
case
we
may
compress
an
ipv6
udp,
co-op
header
down
to
a
size
of
11
bytes
again
the
best
case
with
global
addresses
and
also
in
this
case,
with
no
header
options.
A
Theoretically
and
in
the
most
extreme
case,
it
is
possible
to
achieve
a
theoretical
battery
lifetime
improvement
by
up
to
40
percent.
That
would
be
also
including
a
third
byte
when
using
chic,
which
would
be
the
chic
dispatch
that
will
be
presented
later
and
well.
A
disclaimer
here
is
that,
of
course,
the
actual
improvement
will
be
lower
depending
on
various
parameters
and
features
such
as
device
hardware,
and
especially
the
slip
current
consumption,
mac,
layer,
settings,
application,
layer,
settings
payload
size
and
so
on.
A
So
about
the
status
of
this
document,
so
the
document
I'm
presenting
today
is
an
initial
version.
It's
a
zero
zero.
However,
strictly
speaking,
it
is
not
really
a
zero
zero
because
it's
actually
an
extended
version
of
another
document
that
was
with
a
narrow
scope
which
intended
to
define
just
the
chic
dispatch,
and
here
the
scope
is
greater.
The
aim
is
to
specify
everything
necessary
to
enable
the
transmission
of
ship
compressed
packets
over
15.4
networks.
Also,
the
aim
is
to
incorporate
feedback
from
previous
meetings.
A
Well,
here
we
can
see
two
protocol
stacks.
The
one
on
the
left
is
the
traditional
six
blue,
pan
based
protocol
stack
where,
as
you
can
see,
the
six
load
band
layer
has
been
illustrated
as
two
the
separate
sub-layers,
the
one
on
top
is
the
syslogband
header
compression.
The
other
one
is
fragmentation.
A
A
A
A
So
from
that
point
of
view,
perhaps
there
is
not
much
more
that
can
be
added
by
considering
chic
fragmentation,
then
also
in
terms
of
the
size
of
the
fragmentation
header.
It's
not
so
clear
that
there
will
be
a
huge
improvement
from
that
site
as
well,
and
perhaps
it's
also
positive
to
be
able
to
reuse
existing
code,
existing
six
loop
and
fragmentation
code
for
implementations
of
a
15.4.
A
A
A
The
aim
is
to
just
use
dedicate
a
whole
page
so
that
we
can
have
the
paging
dispatch
as
the
sheet
dispatch,
and
in
this
case,
because
most
pages
are
currently
and
used
and
assigned,
we
would
aim
to
use
page
2..
So,
as
a
result,
the
sheet
dispatch
would
be
the
one
shown
on
the
last
bullet
here
on
the
slide,
which
is
a
one
bite
big
pattern.
F
Hello,
I
have
a
question
about
the
dispatch
type
value
assignment,
I'm
not
too
very
clear
about
when
to
assign
a
whole
page
and
when
to
assign
a
dispatch
value
in
page
in
page
zero,
because
here
I
I
can
see,
we
use
reduce
the
whole
pitch.
But
if
we
assign
only
only
one
value
from
page
zero
seems
to
seems
to
work.
A
Actually,
there
are
only
two
pages
at
the
moment,
actually
assigned
and
there's
a
third
one
that
will
be
assigned,
but
there
are
still
13
pages
which
are
not
used
well
out
of
those
one
is
experimental,
but
anyway
it
seems
like
perhaps
it
might
be
suitable
to
to
allocate
a
whole
page
for
this.
Considering
that
the
aim
here
is
to
keep
low
of
the
head
just
keep
the
dispatch
of
just
one
bite.
That's
the
aim
here,
I
don't
know
if
pascal
is
also
on
the.
G
G
G
A
A
Okay,
so
then,
after
the
sheet
dispatch,
what
comes
next
is
the
chic
packet,
as
mentioned
before.
It
would
be
a
packet
with
a
header
compressed
by
using
chic.
Then
there
would
be
some
payload
and
if
needed,
there
would
be
a
last
field
which
would
be
padding
with
the
aim
to
align
the
size
of
the
frame
format
to
an
octet
boundary.
A
A
A
So
this
is
something
that
might
need
some
adaptation.
Perhaps-
and
another
point
is
that
regarding
co-op,
we
state
that
club
header
fields
if
quad
is
used.
If
compression
focus
is
used,
those
fields
must
be
compressed
as
per
sections
four
to
six
of
rfc
8824,
okay.
So
next
please
well!
Thank
you.
That
was
everything
I
don't
know.
If
there
may
be
other
comments
or.
F
B
F
Okay,
thank
you.
Three
points
drove
me
to
research
on
nic
technology.
The
first
one
is
an
ongoing
massive
expansion
of
network
edge
that
is
driven
by
iot
technology
and
the
second
one
is
manual.
Work
has
been
done
and
to
address
the
front
conditional
issues,
especially
in
six
low
pass
six
law
and
lp1
working
groups.
The
last
one
is
we
still
have,
but
there
is
still
room
to
improve
the
solutions
because
of
existing
solutions.
F
It
will
optimize
networking
of
devices
within
lt
domain
from
while
to
vote
to
the
internet,
and
it
depends
on
nether,
specific,
lower
layer
conventions
nor
centralize,
the
dhcp
v6
server
and
more
on
there
is
no
routing
table
is
needed
anymore,
thus
eliminates
root,
message,
messages
and
considering
the
most
common
route
over
network
case.
The
anc
approach
will
help
for
us
43
percent
headlines,
reducing
giant
six
slope.
F
F
F
F
F
Okay,
a
leaf
and
the
white
node
now
will
ignore
and
drop
the
message
silently
and
and
the
next
and
the
under
the
forward
forward.
Node
all
route
will
execute,
will
execute,
address
allocation
function
to
generate
a
new
address
for
nodex
and
send
the
response
message
to
nodex
next,
please
so
the
node
x
will
receive
many
a
response
response
from
its
neighbors.
Maybe,
and
it
will
accept
it-
will
accept
the
first
valid
response
and
use
setup
and
the
user
address
so
ignores
other
lead
coming
responses.
F
F
D
F
F
F
So
here
here
is
about
the
iona
consideration,
the
new
dispatch
type
assignment,
and
you
actually
need
to
request
some
dispatch
type
values.
The
the
audio
or
the
audio
values
is
16,
but
under
the
columns
of
college
we
cannot
use
or
zero
one
zero
one,
one
one:
zero,
zero,
zero,
zero
value
which
which
are
has
already
been
used
by
the
broadcast.
F
F
G
G
Some
people
came
into
six
low,
I
would
say
almost
15
years
ago,
proposing
something
similar.
I
think
it
was
draft
danielle
hilo,
something
like
that,
and
you
will
find
in
the
system
history
that
it
also
failed,
not
encouraging
six
slope
and
six
loads
to
try
again,
because
we
know
this
fails
also.
The
way
this
draft
is
worded.
It
looks
more
like
a
layer
to
technology
where
you
redefine
headers
and
mac,
then
an
ip
technology
where
you
can
position
ipv6.
G
F
B
Hello,
this
is
dominic.
I
want
to
concur
with
pascal.
I
think
this
has
been
tried,
as
well
with
the
first
version
of
zigbee.
If
my
memory
serves
this
was
about
16
years
ago,
and
they
had
tree
based
address
allocation
with
ranges
at
each
of
the
intermediate
routers,
where,
where
you
had
to
define
statically
the
depth
and
breadth
of
your
possible
tree,
and
that
was
a
failure,
they
quickly
changed
back
to
other
addressing
systems
that
are
not
related
to
the
to
the
topology.
B
F
F
A
A
Okay,
perhaps
one
last
comment:
we
are
on
the
time
for
starting.
The
next
presentation
is
that
well
also
from
the
point
of
view
of
whether
the
work
would
fit
in
six
law
charter
yeah.
There
is
the
concern
that
nodes
in
the
nsa
domain
are
not
aware
of
their
own
corresponding
ipv6
addresses,
so
perhaps
that
is
a
bit
beyond
or
not
exactly
complying
with
ipv6
right,
at
least
in
the
typical
sense.
A
H
H
Thanks
so
on
this
small
example,
which
is
an
example
of
a
forwarding
of
a
packet
under
the
rlc
4944
fragmentation
mechanism,
there
are
three
main
issues,
some
of
which
have
been
addressed
by
following
rss,
but
the
main
one
is
that
the
loss
of
any
fragment
entails
the
failure
or
the
full
transmission
mechanism.
So
if
any
fragment
is
lost,
it
will
mean
that
all
the
transmissions
that
have
occurred
before
will
have
been
done
in
vain.
H
H
So
the
fragment
forwarding
draft
the
rsc
receiver,
knight
8930,
has
addressed
some
of
the
issues
of
the
rsc
for
14
944,
mainly
with
the
addition
of
the
virtual
assembly
buffer,
which
allows
to
avoid
reassembling
the
packets
at
each
hop.
This
has
improved
greatly
the
latency
the
memory
usage
of
the
nodes,
but
still
we
have
this.
One
main
issue
that
I
just
talked
about,
which
is
one
loss,
fragment,
means
that
the
whole
packet
is
lost
and
I
will
now
propose
introduce
introduce
you
to
the
forward
error
correction
principle.
H
H
There
is
a
different
approach,
which
is,
let's
make
our
first
try
and
with
requests
to
the
source
node.
Let's,
let's
correct
the
the
losses
that
we
have
suffered,
the
forward
error
correction
principle
is
a
different
idea
where
we
really
try
to
make
the
first
attempt
successful.
So
there
are
two
type
of
effect.
H
So
we
have
three
propositions
of
fake
for
six
separate
fermentation
and
at
the
end,
if
you,
if
you
are
interested,
you
can
talk
about
one
article
that
we
found
when
we
worked
on
this
next
slide,
please
so
the
first
fake
proposition
is
quite
simple:
we
called
it.
We
called
it
xerfed
because
it
adds
one
additional
fragment
which
is
generated,
but
by
using
the
the
exclusive
r
operator
on
the
original
fragments
of
the
packet.
H
H
H
Successively
I
mean,
and
if
the
destination
sees
that
one
fragment
is
missing,
but
that
it
still
receives
the
number
of
original
fragments,
it
will
perform
the
recovery
by
performing
the
exhaust
operator
at
the
end.
So
that
way
you
are
able
to
recover
one
of
the
fragments
that
could
have
been
lost
next
slide.
Please.
H
H
Since
you
are
also
sending
a
copy
of
the
first
segment,
the
relay
node
will
be
able
to
create
the
vrb.
Thanks
to
the
routing
information
contained
in
the
ipv6
header
compressed
that
is
contained
in
this
first
segment,
the
vrb
will
be
able
to
be
created
and
the
next
fragments
will
be
able
to
be
forwarded
next
slide,
please.
H
So
that
way,
as
I
said,
the
first
segment
will
be
forwarded
from
the
relay
node
to
the
destination
node,
and
the
second
fragment
will
be
able
also
to
be
forwarded
next
slide.
Please,
and
that
way,
even
if
some
of
the
copies
of
the
fragments
are
not
received
next
slide,
please
we
will.
We
will
be
able
to
recover
and
to
reassemble
the
packet
as
long
as
one
of
one
copy
of
each
fragment
is
received
and
in
case
of
reception,
of
two
copies
of
the
same
fragment.
The
second
copy
will
be
discarded
because
it
will
be
unnecessary.
H
So
obviously,
this
improves
the
reliability
of
the
transmission,
but
also
increase
increases
greatly
the
traffic.
So
we
will
now
propose
a
new
fetch
mechanism
based
on
network
coding.
Next
slide,
please
so,
basically,
it
will
fragment
the
it
will
start
by
fragmenting
the
packet,
as
currently
done
by
the
fragmentation
mechanism.
Next
slide,
please
so
the
orange,
the
original
fragments
will
still
be
generated
and
there
will
be
zero.
Padding
added
to
the
last
fragment
next
slide.
Please,
and
what
will
happen?
H
Is
we
use
an
encoding
algorithm
based
on
finite
field,
arithmetic
which
have
the
important
property
where
you
only
need
the
same
number
of
original
fragments
to
be
received
in
order
to
be
able
to
reassemble
the
packets?
So
in
this
example,
we
have
three
original
fragments
and
five
encoded
fragments
and
you
can
receive
any
combination
of
the
of
three
of
the
five
encoded
fragments
in
a
bowl
in
order
to
be
able
to
recover
the
packet.
H
H
H
The
second
one
contains
the
working
information
which
will
allow
to
forward
itself
next
slide.
Please
and
all
the
other
fragments
will
be
able
to
be
forwarded
thanks
to
this
routine
information,
and
any
combination
of
four
fragments
would
have
make
enabled
us
to
recover
the
fragments.
In
that
case,
it
happens
to
be
the
fragments
number
two,
three
four
and
five
and
we're
about
to
decode
these
fragments
in
order
to
reassemble
the
packet
next
slide,
please!
A
Yeah,
so
thank
you
for
the
presentation.
We
are
past
our
agenda
time,
so
we'll
have
unfortunately
no
time
for
discussing
this
today,
but
probably
we
can
continue
and
we
can
discuss
on
the
mailing
list
and
by
the
way,
understanding
is
that
there's
not
yet
an
internet
draft
out
there
for
this,
but
that
you
will
publish
one?