Subject: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt

From: Shunsuke Homma <[email-masked]>
Date: Fri, 10 Aug 2018 18:24:10 +0900

Hi DMM folks,

We reflected feedback from 3GPP CT4 on draft-hmm-dmm-5g-uplane-analysis 
and uploaded the new version. We need more reviews from both IETF and 
3GPP for further improvement. We will appreciate if you can give 
comments or feedback to this I-D.

Best regards,

Shunsuke

-------- Forwarded Message --------
Subject: New Version Notification for 
draft-hmm-dmm-5g-uplane-analysis-01.txt
Date: Fri, 10 Aug 2018 01:44:20 -0700
From: [email-masked]
To:  [email-masked] <[email-masked]>, Daniel Voyer 
<[email-masked]>, Takuya Miyasaka <[email-masked]>, 
Satoru Matsushima <[email-masked]>, Shunsuke Homma 
<[email-masked]>

A new version of I-D, draft-hmm-dmm-5g-uplane-analysis-01.txt
has been successfully submitted by Shunsuke Homma and posted to the
IETF repository.

Name:		draft-hmm-dmm-5g-uplane-analysis
Revision:	01
Title:		User Plane Protocol and Architectural Analysis on 3GPP 5G System
Document date:	2018-08-10
Group:		Individual Submission
Pages:		30
URL: 
https://www.ietf.org/internet-drafts/draft-hmm-dmm-5g-uplane-analysis-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-hmm-dmm-5g-uplane-analysis/
Htmlized: 
https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-01
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-hmm-dmm-5g-uplane-analysis
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-hmm-dmm-5g-uplane-analysis-01

Abstract:
    This document analyzes the mobile user plane protocol and the
    architecture specified in 3GPP 5G documents.  The analysis work is to
    clarify those specifications, extract protocol and architectural
    requirements and derive evaluation aspects for user plane protocols
    on IETF side.  This work is corresponding to the User Plane Protocol
    Study work on 3GPP side.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tom Herbert <[email-masked]>
Date: Sat, 11 Aug 2018 11:49:16 -0700

Hi Shunsuke,

Thanks for the draft! It does a very good job of describing and
framing GTP-U using IETF terminology. This should help significantly
to bridge that gap of understanding between IETF and 3GPP.

Some comments:

General comment: Please look at "Encapsulation Considerations"
(https://tools.ietf.org/html/draft-ietf-rtgwg-dt-encap-02). There's a
lot of material there that might be relevant to encapsulation aspects
of GTP-U.

General comment: There are a number of recommendations that could be
extracted and made to improve GTP (in section 3 in particular). Does
it make sense to these in their own document as a recommendation to
3GPP for a future update of GTP?

Section 1:

"Another aspects of user plane requirements couldn't be found." - I'm
not sure what this means

Section 3:

"Allocation of UDP source port depends on sender tunnel endpoint node
and GTP-U supports dynamic allocation of UDP source port for load
balancing objective." - How is this done in practice. In most UDP
encapsulation protocols the UDP source is set to value from the hash
over a tuple of the encapsulated packet. This way, the outer packet
can ECMP router each encapsulated flow for load balancing. If this
were done in GTP-U this would probably mean that the source port is
not consistent for all packets sent on a tunnel. Would this be
consistent with 3GPP specifications?

"GTP-U does not support IPv6 flow label for load balancing in case of
IPv6 transport." - does the spec say anything about flow label, does
it need to be set to zero otherwise? This should be an easy fix since
setting flow label isn't a wire protocol change and setting flow label
has already commonly implemented in other encapsulations.

"UDP zero checksum is not available in case of IPv6 transport." -
Setting a UDPv6 zero checksum is a little tricky. RFC6935 and RFC6936
need to be considered, but also the specifics and conditions of the
protocol an conditions of deployment. For instance, RFC8086 goes into
inordinate detail on requirements to set a zero UDPv6 checksum.

"GTP-U does not support to response ICMP PTB for Path MTU  Discovery."
- I'm not sure what this means. Is this saying that if a GTP-U
endpoint receives an ICMP PTB error for a packet sent over tunnel, it
doesn't handle that; or is this saying that if a packet from a UE is
dropped at a GTP tunnel ingress point because of MTU exceeded then no
ICMP PTB is sent? If it's the first case, then that's not much a
problem. I doubt PMTU discovery has been implemented for many tunnels.
Usually one of the  suggestions in RFC4459 is used (that RFC should be
referenced in the draft). If it's the second case, then that is more
of a bug in the protocol that should be fixed (this is IP layer
requirements, should not be specific to GTP-U).

"Following list summarizes every extension header which is used for
user plane protocol." - Used or defined? It would be good to know
which, if any extension headers are commonly used in the data path.
This will also be input to the issued raised later on about the
efficiency of extension header processing.

"DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel
endpoint node based on the QFI." - This should be rectified with
RFC2983.

"In general, multiple GTP-U extension headers are able to contained in
one GTP-U packet and the order of those extension headers is not
specified by [TS.29.281-3GPP]." - That is the combinatoric nature of
TLVs. There has been much discussion on that. A potentially related
question would be does GTP-U limit the number or size of extension
headers (unlimited TLVs in a packet could be used as a potential
denial of service attack.

"GTP-U does not support to indicate next protocol type." - A bit
unfortunate, IMO an encapsulation should also have a type field.
Conceptually, there is a way around this by defining the the first
nibble after GTP-U headers to be a type field (similar to GUEv1). 0x4
and 0x6 are IPv4 and IPv6, which is convenient since this coincides
with the version number of an overlaid encapsulated IP packet. Other
values could be used for different types.

"GTP-U supports active OAM as a path management message "Echo
Request/Response"" - Does GTP-U support in-situ OAM?

Header format "DSCP=0" in inner packet. Is this a requirement?

There should be some discussion about how ECN is handled. RFC6040
should probably be referenced.

Section 4:

"Then, the content information of the PDU may be mapped into UDP port
number" - I don't follow this. Does this mean that different
destination port numbers are used to determine the protocol of the
T-PDU?

"For this, the expected evaluation points from this aspect should be
whether there is substitutional means to cover other PDU session
types.  And how much it makes simple the system than deploying
original PDU session types." - Is this another way of saying the
encapsulation protocols should have type field? :-)

"However it increases header size from 20bytes to 40bytes compare to
IPv4." - That's also an overhead problem. In a bandwidth constrained
IoT network where average packet sizes might be as little at 100
bytes, the overhead of two IPv6 headers, GTP-U header and extensions,
and an eight byte UDP header becomes significant to the extent that
overhead packet becomes majority portion of bytes. Techniques to
reduce the overhead could be warranted (ILA is one optimization that
does that).

Section 5 is good, but it would be nice to highlight whether or not
GTP-U can satisfy the evaluation aspects. Most of the problems of
GTP-U listed in section 3 are relatively minor and can be addressed
without significant protocol change (e.g. turning on flow label should
be trivial). The biggest feature touted by the candidate protocols
seems to be anchor-less mobility (might be a topic worth mentioning in
the draft). AFAICT, GTP-U is sufficiently generic and extensible so
that it could be used a the user plane of anchor-less mobility without
much change. Control plane would need major changes, but that is
probably similar to what needed in the control plane for other user
plane protocols to provide anchorless mobility.

Tom

On Fri, Aug 10, 2018 at 2:24 AM, Shunsuke Homma
<[email-masked]> wrote:
> Hi DMM folks,
>
> We reflected feedback from 3GPP CT4 on draft-hmm-dmm-5g-uplane-analysis and
> uploaded the new version. We need more reviews from both IETF and 3GPP for
> further improvement. We will appreciate if you can give comments or feedback
> to this I-D.
>
> Best regards,
>
> Shunsuke
>
>
> Status: https://datatracker.ietf.org/doc/draft-hmm-dmm-5g-uplane-analysis/
> Htmlized: https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-01
> Htmlized:
> Diff: https://www.ietf.org/rfcdiff?url2=draft-hmm-dmm-5g-uplane-analysis-01
>
> Abstract:
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Aug 2018 12:47:44 +0200

Hi, thanks for the draft.  I am happy you wrote and published it.

I am looking forward for a packet capture from a live cellular network 
that illustrates this outer packet header format described in the draft.

In particular, the Source and Destination IPv6 addresses (not IPv4).

I can suppose that the two addresses would have same prefix, because 
that would be a point-to-point link and these links would have same 
prefix.  (i.e. if the src is 2001:db8:1:1::1 then dst would be 
2001:db8:1:1::2 and not 2001:db8:1:2::1).

This is only supposition from my side, because I have never seen a 
packet capture of this.

> 3.5.  Packet Format
> 
>    Figure 4 shows a packet format example of GTP-U over IPv6 that
>    carries an extension header for QFI and an IPv6 PDU.  All values in
>    the example are illustration purpose only.  The encoding of PDU
>    Session Container for QFI refers to [TS.38.415-3GPP].
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      Outer IPv6 Header
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |Version|     DSCP=EF   |               Flow Label              |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |          Payload Length       | NxtHdr=17(UDP)|    Hop Limit  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      +                                                               +
>      |                                                               |
>      +                   Source IPv6 Address                         +
>      |                        2001:db8:1:1::1                        |
>      +                                                               +
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      +                                                               +
>      |                                                               |
>      +              Destination IPv6 Address                         +
>      |                        2001:db8:1:2::1                        |
>      +                                                               +
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alex

---

From: Arashmid Akhavain <[email-masked]>
Date: Mon, 20 Aug 2018 14:58:02 +0000

Alex,
I think you missed this disclaimer in 
"All values in the example are illustration purpose only"

Generally speaking, there is no guarantee for a point to point link.

Arashmid

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Alexandre
> Petrescu
> Sent: 20 August 2018 06:48
> To: [email-masked]
> Subject: Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-
> uplane-analysis-01.txt
> 
> I am looking forward for a packet capture from a live cellular network that
> illustrates this outer packet header format described in the draft.
> 
> I can suppose that the two addresses would have same prefix, because that
> would be a point-to-point link and these links would have same prefix.  (i.e. if
> the src is 2001:db8:1:1::1 then dst would be
> This is only supposition from my side, because I have never seen a packet
> capture of this.
> 
> > 3.5.  Packet Format
> >
> > We reflected feedback from 3GPP CT4 on
> > draft-hmm-dmm-5g-uplane-analysis and uploaded the new version. We
> need
> > more reviews from both IETF and 3GPP for further improvement. We will
> > appreciate if you can give comments or feedback to this I-D.
> >
> > Best regards,
> >
> > Shunsuke
> >
> >
> > <[email-masked]>, Takuya Miyasaka
> > <[email-masked]>, Satoru Matsushima
> > <[email-masked]>, Shunsuke Homma
> > Title:        User Plane Protocol and Architectural Analysis on 3GPP
> > 5G System Document date:    2018-08-10
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> > tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> >

---

From: Shunsuke Homma <[email-masked]>
Date: Fri, 24 Aug 2018 21:30:36 +0900

Hi Tom,

Firstly, I'd like to apologize for my late reply because of summer vacation.

We greatly appreciate your detailed review and feedback. We'll reflect 
your feedback on the I-D at the next update. Please find my replies to 
your comments in-line. (They are tagged with [SH])

By the way, please note that the purpose of this I-D is not denigrating 
GTP-U but introducing what is GTP-U protocol to IETF folks. Therefore, 
we consider that this document should describe just facts derived from 
3GPP docs or general aspects.

Best regards,

Shunsuke

> lot of material there that might be relevant to encapsulation aspects
[SH] Thanks. We'll refer the document and update the content of GTP-U 
section if there are points should be added.

> 3GPP for a future update of GTP?
[SH] It's out of scope, however 3GPP folks may be able to use this I-D
to improve GTP.

> "Another aspects of user plane requirements couldn't be found." - I'm
[SH] It means the fact that the capture of TR 29 891 describes only "how 
to carry 5G specific QoS information between UPF and access networks", 
however, as you pointed out, it is not necessarily needed and we can 
remove it at the next update.

> consistent with 3GPP specifications?
[SH] As we described "however specific procedure, e.g., 5-tuple hashing, 
is not described in the document" in the draft, GTP-U spec described in 
TS29.281 just allows dynamic UDP src port allocation depend on network 
deployment and network node implementation.

So it could also be consistent with the spec when the allocated src 
ports are inconsistent on a tunnel.

> has already commonly implemented in other encapsulations.
[SH] It is not also defined specific procedure in TS29.281.

> inordinate detail on requirements to set a zero UDPv6 checksum.
[SH] Thanks, it looks useful.

> requirements, should not be specific to GTP-U).
[SH] Both of what you pointed out are possibly to occur. As Sridhar, 
3GPP folk, described in the LS-OUT, 3GPP has assumption that MTU between 
RAN and the P-GW or UPF is discovered by offline means and the operator 
takes into account the MTU that is transferrable on the radio interface 
and based on this the operator configures the right MTU to be used. 
Therefore they don't consider there are any MTU issues. We'll add this 
supplemental description about why it would be a problem  at the next 
update.

> efficiency of extension header processing.
[SH] It means defined extension headers. Of course, some extension 
headers are used in the real networks.

> endpoint node based on the QFI." - This should be rectified with
[SH] What this observation means is that UPF remark DSCP value of outer 
IP header based on QFI of GTP extension header, and how to handle GTP-U 
packets with DSCP is out of scope.

> denial of service attack.
[SH] Yes, you're correct. Meanwhile, the problem that we indicated here 
is ambiguity of 3GPP spec and effect on hardware performance caused by 
the ambiguity.

Maybe, each vendor implementation would have its own specification about 
limit on the number, order, and capable types of extension headers. 
Nevertheless, do you think we should add the concern related to limit 
the number of extension headers?

> values could be used for different types.
[SH] It's also good point. We'll add the aspect.

> Request/Response"" - Does GTP-U support in-situ OAM?
[SH] No, it doesn't. GTP-U supports only keep-alive by using Echo 
Request/Response sent regular basis.

> Header format "DSCP=0" in inner packet. Is this a requirement?
[SH] There are no definitions on inner IP packet. The figure describes 
"DSCP=0" as just an example.

> should probably be referenced.
[SH] Thanks. We'll consider how to mention ECN handling at the next update.

> destination port numbers are used to determine the protocol of the
[SH] Sorry, if this description is misleading. The section 9.2 of 
TS29.561 defines that IPv6 address and UDP port number for unstructured 
PDU type data is pre-configured at UPF, and the UPF associates GTP-U 
tunnels with N6 PtP tunnel based on the UDP port destination. Although 
we couldn't find concrete definitions about unstructured PDU type data, 
some variations of UDP port numbers might be needed if there are some 
types in unstructured PDU data.

> encapsulation protocols should have type field? :-)
[SH] Type field seems good point to simplify the system. We'll add the 
aspect as an example.

> reduce the overhead could be warranted (ILA is one optimization that
[SH] As you described, overhead problem would be a point to evaluate 
candidate protocols. Although there seems to be no clear requirements 
for overhead of encapsulation in 3GPP 5G, we can add such aspect if it 
is general problem and useful for comparing candidate protocols.

> plane protocols to provide anchorless mobility.
[SH] Such highlight is a good idea, but 3GPP folks may not hope that 
IETF evaluates GTP-U that is 3GPP protocol. Please let us consider 
whether it can be added in this I-D. Also, as I described at the 
beginning of this email, the purpose of this I-D is clarifying and 
introducing GTP-U protocol and we assume that we don't need to provide 
shorts of GTP-U intentionally.

-- 
----------------------------------
Shunsuke Homma
<[email-masked]>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------

---

From: Shunsuke Homma <[email-masked]>
Date: Fri, 24 Aug 2018 21:35:45 +0900

Hi Alex,

Thank you for reviewing our I-D.

Regarding GTP-U packet format described in the I-D, as Arashmid pointed 
out, all of the values are examples. (Thanks Arashmid!)

If they are confusable, we can change such values to symbols (e.g., IP = 
xxx).

Best regards,

Shunsuke