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

Sridhar Bhaskaran <sridhar.bhaskaran@gmail.com> Mon, 01 February 2021 04:42 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 4B0C83A13F3; Sun, 31 Jan 2021 20:42:34 -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 iyOVXDVvq3Qi; Sun, 31 Jan 2021 20:42:31 -0800 (PST)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 D22E93A13F2; Sun, 31 Jan 2021 20:42:30 -0800 (PST)
Received: by mail-ej1-x631.google.com with SMTP id w1so22169904ejf.11; Sun, 31 Jan 2021 20:42:30 -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=ZHpA8yy240P0pU1hUhmRERmXtmxu4w7Lv6Wop+scTqU=; b=P1AHfkETEya3M0wSXBPV7pJoCZ3qYLEz9VipOInK0UPR9xcb3QAM5FOFAiNY27HODr sLDOL5RxEbJ53ovqFiEDDciTeQqTUn42rWjv6WkUxNe/mDHHdIhdNu7pLXKAyrvWwS3h nL5LEMAKrC4RwXMpBMXS7ujx4SNvMq9tGNT6aAGPNpDa/p0CE62/U2fqZpfcbYbJZ9S5 GcwW+OFFD6hG/qVaoHdaJ0maD6hZGgm/+lyGP+PuNa8iJrB0/YkvKpteBCptYurLo5Mg 5R3ST7NAJHRhlQcfc9UfL3i8dMudCHPbkPRDY583s+Htnd6HUf4vtNhRcsoAR4XmFdns iypw==
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=ZHpA8yy240P0pU1hUhmRERmXtmxu4w7Lv6Wop+scTqU=; b=rl3qKrANehi+0RZqb965v/5uHIqS7tG/4881fL+wY/wqg1L7rNTV6N6AJ36PXNA/8t fHQV4vkcaDgrZE2Mg0LKi6ZvWTWaHb2TsaUz9FfXqvPVBXMqa2hXIEh8NTvryMVMfaDx nN3tl2ICgg84vgm+xPiffCHOAbtYNwID4CF9Na8i9C73FK7dbI84eSvXvvqbfpdPedok hGtD7X6Q5on/SXVjA3iaysRbssLWpCpPB20tPG5iprFi/UNj124fu3XXlIPAKNWWSJ3Z 67QJYdYPoyDvR3BjeTN6LSaZIwWh5ZBU9Y2ZgmF2QULjSP/oTD7GGdzreyRSlfCz9cq4 kQcQ==
X-Gm-Message-State: AOAM532YOxEfeLR27JXll55Mf62d50nbmNUudcF7Cmhfwq6lUGWP90TV /uzVGFVI3DjsFgCm7ukr9KlTxLwUPBKXuzpu/vI=
X-Google-Smtp-Source: ABdhPJz9M5/2/db36dSBoWOU0xXALehTFjsmuCVhwhsb6+MIBm8i8IkmSnu6sfWagVipdX2DQyaBUQ98t0Z9E4seMx8=
X-Received: by 2002:a17:907:1181:: with SMTP id uz1mr8338218ejb.60.1612154549141; Sun, 31 Jan 2021 20:42:29 -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> <CA+3a8OYUPpUyd56PFC48g=sr9OvaQb82qOvUv9znYXm3Y+vWQw@mail.gmail.com> <ab90f474c10048f6b552d863e981a945@huawei.com> <CA+3a8OaEA02oZ8Oo2mHTzX+atK1bufkNOei64XG=96uPsVGfYA@mail.gmail.com> <1fe994365b33407984374f4cdd224911@huawei.com>
In-Reply-To: <1fe994365b33407984374f4cdd224911@huawei.com>
From: Sridhar Bhaskaran <sridhar.bhaskaran@gmail.com>
Date: Mon, 01 Feb 2021 10:12:16 +0530
Message-ID: <CA+3a8ObO_QFR_bKz_ft6qi-3p3OqeLOyz8Z=W4FZvosgckqKBg@mail.gmail.com>
To: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
Cc: "apn@ietf.org" <apn@ietf.org>, Uma Chunduri <umac.ietf@gmail.com>, Kaippallimalil John <john.kaippallimalil@futurewei.com>, dmm <dmm@ietf.org>, Lizhenbin <lizhenbin@huawei.com>
Content-Type: multipart/alternative; boundary="0000000000003983c605ba3efb70"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/nE1ryvgOg3LKonNmqefvCktzRP0>
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: Mon, 01 Feb 2021 04:42:34 -0000

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?

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.

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.

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)

Regards
Sridhar

On Mon, Feb 1, 2021 at 8:10 AM Gengxuesong (Geng Xuesong) <
gengxuesong@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-bounces@ietf.org] *On Behalf Of *Sridhar Bhaskaran
> *Sent:* Friday, January 29, 2021 8:06 PM
> *To:* Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
> *Cc:* apn@ietf.org; Uma Chunduri <umac.ietf@gmail.com>; Kaippallimalil
> John <john.kaippallimalil@futurewei.com>; dmm <dmm@ietf.org>; Lizhenbin <
> lizhenbin@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) <
> gengxuesong@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.bhaskaran@gmail.com]
> *Sent:* Friday, January 22, 2021 12:39 PM
> *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; 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.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
>
>
>
> --
>
>  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