►
From YouTube: IETF102-6LO-20180717-1330
Description
6LO meeting session at IETF102
2018/07/17 1330
https://datatracker.ietf.org/meeting/102/proceedings/
B
C
B
C
C
C
We
have
many
takers
Ryan,
who
thank
you
very
much
and
we
are
looking
for
another
mini
taker:
okay,
Dania,
okay,
Dominic!
Thank
you
very
much.
So
maybe
I
should
have
just
put
your
name
already
and
then
Rahul
Jadhav,
who
has
volunteered
for
Jabbar,
subscribe,
Thank,
You
Rahul,
and
with
that
we
are
going
forward.
C
C
We
have
full
agenda
for
two
hours,
starting
with
the
chair,
slides
and
then
we'll
go
with
Pascal's
presentation
on
our
FC
6775
updates
and
related
ending
updates,
and
then
there
are
several
others
presentation
with
merely
mesh
NFC
update
six
low
applicability
and
there
are
new
drugs
which
are
not
working
group
document.
Yet
then
we
will
address
them
ipv6
for
PLC,
and
then
we
have
work
coming
out
of
the
six
low
fragmentation
recovery,
design
team.
Now
we
have
two
documents
that
are
in
this
working
group.
C
Out
of
that
investigation
that
we
will
discuss
and
at
the
end
we
will
have
a
new
proposal
from
Hudson
Ayres
and
Phil
levees
from
Stanford
University,
and
they
have
an
interesting
investigation
on
low-power
nature
of
the
devices
and
how
that
can
affect
the
interoperability
and
they
have
a
purpose
solution.
So
with
that,
we
will
start
with
draft
status.
C
C
Six
no
ble
mesh,
which
is
another
working
group
document,
Karlis,
has
been
working
on
it
and
now
with
implementations,
it's
in
work
in
progress
and
then
six
low
applicability
and
use
cases
document
we
will
know.
That's
also
may
be
ready
for
working
group
last
fall
after
this
idea
and
then
six
low
deadline
time.
It
has
completed
last
call,
but
no
comments
were
received
as
I
heard
from
Charlie.
If
you
have
comments
still
have
we
have
time
next,
one
we
cut
so
please
provide
comments.
C
Our
otherwise
L
will
do
Shepards
review
and
submit
for
iesg
and
then
finally,
design
team
concluded
for
fragmentation
and
reassembly
at
the
last
IETF,
and
we
came
out
of
three
documents
out
of
that.
One
of
them
is
on
the
implementation,
lightweight
implementation
from
Carsten,
which
is
being
discussed
at
the
lwi,
chill
alight
implementation
group
and
the
two
other
documents
that
are
part
of
six
low
which
are
minimal
fragment,
which
Thomas
will
present
remotely,
and
then
we
will
have
six
low
forwarding
fragments.
So
any
comments.
E
D
F
Okay,
so
this
is
the
usual
unmet
expectation.
It
has
recently
evolved
a
little
bit
because
the
initial
expectation
that
6lowpan
and
he
would
enable
to
register
for
proxy
services
of
our
backbone
with
a
backbone
router
has
been
extended
to
enabling
whatever
method
for
return,
rut
ability,
including
proxy,
but
also
writing
protocols.
F
So
nothing
much
here,
the
family,
it's
a
family
of
three
working
documents.
One
of
them
is
dance,
which
is
must
be
complete.
The
samhita
said
we
get
address
protection
which
is
an
extension
to
it
to
make
it
secure
and
then
the
backbone
water,
which
is
a
proxy
operation
of
our
backbone.
If
that
is
method
that
is
used
or
we
have
SWAT
ability,
okay,
so
the
generic
flow
is
still
in
a
very
complex
network.
F
F
Last
hf
101,
we
were
in
the
middle
of
the
discussion
from
Dave
Farrell's
review,
and
there
was
this
sentence
that
Dave
wanted
to
change
about.
Dave
wanted,
basically
that
we
write
what
network
operator
is.
Administrators
must
do,
which
is
provision
of
resources,
no
network
for
things
to
work
and
further
reviews
which
were
covered
in
18
by
Warren
in
there
ended
up
changing
that
must
again
treat
went
up,
and
then
it
will
bounce.
F
Maria
indicated
to
us
that
the
readability
could
be
better
if
we
just
moved
the
structure
a
little
bit
around.
So
we
also
did
that
in
draft
80
and
quite
right
after
the
HTF
it
was
published.
So
we
also
added
some
clarification
text
about
the
fact
that,
if
the
tea
flag,
which
is
introduced
in
this
back
to
say
that
the
chatting
is
some
value,
the
chief
flag
is
not
said,
then
the
charity
should
be
zero.
F
That's
connected
that's
implicit
by
inheritance
from
AOC
6775,
because
it's
a
result
field,
but
we
had
the
text
to
say
then
pajama
came
in
from
is
review.
The
big
thing
that
happened
is
mostly
that
we
define
much
more
correctly
with
the
rava
field
ears.
So
so
we
ended
up
with
this
new
definition
that
you
can
see
here
and
in
the
final
review
document
that
we
have
now
21.
This
text
is
not
actually
at
the
same
place,
because
this
was
after
Benjamin's
ratio.
F
We
placed
all
this
text
in
the
definition
of
what
robberies
and
in
fact,
if
you
look
at
it,
the
first
sentence
is
the
definition
of
what
it
is
and
the
rest
is
always
operated.
So
as
part
of
Charlie's
work
and
Charlie's
with
you,
we
actually
moved
the
second
part
somewhere
else
in
the
documents
not
lost.
You
just
move
more
in
the
brothel
operation
away
from
the
rather
definition
yeah.
There
was
also
discussion
by
bechamel,
with
a
nonzero
statuses
on
euro
and
yes,
6725,
she's,
very
clear
on
that.
F
And
finally,
the
last
review
was
a
rich,
so
actually
Eric
had
a
lot
of
background
question
about
maybe
having
more
introduction
texts
and
things
like
that.
So
we
added
some
some
clarification
on.
Why
we
do
it
things
like
that
in
the
introduction
and
then
again
some
of
the
text
moved
away
and
that
was
again
part
of
Charlie's
review.
Then
some
of
that
text
has
fallen
into
the
the
appendix
section.
F
So
if
we
didn't
get
a
real
feedback
from
Eric
about
whether
that
text
was
what
you
wanted
and
if
it's
okay,
finally
to
have
moved
down
into
the
appendix,
because
discussion
with
Eric
moved
to
the
AP
and
D
draft
quite
rapidly,
so
he
probably
only
is
G
review,
for
which
I
don't
have
a
clear
excitation
that
we
did
the
right
thing.
So
it
would
be
very
nice
that
we
contacted
rake.
F
F
It's
the
kind
of
comments
we
get
from
Eric
on
this
document,
whose
real.
Why
are
you
doing
this?
So
that's
the
sort
of
text
which
is
now
in
appendix
but
after
Eric's
review
in
89
put
it
in
the
intro
after
Charlie's
review,
it
went
down
into
the
appendix
and
then
we
move
the
discussion
to
AP
and
E
and
that's
what
the
discussion
is
Jo,
but
we
thought
about
here
acceptance
of
the
changes
that
were
made
for
him.
Oh.
F
And
then
there
is
this:
this
dumb
reference
thing
for
which
I
don't
know
what
to
do.
Part
of
the
IHG
review
told
us
that
some
references
we
had
the
terminology
whose
two
should
have
been
that
Adrienne
I
think
should
have
been
normative
reference
because
that's
the
terminology
that
we
are
using.
These
are
Domenici
documents,
but
the
fact
is
those
two
terminology
documents
are
informational.
F
So
if
we
normatively
reference
informational
documents,
then
you
ever
done
ref.
So
how
do
you
do?
How
do
the
other
do
right?
I
mean
what
happens
in
normal
document
when
use
them
energy
from
an
informational
document?
Is
it
an
informational
drive
or
is
it
is
not
much
arrived?
So
I
made
it
a
separate
section
right
now,
so
the
trick
is
I,
have
three
reference:
I
have
normative
terminology
and
info
information,
or
something
like
that.
Yeah
I
know
as
a
shepherd.
F
G
Teri
mandersohn,
not
speaking
for
sure
ish,
but
the
other
in
trad
down
roots,
are
actually
permissible
in
my
ATF
documents.
It
just
needs
the
responsible
ad
to
say
that
it's
okay
to
do
so
it'll,
be
a
discussion.
You'll
have
to
have
with
sure
ish
so
that
that
will
then
stop
the
breakup
of
you,
the
additional
sections
in
the
back
matter,
yeah,
so
I've
talked
with
Ashish,
okay,
okay,.
H
F
A
no-brainer
right,
we
just
move
that
extra
section
back,
including
the
normative,
and
we
all
say
so
what
happens
since
the
last
day?
As
you
review,
you
saw
those
three
versions
were
published
to
my
best
knowledge.
Most
of
it
is
purely
editorial,
even
if
the
change
are
quite
important
and
that
has
to
do
with
Johnny
working
very
hard
on
this
document.
F
So,
as
part
of
this
changed,
my
French
was
turned
into
English.
It's
part
of
it.
The
consistency
of
the
document
was
improved
like
when
you
have
a
section
talking
about
something,
then
all
the
discussion
about
that.
Something
should
be
in
that
section,
not
in
the
definition
or
anyplace
else.
That's
part
of
what
Jerry
said
and
that
I
did
honest
part
of
doing
this.
It
caused
some
progress
which
were
introduced
for
a
review
to
be
actually
split,
doesn't
mean
they
went
away.
It
just
means
they
were
split.
F
F
One
of
the
prime
came
in
really
triggered
by
the
discussion
with
Eric
on
AP
and
D
and
test
to
do
with
the
fact
that
the
rubber
field,
which
is
how
we
protect
the
registration,
can
be
all
the
way
up
to
256
bits.
So
it's
no
more
constrained
to
the
64
bits
of
new
I-64
field,
but
this
thing
goes
into
a
dark
message,
meaning
that
now
the
direct
message
can
be
a
variable
size,
but
the
the
dark
does
not
have
this
rubber
thing
as
an
option.
F
It's
it's
an
integral
part
of
the
every
time
you
send
down
that
part
of
the
message.
Is
this
thing
so,
with
the
only
inversion
of
the
document,
we
just
said
a
look
at
the
total
size
of
the
message,
and
now
that
tells
you
what
is
the
size
of
the
of
the
rubber
inside
about
that?
But
then
came
the
the
need
to
extend
the
attack
with
options
and
we
kept
if,
if
the
size
tells
us
what
the
rubber
is,
then
we
cannot
have
an
option
which
changes
the
size.
F
So
we
said,
hey
we'll,
really
need
to
signal
the
size
of
the
rubber
in
the
dark,
and
so
we
won
scratching
our
heads
on
the
meaningless
and
stuff
and
we
ended
up
indicating
the
size
of
the
rubber
field
as
part
of
the
ICMP
code.
That's
the
best
place
we
found,
because
sometimes
the
rubber
itself
can
be
a
key,
and
you
can't
you
want
to
alignment
and
stuff,
so
you
can't
steal
bits
from
the
key,
so
you
end
up
having
to
signal
it
somewhere
else
and
there
was
not
much
space
left.
F
So
we
decided
that
the
cut
effects
would
be
splitting
the
code
would
put
the
neatest
thing
to
do
it's
consistent
with
the
way
the
dock
was
at
the
time
we
discussed
it
with
Adrian
Farrell,
because
we
had
one
bit
here,
which
was
pretty
much
the
debate
saying:
oh,
it's
so
darn
extended
dock.
Now,
instead
of
having
one
bit,
it's
just
those
four
bits
which
actually
signal
it,
because
we
now
see
you
know:
oh
it's
so
next
and
it
da
plus
the
size
of
the
rubber.
So
it's
not
inconsistent
with
the
way
to
start
initially.
F
F
Yeah
and
the
other
big
thing
was
more
terminology
saying
that
Samhita
already
did
the
big
idiot
at
some
point:
removing
text
about
the
backbone
router,
which
really
was
not
needed
for
this
particular
spec,
was
better
fit
in
the
Bible
righto
text.
Johnny
came
in
with
his
review
and
he
still
thought
we
didn't
go
far
enough
on
that
and
as
he
goes
in
the
meantime,
two
new
pieces
of
works
came
up.
One
of
them
is
role.
F
Now
we
can
use
this
document
in
a
6lowpan
node
to
register
to
a
sick
seller,
which
is
a
ripple
device
and
with
thanks
to
this
draft,
the
repo
device,
the
ripple
router,
can
inject
the
registration
into
ripple.
So
it's
kind
of
free
distributing
six
up
an
mg
into
repo.
So
now
the
device
by
just
doing
the
six
dependency
of
registration
can
get
routing
back
from
a
repo
network.
So
that's
kind
of
that's
different
from
a
6
DB
R,
which
is
a
proxy.
F
So
it's
a
second
type
of
thing,
with
reverse
route
ability
you
can
get
from
the
registration.
There
is
a
third
one,
the
other
draft,
which
is
actually
a
working
group
document,
as
we
retrieved
also
references.
This
work
as
the
way
to
register
to
route
and
say
there
is
a
sequence
number:
if
you
have
a
mobile
device,
then
it
moves
from
report,
another
port
or
it's
Wireless
or
whatever
it's
quite
important
for
the
routing
protocol
to
know
what
is
the
latest
location
of
your
device?
F
And
that's
that's
one
of
this
thing
that
sick
slapping
Andy
does
it
when
you
register
to
something
you
increment
sequence
number
which
is
injected
in
River
all
naturally,
but
it's
also
injected
in
right
now.
So
that's
how
a
rich
fabric
knows
the
latest
location
of
a
VM
or
something
like
that,
so
because
it
was
no
more
just
the
registration
backbone
router.
We
could
not
really
keep
mentioning
bad
blood
writers,
who
are
the
documents,
and
that
was
really
one
of
the
big
thing
that
Charlie
was
pushing
hard
to
do
so
dr.
Suresh.
F
Actually
that
was,
we
had
an
exchange
there,
because
I
was
kind
of
predicted
to
the
change
like
that
in
the
document.
At
the
point
of
time,
yeah
well,
Charlie
I
ended
up
convincing.
It's
mostly
a
change.
All
six
bbl
goes
away,
and
there
is
this
new
term
watching
registrar.
So
you
register
to
a
router
of
some
form,
something
which
in
the
routing
for
you,
then
you
get
the
packets
back.
F
The
one
thing
which
came
at
the
same
time
is
actually
because
of
one
of
those
two
drafts
I
mentioned,
actually
to
offer
both
for
rift
and
for
repo.
Is
those
protocols
allow
you
to
do
multiple
jarate?
So
you
can
inject?
There
can
be
multiple
logical
topologies
on
your
writing
fabric.
Without
a
ripple,
it's
called
an
instance
or
if
it's
wrapped.
F
So
if,
if
the
node
has
a
clue
about
which
instance
it
would
like
to
live
in,
then
it
should
be
able
to
indicate
that
in
the
registration
and
theories
of
bite
here,
so
we
decided
to
make
it
a
no
back
and
what
it
really
is
is
a
way
for
the
6lowpan
node
to
signal,
for
instance,
ripple,
but
it
want
to
live.
It
wants
to
live
in
this
particular
instance,
and
then
there
is
the
default,
which
is
the
default
instance.
F
F
E
Carolyn
so
recently
on
the
six-man
list.
This
recurring
discussion
about
64
is
as
flared
up
again
and
one
of
the
dominant
arguments.
4/1
27s
is
that
routers
are
subject
to
resource
exhaustion,
attacks
from
classical
ND
and
that
you
know
using
slash
127
as
an
attempt
to
sort
of
insulate
backbone.
Routers
from
from
this
possibility,
I'm
just
wondering
whether
you
guys
have
discussed
or
thought
about
backporting
any
of
these
features,
the
classic
you
know
nd.
I
I
The
different
communities
different
sub
communities
that
people
that
only
care
about
phones,
Wi-Fi
in
Internet
and
like
oh
there's,
six
law,
that's
a
different
universe.
So
I
should
be
even
worry
about
that
stuff.
Go
away
right
so
and
and
I
think
that
that's
suboptimal.
But
but
it's
a
state
of
things
so
I
mean
they
don't
they
have
been
drafts
to
get
the
various
Jeff
said:
I
authored,
co-authored
in
the
space
to
move
it
along
and
then
there
might
still
be
opportunity
could
do
stuff.
I
One
of
the
things
that
people
have
pointed
out-
and
it
keeps
on
showing
out
is
that
the
implicit
address
detection
is
expensive
because
it
takes
a
second.
If
you
follow
this
back
right,
so
this
showed
up
in
in
some
discussions
in
IP
wave
as
well
saying.
Okay,
if
you
follow
the
spec,
we
wait
for
a
second
to
tell
the
car
that
we
ship
when
I
talk
to
it
and
start
a
secured
exchange
to
tell
us
that
we're
getting
the
breaks
right.
I
know
that
doesn't
work
right.
So.
I
So
there
might
be
opportunities
to
go.
Do
something
about
that
particular
dad
thing,
the
other
one,
the
/
127
/
120.
There
are
seas.
That
say
this
is
reasonable:
operational
practices
under
these
constraints.
Right
and
yes,
six
man
keeps
on
spending
time
on
the
stuff,
but
right
but
I.
He
deployed
now
Eric's
Radha
Radha
links
as
far
as
I
know.
In
many
cases
they
use
longer
than
/
1,
/
6
diversion,
but.
F
I
must
also
say
that
since
discussion,
actually
we
got
Lorenzo
in
this
room
who
asked
us
to
do
some
changes
which
we
made
and
I
hope
that
makes
the
spec
more
acceptable
now
than
it
was
at
the
time.
So
we'll
see
I
mean,
but
let's
conclude
it
here
and
and
then
see
what
we
can
do
at
six
man
with
it
did.
F
And
yes,
we
are
the
spec
that
is
mandatory
to
implement
in
Wi-Fi,
so
putting
things
together
at
some
point
should
make
sense,
so
not
I
mean
sometimes
it
take.
10
takes
10
years
right.
We
are
not
there
yet
for
the
registration,
we're
there
for
the
fragmentation,
and
you
see
now
it's
coming
so
we'll
see.
Lorenzo
is
coming
as
well.
J
F
J
J
J
F
F
C
For
this
particular
request,
we
have
heard
this
question
at
least
few
times
in
different
contexts
and
I
think
it
in
conclusion.
I
think
it
would
be
good
to
discuss
it
again
with
our
Eddings
C
and
the
six-man
chairs
to
see
if
there
is
any,
even
if
we
can
revive
any
work
from
the
past
that
that
was
kind
of
now
put
in
in
the
back
burner.
D
F
So
eye
candy
we
had
interesting
talks
with
I
engage
moieties
in
the
room,
I
think.
But
please
correct
me
if
I'm
wrong,
but
what
I
got
is
I
understand.
The
trick
is
happening
with
the
fact
that
we
can
carry
robber
of
128
or
256
and
he
understands-
and
he
agrees
that
we
can
protect
what
we
want
to
protect
with
that.
F
There
were,
there
was
a
left-to-right
right-to-left
issue
which
we
solved
actually
Mike
found
out
that
usually
we
when,
when
you
truncate
a
token
and
you
truncate,
left
to
right,
but
not
in
6775,
with
truncated,
right
to
left
or
something
so
did,
and
in
a
PNG
we
did
the
other
way
around.
So
it
was
kind
of
bizarre,
so
we
align
the
two
specs
and
we
do
the
normal
life
to
write
operation.
F
So,
for
instance,
if
you
have
this
case
where
your
your
6lb
are
is
not
graded
to
your
date,
so
it
only
blows
64
bits,
ey
64,
you
have
to
truncate
the
rover
yeah
that
still
allows
you
to
check
that
it
looks
like
the
same
Rover,
at
least
for
those
64
bits.
But
if
you
want
to
validate
it
as
a
key,
you
need
on
the
6.
That
is
the
middle
thing,
but
just
to
post
it
on
the
6
lbr
and
maintain
that
not
the
classical
operation
of
the
6
MB
or
you
have
to
truncate
around.
F
So
we
fixed
it.
So
the
truncation
is
the
same
as
usual
and
that
that
was
done.
For
last
time,
we
actually
aligned
our
options
to
sailed.
We
are
different
and
that
was
consuming
more
option
space.
So
we
said
hey.
Why
don't
we
overload
the
said
options
and
use
the
same
numbering?
Space
just
extend
the
name,
for
instance,.
F
1C
j
option
when
one
of
the
same
options
was
called
eros
a
right.
We
are
doing
analytic
elliptic
curve,
so
we
could
not
have
an
option
called
where
I
say,
but
I
mean
just
change.
The
name
use
the
same
code,
just
say
it's
overloaded
and
that's
what
we
did.
So,
if
there's
a
primary
that
just
let
us
know,
but
the
alternate
is
to
consume
more
spacing
in
there
and.
F
Yes,
there's
still
this
discussion
about
about
how
we
encode
the
key
and
whatever
the
question
by
a
rake
in
this
discussion,
is
that
if
you're
using
a
leaky,
you
see
keys,
you
don't
even
need
to
use
any
of
those
complex
there
or
about
gwk
banker.
Dings
yeah!
Well,
that's
beyond
me
right
so
I
hope
that
connect
helps
us
when
the
joints
or
something
or
many
more
it
sorts
it
out.
But
the
encoding
of
the
key
is
way
beyond
me.
F
H
F
Now
we
should
focus
on
backbone,
router,
it's
a
big
thing
and
I
know
Johnny
at
least
as
some
work
he
wants
to
do
on
there
as
well
yeah.
So
let's
do
backbone.
Router.
Let
give
us
time
for
the
security
aspect
of
Achim.
We
have
close
I
mean
we
have
the
right
options
now,
which
was
not
the
case
earlier.
We
we
have
a
good
feeling
of
what
it
does,
but
edition
wise.
It's
not
dependent.
You
only
wanted
one
years
ago
and
we
discussed
that
last
time
open.
F
Yes,
so
there
is,
there
was
this
earth
built
that
we
added
in
6lowpan
Andy
right,
our
c7
centric
update
to
indicate
I
want
swatting
when
we
had
twinkle
that
in
the
backbone
router
to
say
oh
now,
I'm
doing
watching.
If
there
was
the
abbot's
in
millimeter,
they
want
to
do
it.
That's
pretty
much
the
only
change,
then
we
get
some
clarification
text
and
I
expect
that
if
charlie
is
start
spending
the
same
kind
of
time,
he
spent
on
the
other
draft,
and
that
would
be
a
big
addition
on
just
making
it
clear
and
concise
ER.
F
L
C
B
M
Okay,
so,
first
of
all,
let's
take
a
look
at
the
status
of
the
document,
so
the
last
date
is
0
3,
which
was
published
a
couple
of
weeks
ago.
So,
as
you
may
have
noticed,
that
document
had
not
been
updated
for
a
while.
That's
because
the
previous
version,
0
2,
had
been
considered
stable
by
the
authors,
then
we
thought
it
would
be
a
good
idea
to
validate
the
draft.
My
means
are
having
some
running
code
before
actually
requesting
working
group
last
call.
M
M
Well,
several
simultaneous
due
to
global
regime
connections
and
unfortunately,
there's
not
a
solution
to
that
issue.
As
of
today,
however,
fortunately,
we
found
another
approach
which
is
using
bleach
as
the
basis
for
our
scenario.
So
bleach
is
an
RFC
2616,
open
source
implementation
for
Kentucky,
and
we
have
been
able
to
locally
reproduce
a
UPC
one
scenario
comprising
a
signal
beer
and
several
six
lines.
Communicating
simultaneously.
M
M
So
now,
let's
take
a
look
at
the
the
updates
in
zero
three.
So
first
of
all,
we
have
a
new
author
micro
sport
from
the
brass
University
of
Technology
in
Austria,
who
is
also
the
main
author
of
bleach,
and
we
also
have
a
new
contributor
who's,
also
from
the
same
University,
and
also
related
with
the
bleach
effort.
So
we
have
some
technical
update
in
zero
three,
which
arises
from
the
fact
that
in
the
previous
version
in
zero,
two,
we
assume
a
network
with
already
established
yearly
link
layer
connections.
M
However,
in
zero
three,
now
we
detail,
which
is
the
relationship
between
6lowpan
rooms
and
IPS
Piero's
for
connection
establishment.
By
the
way,
you
recall
that
the
IPS
P
is
the
Bluetooth
profile
that
defines
functionality
for
link
layer
connections
and
discovery
of
devices
that
support
ipv6
over
Bluetooth
Low
Energy.
So,
as
a
result,
we
have
added
text
in
the
section
that
deals
with
labor
discovery.
That's
3,
3
2,
and
we
have
also
added
an
appendix
with
an
example.
M
So,
more
specifically
in
the
neighbor
discovery
section,
we
have
added
item
3b.
That's
because
section
6,
2
of
RFC
6775
states
that
for
dynamic
configured
scenarios
a
6lr
comes
up
first
as
a
non
router.
Then
it
waits
until
it
receives
an
array
to
configure
it
so
interface
address
and
then
finally
terms
to
a
router.
So
in
order
to
support
the
same
operation,
the
idea
is
that
in
our
draft
6lr
starts
by
using
the
IPSP
node
row.
Only
then
this
means
that
the
device
will
advertise
its
presence
by
sending
merely
advertisements.
M
Then
some
previously
existing
IP
router
will
be
able
to
detect
these
advertisements
and
will
initiate
the
establishment
of
buley
connection
really
link
layer
connection
with
the
sips
alarm,
then
at
some
moment
it
will
be
possible
for
the
router
to
send
a
router
advertisement
which
will
be
received
by
the
seller,
which
will
then
configure
its
interface
address,
turn
into
router
and
then
we'll
start
running
also
as
an
IP
SP
router.
So
for
all
these
to
work,
the
idea
is
that
the
6l
gr
needs
to
be
running
from
the
beginning
as
an
IP
SP
router.
M
So
here
we
have
some
slides
that
illustrate
well
the
example
we
have
in
an
appendix
which
try
to
illustrate
an
instance
of
this
behavior.
So
initially,
let's
assume
we
have
all
these
devices
with
this
6lowpan
intended
roles,
and,
let's
assume
that
at
the
beginning
they
are
not
initialized,
except
for
the
six
LDR
which
starts
from
the
beginning.
Let's
say
running
as
an
IP,
SP
router
then
next
place
at
some
moment.
Let's
assume
that
see
6lr
starts
running
initially.
M
So
at
that
moment
the
6lr
can
start
running
as
an
IP
SP
router
and,
on
the
other
hand,
whether
it
continues
or
not
running
the
as
an
IEP
SP
note
in
parallel
is
an
implementation
choice.
Okay,
so
this
is
allowed
by
the
IPS
PA
specification
and
at
our
six
low
level
this
would
be
something
to
choose
from
so
at
that
moment,
we'd
assume
the
rest
of
the
devices
the
six
lines.
M
Some
woman
will
start
also
running
in
this
case
only
as
I
PSP
notes
and
now
it
means
that
the
6lr,
but
some
woman
will
detect
the
presence
of
the
city
lines
and
will
be
able
to
initiate
the
establishment
of
linear
connections.
Similarly
to
the
process
we
have
seen
before,
for
the
signal
be
ours
and
the
6lr.
F
M
M
Okay,
so
one
slide
about
related
work,
basically
because
there
have
been
some
questions
on
this
in
previous
meetings
about
which
is
the
relationship
between
this
work.
We
are
doing
here
and
also
the
Bluetooth
low-energy
network
happening
at
the
Bluetooth
si
G.
So
last
year
there
was
a
set
of
specifications,
I
mean
one
being
called
Brutus
mesh
published,
which
enable
Billy
mesh
networking
which
allow
well.
This
is
actually
a
complete
protocol
stack
which
uses
control
floating
over
advertising
channels
as
the
technique
to
enable
end
to
end
communication
in
a
multi
hop
scenario.
M
One
related
note
here
is
that
our
season
is
six
sixty
eight,
which
is
also
the
basis
for
our
drugs,
assumes
linear
connections
of
a
dated
channels
over
for
ipv6
over
really
so
it
means
well
dated
channels
are
a
different
story
with
different
formats
and
currently
the
IDF.
We
don't
have
a
way
to
carry
actively
six
packets
over
advertising
channels,
so
anyway,
it
appears
that
the
current
scenario
is
that
we
have
at
least
two
options
to
create
Bluetooth
Low
Energy
mesh
networks,
the
one
defined
by
the
Bluetooth
si
G
and
the
one
we
are
enabling
here.
C
M
D
N
N
O
O
Yeah
so
three
years
ago,
or
this
document
was
adopted
and
the
working
group
document-
so
this
is
dr.
Libby
John,
so
I
would
like
to
emphasize
the
goal
of
this
document.
This
document
is
not
a
technical
document,
it
is
information
document.
So
the
purpose
of
this
document
is
to
help
other
person
to
understand
the
six
road
canal
gist
and
how
to
deploy
this
technology
into
the
real
world.
So
it's
the
region
so
to
do
this
or
the
many
person
are
attending
to
developing
this
draft
domain.
O
Also
of
the
six
role
of
a
pure
document
and
other
person
from,
for
example,
jupyter
mesh,
and
why
son
and
since
repairs
he
and
adversity
experts
I
hope
to
develop
this
document.
So
what
is
the
update
part
after
last
meeting?
So
there
is
nothing
to
add
a
new
newly.
We
are
only
trade.
Two
parts,
one
part
is
the
LT
MPC.
So
you
know
in
the
bidding
time
the
health
is
the
MD
she
was
included
in
our
web,
but
in
South
Korea,
it's
specially
to
ask
a
telecom.
O
We
deploy
our
TPMS
in
Korea
and
we
found
the
dead
sea.
Froth
technology
is
not
needed
to
deploy
LT
MTG,
because
every
MPC
is
served
on
support,
ipv6
transmission,
so
LT
MTC
is
not
related
to
six-row
technology.
That
region
with
the
LT
empties
part
and
the
reference.
Do
we
founded
that
MV
IOT
case?
It
is
baby,
some
kind
of
dodgy
flow
technology,
but
MB
IOT
is
heard
in
the
LP.
Double
am
working
room,
so
I
do
not
hinder
the
Mbit
in
this
document
and
we
also
trade
six
ropers
references.
O
The
reason
is
to
eat
what
expired
so
I
hoped
on
you,
I
founded
the
new
six
Rob
pearcy
document
was
raised
and
I
know
that
the
Bingley
you
will
pretend
so
I
hope.
Autistics
repair
document
was
adopted
as
a
working
group
document,
because,
though,
in
the
real
world,
for
example,
disrepair
see
and
they
twisted
I
based
on
the
Piercy
technology,
so
I
hope
the
Pierce
document
was
adopted
as
a
working
document.
O
So
in
my
side
the
remaining
work
is
part.
One
is
to
update
the
tricity
of
the
currently.
The
trustee
is
the
it
is
the
home
plug
power
of
Alliance
support
and
internally.
It
is
transferring
to
my
son
Alliance,
but
there
is
no
official
of
announcement,
so
this
region,
I,
keep
on
ethnicity,
is
the
home
from
low
power
line
compliance.
O
O
N
O
To
the
working
group
at
option,
F
March
2015,
we
have
five
times
revision
and
four
times
revision
for
working
last
call
and
make
sure
at
the
moment.
At
the
moment,
this
document
is
working
narco
since
March
2018
and
there's
no
more
filter
from
the
FC
forum
since
the
January
2017,
and
we
have
a
new
Shepherd
Santa
Santa,
give
me
the
review
of
this
document
for
number
number,
nine
and
I
just
produced
the
number
ten
will
be
published
as
possible
because
I
just
get
the
review
after
the
total
submission
is
inspired
today.
O
N
O
O
O
And
the
last
one
is,
she
gives
a
comment
about
the
the
secret
concentration
actually
just
put
the
last
two
paragraphs.
She
gave
the
comment
just
this:
that
distance
Tocqueville
should
caution
about
the
three
before
the
main
in
the
middle
attack
and
when
the
NFC
device
connecting
offered
in
the
Internet
so
just
put
some
text
in
the
end.
At
the
end
of
the
section
seven
and
she
gave
me,
the
device
text
I
just
ripped
to
put
the
whole
the
text
from
her.
C
So
any
comments
so
Gabriel
and
I
discussed
about
the
changes
in
this
document.
So
originally
there
were
many
shells
in
this
document
all
over
the
document,
so
I
requested
a
younghoon
to
change
them
appropriately
to
shoot
masked
recommended
not
recommended.
So
he
has
made
those
changes.
What
we
discussed
Gabriel
and
I
that
it
would
be
appropriate
that
it
should
go
for
one
week
short
last
call
in
the
working
group.
So
please
we
will
will
do
that
probably
immediately
today
or
tomorrow,
and
there's
providers
comments.
B
L
L
The
address
auto-configuration
configuration
and
mapping
mechanisms
have
been
included
instruct
and
the
related
features
in
the
RFC
6775
update
has
been
introduced
to
this
draft
for
deeper
discovery
of
PLC
devices
and
Charlie.
Perkins
and
and
I
have
become
the
Colossus
of
this
draft
next
page
place
and
for
the
actual
body
in
1901
dot
one.
It
is
a
newly
published
a
triple
a
PLC
standard
by
the
smart,
great
parent
communication
working
group,
and
it
works
in
the
medium
frequency
it
has
following
characteristics,
is
supposed
post,
TDMA
and
CSMA
in
the
frame
into
it.
L
Utilize
the
OFDM
multi
modulation,
to
do
ways
the
inference
on
the
paradise,
and
it
also
supports
the
fragmentation
and
their
assembly.
Data
retransmission
and
multiple
ways
of
encryption
and
four
levels
of
priority
of
different
cues
and
the
data
rates
of
atropine
and
vo
1.1
can
be
up
to
2
megabits
per
second
next
page.
Please
and
the
for
the
state
address
auto-configuration.
L
The
interface
ID
can
be
derived
from
the
democracy
which
which,
which
can
be
the
UI
64
ID
or
the
48-bit
MAC
address,
and
which
can
be
extended
to
64-bit
by
inserting
the
fffe
in
the
middle
and
the
UN
help.
It
should
be
set
1
to
indicate
that
it
is
a
unique
address
and
the
GI
beat
should
be
set
to
0
and
another
option
2
for
state
is
authorized.
Little
configuration
is
to
derive
the
interface
ID
from
the
shorter
dresses
questions.
Yes,.
E
E
So
yeah,
so
one
thing
you
might
run
into
as
this
gets
further
down.
The
pike
is
pushback
from
iesg
on
the
privacy
aspects
of
this.
So
one
thing
you
can
look
at
is
the
way
that
I
finessed
this
in
6
low
back.
This
is
fine,
I
think
for
link
local
traffic
yeah.
But
if
you
start,
you
know,
you
I,
think
you're
gonna
get
resistance
for
using
this
scheme
for
routable
traffic
because
there's
you
know
just
a
lot
of
concern
about
exposing
hardware
addresses
in
ipv6.
L
Another
option
is
to
devise
the
the
interface
ID
from
from
shorter
crises,
and
here
are
the
4
meters
that
were
defined
in
this
draft.
The
difference
between
the
difference
comes
from
a
different
combination
of
shorter
races
for
different
PRC
standards
and
the
will
and
help
it
and
the
job
it
should
be
set
to
zero,
and
it
should
be
a
clear
iodide.
L
The
UNL
and
Jia
beat
should
not
must
not
used
to
generate
an
idea,
also
parity,
to
avoid
any
beauty.
Next
page,
please,
and
for
unicast
mapping,
link
a
link
layer.
Address
option
are
defined
which
can
be
used
for
the
nipper
discovery,
entry,
soft
link,
layer,
dress
and
to
surprise
the
broadcast
in
Liberty
scurry
messages.
L
L
And
the
updated
plc
devices
should
include
the
e
in
the
neighbor
solicitation,
so
here
I
mean
me
personally
station
instead
of
an
altar
solicitation
and
and
that
the
arbiter
should,
besides
to
1.
If
the
PLC
device
can
be
act,
it
is
done
if
the
device
is
not
a,
it
is
not
a
rotor
and
the
arbiter
should
be
sacked
1
if
the
device
is
in
charge
of
from
cell
0.
L
If
the
device
is
in
charge
of
its
own,
which
ability
and
the
updated
PLC
device
should
use
should
used
year
all
to
attract
the
status
registration
from
the
neighbor
advertisement
message
and
the
daily
can
be
proxied
to
routing
register
which
may
operate
in
optimistic,
the
and
the
Falls
to
achieve
the
back
of
our
community
to
our
FC
6775.
Only
POC
devices,
the
door
of
64
bits
must
be
used
and
next
pitch
place.
L
C
L
C
C
D
D
N
F
F
Part
of
the
fragment
recovery
is
to
expose
a
bitmap
which
is
pretty
similar
to
what
we
do
in
LP,
one
of
which
fragments
were
received
and
which
one
were
not.
We
also
enable
windowing
systems
so
that
you
can
limit
the
number
of
fragments
which
are
in
the
air
and
avoid
congestion.
The
network
use
initial
bid
to
actually
see
now.
That
looks
like.
F
On
each
fragment
can
actually
don't
have
to
to
have
one
fragment
in
one
fragment
out
the
reason
why
it
would
happen
that
way
years,
6lowpan
compression
may
not
happen
the
same
way
when
the
packet
goes
here
and
comes
in
and
when
the
packet
goes
out.
Reason
is,
for
instance,
that
if
you
shall
one
hop
away
from
the
source,
the
source
may
choose
the
MAC
address.
F
They
are
till
to
compress
the
IP
address
of
the
earth
right,
but
once
you
for
the
fragmented
compression
doesn't
work
anymore,
you
have
to
put
the
four
IP
addresses
source,
so
you
end
up
with
a
packet
which
is
smaller
on
the
first
hop
than
later.
If
you
fill
up
this
packet
without
any
slack
in
your
room,
then
the
next
heart
has
to
truncate
the
fragment,
keep
some
of
it
for
next
time
and
forward
what
it
has
with
now
the
full
ipv6
address
and
compressions.
It's
not
bad.
So
that's
a
very
sad
thing.
F
Anyway,
the
fragment
recovery
cannot
work
like
that,
because
you
signal
individual
fragments
that
you
have
not
received,
so
you
want
the
the
bit,
which
means
fragment
five
to
mean
the
same
thing
at
the
source
and
the
destination.
You
can't
redo
when
you
fragment
on
the
fly
in
the
middle,
so
with
this
draft
compared
to
the
generic
virtual
buffer
that
Caston
and
tomorrow
writing
on
it.
P
F
The
market
I
had
to
to
insist
that
if
you
have
this
kind
of
network,
where
the
six
top
end
compression
is
that
the
same
all
along
and
you
need
to
have
slack,
then
you
put
the
slack
on
the
first
fragment
so
as
you
follow
the
first
fragment
which,
which
was
where
the
6lowpan
compression
happens
anyway,
if
the
size
of
the
6lowpan
compressed
thing
changes,
you
don't
change
the
content,
the
data
piece
of
the
fragment,
so
all
the
next
fragments
are
forwarded
in
their
integrity.
They
are
not.
You
know
you,
don't
we
split
the
fragments.
F
So
that's
that's
just
a
new
text
that
discussion
now.
My
thinking
is
that
this
should
be
true.
Regardless
I
mean
having
to
change
what
the
death
the
fragrance
are
in
flight.
In
that
send
the
exact
same
data
gram
in
and
out,
but
that's
additional
complexity.
I,
don't
see
the
value.
I
think
the
slack
should
always
be
in
the
first
fragment,
but
that
just
me.
K
Rahul
shadow
from
Harvey
techno,
so
we
are
implementing
this
in
production
code.
Actually,
the
fragment
forwarding
technique
and
we
are
using
the
slack.
We
have
to
keep
slack
for
the
first,
not
only
for
the
addresses,
but
for
the
fields
as
well,
for
example
TTL,
which
has
to
be
changed
on
power
bases.
So
that
also
has
to
be
changing.
So
you
put
this
like
in
the
future.
F
P
P
P
We
have
won
an
elegant
well
in
in
six
low,
the
one
and
L
week
that
discusses
the
implementation
technique
of
fragment
forwarding
the
first
one
and
six
low
draft
number
two
here
details
the
context
and
what
a
fragment
forwarding
is,
and
you
know
what
what
is
currently
defined,
what
needs
to
be
defined
if
anything
and
then
the
third
one
does
fragment
recovery,
which
is
what
Pascal
just
presented
so
I
last
IETF
I
think
we
said
we
wanted
to
close
the
design
team.
As
soon
as
those
drafts
were
adopted,
the
L
week
document
has
been
adopted.
P
The
two
other
ones
who
have
not
been
adopted
so
I
believe
that
the
team
is
still
open
and
I
know.
The
goal
here
is
to
to
ask
the
chairs
whether
they
want
to
adopt
these
drafts
and
we
chose
a
design
team
or
whether
they
we
don't
know
what
the
two
to
adopt
these
drafts,
and
we
still
frozen
to.
Thank
you.
P
So
the
next
slide,
this
next
part,
is
on
the
minimal
fragment
fording,
which
is
next
piece
which
is
giving
some
context
about
what
is
being
what
is
being
what
is
being
defined
now
I,
don't
know
something
that
maybe
you
can
move
move
forward
to
slides
yep.
Thank
you.
So
we
posted
a
in
version
Pascal
myself
a
couple
of
days
ago,
where
we
we
highlight
the
limits
of
per
hop,
reassembly
fragmentation
and
reassembly,
and
then
we
discuss
the
ERP
implementation
and
its
limits
and
the
VMP
vrb
implementation
is
being
discussed
in
the
Elric
draft
love.
P
That
person
has
next
slide.
Please
so
here
again
reiterating
what
the
three
pieces
are.
The
L
wick
draft
details
and
implementation
technique
called
VRB.
This
drive
this
car,
a
Hubert,
anus
Expo,
provides
more
review
of
what's
happening
and
and
the
Highlands
limits
and
then
Pascal's
Draft
adds
a
defines
a
new
protocol
to
do
end-to-end
acting
and
recover
fragments
next
slide.
Please
that's
my
last
slide,
so
the
author's
has
a
600
chairs
to
call
forward
reproduction
off
of
this
draft.
That's
I
hope
this
answers.
Your
question
Kerry
and
I'm
happy
to
great.
D
D
D
C
Q
Q
So
some
of
the
motivation
for
this
research
is
we're
surrounded
and
the
idea
that
interoperability
is
crucial
for
IOT
devices
and
for
low-power
embedded
protocols
and
while
working
on
the
on
a
six-legged
implementation
for
the
talk
embedded
operating
system.
We
started
looking
into
the
6lowpan
implementations
of
several
other
open-source
operating
systems
and
we
found
a
lot
variation
and
ultimately
that
inspired
us
to
do
a
interoperability
study
into
five
open
source
implementations,
specifically
contiki
arm
embed,
riot,
tiny,
OS
and
open
thread.
Q
And
I'm
gonna
elaborate
on
this
a
little
bit
more
later.
But
we
think
that
one
of
the
primary
reasons
for
this
is
actually
due
to
some
of
the
constraints
on
code,
size
and
RAM
as
well,
and
so
the
internet
draft
that
I
presented
it
is
associated
with
this
talk
talks
about
some
principle,
designs
and
guidelines
that
can
anticipate
problems
in
this
space
and
we
hope
that
this
informational.
Q
So
this
is
an
outline
I,
already
sort
of
previewed
everything
here,
but
I'm
gonna
elaborate,
some
more
on
the
motivation
and
the
specific
findings
that
we
had
I'm
gonna
go
into.
My
four
design
guidelines
and
I'm
gonna
illustrate
them
through
example,
application
to
6lowpan
and
then
conclude
with
some
discussion,
see
what
you
guys
think
and
some
of
the
takeaways
that
we
had
from
our
original
results.
Q
Q
Q
In
order
to
be,
you
know,
considered
a
full
6lowpan
implementation
so
stuff,
like
you,
know,
stateless
address,
compression
and
UDP
port
compression
in
a
you
know,
you
know,
support
for
the
mesh
and
broadcast
headers,
etc,
and
when
we
looked
at
all
of
these
implementations,
one
thing
that
we
found
was
that
none
of
them,
actually,
you
know,
seems
to
implement
every
single
feature,
at
least
correctly,
as
described
in
the
specifications,
and
also
that,
for
these
five
stacks,
the
missing
feature.
Support
was
actually
mismatched
so
well,
you
know
some
stacks
would
support.
Q
One
thing
others
might
not
and
that
sort
of
to
us
seem
to
indicate
somewhat
of
a
problem,
and
so
we
investigated
a
little
further
and
we
flashed
some
of
these
operating
systems
and
some
there
example,
six
locally
and
applications
on
different
embedded
boards
and
tried
to
send
packets
back
and
forth,
and
for
many
of
the
sort
of
common,
more
simple
use
cases.
We
found
that
it
worked
fine,
but
we
would
find
that
for
certain
packets
that
might
be
compressed
in
a
certain
way.
Q
We
would
suddenly
have
silent
network
layer
drops
so,
for
instance,
from
an
embed
OS
device
communicating
with
a
contiki
device.
If
given
6lowpan
packet
contained
an
ipv6
extension
header
embed
would
compress
the
extension
header
according
to
the
guidelines
and
RFC
6282
and
Contiki
would
not
be
able
to
parse
that
and
would
respond
with
link
layer
acknowledgments
but
then
would
not
respond
because
it
would
with
any
application
data,
because
it
would.
These
packets
would
then
be
silent
about
the
network
layer.
Q
We
found
that
we
were
able
to
actually
produce
sort
of
a
lot
of
examples
of
this
with
you
know
the
five
stacks
that
we
looked
at
and
some
of
the
different
features
described
earlier
6lowpan
table,
and
we
thought
there
might
be
a
few
possible
reasons
why
this
is
the
case.
You
know,
of
course
these
are
open
source
stacks
and
you
know
6lowpan
has
changed
a
lot
in
the
ten
years
since
2008.
Q
So
perhaps
we
thought-
maybe
those
could
be
the
reasons,
and
you
know
you
know,
there's
not
necessarily
an
established
reference
implementation
like
you
know,
for
instance,
the
Linux
TCP
stack
that
many
people
might
look
to
when
implementing
their
own
TCP
stack.
But
ultimately
we
don't
really
think
these
are
actually
the
primary
reasons
I
mean
if
they
might
have
contributed,
and
instead
we
think
that
a
big
part
of
it
is
due
to
concerns
by
the
designers.
Q
Q
We
would
find
if
deaths
in
a
lot
of
places
such
as
this,
if
def
module,
G,
NRC,
6lowpan,
IP,
HC,
and
you
know,
IP,
HC,
n,
HC
and
so
there'd
be
an
option
for
whoever
was
flashing.
This
operating
system
onto
a
given
embedded
device
to
disable.
You
know
the
NHC
feature,
the
next
header
compression
feature
or
portions
of
the
next
header
compression
feature
when
flashing
a
device
in
order
to
reduce
the
firmware
size
and
just
use
the
subset
of
6lowpan
functionality.
Q
If
you
can
actually
scroll
down
just
a
little
bit
and
for
a
ram
as
well.
We
found
friends
contiki
that
it
assumes
that
the
maximum
possible
growth
upon
decompression
in
the
first
fragment
is
38.
Bytes
and
that
was
conserved
Ram
and
to
avoid
using
more
than
38
bytes
of
RAM
for
the
first
fragment
buffer,
and
you
know
that
38
byte
limit
is
one
that
can
easily
be
exceeded
when
sending
certain
packets,
given
the
amount
that
IP,
headers
and
UDP
headers
and
extension
headers
can
be
compress.
Q
And
so
to
elaborate
some
more
on
this
problem
and
why
it
might
happen
in
particular,
for
these
embedded
operating
systems.
If
you
look
at
a
number
of
the
6lowpan
platforms
with
you
know,
15.4
radios
that
are
supported
by
contiki,
OS
and
riot
OS
I
might
just
sort
of
grabbed
a
sampling
of
the
boards.
You
have
platforms
that
are
small
as
the
T
mode
sky,
which,
while
it
might
be
considered
more
of
a
legacy
mode,
is
still
used
for
research
applications.
Q
They
also
can
be
supported
by
the
smaller
devices
and
it's
rather
rare
for
these
embedded
operating
systems
to
have
significantly
different
implementations
based
off
of
the
size
of
the
device,
that's
being
flashed,
and
we
found
also
that
for
the
IOT
applications
that
many
people
use
these
embedded
operating
systems
for
the
limitations
varied
a
lot
for
some
implementations.
You
know
power
might
be
the
biggest
concern,
but
for
other
implementations
with
relatively
complex
applications.
Q
So
to
get
some
more
concrete
numbers
for
this,
we
tried
to
do
a
6lowpan
code,
size
study
for
these
five
stacks.
We
did
this
using
two
methods
for
contiki
and
riot.
We
did
our
best
to
take
advantage
of
the
options
to
disable
portions
of
the
6lowpan
stack
to
isolate
how
much
code
size
was
attributable
to
those
portions
were
specifically
so,
for
instance,
in
contiki.
If
you
enable
the
options
to
remove
IP
HC
compression,
that
would
reduce
the
code
size
by
about
six
kilobytes
in
riot.
Q
We
looked
at
the
binary
e.l.f
files
and
figured
out
how
much
code
size
was
attributable
to
each
of
the
functions
they're
associated
with
6lowpan
and
with
the
full
I
P
stack,
and
obviously
these
numbers
for
the
IP
stack
conversing
slope
an
are
not
necessarily
huge
relative
to
the
amount
of
program
memory
available
on
a
lot
of
these
devices,
but
I
think
it
would
be
foolish
to
consider
that
they're
not
significant,
especially
for
some
of
the
smaller
devices
and
especially
for
cases
where
applications
might
have
a
significant
amount
of
code
and
that
sort
of
leads
us
to
a
discussion.
Q
Maybe
an
aside
of
the
interaction
between
code,
size
and
compression
there's
a
lot
of
things
you
can
do
to
reduce
the
amount
of
radio
energy
used
by
a
given
embedded
device.
You
know
beyond
just
compression,
there's
also
advanced
Mac
and
physical
layers,
which
can
reduce
the
amount
of
radio
energy
expended
by
a
given
device.
Q
But
the
trade-off
is
that
these
often
a
require
more
compute
power
and
B
they're,
often
relatively
complex,
and
can
require
additional
code,
space
or
RAM,
and
for
cases
where
you
have
an
application
which
might
already
be
pushing
up
against
the
boundary
of
what's
capable
on
a
given
device.
It
can
force
a
requirement
for
more
expensive
or
more
power-hungry
microcontrollers.
Q
I'm
actually
gonna,
the
you
know,
there's
some
other
considerations
as
well.
Just
in
general,
increased
complexity
can
be
harmful
to
expectations
of
interoperability
and
it's
it's
difficult,
for
instance,
to
apply
something
like
pastels
law
to
this
low
resource
environment,
and
that
sort
of
brings
me
to
my
for
design
guidelines
and
in
the
slides
that
follow
I'm,
gonna
present
each
guideline
and
then
I'm
gonna
follow
it
up
with
an
example.
Application
to
6lowpan
and
well
I'm,
committed
to
the
guidelines
and
I
will
defend
the
guidelines
themselves.
Q
So
for
guideline
one,
this
is
actually
slightly
different
than
the
order
that
I
present
the
guidelines
in
the
internet
traffic
for
anyone,
who's
read
it,
but
I,
think
that's
sort
of
logical
here,
I
think
it's
important
that
these
devices
have
the
ability
to
advertise
their
capabilities
so
that
these
silent
network
layer
drops
which
cannot
be
interpreted
is
anything
in
particular
by
a
given
sender
cannot
occur
right
now.
It
seems
sort
of
uncomfortable
that
for
6lowpan
it's
relatively
easy
for
these
five
different
stacks.
Q
You
know
to
send
packets,
which
will
be
silently
dropped
with
no
information
back
to
the
receiver
and
so
long
as
there's
an
explicit
mechanism
defined
in
the
protocol
by
which
this
can
be
avoided.
I
think
that
that's
important
and
useful
for
6lowpan
I
proposed
two
potential
mechanisms
for
this,
which
could
either
either
one
can
be
used
on
its
own
or
could
be
used
in
tandem.
I.
N
Q
Q
The
next
logical
question
would
be
what
exact
information
should
they
be
advertising
during
this
process,
and
so
what
we
proposed
is
that
in
general,
these
protocols
should
define
a
capability
spectrum,
given
that
there
often
are
relatively
broad
range
of
capability
devices
that
might
want
to
use
a
protocol
and
that
some
of
these
devices
may
be
very
concerned
with
saving
power
and
others
might
be
more
concerned
with
code
size
or
RAM
use.
It's
important
that
there
be
a
capability
for
a
given
protocol
that
defines
how
the
features
of
this
protocol
can
be.
Q
Q
You
have
you
know.
Smaller
increments
of
energy
savings
are
relatively
more
complex
additions
to
code,
then
for
a
guideline
3,
just
the
idea
that
these
protocols
should
provide
reasonable
bounds.
This
is
based,
you
know,
largely
in
our
observations
for
6lowpan,
that
many
of
the
stacks
were
taking
certain
shortcuts
or
defining
certain
constants
that
were
not
defined
in
any
of
the
RFC
s
to
serve
Ram
in
certain
places.
Q
So
for
6lowpan
we,
for
instance,
suggest
that
perhaps
a
header
decompression
should
be
limited
to
50
bytes,
so
that
for
instances
where
more
than
50
bytes
of
you
would
occur,
those
messages
should
actually
not
be.
Decompressed
should
not
be
compressed
that
much
before
sending
and
that
allows
for
implementations
to
bound
the
amount
of
extra
RAM
needed
for
initial
fragment
buffers,
which
is
something
for
instance,
that
contiki
already
does,
but
Kentucky
arbitrarily
chose.
38
bytes
is
the
amount
that
they
limited
to.
Q
We
realized
that
it
can
be
very
appealing
to
do
cross
layer,
optimization
and
embedded
systems,
especially
given
you
know
how
much
how
little
energy
is
often
available.
However,
it's
very
difficult
to
design
robust
systems
that
will
interoperate
well
when
you're
doing
this
cross
layer.
Optimization-
and
you
know
the
ability
to
use
libraries
etc
can
be
very
important,
especially
for
these
embedded
operating
systems
where
different
network
transport
layers
etc
might
be
used
and
for
6lowpan,
the
the
one
primary
application
that
we
suggest
there
is
that
UDP
checksum
elision
shouldn't
be
an
option.
Q
We
did
notice
that
for
the
five
operating
systems
that
we
analyzed,
tiny
OS
was
actually
the
only
one
that
implemented.
You
need
a
checksum
elision
and
we
believe
that
the
downsides,
including
it
in
terms
of
how
it
breaks
and
argument
breaks
layering,
can
be
complex
to
implement
because
it
requires
these
application
and
link
layer,
checks
for
message,
integrity,
codes
and
permission
from
the
application
layer
that
it's
simply
not
worth
the
small
energy
say
things
that
it
can
provide.
Q
So
that's
my
four
guidelines,
I'd
really
like
to
know
what
you
guys
think
about
different
suggestions.
I
had
for
6lowpan
about
the
guidelines
themselves,
especially
about
the
idea
of
adding
this
ICMP
option
when
a
given
embedded
implementation
to
not
respond
to
a
certain
6lowpan
message,
because
it
is
allotted
portions
of
the
specification.
Q
F
Let's
catch
me,
so
thank
you
so
much
for
this
one
that
you
asked
any
questions.
I
just
give
you
a
few
hints
here.
First
for
your
spectrum
and
it's
there
is
actually
an
RFC
which
would
allow
you
to
do
that.
It's
just
answer.
I
see
we
are
using
it
in
six
leopard
and
GE
update
to
signal
like
support
for
did
if
you're,
6
or
6
lb,
etc.
We
use
bits
in
there,
so
there's
a
good
number
of
bits.
F
So
if
really
we
want
to
do
a
piece
of
that,
you
could
actually
signal
that
and
experiment
with
it.
Now
it's
not
just
signaling,
it's
it's
having
extra
code
to
manage.
Oh,
if
he
does
that
I
do
this.
If
he
does
that
I
do
this,
so
what
you're
saving
on
one
hand
is
a
cost
on
the
other
one
right,
so
you
had
in
code
to
save
code
so
that
there's
a
limit
to
this
game
to
be
discussed.
I
realize
that
you
make
big
enough
classes
because
you
were
doing
fine,
grained
classes.
F
You
would
spend
your
memory
in
order,
of
course,
your
cases
and
testing
them,
etc.
So
the
real
world
is
not
exactly
like
that.
The
real
world
is
dimensions
right
right,
the
real
world
as
bodies
which
define
interrupt
tests-
it's
not
6lowpan
6lowpan
is
more
like.
There
is
a
whole
set
of
things
you
could
be
doing
right
and
then
there
will
be
a
VIP
that
would
be
a
wise
and
that
will
be
astride.
F
There
is
exactly
what
I
asked
any
implementation
to
do
and
there
will
be
interrupters
that
there
will
be
conformance
tests
and
even
if
your
stack
supports
more
use,
the
bare
minimum,
because
I
know
all
the
messages
which
will
goes
from
my
standard,
which
is
building
on
six
leopard,
but
it's
not
sixth
repair
building
the
many
things
report
on
the
triple
or
all
those
things,
you're
all
the
flows
that
men
support.
I
want
your
implementations
got
all
these
flows.
We
got
less
of
what
else
it
supports
and
all
will
be
tested
here
validated.
F
That's
how
actually,
because
you
have
this
logo
I'm,
the
is
a
100
albums,
epi
P,
I'm
right
I'm,
whatever
you
know,
you'll
get.
You
won't
get
this
probably
to
kill
about
not
within
one
of
those
silos
right.
So
there
is
no
real
aim
at
six
depends
support
everything
assets
to
say
all
you
have
to
support
everything,
but
each
of
those
bodies
will
actually
say
what
they
really
want
and
then
example
of
that
is
that
would
come
back
to
it.
F
Is
that,
yes,
anyone
with
a
Chevrolet,
those
guys
are
doing
an
industry
standard
for
reliable
wireless
communication
for
process
control
and
they
use
600mm,
but
actually
she
look
at
what
they
use
from
6lowpan.
It's
a
very
teeny,
tiny
piece
they
have
link-local
tries
to
have
global
addresses,
but
they,
if
you
look
at
the
frames
that
resend
the
specified
reader,
will
be
sending
this
these
days.
F
It's
a
very
tiny
subset
of
what
you
can
do
is
expand,
but
it's
enough
to
get
their
standards
to
work
and
everybody
went
round
every
month
increments,
all
those
things
one
of
the
thing
they
mandated,
what
we
lied
to
check
some
and
they
came
to
it
to
us
and
they
said.
Okay,
if
you
want
us
to
do
ipv6
at
all,
then
you
need
to
provide
a
way
for
us
to
rely
to
checksum,
because
we
have
a
nikkie
at
the
end
of
the
packet
which
is
4
bytes.
F
Q
Yeah.
Thank
you
just
in
reference
to
what
you
said
at
the
beginning
of
when
you
were
speaking
regarding
how
there
can
be
extra
code
to
handle
different
cases
for
given
capability
spectrum.
I.
Think
the
bright
side
of
the
design
of
this
capability
spectrum
is
that
the
code
for
like
deciding
you
know
oh
well,
I,
send
at
this
level,
will
I
send
at
this
level,
etc
is
at
least
offloaded
onto
the
more
capable
devices.
Q
D
Thank
you
for
this
presentation.
I
think
it's
really
interesting.
The
survey
part
I
think
we
should
digest,
and
maybe
there's
there's
some
stuff.
We
can
do
based
on
that.
The
the
the
overarching
design
consideration
society
and
having
some
trouble
and
I
came
here
to
basically
say
what
Piscotty
is
saying
that
we
in
the
IDF,
we
publish
our
FCS
and
we're
happy,
and
you
know
that's
fine
and
pretty,
but
when
it
comes
to
the
real
world
they
couldn't
care
less.
They
may
take
some
hints
from
some
RFC's.
They
won't
take
them
all
completely.
D
I
know
for
a
fact.
So,
I've
looked
at
the
specs
for
some
of
these
organizations.
They
call
themselves
6lowpan,
there's
no
way
a
6lowpan
completely
compliant
per
our
definition.
Implementation
will
ever
interoperate
with
those
that
are
culture
so
bad.
So,
even
if
we
here
go
through
the
you
know
the
enormous
amount
of
work
that
it
would
be
to
basically
restructure
all
our
documents
and
the
pleasure
of
one
ba-ba-ba-ba-ba,
nothing
guarantees
they
will
even
look
at
it
or
care
about
it
because
they
go
about
looking
at
what
do
we
have
to
deliver
by
yesterday?
D
They
don't
have
the
luxury
of
looking
other
stuff,
I'm
told
I
understand
where
they
come
from
I'm
just
I'm
and
it's
not
like
I'm
blaming
them
I
mean
if
I
were
there.
I
do
the
same
thing
you
have
to
ship
yesterday.
Ok,
here's
the
shortcut!
We
take.
Here's
another
shortcut,
here's
maybe
something
we
think
is
honestly
better.
D
The
the
I
still
want
to
thank
you
for
this.
This
work-
this
is
great
stuff
and
I'm.
Sure
there's
got
to
be
some
lessons
here.
We
have
to
take
it
back
and
digest
I'm.
Just
not
sure
the
overarching
thing
might
be
one
of
those,
but
there's
there's
got
to
be
something
here,
I'm
sure
we
can
learn
from
this
yeah
yeah.
Q
I
mean
I
agree
that
going
you
know,
adding
in
all
of
these
capability
classes,
etc.
There'd
be
no
guarantee
that
everybody
would
do
it.
I
still
think
this
idea
that
we
sort
of
acknowledged
that
we
don't
expect
that
all
implementations
will
implement.
You
know.
Every
aspect
of
an
RFC
is
particularly
a
convincing
argument
that
you
know.
Perhaps
there
should
at
least
be
an
ICMP
error
code
that
can,
you
know,
convey
when
a
given
packet
is
dropped.
You
know,
because
of
that
so
yeah.
Thank
you.
Oh.
R
Hey
fellows
I'm,
so
just
like
I
want
to
respond
to
that.
Come
in
intense
calls
coming
I
think
that's
totally
right.
I
mean
there.
Are
these
vertical
silos
people?
You
know
you
have
a
standards
body,
that's
using
six
weapons,
a
basis
for
its
underlying
protocols,
but
there
might
be
parts
in
specification.
They
don't
want
to
use
and
I.
Think
direct.
That's
fine!
R
That's
the
way
the
world
works,
but
the
question
is:
is
that
only
one
six
look
tend
to
be
I
mean
the
Internet
is
about
connectivity
and
if
we
want
to
relegate
6lowpan
to
only
being
suitable
for
vertical
silos,
I
think
that's
one
decision,
but
another
decision
is
canon
specification
themselves.
Instead
enable
interoperability
where
it's
not
vertically
salad.
That's
you
know.
We
used
open
source
operating
systems.
R
These
are
people
who
would
like
to
stick
different
devices
together
and
get
them
to
work,
and
they
can't
because
there
aren't
these
sorts
of
guidelines,
our
capability
spectrum
to
think
about,
and
so
I
think
those
are
two
paths.
I
personally
like
to
see
6lowpan
saying,
look,
of
course
you
know
open
thread.
R
You're
gonna
do
what
you
need
to
do
and
all
about
or
gosh
go
into
this
IPV,
this
UDP
checksum
compression,
that's
fine,
you're
doing
it
in
your
vertical
silo,
but
then
for
that
to
sort
of
propagate
out
and
make
it
very
difficult
for
open
devices
to
interoperate
that
you
know
that
was
kind
of
a
motivation.
That's
that
was
what
gave
me
pause
and
then
you
think,
would
be
useful
to
have
this
discussion.
C
Sumida
Chakrabarti
without
the
chair
head.
Thank
you
very
much
Knutson
and
the
team
to
do
this
work,
doing
the
great
analysis
for
different
devices
and
coming
up
with
a
possible
solution.
I
think
partly
I
agree
with
the
previous
argument
that
okay,
we
have
interoperability
test.
We
have
different
other
considerations
for
implementations
and
their
interoperability,
but
I
kind
of
like
the
idea
of
the
capability,
but
I
have
a
couple
of
questions
like.
Maybe
you
need
to
think
about
at
what
point
you
want
to
do
this
capability
exchange?
Is
it
like
startup
time
or
application
running
time?
C
Maybe
I
think?
Maybe
we
could
ask
the
bigger
group
if
there
are
comments,
but
personally
I
think
this
is
a
concept
that
maybe
you
are
directing
towards
the
capability
of
the
memory
and
device
capability.
Maybe
it
could
be
used
for
some
applications
or
some
other
way
as
well.
So
overall
I
think
the
idea
of
having
capability
exchange
is
great
and
way
that
we
can
use
exactly
the
same
way
you
proposed
or
not.
That
may
be
subject
to
discussion,
but
thank
you
again.
Yeah.
F
When
you
talk
about
the
silo,
it's
a
lot
more
than
six
nope
and
it
goes
from
which
value
select.
How
you
do
your
security,
which
crypto
utilities
you
pick
which
option
you
put
in
your
beacons
means
it's
a
damn
big
list
of
things
of
choices
that
you
make
so
that,
at
the
end
of
the
day
that
can
be
an
ipv6
packets
row.
It's
it's
socially
complex!
It's
it's
so
I,
don't
relieve!
In
the
node
talking
to
another
node
just
like
this,
but
the
cool,
the
good
news
is
that
the
silo
is
just
a
few
hubs.
F
You
know,
ipv6
is
really
where
feel
as
it
right
it's
at
some
point.
Where
rapidly
you
expand
this
package,
you
go
out
of
this
particular
radio
network,
and
now
you
have
an
ipv6
packet
that
you
can
fly
through
strong
your
network.
So
so
yes,
I
guess
you
have
to
meet
Lee
ipv6
achieves
what
we
want
to
do,
but
it's
way
beyond
a
six
top
and
one
because
what
happens
in
this
subnet
is
a
lot
more
than
six
open
compression.
Q
Suddenly
yeah
sure
it
still
seems
to
be
the
case
that,
while
it's
true
that
once
you
get
to
that,
give
you
six
layer,
you
know
going
to
a
border
router
everything
communicate
with
each
other,
but
it
you
know,
I,
think
sort
of
like
in
terms
of
like
the
long-standing
vision
for
Internet
of
Things
devices.
You
know
the
vision,
isn't
you
know
for
somebody
who's
using
IOT?
For
you
know,
home
automation
and
stuff
like
that,
you
know
is
not
to
have
you
know
a
border
router
for
every
single
device
they
buy
from
every
different
vendor.
Q
D
D
Wrap
my
head
around
what
could
be
rescued
and
maybe
there's
something
I've
heard
that
I
liked
is
like
the
ICMP
message,
for
example.
So
maybe
the
way
to
think
about
it
would
be
if
we
set
out
to
guarantee
interoperability.
I
think
that's
a
very,
very,
very
tall
order.
We
might
fail
because
there's
so
many
things
outside
of
6lowpan.
D
That
would
affect
ultimately
that,
but
maybe
the
the
bar,
at
least
to
start
with,
could
be
a
little
bit
lower,
more
practical,
saying:
okay,
is
there
anything
we
can
add
to
help
the
people
who
presumably
know
what
they're
doing
to
interoperate
just
to
do
better
troubleshooting?
So
it's
not
that
they
don't
have
all
the
set
of
information
in
principle
they
do
but
still
you've
made
so
many
mistakes,
there's
so
many
variables.
So
many
things
that
you
need
some
help
right.
This
is
supposed
to
work.
D
This
is
I'm
within
a
silo
or
whatever
I'm,
not
inside
about
and
I'm
an
open
source
looking
at
them.
Whatever
it's
supposed
to
work
because
I
have
an
agreement,
you
know,
but
still
I
have
no
visibility.
So
if
maybe
that's
a
practical
bars
to
start
with
and
and
and
that
would
be
useful,
that
would
really
help
interoperability,
maybe
in
a
more
practical
way
than
trying
to
boil
the
ocean.
Sure.
Q
P
So
I
I,
don't
have
particularly
anything
different
to
say,
but
I
want
to
stress.
You
know
the
the
point
that
Pascal
was
making
and
I
agree
with
this
I
mean
the
there
there
it's
much
more
than
600
pan
and
it's
so
complicated
and
trying
to
have
yet
another
protocol
that
kind
of
announces
the
capabilities.
It's
just
not
gonna,
work
and
and
I
think
it
takes.
It
takes
a
group
of
industrial
people
to
to
come
together
and
agree
on.
P
You
know
Interop
in
trouble
in
chop
test
specifications
I'm
not
talking
about
silos
I'm
talking
about
you,
know
like-minded
people
same
kind
of
business
case,
and
then
they
take
a
subset.
I
think
this
relates
to
BL
wig
thing
and
I'm,
not
at
all
talking
about
your
draft
here,
but
but
I'm.
You
know
I
one
thing
that
I
that
I
find
challenging
in
what
we
do
at
the
ITF
is
that
if
you
take
all
the
must
for
all
the
drafts
that
are
within
our
kind
of
IOT
stack,
it
doesn't
fit
in
the
Pentium
computer.
P
So
so
I
think
we
need
to
be
it's
very
good
that
your
your
draft
highlights.
Have
some
of
these
parts,
but
but
I,
think
we
need
to
be
aware
of
the
fact
that
the
specs
that
we
that
we
define
if
we
are,
if
we
were
to
implement
every,
must
and
every
of
these
specs
it
just
wouldn't
fit
anywhere
and
so
and
so
making
making
informed
decisions
about
taking
P
bits
and
pieces
is
impossible
to
avoid.
Thank
you
thanks.
G
Terry
mandersohn
interior
director,
so
thank
you
for
doing
this.
Work
really
is
appreciated
and
it's
a
credit
to
your
program.
Good
work,
there's
some
aspects
here
that
I
really
do
like
I
mean
the
IETF
has
been
a
lot
of
time
doing:
capability
negotiation,
whether
it's
in
BGP,
whether
it's
in
sip,
SDP,
etc.
The
list
goes
on
and
on
and
on
so
there
might
be
some
things
to
learn
from
that
as
to
why
it's
not
directly
applicable
in
this
constraint,
this
very
constrained
environment.
G
This
might
be
a
class
five
device,
and
that
might
be
enough
to
get
some
understanding
and
to
get
interoperability
to
a
point
where
it's
accessible,
I,
don't
know,
but
it's
just
highlighting
that
at
the
end
of
the
day,
however,
that's
a
discussion
for
the
entire
work
group,
so
great
work,
maybe
come
back
a
a
more
solid
document
and
perhaps
running
code
and
see
how
that
goes.
Thank
you
very
things.
Thank.
C
R
Very
quickly,
I
think
we're
out
of
time,
but
please
yeah.
This
follows
this:
one
I
won't
respond
to
Thomas
items,
which
is
that
I
agree
that
having
bodies
that
are
doing
new,
Interop
tests
etc
be
really
valuable.
But
for
my
personal
experience,
that's
actually
been
is
not
being
someone
initially,
that's
actually
very
difficult.
For
example,
we
started
this
wine
Tim
blown
open
thread
to
do
that.
I
had
to
download
a
specification
document
which
required
me
to
sign
a
legal
agreement,
and
it's
watermark
to
me
right,
because
I'm
not
allowed
to
share
this.
R
Every
single
person
wants
to
read:
that's
the
download,
a
separate
copy,
and
if
you
don't
think
that
this
is
in
pay-to-play
right,
if
I
actually
wanted
to
do
full
interoperability,
just
the
idea
that
I
have
to
pay
to
play
to
do
6lowpan
in
order
to
interoperate
to
me,
you
know
that
it
might
be
that
that
is
in
fact
what
we
have
to
do,
but
it
kind
of
it
rubs
me
the
wrong
way.
Maybe
that's
because
I
I
live
in
so
but
that's
just
this.
R
P
So
we
have
this
thing,
we'll
talk
about
it
tomorrow,
at
six,
we
we
have
this
project
called
F
interrupts,
which
is
a
free
online
interoperability
platform.
You
can
send
it
co-op
in
six
and
6lowpan
packets
and
it
will
tell
you
whether
you're
compliant
or
not
just
kind
of
the
free
version
of
what
you're
describing.