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

From: "Carl Williams" <[email-masked]>
Date: Fri, 9 Nov 2001 18:33:03 -0800

Dear MIP working group members,

  I have submitted version 01 of the LMM requirements draft.  The
  URL for this draft is at: http://www.docomolabs-usa.com
  under publications link (2001 papers).  It was officially submitted at 
  mid week so the announcement from IETF will be made soon to mip alias.
  
  Please review over this draft over the next 10 days and provide
  final comments.  I will post version 02 before Nov 21st deadline
  which will include any comments (general consensus to changes/additions).

  At this point I think we are done adding new requirements.  Unless there
  is some requirement that we are really missing, let's focus on the
  requirements already present.  

  Changes since last update:

  - The MIP working group chairs asked that Erik Nordmark, Theo Pagtzis,
    James Kempf, Hesham Soliman, Jari Malinen, and I to get together and
    deal with the wording for a requirement that is agreeable to all in terms
    of the issue of multilevel hierarchies. No text was added specifying multilevel
    hiearcharchy as a requirement; however,  in order to meet some of
    the requirements presented, an LMM scheme may have a hierarchical structure.

 - Clarity (more details on exisiting requirements since version 00 of draft):

   Some working group members requested more clarity of some of the requirements.
   Thus the following changes were made:

    1.  Scalability requirement regarding guarantees to support millions of nodes for
         an administration domain.  
   
         Text was added to state that the LMM framework MUST scale linearly with the increase
          in the number of MNs.  An elaboration of this requirement is provided in the draft.

    2.  Auto-configuration requirement

         A number of working group members (email and IETF-London) wanted me to clarify
         what this requirement means.  An elaboration of this requirement is provided in the draft.

    3.  Sparse routing element population requirement

         Hongyi Li and Hesham Soliman requested on the mip wg alias to explain what is 
         the Sparse Routing Element and what is the reason behind this requirement.
         Text was provided in the draft defining Sparse Routing Element and the reason
         (elaboration done) for it.

    4.  FMIPv6 and LMM interworking.
   
       SHOULD changed to MUST at request of many working group members.  Presented
        proposed text at IETF-London.  A bit more elaboration done on the requirement in 01.

    5. Scope of LMM effect now changed to "Induced LMM Functional Requirements"

       Change to allow MN to have changes/modifications for LMM solution made. 
       Elaboration done on this requirement.

    6.  Introduction and abstract

        Introduction now provides "movtivation" and "principles" of LMM.  

   - New requirements

     1. Strong Authentication Requirement
 
        Add this requirement based on design team member request.  This requirement
        is being put in draft but there was some concerns about it by one design team
        member.  I think that we simply need to come up with text here that meets
        the intent of having the requirement without specifying "Strong Auth" in it.

    2.  Single Point of Failures
 
        New requirement added. Although this was in the original draft as a "goal".
       
   3.  Resilience to topological changes

       Requested on the MIP working group alias. No one seem to have problem and
       this requirement made sense.

   4.  Movement detection
  
        Jari Malinen requested this new requirement that mandates LMM provide
        a global unique identity of a visited domain.  Please see draft for elaboration.

   5. LMM MUST not disrupt core IP routing anywhere in network requirement

       Working group member requested it.

   6. Location Privacy and tracking support
  
       Requested by James Kempf to be added to draft.

   7.  Reliability, Stability and Quality requirement

       Requested by working group members.

Thanks all to those who contributed.  If I missed anyone in acknowledgement section,
please send me email.

Phil and Raj,  I would like to make plans for last call on this draft after
we put out version 02 on Nov 21st.    

Working group members, please send comments/debate over next weeks.
Hopefully, we can wrap this up at IETF-Salt_Lake_City meeting and 02
will be final revision.

Thanks all!

Carl

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 13 Nov 2001 18:18:43 -0800

great work!
thanks for putting together the LMM requirements draft, and I have a
couple comments.
I organize them as: comments on the reqs, new reqs, and editorial
comments.

----------------------
Comments on the requirements
---------------------
1.2 Principles of the LMM

It seems to me that this subsection belongs to the solution space. "This
is done
by [...] assigning two care-of addresses..." and other sentences like
this one describe how to implement LMM. This should not be in a req
draft. The principles should be at a concept level. Or the whole
paragraph should
be scrapped. (Same issue in 2.0 Terminology:  the LMA is defined in
solution space,
and not concept space).

3.3 Induced LMM functional requirements
("Functional requirements induced by LMM" would be better0

3.3.1 and 3.3.3: I do not see the difference. Please merge or clarify.

3.4 Scalability

Shouldn't 3.3.2 be filed in there?

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. 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.

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.

3.4.7 Technically, it is not triangular routing, as uplink is optimized
and downlink is
triangular. Actually, it assumes that "all traffic MUST go through the
LMM agent"
(MUST emphasis mine), uplink and downlink. More on this later.

'The LMM framework SHOULD support optimal placement...LMM"
This is an implementation issue.  Should be removed.

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?

3.5.1/2/3 Add a mention that if MUST NOT increase is the least expected,
SHOULD decrease
would not be too bad either

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.

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.

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?

3.12.1 is redundant with 3.4.5 (and 3.4.2 to some extent). As a general
comment, reliability is
dealt in both 3.4 and 3.12, maybe both sections should be merged.

3.14 Quality

What exactly is meant by Quality. Is it QoS, then say so. Otherwise,
clarify.

------------------------------------
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.

-----------------------------------
Editorial comments:
-----------------------------------
Abstract:
-add a sentence about relationship between administration domain
and LM domain, or some introduction about what is LM domain.
-"The identified requirement listed": get rid of listed, it's redundant.

-"They are intended to be used as....schemes": split in two or three
clear sentences.

1.0 Introduction:
-"Mobile IPv6 is presented with a number...". replace with: 'is facing',

as Mobile IPv6 is not presented in this document.

1.1 Motivation:
-"It is well established that...loss[1]". Why quoting a paper not yet
published if it
is well established? Get rid of the quote, or quote a well-established
result.
-typo in "with its curent mobility bindings that YIELD".
-"an interdomain Binding Update signal". Replace with "Binding Updates"
-Replace all both "it's" and the "it?s" with "its"
-place the acronym "(BUs)" after "Binding Update", a couple lines
higher,
and not "mobility binding".
-again, why quote [1] to say that the MN time at one AR has to be longer
than
a RTT if it hopes to receive a packet.

1.2 Principles of the LMM:
-First two sentences are redundant. Chop one.
-"This is achieved by introducing LMM Agens....similar to a HA": this
sentence should
disappear, as it is solution space. Replace with something like:
"A LMM agent concept is introduced in this draft. LMMA are the logical
entities
hiding the mobility within the LMMD to the outside of the LMMD" and
modify the end
of the paragraph accordingly.
-this paragraph needs more editing, but I advocate to suppress it
altogether. "regional
care-of (RCoA) address" replaced by "regional care-of address", etc.

1.3 Consideration points for LMM design:
-"principals" replace with "principles"
-replace "consideration points (goals)" with "goals"
-"when designing an LMM framework": this is not design nor framework.
"when specifying
LMM reqs".
-replace "reducing" in the item list with "reduce" twice, or make all
other introductory verbs in
the items in the participle "ing" form.
-the last paragraph ("Identifying..." till "...inpractice today")
is patting itself on the back, on how "solid" the reqs in this draft
are, "robust",
"essential", and a sounde "foundation". While it is true, and the team
should be thanked for
the good work, maybe the self congratulations should be left out.

2.0 Terminology:

LMM: replace "the true peers entity" with "its peers"

3.3.1 The last sentence: "this is so, since experience ...convergence"
should be removed or rephrased.
It is true that it is better to leave routing to routers. However, LMM
is one big contradiction
to this principle.

3.3.2 Maybe add "at most linearly", as "linearly" is good, but better
than linear is even better.

- "This would involve MIP-specific eliminated by any mobility management
protocol including
routing state as binding caches in addition to standard routing table
host routes. While host routes cannot be base IP mobility, any LMM
protocol MUST keep the number of host routes to a minimum."
This sentence should be reworded. At least, I cannot make sense of it.

3.3.5 Again, replace "true peer entities" with "peers"

3.4.5 replace " effected in the routing of the ...applied" with "in the
routing of the LM domain".

3.4.6 Make two sentence of the first paragraph "Any..compression",
"Transfer of compressor...disruption".

3.4.8 replace "doesn't" with "does not"

5.0 References
[1] Replace 'localised' with 'localized'
[3] get rid of question marks

---------------------------------------------------
That's about it.
Thanks again for putting it together, hope you'll find my comments
useful,

Cedric.

---

From: "Carl Williams" <[email-masked]>
Date: Tue, 13 Nov 2001 18:59:53 -0800

\

> Carl:

Hi Cedric,

   Thanks, I will review over your comments.

Thanks for reading the draft!

Carl

---

From: "James Kempf" <[email-masked]>
Date: Wed, 14 Nov 2001 11:30:15 -0800

Cedric/All,

I'm looking at draft-ietf-mobileip-lmm-requirements-01.txt on
http://www.docomolabs-usa.com (it has not yet been posted to ISI), and I
don't see any requirement listed as 3.4.8. Section 3.4 only goes up to
3.4.7.

As for the rest of  Cedric's comments, I agree.

Also, I'd like to register an objection to the following wording in
Section 3.9:

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

This wording essentially rules out any solution that would combine with
fast handoff. I think that is a mistake because it may be possible to
obtain a solution that is simple and easy to deploy and implement which
is tightly bound with one of the fast handoff algorithms. This is not to
say that it should be the only solution, so that if another fast handoff
algorithm were deployed, another LMM solution might be required.

I think what this requirement is getting at is that there must be an LMM
solution that is available regardless of the handoff algorithm. The
current text does not cover standard MIPv6, so, given the current text,
it would be possible to develop a LMM
solution that does not cover standard MIPv6 handoff and it would still
be compatible with the requirements. I think the
requirement should ensure that SMIPv6 is covered as well.

 So how about.

3.9 Support for MIPv6 Handover.

   An LMM solution MUST be available for all standardized MIPv6 handover
algorithms. The signaling interactions
   between the handover algorithms and LMM MUST maintain compatibility.
This requirement SHOULD NOT be interpreted
   as ruling out useful optimizations of LMM and MIPv6 handoff that
simplify the implementation or deployment of LMM or
   MIPv6 handover.

            jak

----- Original Message -----
From: "Cedric Westphal" <[email-masked]>
To: <[email-masked]>
Cc: "Carl Williams" <[email-masked]>
Sent: Tuesday, November 13, 2001 6:18 PM
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
.01)

---

From: Theo Pagtzis <[email-masked]>
Date: Thu, 15 Nov 2001 17:33:58 +0000

> be scrapped. (Same issue in 2.0 Terminology:  the LMA is defined in

I strongly disagree.. The principles describe the operational abstract
of an LMM scheme. Perhaps one needs to qualify the 'two CoAs' with 'at
least two CoAs' since you require at least one localised (domain-wide)
point of routing/id reference. Perhaps you may want to add more in a
future LMM scheme (but I very much doubt since it would be at least
sub-optimal unless you intend to abstract CIP or HAWAII with just one
such route/id ref -which is probably another class of micro-mobility in
my book)

BTW the LMA term you mention is solution specific but not mentioned in
the reqs doc..

> 3.3.1 and 3.3.3: I do not see the difference. Please merge or clarify.

Indeed they may seem somewhat similar. However, the first one involves
_also_ functionality on the routing elements that needs to be tightly
controlled.

This may indeed need to be made more specific such that one stands as a
requirement over HA+CNs and the other stands as a requirement over ARs.
I believe this is also a good divide and conquer approach
(reqirements-wise) to tackle the issue on what we see as the abstract of
a mobility extension.

> Is this about scaling, or about supporting a large number of users?

I perceive scalability of an LMM scheme as the ability to support
(scales with) an increasing number of MNs. Perhaps if you voice out how
you perceive scalability we may see a different perspective on the
requirement. Do you want to elaborate a little on your view?

> This, unlike
> other subsection headings, is not phrased as a requirement.

considering my perception of scalability I kindly disagree although
wordsmithing is a never-ending endeavour.

 I'd replace
> earth today, so millions are already not enough. 

I agree that scalability needs to touch on a unit of measure: i.e.
globally? link-locally, site-locally or what? 
In a distributed system you want to see the capacity over what may be
considered the minimal unit of capacity measure and then work your way
up to the global (perhaps billions/zillions) aggregate. In that
perspective we need to be driven by a metric of node capacity over the
measure of locality! This goes away from numbers which is probably
better as the figure is a bit stochastic..

There are two
> says "it should be distributed so as to avoid scaling effects").

I am not clear what you mean here..all it says is that distribution
would aid scaling...this may sound like a potential suggestion for
scalability but it is generic enough to remain in the abstract.

> Also, replace "linearly" with "at most linearly", as we can accept

It seems to me that the wordsmithing here calls for 'at worst linearly'
rather than 'at most..'. I trust this is what you want to mean but 'at
most' sounds a bit strange..

> Local Domain expands in size.

Signaling will by default increase with the number of MNs. Nobody argues
against that. The question here lies with what is defined as a domain?
Is it the MN population (I believe this is not what is the intended
semantic but I may be wrong)? or is it the size (diameter, say) of the
domain? Perhaps Carl wants to consider the two perspectives in the
document.

> (MUST emphasis mine), uplink and downlink. More on this later.

With all due respect, technicaly you are wrong: I cite the term of
Triangle Routing from the Route Optimization draft of  
Perkins and Johnson:

" Triangle Routing

         A situation in which a Correspondent Host's packets to a Mobile
         Host follow a path which is longer than the optimal path
         because the packets must be forwarded to the Mobile Host via a
         Home Agent."

i.e. we only refer to the downlink. That is to say that upstream traffic
from the MN to the world is not even considered. Perhaps though Carl
wants to make that clearer for the uninitiated.

> This is an implementation issue.  Should be removed.

IMHO this is not an implementation issue, it is the issue of eliminating
the triangular routing. It does not say where to put it, however it
identifies that placement can make a difference in at least the second
routing leg past the LMM agent if not placed optimally.

> optimizations in particular?

I agree but I could not see it in the draft version I have perhaps it
by-mistake is still lurking out there...I also thought we removed it.
Carl?

> would not be too bad either

disagree, the 'SHOULD' directive conveys instruction which is not
necessarily mandatory..the 'MUST NOT' certainly mandates..
> between seperated domains?

Hmm on this one I must agree..that is a new one to me, which does
introduce a different consideration: differentiation between domain wide
and link wide MN detection...perhaps clarify and keep it short in this
requirements doc.

> to work..." is pure casuistic. If it is a non-LMM mechanism, what is it

largely in agreement on this one..

> NOT disrupt IP routing outside of the LM domain.

Well this is really tricky..how can you assure elimination of
disruption. How do you perceive disruption? Why should the LMM domain be
considered any different than the internet backbone when it comes to
routing. I thought the intent is to keep host routes under control. The
above statement does make some (partial) sense to me I guess..
> of building carrying base stations?

I disagree with the removal but let me explain the rationale here,
perhaps needs a bit of a wordsmithing here also. Basicaly your LMM
domain is not cast in stone with respect to the population of the LMM
agent. You initiate deployment with a minimal set of LMM agent, usualy
sparse at first. If the thing works out to do well and more MNs start
populating the _domain_ you want to scale up your deployment plans with
more LMM agents (dense). That means that the LMM scheme must cater for
the introduction of new LMM agents which are a change in the LMM
topological overlay, without incurring a prohibitive cost of ownership,
i.e. autoconfigure the new LMM (meta)-topology

I think however I agree with a merging with 3.4.5 since they are pretty
much the same thing (only from the generic to the specific :).

In that respect I guess 3.8 section should merge to 3.4.5.

> dealt in both 3.4 and 3.12, maybe both sections should be merged.

I agree with the point about 3.12.1 merged with 3.4.5 (see above). I
also agree with the 3.12 section merge with the 3.4.5 since there is an
issue with indicating failure among LMM agents. This pertains to
reliability and quite rightly manifesting itself as a topological change
that needs to be noted accordingly. So 3.12 may be transormed in to
3.4.5.1 (perhaps??)

> What exactly is meant by Quality. Is it QoS, then say so. Otherwise,

fine by me..and rightly noted..

fine !

> 3.15.2-facilitate the new provisioning of both uplink and downlink QoS

fine (2) with a slight reservation for the following comment. Who says
that if you facilitate new provisioning for the uplink from the MN you
have to go through the LMM agent?

> uplink traffic is tunneled through the LMA (section 3.4.7).

_no it is not! In fact it assumes that it doesn't although it is not
explicitly stated (I guess two edged sword.. :)

 It also
> 2-means that LMM and QoS (like LMM and IP routing) MUST work

I will just agree with Hesham on this one since there is no point in
saying same thing with different words..

Cheers

Theo
UCL/Mobile Systems

---

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

Theo,

thanks for reading my comments. I snipped the ones where we agree, and
tried to explain myself better on the other points.

> such route/id ref -which is probably another class of micro-mobility in

I think this is not the point I was making. The wording in the principles
paragraph
is not at the principles levels, but can be seen as implementation
recommandation.
For all I care, if someone can meet all the reqs with one CoA, it is fine with
me. The doc
says: "This is done by..." I assume refering to HMIP or RegReg.

> BTW the LMA term you mention is solution specific but not mentioned in

I should read again the reqs doc: it is one of 6 terms defined in the
terminology.
As it is defined in the terminology, for the consistency of the document, it
should
be used instead of LMM agents that populate the document.

> _also_ functionality on the routing elements that needs to be tightly

So you mean the second one is included in the first one? Them please merge or
clarify.

> requirement. Do you want to elaborate a little on your view?

Scalability is about the marginal increase induced by adding new users. You
can
build a system for a million users. If you multiply by one million the system
complexity
to accomodate 3 more users, then it is not scalable. However, you did
guarantee
support for millions of nodes. Thus, I strongly disagree with the wording
above.

> wordsmithing is a never-ending endeavour.

Well, let me put it simply: I would like a MUST or a SHOULD or any word like
this, like the other headers in this section 3.4 have.

> globally? link-locally, site-locally or what?

You agree with something I did not say :-).

> better as the figure is a bit stochastic..

Let's keep it simple, would you? I'd suggest:
"3.4.1 The LMM complexity MUST increase at most linearly with the size
of the LM domain and the number of MNs."

> scalability but it is generic enough to remain in the abstract.

My point is that, if you suggest to distribute the system to make it scalable,

then you are going into solution space. The second req goes as:
"The LMM framework MUST support distribution of the LMM functionality
in the visited domain..." . While I see where you are coming from,
it seems to me that the LMM functionality should be distributed over the
LMM domain. What is the visited domain? The LMM domain. What is the
LMM domain? The domain where the LMM functionality applies. With this
in mind, re-read the excerpt I just quoted. You'll agree it should be removed.

> most' sounds a bit strange..

Not to me. It is meant as an upper bound, thus at most. At worst is fine
with me.

> against that.

The req as phrased does.

> The question here lies with what is defined as a domain?

I quote from 3.4.7: "all traffic must go through the LMM agent". So both
uplink and downlink are considered. I agree with this, it should be clarified,

and this is why I proposed to add this as a requirement.

> routing leg past the LMM agent if not placed optimally.

It is actually an engineering issue. This to me is the same as requesting
for instance that "the LMM framework SHOULD support optimal provisioning
of the links to the LMM agent". Where I locate my LMM agent box in
my network is a L1, physical layer, issue.

> necessarily mandatory..the 'MUST NOT' certainly mandates..

this is why I say: Add a mention. I did not say: replace one with the other.

> disruption.

The req as stated is: "The LMM framework MUST NOT disrupt core IP routing..."
So I'll return the question to you.

> How do you perceive disruption? Why should the LMM domain be
> routing.

Because the LMM interferes with routing. Using only the regional CoA, packets
cannot get routed to the MN. Thus my grudge with the requirement, and the
suggested change, as by its definition, the LMM makes it impossible to
enforce.

> I thought the intent is to keep host routes under control. The

> i.e. autoconfigure the new LMM (meta)-topology

I think this is covered in the scalability requirement: as your number of MN
increases,
the complexity of scaling the LMM to accomodate these users should not get out
of hands.
Don't you think?

> have to go through the LMM agent?

not me! If the CN is outside of the LMdomain, then yes, you'd require the
uplink traffic and the QoS signaling to go through the LMM agent. If the CN is

inside the same LM domain, then by no means should you go to the LMA.

> explicitly stated (I guess two edged sword.. :)

This is why I suggest to clarify! Although I'd make the recommendation that
the
uplink traffic goes through the LMA, when the CN is outside of the LM domain
(this for location privacy and signaling economy by avoiding e2e QoS signaling

after handoff).

Take care,

Cedric.