Subject: RE: [mobile-ip] LMM for IPv6 requirements draft (new revision .01 )

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 14 Nov 2001 11:55:55 +0100

Cedric, 

Thanks for the feedback, 
I haven't been able to contribute much to
the requirements group recently so I have some 
additions / comments below. 

3.4.1:  "Scalability guarantees to support millions of nodes for an AD"
Is this about scaling, or about supporting a large number of users?
This, unlike
other subsection headings, is not phrased as a requirement. I'd replace
it with
the first sentence, but then again, I don't know what the scaling of a
_framework_
means. Get rid of number references. There is a billion cell phone users
on this
earth today, so millions are already not enough. 

=> I agree, numbers won't mean much, the linearity 
requirement should cover that. 

There are two
requirements in the
paragraph anyway (and they contradict: one says "it should scale", the
other
says "it should be distributed so as to avoid scaling effects").
Also, replace "linearly" with "at most linearly", as we can accept
better than linear
performance.

=> Agreed.

3.4.4: The last MUST NOT seems hard to enforce. It is expected, and I
don't think
it is bad, that the amount of signaling would increase as the number of
users, as the
Local Domain expands in size.

=> Yes. 

3.4.8 link layer
I am confused here by this requirement. Is LMM a MIPv6 extension, as
described in
the document? So why does it care about L2 in general, and L2
optimizations in particular?

=> I agree. I thought we agreed to remove that. 

3.5.4 Should be removed or clarified. Who is detecting the movement
between seperated domains?
The MN, the CNs, the HA, the LMA? Is it a domain addressing issue (which
should be
left out here). The sentence: "The reason for this ...is that there is a
need...for the mechanism
to work..." is pure casuistic. If it is a non-LMM mechanism, what is it
doing here? Etc.

=> I can't agree more, this requirement definitely
does not belong to LMM or this draft. This is a whole
different domain of work.

3.7 LMM disrupts IP routing by adding host routes. Should be rephrased
as: LMM MUST
NOT disrupt IP routing outside of the LM domain.

=> Makes sense.

3.8 Last paragraph "To avoid concentration....populate the
administrative domain". Remove the
paragraph. There is no concern that MNs mobility patterns would be
affected or influenced
by the LMM-agents (btw, it is LMA in the terminology). Is this paragraph
saying that
MN will flock to an access point close to a LMA? Do cell phone users
aggregate in front
of building carrying base stations?

=> I never understood this requirement, perhaps Carl 
or someone can clarify. 

3.14 Quality

------------------------------------
Missing reqs
-----------------------------------
Even though you request that no new reqs be provided, let me make the
case for one:

3.15 QoS

The LMM MUST interwork with the QoS schemes to:
3.15.1-hide the mobility of the MN to its peer by avoiding end-to-end
QoS signaling.
3.15.2-facilitate the new provisioning of both uplink and downlink QoS
after a handoff

1- means that the uplink traffic MUST be tunneled through the LMA.
(this is assume in the document, it must be explicited. Current LMM
proposals
(HMIP, RegRegv6) have an uplink that is not tunneled through the LMA.
This allows the CN to be aware of the local mobility of the MN by
looking at
the source IP address.) This draft makes the assumption that the
uplink traffic is tunneled through the LMA (section 3.4.7). It also
mention
provisioning in 1.3 as one of the goals of the LMM.

Having an optimized (non-triangular) uplink means that in case of QoS
renegotiation
after handoff end-to-end for the uplink, the location is not hidden to
the CN. It also introduces
delays and extra signaling in having to renegotiate e2e. By having a
potentially
distinct uplink and downlink, it introduces the need for distinct QoS
signaling uplink
and downlink for re-establishment after handoff. On the other hand, by
having
both uplink and downlink going through the LMA, the handoff implies
changing
on the paths only below the LMA. One QoS re-establishment request can be
sent
to the LMA for both up and downlink.

2-means that LMM and QoS (like LMM and IP routing) MUST work
hand-in-hand.

=> I understand what you're trying to get to, but there is 
clearly a compromise and inefficiency here in terms 
of routing, additional dealys ...etc if the CN is 
closer than the LMM agent. Having said that I've actually
added this feature in the HMIPv6 draft, but for a different
reason. I'm neutral to this requirement really, I see 
your point but I can also envisage different ways of 
re-establishing the QoS path within the domain. For instance
a combination of Context transfer and proxy RSVP
from the new AR might also work, but I haven't looked
into it in more detail. 

I have another comment on the requirement for LMM to use 
strong authentication. I can understand it if we want to 
allow LMM to use strong authentication (PKI ...etc) 
optionally in addition to the -TBD- MIPv6 SA establishment
protocol. But I certainly don't think we should mandate
strong authentication only for LMM. This seems very strange
in light of the current MIPv6 security debacle. 

Regards,
Hesham

---

From: Cedric Westphal <[email-masked]>
Date: Fri, 16 Nov 2001 09:35:52 -0800

Hesham,

"Hesham Soliman (ERA)" wrote:

> .../...

> closer than the LMM agent.

[CWe] I agree that there is a trade-off. This trade-off exists already for
the downlink (assuming
the MN uses its regional CoA anyway, to avoid the BU overload on the
CN or to achieve some location privacy). I would agree with a requirement
that distinguishes between a CN in the LM domain, and a CN away out of the
LM domain.

> Having said that I've actually
> reason.

out of curiosity, can I ask which one?

> I'm neutral to this requirement really, I see

I thought about something along these lines, but it seems more
complex to me. By having the old path and the new path after
handoff differing only in the LM domain, you can give bounds
on the handoff latency (signalling goes no higher than LMM agent,
provisioning is within the LM domain, and every thing is in your
control). This is very appealing in terms of QoS: you can guarantee
the QoS is re-established within so many milliseconds within the domain.
If you don't 'pin' the uplink at the LMM agent, then it is beyond your
control.

> in light of the current MIPv6 security debacle.

Agreed.

Cheers,

Cedric.

---

From: "Carl Williams" <[email-masked]>
Date: Tue, 20 Nov 2001 00:33:41 -0800

I am working on the revision of the LMM requirements draft for Wednesday
final submission.  I have made changes based on the input over the last 10
days.

Here are three proposed changes that I want some review before I add them
to the final draft.  These three seem to get the most attention.

I removed the last paragraph for 3.8 Sparse routing requirement.  The
proposed final text for this requirement is:

3.8 Sparse routing element population requirement

   Any LMM protocol MUST be designed to be geared towards
   incremental deployment capabilities; the latter implies
   that the LMM scheme itself imposes minimum requirements
   on the carriers network.  Incremental deployment capabilities
   for an LMM protocol signifies that an initial set of sparse
   LMM agents can populate the administration domain of a network
   provider and operate sufficiently.  In addition, any LMM
   scheme MUST be compatible with any additional deployment
   of LMM agents in future infrastructural expansions; that is to
   say, allow progressive LMM deployment capabilities.

   It is for this reason that the LMM framework MUST NOT require
   that all routing elements be assumed to be LMM-aware in the
   signaling interactions of an LMM protocol. The LMM framework
   MUST BE supported, at the very minimum, by a sparse (proper
   subset) LMM agent population that is co-located within the
   routing topology of a single administration domain.

Requirement 3.9 (regarding interworking of LMM and MIPv6 handover)
has been modified as:

3.9 Support of Fast handoffs in LMMs

   Mobility extensions have been proposed to quickly enable IP
   connectivity of the MN at a new point of attachment; See [7]
   for one example.

   These enhancements are intended to minimize handoff latency
   and reduce packet loss.  LMM and any standardized Mobile IPv6
   handover algorithm  MUST BE able to be deployed independently
   of each other.  However, when the two classes of protocols
   co-exist, LMM and any Mobile IPv6 handover scheme MUST maintain
   compatibility in their signaling interactions for fulfilling
   complementary roles with respect to each other.

   This requirement SHOULD NOT be interpreted as ruling out
   useful optimizations of LMM and Mobile IPv6 handoff schemes
   that simplify the implementation or deployment of LMM or Mobile
   IPv6 handoff.

I will rework the 3.2.6 (strong auth) requirement to address Hesham's
concern.
Once this new text has been worked out I will send to alias for review.

3.2.6 Any LMM scheme MUST make use of a strong authentication mechanism
      to avoid a malicious MN from diverting traffic destined to a
      legitimate MN.  LMM SHOULD also ensure that the network be able
      to maintain topological confidentiality from visiting mobile
      nodes.  That is to say that the LMM scheme in use SHOULD NOT
      reveal the visited network's topology to the Mobile Node.

Cedric, thanks for your comments.  I think I have addressed them in my
revision.

Carl

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Nov 2001 09:50:52 -0800

Hi Carl,

>    that simplify the implementation or deployment of LMM or Mobile

I still think this misses the point. There are two problems with the
requirement as written:

1) It still could be interpreted as excluding standard Mobile IPv6. I
think all reference to fast handover as opposed to handover at all
should be deleted.

2) The second and third paragraphs are in contradiction. The second
paragraph says that LMM and handover must be separately deployable, but
the third says that optimization is allowed. This still prohibits a
solution in which LMM and handover are combined.

The requirement should state that all handover algorithms must be
supported, period. It is up to the designers of the protocol to figure
out whether to use the same protocol, an optimization that combines a
specialized LMM protocol with one or more handover protocols, or a
completely separate protocol.

Here is what I think the wording needs;

1) The title should be "Support for Handover in IPv6".

2) The first paragraph should be removed.

3) The sentence "LMM and any standardized Mobile IPv6 handover algorithm
MUST BE able to be deployed independenlty
of each other." should be removed.

>       reveal the visited network's topology to the Mobile Node.

This requirement should stress that the authentication must be the same
as authentication for routers. I believe Hesham's comment was that
strong authentication implied that IPSEC must be used, and I don't think
that is the intention. The trust relationship between an LMM agent and
the MN must be at the same level as the trust relationship between the
MN and, for example, the access router. This is clearly a different
trust relationship between the MN and the CN, but it need not be
required to be constructed with IKE or use IPSEC (on the other hand, it
may in fact be).

            jak

---

From: "Carl Williams" <[email-masked]>
Date: Tue, 20 Nov 2001 10:40:11 -0800

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; "Cedric Westphal"
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, November 20, 2001 9:50 AM
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision .01)

> think all reference to fast handover as opposed to handover at all

James,  I don't see that in the requirement.  The only mention of Fast
handofff
is in the title (which I can change to Supprt for Handover In IPv6").

> solution in which LMM and handover are combined.

No.  This is not what this says.  Please read carefully:

.  LMM and any standardized Mobile IPv6

> completely separate protocol.

Agreed.  And that is what it states.  Indeed, I wrote the requirement
so in such away that LMM must be designed in such a way that
it can be deployed independently of any MIPv6 handover algorithm
or if the two protocols are deployed together, then LMM and the
MIPv6 handover scheme MUST maintain compatibility (they MUST
interwork with each other).

> 1) The title should be "Support for Handover in IPv6".

I have no problems with this.

> 2) The first paragraph should be removed.
I have no problems with this.

> of each other." should be removed.

I disagree.  I think we should state this explicitly.

Carl

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Nov 2001 12:35:04 -0800 (PST)

> required to be constructed with IKE or use IPSEC (on the other hand, it

If there were a truly middle ground between the
expectation of localization with the MN/HA
relationship, and the any-any relationship of
MN/CN, this seems like it. The MN/LMM MAY have the
same localization properties as MN/HA, but then
again, maybe it doesn't. For example, what about
the situation where somebody's providing mobile
access gratis? Does there need to be strong
authentication? Admittedly the mobile node uses
this access provider at their own peril if they
aren't authenticated, but that may be a reasonable
assumption in many cases, just like I probably
don't worry too much about the identity of a
provider so long as I've taken reasonable
precaution while I'm on a foreign network.

I wish I had an easy answer here, but this seems
to be an ease of use vs. security tradeoff. I
guess that I'm pretty skeptical that mandating
heavy authentication subsystems of whatever
variety you care to envision is a desirable
outcome; it seems pretty heavy handed, but it's
not without its own set of problems.

	    Mike

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Nov 2001 16:11:29 -0800

Hi Carl,

> is in the title (which I can change to Supprt for Handover In IPv6").

The first paragraph also talks about "quickly moving," implying
fast handover. I'd suggest removing the first paragraph.
> No.  This is not what this says.  Please read carefully:

Here is what the second paragraph says:

    LMM and any standardized Mobile IPv6
    handover algorithm  MUST BE able to be deployed independently
    of each other.

So please explain to me how an LMM solution that leverages
a handover protocol could be separately deployed from
the handover protocol?

                jak

---

From: "Carl Williams" <[email-masked]>
Date: Tue, 20 Nov 2001 18:55:56 -0800

> a handover protocol could be separately deployed from

Hello James,  

Initially the requirement was written from the perspective
of an "optimized" MIPv6 handover scheme that was *optional*.

So with your proposal we are now not making any assumptions
about the nature of the handover scheme.  Indeed, it could just simply
be MIPv6.  I will use the suggested text and include:

3.9 Support for Mobile IPv6 Handover

Since one of the primary goals of LMM is to minimize
signaling during handover, an LMM solution MUST
be available for the standardized Mobile IPv6 handover
algorithms. LMM and the Mobile IPv6 handover algorithms
MUST maintain compatibility in their signaling interactions for
fulfilling complementary roles with respect to each other.

If anyone has any comments on this requirement, please
make your concerns known.

Thanks to all those who read the draft:) and provided feedback.

Carl

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 21 Nov 2001 08:29:35 +0000

Hi Jak,

  I thought that any mention w.r.t. a handover and compatibility of a
handover mechanism w.r.t to an LMM scheme was only to imply
compatibility with handoff optimisations. That is to say, it assumes
existence of base MIPv6 handoffs at the very least..i.e. we assume base
MIPv6 and only care about compatibility of LMM schemes with handoff
mechanisms _beyond_ base mobility (a.k.a MIPv6).

Theo
UCL/Mobile Systems Group

---

From: "James Kempf" <[email-masked]>
Date: Wed, 21 Nov 2001 08:37:32 -0800

Hi Theo,

> mechanisms _beyond_ base mobility (a.k.a MIPv6).

If a service provider wants to deploy standard MIPv6 handover, then it
should be possible to obtain LMM support for it. This is not to imply
that the same LMM solution is required for both standard MIPv6 handover
and the optimizations, they could be different.

            jak

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 21 Nov 2001 17:07:53 +0000

Hmmm...

       ( reductio ad absurdum..)

consider:

   an LMM solution X must work with MIPv6...
   an LMM solution X' must work with handoff optimizations... 
   
However handoff optimization cannot work on their own...they assume
existence of MIPv6 

that implies that X' must also work with MIPv6..

but X and X' are not the same... !!!
..that leaves me with no other option but to conclude that X=X' !
.. which basically means that the SAME LMM solution must be compatible
with MIPv6 and the handoff optimisation at the same time...

Theo
UCL/ Mobile Systems Group

PS: work with = be compatible with

---

From: "James Kempf" <[email-masked]>
Date: Wed, 21 Nov 2001 13:27:00 -0800

Your logic is impeccable, Mr. Pagtzis. :-)

        jak

----- Original Message -----
From: "Theo Pagtzis" <[email-masked]>
To: <[email-masked]>
Cc: "Cedric Westphal" <[email-masked]>; "Hesham.Soliman"
<[email-masked]>
Sent: Wednesday, November 21, 2001 9:07 AM
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
.01)