Subject: Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore

From: "Bogineni, Kalyani" <[email-masked]>
Date: Sun, 10 Dec 2017 00:39:14 +0000

All:

Here is a suggested title and outline of a white paper to evaluate the different mobility management related 
protocols being developed in IETF. This can be used as a basis for the study item in 3GPP that starts work in 
July 2018. If we have questions as we  develop this white paper, we can send Liaison statements to 3GPP 
CT4 which has the following scheduled meetings before July 2018: 22 - 26 January; 26 Feb - 2 Mar; 16 - 20 April; 
21 - 25 May. CT4 said that they can respond to questions from IETF in phase 1. 
 
Please provide comments and we can start writing the white paper.

===============
Title "IP Session Management and Mobility Management for 5G and Next Generation Internet"
(Mobility management mechanisms have an impact on how session management is done, hence the title)

Sections:

1. Introduction and Problem Statement
2. Overview of Existing Architectures and Protocol Stacks
3. Requirements for 3GPP accesses and non-3GPP accesses
	IP session management requirements
	Mobility management requirements
4. Reference Scenario(s) for Evaluation
5. Criteria for Evaluation
6. SRv6 based Solution
7. LISP based Solution
	ILSR
8. ILNP based Solution
9. ILA based Solution
10 Comparison of Protocols
11. Recommendation to 3GPP?
============

Kalyani

-----Original Message-----
From: Bogineni, Kalyani 
Sent: Saturday, December 9, 2017 4:32 PM
To: [email-masked]
Cc: Bogineni, Kalyani <[email-masked]>
Subject: RE: [E] Re: [5gangip] MINUTES of side meeting in Singapore

All:

3GPP CT4 has agreed to study possible candidates for user plane protocol for N9 (UPF - UPF) interface based on stage 2 requirements from TS 23.501 which specifies system architecture for the 5G system. TS 23.502 specifies procedures for the 5G system. 

You can refer to TS 23.401 and TS 23.402 to  understand how IP session management and mobility management work in LTE and with non-3GPP accesses.

Some references for GTP:
TS 29.281: Protocol details of GTPv1-U
TS 29.274: Protocol details of GTPv2-C
TS 29.244: Interface between control and user plane of EPC nodes

Kalyani Bogineni
Verizon

---

From: <[email-masked]>
Date: Sun, 10 Dec 2017 11:59:06 +0000

Kalyani

When we consider this work we should bear in mind that the control plane interface for the UPF, N4, has been decided in 29.891 as retaining current Sx semantics but over PFCP.

This text in 29.891 is germane:

" Besides, GTPv1-U is also used over the N3 and N9 interfaces (see clause 5), like in the EPC.
The packet forwarding model specified in subclause 5.2 of 3GPP TS 29.244 [7], which defines how the CP controls the processing of the packets in the UP function, enables to support all the current N4 requirements without any change to the model."

So we need to be careful that we either propose something which can be used with N4 as defined or can be added to N4 with relative ease.

David

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Bogineni, Kalyani
Sent: 10 December 2017 00:39
To: [email-masked]
Cc: Bogineni, Kalyani <[email-masked]>
Subject: Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore

All:

Here is a suggested title and outline of a white paper to evaluate the different mobility management related protocols being developed in IETF. This can be used as a basis for the study item in 3GPP that starts work in July 2018. If we have questions as we  develop this white paper, we can send Liaison statements to 3GPP
CT4 which has the following scheduled meetings before July 2018: 22 - 26 January; 26 Feb - 2 Mar; 16 - 20 April;
21 - 25 May. CT4 said that they can respond to questions from IETF in phase 1. 

===============

Sections:

2. Overview of Existing Architectures and Protocol Stacks 3. Requirements for 3GPP accesses and non-3GPP accesses

Kalyani

-----Original Message-----
From: Bogineni, Kalyani
Sent: Saturday, December 9, 2017 4:32 PM
To: [email-masked]
Cc: Bogineni, Kalyani <[email-masked]>
Subject: RE: [E] Re: [5gangip] MINUTES of side meeting in Singapore

All:

Some references for GTP:

Kalyani Bogineni
Verizon
_______________________________________________
5gangip mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/5gangip

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Sun, 10 Dec 2017 13:41:59 +0000

David:

Responses inline as [KB]

Kalyani

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, December 10, 2017 6:59 AM
To: Bogineni, Kalyani <[email-masked]>; [email-masked]
Subject: RE: [5gangip] [E] Re: MINUTES of side meeting in Singapore

Kalyani

[KB] We need to identify the changes needed to N4 and SMF for each of the different protocol options. Those will be criteria for comparison of the protocols.

David

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Bogineni, Kalyani
Sent: 10 December 2017 00:39
To: [email-masked]
Cc: Bogineni, Kalyani <[email-masked]>
Subject: Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore

All:

===============

Sections:

Kalyani

-----Original Message-----
From: Bogineni, Kalyani
Sent: Saturday, December 9, 2017 4:32 PM
To: [email-masked]
Cc: Bogineni, Kalyani <[email-masked]>
Subject: RE: [E] Re: [5gangip] MINUTES of side meeting in Singapore

All:

Some references for GTP:

Kalyani Bogineni
Verizon
_______________________________________________
5gangip mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIFAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=pfHEGh3K9he_rgFSrcR-_VG3QUDg7NP8OCaSqkDWUBM&s=0sZnln-_Z0js5RGr-jpFLm3DhEncaVp2HC_oVF2drVU&e=

---

From: Ca By <[email-masked]>
Date: Sun, 10 Dec 2017 15:45:39 +0000

> Please provide comments and we can start writing the white paper.

Can we please add one:

10. Slice based Mobility determination:  UE classifies traffic to enter a
mobilty sensitive or nonsensitive slice. Dedicated slice using traditional
GTP based mobility for highly mobile critical flows (VoLTE) and local
breakout (nomadic mobility / distributed CUPs) for internet flows that are
not highly sensitive to periodic ip address changes (youtube, netflix,
amazon shopping, general web browsing).  This allows tradional mobility for
VoLTE, but also  a dramatic offload of the majority of today’s traffic from
the high touch 3gpp mobility system.  This recognizes the need to for low
lantency local breakout and the reality that most UE traffic can change ip
address frequently with no negative user experience.

The operator keeps traditional mobility for selected flows, and the
operators saves money by not pushing bulk https / quic traffic from youtube
and others through the mobility system that supports VoLTE.  This traffic
is exited from the mobility system close to the edge using CUPS, ideally
the eNB is a CUPs client and presents both SGi and S1.  The non-mobile
flows are never encapsulated in GTP.

The mobility for youtube and others is left to the app (which works well
today when switching between wifi and Lte as an example of nomadic
mobility).  Furthermore, with CUPs, interested parties can deploy LISP,
ILNP, and ILA as a UE / app function.

> 3GPP CT4 has agreed to study possible candidates for user plane protocol
> for N9 (UPF - UPF) interface based on stage 2 requirements from TS 23.501
> which specifies system architecture for the 5G system. TS 23.502 specifies
> procedures for the 5G system.
>
> You can refer to TS 23.401 and TS 23.402 to  understand how IP session
> management and mobility management work in LTE and with non-3GPP accesses.
>
> Some references for GTP:

---

From: <[email-masked]>
Date: Sun, 10 Dec 2017 16:14:26 +0000

Agree that this is a very important addition, but there is work on-going on the Network Slicing IETF list around this.  Also, IDEAS is considering a new transport protocol which could be relevant.

As much as I know there are some objections, I think we need to consider how the parts of the IETF link together here.

We need an IETF-wide view of all 5G-related technologies IMvHO.

Specifically:

“This traffic is exited from the mobility system close to the edge using CUPS, ideally the eNB is a CUPs client and presents both SGi and S1.  The non-mobile flows are never encapsulated in GTP”

The interface from gNB to UPF is N3 (which is S1 equivalent) and that will be GTP based.  In many cases, especially as deployment of C-RAN increases, it will be that the first UPF is co-located with the gNB so I don’t think that we have to totally remove GTP on S1/N3 to be 100% successful.

In fact, one of the premises of network slicing is the ability to place the UPF close to the edge.

That means that the interception point will probably be the N9 exit of the first UPF.   That is good from a 3GPP standpoint because right now N9 is in play whereas N2, N3 and N6 are declared as done.

One question – we already have the ability to break-out locally in LTE with LIPA and SIPTO, but my understanding is that it is not commonly used and that is partly due to the regulatory/intercept requirements.  Does anyone have any recent data or explanation on this?

David

From: 5gangip [mailto:[email-masked]] On Behalf Of Ca By
Sent: 10 December 2017 15:46
To: Bogineni, Kalyani <[email-masked]>
Cc: [email-masked]
Subject: Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore

On Sat, Dec 9, 2017 at 4:39 PM Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>> wrote:
All:

===============

Sections:

Can we please add one:

10. Slice based Mobility determination:  UE classifies traffic to enter a mobilty sensitive or nonsensitive slice. Dedicated slice using traditional GTP based mobility for highly mobile critical flows (VoLTE) and local breakout (nomadic mobility / distributed CUPs) for internet flows that are not highly sensitive to periodic ip address changes (youtube, netflix, amazon shopping, general web browsing).  This allows tradional mobility for VoLTE, but also  a dramatic offload of the majority of today’s traffic from the high touch 3gpp mobility system.  This recognizes the need to for low lantency local breakout and the reality that most UE traffic can change ip address frequently with no negative user experience.

The operator keeps traditional mobility for selected flows, and the operators saves money by not pushing bulk https / quic traffic from youtube and others through the mobility system that supports VoLTE.  This traffic is exited from the mobility system close to the edge using CUPS, ideally the eNB is a CUPs client and presents both SGi and S1.  The non-mobile flows are never encapsulated in GTP.

The mobility for youtube and others is left to the app (which works well today when switching between wifi and Lte as an example of nomadic mobility).  Furthermore, with CUPs, interested parties can deploy LISP, ILNP, and ILA as a UE / app function.

Kalyani

-----Original Message-----
From: Bogineni, Kalyani
Sent: Saturday, December 9, 2017 4:32 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>>
Subject: RE: [E] Re: [5gangip] MINUTES of side meeting in Singapore

All:

Some references for GTP:

Kalyani Bogineni
Verizon
_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

---

From: Ca By <[email-masked]>
Date: Sun, 10 Dec 2017 16:56:36 +0000

On Sun, Dec 10, 2017 at 8:14 AM <[email-masked]> wrote:

> Agree that this is a very important addition, but there is work on-going
> on the Network Slicing IETF list around this.  Also, IDEAS is considering a
> new transport protocol which could be relevant.
>
>
>
> As much as I know there are some objections, I think we need to consider
> how the parts of the IETF link together here.
>
>
>

As you can see from Dino and Tom, there will not be a concensus — the
entire loc/id history is defined by lack of concensus — hence the
desperation to define 5G

And, i’d be willing to take the side that any and all loc/id schemes are
pedantic and have no place in the operational internet.

Specifically:
>
>
>
> “This traffic is exited from the mobility system close to the edge using
> CUPS, ideally the eNB is a CUPs client and presents both SGi and S1.  The
> non-mobile flows are never encapsulated in GTP”
>
>
>
> The interface from gNB to UPF is N3 (which is S1 equivalent) and that will
> be GTP based.  In many cases, especially as deployment of C-RAN increases,
>

CRAN is just a big Macro or a small UMTS RNC.  I doubt CRAN will catch once
people see it has all the same flaws as a UMTS RNC.  Just mho.

it will be that the first UPF is co-located with the gNB so I don’t think
> that we have to totally remove GTP on S1/N3 to be 100% successful.
>
>
>

The idea here is the upf and gNB / eNB are colocated or, ideally the same
node

UPF is just a function, it can be instantiated anywhere — including on the
CRAN or gNB

In fact, one of the premises of network slicing is the ability to place the
> UPF close to the edge.
>
>
>
> That means that the interception point will probably be the N9 exit of the
> first UPF.   That is good from a 3GPP standpoint because right now N9 is in
> play whereas N2, N3 and N6 are declared as done.
>
>
>
> One question – we already have the ability to break-out locally in LTE
> with LIPA and SIPTO, but my understanding is that it is not commonly used
> and that is partly due to the regulatory/intercept requirements.  Does
> anyone have any recent data or explanation on this?
>
>
>

SIPTO and LIPA were more focused on the femto cell use case.

The LI stuff usually is about doing a wiretap, which forks the traffic to
an LI collector. The UPF can fork a copy of the traffic to the collector.

David
>
>
>
> *From:* 5gangip [mailto:[email-masked]] *On Behalf Of *Ca By
> *Sent:* 10 December 2017 15:46
> *To:* Bogineni, Kalyani <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore
>
>
>
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 10 Dec 2017 18:18:35 +0000

I had a similar question.

Is the work scope of CT4 strictly about the protocols between UPF to UPF,
with the goal to realize an alternative approach to GTP-U tunnels?

Does it allow definition of new protocols between SMF and UPF (say, FPC
type interfaces) for N4/Sx.

Also, will they allow the use of additional control protocols in SMF that
drives the UPF state machine (Ex: Some mobility control protocol running
in SMF (Ex: GTP-C/LISP/PMIP/name it Š), triggering FPC type interfaces
(between SMF and UPF) to drive some routing protocol (between UPF¹s, say
SRv6). 

Trying to understand the scope.

The below structure is fine, but I do not know how any of the mobility
protocols (typically which control both signaling + user plane states) fit
into this CT4 work scope.

Sri

On 12/10/17, 3:59 AM, "5gangip on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>Kalyani
>
>When we consider this work we should bear in mind that the control plane
>interface for the UPF, N4, has been decided in 29.891 as retaining
>current Sx semantics but over PFCP.
>
>The packet forwarding model specified in subclause 5.2 of 3GPP TS 29.244
>[7], which defines how the CP controls the processing of the packets in
>the UP function, enables to support all the current N4 requirements
>without any change to the model."
>
>So we need to be careful that we either propose something which can be
>used with N4 as defined or can be added to N4 with relative ease.
>
>David
>
>Here is a suggested title and outline of a white paper to evaluate the
>different mobility management related protocols being developed in IETF.
>This can be used as a basis for the study item in 3GPP that starts work
>in July 2018. If we have questions as we  develop this white paper, we
>can send Liaison statements to 3GPP
>which specifies system architecture for the 5G system. TS 23.502
>specifies procedures for the 5G system.
>

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Sun, 10 Dec 2017 19:00:55 +0000

Sri:

Responses inline as [KB]

> From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
> Sent: Sunday, December 10, 2017 1:19 PM
> To: [email-masked]; Bogineni, Kalyani
> <[email-masked]>; [email-masked]
[KB] yes
> type interfaces) for N4/Sx.
[KB] We need to identify changes to N4 and SMF for the different protocols.
> 
> Also, will they allow the use of additional control protocols in SMF that drives
> the UPF state machine (Ex: Some mobility control protocol running in SMF
> (Ex: GTP-C/LISP/PMIP/name it Š), triggering FPC type interfaces (between
> SMF and UPF) to drive some routing protocol (between UPF¹s, say SRv6).
> 
> protocols (typically which control both signaling + user plane states) fit into
> this CT4 work scope.
> 
[KB] Based on the presentations from various proponents, it seemed like
SRv6 based solution and ILSR could use the existing control plane protocol
and ILA based solution could simplify the control plane protocol.

As we write the white paper, the proponents can provide the details. 

Kalyani

> >When we consider this work we should bear in mind that the control
> >plane interface for the UPF, N4, has been decided in 29.891 as
> >retaining current Sx semantics but over PFCP.
> >
> >The packet forwarding model specified in subclause 5.2 of 3GPP TS
> >29.244 [7], which defines how the CP controls the processing of the
> >packets in the UP function, enables to support all the current N4
> >requirements without any change to the model."
> >
> >CT4 which has the following scheduled meetings before July 2018: 22 -
> >26 January; 26 Feb - 2 Mar; 16 - 20 April;
> >2. Overview of Existing Architectures and Protocol Stacks 3.
> >Requirements for 3GPP accesses and non-3GPP accesses
> >4. Reference Scenario(s) for Evaluation 5. Criteria for Evaluation 6.
> >SRv6 based Solution 7. LISP based Solution
> >	ILSR
> >8. ILNP based Solution
> >9. ILA based Solution
> >3GPP CT4 has agreed to study possible candidates for user plane
> >protocol for N9 (UPF - UPF) interface based on stage 2 requirements
> >from TS 23.501 which specifies system architecture for the 5G system.
> >TS 23.502 specifies procedures for the 5G system.
> >
> >https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailm
> >an_listinfo_5gangip&d=DwIF-
> g&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0Pom
> >BTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYET
> cBynUdpT&
> >m=jpDjTpOYMxcs7xnTG0uxMAJXA4WCmVVsZL1yc2lwlKE&s=ZcYdSc0xMXp
> h73GNQtSRf9q
> >L8NuHIEZraVccXtEC9EA&e=
> >
> >https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailm
> >an_listinfo_5gangip&d=DwIF-
> g&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRj
> dCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=jpDjTpO
> YMxcs7xnTG0uxMAJXA4WCmVVsZL1yc2lwlKE&s=ZcYdSc0xMXph73GNQtSRf
> 9qL8NuHIEZraVccXtEC9EA&e=

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 10 Dec 2017 20:03:15 +0000

Thanks Kalyani.

I view the SRv6 work as mostly about steering packets from point A to
Point B.  There will be associated work that DMM WG is looking into which
looks into the logic of anchor management/selection/removal/*, and for
managing the state/forwarding policies into UPF nodes or to a Transport
Controller using FPC type interface.   There will be impact/changes to the
control plane functions which run the user plane states.

May be your second point below that we need to identify the
changes/impacts to N4 .. SMF covers that.

Regards
Sri

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 10 Dec 2017 12:10:37 -0800

And note that SRv6 is not competitive but complementary to locator/ID solutions. 

If an overlay can take advantage of any underlay feature, it should, modulo evaluating the cost to do so. 

Dino

> On Dec 10, 2017, at 12:03 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> Thanks Kalyani.
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sun, 10 Dec 2017 21:03:11 +0000

Agree; SRv6 based user-plane can be used in conjunction with any of the
control protocols that keep Locator/ID states in a fixed anchor, in some
central location, or flood them across. That also brings the question on
the assumption around those mobility management protocols that are active
in SMF/*, which drive the SRv6 routing states in the user-plane. Probably,
a big part of this work is in that control layer.

Sri

On 12/10/17, 12:10 PM, "5gangip on behalf of Dino Farinacci"
<[email-masked] on behalf of [email-masked]> wrote:

>>>>> From: 5gangip [mailto:[email-masked]] On Behalf Of
>>>>>Bogineni,
>>>>> Kalyani

---

From: Tom Herbert <[email-masked]>
Date: Sun, 10 Dec 2017 20:25:17 -0800

On Sun, Dec 10, 2017 at 7:45 AM, Ca By <[email-masked]> wrote:
>
> On Sat, Dec 9, 2017 at 4:39 PM Bogineni, Kalyani
> <[email-masked]> wrote:
>>
>> All:
>>
>> different mobility management related
Ca,

What is true for the "majority of today's traffic" says little about
what happens tomorrow unless somehow you believe that we've reached
the end of innovation.

> and others through the mobility system that supports VoLTE.  This traffic is
> exited from the mobility system close to the edge using CUPS, ideally the
> eNB is a CUPs client and presents both SGi and S1.  The non-mobile flows are
> never encapsulated in GTP.
>
That raises a _key_ question: why not encapsulate all traffic in GTP?
Presumably, because it's too expensive! So it follows the goal here is
to engineer a solution where the mobility mechanism can be uniformly
applied such that there is no negative impact to the application. This
way all applications get the same treatment and we don't need to
invent complex interfaces in UEs for application to somehow say
whether they want the low level mobility service or the premium
mobility service. Allowing applications to choose things like priority
doesn't work. Left to their own devices, they all choose highest
priority and best service

> ILNP, and ILA as a UE / app function.

Again "works well today" does not imply works well tomorrow. To
achieve the 1ms application latency goal of 5G we can rely hardly rely
on TCP retransmission timeouts to figure out that we need to
reconnect. In fact I will argue that no mechanism solely located in a
UE or in the transport layer will be reactive enough to detect and
adjust to a mobility event to meet such latency goals. However, the
network can do this. If this is done a layer 3 then all applications
of teh UE get the advantages of low latency, not just a few select
ones (especially not just those that pay more!).

Btw, given that YoutTube buffers something like thirty seconds of data
it's not interesting in any discussion about latency-- a human
switchboard operator would be fast enough for YouTube! IMO, there are
interactive gaming, video, AR applications that would be provide much
more interesting basis for discussion.

Tom

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 11 Dec 2017 16:17:27 +0900

Hello Kalyani,

Thank you for introducing the study item which is going to be approved at next plenary of 3GPP.

I think that it is very good idea that we will start from studying 3GPP architecture and understand how the user-plane works as it published as a document in terms of the user-plane study item. Here I’d suggest that we move it to DMM WG which already starts data-plane work. It targets not to limit only SRv6 draft as it just starting point so that other data-plane protocols will be considered. The goal of DMM WG work should be a whole package of data-plane suits which is mature to be competitive against existing GTP-U.

For me introducing Id/Loc type mobility management in control-plane in a white paper seems good idea since it wouldn't be covered within the user-plane study work perspective. 

Cheers,
--satoru

> 2017/12/10 9:39、Bogineni, Kalyani <[email-masked]>のメール:
> 
> All:
>

---

From: <[email-masked]>
Date: Mon, 11 Dec 2017 08:07:05 +0000

Thanks for the answers.

So on S1/N3 the GTP single header adds 96 bits if I’m correct.

If the UPF is co-located with g/eNB, do we care about that 96 bits?

D

Sent from my iPhone
________________________________
From: Ca By <[email-masked]>
Sent: Sunday, December 10, 2017 5:56:36 PM
To: Lake D Mr (PG/R - Elec Electronic Eng)
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore

On Sun, Dec 10, 2017 at 8:14 AM <[email-masked]<mailto:[email-masked]>> wrote:
Agree that this is a very important addition, but there is work on-going on the Network Slicing IETF list around this.  Also, IDEAS is considering a new transport protocol which could be relevant.

As you can see from Dino and Tom, there will not be a concensus — the entire loc/id history is defined by lack of concensus — hence the desperation to define 5G

And, i’d be willing to take the side that any and all loc/id schemes are pedantic and have no place in the operational internet.

Specifically:

The interface from gNB to UPF is N3 (which is S1 equivalent) and that will be GTP based.  In many cases, especially as deployment of C-RAN increases,

CRAN is just a big Macro or a small UMTS RNC.  I doubt CRAN will catch once people see it has all the same flaws as a UMTS RNC.  Just mho.

it will be that the first UPF is co-located with the gNB so I don’t think that we have to totally remove GTP on S1/N3 to be 100% successful.

The idea here is the upf and gNB / eNB are colocated or, ideally the same node

UPF is just a function, it can be instantiated anywhere — including on the CRAN or gNB

The LI stuff usually is about doing a wiretap, which forks the traffic to an LI collector. The UPF can fork a copy of the traffic to the collector.

David

From: 5gangip [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ca By
Sent: 10 December 2017 15:46
To: Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore

===============

Sections:

Can we please add one:

Kalyani

-----Original Message-----
From: Bogineni, Kalyani
Sent: Saturday, December 9, 2017 4:32 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Bogineni, Kalyani <[email-masked]<mailto:[email-masked]>>
Subject: RE: [E] Re: [5gangip] MINUTES of side meeting in Singapore

All:

Some references for GTP:

Kalyani Bogineni
Verizon

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Dec 2017 09:15:46 +0100

Le 10/12/2017 à 16:45, Ca By a écrit :
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     All:
> 
>     Here is a suggested title and outline of a white paper to evaluate
>     the different mobility management related
>     protocols being developed in IETF. This can be used as a basis for
>     the study item in 3GPP that starts work in
>     CT4 which has the following scheduled meetings before July 2018: 22
>     - 26 January; 26 Feb - 2 Mar; 16 - 20 April;
> 10. Slice based Mobility determination:  UE classifies traffic to enter 
> a mobilty sensitive or nonsensitive slice. Dedicated slice using 
> traditional GTP based mobility for highly mobile critical flows (VoLTE) 
> and local breakout (nomadic mobility / distributed CUPs) for internet 
> flows that are not highly sensitive to periodic ip address changes 
> (youtube, netflix, amazon shopping, general web browsing).  This allows 
> tradional mobility for VoLTE, but also  a dramatic offload of the 
> majority of today’s traffic from the high touch 3gpp mobility system.  
> This recognizes the need to for low lantency local breakout and the 
> reality that most UE traffic can change ip address frequently with no 
> negative user experience.
> 
> operators saves money by not pushing bulk https / quic traffic from 
> youtube and others through the mobility system that supports VoLTE.  
> This traffic is exited from the mobility system close to the edge using 
> CUPS, ideally the eNB is a CUPs client and presents both SGi and S1.  
> The non-mobile flows are never encapsulated in GTP.
> 

I support this addition of 10.

It is not the first time "sliced 5G" is mentioned for mobility.  I have 
seen demos that state to be the first "sliced 5G" for cars.

Alex

>     from TS 23.501 which specifies system architecture for the 5G
>     system. TS 23.502 specifies procedures for the 5G system.
> 
>     You can refer to TS 23.401 and TS 23.402 to  understand how IP
>     session management and mobility management work in LTE and with
>     non-3GPP accesses.
> 
>     Some references for GTP:

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 11 Dec 2017 16:10:09 +0000

> The non-mobile flows are never encapsulated in GTP.

To be clear there is really no such thing as a non-mobile device unless we can fix the RF environment so that it never changes over the life of the device's connection (mmWave line of site perhaps would be fixed). This is especially true of a device which is close to the boundary between two sectors as it may flip back and forth regularly as the RF conditions change (rain, traffic etc).

Essentially there are four approaches to deal with this:

1 - flat routing - no encap, so every time RF conditions change the routes are updated everywhere.. not so great.
2 - tunnel to a fixed point - what we do today but hairpins, delay etc.
3 - map and tunnel - exactly what we do for VPN's today but with quicker mapping technology i.e. LISP etc. same as all OTTs today.
4 - reattach and re-allocate a different address - ok but control traffic is now pretty busy as RF conditions change and UE has to restart its connections. This is WIFI essentially or WIFI to LTE today.

So I don’t think you can escape mobility even for IOT type devices and option 1 and 4 are probably not going to scale very well for those cases.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Dec 2017 09:19:17 -0800

> 4 - reattach and re-allocate a different address - ok but control traffic is now pretty busy as RF conditions change and UE has to restart its connections. This is WIFI essentially or WIFI to LTE t…

Peter,

That is a good synopisis of the solution space of IP mobility.

I believe #3 describes identifier/locator protocols and is the method
espoused by of the all the protocols that have been proposed on this
list thus far (ILA,ILNP,LISP,SR). Also note, the problem of mobility
is not unique to this use cases. Cloud and network virtualization have
already fully deployed identifier/locator solutions that allow
efficient VM and task mobility.

> So I don’t think you can escape mobility even for IOT type devices and option 1 and 4 are probably not going to scale very well for those cases.
Additionally, there is also a motivation to assign non-topological
untrackable addresses for privacy even to devices that might never be
mobile. This is also facilitated by identifier/locator split (option
#3).

Tom

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Mon, 11 Dec 2017 18:45:43 +0000

All:

Based on the comments, here is the Word template for the white paper. 

I included impact to N4, impact to SMF and slice based mobility management as criteria for evaluation.
Every solution will need to address slice based mobility management, hence has been included
in the Criteria for Evaluation section.

Let me know who can provide content to the various sections. 
I can provide content into Section 1, 2, 3, and 4 pertaining to 3GPP accesses. 

Does anyone know how to move this white paper work into DMM or other WG? Also how can we
create liaison statements to 3GPP as needed while we work on the White paper?

Kalyani

> Sent: Saturday, December 9, 2017 7:39 PM
> To: [email-masked]
> This can be used as a basis for the study item in 3GPP that starts work in July
> 2018. If we have questions as we  develop this white paper, we can send
> Liaison statements to 3GPP
> 3GPP CT4 has agreed to study possible candidates for user plane protocol for
> N9 (UPF - UPF) interface based on stage 2 requirements from TS 23.501

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 11 Dec 2017 18:51:51 +0000

Kalyani,

Did you have a look at the "evolving 5G routing" white paper that we wrote a month or so ago?

https://meetings.webex.com/collabs/url/VkonUGsFDdkEErJGrYRldUt3rrkjRjr

Myself, Dino, Arash and Kure put a fair amount of work into that. You may be able to find some useful stuff in there ;)

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Bogineni, Kalyani
Sent: Monday, December 11, 2017 1:46 PM
To: [email-masked]
Subject: Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore

All:

I included impact to N4, impact to SMF and slice based mobility management as criteria for evaluation.
Every solution will need to address slice based mobility management, hence has been included in the Criteria for Evaluation section.

Does anyone know how to move this white paper work into DMM or other WG? Also how can we create liaison statements to 3GPP as needed while we work on the White paper?

Kalyani

> This can be used as a basis for the study item in 3GPP that starts 
> work in July 2018. If we have questions as we  develop this white 
> paper, we can send Liaison statements to 3GPP
> protocol for
> TS 29.281: Protocol details of GTPv1-U TS 29.274: Protocol details of 
> GTPv2-C TS 29.244: Interface between control and user plane of EPC 
> nodes
> 
> Kalyani Bogineni
> Verizon

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Mon, 11 Dec 2017 19:14:05 +0000

Peter:

I saw that paper. Can you help me identify which sections from that paper can
be included in this white paper? There is some background information, some
problem description and ILSR description. Do you see ILSR as a variant of LISP
based solution or would you consider that as an independent solution? Right
now I placed ILSR as a variant of LISP based solution.

Kalyani

> From: AshwoodsmithPeter [mailto:[email-masked]]
> Sent: Monday, December 11, 2017 1:52 PM
> To: Bogineni, Kalyani <[email-masked]>;
> [email-masked]; [email-masked]
> 3A__meetings.webex.com_collabs_url_VkonUGsFDdkEErJGrYRldUt3rrkjRjr&
> d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiS
> ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&
> m=CMwDWsZ6Ury2BiPPSUvLhhhXttXQyYI86idIALgkIC4&s=GPqCW38KewU_
> 5yzHud2R2LTitjXT-_BW98_k41TJO9o&e=
> 
> 
> 
> Myself, Dino, Arash and Kure put a fair amount of work into that. You may be
> able to find some useful stuff in there ;)
> 
> 
> 
> Peter
> 
> 
> 
> Every solution will need to address slice based mobility management, hence
> has been included in the Criteria for Evaluation section.
> 
> 
> 
> Does anyone know how to move this white paper work into DMM or other
> WG? Also how can we create liaison statements to 3GPP as needed while we
> work on the White paper?
> 
> 
> 
> Kalyani
> 
> 
> 
> > Title "IP Session Management and Mobility Management for 5G and Next
> 
> > Generation Internet"
> 
> > (Mobility management mechanisms have an impact on how session
> 
> > management is done, hence the title)
> 
> >
> 
> > Sections:
> 
> >
> 
> > management and mobility management work in LTE and with non-3GPP
> 
> > accesses.
> 
> >
> 
> > Some references for GTP:
>

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 11 Dec 2017 19:24:49 +0000

> On 11 Dec 2017, at 16:10, AshwoodsmithPeter <[email-masked]> wrote:
> 
> 

5 - dynamic binding - discover a (topologically "correct") locator value, and rebind the identifier to that locator value (UE does not need to restart connections, as they are bound to the identifier, and not the locator)

Cheers,
--/Saleem

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 11 Dec 2017 19:26:03 +0000

Tom;

> On 11 Dec 2017, at 17:19, Tom Herbert <[email-masked]> wrote:
> 
> list thus far (ILA,ILNP,LISP,SR).

No, ILNP does not use tunnels.

> Also note, the problem of mobility

Or by option 5 (please see my other message).

Cheers,
--/Saleem

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 11 Dec 2017 19:30:50 +0000

Kalyani,

The view we took with the white paper was not to try to get into the details of the different location/separation protocols. To be honest those details while important don't "matter" as much as the architectural concept. So we focused on how the architectural concept solves problems. One could have a section on which of the different id/separation data planes was 'best' but I think that is the wrong thing to focus on until fairly late in the discussion. There is also a fairly interesting discussion around how the mapping/control should work which has a very big impact on the performance and scale.

Anyway I think the overview and challenges could be included and I think the generic description of ID-Location separated routing could be included before getting into the different data planes of each.

Peter

-----Original Message-----
From: Bogineni, Kalyani [mailto:[email-masked]] 
Sent: Monday, December 11, 2017 2:14 PM
To: AshwoodsmithPeter <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [5gangip] [E] Re: MINUTES of side meeting in Singapore

Peter:

I saw that paper. Can you help me identify which sections from that paper can be included in this white paper? There is some background information, some problem description and ILSR description. Do you see ILSR as a variant of LISP based solution or would you consider that as an independent solution? Right now I placed ILSR as a variant of LISP based solution.

Kalyani

> Myself, Dino, Arash and Kure put a fair amount of work into that. You 
> may be able to find some useful stuff in there ;)
> 
> 
> 
> Peter
> 
> 
> 
> Every solution will need to address slice based mobility management, 
> hence has been included in the Criteria for Evaluation section.
> 
> 
> 
> WG? Also how can we create liaison statements to 3GPP as needed while 
> we work on the White paper?
> 
> 
> 
> Kalyani
> 
> 
> 
> > the
> > -
> > 21 - 25 May. CT4 said that they can respond to questions from IETF 
> > in phase
> 1.
> 
> >
> 
> > session

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 11 Dec 2017 19:35:34 +0000

>No, ILNP does not use tunnels.

But, there is translation some where correct? They all boil down to either
Tunneling or Translation?

In all of these approaches, there is a Loc/ID mapping state (ignoring the
terms). Some approaches keep that state on an anchor, some keep it
centralized and some distribute the states. At the end, its tunneling, or
by translation. 

Interestingly and one sense, with the CUPS and a programmable interface to
the user-plane, all of these approaches are converging. The control plan
has the state, it can learn the mobility events from the RAN, and can
program the translation/tunnel rule on the user-plane over that
programmable interface.

Sri

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 11 Dec 2017 19:36:14 +0000

> No, ILNP does not use tunnels.

I think of ID-Location separated routing as an architecture rather than a specific implementation. What makes the 'tunnels' part of ID-Location separated routing work is that they are globally routable, addresses, most likely hierarchical into which you can send traffic with a different address space. Call it what you want .. it’s the architecture that matters at the moment. 

I strongly think an architectural discussion with pros/cons relative to other architectures is more useful than a bits and bytes comparison, at least initially.

Peter

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 11 Dec 2017 19:51:16 +0000

Peter;

> On 11 Dec 2017, at 19:36, AshwoodsmithPeter <[email-masked]> wrote:
> 

I guess that the word "architecture" is over-loaded, and so probably worth qualifying, e.g. "systems architecture" (e.g. engineering, how it should be built), or "functional architecture" (e.g. what we want it to do, and how functions relate to each other). I guess these are my own distinctions, so my apologies if that is not helpful.

My feeling is that a lot (but not all) of the discussion so far has been related to "systems architecture", which seems to have some strong non-functional requirements attached to it, i.e. maintaining specific engineering, such as GTP, for practical reasons (I have no problem with that, by the way, just stating my observation).

> I strongly think an architectural discussion with pros/cons relative to other architectures is more useful than a bits and bytes comparison, at least initially.

Agreed ... if I am presumptuous and read your sentence above as meaning a discussion on "functional architectures".

I suspect, then, to have that discussion we need some functional requirements.

Cheers,
--/Saleem

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Dec 2017 11:58:20 -0800

> No, ILNP does not use tunnels.
Neither does ILA. I think identifier/locator split is the common
thread so maybe #3 should be reworded. I admit I'm not exactly sure
how SR works to provide mobility so that might not be entirely
correct.

Tom

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 11 Dec 2017 20:03:44 +0000

> Neither does ILA. I think identifier/locator split is the common thread so maybe #3 should be reworded. I admit I'm not exactly sure how SR works to provide mobility so that might not be entirely correct.

If you list out the different technology approaches on one axis and the problems to be solved on the other that pops out rather glaringly.  FMC, Mobility, reduced signaling etc. are to the best of my knowledge mostly unaffected by SR although if you wanted to signal explicit routes then it helps.

---

From: Bill Gage <[email-masked]>
Date: Mon, 11 Dec 2017 20:04:14 +0000

> I think identifier/locator split is the common thread.

I disagree. The common thread in all of these discussion is traffic steering.

In some cases, traffic steering is being used to redirect (downlink) traffic to the current attachment point of a device. In other cases, traffic steering is being used to redirect (uplink) traffic to the "closest" network border router. In other cases, traffic steering is being used to force packets to follow a particular path to meet operator requirements for security, accounting, LI, QoS, etc.

Cheers ... 

/bill

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Monday, December 11, 2017 2:58 PM
To: Saleem Bhatti <[email-masked]>
Cc: [email-masked]; Cameron Byrne <[email-masked]>; Bogineni, Kalyani <[email-masked]>; AshwoodsmithPeter <[email-masked]>
Subject: Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore

Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Dec 2017 12:26:45 -0800

> In some cases, traffic steering is being used to redirect (downlink) traffic to the current attachment point of a device. In other cases, traffic steering is being used to redirect (uplink) traffic…
I don't believe so. Peter's four options were specifically about
device mobility not just a general explanation for traffic steering or
even simple routing. The mobility problem is how to forward packets to
non-topological destination addresses (save that option #1 is used and
the network feasilby manage a billions of host routes).

Tom

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 11 Dec 2017 20:43:52 +0000

>I disagree. The common thread in all of these discussion is traffic steering.

Hey Bill, If you add requirements such as:

- irrespective of the access technology
- without per UE state except as needed by the edges
- allowing for high volume changes in attachment point

Then I would agree  and I'd further note that ID-LOC separated routing is one possible architecture to meeting all of those requirements. 

Peter

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 Dec 2017 14:51:48 -0600

Folks,
I missed the requirements discussion.
I think that the requirements stated so far are good but for better
recording a different thread name should have been used.

Also, please remove as many names as possible from the cc list.

Regards,
Behcet

On Mon, Dec 11, 2017 at 2:43 PM, AshwoodsmithPeter <
[email-masked]> wrote:

> Then I would agree  and I'd further note that ID-LOC separated routing is
> one possible architecture to meeting all of those requirements.
>
> Peter
>

---

From: sothy shan <[email-masked]>
Date: Mon, 11 Dec 2017 22:21:18 +0100

> program the translation/tunnel rule on the user-plane over that

Hello Sri,
Using Mobility events and topology information of data plane network,
control plan can program user plane over native IP. (no tunnel).
This is not E2E solution, can be replacement of current EPC core network
from eNB to PGW. If control plane of the operartor keeps those information,
features (Policy Enforcement, QoS
- Billing, Statistics, Accounting, Metering
- Lawful Interception, Traffic Monitoring
- Roaming
- MVNO
- IMS interaction
- Inter Carrier Communication
- Interaction with Voice Network
- What about 3G, 2G)   (taken from 5G routing evolution)

can be provided also by operators.

I am not sure what is today status of CUPS design at 3GPP. My understanding
is that it is just proposal the split of control plane and user plane with
a protocol (PFCP).
It does not explicitly use mobility events.

Already some people talks complexity of LTE protocols here. Newly emerged
PFCP itself seems complex.
PFCP has 23 messages and  116 IEs for flow detection, flow forwarding
action, QoS, report reporting and buffering.
#Reducing the complexity of the control plane is also one requirement.

A+
Sothy

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 11 Dec 2017 22:35:37 +0000

Hi Sothy,

> Using Mobility events and topology information of data plane network, control plan can program user plane over native IP. (no tunnel).
This is not E2E solution, can be replacement of current EPC core network from eNB to PGW.

With separation of control plane or CUPS (by the way this is a general trend and not a 3GPP innovation), it now gives you greater flexibility with respect to programming the user plane. To tunnel a packet or a apply a translate the addressing is a simple a Rule that gets pushed from the control plane. Now, how that CP entity obtains that policy can be an event from the Radio network, Authentication frame work or a mobility signaling event from the access network.

> If control plane of the operartor keeps those information, features (Policy Enforcement, QoS - Billing, Statistics, Accounting, Metering
- Lawful Interception, Traffic Monitoring - Roaming - MVNO - IMS interaction - Inter Carrier Communication - Interaction with Voice Network

There is lot of 3GPP functions/terminology above, but the capabilities that you need from the data plane are not unique to 3GPP access.  My IP flows that go over LTE network, DSL network, or an enterprise network fundamentally require the same set of basic services. Meter/Prioritize/Block/Steer... So, if we can abstract the entire data plane and build a service layer, we can ignore what happens in that control plane layer.

>  Already some people talks complexity of LTE protocols here. Newly emerged PFCP itself seems complex. PFCP has 23 messages and  116 IEs for flow detection, flow forwarding action, QoS, report reporting and buffering.    #Reducing the complexity of the control plane is also one requirement.

I do not think IETF should even attempt to remove 3GPP CP complexity. So much is tied to the radio network there is no point and we don't understand any thing there. Instead, if we can try to build a data plane which does not smell and feel like a 3GPP data plane, its a huge success.

Sri

From: sothy shan <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 11, 2017 at 1:21 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Bogineni, Kalyani" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore

On Mon, Dec 11, 2017 at 8:35 PM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Sri,
Using Mobility events and topology information of data plane network, control plan can program user plane over native IP. (no tunnel).
This is not E2E solution, can be replacement of current EPC core network from eNB to PGW. If control plane of the operartor keeps those information, features (Policy Enforcement, QoS
- Billing, Statistics, Accounting, Metering
- Lawful Interception, Traffic Monitoring
- Roaming
- MVNO
- IMS interaction
- Inter Carrier Communication
- Interaction with Voice Network
- What about 3G, 2G)   (taken from 5G routing evolution)

I am not sure what is today status of CUPS design at 3GPP. My understanding is that it is just proposal the split of control plane and user plane with a protocol (PFCP).
It does not explicitly use mobility events.

Already some people talks complexity of LTE protocols here. Newly emerged PFCP itself seems complex.
PFCP has 23 messages and  116 IEs for flow detection, flow forwarding action, QoS, report reporting and buffering.
#Reducing the complexity of the control plane is also one requirement.

A+
Sothy

Sri

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 12 Dec 2017 11:17:52 +0900

I agree with Sri, thanks.

> I do not think IETF should even attempt to remove 3GPP CP complexity. So much is tied to the radio network there is no point and we don’t understand any thing there. Instead, if we can try to build a data plane which does not smell and feel like a 3GPP data plane, its a huge success.

+1

In terms of control/data plane separation architecture, we can provide a data plane suit which is employed by any type of mobility control method including existing one. 3GPP Rel-15 has already taken the service based control plane architecture on top of data plane. It means that it allows operators to deploy data plane functions into the path in much more flexible ways in addition to just mobility.  

The study item of user plane protocol in CT4 will seek the candidates for that.

cheers,
--satoru

> 2017/12/12 7:35、Sri Gundavelli (sgundave) <[email-masked]>のメール:
> 
> Hi Sothy,
> 
> - Lawful Interception, Traffic Monitoring - Roaming - MVNO - IMS interaction – Inter Carrier Communication – Interaction with Voice Network 
> 
> There is lot of 3GPP functions/terminology above, but the capabilities that you need from the data plane are not unique to 3GPP access.  My IP flows that go over LTE network, DSL network, or an enterprise network fundamentally require the same set of basic services. Meter/Prioritize/Block/Steer… So, if we can abstract the entire data plane and build a service layer, we can ignore what happens in that control plane layer. 
> 
> 
> 
> 
> I do not think IETF should even attempt to remove 3GPP CP complexity. So much is tied to the radio network there is no point and we don’t understand any thing there. Instead, if we can try to build a data plane which does not smell and feel like a 3GPP data plane, its a huge success.
> 
> 
> Sri
> 
> 
> 
> From: sothy shan <[email-masked]>
> To: Sri Gundavelli <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "Bogineni, Kalyani" <[email-masked]>
> On Mon, Dec 11, 2017 at 8:35 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
>> 
>>

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 12 Dec 2017 11:55:15 +0900

Hello Kalyani,

> [...]

> Does anyone know how to move this white paper work into DMM or other WG?

You can just post that draft named draft-bogineri-dmm-....

> Also how can we

I thinks we need to wait final approval for the SID and first liaison from CT4.

Cheers,
--satoru

> <draft-white-paper-01.docx>_______________________________________________
> 5gangip mailing list
> [email-masked]

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Tue, 12 Dec 2017 03:03:51 +0000

Thank you Saturo.

Just to confirm: Will DMM WG consider all the protocols listed in the outline for evaluation in the white paper?

Kalyani

From: "Satoru Matsushima" <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 11, 2017 at 9:55:24 PM
To: "Bogineni, Kalyani" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [5gangip] [E] Re: MINUTES of side meeting in Singapore

Hello Kalyani,

Cheers,
--satoru

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIFAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=RExSRCZPZ59JTqWb7xJuL827PuJTppPpbLHjG4mkfDo&s=96Y2kj1rylvPfl1e28-PruO_xP-Zh2l-Vk9O5VCY6TI&e=

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 12 Dec 2017 13:11:51 +0900

Kalyani, I think yes you can bring it to DMM anything that related mobility.

Cheers,
--satoru

> 2017/12/12 12:03、Bogineni, Kalyani <[email-masked]>のメール:
> 
> 
> Thank you Saturo. 
> 
> From: "Satoru Matsushima" <[email-masked]>
> To: "Bogineni, Kalyani" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 12 Dec 2017 13:20:05 -0600

Hi Satoru,

> Kalyani, I think yes you can bring it to DMM anything that related
Wait a minute.

dmm works on PMIP, MIP derivatives, i.e. mainly tunneling based for 4G
mobility.
5G IP list is on everything 5G, mainly IP related issues, of course
including 5G mobility. We have been concentrating on no-tunnels mobility,
mainly using  id-loc systems.
We welcome people from dmm to join our list and help us in the issues.
Thanks to you and Sri.

Hope this clarifies.

Behcet

> > Just to confirm: Will DMM WG consider all the protocols listed in the
> outline for evaluation in the white paper?
> >
> > Kalyani
> >
> >
> >
> WG?
> work in July
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_5gangip&d=DwIFAg&c=
> udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=
> IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=
> RExSRCZPZ59JTqWb7xJuL827PuJTppPpbLHjG4mkfDo&s=96Y2kj1rylvPfl1e28-PruO_xP-
> Zh2l-Vk9O5VCY6TI&e=
> >
>

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 13 Dec 2017 16:37:58 +0900

Hi Behcet,

> dmm works on PMIP, MIP derivatives, i.e. mainly tunneling based for 4G mobility.

When I see DMM charter it seems partially correct.

> 5G IP list is on everything 5G, mainly IP related issues, of course including 5G mobility. We have been concentrating on no-tunnels mobility, mainly using  id-loc systems.

Thanks for that clarification. I agree and thank you too for hosting good discussion on the list and side meetings.

But I didn’t see that it represents IETF responsibility to develop _5G_ protocols. So that’s why I suggested Kalyani DMM to work in terms of user plane study in IETF side. It doesn’t mean that I’d disturb any discussions on this list so please don’t get me wrong.

Cheers,
--satoru

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 13 Dec 2017 18:23:33 +0000

Folks:

After discussion with DMM WG Chair on timelines for the white paper and 
the potential need for Liaison Statements between IETF and 3GPP with
reference to this work, this work is being moved to the DMM WG. 

Kalyani Bogineni
Verizon