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

Kaippallimalil John <john.kaippallimalil@futurewei.com> Fri, 29 January 2021 16:55 UTC

Return-Path: <john.kaippallimalil@futurewei.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 B97723A1167; Fri, 29 Jan 2021 08:55:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 OLxnzdUNhkQ3; Fri, 29 Jan 2021 08:55:39 -0800 (PST)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2098.outbound.protection.outlook.com [40.107.243.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67E03A1164; Fri, 29 Jan 2021 08:55:38 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZFerJsY+qRrceZI5d/d2ECxu/rwYsT1cg1vENXrw9m2Ta2ZUdtXnHCs8nUF6pCF5MNCd3Gcv3tl43h+/F3a9D1YLDY8XJzHgH23FKZJaf6EO+OVn2OgLO1Y/ipXSwwd6ZuP+emxg167ETWdPI9FbJ9XSnQHvEnSYZzoChefPsplOn06/QDgWDA0QgJPcDFZqRIV9Y79n6+q5dJPx7jMVeMAihjajFd60R5jIqaofnSq7hEtcn3LD5j0ZZqIb1bks8049nKM91vJfHcnuhpjrtJllmCp9HkTve0ouv+N+/tsIKc3KWiE3ozR9T+BCBxInpZt3/jyqA8IrivnFkaZ6AA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HZbneIt7eSfGDCK9QbfMSMFXG0bcEQIClO7HKqQXL2w=; b=SlCYarpNRO4bH2UXH18hwaunrXhJiLBJAqUUPYHgadL3Mk778SmA/QQFUAdP1fAhqcaO8Q0tGUOIMbQiJhsEjjRjDO0WYTYVHTbx6VthpuFmSaBCCf5ePnapZ5v4NAywfggHirwJvjDDCloESpVtPQya/vqCJ96R8CBIjcicqWRGPeynEf0aWJsvvscYgjEZ3yPMTRQnkzj2hXRZcdPctRQ+kqC5gJ25NhJ9gFyv6OSg4v8DKCACtplBELy15g1IuvrRsBjH7DEoUfQ+OzG1BnEMzSv9Iky5ehCjBZ9pbG5CzF0k8mY2MDjfiobRL8Kl2Ke92BSSpWCPJWGqwuzElg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HZbneIt7eSfGDCK9QbfMSMFXG0bcEQIClO7HKqQXL2w=; b=j2oFvXJTq+kwv32TqD8imq69gIEA7ZHs1Bu2hoRSLayHwVkRqlG5yEStwNaDTl9lJv5m420tNsam0DGKpH8VFJqZk528nhUrfF9MV9KF+llpGJuHujBGsiIEpfO6ALxngJe5xbAeRDorxbholYNd1xtBv9ZNsnnuiEunRlb+NpI=
Received: from (2603:10b6:806:9b::22) by SA1PR13MB4992.namprd13.prod.outlook.com (2603:10b6:806:186::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.8; Fri, 29 Jan 2021 16:55:33 +0000
Received: from SA0PR13MB4080.namprd13.prod.outlook.com ([fe80::4d5d:4f1a:ccd2:4863]) by SA0PR13MB4080.namprd13.prod.outlook.com ([fe80::4d5d:4f1a:ccd2:4863%4]) with mapi id 15.20.3825.010; Fri, 29 Jan 2021 16:55:33 +0000
From: Kaippallimalil John <john.kaippallimalil@futurewei.com>
To: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, Uma Chunduri <umac.ietf@gmail.com>, Lizhenbin <lizhenbin@huawei.com>
CC: "apn@ietf.org" <apn@ietf.org>, dmm <dmm@ietf.org>
Thread-Topic: [DMM] [Apn] Regarding APN Usecase in Mobile Core
Thread-Index: AQHW75xrkd2Ql7I3CUy/a8odgG8eZqoydanggAv2bICAAGIMMA==
Date: Fri, 29 Jan 2021 16:55:33 +0000
Message-ID: <SA0PR13MB4080548CA69DDD2FAD89A83DE8B99@SA0PR13MB4080.namprd13.prod.outlook.com>
References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D939966D9@DGGEMM532-MBX.china.huawei.com> <CAF18ct4nYsk9nNBN0enCeLwhUuSF1Quy+MTUoe7Gb3yYmjOU2w@mail.gmail.com> <aae1d163a31b4ff8b31c4f90751c3d0c@huawei.com> <SA0PR13MB408027C75E2F3FAACCC8404CE8A19@SA0PR13MB4080.namprd13.prod.outlook.com> <6c0e8164b76748e5ab21fc6f2d280e2b@huawei.com>
In-Reply-To: <6c0e8164b76748e5ab21fc6f2d280e2b@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [12.111.81.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7fce39cd-55d6-4293-5e66-08d8c476b168
x-ms-traffictypediagnostic: SA1PR13MB4992:
x-microsoft-antispam-prvs: <SA1PR13MB49922AAB401D24601BE83912E8B99@SA1PR13MB4992.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: h3q0rIH5PGFkjjWXLadEmvHMZFx0wVLW4/U8icizVafxMHuHFm0f9TEb9mdT9x1vEjp74w3SmscWKwFFuig0FGc3f3TMsG2mXVVOp2iMQ02Wblt/4wSewO7kDVDO29DUheTxFtN4jtGz4VQGu0Fe2m5m+WrIDTkqrX/yVXbhjrDfrk6fXJkz5OHEScDrmOjkk5Im4rkieIfyAaYhYwqmliFBqrI2p/o9XiAaVMtSG/9sGxWZkZX+GEC2jrkHJgGRnWrMmXZ4b2gT89ALv7F7O8fsMbCAVqMLljLfrLIM7FsquFQghxrhJS6P6GqGsi0p/YZGHfLHJzW5KIhSYBwinDj84n+Y21dKCYPkPM+q+u3cNQRZNcyat/cIvteQY/SAkEX/bvqIB0RTJNwGmV3ftHlJHy9gv76BxRY0NIrtAaurEGCf7Rdo1agmYnR4BT8kbIp0LAgwMffYpNZBebHIIH15aBdAktzNzwvSoB8MNG4KDcH1am+Vg7nD3y23W5idLBdMEOQUbGl1zATqYpIaPBG8Q34RN8ddFVg/RrSsEK1ZFgj79ZMfgXXX2b1GcRDsFpbFVpM3PDviVlTsiHdqabY5CMIDjDNK6fuklpzPCAk=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR13MB4080.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(136003)(39850400004)(346002)(376002)(66556008)(4326008)(55016002)(66476007)(966005)(53546011)(8676002)(7696005)(26005)(71200400001)(186003)(6506007)(66446008)(52536014)(64756008)(66946007)(478600001)(76116006)(9686003)(110136005)(316002)(33656002)(2906002)(86362001)(8936002)(9326002)(5660300002)(54906003)(166002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: dkuLeOqK61xrJdhvF9I7ufmxsC9x9yrU0qEuIaFN5nRX8B6GfTYCKauydrq1bFWKXK5FFPbsEDbrgOAKcOetKG6GomqLwDbRllCzA8f6LTH64GniRjTiVV/9fWdefyzaN/qAEGkIpv+SuQ/FzNVEu+SpYGtjCdV9ueEQ49BfNuAWCgb1RjsYO07cfVxY0rrl3IxZPuGgPkGk+ry9jW3PWJyQrgGgncv6ycDP7foEar3FN1sWpOfyR8+K9Kv8Q5HlxZRcq/+MvjXfnw+2I6gew3fZ3DjX0/45u4blKPf1YDqJ9c4vCBR8M/TJd7dHn6lXSubi6jk1dX22MrEyj0ZKoNOmxzTq0vr8NSXyqOcMGR1OJ/03c7euhIaI8DYMneZc4sXUW7iunxwtmm/bl0cvhsD7ZuJIucwnfxtAMAtJRcOAYPP0ZSNtlCsMlCX1UERShEWys34q8Egv6gGDxCLlG4p8zUdda6htYtM23XclKiz7s/ztekcpq8Gk7fGD0C0mg88NwLQVYPWQDoM8mf1Yzxb977Sz8SaLbPYWVdONKBla3dfMfDqLwSwmVKpdsCGlgkLhl5Rx+BiHwjp+LilLQPcjDgc60913nv8bEsOkW9rbIwQg183ER9ttDEeHNszjQdJfEIq/kHbb81LX4vT4t506kDR0FGm/41GmC7M3dP2/KTvSq4wX7B3p6+0ZGzyLOkQXEkOLcYzZIcI3eTl8eGFxvj5NuHHCDuHVIfQGx2F0BvK1u9UnROz+ffn9FEcrPicwuzY/f9OJzTttjzQeI0HOR2+OYi+iQU5uXAQy5q813QCdNA7m704Vw02kxW7XiJ4mMfwveXb4ztC3F5LbgCl8XD511tjwANtRyvy+Ju1fKkqfa4fQkXXOlG4hNr6AM8A6L5Yat2Klb1xrAlAdQ4hwYxQpaxLLlpkhJiLnGqWV6NN45G3E8y3HJkAZDXowSg6bn61hipG8/RMDfzVu3DVi7Bm2UxANeV79Z2NPMBpztcwv7CMv6GQGwxSxT7rXK3H/x9GHp+ed6CMksvwsxcY0WV6ULP1owTXyvKFJBV0tXlwjYIxldRITUs+46ANU
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SA0PR13MB4080548CA69DDD2FAD89A83DE8B99SA0PR13MB4080namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA0PR13MB4080.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7fce39cd-55d6-4293-5e66-08d8c476b168
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2021 16:55:33.3143 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /CLsfRH2AWzcdWmH+I99A3Zrvt1WU/cb2pZNSWo8LMotlkBDEip72hIXvwwK77xs2+JedtxUeTsXfjROSh6y7g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR13MB4992
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/lRweWp-Ntp12_5JyCJx29c2q9rQ>
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, 29 Jan 2021 16:55:42 -0000

Hi Xuesong,
The point on using GTP-u extension header for classifying each packet was that unlike classifying using DSCP (which is in the IP header), finding the QCI in GTP extension requires more searches. And the control fields in GTP-u are for signaling between the 2 GTP end points (gNB, UPF, etc).

Now with regard to DSCP, since it is a mutable field, the value can be changed on path. It may be suitable in some deployments but not as a general solution.
In a gNB or UPF, there is already the subscriber context for a session and identifiers like radio bearers or IP address (upstream/downstream) to classify incoming packets.
E.g., a UPF may look up session context indexed by a UE IP address, retrieve QoS, reliability, etc , classify and select MPLS label L (or a DSCP value in some cases).
However, when there is a gNB or UPF function deployed in one network and IP transport is provided by another network, DSCP may not be able to convey slice aspects for a path across two different networks (this apart from DSCP being mutable).

Best Regards,
John

From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
Sent: Friday, January 29, 2021 4:01 AM
To: Kaippallimalil John <john.kaippallimalil@futurewei.com>; 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 John,

You mentioned that "5QI/QCI etc are in the GTP extension header which may not be ideal to lookup to classify each packet in the transport network". This is slightly different from my understanding about this: 5QI/QCI belongs to control plane information, and when the base station encapsulates the packet with GTPu, it maps the 5QI/QCI into the DSCP in  IP header outside GTPu encapsulation. Do I have any misunderstanding about this point?

Best
Xuesong

From: Kaippallimalil John [mailto:john.kaippallimalil@futurewei.com]
Sent: Friday, January 22, 2021 5:25 AM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; Uma Chunduri <umac.ietf@gmail.com<mailto:umac.ietf@gmail.com>>; Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>
Cc: apn@ietf.org<mailto:apn@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [DMM] [Apn] Regarding APN Usecase in Mobile Core

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<mailto: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<mailto:umac.ietf@gmail.com>>; Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>
Cc: apn@ietf.org<mailto:apn@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-bounces@ietf.org] On Behalf Of Uma Chunduri
Sent: Tuesday, January 19, 2021 3:17 AM
To: Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>
Cc: apn@ietf.org<mailto:apn@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 <lizhenbin@huawei.com<mailto: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%7C8d3a8d34ea0049ed523f08d8c43ccbc9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637475112703506588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=r6m55gGEQqmacjcKy21wzksXsCzvxLBF%2Fx%2FqUFFxFPU%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%7Cjohn.kaippallimalil%40futurewei.com%7C8d3a8d34ea0049ed523f08d8c43ccbc9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637475112703506588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5lmTCot3wizMZWRXkGRQDP8c03xbCGVOqNIBo1tplx0%3D&reserved=0>