Re: [Idr] 3GPP SSC Mode 3 in draft-dunbar-idr-5g-edge-compute-app-meta-data-03

Gyan Mishra <hayabusagsm@gmail.com> Sat, 13 November 2021 04:14 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BF53A1075 for <idr@ietfa.amsl.com>; Fri, 12 Nov 2021 20:14:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 s5uOlRZUeArT for <idr@ietfa.amsl.com>; Fri, 12 Nov 2021 20:14:25 -0800 (PST)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 56CEF3A1070 for <idr@ietf.org>; Fri, 12 Nov 2021 20:14:25 -0800 (PST)
Received: by mail-pf1-x42d.google.com with SMTP id o4so10039547pfp.13 for <idr@ietf.org>; Fri, 12 Nov 2021 20:14:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LYG6DhXfAnXvzW91Biw1MKC8o7fILF1C1Pnf1CID9nE=; b=kXh2ClgKQESRFBvMyBaATbjGXXbbGc+4dHG/wXPfw/UKZ5Ryl75xzFk8pXSpOV5o4p +dQzhAPbnRGnI8keZH5ElQJbFFX5FSsD4YN4RWqFTjfnmfNYebvhsfGRmx+G98a6Ix8v nSmk+sUDPWsahNdEYXFUmCXbytJ8mACrzz560+Zb3MOWXNFgNgOeTGjoq3EVZ3mgsOyI itTcr+i+6G3uPMBmac8RIS5Wge4Pm6MfGQN025iqclIK2iKBrwPvlbqpQyYGI6DJL1Rx 1vy5vcAgmFe5hqKpoIWKedI17zEDL7YzmoR5s12OYwxI4jzqq7rxkFMaW4wow/VR/WmB zlGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LYG6DhXfAnXvzW91Biw1MKC8o7fILF1C1Pnf1CID9nE=; b=N2bVlew+rlXrck/nQT8faTEcCA1KKaj0K+yh23zSkHW9VHy7U//BDqXPlhiIxyGUfw uQV3ZNApHGu27ZVAa+PCFJOIL7YPI+HR8q2kyUTr7uZVM98TqBWeqMyij7PxHoO6Fru0 SBWVtBed6seuHi1gZf8dashsw0Dvf7ZTUhX9Q6TM+XYZ2N1wLXedqkqR/S+R7JW0f9Mz JfyZ4Gr91gElOHPZKbuCyMJDBZ4bYhEAnLh2V92VA8gJOk5f8nTEmyPoCUc1o4DOYoxN 0q4E9U4xZ++T+P7gqixmTLCflbWclbfHf3a2nvij7UsR46cYAYbX9+da6xmykOg3N0jD 4mJw==
X-Gm-Message-State: AOAM531kw4Tf5+Hgu++IK4Fb5rSQYBfiWqkUEWUnGRxpkUPUI6JeCCw4 2cahsqomDCYqkCv+jcHS8QPY27gDSCNb4w7FkOTGDXXT
X-Google-Smtp-Source: ABdhPJyU78PFBfEbRO8vgEH56GJvloOMKX+3j8v81/HcsaWBieOVC/9x1HKt/oOtYr5Lq/fN8TJlatW7GFmASXIV4io=
X-Received: by 2002:a63:86c1:: with SMTP id x184mr11623729pgd.469.1636776864121; Fri, 12 Nov 2021 20:14:24 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR05MB56540004802EC81C76F3BBE2D4949@BYAPR05MB5654.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB56540004802EC81C76F3BBE2D4949@BYAPR05MB5654.namprd05.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 12 Nov 2021 23:14:13 -0500
Message-ID: <CABNhwV3Q6fetANGWn47KUgqDLsxQ3wex3HM4VV7vQE28ZeNZ9w@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009005aa05d0a3cfce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LU33ZyHEdUt2He1v-7-StdjCeMA>
Subject: Re: [Idr] 3GPP SSC Mode 3 in draft-dunbar-idr-5g-edge-compute-app-meta-data-03
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Nov 2021 04:14:30 -0000

Hi Jeffrey

I read the text as well and as long mode 1 the address does not change and
mode 2 it does change and mode 3 is dual homed is like a MOB (make before
break) where it disconnects the old IP once the new is established.

So mode 2 is the where the session will reset

https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/15.02.00_60/ts_123501v150200p.pdf

Mode 3

After the new IP address/prefix has been allocated, the old IP
address/prefix is maintained during some time indicated to the UE via NAS
signalling (as described in TS 23.502 [3] clause 4.3.5.2) or via Router
Advertisement (as described in TS 23.502 [3] clause 4.3.5.3) and then
released.


If a PDU Session of SSC mode 3 has multiple PDU Session Anchors (i.e., in
the case of multi-homed PDU Sessions or in the case that UL CL applies to a
PDU Session of SSC mode 3), the additional PDU Session Anchors may be
released or allocated.

5.6.9.3 SSC mode selection
The SSC mode selection policy shall be used to determine the type of
session and service continuity mode associated with an application or group
of applications for the UE.

I wonder what determines what mode is used by the N6 interface.

Thanks

Gyan

On Thu, Nov 11, 2021 at 3:27 PM Jeffrey (Zhaohui) Zhang <zzhang=
40juniper.net@dmarc.ietf.org> wrote:

> Hi Linda,
>
> In draft-dunbar-idr-5g-edge-compute-app-meta-data-03 there is the
> following updated text:
>
>    When the UE moves out of coverage of its current gNB (next-
>    generation Node B) (gNB1), handover procedures are initiated,
>    and the 5G SMF (Session Management Function) selects a new
>    UPF-PSA. The standard handover procedures described in 3GPP TS
>    23.501 and TS 23.502 are followed. When the handover process
>    is complete, the UE is anchored to the new UPF-PSA, meaning
>    the packets to/from the UE is carried by the GTP tunnel to the
>    new UPF-PSA. The UE usually maintains its IP address when
>    anchored to the new UPF-PSA unless the new UFP-PSA belongs to
>    different mobile operators. 5GC may maintain a path from the
>    old UPF to new the UPF for a short time for the SSC [Session
>    and Service Continuity] mode 3 to make the handover process
>    more seamless.
>
> It's different from -02 which says that a new address would be assigned. I
> am curious which is correct -
> *http://4g5gworld.com/blog/session-and-service-continuity-evolution-5g-networks*
> <http://4g5gworld.com/blog/session-and-service-continuity-evolution-5g-networks>
> says that only mode 1 (where the anchoring UPF does not change) maintains
> persistent address. That seems to be consistent with 23.501:
>
> ---------------------23.501------
> 5.6.9.2.3       SSC Mode 3
> For PDU Session of SSC mode 3, the network allows the establishment of UE
> connectivity via a new PDU Session Anchor to the same data network before
> connectivity between the UE and the previous PDU Session Anchor is
> released. When trigger conditions apply, the network decides whether to
> select a PDU Session Anchor UPF suitable for the UE's new conditions (e.g.
> point of attachment to the network).
> In this Release of specification, SSC mode 3 only applies to IP PDU
> Session type and to any access type.
> In the case of a PDU Session of IPv4 or IPv6 or IPv4v6 type, during the
> procedure of change of PDU Session Anchor, the following applies:
> a.      For a PDU Session of IPv6 type, the new IP prefix anchored on the
> new PDU Session Anchor may be allocated within the same PDU Session
> (relying on IPv6 multi-homing specified in clause 5.6.4.3), or
> b.      The new IP address and/or IP prefix may be allocated within a new
> PDU Session that the UE is triggered to establish.
> After the new IP address/prefix has been allocated, the old IP
> address/prefix is maintained during some time indicated to the UE via NAS
> signalling (as described in TS 23.502 [3] clause 4.3.5.2) or via Router
> Advertisement (as described in TS 23.502 [3] clause 4.3.5.3) and then
> released.
> If a PDU Session of SSC mode 3 has multiple PDU Session Anchors (i.e., in
> the case of multi-homed PDU Sessions or in the case that UL CL applies to a
> PDU Session of SSC mode 3), the additional PDU Session Anchors may be
> released or allocated.
> ------------------------
>
> In fact, I introduced a proposal in 3GPP to assign persistent addresses in
> Release 17 EC Enhancement SID. It was accepted in the early stage but I was
> not available to defend the proposal when it came to the final conclusion
> stage so it was not eventually taken to WID. It would be nice if we could
> push that through in Release 18.
>
> Thanks.
> Jeffrey
>
>
> Juniper Business Use Only
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*