Subject: [DMM] DMM solution space categorization

From: Alper Yegin <[email-masked]>
Date: Sat, 19 Jul 2014 11:44:03 +0300

I've updated the list with the I-Ds suggested by Behcet/Fred/Jouni.

Please see below for my opinions about how each category relates to the overall work.
Comments welcome.

1. Per-flow IP address configuration according to mobility needs

Apps indicating their mobility needs to the IP stack on the MN, and associated IP configuration signaling between the MN and the network.

draft-bhandari-dhc-class-based-prefix-03
draft-korhonen-dmm-prefix-properties-00.txt
draft-yegin-dmm-ondemand-mobility-02

This category is essential, given that we all agree mobility will be treated on a per-flow basis.
(and once we dive into the category, I'd say the aforementioned I-Ds are complementary).

2. Mobility solution selection 

MN determining the type of mobility solution(s) it'd apply to a given flow.

draft-yegin-ip-mobility-orchestrator-00

In recognition of L4+ mobility solutions (such as MPTCP, SIP, apps having their own), this also becomes essential for a DMM solution. Some people may argue, discussion is very welcome.

3. IP anchor selection

MN selecting the IP anchor node after it decides to use IP anchoring (whether in the access network or the core network).

draft-aliahmad-dmm-anchor-selection-00.txt

This category is supporting the Category 4, 5 and 6. This is about more intelligent way of picking the IP anchor once the type of anchor is determined.
This may produce a standalone I-D, or may be folded into individual solutions in those categories. 

4. Access network anchoring

Anchoring IP address within the access network using IP-in-IP tunneling.

draft-bernardos-dmm-cmip-01
draft-bernardos-dmm-pmip-03
draft-bernardos-dmm-distributed-anchoring-04
draft-chan-dmm-enhanced-mobility-anchoring-00
draft-sarikaya-dmm-for-wifi-00.txt
draft-seite-dmm-dma-07.txt
draft-xuan-dmm-nemo-dmm-02.txt
draft-korhonen-dmm-local-prefix-01

The need for this category is well-understood. The challenge is having plethora of solutions. Though the main concept is common… 

5. Corresponding node/network anchoring

Anchoring IP address on the Corresponding Node or Corresponding Network.

Mobile IPv6 route optimization
draft-yegin-dmm-cnet-homing-02
draft-xiong-dmm-ip-reachability-01
draft-templin-aerolink-29

This category of solutions are also needed (for their ability to produce better paths and different applicability with respect to the Category 4)

6. Host-route based intra-domain solutions

Non-tunneling solutions.

draft-chan-dmm-enhanced-mobility-anchoring-00
draft-matsushima-stateless-uplane-vepc-02
draft-mccann-dmm-flatarch-00
draft-sarikaya-dmm-for-wifi-00.txt

Solutions in this category are competing with the Category 4 type solutions. There are various pros and cons. IMHO, we cannot resolve that contest, hence we should produce solution for both categories and let the industry pick and choose. Given that these solutions are isolated from the other components (categories), standardizing both should not have adverse impact on the overall DMM complexity.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 20 Jul 2014 22:06:53 +0300

Alper,

Thanks for doing the categorization work. We should also try to look 
these how they fit under the proposed new milestones. See below:

7/19/2014 11:44 AM, Alper Yegin kirjoitti:
> *
> *
> *
> *
> *
> *
> *1. Per-flow IP address configuration according to mobility needs*

"Exposing mobility state to mobile nodes and network nodes"

> Apps indicating their mobility needs to the IP stack on the MN, and
> associated IP configuration signaling between the MN and the network.
>

Then we have a number of I-Ds from MIF:

  draft-kk-mpvd-ndp-support
  draft-kkb-mpvd-dhcp-support
  draft-kkbg-mpvd-id

These intend to build the overall method of conveying the signaling 
between the network and the mn. There are no spacific use cases 
described for mobility yet but those are then amendments for the above.

  draft-liu-dmm-mobility-api

Above has extensions to RFC5014 for applications to check prefix properties.

> *2. Mobility solution selection *

In my optinion this also fits under "Exposing mobility state to mobile 
nodes and network nodes".

> In recognition of L4+ mobility solutions (such as MPTCP, SIP, apps
> having their own), this also becomes essential for a DMM solution. Some
> people may argue, discussion is very welcome.
>
>
>
> *3. IP anchor selection*

"Enhanced mobility anchoring"

> MN selecting the IP anchor node after it decides to use IP anchoring
> (whether in the access network or the core network).
>
> This category is supporting the Category 4, 5 and 6. This is about more
> intelligent way of picking the IP anchor once the type of anchor is
> determined.
> *4. Access network anchoring*

Still related to "Enhanced mobility anchoring". Many of these I-Ds 
handle the anchor change issues (like tunneling between the anchors).

> The need for this category is well-understood. The challenge is having
> plethora of solutions. Though the main concept is common…
>
>
> *5. Corresponding node/network anchoring*

Still under "Enhanced mobility anchoring".

> This category of solutions are also needed (for their ability to produce
> better paths and different applicability with respect to the Category 4)
>
>
> *6. Host-route based intra-domain solutions*

"Forwarding path and signalling management"

> Solutions in this category are competing with the Category 4 type
> solutions. There are various pros and cons. IMHO, we cannot resolve that
> contest, hence we should produce solution for both categories and let
> the industry pick and choose. Given that these solutions are isolated
> from the other components (categories), standardizing both should not
> have adverse impact on the overall DMM complexity.
>
> Alper

- JOuni

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

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 20 Jul 2014 22:11:12 +0300

And then there is the "Distributed mobility management deployment models 
and scenarios":

   draft-liu-dmm-deployment-scenario

Forgot that.. sprry.

- Jouni

---

From: Marco Liebsch <[email-masked]>
Date: Sun, 20 Jul 2014 19:26:40 +0000

You may add the framework draft to that category as well.
draft-liebsch-dmm-framework 

Marco

On 20.07.2014, at 15:11, "Jouni Korhonen" <[email-masked]> wrote:

> And then there is the "Distributed mobility management deployment models and scenarios":
>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 21 Jul 2014 17:31:47 +0300

Marco, Jouni,

The categorization I provided was for the "solution space".
Framework, and deployment models are not solution documents.

If I'm missing something, and also for any other docs I missed in the categorization, folks please also suggest where they should fit in when sending the I-D names.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 21 Jul 2014 17:38:26 +0300

Jouni,

> These intend to build the overall method of conveying the signaling between the network and the mn. There are no spacific use cases described for mobility yet but those are then amendments for the above.
> 

MIF problem space is different than DMM's. 
We should not create any dependency between the two.

> draft-liu-dmm-mobility-api

I'll add that.

Alper

> In my optinion this also fits under "Exposing mobility state to mobile nodes and network nodes".
> 
> Still related to "Enhanced mobility anchoring". Many of these I-Ds handle the anchor change issues (like tunneling between the anchors).
>

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 21 Jul 2014 18:04:41 +0300

Alper,

>> These intend to build the overall method of conveying the signaling between the network and the mn. There are no spacific use cases described for mobility yet but those are then amendments for the…

I am bringing these up because they _do_ propose a framework for 
MN-Network communication.. specifically when you need to add semantical 
information into prefix/link/etc information the network advertises to 
the MNs.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 21 Jul 2014 14:55:36 -0500

Hi all,

I am unable to understand why we are complicating life so much.
It seems like we forget the fact that this WG existed since 2012 and
many things happened since then.

Initially we had this simple categorization:

MIP-based approaches, those that are requiring a client at the MN,

PMIP-based approaches not requiring a client at the MN but some prefix
management may be needed due to the distributed approach.

Routing based approaches not requiring a client also not requiring
prefix management

My question is why these 3 categories are not enough?

Regards,

Behcet

On Mon, Jul 21, 2014 at 10:04 AM, Jouni Korhonen <[email-masked]> wrote:
>>> between the network and the mn. There are no spacific use cases described
>>> for mobility yet but those are then amendments for the above.
>
>
> I am bringing these up because they _do_ propose a framework for MN-Network
> communication.. specifically when you need to add semantical information
> into prefix/link/etc information the network advertises to the MNs.
>
> - Jouni
>
>
>
>>>
>>
>>
>>> Still related to "Enhanced mobility anchoring". Many of these I-Ds handle
>>> the anchor change issues (like tunneling between the anchors).
>>>