Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core

Sridhar Bhaskaran <sridhar.bhaskaran@gmail.com> Fri, 22 January 2021 04:39 UTC

Return-Path: <sridhar.bhaskaran@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256253A0EEF; Thu, 21 Jan 2021 20:39:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FqTRJXifWBD; Thu, 21 Jan 2021 20:39:57 -0800 (PST)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB8F3A0EDB; Thu, 21 Jan 2021 20:39:37 -0800 (PST)
Received: by mail-ed1-x534.google.com with SMTP id bx12so5073694edb.8; Thu, 21 Jan 2021 20:39:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5++S6kqp+vSYPLxmfs0XQH3fjKEM6tSDCybqC9HEAr4=; b=jiBTwv9RIWEAffaj7PW/QorO/MhyC9WyLFzAXqRfMXLlmUNmpmFxCu1WAwzA0H9pWB puNacPtRCUs8tS5yGY26YGWC8gh1JKScKezuIaJn0cVpl+GtIeRHtgijbEXI5v9liwTe UwkoixH5Fc7Y9X9rUaJUnJNoIyL7IM+xWEOOyy372wlFBzPS+U/rj9qrRp8qBjNIUSMc PgzbOD9BncZiRDXsQU61NQkVGglNwNqenaCfCMbRY0V4hVjzsMqhLhHn/6x6hLsI0S0z P89Kf1gh7nH0V5m9dphjOHe9WKS1pFQS+F4MWuoWSXC0DYo5FdPFEwqXI/xplgEAP8ay nVOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5++S6kqp+vSYPLxmfs0XQH3fjKEM6tSDCybqC9HEAr4=; b=fRY57hWRKPQ7jk3x5bow4y8IbihWCvB/ddtV/b4s59wS2Cj5T6gp6mULHj5pxr2F9s knOdTvCXC3A5OU4KJR+7oSb9mzCjbM/Ls+/K/QxEu0GPFa5KizjAyA4k4E5tODID46Ht 0qz3+MfHuExkmbLUO4wtFbh5lcebLC1jDmdWaEQN8OJd2qIZiXNtrc9m6tOcmTVHyjKa O1W4UUP1xugosylG7LlyF+bxQsuhyxGtulItpdpVOrgvE4SDcgJS8yWDVTJrQC5W1twS c0vU4aJlRS88VRR19g+NRhFrQdkrKQWGsFOuJ092Bid3r0/M6jLWEhfbtMogV/DRZaOh YGIw==
X-Gm-Message-State: AOAM531TnODAjjy9myvQlgFoxShzm5FJ/bAFBjaqTtJRi97C4SaILJiE fOsK2wGHWH6FG3FMdIub3NNTrOT3gB3NnaPHrOU=
X-Google-Smtp-Source: ABdhPJwRNujTnk+GOocw5Svt133tDBAwSzIh4fKVQDIRM4rC9adW2Xti/sGS5ySvsZAruPJSfR1USuUA4gErcjjTtzk=
X-Received: by 2002:a50:ec05:: with SMTP id g5mr1801873edr.182.1611290375994; Thu, 21 Jan 2021 20:39:35 -0800 (PST)
MIME-Version: 1.0
References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D939966D9@DGGEMM532-MBX.china.huawei.com> <CAF18ct4nYsk9nNBN0enCeLwhUuSF1Quy+MTUoe7Gb3yYmjOU2w@mail.gmail.com> <aae1d163a31b4ff8b31c4f90751c3d0c@huawei.com> <SA0PR13MB408027C75E2F3FAACCC8404CE8A19@SA0PR13MB4080.namprd13.prod.outlook.com>
In-Reply-To: <SA0PR13MB408027C75E2F3FAACCC8404CE8A19@SA0PR13MB4080.namprd13.prod.outlook.com>
From: Sridhar Bhaskaran <sridhar.bhaskaran@gmail.com>
Date: Fri, 22 Jan 2021 10:09:19 +0530
Message-ID: <CA+3a8OYUPpUyd56PFC48g=sr9OvaQb82qOvUv9znYXm3Y+vWQw@mail.gmail.com>
To: Kaippallimalil John <john.kaippallimalil@futurewei.com>
Cc: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, Uma Chunduri <umac.ietf@gmail.com>, Lizhenbin <lizhenbin@huawei.com>, "apn@ietf.org" <apn@ietf.org>, dmm <dmm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007dc03905b975c688"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/vxmmSr4YlLs8KzAA4DEd6Eg_uUc>
Subject: Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2021 04:39:59 -0000

 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.kaippallimalil@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-bounces@ietf.org> *On Behalf Of *Gengxuesong (Geng
> Xuesong)
> *Sent:* Wednesday, January 20, 2021 8:23 PM
> *To:* Uma Chunduri <umac.ietf@gmail.com>; Lizhenbin <lizhenbin@huawei.com>
> *Cc:* apn@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-bounces@ietf.org <apn-bounces@ietf.org>] *On
> Behalf Of *Uma Chunduri
> *Sent:* Tuesday, January 19, 2021 3:17 AM
> *To:* Lizhenbin <lizhenbin@huawei.com>
> *Cc:* apn@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 <lizhenbin@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