Hi Linda, Thank you for your clarification!
The APN ID is independent of the data plane, which could be MPLS, VXLAN, SR/SRv6 and other tunnel technologies that are adopted to provide services within a service provider's limited domain. Best regards, Shuping From: Apn [mailto:apn-boun...@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, February 2, 2021 11:00 AM To: Pengshuping (Peng Shuping) <pengshup...@huawei.com>; Sridhar Bhaskaran <sridhar.bhaska...@gmail.com>; Kaippallimalil John <john.kaippallima...@futurewei.com> Cc: a...@ietf.org; Gengxuesong (Geng Xuesong) <gengxues...@huawei.com>; Uma Chunduri <umac.i...@gmail.com>; Lizhenbin <lizhen...@huawei.com>; dmm <dmm@ietf.org> Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core Shuping, Answers to your questions are inserted below: From: Pengshuping (Peng Shuping) <pengshup...@huawei.com<mailto:pengshup...@huawei.com>> Sent: Saturday, January 30, 2021 10:18 PM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>; Sridhar Bhaskaran <sridhar.bhaska...@gmail.com<mailto:sridhar.bhaska...@gmail.com>>; Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>> Cc: a...@ietf.org<mailto:a...@ietf.org>; Gengxuesong (Geng Xuesong) <gengxues...@huawei.com<mailto:gengxues...@huawei.com>>; Uma Chunduri <umac.i...@gmail.com<mailto:umac.i...@gmail.com>>; Lizhenbin <lizhen...@huawei.com<mailto:lizhen...@huawei.com>>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: RE: [Apn] [DMM] Regarding APN Usecase in Mobile Core Dear Linda, Many thanks for the reference you pointed to. Through this draft I also read the other draft which seems to be source of this work, https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-07<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-07&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C16dbfa2f80114b0010dc08d8c59f4a94%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637476635266911825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q4XvitjEU0B%2FLZ5NrgByhtErVWdXEMJAPgweH6%2FozAg%3D&reserved=0>. I will have to first check whether I have understood it correctly. MTNC-ID is generated by 3GPP NSSMF (TNF) and unique per path and per traffic class but not per flow/session. The MTNC-ID actually can be seen as an indicator of a path/slice in the IP transport network. This ID is carried in the packets and when the packets reach the transport network PE nodes, the ID will be read out and according to which the path/slice in the IP transport network can be selected and the traffic will be steered into it. Am I right? My first question is where is the MTNC-ID first added, on the UE? gNB? Or UPF? [Linda] MTNC-ID is only valid between gNB and the UPF. The draft suggests mapping to UDP port number which is managed by the Management Function. So on the data packets, if you use Wireshark you can only see the UDP port number. It is the UPF and gNG interpret per the mapping from the Management Function. It is mentioned in the draft that "to mininise the protocol changes are required and make this underlay tranport independent IPv4/IPv6/MPLS/L2), an option is to provision a mapping of MTNC-ID to a UDP port range of the GTP encapsulated user packet....This mapping is configured in 3GPP user plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that process MTNC-IDs." My second question is whether the actual mapping procedure is like this. At the 5G-AN, the MTNC-ID is mapped to the UDP port range in the GTP-u packet header due to easier implementation/deployment, and then at the PE router, the UDP port range in the GTP-u header is used to steer the traffic into the selected path/slice. Is it correct? [Linda] Correct. It is good for you to consider to extend to N6 since it is IP to further provide SLA guarantee and other value added services. Do you plan to continue to using the UDP port range? [Linda] the UDP port number in the GTP-u tunnel is removed by the UPF function. So the packets sent to the N6 interface doesn't have the label anymore. More reasonable approach is having signaling (or messages) between the Management function of the 5G Core and N6 network Controller, which is feasible if both 5G core and N6 Networks are administrated by the same network operator. I just keep wondering whether you have to do this. The use of the UDP port range is because of the limitation caused by the GTP-u encapsulation. So when it is N6, it is IP based. You may not need to continue this limitation. On the other hand, the UDP port range itself is also very limited, not very meaningful. So what I am thinking is that you could use the APN ID in this case. It can serve your purpose and achieve more service provisioning possibilities. [Linda] That is possible. Question: is APN-ID an additional Metadata inserted into data packets on top of SRv6 header? Currently, the draft describes using the labels supported by the N6 IP network, i.e. if N6 IP network is SR, uses the SR label, if the N6 IP network is MPLS, use the MPLS label, etc. Thank you very much for starting the discussions in the 5G scenario and N6 interface in particular! I believe it is a very important case for APN, and it can be integrated with MEC etc. Best regards, Shuping From: Apn [mailto:apn-boun...@ietf.org] On Behalf Of Linda Dunbar Sent: Saturday, January 23, 2021 4:58 AM To: Sridhar Bhaskaran <sridhar.bhaska...@gmail.com<mailto:sridhar.bhaska...@gmail.com>>; Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>> Cc: a...@ietf.org<mailto:a...@ietf.org>; Gengxuesong (Geng Xuesong) <gengxues...@huawei.com<mailto:gengxues...@huawei.com>>; Uma Chunduri <umac.i...@gmail.com<mailto:umac.i...@gmail.com>>; Lizhenbin <lizhen...@huawei.com<mailto:lizhen...@huawei.com>>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core Many thanks to Sridhar and John 's insightful description of GTP-u tunnel for both 4G and 5G. IMHO, APN should focus on the 5G case, i.e. potentially hundreds of thousands (or even millions) of GTP-u tunnels between a pair of one gNB and one UPF. I think two scenarios worth exploring further separately: 1) 5G core can exchange signal with the IP network (the N6 interface), more likely the 5G Core and N6 network are administrated by the same network operator. a. 5G core can tag the packets before handing off to the N6 interface (i.e. the IP network), such as inserting a metadata to the data packets b. inform the IP network of the meaning of the inserted Metadata. c. The IP network needs to remove the metadata before handing the packets to their destinations 2) There is no communication between the 5G core and the IP network, then the IP network can only depend on the priority bits added by the UE, which can be very unpredictable. The Section 4 (Mobility Packet Transition in the Data Network) and the Section 5 (Transport Network characteristics Mapping to SR-TE Paths) have good description on how to extend 5G core's TN aware mobility information for various TE paths within IP networks. https://datatracker.ietf.org/doc/draft-mcd-rtgwg-extension-tn-aware-mobility/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mcd-rtgwg-extension-tn-aware-mobility%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C16dbfa2f80114b0010dc08d8c59f4a94%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637476635266911825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=12Du2nNaBgxXw41zrZyAMPlqeoqgUnJhC1Kucnrnrns%3D&reserved=0> Linda Dunbar From: Apn <apn-boun...@ietf.org<mailto:apn-boun...@ietf.org>> On Behalf Of Sridhar Bhaskaran Sent: Thursday, January 21, 2021 10:39 PM To: Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>> Cc: a...@ietf.org<mailto:a...@ietf.org>; Gengxuesong (Geng Xuesong) <gengxues...@huawei.com<mailto:gengxues...@huawei.com>>; Uma Chunduri <umac.i...@gmail.com<mailto:umac.i...@gmail.com>>; Lizhenbin <lizhen...@huawei.com<mailto:lizhen...@huawei.com>>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>> Subject: Re: [Apn] [DMM] 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<mailto: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<mailto: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<mailto:umac.i...@gmail.com>>; Lizhenbin <lizhen...@huawei.com<mailto:lizhen...@huawei.com>> Cc: a...@ietf.org<mailto:a...@ietf.org>; dmm <dmm@ietf.org<mailto: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] On Behalf Of Uma Chunduri Sent: Tuesday, January 19, 2021 3:17 AM To: Lizhenbin <lizhen...@huawei.com<mailto:lizhen...@huawei.com>> Cc: a...@ietf.org<mailto:a...@ietf.org>; dmm <dmm@ietf.org<mailto: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<mailto: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%7Clinda.dunbar%40futurewei.com%7C16dbfa2f80114b0010dc08d8c59f4a94%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637476635266921821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4SZ3u7UbcMYWmkfrcg1ksNuX%2BfIJsEpmwyQRyVgch60%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<mailto: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%7Clinda.dunbar%40futurewei.com%7C16dbfa2f80114b0010dc08d8c59f4a94%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637476635266931813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CN0rF3Z3wrsL3%2B0VBfunJo1HJhpXzF1%2BeZA6hslejNw%3D&reserved=0> _______________________________________________ dmm mailing list dmm@ietf.org<mailto: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%7Clinda.dunbar%40futurewei.com%7C16dbfa2f80114b0010dc08d8c59f4a94%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637476635266931813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CN0rF3Z3wrsL3%2B0VBfunJo1HJhpXzF1%2BeZA6hslejNw%3D&reserved=0> -- 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
