Subject: RE: multi-interfaced vs multi-addressed [Re: [Mip6] Draft Agenda for WG meeting at IETF58]

From: Soliman Hesham <[email-masked]>
Date: Tue, 4 Nov 2003 00:41:26 -0500

> > > Furthermore, I dispute your claim that case 1 has no benefit.
 > > > Clearly, it does when the addresses have separate DNS names.
 > >
 > >=> I didn't think that we'd want CoAs to be put in the 
 > >DNS. Case 1 was discussing having two different CoAs. 
 > >I was always assuming that the MN will have on HoA. 
 > >
 > Ohhh... I was thinking about multiple home addresses here.  
 > But, even so,
 > it is possible once again to make use of multiple care of 
 > addresses with
 > return routability.
 > 
 > Is it a restriction in the "applicability statement" for 
 > this thread that
 > a mobile node can only have a single home address?

=> Not at all. We are trying to look at the problem where
a mobile node is communicating with one CN using 
more than one interface for its connections. I.e.
It has more than one connection and it wants to split
them across multiple interfaces. This will not work
today becuase it would require the CN to maintain
multiple BCEs for the same home address (in the case 
where one hoa is being used). 

If the MN has multiple home addresses there is still
no guarantee that the CN will choose the right MN home 
address (corresponding to the right interface for 
that particular connection)when it initiates communication
with the MN. If the MN initiates communication then
it is possible for it to choose the right home address.

There is another case to consider: The MN does not 
use RO and wants the HA to split its traffic to 
different CoAs. This requires the home agent to maintain
more than one CoA for the same HoA (because you 
can't gurantee that 1) the MN will have more than one
and 2) if it did the right HoA will always be chosen by 
the CN). This feature is not supported today in MIPv6. 

Hesham

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

---

From: Soliman Hesham <[email-masked]>
Date: Tue, 4 Nov 2003 07:34:17 -0500

> > I'm not sure if having multiple tunnels requires a liveness
 > > determination mechanism. I.e. if it's not done for a single 
 > > tunnel today (apart from the lifetime field in the binding 
 > > which can be used for other bindings), why is it needed
 > > when more tunnels are introduced?
 > 
 > Because one reason for multiple tunnels is higher availability.
 > For instance, so that when your tunnel over the WLAN stops working
 > due to being out of reach, the traffic will switch over to the tunnel
 > over the GPRS.
 > 

=> Good point. I never thought of it as a way 
of increasing availability. We should consider this case.

 > > => Not really. I think it's a general problem for multihomed
 > > host. But for non-mobile nodes I think this can be done without
 > > introducing new bits on the wire. For instance, 
 > multi-addressed/multihomed
 > > nodes are free to select their source address on a per-connection
 > > basis. The same goes for mobile nodes that either have more
 > > than one home address, or want to split traffic going to 
 > > different CNs. I.e. use a different binding with different 
 > > CNs, for the same HoA. I think things get more difficult
 > > when different bindings are needed for the same end point
 > > (be it HA or CN). 
 > 
 > For outgoing traffic the host can select the source address.
 > But that isn't true for inbound traffic to lillen.france.sun.com;
 > all the initiator has is one or more IP addresses returned 
 > by the DNS.

=> Agreed.

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Wed, 5 Nov 2003 05:16:03 -0500

> > Yes, I agree. The other thing I have a hard time 
 > understanding is exactly
 > > what information can be discovered at the IP layer to 
 > allow the home agent
 > > or corresponding node to intelligently utilize multiple 
 > addresses tied to
 > > one home address.
 > 
 > One could run a periodic "hello" protocol to detect liveness of
 > each tunnel and use that as an indication to switch from a 
 > failed tunnel/CoA
 > to a working one. Doing this periodically is a waste of 
 > resources, thus
 > if one is going to perform such liveness tests doing it only 
 > when data
 > is being sent and not as a constant background load would make sense.
 > 
 > This could be combined with other information like ICMP errors.
 > 
 > But I suspect that there isn't a shared understanding of what
 > multiple tunnels/CoAs for a single home address will bring 
 > to the table.
 > One is better availability of the connection by doing failover.
 > Another is combining it with some policy of what flows use 
 > which tunnel
 > to provide a knob to control performance vs. cost.
 > And perhaps there are other motivations.

=> Personally, my motivation for doing this is to provide
the right design for a higher granularity of mobility. 
Several things can be gained from this, the ones I originally
thought of were:

- Allowing for certain policies to exist, which can provide
a better value for cost/link type to the MN. The cost issue
is mainly financial. The link type issue is all about putting
the right flow(s) on the best possible media. 

- As a handover optimisation: It is clear to me that there are
different types of handover smoothing techniques which are 
suited to certain types of connections. It's the old packet
loss Vs delays argument. Ditinguishing certain flows during 
a handover can be useful. 

Erik also mentioned the availability case which I never 
actually thought about (maybe because it's the most obvious!). 

But generally speaking, this is a feature that can augment
the base mobility framework and when it's added I have a feeling
that people will find more uses for it than what we're
talking about. 

Hesham