►
From YouTube: IETF110-DTN-20210311-1600
Description
DTN meeting session at IETF110
2021/03/11 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
Except
in
the
movies
anyway,
so
it's
1500
or
1700
utc.
This
is
the
dtn
working
group
session
and
I
think
we
should
start
so.
A
Okay,
I'm
gonna
have
to
jump
to
the
slide
deck,
so
I
can
lose
a
picture
there.
So
you
get
to
watch
me
staring
at
my
screen,
so
the
agenda
is
published
online
as
part
of
the
meeting
materials.
There's
a
url
here
guides
for
participants
particularly
relevant
with
this
being
an
online
session.
Although
given
it's
now
thursday,
one
would
have
hoped
you
would
have
participated
in
a
few
other
things
if
you
were
attending
all
iedf
week,
if
you
need
any
technical
assistance,
there's
a
url
there
as
well.
A
So
this
being
an
ietf
working
group
meeting,
it
is
covered
under
the
note.
Well,
I
am
not
going
to
go
into
a
deep
legal
analysis
of
this
document.
If
this
is
your
first
ietf
or
this
document
and
the
concept
of
a
notewell
is
a
mystery
to
you,
you
need
to
read
it
carefully
because
you
are
actively
contributing
during
this
meeting
and
there
are
ramifications
to
do
with
ipr
disclosure
associated
with
that.
I
am
not
a
lawyer,
but
this
document
was
written
by
lawyers.
A
Go
and
read
it
if
you
have
any
queries
type
notewell
into
your
favorite
search
engine
and
it'll
find
it
so
ed
go
ahead
agenda.
B
Certainly
so
the
the
working
group
meeting
for
the
two
hours
that
we
have
is
essentially
split
into
two
parts.
The
first
part
is
our
series
of
four
presentations
to
talk
about
some
of
the
work
that
is
going
on
and
in
particular
to
have
some
some
of
the
users
in
our
community
who
are
starting
to
deploy
dtn,
either
to
talk
about
their
deployments
or
to
talk
about
the
additional
things
they
want
to
add
in
support
of
their
deployments
and
then
the
second
part
of
the
meeting.
B
If
you
notice
it
says
next
steps
for
the
working
group
and
rechartering
40
minutes,
we've
allocated
just
sort
of
a
large
enough
chunk
of
time
to
talk
through
all
of
the
things
that
we
think
are
candidates
for
the
next
set
of
working
group
charter
items
and
then
to
talk
a
little
bit
about
how
we
might
prioritize
those.
We
can't
do
everything
in
the
next
recharter.
B
We
need
to
make
sure
that
we
take
on
enough
material
to
move
the
community
forward,
but
not
so
much
material
that
it
takes
us
years
and
years
and
years
before
we
can
start
crossing
things
off
the
list,
and
I
think
that
that
is
a
large
and
interesting
and
complex
discussion.
That's
going
to
take
a
fair
bit
of
time,
so
that
is
the
second
half
of
the
meeting.
B
A
Yeah,
it's
administrative
yeah.
Sorry,
I
should
have
probably
put
this
before
the
agenda,
but
I
was
shuffling
slides
around
at
the
last
minute,
so
adam's
already
put
a
post
on
the
chat
saying
we're
using
kodi
md
it
for
note
taking
it's
a
collaborative
platform.
So
please
all
help
to
collaborate.
A
Please
hope
to
please
all
help
to
try
and
get
accurate
minutes
and
please
don't
type
all
over
each
other.
I
had
a
different
working
group
where
the
notes
somehow
failed
to
merge
at
all
well
and
it
ended
up
as
gibberish,
but,
to
be
honest,
someone
could
have
been
typing
gibberish
to
start
with,
so
a
little
bit
of
care.
It's
not
a
bad
system,
but
we
are
global
and
latency
can
be
a
problem.
The
mailing
lists
you
probably
are
aware
of.
If
not
they
are
recorded
there.
A
Magnus
westland
has
finished
his
term
as
rad,
so
a
massive
thank
you
to
magnus
for
helping
get
bpsec
and
bp
base
and
tcpcl
over
the
line
and
welcome
to
our
new
ad.
Who
is,
I
hope,
I've
pronounced
that
right.
A
I
should
be
continue
to
refer
to
him
as
a
head,
because
I
struggle
with
names,
because
I'm
an
idiot
and
also
a
big
thank
you
for
our
new
working
group
secretary,
adam
whitaker,
for
basically
deciding
he
would
be
happy
to
take
extra
notes
and
nobody's
quite
sure
what
a
secretary
does,
but
you're
very
welcome,
and
with
that
ed,
you
sort
of
covered
the
charter
items.
But
the
key
point
is
bp:
bis.
Bp,
sec
and
tcpcl
are
now
in
the
rfc
editor
queue.
This
is
a
huge
achievement.
A
Well
done
everyone
involved
and
a
massive
thank
you
to
the
author
teams
and
also
the
isg
reviewers
and
everyone
discussing
the
fine
points
of
the
feedback.
We've
done
it
it's
taken
a
very
long
time,
but
they
are
complicated
things
and
I
think
the
working
group
should
be
deserved,
deservedly
proud
of
doing
it
and
the
authors,
particularly
so
as
a
follow-up
to
that.
The
fourth
document,
which
is
the
bp
sec
default
security
context
document,
has
just
been
submitted
to
the
iesg.
B
That's
correct,
I
think
the
next
step
is
the
ad
review
and
we've
not
gotten
feedback
yet.
A
Okay,
possibly
the
change
in
ads
is
going
to
slow
that
down,
and
it's
probably
the
head's
first
document
to
look
at
so
he
will
undoubtedly
have
some
questions.
The
looking
at
the
charter
items
as
they
currently
stand.
We
have
a
charter
item
for
custody
which
has
sort
of
been
superseded
by
the
bundle
in
bundle,
encapsulation
procedures,
so
tunneling
is
part
of
custody
transfer.
A
Scott
is
going
to
say
a
few
words
about
that
in
a
minute,
and
our
intention
is
to
roll
that
into
any
re-chartering,
so
to
clarify
that
we're
not
looking
at
custody
transfer
per
se
as
a
technology,
but
probably
rolling
it
into
bundle
in
bundle.
If
that
seems
the
right
technology,
and
with
that,
that's
a
repeat
slide
on
the
agenda.
A
A
A
In
which
case
I
will
I
will
switch
slides
and
I
will
put
the
slides.
C
B
We'll
see
if
he
reconnects,
if
not
give
me
a
moment,
and
I
can
take
over
and
and
drive.
C
I
can
I
try
putting
in
a
headset
that
may
be
better,
but
I
thought
this
would
be
better
coordinated.
I
don't
know
it's.
It's.
A
Why
can
I
no
let
me
just
find
these,
I
keep
opening
these
slides
and
not
you've
named
them
solar
system,
internet.
That's
why
I
keep
there.
We
go.
C
C
A
C
Okay,
so
let
me
press
on
with
this
and
the
reason
that
the
date
on
this
is
so
weird
is
that
this
is
actually
a
talk
that
I
gave
three
years
ago.
I
didn't
do
any
new
slides
because
really
there
hasn't
been
any
significant
change
in
the
thinking
on
bundle,
button
encapsulation.
Since
then
this
is
actually
a
pretty
good
summary
of
of
where
we
were
then
on
on
this
topic
and
and
where
we
are
now.
C
I
believe
on
this
topic
so
and-
and
these
slides
had
already
been
cleared
for
an
unlimited
release,
so
it
saved
me
a
whole
lot
of
administrative
stuff.
So
with
that
as
background,
can
we
go
ahead
to
the
next
slide?
The
first,
which
is,
I
think,
a
summary
of.
What's
in
the
presentation.
C
I
will
very
briefly
go
over
one
of
the
bundle
encapsulations
history
talk
about
aggregate
custody,
signaling,
which
is
an
elaboration
of
the
custody
transfer
that
was
in
the
original
rsc
5050
specification
go
through
the
current
design
of
bundle,
bundle,
encapsulation
and
then
to
to
whatever
extent
people
are
patient
with
it.
C
I
can
go
through
some
of
the
the
ways
in
which
bundle
and
bundle
encapsulation
technology
can
be
applied,
which
I
think
they're
actually
quite
interesting
and
and
ingenious
in
some
ways,
and
then
I
guess
a
note
on
on
what
we
can
do
in
the
future.
So
next
slide
please
and
the
next
one
after
that,.
C
So
the
original
bundle
bundle
specification
dates
back
to
august
of
2009.
It
was
put
together
by
some
folks
at
mitre
corporation,
who
are,
I
think,
keith,
of
course,
is
still
heavily
involved
in
dtn.
Bob
durst
is,
I
think,
an
amused
spectator.
At
this
point.
C
It
was
the
original
idea
was
that
bundle
bundle,
encapsulation
would
be
a
bundle
protocol
application
that
is
living
you
can
think
of
it
as
being
above
bundle
protocol
and
the
motivations
for
it
were
support
for
content,
centric,
networking
custodial
retransmission
of
multicast,
bundles
and
and
security
tunneling,
especially
traffic
analysis.
Defense.
C
Next
slide,
please,
those
motivations,
I
think
are
are
are
still
kind
of
handy
and,
and
they
are
more
or
less
preserved
in
in
later
thinking,
on
bundle
and
bundle.
Encapsulation,
we
should
sort
of
get
resurrected
in
2013.
C
I
wrote
up
a
draft
for
it
in
march,
and
here
the
idea
was-
and
it's
sort
of
it's
just
a
matter
of
looking
at
it
in
a
different
way.
I
guess
it's
conceived
in
this
draft
as
a
convergence
layer
protocol
underneath
bundle
protocol
instead
of
a
an
application
above
it,
and
that
was
intended
to
solve
a
couple
of
problems.
C
C
It
gave
us
a
way
of
of
implementing
security
with
a
security
source
and
a
security
destination
that
it
was
more
rational
and
more
powerful
than
in
the
original
bundle
security
protocol
spec
it
it
solved
a
bunch
of
of
potential
routing
problems
and
ways
in
which
routing
and
security
could
conflict
next
slide.
Please.
C
So
taking
a
step
back
at
at
the
same
time,
we've
been
looking
at
custody
transfer
and
in
2015
2016
we
we
looked
at
what
became
the
eventual
decision
to
remove
custody
transfer
from
bundle
protocol.
There
were
a
couple
of
problems
with
it.
C
One
was
that
custodial
retransmission
was
was
problematic
in
a
number
of
ways,
the
two
most
prominent
being
that
accurately,
estimating
the
round-trip
time
was
not
possible
in
the
general
case,
because
the
the
entity
that
would
be
acknowledging
the
bundle
might
be,
the
next
bundle
hop
or
it
might
be,
six
bundle
hops
away.
There
was
no
requirement
for
restricting
that,
and
so
you
just
couldn't
really
know
who
was
gonna
receive
and
take
custody,
and
so
you
couldn't
know
when
that
would
happen.
C
You
couldn't
know
when
it'd
be
efficient
to
time
that
out
and
retransmit,
maybe
even
more
of
a
problem
bundles
that
were
fragmented
by
non-custodians.
The
the
original
custody
holder
would
never
receive
a
custody
acknowledgement
and
the
custody
transmission
would
just
basically
break
down
all
the
same.
There
were
and
are
some
deployment
scenarios
where
a
delay,
tolerant,
asymmetric
acknowledgement
mechanism
is
needed
and
bundled
protocol
is,
is
clearly
the
way
to
do
that
next
slide.
C
So
so
the
the
idea
there
was
well
how
about
just
making
bundle
protocol
encapsulation
a
convert,
make
custody,
transfer
and
encapsulate
a
convergence
layer,
re-transmission
mechanism
same
as
tcp
or
ltp,
that
is,
between
topologically
adjacent
bundle,
protocol
nodes.
So
you
would
do
custody
transfer
at
the
convergence
layer,
so
you'd
use
bundle
protocol
as
a
configurator
protocol.
D
C
Well,
one
of
the
bundle
encapsulation
was
already
doing
that,
so
the
the
concept
suddenly
became,
let's
just
put
custody
transfer
into
bundle
and
bundle
encapsulation
and
use
the
ibe
for
both
purposes
independently
or
together.
That
is
it.
It
can
function
in
to
solve
some
cross-domain
security
problems,
with
mechanisms
for
security
sources
and
destinations
and
and
at
the
same
time
it
can
be
the
the
place
where
we
do
reliable
convergence.
There
re-transmission
over
asymmetric
paths,
using
bundle
protocol
next
slide.
C
So
taking
one
more
out
of
left
field
approach
at
this
in
in
2012,
there
were
some
folks
at
university
of
colorado
who
were
working
on
a
mechanism
for
more
efficient
custody
transfer
by
aggregating
custody
signals
for
for
multiple,
bundles
and
sort
of
tagging,
the
bundles,
so
that
the
signals
could
be
applied
to
multiple
bundles.
D
C
C
For
example,
where
that's
definitely
true
in
particular,
this
mechanism
was
implemented
and
was
used
for
reliable,
vertical
communications
with
the
international
space
station,
starting
in
probably
2014,
something
like
that
and
and
has
been
very
well
received.
It's
it's
there's
a
lot
of
enthusiasm
for
aggregate
custody,
signaling
next
slide.
C
So
aggregate
custody
signaling
has
been
so
successful
in
operational
use
in
on
iss
that
it
seemed
to
me
that
the
original
custody
transfer
really
wasn't
necessary
that
the
acs
can
do
all
the
things
that
the
original
custody
transfer
system
could
do
and
and
can
also
be
much
more
efficient.
C
And
so
this,
this
new
design
for
bundle
and
bundle
encapsulation
posted
in
may
of
2018,
includes
custody
transfer
in
bundle
and
bundle
and
in
particular
it
concludes
the
aggregate
custody,
signaling
concept
in
bundle
and
bundle
encapsulation
that
enables
bib-e
to
operate
as
a
an
optionally.
It's
not
necessarily
you
can
turn
off
a
custody
transfer,
but
it's
an
optionally,
reliable
convergence
layer
protocol
under
bundle
protocol
that
is
asymmetric
and
and
can.
C
Traverse
multiple
bundle
hops,
because
the
the
the
end
points
at
the
convergence
layer,
which
are
the
sender
and
receiver
of
the
custody
transfer
destination,
will
will
in
turn,
send
their
bundles
using
underlying
custody
transfers.
This
turtles
over
turtles,
you
know,
turtles
all
the
way
down
sort
of
thing,
very
bizarre,
looking
stack,
but
it
enables
this
quite
powerful
operational
mode.
C
The
encapsulated
bundle
can
be
acknowledged,
that
is,
the
the
the
custody
transfer
can
be
used
to
to
move,
that
encapsulated
bundle
between
nodes,
reliably
and
and
or
it
can
be
encrypted
or
signed.
D
The
security
measures
available.
C
So
how
does
this
work?
Bibe
is
a
reliable
custody
convergence
layer
protocol
and
the
way
we
do
this
is
that
the
payload
of
the
encapsulating
bundle,
the
payload
of
that
of
that
bundle
is
three
things:
the
encapsulated
bundle,
but
that's
preceded
by
a
transmission
identifier
and
an
expected
time
of
acknowledgement.
That
is,
the
the
sender
passes
along
in
the
in
the
payload
of
the
encapsulated
bundle,
the
time
that
it
expects
to
get
an
acknowledgement
back
and
those
things
can
be
zeroed
out
if
custody
transfer
is
not
requested.
C
The
acknowledgment
of
the
encapsulating
bundle
is
aggregated
into
a
new
administrative
record
that
is
sent
in
a
responding
bundle.
The
expected
time
of
acknowledgment
is
used
as
a
control
mechanism
for
for
telling
the
receiver
when
to
stop
aggregating
and
go
ahead
and
send
the
aggregated
custody
signal.
C
The
responding
custody
signal
will
contain
a
custody
transfer
disposition
code
same
as
the
original
custody
transfer
mechanism
of
custody
accepted,
or
else
a
reason
for
refusal
and
and
and
there
will
be
in
each
acknowledgement,
bundle
a
custody
signal
bundle,
a
sequence
or
multiple
sequences
of
consecutive
transmission,
ids
of
the
received
bundle
so
that
any
number
of
of
bundles
can
be
acknowledged
in
a
single
acknowledgement.
C
The
acknowledgement
is
not
received
by
the
expected
time,
then
the
transmission
of
the
encapsulated
bundle
is
assumed
to
have
failed
and
encapsulated.
Bundled
can
then
be
queued
for
for
being
re-forwarded
the
same
as
we
would
do
with
other
reliable
convergence
layer
protocols.
Next
slide.
C
In
the
interest
of
time,
I
won't
go
through
all
these,
but
but
I
will
suggest
that
these
are
kind
of
interesting
ways
in
which
bundled
model
encapsulation
can
be
configured
and
used.
You
can
in
in
this
slide
here
we're
showing
it
doing
just
custodial
reliability.
C
C
Slide:
here's
a
cross-domain
security
which
is
bundle
and
bundle
encapsulation
being
used
to
to
sign
a
bundle
as
it
traverses
and
a
particularly
unsafe
segment
of
the
end-to-end
path.
Next
slide.
C
Now
I
think
the
next
slide
is
the
same
sort
of
thing,
but
here,
instead
of
being
signed,
it's
encrypted
during
its
traversal
over
this,
this
unsafe
bit
of
path,
defense
against
traffic
analysis.
Next
slide,
we
can
imagine
a
node
and
I'm
sorry
a
bundle
entering
a
portion
of
the
network,
that's
very
heavily
used
and
during
in
its
local
parts
of
the
network,
it's
it's
a
an
expedited
high
priority
bundle
once
it
gets
to
the
trunk
line.
C
C
The
same
thing
there's
a
notion
in
in
the
ion
implementation
of
something
called
critical
forwarding
where
there's
a
extend
class
service
switch.
That
says
this
is
a
really
critical
bundle.
Send
it
every
possible
way
you
can
send
it
and-
and
that
could
be
done
end
to
end
and
here
we're
showing
it
being
done
only
between
the
entry
and
exit
points
from
a
particularly
unstable
portion
of
the
network.
Next
slide.
C
Multicast,
oddly
enough,
you
could
do
a
transient
multicast,
you
could
have
an
end-to-end
bundle
that
is
not
really
multicast,
but
when
it
gets
to
a
particularly
unstable
part
of
the
network,
to
increase
the
chance
of
it
getting
out
and
reaching
the
destination.
C
Maybe
the
entry
to
that
that
portion
of
the
of
the
network
encapsulates
the
original
bundle
in
in
a
bundle
that
is
then
multicast
to
multiple
exit
points
from
that
portion
of
the
network
and
whichever
one
of
those
guys
actually
gets
the
bundle
and
can
forward
it
on
to
the
destination
node
in
the
stable
part
of
the
network
that
that
succeeds
or
there
may
be.
Maybe
there
are
multiple
copies
that
arrive,
but
it
increases
the
chance
of
successful
arrival
next
slide.
C
This
is
oddly
enough,
a
way
that
you
can
use
this
mechanism
to
do
source
path,
routing
by
encapsulating
in
increasingly
deep
layers
of.
C
Network
adjacency
next
slide.
C
Oh
and
yeah,
here's
you
can
do
you
know
certain
combinations
of
all
these
things.
You
could
do
certified
multicast
that
that
the
certification
and
the
multicast
terminates
when
you
leave
the
network
and
and
the
number
of
combinations
is,
I
think,
limited
only
by
the
imagination
next
slide.
C
So
what
I
would
see
here
is
I
would,
I
would
urge
us
to
add
bundle,
button
encapsulation
along
these
lines
to
the
chartered
program
report
for
the
working
group.
The
specification
is
actually
not
very
difficult.
Implementation
is
not
very
difficult.
C
I
think
we
can
get
a
lot
of
benefit
from
it
and
I
think
the
the
ability
to
reclaim
some
of
the
features
of
earlier
earlier
iterations
of
our
protocols
that
we
had
to
abandon
is
is
desirable
just
in
itself
getting
security
sources
and
destinations
and
custody
transfer
back
in
in
a
way
is
I,
I
think
in
itself
a
good
argument
for
adopting
bundled
encapsulation,
and
I
will
finish
right.
There.
A
Thanks
very
much
scott
spot
on
time,
I've
noted
that
you're
effectively
requesting
working
group
adoption
of
bundle
in
bundle.
I
think
we
will
roll
that
question
into
the
discussion
in
the
second
half
of
the
agenda,
because
I
know
you've
made
mention
of
bundle
and
muddlers
as
part
of
that.
I'll
still
make
a
note
anyway.
A
So
next
up
on
the
agenda,
I
believe
we
have
the
we
have
marius
feldman
who's
going
to
talk
about
his
bundle.
Protocol
version
7
tests
with
issa
opsat
marius.
Are
you
there?
Yes,
you
are
yes,
I'm
here
hi
can.
Can
you
present
your
own
slides
or
would
you
like
me
to
do
it.
E
Felix
will
do
it,
so
he
will
take.
The
second
part
of
the
presentation
and
cersei
will
share
the
slides.
A
E
I
can
already
start
to
talk
a
little
bit
about
the
next
minute,
so
actually
so
we
changed
the
title
slightly,
because
we
do
not
just
want
to
talk
about
that
one
test,
but
there's
a
preliminary
test
with
it,
because
while
we
hadn't,
we
did
not
had
any
any
flight
opportunity
in
the
meanwhile-
and
I
briefly
want
to
to
talk
about
that
test
as
well
and
then
about
the
either
offset
test
that
we
did
just
in
in
december
or
2020.
E
So
before
we
go
to
some
technical
things,
I
would
like
to
give
you
some
some
background
information
felix.
Maybe
you
start
with
the
next
slide
right,
so
it's
some
background.
Well
that
shows
how
how
long
we
already
desired
that
moment
to
test
the
ddn
protocols
in
the
low
earth
orbit.
E
Actually,
so
we
are
working
intensively
on
the
so-called
ring
road
concept
since
a
couple
of
years,
so
it
was
well
the
guy
that
that
was
just
presenting
scott
burleigh,
who
pointed
us
to
that
concept.
So
the
idea
is
that
you
leverage
low
earth
orbit
satellite
satellites
in
order
to
transfer
data,
for
example
from
from
sites
that
are
decoupled
from
the
internet.
E
To
the
internet
and
back
again,
so
it's
a
sort
of
approach
for
low-cost
communication
networks,
and
so,
while
scott
mentions
that
back
in,
I
think
it
was
march
or
february
2013
13
during
a
visit
of
mine,
it's
a
jpl
so
eight
years
ago,
and
the
interesting
thing
is
first
of
all.
Well
for
sure.
I
liked
the
idea,
because
it's
simple
and
well,
I
saw
an
opportunity
to
say
something
practically
and
on
the
other
hand
it
was
a
lucky
incident
of
history.
E
Let's
say
that
suddenly
two
flight
opportunities
popped
up,
one
of
them
was
from
the
technical
university
of
dresden,
where
cubesat
was
built
and
they
were
searching
for
payloads
and,
on
the
other
hand,
well,
there
was
a
either
observed
request
for
for
proposals
that
was
published
in
march
2013,
also
really
at
the
same
point
in
time
when
scott
mentioned
this
is
over
a
concept
in
a
discussion
with
me,
and
we
have
handed
in
at
that
point
in
time
a
proposal
to
practically
demonstrate
this
ring
road
concept
on
leveraging
the
these
are
upset.
E
E
The
first
issue
is
that
the
the
project
that
worked
on
the
cubesat
at
the
technical
university
of
dresden
required
a
really
simple
implementation
that
can
operate
on
the
arm,
cortex
m5
microcontroller,
and
that
leverages
three
others
as
an
operating
system,
which
was
at
least
to
the
best
of
our
knowledge
not
available
at
that
point
in
time
and
on
the
other
hand,
while
it
was
for
sure
unclear
if
this
either
offset
will
happen
one
day
and
if
our
proposal
is
accepted,
so
we
focus
in
the
first
place
on
the
geodristin
experiment
and
started
to
to
build
an
own
dtn
protocol
implementation
in
the
beginning
of
2014..
E
Unfortunately,
unfortunately,
it
was
finally
decided
that
that
experiment
will
not
make
it
to
the
to
dresden
cubesat,
as
I
want
to
have
had
have
very
simple
payloads.
Only
and
our
project
idea
was
maybe
a
little
bit
too
too
complex
from
them
for
them
and
they
saw
it
some
some
risk
in
it
for
their
overall
goals
so
thus,
well,
even
if
it
triggered
the
overall
development
of
micro
and
pcn.
E
Also
a
low
memory
profile,
dpi
protocol
implementation,
it
didn't
make
it
to
to
that
experiment
and,
on
the
other
hand,
well
either
was
somehow
active,
but
there
was
not
continuous
feedback
from
from
that
opportunity.
So
we
didn't
know
it
if
it
will
happen
and
that
part
of
the
history
will
be
relevant
in
a
second.
When
I
talk
about
the
first
field
tests
that
we
said,
we
did
so
well
time
moved
on
for
sure.
E
We
are
delayed
tolerance,
so
we
kept
on
the
track
and
pushed
forward
micro
pcn
and
as
it
has
grown
this
time,
we
decided
to
to
transform
it
to
an
a
real
open
source
project
that
is
hosted
in
in
gitlab
felix.
Maybe
you
you
can
go
on
and
well.
I
have
also
fully
redesigned
it
and
extended
its
its
applicability.
E
So,
first
of
all,
it
was
intended
to
to
just
run
on
really
low
profile
microcontrollers,
but
later
on,
we
added
also
platform
support
for
public
operating
systems
and
well
linux
and
have
developed
several
convergency
layer
adapters.
I
don't
want
to
go
into
the
detail
of
the
architecture
and
so
on,
but
one
thing
that
will
be
important
in
a
second
for
describing
the
experiment
as
well
is
that
we
needed
an
opportunity
for
sure
to
also
from
the
application
layer
interact
with
the
ddm
protocol
implementation
with
micro
pcn.
E
That
was
well
renamed
some
time
ago
to
micro
dtn,
and
for
that
we
we
have
developed
a
specific
protocol
which
we
named,
just
as
we
are
not
that
creative
on
our
naming
application
agent
protocol
aap
for
sure
for
short,
and
that
protocol
can
be
used
to
transfer
typical
commands
to
a
ddn
protocol.
Implementation
like
means
that
you
will
want
to
create
a
bundle
or
such
well.
E
You
want
to
hand
over
some
configuration
information,
so
we
defined
a
set
of
commands
for
well
typical
operations
within
this
dtn
protocol
implementation.
So,
apart
from
this,
as
I
said,
or
several
cla
implementations
have
been
created
like
mtcp
or
spp,
also
over
tcp,
for
example,
plus
also
the
first
bundled
protocol
on
version.
7
implementation
has
been
added
to
our
implementation,
already
quite
some
some
while
ago
and
yeah
with
this
well,
we
have
also
received
some
some
mentioning
in
the
in
the
itf
draft
document
felix.
E
E
So,
as
I've
already
mentioned,
there
were
initially
two
options
for
for
testing
everything,
but
well
it
it
took
really
some
time
to
to
to
flight
test
things
on
on
observe
so
in
the
meanwhile
to
not
get
bored
and
after
having
a
basic
version
of
micro,
dtn
on
slash
micropc
pcn
available,
and
we
decided
to
go
for
a
small
ether
project
to
do
some,
some
fuel
testing
and
that
project
is
named
code
sound.
E
E
So
in
this
case
well,
we
for
sure
also
had
the
idea
to
to
have
the
ring
road
approach
within
the
space
segment.
However,
while
we
can
also
easily
use
or
could
also
easily
use
existing
satellite
networks,
this
is
what
we
exactly
do.
I
did
felix
next
slide
so
in
this
test.
Well,
the
idea
was
then
to
transfer
typical
data
that
you
can
gather
easily
under
water,
like
temperature,
like
pressure
and
so
on,
and
so
on.
E
Via
a
homebrew
sensor
network
and
from
this
sensor
network
we
transferred
the
data
to
a
spoil
system
that
I've
just
mentioned,
handed
it
over
to
micro,
dtn
and
then
via
mtcp,
in
a
specific
relay
that
we
have
built
on
through
the
inverse
satellite
iot
network
to
a
remote
web
service
and
from
there
it
was
then
transferred
via
mpcp
again
to
micro,
dtn.
So
yeah
we
did
some
some
testing.
Maybe
you
can
show
some
some
pictures
on
the
next
slides.
E
I
always
like
to
show
such
pictures
here,
so
it's
really
getting
our
hands
dirty
or
maybe
also
the
next
one
as
well,
where
we
did.
The
first
bundle
protocol
version,
seven
testing
on
in
a
lake
nearby,
where
we,
when
pulled
that,
sets
that
overall
boy
system,
as
well
as
a
underwater
network,
so
it
was
a
sort
of
mobile
underwater
network
even
through
a
lake
and
transferred
data
continuously
to
a
monitoring
system
in
the
internet,
leveraging
the
bundle
protocol
version
seven.
E
So
that
was
our
answer
to
not
having
a
flight
opportunity
for
quite
some
years
that
we
at
least
were
able
to
play
a
little
bit
around
with
the
protocols
test.
Everything
and
plug
things
together
and
to
have
some
practical
experiences
next
slide.
Please
so!
Well,
then,
after
really
years,
finally,
the
offset
was
well
launched
and
became
reality.
E
Maybe
some
basic
information
about
that
that
satellite,
it's
a
three-year
cubesats,
it
was
launched
in
december
2019
and
then,
while
it
took
one
year
before,
experiments
were
allowed
and
our
experiment
was
the
first
one.
So
it
was
a
well
simple
ring
road
concept
that
was
explored.
Maybe
some
information
about
the
usage
of
the
the
upside,
so
in
the
end
we
we
could
start
a
payload
there
and
connect
to
a
local
port
or
tcp
port
and
transfer
data
via
sbp
to
this
tcp
port
and
well.
E
If
a
ground
station
is
inside,
then
the
data
will
be
handed
over
and
either
offered
the
so-called
either
smile
lab,
so
a
ground
station
in
dumstraps
germany,
in
order
to
to
fetch
the
data
via
some
some
reverse
ssa,
ssh
port
forwarding.
So
in
the
end,
well,
we
were
just
able
to
pass
spp
packets
from
us
observed
to
the
ground
segment.
Next
slide,
please,
based
on
that
setup,
we
have
developed
a
small
scenario,
so
it
demonstrates
a
ring
road
approach.
E
Side
here
is
a
code
spot
not
having
an
internet
connection
and
from
there
we
were
wanted
to
be
able
to
to
query
our
websites.
So
the
idea
is
that
there's
a
remote
user
that
wants
to
assess
leveraging
http
a
website
and
an
http
request
is
then
transferred
by
a
gateway
to
to
a
micro
dtn
that
encapsulates
the
http
request
in
a
bundle
and
hence
over
the
bundle
then
to
the
space
segment.
E
This
hanging
over
is
done
leveraging
a
specific
component
that
we
call
dispatcher,
or
it's
also
offered
as
open
source.
If
somebody
is
interested,
it's
a
simple
component
that
whether
it's
possible
to
simulate
different
ground
stations,
as
we
only
had
one
well,
we
needed
to
introduce
virtual
ones.
So
the
dispatcher
then
connects
at
a
specific
point
in
time
or
in
a
specific
time
span
with
one
of
the
micro
dtn
instances
of
simulating
different
ground
stations
and
leveraging
spp.
E
Well,
as
I've
just
mentioned,
we
handed
over
bundle
protocol
version,
seven
instances
to
a
micro
gta,
an
instance
operating
on
the
upside
and
then
back
to
the
ground,
where
well
again,
some
gateway
carried
for
transferring
the
http
request
to
to
then
a
real
request
to
a
web
server
and
from
there
well
the
pass
back
again
or
was
sent
and
selected
by
the
offset
back
to
the
the
requesting
user.
One
information
about
that
that
figure.
E
So
you
see
an
iron
instance
and
some
information
about
the
dsn
on
the
on
the
bottom.
So
the
reason
for
that
is
that
initially
we
planned
also
in
the
discussion
with
scott
to
have
an
extended
version
where
we
wanted
to
simulate
a
sort
of
well
communication
from
a
ring.
E
Road
realized
on
planet
mars
to
earth
where
well,
dsn
would
have
played
a
role,
unfortunately,
so
far,
there's
no,
no,
no,
no
feedback
on
on
on
the
requests,
but
we
can
discuss
this
with
scott
again,
but
that
would
be
an
option
for
extending
the
experiment
later
on.
Yeah
felix
will
now
use
the
last
two
minutes
in
order
to
get
some
details
on
on
that
experiment.
F
F
So,
first
of
all,
of
course,
what
we
had
to
do
here
is
to
configure
all
these
instances
all
these
services
which
we're
running,
and
we
can
take
a
look
at
how
we
configured,
for
example,
the
micro
dtn
instance
on
the
offset.
Let's
shortly
have
a
look
at
the
code.
F
So
this
is
just
a
part
of
our
script,
which
con
configured
and
ran
the
experiment,
and
what
we
can
see
here
is
that
we
leverage
a
small
python
tool
aapsend.pi,
which
sends
an
aap
packet
to
a
given
micro,
dtn
instance
specified
by
a
tcp
endpoint,
and
this
aap
packet
contains
a
destination
eid
as
well
as
a
bundle
payload,
and
the
micro
dtn
instance
will
then
take
this
and
make
this
the
payload
of
an
actual
bp
version,
7
bundle
and
send
it
to
the
specified
endpoint
id,
and
what
you
can
see
here
is
is
basically
the
payload
of
one
of
our
configuration
messages.
F
So
this
is
a
quite
a
basic
straightforward.
Configuration
format
that
consists
of
first
a
command.
That
is
this
number
one
at
the
start,
which
just
says
add
this
contact
to
the
local
contact
plan.
And
then
we
have
the
endpoint
identifier
of
our
ground
station
of
our
hotspot
ground
station.
First
of
all-
and
this
is
addressed-
or
this
is
reached
via
a
tcp
spp
convergence
layer.
F
So
space
packet
protocol
encapsulated
into
a
tcp
connection,
and
then
we
have
the
contacts
which
can
be
added
here,
where
we
simply
specify
one
contact
by
two
variables
that
contain
the
dtn
timestamps
of
the
contact
interval,
as
well
as
a
bitrate
for
calculating
contact
volume,
and
this
is
also
done,
of
course,
for
the
cold
spot
contact
and
when
this
is
configured
and
as
well.
Of
course,
the
dispatcher
service
is
configured
with
the
same
parameters.
F
Then
we
can
send
a
request
to
our
hd
http
gateway
that
we
can
see
here.
And
for
this
we
leverage
curl,
which
gets
set
in
http
proxy
and,
of
course
also
and
quite
an
increase
in
the
in
the
maximum
allowed
delay
for
the
request,
so
that
we
don't
run
into
a
timeout
here
and
then
we
add
simply
the
the
url
which
shall
be
requested
and
the
http
contents
are
then
sent
to
the
communication
gateway
which
will
forward
them
via
aap.
The
bundle
will
be
generated.
F
This
goes
to
the
offset
the
offset
routes,
the
bundle
back
to
via
the
dispatcher,
to
the
micro
dtn
instance
two,
and
then
it
will
reach
the
web
server
via
the
communication
gateway.
And
when
we
take
a
look
at
the
log
files
which
were
produced
during
the
test,
we
can
first
of
all
take
a
look
at
this
instance.
Micro
dtn,
one
where
we
see
that
it
first
of
all
receives
a
bundle
payload
via
aap.
F
It
makes
a
bundle
out
of
it
it
routes
the
bundle
so
and
shows
that
okay,
the
bundle
has
been
scheduled
and
then
a
connection
is
created
to
the
dispatcher
to
to
the
esa
ground
station
wireless
dispatcher
and
the
bundles.
The
bundle
is
scheduled
for
this
contact
and
sent
via
this
connection,
and
then
we
can
take
a
look
also
at
the
micro
dtn
instance
three,
when
the
bundle
comes
back
from
the
satellite.
F
We
see
that
here
again
a
contact
starts
with
a
dispatcher
service,
and
then
we
get
a
bundle
for
a
local
endpoint
which
is
then
delivered
again
via
aap
to
the
http
proxy,
which
send
it
the
request
to
the
web
server.
The
web
server
will
answer,
and
then
we
even
get
the
response
from
which
another
bundle
is
created,
and
this
is
sent
back
to
our
satellite
in
this
case.
Unfortunately,
during
this
experiment,
we
could
not
verify
the
whole
return
path,
as
the
contact
wasn't
simply
over.
F
It
was
a
quite
short
contact,
but
we
aim
to
test
this
during
our
next
opportunity,
which
will
hopefully
occur
soon.
So
all
in
all
from
on
this
experiment,
we
can
summarize
that
the
bundle
protocol
version
seven
as
well
as
our
implementation,
worked
without
any
issues.
However,
what
we
identified
as
an
issue
is
that
routing
and
forwarding
simply
based
on
time
stems,
is
quite
error
prone.
F
So
in
this
experiment,
we
had
no
mechanism
to
to
to
notice
that
the
actual
link
to
the
satellite
is
up
and
and
so
that
our
bundle
protocol
implementation
can
react
to
this.
So
the
the
forwarding
of
the
bundles
purely
occurred
due
to
the
timestamps
and,
of
course,
for
this,
you
need
a
very
accurate
and
precise
clock
synchronization,
which
was
a
bit
of
an
issue
for
us.
Also.
F
What
we
want
to
highlight
is
that
a
standardized
mechanisms
for
configuration
and
management
would
be
very
good.
So,
on
our
side,
we
have
this
very
simple
configuration
format
which
which
I
have
shown
in
the
future.
Of
course,
we
also
want
to
explore
amp,
but
I
I
think
it's
quite
important
to
have
something
standardized
here,
to
interact
also
with
heterogeneous
implementations
of
the
bundled
protocol.
F
And,
last
but
not
least,
what
would
be
also
massively
useful
for
us
would
be
some
basic
tools
which
are
able
to
check
on
the
bundle
layer
on
the
availability
of
other
abundant
protocol
agents,
as
well
as
their
operational
states.
So
simply
like,
like
something
like
a
a
ping
utility
which
can
be
used
to
simply
check
whether
the
instance
running
on
the
offset
is
alive
and
well
so
at
the
end,
we
would
like
to
motivate
everyone
to
participate
in
more
practical
tests
and
experiments
and
collaborate
on
to
drive
really
these
things
forward.
A
Thank
you
very
much
both
of
you
that
was
really
interesting.
It's
it's.
Your
conclusions
were
very
interesting
and
I
think
we'll
feed
into
the
the
discussion
we'll
have
after
the
presentations,
particularly
your
comment
about
time.
Based
routing,
that's
that's
interesting.
Do
we
have
any
questions,
nobody
in
the
queue
and
I'm
watching
our
time?
So
if
not,
thank
you
both
very
much
and
next
up
brian.
A
G
A
A
A
G
I
should
be
coming
through
now,
yes,
so
the
first
thing
I
want
to
discuss
are
potential
updates
to
udpcl,
and
these
are
all
kind
of
at
this
point-
speculation
and
open
for
question,
but
the
the
main
idea
is
that
udp
provides
some
unique
behaviors
that
other
transports
are
not
going
to
have
and
the
the
main
goal
of
all
of
this
discussion
is
in
a
sense
backwards.
Compatibility
for
the
very
simple
use
case
of
one
bundle
turns
into
one
datagram.
G
G
The
next
area
is
about
unspecified
weak
points
of
the
current
youtube
pcl,
which
is
very
simple
and
straightforward,
but
it
leads
some
things
to
imagination
and
to
implementation.
G
D
G
D
G
Big
1500
to
1200
bytes
is,
is
kind
of
a
typical
mtu,
so
in
the
individual
draft
that
I
posted
was
a
very,
very
simple
unacknowledged,
still
way
of
doing
convergence,
layer,
fragmentation
and
the
other
thing
that's
not
mentioned
in
the
original
udpcl
was
how
unicast
versus
multicast
are
to
be
used,
and
bp
agent
level
interface
details
like
should
an
agent
or
must
an
agent
choose
what
network
interface
a
a
bundle,
be
transported
on
things
like
that,
and
then
the
the
next
topic
is
about
extensibility
and
interoperable
security
in
the
same
way
as
the
updates
to
tcpcl
involved
a
lot
of
discussions
with
ietf
best
practices
and
around
security
and
tls.
G
It
seems
like
this
is
a
reasonable
thing
to
at
least
specify
in
the
same
vein
as
tcpcl,
where
it
is
here's
how
to
do
it
when
you're
configured
to
do
it,
but
nobody's
saying
you
have
to
do
it
and
and
again
the
the
goal.
Is
this
send
and
forget
type
of
strategy
with
this
convergence
layer?
Is
that
it's
very
simple?
It's
straightforward:
there's
no
convergence,
layer,
acknowledgements,
it's
the
the
bundles
go
out
and
something
else
worries
about
acknowledgement
and
also
doing
congestion
control
things
like
that.
G
The
last
thing
I
ran
into
when
I
was
looking
at
some
other
similar
protocols
was
bundle
packing
within
datagrams
for
efficiency
purposes.
Right
now,
the
the
udpcl
very
explicitly
says
one
bundle
one
datagram,
but
if
you
have
very
small
bundles
does
it
make
sense
to
allow
packing
to
fill
up
datagram
sizes
and
then
the
last
thing
that
I
had
run
into
and
hadn't
written
anything
up
about
this
yet
is
in
circumstances
where
an
agent
is
behind
a
nat.
G
I
can't
open
up
a
port
arbitrarily,
but
what
I
can
do
is
I
can
establish
a
udp
conversation,
that's
going
to
get
through
a
firewall
and
through
a
nat
and
that
I
can
potentially
advertise
here.
I
am:
are
there
any
bundles
for
me
in
the
same
ways
that
the
tcpcl
allows
bi-directional
communication
allows
but
doesn't
mandate.
G
G
It
covers
a
lot
of
these
topics:
unicast
multicast,
fragmented
transfer,
dtls
use
and
also
I
I
open
up
a
bunch
of
different
issues
on
these
specific
topics
here
about
bundle
packing
about
fragmentation
above
and
below
mtu
discovery
is
a
thing
that
you
run
into
when
you
start
dealing
with
a
packetization
at
a
datagram
layer
and
then
advertise
return
path,
and
the
this
last
one
is
about
conversations
that,
when
you're,
when
you're,
trying
to
troubleshoot
or
trying
to
analyze
things
right
now,
the
the
udpcl
doesn't
say
anything
about.
G
If
I'm
communicating
with
a
peer
node,
should
I
always
use
my
same
source
port
number
when
I'm
communicating
with
them,
it's
a
it's
an
ephemera
report,
but
should
I
use
it
consistently
or
does
it
not
matter
so
the
those
are
all
my
topics
for
the
udpcl.
Let
me
check
my
time
quickly,
a
little
bit
of
time.
So
I
can.
I
can
go
on
to
questions
or
any
discussion
topics.
H
Yes,
I
one
question:
you
brought
up,
not
the
firewalls
here,
or
I
mean
I
assume
this
is
you
want
to
maintain
that
this
is
simple
in
in
regards
to
what
you're
trying
to
achieve?
But
maybe
you
actually
want
to
discuss
three
usage
of
stand
and
turn
here
for
to
achieve
those
controversial
capabilities.
G
Yeah
I
had
looked
into
those
as
topics
and
things
like
that
rely
on
some
specified
behavior,
such
as
using
consistent
port
numbers
or
accepting
return
path.
G
Behavior
that,
right
now
the
the
udpcl
doesn't
doesn't
mention
all
about
source
port
numbers
or
possible
return
path.
So
using
things
like
stun
and
those
kind
of
related
strategies
would
rely
on
some
more
well
specified.
Behavior
such
as
discussed
in
this.
H
Yeah
I
mean
in
general,
if
you're
gonna
have
bi-directional
communication
through
and
that
the
firewall
you're
gonna
have
to
have
some
restrictions
to
how
you
transmit.
So
you
you're
outgoing
traffic
through
the
nuts,
has
a
return
path.
So,
but
maybe
it's
it,
I
don't
know.
If
really
you
need
to
how
complicated
you
want
to
do
this,
and
I'm
probably
maybe
keeping
that
on
simple
side
for
those
particular
use
case,
which
is
more
like
okay,
it's
multicast.
Is
it
one
way.
E
G
In
the
current,
the
current
draft
doesn't
mention
anything
at
all
about
about
return
path.
So
this
specific
item
is
really
just
asking:
is
there
enough
value
in
operating
a
node
behind
a
nat
or
behind
a
firewall?
Is
there
even
enough
interest
that
it's
worth
investigating
or
just
leave?
It
unspecified
as
currently.
A
So
I
rick
with
my
personal
hat
on
I'm
with
magnus,
I
think,
taking
the
the
steer
from
stun
and
turn
and
though
those
sort
of
net
punching
technologies
is,
is
worth
doing.
Bidirectional
capability,
I
can
see
being
useful,
particularly
in
that
environment,
and
I
think
dtn
has
uses
on
domestic
terrestrial
internets
for
for
messaging
services
and
so
on
and
in
those
cases
you're
going
to
get
firewalls
and
nets
and
all
sorts
of
horrible
domestic
broadband
kind
of
things
in
the
way,
and
that's.
H
So
I
had
no
particular
interest
in
or
need
for.
This
provides,
yes
that
I
mean
I
have
experience
with
the
whole,
not
five
volt
reversal
aspect.
So
that's
what
I
was
asking
so
it's,
but
I
would
recommend
keeping
on
a
simple
side
and
then
just
go
for
what
you
really
need.
If
it's.
If,
if
you
need
bi-directional,
yes,
then
you
probably
need
to
specify
something
but
trying
to
get
this
water
tight.
A
With
my
chair
hat
on,
I
think
if
this
was
to
be
adopted
as
a
working
group
draft,
that
is
the
sort
of
topics
that
the
working
group
would
sort
out
and
so
on.
Personally,
I
think
this
sounds
like
interesting
work,
but
in
light
of
time,
because
we
want
to
get
on
to
the
next
steps
discussion
in
general,
do
you
want
to
cover
the
cozy
bit?
Why
do
you
have
the
the
mic?
A
I
G
And
this
is
covering
a
lot
of
the
same
ground
as
as
the
last
cozy
beep
stick
presentation.
The
goals
are
all
the
same
as
what
was
discussed
before
is
keeping
it
as
simple
as
possible.
This
is
a
glue
between
two
existing
protocols
that
are
both
well-defined
enough
that
they
both
have
some
implementation
and
and
some
logic
about
how
they're
supposed
to
operate,
and
it
proposes
a
a
very
simple
set
of
I'll
show
in
the
next
slide:
interoperability.
Algorithms.
G
That
follows
very
similarly
from
the
the
bpsec
default
algorithms
for
symmetric
keys,
but
it
expands
the
scope
to
asymmetric
keys
and
that's
really
the
the
big
goal
for
this
draft
is
to
allow
existing
asymmetric.
G
Keyed
algorithm
behavior
in
as
little
effort
as
possible
in
the
bpsec
environment
and
cosy,
is
a
very
good
fit
because
code
c
itself
is
designed
for
that
kind
of
store
and
forward
transfers.
There's
no
bi-directionality
to
it
at
all,
and
there
is
also
some
ongoing
work
in
the
cozy
working
group
about
pkix
and
x509
transfers
and
details
to
be
worked
out
on
the
cosy
side.
G
But
all
the
main
points.
All
the
main
requirements
exist
already,
at
least
as
far
as
drafts,
to
point
that
and
explain
how
things
are
all
to
be
done.
G
And
there's
there's
also
a
demo
implementation
that
actually
is
doing
bi-directional:
bp,
sec
transfers
with
integrity
checks,
and
it
it's
working
at
least
all
pieces
fit
together.
J
A
A
seems
like
an
obvious
next
step.
Okay,
any
questions
on
that
from.
A
Anyone
I
don't
hear
any
so.
Thank
you
very
much
brian,
thank
you
for
keeping
it
nice
and
short
as
well.
So
next
up
we
have
alberto
montia
from
ipnzig
who
wants
to
talk
about
interplanetary,
internet
interoperability
and
management
considerations.
A
K
Just
give
me
one
second,
I'm
having
a
it
seems
I'm
having
a
share
issue
here
with.
J
Their
preferences
I've
got
a
copy
of
your
slides.
If
you,
if
you
decide
to
give
up
okay,
let
me
let
me
try
and.
L
Oops
yeah,
I
might
need
your
help
because
it's
not
letting
me
to
do
it.
Okay,
let
me
try
share
screen.
K
Yep,
I
can
see
it.
Thank
you
no
trouble
and
good
morning
good
afternoon,
everyone.
My
name
is,
although
it
says
alberto,
bravo
and
the
titan,
I'm
a
board
member
of
ipnc,
the
interplanetary
networking,
especially
especially
interest
group
within
the
internet
society,
and
I'm
also
a
member
of
one
of
it
working
group.
The
pilot
project
working
group
which
I'm
representing
today
and
also
I'm
a
board
member
and
ceo
of
spartan
corporation.
K
My
goal
is
to
provide
you
our
perspective,
share
a
bit
about
what
we
are
doing
at
ipmc
and
draw
some
conclusions
about
it
as
well.
Next
slide.
K
So
the
mission
of
the
ipn
city
is
no
other
than
to
help
realizing
a
functional
and
scalable
system
of
interplanetary
data
communications,
and
within
that
we
have
an
organization
which
tackles
a
strategy
tackles
experimentation,
which
is
the
pilot
project
group,
also
technical
documentation,
because
one
of
our
main
goals
is
to
advocate
and
promote
the
use
and
the
technologies.
K
So
looking
at
any
possibility
for
us
to
expand
adoption
of
these
technologies.
So,
within
the
pilot
project
working
loop,
we
basically
engage
in
research
and
prototyping
opportunities
to
validate
and
extend
the
use
of
dtn
a
couple
of
things.
One
is
we
look
at
the
core
of
vtn
in
the
sense
of
scale,
interpretability
and
management
of
vtn
protocols,
and
second,
we
also
experiment
with
use
cases
and
applications
primarily
to
demonstrate
the
applicability
of
the
protocol
and
also
promote
its
use
to
space
which
is
well
known
and
also
to
air
applications.
K
I'm
going
to
be
talking
today
about
some
of
the
projects
we're
building.
Primarily,
our
main
goal
is
to
build
a
dtn
test
bed
and
then
we
currently
have
active
pursuit
participation
from
many
institutions
and
corporations.
So
we
are
trying
to.
We
have
very
ambitious
goals,
but
going
step
by
step
which
I'm
gonna
talk
about
in
a
couple
of
minutes,
and
one
thing
is,
you
know
we
would
like
to
share
priority
our
progress
and
very
important
our
learnings
with
this
community,
and
this
is
our
first
update
next
slide.
K
So,
let's
talk
about
the
active
projects,
the
first
and
main
one
is
the
dtn
test
that
we
basically
are
creating
a
network
of
networks.
Now
we
have
different
different
institutions
and
corporations
that
are
participating
each
of
them
with
their
own
networks,
and
the
idea
is
that
we
create
a
platform
in
which
a
platform
that
is
open
to
the
general
public
to
come
in,
learn
and
also
run
certain
experiments
very
specific
to
btn.
So
things
that
are
keeping
us
busy
is
looking
at
how
we
scale
so
connecting
not
only
tens
of
nodes.
K
But
our
goal
is
to
get
to
the
hundreds,
if
not
thousands,
of
nodes
as
well
and
look
at
interoperability
in
general
and
then
look
at
new
features
so
use
the
test
bed
also
as
a
way
to
test
some
of
the
new
features
that
are
coming
or
some
of
the
proposals
that
are
coming
from
the
different
organizations
and,
in
addition
to
looking
a
need
for
at
the
network
level,
we're
also
looking
at
the
different
use
cases
as
you're
going
to
see
in
a
second.
K
K
So
when
we
look
at
the
and
then
member
projects,
starting
with
network
management
to
basically
manage
btn
and
very
specifically
at
this
point,
ion
instances
that
could
be
in
a
space
or
on
earth
looking
at
the
different
applications,
the
the
one,
a
prayer
that
is
ongoing
is
the
use
of
dtn
to
extend
crisis
information
management
systems
with
the
use
of
rovers
and
the
use
of
drones
that
are
connected
via
dtn.
And
this
is
an
earth
use
case.
K
We
also
are
now
in
or
have
incorporated,
let's
say
incorporated
one
of
our
members
and
I'm
gonna
talk
about
that
in
a
second
have
implemented
a
dtn
system
for
a
reindeer
husbandry
and
that's
in
the
nordics
in
the
arctic
circle
in
the
I
think
the
area
belongs
to
sweden,
and
this
is
a
fully
operational
system
as
well
things
we
have
tried
out
unified
medical
records
for
space
exploration,
there's
a
prototype,
a
build
that
basically
takes
information
from
the
emr
database
using
sql
and
basically
have
a
gateway
that,
where
you
know
those
records
can
be
sent
to
a
space
as
needed
and
the
gateway.
K
Also
performs
you
know,
curate
the
data,
so
only
the
critical
data
is
sent
back
to
you
know
the
remote
area
and
very
recently
we
with
the
help
of
google.
We
have
been
experimenting
with
connecting
some
machine
learning
and
or
computer
vision.
I
would
say:
com,
computer
vision,
algorithms,
to
perform
in
image
recognition
over
dtn
and
the
goal
is
to
basically
you
know
some
of
these
applications.
The
goal
is
to
understand
and
the
particularities
of
you
know
how
the
application
would
work
in.
K
You
know
over
long
distances
and
things
of
that
nature
next
slide.
K
Then
let
me
double
click.
On
a
couple
of
things.
I
mentioned
the
dtn
testbed
late.
Last
year
november
27th
we
were
able
to
make
the
first
connection
having
a
few
instances
running,
ion
instances
running
on
the
google
cloud
and
that's
basically
managed
by
google,
including
some
sensors
connected
via
all
using
the
bundled
protocol
versus
seven
connecting
to
the
health
information
network
deployment
on
aws
that
have
the
medical
gateway
record
as
well.
K
So
this
basic
was
a
you
know,
hello,
world
demonstration,
just
a
basic
using
basic
bp7
functionality,
and
that
was
the
start
of
it.
As
of
february,
we
have
now
four
organizations
on
board
basically
exchanging
messages.
K
Everything
is
ion-based
right
now,
but
we
basically
welcome
other
implementations
of
the
bundled
protocol
so
that
we
can
also
do
interpretability
testing
we
are
exercising
with
you
know,
exchanging
messaging
files
recently,
starting
with
multicast,
and
we
have
put
image
free,
an
image
recognition
prototype
over
dtn,
where
a
node
can
send
an
image
and
then
we'll
get
back.
Basically
what
elements
or
objects
have
been
identified.
K
So
one
of
the
one
of
the
things
is
we're
looking
at
the
understanding
of
the
extent
of
what
use
cases
could
be
enabled,
like
you
know,
identification
of
identification
of
elements
within
a
picture
or
a
video.
So
one
thing
that
we
learned
straight
away
is
that
management
is
critical.
You
know,
contacts
and
context.
Plans
are
hard
to
manage
and
prone
to
error
every
single
test
session
we
have
had
there.
There
was
always
you
know,
one
eid
that
was
wrong
or
one
ip.
K
That
was
wrong,
so
you
know
at
four
scale.
The
first
thing
is,
you
know,
having
consistent
management
across
the
board,
not
only
within
the
networks
but
also
between
the
networks
is
is
critical
and
the
other
is
that
separating
routing
from
management.
Today
is
an
interesting
challenge
and
both
from
topology
and
as
well
as
you
know,
the
exchange
of
contact
information
as
well.
So
you
know
we're
working
on
trying
to
understand
how
much
governance
and
automation
we
need
to
continue
this
scale
next
step
next
slide.
Sorry.
K
The
next
point
is
you
know,
as
we
discovered
those
challenges,
we
also
continue
the
experimentation
with
network
management
and
where
we
have
a
very,
very
early
draft
of
a
contact
plan,
generator
that
the
whole
organization
is
using,
but
we
also
are
experimenting
with
and
as
a
way
to
basically
transfer
those
contacts,
those
contacts
automatically
to
the
different
agents
on
the
different
nodes,
and
that's
something
that
is
keeping
us
busy
right
now,
so
that
you
know
there
is
just
a
single
place
where
all
the
organizations
can
go,
manage
their
networks
and
also
manage
the
test
bed,
which
is
the
interconnection
of
the
networks
in
a
dynamic
fashion.
K
And
this
is
the
example
of
the
unified
medical
records,
very
straightforward,
every
corporation
or
institution
on
earth
it
relies,
or
every
person
rely
on
their
medical
records
on
a
hosted
on
an
electronic
medical
record
system,
emr
or
ehr.
Depending
on
where
you
live.
There
is
a
bunch
of
data,
typically
using
relational
databases.
K
K
K
Slide
last
but
not
least,
on
the
ones
we
want
to
highlight.
This
is
a
project,
as
I
said
before,
this
is
a
project
that
it's
fully
in
production.
K
It
was
contracted
by
and
is
still
run
by,
the
dalvadis
economic
association
back
there
in
sweden,
with
the
help
of
the
lulia
university
of
technology,
and
it
incorporates
the
full
stack
from
a
series
of
lower
radio
stations,
all
the
way
to
the
sensors
and
the
the
dtn
sensor
and
and
stack
plus
sensors,
on
the
renders
all
the
way
to
an
app
where
the
hertz
can
be
tracked
and
followed,
and
this
doesn't
use
ion.
K
This
use
a
kind
of
a
different
version
of
a
proprietary
version
of
a
dtn.
It's
not
it
doesn't
rely
on
the
bundled
protocol
and
part
of
the
discussions
is
understanding
how
what
it
would
take
to
get
this
to
become.
You
know
a
standard
implementation
using
standard
protocols
like
bp.
K
And
one
thing
you
know
I
want
to
highlight
is:
if
you
think
about
the
goal
of
ipnc,
which
is
promoting
the
an
extended
use
of
vtn
protocols
to
have
a
reliable
and
scalable
interplanetary
internet,
we
are
committed
to
standard
so
right
now.
Every
test
that
we're
doing
is
incorporating
the
bundle
protocol
version.
Seven.
K
We,
as
I
said
before,
we
are
starting
to
experiment
with
an
amp
as
a
way
to
have
a
management
framework
for
all
the
instances,
and
you
know
as
we
go
forward,
we
you
know
continue
identifying
areas
for
to
for
further
exploration
and
enhancement
such
as
multi-region
we're
going
to
talk
about
ion
charms,
multi-agency,
routing
and
management
is
critical
for
scale.
Network
management
is
also
critical
for
scale
and
also
better
supports
for
mobile
use
cases
on
the
discovery
and
auto
configuration
front
as
well.
K
And
last
this
is
the
summary
so
we're
building
the
dtn
test
bed
with
my
participation
from
multiple
institutions.
We
are
learning
a
lot.
You
know
current
learnings
are
very.
You
know
telling
us
that
there
is
a
still
a
big
interdependency
between
dtn
and
the
management,
and
this
requires
a
time
alignment
to
jointly
evolve
both
protocols
and
frameworks.
K
There
is
an
opportunity
to
enhance
the
protocol
stack
by
you,
know,
management
and
routing
options
to
enhance
multi-network
and
multi-agency
connectivity
and
basically
taking
scale
into
consideration,
and
we
have
this
for
the
long
run,
so
we're
committed
to
promote
experiment
with
and
augment
the
standard
as
needed,
and
last
but
not
least,
you
know,
we
would
like
to
continue
reporting
the
updates
to
this
working
group
as
needed.
Thank
you.
A
Thank
you,
alberto.
That
was
very
interesting
and
yes,
of
course,
you
would
be
welcome
to
continue
reporting
updates
to
this
working
group.
I
think
multi-agency
test
beds
being
built
and
really
testing
at
scale
gives
us
very
valuable
feedback
as
we
get
into
standardization,
and
I
think
it
will
be
input
into
our
next
step.
Conversation
today
and
we'll
also
guide
what
we
think
considering
you
as
effectively
operators,
it
will
guide
what
we
as
a
working
group,
look
to
standardize
for
interoperability
at
that
sort
of
scale.
A
So
thank
you
very
much.
What
I
will
do
now
is
hand
over
to
ed
who
wants
to
introduce
the
next
steps
ed.
Would
you
like
me
to
share
slides,
or
do
you
want
to
give
it
a
try.
A
I
will
click
the
button
as
I'm
becoming
accomplished
at
this
now,
allegedly
and
attempt
to
click
the
right
tab
working
group
next
step.
So
these
are
my
slides
I
must
say,
which
is
why
they
are
hideously
ugly,
but
only
go
ahead.
B
No
worries,
so
what
we
did
in
preparation
for
this
meeting
was
to
go
back
through
the
set
of
new
agenda
topics
that
had
come
up
through
discussion
over
the
past
roughly
year
and
a
half
or
maybe
more
this
past
year
has
been
a
strange,
a
strange
time
for
sure
at
the
ietf's,
105
and
106.
In
anticipation
for
finishing
our
initial
set
of
working
group
charters,
we
had
put
out
some
calls
to
the
working
group
associated
with
what
do
we
think
are
candidates
for
next
steps.
B
B
There
was
a
discussion
of
whether
additional
extension
blocks
were
near-term
needs,
neighbor,
discovery
and
and
right
behind
that
naming
and
addressing
their
the
network
management
work
and
then
how
many
other
additional
security
contexts
and
convergence
layers
again
were
needed
in
the
short
term
next
slide
in
and
then
looking
through
this.
The
the
the
comment
both
from
us
and
and
from
from
the
from
magnus
at
the
time
was
that's
an
awful
lot.
It's
very
good
work.
B
But
how
do
we
prioritize
this
in
terms
of
again
near-term
over
the
next
few
years
and
then
that
which
follows
and
and
we
started
to
whittle
it
down
and
say
there-
there
are
things
that
are
already
actively
being
pursued,
there's
energy
behind
it
and
there's
a
lot
of
work
there
and
we
shouldn't
let
that
go
so
to
that
extent
of
the
things
from
the
prior
list,
the
ones
that
seem
to
have
a
lot
of
activity
behind
them
right
now
are
bundle
and
model
encapsulation,
the
udp
convergence
layer,
some
prior
work
that
had
been
done
on
key
administration,
the
amp
work
and
then
the
cosy
security
context.
B
So
in
all
of
this
and
and
what
we
had
devoted.
The
second
portion
of
this
meeting
for
was
to
walk
through
this
list.
Ask
to
the
working
group.
Are
there
significant
things
that
are
missing,
but
then
also
to
to
really
come
to
understand?
What
is
the
prioritization
of
this
to
inform
the
next
charter
so
to
try
and
do
that
in
an
organized
way
we
propose?
Is
we
go
through
these
topics
topic
by
topic
and
we
have
some
comments
associated
with
them.
B
We
ask
people
to
comment
on
those
topics
and
also
to
suggest
new
topics,
and
then,
when
this
conversation
is
done,
then
we
will
take
the
compiled
list
out
to
the
mailing
list
and
and
finish
it
there
where
we
would
then
have
the
entirety
of
the
mailing
list
and
not
just
the
folks
who
were
able
to
attend
today
and
then,
of
course,
the
hope
is
that
the
you
know,
we
will
suggest
that
a
final
decision
on
the
chart
will
be
confirmed
at
1
11.,
unless
we
think
that
we
need
more
time
based
on
the
mailing
list
conversations.
B
B
The
the
topic
breakdown,
something
that
that
rick
and
I
propose
as
a
way
of
helping
to
prioritize
this
work
is
again
we
mentioned
before.
There
are
some
things
for
which
there
is
already
a
lot
of
active
involvement,
and
we
certainly
don't
want
to
to
lose.
B
You
know
that
that
energy
and
work-
that's
already
progressing
so
to
help
us
prioritize
and
not
pick
too
much,
but
also
not
to
not
pick
too
little
is
to
come
back
and
try
and
look
at
things
in
terms
of
existing
work
and
extensions
to
existing
work
and
things
that
are
just
brand
new,
and
the
idea
is
that
we
could
take
on
a
larger
amount
of
existing
work
and
extensions
to
existing
work,
because
these
things
are
closer
to
being
finished
and
farther
along
in
being
understood
and
then
things
that
are
brand
new
work,
where
we
will
spend
significant
time
scoping
understanding.
B
B
That's,
that's
obviously
a
big
part
of
things,
but
if
we
were
to
look
back
realistically
and
say
where
is
the
likely
complexity,
the
likely
complexity
is
and
and
concern
would
be,
that
we
would
take
one
too
many
brand
new
things
and
there
are
some
new
topics
vital
to
get
right
and
at
the
end
here,
we've
mentioned
it
again.
Naming
and
addressing
is
probably
a
big
one.
B
So
then,
if
we
go
to
the
next
slide
and
say
these
are
the
things
that
we
have
decided,
you
know
are
extensions
to
existing
work
or
we
propose
that
they
are
the
extensions
to
existing
work.
Again.
Bundle
and
bundle
encapsulation
is
under
active
development
and
and
exists.
B
The
manifest
block
is
part
of
open
discussion,
but
it
has
been
discussed
prior.
The
udp
convergence
layer
is
also
being
discussed
and
also
a
male
convergence
layer
which
an
http
convergence
layer
is
something
that's
come
up
several
times.
Convergence
layers
are
extensions.
We
have
put
one
convergence
layer
out.
We
have
a
sense
of
what
convergence
layers
need
to
do.
Bundle
and
bundle.
Encapsulation
is
a
a
convergence
layer,
and
so
these
are
all
things
that
are
repetitions
on
a
theme.
B
We
already
have
a
default
security
context
that
has
gone
out
if
we
add
another
security
context
that
that
certainly
helps
explain
the
concept
of
security
context
and
there's
a
lot
of
energy
there
and
then,
of
course,
the
asynchronous
management
work
is,
is
also
quite
active
and
and
is
existing
work.
B
So
with
that
with
an
idea
of
that
which
is
new
in
that
which
is
existing
and
and
rick.
Please
correct
me
if
you
wanted
to
approach
this
in
a
different
way.
We
were
going
to
go
slide
by
slide
and
talk
through
some
of
this
and
then
elicit
any
comments
for
each
of
these
topics
and
then,
when
we
get
to
the
end,
if
there's
anything,
that's
missing,
we
would
then
discuss
that
as
as
new
items
is
that
about
right,
rick.
A
That's
that
was
my
plan.
I
think
there
is
a
danger
if
we
stop
constantly
for
people
to
say.
Oh
what
about
this
subject,
then
we'll
miss
out
an
active
discussion
over
the
things
we
have
already
discussed
at
some
length,
so
this
slide
on
asynchronous
management
is
just
to
say
there
we've
heard
twice,
maybe
three
times
now
today
that
I'll
turn
my
camera
on
for
polinus,
we've
heard
twice
or
maybe
three
times
today
from
people
saying
management
needs
more
work,
we're
really
interested
in
amp.
A
So-
and
this
is
just
to
say,
although
we
have
a
charter
item
already
about
the
management
architecture,
and
we
have
a
draft
which
really
is
ready
for
last
call
as
an
aside
that
we
will
ask
for
last
call
after
this
meeting
there's
work,
there's
energy,
there's
teams
working
on
this.
From
my
perspective,
although
it's
existing,
I
think
it
really
should
go
ahead.
That's
the
only
reason
this
slide
is
here.
A
The
rest
of
the
slides
are
purely
talking
about
the
new
items
and
breaking
them
down
so
that
people
get
some
idea
of
of
of
where
the
discussion
is
going
so
carry
on
ed.
I've
interrupted.
B
No,
no,
no,
that
that's
good!
So
so!
Yes,
I
agreed
there's
a
lot
of
of
of
the
set
of
existing
work,
there's
a
lot
of
good
work
behind
there
and
I
think
that
a
lot
of
that
should
continue.
I
certainly
heard
the
same
message
that
management
is
something
that
we
need
to
tackle
here
and
that
it
is,
has
unique
parts
to
dtn.
So
I
think
that
that
is
fairly
and
and
firmly
in
scope
for
a
recharter,
and
then
I
think
we
should
talk
through
these
new
proposals.
B
No,
no,
please
yeah,
I
I
I
talk
plenty.
Why
don't
you
go
through
and
talk
through,
naming
and
addressing
and
so
on.
A
Yeah
I'll
start
to
peter
out
when
it
gets
to
sort
of
discovery.
Okay,
so
so
naming
addressing
there's
quite
a
lot
of
detail
on
these
slides
and
I'll
go
reasonably
quickly,
but
these
are
things
that
I
believe
should
be
tackled
as
part
of
naming
and
addressing.
So
on
the
surface
naming
addressing
sounds
really
obvious,
because
bundle
protocol
defines
the
ipn
and
the
dtn
eid
format.
It
specifies
how
you
put
text
characters
in
what's
valid:
what's
not
jobs
done
where's
the
complexity?
A
The
complexity
really
is.
When
you
start
to
read
between
the
lines
of
bundle,
protocol
version
7
and
the
earlier
bundle
protocols,
the
concept
of
late
binding
of
endpoints
is
very
interesting.
It
starts
to
suggest
that
an
endpoint
is
named
and
the
name
doesn't
necessarily
give
you
any
meta
information
of
how
to
get
a
bundle
to
that
name.
So
so-called
locator
identity,
separation,
okay,
so
then,
if
bundles
are
bundle,
names
are
semantic
rather
than
location
based
or
they're
purely
an
identifier.
A
How
do
we
locate
them,
etc,
etc?
So,
there's
a
lot
of
questions
here.
One
of
the
other
questions
is
okay.
We've
we've
got
a
dtn
and
we've
got
an
ipn
scheme.
Are
they
global?
Will
the
interplanetary
internet
have
a
single
set
of
of
globally
unique
names?
If
so,
who
controls
them?
The
schemes
are
controlled
by
iona
the
scheme
registration.
A
Does
that
extend
to
icann
handing
out
in
in
a
sort
of
dns
style
way?
Is
it
a
free-for-all?
There
are
some
open
questions
there
that
need
to
be
addressed,
and
the
bottom
point
here,
which
is
entity
ids
an
entity
id
can
refer.
It
can
be
a
multicast
entity
so
giving
you
multicast
anycast
style
capabilities.
So
it's
not
blindingly.
Well.
That
underlines
my
thought
that
there
is
locator
identity
separation
going
on
here.
This
is
a
topic
that
needs
careful
thought
and
many
of
these
things
need
to
be
tackled.
A
That's
that's
my
pitch
on
naming
and
addressing
as
a
sort
of
addendum
to
that.
As
part
of
our
current
charter.
There
is
an
item
called
a
registry
of
service
identifiers,
so
this
is
the
concept
of.
Are
there
common
bundle
services
a
bit
like
the
common
services?
You
would
get
in
your
services
file
on
a
on
a
unix
machine
which
says
port
22
is
ssh,
port
80
is
is
http.
A
Do
we
have
common
dtn
services
that
we
wish
to
update?
I
think
there
is
an
existing
iona
registry.
Do
we
wish
to
refresh
that?
Do
we
wish
to
do
that
sort
of
work
from
that
point,
ipn
has
a
concept
of
a
service
number
as
part
of
its
definition.
Dtn
doesn't
so
that
probably
needs
to
be
tackled
at
some
point.
B
And
rick
yep,
oh,
I
think
we
have
somebody
who
joined
the
queue.
A
D
Hello,
do
you
hear
me?
Yes,
yes
yeah,
I
was,
I
actually
chatted
the
same
thing,
which
is
in
the
chat
room,
so
we
a
while
ago,
we
discussed
that
we
would
do
that
work
after
you
know,
bp
business
kind
of
you
know
done
so
that,
if
anything
related
to
it
is,
would
have
an
impact
on
this
thing,
which
we
all
thought
it
was.
D
You
should
not,
but
you
know
to
be
precocious,
so
I'm
happy
to
resume
that
work
and
you
know,
do
a
new
draft
and
and
working
through
the
hurdles
of
this
work.
I
think
that's
very
important,
because
right
now,
there's
kind
of
an
implicit
you
know
things
around
and
around
people
deploying
that
is
that
they
know
what
they're
expecting,
but
in
the
general
context
of
deploying
like
you
said,
like
you
know,
port
numbers,
we
need
to
identify
and
standardize
what
we
expect
to
receive.
A
So
right,
I'm
gonna,
I'm
gonna
keep
going
on
this
because
I
want
to
try
and
get
to
some
discussion
as
well
as
these
slides
are
possibly
useful
to
go
back
to
if
people
wish
to
raise
explicit
comments.
A
Another
topic
that
has
come
up
over
the
years
repeatedly
is
when
we
get
bp7
out
the
way
in
bpsec
etc.
We
really
ought
to
tackle
neighbor
discovery.
So,
on
my
analysis,
neighbor
discovery
is
sort
of
divided
actually
into
a
couple
of
topics.
There's
neighbor
discovery
is
a
bundle
protocol
facility,
so
some
kind
of
bundle,
protocol
style,
arp.
That
says
you
know
I
will
send
bundles
across
my
one
hop
or
whatever
neighborhood
to
say:
hey,
I'm
here
who
are
you?
What
have
you
got
kind
of
an
arp
analogy?
A
Then?
If
we've
got
service
identifiers,
do
we
use
that
as
service
discovery,
as
well
as
node
id
discovery
given
endpoint
ids
implicitly
encapsulate
services?
Maybe
also
there's
the
element
that
convergence
layers,
because
they
could
well
be
running
across
ip,
which
has
its
own
neighbor
discovery
mechanisms.
Convergence
layers
may
discover
neighbors,
possibly
wouldn't
discover
dtn
services
at
neighbours,
but
could
probably
discover
node
ids
and
that
information
could
flow
back
up
in
a
sort
of
event-driven
way
into
the
into
the
bundle
protocol
there
to
say
hey.
A
That's
why
I
thought
about
neighbor
discovery
and
it's
more
than
one
draft
in
my
mind,
any
comments
on
that
or
I'll
move
on
to
the
next
one.
A
G
C
Endorse
the
importance
of
this,
I
think
the
the
ip
neighbor
discovery
protocol,
for
which
we've
had
a
draft
for
many
years,
is,
I
I
think,
is
an
excellent
starting
point,
and-
and
I
and
it
seems
to
me
the
the
the
the
the
core
of
neighbor
discovery
has
to
be
discovery
at
the
convergence
layer,
because
bottom
protocol
absent
that
converts
their
protocol
cannot
hear
anything,
and
so
I
don't
know
how
it
can
converse.
C
So
I
I
strongly
endorse
pursuing
this.
I
think
it's
a
really
important
charter
writer.
G
I
can
mention
that
I
did
play
around
a
little
bit
with
some
neighbor
discovery
based
on
mene
and
some
other
related
protocols,
and
one
of
the
updates
to
the
udpcl
would
be
to
enable
a
multicast
type
of
discovery.
A
That
that
sounds
like
there's.
There's
such
general
interest
and
support
there
for
the
neighbors
discovery
tasks
so
noted.
What's
the
next
slide?
Is
it
more
contentious?
Yes,
it's
the
big
one
rooting
okay.
So
as
several
people
brought
up
in
the
the
ipn
sig
and
the
esa
opsats
implementation,
experiences
routing's
really
hard,
but
it
has
to
happen
otherwise.
How
on
earth
do
we
work
out
where
or
where
to
send?
Where
or
when
to
send
these
bundles?
A
I
know
contact
graph
routing
has
been
a
stalwart
now
named
sabre
from
from
ccsds.
A
I
really
hope
they're
listening
and
can
come
and
talk
to
us
at
ietf
111,
because
they
had
done
some
tweaks
for
bp7,
which
would
be
interesting,
and
I
think
we
have
to
be
realistic
and
say
we
haven't
solved
rooting
and
lots
of
people
are
itching
to
turn
up
with
exciting
rooting
ideas.
A
So,
as
I
say
here,
attempting
to
standardize
one
of
these
within
the
working
group
starting
tomorrow,
I
think
maybe
beyond
our
current
bandwidth,
I
I
don't
think
we
have
sufficient
bits
and
pieces
together
to
try
and
get
this
done
within
a
reasonable
period
of
time.
A
A
They
they
separate
the
the
information
that
the
routing
protocol
builds
into
its
routing
information
base
and
the
sum
of
whatever
clever
protocol
evaluation
that
is
performed
is
then
placed
into
the
forwarding
information
base
of
the
system
which
actually
moves
the
packets.
You
know
kind
of
the
os
kernel
or
or
however,
whatever
your
abstract
image
is,
and
I'm
wondering
whether
it
would
be
achievable
and
beneficial
for
the
working
group
to
try
and
define
the
forwarding
information
base
in
terms
of
these
are
the
minimum
things
you
need
to
have
in
that
conceptual
data
structure.
I'm
not.
A
I
don't
want
to
get
in
to
see
implementation
here
or
rust,
or
name
your
favorite
language,
I'm
trying
to
say
to
do
forwarding
the
bundle.
Processing
agent
needs
this
information
now.
I
think
that
might
be
achievable
because
it's
alluded
to
in
bundle
protocol
version
7
but
quite
rightly
bundle
person
version
7.
At
a
certain
point
says
this
is
out
of
scope.
A
I
think
it
might
now
start
to
be
in
scope
and
it
allows
us
to
see
how
that
that
forwarding
table
interacts
with
neighbor
discovery
and
convergence
layers
and
naming
and
addressing
without
having
to
work
out
how
to
do
full
end
to
end
root
and
path.
Tie
down
that
I'm
gonna
flip
back
to
the
actual
yeah
scott's
in
the
queue
I
knew
someone
was
in
the
queue
go
ahead.
Scott.
C
I
think
you're
correct
that.
That's
our
thing
to
point
off
right
now.
I
I
think
it's
still
a
topic
that
is
actively
being
researched
and
I
think
there
are
remain
new
ideas
that
can
be
discovered
that
can
be
applied
to
it.
So
I
endorse
the
idea
of
like
continuing
to
study
this
and
pay
a
lot
of
attention
to
it
and
bring
it
up
at
these
meetings
and
and
yet
not
yet
to
commit
to
a
a
particular
target
document
production
as
as
part
of
the
charter.
C
Yet
one
other
thing
I
would
like
to
say
in
connection
with
that
is
that
I
think
multicast
is
an
important
element
of
the
forwarding
and
routing
and
and
also
of
the
naming
and
addressing.
It
is
a
topic
that
is
near
and
dear
to
my
heart,
and
I
think
it
might
be
productive
to
pursue
multicast
in
the
naming
and
addressing
sort
of
area
before
plunging
into
what
we
do
in
in
terms
of
route
computation.
C
C
A
I
absolutely
agree
because
you're
right
about
multicast-
and
I
really
wish
I'd-
put
a
slide
in
now
about
it.
Multicast
touches
addressing
as
in
how
do
we
know
it's
a
multicast
group,
it
touches
forwarding,
as
in
when
I'm
trying
to
send
a
multi-car
a
bundle
address
to
something
multicast.
How
do
I
forward
that,
and
how
do
I
know
that
I
forwarded
it
to
all
the
you
know
and
the
group
membership
so
it
attached
it
affects
neighbor
discovery.
How
do
I
dis
what
is
our
equivalent
of
igmp?
C
A
And
this
was
one
of
the
reasons
I
suggested
that
an
an
interim,
perhaps
to
just
put
all
the
naming
and
addressing
discussion
on
the
table
and
just
chew
that
one
subject
to
work
out
if
we
even
had
any
kind
of
consensus
at
all,
I
think
there
might
be
some
value
in
that
again
we'll
see
but
interesting
to
see
what
people's
opinion
is.
I,
okay,
I'm
sorry,
I'm
not
I'm
hearing
good
noises
from
scott
about
forwarding
we'll
see
what
everyone
else
has
to
say.
What
else
have
I
got.
B
Is
is
then
the
sense
that
routing
in
general
is
not
a
topic
that
we
should
look
at
for
the
current
charter,
because
it
is
complex
and
probably
best
tackled
after
we
do
naming
and
addressing
to
include
multicast,
so
naming
addressing
in
multicast
should
be
in.
But
routing
routing
should
not
be
in
this
in
this
next
in
this
next
rev
that
that's
what
I
took
away
from
that-
and
I
just
wanted
to
make
sure
that
that
is
the
right
thing
to
be
hearing
well.
D
A
That
I
think
we
we
kind
of
are
going
to
have
to
define
it
and
if
we
don't
we'll
sort
of
automatically
have
to
define
it
at
the
start
of
every
document.
That
really
should
refer
to
the
standard
definition
and
they'll.
All
slightly
disagree
yeah
so
very
quickly
summarizing,
because
I
think
this
is
the
last
slide.
I've
got
in
the
deck
as
mentioned
before.
There's
the
dtnk
administration
work.
I
know
scott
presented
some
work.
I
think
he'd
been
doing
a
fred
templin
on
some
really
clever
techniques
for
distributing
keys.
A
I
mean
bp
sec
and
the
convergence
layers
require
cryptographic
material.
If
these
networks
are
delayed
and
disrupted
disrupted,
then
the
keys
still
need
to
get
there
just
relying
on
some
unspecified
outbound
mechanism
at
a
band
mechanism-
okay,
but
it
would
be
nice
to
have
some
protocols
that
do
this
that
run
over
bpsec.
I
There
we
go
okay,
much
better.
I
think
I
double
clicked
muting
for
some
reason
I
requested
to
present
clarifying
on
the
on
the
forwarding.
So
would
it
be
in
scope
to
so?
Is
it
just
affording
information
based
or
does
health
does
that
include
how
forwarding
decisions
are
made,
given
that
information.
A
I
A
Yeah,
that's
I
I.
If
I
was
writing
this
document,
I
would
say
how
this
table
is
populated,
is
currently
out
of
scope
and
if
neighbor
discovery
protocols
want
to
say-
and
actually
you
can
populate
bits
of
the
fib
with
the
equivalent
of
linked
local
addresses
or
link
local
scoped
stuff,
that's
great,
they
can
say,
and
this
can
be
used
to
populate
the
following
fields
within
the
forwarding
information
base.
So
it's
kind
of
I
could
see
it
being
informational.
I
don't
think
it
needs
to
specify
anything.
I
I
mean
it
seems
like
a
sensible
conceptual
breakdown.
In
my
mind,
the
other
related
point
I
would
make
is
I
would.
I
would
ask
that
the
charter
consider
the
cross
area.
Consultation
should
happen,
whether
it
be
interior,
routing
area
or
whatever.
It
is
that's
relevant
to
this
I
mean
you
know
naming
and
so
on.
Thanks.
B
Hey
scott.
C
I
like
the
idea
of
an
informational
document
that
describes
the
of
the
forwarding
information
base.
I
think
establishing
concepts
and
terminology
would
be
very
helpful.
The
other
thing
I
did
what
I
originally
originally
got
into
the
q4
was
to
endorse.
Certainly.
A
Thanks
scott
zahed,
hello,
welcome
on
uad.
M
Yes,
before
I
mean
now
we're
open
mike,
I
I
was
thinking
like.
Maybe
I
should
say
before
you
start
the
presentation,
I'm
describing
all
the
topics,
but
I
mean
help
me
understand
the
one
thing
like
I
think
this
is
this:
is
mix
of
technical
and
and
like
charter
discussion,
rechargeable
discussion
like
there's
a
technical
difficulties
and
now
what
is
included
in
the
current
chapter
charter
or
what
it's
rechartering
help
me
in
this
discussion
to
understand
it
better
like
when
you
talk
talk
about
how
to
discuss
something
on
the
topics.
A
So
I
was
from
my
perspective.
I
was
really
just
going
to
raise
the
list
of
things
we
had
previously
talked
about
to
the
working
group
and
say
everyone:
we've
we've
been
dancing
around
these
topics
and
as
chairs,
either
myself
or
an
ed
or
myself
and
mark
have
said
not
yet
because
we
need
to
get
bundled
protocol,
7,
bpsec,
etc.
Tcpcl
out
the
door
now
they're
gone,
we've
done
them
now,
so
we're
now
going
to
stop
saying
no
to
everything.
A
But
obviously
we
can't
say
yes
to
everything,
but
here
is
the
list
of
all
the
things
we
said
no
to
before.
What
do
you?
The
working
group
want
to
do,
which
has
to
be
ordered
by
not
only
interest
but
also
technical
need,
so
we
can't
go
off
and
all
as
a
working
group
go
and
work
on
some
crazy
quantum
based
probabilistic
forwarding
routing
algorithm,
although
it
would
be
great
if
we
can
all
get
phds
again,
we'll
never
achieve
anything.
A
Is
there
interest
in
the
working
group
to
do
these
things
so,
and
this
is
really
everyone
else
in
this
meeting
and
again
on
the
mailing
list
later
on?
Can
you
gives
ahead
your
feedback
on
what
you
I
know,
scott's
excited
about
doing
stuff?
I
know
mark's
excited
about
doing
service
identifiers.
Is
there
interest
from
others
I'm
going
to
do
a
poll
you.
B
I
just
wanted
to
make
the
the
observation
that
when
we,
when
we
looked
at
and
started
with,
bundled
protocol
version,
6
and
rfc
5050
again
going
back
to
2002,
there
were
a
lot
of
deployments
and
lessons
learned
from
that
and
part
of
that
working
group
was
to
take
that
that
set
of
work
and
then
turn
it
into
the
non-experimental
specifications
and
because
it
has
taken
several
years
for
that
that
tail
part
of
that
process.
B
We
now
have
a
case
where
some
of
these
other
activities
have
been
up
and
running
in
various
areas
for
a
few
years
or
or
more
in
reference
implementation,
in
this
case
I'm
thinking
of
the
network
management,
but
also
some
of
the
the
routing
work
and
so
on,
and
we
have
experience
with
what
needs
to
be
done
there.
B
So
I
think
for
some
of
that,
it
is
working
through
that
backlog
to
make
based
on
the
priority
of
how
much
effort
and
how
close
are
they
to
finishing
and
and
almost
having
part
of
that
next
recharter
be
like
the
original
charter,
which
is
take
that
body
of
work
and
finish
it
and
and
before
we
get
into
the
things
that
are
really
sticky
and
and
difficult
to
work
through.
M
Yeah,
so
so
let
me
just
clarify
myself
a
bit
I
mean
I
I
was.
I
was
reading
the
charter
text
and
trying
to
understand
what
has
been
discussed
so
far
today,
and
there
was
like
a
couple
of
things
like
the
service
registry
and
stuff,
like
that.
Those
are
already
in
the
chat
right
and
there
are
some
existing
architecture,
work
and
other
things
are
already
yeah.
M
This
working
group
is
working
on,
but
there
are
some
new
topics
like
cosa.
If
you
need
like
a
key
management,
whether
that's
something
people
are
interested
in.
So
I
was
like
what
I
wanted
to
take
advantage
of.
Today's
discussion
is
like
if,
when
you
are
discussing
the
technical
discussions,
technical
interest
and
whether
something
is
needed
also
might
be
a
footnote
saying
like
this
is
perhaps
needs
some
rechartering
so
that
I
can
record
it
for
myself
for
further
description.
M
But
that's
the
only
thing,
but
I
understand
like
if
you
want
to
only
do
the
technical
discussion
and
pull
the
interest
of
the
working
group.
That's
fine.
You
can
come
back
to
recharge
questions,
whether
you
say
including
charter
and
current
chatter,
or
we
need
need
to
reach
it,
or
maybe
you
can
revisit
that
one
later
on.
A
So
yeah
it's
ahead,
I
think
that's
a
conversation
we'll
the
chairs
and
you
can
have
between
now
and
ietf111,
where
perhaps
we
can
propose
a
charter
based
on
the
the
simultaneous
conversation
within
the
working
group
about
the
technical
aspects
and
the
importance
and
then
at
one
one
one.
We
can
decide
whether
a
proposed
new
charter
works,
whether
the
isg
is
happy
to
do
that,
blah
blah
blah.
If
that
works.
For
you.
A
I
Sure
I
I'll
have
on
two
completely
unrelated
points
as
irresponsible
ad
number,
one
that
beyond
just
like
what
the
group
wants
to
work
on,
I
think
it's
always
important
to
ask
what
is
actually
what
are
people
like
really
dying
to
deploy?
This
is
not
a
research
group,
so,
let's
make
sure
there
are
clear
applications.
I
The
other
on
totally
unrelated
point
is
about
convergence
layers.
If
I
understand
correctly,
the
only
thing
we're
considering
doing
is
udpcl
this
at
this
point.
Yes,
so
the
other
thing
I
okay,
fair
enough,
the
only
thing
I
want
to
pitch
here
is
taps.
I
don't
know
who
here
is
aware
of
that
is.
It
is
a
different
transport.
I
No,
no,
no
worries,
so
it's
another
transport
working
group
there's
also
heads
actually,
but
I'm
involved
in
it,
but
anyway.
D
I
Is
a
generic
api
for
applications
to
leverage
whatever
transports
happen
to
be
on
the
platform
by
they
would
just
the
very
short
pages
applications
request
certain
characteristics
and
then
you
would
just
go
find
whatever
tls
library,
whatever
http
library,
whatever
tcp
implementation.
Whatever
I
mean
taking
an
expansive
view
of
transport
from
http
and
below
to
include
you
know,
tls,
etc
so
anyways.
The
upshot
of
this
is
not
sure
how
big
it
is,
but
I
think
that's
a
very
fertile
ground
for
something
like
this.
Where
you
could
have.
A
I
Yeah,
so
just
something
to
play,
I
mean
that
doesn't
sound
good,
a
ton
of
convergence
layer
stuff
in
this
round,
but
it's
something
I
think
that
people
should
take
a
look
at
a
great
entry
point
to
this
is
the
tsv
area
meeting
from
109..
This
is
the
last
session.
We
had
a
talk
very
similar
to
edwards
today
on
dtn,
but
it
was
about
taps
by
brian
trammell.
There's
a
good
30
minute
discussion
of
what
that's
about.
If
people
don't
want
to
read
a
ton
of
text
thanks.
A
Okay,
thanks
martin,
so
I
was
putting
a
poll
together
very
quickly.
Basically
saying
is
anyone
interested
in
doing
this
work?
Given
the
time
I'm
wondering
whether
it's
it's
worth
people
I'm
going
to
check
the
chat?
A
Putting
forward
to
any
questions
I
mean
it
really
is
open,
mic
technical
questions.
Have
we
missed
something?
Are
you
itching
to
work
on
something
that
you
think
is
vital,
that
we
have
completely
missed.
C
I'd
like
to
get
in
a
plug
for
quality
of
service,
again
that
disappeared
from
funnel
protocol.
I
think
people
are
going
to
need
it
exactly.
What
that
is,
I
think,
is
open
to
a
lot
of
discussion,
but
I
I
think
we're
gonna
need
to
have
something,
and
that
would
be
a
an
additional
thanks
for
block
and
on
that
top.
C
The
manifest
extension
block,
as
ed
pointed
out
a
couple
of
months
ago,
is
maybe
obviated
by
bp
sec,
because
the
multi-target
nature
of
bibs
and
who
needs
the
manifest
blocks
to
be
able
to
do
the
job.
A
Yeah,
okay,
I
take
your
point
on
qos
completely
missed
that
out
and
yes,
that's
vital,
and
that
opens
the
door
to
okay.
If
you're
going
to
do
qos,
is
it
a
one
bit
high
priority
low
priority
switch
or
is
it
a
full
mpls
style
label
switch,
pin
down
flow
track
model
to
allow
transit
networks?
I
think
the
answer
is
somewhere
in
between
the
two,
because
bundle
and
bundle
can
handle
your
segment
routing.
If
you
want
to
do
it,
but
yeah.
A
B
The
last
thing
I
was
going
to
bring
up
as
a
question
is:
do
we
do
we
think
that
there
is
value
in
planning
now
for
an
interim
meeting
to
to
sort
of
force?
You
know
the
discussions
on
the
working
group
in
anticipation
of
an
interim
meeting
so
that
we
can
then
have
a
down
select
to
then
better
inform
the
next
working
group
meeting
at
the
next
ietf
and
just
wanted
to
know
if
there
was
any
concerns
about
the
ability
to
support
that.
B
A
Poll
is
for
an
interim
meeting.
It's
it's.
Would
you
attend
an
interim
meeting
before
july
and
I'm
seeing
of
the
30
yard
participants
I'm
seeing
a
five
positive,
yeah,
okay,
well
I'll,
let
that
tickle
along
because
we're
we're
heading
towards
the
end
of
the
session.
Where
is
the
pole?
So
the
pole
there
is
a
there
is
a
poles
tab
somewhere.
A
A
So
really
the
the
session
is
coming
to
a
close.
Luckily,
they
keep
the
microphone
open
for
a
little
bit
longer.
I'm
gonna
watch
the
queue,
and
I
what
I'm
seeing
is
is
an
overwhelmingly
positive.
Yes,
they
would
attend
an
interim.
A
I
think,
as
ed-
and
I
mentioned
before,
an
interim
would
be
a
sort
of
cards
on
the
table
discussion
about
probably
naming
and
addressing,
because
I
think
that
drifts
into
neighbors
quite
easily,
but
we
can
discuss
the
the
the
actual
content
of
the
of
the
interim
on
on
the
list
between
now
and
a
sort
of
midway
between
now
and
ietf.
111
would
be
my
proposal
for
for
when
to
hold
the
interim
ed.
Do
you
have
any
closing
comments,
and
I
am
going
to
end
that.
B
Nope
no,
no
closing
comments
other
than
thank
you
to
everyone
who
presented.
Thank
you
for
everyone
for
your
attention
and
please
be
active
on
the
working
group
mailing
lists,
particularly
as
we
go
into
that
interim
discussion,
because
we
recharter
infrequently-
and
it
is
important
that
we
get
the
priorities
of
these
things.
Correct.
A
And
equally
watch
the
mailing
list,
because
we
will
be
asking
for
some
working
group
adoption
for,
on
behalf
of
the
authors
of
a
couple
of
drafts,
so
they'll
be
in
the
next
couple
of
days
a
bit
of
a
flurry
of
emails,
saying
working
group,
adoption,
yay
or
nay.
So,
please,
let
us
have
your
feedback
on
that,
as
usual,
ascent
is
assumed,
as
silence
is
assumed
as
ascent
but
otherwise
enjoy
the
rest
of
your
ietf.