Subject: [Int-area] AD review of draft-zhu-mobility-survey

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Feb 2011 13:49:00 +0100

I was asked to AD sponsor this draft to an RFC. Sorry for the extremely 
long time this has taken to get to my review. But I have now reviewed it.

Abstract from draft-zhu-mobility-survey:

   Over the last two decades many efforts have been devoted to
   developing solutions for mobility support over the global Internet,
   which resulted in a variety of proposed solutions.  In this draft we
   conducted a systematic survey of the previous efforts to gain an
   overall understanding on the solution space of mobility support.
   This draft reports our finding and identifies remaining issues in
   providing ubiquitous and efficient global scale mobility support.

The document is well written and a pleasure to read. It is a relevant 
overview of the mobility protocol design space, and its analysis is 
useful for thinking about the deployment issues that we've seen in this 
space. As far as I can tell, the document includes most of the relevant 
work (some exceptions noted below), and I have no major technical 
comments. I have sent the draft forward to IETF Last Call, and hope that 
you can work on the remaining issues during the last call, and get more 
suggestions and additional material from the last call reviewers.

Technical:

> 4.12. IKEv2 Mobility and Multihoming Protocol (MOBIKE)
>
>
>    MOBIKE is an extension to Internet Key Exchange (IKEv2) to support
>    mobility and multihoming.  The main purpose of MOBIKE is to allow
>    roaming devices to keep the existing IKE and IPsec SAs despite of IP
>    address changes.  The mobility support in MOBIKE allows both parties
>    to move, but it does not provide a rendezvous mechanism.  In other
>    words, simultaneous movement of both parties is not supported.

Hmm. While this is true, part of the simultaneous mobility support is 
always in a stable anchor point, even in Mobile IP. If you assume mobike 
device 1 = host and mobike device 2 = gateway, then the situation really 
is equivalent to mobile IP mobile node - home agent arrangement. Home 
agent stays put, but mobiles can move around and everything still works.

Also, I think it would be useful to state something about multihoming 
support in some of these protocols. Some do support this, for instance 
Mobike and more recently, also Mobile IP. A feature matrix for the 
different protocols is not so interesting, but it would be useful to 
understand what scope the different protocols have.

> The reachability
>    information of the user's machine is published in DNS, and only
>    accessible to the subscriber.
>   

"published in DNS" and "only accessible to the subscriber" do not appear 
to be compatible statements. Can you expand on this a bit?

>    BTMM has millions of subscribers, which is perhaps the first large-
>    scale commercial host mobility support in Internet as of today.

I wonder if the use of Mobile IP in CDMA/3GPP2 networks exceeds this. 
Please check. Also, since you are missing GTP which is essentially a 
non-IETF variant of PMIP, you should probably include GTP and note that 
that network-based mobility support is extremely widely used (to the 
order of a billion data users).

> The second approach to mobility support is to provide a mapping
> between a mobile's stable identifier and its dynamically changing IP
> address.  Instead of notifying the world on every movement, a mobile
> only needs to update a single binding location about its location
> changes.  In this approach, if one level of indirection at IP layer
> is used, as in the case of Mobile IP, it has a potential side effect
> of introducing triangle routing; otherwise, if the two end nodes are
> aware of each other's movement, it means that both ends have to
> support the same mobility protocol.
>
> Yet there is the third case in which the protocols combine the above
> approaches, in the hope of keeping the pros and eliminating some cons
> of the two.  WINMO is a typically protocol in this case.
>   

This is a very nice classification. But I have a question. How would you 
classify designs that include support for route optimization, such as 
Mobile IP? They do not impact routers, but still there's a need to 
update more than a single entity about a new location? Also, in Section 
5.2 you talk about mobility aware entities, but this does not take into 
account whether the CNs are aware in route optimization mode.

Missing:

It might be valuable to describe the limited mobility support in 
transport layer solutions (SCTP and MP-TCP) as well. That is, they allow 
a single connection to stay up even as you move around, but do not by 
themselves allow simultaneous mobility of both parties. What about SHIM6?

I would talk about GTP (a network-based mobility protocol) as well.

What about mentioning application layer mobility designs (e.g., start 
from the paper by Henning on SIP mobility)?

It might be useful to have at least some pointers to various 
optimization efforts that the community has spent quite a lot of time 
on. It felt that FMIP was the only one that was mentioned in addition to 
the general idea of route optimization in Mobile IP.  Look for pointers 
from the MIPSHOP WG's page, RFC 4651, etc.

Editorial:

> Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and
> Prototypical Implementaion of An End-to-End Mobility
> Concept"
Typo

>    LISP-Mobility [LISP-Mobility <http://tools.ietf.org/html/draft-zhu-mobility-survey-03#ref-LISP-Mobility>] is a relatively new design, in which
>    the designer hopes to utilize LISP[LISP], which is designed for
>    routing scalability, to support mobility as well. 

This sentence could probably be simplified a bit.

Jari

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Feb 2011 05:01:49 -0800

Jari,

With apologies that this is the first time I am seeing
this document, I have to say that the survey is incomplete
without an analysis of the mobility management scheme that
is in-built within the IRON architecture:

http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt 

Please have a look at IRON and consider adding it to the
analysis. Let me know if there are any questions, and if
there is any help needed with adding text.

Thanks - Fred
[email-masked] 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Wednesday, February 09, 2011 4:49 AM
> To: [email-masked]; Lixia Zhang; 
> Internet Area
> Subject: [Int-area] AD review of draft-zhu-mobility-survey
> 
> >    LISP-Mobility [LISP-Mobility 
> <http://tools.ietf.org/html/draft-zhu-mobility-survey-03#ref-L
> ISP-Mobility>] is a relatively new design, in which
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 10 Feb 2011 01:17:59 -0800

Hi Jari,

Thanks for your review. Please find my comments inline.

On 2011/02/09, at 4:49, Jari Arkko wrote:

> I was asked to AD sponsor this draft to an RFC. Sorry for the extremely long time this has taken to get to my review. But I have now reviewed it.
> 
> The document is well written and a pleasure to read. It is a relevant overview of the mobility protocol design space, and its analysis is useful for thinking about the deployment issues that we've seen in this space. As far as I can tell, the document includes most of the relevant work (some exceptions noted below), and I have no major technical comments. I have sent the draft forward to IETF Last Call, and hope that you can work on the remaining issues during the last call, and get more suggestions and additional material from the last call reviewers.

thanks.

> Hmm. While this is true, part of the simultaneous mobility support is always in a stable anchor point, even in Mobile IP. If you assume mobike device 1 = host and mobike device 2 = gateway, then the situation really is equivalent to mobile IP mobile node - home agent arrangement. Home agent stays put, but mobiles can move around and everything still works.

What we meant "simultaneous mobility support" here is the scenario where two mobile nodes move at once.  In your above case, mobilke device2 is stable and don't move.
We will clarify this point.

> Also, I think it would be useful to state something about multihoming support in some of these protocols. Some do support this, for instance Mobike and more recently, also Mobile IP. A feature matrix for the different protocols is not so interesting, but it would be useful to understand what scope the different protocols have.

Which scopes do you have in your mind? 
I can imagine something like multihoming, dualstack, RO, network mobility, anything else?

> "published in DNS" and "only accessible to the subscriber" do not appear to be compatible statements. Can you expand on this a bit?
> 
> I wonder if the use of Mobile IP in CDMA/3GPP2 networks exceeds this. Please check. Also, since you are missing GTP which is essentially a non-IETF variant of PMIP, you should probably include GTP and note that that network-based mobility support is extremely widely used (to the order of a billion data users).

Right. We will update this part.

> This is a very nice classification. But I have a question. How would you classify designs that include support for route optimization, such as Mobile IP? They do not impact routers, but still there's a need to update more than a single entity about a new location? Also, in Section 5.2 you talk about mobility aware entities, but this does not take into account whether the CNs are aware in route optimization mode.

As a base protocol design, Mobile IP works with a single binding at HA. 
A mobile node can decide whether RO is activated or not. 
When we discuss the protocol design in high level, Route Optimization can be treated as an option so that we didn't mention RO here.

We will try to include RO feature in this document.
 
> Missing:
> 
> It might be valuable to describe the limited mobility support in transport layer solutions (SCTP and MP-TCP) as well. That is, they allow a single connection to stay up even as you move around, but do not by themselves allow simultaneous mobility of both parties. What about SHIM6?
> 
> What about mentioning application layer mobility designs (e.g., start from the paper by Henning on SIP mobility)?
> 
> It might be useful to have at least some pointers to various optimization efforts that the community has spent quite a lot of time on. It felt that FMIP was the only one that was mentioned in addition to the general idea of route optimization in Mobile IP.  Look for pointers from the MIPSHOP WG's page, RFC 4651, etc.

OK, I mostly agree with you. 

Do we need SHIM6 here? Although SHIM6 solve ID and locator things for multihoming purpose, it has potential to solve mobility issue, too.
I remembered there were some mobility discussion, but I'm not sure there is mobility related extension to SHIM6.

regards,
ryuji

---

From: Alberto García <[email-masked]>
Date: Thu, 10 Feb 2011 13:08:50 +0100

Hi Ryuji,

|  > It might be valuable to describe the limited mobility support in
transport
|  layer solutions (SCTP and MP-TCP) as well. That is, they allow a single
|  connection to stay up even as you move around, but do not by themselves
|  allow simultaneous mobility of both parties. What about SHIM6?
|  >
|  > I would talk about GTP (a network-based mobility protocol) as well.
|  >
|  > What about mentioning application layer mobility designs (e.g., start
from
|  the paper by Henning on SIP mobility)?
|  >
|  > It might be useful to have at least some pointers to various
optimization
|  efforts that the community has spent quite a lot of time on. It felt that
FMIP
|  was the only one that was mentioned in addition to the general idea of
|  route optimization in Mobile IP.  Look for pointers from the MIPSHOP WG's
|  page, RFC 4651, etc.
|  
|  OK, I mostly agree with you.
|  
|  Do we need SHIM6 here? Although SHIM6 solve ID and locator things for
|  multihoming purpose, it has potential to solve mobility issue, too.
|  I remembered there were some mobility discussion, but I'm not sure there
|  is mobility related extension to SHIM6.
|  

Regarding to Shim6, it allows a node which has changed its location to
inform the corresponding node about its new address(es). For this, the
moving node must have a CGA configured, and the identifier used for
initiating the Shim6 context (the ULID of the node) must be this CGA. Since
there is no Rendezvous server defined for the Shim6 suite, 'simultaneous'
movement of the communicating parties is not supported. As RFC 5533 states,
Shim6 does not attempt to solve the problems of host mobility, although it
may be useful in some specific scenarios.

Besides, there are some guidelines (draft-ietf-shim6-applicability-08) on
how to combine Shim6 and MIPv6 to allow mobile nodes benefiting from
multihoming when the Multihomed Home Network is multihomed and the MN has
multiple HoAs, so that Shim6 can be used between MN and CN; and when Shim6
can be used between MN and HA. A previous draft (draft-bagnulo-shim6-mip-00)
went in more detail on this topic.
Apart from this, there are no mobility extensions to Shim6.

Regards,
Alberto

---

From: Zhenkai Zhu <[email-masked]>
Date: Mon, 14 Feb 2011 00:29:51 -0800

Hello Jari

Thanks for the review. Please find my comments inline. 

>> "published in DNS" and "only accessible to the subscriber" do not appear to be compatible statements. Can you expand on this a bit?

BTMM uses long-lived query to allow DNS server to push changes to the answers to the queries. TSIG is used for authentication when establishing the long-lived query.
We'll make it clear.

> Right. We will update this part.

I agree.

> I remembered there were some mobility discussion, but I'm not sure there is mobility related extension to SHIM6.

So, in sum,
We plan to briefly discuss the following in the draft:
	1. GTP
	2. transport protocols that can handle multiple IP addresses (SCTP, multipath TCP)
	3. applications that can handle change of IP addresses  (SIP)	
	4. pointers to various optimizations for Mobile IP.

We'll update the draft shortly and send it out for comments.

Regards,
Zhenkai