Hi Sridhar, Xuesong, Quick thoughts below [Uma]:
-- Uma C. On Sun, Jan 31, 2021 at 8:42 PM Sridhar Bhaskaran < sridhar.bhaska...@gmail.com> wrote: > Hi Gengxuesong, > > On, > > >> Maybe the existing question becomes whether DSCP is sufficient for > passing information from the mobile network to transport network? whether > there is any simplification or omission of information in the mapping to > the DSCP? > [Uma]: First of all, a lot of discussion below was discussed during 04 version of https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08. It was presented by John in one the IETF DMM sessions that time. And yes, it was limiting and moreover a lot of implementations reset DSCP bits in the shared transport scenarios (like WAN scenario). > > > 3GPP allows mapping of a GTP-u tunnel (PDU session) to an index to a > transport network configuration / policy via "Network Instance" concept. > When the GTP-u tunnel is setup in the UPF by the signalling plane, it > provides a "Network Instance" which is just a string that acts as an index > into UPF's transport layer configuration. > [Uma]: Right and that's natural as overlay is processed at the tunnel endpoints (gNB/PSA-UPF/ULCL-UPF/BP-UPF). > Now what the transport layer configuration is - 3GPP doesn't care as it is > out of their remit. If you are using just plain IP routing, then DSCP (for > IPv4) and Flow label (IPv6) are the options to map a QFI within a GTP-u > tunnel to IP transport. However if you are using - say a source routing > technology like SRv6, you may potentially configure the UPF to map a slice > (PDU session / TEID) and QFI to a specific SID list. If you use PPR > (Preferred path routing), then MTCN-ID is an option. > [Uma]: I am afraid this may not be possible in all scenarios for example gNB may not be knowing the all underlying transport information to encode that way. However, if 5G-AN node is integrated with the PE this is a possibility. Another possibility is SRv6 user plane where interoperability scenarios and overall user plane are described in https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-09 > > Also note that on the N3 interface between UPF and gNB, if it is going to > traverse a public network, operators would employ IPSec tunneling for > security. So any markings at the transport protocol layer (e.g. UDP source > port) will not be visible to on path routers due to IPSec. In such a case, > the mapping of Slice (PDU Session / TEID) and QFI should be to the outer IP > header in the IPSec tunnel. This is where a solution at IP header level > helps (e.g DSCP / flow label / SID list) > [Uma]: Or one can use https://tools.ietf.org/html/draft-xu-ipsecme-esp-in-udp-lb-07 (note RFC 3948 UDP encap only for nat traversal scenarios) > > Regards > Sridhar > > On Mon, Feb 1, 2021 at 8:10 AM Gengxuesong (Geng Xuesong) < > gengxues...@huawei.com> wrote: > >> Hi Sridhar, >> >> >> >> Thanks for your explanation. It is much clearer for me as the following: >> >> ž UPF < ----- GTP-u tunnel [PDU session]------ > gNB >> >> ž PDU session contains multiple QoS flows [QFI marker->5QI] >> >> ž QFI marker in GTP-u extension header >> >> 5QI is not in GTP-u header directly but could be indicated by QFI. So the >> QoS requirements presented by 5QI can’t be used/seen by transport network >> in the existing in the current implementation (TEID is similar). And DSCP >> can act as a mediator between transport network and UPF/gNB. >> >> Maybe the existing question becomes whether DSCP is sufficient for >> passing information from the mobile network to transport network? whether >> there is any simplification or omission of information in the mapping to >> the DSCP? >> >> >> >> Best >> >> Xuesong >> >> >> >> >> >> *From:* Apn [mailto:apn-boun...@ietf.org] *On Behalf Of *Sridhar >> Bhaskaran >> *Sent:* Friday, January 29, 2021 8:06 PM >> *To:* Gengxuesong (Geng Xuesong) <gengxues...@huawei.com> >> *Cc:* a...@ietf.org; Uma Chunduri <umac.i...@gmail.com>; Kaippallimalil >> John <john.kaippallima...@futurewei.com>; dmm <dmm@ietf.org>; Lizhenbin < >> lizhen...@huawei.com> >> *Subject:* Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core >> >> >> >> Hi Gengxuesong, >> >> >> >> QFI (mapped to 5QI) and TEID are to identify QoS flows and PDU sessions >> within UPF and gNB. They are not meant for transport network to look into. >> UPF and gNB map QFI to DSCP marking in the outer IP header which the >> transport network can use for differentiated services. >> >> >> >> Regards >> >> Sridhar >> >> >> >> On Fri, Jan 29, 2021 at 3:37 PM Gengxuesong (Geng Xuesong) < >> gengxues...@huawei.com> wrote: >> >> Hi Sridhar, >> >> >> >> Thank you for your additional information. Can I come to a conclusion >> that: both 5QI and TEID have the potential to provide additional >> information for differentiated services in transport network, although the >> two parameters act in different scopes? >> >> >> >> Best >> >> Xuesong >> >> >> >> *From:* Sridhar Bhaskaran [mailto:sridhar.bhaska...@gmail.com] >> *Sent:* Friday, January 22, 2021 12:39 PM >> *To:* Kaippallimalil John <john.kaippallima...@futurewei.com> >> *Cc:* Gengxuesong (Geng Xuesong) <gengxues...@huawei.com>; Uma Chunduri < >> umac.i...@gmail.com>; Lizhenbin <lizhen...@huawei.com>; a...@ietf.org; >> dmm <dmm@ietf.org> >> *Subject:* Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core >> >> >> >> Hi Xuesong, >> >> >> >> In addition to what John said, in 3GPP networks there is one GTP-u tunnel >> per bearer (in case of 4G) and one GTP-u tunnel per PDU session (in case of >> 5G). >> >> >> >> One UE (user equipment - i.e mobile device) may have multiple PDU >> sessions and hence in the network there may be more than one tunnel for a >> UE. The scope of GTP-u tunnel is from UPF to gNB only. GTP-u does not go >> all the way upto UE. The GTP-u header has a field called "TEID" (tunnel >> endpoint identifier). The TEID in the header identifies a context in UPF >> and gNB. The context gets established through signalling plane. The context >> provides information on the QoS to be provided for the bearer, PDCP >> ciphering keys applicable for the bearer context etc.,. If there are a >> million UE that are getting connected to a UPF, there could be few million >> GTP-u tunnels (TEID). >> >> >> >> In summary: >> >> 1. The 5QI / QFI marking in the GTP-u extension header provides a lookup >> for the general QoS characteristic applicable for that 5QI >> >> 2. TEID in the GTP-u header provides a lookup for UE and bearer specific >> contextual information for any differentiated treatment. >> >> >> >> Regards >> >> Sridhar >> >> >> >> On Fri, Jan 22, 2021 at 2:55 AM Kaippallimalil John < >> john.kaippallima...@futurewei.com> wrote: >> >> Hi Xuesong, >> >> >> >> Traffic policy for subscribers is managed per PDU session at the UPF (and >> gNB). >> >> GTP-u does provide encapsulation between the end points, but its control >> fields are meant for conveying control semantics between the GTP endpoints: >> they were not intended for IP transport/ traffic underlays. 5QI/QCI etc are >> in the GTP extension header which may not be ideal to lookup to classify >> each packet in the transport network. >> >> >> >> The entity that classifies data packets (upstream at gNB and downstream >> at UPF-PSA) also inserts the DSCP for that GTP packet. The classification >> is based on subscriber aspects but may also on be based on its content >> (e.g., using DPI). >> >> >> >> Best Regards, >> >> John >> >> >> >> >> >> *From:* dmm <dmm-boun...@ietf.org> *On Behalf Of *Gengxuesong (Geng >> Xuesong) >> *Sent:* Wednesday, January 20, 2021 8:23 PM >> *To:* Uma Chunduri <umac.i...@gmail.com>; Lizhenbin <lizhen...@huawei.com >> > >> *Cc:* a...@ietf.org; dmm <dmm@ietf.org> >> *Subject:* Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core >> >> >> >> Hi Uma and all, >> >> >> >> I have read the document and got a few questions: >> >> In my understanding, in the UPF where traffic policy is enforced, the >> fine-granularity services are provided. Then what fields in the GTP-u >> encapsulation indicates the traffic's service requirements? When a GTP-u >> tunnel goes into a SRv6 policy, according to which fields in the GTP-u >> encapsulation the DSCP is generated? We know that there are parameters such >> as 5QI/QCI and QFI, whether they are associated with a GTP-u tunnel? >> >> >> >> Best >> >> Xuesong >> >> *From:* Apn [mailto:apn-boun...@ietf.org <apn-boun...@ietf.org>] *On >> Behalf Of *Uma Chunduri >> *Sent:* Tuesday, January 19, 2021 3:17 AM >> *To:* Lizhenbin <lizhen...@huawei.com> >> *Cc:* a...@ietf.org; dmm <dmm@ietf.org> >> *Subject:* Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core >> >> >> >> Hi Robin, >> >> >> >> In-line.. >> >> >> >> Cheers! >> -- >> >> Uma C. >> >> >> >> On Mon, Jan 18, 2021 at 5:25 AM Lizhenbin <lizhen...@huawei.com> wrote: >> >> Hi APNers and DMMers, >> >> I remember that in the mobile core scenarios the GTP-u tunnel can be set >> up according to the user and application requirements, but I do not >> understand the details. >> >> >> >> [Uma]: Obviously, the best reference for GTP-U is TS 29.281. However, uou >> should look into >> https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/ >> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-5g-uplane-analysis%2F&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C77632db844b34a8e561108d8bdb38cb8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637467926158632424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=5nVGUJhkHBn7FWHUCFPC4lGhwr6lBqtIWNyY1o0dxsg%3D&reserved=0> >> where lot more details and other references related this topic was analyzed >> (primarily started after/during REL-15, when any other use plane other >> than GTP-U is worthwhile is debated for 5G N9 interface). >> >> >> >> I think when the packet tunneled by GTP-u traverses the APN-based >> transport network, it may be mapped to the corresponding tunnel according >> to the user and application requirements to implement the uniform service. >> If you are familiar with the principle of GTP-u in the mobile core, please >> help provide some details. >> >> >> >> >> >> Best Regards, >> >> Zhenbin (Robin) >> >> >> >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C77632db844b34a8e561108d8bdb38cb8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637467926158632424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=oHJnGPO3hUL9xPkObVLsJ5S1JnwGOF6IeJrLADLrTVA%3D&reserved=0> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> >> >> -- >> >> o__ >> _> /__ >> (_) \(_)... Burn fat not fuel - Bike along to a healthier life and >> cleaner >> world! :) >> >> Sridhar Bhaskaran >> >> >> >> -- >> >> o__ >> _> /__ >> (_) \(_)... Burn fat not fuel - Bike along to a healthier life and >> cleaner >> world! :) >> >> Sridhar Bhaskaran >> > > > -- > o__ > _> /__ > (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner > world! :) > > Sridhar Bhaskaran > >
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
