►
From YouTube: IETF110-TSVAREA-20210311-1200
Description
TSVAREA meeting session at IETF110
2021/03/11 1200
https://datatracker.ietf.org/meeting/110/proceedings/
B
All
right:
well,
we
can
start
now.
I
guess
it's
it's
one
after
the
hour
welcome
everyone
to
tsv
area
at
110.
I
hope
you're
all
having
a
good,
remote
meeting
approaching
the
end
here.
I
think
this
is
the
notewell,
I
think,
probably
most
of
you.
If
not
all
of
you
have
seen
this,
if
you
have
any.
B
B
This
is
the
agenda
for
today
I
would
like
to
bash
my
own
agenda
and
actually
just
move
the
open
mic
in
front
of
ed's
dtn
talk
just
because
I
think
it'll
be
shorter
and
I
just
want
to
give
dtn
the
time
it
needs
to
to
take
us
where
the
discussion
wants
to
go.
So
after
the
normals
of
this
trivia
and
the
open
mic,
we're
going
to
have.
B
Barron
of
the
I
hope
I
pronounced
that
correctly
of
the
dtn
working
group
he's
the
new
chair
there
and
he's
going
to
repeating
the
the
experience
of
our
presentation
last
time,
we're
going
to
highlight
another
less
known
part
of
the
area
and
and
talk
about
dtn,
which
is
pretty
cool.
It's
got
lots
of
deep
space
stuff,
which
I
think
is
cool,
and
it's
also
a
lot
of
interesting
and
challenging
technical
problems.
So,
looking
forward
to
that
talk,
would
anyone
else
like
to
bash
the
agenda.
B
Okay,
our
most
significant
change,
I
think,
is
that
as
of
yesterday,
in
a
somewhat
bittersweet
moment,
we're
not
saying
goodbye
to
magnus
by
any
means
he's
not
going
anywhere,
but
he
will
no
longer
be
one
of
the
area.
Directors
magnus
has
done
a
total
of
six
years
of
the
job
again
in
2006
and
just
concluded
a
two-year
term.
It
has
been
incredibly
valuable
to
me
to
have
someone
with
that
depth
of
experience
both.
B
And
is
in
the
transport
area
in
the
itf
in
general,
because
I
I
I'm
not
necessarily
strong
in
that
particular
area
and
just
having
his
advice
and
his
his
his
his
wisdom.
D
B
A
number
of
matters
has
been
invaluable
to
me
so,
and
you
know
I
think,
he's
done
a
lot
of
things
for
a
lot
of
people.
C
B
In
this
area,
his
most
notable
achievement-
probably
I
think
he
would
say
his
most
notable
achievement
in
this
term-
was
getting
quick
out
the
door
just
under
the
wire,
which
is,
of
course
an
enormously
consequential
development,
not
just
for
transport
area
but
for
the
internet
and,
of
course,
he's
and
of
course,
zahad
is
moving
into
that
position.
B
A
Thank
you
very
much
for
those
words
yeah,
it's
been
two
fairly
interesting
years
been
intense
with
quick,
but
I
I
also
would
like
to
really
I
think,
if
large
accomplished
has
been
to
actually
get
the
dtn
core
specs
out.
A
That
in
some
sense,
has
taken
more
work
from
me
as
an
aed
and
then
a
lot
of
four
near
issues
with
cross-area
relations,
because
dtn,
as
you
will
see,
is
actually
not
just
the
transfer
protocol.
It's
the
whole
idf
squished
into
one
working
group
in
some
sense
for
that
particular
problem.
So
it's
it's
a
lot
of
challenging
problems
and
security,
routing,
etc
all
exist
in
there.
A
But
you
will
learn
more
about
that
later,
but
so
therefore,
actually
is
happy
that
we
managed
to
get
the
first
set
of
specs
yes,
standards,
standard
strikeout
and
that
the
working
group
can
continue
to
work.
There's
been
a
number
of
other
specs,
but
actually
looking
back.
This
two-year
term
has
been
from
a
document
perspective,
valley,
light
and,
and
we
haven't-
which
maybe
got
more
through
in
some
sense,
but
yeah
still
idf
changes
and
that's
been
noticeable
also
compared
to
my
2016-2010
term.
This.
It's
another
isd:
it's
another
itf!
A
Logically,
you
maybe
not
notice
this
when
you're
just
looking
here,
but
when
you
take
this
managerial
roll
up
and
you
see
a
little
bit
more
and
you
actually
see
what
has
changed,
etc.
So
I
I
enjoy
it,
but
I'm
gonna
enjoy
being
back
going
back
to
doing
maybe
a
little
more
technical
work
and
also
the
tsb
art
is
not
gonna
get
rid
of
me
because
I'm
backwards
reviewing
and
I'm
gonna
probably
work
a
little
bit
more
intensely
to
sign
them
documents
when
to
help
out
wes
in
the
triage
position.
So.
A
B
Yeah
done
thanks
magnus
for
your
work
and
your
friendship.
Would
you
like
to
introduce
yourself.
E
Yes,
I
would
I
so
so
thanks
magnus
and
martin
duke
for
having
me
here.
I
need
to
be
here
and
to
some
extent,
so
my
name
is,
but
usually
people
call
me
a
short
version
of
that
jahid.
So
you
can
call
me
jahid,
so
I
work
at
ericsson,
particularly
ericsson,
research,
especially
with
magnus
as
colleague
for
last
13
years.
E
E
After
then
I
have
been
working
on
different
working.
I
think
it
was
pc
and
working
group.
That's
where
I
first
posted
my
draft
and
then
I
worked
in
a
video
call
webrtc
and
more
like
quick,
and
I
have
chair
tabs
taps
arm
cut
substantial
work
done
in
the
arm
cut
so
internally
also,
I
have
been
working
on
different
layers
like
application,
layer,
transport
layer
and
radial
layer,
so
I
have
some
experience
on
the
mobile
networks,
obviously
everywhere,
for
example.
So
that's
that's
it
that's.
E
Who
am
I,
as
some
of
you
might
already
know
me
and
I'm
looking
forward.
I
think
I'm
already
getting
so
two
thing
I
did
when
I
get
assured
from
magnus
he's
not
abandoning
me
and
the
other
thing
is
like
I'm
taking
off
some
of
the
stack
that
he
has
left.
So
nice
work
done
great
achievements
magnus,
hopefully
I'll
leave
up
to
this
expectation.
B
Welcome
zahad,
I'm
looking
forward
to
to
spend
the
next
couple
of
years
with
you.
This
will
be.
This
will
be
fun.
Moving
on
here
is
a
update
of
of
the
working
groups
from
across
the
area.
B
I
will
say
that
alto
dtn
are
rapidly
approaching
a
recharter,
as
is
quick
for
that
matter,
and
so,
if
you're
interested
in
the
overall
direction
of
those
groups,
this
is
a
good
time
to
get
involved
in
those.
B
B
A
And
the
fact
that
we
actually
I
mean
the
first
four
of
the
quick
documents
I
do
expect
to
within
weeks.
As
I
said
yesterday
in
the
plenary
too,
it's
it's
nothing
preventing
it's
just
the
editing
time
from
the
rfc
editor
here
and
then
the
other
48
and
there's
so
there's
no
known
issues
before
it's
published.
The
quick
http
and
coupon
specs
they're
gonna
be
stuck
behind
the
miss
ref
in
hbbs,
but
I
expect
it
to
come
out
within
a
few
months.
They
are
making
progress
and
we're
already
working
plus
call
a
few
back.
B
So
not
only
quick
and
dtn,
which
we've
already
spoken
about
the
significance
of
that,
but
also
cluster
238,
the
the
for
the
pile
of
rmcat
documents
that
was
stuck
forever,
actually
made
it
to
rfc.
So
the
queue
is
much
smaller
than
it
used
to
be
just
a
few
things
that
are
blocked
because
of
some
some
down
references,
mainly
from
ippm,
so
good
work,
everybody,
it's
a
very
productive
interim
between
the
two
between
it
409
and
today.
So
nice
work.
A
Yeah-
and
I
expect
there's
a
few
more
of
those
documents
that
was
from
309-
is
it's
actually
gonna
start
moving?
Aren't
they
they're
some
of
the
ippm
documents
still
and
they
I
hope
they
nfs
it's
not
too
far
off
either,
but
it's.
B
B
This
is
our
every
meeting
reminder
that
we
have
a
tsv
area
review
team
which
greatly
assists
the
iesg
in
reading
documents
from
other
areas
and
looking
at
them
in
transport
lens
and
making
sure
they're
not
doing
stupid
stuff
from
transport
perspective.
I
invite
you
to
contact
magnus
or
wes.
I
think
magnus
is
not
listed
here,
but
I
think,
as
of
today,
he's
back
on
the
tsv
art
or
as
of
yesterday,
so
you
can
you
can
contact
west
or
magnus
if
you're
interested
in
participating.
B
I
think
it's
a
good
opportunity
to
learn
a
little
bit
what's
going
on
elsewhere
in
the
itf
outside
transport
area
and
also
helps
us.
A
lot
helps
create
good
quality
documents
and
I
think,
as
you
can
see,
that
little
number
parentheses
is
how
many
reviews
they
had
to
do
since
109..
So
you
know
people
read
one
or
two
documents
or
in
some
cases
zero
documents,
and
I
I
would
hope
that
shows
that's
not
an
incredibly
onerous
workload
on
people.
B
So
so,
please,
you
know
if
this
something
interests
you
please
contact
either
west
or
magnus,
and
thanks
to
our
reviewers
for
the
good
work
that
they've
been
doing.
C
B
Okay,
so
that's
I
stopped
sharing
okay,
so
that
concludes
the
advanced
trivia
and
I
think
we'll
go
ahead
and
open
it
up
for
open
mic.
If
anyone
has
any
concerns
issues,
questions
about
things
in
the
area.
C
B
Okay,
there's
a
very
content
population
out
there,
either
that
or
asleep
where
most
of
us
should
be
right
now.
Okay,
so
I
think
at
this
point
we'll
go
ahead
and
head
off
to
edward
moran,
who
is
the
dtn
working
group
chair
the
newish
one,
and
he
is
going
to
talk
about
this
particular
part
of
the.
B
B
D
So
I
clicked
share
screen
request
and
I
think
I'm
cued
waiting
to
be
given
permission.
Oh
yes,.
D
Right
and
are
you
seeing
my
screen?
Oh
I'm
saying
my
screen
so,
okay
hi,
my
name
is
ed
bahrain,
I'm
from
the
johns
hopkins
university,
applied
physics
laboratory,
I'm
a
co-chair
of
the
dtn
working
group
along
with
rick
taylor
from
airbus
defense
in
space.
D
I
wanted
to
spend
a
little
bit
of
time
today
and
talk
about
just
sort
of
the
general
area
of
delay,
tolerant,
networking
and
then
some
of
the
things
that
we're
doing
in
the
working
group-
and
I
I
see
a
couple
of
familiar
names
in
the
in
the
meeting
and
some
people
who
had
been
working
on
dtn
in
the
past
as
well.
So
yes
can.
A
D
Oh
indeed,
thank
you
very
much,
no
worries
so
so
what
I
wanted
to
do
is
give
just
sort
of
an
overview
of
the
history
of
dtn,
how
we
got
here,
how
we
came
to
understand
the
problems,
how
it
came
into
ietf
and
then
in
particular,
as
magnus
said
before,
d10
is
a
large
and
sort
of
cross
area
set
of
concerns,
but
I
wanted
to
then
focus
a
little
bit
on
how
the
bundle
protocol,
in
particular
the
bundle
protocol
version,
seven
operates.
D
It
really
is
the
the
transport
protocol
for
dtn
and
the
thing
that
has
mo
you
know
a
lot
of
the
attention
with
the
addition
of
how
to
secure
that
protocol,
and
then
lastly,
I
I
have
there
are
many
case
studies
on
the
the
value
of
dtn
in
certain
environments,
and
I
picked
one
related
to
nasa
optical
communications.
D
D
There
was
an
initial
desire
to
move
from
this
very
point
to
point
link
scenario,
which
is
what
we
have
for
the
most
part
now
in
deep
space,
where
individual
space
agencies
build
their
entire
direct-to-earth
infrastructure
when
they
land
on
mars,
when
they
start
landing
on
the
moon
when
they
start
putting
orbiters
and
other
deep
space
assets
into
space.
And
how
do
we
get
to
a
point
where
we
get
to
some
sort
of
you
know
deeply
richly
networked
model
of
of
spacecraft?
D
Could
we
get
to
a
point
where
landers
are
only
carrying
enough
radio
to
get
up
to
an
orbiter
and
can
rely
on
a
network
to
give
them
that
multi-hop
back,
in
particular
with
the
non-linearities
of
transmission,
adding
those
hops
where
you
can
get
to
a
more
resource?
Node
actually
can
increase
the
data
rates
while
reducing
size,
weight
and
power
on
landers,
and
so
there's
there's
really
a
significant
desire
to
get
to
that
point.
D
So
when,
when
space
agencies
in
general
and
nasa
in
particular,
started
looking
through
this,
they
said
well,
there
are
a
couple
of
do's
and
do
nots
that
we
think
we
need
here.
Certainly
there
were
a
few
do
nots,
which
are.
We
can't
always
assume
that
a
path,
an
end-to-end
path
exists
all
at
once.
If
you're
a
lander
and
the
orbiter
isn't
overhead,
then
you
can't
talk
to
it.
If
the
orbiter
is
overhead,
but
you
don't
have
line
of
sight
back
to
earth,
you
can't
talk
to
ground.
D
You
therefore
also
given
long
light,
round-trip
delays
and,
just
generally
the
resource-constrained
nature
of
some
of
these
devices
you
you
also
don't
always
have
the
ability
to
keep
end
states
at
the
lander
down
to
ground
station
and
so
on,
and
certainly
because
of
those
first
two
things.
If
you
do
have
to
do
re-transmissions,
you
don't
want
to
re-transmit
from
the
original
message
source,
because
it's
hard
enough
to
get
through
the
network
and
starting
all
over
again
from
scratch
makes
that
more
difficult.
D
If
we
do
that
from
a
transport
perspective,
then
how
do
we
secure
things
now?
Obviously
we
know
we
can't
rely
solely
on
physical
layer
security,
but
if
you
are
in
in
this
sort
of
top
picture
of
point-to-point
links
without
really
a
networking
model,
there
tends
to
be
an
over-reliance
on
that
kind
of
security.
D
If
we
have
annotative
metadata
added
as
secondary
headers
in
a
packet
in
a
bundles
as
we'll
come
to
see,
does
that
change?
How
we
secure
things
and
then
how
do
we
make
sure
that,
while
we're
storing
things
for
milliseconds
or
days
that
they
are
secured,
and
then
there
are
other
questions
about
how
much
autonomy
goes
into
network
management?
And
how
do
we
do
routing
with
time,
variant,
graphs
and
so
on?
D
And
when
we
started
asking
those
kinds
of
questions,
then
the
the
the
first
thing
you
do
is
you
say
well
what
what
do
we
currently
have
and
what
can
we
currently
reuse?
We
certainly
don't
want
to
make
a
new
thing
just
because
and
and
there
were
sort
of
two
driving
concerns
that
came
out
of
you
know
everything
we
just
talked
about.
The
first
was
delay
and
the
second
was
disruption
and,
and
the
delay
case
is,
you
know
fairly
clear.
D
You
know
if,
if
we
look
at
this
particular
illustration,
where
we
have
you
know
some
number
of
nodes
nodes,
one
two,
three
and
four
on
the
vertical,
with
some
notion
of
time
on
the
horizontal
and
if,
if
blue
here
or
the
shaded
area,
represents
connectivity
between
the
nodes,
if
you
have
a
data
volume
which
we
call
d1
and
it
has
to
wait
for
an
end
to
end
node
1
to
node
4
path
to
exist
all
at
once,
it
may
be
waiting
for
a
very
long
time
and
it
may
be
waiting
for
long
enough
that,
by
the
time
that
transmit
opportunity
comes
there's
another
data
volume
which
would
be
in
contention
with
that
that
same
end-to-end
path,
and
if,
of
course,
we
can
take
advantage
of
sooner
hops
than
waiting
for
an
end-to-end
path,
then
the
ability
to
exfiltrate
data
off
of
a
particular
platform
sooner.
D
You
know
for
certainly
for
resource
constrained
devices,
allows
you
to
get
data
off
your
platform
so
that
you
can
free
up
storage
and
take
new
observations.
But
it
also
means
these
kinds
of
link
opportunities,
don't
become
wasted
in
the
network.
D
The
other
observation
was
disruptions
and
and
what
happens
when
we
have
frequent
enough
disruptions
that
the
disruptions
are
not
considered
strange
cases
to
recover
from,
but
they
actually
represent
the
normal
operation
of
the
the
network
as
you
have
it.
So
if
we
look
at
a
standard,
you
know
you
know
session
establishment
con
up
where
we
take
some
amount
of
time
to
synchronize
on
information.
We
do
data
exchange
and
keep
sessions
alive.
We
do
some
cleanup
at
the
end.
D
You
know
if
there's
negligible
disruption,
it's
all
handled
as
part
of
just
the
minor
jitter
in
the
network.
If
you
get
infrequent
disruptions
of
significant
length,
this
this
graphic
isn't
meant
to
imply
that
packets
are
actually
exploding.
But
if
we
sort
of
lose
and
time
out,
we
may
have
to
re-establish
sessions
or
if
the
session
itself
collapses,
we
may
have
to
re-establish
sessions
and
there's
an
implied
focus
here
on.
If
we
can
just
wait
out
the
storm,
then
we
can
go
back
to
normal
operations.
D
Of
course,
if
the
disruptions
are
regular
enough
and
infrequent
and
perhaps
even
unplanned,
then
it
becomes
a
lot
harder
to
do
that,
and
so
the
the
overall
area
of
dtn
started
as
delay.
Tolerant,
networking
it
sort
of
morphed
into
disruption,
tolerant
networking-
and
it
again
was
this
migration
from
you
know.
What
would
a
solar
system
internet
or
an
interplanetary
internet?
Look
like
30
50
years
into
the
future,
and
what
can
we
do
now
just
to
get
little
bits
of
it?
D
That
concept
doesn't
look
dramatically
different
than
local
sensor
networks.
So,
instead
of
an
orbiter
over
a
lander
on
a
planetary
surface,
you
may
have
a
data
mule,
maybe
a
uav
or
or
a
car,
or
a
bus
going
by
and
collecting
sensor
nodes,
and
maybe
you
have
a
satellite,
a
satcom,
backhaul
or
maybe
something
else,
and
so
if
the
problems
on
the
left
are
mostly
delay,
the
problems
on
the
right
might
actually
be
more
disruption.
D
So
then,
if
we
said
that
was
some
of
the
statement
of
problem,
what
could
we
start
doing
to
solve
all
of
this
so
so
dtn
started.
Looking
at
a
couple
of
things
related
to
you
know
existing
protocols.
Can
we
pick
up
and
reuse
ip
about
15?
I
think
at
this
point
15
years
ago,
there's
a
lot
of
discussion
of
whether
a
nasa
should
be
baselining
ip
for
their
for
their
deep
space
networking
aspirations.
D
They
started
looking
at
the
kind
of
things
that
are
just
sort
of
generally
considered
useful
on
the
internet.
Today,
a
couple
of
them
are
here.
I'm
sure
that
the
people
in
the
audience
know
and
can
come
up
with
many
more
suggestions
than
the
couple
of
bullets
here,
but
the
idea
of
of
caching
and
pushing
information
and-
and
not
you
know,
relying
on
sessions
if
you
don't
have
to
or
not
having
to
rely
on,
nested
sessions
and
things
of
that
nature.
D
But
a
lot
of
this,
it
came
down
to
the
observation
again
that
we
don't
have
infinite
access
to
bandwidth
and
and
as
silly
as
that
sounds.
If
you
are,
if
you
are
wholly
in
control
of
the
construction
of
your
purpose-built
network,
then
there
is
a
sense
that
you
can
build
it
and
resource
it
enough
for
the
data
that's
coming
through,
whether
whether
that
actually
tends
to
be
true
over
the
entire
lifetime
of
the
network
and
whether
that
remains
true.
As
you
try
and
federate
other
networks.
You
know
that
that
tends
to
be
the.
D
We
need
to
think
10
15
years
into
the
future,
so
so
being
able
to
go
to
missions
and
be
able
to
go
to
those
who
build
their
own
networks
and
say
you
cannot
just
assume
that
you
will
solve
these
problems
by
having
you
know
relatively
infinite
access
to
bandwidth.
D
Even
when
you
do
in
the
moment,
you're
going
to
have
to
prioritize
you're
going
to
want
to
look
at
whether
or
not
your
protocols
are
making
good
use
of
these
of
of
your
bandwidth
when
you
federate
you're,
going
to
need
to
worry
about
untrusted
infrastructure,
so
dtn
came
back
as
specific
solutions
to
some
of
the
problems
and
and
if
you
look
to
the
right
here
again,
you
see
another
concept
of
of
how
folks
would
measure
what
they
would
call
the
the
latency
of
of
of
an
ip
network
where
latency
here
includes
the
wait
for
the
end
to
end
path
versus
what
folks
would
call
the
d10
latency,
which
is
the
time
essentially
to
get
data
off
the
platform.
D
Then,
when
we
started
looking
at
not
just
waiting
for
the
end
to
end
path,
but
the
asymmetry
of
of
the
likely
links
where
you
may
have
a
very,
very
small,
for
example,
very
small
uplinks,
but
very
large
downlinks,
again
going
back
to
the
space
cases
where
an
orbiter
may
have
a
much
larger
dish
more
power
and
be
able
to
send
data
down
to
a
lander
or
back
to
earth
significantly
faster
than
the
lander
could.
Otherwise.
You
know
upload.
C
C
D
A
couple
of
features
that
you
need:
you
need
to
be
able
to
send
data
without
knowing
if
the
end
state
destination
is
online
or
not,
you
don't
want
to
start
re-transmissions
back
from
the
beginning
partially
because
of
the
disconnected
nature
of
these
networks
and
partially
because
of
the
significant
asymmetries
of
of
the
uplinks.
If
you
uplink
something
and
it
gets
somewhere-
that's
great.
You
don't
want
to
then
take
that
precious
low
rate
up
link
and
use
it
for
the
re-transmissions.
D
If
you
do
that,
then
your
endpoints,
perhaps
don't
need
to
remember
very
much
session
information
or
special
states
and
all
of
all
of
this
sort
of
boils
down
into
what
you
know
started
to
look
like
familiar
features
in
other
areas
like
asynchronous
text,
messaging
or
email,
and
the
interesting
observation
from
the
dtm
perspective
is:
how
do
we
get
that
down
into
a
package
that
is
small
and
efficient
enough,
that
it
can
run
on
very
resource
constrained
devices?
D
So
what
then
came
out
of
that
was
a
description
of
of
dtn
as
a
suite
of
protocols
and
applications,
and
this
is
what
is
considered
right
now
to
be
sort
of
the
core
set
of
concerns
that
that
are
being
addressed
now.
D
The
the
four
major
protocols
that
are
on
the
right
are
just
so
happen
to
be
the
four
documents,
three
of
which
have
have
gone
out
for
centers,
I
think,
are
waiting
on
a
a
ref,
a
missing
reference
and
then
a
third
related
to
security,
and-
and
these
are
the
bundle
protocol,
bp
version
7,
and
that
is
the
main
transport
protocol.
That
is
the
the
protocol
that
allows
for
these
extension
headers
for
carrying
additional
information
and
the
behavior
around
store
and
forward
operations.
D
A
security
protocol
for
securing
the
bundle,
in
particular
the
ability
to
handle
and
secure
payloads
separately
from
some
of
these
secondary
headers.
A
some
context,
security
context
to
provide
information
around
how
that
security
information
and
the
cryptographic
materials
they're
in
should
be
handled
and
then
because
bp
is
is,
is
considered
an
overlay
how
it
it
maps
to
the
underlays
that
are
carrying
it
and,
in
particular,
out
of
the
working
group.
D
But
there
are
plenty
of
terrestrial
uses
of
dtn
that
care
about
disruption,
but
otherwise
don't
have
long
signal
propagation
delays,
but
then
there
are
other
things
that
are
that
are
weighting
and
progressing
and
and
those
include
work,
one
quality
of
service
time
variant,
graph,
routing
in
particular.
The
ccsds
is
working
through
something
called
schedule,
aware:
bundle
routing
and
there
is
additional
work
on
what
it
means
to
do.
D
Key
management
in
these
kinds
of
very
disconnected
networks
and
a
look
at
network
management
from
a
from
to
include
more
deterministic
autonomy
in
the
system,
which
is
the
asynchronous
management
protocol
or
amp
things
that
are
not
particularly
considered.
Part
of
the
ecosystem
are
higher
level,
user
applications,
delay,
tolerant,
file,
transfer
or
messaging
or
or
that
sort
of
thing,
and
then
the
underlying
transport
mechanisms,
beyond
how
we
talk
about
them
in
the
convergence
layers
are
also
things
that
aren't
considered
part
of
that
suite.
D
So
we
we
start,
we've
talked
quite
a
bit
about
the
nasa
and
the
space
part
of
the
problem.
Dtn
has
the
the
focus
on
d10
included
many
different
folks
over
time.
My
my
understanding
of
the
history
is,
it
started
with
nasa's
concerns
about
interplanetary.
Networking
darpa
picked
it
up
for
several
years
and
and
worried
about
what
it
means.
In
highly
disrupted
environments,
the
ccsds,
the
consultative
committee
for
space
data
systems,
looked
at
and
started
doing
some
initial
standardizations
specific
to
space,
and
then
it
came
into
the
irtf
and
the
ietf.
D
A
dtn
research
group
was
formed
in
2002
that
was
chaired
by
kevin
fall
and
yorgoth,
and
its
initial
charter
pulled
from
the
initial
charter,
which
you
can
see
from
I
rtf4
concluded.
Dtnrg
was
the
observation
that
you
know:
non-interactive
asynchronous
messaging
was
important,
and
not
only
is
it
important
in
these
space
cases,
but
there
are
lots
of
different
networks
where
this
would
be
useful.
The
irtf
the
dtnrg
produced
14
rfcs,
four
that
were
notable.
They
were
all
notable
before
that
were
fundamental.
D
After
after
some
experimental
deployments
and
field
tests
and
lessons
learned,
a
working
group
was
formed
to
standardize
this,
and
that
was
at
ietf
91
and
the
initial
charter.
Large
parts
of
the
initial
charter
were
to
take
this
work
from
the
from
the
irtf
and
the
lessons
learned
from
field
deployments
and
then
update
these
different
documents,
and
so
you
know
update
rfc
5050,
which
was
bundle
protocol
version,
6
update,
6257
the
security
protocol.
D
You
know
provide
a
convergence
layer,
rfc
update
to
tcp,
and
that's
what
we've
done
and
that's
why
they
mentioned
we're
going
into
our
rechartering
discussions
now,
so
the
the
ones
that
are
in
the
editor's
queue
bundle,
protocol,
seven
security
and
tcpcl
version
four
and
then
another
that's
an
ad
evaluation,
which
is
a
security
context
to
work
with
the
security
protocol.
D
So
if
we
speak
just
a
little
bit
about
the
bundle
protocol-
and
you
know
the
first
question
always
is:
where
does
it
live?
And
sometimes
the
answer
is
wherever
you
would
like
it
to
live,
and
if
you
were
to
go
out
and
pull
images
off
the
internet,
as
I
did
to
create
this
slide.
You'll
see
a
couple
of
different
versions
of
this,
but
generally
a
bundle,
bundle,
agent
or
forwarder
is
something
that
that
lives
in
an
overlay,
overlaying
and
speaking
through
its
convergence
layers.
D
The
value
of
that,
of
course,
is
that
a
a
bp
instance
can
go
over
different
underlying
networks,
and
so
just
like
for
internet
transfers
and
what,
hopefully
is
a
very
familiar
simplification
of
of
tcp
networking,
where
you
don't
need
to.
Of
course,
you
know
terminate
tcp
at
every
node
and
tcp
talks
end
to
end.
D
If
we
put
a
bundle
layer
in
place,
the
bundle
layer
has
the
ability
to
do
some
storage
because
it
is
a
stored
forward
network,
but
also
it
can
sit
over
various
convergence
layers
to
include
the
point
where
perhaps
you
you
move
away
from
tcp
and
then
do
something
else.
For
you
know
a
to
bridge
a
tcp
part
of
the
network
with
a
non-tcp
part
of
the
network.
D
The
bundle
itself
is
considered
a
bundle
of
blocks,
so
everything
is
termed
a
block.
There
is
a
primary
block,
which
of
course,
is
a
primary
header.
There
is
a
payload
block
which
is
a
payload,
and
then
there
are
a
series
of
extension
blocks
and
you
can
have
sort
of
any
number
of
those.
The
the
primary
block
has
standard
primary
header
things
in
it.
It
identifies
the
bundle
and
particular
processing
options.
D
D
If
we
look
at
the
extension
block
mechanism
in
in
bp,
one
of
the
things
that's
interesting
about
it,
of
course,
is
that
you
can
define
and-
and
the
protocol
is
structured
to
allow
for
the
creation
of
of
new
extension
blocks
over
time
and
also
for
nodes
that
are
doing
processing
to
read
these
extension
blocks.
Do
whatever
processing
is
necessary
and
maybe
even
write
back
or
update
those
extension
blocks
or
add
new
ones.
So
it
is
not
necessarily
the
case
that
the
originator
of
a
bundle
is
the
only
bundle
agent.
D
That
would
add
an
extension
block.
Obviously
I
just
mentioned
before
something
called
the
prior
hop
block.
That's
something
that's
added
by
a
prior
hop,
so
you
could
accept
a
bundle
in
look
at
the
prior
hop
block.
That
is
there
remove
it,
add
your
own
and
send
it
along
the
way,
and
and
again
this
is
part
of
getting
to
that
operational
concept
of
not
relying
on
state
existing
end
to
end
but
being
able
to
update
it
in
the
network
as
you
go
and-
and
that's
essentially
what
we
talk
about
here.
D
The
value
of
course,
is
that
if,
if
you're,
able
to
synchronize
state,
end-to-end
and
end-to-end
could
mean
truly
message
and
and
or
maybe
source
to
some
initial
gateway
or
something
else,
then
you
know
you,
you
can
make
your
messages
smaller
and
just
simply
refer
to
sessions
as
you
or
session
state.
That's
that's
synchronized,
along
the
way.
D
If
you
can't
rely
on
this,
then
you
need
to
carry
all
of
that
information
with
you,
and
I
I
think
that
that
is
probably
one
of
sort
of
the
key
insights
behind
bundle
protocol
the
need
to
store
the
data
waiting
for
a
time
variant
path,
and
this
idea
that
you
can't
always
rely
on
your
endpoints
to
tell
you
what
you
need,
and
you
can't
always
rely
on
your
destination
to
know
everything
it
needs
to
know
to
process
you
from
that
perspective.
Again
we
talked
about
primary
blocks
and
payload
blocks.
D
What's
interesting
in
bpv7
is
that
the
the
primary
block
is
is
immutable,
so
it
can
be
signed
by
the
by
the
bundle
source
and
and
it
should
remain
unchanged
through
the
network
unless
it
is
fragmented,
in
which
case
new
new
bundle
fragments
are
created.
But
that's
not
the
original
bundle,
that's
a
fragment,
and
then
you
know
the
payload
block.
It's
always
the
the
last
block
in
a
bundle.
D
The
original
bp
version
6
had
some
ideas
of
extension
blocks
before
a
payload
and
extension
blocks
after
a
payload
to
help
with
the
the
the
understanding
of
very
large
bundles.
But
we
didn't
see
the
need
to
carry
that
forward
in
bp
version
7.
and
then
the
extension
blocks
in
general,
which
are
the
ones
that
live
between
the
primary
block
and
the
payload
block,
have
some
standard
information
in
them.
What
is
the
type?
What
is
the
unique
identifier
of
the
block?
D
If,
if
you
have
more
than
one
block
of
the
same
type,
existing
in
a
bundle
and
then
are
there
interesting
processing
options
associated
with
those
blocks?
So,
for
example,
because
extension
block
types
can
be
added
to
over
time,
you
may
you
may
find
that
not
every
bundle
agent
in
a
network
understands
every
block
type,
and
so
there
are
options
here
that
say
things
like
if
you
understand
this
block
type
process
it.
D
But
if
you
don't
understand
this
block
type,
just
pass
it
along
quietly
or
if
you
don't
understand
the
block
type,
then
that's
a
problem
and
remove
that
block
from
the
bundle
before
you
pass
it
along
or
if
you
don't
understand
the
block
type,
that's
a
big
problem
and
get
rid
of
the
entire
bundle
and
and
process
it
no
further
or
perhaps
hold
it
off
to
the
side
for
forensic
analysis
within
the
bpv7
spec
itself,
we
define
a
couple
of
blocks
that
are
are
useful
that
we
think
are
generally
useful
and
need
to
be
supported.
D
This
is
particularly
helpful
for
devices
that
themselves
have
can
keep
relative
time,
but
have
difficulty
keeping
absolute
time
and
then
a
for
for
areas
where
you
know
hop
count
is
still
a
a
very
useful
thing,
even
in
a
delay,
tolerant
network
for
for
to
avoid
routing
loops
and
things
like
that,
particularly
in
time
variant,
graphs,
carrying
hop
counts
and
and
hop
limits
may
also
be.
D
You
know
necessary
in
the
network
and
then
there's
a
another
set
of
specifications
called
the
bp
sec
or
the
bundle
protocol
security
protocol,
which
uses
two
additional
blocks
to
carry
integrity
and
confidentiality.
Information
and
I'll
talk
about
those
a
little
more
in
just
a
moment,
which
is
right
now,
because
it's
a
little
more
about
security.
D
D
The
first
was,
if
we're
having
different
kinds
of
information
in
a
bundle,
then
having
block
level
granularity
is
going
to
become
important,
because
now
information
that
normally
would
be
in
different
payloads
is
now
in
a
single
bundle,
and
we
may
have
to
treat
that
differently.
Perhaps
we
want
to
sign
an
extension
block
with
metadata
or
sign
the
primary
block,
but
encrypt
a
payload,
and
those
are
two
different
things
that
may
have
to
coexist
in
a
single
pdu
separately.
D
If
we
accept
that
different
nodes
in
a
network
could
add
extension
blocks
as
we
go
like
with
the
prior
pop
extension
block.
Well,
then,
the
node
that
adds
a
block
may
have
to
secure
that
block
and
that's
different
than
the
node
that
created
the
bundle
itself.
So
there
are
different
sources
of
security
in
a
pdu
and
then,
of
course,
because
of
those
first
two
things
you
will
have
different
security
policies.
D
If,
if
you
have
different
security
sources
in
the
network,
they
will
probably
have
different
identifications,
they
might
be
using
different
cipher
suites
or,
if
they're,
using
the
same
cipher
suite,
they
will
probably
have
different
keys
or
other
cryptographic
material
associated
with
those
cipher
suites.
D
D
Block
integrity
is
defined
here,
as
essentially
an
integrity
mechanism.
Over
plain
text
is
for
if,
for
example,
you're
using
signing
as
your
integrity
mechanism,
then
you
can
sign
plain
text
and
you
can
sign
multiple
blocks
at
once
and
it
can
carry
that
along
and
there
there
are
some
constraints
associated
with
not
having
circular
references,
if
you,
if
you
use
bibs
and
bcb's
for
your
security
and
bibs,
can
target
bcbs,
which
can
target
bibs,
which
can
target
bcbs.
That's
something
you
want
to
avoid.
D
So
we
had
to
put
some
some
some
constraints
there
and
then
a
confidentiality
block
is
defined
as
confidentiality
on
the
plain
text
and
integrity
over
the
cipher
text.
What
that
means
is
any
cipher
suite
used
for
the
application
of
confidentiality.
It
really
must
be
an
aad
cipher
suite
it
needs
to
carry
with
it.
D
You
know
you
know
additional
authentication
data
and,
and
it
to
to
include
being
able
to
do
things
like
cryptographically
bind
blocks
into
a
bundle
so
that,
for
example,
you
could
include
the
primary
block
of
the
bundle
as
part
of
the
authenticated
data,
along
with
the
ciphertext
that's
created
when
you
create,
for
example,
a
signature.
D
If,
if
we
then
sort
of
look
through
the
the
security
considerations
unique
to
dtn's,
there
are
certainly
a
lot
of
them,
obviously,
with
any
kind
of
store
and
forward
network.
There's
a
lot
of
concern
about
a
person
in
the
middle
attacks,
clearly
eavesdropping
and
working
on
things
out
of
band
and
offline,
the
the
concern,
of
course,
when
you
have
blocks
that
are
added
and
removed
from
a
bundle.
You
worry
about
modification
and
replay
and
then
anything
that's
time
variant.
There
are
concerns
about.
D
You
know
topology
attacks
as
well,
so
for
those
who
are
interested
in
this,
there
is
a
a
a
good
security
analysis
of
this
in
the
bp
sec
document
itself,
under
security
considerations,
where
we
talk
through
what
we
can
handle
in
inside
of
the
bundle
itself
and
then
what
can't
be
handled
from
a
security
perspective
solely
inside
of
the
bundle
and
would
need
to
be
taken
more
out
of
band
in
the
network,
but
not
in
a
particular
bundle
itself.
D
The
last
thing
I
wanted
to
mention
on
the
security
side
is
you
know?
When
would
you
use
the
bpsac
protocol,
you
know,
so
it
is
not
something
that
needs
to
be
used
all
the
time,
and
it
depends
of
course,
on
the
security
you're
trying
to
to
create.
So
if
you
want
security
at
rest,
then
having
the
security
as
part
of
the
protocol
data
unit
itself
certainly
helps
with
that.
D
It
is
nice
to
say
that
you
know
some
of
the
blocks
inside
of
a
bundle
are
themselves
encrypted
by
the
network,
and
if
the
network's
going
to
store
this
persistently
for
hours
and
days,
then
that
security
persists
and
you
don't
have
to
decrypt
a
bundle
coming
out
of
a
secure.
You
know
tunnel
and
then
re-encrypt
it
for
for
storing
it
locally
and
then
decrypt
it
off
of
the
local
drive
and
then
re-encrypt
it
for
pushing
it
down
the
next
tunnel.
So
you
can
save
some
of
that.
D
Interestingly,
obviously,
we
think
that
applications
will
provide
encrypted
payloads
when
the
applications
feel
that
that
is
necessary,
but
then
all
of
the
additional
extension
blocks
and
other
network
information
itself
will
need
to
be
encrypted
and
then,
of
course,
the
underlying
convergence
layers.
We
also
assume
provide
security,
but
since
the
convergence
layers
may
change,
as
the
bundle
works
its
way
through
the
network,
then
you
know
then
again
having
security
within
the
bundle
itself
is
a
useful
thing.
The
other
interesting
observation
is
that
there
are
probably
some
some
different
ways
of
using
this.
D
That
may
be
interesting
to
certain
security
operational
concepts,
namely,
if
you're
trying
to
create
secure
tunnels
in
in
networks,
but
they
may
want
to
overlap
if
you
use
security
solely
as
encapsulating
the
entirety
of
a
bundle
in
ways
that
don't
don't
secure
extension
blocks
and
payloads
separately,
then
it's
all
or
nothing
for
things
that
are
in
a
tunnel.
D
However,
if
you
wanted,
because
you're
carrying
different
information
to
have,
for
example,
integrity
over
a
primary
block
from
the
beginning
to
an
end
of
a
of
a
transmission
end
to
end,
perhaps
confidentiality
for
some
subset,
some
other
kind
of
confidentiality
for
another
subset
of
the
network,
this
becomes
impossible
to
do
if,
if
everything
is
treated
the
same
within
the
pdu.
However,
if
you
look
at
this
block
by
block
and
not
pdu
by
pdu,
you
can
start
getting
that
kind
of
behavior.
D
Then
the
last
thing
is
just
you
know.
There
are
many
many
studies
on
how
story
and
forward
in
general
and
bundle
protocol
in
particular
is
useful
in
you
know,
challenged
environments
and
how
we
get
data
through
here's.
Here's
a
one
from
2014
called
the
lunar
laser
communication
demonstration
that
nasa
had
had
run
and
it
was
just
to
to
show
the
value
of
optical
communication
and
and
how
how
we
are
proceeding
at
that
time.
D
D
D
So
there
was
a
dtn
demo
that
was
done
in
in
this
way
it
was
using
dtn
up
to
and
through
so
bent
piping
through
the
lunar
link.
I
don't
think
that
detain
was
actually
on
the
spacecraft
itself,
but
it
was.
D
It
was
providing
the
actual
date
of
handling
when
that
link
went
up
and
down,
and
one
of
the
things
that
they
found
in
particular
was
one
of
the
limiters
of
of
getting
the
data
through,
particularly
back
at
particularly
back
to
earth,
or
up
to
the
spacecraft.
Initially
was
clouds.
D
You
know
what,
with
they
called
the
all-natural
laser
com
link
limiter
and
what
they
found
was
that
you
know
dtn
worked,
you
know,
just
as
it
was
supposed
to
when,
when
things
were
good
delivery
went
through
just
as
expected,
bundles
were
sent,
that's
the
blue.
Bundles
were
received
back
again.
D
When
the
link
went
down,
then
they
didn't
get
any
of
the
receptions.
However,
once
the
link
started
to
come
back
up,
the
data
started
to
trickle
in
and
what
was
nice
about.
It
is
this.
This
essential
recovery
period
here
was
not
swamped
with
control
information,
trying
to
re-establish
a
sense
of
obsession,
thereby
losing
you
know
the
data
opportunities
to
control
information.
D
A
little
bit
of
control
could
be
in
extension
blocks,
but
then
the
rest
was
coming
in
as
data,
and
they
found
that
this
period
of
recovery
versus
other
things
that
they
had
experimented
with
got
more
of
the
user
data
down
faster,
increased
their
good
put,
and
and
for
those
reasons
nasa
came
back
and
said
you
know
we.
We
really
need
this
technology
for
any
time.
D
We're
doing
you
know
these
kinds
of
operations
and-
and
then
essentially,
there
were
also
things
here
where
just
from
optical
to
rf
rate
buffering
was
considered
valuable
to
them
as
well.
So
so
that
was
my
last
slide.
It's
a
little
bit
about
the
history
of
dtn.
It
came
from
outer
space,
but
it
has
application
to
any
kind
of
disruption,
certainly
link
disruption,
but
also
sometimes
priority,
prioritization
and
disruption
around
administrative
boundaries.
D
B
Well,
thanks
and
where
that
was
really
interesting
and
I
think
really
cool.
I
can't
I
mean
I'm
like
a
kid
when
I,
when
I
hear
about
this
deep
face
stuff.
So
if
any
of
you
are
super
energized
now
to
go
be
a
part
of
vtn,
you
have
to
wait
about
three
hours.
The
third
session
today
is
dtn
is
having
here
their
meeting
ipfor
to
ten.
Let's
open
up
the
queue
for
for
questions.
B
Okay,
I
see
a
lot
of
positive
comments
in
the
in
the
java
no
wants
to
come
to
the
mic.
So
I
I
have
a
question
so
just
because,
like
you
know
here
at
the
ad
level,
we're
working
on
creating
a
little
more
press
about
what
tsp
is
doing
and
also
because
I'm
personally
interested
like
what
has
like
to
what
extent
has
been
deployed.
Like
I
mean
obviously,
v7
is
pretty
new.
B
You
know
you
just
showed
this
demo
here,
but
like
are
any
like.
Are
any
probes
or
anything
that
have
gone
out
used
this
or
an
earlier
version
of
vtn
technology?.
D
So
so,
yes,
and
no
next
question,
no
so
the
yes
and
no,
the
the
the
issue,
particularly
on
the
space
side,
is
early
in
mission
formulation.
You,
you
really
need
to
have
the
standards
set,
and
so
there
is
we
we
are.
We
are
quite
and
keenly
aware
of
some
of
the
pressure
to
make
sure
that
bundle,
protocol
version
7
is
out
and
out
in
in
a
timely
fashion,
because
it
is
necessary
to
have
that
rfc
so
that
it
can
be
put
into
contracts
and
requirements
for
missions.
D
Emissions
won't
adopt
it
until,
however,
bundle
protocol
version,
6,
rfc
5050
for
a
similar
reason,
was
taken
and
standardized
by
the
ccsds.
The
consultative
committee
for
space
data
systems,
as
as
a
blue
book,
and
once
that
happened
missions
did
adopt
it.
So
nasa
goddard
has
a
large
mission.
I
think
it's
a
billion
dollar
mission
called
pace,
plankton,
aerosol
something
and
it
will
be
using
bundle,
protocol
version
six
and
what's
interesting.
There
is
by
using
it
on
a
spacecraft,
and
this
is
not
necessarily
for
delay
and
disruption,
but
just
efficiency.
D
You
you
don't
need
the
complexity
of
a
file
system
to
do
all
of
that,
and
so
you,
you
can
have
a
little
more
efficient
processing
if
you
have
a
bundle
store
instead
of
a
file
system.
So
I
I
I'm
really
anxious
to
see
whether
missions
start
seeing
those
kinds
of
benefits
as
they
go
through
their
deployments,
but
it
will
fly
on
pace.
D
We're
also
going
to
hear
in
the
dtn
working
group
about
an
esa
european
space
agency,
a
project
called
opsat
which
will
be
flying
both
bundle,
protocol
version,
6
and
bundle
protocol
version
7,
and
we
also
have
several
industry
folks
who
have
non-space
case
uses
of
dtn,
although
they
they
keep.
Some
of
that
private
until
they're.
Ready
to
you
know,
release
their,
you
know,
products
and
results,
and
so
on.
C
B
B
Okay,
so
I
guess
well
so
we're
you
know.
This
was
supposed.
We
asked
for
an
hour
session.
We've
got
two
hours
so.
B
We
really
hope
that
you
have
again.
Thank
you
thanks
thanks
to
edward,
for
this
talk,
which
I
found
super
interesting,
even
though
I
don't
have
to
read
all
the
again
docs,
and
I
hope
that
the
rest
of
your
110
is
productive,
we'll
see
you
at
111
and
hopefully
again,
zahad
and
I
were
being
gathered
on
town
a
lot
if
you
want
to
hit
us
up
about
any
particular
issues
more
privately,
so
have
a
good
rest
of
your
meeting
and
see
you
in
san
francisco
with
a
little
bit
of
hope.