Subject: [netext] NETEXT2 BOF conclusion

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Oct 2009 00:29:00 +0300

I have been trying to come up with a way forward on this, but its hard.
To recap, there are a few different technical possibilities for
multi-interface mobility:

1) Link layer hides interface variants behind one logical interface. For
instance, an IP stack does not see the change from GSM to UMTS radio or
802.11b to 802.11g; its handled as a part of the link layer. Such link
layer operations need to be supported both by the host and the network.
This approach has the minimum impacts on IP stack, but requires
specification of the link layer mechanisms across the used interfaces.

2) Different interfaces are handled via existing host-based mobility
mechanisms (Mobile IPv6, MOBIKE, HIP, application layer). Within one
interface the link layer handles mobility, possibly using Proxy MIP
internally. Both the host and the network need to support the host-based
mobility mechanism, but the link layer does not have to aware of the
other interfaces in any way.

3) We extend Proxy MIP with capabilities to handle cross-interface
handovers. This is similar to approach #1, but the signaling messages
are at the IP layer. The benefit is that this could be used across
different types of link layers even if they do not support handovers.
The downside is that just as with approach #2, the IP stack has to be
capable of these operations.

The big argument we have been stuck with since San Francisco is between
#2 and #3. One group believes that existing mechanisms are sufficient,
and they are -- it is indeed possible to do this. Another group believes
that they need a different solution based on Proxy MIP. Such a solution
is also of course possible. But we've made very little headway in
resolving the question on what should be done. In particular, we've not
been able to describe very well why some technical reasons would dictate
one or the other solution. I believe that is likely because they are
really very similar solutions.

At this point I do not believe we have consensus to go forward. We left
the BOF with the idea that requirements work would solve this issue. If
I'm right the solutions really are very similar, this work may not be
able to resolve the conflict, and it would take a long time. I think it
would actually serve as better if we were to decide now, as opposed to
pretending that more details will make the decision easier.

With this in mind, I have a proposal for a way forward. Given that I do
not see consensus for approach #3, I do not think we can go ahead with
that. I also personally believe that #2 and #3 are functionally similar
enough that there's no requirement that forces us to pick #3. In
addition, approach makes mobility end-to-end between the host and a
network node; approach #3 ties the use of mobility to a particular link.
If the router on that link does not support the mobility mechanism,
mobility service is not possible. I think it would be architecturally
better to separate access and mobility.

However, I would like to move forward with a different work item. The
IETF has never really explored approach #1, even if it is commonly used.
Of course, the IETF's role is not to design these link layer mechanisms,
but I believe it would be valuable for the IETF to publish an
informational document on considerations for building such mechanisms.
This document would talk about the requirements that the mechanisms must
fulfill in order for IP to work correctly, when such mechanisms are
recommended and when not, what their advantages and downsides are, what
happens if MTUs or routers differ, and so on. At the same time this
document would describe the "virtual link" model that some people have
been using in the context of Proxy MIP. The idea is to add this work
to the NETEXT WG charter.

I realize this does not make everyone happy, but I'm not sure there
is an outcome that does. What we lose by not doing solution 3 is
a design that that simultaneously allows something to be done
in a link-layer agnostic manner _and_ employs PMIP as a part of the
solution.

Thoughts?

Jari

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 21 Oct 2009 16:34:05 -0700 (PDT)

Hi Jari,
  I could not understand approach #2 well.

However, I think that PMIPv6 has some other problems when it comes to a MIPv6-like flow mobility solution. This is addressed in some drafts like Conny's. How are we going to address those issues that relate to the basic design of the protocol?

Regards,

Behcet

----- Original Message ----
> From: Jari Arkko <[email-masked]>
> To: [email-masked]
> Sent: Wed, October 21, 2009 4:29:00 PM
> Subject: [netext] NETEXT2 BOF conclusion
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Fri, 23 Oct 2009 08:53:26 +0800

Hello Jari,

Thanks for the mail.

The informational document based on approach 1, is it going to analyze
or identify requirements needed to perform inter RAT handoff and
multihoming(flow mobility) etc for PMIP?  Is that the goal of the
document?

BR,
Mohana

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Jari Arkko
> Sent: Thursday, October 22, 2009 5:29 AM
> To: [email-masked]

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 23 Oct 2009 16:49:18 -0400

Hi Jari,
 
thanks for following up on this.
 
If I understand correctly, the proposal is to develop recommendations for link layers to support inter-access handovers and flow mobility.
 
I am not sure why link layer is the best way to handle this when we are in fact traversing disparate link layers. 
I would have thought extensions to Router Solicitations and Router Advertisements would be appropriate. Granted this is an extension to the host stack, but that should be made clear in an Applicability Statement.
 
Anyway, this is missing an important piece: the LMA - MAG protocol interaction, assuming underlying support for what is necessary between MN and MAG. Without LMA - MAG protocol, we cannot do inter-tech handovers and flow mobility. We would need this regardless of how we solve the MN - MAG part.This should be included in the charter. 
 
Regards,
 
-Rajeev

________________________________

From: [email-masked] on behalf of Jari Arkko
Sent: Wed 10/21/2009 2:29 PM
To: [email-masked]
Subject: [netext] NETEXT2 BOF conclusion

Thoughts?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Oct 2009 12:26:00 +0200

> multihoming(flow mobility) etc for PMIP?  Is that the goal of the

Maybe. My idea of the scope was to provide guidance for creating link 
layers that hide movements. What the requirements are so that IP layer 
is not affected, what are the difficult points, etc. I think PMIP 
virtual interfaces are one example of these link layer mechanisms. But I 
am not suggesting a L3 solution for PMIP multihoming to be within the scope.

Jari

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 29 Oct 2009 08:35:55 +0800

Hi Jari,

Thanks for your reply.

I understand your intention is to explore whether inter RAT handoff and
multhoming in PMIP can be done in L2 and identify the requirements.
Also explore whether we can do it without any changes to L3.  Consider
virtual interfaces or any other minor host fixes to achieve the goal.  

Also as many other folks feel, I too think that aproach 3 is also a
neater way of doing this and use the MN-MAG interface to indicate MN
state to the MAG.  This is different from appraoch 2 because the MN is
not doing mobility signaling as in approach 2.  It is just indicating
some state/prefernce information for inter RAT handoff and flow
mobility.

Thanks.

BR,
Mohana  

Behalf
> Of Jari Arkko
> Sent: Wednesday, October 28, 2009 6:26 PM
> To: Mohana Jeyatharan
> Cc: [email-masked]
> Subject: Re: [netext] NETEXT2 BOF conclusion
> 
> Mohana Jeyatharan wrote:
> > Hello Jari,
> >
> > Thanks for the mail.
> >