From: Bogineni, Kalyani [mailto:[email protected]]
Sent: Thursday, February 08, 2018 6:18 PM
To: Uma Chunduri <[email protected]>; Sri Gundavelli (sgundave)
<[email protected]>; Marco Liebsch <[email protected]>; Dino Farinacci
<[email protected]>
Cc: [email protected]; dmm <[email protected]>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
draft-herbert-ila-mobile-00.txt
Uma - It will support mobility scenarios similar to what SGW/PGW support in 4G.
[Uma]: Yes, then ILA-N has to be on gNB and ILA-R has to be on the UPF where
N6 is there.
But current draft suggests ILA-N on another UPF (perhaps BP
UPF) and the address transformation between only between UPFs on N9. I don't
see any mobility in that case..
Perhaps you have to adjust the draft to move ILA-N to gNB.
Yes, with this N3 comes into picture.
And will also support local access to the DN.
[Uma]: ??
Kalyani
From: Uma Chunduri [mailto:[email protected]]
Sent: Thursday, February 8, 2018 9:13 PM
To: Bogineni, Kalyani
<[email protected]<mailto:[email protected]>>;
Sri Gundavelli (sgundave) <[email protected]<mailto:[email protected]>>;
Marco Liebsch <[email protected]<mailto:[email protected]>>; Dino
Farinacci <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; dmm <[email protected]<mailto:[email protected]>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
draft-herbert-ila-mobile-00.txt
Kalyani -
In-line [Uma]:
--
Uma C.
From: Bogineni, Kalyani [mailto:[email protected]]
Sent: Thursday, February 08, 2018 6:07 PM
To: Uma Chunduri <[email protected]<mailto:[email protected]>>; Sri
Gundavelli (sgundave) <[email protected]<mailto:[email protected]>>; Marco
Liebsch <[email protected]<mailto:[email protected]>>; Dino
Farinacci <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; dmm <[email protected]<mailto:[email protected]>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
draft-herbert-ila-mobile-00.txt
Uma:
The goal of the white paper is to understand how each of the proposals impact
N3, N4, SMF and gNB as is listed in Section of the white paper.
[Uma]: Absolutely. I got that. But I am not asking about the whitepaper below.
I am not getting which mobility scenario is covered by ILA
proposal in the subject line if you don't include N3?
Here is the extract from Section 4 of the CT4 study item. They say that
coordination with other working groups will be done as needed. So
documenting the proposals is important.
------------- from CT4 Study item --------
As CT4 is not responsible for selecting the user plane protocol in the RAN
(e.g. N3, F1-U), and since the user plane protocol in the 5GC cannot be decided
irrespectively of the user plane protocol supported in the RAN, the study will
have to involve coordination with RAN3.
Coordination will also be required with CT3 for potential impacts on N6, and
with SA2 if the work has possible impacts on the stage 2 specifications.
---------
Kalyani
From: Uma Chunduri [mailto:[email protected]]
Sent: Thursday, February 8, 2018 8:07 PM
To: Sri Gundavelli (sgundave) <[email protected]<mailto:[email protected]>>;
Bogineni, Kalyani
<[email protected]<mailto:[email protected]>>;
Marco Liebsch <[email protected]<mailto:[email protected]>>; Dino
Farinacci <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; dmm <[email protected]<mailto:[email protected]>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
draft-herbert-ila-mobile-00.txt
Hi Tom, Kalyani -
I fully agree what Sri said below.
>From Section 7.2 of the subject line:
---> ---> --->
DN to ILA-R ILA-R to ILA-N ILA-N to gNB gNB to UE
+------------+ +------------+ +------------+ +------------+
| Application| | Application| | Application| | Application|
+------------+ +------------+ +------------+ +------------+
| L4 | | L4 | | L4 | | L4 |
+------------+ +------------+ +------------+ +------------+
| IPv6 | | IPv6 (ILA) | | IPv6 | | PDU Layer |
+------------+ | +------------+ | +------------+ +------------+
| L2 | | | L2 | | | GTP-U | | AN Protocol|
+------------+ | +------------+ | +------------+ | Layers |
| | | UDP/IP | | |
N6 <--N9 --> N3 +------------+ +------------+
| L2 |
+------------+
If this were to be nextgen and seeking key benefits of ID/LOCs, I strongly
suggest changing the content of the draft to make this fully anchorless i.e.,
including N3 else I am not seeing *any mobility* scenario that is being solved
by ILA.
As it stands - eNB/gNB mobility would be taken care by S1U/N3. Meaning both X2
based and S1 based handovers/mobility (used 4G terminology, but I meant
equivalent interfaces) is out of the scope for ILA.
If you were to bring in transformation concept (tunnel-free concept) or ILA-N
it has to be on gNB not UPF (not even staging BP UPF).
Please tell me if my understanding is incorrect here. I have few more questions
on the draft and shall wait.
--
Uma C.
From: ila [mailto:[email protected]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, February 08, 2018 4:14 PM
To: Bogineni, Kalyani
<[email protected]<mailto:[email protected]>>;
Marco Liebsch <[email protected]<mailto:[email protected]>>; Dino
Farinacci <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; dmm <[email protected]<mailto:[email protected]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
draft-herbert-ila-mobile-00.txt
HI Kalyani,
> The adaptation from GTP to IP has to happen somewhere, either in the radio
> node or in the UPF.
I guess when you say from "adaptation from GTP to IP", you mean to say GTP-U
decapsulation of the user-plane IP packet for handling it by other protocols
and for forwarding it on N9.
If N3 is untouched, then its the UPF that is doing that decapsulation and
giving it to XYZ function (LISP/ILA/SRv6/Aero/*). There is no node that can do
the GTP-U decap. But, that also makes the UPF with dual personality of GTP-U
one one side and XYZ function towards the other UPF on N9. But, in some cases
there may not be even a N9 (Ex: S/P GW function for a session are collocated on
the same SAE GW when there is no mobility). So, my point is solving this for
N9 may not greatly simplify the architecture; there is still an anchor and
there is still GTP-U. The CT4 study may be about N9, but I think it will be
useful IMO for IETF to look at the entire system and realize a GTP-U less
architecture.
Sri
From: "Bogineni, Kalyani"
<[email protected]<mailto:[email protected]>>
Date: Thursday, February 8, 2018 at 4:39 AM
To: Sri Gundavelli <[email protected]<mailto:[email protected]>>, Marco
Liebsch <[email protected]<mailto:[email protected]>>, Dino
Farinacci <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, dmm <[email protected]<mailto:[email protected]>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
draft-herbert-ila-mobile-00.txt
Sri:
Even though N3 is shown for 5G and S1-U for 4G, my understanding is that there
are commons sub-layers in the protocol stack
that are common to both 4G and 5G radio accesses that could be re-used. The
adaptation from GTP to IP has to happen
somewhere, either in the radio node or in the UPF. The UPF closer to the radio
node also does the adaptation. Are there any
other ideas?
Kalyani
From: Sri Gundavelli (sgundave) [mailto:[email protected]]
Sent: Wednesday, February 7, 2018 12:23 PM
To: Bogineni, Kalyani
<[email protected]<mailto:[email protected]>>;
Marco Liebsch <[email protected]<mailto:[email protected]>>; Dino
Farinacci <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; dmm <[email protected]<mailto:[email protected]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
draft-herbert-ila-mobile-00.txt
Hi Kalyani,
For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there are
two nodes that's where the translation/tunneling is happening. In a generic
sense, it could be a layer-2 termination point, a first-hop router, or a
transit router. When seen from 3GPP lens, there is only UPF and the N4
interface that you talk about. But, there is N3 (eNB to UPF) and then there are
also other nodes where there is an impact. The translation/tunneling/steering
may very well happen on some router connected to the service cloud/core (on
N6), or at some exit router where there is no 3GPP UPF function and there is
no N4.
So, there are two key questions here:
1.) Is the UPF only node that is impacted here? Is the assumption that these
protocols are doing some translation/tunneling only on UPF node? Or, we can
introduce a two types of IP forwarding nodes, one collocated with UPF and
another without UPF. I know how this discussion will go in 3GPP; they will
insist and say they we will never recognize any other node other what they
created.
2.) Is N4 the only interface to these two types of node variants. Or we will
have N4' to these both types of nodes from some AF (which can interwork with
the service bus), and we don't' touch N4.
Marco's point is to keep this generic and not make this very UPF specific, as
it will be too restrictive.
Sri
From: "Bogineni, Kalyani"
<[email protected]<mailto:[email protected]>>
Date: Tuesday, February 6, 2018 at 1:23 PM
To: Marco Liebsch <[email protected]<mailto:[email protected]>>,
Sri Gundavelli <[email protected]<mailto:[email protected]>>, Dino Farinacci
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, dmm <[email protected]<mailto:[email protected]>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
draft-herbert-ila-mobile-00.txt
Marco, Sri:
Here is the services based 5G architecture.
[cid:[email protected]]
SMF is a control plane entity and talks to the User plane functions (UPF)
through N4 interface as specified in 3GPP TS 29.244.
Here are two variants:
Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.
[cid:[email protected]]
Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs
also support APIs like the control plane functions.
[cid:[email protected]]
The architecture is extensible and additional control plane or user plane
functions can be added.
Is this what you had in mind?
Kalyani
-----Original Message-----
From: ila [mailto:[email protected]] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <[email protected]<mailto:[email protected]>>;
Dino Farinacci <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; dmm <[email protected]<mailto:[email protected]>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for
draft-herbert-ila-mobile-00.txt
It could be a nice option to keep the data plane specific control (the mapping
DB you refer to) in the user plane and take a common N4 to update the mapping
DB in case of mobility. But I think that clashes with the clear data plane /
control plane separation in nextgen. And: there may be data plane solutions
which don't come with a control plane / mapping system. For these the N4 needs
to disseminate complete forwarding states (an more, e.g. for chargeable event
monitoring, device dormancy support etc.) to all relevant data plane nodes,
means the ones that hold a state for the mobile.
Btw, in terms of compatibility with nextgen, so far N4 is terminated only in
few types of core data plane nodes with a dedicated role. We may investigate
options to push forwarding and further policies from the (nextgen) control
plane to other data plane nodes which don't terminate N4.
marco
-----Original Message-----
From: dmm [mailto:[email protected]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Dienstag, 6. Februar 2018 04:07
To: Dino Farinacci
Cc: dmm; [email protected]<mailto:[email protected]>
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for
draft-herbert-ila-mobile-00.txt
> The UPF sends IP packets. The UPF is part of the NGC core, right? So
>the packets from the UPF get to a map-resolver and map-server via IP.
>It's pretty simple. At least it should be.
Sure, that LISP control plane packet is an IP packet. But, every message that
is going between CP and UP will be named and numbered in 3GPP specs, and so
said in my first mail that its probably a new interface specific to LISP.
With any of the IETF protocols, PMIPv6/LISP/ILA, it can be argued that these
are IP packets. But, we should note that there is interworking needed with the
3GPP authentication infrastructure, and the protocol specific control plane.
Note that these protocols are not doing MN identity establishment. May be I
could be wrong here on the assumptions you have around LISP MN capabilities,
but to me MN is a standard 3GPP UE with no special capabilities such as
MIPv6/LISP MN stack.
Sri
On 2/5/18, 6:52 PM, "Dino Farinacci"
<[email protected]<mailto:[email protected]>> wrote:
>> Sure, but I assume the mapping table/DB is some where else in some
>>central location and not on the UPF?
>
>True.
>
>> The question is how does the UPF fetch that entry and if the
>>interface for that query is built on some 3GPP interface, or its
>>internal to LISP with no bearing on the access technology.
>
>The UPF sends IP packets. The UPF is part of the NGC core, right? So
>the packets from the UPF get to a map-resolver and map-server via IP.
>It's pretty simple. At least it should be.
>
>Dino
>
>>
>> Sri
>>
>>
>>
>> On 2/5/18, 6:42 PM, "Dino Farinacci"
>> <[email protected]<mailto:[email protected]>> wrote:
>>
>>> I don't know what you mean. If you put the xTR function on an UPF,
>>> then by LISP spec definition, Map-Request, Map-Reply, and
>>> Map-Register functionality is part of the UPF.
>>>
>>> Dino
>>>
>>>> On Feb 5, 2018, at 5:27 PM, Sri Gundavelli (sgundave)
>>>> <[email protected]<mailto:[email protected]>> wrote:
>>>>
>>>> I suspect there might be a need for a new interface.
>>>>
>>>> Assuming the LISP mapping system stays in the control plane, next
>>>>to SMF/AMF, and the xTR functions on the UPF, there needs to be
>>>>probably a new interface along the lines of the N4, for managing
>>>>the LISP MAP operations (Reg/Req/Reply/Notify..). But, off course
>>>>if the mapping system stays in the user-plane, may be there is just
>>>>interworking with the 3GPP authentication interfaces.
>>>>
>>>> Sri
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 2/5/18, 5:15 PM, "Bogineni, Kalyani"
>>>> <[email protected]<mailto:[email protected]>>
>>>> wrote:
>>>>
>>>>> Dino:
>>>>>
>>>>> Please look at 3GPP TS 23.501 to understand the architecture of NGC.
>>>>>We
>>>>> tried to explain that in the White paper.
>>>>> TS 23.502 has the procedures for the NGC. TS 23.503 specifies the
>>>>>policy and charging control framework for NGC.
>>>>> CT4 has a technical report on protocol aspects for NGC in TR 29.891.
>>>>>
>>>>> Your draft needs to describe how it fits in the 5G architecture,
>>>>>right now it only addresses 4G.
>>>>>
>>>>> Kalyani
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: ila [mailto:[email protected]] On Behalf Of Dino
>>>>>Farinacci
>>>>> Sent: Monday, February 5, 2018 7:32 PM
>>>>> To: Bogineni, Kalyani
>>>>> <[email protected]<mailto:[email protected]>>
>>>>> Cc: Tom Herbert <[email protected]<mailto:[email protected]>>;
>>>>> [email protected]<mailto:[email protected]>; dmm
>>>>><[email protected]<mailto:[email protected]>>; Sri Gundavelli (sgundave)
>>>>><[email protected]<mailto:[email protected]>>
>>>>> Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for
>>>>>draft-herbert-ila-mobile-00.txt
>>>>>
>>>>>> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani
>>>>>> <[email protected]<mailto:[email protected]>>
>>>>>> wrote:
>>>>>>
>>>>>> Dino:
>>>>>>
>>>>>> Can you add a section to show how this proposal would fit in 5G
>>>>>> architecture?
>>>>>
>>>>> Can you be more specific in what you¹d like to see in the new
>>>>>section?
>>>>>
>>>>> There are references throughout the draft where you see eNodeB and
>>>>>pGW that UPF functionality could be at the same network mode
>>>>>location.
>>>>>
>>>>> Dino
>>>>> _______________________________________________
>>>>> ila mailing list
>>>>> [email protected]<mailto:[email protected]>
>>>>>
>>>>>
>>>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
>>>>>ail
>>>>>ma
>>>>> n_
>>>>>
>>>>>
>>>>>listinfo_ila&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ
>>>>>&r=
>>>>>Id
>>>>> iS
>>>>>
>>>>>
>>>>>ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=zf1K
>>>>>fRu
>>>>>4n
>>>>> UF
>>>>>
>>>>>
>>>>>sUT8IJVExPygA_iAC-h4BErkY_CE2ugM&s=oLQOKLOAxuYtjVD_qWMbiQjkmP9acy6A
>>>>>u0X
>>>>>6l
>>>>> pS
>>>>> iBvg&e=
>>>>
>>>
>>
>
_______________________________________________
dmm mailing list
[email protected]<mailto:[email protected]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dmm&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=lWGVj8Jd11JyGVLcPLOSIxTZ-YHY3VbtfD1mi2uqhOY&s=-EIvAEYOQusoChy_iwtR4nMkaEqRKBTKTJ8GDjADuCk&e=
_______________________________________________
ila mailing list
[email protected]<mailto:[email protected]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=lWGVj8Jd11JyGVLcPLOSIxTZ-YHY3VbtfD1mi2uqhOY&s=cwX6UkOqq2vREiCvsQ7GPBXgKsinbkDmmckbpGwi73o&e=
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
