Subject: [nemo] multiple prefixes, multihoming and spliting

From: "Soliman Hesham" <[email-masked]>
Date: Sun, 28 Mar 2004 10:51:12 -0500

> > => As I stated before, I think it's cleaner to have
 > > different MNPs for MRs.
 > 
 > First of all, let's first define what is the goal of having 
 > multiple MR, or
 > put in another way, which is the goal of being multihomed.
 > 
 > Because of the nature of multihoming in NEMO, i think that 
 > the support for
 > multiple technologies is a very important goal, so i guess that a
 > multihoming solution should support this. This means that we 
 > have two MR
 > with different access technologies, so packets have to be 
 > forwarded through
 > the router that has a link available.
 > I guess that is expected that links will become available 
 > and unavailable
 > quite often when the network is moving, so it is important 
 > that established
 > connections are preserved when switching technologies (and MRs)
 > 
 > So i think that important requirements for multihoming in 
 > nemo are what some
 > can call transparent support for ubiquity.

=> Agreed.

 > 
 > Now, this is different from the fault tolerance requirement 
 > (despite what i
 > have claimed before :-), since this is very localized 
 > problem, the links
 > that can "fail" are the links between the MR and the access 
 > routers. 

=> Exactly, this is one point I wanted to clarify in
an earlier response to you.

   This
 > would allow a solution that consists in mechanisms based in 
 > the HA, or even
 > in the Home network perhaps in the visited network, but not much more

=> We can also include the MR(s) as a possibility.

 > 
 > An possibility as you mention would be to use multiple 
 > prefixes, one per MR.
 > 
 > The problem here is that one prefix is associated with a MR, 
 > so with an
 > access technology. So when this access technology is 
 > unavailable, this
 > prefix would become unavailable.

=> Right.

 > For example, suppose you have MR1 with Pref1 and MR2 with Pref2
 > There is also a LFN, that in order to be reachable through both
 > technologies, it has to configure two addresses, Pref1:LFN 
 > and Pref2:LFN
 > Suppose now that LFN has established a communication with a 
 > host in the
 > internet, Host1, using Pref1:LFN.
 > suddenly, the network moves and the technology that is using 
 > MR1 is no
 > longer available. How do you preserve the established session?
 > 
 > To do that you can:
 > Modify the external host Host1 to support multiple addresses 
 > per connection.
 > This may be part of a general multihoming solution, but this 
 > will take time
 > to be deployed

=> Well you can use existing solutions to do that: MIP.
But I need to look into it a bit deeper to see how the 
home address config will work.

 > Make some tunnels between the MR so that they forward 
 > packets belonging to
 > the other prefix, which actually you end up with both 
 > routers forwarding the
 > same prefix, which i am not sure this is so clean.

=> That wouldn't solve this problem anyway since one 
of the MRs is not connected to the Internet. What you
need to do is make sure that MR2's HA will accept MR1's
traffic. This can easily work when both HAs are in the 
same ISP's domain. 

 > 
 > There are also other problems with this multiprefixed setup, like for
 > instance how do you select the source address that is 
 > working properly for
 > initiating a communication. Probably you will need a 
 > mechanism in the LFN to
 > retry with different source addresses. This may also be part 
 > of a general
 > multihoming solution, but again may take longer to deploy.

=> It's a part of any multiaddressing solution. Let 
me comment on a couple of points here:

- If MRs are connected to different access technologies 
then we need information to be sent from those MRs to
MNNs to inform them about the implications of selecting
certain addresses. This is essentially the same problem
for multihomed hosts (note by multihomed I mean a host
with more than one interface), except that in the 
multihomed host case this information is internal. 

- Fault detection, router failure ...etc can be achieved
with ND. How timely this is depends on tuning ND information. 

- The fact that adding this stuff will take time is 
in no way discrediting the approach. Note that adding 
this information does not mean we need to wait for 
a full multihoming solution with, for example, location/identifier
split. This is not relevant for the link-local  problems
that we're addressing here. 

 > 
 > So my comment essentially is: the support for ubiquity seems 
 > an important
 > goal and that IMHO can be solved by adding some mechanisms 
 > to specific
 > devices, like the HA, and MR only.

=> This may well be the end result, but setting 
that as a goal is premature IMO. Especially when we
don't understand all the problems in this space.

 > If you adopt a multiprefix solution, a clean support will 
 > require support
 > from the external hosts. Other solutions like the tunnel 
 > based solutions,
 > are not so clean i am not so sure that are cleaner than the 
 > single prefixed
 > ones. 

=> I didn't understand the "other" solution, why is tunnelling
needed? and why is it not clean?

   Additionally, a multiprefix solution will require 
 > support from LFN.
 > 
 > So, my bet would be to try to explore a single prefixed solution that
 > provides transparent support for ubiquity and see how we can 
 > address the
 > case when it splits.

=> I'm going to consider both approaches and see 
what ends up being more scalable in the long term.
At the moment I can't see the single prefix case
as being realistic for a general multihoming solution.
Since the easy case (of MRs being fixed in relation
to each other) is solveable by either approach, 
I don't see why we should end up with a single prefix
solution for the "short" term and another solution
for the long term. 

Hesham

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by other is 
strictly prohibited.  If you are not the inteded recipient please contact
the sender and delete all copies.
========================================================

---

From: "Soliman Hesham" <[email-masked]>
Date: Sun, 28 Mar 2004 21:36:09 -0500

> Been there before, and i haven't been able to make it work 
 > if you use RR
 > check.
 > A detailed analysis of how i would build a multihoming 
 > support solution
 > using MIP can be found at: draft-bagnulo-multi6-mnm-00.txt
 > Basically the conclusion is that a connection can survive 
 > only 7 minutes
 > after the HoA is unreachable because BCE lifetime expiring. 
 > After 7 min,
 > the connection is down.

=> That's why I said I need to look into it to see
how the _HoA_ config will work. I think you've 
considered the case of having multiple HoAs to provide
multihoming support for the home site. I'm talking about
switching CoAs. This is a different approach. I'm _not_
concerned with multihoming for the _home_site_.  

Like I said, I'll put it all in a draft. It's hard
to explain it all on email.

 > Well, this is one step more that i was considering. I was 
 > mainly focusing in
 > fault tolerance, you are also including policing. 

=> This is not policing, it's a matter of providing
the right information for hosts to do policy-based
src address selection. 

   Policing 
 > can be done by
 > the hosts or by the routing system. If you do host based 
 > policing, the path
 > selection is performed by the host and there is harder to 
 > enforce it by the
 > routing system. This would be more like the multiprefix approach.
 > The single prefix approach, allows the routers to define and enforce
 > policing.
 > Both approaches have drawbacks and benefits, but i guess 
 > that allowing the
 > network administrator to enforce policy is an important benefit.

=> I's impossible to do what I'm trying to do by the 
administrator. It has to be done by the end host.

 > > in no way discrediting the approach.
 > 
 > Agreed, but adding stuff usually increases the complexity of 
 > the solution

=> Sure, I still think it's inevitable though.
This might change after a deep analysis.

 > > Note that adding
 > Agree, but it depends on which stuff are waiting for. Some 
 > of the stuff may
 > require a full multihoming solution.

=> Not the default router - host interface, this is needed
in all cases independently of the rehoming protocol.

 > > needed?
 > I have in mind something like RFC 3178, RFC2260
 > 
 > > and why is it not clean?
 > 
 > You were the one who introduced the clean word :-)
 > 
 > No, it is just that when you start adding tunnels to a 
 > solution it starts
 > getting messier IMHO, You end up with MTU problems, 
 > fragmenting overhead
 > manual config and so on.
 > 
 > So, i am just saying that while is seems a clean approach to 
 > assign a prefix
 > to each MR, then when you start trying to provide fault 
 > tolerance support,
 > you need other stuff that may turn the solution a bit more 
 > messier, so we
 > have to look at the complete picture to compare.

=> Ok, if we want to look at the complete picture
we should also consider the cases where the 2 MRs are
not fixed in relation to each other.

 > Fine. I am willing to provide my opinion if you find it usefull

=> Please continue to do that.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Tue, 30 Mar 2004 10:44:10 -0500

> So, the idea would be:
 > 
 > Recycling an old figure...
 > 
 > 
 >               P::/26
 >        ----|-------------- Home network
 >            |
 >          +---+
 >          |HA |
 >          +---+
 >    route  |  \ route to
 >    P:P1:: |   \ P:P2::
 >           |    \
 >        +---+   +---+
 >        |MR1|   |MR2|
 >        +---+   +---+
 >    P:P1::|        |P:P2::
 >    ---------------------- Mobile network
 > 
 > 
 > (it doesn't matter if there is only one or more HAs)
 > 
 > So, the nemo has as many prefixes as MR and each MR 
 > registers its own prefix
 > to the HA
 > Only one MR can register one prefix (i.e. not two different 
 > MR can register
 > simultaneously the same prefix)

=> Actually I was thinking of having both MRs register
simultaneously. I think what you're saying is geared
towards redundancy. While this is valid, I think
that we still need to consider the case where both MRs
are registered. But anyway, this is fine as an example.

 > 
 > When both MR are working, LFN can use any of the two 
 > prefixes and this will
 > determine the reverse path of the packets.
 > 
 > Now when MR1 is no longer available (or its link is no 
 > longer available),
 > the idea would be that MR2 registers P:P2:: on the HA so 
 > that packets are no
 > longer forwarded to MR1 but to MR2.
 > 
 > This would provide transparent ubiquity support while not 
 > requiring the
 > simultaneous registration of the same prefix by different HA
 > 
 > This would also allow that when the network splits, each MR 
 > takes its prefix
 > with it.
 > 
 > Is this what you are considering?

=> Not really, but this is possible. I was considering 
the case where both prefixes are registered simultaneously.
In this scenario the LFNs will still work fine as you 
describe. But the advantage of both being registered
is that different types of access may be available
to each MR. Do you see a show stopper when both are
registered? I'm curious why you chose to have only
one prefix registered.

 > well it is also policing. for instance i guess that the 
 > netwrok admin would
 > want to ba able to stop the users from using the GPRS access 
 > when a wi fi
 > access is available or something. I mean, especially in wireless
 > environments, path selection may have economical impact, so 
 > the network
 > admin probably wants to be able to influence in which link 
 > is used, don't
 > you think?

=> There are multiple points to address here: 

- Who is the admin in your example? The MR can be 
administered by the the entity as the LFN/MNN.

- This goes back to my earlier point about whether different 
access link can really be used for complete redundancy. 
In your example, this doesn't work. The ISP doesn't 
(typically) want to run the voice traffic on a public 
access WLAN because there are no guarantees for quality. 
The choice of access must be done by the end host. 
It's quite natural that the end host will choose the 
link with better performance. 

- There may be cases where the ISP provides Wifi
access to alleviate the load on the cellular network.
But I don't really think that the use of the Wifi
access should/need be enforced. Incentives like 
cost/BW are much more likely to attract users anyway.
So the question is how we to provide the information
to end hosts to make the decision.

- At the end of the day, the ISP has no way
of being sure about the characteristics/requirements
of the application being used by the end host in all cases. 
So forcing things is not really a scalable or a 
generic way to solve the problem. 

 > well, let's first discuss whether this is a requirement and 
 > then we can
 > discuss if we can do it or it is impossible

=> My requirement is that hosts should be able to
discover and choose the type of access. See the last 
point above about why the end host must choose. 
I appreciate the fact that ISPs want to influence this
decision, but I don't think this should/could be done
at run time in a generic manner. IMO this is best 
done out of band (e.g. subscription). 

Hesham

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 31 Mar 2004 11:28:52 -0500

> I was considering that each router has only one access technology. So
 > selecting the router is equivalent to select the technology. 
 > I guess you are
 > considering a more general case, where MR has multiple technologies.

=> No. I want to allow the MNNs to use the available 
technologies effieciently. That's why simultaneous registrations
make sense. In other words, if each MR is connected to 
a different technology then nodes should be able to use
either access simultaneously. 

 > 
 > Let me see if i understand the motivations for having 
 > multiple prefixes:
 > You can bind one prefix with one technology, with one link 
 > or with one MR. I
 > am not really sure which is better. I guess that if you bind 
 > one prefix with
 > one technology, you have a simple mechanisms to let the host 
 > to select the
 > technology that fits the needs of its traffic and all of this per
 > application (or even per packet) since it the selection is 
 > contained in the
 > source address used.

=> Not per packet. Per application is ok.
But I'm not binding a prefix to an access technology.
The prefix belongs to the MR, whichever access type
it has is what it uses. 

 > You can bind a prefix to a link, so that even if you have 
 > multiple links of
 > the same technology, you can provide some support for fault 
 > tolerance by
 > selecting the link available through the selection of the 
 > source prefix.

=> See above. I'm not binding anything to access technology.

 > You can bind a prefix to a MR, so that if the nemo splits, 
 > each MR takes it
 > prefix with it.

=> That's it!

 > 
 > Now, depending on which of these goals you are designing 
 > for, it makes more
 > or less sense to register the same prefix by different MRs, i guess.

=> It's the last one above.

 > I usually consider that there is a network admin, that configures and
 > manages MRs and links, and then there are users, who can 
 > configure its LFN
 > at will. 

=> We're very far apart here. I don't make assumptions
like these. The MR could be your mobile phone, laptop, PDA ...etc.
There is no point in assuming that these devices are
not administered by the end user.

   So, if the network admin wishes a specific usage of 
 > the network
 > recourses like links, it may not be able to trust the LFN to 
 > do what is
 > specified. For instance, a policy like "use the expensive 
 > link only to carry
 > real time traffic and not for ftp" may makes sense for the 
 > network admin but
 > the user may think otherwise. 

=> Hmmm. I wonder why the user would think otherwise.

  So, it is probably good to 
 > allow the network
 > admin to enforce some of its policies.

=> Again, the network admin is the user in many cases.

 > Ok, i see your point.
 > I usually define fault tolerance as sending the packets through the
 > available path as long one exists.
 > Your definition seems to be more demanding, like use the 
 > link available that
 > matches the QoS required.

=> I'm not defining fault tolerance though. I'm
trying to point out that different access technologies
can be used efficiently by different applications.
I'm not limiting multihoming to redundancy.

 > Yes but this may be conflicting with network admin preferences.
 > I guess we have a tradeoff here, between empowering the 
 > users vs. empowering
 > the network admin.
 > I also think that different scenarios will require different 
 > parts to be
 > empowered.

=> Sure, the question is how? It's not clear that 
protocol work is needed here. I think that out of band
mechanisms are sufficient to setup the necessary static
information like cost. The rest is up to the user.
If a user decides to ignore a WLAN and ftp a 10M file 
on a cellular link and pay for it, then that's fine.

 > I guess that there will be a need for different approaches.
 > the other option would be to try to find a solution that 
 > provides tools to
 > both of them to perform path selection, and we should decide 
 > who overrules
 > who.

=> The user overrules.

 > Well, if you bind a prefix with a technology, the selection 
 > of the source
 > address performed by the host may inform the routing system 
 > which technology
 > it is willing to use to carry the packet.
 > Then what you need is a mechanism to influence the source 
 > address selection
 > policy
 > RFC 3484 policy table may be a starting point.
 > You probably need to extend it, in order to have more 
 > granularity, perhaps
 > the port numbers.
 > You will also need a mechanisms to automatically configure 
 > this policy
 > table, like a dhcp option ( i prefer it to Radv based mechanism)

=> Yes, something along those lines. RFC 3484 is very simplistic
though for these types of scenarios. But I'm not too
concerned about this part because every implementation
can select the src address in its own way. I'm more
concerned (in IETF) about the way of communicating 
the information about the link behind the MR.

 > In a world where users behave according to the common good, 
 > this is fine.
 > In a world with greedy users, this may not work so well, i am afraid.

=> The user will always behave for his own good. Trying to
overrule that will not work in a deregulated world. 
Basically what I'm trying to say is that you need not
be afraid because ISPs want the user to use the cheap
link for cheap apps and the expensive link for QoS. 
And why wouldn't the user want that if it's cheaper
for her? I don't see a problem. Are you worried that 
a user might want to use an expensive access despite 
the presence of a cheap one for the same app?? Doesn't 
make sense. Or the reverse: use a cheap access that doesn't
support QoS for an app that requires QoS? Well if it works
poorly and they're happy with that, it's ok!

 > I am not talking about the ISP here but about the 
 > administrator of the nemo.

=> The nemo may well be administered by the user
of the MNNs. If not, then it's an ISP, what else 
could it be?

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 31 Mar 2004 11:28:52 -0500

=> That's it!

=> The user overrules.

Hesham