►
From YouTube: IETF103-MANET-20181108-1120
Description
MANET meeting session at IETF103
2018/11/08 1120
https://datatracker.ietf.org/meeting/103/proceedings/
A
C
A
A
A
Then
we've
got
a
remote
presentation
on
media
echo
from
creased
us
on
multipath
chameleon,
which
is
a
surrounding
protocol
work.
That's
been
done
and
brains
going
to
talk
to
us
about
a
synchronous
network
management,
specifically
in
DTS,
and
then
Rick's
got
some
a
short
presentation
on
some
multicast
related
data
items
before
he
left.
A
So
let's
look
real
quick,
a
document
status
right
now.
We've
got
two
documents
and
in
publication,
requested
the
lid
extension
in
the
multi
hop
forward
in
the
extension
perdy
left.
The
lid
extensions
been
in
that
requested
status
for
almost
80
days,
so
we're
trying
to
figure
out
what
the
log
jam
is.
There.
E
A
A
A
F
A
G
A
F
You
the
thought
to
build
something
a
little
funny
here,
we're
rendering
PDFs
but
I
think
we
can
get
the
point.
We've
I
think
we
just
talked
about
the
latency
extension,
so
I'm
not
sure
how
much
more
no
I'm.
Sorry,
we
didn't
talk
about
latency,
the
other
one.
So
this
is
a
document.
That's
post
last
call
the
last
call
completed
in
February.
We
addressed
the
comments
as
best
as
we
could
published
an
update
and
we
didn't
get
any
of
any
complaints.
So
we
think
we're
ready
for
public
icing
on
this.
One
I
agree.
B
Also
I
looked
at
that
and
it's
it's
a
pretty
it's
a
really
simple
document.
I
think
everyone's
had
time
to
look
at
it
haven't
and
always
ITF
last
call,
but
it's
really
simple:
I'll
do
the
write-up
on
that
and
move
it
forward.
Thank
you
unless
there's
an
objection
in
the
room
or
on
list
I'll,
take
it
upon
me
to
do
that
very
soon
and.
F
F
F
We
have
these
documents
have
a
bit
of
a
history,
the
it
actually
started,
with
a
meant
that
Stan
wrote
and
that
got
modified.
The
concepts
got
modified
a
bit
and
ended
up
in
something
that
was
Elop
flow
control
and
along
the
way,
there
was
some
decisions
to
split
the
documents
apart
and
that's
why
we
have
a
zero-zero
that
we're
noting
that
we
think
is
ready
for
last
fall.
The
reason
why
we
think
it's
ready
for
last
call's
we've
taken
the
last
action
that
was
identified
as
being
open
on
the
other
that
0-3
document
actually
I.
F
Guess
we
started
with
credit
extension
and
more
broke
it
into
these
three,
so
I'm
gonna
go
through
them
a
little
bit
more
and
but
we
think
the
first
three
are
ready
for
last
call
as
part
of
this
process.
We
identified
that
being
able
to
do
traffic
classification
based
on
Ethernet.
Headers
is
a
good
thing
as
well.
F
Sort
of
actually
almost
more
aligned
with
develop
and
Ikey,
but
so
it's
funny
it's
coming
last,
but
we
we
have
an
individual
document
on
that
and
we
think
that
that
should
be
adopted
by
the
working
group
it'll
be
interesting
to
see
how
much
work
we
want
to
do
after
we
go
to
adoption.
You
may
find
we're
gonna
go
rapidly
to
last
call
right
after
adoption.
That
said,
I
think
every
author
thinks
that
so
once
it
comes
into
the
working
group,
we'll
figure
out
what
really
needs
to
be
done.
E
E
Thank
you
actually,
Rick
again.
This
actually
raises
a
larger
question.
The
reason
we
were
splitting
it
out
was
to
make
sure
that
DNA
extension
Dean
of
extensions
existed
in
their
own
document,
so
that,
if
you
supported
extension
bar
there
was
a
document
called
blah.
So
the
reason
why
the
ethernet
and
the
dscp
extensions
were
split
out
into
separate
documents.
Despite
the
fact
they
are
almost
a
cut,
cutting
paste
with
a
replace
for
the
word
Ethernet
and
dscp.
In
fact,
I
missed
one
of
those,
but.
E
F
I'm
not
at
all
opposed
to,
but
you
really
are
saying
the
same
things
that
I
have
here
and
that's
actually
great,
because
what
it
shows
is
that
I'm
in
sync,
with
the
working
group,
which
is
really
what
he
at
least
at
least
with
rec,
so
as
Rick
was
talking
about,
we
had
in
the
working
group
in
previous
sessions,
talked
about
that.
It
would
be
worthwhile
to
split
the
functions
that
are
being
find
within
the
document
so
that
they
can
be
composed
in
different
ways
and
that,
yes,
credit
control
is
an
important
thing
on
its
own.
F
But
so
is
traffic
classification
and
that
in
the
future
we
might
want
to
do
traffic
classification
without
credit
control,
and
we
should
be
able
to
specify
that
that
we
can
reference
the
RFC
that
brings
in
just
traffic
classification
and
doesn't
bring
in
credit
window
control.
And
that
was
the
reason
for
the
split.
You
know.
I'll
say
that
this
was
asked
of
the
authors
and
we
did
that
if
the
working
group
preferred
to
publish
it
together
and
we
could
get
through
the
process-
faster,
we'd
be
cool
with
that.
E
Keep
it
quick,
Rick
Taylor
again,
I
was
the
guy
who
asked
to
split
these
simply
because
I
want
to
do
metrics
per
flow.
Hence
I
wanted
to
refer
to
a
document
about
flows
without
bringing
in
credit.
Renewing.
My
previous
question
was
whether
just
because
it's
a
new
extension
do
I
need
a
new
document.
Alright,.
F
So
the
other
thing
that
we
did
is
we
do
have
a
split
of
the
diffserv
aware
credit
window
extension
and
here
are
now
talking
about
extensions,
not
data
items
and
the
802
Q
or
Ethernet
creditor
extension
and
the
reason
those
are
two
separate
documents
is
that
so
you
can
specify
that
you
want
to
be
do
Ethernet,
credit,
annoying
or
IP
credit
windowing
and
be
clear
what
you're
specifying
as
you
know,
so
that's
both
from
a
vendor
standpoint
as
well
as
from
a
provider.
So
our
user
standpoint.
F
You
want
to
know
what
you
have,
because
if
you
don't,
if
you
don't
split
them,
we
can
have
a
router
that
says
we're
conformant
with
the
extension
and
a
radio
Odom
that
says
it's
conform
it,
but
one
does
Ethernet
one
does
IP
and
guess
what
it
work
together.
So
that's
the
reason
for
that
split
and
that's
reflected
in
the
working
group
document,
which
is
the
dip
server.
Where
one
and
the
individual
document.
F
As
Rick
said,
these
are
basically
identical
documents
but
define
a
new
extension
value
for
each
of
those
operations
and,
just
as
a
reminder,
excuse
me
as
a
reminder:
we
have
Ethernet
traffic
classification
defined
in
our
base
traffic
classification
document.
Why
is
it
okay
to
have
Ethernet
and
IP
together
in
that
document?
Is
because
that
document
just
defines
data
items
it
doesn't
find
the
use
of
the
data
items.
The
use
of
the
data
items
happens
in
the
extension
documents.
Those
should
be
separate
and
that's
why
we
don't
see
that
reflected
on
the
bottom.
F
So
what
what's
next
we
think
the
top
three
are
ready
for
last
call.
We
think
the
bottom
one
is
very
simple.
As
Rick
said,
it's
basically
the
same
document
as
the
destinated,
the
diff
server,
where
credit
extension,
but
we've
done
a
said,
we've
done
and
replaced
diff
server
where,
with
ethernet
or
802
Hydra
blue
802
that
one
headers.
F
F
You
know
I'm
an
author
I
want
to
get
my
document
done,
but
it
would
if,
if
we're
not
going
to
do
that,
this
is
the
next
best
thing
is
we'd
like
to
see
the
last
call
that
the
existing
working
group
documents
that
we've
gone
over
and
have
been
stable,
basically
for
I,
think
two
or
three
I
ETFs
now
they've
been
technically
stable.
It's
just
the
editorial
stuff.
We've
been
getting
right
and
I
do
think.
Those
were
good
changes.
It's
not
that
it
was
unnecessary
delay.
We
now
have
the
documents
in
the
right
form.
This.
F
E
Algorithm
I
wrote,
Andy
I,
don't
necessarily
want
to
add
more
documents
to
my
queue
since
I'm
already
late,
as
you
pointed
out
in
your
first
life
I,
just
wanted
to
point
out
that,
according
to
one
of
the
RFC's
that
I
forget
the
name,
the
number
of
that
talks
about
the
working
group
process.
It
is
up
to
you
as
chairs,
for
the
side
where
you
need
to
work
at
your
best
or
not.
A
Point
taken,
I
was
just
a
little
bit
concerned
about
one
thing
too
much
together,
because
right
now,
I
figure,
it's
the
same
chance
as
all
of
us
being
struck
by
lightning
right
now,
thank
you
didn't
happen,
but
somebody
we
could
ask
for
for
working
group
adopt
it's
of
the
of
the
ethernet
credit
extension
and
find
somebody
with
some
kind
of
odd
out
of
left
field.
Concern
that
none
of
us
thought
of
you
know
so
I'm
just
trying
to
trying
to
be
inclusive
and
whatever
let
the
process
work.
E
F
F
Okay,
okay.
I.
Do
want
to
point
out
that
we,
my
co-authors,
have
some
code
published
open
source
for
gillip.
They
have
made
a
an
update.
I
meant
to
check
where
I
came
up
here,
whether
or
not
that
got
pushed
it's
actually.
The
hope
was
before
I
stood
up
and
talked
that
update
would
be
available
on
the
repo
and
that
change
was
to
put
in
sub
data
items
and
the
putting
in
sub
data
items
turned
out
to
be
a
little
more
complicated.
F
F
We
did
actually
talk
about
a
simplification
that
would
have
made
his
code
easier
to
implement
and
agreed
that
it
would
not
be
the
right
format
for
the
standard
is
that
it
really?
It
actually
was
an
unnecessary
restriction
that
would
hinder
how
he
did
sub
data
items
of
the
future,
and
what
we
had
in
the
document
was
better,
even
though
it
made
his
implementation
work
a
little
bit
harder,
but
it
wasn't
a
big
deal.
I
mean
in
the
end,
he's
done
it.
It's
available.
It's
tested,
I'm.
F
I
F
A
B
Have
one
one
thing
I
would
like
to
bring
up
there?
You
look
guarding
multiple
documents,
kind
of
a
direction
toward
Alvaro,
and
maybe
the
group
in
general
is
do
we
want
to
continue
proceeding
with
having
one
extension
per
document
or
is
there
a
way
that
is
specified
that
the
ITF
uses
where
you
can
specify
multiple
extensions,
so
that
you
know
it's
RFC,
xx,
xx,
dot
or
some
subset
of
that
suspension?.
A
Iterated
or
who
explained
the
case
of
if
you're,
going
to
put
multiple
features
into
one
document
and
you
let
implementers
then
pick
and
choose
which
feature
they
want,
that
they
can
still
claim
compliance
and
I
believe
he,
the
same
really
smart
guy
said
it
again
right
up
here
right
now,
so
my
vote
would
be
no
for
exactly
the
reason
that
Lou
has
commented
on
on
multiple
occasions
with
me
in
the
room
and
that's
the
one
to
one
in
that
way.
If
you
say
I
support,
RFC
blah-dee-blah,
you
know
every
piece
of
functionality.
That's.
B
B
E
B
E
It
is
up
to
the
right
here
what
you
wants
to
do
personally,
just
because
they
couldn't
come
into
my
queue.
I'd
rather
have
less
documents
to
read
by
this
is
not
the
only
working
group
that
this
point
has
been
made
about
compliance
and
your
RFPs
and
thinks
of
that
sure
you
could
ask
the
RFE
the
use
report
RFC
five
section:
two
where
that
gets.
You
know
really
complicated,
really,
not
nice.
So
if
the
working
who
wants
to
publish
you
know
whatever
number
of
extensions
in
different
narcy's,
that's
fine
with
me
and
that's
fine
with.
F
F
E
E
F
H
E
That
you,
let
me
know
what
you
want
it
so
that
I
don't
have
to
measure
the
gas
with
all
the
pens.
Are
there
way?
No,
the
best
thing
to
do.
Yes,
thanks
retail,
you
again
very
quickly
talking
about
rfp's,
the
incoming
RFPs
I've,
seen
about
deal
app
have
actually
specified
extensions,
not
numbers
virtually
because
most
of
them
are
in
drafts.
I'm
saying
to
people
seem
to
be
talking
about.
I
need
this
extension.
I
need
that
extension.
E
A
J
H
H
Let
me
if
I
have
my
style
of
the
presentation,
then
yes,
yes,
go
ahead,
all
right
guys.
Essentially
maybe
you
remember
us.
We
submitted
a
couple
of
years
ago.
It
was
Arvind
Rama,
Rama
Rica.
One
of
my
draft
was
called
chameleon
back
then,
is
it
was
admit
that
believe
in
2014
in
ITF
I
think
he
went
to
your
meeting
in
Amsterdam
presently
the
other
thing
and
then
I
think
he
was
in
the
States
at
some
point
present
there
as
well.
Since
then
we
try
to
commercialize
it.
We
haven't
been
very
successful.
A
H
End
us,
we
are
continuing
the
research
path.
So
what
I
am
here
I'm
down
here
actually
I'm
in
Malaysia
at
the
moment
and
in
Thailand
earlier
this
week?
Actually
because
we
have
a
very
big
project,
funded
by
the
UK
government,
a
fan's
free,
UK,
University,
King,
University's,
Kingston,
sorry
and
Glasgow
in
Scotland
to
work
with
Malaysia
a
few
universities
in
Malaysia
to
set
up,
let's
say
a
network
and
a
medicine
Network
actually
to
support
these
communities
when
there
is
any
catastrophic
events
like
that,
not
me
a
few
years
ago.
H
So
that's
the
reason
I'm
down
here.
Actually
in
Malaysia,
actually
working
with
guys
who
set
up
a
prototype
is
we
are
actually
one
here
and
a
bit
on
the
project
and
and,
as
I
said
actually
sorry
is
part
of
the
of
the
team.
Anna.
Can
you
hear
me
yeah,
I'm,
okay,
yeah,
yeah,
you're,
fine,
okay,
great
and
then
and
sorry
actually
provide
the
5g
infrastructure.
So
essentially
you
have
a
5g
extension
to
that
Kingston.
Since
this,
as
I
said
actually
long
time
ago,
we
work
on
manats.
H
So
we
continue
down
that
path
on
the
research
side
of
things.
So
we
do
a
bit
of
commercial
activity
of
mammoths,
but
I'm
not
going
to
talk
about
this
here.
So
essentially,
I
said
before
my
ex
PC
students
are
veneer.
America
and
gran
Miller
actually
created
a
design.
That
protocol,
which
was
called
chameleon
chameleon,
was
a
kind
of
a
Hydra
protocol
between
profit,
even
reactive,
routing
protocols,
very
well
defined
by
the
ITF.
H
So
essentially,
the
plan
here
is
actually
to
create
a
kind
of
in
a
new
protocol
still
based
on
chameleon
with
for
face
phases
of
operation,
because
still
it
practically
reactive
face
still
has
disaffiliation
face.
I
know
I
know
actually
long
time
ago
when
we
presented
in
IDF
on
IDF.
We
got
a
lot
of
comments
and
a
lot
of
kind
of
ideas
for
improving
the
protocol,
especially
the
automation
plane.
So
we've
done
actually
in
order
to
improve
it,
and
we
got
a
lot
of
comments
on
board
is
actually
to
create
this
monitoring
face.
H
H
A
H
See
anything
on
my
scream,
I
don't
know
why.
Maybe
I
don't
do
something
correct
yeah
anyway,
life
or
yeah,
so
essentially
a
quick
overview
of
the
protocol
so
as
before
it
has
four
phase.
It's
one
more
phase
from
the
initial
design,
the
protocol
and
we
have
we
are
working
actually,
the
multipath
extension
of
all
SL
version.
Two
and
the
reactive
side
is
actually
on
iotv
version.
Two.
H
Now
the
reactive
phrase
is
triggered
when
the
network,
depending
on
the
currents
and
that
is
been
kinda,
run
on
the
on
the
on
our
algorithm
at
fables,
reactive,
let's
say,
parameters,
reactive
statistics,
so
in
that
case,
actually
we're
using
the
monitoring
faith
to
trigger.
If
you
like,
we
need
reactive,
Fame
now
tipping
point.
The
transition
between
proxy
and
react
is
actually
a
dealt
by
the
ocean,
a
complaint
which
is
the
same
within
priori.
We
make
notable
for
the
chameleon
protocol
a
with
Sameer
idea
that
we
thought
now
I'm
slide
5.
H
So
the
previous
idea
is
to
create
a
set
of
level
n
values.
This
is
different
from
the
previous
protocol,
which
is
a
particular
specific
to
the
individual
routing
protocol
other
either
reactive
or
party.
So
for
this,
like
specific
submission,
we
have
created
four
scenarios
by
a
trained
thing.
We
know
density,
do
not
mobility,
energy
consumption
and
the
cold
extremes
requirements,
mainly
mainly
the
England
constraint
and
all
would
have
done,
have
actually
investigated
and
selected
the
scenario
by
running
ms3
simulations.
H
We
use
the
other
three
to
define
the
best
shooting
scenario
for
our
case
our
case,
one
more
time
a
safe
is
based
on
emergency
medicine
situation,
an
emergency
case,
so
the
audacity
the
adaptive,
my
mold
module
inside
the
node
analyzes
the
network
scenarios
and
then
three
gives
the
appropriate
place
so
business
nough
said,
is
new
from
the
previews
chameleon
protocol.
This
monitoring
phase.
A
H
The
M
phase
within
the
m
p
face
then,
depending
on
the
network
scenario,
selecting
England
specifically
case.
We
have
actually
four
scenarios.
We
are
actually
monitoring
the
situation
and
then,
if
the
depending
on
the
obviously
how
dynamic
the
network
is
not
with
me,
we
are
using
the
equation
made
to
fit
from
pre-placed
work.
H
We
don't
use
at
this
expecting
the
multipath
LDV
version,
two
we
use.
Actually
the
clean
air
will
beep
intention
to
so.
This
is,
if
you
like
that
kind
of
efficiency
of
the
silent
reasoning,
but
our
next
people
like
release,
hopefully
we
be
able
to
accommodate
a
beautiful
extension
of
believers.
In
truth,
then,
we
have
M
faith
in
the
monitoring
phase,
which
is
a
solid,
monitor.
H
Recon
come
with
welfare
so,
depending
on
the
phone
I'm
coming
to
requests
and
using
the
adaptive
module
depending
on
the
network
side
rest
world,
which
again
depends
on
the
certain
characteristics
earlier,
the
community.
We
call
be
of
service
than
the
local
network
and
so
on,
each
latest,
if
it
needs
to
be
to
be
so
to
using
the
later
phase
to
a
reactive
protocol.
H
So,
if
you
like
shorten
it
out,
we
have
put
the
maximum.
How
ultimately
depends
on
the
number
of
hops-
and
usually
we
take
the
to
hoax
scenario
before
we
are
to
be
speak
to
the
population
rate,
depends
on
one
honestly,
you
know-
and
this
is
something
which
is
ongoing.
It
is,
it
is
a
no
improvement
for
us,
and
this
is
something
we
want
to
continue
working
on
and
finally,
if
the
last
slide,
we
begin
my
slide
9,
so
future
directions.
H
H
The
next,
in
terms
of
technical
characteristics,
the
next
the
next
step
is
action.
Quad,
multiple
question
of
nor
the
reactive
nature
will
be
win
all
week
and
implement
that
to
my
own
ministry.
Also,
the
other
thing
you
need
to
actually
to
say,
select,
feathers
and
I
had
among
you
have
four
scenarios.
We
want
to
work
on
a
further
and
video
number
of
scenarios,
such
as
a
little
team
of
network
scenarios,
are
actually
increased,
and
thus,
actually
you
might
pick
you
can
even
like
to
select
from
and
make
your
system
little
bit
more
intelligent,
more
adaptive.
H
Routing
scenario,
so
this
is
the
second
thing
you
want
to
do
and
obviously
we
want
to
continue
working
on
the
simulations.
I
think
the
empirical
side
of
things
by
creating
this
in
you
grow
the
collection
or
ministry.
Hopefully,
bacon
is
available
on
on
there
for
the
global
community
to
welcome
my
manager.
H
A
Crowning
from
the
cares
from
the
chairs
perspective,
my
only
question
to
you
would
be
you've
listed
out
some
future
directions.
Do
you
also
envision
as
one
of
your
future
directions
that
you
would
be
asking
the
working
group
to
accept
this
document
and
move
it
through
the
working
group,
or
is
this
more
of
an
informational
type
thing?
We.
H
K
Okay,
my
name
is
Charlie
Perkins
and
I'll.
Make
it
quick,
but
I
just
have
a
couple
of
questions.
First
of
all,
there's
a
monitoring
phase.
What,
where
where's
the
monitoring
occurring
I
mean
it's
her
part,
ARDS,
a
distinguished
device
and
the
network,
that's
doing
the
monitoring
or
is
it
some
sort
of
distributed
monitoring
or
how
is
that
yeah.
H
Together,
maybe
we
work
together
with
my
student
Arvind.
Maybe
you
remember
him?
Actually
you
paint
with
you
to
in
in
I
think
it
was
enough
now,
because
anything
is
here,
like
a
million
for
the
road
good
to
see
you
good
to
see
you
so
essentially,
yes,
the
morning
monitoring
phase,
then
together,
this
is
numbered,
slide
number
seven,
so
the
monitoring
actually
is
part
of
the
adaptive
module
that
was
in
the
previous
design.
Really
different,
as
I
said
before
is
we
monotone
will
be
account
request?
H
B
B
I
think
we
don't
have
time
today,
but
we
should
take
this
to
the
list
and
it's
an
interesting
development
in
terms
of
future
of
many
and
possible
work.
I,
don't
know
that
this
specific,
like
the
specifics
we
can
get
into
on
the
list
about
how
a
how
a
new
dynamic
using
a
OD
v,
v2
and
LS
r
v2
protocol
could
work
and
if
that's
something
the
working
group
wants
to
work
on.
That
seems
like
the
logical
next
step.
B
A
A
L
You
hi,
my
name
is
ed
brain
I'm
from
the
Johns
Hopkins
University
Applied
Physics
lab
I'm,
a
member
of
the
DTN
working
group.
One
of
the
things
that
we
have
been
working
on
in
DTN
is
what
does
network
management
look
like
in
a
DTN
and
looks
a
little
bit
like
this,
so
so
so
I'm
I'm
on
an
unaligned
boundary.
So
one
of
the
things
that
we
had
started
looking
at
in
DTN
was
how
do
we
manage
a
delay,
tolerant,
Network?
And
how
do
we
manage
a
case
where
we
have
constant
disruptions?
L
We
cannot
assume
sessions
and
in
particular
we
cannot
assume
a
pull
model
of
information
and
we
looked
at
that
from
a
couple
of
different
perspectives.
We
looked
at
it
from
the
challenges
that
news
face
is
looking
at
from
certain
sensor:
networks,
vehicle
networks,
other
resource
constrained
networks
and
and
the
way
we
distilled
the
problem
was
to
say
that
if
you
look
at
some
of
the
most
constrained
use
cases
we
have,
which
are
spacecraft,
fault
management
systems,
yeah.
So
I
did
you
know
flight
software
for
New
Horizons,
which
was
out
past
Pluto.
L
We
really
didn't
have
a
concept
of
a
timely
round-trip
data
exchange
and
we
will
hand
up
having
we
wound
up
there
interesting
stories
about
that
after
the
working
group.
But
we
wound
up
coming
back
and
saying
autonomy.
Models
for
fault
management
are
necessary.
We
do
not
need
sessions
associated
with
that
and
we
know
how
to
do
it
and
pretty
much
all
spacecraft
do
it
in
about
the
same
way
their
proprietary
differences,
but
but
from
a
logical
decomposition.
L
They
do
it
about
the
same
way,
and
it
is
not
the
way
that
we
manage
networks
in
data
centers
today,
because
we
have
high
availability
links.
We
have
standards
and
open
source
tools
and
very
large
investments.
The
question
that
we're
trying
to
answer
in
detain
is:
is
there
a
motivating
overlap
between
these
highly
autonomous
but
very
customized
management
systems
and
the
more
commoditized
high
rate
pull
session
systems?
L
The
first
is
something
called
the
asynchronous
management
architecture,
which
laid
out
sort
of
the
logical
decomposition
of
how
you
would
do
this
and
what
logical
data
models,
roles
and
responsibilities
and
system
properties
would
be
there.
For
all
intents
and
purposes,
it
is
like
a
requirements
document
for
how
one
would
do
asynchronous
management.
L
Second,
from
that
we
created
a
physical
data
model,
we
call
it
an
application
data
model
and
it
is
primitives
associated
with
that
model
and
how
you
would
communicate
them,
and
examples
are
shown
here
in
terms
of
externally
defined
data,
literals
operators,
time
and
state-based
rules
and
reports
and
strongly
typed
variables,
and-
and
these
should
not
be
particularly
new
for
anyone
that
is
looking
at
doing
different
kinds
of
management.
The
important
part
of
this
is
that
the
definition
of
Management
in
this
case
is
not
simply
performance.
Monitoring
of
reports
coming
back.
L
It
is
open
loop
control,
saying
I
need
to
configure
the
device
so
that,
when
I
cannot
communicate
with
you,
these
are
the
responses.
I
need
you
to
take.
This
is
the
data
you
need
to
know
when
to
report
and
when
not
to
report,
and
that
requires
more
than
just
a
table
and
report
semantics
and
then
the
last
is
something
called
the
ANP.
The
asynchronous
management
protocol,
which
is
one
of
potentially
many
encoding
zuv,
that
data
model,
in
this
case
using
Seaborg
and
my
last
slide.
L
If
we
go
to
it
is
we
are,
we
are
starting
to
standardize
this
where
we
have
many
drafts
that
are
coming
forward
in
the
context
of
the
DTN
working
group,
the
first
the
AMA
is
out
there.
It
is
a
a
personal
draft,
but
it
has
been
put
in
as
a
detailed
working
group
draft
AMAO,
seven,
and
if
you
are
interested
in
this,
that
is
the
place
to
start
looking
in
terms
of
overall.
What
we're
trying
to
accomplish
in
terms
of
the
data
model
template
and
the
JSON
encoding
of
that
template?
L
Specifications
that
you
need
to
do
the
kind
of
things
you
want
to
do
end-to-end.
So
the
reason
that
we
were
hoping
to
bring
this
up
to
this
working
group
is
to
come
back
and
say.
Part
of
our
motivation
was
new
space.
Part
of
our
motivation,
we're
sensor,
networks
and
part
of
our
motivation
were
mobile
networks
and
and
a
question
out
to
the
group.
One
is
if
people
are
interested
in
this
too.
E
E
A
E
I'll
be
quick,
so
this
is
a.
This
is
a
pre
draft
concept
that
the
joy
of
the
IETF
meetings
as
you
speak
to
smart
people
and
ideas,
sort
of
start
to
consolidate.
So
just
as
a
quick
recap,
the
there
are
two
thing,
two
reasons
for
delay.
One
is
based
on
the
premise
that
the
radio
system
knows
more
about
what
is
happening
on
the
local
link
than
the
router
does
so
the
it's
a
better
idea
for
the
Rooter
to
go
down
to
the
radio
system
and
say
what
is
going
on.
E
The
second
point
is
that
if
you
can
bootstrap
a
lot
of
your
hello
protocols,
you
can
pre-fill
your
ARP
caches.
You
can
send
around
some
initial
data
in
many
networks,
where
you
have
very
short
contact
times
the
more
you
can
get
chucked
across
the
control
plane
of
the
radio,
the
better
it
means
your
adjacencies
very
short-lived.
Adjacencies
are
still
usable,
so
I'm
not
going
to
read
the
slides,
but
fundamentally
multicast
protocols
and
some
other
useful
protocols
rely
on
rendezvous
points.
You
know
there
is
something
is
elected
in
your
to
hop
neighborhoods
or
whatever.
E
That
is
used
to.
As
a
forwarding
point
for
distributing
now
a
lot
of
the
algorithms
that
decide
how
to
elect
a
rendezvous
point,
they're,
either
statically
configured
or
they
use
a
to
hop
neighborhood
or
whatever
the
radio
system
underneath
has
its
own
topology
built
on
its
own
physics
and
its
own
way
of
working
yeah,
SATCOM
hub-and-spoke.
You
want
to
elect
the
hub
to
be
the
relay
point.
E
It
seems
a
really
sensible
thing
to
say,
but
you're
routing
over
that
may
just
go
hey
I've
got
I've,
got
seven
peers,
which
one
should
I
choose
the
one
with
the
lowest
ID,
which
happens
to
be
a
spoke.
You
know
so
there's
some
very
quick
examples
there.
So
the
proposal
next
slide,
please,
is
to
allow
a
modem
to
inform
a
Rooter
that
it
is
a
good
candidate
as
a
relay,
so
the
modem
can
say:
hey
I'm
in
a
good
spot.
I've
got
good
coverage
to
all
my
peers.
E
I
seem
to
be
in
the
middle
of
the
cloud
of
local
nodes
and
the
other
part
is
to
a
Rooter
to
say:
hey
when
you
see
a
new
dear
modem,
when
a
new
destination
comes
up,
please
tell
him
that
I
have
been
elected
as
the
relay,
because
it
saves
you
bootstrapping
and
it
saves
kicking
up
a
new
leader
election
or
whatever
okay.
So
this
is,
although
this
is
really
useful
for
multicast,
specifically
PIM
and
that
kind
of
stuff.
This
is
not.
This
is
orthogonal
to
the
multicast
components
that
are
in
T
lip
already.
E
So
it's
not
talking
about
multicast
Metrix,
multicast
destinations
unrelated
next
slide,
please.
So
how
do
we
do
this?
A
deal
of
extension,
of
course,
so
we're
proposing
a
new
extension
and
there's
a
question
about
this
later
on,
which
is,
would
introduce
two
new
data
items
which
would
be
per
destination
data
items.
So
one
saying
route,
a
relay
point:
hey
I'm,
a
Rooter
and
I,
whether
a
route
willingness
to
be
a
relay
or
whether
it
has
been
elected
to
be
a
relay.
E
The
election
is
banned
or
you
know
what
over
whatever
algorithm
was
running,
and
the
other
data
item
would
be
the
mode
M
relay
point
so
that
the
modus
of
the
radio
system
could
inform
the
router
to
say,
hey
I,
don't
know
how
you're
sorting
out
your
relays,
but
you
would
be
a
really
good
candidate
or
the
counter
example
is
actually
you'd
be
a
really
bad
candidate
you're.
Currently
in
a
tunnel,
you
can
only
see
one
other
pair
for
God's
sake.
E
Don't
elect
yourself
as
a
don't
announce
that
you're
a
good
relay
point,
because
you're
not
next
slide
yeah.
So
this
is
the
proposed
set
of
drafts.
I've
started
putting
some
text
together
for
a
relay
point
extension
draft:
it's
the
standard,
boilerplate
old,
ion,
a
registration
for
extension,
point
IDs
layouts
of
the
data
items,
ba-ba-ba-ba-ba
I
think
there
could
be
a
second
draft
to
say.
Given
this
extension,
this
is
how
you
make
it
work
with
PIM.
E
Don't
know
in
the
sense
of
networks
that
we
work
here
if
there
is
a
lot
of
any
source
multicast
and
then
you
need.
You
know
the
relation
all
that
stuff
I'm
just
saying
this,
because
if
what
you
see
a
single
source,
then
don't
work
on
the
pin
thing
right.
There's!
No,
but
then
I'm,
not
a
pin
expert!
Isn't
there
is
still
tree
building
and
for
intermediate
nodes
within
your
tree
for
for
branch
branch
nodes
in
your
tree,
they're
effectively
relaying
if
they're
not
running,
if
they're
running
off
n
BMA
links.
E
I
I
Because
you
still
so
when
a
node
says
it
monitors
it's
its
layer,
it
knows
that
it's
very
good
in
average
and
then
it's
SN
a
request
to
be
part
of
the
candidate
relay
set
at
the
end
used.
You
mentioned
you
have
to
be
elected,
meaning
the
decision
to
take
him
as
a
next
hop
is
taken
before
the
transmission
on
not
after
so
I
chew.
E
Right,
okay,
so
I'd
be
I've
gone
very
quickly
because
we're
short
of
time
so
I've
covered
I
made
a
lot
of
assumptions
by
prior
knowledge.
The
the
signals
that
are
coming
through
are
not
sets.
They
are
not
demands,
they're
purely
informational,
so
the
radio
can
say
you
would
be
a
good
relay.
The
router
can
completely
ignore
that
you
know
it
may
say:
hey
I'm
running
on
two
double-a
batteries,
I'm
not
gonna,
be
a
relay.
So
it's
it's,
it's
purely
informational
transfer
and
it
can
change
over
time.
They're
a
develop
destination
update.
E
You
could
say:
hey
you're,
a
good
relay
point
and
then
a
minute
or
two
later
you
can
say
you're
not
anymore.
You
know,
you're
in
a
moving
vehicle.
You've
disappeared,
don't
be
a
relay
anymore.
What
the
other
layer
does
is
entirely
up
to
the
other
layer.
It's
just
providing
more
information,
and,
following
from
that
point,
is
this?
Actually
two
extensions
is
one,
so
the
router
can
say:
hey
I've
been
elected,
a
relay
point,
perhaps
link
layer.
E
You
might
be
able
to
do
something
or-
and
please
pass
this
on
to
other
people,
so
we
can
do
fast.
Bootstrapping
of
who's
the
relay
and
is
the
other
extension
the
modem
able
to
signal
to
the
route
up
to
layer.
Three
to
say
you
would
be
a
good
candidate
or
you
would
not
be
a
good
candidate
questions
is
this,
and
this
goes
back
to
the
one
document.
Two
extensions,
one
extension
that
covers
quite
a
few
things
are
two
different
abilities
use
cases
I'm
looking
at
the
chairs-
and
this
is
probably.
A
B
F
Neuberger
in
the
interest
of
limiting
scope
of
information
and
improving
layering,
you
might
consider,
instead
of
making
the
decisions
for
the
router,
because
that's
what
you're
doing
is
you're
making
a
router
decision
provide
the
information
that
is
useful
to
the
router
to
make
that
decision.
So
if
what's
really
going
on
is,
is
you're.
Identifying
who's
richly
connected
have
an
extension
that
says
connectedness
and
then
have
a
document
that
says
if
you're
running
him
use
one
who
has
the
highest
connectedness
and
then
you.
F
A
F
F
E
We
might
use
it
for
something
else:
yeah
can
I
paraphrase
I.
Think
you're
saying
don't
my
proposal.
What
our
proposal
is
boolean
flag,
good,
bad!
Your
proposal
is
make
it
an
integer
called
connectiveness.
You
know
you
can
you
can
see.
I
am
connected
directly
to
18
rather
than
4,
and
you
could
use
that
so
yeah.
Maybe.