Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt
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 On 2018/08/20 23:58, Arashmid Akhavain wrote: 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:dmm-boun...@ietf.org] On Behalf Of Alexandre Petrescu Sent: 20 August 2018 06:48 To: dmm@ietf.org Subject: Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g- uplane-analysis-01.txt 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 Le 10/08/2018 à 11:24, Shunsuke Homma a écrit : 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 Voyer , Takuya Miyasaka , Satoru Matsushima , Shunsuke Homma 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 aspect
Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt
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 On 2018/08/12 3:49, Tom Herbert wrote: 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. [SH] Thanks. We'll refer the document and update the content of GTP-U section if there are points should be added. 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? [SH] It's out of scope, however 3GPP folks may be able to use this I-D to improve GTP. Section 1: "Another aspects of user plane requirements couldn't be found." - I'm not sure what this means [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. 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? [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. "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. [SH] It is not also defined specific procedure in TS29.281. "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. [SH] Thanks, it looks useful. "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). [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. "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
Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt
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:dmm-boun...@ietf.org] On Behalf Of Alexandre > Petrescu > Sent: 20 August 2018 06:48 > To: dmm@ietf.org > Subject: Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g- > uplane-analysis-01.txt > > 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 > > Le 10/08/2018 à 11:24, Shunsuke Homma a écrit : > > 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 Voyer > > , Takuya Miyasaka > > , Satoru Matsushima > > , Shunsuke Homma > > > > > > > > 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/ > > Html
Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt
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 Le 10/08/2018 à 11:24, Shunsuke Homma a écrit : 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 Voyer , Takuya Miyasaka , Satoru Matsushima , Shunsuke Homma 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
Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt
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."
[DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt
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 Voyer , Takuya Miyasaka , Satoru Matsushima , Shunsuke Homma 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
