Subject: RE: [mobile-ip] MIP v6 Regional Registration - identifying re qui rements

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 10 Apr 2001 02:08:18 +0200

James, 

> >>  A short list of concerns include worries about introducing single
> >> 	points of failure, whether or not multiple levels of hierarchy are 
> needed,
> >> 	the amount of signaling and tunneling overhead that is implied, the
> >> 
> >> 	=> We believe we got some confirmation for ROHC and CT
> >> 	folks that tunnelling will not be an issue. 
> >> 
> 
> Well, I'm glad you think that, because I've seen nothing in the
> email thread that gives me any confidence at all that this will
> be possible. I've seen Rajeev's note that changing the IP
> address on the header might work, but not that changing 40 bytes
> of header option will. And the ROHC chairs have not come out
> one way or the other on this.
> 
	=> We have heard at least 4 times now that ROHC will 
	handle IP in IP tunnels. IPv6 in IPv4 will also be handled. 
	We don't need to discuss this since you can verify it 
	by reading the spec. 

	As for sending full headers after handovers, we've seen 
	the discussions, one camp says that simultions have 
	proven that losing more than 3 packets in WCDMA (an
	example of an error prone environment) is extremely 
	unlikey. The other camp disagrees and says that the 
	problem exists and can be solved by CT. What more
	do we need to know ?
	I don't think this is relevant to HMIPv6 only so I
	don't see why this keeps coming up in relation
	to HMIPv6.

> >> 	We would like to add two more requirements. 
> >> 
> >> 	0) Localised mobility management should provide the same
> >> 	level of mobility management support as in the basic 
> >> 	MIPv6 specifiation. The mobility management functions 
> >> 	supported in MIPv6 must not be reduced in such mechanism.
> >> 
> >> 	0.5) The provided mechanism must interwork with existing 
> >> 	MIPv6, IPv6 and the proposed mechanisms for SA establishment
> >> 	in MIPv6. 
> 
> Yes, I would agreee.
> 
> Additionally, I would add:
> 
> 	The mechanism should minimize mobile node involvement in routing,
> 	beyond what the current MIPv6 requires. Preferences, load balancing,
> 	and other complex host-based mechanism whereby the mobile node, 
> 	rather than the network, is involved in determining routes should
> 	be avoided, 
> 
	=> I guess you are referring to HMIPv6 here and no the requirements 
	in an abstract sense. The preference value was first introduced in
	the MIPv6 spec for the HA. Why is this any different ? do you have 
	the same reservation on MIPv6 ? If so I disagree. I think the 
	HA's preference field is useful.

	Regarding load balancing, this is something that we believe is 
	important and needed. However, based on comments received
	we will put it in a different drat. This is not a new thing, it already
	exists in routers today. Furthermore, in some cellular networks
	(3GPP) a very similar feature is implemented in the GGSN. 
	This is _already_being_developed in products (GGSNs). 

> >> 	6) Regional registration shall allow multiple levels of hierarchy
> >> 
> >> 	=> We can't see a reason for this requirement. We think it's 
> >> 	 OK if we want to support mobile networks but we don't 
> >> 	think this requirement should be placed for all cases. 
> >> 	We never got an answer for the technical merits of 
> >> 	this requirement. It would be good to know why. Otherwise 
> >> 	we'd like to remove this requirement.
> >> 
> 
> Hesham, I've given reasons for this requirement multiple times, but
> my impression is that you've ignored them. The fact of the matter is you don't 
> believe it's important because HMIP can only do it to a limited extent.
> 
	=> Actually I haven't ignored anything. You haven't mentioned any
	reasons on this list or others. If I missed it, please point me to
	the mail or date and I'l look it up. When we discussed this 
	in private I responded and didn't get a reply. 
	So it would be much easier IMO if you just tell us the 
	reasons.

> >> 
> >> 	8) Regional registration shall not require changes to the mobile node, 
> the
> >> 	home agent, or correspondent nodes
> >> 
> >> 	=> We can understand the HA and CN, but no changes in the MN
> >> 	seems strange. Is this possible ? 
> >> 
> 
> Ideally, this would be great. The less the mobile node has to 
> change, the better.
> 
	=> Ageed, but I don't think it's possible. I stand corrected.

	Hesham

> 		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 12 Apr 2001 12:47:38 -0700 (PDT)

I've been having problems with my email again, don't know if this
made it out on Monday.

>	don't see why this keeps coming up in relation

I'm not bringing it up in the context of HMIPv6 only, I'm bringing it
up in the context of requirements for RegReg. I think there 
needs to be a requirement for minimizing over the air header, in
the absence of a definitive statement that handovers will not be
slowed. MIPv6 has already been bitten by using work from another
working group in a way that generated unintended consequences, we don't want 
that to happen again. Until I see a statement from the ROHC working group
that piling on tunnel overhead won't cause significant (and 3 packets
is significant) latency increase in handover, I think we need a requirement
that the RegReg protocol introduces no header overhead beyond basic
MIPv6.

>	HA's preference field is useful.

Actually, yes. I think the whole HA preference list thing in MIPv6 is
unnecessarily complex. Why should a host care what router it's getting?
The only reason I could see for a host to care is that it is authenticated
for a particular router and not another, and that isn't addressed
by the preferences design, or, it could be addressed in a roundabout and
rather cumbersome way, IMHO.

Routing decisions should be left to routers, not hosts. This has
been a proven, successful design in the wired Internet and I don't
know why it should not be so for wireless as well.

>	This is _already_being_developed in products (GGSNs). 

GPRS is a competing IP mobility standard being pushed by 3GPP. They've 
shown little or no interest in deploying mobile IP. Why should we
do something to accommodate them, or accommodate our design  to their
poor design?

>	So it would be much easier IMO if you just tell us the 

OK, I missed the private email, like I said, I've been having email problems.

Here are a couple reasons:

1) Our design work on an all-IP radio access network showed that if
mobile IP is to be used for managing movement of the macrodiversity
resolution point and radio control server, then the hierarchical
signalling must be arranged to allow multiple levels of hierarchy.
Typically one level of hierarchy will be involved in managing 
macrodiversity resolution/radio control in the RAN while another
will be involved in managing the movement of the mobile's globally
visible IP address. 

2) A large ISP that peers for multiple wireless ISPs and, in addition,
has its own wireless networks may want to aggregate traffic for
particular wireless ISPs through particular RegReg routers. This
is very similar to how current ISPs aggregate through particular
border routers. Routing hierarchies have been important in the
wired Internet, we see no reason why the same might also not
be true with wireless.

		jak

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Tue, 17 Apr 2001 15:02:38 +0200

Hello James

Some comments below.

> up in the context of requirements for RegReg. 

Karim:
OK, but there should be no difference.
I think that the point Hesham was making above is that compressing
a tunnel is something that has a wider scope than local MIP mobility.
HMIP should not be designed specifically to remove tunnelling
since that is part of MIPv6. Any optimisations for wireless can
be done but should be simple IMO, and given the wider scope, should not
be MIP-specific. The use of header compression seems like a good idea.
In fact, independently of whether there is a tunnel or not, the
spectrum efficiency issue is still a problem. Even one IP header is
not good enough, so putting a tunnelling restriction on HMIP wouldn't
solve that problem. On the other hand, as mentioned previously, if
you have HC then you get to compress single or multiple headers.
This allows the HMIP solution to be more generic.

> I think there 
> slowed.

Karim:
The spectrum efficiency problem doesn't disappear if you don't
have tunnelling. One IP header (and UDP/RTP or TCP headers) is
still an issue, which ROHC has targeted. So I believe this is a
generic problem which exists independently of MIP, and should be
solved in ROHC WG not MIP.

Your other issue, CT, has to do with handoffs which HMIP does not
have as a requirement to solve. Also, you imply that moving a header
compression context for a tunnel is hard to do (compared to moving
context for a single header)? If this is true then this applies to
all tunnelling to the MN, independently of MIP. Is the work at a
stage where such conclusions can be drawn? Should there be such
limitation (i.e. do not tunnel)? Until we are sure I think we should
not make the HMIP solution too handover-specific. If it is found that
CT for HC is needed (which some do not believe is the case) then we
should make sure that the CT solution works independently of what
you are transferring. This sounds better to me than posing limitations
on the local mobility solution.

> MIPv6 has already been bitten by using work from another

Karim:
Some comments on HC above.
Regarding your last sentence (requirement) I think I agree
in principle, but we probably don't mean the same thing. The local
mobility agent is basically a local Home Agent. So it will tunnel
packets to the MN as in basic MIPv6.

> >> 	rather than the network, is involved in determining 

Karim:
I think that we agree that the "multiple interface" or load balancing
part should be put in another draft and we will try and get that in
by the next IETF. However, it is important to allow the MN to
use its local policies to move connections over different interfaces
depending on the cost, QoS etc. of the access. So, in general
I don't think we should disallow such mechanisms.

> rather cumbersome way, IMHO.

Karim:
Well, you may want to get more users on one agent than another for
example. Anyway, this discussion is now about MIPv6 and not only HMIP
so it may need a separate thread.

> know why it should not be so for wireless as well.

Karim:
Mobiles may want to decide which interface to receive traffic on.
Cost and QoS are two important reasons to get mobiles involved
in this decision.

> do something to accommodate them, or accommodate our design  to their

Karim:
Hesham's comment related to the fact that it is a "very similar
feature". I believe the intended point was that such a feature
is required and 3GPP has a solution for it. Nothing was said about
having to accommodate any design for another.

> >> my impression is that you've ignored them. The fact of the 
> matter is you 
> don't 

Macrodiversity on IP-level and other such issues are likely to
start a long discussion which we may not want to repeat. I don't know
much about your work so let me have more information if you would
like some comments. However, I can't see in principle why you need two
levels instead of one. I'd like to add that this is only one view of
how an all-IP network should be. The way the 3GPPs see it today,
although you may not personally hold this in high regard, is quite
different. I could add another view, possibly different from your study.
These comments are not meant to be a criticism of your study, but unless
we all agree on the future all-IP architecture it is difficult to use
this as a requirement. The architecture issue is a tough topic.
I currently understand that this is something meant for the 3GPPs to
solve and therefore out of our scope.
 
> wired Internet, we see no reason why the same might also not

I understand the routing hierarchy concept, but I can't see how this
maps to mobility and local mobility agents. The "local" agents (MAP)
must be placed locally and not in the backbone of large ISPs.
A large ISP can still aggregate traffic from multiple smaller
providers without the need to own local agents (except for their
own access networks if any). So I agree with you that aggregation
can be applied to wireless, but no need to de-localise the local
agents.

Regards
/Karim

---

From: James Kempf <[email-masked]>
Date: Tue, 17 Apr 2001 17:50:52 -0700 (PDT)

Hi Karim,

>This allows the HMIP solution to be more generic.

Sure, I've got no argument with using header compression, and I agree
that the issue of whether it will work in the face of handover
is a general problem. The issue I have is designing something 
based on an assumption that it will work a certain way when we
currently don't have a definitive statement that it will work that
way. I just don't want to get blindsided again like happened with security
and binding updates.

Perhaps the requirement should be restated as a requirement that
the ROHC/Semoby context transfer groups be requested to review any design for a 
statement as to whether the design will not cause any latency when
header compression state is transferred during handover, if the
design does in fact include additional header bytes.

>solved in ROHC WG not MIP.

Agreed.

>on the local mobility solution.

Honestly, Karim, I just don't know, and I don't think anybody does.
I just don't feel comfortable making assumptions about technology
that isn't there now, and may or may not be there when we need it.

But we do need to make progress, and so maybe we can establish
a review requirement as suggested above.

>packets to the MN as in basic MIPv6.

The requirement I see is that any additional header state be
eliminated by compression, and that transfer of compressor state
upon handover makes it possible to restart compression so as to not introduce 
any additional latency into handover.

>I don't think we should disallow such mechanisms.

Well, we have a disgreement here.

I think hosts should be kept out of routing decisions as much as possible.
This is based on the successful history of IP design, in
which hosts do very little routing. Mobile IP already involves the
host in much more of the routing decision than has traditionally been
the case, and I see little point in expanding that role unless absolutely
necessary.

The current preferences design is, in any case, too broad. What do
these mean? There could be a potential interoperability problem
if the mobile node moved from one network where the local policy
defined preferences one way into another where they were defined
another way. How would the mobile node know that the interpretation
of preferences had changed? In most routing protocols, attributes
are standardized so that interoperability based on attributes is possible.
So including something as simple as preferences is a slippery slope.

If you want to look at local policies, I believe the Seamoby group
is working on a protocol to discover access point capability.
It sounds to me that you want something more along those lines.
With such a protocol, the meaning of the attributes/preferences
would be standarized, eliminating the interoperability problem.

>Cost and QoS are two important reasons to get mobiles involved

Again, the right way to do that is using something like the Seamoby
protocol, where there is a framework for standarizing the meaning.
Including it in the routing protocol is not the right direction, IMHO.

>solve and therefore out of our scope.

Sure, but this is a requirements discussion and I'm bringing up
a potential area where it might be required.

If we ignore this possibility, we have effectively foreclosed one
potential application area for LMM. And, as we have recently
been reminded by our good friend PhilN, we are not here to
design systems for 3GPP/2. Though I disagree with his assessment
of the situation, the point of requirements generation is to
come up with requirements from the working group members about
what they see as important for the Internet. I think this is important
if we are to leave open an option for having IP radio access
networks that use IETF protocols.

>can be applied to wireless, but no need to de-localise the local

The MAP or some other hierarchical agent is acting as a router. 
Traffic from outside the local managed mobility domain must
come through the agent. The ISP may want to aggregate to direct
traffic from a collection of lower level agents through a
border agent, and recursively. If multiple levels of hierarchy
are not allowed, this option is effectively foreclosed by the
design.

		jak

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 18 Apr 2001 11:26:42 +0200

Hi James

> design does in fact include additional header bytes.

Karim:
I'm also happy that we leave this to ROHC/Seamoby and make changes
if/when we are advised to do so. From the comments so far it looks as if
we can be flexible and use tunnelling.

Regarding Seamoby, I'd like to wait until we know if header compression
CT is needed. If so we could put a requirement to the CT group.
Of course, from the local mobility viewpoint, we are also required to monitor
activities in ROHC/Seamoby and get their feedback (as you wrote above), but
that goes without saying. More on the requirements issue below.

> a review requirement as suggested above.

Karim:
Yes, I'm happy to move on and review the solution once the other
groups give us guidelines. However I don't think this is a requirement
on local mobility, instead we should put requirements on other groups.
If these requirements can't be met we'll know and will make changes.
i.e. Seamoby: If CT for HC is needed, we require tunnel CT.
I propose we include a short discussion in the draft on HC, explaining
what we discussed. What do you think about this?

> any additional latency into handover.

Karim:
I agree with what you have above, except for the latency part.
If a user cannot notice (or is not disrupted by) the reestablishment
of header compression context without CT, then no additional latency
is introduced (i.e. the MN gets service, but the first few packets are
sent uncompressed). I think we got feedback both from people saying
that CT is needed and from people saying CT is not needed for header
compression. So I'd like to modify your requirement to be:
"it should be possible to reduce impact due to additional headers by
compression, and the service perceived by the user should not be
degraded upon L3 handoff (either through reestablishment of context or
through transfer of compressor state upon handover)"

However this requirement is not a requirement on local mobility,
it's a requirement on ROHC/Seamoby CT. So I think it's more appropriate
to pass this requirement onto those groups and monitor the results.

> would be standarized, eliminating the interoperability problem.

Karim:
I didn't mean to exclude the Seamoby AP discovery mechanism. It is
in fact one way of informing the MN of what access is available to it.
The MN may use other methods too, which are not necessarily better.
For example, if it has WLAN, Bluetooth and W-CDMA interfaces it
could know locally (local user preferences) which one it prefers for
which type of connection and act as a consequence. However, the way the
MN finds this out is outside the scope of this draft.

So I think we agree that it could be useful to allow the MN to
move connections over different accesses as it moves.
Regarding the preferences value, that is only needed to choose
between MAPs where multiple MAPs are advertised.
More below.

> Including it in the routing protocol is not the right direction, IMHO.

Karim:
OK, but it was never included. I agree that Seamoby may provide the
right solution for access discovery, and appropriately access
discovery was not included in the local mobility protocol.
The preference value is a different issue, only used to pick a MAP.
What was included (in HMIPv6) was a mechanism to move connections to
different MN interfaces. The method used by the MN to find out the "best"
interface/access for a connection was not included in the spec.

So I think we should allow a multiply-interfaced MN to move connections
between its interfaces, but in a more generic way applicable to HA and/or
local agent (i.e. MAP). That's the separate draft I was talking about.
I think we agree on this, but had a misunderstanding on the preference
issue?

> networks that use IETF protocols.

Karim:
OK, I see your point, but this still needs a discussion so that we
agree on what we want. This requirement makes certain architectural
assumptions about the IP radio network. The problem is that we probably
have different views of what an IP wireless network should be, so any
requirement from one side or another will be a source of misunderstanding.
In my case, for example, I can only see the need for a one-level local MAP
(possibly multiple independent MAPs to share the MN load in a large local
network and for eventual redundancy mechanisms to be developed).

> are not allowed, this option is effectively foreclosed by the

Karim:
Let's say you don't have multiple levels of agents, but have multiple
levels of routers. I can see ways in which you can achieve what you
are saying through normal IP routing, without having to deploy local
agents in the large ISP. What I mean is that you don't need to use
MIPv6 and local agents to make traffic from outside a local domain go
through a particular border router. So, I don't think that placing a
local agent to aggregate traffic in a transit ISP network is the right
solution.

Regards
/Karim

---

From: James Kempf <[email-masked]>
Date: Wed, 18 Apr 2001 14:52:43 -0700 (PDT)

Hi Karim,

>to pass this requirement onto those groups and monitor the results.

OK, so I think we have agreement that the requirements should state
something about ROHC/Seamoby review to make sure that compression
and context transfer can handle a change in header during handover,
if the solution introduces any additional header overhead beyond
standard MIPv6. Phil, please take note?

>move connections over different accesses as it moves.

Yes, but I don't see this as specifically a LMM requirement. This
is actually a more a basic MIPv6 requirement since I could imagine
that it would be useful even in the absence of LMM. And, I am
not clear whether MIPv6 actually  will support it now, would need
to spend some time with the spec to make sure. In any event, I
don't see it as part of the LMM requirement set.

>The preference value is a different issue, only used to pick a MAP.

Why couldn't the Seamoby protocol be used for this? The MAP could
advertise using the Seamoby protocol and the mobile could select
a MAP based on that.

>I think we agree on this, but had a misunderstanding on the preference

Yes, that's right. As Hesham pointed out, basic MIPv6 also has these
preferences, so perhaps I need to formulate a proposal to Dave
and Charlie that it be removed from there as well, since the Seamoby
protocol should take care of it. 

>network and for eventual redundancy mechanisms to be developed).

Right, I understand. I was not proposing a requirement specifically
for a radio access network, but using the radio access network as
an example of what the requirement would allow or deny.

>local agent to aggregate traffic in a transit ISP network is the right

Well, packets from CNs outside the MAP domain are getting sent to the
RCoA at the MAP, where they are encapsulated and sent to the mobile
node. So, like I said, the MAP is operating as a router. Now, if
a wired network operator is acting as an ISP peer for a bunch of
wireless ISPs, the wired operator may want to set up a single MAP
through which all the peered MIP traffic is run, and each sub-ISP will
want to have their own MAP for signalling within their domain. These
sorts of routing hierarchies are commonly used, and if the LMM
solution precludes them, we may end up with problems down the line.

		jak

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Thu, 19 Apr 2001 11:39:35 +0200

Hi James

More comments below.

> standard MIPv6. Phil, please take note?

Karim:
Almost. CT may not be needed for header compression, so the requirement
cannot state that we must make sure that CT works for us.
The only thing I can see is the need for ROHC when low bandwidth
links are used. Should we have a requirement saying this? Don't know if
it is much use though.

> don't see it as part of the LMM requirement set.

Karim:
Agreed. It is something more generic, and we decided to make it
into a separate draft in Minneapolis.

> advertise using the Seamoby protocol and the mobile could select

Karim:
Well, the MAP will advertise, so why not make use of the preference?
I'm sure you could use the Seamoby protocol to convey more info,
but they could coexist. It is possible that not all MNs support
the seamoby AP discovery protocol. I think it is a basic MIPv6
discussion in any case, as you say in your comment below.

> protocol should take care of it. 

Karim:
I'm not sure I agree on its removal, but it is a MIPv6 issue.

> solution precludes them, we may end up with problems down the line.

Karim:
I can see that you could use a MAP for this, but is it not simpler to
use normal routing to direct all traffic to local MAPs (RCOAs) through a
certain router if required? What I mean is that it's not a strong reason
to have multiple levels since it can be done otherwise without the need
for MIP.

Regards
/Karim

---

From: James Kempf <[email-masked]>
Date: Thu, 19 Apr 2001 11:19:08 -0700 (PDT)

Hi Karim,

>links are used. Should we have a requirement saying this? Don't know if

Here's what I want the requirement to say:

	The LMM design MUST not introduce any additional latency
	into handover. Candidate LMM designs that require additional
	header overhead for tunnels MUST be reviewed by the ROHC
	working group to determine if the header overhead can be
	compressed out, and if the header compressor can be restared
	from transferred compressor context when handover occurs
	without requiring any full header packet exchange on the new link.

>discussion in any case, as you say in your comment below.

There's still the interoperability problem, and co-ordinating between
the Seamoby protocol and the LMM preferences would be a problem.
I think it would make more sense to focus on one capabilities solution
and not try to split into two.

>to have multiple levels since it can be done otherwise without the need

Let me state this perhaps more clearly. By its very nature, LMM reintroduces
triangle routing into mobile IP. It does this because the LMM agent
acts like the home agent in the sense that all traffic to the mobile node
must go through it. There is no way to avoid this, it is a consequence
of having to keep the regional care of address fixed.

One way to reduce the length of the unwanted triangle leg is to position
the LMM agent in the natural routing path of the mobile node. This
collapses the triangle into approximately the nontriangular path.

As the mobile node moves, however, the triangle may become extended,
to the point where delays are occuring in the routing. If the option of 
deploying multiple levels of hierarchy is available, the network can
be engineered so that the bottom level LMM agent moves if the triangle
becomes too extended, while the upper level stays the same. 

The above argument explains why at least two levels of hierarchy are needed.
An argument for more is that, in a large multinational ISP, the signalling
lines may become extended to the point where updating the local care of
address becomes a problem. Allowing multiple levels of hierarchy allows
the ISP to design their network so that signalling is optimized.

		jak