Subject: [Mip6] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF

From: Soliman Hesham <[email-masked]>
Date: Mon, 17 Nov 2003 05:20:33 -0500

Hi, 

Just wanted to drop a note on adding flow movement
capabilities to MIP. 

I completely agree that adding new functions to
MIP just because "it's there" does not make any sense, 
and that where a problem applies to both fixed and mobile
hosts we should avoid fixing it in a mobility protocol. 
However, when it comes to flow movement, it is not immediately
obvious to me that it is outside the scope of MIP. 
I'll try to break the problem down in an attempt to realise
where each component belongs. 

The basic problem is that a node needs to decide what 
src address should be used by a particular connection.
Forgetting about MIP for a minute, this is obvious when
a host is trying to initiate communication with another host.
Src address selection can be augmented with various policies
(user-based or otherwise) to allow the host to pick the 
right src address. However, this is a bit more complex when
a host is not the initiator of communication. This leads
to sub-problem (1)
  (1) Informing the initiator of communication of the right
      dst address for the host on the other end.

This information can be communicated implicitly or explicitly. 
One possible example for implicitly informing the other end
is through using different domain names (e.g. audio.example.com
returns a different address from video.example.com). On the 
other hand, explicit notification of the address can be done
by using a protocol to negotiate a connection setup (e.g. SIP
does this today). 

Not withstanding the example solutions above, sub-problem
(1) is independent of any mobility and applies to any 
multi-addressed host. 

Once a connection is established, the right addresses are 
chosen by both ends, end of story. 

Now, the other aspect of the problem is this: Once a connection
is established, using a particular src and destination address
pair, how can either host modify this information? In other
words, if WLAN coverage suddenly appeared to my laptop, how
do I inform the host on the other end to move one of our 
connections to WLAN, while leaving the other on the cellular 
interface? In a few words, I want to change the dst address for
a particular connection without breaking that connection.
This requires a protocol to signal that to the other end. 
To me, this problem seems to fall into the IP mobility category
of problems, although it is addressing a finer granularity
of mobility. 
Note that SIP also has signalling support for session transfer, 
but: A) it was not intended for this purpose and B) it is 
not widely implemented and C) it is slower than an "optimised" MIP
(BTW neither A nor B discredits using SIP for this purpose). 

So sub-problem (2):
  (2) How to move a flow from one address to another. 

MIP efficiently solves this problem for a host, but it 
does not provide further granularity (i.e. connection
or flow). 

Personally, I think sub-problem (2) is a mobility
problem, by the definition of IP mobility. I believe
that MIP solves two problems: maintaining current connections
while moving, and reachability. 
"Moving" in the context of IP mobility effectively means 
changing IP address, independently of whether that change
affects all flows or only one or two. 

My 2 cents! 

Hesham

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 17 Nov 2003 13:58:44 +0100

Hi Hesham,

    That's a pretty good summary.  My own thinking on this, after a bit
of discussion in Minneapolis, is that the MIP solution which is the
least MIP-specific would be to have separate individual MIP sessions for
each flow (or group of flows) we wanted to move independently of other
flows. This takes care of the ability to treat flows individually, and
it does so by providing separate Home IP-addresses for those flows to
pass through.

I also note that the flow groups, and their IP-addresses, needs to be
established before individual user applications start up and bind to the
individual HoAs - we have no way to signal most application to re-bind
to a new IP-address.

The cost of this solution is in having to do re-registration of multiple
sessions when you move, but such a cost is already implicit in the fact
that with multiple connections through different connection media you
have to be able to handle each media individually, whether it is by
separate sessions or by filter adaptations.  But I believe completely
separate sessions will adapt better to any other non-movement-specific
solution to multihoming that may appear.

	Henrik

Monday 17 November 2003, Hesham wrote:
> -- 
> Mip4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mip4

---

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Nov 2003 14:49:30 -0800

Hi Hesham,

This is a little bit different perspective than the one I've been coming at
this from. If I understand you correctly, you seem to be assuming that the
correspondent node has knowledge of the additional care of addresses
available to the mobile node, correct? Unless the flow is opened directly
with the care of address (i.e. the correspondent or mobile node does not go
through the home address to start the flow which is somewhat outside the
basic Mobile IP scenario) then the only way I can see the correspondent
learning about the additional addresses is through MIPv6 route optimization,
i.e. the mobile node tells the correspondent to move a particular flow to a
different care of address using a binding update that is somehow enhanced to
indicate which flow should be handed off (perhaps a use for the new flow
label work in the IPv6 WG?) instead of handing off all flows. This is
certainly much cleaner than treating the home agent as a middlebox and
trying to accomplish the flow handoff there.

However, for MIPv4, this won't work because there is no route optimization.
Flow handoff will have to occur at the home agent. And, any indication of
which flow to handoff will probably require looking into the transport
header to determine the port number, the kind of thing typically done by
firewalls and NATs in IPv4. This is decidedly less appealing, because it
involves middlebox functionality on the home agent. If that's the case, then
the issue is what should the signaling look like between the mobile node and
home-agent-as-middlebox to accomplish the flow handoff?

            jak

----- Original Message ----- 
From: "Soliman Hesham" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, November 17, 2003 2:20 AM
Subject: [Mip6] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple
Lin k Flows BAR BOF

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 18 Nov 2003 13:59:32 +0100

Hi,

>it does so by providing separate Home IP-addresses for those flows to
I personnally don't agree with that point. First point, it is not sure 
that a MN can benefit of having as many HoAs as he wants. But, 
considering the solution of using multiple HoAs, at the initialization 
of the flow,  you should choose the right HoA. If it is the MN which 
initiates the flow, it is easier, but it may be difficult if it already 
has many flows: on which criteria the MN will group several flows to be 
mapped to a HoA, or which criteria tells to MN to use a new HoA for the 
new flow ? If it is the CN which initiates the communication, it is even 
more difficult, how can he choose (or even discover ??) the HoA of the MN ?

Secondly, if you want to individually manage two flows bound to the same 
HoA with the same CN (probably you choose the wrong HoA or your 
preferences had changed), so as you said you have to re-initiate the 
communication, that means the communication is broken. If we have a way 
to maintain this communication, why don't use it ?

The draft draft-montavont-mip6-mmi-01 (available at 
http://www.ietf.org/internet-drafts/draft-montavont-mip6-mmi-01.txt) 
details the different levels of granularity of the mobility (and 
particulary the limitation of the use of multiple HoAs to manage several 
flows). The document tries to explain the pros and the cons of each 
level of granularity.