Tom, Are you referring to a use case where the UE moves between different access technologies?
Arashmid > IMO Unified concept in that encapsulation doesn’t seem to work i.n that > circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane > protocol which is also a foo-over-UDP variation. > Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming device, what protocol are they going to use? -----Original Message----- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert Sent: 27 March 2018 10:03 To: Satoru Matsushima <satoru.matsush...@gmail.com> Cc: dmm@ietf.org Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima <satoru.matsush...@gmail.com> wrote: > Thank you Tom, > > Unfortunately I couldn’t find clear advantage of GUE against GTP-U. > (No offensive, please don’t get me wrong.) > > I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP > type encapsulation in IETF. It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and draft-ietf-intarea-gue-extensions. > IMO Unified concept in that encapsulation doesn’t seem to work i.n that > circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane > protocol which is also a foo-over-UDP variation. > Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming device, what protocol are they going to use? > Nevertheless I think that that aspect would be a criteria for user plane > protocols comparison provided to 3GPP. But I don’t think it is good idea that > we provides 3GPP all kind of foo-over-UDP encapsulation protocols in IETF. It > would be better to pick SRv6 and some generic foo-over-UDP protocol to be > compared with GTP-U supported functionalities. > GUE is the generic foo-over-UDP protocol for that purpose. > Basic functionalities of GTP-U is that sequence number option, > extension-headers, and multicast and those should be the part of criteria. > IMO as you suggested, overhead size, performance, TE, extensibility and > encryption would be good idea for the criteria in addition to the above > fundamental ones. > > Best regards, > --satoru > > > >> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール: >> >> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima >> <satoru.matsush...@gmail.com> wrote: >>> Thank you Tom for your suggestion. >>> >>> Do you think that GUE has some advantages against GTP-U? >> >> I believe so. GUE is designed to be a general purposed multi use case >> encapsulation. The defined GUE extensions deal with problems and >> provide features of encapsulation (header security, fragmentation, >> payload security, checksum handling etc.). This is done without >> resorting to expensive TLV processing. GUE also allows "private data" >> that could be used for use case specific info-- so TLVs or GTP >> extensions could be encoded so in that sense it's a superset of GTP >> functionality. As I mentioned, GUE has a mode for encapsulating IP in >> UDP with minimal overhead (direct IP over UDP). >> >>> When it comes to foo over UDP capsulation, does GUE benefit user plane >>> beyond GTP-U? >>> >> I think so. Perhaps the biggest advantage is the GUE can be used >> accross different use cases and technologies. It's generic protocol >> so it could be used for multiple use cases in a mobile network. For >> instance, a UE might talk to a a low latency service application via >> GUE. To the server this looks much more like simple virtualization or >> encapsulation and GUE includes potential optimizations. Similarly, >> GUE also could be use to connect across different access technologies >> that might not be 3GPP (like roaming between WIFI and a mobile network). >> Conceptually, other IETF defined encapsulations could also be used >> for this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically >> designed to be multi use case, low overhead, but still extensible. >> >> We intend to use ILA in a similar multi-use case fashion, however >> when encapsulation is required (like SR TE is needed, or we need an >> encrypted tunnel) then I believe GUE is a good alternative for that >> case to provide necessary functionality and extensibility. >> >> Tom >> >>>> 2018/03/27 9:16、Tom Herbert <t...@quantonium.net>のメール: >>>> >>>> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave) >>>> <sgund...@cisco.com> wrote: >>>>> FYI. This is the notes that Carlos captured. Thank you Carlos!! >>>>> >>>>> We are also waiting for Lyle to share his notes. Please review and >>>>> comment, if you see any mistakes. >>>>> >>>> >>>> With regards to SR encapsulation: "this is using IP-in-IP as default. >>>> Why not using UDP encapsulation?" >>>> >>>> There is some rationale for UDP encapsulation here to maximize >>>> compatibility with the network and potentially intermediate nodes >>>> like firewalls. For example, in the performance numbers that >>>> Kalyani posted, the TPS for SR over IPIP routing was lower than >>>> other encapsulations. The reason for this is that the particular >>>> NIC (ixgbe) is not parsing over IPIP or using flow label to get a >>>> good hash for RSS. This is symptomatic of network devices that >>>> don't provide as good support for protocols outside of TCP and UDP. >>>> There are likely routers that would not be able to provide flow >>>> specific ECMP for similar reasons. There was a comment in dmm >>>> meeting that ECMP for IPIP was expected to by solved by using flow >>>> label in the hash. This is a great idea, but unfortunately there is >>>> significant resistance to using flow label for this purpose since >>>> it is not guaranteed to be persistent for a flow and that can cause >>>> problems for stateful devices like firewalls. >>>> >>>> UDP encapsulation is the typical answer to network protocol >>>> compatibility. Several UDP encapsulation techniques have been >>>> defined as well as some foo over UDP to run existing encapsulations >>>> over UDP (e.g. MPLS/UDP, GRE/UDP). draft-ietf-rtgwg-dt-encap gives >>>> a nice overview of considerations for UDP encap protocols. >>>> >>>> If a UDP encapsulation is considered for use with SR, I would >>>> suggest GUE is an option. GUE has some unique features: >>>> >>>> - It's extensible (both common extensions are defined and allows >>>> custom extensions per use case) >>>> - It's generic (can encapsulate any IP protocol) >>>> - It allows directly encapsulating IPv4 and IPv6 in UDP (to >>>> minimize encapsulation overhead) >>>> - It allows encapsulation of extension headers >>>> >>>> The last point may be of particular interest to SR. SR over IPIP >>>> might be more precarious compared to other encapsulations since it >>>> introduces two "atypical" (i.e. not TCP or UDP) protocols. GUE >>>> could be used to normalize SR packets to look like UDP to the >>>> network. This might look something like: >>>> >>>> IP|UDP|GUE|Routing_hdr|IP|payload >>>> >>>> The UDP and GUE header are effectively treated as routing shim at >>>> each segment hop so SR is processed as without regard to the encapsulation. >>>> To intermediate nodes these packets looks like any other UDP packet >>>> so there's no compatibility issue. >>>> >>>> Tom >>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
