►
From YouTube: IETF115-6LO-20221109-1500
Description
6LO meeting session at IETF115
2022/11/09 1500
https://datatracker.ietf.org/meeting/115/proceedings/
A
Okay,
hello,
everyone
welcome
to
the
meeting
of
the
six
law
working
group.
Please
make
sure
that
you
are
in
the
right
room.
My
name
is
Carlos
Gomez.
We
are
the
cherish,
shweta
bandari.
She
is
online.
Today
we
have
our
responsible
ad
Eric
client
here
and
we
have
at
least
one
minute
taker,
Dominique
volunteered
once
again
as
minute
taker
for
six
laws.
So
thank
you
so
much
for
your
continued
support
and
we
encourage
actually
everyone
to
join
the
collaborative
process
of
taking
minutes
which
will
be
done
as
usual
by
means
of
hedge
doc.
A
A
So
there
are
a
few
tips
for
this
meeting,
similar
to
the
last
couple
of
meetings
which
had
an
in-person
component
for
in-person
participants.
Please
make
sure
that
you
sign
into
the
session
into
the
meet
Echo
session,
for
example,
by
using
the
on-site
tool,
which
you
can
find
from
the
data
tracker
agenda.
It's
also
available
from
QR
codes
here
recall
that
we
are
going
to
use
meteco
to
manage
the
queue
so
there's
a
single
unified
queue,
which
is
the
one
in
meteco
also
for
remote
participants.
A
A
A
Next,
there
will
be
an
update
of
the
six
low
use
cases
draft
by
Jung,
Yoon
Hong,
and
that
will
be
followed
by
a
couple
of
presentations
related
with
neighbor
Discovery.
The
first
one
is
multicast
address,
listener,
registration
and
the
second
one
is
a
new
draft.
Although
the
idea
had
been
presented
in
a
previous
ITF,
which
is
on
prefix
registration,
both
will
be
given
by
pascala.
A
Then
there
will
be
another
set
of
two
presentations.
You
may
recall
that
in
August
we
had
a
call
for
working
group
adoption
on
the
document
that
was
known
as
native
short
address
NSA.
So
there
was
a
lot
of
discussion
then,
and
the
authors
have
updated
the
documents,
and
now
they
have
been
renamed
as
path
aware
semantic
addressing
pasa.
A
So
you
can
see
that
this
is
a
pretty
packed
agenda,
so
we
need
to
kindly
request
the
presenters
to
try
to
stick
to
the
allocated
times
which,
in
addition
should
allow
for
some
time
for
discussion
and
questions
and
so
on.
Nevertheless,
if
time
permits,
we
have
another
presentation
which
is
entitled
IP
payload
compression,
excluding
transport
layer
by
hangxi.
A
A
The
second
document
is
IPv6
over
NFC.
You
may
recall
that
this
draft
was
evaluated
some
time
ago
by
the
isg.
Then
it
was
modified
and
now
after
some
time
the
draft
has
been
updated
and
also
we
have
interesting
news
that
the
draft
is
back
in
isg
evaluation,
State
and
it
is
actually
scheduled
for
the
telechat
agenda
in
December.
A
The
third
document
is
the
six
low
use
cases
draft
which
had
been
evaluated
by
a
couple
of
directorates.
Then
the
draft
has
been
updated,
trying
to
address
the
remaining
commands,
and
the
document
has
also
entered
the
isg
evaluation
State
and
it's
actually
on
the
same
telechat
agenda
on
the
same
day
in
December.
A
This
will
also
be
presented
later
today,
and
the
last
working
group
document
is
the
multicast
address
listener
registration
draft,
which
has
been
updated
several
times
since
the
last
ITF,
and
it
is
perhaps
getting
close
to
being
ready
for
working
group
last
call.
So
is
there
any
comment
or
question.
B
C
C
And
this
is
the
the
history
of
the
draft.
The
draft
has
such
a
long
history
actually
I,
think
the
the
longest
history
ever
or
ever
in
ITF
I
think
last.
The
first
Stella
chat
two
years
ago.
Just
we
got
the
updated
two
for
two
draft
budget,
the
number
17.
After
that,
the
there
is
something
common
from
the
Eric
day.
He
wanted
to
know
the
changes
the
because
the
the
there's
newly
list
of
the
the
data
link
of
the
NFC
is
for
the
number
waterfall
from
the
Wonder
three.
C
Let's
try
it
please!
So,
since
the
previous
meeting
results
actually
to
Eric
gave
us
the
comment
gave
me
the
comment.
Actually
he
got
the
finally
reviewed
about
the
the
of
two
specification
of
the
data
link
of
NFC
version
1.3
and
on
the
four,
but
I
think
he
did.
Doesn't
know,
do
not
have
any
any
more
concerned
about
that
changes.
What
about
the
two
between
the
two
specifications?
C
C
About
the
RFC
sorry
756
about
that
the
survive,
the
layer
sequence
condition
five
position.
Six.
He
gave
me
that
the
I
think
we
need
to
put
the
new
references
of
the
RFC
770s
37
56.,
so
because
I
will
produce
the
new
draft
version,
maybe
19
as
soon
as
I
I
finished.
We
finished
that
the
sixth
row
session
this
time
next
slide
please.
C
C
C
Please
so
next
step
actually
I'm
going
to
produce
television,
the
19th
I
put
that
I
mentioned
that
the
RFC
sorry
7
56
will
be
there,
you'll
be
that
will
be
put,
and
then
we
will
have
the
second
round
the
TeleCheck
on
December
15th,
so
I
can
see
that
the
final
step
finally
and
then
I
can
see
it
at
the
end
of
the
a
little
bit
more
that
before
I
think.
Thank
you.
A
D
Okay,
good
afternoon,
everyone,
my
name
is
present.
The
sixth
row
use
k-thrift
next
page,
please
this
is
the
history
and
status
or
this
is
the
14
revision.
So
in
this
year,
so
February
this
document
will
to
ISC
evaluation.
So
we
are
awaiting
some
of
the
feedback
next
page
yes,
so
this
is
the
opaque
after
last
meeting
or
we
call
a
couple
of
command.
So
we
believe
that
we
are
we
reserved
or
comment,
but
among
document
from
the
robot
or
spark-
or
there
are
some-
the
command
was
not
remaining
as
on
the
result.
D
That
is
the
handling
appendix
a
and
the
security
control
section.
So
appendix
a
is
neither
introduced
or
differs
from
the
body
of
this
document,
so
we
ask
why
it
is
here.
Yes,
he's
right.
So
in
the
revision
we
try
to
resolve
his
command,
and
the
second
thing
is
the
security
control
section.
Robert
Sparks
says
that
he
didn't
satisfy
our
update.
So
in
this
revision
we
also
try
to
resolve
his
command
next
page.
D
The
first
thing
is
to
appendix
a
the
appendix
a
is
a
design
space
dimension
for
sixth
row
deployment.
So
in
all
the
position
of
this
draft
or
this
content
in
Authentics
a
is
located
in
main
body
but
or
during
the
progress
in
this
left
and
resolving
some
document,
it
was
moved
to
appendix
a
also
the
other
comment
to
keep
the
appendix
a
because
it
provides
useful
information
for
sixth
row
deployment.
So
our
resolution
is
to
add
a
related
sentence
in
the
introducing
section.
So
it
is
a
simple
modification.
D
Next
phase
yeah.
The
second
thing
is
to
security
control
section.
It
was
come
from
the
robot
spark
so
import.
The
text
is
like
this.
It
is
a
little
short
but
He
suggests
to
add
some
sentence
which
is
related
to
L2
layer
of
security.
So
we
analyze
the
other
six
row
RFC
document,
so
we
cut
some
ideas
from
the
existing
sixth
row
rfps
document,
so
we
modify
the
security
control
section
as
like
it
is
so.
D
A
D
F
F
F
So
that's
that
allows
several
kilometers
between
devices
and
the
devices
are
deployed
in
mesh
networks
which
can
range
from
Androids
to
thousands
of
nodes.
Those
nodes
join
the
network
using
six
slope
nnd
and
then
repo
is
used
to
Route
inside
the
the
subnet.
So
each
mesh
is
a
single
64
where
you
can
find
those
thousands
of
nodes
and
the
links
are
about
100
kbps
speed,
so
it's
all
route
over
using
repo.
F
F
It
Ripple
also
allows
for
multicast
addresses
and
anycast
addresses.
So
what
we
do
in
this
draft
is
not
only
enable
the
registration
of
anycast
and
multicast
addresses
in
8505.
We
also
couple
that,
with
work
on
the
Ripple
side
to
redistribute
this
knowledge
into
repo
same
message:
505,
the
advertisement
is
unaware
and
Abstract
agnostic
to
the
rotting
that
happens
on
the
other
side
of
the
router.
So
today
we
want
to
use
this
for
any
other
multicast
rotting
protocol
like
PM.
We
can.
F
We
can
always
do
that
so
this
this
makes
it
so
that
the
six-dependent
family
is
growing.
We.
So
we
have
this
multicast
registration,
which,
as
you
said,
is,
is
close
to
finish.
We
are
done
with
this
document.
Pretty
much.
We
have
the
unicast
lookup,
which
has
not
progressed
for
a
long
time.
We've
not
been
working
on
it
we'll
have
to
decide
what
we
do
with
it.
But
basically
the
idea
is
since
the
rotting
fabric
knows
where
the
addresses
are.
Why
do
we
still
broadcast
work
as
lookups?
F
So
can
we
generalize
what
we
do
in?
So
we
don't
even
have
broadcast
value
caps,
and
then
there
is
the
new
member
of
the
family
which
I
will
discuss
after
which
is
the
prefix
registration.
So
this
gives
us
kind
of
an
interesting
family.
Now
next
slide,
please.
So
what
changes
do
we
see?
So,
as
you
said,
callous
we've
moved
quite
a
bit
since
last
day
ATF,
so
we
have
improved
the
terminology.
We
have
beefed
up
the
section
that
says
how
we
improve
Ripple.
F
We
extend
repo,
the
six
slope
and
piece
itself
has
been
rather
stable,
but
on
the
Ripple
side
we
have
improved
in
particular
the
way
we
look
at
freshness
for
those
who
are
aware
of
the
way
Reaper
works.
There
is
a
sequence
counter
that
comes
from
the
host
when
the
host
moves,
which
is
password,
505
and
then
redistributing
in
redistributed
into
repo
as
a
sequence,
counter
the
path
sequence
that
allows
to
find,
which
is
the
most
fresh,
the
freshest
path
and
key
on
the
older
path.
F
Well,
when
you
inject
a
multicaster
drives
for
multiple
members,
those
numbers
may
not
compare,
because
each
each
host
will
or
each
router
will
maintain
its
own
sequence
number.
So
as
long
as
it's
Unique
as
it's
okay,
there
is
a
single
one,
but
if
it's
multicast,
then
there
can
be
multiple
sources
and
the
numbers
cannot
compare.
So
we
we
explain
how
we
use
the
rubber
field,
which
is
taken
from
six
weapon
ND
and
inject
into
repo
as
a
proof
of
ownership
of
what's
being
distributed.
F
We
basically
say
hey.
If
it's
coming
from
the
same
guy
so
same
Rover,
then
you
can
compare
the
sequence
number
and
eliminate
eliminate
the
stale
routes
if
it's
coming
from
different
Rovers.
So
it's
different
listeners
for
the
same
multicast
address
then
effectively
all
the
routes
have
to
be
injected
in
the
multicast
rotting
table.
F
Another
thing
that
happens
is
the
introduction
of
the
P
flat
pfl,
but
I
will
go
back
to
that
on
the
next
slide
and
with
clarifying
the
language
when
it's
any
cast
or
multicast,
we
are
using
the
term
subscribe
as
opposed
to
register
just
to
say,
hey
it's
a
subscription
because
you
intend
to
get
a
multicast
packet
delivered.
Basically,
we
had
we
discussed
last
time
an
issue
about
the
consistent
uptime
option.
So
the
consistent
uptime
function
is
option
is
the
way
the
host
can
figure
if
the
router
has
lost
a
registration.
F
F
It
does
change
a
little
bit
because
we
want
to
to
exchange
the
State
sequence
information
in
both
directions,
so
the
host
can
know
what
is
the
most
recent
State
for
the
router
and,
reciprocally,
it's
completely
abstract
to
the
fact
that
we
use
it
for
six
slip
and
ND
or
any
other
state
from
which
the
host
and
the
router
must
have.
You
know
some
some
kind
of
agreement
right
now.
F
F
Even
if,
during
the
work
group,
let's
go,
we
decide
to
take
it
off.
I,
don't
see
why
that
should
hold
our
group
last
call,
because
taking
off
that
section
is
still
good
reviews,
I
mean
if
anything
get
reviews.
Yes
during
World
group
Prescott
for
this
and
we
take
it
off.
The
reviews
are
still
good
to
take.
G
We
go
does
that
work?
Yes
yeah.
This
fell
off
through
the
cracks
a
little
bit
from
the
last
Philadelphia
meeting.
I
did
send
email
to
six
man
chairs
and
there
was
a
but
I
failed
to
follow
up,
because
I
think
there
was
no
the
general
discussion
on
on
that
email.
The
thread
that
I
said
so
I
think
a
perfectly
fine
thing
to
do
is
to
do
it.
You
know,
if
you
want
to
do
an
adoption
call,
do
an
adoption
call
on
all
cc6
man.
F
So
I
don't
see
that
as
blocking
local
classical
next
slide.
Please,
yes,
so
the
the
other
change
doesn't
affect
the
binary
of
the
packets.
That
would
be
thrown
it's
just
that,
since
we
are
doing
the
work
and
the
prefix
registration
for
a
number
of
reasons,
we
needed
yet
another
flag
to
indicate
prefix.
But
if
you
look
at
its
unique
as
multicast
any
cast
and
prefix
are
mutually
exclusive.
F
So
why
take
yet
another
bit
saying
it's
mutually
exclusive
with
the
others?
So
the
idea
was:
let's
keep
the
two
bits
with
the
same
value:
zero
unicast
one
multicast
zero!
Well,
second,
bit
on
any
cast,
but
call
that
a
single
field,
so
the
value
of
three
would
be
available
to
us
for
the
prefix
registration.
F
F
By
the
way,
so
the
prefix
is
the
second
draft.
I
will
be
talking
about
right
after
but
remember
for
those
who
have
a
pending
draft.
There
is
this
early
INR
discussion
that
has
happened
for,
for
those
drafts
and
Amanda
came
to
me
and
said
what
do
I
do
with
this
thing
and
well
that's
a
question
to
the
group.
F
A
G
F
A
F
F
C
F
We
we
are
already
redistributing
what
we
learned
from
8505
into
routing.
This
is
not
a
surprise.
The
way
it
works
is
today
when
the
host
or
even
the
router,
has
a
unicast
address,
and
he
wants
to
ensure
there
is
reachability
back
independently
of
what
the
rotting
is
above
the
first
operator,
it
will
set
the
r
flag
in
8505,
telling
the
router
a
whatever
you're
doing
in
the
proxy
Rift
evpn,
you
name
it.
Repo
obviously
do
whatever
is
necessary
for
me,
because
I
won't
be
doing
it
myself.
F
So
this
is
what
we
have
here
and
well
that's
effectively.
The
way
Reaper
works,
so
you
can
see
this
prefix
a
which
is
the
whole
ysn
network.
If
you
like,
the
the
single
subnet-
and
you
can
see
that
Mr,
C
and
Mr
D
tell
the
root
that
their
parent
is
B
and
the
root
will
know
that
it
has
this
last
Hub
to
to
make
to
Rich.
Basically,
you
see
on
the
right
routing
table,
that's
built
out
of
that
next
slide.
F
F
Is
this:
this
device
is
effectively
injected
into
Ripple
by
c,
as
opposed
to
l,
okay,
as
an
external
Rod,
the
result
is
pretty
much
the
same.
It's
just
that
the
router
is
aware
that
this
host
does
not
belong
to
repost,
so
it
cannot
be
expected
to
terminate
the
Ripple
artifacts
that
we
place
in
the
packet.
So
typically
a
tunnel
from
the
route
that
is
supposed
to
reach
L
will
terminate
at
C.
That's
pretty
much.
F
The
the
main
difference
with
the
usual
in
usually
determine
the
tunnel
will
terminate
the
node,
because
it's
Ripple
aware,
but
here
we
don't
even
expect
that
the
node
L
is
capable
of
terminating
the
rod
the
tunnel,
so
we
terminate
it
at
C.
Now
we
have
this
for
hosts,
but
next
slide.
Please
we
don't
have
it
for
prefix.
So
what
are
we
waiting
for?
There
are
a
number
of
reasons
why
we
would
do
it
for
prefix,
not
any
type
of
prefix.
F
We
never
want
it
and
still
don't
want
Ripple
to
become
a
Transit
Network,
because
we
expect
tlds
to
be
a
very
edge
network,
but
for
this
Edge
node
that
we
saw
there
could
still
be
a
an
external
stat
Network
connected
or
it
could
be
that
this
Edge
node
is
not
only
owner
of
a
one
address,
but
it
could
be
owner
of
a
prefix.
For
instance,
there
is
the
story
of
doing
64
per
host,
which
is
perfectly
good
and
legal.
Why
would
not
Ripple
a
low
for
it?
F
So
basically,
in
this
case
it
will
be
a
ripple
again,
but
it
could
be
any
rotting
protocol
or
any
action
and
I
will
be
presenting
this
draft
at
slack
tomorrow,
because
it's
it
solves
the
slack
Prime
just
like
it's.
It
helps
in
the
Ripple
case,
snack
snack
snacks.
It's
like
well
much
is
like
these
days.
F
So
I
will
skip
that,
but
just
just
as
an
example
of
how
that's
that
addresses
the
snack
use
cases.
Basically,
as
soon
as
a
router
advertised,
like
a
step
writer
advertises
to
a
main
writer
that
it
has
a
prefix,
the
the
main
router
can
forward
the
packets
to
that
first
router,
you
don't
need
a
full-fledged
rotting
protocol
with
distances
and
stuff,
because
the
stub
is
attached
to
a
6lr2.
F
F
F
Could
you
say:
oh
routers
are
free
to
autoconf
64th
instead
inside
that
slash
48.,
because
we
have
still
this
6
lbr
which
could
manage
no,
you
can
do
it,
it's
a
duplicate
or
you
can't
do
it.
I
mean
we
have
all
the
the
tools.
That
would
basically
say
Hey.
You
have
this
prefix
or
you
can't
have
this
prefix.
F
So
it's
pretty
cool
by
reusing
what
we
have,
but
instead
of
looking
at
exact
match
of
okay,
that
this
address
already
owned,
exact
match
with
this
adult
dress.
Now
we
could
look
at.
Is
this
prefix
part
of
that
other
prefix?
Is
this
other
prefix
available
for
auto
config
subnets
of
it?
Okay?
So
so,
there's
a
whole
possibility
there
that
we
we
could
develop
just
because
we
we
have
that
anyway,
and
it
would
be
an
extension
of
what
we
do
for
that,
but
by
looking
at
which
prefix
is
inside,
which
are
the
prefix.
F
So
so
the
draft
doesn't
do
auto
allocation
or
prefix
a
location
right
right
now,
but
that's
a
possibility
that
is
offered
to
us
with
this
draft
next
slide
so
well.
How
that
would
that
work,
but
pretty
much
the
same
way
as
nine
zero
one
zero
works
I
mean
the
the
step
router
advertises
through
ND,
the
the
one
half
reachability
of
the
prefix,
and
then
the
routers
above
will
do
whatever
is
necessary.
F
Maybe
the
aggregate,
maybe
they
redistribute
whatever
they
have
to
do
in
their
own
routing
protocol,
and
here
I
have
the
case
of
pvpn,
but
it
could
be
anything
basically
they
will
inject.
If
they
are
flag
is
if
it's
set,
then,
instead
of
injecting
a
horse
route,
they
will
inject
a
prefix
rod.
Now
there
is
a
question
I
presented
that
slide
to
ietfs
ago,
because
when
we
started
this
I
presented
it
before
I
wrote
the
draft
to
see.
F
If
there
was
interest,
the
group
kind
of
told
me
hey,
yes,
we're
interested
in
working
on
that,
so
I
produced
the
draft,
and
in
my
slides
I
indicated
it
could
have
been
an
RS
and
the
other
option
could
have
become
a
stub
router
or
option
or
something
the
names
are
not
that
important.
It
could
be
cool
to
figure
out
if
we
want
to
use
errors
RNs
at
the
moment
to
keep
it
very
similar
to
8505
it's
a
narrow
option
in
an
NS,
and
there
is
just
a
prefix
length
that
set
it
to
the
error
option.
F
But
if
you
know,
you
guys
think
it's
more
relevant
to
call
it
an
errors,
then
it
could
become
an
errors,
whatever
works
for
me
next
slide
and
big
surprise,
as
I
introduced
this
these
two
bits,
which
can
say
unicast
multicast
anycast.
Now
the
proposal
is
to
assign
value,
1,
1
to
say,
hey,
we
are
registering
for
a
prefix
and
if
we
are
registering
for
a
prefix,
yes,
you
have
a
prefix
lag
somewhere
in
this
packet
next
slide,
so
in
the
RO
effectively-
and
this
is
not
change
much.
This
is
this.
F
This
just
shows
that
same
asset
505
with
eight
nine,
two,
eight
eight
nine
two
eight-
is
the
way
we
do
sound
in
that
world.
That
basically
says
hey
when
you
register
an
address.
If
this
route
ownership,
verification
verifier,
is
a
crypto
ID,
then
you
can
be
challenged
for
running
it.
So
so,
if
the
same
address
shows
up
somewhere
else,
the
routers
will
challenge
the
somewhere
else
to
see.
If
this
token
is
can
be
validated.
F
If
the
host
can
validate
the
token
it
means
he
has
the
private
address
that
goes
with
it,
so
it
can
only
address.
That's
basically
the
way
we
avoid
stealing
addresses.
Well,
we
can
do
the
exact
same
thing
for
prefixes
if
the
prefixes
are
owned
by
a
single
node
or
if
the
different
owners
share
the
same
key,
then
it's
possible
to
ensure
that
a
route
can
only
be
injected
in
the
routing
fabric
by
the
real
owners.
F
F
Would
we
want
to
to
add
a
to
to
make
it
an
arrest,
make
it
an
NS?
Would
we
like
to
to
extend
the
proof
of
ownership
per
ifc9
8928,
which
is
not
done
yet
in
this
draft
more
interesting,
since
we
are
advertising
prefixes
and
we
may
advertise
them
through
different
places.
Do
we
want
to
influence
load,
balancing
again,
that's
more
of
a
data
center
type
of
use
case
and
then
again
it's
not
a
distance.
We're
talking
about
right!
It's
it's
we're
talking
about
weights.
F
We
are
not
doing
a
routing
protocol,
we
are
still
in
NS
space,
but
in
NS
you
have
a
pre-filled
router,
for
you
have
this
router
preference
thing
right
same
thing.
When
we
inject
the
prefix,
we
could
say
hey.
If
I
have
several
parents
to
whom
I
want
to
advertise,
this
prefix
I
could
say:
I
want
more
traffic
through
this
parent
and
through
that
one,
for
instance,
because
I
don't
know,
I
mean
that's
the
way,
balance,
Mannix
and
well
that's
pretty
much.
F
It
I
just
want
to
to
to
be
very
explicit
that
this
is
a
beginning,
and
there
is
a
lot
of
power
that
we
could
develop
with
decider.
It's
so
so
don't
take
for
granted
the
fact
that
it's
an
NS
or
that
the
capabilities
that
are
disclosed
in
zero,
zero
are
very
limited.
There
are
tons
of
things
we
could
be
doing,
but
then
again
it's
not
a
rotting
protocol.
It's
just
advertise
the
one.
How
preachability
it
will
stop
and
that's
pretty
much
it
so.
F
F
F
A
Yeah
so
now,
since
there
is
a
written
draft
now
it's
a
good
moment
to
actually
read
it
and
provide
feedback.
So
we
encourage
the
working
group
to
to
read
the
document
and
provide
comments.
Thank
you.
So
then,
the
next
set
of
presentations
will
be
the
ones
related
with
past
aware
semantic
addressing.
H
This
is
rapidly
the
the
the
history
how
the
the
draft
day
is
advancing.
We
are
back
again
to
zero
zero
because
we
changed
the
name.
Okay,
we
have
beside
the
name.
We
have
to
welcome
two
more
quarters.
One
is
Pascal.
That
is
a
great
job
in
helping
us
we'll
go
over
the
his
contribution
Kieran
as
well.
All
this
contribution
actually
came
up
from
the
nice
discussion
that
we
had
during
the
the
working
group
called
for
our
adoption.
That
I
mean
the
document
didn't
make
through,
but
actually
all
in
all,
we
did
good
progress.
H
To
be
honest,
so
that's
wonderful
from
my
perspective,
the
outcome
of
the
call
for
adoption
was
the
the
fact
that
we
need
some
clarity,
clarification.
Sorry,
the
chance
did
a
a
good
summary
of
all
this
discussion
that
we
had
on
the
mailing
list
was
a
quite
a
long
discussion,
I
think
in
the
last
year,
or
so
was
the
longest,
if
I
dare
to
say,
but
69.
A
H
Oh
yeah,
it
was
pretty
good,
I
would
say
so
and,
as
I
said
before,
Kira
was
suggesting
a
new
use
case,
and
we
had
discussion
on
that
and
also
Pascal
in
one
of
the
latest.
Email
was
suggesting
to
use
the
routing
header
as
a
way
to
move
forward
okay
and
go
over
what
we
the
different
points
that
were
discussed
right
so
yeah.
H
The
main
changes
beyond
the
name
in
the
in
the
document
is
the
fact
that
we
have
now
an
extensive
use
case
section,
which
better
explains
what
what
where
we
see
this
solution
to
apply,
because
it's
not
and
should
not
be
considered
a
general
solution
that
you
you
can
use
in
all
the
possible
six
slow
scenarios.
Okay,
there
are
specific
scenarios
that
were.
It
is
very
reasonable
to
be
used.
H
So
the
way
you
decide
where
to
send
the
packet
that
piece
of
work
remains
on
on
changed.
That
is
pretty
stable.
It's
just
the
way
where
we
use
it
in
which
use
cases
and
actually
how
we
encode
our
pockets.
Okay,
as
I
said,
we
try
to
to
have
a
to
type
better
the
work
with
the
six
slow
use
cases.
This
is
one
of
the
the
points
that
the
chairs
put
in
the
summer:
email
closing
the
call
for
adoption,
the
the
clarification
of
whether
we
should
use
this.
H
The
main
use
case
is
obviously
related
to
PLC,
where
we
have
already
three
topologies,
which
is
also
the
logical
topology,
that
the
passer
X
NSA
tried
to
build
in
order
to
forward
the
packets
and
obviously
the.
If
you
do
this
stateless
approach.
In
order
to
forward
you
are
sensible
to
Mobility,
so
we
I
mean
PLC.
There
are
no
Mobility
requirements.
There
are
other
scenarios
who,
where
the
mobility
is
not
a
requirement,
but
then
you
have
to
build
the
tree
topology,
which
may
or
may
not
fit.
H
H
Add
up
all
the
the
the
full
six
law
protocol
stack
program,
but
you
can
have
a
software
update
that
allows
you
to
have
stateless
forwarding
and
yeah
the
again.
This
pasta
solution
seems
to
fit
well:
okay,
I
invite
you
to
really
go
over
the
use
cases
and
see
if
this
solves
all
the
the
the
the
clarification
requested
that
we
received
in
an
email
and
also
suggested
by
the
HHS.
H
So
as
for
the
encapsulation
format
itself,
what
we
have
is
now
to
use
the
60
pound.
Routing
header
I,
suggested
us
Define
it
in
RFC
8138.
So
we
will
have
page
one,
this
routing
header
and
then
the
normal
low,
pan
iphc.
So
basically,
the
IPv6
compressed
header
according
to
60,
to
82.,
okay,
no
special
treatment
there.
H
What
we
do
is
actually,
once
you
build
the
what
we
call
the
passer.
A
rich
header
is
well,
the
format
is
pretty
simple:
we
you
have
to
type
that
allows
you
to
understand
which
kind
of
routing
header
you
are
using.
Then
we
have
two
bits
that
allows
us
to
to
understand
what
kind
of
address
you
have
in
this
header
the
size
of
the
address,
and
then
we
have
a
set
of
quad
squads.
So
just
two
octets.
So
it's
a
couple
of
that's
like
we.
We
cut
the
IPv6
addresses
with
the
columns
right.
H
So
the
idea
is
basically
when
we
add
this
header,
we
take
the
destination
address
from
the
iphc
and
put
it
there,
and
we
do
you
don't
need
to
to
put
in
the
iphc.
You
can
delete
it
at
once,
so
that
we
you
don't
need
to
have
duplicate
and
then
each
and
every
node.
What
does
it's?
It
looks
at
this
header
and
it
takes
the
forwarding
decision
according
to
the
rules
that
were
all
already
there
now
and
this
this
piece
of
content.
H
H
So
basically
how
these
things
all
works
together.
The
password
domain
just
does
compress
and
compress
the
the
the
packets.
According
the
the
specification
in
this
document,
the
prefix
of
the
parcel
domain
represent
the
context
that
we
use
to
compress
according
to
6282.
So
basically
you
can
shrink
the
the
big
IPv6
address,
at
least
to
a
slash
to
only
64
bits.
H
Okay,
according
to
the
size
of
the
the
pass
address,
you
can
do
even
more
if
you,
if
you
wish
on
the
way
back
the
the
document,
describes
how
to
take
the
pass
address
and
rebuild
the
full
IPv6
or
just
just
the
correlations
operation
that
is
always
already
described
in
8138
Okay.
So
when
we
send
a
packet,
we
compress
according
to
60
6282,
okay,
based
on
the
context
and
then,
as
I
said,
we
take
the
destination
address
we
put
in
the
RH.
H
We
lead
it
from
my
phc
and
we
said
well,
we
set
the
size
accordingly,
etc,
etc,
and
we
send
the
packet
the
receiving
side.
What
we
do
is
basically
we
take
the
the
address
in
the
RH
header
and
we
use
it
as
a
IID
and
we
we
can
rebuild
the
full
like
pv6
address
according
to
8138.
That
is
nothing
really
special,
and
this
is
the
the
intra-domain
communication
in
a
passer
domain.
Okay
from
the
the
for
external
communication,
things
are
a
little
bit
different
but
different
because
we
need
to
send
outside.
H
So
this
is
something
that
we
I
wouldn't
say,
we're
still
working
on.
We
we
have
to
better
the
finance
and
the
document
we
are
discussing
again
with
with
pascalte,
but
the
idea
is
pretty
simple:
if
we
have
to
send
outside
what
we
need
to
do
is
just
send
up
to
the
root,
nothing
more
right
and
when
we
receive
something
from
the
outside,
the
root
will
will
create
the
RH
header
with
the
pass
address,
and
this
becomes
a
intra-domain
communication
and
will
be
delivered
to
the
offly
to
the
right
destination.
H
D
Okay,
thank
you
for
your
cool
presentation
and
thank
you
for
your
report.
Sixth
row
use
case
left.
I.
Think
that
sixth
row
you
skate
draft
is
a
kind
of
the
information
to
other
documents,
so
it
is
very
good,
so
I'm
wondering
so
you
refer
to
PLC
cases,
the
PLC
the
PLC
can
be
utilized
in
G3,
PLC
or
electricity
ucg.
So
I'm
wondering
your
idea
is:
is
there
any
practical
reference
site
to
use
or
do
you
have
any
plan
to
utilize?
Your.
H
D
H
I
Just
a
couple
of
quick
question
or
about
a
quick
note,
I,
wouldn't
rule
out
or
I,
would
ask
you
to
state
in
document
why
you
did
rule
out
all
kind
of
hero
compression
other
than
iphc,
for
example,
for
example,
GHC
or
chic
I
know
that
Rover
brief
for
the
document.
It
is
more
important
to
ex
to
explain
how,
for
iphc
is
working
the
address,
expansion
and
compression,
but
there
are
other
methods
as
well,
and
the
second
is
a
suggestion
for
addresses
that
are
going
outside
of
the
network.
I
I
found
myself
very
comfortable
with
stateful
compression
for
a
phc
that
sure
enough.
It
requires
also
to
have
a
distribution
for
the
contextness,
but
it's
very
useful
just
just
because
your
scenario
seems
to
be
just
fitting.
The
idea
that
the
outside
addresses
or
whether
the
addresses
toward
the
internet
are
just
a
handful.
H
Yeah
but
I
I
agree
on
the
second
comments
that
you
did
about
the
external
communication
about
the
the
first
part.
The
first
comment
that
you
said
are
we
ruling
out
something,
and
let's
say
that
we
did
not
include
this
something
in
this
document,
but
this
is
my
personal
point
of
view.
This
is
something
to
discuss
also
with
the
other
quarters
and
with
you
guys,
the
working
Loop,
but
we
we
don't
necessarily
rule
out
other
form
or
compressions.
We
maybe
need
other
specifications
at
that
side.
I
H
In
the
document
from
the
original
one,
let's
say
there
was
also
some
kind
of
optimization
in
the
way
you
treat
the
the
addresses
that
are
external
and,
as
I
just
said,
these
are
optimization.
We
don't
need
in
the
basic
specification,
but
something
we
cannot
optionally
if
we
wish
and
the
the
group
is
interested,
but
the
basic
set
of
of
specification
that
we
are
converging
on
looks
okay
thanks.
J
Hello
here,
yeah
I
was
looking
at
one
of
the
use
cases
that
you
introduced
so
there's
a
smart
home
use
case
and
again
about
the
PLC
there
so
yeah.
What
I
was
thinking.
If
you
look
at
that
topology,
then
typically
in
a
smart
home,
there's
also
something
like
or
what
we
call
sometimes
infrastructure
link.
So
that's
like
Wi-Fi
or
ethernet
link
that
binds
everything
together
so
that
yeah
that
I
suppose
we
have
that
there
and
then
there
are
a
number
of
PLC
gateways
and
those
you
can
consider
as
a
stop
Network.
H
That's
not
true
actually,
because
in
the
in
the
different
use
cases,
and
we
have
ASCII
art
in
the
document
that
tries
to
explain
what
you
there
is
also
in
the
text
is
the
fact
that
at
the
end
of
the
day,
you
have
some
hierarchy
in
your
privacy
Network.
We
have
because
one
thing
is
the
end
device
which
could
be
something
big
or
some
something
small,
but
all
the
the
connecting
infrastructure,
as
small
as
a
smart
home,
might
have
some
hierarchy
limited.
H
J
I
think,
okay,
then
it's
good
maybe
to
update
the
picture
also.
So
if
the
PLC
has
some
hierarchy,
then
I
kind
of
understand,
maybe
better
yeah.
How
that
how
that
fits?
But
overall
the
use
case
doesn't
doesn't
look
like
the
smart
home.
That's
now
usually
introduced
today,
where
lots
of
devices
are
Wireless
like
your
lights
and
doorbell
yeah.
J
H
But
if
something
goes
wrong
and
you
don't
have
a
routing
protocol
that
allows
you
to
go
around,
then
you
need
to
to
manage
the
reliability
in
a
different
way.
So
what
I
want
to
say
by
that
is
that
this
work
in
principle,
could
work
in
the
wireless
environment.
But
there
is
a
reliability
issue
that
you
have
to
to
look
at
it
carefully,
because
the
wireless
link
is
is
not
as
stable
as
a
PLC
wireless
link,
so
so
yeah.
So.
J
H
J
A
B
H
H
Certainly,
let's
say
this
is
an
initial
effort
and
might
have
some
adjustments
to
be
done,
but
the
more
important
the
point
is
to
receive
your
feedback,
so
I
I
hope
that
you
at
some
point
we
will
have
the
possibility
to
discuss
this
on
the
mailing
list.
Okay,
so
new
document
submitted
in
October
as
I
said,
the
main
change
is
the
the
naming
we
try
to
go
over
the
the
whole
document
to
replace
an
essay
bypass
and.
C
H
H
There
is
also
a
section
about
consideration
how
to
detect
the
failures
and
the
recovery
as
well,
because
this
is
also
a
change
in
topology.
It's
not
about
only
a
workaround,
something
that
is
missing
is
also
understanding
when
this.
This
link,
for
example,
or
not,
that
that
was
not
available,
is
coming
back
and
we
can
go
back
to
the
initial
state
and
then
some
consideration
about
their
obviousness.
H
You
know
so
the
the
obviously,
in
order
to
to
have
a
reliability,
the
private
requisite
is
to
have
redundant
links.
If
you
don't
have
an
alternative,
if
something
breaks
it
breaks
and
you
you
lose
connectivity.
So
this
is
obviously
the
what
you
need
at
the
beginning
doesn't
mean
that
you
need
to
this
redundant
links
all
to
be
active
at
the
same
time.
So
it
could
be
an
active,
passive
kind
of
usage.
H
This
is
except
the
root
nodes
in
the
sense
that
the
root
node
is
the
one
that
that
is
the
the
gateway
to
the
internet
and
starting
from
there
you
have
different
kind
of
reliabilities
and
you
are
outside
the
passer
domain.
So
yeah,
that's
a
different
story
and
the
alternative
parent
could
be.
You
know,
is
connected
in
to
a
non-active
link.
H
Okay,
so
it's
like
multi-topology
routing.
So,
basically,
you
have
two
parallel
instance,
or
over
to
three
topology
that
not
match
in
the
sense
that
so
that,
when
one
link
is
down,
you
have
an
alternative
pass
on
the
other
topology
right
or
you
can
use
one
single
address
or
like
we
do
in
the
normal
case.
H
But
then
you
need
to
store,
alter
some
addresses
in
order
to
have
to
know
which
is
your
alternative,
parent
or
children.
Okay,
in
a
multi-topology
case,
you
don't
need
you
don't
need
that
they
are
really
running
in
parallel,
so,
but
in
a
certain
way
both
require
some
some
additional
State
on
the
different
nodes.
So
I
said
this
is
pretty
trivial.
I
mean
there
is
not
such
a
thing
as
a
free
lunch
right.
H
So
when
the
multi-address
case
in
case
of
a
link
you,
you
will
have
basically
two
routes,
and
then
you
have
these
multiple
links.
You
build
a
parallel
topology
when
something
happens
like
in
this
case.
In
this
example,
we
have
the
link
between
one
zero,
zero
and
one
zero
that
he
at
some
point
breaks
after
detection.
H
One
zero
zero
can
use
the
other
topology
in
order
to
send
a
an
icmp
notification
to
the
root.
In
order
to
say
this
link
is
down-
and
this
is
this
is
done
on
the
alternative
topology
using
the
address
zero
one,
one,
zero,
zero,
sorry
for
all
these
bits
going
through
the
alternative
route
and
then
the
original
route.
Okay,
this
is
from,
let's
say
from
the
bottom
side
of
the
link
on
the
app
Sim
side.
The
denote
one
zero
just
send
an
icmp
straight
up
through
the
different
layers
to
the
root
and
for
optimization.
H
H
You
can
tunnel
through
the
alternative
topology
and
send
it
to
the
root
okay,
on
the
way
back,
let's
say
that,
oh
there
is
a
packet
from
the
root
could
have
come
externally
or
from
the
local
domain
doesn't
matter
when
it
is
on
the
route,
and
you
look
at
the
destination
address
now.
The
route
needs
needs
to
remember
that
there
is
a
broken
link
and
so
that
it
needs
to
Tunnel
the
bucket
on
the
alternative
topology
back
to
100..
H
Okay,
so,
basically
it
uses
the
alternative
path
goes
to
one
zero,
zero
decapsulate,
you
see
the
real
destination
and
you
send
it
down
to
the
real
destination.
Okay,
so
the
the
the
the
the
state
that
you
need
to
add
is
in
Niche.
No,
each
node
that
is,
has
a
broken
link,
absely
more
donesting.
There
is
this
additional
stated
that
you
have
to
remember
that
the
link
is
broken,
but
it's
not
that
much
stage.
You
still
need
to
to
have
this.
H
H
There
is
some
State
on
the
root
because
the
route
has
to
have
the
knowledge
of
all
ongoing
failures
and
where
to
encapsulate
in
order
to
Tunnel
the
packet
to
the
right.
Node
I
mean
now.
This
is
hopefully
limited
State
because
you
have
few
failures,
but
if
you
have
a
lot
of
failures
popping
up
in
your
network,
so
the
state
that
you
have
to
keep
on
the
root
is
not
anymore.
Your
problem,
you
have
a
bigger
issue
with
the
reliability,
physical
reliability
of
your
network,
right.
H
H
I
will
go
straight
to
the
single
single
address
case
with
the
simplest,
the
same
scenario:
okay,
a
link,
failure
between
one
zero
one,
zero
zero.
As
you
can
see
now,
we
don't
have
double
addressing
it's
just
that
in
this
case,
we
need
to
keep
a
bigger
neighbor
State
with
alternative
parents
and
children
in
order
to
know
what
to
do.
When
the
link
fails,
you
basically
one
zero
zero,
send
an
icmp
message
through
110
to
the
root
in,
in
order
to
say
to
do
the
same
notification.
H
Basically,
okay,
so
we
need
to
exchange
Samosa
state,
but
we
still
can
walk
around
the
the
link.
Failure,
okay
and
when
we
go
down
The
Roots
knows
that
something
is
wrong
and
it
can
decide
to
do
some
kind
of
source
routing
in
order
to
send
the
packet
to
the
right
destination
looking
to
run
through
forwarding
through
an
alternative
pass.
In
that
case,
however,
you
can
have
some
hope
at
it,
because
you
need
to
to
embed
the
path.
H
For
the
sake
of
time,
I
will
skip
the
the
the
flowcharts,
but
these
are
in
the
document
pretty
easy.
So
if
we
want
to
compare
a
little
bit
to
classes,
the
multiple
addresses
single
address,
the
the
amount
of
state
that
we
see
in
the
root
in
the
multiple
addresses
is
low,
because
you
just
have
a
redirect
rule.
The
single
address.
The
root
needs
to
know
that
your
full
topology
knows
that
when
we
go
downlink,
we
need
to
know
which
path
to
build.
H
Okay
in
in
the
forwarder
nodes,
the
status
is,
in
both
cases
relatively
low.
Some
some
rules
can
be
there
or
neighborhood
and
the
robustness.
If
you
have
multiple
failures,
the
multiple
addresses
there
is
no
clear.
Synchronization
could
be
weaker
in
that
case,
but
in
the
single
address
case,
since
the
route
has
a
global
vision
can
do
semester
choices.
But
again,
if,
if
you
have
a
lot
of
failures,
then
you
have
a
bigger
problem
and
that's
it
about
being
a
little
bit
of
time.
A
A
A
So,
first
of
all
a
reminder
for
the
motivation
of
this
draft.
As
this
working
group
knows
well,
RFC
622
has
been
the
basis
for
header
compression
in
six
low
pan
and
also
in
six
low,
with
these
rfcs
possible
to
compress
a
48,
byte,
ipp6
UDP
header,
down
to
just
seven
bytes
in
the
best
case
with
global
addresses.
However,
there
is
a
more
recent
specification
called
Chic,
which
is
the
main
product
of
the
lp1
working
group,
which
is
able
to
compress
even
further
the
same
header
down
to
just,
for
example,
one
byte.
A
That's
because
cheek
uses
static
context
based
on
a
priority
knowledge
of
the
header
field,
values
of
the
packets
that
will
be
transmitted.
Then,
if
we
take
into
consideration
also
an
application
layer
protocol
like
Co-op,
there
is
no
six
low
band
style,
header
compression
defined
for
Co-Op,
but
there
is
a
way
to
compress
Co-op
headers
with
Chic.
So
here
we
are
considering
two
examples.
Two
cases
of
Co-op
headers
one,
which
is
a
means.
A
No
header
options,
which
means
had
the
size
of
four
bytes
case
b,
corresponds
to
the
example
in
Table
Six
in
RFC
8824,
where
the
cop
had
a
size
is
16
bytes.
So
in
both
cases,
the
seek
it's
possible
to
compress
those
two
headers
down
to
just,
for
example,
one
byte,
which
leads
to
a
total
Improvement,
which
is
quite
significant.
A
So,
for
example,
this
represents
a
battery
lifetime
Improvement
for
battery
operated
devices
over
15.4
by
a
factor
which,
in
theory,
could
be
even
greater
than
two.
Although
a
disclaimer
here
is
that
the
actual
Improvement
will
be
lower
depending
on
the
different
parameters
and
settings
like
the
device.
Hardware
features
such
as
sleep
current
consumption,
different
settings
at
the
Mac
layer,
adaptation,
layer,
application,
layer,
payload
size,
Network,
topology
and
so
on.
Next,
please.
A
A
Like
short,
Mac
addresses,
intrapan
communication
and
a
sensor
that
is
battery,
operated
and
periodically
transmitting
a
message,
for
example,
containing
sensor
readings
over
15.4,
and
we
are
considering
also
star
topology
and
mesh
under,
so
we
may
add
route
over
in
in
future
updates
of
this
figure
and
as
you
can
see,
there
is
some
improvement
factor
which
is
reasonably
significant
and
it
increases
as
the
core
payload
size
decreases
and
anyway
this
is
theoretical
results,
so
the
actual
Improvement
will
be
somewhat
lower.
Next,
please!
A
So,
on
the
status
of
this
document,
there
was
some
previous
document
a
precursor
to
to
this
one
which
was
presented
already
in
ITF
110.
Then
this
document
I'm
presenting,
tries
to
provide
all
the
details
required
to
enable
the
transmission
of
sheet
compress
packets
over
15.4
networks
and
the
previous
versions.
Previous
first,
four
versions
of
the
draft
have
been
presented
in
the
last
four
ITF
meetings
and
today
I'm
presenting
revisions
zero.
A
A
So,
let's
see
the
update
in
the
draft
first
there's
some
changes
in
the
organization
of
some
of
the
content.
In
the
document.
Previously,
there
was
section
6
entitled
multi-hub
communication,
which
now
has
increased,
and
now
it's
located
in
Section
3
architecture.
Also,
we
have
modified
the
change
of
the
two
previous
subsections
in
the
architecture
part
in
order
to
provide
a
better
introduction
to
the
multi-hop
communication
topics.
A
A
So,
on
Section
3.3
on
multi-hub
communication:
these
are
the
three
approaches
by
which
compressed
packet,
maybe
transmitted
through
a
multi-hop
path
in
a
15.4
network.
Now
the
first
one
we
are
calling
it
straightforward
route
over
approach.
In
this
case,
all
nodes
must
store
all
the
rules
in
using
the
network
for
compression
decompression.
That's
because
maybe
a
note
could
be
a
node
in
the
middle,
an
intermediate
mode
which
might
need
to
decompress
and
compress
again.
A
So
later
we'll
see
the
the
details
for
this
one,
which
is
the
details,
have
been
added
in
these
last
dates,
and
there
is
also
the
mesh
under
approach
by
which
an
endpoint
must
Only
Store
the
rules
for
the
communications.
It
is
involved
in
as
an
endpoint
as
well.
Next,
please
yeah
so
on
the
tunnel
Ripple
based
route
over
approach.
Here,
the
assumption
is
that
we
are
using
Ripple
non-stirring
mode
and
the
overview
would
be
as
follows.
A
Packet
sent
by
A6
Ln
are
tunnel
upward
to
the
root
and
if
the
final
destination
is
another
6
Ln
in
the
same
Ripple
domain,
then
the
packets
are
tunnel
downward
from
the
root.
So
then
we
have
RFC
9008,
which
describes
how
a
packet
would
be
transmitted
from
a
6lm
to
another
node
which
could
be
another
six
land
or
the
root
in
the
same
Ripple
domain
or
an
external
node.
So,
according
to
this
RFC
for
downward
traffic,
there
is
IPv6
in
IPv6
tunnel,
except
when
the
route
itself
is
the
packet
source
and
there's
the
tunnel.
A
A
A
A
A
A
So
for
Upward
transmission,
the
format
is
similar.
However,
in
this
case,
we
don't
need
the
source,
routing,
header
and
formation
under
the
ideas
that
the
formats
would
be
the
same
as
those
in
RFC
4944.
However,
the
compress
header
in
this
case
of
the
IPv6
packet
would
be
a
header
compression
would
be
made
by
means
of
chic.
A
So
there
are
other
fewer
dates
in
Section
5,
which
is
about
Chic
compression
of
IPv6
UDP
called
headers.
Now,
we've
added
that
each
row
defines
the
set
of
protocols
whose
headers
are
being
compressed
or
decompressed.
For
example,
in
some
deployment
one
could
decide
to
assign
rule
IDs
one
two
three,
for
example,
to
compress
the
IPv6
header
Only
Rule,
like
this
fall
to
seven
to
compress
IPv6,
UDP
and
Rule,
like
this
8-15
to
compress
IPv6,
UDP,
Co-op
and
other
than
that.
A
A
K
K
B
K
K
K
And
the
second
problem
is
that
Auto
photo
processing.
Basically
it's
because
the
ipcon
May
produce
longer
pay
nodes.
The
compression
is
not
effective,
for
example,
and
the
obviously
says
that
if,
if
compression
is
not
effective,
you
just
send
the
uncompressed
results
and
the
IP
comp
header,
but
say
in
the
decompression
side
the
packet
with
the
IP
comp
header
will
go
through
the
decompression
code
processor
first.
But
if
a
package
is
without
IP
comparator,
it
will
be
forward
directly.
So
it's
different
process
is
cause
also
of
other
next.
K
So
the
the
second
negotiation
is
about
so
we
add
the
ipcon
header,
regardless
of
the.
If
the
pain
of
this
and
uncompressed
or
not,
we
can
just
add
a
new
CPI
value
for
the
uncompressed
packet
next
next
side.
Please
yeah,
that's
one!
Basically,
we
think
a
signal
also
have
some
kind
of
compression
on
the
header,
so
we
think
we
can
ask
a
phone
the
suggestion
about
this
kind
of
design.