One thing I want to follow my comment. > 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.
I think that we have to have OAM functionality in addition to that criteria. Best regards, --satoru > 2018/03/27 15:57、Satoru Matsushima <satoru.matsush...@gmail.com>のメール: > > 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. > IMO Unified concept in that encapsulation doesn’t seem to work in that > circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane > protocol which is also a foo-over-UDP variation. > > 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. > > 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
