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 <homma.shuns...@lab.ntt.co.jp> 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 > > > -------- 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: internet-dra...@ietf.org > To: daniel.vo...@bell.ca <daniel.vo...@bell.ca>, Daniel Voyer > <daniel.vo...@bell.ca>, Takuya Miyasaka <ta-miyas...@kddi-research.jp>, > Satoru Matsushima <satoru.matsush...@g.softbank.co.jp>, Shunsuke Homma > <homma.shuns...@lab.ntt.co.jp> > > > 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 > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
