Subject: [DMM] draft-yegin-ip-mobility-orchestrator-00.txt

From: Alper Yegin <[email-masked]>
Date: Fri, 4 Jul 2014 10:10:46 +0300

Hello DMMers,

We have a new I-D for your reading and discussion.

 Title           : IP Mobility Orchestrator
 Authors     : Alper Yegin
                      Jungshin Park
                      Kisuk Kweon
                      Jinsung Lee
Filename   : draft-yegin-ip-mobility-orchestrator-00.txt
Pages         : 13
Date            : 2014-07-03

Abstract:
  Host stacks can support mobility at multiple layers.  Mobility
  protocols operating at different layers constitute alternate
  solutions with various pros and cons, and they can also have adverse
  affects on each other when used simultaneously.  Optimal results in
  terms of seamless handover and data-path optimization can be achieved
  when execution of these protocols are coordinated.

We'll also be submitting an IPR statement to IETF.

https://datatracker.ietf.org/doc/draft-yegin-ip-mobility-orchestrator/

Please review this I-D and share your comments.

Thanks,

Alper

---

From: Weixinpeng <[email-masked]>
Date: Mon, 7 Jul 2014 03:57:25 +0000

Hi Alper,
I agree with you that there should be some kind of coordination between different mobility mechanisms.
Thanks for providing this document, and here are some of my questions:
(1) It's possible for orchestrator to discovery mobility capabilities such as MIPv6, PMIPv6, GTP, MPTCP, but I think it's not convenient to find out whether L7 application is mobility capable.
(2) If there is no communication between MN and CN, then which mobility management scheme will be used when MN moving in network?
(3) what's the criteria for Mobility Protocol Selection in section 4.4? I think that may depends on the characteristic of application traffic.
(4) In Fig. 2, step 5b, you mean the DNS system is used to discovery CN's mobility capability? Could be explain how it works?

Thanks!
Best Regards,
Xinpeng

From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Friday, July 04, 2014 3:11 PM
To: [email-masked]
Subject: [DMM] draft-yegin-ip-mobility-orchestrator-00.txt

Hello DMMers,

Abstract:

Thanks,

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 9 Jul 2014 12:21:55 +0300

Hello Xinpeng,

Thank you for your review and comments.

Please see below.

On Jul 7, 2014, at 6:57 AM, Weixinpeng wrote:

> (1) It’s possible for orchestrator to discovery mobility capabilities such as MIPv6, PMIPv6, GTP, MPTCP, but I think it’s not convenient to find out whether L7 application is mobility capable.

We are thinking that this is possible thru an API where the app can register its mobility capability. This can be complemented by application profiling.

> (2) If there is no communication between MN and CN, then which mobility management scheme will be used when MN moving in network?

You mean, if there is no flow between MN and any CN, then what mobility protocol would be used?
In that case, there is no need for any mobility. In other words, the MN can be configured with a nomadic IP address.

> (3) what’s the criteria for Mobility Protocol Selection in section 4.4? I think that may depends on the characteristic of application traffic.

This algorithm is for flows that require session continuity. 
If the flow requires a fixed IP address, then it needs a Mobile IP with fixed HA (legacy MIP) solution.
If the flow needs neither of the above, then it'd be happy with any IP address (nomadic IP address is fine).

> (4) In Fig. 2, step 5b, you mean the DNS system is used to discovery CN’s mobility capability? Could be explain how it works?
>  

We are thinking of defining new DNS resource records to store mobility capability in DNS.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 16 Jul 2014 02:19:55 +0300

Alper,

I had a quick read on the document. There are few places that I need 
clarification for my own education.. since I have a feeling that the 
text does not say everyting it assumes a priori. Furthermore, I got some 
more editorial comments.

Section 3. says:

    Solutions operating above the IP layer include MPTCP, SCTP, SIP, and
    application-specific ones.  Availability of these protocols cannot be

I would add references to SCTP and SIP specifications that actually add 
the handover functionality to the listed protocols. Also, there could be 
more protocols to add like DCCP..

During the handovers are multiradio cases ruled out or also applicable 
or even assumed? I cannot see that clearly from the motivation or 
solution part.

Section 4.1. says:

    data-path optimization.  On the other hand, above-IP solutions
    provide data-path optimization but fail to provide seamless
    handovers.  The ideal solution would be based on coordianted

I do not agree this fully. "Above-IP solution" allow seamless handovers 
in cases where you can have multiple radios on simultaneously.

In Figure 2. and the related text:

What is unclear to me is s-GW would keep the IP1 when the MN attaches to 
t-GW. What is the background assumption here? Is MN attached to both GWs 
simultaneously?

- Jouni

7/4/2014 10:10 AM, Alper Yegin kirjoitti:
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 16 Jul 2014 09:40:52 +0300

Hi Jouni,

Thank you for the review and feedback.
Please see below.

> 
> Alper,
> 
> I had a quick read on the document. There are few places that I need clarification for my own education.. since I have a feeling that the text does not say everyting it assumes a priori. Furthermore, I got some more editorial comments.
> 
> Section 3. says:
> 
> I would add references to SCTP and SIP specifications that actually add the handover functionality to the listed protocols. Also, there could be more protocols to add like DCCP..
> 

OK.

> During the handovers are multiradio cases ruled out or also applicable or even assumed? I cannot see that clearly from the motivation or solution part.
> 

Just like for any of our base IETF protocols, we cannot assume multiple radios exist on a given node.
So, this solution works even for single-radio nodes.

> I do not agree this fully. "Above-IP solution" allow seamless handovers in cases where you can have multiple radios on simultaneously.
> 

That's right. But we are providing a solution for the general case where there's only one connected radio.
We can add "multi-radio" considerations (as a special case) in the next version of the draft. 

> What is unclear to me is s-GW would keep the IP1 when the MN attaches to t-GW. What is the background assumption here? Is MN attached to both GWs simultaneously?
> 

The MN has a single radio connection. But, it can maintain its previous IP address with the help of a tunnel between the s-GW and the MN or t-GW. 
This is what we call "access network anchoring".

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 16 Jul 2014 18:59:39 +0300

Alper,

> So, this solution works even for single-radio nodes.

Ok.. I get confused by Figure 1 saying the sub-IP mobility is PMIPv6. 
AFAIR what is in figure is somewhat stretching what PMIPv6 does now. 
That is also what I meant about assumptions that are not said.

> This is what we call "access network anchoring".

I might be a good idea to clarify that a handover from s-GW to t-GW 
specifically with a single radio does not cause s-GW to think the MN is 
not under its control anymore.. even if the s-GW notices that the MN has 
lost the radio connectivity. Same also on the MN side.. even if the 
radio connectivity to the s-GW was lost, it does not imply discarding 
the IP from the interface..

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Thu, 17 Jul 2014 00:53:26 +0300

> Ok.. I get confused by Figure 1 saying the sub-IP mobility is PMIPv6. AFAIR what is in figure is somewhat stretching what PMIPv6 does now. That is also what I meant about assumptions that are not said.
> 

Stretching in what sense?
s-GW is acting as LMA, and t-GW is acting as MAG in that case (which we can elaborate in the next rev).

> I might be a good idea to clarify that a handover from s-GW to t-GW specifically with a single radio does not cause s-GW to think the MN is not under its control anymore.. even if the s-GW notices that the MN has lost the radio connectivity. Same also on the MN side.. even if the radio connectivity to the s-GW was lost, it does not imply discarding the IP from the interface..
> 

Yes, we can elaborate on that.

Thanks.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 17 Jul 2014 01:29:12 +0300

Alper,

> s-GW is acting as LMA, and t-GW is acting as MAG in that case (which we can elaborate in the next rev).

That s-GW and t-GW mapping is not clear. Figure 1 step 1 makes me think 
s-GW is a LMA and step 4a also makes me think t-GW is a LMA. That is the 
source of confusion, since I do not know which nodes these GWs map to 
and what is assumed out of those (on top of existing PMIP). Just spell 
out the assumed functionality etc.

> Yes, we can elaborate on that.

Ok.

- Jouni