►
From YouTube: IETF115-DMM-20221108-0930
Description
DMM meeting session at IETF115
2022/11/08 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
B
D
D
E
D
D
Document
is
this
meeting
is
governed
under
certain
rules.
Please
be
familiar
with
the
with
these
suits
and
before
we
don't
need
the
blue
sheets
anymore,
yeah.
We
want
the
note
taker,
please
any
volunteers.
C
D
Okay,
quick
update
on
the
document
status.
D
So
the
first
one,
the
working
these
are
the
working
group
documents.
First,
one
is
segment
routing
for
Segment,
routing
or
IPv6
for
mobile
user
plane.
This
has
finished
the
the
working
group
last
call
it's
with
the
area
director.
D
D
B
F
So
thanks,
this
is
the
a
fifth
revision
of
the
mobile,
a.
B
F
F
So
if
we
go
to
the
next
slide,
please
so
We've.
The
document
is
generally
very
stable.
We've
we're
really
working
with
addressing
the
comments,
and
you
know
basically
all
the
comments
that
we've
received
in
the
last
meeting,
so
I'll
just
go
through
this
I've
divided
into
four
sections.
F
Really,
the
major
comments
were
really
to
align
the
terminology
and
the
concepts
to
the
t's,
Network
slices
work
and
we've
done
a
lot
of
work
to
align
with
the
t's
framework
using
the
terminology,
the
concepts
and
even
working
with
the
folks
in
who
are
who
are
around
that
the
framework
draft
so
I'll
get
into
that
on
the
next
few
pages,
the
the
other
one
was
to
address
a
relation
to
the
3gpp
functions
and
we've
clarified
that
we're
we're
not
modifying
or
changing
any
of
the
3gpp
functions,
we're
only
relating
it
to
how
the
user
plane
is
or
the
transport
network
is
setting
up
the
slices
and
I
guess.
F
The
third
one
was
a
broad
comment
to
read:
to
have
the
text
in
the
draft
read
more
consistently
and,
to
that
extent
I
think
we've
we've
made
significant,
we'll
go
and
go
through
it,
and
you
know
we
made
it
made
changes
throughout
the
draft.
Actually
on
that.
So
let
me
go
to
the
next
page
please.
F
So
this
is
just
a
reference
to
the
abstract
section.
To
show
that
you
know
we
are
addressing
the
comments
that
were
received
so
fundamentally
the
changes
in
T's
terminology
we've
changed
the
terminology
to
use
customer,
so
the
3gpp
customer
to
an
ietf
slice
provider
with
an
intermediate
Network
in
between
which
is
the
specific
use
case
that
we're
addressing.
F
F
F
Basically,
we
were
using
an
sdn
controller
sdnc
and
the
TS
terminology
refers
to
it
as
a
network
controller
I
think
there
is
a
one-to-one
correspondence
but
the
specific
uses
of
network
controller
and
then
the
the
others
that
we
had
refer
to
it
as
a
transport
Network
function
in
the
5G
management
plane.
But
what
T
is
generally
refers
to
is
an
orchestrator
and
we've
called
it.
The
transport
Network
Orchestra
here
so
so
I
think
it's
pretty
well
aligned
now
in
terms
of
the
terminology
and
the
text.
F
Right
so
here
I
think
we're
getting
into
the
specifics
of
the
draft,
and
you
know
what
we
are
covering
in.
The
draft
is
that
this
is
a
scenario
where
there
is
an
attachment
circuit
in
between
the
3gpp
customer,
which
is
the
requester
of
the
slice
and
the
provider,
which
is
the
transport
ietf
transport
provider.
And
you
know
we
also
go
into
the
service
demarcation
points.
F
I
mean
where,
where
those
are,
and
so
if
we
go
to
the
next
sorry
I'm
going
to
the
next
politics
again,
we
clarify
the
tno
being
a
logical
entity
that
can
be
a
part
of
the
nssf,
but
we
don't
get
into
describing
what
it
is.
F
That
is,
you
know
in
3gpp,
and
then
we
also
clarified
how
the
UDP
Port
information
is
provided
from
the
slice
establishment
to
the
management
plane,
because
that
was
the
part
that
we
need
to
address
in
terms
of
how
the
how
they,
how
it's
populated
to
how
the
user
plane
works,
I
mean,
which
is
what
we're
describing
this
draft.
F
Yeah
I
think
it.
You
know
the
the
changes
were
in
terms
of
really
terminology
and
and
the
concepts
and
teas,
and
also
the
3gpp
related
aspects
to
how
it
works.
I
believe
that
now
the
we've
addressed
each
of
those
comments
and
also
made
a
thorough
change
in
the
draft
to
make
it
read
consistently.
It's
also
aligned
with
I
mean
so
tease,
is
actually
working
on
some
other
uses
of
the
slice,
and
this
becomes
it's
fully
aligned
with
that.
F
This
is
one
of
the
cases
where
the
the
the
service
demarcation
point
and
the
customer
requesting
it
are
separate,
and
so
it
is
it
they
have
other
cases
which
they
use,
Layer,
Two
and
other
things.
So
this
becomes
one
of
the
many
ways
in
which
you
can
configure
slices
and
I
think
it
is
ready
to
progress.
But
we
need
reviews
from
the
group
and
we'd
be
happy
to.
You
know,
address
comments
as
they
come
so
I
I'd
really
like
to
request
for
reviews
and
see
how
we
can
proceed.
D
G
Attention
from
cmsac
I
have
a
I
have
an
address
through
the
whole
details
of
the
draft,
but
I
just
wondering,
because
yesterday
I
was
thinking
one
thing
from
the
the
five,
the
3gp
5G
part
and
they
have
an
art,
slicing
and
access
and
then
from
the
X
that
the
genome
B
to
the
UPF
there
is
the
IP
network.
I
have
been
thinking
about,
like
you,
have
a
size
and
then
allocated
so
like
as
an
ssai
those
type
of
things,
then
how
are
you
going
to
map?
G
F
F
F
The
the
specific
one
that
we
are
proposing
here
is
to
use
a
UDP
Port
because
and
that's
in
addition,
we've
also
mentioned
that
in
the
document
in
in
the
draft,
because
when
you
have,
if
you
look
at
the
figure
on
the
right,
if
you
have
the
customer
ads
and
the
provider
ads
separated
by
an
attachment
circuit,
then
you
need
to
be
able
to
convey
that
via
those
IP
semantics,
so
that
is
covered
in
the
draft.
That's
so
that's
how
so
that's
the
user
plane
part.
G
And
no,
not
on
that
part
the
things
like
I
suppose
on
the
ginobi
at
the
moment,
toward
the
GTP
side
and
three
interface,
and
then
that
one
is
like
for
the
3gbt
is
Checker
overlay.
Well,
IP
is
the
underlying
here
you
I
assume
you
are
trying
to
provision
or
Define
a
IP
based
the
slides
well
to
match
the
for
the
NR
size
not
being
allocated
by
the
3gpp
side,
so
the
genob
at
that
moment
right
about
N3.
There
must
be
some
way
to
map
I.
F
Yeah
I
I
think
you're
mentioning
if
I
understand.
Let
me
see
if
I
understand
it
fully.
You
mentioned
that
in
3gp
page
the
GTP
connection
between
yes.
G
Exactly
ginobi
and
UPF
on
N3
and
then
but
the
IP
is
I,
assume
you're
trying
to
do
the
the
underlay
on
for
the
IP
side.
So
but
you
have
to
map
from
the
3gp
slides
to
the
IP
slides.
Otherwise
you
cannot
like
do
the
the
guarantees.
No.
F
I
think
we
I
think
it's
covered
in
the
draft,
but
I
advise
you
so
just
a
very
brief
explanation.
That
is,
that
the
the
GTP
is
configured
via
the
SMF
via
the
N4
and
the
N2
interfaces.
So
the
the
IP
address
corresponds
to
the
the
what
is
provisioned
via
GTP.
So
so
there
is
a
correspondence
there,
but
yeah.
But
but
please
comment
on
that
and
I.
E
D
Okay,
so
I
think
John
I
think
you
asked
for
the
reviews
right,
I
think
you
also
have
a
chair
review.
Finding
we'll
also
just
do
some
initial.
D
D
D
A
Oh
yeah,
so
the
the
DMM
srv6
user
playing
document
is
in
ITF,
less
call,
I
think
the
same
objection
about
it
being
proposed
standard
resurfaced,
Joel's,
concerned
about
interfering
in
3gp
architecture.
Space
I
had
thought
that
changing
the
some
sections
to
be
informational
might
have
addressed
that.
A
He
told
me
the
other
day
that
changing
the
entire
document
informational
would
address
it
that
just
changing
the
the
sections
would
what
did
not
somehow
so
I
have
reached
out
to
the
3gp
coordination
team
and
Lionel
from
CT
who's
I
think
is
the
is
it
what
are
they
called
chairs
or
repertoires,
or
everything
right.
A
So
you're
you're
presenting
in
the
next
coordination
meeting
after
this
about
the
status
or
sorry
about
our
inquiry
to
ct4
about
whether
or
not
it
it
conflicts
her.
It
is
in
Pages
upon
3gpp
architecture,
so
otherwise
I
think
there
have
been
generally
no
other
comments
in
the
ietf
last
call.
A
So
I
don't
know
what
happened
during
the
TeleCheck,
but
this
is
I
think
the
only
the
only
issue
to
be
resolved
one
way
or
the
other
so
just
waiting
to
see
how
this
plays
out
I
have
no
personal
preference
for
informational
versus
PS.
The
Iona
registry
affected
because
first
come
first
serve
so
I
mean
you
could
write
it
on
the
back
of
a
napkin
and
get
your
number.
So
it's
fine.
A
But
I
did
you
know
like
I
I
was
I
was
hoping
we
could
accommodate
the
the
wishes
of
the
authors
and
the
concerns
of
others,
but
maybe
there's
just
no
way
to
do
that
so
yeah.
Do
you
want
to
maybe
correct.
H
Thank
you,
yeah
from
the
3gp
side.
So,
first
of
all,
we
had
the
same
common
things
that
why
it
was
proposed
as
a
purpose
not
out
saying
that
it
was
at
least
at
this
time
only
for
information,
because
we
are
not
even
sure
that
how
it
would
actually
map
with
the
ongoing
work
within
three
gpp
and
so
on
so
I
think
it's
fine.
The
other
aspect
was
that
we,
so
it
was
requesting
to
for
some
review
from
3gp
and,
as
I
said,
the
ct4
is
the
main
group.
H
We
had
already
an
activity
on
that,
so
this
message
was
sent
to
3gpp,
so
I
don't
know.
If
anyone
will
comment
that
and-
and
my
point
would
be
for
you
to
to
know
what
would
be
the
next
step-
if
whether
it
is
informational
or
proposed
on
that,
what
would
be
the
next
step
for
for
this,
and
especially
with
any
coordination
with
the
3gp
candidate
aspects,
so
maybe
go
on
or
resume
the
studio
that
we
had
on
this
topic
in
ct4.
D
Yeah,
thank
you.
Thank
you
Lionel
for
that
feedback.
It
helps
I
think
from
the
chairs
point
of
view.
At
least
you
know
me
alone,
because
Saturday
is
a
quarter
so
me
and
from
Japan
side
I
think
we
made
sure
that
at
least
based
on
the
feedback
that
we
got
from
the
working
group,
we
try
to
make
sure
we
are
in
no
part
of
the
specification
says
we
are
overwriting
what
3gpp
says
in
23501
or
whatever
document
right.
It's
an
IDF
specification
completely
no
way
it
affects
our
impacts,
the
3gp!
D
D
I
I'll
just
give
you
some
perspective
on
the
draft
right
like
I've,
been
following
the
draft
versions
and
so
on.
So
there's
like
Parts
in
the
draft
that
actually
work
within
the
architecture
itself
right,
so
it
says
like
okay,
like
you
know,
you
have
the
SMF,
you
have
the
UPF,
and
this
is
how
we
can
put
other
functions
around
it
to
stop
the
connection
between
them
and
there's
Parts,
where
it
says
like
hey,
you
can
do
better
than
the
other
architecture.
I
I
think
that's
the
parts
that
have
been
moved
to
informational
because
it
kind
of
doesn't
fit
the
architecture.
So
that's
where
we
are
so
there
is
like
changes
in
the
draft
that
has
happened
like
since
the
last
time,
I
read
it
like
I
read
like
version
seven
or
eight,
or
so
now
it's
in
the
21.
or
something
right
like
so
it's
been
changed
a
bit,
but
we
need
to
still
discuss
it
and
see
how
things
go,
but
that's
the
perspective
so
there's
stuff
in
the
draft.
D
E
I
I
know
the
time
so
that
I
look
at
it,
so
so
hanu
so
usually
the
last
call
is
two
weeks
right,
but
since
we
had
an
idea
week,
it's
going
to
be
three
weeks.
I
think
it's
November.
23Rd
is
the
last
day
on
on
the
last
call.
D
You
all
right,
thank
you!
So
much
next
we
moved
the
Eric.
J
Okay,
so
this
is
the
follow-up
discussions
on
the
idea
of
integrating
a
n
and
UPF.
We
allow
ads
version
2
of
this
draft.
We
have
a
new
co-author
Kashif
Aslan
from
Red
Hat
Next
Step.
Please.
J
So
I
want
to
give
a
brief
review
of
this
basic
idea
in
5G.
Upf
are
more
and
more
distributed
and
close
to
the
Geno
BCU
for
and
in
the
meantime,
the
renting
decomposition
is
moving
the
CU
towards
the
core
side.
So
now
they
meet
in
this
Edge
data
center
they
become
co-located
and
often
if
they
are
implemented
by
software,
they
may
be
running
on
the
same
server,
but
still
they
are
separate
functions
per
current
3gp
architecture.
J
J
Wi-Fi
technology
gives
your
Wi-Fi
connection
to
a
router,
and
now
we
have
3gpp
technology,
okay
with
a
mobile
wireless
connection
to
a
router
and
the
rest,
it's
just
routing,
switching
for
ietf,
i3pe
standards
and
all
the
services
or
the
features
we
have
deployed
for
wireless
networks,
ipvp
and
evpn,
whatever
can
be
just
applicable
to
the
wireless
network.
So
that's
the
basic
idea
next
slide,
please,
so
the
work
will
need
to
be
done
in
3gpp.
J
It's
not!
It's
not
iitf
work,
but
we
are
using
this
DMM
menu
to
discuss
the
idea
hoping
to
to
get
feedback,
and
especially
from
mobile
operators,
to
see
if
this
idea
makes
sense.
If
it
does
make
sense.
If
the
operator
wants
to
see
this
deployed,
then
we
can
bring
this
to
3gpp
for
further
discussion
for
standardization
there.
J
So
this
is
a
picture
that
shows
the
idea.
Today
we
have
the
UE
and
connection
to
r-u-d-u-c-u
and
then
eventually
the
UPF
being
distributed
UPF.
That
means
that
the
data
Network
that
upfg
connects
to
also
needs
to
be
distributed,
and
that
means
that
Data
Network
needs
to
be
connected
together
by
VPN.
J
So
now,
if
you
click
just
click
yeah,
so
between
the
UE
and
CU,
we
have
the
ue's,
IP
or
ethernet
traffic
on
top
of
radio
stack
and
then
click.
J
J
J
Continue
so
now
that
end
up,
one
is
a
combination
of
cu1,
upf1
and
pe1,
and
up
two
is
a
combination
of
the
the
CO2
upf2.
Now
the
radio
protocol
stack
comes
from
ue1
to
end
up
one
directly
and
then
the
end
up
one,
just
that's
the
routing
or
switching
there
to
the
local
Data
Network
or
to
the
remote
VPN
site.
That's
the
basic
idea,
foreign.
E
J
J
We
talked
about
this
already
so
skip
the
next
one.
So
the
advantages
that
is
that
we
now
have
a
simplified
signaling,
an
open,
optimized
data
plan
before
I
counted
that
to
establish
that
entry
paneling
between
the
Geno,
BCU
and
UPF,
even
if
they
are
running
on
the
same
server
but
be
in
separate
function.
You
need
signaling
to
establish
that
tunnel
and
it
involves
seven
steps.
J
Four
Network
functions
three
signaling
interfaces.
Now
that
is
all
gone
and
also
before
you
need
to
the
genobc
you
need
to
put
on
gdpu
header
and
immediately
taking
off
by
the
UPF
that
is
running
on
the
same
server,
so
that
brings
in
now
that
is
not
needed
anymore.
That
brings
in
the
performance
Improvement,
especially
when
you're
doing
this
on
servers
using
software
implementation.
That's
a
big
win!
There.
D
I
So
I
think
I
think
other
than
the
things
you
should
be
brought
up
right,
I
think
like
and
Hano
actually
brought
it
up
as
well.
But
let's
say
you
hand
off
between
two
genot
bees
right
so
right
now
you
can
use
like
a
vertical
Handover
to
kind
of
use.
A
sideways
interface
like
X2
or,
like
whatever,
is
a
replacement
for
that
to
actually
send
back
to
the
same
UPF,
because
UPF
is
your
IP
point
of
presence
right
now?
If
you
combine
it,
then
your
IP
point
of
presence
is
going
to
change.
J
I
So
that
is
not
changing,
so
your
assumption
is
that
there's
going
to
be
multiple
RR
use
like
that
are
distributed
and
they'll
end
up
at
the
same
CU.
Is
that
your
base
assumption.
I
No,
it's
not
it's
not
that
it
doesn't
change!
You
need
to
state
that
has
an
assumption,
because
it
was
not
clear,
like
from
your
presentation
that
that's
an
assumption
right
so
like
put
that
in
and
the
second
thing
is
like,
if
you
look
at
like
how
the
SMF
talks
to
the
UPF
right,
how
the
session
set
up
how
the
quality
of
service
is
set
up.
It's
based
on
the
teid.
I
Okay,
yes!
So
now
we're
getting
rid
of
the
tid,
so
you're
going
to
come
up
with
a
whole
policy
control
architecture
for
this
right,
because
that's
gone
because
the
what
if
you
have
the
CU
directly
with
the
UPF,
there's
no
tunnels
to
differentiate
the
things
in
there.
So
this
is
input
to
you,
like
you
know,
just
think
about
it.
J
Thank
you
indeed,
that
needs
to
be
changed.
I
actually
mentioned
it
in
the
previous
Ito
presentation.
It
does
involve
changes
in
the
signaling
plane.
However,
we
are
talking
about
6G
I'm,
pretty
sure.
Even
if
we
didn't
make
this
change,
there
will
be
big
big
changes
coming
in
that
right.
So
indeed
the
changes
will
happen,
and
in
this
case,
if
it
does
happen,
it
brings
in
the
simplified
signaling
yeah.
F
Hi
John
from
future
way,
I
have
a
similar
question.
That's
how
new
and
to
an
extent,
about
Suresh,
asked
about
the
te
ID,
and
course
my
understanding
is
that
the
biggest
challenges
are
with
qos
and
how
that
is
sent
to
the
genome.
B
and
just
putting
it
together
as
one
function
will
not
change
those
Dynamics
and
it's
all
those
queuing
delays
and
so
on.
That
needs
to
be
optimized.
F
So
I
I
have
the
same
opinion
as
hanu
that
putting
it
together
is
possible
today,
so
combining
it
takes
away
the
flexibility
of
separating
it
while
it
does
not
address
the
queuing
related
aspects
of,
for
example,
if
you
have
qfis
that
are
mapped
into
specific
entities
in
the
genome,
B
all
of
those
issues
still
need
to
be
solved.
If
you
want
to
get
better
streamlining.
J
So
in
previous
ietf
we
I
have
a
slide
talking
about
the
class
aspects,
so
in
in
this
one
I
didn't
have
a
slide
for
that.
I
will
follow
up
with
you
to
see
if
what
I
thought
about
last
time
that
already
addresses
that
that,
if
not
I
will
add
more
article
discussions
there,
but
here
so
I
right
so
far.
This
is
just
a
review
part.
If
you
go
to
the
next
slide.
J
Foreign,
so
in
this
new
reversion
we
added
quite
a
few
discussion
points.
There's
following
slides
are
basically
for
those
discussion
points
one
by
one.
So
let's
just
skip
this
one.
Let's
just
go
to
the
specific
slides,
yeah.
D
But
I
did
notice
notice
the
NAT
here
so
in
60.
D
J
Okay,
so
we
already
talked
about
simplified
signaling
last
time
and
then
earlier
here,
I
added
this
red
text
there.
This
is
the
what
I
learned
from
an
operator
recently,
so
it
turns
out.
That's
we
not
only
need
to
establish
the
N3
tunnel
when
it
is
first
brought
up.
We
actually
need
to
periodically
refresh
the
signaling
to
maintain
it
turns
out
that
is
a
big
performance
hit
in
the
control
plane.
So
by
doing
this
getting
rid
of
the
N3
tunneling
when
it
is
not
needed,
we
also
reduce
it.
Remove
that
periodic
refreshes
entirely.
J
One
point
that
came
up
is
about
net,
so
an
operator
a
large
operator
may
have
many
regions
than
they
use
the
same
private
address
space
across
those
different
regions.
So
today
they
have,
in
that
case
they
have
a
net
Gateway
attached
to
each
Central
UPF
and
then
so.
The
UE
to
internet
traffic
goes
through
the
net.
Gateway
UE
to
UE
traffic
is
intravision,
does
not
go
through
that
you
you
eat
to
UE
traffic.
If
it's
interesting,
then
it
goes
through
the
net
Gateway
twice
right.
J
So
the
question
was
what
what
happens
if
you
do
use
integrate
the
end
up
in
that
situation,
and
the
answer
is
that
some,
even
before
you'd
have
the
n
up
as
long
as
you
use
distribute
UPF,
you
have
the
same
problem
that
you
need
to
solve
already,
and
the
solution
is
actually
the
same.
So
you,
basically
in
each
region,
you
have
many
distributed
upfs,
but
you
will
have
a
central
router
in
the
data
Network
and
that's
Central
The
Hub
router
will
have
a
Gateway
attached
and
again.
J
The
yoe
to
internet
traffic
goes
through
goes
through
that
that
Gateway
interregion
traffic
goes
through
two
gateways,
and
that
already
needs
to
happen
with
distribute
here
and
adding
the
replacing
the
integrating
the
UPF
and
Co
together
into
an
app
does
not
change
that.
It's
same
same
thing
will
still
work.
So
next.
J
What
about
ulcer
CEO
iupf
for
Mac,
so
for
Edge
Computing?
One
way
to
do
to
do
the
traffic
local
breakout
is
use
this
uplink
classifier
iupf.
J
That
is
today
with
5G,
even
with
Central
UPF
deployment.
You
can
do
that
already,
but
it
is
a
special,
an
extra
user
plane
function.
It
sits
in
the
past
of
N3
tunnels
and
it
exams
all
the
industry
traffic
and
then
it
intercepts
some
traffic
for
local
breakout,
breakout
purpose
reason
based
on
the
filtering
rules
signaled
from
SMF.
J
So
in
that
case
the
CU
puts
on
the
gtu
encapsulation
and
then
all
those
traffic
with
the
GTO
header
will
be
exempt
by
this
ulcer
or
IOP
app,
and
then
some
of
them
build
a
locally
erotic.
So
that's
a
waste
of
your
processing
power
that
is
already
avoided
by
even
by
distributed
up
here
and
and
replacing
that
distribute
UPF
with
end
up
does
not
change
that.
J
So
basically,
the
the
in
the
Target
scenario
for
the
am
for
the
third
n
up
where
you
have
distribute
UPF
collected
with
a
as
an
or
CU,
then
you
do
not
need
the
ulc
or
UPF
already
and
switching
towards
integrity
and
up
does
not
change
that.
J
What
some
people
are
worried
about
that,
and
now
the
an
does
more
work.
It's
it's
increased
the
burden
you
may
overpower
it,
but
notice
that
the
context
of
this
is
that
we
have
the
cu,
UPF
and
PE
co-located
in
the
same
Edge,
Data
Center,
whether
you
do
it
separately
or
integratively.
J
The
same
thing
need
to
happen,
no
matter
what,
whether
in
separated
functions
or
in
this
integral
functions
and
is
in
in
case
of
a
cloud
native
implementation,
whether
it's
the
work
to
be
done
on
the
A
and
UPF
and
up
does
not
matter
in
fact,
for
capacity
planning
purposes.
It
may
be
easier
because,
before
you
had
to
figure
out
okay
I'm
going
to
allocate
how
much
compute
resource
for
the
CU
function
and
I
need
to
figure
out
how
much
computer
resource
I
allocate
for
the
for
the
UPF
function.
J
C
J
And
another
question
is
now
the
a
needs
to
do
more:
it
becomes
more
complicated
for
that.
J
Keith
I
I
want
to
point
one
fact
today
so
today
on
the
CU
where
we
put
on
the
gdpu
header
and
send
it
to
the
UPF
that
is
actually
already
performing
the
PE
functional
identity.
See
think
of
this
put
forget
about
mobile,
forget
about
a
water
snack
for
one
moment,
just
think
about
VPN
technology
in
ietf
and
the
Wireline.
We
have
this
concept
of
hop
and
spoke
VPN
and
we
have
the
concept
of
per
prefix
VPN
label.
J
So
you
have
the
spoke
P
connecting
to
some
CE
and
you
can
you
can
advertise
per
prefix
label?
So
so
that's
when
you
get
a
traffic
with
the
pro
prefix
VPN
label,
you
don't
need
to
do
iplookup
anymore.
You
based
on
the
VPN
label,
you'll
know
exactly
which
CE
to
to
send
traffic
to,
and
that's
exactly
what
this
CEO
does
is
here.
So
the
gtpu
tunnel
corresponds
to
the
VPN
label
stack
today
on
the
CU.
J
J
So
today,
all
that
is
different
from
the
ipvpn
in
the
Wildland
case
is
that
we
don't
have
a
a
vrf
on
the
on
the
CEO
to
do
the
iplookup,
but
now
you
for
for
the
purpose
of
Edge,
Computing
or
local
internet
breakout.
We
want
to
do
the
local
routing
on
the
CEO
there
in
the
edge
data
center
there,
so
we
can
put
a
look
of
a
vrf
there
for
that
purpose,
and
remember
one
thing:
that's
today,
routing
functions
are
actually
being
commoditized.
J
J
I
think
this
is
the
final
slide
here.
So
one
question
I
got
was
isn't
this
against
microservice
architecture
because
with
microservice
you're
breaking
up
everything
and
here
you're
combining
everything
you
are
going
against
the
trend.
So
I
looked
up.
The
microservices
I
found
this
on
internet.
It
says
microservices
architecture,
style,
desk,
right
the
structures
and
application
as
a
collection
of
services
and
the
macro
service
action
enables
the
rapid,
frequent
and
reliable
delivery
for
large,
complex
applications.
So
to
me
it
is
about
decomposing,
complex
applications.
J
B
E
J
I
have
one
more
slide,
and
so
basically
I
I
bring
this
to
this
foreign
for
discussion.
I
appreciate
that
the
odd
comments
I
get
and
I
I
want
to
see
that
if
you're
interested
in
this
talk
to
your
colleagues
on
your
wireless
site
to
see
this
is
this,
it
makes
sense
to
them
as
well.
Thanks.
E
J
So
if
you
look
at
this
picture,
we
are
basically
just
combining
the
those
separate
functions
together,
so
whatever
magic
access
functions,
you
need
in
a
separate
architecture.
The
same
should
happen
here,
but
we
I
I.
Let
me
follow
up
with
you
offline
on
that
yeah.
Thank.
K
Thanks
a
lot
for
this
very
interesting
draft
and
discussion,
so
I
really
like
it,
but
as
I
said
it's
pretty
much
3gpp
specific.
It
discusses
footage,
functions,
reference
points
and
that's
so
correctly
said
well.
If
there
is
acceptance
of
this,
then
you
need
to
bring
it
to
three
gpp
so
for
the
ietf.
If
we
deploy
something
like
an
Anup,
do
you
expect
any
kind
of
changes
on
the
remaining
interfaces
which
have
not
so
spotted
here,
which
is
between
the
UPF
and
any
access
application
service
which
is
n6
right?
J
J
If
I,
if
I,
don't
even
get
support
from
The
Operators
or
from
I
from
the
people
who
are
familiar
with
and
friendly
with
IHF
Technologies
I
have
there
is
no
chance
I
can
I
can
I
can
get
it
accepted
on
the
3gb
side.
So
that's
why
I'm
talking
about
here.
Indeed,
the
work
will
need
to
be
done
in
3gpp,
but
I'm,
just
trying
to
First
socialize.
This
idea
among
people
who
are
familiar
with
and
friendly
with
the
ITF
and
Wildland
Technologies.
Okay,.
K
Because
some
some
early
aspects
of
DMM
could
be
brought
in
here
right
if
we
deploy
something
like
an
anode
and
we
consider
session
continuity
when
moving
from
one
end
up
to
another
one,
you
could
do
something
with
traffic
steering
unless
you
treat
the
previously
assigned
and
SM
anchor
and
remain
anchored
there
until
you
change
the
IP
address
of
the
user
equipment.
But,
okay,
thanks
for
the
clarification.
D
L
Thank
you
very
much
for
interesting.
This
question
just
comment.
When
we
see
the
the
structure
of
the
cgpp
organization,
we
can
see
the
land,
you
can
see,
it's
a.
We
can
see
the
city,
that's
the
very
fundamental
architecture,
actually,
so
all
of
the
ecosystem
follow
that
tactics
right
now,
so
your
proposal
seems
that
corrupts
that's
fundamental
architecture,
but
it's
really
interesting
for
the
architecture.
Consideration.
J
H
Lana
more
yes,
another
feedback
from
from
a
three
gpp
point
of
view.
Actually
it
would
be
seen
only
as
a
deployment
option,
so,
for
instance,
today
you
can,
you
can
deploy
the
private
mobile
networks
using
this
configuration.
If
you
want,
you
can
even
encapsulate
all
the
radio
parts,
it
will
be
a
black
box
for
them.
The
only
thing
that
will
matter
is
the
link
between
the
you
in
the
box
and
the
box
and
the
rest,
what
whatever
the
rest.
H
So
if
it
is
something
that
need
to
be
bringing
to
a
UTF,
it's
some
things
that
you
you
need
to
highlight.
What
needs
to
be
changed
according
to
the
existing
specification.
H
H
So,
for
instance,
we
have
already
a
cases
for
UPF
SMF,
co-location,
upfimf
collocation,
but
from
an
architecture
point
of
view,
it's
not
really
relevant
from
svgpp
we're
just
speaking
about
the
functionality,
the
signaling,
but
what
anything
regarding
the
deployments?
It's
really
for
the
vendor
side
or
for
the
operator
side.
J
Right
so,
for
the
co-location
indeed,
does
not
reinvolve
any
changes
at
all
but
I
by
integrate
them
to.
If
you
want
to
simplify
the
signaling
part,
then
that,
indeed,
does
involve
3dp
changes
and
that
indeed
needs
to
to
be
accepted
by
3gpp
for
it
to
to
happen
in
and
at
all.
So
that's
the
part
that
we
won't
need
to
bring
to
3gpp
after
we
get
support.
H
If
I
make
not
really,
if
you
said,
if
everything
is
in
a
box,
whatever
the
type
of
bugs
what's
happened
in
the
Box,
it's
only
relevant
to
the
vendor
or
to
zero
operator,
you,
you
don't
have
to
comply
always
as
a
signaling
defined
as
a
specification.
So
if
you
have
something
ending
between
the
CU,
UPF
or
UPF,
or
something
and
inside
the
bus,
it's
not
really
a
relevant.
H
And
it's
why
I'm
saying
so?
It
could
be
relevant
in
that
case,
but
from
a
3gp
point
of
view,
we
really
don't
care.
The
only
thing
that
would
matter
in
that
case
is
that
what's
come
from
the
DU
and
west
house
from
the
UPF,
if
everything
is
fine
there,
you
can
do
whatever
you
want,
for
instance,
I
have
example
where
we
are
using
a
mesh
architecture
and
so
on
machine
learning
in
a
box,
even
if
it
is
not
defined
by
3gpp,
but
as
long
as
you
have
everything
good
for
the
input
and
the
output.
H
It's
it's
up
to
to
your
implementation,
but.
J
Here,
I
I
should
have
drawn
the
AMF
and
SMF
in
this
picture,
because
today
there's
enter
signaling
between
AMF
and
CU
and
M4
signal
between
SMF
and
UPF.
That
part
can
be
simplified
so
that
you
don't
have
to
have
those
seven
steps
of
the
signaling
to
see
establish
a
tunnel
between
the
two
software
entities
and
running
on
the
same
server.
That
part
could
be
optimized.
G
And
Jeff.
B
G
I
Search
yeah
thanks
to
Angie,
so
I
I
think
the
feedback
you
should
take
like
at
least
like
from
everybody
like
you
know
like
what
Hana
said
like
Marco
said,
like
you
know,
John
said
and
Lionel
said
as
well
right.
So
this
is
possible
today.
So
if
your
thing
is
like
the
other
thing
should
not
be
possible,
I
think
you're
gonna
face
like
an
uphill
task
in
3gpp
right.
I
So
to
give
you
an
example
right
this
SMF
and
UPF
right,
so
they
got
an
N4
in
between
with
pfcp
there's
like
I've,
seen
like
hundreds
of
networks
where
they're
in
the
same
box
and
there's
no
externally
visible
info
interface.
They
use
some
kind
of
internal
things.
I
If
you
do
that,
the
same
way
as
an
implementation
like
combine
this
to,
have
your
implementation
be
more
performant,
that's
fine,
but
it
should
still
have
the
same
IES
on
the
N4,
and
if
it's
able
to
look
at
the
ID
and
map
it
to
some
internal
thing
that
you
do,
everything
should
work
as
I.
Think
that's
like
what
Lionel
is
pointing
to
and
I
think
100
days
as
well
before
to
say
this
is
possible
today.
I
So,
but
if
is
to
take
away
the
other
option
where
it's
like
not
co-located,
I,
think
that's
going
to
be
a
harder
sell
than
that,
so
I
think
that's
the
feedback.
You
should
take
from
this
discussion.
There's
nothing
saying
this
is
bad,
but
this
is
not
like
a
win
only
so
there's
losses
right
on
the
mobility
front.
You
you
lose
like
you
probably
do
like
more
handovers
than
needed,
so
there's
all
and
the
policy
control
changes.
J
Thank
you,
so
I
have
two
characters
one
here.
This
is
not
the
only
option.
The
end
up
can
still
do
the
N3
tunnel
into
a
separate
UPF
when
it
is
needed.
Second
of
all.
Secondly,
the
indeed
with
today's
separate
signaling
N2
and
then
four
signaling,
this
can
be
done
in
the
same
box
with
internal
optimization.
However,
I
still
see
that
the
signal
in
the
separate
signaling
could
be
simplified.
Instead
of
doing
seven
step,
signaling
involving
four
Network
functions
and
three
three
interfaces.
J
We
we
only
need
to
involve
a
two
Network
functions
and
two
steps:
I
think
that
is
a
optimization
that
we
I
would
like
to
see
accepted
and
since
3db
said,
but
indeed
this
needs
to
be
discussed
in
3dp
and
I'm
actually
going
to
tools
next
week.
Okay,.
E
D
Oh,
thank
you.
Jeffrey
I
think.
My
final
comment
on
this
I
think
good
stuff,
I.
Think,
like
all
the
feedback,
I
think
there's
some
merits
in
this
proposal.
I
think
the
key
thing
is
what
you
want
from
ietf
is
also
the
key
discussion
point
I.
We
cannot
touch
the
3gp
pieces
to
architecture,
but
if
they're
for
supporting
such
an
architecture,
if
you,
if
you
need
some
extensions,
some
protocol,
something
I,
think
that
would
be
a
one
very
much
relevant
discussion.
D
That's
one
point,
and
on
the
technical
front,
if
you
look
at
Enterprise
private
5G,
we
have
also
collapsed
functions
into
a
single
thing
and
in
the
process.
If
the
control
plane
is
outside,
there's
certain
optimizations
you're,
absolutely
right
right.
If
those
optimizations,
how
do
we
standardize
again?
You
need
to
go
back
to
3gpp,
but
yeah
I
think
more
discussions.
If
you
need
something
for
ETF,
welcome,
yeah.
J
D
D
D
Okay,
this
AI
service,
mobile
user,
okay,
yeah.
L
Hello,
this
is
saturu
I'm
present
here.
Some
update
on
SRB
mobile
is
a
plane
architecture
for
DMM,
on
behalf
of
the
my
course
thought,
from
the
SoftBank
accounts:
Cisco
the
Canada
dot
com
and
Intel.
L
So
this
is
the
update
from
zero
three
to
zero.
Four.
What
we
made
on
this
our
division
was
mainly
on
the
illustration
section.
You
can
see
the
old
zero
three
draft
we
put
just
illustration
of
the
year,
one
section
only,
but
we
structured
this
illustration
section
with
the
four
Subs
section.
The
first
one
is
how
to
accommodate
a
service
network
for
the
existing
mobile
network
service.
L
Second,
one
is
SRB
map
PE
deployment
at
all
Sr
domain
egress,
it's
just
what
I
presented
in
the
previous
IDF
meeting.
You
can
find
that
and
third
one
is
adding
direct
segment
with
new
service
map
PE.
This
is
also
I
presented
before
so
please
find
that
and
I
include
that
model
in
the
appendix
right.
L
L
Thank
you.
So
this
is
the
how
the
crops,
a
service
map,
P
deployment,
works.
On
the
left
hand
side.
This
is
the
control
plane
figure
how
it
works
so
on
the
control
plane
side
at
the
map,
controller
receive
the
system,
information
from
the
mobile
Mobility
management
system
and
then
map
controller
create
the
two
type
of
the
session
transform
route
for
each
system:
type
1
for
downlink
type
2
for
Uplink.
For
all
the
system
transform
the
route
received
at
the
map.
L
Pe
exists
on
the
the
border
between
the
Intel
work
segment
for
existing
mobile
mobile
search,
Network
and
the
course
side
of
the
map.
Pe
is
your
usual
SRB
sick
backbone,
not
special
on
the
demote
P.
It's
not
a
service
map
aware,
because
the
once
map
P
deceived
the
system
Transformer
route
from
map
controller
map
PE
in
advertise,
the
corresponding
loud
for
the
UE
as
a
usual
s3ppm
net
or
routing
information.
That's
you
have
control
Frame
Works.
On
the
user
print
view.
L
You
can
see
this
I
highlighted
only
on
the
map
aware
PE,
it's
usually
other
deployment
model.
The
owpe
accepts
the
rpe
connecting
to
the
UPF
need
to
be
map.
Aware,
but
in
this
deployment
model
the
ma
the
map
area
P
only
can
exist
on
the
side
of
the
interbox
segment
side
in
the
5G
architecture
case,
which
is
the
industry
interface,
that's
how
the
new
deployment
model
might
be
corrupt
map,
P
development
looks
like
and
how
it
works.
B
L
So
what
you
can
see,
we
added
the
deployment
model
in
the
illustration
section
and
we
will
continue
to
update,
make
much
precise
and
clarify
the
how
to
better
understanding
and
I
think
it.
We
could
reach
the
certain
level
of
the
maturity
of
these
documents.
So
please
review
it
and
if
you
are
testing,
please
inform
us
whether
it
will
be
time
to
adopt
the
RTA
working
group
document.
B
D
B
E
A
D
This
is
a
individual
ID,
not
a
working
group
document.
C
L
If
it
is
the
right
timing,
I
think
we
could
continue
the
the
work
in
the
individual
draft,
but
if
we
can
collect
the
enough
interest,
I
can
ask
the
other
option
document
or
DMM.
D
So
so
on,
this
I
have
one
question
now
to
Eric:
can
IDF
make
like
how
Margaret
made
recommendation
for
IPv6
prefix
allocations
right
back
in
2012
time
frame
or
earlier
right
for
PDN
sessions
right
so,
in
other
words,
making
recommending
3gp
to
instead
of
allocating
individual
IP
addresses,
do
a
prefix
allocation
in
the
same
manner
and
fashion
right?
Can
we
publish
some
of
these
architectural
recommendations?
A
I
mean
I
think
I
could
take
Joel's
Point
here
that
it
could
be
informational
like
this
is
a
way
you
could
do
it.
Okay,
I,
don't
I
I'm,
not
yeah
I'm,
not
fully
aware
of
all
the
sensitivities
about
how
the
uvp
feels
about
their
extra
I
know
that,
like
a
lot
of
people
run
a
lot
of
different
combinations
of
of
stuff,
not
everybody
runs
the
whole
I
know
all
of
the
interfaces
and
that
kind
of
stuff
right
I
mean
there's
lots
of
different
deployment
models.
L
All
right,
let
me
clarify
the
the
standpoint
of
these
document
of
the
architecture
document
so
yeah.
The
draft
currently
on
the
ID
rascore
is
the
the
protocol
and
the
under
under
the
5G
architecture,
to
be
followed
because
yeah
we
followed.
We
follow
that
architecture
and
study
that
protocol
under
the
5G
architecture
in
3gpp
as
well,
and
then
this
is
the
outside
of
the
3gpp
architecture,
but
this
is
just
programming
if
operator
want
to
use.
L
There's
no
nothing
happened.
Unless
the
the
map
controller
receives
the
session
information
from
the
existing
Mobility
Network,
the
list
of
the
part
of
the
network
network
is
totally
outside
with
the
3G
5G
architecture.
This
is
yeah.
Just
ITF
Network
follow
the
SRV
Sr
architecture,
so.
I
Does
it
impact
the
architecture
I
I,
think
kind
of
right
like
because
so,
if
you
look
at
the
so
Eric
just
to
give
you
a
brief
on
the
like
the
goal
of
this
right,
so
this
is
like
more
into
a
3gpp
operators
rather
than
3gpp
right.
So
the
the
idea
is
like
there's
some
kind
of
use
cases
like
you
know.
If
you
look
at
like
you
know,
fixed
Wireless
or
something
right
where
all
the
heavyweight
stuff
is
not
required.
I
So
this
is
like
recommendation
saying
like
hey
for
some
of
the
use
cases
like
like
you
know,
you
can
do
something
simpler.
It's
like
what
this
draft
is
trying
to
do
so
it's
it's
possible
that
it
says
like
hey.
Some
of
these
things
are
not
probably
needed
for
you
right,
I
think
we
need
to
find
a
sensitive
way
of
saying
that
right,
but
that's
what
this
is
you're
saying
like
Okay,
like
you
know,
if
you
have
like
best
effort
traffic
only
and
you
don't
need
accounting
for
it.
I
This
is
how
you
can
do
it
I
think.
That's
the
line
he's
taking
so
whether
or
not
that
like
infringes
that's
something
we
need
to
discuss
for
sure
right,
but
that
is
the
line
it's
taking
and
and
it
and
this
can
be
fuel
information.
So
there's
nothing
really.
That
needs
to
to
happen.
So
this
is
using
IDF
protocols
from
all
I.
Don't
think,
there's
any
new
protocol
development
required
for
this,
but.
I
We
don't
ask
a
question:
we
don't
know
it's
possible,
it's
certainly
possible
because
there
is
some
way
saying
like
hey
like
you
know,
but
should
it
happen
in
3gpp
right
because,
like
I'm
sure
like
3gpp
may
be
interested
in
saying
hey,
like
you
know,
for
these
use
cases,
maybe
this
is
better,
so
I
don't
know
the
answer.
We
cannot
answer
that
up
front,
but
I
think
like
keep
the
communication
lines
open
like
Lionel.
Is
there
like
Hunter?
I
Is
there
so
kind
of
keep
the
lines
open
and
Saturday
is
like
in
3gbp
too
so,
like
kind
of
get
I,
don't
know
for
like
release,
I,
don't
know
19
or
something
like
you
know,
putting
it
stage,
one
for
this
right,
I,
don't
know
like
study,
item
or
something
I
think
would
be
good
to
at
least
go
and
explore
the
problems
with
somewhere
as
well
like
in
parallel,
like
I.
Don't
think
he's
like
needs
to
stop
your
work
on
this,
but
yeah
all
right.
Thank.
D
Yeah,
okay,
that's
it!
Thank
you,
so
I
think
the
key
takeaways
I
think
you
know
I
think.
As
long
as
we
are
not
touching,
the
3gp
System
point
number
one
generally,
if
it's
informational
and
if
there
are
no
major
objections,
there
are
no
objections
from
3gpp
and
if
they
believe
IDF
is
a
good
forum
to
continue
doing
this
work.
I
think
that's
that's
something
to
vibrate
I!
Think
thanks
for
again
for
the
presentation.
If
there
are
no
other
comments,
we
oh
yeah,
please.
G
Work,
but
from
your
explanation
here,
I'm
seeing
is
an
obviously
significant
impact
to
the
3gbp
process
or
procedure
flow
here,
no
impact.
Okay,
let
me
explain:
okay,
because
when
I
think
we
should
reach
our
question
about
okay,
your
mob
controller-
and
you
say:
okay,
this
one
has
to
get
some
sort
of
information
from
3gp
5G
system,
so
I'm
trying
to
think
okay,
how
you're
going
to
get
it
and
then
you
can.
G
You
can
use
like
the
edge
Computing
scenario
to
kill,
like
AF
guidance,
those
type
of
things,
but
the
thing
is
to
expose
some
5G
system
information
to
our
third
party.
That
is
one.
The
first
thing
you
have
to
address.
G
The
second
one
is
the
things
like
the
I
think
you
have
to
get
a
true
way.
It's
not
just
like
a
one-way
from
5G
to
you
or
your
system
and
your
system
to
5G
here
so
I
think
this
type
of
things
and
then
suppose
you
do
use
some
sort
of
Make
Your
Mark
controlled
as
the
AF
and
like
AF
guidance,
and
it
goes
through
the
nef
and
PCF
those
type
of
things.
G
But
the
problem
here
is,
you
have
to
not
just
the
study
items
stage.
One
stage
two
is
is
really
that
is
a
bit
beyond
what
you
are
doing
right
now
here,
because
there
you
have
to
like
from
PCF.
You
have
to
at
least
that
you
tell
the
thing
involved
in
this
picture
here,
but
even
if
you
are
not
describing
like
the
ginobi
part,
the
UPF,
but
the
thing
is
they
are
on
the
data
plan
so
I.
Actually
you
know
you
have
to
think
about
that
thing,
especially
like
from
your
map
controller.
G
How
are
you
going
to
get
those
information
exposure
that
is
big
I
would
say
a
big
story
from
5G
system.
Thank.
L
You
thank
you,
I
think
I
would
recommend
to
release
the
the
document,
because
the
map
controller
just
expose
the
entire
API,
whether
using
API
or
not.
It
totally
depends
on
the
operator
decision
and
then
what?
If
the
CPP
want
to
utilize
that
interface?
That's
fine,
so
just
open
the
interface
for
for
one
to
this
underlying
of
the
network
and
mechanism.
Just
that.
J
L
It
could
be
whether
the
entity
on
this
HP
design,
whether
it
is
a
UPS
whether
it
is
SMF,
it's
totally
out
of
the
scope
of
this
document.
Still
the
I.
G
So
it
seems
like
the
mob
controller
or
Jeffrey
explained
here.
You
can
make
a
latches
like
SML
work
or
some
things,
the
steel,
the
things
like
you
have
to
introduce
that
one
I'm
not
sure
you're,
going
into
the
function
as
inside
the
SMF
or
we're
going
to
introduce
some
I.
Don't
think
you
have
any
I,
don't
think
you
can
introduce
one
network
function
so
that
that's
the
shot
is
for
the
AF
part.
Some
trusted
third
part
AF.
L
Let
me
clarify
this
is
actually
independent
from
any
specific
Mobility
management
system,
any
Mobility
management
system.
Can
you
tell
these
mechanism
not
depends
on
the
just
5G
not
depends
on
just
4G
or
3G
or
6G
p
mip
and
the
other
Mobility
management
appeared.
All
of
the
mobility
management
system
can't
see
the
some
programming
option
to
carry
the
RW
the
print
packet
over
the
srbc
network.
That's
the
idea
of
this
architecture
not
to
depend
on
the
specific
Mobility
architecture.
L
G
Okay
and
I
think
well.
Thank
you
for
that.
One
I'd
like
to
work
with
you
on
that
part
well
by
the
way
I
think
Jeffrey
mentioned
the
next
week
in
totals
they
are
going
to
be
a
big
meeting
on
3gbp.
Another
part
is
I.
You
keep
seeing
for
the
mob
controller.
I
think
that
one
is
the
true
way.
It's
like
you
have
to
get
some
exposure
from
5gs
and
also,
and
also
you
have
to
tell
something
to
5gs.
G
D
F
So
this
is
a
new
draft
on
media
header,
extensions
for
the
wireless
networks,
so
this
has
I
mean,
for
it
has
a
lot
of
Transport
layer
impact,
but
also
the
architecture
is
related
to
the
mobile
network
environment,
particularly
so,
hence
the
request
for
some
input
or
feedback
from
this
group.
So
if
you
go
to
the
next
place,.
F
F
F
F
Yeah,
so
the
motivation
for
this
I
mean
this
figure
is
really
showing
a
couple
of
things.
I
mean
one.
If
you
look
from
the
UE
to
the
wireless
network,
it's
showing
the
change
in
the
rate
of
that
the
wireless
network
provides
and
that
that
changes
rapidly
much
faster
than
an
end-to-end
congestion
control
can
signal
that
change.
So,
in
other
words,
I
mean.
F
It
delay
and
other
things
are
impacted
just
for
clarification
to
the
group.
The
iframe
why
the
iframe
is
important
is
because
other
frames
that
follow
like
a
p
or
a
B
frame
are
dependent
on
the
iframe
itself.
So
if
that
is
dropped,
randomly
I
mean
because
with
without
any
other
specification,
it's
going
to
be
drop
random
randomly
you
know
and
that's
not
a
good
situation.
What
we're
requesting
for
is
some
way
to
handle
this
kind
of
mechanism
and
I'll
get
to
that
in
the
next
page,
but
to
go
to
the
second
bullet.
F
Now
you
know
in
3gpp,
for
the
time
being,
we've
looked
at
RTP
and
srtp
which
expose
headers
which
carry
what
kind
of
a
packet.
It
is,
whether
it's
a
dependent
packet
or
an
independent
packet
where
it
starts
and
stops,
and
based
on
that,
you
can
classify
these
packets
and
give
information
to
the
radio
scheduler
to
act
in
a
specific
way.
F
But
once
you
go
to
something
like
HTTP
3
this
all
of
this
information
is
lost
and
I
suppose,
even
with
RTP
cryptex,
you
know
all
of
this
information
is
going
to
be
lost
and
the
scheduler
does
not
have
the
ability
to
make
any
informed
decision,
and
so
it's
going
to
do
random
random
decisions
on
topic.
So
that's
the
problem
that
we
face,
and
so,
if
you
go
to
the
next
page,
we'll
cover
the
what
kind
of
metadata
we
would
like
to
get
from
the
application
and
then
the
how
we
want
to
transport
it
also.
F
So
you
know
the
metadata
is
obviously
very
sensitive
information
and
this
would
be
between
two
trusted
endpoints
in
the
wireless
network
and
the
application
server.
So
it's
not
exposed
data,
that's
sent,
you
know
like
dscp
or
something
on
the
wire.
It's.
F
We
expect
that
it
will
be
handled
in
a
secure
way,
and
you
know
between
the
two
endpoints,
but
the
main
data
that
is
required
is
not
to
encode
or
decode
the
packet,
but
rather
to
handle
it
in
the
radio
network,
and
the
radio
network
would
perhaps
require
these
three
at
least,
and
hopefully
only
these
the
priority
or
importance
level
of
a
packet
or
a
series
of
packet
that
belongs
to
that
same
group
like
an
iframe
and
I.
Think
I
mentioned
the
example
earlier
itself.
F
So
if
there's
a
congestion,
even
if
it
is
discarded,
the
application
will
have
to
resend
it.
So
that's
not
a
situation
we
want
and
if
the
network
can
handle
it
better
to
where
it
is
sent
in
the
first
place,
then
the
application
performance
and
everything
is
improved
in
in
a
better
way.
You
know
so
there
are
these
dependencies
that
and
importance
that
is
being
addressed
here.
The
second
is
Packet
burst.
If
the
scheduler
knows
how
much
I
mean
it
looks
like
these
are
heavy-tailed
applications,
I
mean
the
the
packets
arrival
rate.
F
So
if
this
information
is
provided,
for
example,
how
big
that
burst
is
then
the
scheduler
can
prioritize
a
change
resources
to
be
able
to
handle
that
burst
in
in
the
right
way.
You
know
by
it
cannot
create
resource,
but
it
can
handle
it
can
re-prioritize
and
handle
these
in
a
better
way,
and
the
last
is
with
respect
to
delay
budgets.
F
If
it's
known,
as
you
know,
some
are
not
delay
critical.
So
since
there
is
I
mean
the
link,
changes
go
up
and
down
it.
Could
you
know
re-prioritize
aware
some
packets
that
have
more
of
a
delay
budget
is
delayed
to
when,
when
the
resources
come
back
up
again-
and
you
know
during
the
time
when
there
is
only
very
little
budget
available,
then
those
with
a
very
short
time
delay
are
sent
along.
So
those
are
the
three
aspects
that
we
think
are
essential.
F
F
This
is
about
the
transport
of
the
metadata
itself,
and
you
know
there
are
three
options:
I
mean
that
you
know
this
is
not
something
we've
come
up
with.
This
is
something
that
the
3gpp
study
has
looked
at,
and
you
know
there
are
these
three
options
that
that
look
interesting,
but
each
has
a
problem
of
his
own
or
advantages
and
disobeyances.
You
know
media
over
quick
extension.
F
If,
for
example,
if
this
transport
I
mean
if
the
3gp
Network
looks
as
a
relay
then-
and
it
also
transports
this
metadata,
then
you
know
that
would
be
one
option.
But
then
this
is
restricted
to
http
3
data,
but
you
know:
we'd
have
to
deal
with
RTP
and
http
3.
F
UDP
options,
on
the
other
hand,
will
cover
all
these
cases,
but
then
we
have
to
consider
how
we
Expose
and
get
this
information
for
the
UDP
option
to
transport
it
along
and
then
there's
mask
encapsulation
which
avoids
the
need
for
major
standardization.
But
then
you
incur
a
lot
of
overhead
in
terms
of
the
UPF
behaving
like
a
proxy,
and
you
know:
encrypting
I
mean
creating
a
mask
tunnel
and
getting
it
back
to
just
get
the
metadata.
F
So
each
of
these
has
some
advantages
and
disadvantages,
and
you
know
we
need
to
find
the
right
trade-off,
handle
privacy
concerns
and
make
sure
that
there's
a
fair
way
to
get
this
information,
but
I
think
what
we're
finding
is
that
this
information
would
be
very
helpful
and
we're
looking
for
how
we
can
handle
this
in
ITF
I
mean
this
is
obviously
over
the
n6
or
the
IP
network
to
the
3gp
Network,
and
so
this
is
this
is
what
we're
looking
for.
F
If
we
go
to
the
next
page,
I
think
I'm
only
summarizing
it.
So
I
think
you
know
I
think
if
the
problem,
the
problem
is
essentially
to
handle
those
variations
in
wireless
networks
and
get
the
metadata
how
to
handle
it
with
encrypted
and
non-encrypted
media
packets
and
how
to
transport
that
information
welcome
any
comments
and
feedback.
N
From
Huawei,
do
you
have
any
quantity
results
that
how
how
much
increment
can
bring
to
the
to
the
video
query
if
you
use
this
kind
of
advanced
scheduler.
F
Yeah,
no,
we
don't
have
any
quality,
I
mean
or
qualitative
information
on
that
I
mean
more
or
less
as
qualitative
information,
which
is
that
the
current
approaches
are
lacking.
There
is
significant
amount
of
work
in
3gpp
by
various
companies.
You
know
so
it's
a
whole
study.
That's
been
running
for
a
year
which
includes
the
major
you
know
component
vendors
in
Ryan,
including
Huawei,
Nokia,
Erickson
and
others.
F
You
know
so
they
all
are
engaged
in
the
discussion
and
feel
the
need
to
do
it
and
it
is
being
addressed
for
RTP
and
srtp.
What
we're
now
bringing
up
here
is
how
to
handle
the
the
issue
for
when
you
have
encrypted
information.
And
then
what
do
you
do?
You
know
you
don't
have
this,
so
the
the
the
metadata
that
we
proposed
here
is
what
has
been
identified
in
the
study.
It's
not
what
we've
come
up
with
that
metadata,
it's
how
to
handle
the
it
for
encrypted
packets.
N
D
C
D
You
know
doing
their
study
in
the
xrm
study,
that's
very
specific
to
their
access,
bringing
it
here.
I
think
we
can
potentially
apply
to
other
radio
Technologies
and
maybe
even
non-radio,
Technologies
I.
Think
potentially,
let's
say,
there's
a
DOCSIS
transport
right.
If
it
sends
this
metadata,
maybe
on
the
scheduler.
Maybe
how
we
manage
use
this
information.
Maybe
we
can
improve
the
system.
I
think
that's
a
theory,
that's
a
thesis!
So
any
feedback.
Would
you
appreciated
yeah.
M
M
You
know
you've
definitely
seen
people
like
Netflix
get
into
fights
with
people
like
Comcast
about
you
know
who
should
drop
who's,
packets
and
so
on
and
who
should
pay
home
so
I'm
kind
of
wondering
whether
you
it
seems
like
you
ruled
out
anything
that
acts
at
the
IP
layer.
But
you
know
the
SCP
bits
or
something
like
ecn
like
moving
Easy
Like
Making,
specifying
ecn
for
quick.
All
of
that
stuff
seems
like
it's
a
much
easier
cell,
because
it's
outside
the
encryption
so.
F
Right
I
agree
that
there's
there's
clearly
a
problem
with
how
to
establish
the
trust
between
the
yeah.
That's
something
that
we
have
to
handle.
What
we
we
find
that
the
l4s
and
other
ecn
can
help,
but
not
to
the
extent
so
we
need
to
find.
Maybe
this
is
something
we
need
to
explore
and
to
answer
Lawrence's
question
in
a
little
more
detail.
Maybe
we
can
have
the
application
server,
provide
the
specific
metadata
in
such
a
way
that
it
is
not
leaky.
F
You
know,
and
that
may
be
the
challenge.
I
mean.
What
is
it
willing
to
disclose?
I
think
that's
a
key
part
of
something
they'll
have
to.
D
Do
yeah
I
know
just
I
think
to
Lorenzo's
comment.
I
think
is
somebody
in
you
know
with
this
matter
at
all,
will
they
be
able
to
correlate
the
flow?
Will
they
be
able
to
identify
the
type
of
flow?
I?
Think
that's
a
question.
All
we
are
saying
is
it's
an
iframe
or
a
p
b
frame
or
a
p
frame?
What
can
one
possibly
do
with
that
information?
F
E
G
This
is
legitimate,
legitimate
problem
for
sure,
but
if
you,
since
you
keep
talking
about
the
5G
system
as
the
example
here
so
I
try
to
understand
one
thing
you
have
all
the
metadata
is
important
and
then
you
think,
okay
suppose
you
may
face
some
challenge
about
encryption,
so
encryption
for
the
data
player
and
you
have
a
metadata.
The
information
about
your
metadata
has
to
be
provisioned
to
the
5G
system.
G
So
even
after
that,
we'll
still
be
we
used
to
be
fixing
the
challenge
about
the
encryption,
the
first,
the
second
one
here
is,
like
you,
have
the
other
kind
of
metadata
and
then
this
information
has
to
be
some
sort
of
converted
and
we
provisioned
into
the
5G
system
right.
So
this
is
legitimate
but
I'm
thinking
how,
in
the
background
of
5G,
how
I'm
going
to
apply
this
one.
F
Okay,
so
let
me
take
that
second
part,
first
yeah
and
say
that
in
the
5G
there's
already
specific
I
mean
not
specification,
but
studies
that
have
reaching
conclusion
on
how
to
transport
that
information
from
the
UPF
to
the
radio
side.
So
that's
essentially,
why
extensions
to
either
the
GTP
or
header
or
by
using
multiple
QRS
flows,
so
that
part
is
being
handled
it's
specific
to
3gpp
and
that's
why
I
did
not
bring
it
here,
but
it
is
being
proposed
and
there
are
two
models
currently
in
contention.
F
You
know,
and
one
of
them
will
be
picked,
but
both
will
provide
the
3gpp
radio
with
how
to
qualify.
You
know
which
flow
is
more
important
than
to
prioritize
the
drops
and
so
on
for
the
RTP
and
srtp
cases.
But
now,
when
we
come
to
as
we
go
forward,
we've
got
to
look
at
this
encrypt
report,
which
is
which
is
what
we're
looking
at
here,
and
you
had
a
question
on
that
which
I
may
have
missed
me.
Yes,.
G
Talking
about
the
encryption,
so
I'm
your
GDP,
and
if
you
look
at
the
you,
have
the
IP,
udb
GDP
and
then
beyond
it
in
the
control
plan,
data
has
been
encrypted
so,
like
I,
forget
a
lot
of
information
but
like
iframe
P
from
B
frame
and
those
type
of
things,
you
may
be
able
to
send
the
RTP
extension
header
to
know
some
sort
of
information
discount
ability
importance.
Are
you
not
be
able
to
look
at
which
one
is
more
important,
I
or
less
important,
P
or
B
other
kind
of
things
right.
F
Actually,
we
don't
want
to
be
able
to
decode
all
of
that,
so
essentially
there,
the
scheduler
needs
very
little
information.
So
what
you
mentioned
really,
is
it
discardable
or
is
it
independent
or
is
it
not
one
of
those
you
know
so
based
on
that
that
that's
really
the
basic
information
and
that
importance
really
so
that's,
which
is
already
there
in
the
RTP
headers
now
I
mean
srtp,
header
extension
structure.
So
that's
the
kind
of
information
we
want
and
also
where
it
starts
and
where
it
ends,
because
we
don't
want
to
drop
in
between.
F
So
all
of
that
is
already
there
and
the
RTP
headers
now
and
if
that
is
available
in
some
way.
For
you
know
the
yeah.
M
If
you
give
those
bits,
semantics,
you're
kind
of
taking
away
the
ability
to
of
those
folks
to
ex
you
know,
experiment
with
what
works
best
for
their
users
right,
so
they
may
want
something
that
is
like
kind
of
deliberately
vague,
like
the
SCP
or
ecn
or
whatever.
It
is
that
we
want
to
specify
so
that
they
can
actually
figure
out.
F
So
can
I
follow
up
and
ask
if,
if
that
would
be
something
that
application
mean,
we
really
realize
that
applications
should
be
in
control
of
this
whole
process
as
to
what
is
important
or
not,
and
so
on
so
I
wonder
if
I
mean
without
the
applications,
trust
and
its
needs.
F
D
D
D
Now,
in
the
same
manner
and
fashion,
can
we
bring
a
structure
and
some
semantics
for
device
identification.
I.
Think
that's
the
The
Proposal
like
if
you
look
at
the
4281
right,
I
think.
E
D
Along
the
same
lines,
next
slide,
please.
So
let's
talk
about
the
use
cases
today.
If
you
look
at
the
identifiers
that
are
present
on
the
device,
there
is
a
on
the
interface
level.
You
have
a
MAC
address,
yeah
at
a
device
level,
you
have
a
serial
number
or
IMEI
or
Pei
in
the
5G
system
or
on
the
cellular
subscription
point
of
view,
there's
a
MC
or
but
the
question
is
which
one
can
be
used
as
a
device.
D
Identifier
I
think
that's
the
semantic
that
is
missing,
so
you
clearly
are
use
cases
where
you
know
we
need
to
come
out
with
a
format
and
structure.
That
is
one
thing
and
also
I
think
we
want
to
bring
in
some
cryptographic
relation
because
I
think
there's
some
threat
related
issues
around
that.
So
next
slide.
Please.
D
Yeah,
oh
I,
think
if
you
look
typically
in
Enterprise,
aha,
my
Enterprise
now
I
and
case
one
or
even
bringing
two
devices
an
iPhone
and
iPad,
but
if
the
identity
is
the
same
now,
how
can
the
access
network
you
know
apply
any
device?
Specific
policies,
I
think
that's
the
semantic
that
is
missing
right
earlier
it
there
was
an
extensive
use
of
Mac
addresses,
but
with
RCM
with
Mac
randomization.
You
don't
have
that
identifier
anymore
right.
So
now
the
question
is
you
know
what
is
the
alternative
to
that?
D
The
other
use
cases,
let's
say
Enterprise
has
both
5G
and
Wi-Fi.
I
can
do
in
handles
now,
if
I
bring
in
two
devices,
how
does
the
device
know
that
yeah,
it's
a
still
the
same
user.
My
identity
is
the
same
I'm
using
the
same
identity
credentials.
But
what
is
my
device
identifier
so
that
the
network
can
perform
whatever
handovers
or
permit
the
Handover
or
do
session
continuity
thing
right
so
again
we
need
some
semantic
for
device
identification
next
slide.
Please.
D
D
Rules
I
think
you
know
yeah,
you
know,
let's
assume
we
use
some
stable
identifier
with
some
somehow.
Let's
say
we
use
IMEI
as
a
stable
antifa,
but
the
thing
is
with
the
gdpr
rules.
Now
I
I
don't
want
to
expose
the
same
identifier
in
every
Network
right,
potentially
because
somebody
can
do
traceability
so
now
the
question
is:
can
we
come
out
with
this
structure
and
semantics
where
the
antifa
has
a
relation
to
the
access
network?
D
Next
next
slide,
please
so
I
think
the
proposal
here
is
coming
out
with
a
structure
and
semantics
where
the
device
amplifier
is
generated
based
on
some
cryptographic
terms
right,
maybe
there's
a
public
key
private
key
pair
and
we
use
some
Access
Network
identifier
and
some
auxiliary
parameters
based
on
that
kind
of
commodity.
The
structure
that
way
the
identifier
is
a
binding
to
the
access
network.
D
That
is
that
way
when
I
present
that
identifier
to
the
network
network
knows
yes,
you
know
I'm
able
to
I
know
that
this
identifier
is
for
this
network
and
I
can
identify
the
device.
So
this
is
you
know
the
thinking
here.
One
I
think
I
see
applicability
potentially
may
be
useful
in
many
environments,
one
more
slide
and
we
close
it.
D
Yeah,
yeah
I,
think
the
identifier
generation
how
we
generate
and
the
what
are
the
elements
that
we
use
for
the
identifier
construction
and
finally,
we
should
be
able
to
Signal
this
in
radius
and
E
extensions
and
other
things
all
right.
We
Define
some
identifier
for
that.
Some
attribute
to
radius
attribute.
B
D
Yeah
and
how
the
network
validates
the
Enterprise
I
think
you
know
that
also
I
talked
about
it
so
I'm
trying
to
see
if
you
can
publish
some
document
here
along
the
lines
of
now
document.
H
You
yeah
it's
more,
it's
just
a
question
time
to
time.
You
need
the
device
identifier
to
be
able
to
perform
some
configuration,
update
and
so
on.
So
in
that
case,
if
you
are
using
something
that
will
be
encrypted
encrypted,
so
how
you
will
time
to
time
you
will
have
to
they
encrypted
or.
D
So
so
the
identifier
is
generated
based
on
some
cryptographic,
key
pairs,
I
think
that's
one
thing,
but
the
access
network
will
be
able
to
you
know:
access
network
has
The
the
device,
identifier
right.
It's
able
to
decode
that
I
think
it's
a
see.
The
key
thing
is
the
endpoint
can
assert
that
I
am
the
owner
of
the
Dos
amplifier
because
of
the
private
key
associated
with
that
and
the
network
can
value
it.
Yes,
you
are
the
true
owner
of
that.
D
D
E
K
D
Super
you
said:
yeah
yeah,
yeah,
yeah,
see
Sufi
is
a
subscription
identifier
right
now.
The
question
is:
if
I
my
device
has
both
the
radio,
Technologies,
Wi-Fi
and
private
5G,
that
I
can
use
on
the
Wi-Fi
link
or
something
else,
I
think
that's
a
question
right
super
is
so
very
much
specific
to
the
this.
The
SIM
card
right
so
yeah.
H
E
J
The
use
case
actually
started
here
about
mobile
user
print
Transportation,
so
in
5G
between
the
CU
or
genob
and
the
UPF.
There
is
this
gdpu
tunneling
in
Street
Harmony,
that
is
over
an
IP
VPN.
We
refer
to
that
one
as
N3
VPN.
In
this
document
we,
the
ipvp,
is
used
so
that
a
converged
transport
infrastructure
can
be
useful,
both
entry
and
all
kinds
of
other
transportations.
So
I
have
a
picture
here.
J
The
genobi
is
put
on
the
GDP
header,
UDP
header,
mpv6
header
and
gets
to
the
n3brf
and
then
depending
on
whether
the
transport
is
mpospace
or
srb6,
based
we
put
on
a
label
stack
or
srv6
header,
plus
the
original
Ip
header,
UDP
header
and
GTP
GDP
header,
okay,
so
the
other
end
and
the
PE
D
removes
the
label
stack
or
srv6
header
you,
you
get
the
IP,
basically
or
UDP
header
and
GDP
header
Panic
as
the
UPF.
That's
how
traditionally
it
works
next
slide
please.
J
So
this
is
what
we
call
the
mpos
or
srv6
transporting
GTP
the
drafts
srv6
mobile
user
print.
That
draft
is
basically
replacing
GDP
with
srv6
and
based
on
the
M4
N2
signal
signal.
Gdp
parameters
that
is
under
the
hood
does
not
require
certificate
changes
and
that
replacement
could
be
between
the
network
functions
like
between
genob
and
UPF,
or
it
could
be
just
between
the
gateways
attached
to
those
functions
in
in
the
Gateway
case.
J
This
is
a
acceptable
and
preferred
by
some
operators,
and
they
they
like.
They
accept
this,
because
all
the
elements
are
under
their
own
control,
so
they
are
fine
with
doing
that,
and
the
advantage
of
this
is
that
you
get
the
traffic
against
steering
cavities
for
SRT
or
sfc
purposes,
and
you
also
get
bandwidth
savings
because
you
no
longer
need
the
IPv6
header,
your
depend
or
HTTP
header
anymore.
F
J
J
Yeah,
so
this
is
about
a
service,
is
replacing
GDP
and,
as
I
show
in
this
picture,
I
want
to
point
out
another
option
for
The
npos
Operators,
if
you're
not
using
srb6,
and
if
you
want
to
continue
to
use
mpis,
you
can
do
similar
things.
So
here
you
replace
that
srv6
header
with
the
MPS
label
stack.
Oh,
that's!
All
you
still
get
a
SRT
sfsa
is
a
benefit
that
srv6
replacing
GDP
gives
you
Additionally.
J
Just
a
GDP
payload,
basically
yeah,
so
in
the
srb6
replacing
GDP
case,
the
tid
and
other
gdpu
parameters
are
put
into
the
srb6
header,
but
it
was
in
the
MPS
replacing
GDP
case.
We
leave
the
GTP
header
in
place.
We
just
replace
the
IPv6
header
and
UDP
header
with
the
NTS
level
stack
next
slide.
So
that's
the
basic
idea.
It
was
originally
written
here
as
a
pseudo
wire
draft,
but
then
we
generalize
it
to
the
entire
ipvpn.
J
There
are
a
lot
of
details
in
the
draft
about
the
signaling
but
I'm
going
to
skip
it
here.
I
just
want
to
mention
this
option
of
replacing
GDP
tunneling
under
the
hood,
with
mpos,
similar
to
using
srv6
to
replace
that
again,
it's
under
the
hood
I
think
I'm
just
going
to
stop
here,
skip
the
rest
of
the
slides.
G
No
matter
what
replace
GTP
with
either
srv6
or
mpis
I
haven't
read
your
your
draft.
Yet
how
about
those
like
the
IE
information
element
that
embedded
in
the
GDP
like
a
pdu
session
container
for
the
QX
flow?
All
kind
of
information
regarding
you
know,
don't
be
carried
within
the
beyond
the
GDP
header.
J
K
Jim
Costello
from
BT
could
I
ask
if
you've
had
a
liaison
statements
exchange
with
3gpp
the
CT
groups
at
all.
J
So
I
use
the
word
under
the
hood
several
times,
so
basically,
there
is
no
change
to
3gb
architecture
or
signaling.
We
are
still
doing
this
based
on
the
N2
and
M4
signaling,
so
it
because
of
that
I
didn't
think
we
needed
a
a
liaison,
because
this
is
all
under
the
hood.
So
it's
just
the
operator
deployment
choice.
A
G
Have
a
follow-up
question
regarding
the
the
lesson
part
you
keep
Imaging
about
the
the
end
of
the
hood.
The
the
underlying
part
is
like
transparency
to
the
up
linear
here
regarding
the
GDP
I'm.
Thinking
for
the
ti
department
is
okay.
How
about
the
the
end
the
end
device?
No,
the
IP
for
the
the
both
ends.
For
those
things.
Are
you
going
to
embed
it
in
your
like
srv6,
header
or
MPS
label?
G
G
J
G
Exactly
but
the
what
is
the
you
know,
because
you
have
to
do
the
mapping
here.
You
have
the
the
Qs
flows,
those
type
of
things
through
sdap,
on
gnode
for
the
Uplink
for
the
downlink.
You
have
the
things
originally,
the
UPF
will
do
the
in-cap
for
the
GTP.
Now
you
have
to
add
additional
functions
and
also
is
necessary
or
not,
but
you
have
to
add
those
things
in
order
to
in
incorporate
these
things
inside
if
the
genome
beside
or
the
UPF
side.
J
Even
in
the
original
s36
or
mposite
transport
GDP
case,
you
still
need
to
translate
that
across
things
into
the
IP
or
mpos
request
mechanism
in
the
underlying
Network
that
part
no
matter
what
it
needs
to
happen,
how.
G
G
C
D
Really,
let's
yeah
I
think
so.
Thank
you
so
much
yeah,
okay,
all
right
I
think
this
was
our
last
presentation
this,
that's
all
we
close
the
meeting
here.
Thank
you.
So
much
excuse
me.