Subject: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

From: "Majumdar, Kausik" <[email-masked]>
Date: Wed, 11 Aug 2021 01:06:51 +0000

Hi All,

I have presented our draft draft-mcd-rtgwg-extension-tn-aware-mobility-02<https://datatracker.ietf.org/doc/html/draft-mcd-rtgwg-extension-tn-aware-mobility-02> in the IETF 111 on behalf of other co-authors. There are some questions and comments in the IETF for this presentation. We felt it would be good to review those comments over email thread to sort those out.

Here are the different comments we have captured - it was either through Meetecho session chat window or over direct Q&A after the presentation. Please feel free to add any other comments you have.

@Jeff Tantsura
3GPP TS 23.501; System architecture for the 5G System (5GS) - a good reference13:39:32

KM>> Thanks Jeff. We will capture this reference in the next version of the draft.

@Jie Dong
my understanding is this (UDP source port) may be one of the options to map 3GPP SSTs or slices to transport network, there is a draft about the network slice mapping in teas WG: draft-geng-teas-network-slice-mapping which analyzed several options. That said, some coordination with 3GPP may be needed on which field they will use to for the mapping.

KM>> Yes, UDP Source Port is simply one of the option to map 3GPP SSTs or slices to the transport network. The existing dmm draft - draft-ietf-dmm-tn-aware-mobility-00 uses UDP source port range to define the different SSTs (MIOT, URLLC, EMBB, etc) in the Mobile Network and here we are extending the same mechanism in the Data Network as part of the RTG draft.

@Eduard
Why only UDP Source Port is being used for the Traffic Characterization in the Mobility and Data Networks?

KM>> The GTP Tunnel inner packet can carry any L4-L7 packet types (TCP, UDP, QUIC) and that can continue in the Data Network, there is no such restriction on that. But when comes to packet characterization we have tried to keep the mechanism consistent across the Mobile and Data Network. As in the Mobile Network the UDP Source Port range is being used for characterizing different SSTs we have extended the same in the Data Network so that end to end SLA is maintained for the UE traffic.

@Cheng
Why there are multiple mapping methods is proposed in the Data Network?

KM>> We believe that multiple mapping method in the Data Network provides the Operators flexibility in the mapping mechanism. Based on the deployment model the Operators should be able to characterize the traffic belongs to different SSTs and map to the corresponding SLA driven path based on the SR driven policies.

@Acce
Two questions:

  1.  Same as Cheng.
  2.  Why is SDWAN with Security treated as a separate Use Case? Why not be Security appliable in the regular SR-TE Network?

KM>> We have kept SDWAN as a separate Use Case for the Enterprise 5G. Here Mobile traffic ending up going through the Enterprise GW/CE device. These traffic mostly destined to the Cloud GW to access different SaaS applications. The SDWAN CE devices generally provide different Tunneling mechanism for taking the traffic in a secure fashion to the Cloud GW. Hence security is considered as important characteristics for the Mobile traffic to go over SDWAN network to the Cloud GW and given a priority in terms of choosing the appropriate SDWAN tunnels.

On the other side, when the Mobile traffic comes to the Ingress PE node there traffic goes over provider VPN network and that's a secure network in general. In that network, characterizing the different SSTs and maintaining the SLA specific to each SST is more important.

We felt keeping it two separate use cases one for carrier SR-TE network and the other one for the SDWAN type of deployment scenarios, the mapping mechanism clarifies it better.

If you have further comments/questions please let us know and we can discuss that further.

Regards,
Kausik

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 11 Aug 2021 07:54:05 +0000

Hi Kausik,
As a result of the discussion following my question, it has been understood that it is not just your assumption that gNodeB would use different source UDP port range for different application.
Jeff Tantsura was even immediately taken from the thin air 3GPP TS 23.501 that makes sense to reference as normative.
What is still important to understand: is this requirement mandatory for gNodeB implementation?
If yes, then excellent - just reference and abuse.
If not, then how many vendors implemented it? Because it is a pre-requisite for you.

The reference to any IETF draft would not help if functionality is needed from gNodeB.
Eduard
From: rtgwg [mailto:[email-masked]] On Behalf Of Majumdar, Kausik
Sent: Wednesday, August 11, 2021 4:07 AM
To: RTGWG <[email-masked]>
Subject: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

Hi All,

@Jeff Tantsura

@Jie Dong

@Eduard

@Cheng

@Acce
Two questions:

  1.  Same as Cheng.

Regards,
Kausik

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 11 Aug 2021 17:20:53 -0700

Hi Eduard,

in-line [Uma]:

--
Uma C.

On Wed, Aug 11, 2021 at 12:54 AM Vasilenko Eduard <
[email-masked]> wrote:

> Hi Kausik,
>
> As a result of the discussion following my question, it has been
> understood that it is not just your assumption that gNodeB would use
> different source UDP port range for different application.
>
> Jeff Tantsura was even immediately taken from the thin air 3GPP TS 23.501
> that makes sense to reference as normative.
>

[Uma]: Yes. This is much debated and documented in
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility
            The approach taken there is management plane or AF related
changes (as opposed to any change in the 3GPP control plane). These are by
definition deployment specific and many
            deployments have knobs to do this.

> If yes, then excellent – just reference and abuse.
>
[Uma]: For many "LTE slicing" (if I may allow to be used, as it has become
sort of abusive word) deployments today use UDP source port as those nodes
can't be upgraded with new  data planes with many bells and whistles (it's
noble, please go ahead and  use those and let gNodeBs emit those
eventually). And also remember,  it doesn't help to put that information in
GTP overlay (IEs or extension headers), for the ingress PE to look into to
and act accordingly. All these options were discussed many times in the DMM
WG and was presented last year.

The reference to any IETF draft would not help if functionality is needed
> from gNodeB.
>
> Eduard
>
> *From:* rtgwg [mailto:[email-masked]] *On Behalf Of *Majumdar,
> Kausik
> *Sent:* Wednesday, August 11, 2021 4:07 AM
> *To:* RTGWG <[email-masked]>
> *Subject:* IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft
>
>
>
>
>
> Hi All,
>
>
>
> I have presented our draft draft-mcd-rtgwg-extension-tn-aware-mobility-02
> <https://datatracker.ietf.org/doc/html/draft-mcd-rtgwg-extension-tn-aware-mobility-02>
> in the IETF 111 on behalf of other co-authors. There are some questions and
> comments in the IETF for this presentation. We felt it would be good to
> review those comments over email thread to sort those out.
>
>
>
> Here are the different comments we have captured – it was either through
> Meetecho session chat window or over direct Q&A after the presentation.
> Please feel free to add any other comments you have.
>
>
>
> *@Jeff Tantsura*
>
> *@Jie Dong*
> my understanding is this (UDP source port) may be one of the options to
> map 3GPP SSTs or slices to transport network, there is a draft about the
> network slice mapping in teas WG: draft-geng-teas-network-slice-mapping
> which analyzed several options. That said, some coordination with 3GPP may
> be needed on which field they will use to for the mapping.
>
>
>
> KM>> Yes, UDP Source Port is simply one of the option to map 3GPP SSTs or
> slices to the transport network. The existing dmm draft -
> *draft-ietf-dmm-tn-aware-mobility-00* uses UDP source port range to
> define the different SSTs (MIOT, URLLC, EMBB, etc) in the Mobile Network
> and here we are extending the same mechanism in the Data Network as part of
> the RTG draft.
>
>
>
>
>
> *@Eduard*
>
> KM>> The GTP Tunnel inner packet can carry any L4-L7 packet types (TCP,
> UDP, QUIC) and that can continue in the Data Network, there is no such
> restriction on that. But when comes to packet characterization we have
> tried to keep the mechanism consistent across the Mobile and Data Network.
> As in the Mobile Network the UDP Source Port range is being used for
> characterizing different SSTs we have extended the same in the Data Network
> so that end to end SLA is maintained for the UE traffic.
>
>
>
> *@Cheng*
>
> KM>> We believe that multiple mapping method in the Data Network provides
> the Operators flexibility in the mapping mechanism. Based on the deployment
> model the Operators should be able to characterize the traffic belongs to
> different SSTs and map to the corresponding SLA driven path based on the SR
> driven policies.
>
>
>
> *@Acce*
>
> Two questions:
>
>    1. Same as Cheng.
>    2. Why is SDWAN with Security treated as a separate Use Case? Why not
>    be Security appliable in the regular SR-TE Network?
>
>
>
> KM>> We have kept SDWAN as a separate Use Case for the Enterprise 5G. Here
> Mobile traffic ending up going through the Enterprise GW/CE device. These
> traffic mostly destined to the Cloud GW to access different SaaS
> applications. The SDWAN CE devices generally provide different Tunneling
> mechanism for taking the traffic in a secure fashion to the Cloud GW. Hence
> security is considered as important characteristics for the Mobile traffic
> to go over SDWAN network to the Cloud GW and given a priority in terms of
> choosing the appropriate SDWAN tunnels.
>
>
>
> On the other side, when the Mobile traffic comes to the Ingress PE node
> there traffic goes over provider VPN network and that’s a secure network in
> general. In that network, characterizing the different SSTs and maintaining
> the SLA specific to each SST is more important.
>
>
>
> We felt keeping it two separate use cases one for carrier SR-TE network
> and the other one for the SDWAN type of deployment scenarios, the mapping
> mechanism clarifies it better.
>
>
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 12 Aug 2021 08:59:12 +0000

Hi Uma,
Yes, indeed, section 2.5 of https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility

has a detailed explanation of how “port range” *may be* mapped into “Mobile Transport Network Context”.

By the way, such abbreviation (MTNC) is not available in 3GPP TS 23.501.

I could not imagine how else it is possible to tell about “port range” without “range”.
I have looked at all “range” in 3GPP TS 23.501 – it is not about what we need here.

“Indirect next hop” reference is not typical in SDOs publications.
If you need some functionality from Mobile guys – you need to reference 3GPP directly, not through other IETF documents,
especially if this other document does not have a direct reference too.

https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility is written in such a style like it is a proposition.
Looking at the text I come even to more suspect that this functionality is not requested in any 3GPP spec. Hence, may never be implemented in any gNodeB.

Does not matter who was the first in IETF to request this functionality and who is just cross-reference it in “indirect next hop” style.
I still have a question: Who has taken responsibility to push this requirement inside 3GPP?

Direct reference to a particular section of any 3GPP document would disperse my doubts.

Because if nobody is pushing this inside 3GPP then it would never happen, independent of how many times this functionality would be cross-referenced inside IETF.

Eduard
From: Uma Chunduri [mailto:[email-masked]]
Sent: Thursday, August 12, 2021 3:21 AM
To: Vasilenko Eduard <[email-masked]>
Cc: Majumdar, Kausik <[email-masked]>; RTGWG <[email-masked]>
Subject: Re: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

Hi Eduard,

in-line [Uma]:

--
Uma C.

On Wed, Aug 11, 2021 at 12:54 AM Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kausik,
As a result of the discussion following my question, it has been understood that it is not just your assumption that gNodeB would use different source UDP port range for different application.
Jeff Tantsura was even immediately taken from the thin air 3GPP TS 23.501 that makes sense to reference as normative.
What is still important to understand: is this requirement mandatory for gNodeB implementation?

[Uma]: Yes. This is much debated and documented in https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility
            The approach taken there is management plane or AF related changes (as opposed to any change in the 3GPP control plane). These are by definition deployment specific and many
            deployments have knobs to do this.

[Uma]: For many "LTE slicing" (if I may allow to be used, as it has become sort of abusive word) deployments today use UDP source port as those nodes can't be upgraded with new  data planes with many bells and whistles (it's noble, please go ahead and  use those and let gNodeBs emit those eventually). And also remember,  it doesn't help to put that information in GTP overlay (IEs or extension headers), for the ingress PE to look into to and act accordingly. All these options were discussed many times in the DMM WG and was presented last year.

The reference to any IETF draft would not help if functionality is needed from gNodeB.
Eduard
From: rtgwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Majumdar, Kausik
Sent: Wednesday, August 11, 2021 4:07 AM
To: RTGWG <[email-masked]<mailto:[email-masked]>>
Subject: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

Hi All,

Here are the different comments we have captured – it was either through Meetecho session chat window or over direct Q&A after the presentation. Please feel free to add any other comments you have.

@Jeff Tantsura

@Jie Dong

@Eduard

@Cheng

@Acce
Two questions:

  1.  Same as Cheng.

On the other side, when the Mobile traffic comes to the Ingress PE node there traffic goes over provider VPN network and that’s a secure network in general. In that network, characterizing the different SSTs and maintaining the SLA specific to each SST is more important.

Regards,
Kausik

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 13 Aug 2021 19:29:42 -0700

Eduard,

Very good question.

Let me tell you a bit more and give context on this. For E2E desired
traffic characteristics, where the packet is transiting through RAN,
transport and 5G Core, there is some coordination and minimal exchange of
information is needed. In this case, it happens to be touching 2 SDOs and
utmost care is taken (over many individual versions) to minimise those
changes and still acceptable to deployments (management plane). In this
case, there are 2 3GPP delegates being co-authors enhanced carefully, but
still it's in a grey area where we need full blessing from 3GPP or what's
needed. For example changing UDP encap parameters were done and deployed
(yes), in earlier instances without having to specifically mention in
23.401 (LTE).  Further we did think about it to be part of the latest study
item (ongoing discussion with SA2 delegates) and also some discussions
happened in DMM to liaise further, with their official channel.

It doesn't matter if I answer your question fully or partially or not at
all, but this is what happened on this one. I would say one thing further,
no matter this work or in a different form you need to have a mechanism to
signal stuff from other SDO's domain to us to fully define the slicing work
E2E. I don't see another way.

--
Uma C.

On Thu, Aug 12, 2021 at 1:59 AM Vasilenko Eduard <
[email-masked]> wrote:

> Hi Uma,
>
> Yes, indeed, section 2.5 of
> has a detailed explanation of how “port range” **may be** mapped into “Mobile Transport Network Context”.
>
> By the way, such abbreviation (*MTNC*) is not available in 3GPP TS 23.501.
>
>
>
> If you need some functionality from Mobile guys – you need to reference
> 3GPP directly, not through other IETF documents,
>
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility is
> written in such a style like it is a proposition.
>
> Looking at the text I come even to more suspect that this functionality is
> not requested in any 3GPP spec. Hence, may never be implemented in any
> gNodeB.
>
>
>
> Does not matter who was the first in IETF to request this functionality
> and who is just cross-reference it in “indirect next hop” style.
>
> Because if nobody is pushing this inside 3GPP then it would never happen,
> independent of how many times this functionality would be cross-referenced
> inside IETF.
>
>
>
> Eduard
>
> *From:* Uma Chunduri [mailto:[email-masked]]
> *Sent:* Thursday, August 12, 2021 3:21 AM
> *To:* Vasilenko Eduard <[email-masked]>
> *Cc:* Majumdar, Kausik <[email-masked]>; RTGWG <
> [email-masked]>
> *Subject:* Re: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility
> draft
>
>
>
> Hi Eduard,
>
>
>
> in-line [Uma]:
>
>
>
> --
>
> Uma C.
>
>
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 16 Aug 2021 09:20:24 +0000

Hi Uma,
The mechanism itself (use UDP source port range for forwarding decision) looks questionable,
Because in the case of IPv6 data plane it would be difficult to parse IPv6 EH headers chain up to UDP, especially if SRH 200B+ header would be in between, potentially with Authentication header and Encapsulation Security payload header on top that is very probable in MBH environment. I do not know any ASIC that could parse all of this in the worst-case scenario.
IMHO: this mechanism looks good only for IPv4 where UDP directly follows IPv4 header.
What you need here is some VPN+ (resources reservation in TEAS terminology).
There is a dispute right now in 6man about the introduction of an additional header to show resource attachment.
MPLS guys push strongly that it should be Label. SR guys insist on SID. Jimmy (and a few others) proposes something new/small/independent/just_for_this_purpose.

In general, I see in this draft an extremely high intersection with the Slicing story. It looks like yet another one (UDP port-based).
I have put Jimmy on the copy because he knows what is available in 3GPP on slicing.

But it does not matter: if nobody pushing a particular type of VPN+ in 3GPP – it would not happen anyway. gNodeB just would not label the packet properly.

Eduard
Sent: Saturday, August 14, 2021 5:30 AM

Eduard,

Very good question.

Let me tell you a bit more and give context on this. For E2E desired traffic characteristics, where the packet is transiting through RAN, transport and 5G Core, there is some coordination and minimal exchange of information is needed. In this case, it happens to be touching 2 SDOs and utmost care is taken (over many individual versions) to minimise those changes and still acceptable to deployments (management plane). In this case, there are 2 3GPP delegates being co-authors enhanced carefully, but still it's in a grey area where we need full blessing from 3GPP or what's needed. For example changing UDP encap parameters were done and deployed (yes), in earlier instances without having to specifically mention in 23.401 (LTE).  Further we did think about it to be part of the latest study item (ongoing discussion with SA2 delegates) and also some discussions happened in DMM to liaise further, with their official channel.

It doesn't matter if I answer your question fully or partially or not at all, but this is what happened on this one. I would say one thing further, no matter this work or in a different form you need to have a mechanism to signal stuff from other SDO's domain to us to fully define the slicing work E2E. I don't see another way.

--
Uma C.

On Thu, Aug 12, 2021 at 1:59 AM Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Uma,
Yes, indeed, section 2.5 of https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility

Eduard
From: Uma Chunduri [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 12, 2021 3:21 AM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: Majumdar, Kausik <[email-masked]<mailto:[email-masked]>>; RTGWG <[email-masked]<mailto:[email-masked]>>
Subject: Re: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

Hi Eduard,

in-line [Uma]:

--
Uma C.

Hi All,

@Jeff Tantsura

@Jie Dong

@Eduard

@Cheng

@Acce
Two questions:

  1.  Same as Cheng.

Regards,
Kausik

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 16 Aug 2021 14:20:54 -0700

Hi Eduard,

It seems you completely misunderstood the scope of the work and what
needs to be done at gNodeB.

Also I recommend you to the conversations and suggestions from many DMM
participants in IETF105/106 to see where we are now.

I can't replay all the discussion back here. But -
             - There are various operators seeking to keep transport
agnostic to mobile side of the network
             - There are various network segments where GTP-U is used i.e.,
in F1U, N3, N9 and these segments can have L2, IPv4, IPv6, SRv6, MPLS etc..

You are mixing what has to be done on PE-PE on these segments (VPN+, SRv6,
MPLS etc) to what has to be done on gNodeB.

gNodeB doesn't want to know all the transport network details and slew of
possible encapsulations options available currently and/or being developed.

more in-line [Uma]

--
Uma C.

On Mon, Aug 16, 2021 at 2:20 AM Vasilenko Eduard <
[email-masked]> wrote:

> Hi Uma,
>
> The mechanism itself (use UDP source port range for forwarding decision)
>

[Uma]: You misunderstood this completely. This is not for forwarding
decision. It just indicating the slice the packet belongs to from the
cellular side (any UP function); so that the PE can do the right mapping to
the transport path which can offer those characteristics.

> looks questionable,
>
> Because in the case of IPv6 data plane it would be difficult to parse IPv6
> EH headers chain up to UDP, especially if SRH 200B+ header would be in
> between
>

[Uma]: gNodeB will not get into transport network and the path information
that has to be encoded in the SRH or MPLS currently. If you really want
that, you can try bringing that to 3GPP. Today there is a separation
between these two  for many reasons (some are good and some are bad but
there for backward compatibility).

> , potentially with Authentication header and Encapsulation Security
> payload header on top that is very probable in MBH environment. I do not
> know any ASIC that could parse all of this in the worst-case scenario.
>
[Uma]: Yes, native IPv4 and IPv6.

> There is a dispute right now in 6man about the introduction of an
> additional header to show resource attachment.
>
> MPLS guys push strongly that it should be Label. SR guys insist on SID.
> Jimmy (and a few others) proposes something
> new/small/independent/just_for_this_purpose.
>
>
>
[Uma]: I agree with that. But as I said above please don't mix things on
what has to be done on PE and what has to be done on cellular endpoints.
TEAS clearly said they don't want to dictate anything on the cellular
endpoints.

In general, I see in this draft an extremely high intersection with the
> Slicing story. It looks like yet another one (UDP port-based).
>
[Uma]: Yes, Jimmy is aware of this and had multiple comments last year and
Q1 2021.

>
>
> But it does not matter: if nobody pushing a particular type of VPN+ in
> 3GPP – it would not happen anyway. gNodeB just would not label the packet
> properly.
>
[Uma]: You are right.

> *Sent:* Saturday, August 14, 2021 5:30 AM

---

From: "Majumdar, Kausik" <[email-masked]>
Date: Mon, 16 Aug 2021 22:14:43 +0000

Hi Eduard,

Please see some inline comments.

From: Vasilenko Eduard <[email-masked]>
Sent: Monday, August 16, 2021 2:20 AM
To: Uma Chunduri <[email-masked]>
Cc: Majumdar, Kausik <[email-masked]>; RTGWG <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Subject: RE: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

Hi Uma, The mechanism itself (use UDP source port range for forwarding decision) looks questionable, Because in the case of IPv6 data plane it would be difficult to parse IPv6 EH headers chain up to U
External ([email-masked]<mailto:[email-masked]>)
  Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2thdXNpay5tYWp1bWRhckBjb21tc2NvcGUuY29tL2ZlZjUyZjNjMjkxNWIxMDM3MTY1MTE0MzE0MWM2NDBhLzE2MjkxMDU2MzYuMzI=#key=a41f319b508ba9216ab4905e36e53aba>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

Hi Uma,

KM>> I am not sure if I follow this comment properly. Based on the current rtgwg-extension-tn-aware-mobility draft – the processing of the UDP Source Port is needed in the immediate ingress Node that is connected to the UPF over L2/L3 network unless virtual UPF is running on the same ingress PE node. Please refer to Section 4. Mobility Packet Transition to the Data Network in the draft.

We are talking about N6 interface here. The UDP/Transport Header should be followed by an outer header that carries the destination of C-PE header. It could be either IPv4 or IPv6, but SRH would not be inserted by the UPF when it is sending the packet to the C-PE Node in the Data Network over N6 interface. The UPF would use a P2P tunnel to send the First Hop Node in the Data Network.

The Ingress C-PE node that is connected to the UPF has to open up the packet to parse the inner packet to find out the actual UE destination. Hence it has to process the UDP Source Port info, I don’t see any issue here. But please note based on the proposal described in the draft the UDP Source Port doesn’t carry with the packet from one Node to other Nodes in the Data Network, it is only processed by the First Hop C-PE Node that is connected to the UPF over N6 interface. This Node process the UDP Source Port and maps to proper Network Slice based on the existing SR-TE mechanism to maintain E2E traffic characteristics – no changes inside the SR-TE network, UDP Port doesn’t get carried with the packet.

KM>> Yes, it’s another one but much simpler technology to use and maintain E2E network characteristics using UDP Source Port. The 3GPP TS 23.501 spec where actually UDP Source port is referred for the PDU session type data.

Based on - ETSI 3GPP TS 23.501 version 16.6.0 Release 16 129 ETSI TS 123 501 V16.6.0 (2020-10)

- For uplink, the UPF forwards the received Unstructured PDU Session type data to the destination in the data network over the N6 PtP tunnel using UDP/IPv6 encapsulation.

- For downlink, the destination in the data network sends the Unstructured PDU Session type data using UDP/IPv6 encapsulation with the IPv6 address of the PDU Session and the 3GPP defined UDP port for Unstructured PDU Session type data. The UPF acting as PDU Session Anchor decapsulates the received data (i.e. removes the UDP/IPv6 headers) and forwards the data identified by the IPv6 prefix of the PDU Session for delivery to the UE.

Thanks,
Kausik

Eduard

Eduard,

Very good question.

--
Uma C.

On Thu, Aug 12, 2021 at 1:59 AM Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Uma,
Yes, indeed, section 2.5 of https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility<https://secure-web.cisco.com/1wSHdCFzobAMGvLXWudjEWfqhJW6QLBT1DwH7Sr4S1Yc2CFavljqjnz4rHpC7L2IUJxKCBTonAiNFIoDspWUv1Hc8mrJQynyiR4d2Sq_xFqDxaNxBj3RWl-ISIQiFWReSMRD7JB_YarXPNapaq_x63774DHG6CN8W9icQShIeznWzH_IzbD42pCUPVNSsT6-UCsOvZ6HHjtcmp0X5zXWJZ4WcuKdVa__dVd_3BZjOToNMfspSfjHn0sN6aTw2sq7eB23kREmi6jwf9MQt1qTLxrMMbTf-ktDHbt2h8YvdTNzBMYFbaKfBHAXcvL6cBrc4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-tn-aware-mobility>

https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility<https://secure-web.cisco.com/1wSHdCFzobAMGvLXWudjEWfqhJW6QLBT1DwH7Sr4S1Yc2CFavljqjnz4rHpC7L2IUJxKCBTonAiNFIoDspWUv1Hc8mrJQynyiR4d2Sq_xFqDxaNxBj3RWl-ISIQiFWReSMRD7JB_YarXPNapaq_x63774DHG6CN8W9icQShIeznWzH_IzbD42pCUPVNSsT6-UCsOvZ6HHjtcmp0X5zXWJZ4WcuKdVa__dVd_3BZjOToNMfspSfjHn0sN6aTw2sq7eB23kREmi6jwf9MQt1qTLxrMMbTf-ktDHbt2h8YvdTNzBMYFbaKfBHAXcvL6cBrc4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-tn-aware-mobility> is written in such a style like it is a proposition.
Looking at the text I come even to more suspect that this functionality is not requested in any 3GPP spec. Hence, may never be implemented in any gNodeB.

Eduard

Hi Eduard,

in-line [Uma]:

--
Uma C.

[Uma]: Yes. This is much debated and documented in https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility<https://secure-web.cisco.com/1wSHdCFzobAMGvLXWudjEWfqhJW6QLBT1DwH7Sr4S1Yc2CFavljqjnz4rHpC7L2IUJxKCBTonAiNFIoDspWUv1Hc8mrJQynyiR4d2Sq_xFqDxaNxBj3RWl-ISIQiFWReSMRD7JB_YarXPNapaq_x63774DHG6CN8W9icQShIeznWzH_IzbD42pCUPVNSsT6-UCsOvZ6HHjtcmp0X5zXWJZ4WcuKdVa__dVd_3BZjOToNMfspSfjHn0sN6aTw2sq7eB23kREmi6jwf9MQt1qTLxrMMbTf-ktDHbt2h8YvdTNzBMYFbaKfBHAXcvL6cBrc4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-tn-aware-mobility>
            The approach taken there is management plane or AF related changes (as opposed to any change in the 3GPP control plane). These are by definition deployment specific and many
            deployments have knobs to do this.

Hi All,

I have presented our draft draft-mcd-rtgwg-extension-tn-aware-mobility-02<https://secure-web.cisco.com/19OeA7-00gZwg2jMI_Cx2QOylJUPiDdkhTBcI-CExmKOFvX2wDGVKWpvPUbcqB3H4ZcFN_Mp7BLje30aHmh6BvfOiVnYqYRin3gITnGVKxKK37aQeBZg0Rw18qXw6B80Sz4jJynZYTA48vW8W5Ai6dKS-tX2rS-bIxhBVQGo_EUmEeGTBZsuBqIfboLPIx6WBQHU3y5uYZC8YLQZzGaAwXcCt5fPKwO4ZR-ShieJJDg6JSluWYEB3CXAaEfHow2gDdi-i9yiEGURbohp6XMcBN58NXpvO7FNijvVd-HgFPNl4AQUgSgtn4dK7vk6MChQM/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mcd-rtgwg-extension-tn-aware-mobility-02> in the IETF 111 on behalf of other co-authors. There are some questions and comments in the IETF for this presentation. We felt it would be good to review those comments over email thread to sort those out.

@Jeff Tantsura

@Jie Dong

@Eduard

@Cheng

@Acce
Two questions:

  1.  Same as Cheng.

Regards,
Kausik

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg<https://secure-web.cisco.com/1l5TbzmmXXPKe0yyoKVkbQGd38fcTdsjThI_uticWO-Oa8BM5HHH8E8nOTELDpbartgrdTs5B9EyI0ObpsnH8EmuPML4wlUwGhhnJt8HR8y1twKZUL2IoKwoPEVMIrYRHJra-paj7eeIuF-7QxCMdIZMsnoZzNMacSTYjdh3Xtcn5pQKWVEA61Lkl4AkkawnBcu7rdMN8byNvE6sp5xyR7PFVhZvNSCrtztnd-giYGhmEHARWiBxsPF62yJD8ZZElhd72e_r86VavRMUmS0107-1jFUqDmrAt3oSDcf8h4YSMOfGk3c1LkbdtaU91kH_F/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg>

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 17 Aug 2021 08:57:24 +0000

Hi Kausik,
Hi Uma,
It may be my fault but I still have different assumptions in my mind that prevent me from understanding you.

You tell me that that it is slicing but in different scope.
Many other people are developing slicing for PE-PE that is typically multi-hop.
You are developing slicing for CE-PE (in old terminology). Moreover, “CE” (UPF) and “PE” are always collocated, topology is pretty much restricted: no multi-hop, just 1 link.
Hence, the additional header/field looks overkill. Let’s use the “source UDP port” that has been already proposed for UE-UPF SLA/QoS signaling in the different drafts.
Logical?
Not yet.

UE is not connecting to UPF directly (like on your slides). gNodeB has N3 to the edge UPF, then N9 to regional UPF, and only then N6.
N3 and N9 are GTP-U. Hence, you would probably tell me that it is possible to re-map UDP port ranges along the path
(by the way, it is an additional requirement for gNodeB and all types of UPF that needs to be pushed inside 3GPP).
But I would tell that N3 and N9 could be multi-hop from the bearer's point of view.
And then all my comments about SRH and AH/ES could become relevant – this overhead would pop up.
I mean: you have to remap UDP port ranges (that looks proper solution for UE) into SRH/MPLS much early, on N3 and N9.
It is possible to remap UDP port ranges into some special slicing header (SRH? MPLS?) on every PE after gNodeB, Edge UPF, Regional UPF. Then SLA/QoS would be triple overhead in every packet:

-          nobody discarded Diffserv code point (well, used for different purposes)

-          UDP port ranges for slicing mapping at 3GPP nodes

-          SRH/MPLS/other for slicing in multiple bearer hops
IMHO: it was too much to involve UE in additional headers,
but I believe that for all other 3GPP nodes we need an additional header to signal slicing to cut overhead at least for duplicity (slicing header and DSCP).
3GPP is trying to be technology agnostic – they would probably reject anything SRv6 or MPLS related as the lock to one particular technology.
Hence, I have copied Jimmy because he is pushing the VTN ID that is IPv6 EH (more general). 3GPP may reject it too because it is the lock to IPv6 in the infrastructure.
But maybe lock to IPv6 is not so big a problem? I could not predict what 3GPP would say about the IPv6 lock.
UDP port range looks the most general – no additional lock to a particular technology (UDP lock did happen 20 years ago). Hence, 3GPP may steer to UDP port ranges. Then we would have triple overhead.
But all this guesswork in IETF does not make sense till 3GPP would decide what would be used in the data plane for slicing indication on all 3GPP interfaces. It is possible that the last UPF in the chain would receive and transmit some special header for slicing, then this draft would become immediately irrelevant.

The except from TS 23.501 below does not indicate the possibility or requirement to map or re-map UPD port ranges for different services.
What 3GPP would like to use for Slicing indication in the forwarding plane on all interfaces N9? N6? N3? Who does follow 3GPP carefully?
Eduard
From: Majumdar, Kausik [mailto:[email-masked]]
Sent: Tuesday, August 17, 2021 1:15 AM
To: Vasilenko Eduard <[email-masked]>; Uma Chunduri <[email-masked]>
Cc: RTGWG <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Subject: RE: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

Hi Eduard,

From: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 16, 2021 2:20 AM
To: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Cc: Majumdar, Kausik <[email-masked]<mailto:[email-masked]>>; RTGWG <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Subject: RE: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

Hi Uma,

Thanks,
Kausik

Eduard

Eduard,

Very good question.

--
Uma C.

Eduard

Hi Eduard,

in-line [Uma]:

--
Uma C.

Hi All,

@Jeff Tantsura

@Jie Dong

@Eduard

@Cheng

@Acce
Two questions:

  1.  Same as Cheng.

Regards,
Kausik

---

From: "Majumdar, Kausik" <[email-masked]>
Date: Tue, 17 Aug 2021 19:05:23 +0000

Hi Eduard,

Just curious, have you gone through two drafts below ?

https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility-00
https://datatracker.ietf.org/doc/html/draft-mcd-rtgwg-extension-tn-aware-mobility-02

KM>> The N3 and N9 is multi-hop to the UPF. Please check the Figure 1 representation in the original dmm-tn-aware-mobility draft, the connection from the gNB to the UPF.

Coming back to my slide, the stress has been given to the Data Network as the Mobility side network is covered in detail by the dmm draft. The RTG tn-aware-mobility draft discusses once the packet transitioned from the UPF to the first hop ingress CE/PE Node. I know that UE is not directly connected to the UPF, it is connected over a transport network the way it is represented in Figure 1 of the dmm draft and I didn’t want to stress that portion of that network as I mentioned in the RTG draft starts on how the UE packet transitioned from the UPF to the ingress Node over N6 interface. The P2P tunnel we are talking about that is between UPF and the first-hop Ingress Node over N6 as the 3GPP spec also mentions. I am not saying the network UE to the UPF is not the multi-hop network. Please review this portion through the other dmm draft.

The goal is to maintain the E2E traffic characteristics for the UE traffic over the Mobile and Data network. The UPF simply terminates the GTP-U tunnel and handoff to the Data Network over N6 interface over a P2P tunnel. The SRH you are describing within the Mobile side network will not carry forward in the Data Network. The first hop Ingress PE node in the Data Network will insert the SRH header based on the Policy of the local/global domain for the UE traffic to reach the destination. I think what Uma was describing to you is how the Packet would be steered through the IP Mid-haul and IP Backhaul in the Mobile Network based on the UDP Source Port range. Why gNB has to come into the picture for managing the UDP Source Port range? That should be pass-through. The connections and maintaining the network characteristics between the PEs in the IP Mid-haul and Backhaul, that would maintain the network characteristics based on the UDP port range.

With that said, we can hop into a meeting/call to discuss more and to clarify. Let me know if you like me to set it up.

Thanks,
Kausik

From: Vasilenko Eduard <[email-masked]>
Sent: Tuesday, August 17, 2021 1:57 AM
To: Majumdar, Kausik <[email-masked]>; Uma Chunduri <[email-masked]>
Cc: RTGWG <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Subject: RE: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

Hi Kausik, Hi Uma, It may be my fault but I still have different assumptions in my mind that prevent me from understanding you. You tell me that that it is slicing but in different scope. Many other p
External ([email-masked]<mailto:[email-masked]>)
  Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2thdXNpay5tYWp1bWRhckBjb21tc2NvcGUuY29tLzI2OTMzMmYzZTdhNGY3YThkMTI4ODRiZWM3YmFhOTRlLzE2MjkxOTA2NTYuMTI=#key=26ffc70bc4f5b32c3a1edaa13931c4e2>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

Hi Kausik,
Hi Uma,

  *   nobody discarded Diffserv code point (well, used for different purposes)
  *   UDP port ranges for slicing mapping at 3GPP nodes
  *   SRH/MPLS/other for slicing in multiple bearer hops
IMHO: it was too much to involve UE in additional headers,
but I believe that for all other 3GPP nodes we need an additional header to signal slicing to cut overhead at least for duplicity (slicing header and DSCP).
3GPP is trying to be technology agnostic – they would probably reject anything SRv6 or MPLS related as the lock to one particular technology.
Hence, I have copied Jimmy because he is pushing the VTN ID that is IPv6 EH (more general). 3GPP may reject it too because it is the lock to IPv6 in the infrastructure.
But maybe lock to IPv6 is not so big a problem? I could not predict what 3GPP would say about the IPv6 lock.
UDP port range looks the most general – no additional lock to a particular technology (UDP lock did happen 20 years ago). Hence, 3GPP may steer to UDP port ranges. Then we would have triple overhead.
But all this guesswork in IETF does not make sense till 3GPP would decide what would be used in the data plane for slicing indication on all 3GPP interfaces. It is possible that the last UPF in the chain would receive and transmit some special header for slicing, then this draft would become immediately irrelevant.

The except from TS 23.501 below does not indicate the possibility or requirement to map or re-map UPD port ranges for different services.
What 3GPP would like to use for Slicing indication in the forwarding plane on all interfaces N9? N6? N3? Who does follow 3GPP carefully?
Eduard
From: Majumdar, Kausik [mailto:[email-masked]]
Sent: Tuesday, August 17, 2021 1:15 AM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Cc: RTGWG <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Subject: RE: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

Hi Eduard,

Hi Uma,

Thanks,
Kausik

Eduard

Eduard,

Very good question.

--
Uma C.

Eduard

Hi Eduard,

in-line [Uma]:

--
Uma C.

Hi All,

@Jeff Tantsura

@Jie Dong

@Eduard

@Cheng

@Acce
Two questions:

  1.  Same as Cheng.

Regards,
Kausik

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 18 Aug 2021 09:20:56 +0000

Hi Kausik,
You do not hear me. Probably, I am telling it in the wrong way.

1.
Choosing what to be used for “Slice ID” (MTNC-ID) is the fundamental decision. 3GPP should agree that it is “UDP port range” and make this recommendation in some TRs.
I am very surprised that Uma and you have deep dive into this topic but do not know who is negotiating this in 3GPP and what is the roadmap?
The whole chain of these drafts would be broken if 3GPP would say “No, Slice would be carried by different field or it would not be carried at all – use stateful filter to catch slice on the 1st PE”.

2.
I have read draft-ietf-dmm-tn-aware-mobility-00
And I am not happy that IPv6 was not accounted for as the possible infrastructure data plane.
Because IPv6 has a lot of functionality packed inside EHs, it would create a big problem to use Slice ID buried so deep into the packet (UDP source port offset could easily cross 128B).
IMHO: it was a bad choice to choose the UDP port as the slice ID just because it is buried so deep in the packet (a huge chain of heads should be parsed before).
It would need to duplicate Slice ID in something that would be close to the packet head. UDP port range would be not useful anyway.

3.
You continue pointing that this decision is made by draft-ietf-dmm-tn-aware-mobility, you just use it as the given. It looks like you push this discussion to the draft that you consider as the “parent”.
You are partially right (but Uma is the 1st in the list of authors draft-ietf-dmm-tn-aware-mobility).
I am asking in the wrong place (should be different WG) and at the wrong time (should be the discussion about draft-ietf-dmm-tn-aware-mobility).
I would shut up here in respect of this draft.

PS: You are constructing the 2nd or 3rd floor of this building. Be aware that the basement construction has not started yet.
Eduard
From: Majumdar, Kausik [mailto:[email-masked]]
Sent: Tuesday, August 17, 2021 10:05 PM
To: Vasilenko Eduard <[email-masked]>; Uma Chunduri <[email-masked]>
Cc: RTGWG <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Subject: RE: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft

Hi Eduard,

Thanks,
Kausik

To: Majumdar, Kausik <[email-masked]<mailto:[email-masked]>>; Uma Chunduri <[email-masked]<mailto:[email-masked]>>

Hi Kausik,
Hi Uma,

Hi Eduard,

Hi Uma,

Thanks,
Kausik

Eduard

Eduard,

Very good question.

--
Uma C.

Eduard

Hi Eduard,

in-line [Uma]:

--
Uma C.

Hi All,

@Jeff Tantsura

@Jie Dong

@Eduard

@Cheng

@Acce
Two questions:

  1.  Same as Cheng.

Regards,
Kausik

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 18 Aug 2021 18:29:23 -0700

And I am not happy that IPv6 was not accounted for as the possible
> infrastructure data plane.
>
Because IPv6 has a lot of functionality packed inside EHs, it would create
> a big problem to use Slice ID buried so deep into the packet (UDP source
> port offset could easily cross 128B).
>
IMHO: it was a bad choice to choose the UDP port as the slice ID just
> because it is buried so deep in the packet (a huge chain of heads should be
> parsed before).
>
It would need to duplicate Slice ID in something that would be close to the
> packet head. UDP port range would be not useful anyway.
>

[Uma]: You are asking the question differently (earlier you said with SRH,
128 bytes can be crossed). I responded
https://mailarchive.ietf.org/arch/msg/rtgwg/854WAs6ZxVvgFiGdkQ5vxgaa-tU/

Remember gNodeB is emitting the is't time with GTP-U (with IPv6 and if any
other EH, other than topology related) and this can be handled and by the
sender and the incoming PEs with other EHs (if any) for ages (nothing is
free).

You continue pointing that this decision is made by
> draft-ietf-dmm-tn-aware-mobility, you just use it as the given. It looks
> like you push this discussion to the draft that you consider as the
> “parent”.
>
You are partially right (but Uma is the 1st in the list of authors
> draft-ietf-dmm-tn-aware-mobility).
>
I am asking in the wrong place (should be different WG) and at the wrong
> time (should be the discussion about draft-ietf-dmm-tn-aware-mobility).
>
[Uma]:  Yes. I don't have much to add here any more.

--

Uma C.