Hi Charlie, Mobile IPV6 can be among the alternatives. But mobility is just one the important features in 3GPP. There are several aspects such as impact on CP, support for service chaining, traffic engineering, QoS and BW reservation, etc. that perhaps require further investigation.
Best regards, Arashmid -----Original Message----- From: Charlie Perkins [mailto:charles.perk...@earthlink.net] Sent: 27 March 2018 15:02 To: Arashmid Akhavain <arashmid.akhav...@huawei.com> Cc: dmm@ietf.org Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 Hello Arashmid, > if a WiFi network needs to talk to 3GPP network for a roaming device, what > protocol are they going to use? They could use Mobile IPv6, which was designed for exactly this purpose. Do you think that would work? Regards, Charlie P. On 3/27/2018 11:08 AM, Arashmid Akhavain wrote: > 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 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
