Subject: Re: [nemo] Re: more comments on the RO Taxonomy draft

From: Chan-Wah Ng <[email-masked]>
Date: Mon, 04 Oct 2004 14:21:53 +0800

Hello Alex,

I hope to address as much of your concern as possible to my best
knowledge. Some issues you raised are beyond me, so I left them alone.

/rgds
/cwng

On Thu, 2004-09-30 at 22:20, Alexandru Petrescu wrote:
> Chan-Wah Ng wrote:
> > Like to ask the WG on their opinions of what is still lacking for the
> >  draft to be put forth as the RO Problem Space analysis. All comments
> >  are greatly appreciated.
> 
> Dear Chan-Wah, I've read the draft in more detail and I have several
> comments.  I've hesitated before sending them, because they may look too
> harsh, but then you say that all comments are greatly appreciated so I'm
> sending them.  I think the draft has some good parts and some badly
> explained parts and some unnecessary parts.
> 

No problem about comments being harsh (In fact, I don't think any of
them is harsh, I thought your previous mail was harsher :)).  Thank you
for your insightful and thorough comments.

> > between nodes in a mobile network and their correspodnet nodes.
> 
> correspondent.
> 

ok.

> > route optimization with corresponding nodes initiated bu mobile
> 
> by for bu.
> 

ok.

> > 3.  performing RO over the routing infrastructure involving 
> > optimizing the route between two routers situated near to each end 
> > point, instead of end-to-end;
> 
> Last words should be "instead of end-to-end RO" and "end-to-end RO"
> should be defined somewhere.  Where is it defined?  google "end-to-end"
> the first entry is right so you're lucky.
> 
> "End-to-end" is like saying that your app talks to my app, and that your
> app does not talk to my kernel.  _That_ is "end-to-end".  Ping is not
> "end-to-end" because your app talks to my kernel.  But better rely on
> that paper's explanation and on that of RFC 3724 "The Rise of the Middle
> and the Future of End-to-End" and of RFC 3439 "Architectural Guidelines".
> 
> "End-to-end" is not adapted for what you're trying to say, to my taste.
>   I think what you're trying to say with "end-to-end RO" is more like
> "keep the network dumb" or "empower the end user" or "keep soft state in
> the network" or "fate-sharing" similar.  I don't have a reference handy
> for this, but the term "end-to-end" is so much used and so badly so
> often that I'd take no risk and not use it at all.
> 

I see, ok.  Will use some other expression.

> > Lastly, route optimizations involving nested mobile networks are 
> > explored. This involves minimizing the number of tunnels required 
> > when there is multiple levels of nesting.
> 
> One can achieve minimal tunnels without actually offering shorter paths,
> with ROHC.  The two goals are different.
> 
> > This scenario is useful when a lot of MNNs in a mobile network is 
> > communicating with a few
> 
> "MNN's are communicating", not the "lot is communicating".
> 
ok.

> > In such cases the MR only needs to send one binding update (BU) to 
> > optimized the route between CN and a few MNNs.
> 
> "optimize" instead.
> 
ok.

> If an MNN is actually a VMN, it is not sufficient for MR to send a BU to
> CN, the comm still goes to that VMN's HA.  Better use "LFN" instead of
> "MNN".
> 

That is arguably solution dependent.  I propose to add in the word
'may', and will consider changing MNN to LMN.

> > A major issue with this form of optimization is that the end-to-end 
> > principle of the MIPv6 Reverse Routability (RR) test is broken.
> 
> What is the "e2e principle of the MIPv6 RR test(s)"?  RFC 3775 Mobile
> IPv6 has no such principle...  RFC 3775 Mobile IPv6 has another
> end-to-end mentioning of end-to-end IPsec, but it is not an end-to-end RR.
> 
> So the reader is not convinced this is a "major issue"; and also it's
> called Return not Reverse.

Agreed to your objection in the use of the term 'e2e'.  But it is still
a major issue. I will address this in greater detail in the update
version of the draft.

> 
> > If not, the optimization may be limited to triangular routing 
> > MR->CN->HA->MR.
> 
> better: "optimization would be limited to only eliminating the CN-HA and
> HA-MR edges of the MR-CN-HA triangular path."
> 
> What's "triangular routing" by the way?  Is it that all 3 edges are used
> to send packets?  Is it that only two edges are used so? (a prior
> version of MIP6 was wrongly using sending packets MN-CN and receiving
> CN-HA-MN, so that was "triangular"; current MIP6 w/o RO is bi-angular
> path because there's no CN-MN path and there's CN-HA and HA-MN).
> 

Agreed.  I think the use of the term "triangular routing" was largely
(and I admit wrongly) based on historical usage of the term to describe
the suboptimal routing problem (I think dated as far back to MIPv4).

> > When a Mobile Node visits a Mobile Network, the best Route 
> > Optimization is obtained if the path in the Infrastructure is the 
> > same as if the Mobile Network was attached at the attachment point of
> >  the Mobile Router (i.e., there is not additional Tunneling that is 
> > linked to NEMO).
> 
> I don't understand this.  The Mobile Network _is_ attached at the
> attachment point of the Mobile Router, yet routes are not optimal.
> 
I think the confusion is our unfortunate typo mistake "... if the Mobile
*Network* was ..." should read "... if the Mobile *Node* was ...".

> > In this model, both the LFN behind the MR and the Correspondent can 
> > be MIP agnostic.
> 
> The CN can not be MIP agnostic because RFC 3775 requires it to be a MIP
> believer.  The CN may be NEMO-agnostic, and not be NEMO-aware.

I agree to change "MIP" to "NEMO", but the reason you gave I disagree. 
RFC3775 defines "CN to be a peer node with which a mobile node is
communicating".  It makes no assumption whether CN is MIP-aware or not. 

But this is a small matter, and this draft is addressing NEMO RO.  So we
shouldn't be talking about MIP-agnostic, but NEMO-agnostic.

> > The goal is to locate the closest (BGP) gateway for a Correspondent 
> > that is located outside of the domain, and tunnel between the MR and
> >  that gateway as opposed to the Home Agent for that specific 
> > Correspondent.
> 
> There is a reference for BGP and mobile networks at a this year's NANOG
> by Cisco I believe, find it.

ok.

> 
> "4.2 Correspondent Router"
> 
> But earlier the draft was talking about "C-side routers".  What's the
> difference?
> 
> > The Core Routers for the network of the Correspondent are all CRs.
> 
> Yes, because CR stands for Core Router.  Or?
> 
> > M-side routers
> 
> What do you call an edge router to which MR visits and that also serves
> a CN?  Is it a CM-side router?
> 
> What is an MR to which two MR's visit whose LFN's talk to each other?
> is this AR a CM-side router?
> 

I will look into this section and clarify in the next version.

> > 5.1 Nested Tunnels Optimization ...
> > 
> > With no Nested Tunnels Optimization, we would have three 
> > bi-directional nested tunnels
> > 
> > Such a solution introduces the following problems:
> > 
> > "Pinball" routing
> 
> What _is_ Nested Tunnels Optimization?
> 
> What "solution" introduces the pinball routing?
> 
> By your logic it would mean that Nested Tunnels Optimization is a
> solution to the problem of having three bi-directional nested tunnels
> and this solution (supposedly eliminating the too many tunnels) induces
> pinball routing!  Is this what is meant?

OH, another confusing sentence structure!  "solution" in the second
statement should refer to "a solution with no nested tunnel
optimization".  I will restructure the paragraphs.

> 
> > On the other hand, with a Nested Tunnel Optimization, we would have 
> > at most one bi-directional tunnel outside the Mobile Network
> 
> Partially agree.  It is possible to have such a NT Optimization and
> haveat most zero (instead of one) tunnels, at least within an
> aggregation of moving networks.  Zero-encapsulation RO for nested NEMO.
> 

Zero encapsulation? That looks like a full RO solution.  The idea of
nested tunnel optimization is to eliminate the effect of nesting, so
that the end result is as though there was no nesting.  If there was no
nesting, that basic  NEMO will result in one tunnel. 

Furthermore, the text uses the words "at most one", which includes any
solution that can reduce the number of tunnels to zero.

> > The Reverse Routing Header (RRH) approach avoids the multiple 
> > encapsulation
> 
> Depends what you call encapsulation.  RRH, and any routing header for
> that matter, is already a form of encapsulation because it adds data
> fields to a pure base header.  Of course, multiple encapsulation by
> adding multiple 40byte base headers is worse than multiple encapsulation
> by adding only 16byte addresses, but still, one can't say RRH is
> avoiding multiple encapsulation.
> 
I understand what you are driving at, but I wasn't aware that it is the
common understanding among IETF folks that routing header is treated as
a form of encapsulation.  We would change the wordings if it is the
common understanding that routing header is treated as a form of
encapsulation, but AFAIK, most would not treat it that way.

> > Although optimization  within a mobile network is not within the 
> > charter of the NEMO working group, it might be insightful to discuss
> >  such optimizations.
> 
> Optimization within a moving network is as much in the NEMO charter as
> optimization outside of it: define the problem.

Agreed, the problem should be defined first, before we decide if it was
in the charter or not.

> 
> > These approaches are generally difficult to secure unless all the 
> > Mobile Routers and Visiting Mobile Node belong to a same 
> > administrative domain and share predefined Security Associations.
> 
> 
> Finally something to which I agree wholehartedly.  Something to which
> can be added "true if no widely deployed security infrastructure".
> 
ok.

> > 1.  Binding Update storm
> 
> Is this stormy or more windy?  Because I know a paper simulating this
> stuff and finding it to be more windy.

Could you provide details to the paper?  Anyway I suspect this is just a
question of metaphor ...

> 
> > 4.  Missing BU
> > 
> > If a CN doesn't receive the full set of PSBU sent by the MR, it will 
> > not be able to infer the full path to a node inside the nested Mobile
> >  Network.  The RH will be incomplete and the packet may or may not be
> >  delivered.
> 
> 
> Ok but don't try to make the BU-BAck exchanges any more reliable than
> currently is.
> 
> > 6.3 Mobile Access router selection
> 
> Remove this.  This is CARD.  This is specified, Seamoby is closed.
> 
> > 6.5 Multihoming stuff
> 
> Remove this, it's not required by this charter item.
> 
> > 6.5 Mobility Transparency
> 
> Remove this, it's not required by this charter item.
> 
> However, the effects of some nodes being NEMO-aware is required and this
> section has discussion about this.  So maybe write a new section keeping
> those.
> 
> > 1) The RR test prevents a MR-LFN dichotomy on the Mobile Side,
> 
> What is a "MR-LFN dichotomy"?

good question! I don't know myself ...

---

From: Chan-Wah Ng <[email-masked]>
Date: Mon, 04 Oct 2004 14:37:43 +0800

Hello Alex,

thanks for mapping the draft against the charter.  It is very
beneficial, as often authors (at least myself) got carried away and
deviates from the charter.

On Thu, 2004-09-30 at 20:28, Alexandru Petrescu wrote:
> The Charter item does not require for an RO Taxonomy (classification).
> It requires for a problem definition first so let's define the problem.
> 
> Chan-Wah Ng wrote:
> > http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ro-taxonomy-02.txt
> > 
> > 

> The respective charter item is the following:
> 
> > An informational document which specifies a detailed problem 
> > statement for route optimization and looks at various approaches to 
> > solving this problem.
> 
> So: first describe the problem.  The problem is that paths are
> artificially long.  They are longer than if MIP6 were not used.  The
> problem is worse than with Mobile IPv6 for hosts because multiple HA's
> are involved (MIP6 for hosts involves "triangular" paths, MIP6 for
> routers involves "multi-angular" paths).  Your "Pinball" routing is your
> figurative way of understanding my "multi-angular" routing.  I suggest
> the latter term for the terminology document.

We will be consistent with the terminology draft.

> 
> The NEMO RO problem is not the same as the multiple encapsulation
> problem.  The too-big-packets-because-too-many-headers problem has
> solutions like compress-those-headers aka ROHC.  It may be that a NEMO
> RO solution reduces the headers size too but that's only a side effect.
>   Solving the NEMO RO problem should at least reduce the path lengths but
> it is not requiring to reduce the packet sizes.

Yes, multiple encapsulation increases packet size is not the core
problem.  But it is still a problem.  It does not matter if a solution
already exists (eg ROHC).  And the job of the WG charter item is to
analyse the problem.

> 
> The charter does not require to define Mobility Transparency either,
> while the draft does it in three versions.
> 
The charter does not require the WG item "not to mention Mobility
Transparency" either.  

> The charter does not require dealing with multi-homing and NEMO RO, the
> draft deals.
> 
> > This document will look into the issues and tradeoffs involved in 
> > making the network's movement visible to some nodes, by optionally 
> > making them "NEMO aware".
> 
> The draft describes (in section Mobility transparency and RO) how some
> nodes are NEMO-aware.  That's ok and needed.  But I don't see the good
> description satisfying the charter.
> 
 Agreed, we will re-work the section.

> First, "end-to-end" principle is mentioned, should have the reference.
> I don't understand how not passing mobility from MR to CN breaks the e2e
> principle.
> 
> Second, having nodes that are NEMO-aware is used as a solution to
> achieve "mobility transparency".  The charter does not require "mobility
> transparency".  It requires a description of the issues and tradeoffs
> involved making the network's movement visible to some nodes,
> NEMO-aware.  Id' better write it like this:
> 
> "In order to develop a solution for the problem describe in this
> document, it might be needed that some nodes become NEMO aware.  The CN
> may be required to interpret bindings between a full address and a
> partial prefix (instead of between 2 full addresses).  The advantage of
> this is that it may help achieve RO for all LFN's under MR but the
> tradeoffs are: (1) successful attackers may reroute traffic of an entire
> prefix (2) it is difficult to use RR tests for all addresses within a
> prefix."
> 
> This would be the idea how to write it, but more detailed it should be.
> 
Thanks for the suggested text.

> > The interaction between route optimization and IP routing will also 
> > be described in this document.
> 
> So it should.
> 
> > Furthermore, security considerations for the various approaches will
> >  also be considered.
> 
> So it should.
> 
agreed. 

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Oct 2004 12:05:31 +0200

Chan-Wah Ng wrote:
>> solutions like compress-those-headers aka ROHC.  It may be that a
>> NEMO RO solution reduces the headers size too but that's only a
>> side effect. Solving the NEMO RO problem should at least reduce the
>> path lengths but it is not requiring to reduce the packet sizes.
> 
> problem.  But it is still a problem.  It does not matter if a
> solution already exists (eg ROHC).  And the job of the WG charter
> item is to analyse the problem.

Yes, it would be interesting to give a conclusion like: fragmentation
starts when 3 levels of nestedness all using Ethernet MTU 1280, for data
packets; for signalling, fragmentation starts at 10 levels.

>> The charter does not require to define Mobility Transparency
>> either, while the draft does it in three versions.
> 

:-)

Migration transparency, performance transparency, network mobility
support transparency and operational transparency - are all requirements
in the NEMO requirements/goals document.

The statements in the taxonomy draft about mobility transparency are, in
fact, relaxing the transparency requirements of the requirements/goals
draft, was this the intention?

Alex

---

From: Chan-Wah Ng <[email-masked]>
Date: Mon, 04 Oct 2004 18:26:11 +0800

> packets; for signalling, fragmentation starts at 10 levels.

:), that's a bit extreme, but I know what you are trying to point out. 
In the next version, I promise I'll do my best not to make the text
sounds as if increased packet size is a significant problem.  But I
would definitely mention it as a consequence of nested NEMO.

> in the NEMO requirements/goals document.
May I politely point out that they are requirements for NEMO Basic
Support... or am I mistaken?

> draft, was this the intention?
Nope, at least that wasn't my interpretation when I read/write (sorry
don't really recall who wrote that text) the paragraph.  The text about
mobility transparency is mainly to discuss that in achieving RO, it
might be necessary to have some nodes be RO-aware, eg CN (as you've
highlighted in another fork of this thread).

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Oct 2004 12:32:16 +0200

Chan-Wah Ng wrote:
>>> A major issue with this form of optimization is that the
>>> end-to-end principle of the MIPv6 Reverse Routability (RR) test
>>> is broken.
>> 
>> What is the "e2e principle of the MIPv6 RR test(s)"?  RFC 3775
>> Mobile IPv6 has no such principle...  RFC 3775 Mobile IPv6 has
>> another end-to-end mentioning of end-to-end IPsec, but it is not an
>> end-to-end RR.
>> 
>> So the reader is not convinced this is a "major issue"; and also
>> it's called Return not Reverse.
> 
> Agreed to your objection in the use of the term 'e2e'.  But it is
> still a major issue.

Until I don't know what the e2e principle of the MIPv6 RR test is, I can
not say whether that form of optimization is an issue or not (and even
less of being 'major').  For example, maybe the e2e principle of the
MIPv6 RR test states that only same-layer ends can address each other,
but different-layer ends can not address each other; if that principle
says so, then that form of optimization does not break that principle:
MR's IP-layer talks to CN's IP-layer and LFN's app-layer talks to CN's
app-layer.  So no problem, no issue, and no need of an issue to that
problem.

>> What's "triangular routing" by the way?  Is it that all 3 edges are
>> used to send packets?  Is it that only two edges are used so? (a
>> prior version of MIP6 was wrongly using sending packets MN-CN and
>> receiving CN-HA-MN, so that was "triangular"; current MIP6 w/o RO
>> is bi-angular path because there's no CN-MN path and there's CN-HA
>> and HA-MN).
>> 
>  (and I admit wrongly) based on historical usage of the term to
> describe the suboptimal routing problem (I think dated as far back to
> MIPv4).

Does the MIPv4 RFC define "triangular routing" somehow?

>>> In this model, both the LFN behind the MR and the Correspondent
>>> can be MIP agnostic.
>> 
>> The CN can not be MIP agnostic because RFC 3775 requires it to be a
>> MIP believer.  The CN may be NEMO-agnostic, and not be NEMO-aware.
> 
> I agree to change "MIP" to "NEMO", but the reason you gave I
> disagree. RFC3775 defines "CN to be a peer node with which a mobile
> node is communicating".  It makes no assumption whether CN is
> MIP-aware or not.

Ok, I think that's right.

>>> On the other hand, with a Nested Tunnel Optimization, we would
>>> have at most one bi-directional tunnel outside the Mobile Network
>>> 
>> 
> that the end result is as though there was no nesting.  If there was
> no nesting, that basic  NEMO will result in one tunnel.

One-tunnel?  For MIP6 for hosts, after RR, there's no tunnel at all.

> Furthermore, the text uses the words "at most one", which includes
> any solution that can reduce the number of tunnels to zero.

Right.

>> Depends what you call encapsulation.  RRH, and any routing header
>> for that matter, is already a form of encapsulation because it adds
>> data fields to a pure base header.  Of course, multiple
>> encapsulation by adding multiple 40byte base headers is worse than
>> multiple encapsulation by adding only 16byte addresses, but still,
>> one can't say RRH is avoiding multiple encapsulation.
>> 
> I understand what you are driving at, but I wasn't aware that it is
> the common understanding among IETF folks that routing header is
> treated as a form of encapsulation.  We would change the wordings if
> it is the common understanding that routing header is treated as a
> form of encapsulation, but AFAIK, most would not treat it that way.

Ok, I see what you mean.  Let me put it this way: without MIP6 there's 
no additional data added to all application-level IPv6 packet (the 
encapsulating headers or the routing headers).  With MIP6 there is.  One 
can say that routing headers involve less of this overhead data (less 
than encapsulating base and IPsec headers), but it's still overhead.

Wouldn't it be possible to have a sort of NEMO-RR after whose completion 
there's no encapsulating header, no routing header?  I bet this is part 
of the solution space to the problem you're trying to define.

>>>  charter of the NEMO working group, it might be insightful to
>>> discuss such optimizations.
>> 
>> Optimization within a moving network is as much in the NEMO charter
>> as optimization outside of it: define the problem.
> 
> Agreed, the problem should be defined first, before we decide if it
> was in the charter or not.

I wanted to say that the RO problem for NEMO should define the RO 
problem within the nested aggregation too (not only outside of it).

>> Is this stormy or more windy?  Because I know a paper simulating
>> this stuff and finding it to be more windy.
> 
> Could you provide details to the paper?  Anyway I suspect this is
> just a question of metaphor ...

Don't have it handy.  Do you have a paper quantifying that being stormy?

If one is sure that the BU storm is more windy than stormy then one does 
not consider it as a problem, metaphorically speaking.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Oct 2004 12:46:01 +0200

Chan-Wah Ng wrote:
>> Yes, it would be interesting to give a conclusion like:
>> fragmentation starts when 3 levels of nestedness all using Ethernet
>> MTU 1280, for data packets; for signalling, fragmentation starts at
>> 10 levels.
>> 

Sorry, what do you find to be extreme?  10 levels threshold before
fragmentation for signalling is too much?

Or using explicit numbers is extreme?

Sorry...

> would definitely mention it as a consequence of nested NEMO.

Yes and can we have more discussion before modifying text?  I don't 
think it's yet time to modify text.  There's already much text around:
three problem statements drafts.

>> support transparency and operational transparency - are all
>> requirements in the NEMO requirements/goals document.
>> 
> 
> Support...

Absolutely!  Yes, you're right, they're requirements for the NEMO Basic
Support, which were changed to become more "goals".

I wanted to learn how do you see the "mobility transparency" term with
respect to the other "x transparency" terms in the NEMO goals document.

>> The statements in the taxonomy draft about mobility transparency
>> are, in fact, relaxing the transparency requirements of the
>> requirements/goals draft, was this the intention?
>> 
> 
>  don't really recall who wrote that text) the paragraph.  The text
> about mobility transparency is mainly to discuss that in achieving
> RO, it might be necessary to have some nodes be RO-aware, eg CN (as
> you've highlighted in another fork of this thread).

Yes.  So why not titling such a discussion with "The Need for RO-aware
Nodes".  In my oppinion it is not because mobility should be transparent
that we need RO-aware nodes.  If one leaves place for such a light
interpretation of why RO is needed then _any_ other argument would 
apparently play in its favor.  For example: we need RO-aware nodes 
because handovers should be fast, we need RO-aware nodes because 
Internet should be end-2-end and so on.  Those are all bogus arguments 
to me, they all lack concreteness.  Metaphoring has its risks :-)

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 5 Oct 2004 13:12:43 +0900

Hi,

> Support, which were changed to become more "goals".

Well, not exactly. draft-ietf-nemo-requirements is about "Goals and
Requirements". Section 4 is about "design goals" for both Basic and
Extended, i.e. what is **desirable** to achieve (but which might not be
possible, with limited effort).

Section 5, on the other hand, is about **requirements** for NEMO Basic
Support. It served as the basement of draft-ietf-nemo-basic-support.

> to me, they all lack concreteness.  Metaphoring has its risks :-)

I kind of agree with Alex. On the other hand, I think it's extremely
difficult to decide if we need RO-aware nodes or not without looking
into the solutions.

I think what we should do is definitely using "RO-aware nodes ?" as a
metric to evaluate the many solutions, after the problem statement is
issued.

So, the discussion about the "need" could be left off after the document
is issued and the existing solutions are analysed.

Thierry.

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 05 Oct 2004 13:38:48 +0800

> difficult to decide if we need RO-aware nodes or not without looking
Agreed.

> is issued and the existing solutions are analysed.

Agreed.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 05 Oct 2004 14:10:14 +0800

> app-layer.  So no problem, no issue, and no need of an issue to that

I have a, should I say, vague idea about the problem of RR procedure
with respect to its application in NEMO-RO.  Give me some time to
organize my thoughts, and I would return to this with a clearer idea in
mind.

> Does the MIPv4 RFC define "triangular routing" somehow?

Not that I recall, but I remember the term triangular routing refers to
the sending of packets from FA to CN, and the return path of CN->HA->FA
(thus forming the triangle).  That is the time when the issue of ingress
filtering was not that obvious/significant.

> One-tunnel?  For MIP6 for hosts, after RR, there's no tunnel at all.

We are talking about nested tunnel optimization, so by your reference to
MIPv6 for host, I presume you have the VMN behind a MR in mind.  Even
with MIPv6 RO (with RR completed), there is still a tunnel between MR
and HA-of-MR.  With nested tunnel optimization, assuming the solution
can be extended to MIPv6 hosts, it is possible to have zero or one
encapsulation.  

It depends on the solution.  A solution can either result in a direct
routing over MR (by means of an extended routing header or otherwise),
which would then result in zero encapsulation (for simplicity, we don't
treat routing headers as encapsulation).

Alternatively, another solution might result in a tunnel established
between MR and the CN.  Then there is one level of encapsulation.

> of the solution space to the problem you're trying to define.

That would be very difficult to achieve.  By your definition of
overheads, a home-address destination option would also constitute as an
overhead.  I don't see how a NEMO-RO solution can hope to achieve zero
overhead, except perhaps using an entirely and drastically different
routing infrastructure.  I remember coming across Motorola's solution of
using multicast addressing to achieve RO.  That might be one approach to
achieve zero overhead ... or maybe not zero, but minimal, since some
overheads will be required to map that multicast address to the
home-address of the mobile node (VMN, LMN, or LFN).

> Don't have it handy.  Do you have a paper quantifying that being stormy?

Nope, but let's do a bit of thought experiment.  If you are looking at
the NEMO being a W-PAN or a car network, it might not even be windy at
all! Perhaps only a little breezy, so to speak. ;)

However expand that little W-PAN or car network to a train with hundreds
of VMN.  IF every change in point of attachment of such a large NEMO
must be accompanied with one BU per CN, we can expect 100 BUs after a
change in point of attachment.   Is that stormy?  Now add in the BAcks,
and perhaps even RR messages.  Is that stormy?

> not consider it as a problem, metaphorically speaking.

I suspect the differentiation of stormy and windy is itself subjective
enough.  Whats makes stormy stormy?  100 packets per sec?  A thousand
packets per second? Or a million?  It also depends on the scale of the
NEMO.   In the worst cases, we assume an entire mass transport vehicle
is the NEMO, and any breeze would scaled to a hurricane.

On the other hand, one can quantify the question of stormy/windy by
normalizing the number of signalling packets with the number of data
packets.  Then perhaps we can have scale invariance.  I think it make
sense to have the draft talk about all these issues.  Make sense?

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Oct 2004 18:26:20 +0200

>>is issued and the existing solutions are analysed.

I can deduce you agree that the mobility transparency section is not needed?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Oct 2004 19:06:25 +0200

Chan-Wah Ng wrote:
> Not that I recall, but I remember the term triangular routing refers 
> to the sending of packets from FA to CN, and the return path of 
> CN->HA->FA (thus forming the triangle).  That is the time when the 
> issue of ingress filtering was not that obvious/significant.

Yes, MIP4 RFC3344 has Figure 1 that ressembles to a triangle, but the
RFC does not contain the string "triang".  I am looking for other early
definitions of "triangular routing" in an RFC or email discussions or
early Internet Drafts.

>> Wouldn't it be possible to have a sort of NEMO-RR after whose 
>> completion there's no encapsulating header, no routing header?  I 
>> bet this is part of the solution space to the problem you're trying
>>  to define.
> 
> overheads, a home-address destination option would also constitute as
>  an overhead.  I don't see how a NEMO-RO solution can hope to achieve
>  zero overhead, except perhaps using an entirely and drastically 
> different routing infrastructure.

I agree with the DO containing the HoA means no zero-encapsulation and
overhead.  I don't see how a NEMO-RO solution can hope to achieve zero
overhead with existing routing infrastructure, but I see how a NEMO-RO
solution can achieve zero-overhead without the existing (and not any
other) infrastructure.  That is, if the aggregatation of moving networks
is disconnected from the infrastructure, then it is possible to have
that zero-overhead, no routing header, no DO.

> I remember coming across Motorola's solution of using multicast 
> addressing to achieve RO. That might be one approach to achieve zero
>  overhead ... or maybe not zero, but minimal, since some overheads 
> will be required to map that multicast address to the home-address of
>  the mobile node (VMN, LMN, or LFN).

Ah yes?

> Nope, but let's do a bit of thought experiment.  If you are looking 
> at the NEMO being a W-PAN or a car network, it might not even be 
> windy at all! Perhaps only a little breezy, so to speak. ;)

But the number of BU's depend not on the size of the moving network!
Let me however follow your thought experiment.

> However expand that little W-PAN or car network to a train with 
> hundreds of VMN.  IF every change in point of attachment of such a 
> large NEMO must be accompanied with one BU per CN, we can expect 100 
> BUs after a change in point of attachment.

Hundreds of VMN's in a train send zero BU's when the MR changes its
attachment point, no?  It's the MR that sends the unique BU no?

> It also depends on the scale of the NEMO.

The nunmber of BU's/second does not depend on the size of the moving
network, except certain assumptions.

If there were no NEMO-based MR, and if every MN in the train is
connecting to the successive AR's along the track, and if every MN is
having a continuous communication, then the number of BU's is exactly
the number of MN's, yes.  But if any of those 'if's is not then no storm.

And "stormy" to what?  Who is imposed a stress because of too many BU's?
  Let me write a different mail on that...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Oct 2004 19:23:55 +0200

draft:
> An intermediate MR would keep track of all the pending communications
>  between hosts in its subtree of Mobile Networks and their CNs, and a
>  binding message to each CN each time it changes its point of 
> attachment.
> 
> If this was done, then each CN, by receiving all the binding messages
>  and processing them recursively, could infer a partial topology of 
> the nested Mobile Network, sufficient to build a multi-hop routing 
> header for packets sent to nodes inside the nested Mobile Network.
> 
> However, this extension has a cost:
> 
> 1.  Binding Update storm
> 
> when one MR changes its point of attachment, it needs to send a BU to
> all the CNs of each node behind him. When the Mobile Network is
> nested, the number of nodes and relative CNs can be huge, leading to
> congestions and drops.

related, not relative (minor).

What is more precisely the network on which numerous BU's will act as a 
storm?  It is actually the segment between TLMR and the last common 
router on the path between the new AR and all CN's.  If you look 
closely, it is exactly the same common path that all packets (not only 
BU's to CN's) between all MNN's and their CN's will impose a stress.

Imagine a train with many people watching different videos over Internet 
approaching the new AR.  That new AR's upstream connection is relatively 
quiet (as preparing for a storm).  When that AR receives the train's 
TLMR suddenly all those BU/BAck's followed by application-level packets 
will storm that common segment.  However, the number of BU/BAck's is 
much smaller than the number of video-streaming packets.  The "storm" 
has a small BU/BAck component.  Eliminate that component and it's still 
"stormy".

This is to say I do not think a BU storm is an inconvenient of having MR 
send BU's on behalf of its MNN's, or LFN's.

And, if a MR-RO-for-LFN's BU's were stormy in the sense like that of 
RS's of hosts powering up on a common subnet, would an exponential 
backoff algorithm limiting and randomizing the order of sent BU's apply 
as a solution.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 05 Oct 2004 19:56:22 +0200

Hi Alex,

> has a small BU/BAck component.  Eliminate that component and it's still 

	I agree with you that, in the scenario you've pointed out, sending or
not sending those BUs really doesn't make any (appreciable) difference.
Nevertheless, if you think in a different scenario, like, for example,
the following, perhaps the effect of this signalling (i.e. BU) storm can
be significant:

	Imagine the same train with many people browsing the web (i.e. many
connections to many different CNs) approaching to a new AR. In this
scenario, we can think in having some parts of the train's route covered
only by some kind of 2.5/3G access technology (e.g. GPRS) in which the
bandwidth is a very scarce resource. Therefore, in this scenario, having
a signalling storm may be really suboptimal, leading to congestions and
drops.

	What do you think?

	Thanks a lot.

	Cheers,

	Carlos J.

-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Oct 2004 20:07:09 +0200

Carlos Jesús Bernardos Cano wrote:
>  not sending those BUs really doesn't make any (appreciable)
> difference. Nevertheless, if you think in a different scenario, like,
> for example, the following, perhaps the effect of this signalling
> (i.e. BU) storm can be significant:
> 
> scenario, we can think in having some parts of the train's route
> covered only by some kind of 2.5/3G access technology (e.g. GPRS) in
> which the bandwidth is a very scarce resource. Therefore, in this
> scenario, having a signalling storm may be really suboptimal, leading
> to congestions and drops.
> 
> What do you think?

Thanks for asking.

Saying 2.5/3G GPRS/UMTS leads to my oppinion that there is no BU at all,
so no 'storm'  because there is no change in IP address, neither the
MNN's neither the MR is changing its IP address.  This is the case with
various GPRS/UMTS I'm accustomed with.

GPRS/UMTS have indeed lower bandwidth than WLAN.

I was trying to say that "BU storm" is a very vague problem that does
not invite for a solution.

I was trying to say that BU storm is not a drawback of having MR do RO
on behalf of MNN's.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 05 Oct 2004 20:15:22 +0200

Hi Alex,

> various GPRS/UMTS I'm accustomed with.

	I was thinking in inter-technology handovers (e.g. WLAN-GPRS). The
train may obtain connectivity by any 802.11x (or maybe 802.16) access
technology while, for example , crossing cities and then it handovers to
GPRS. BTW, I'm not sure if this would be a realistic scenario, but it
could be.

	Of course, if the train is always connected to GPRS, there is no L3
handover at all.

> I was trying to say that BU storm is not a drawback of having MR do RO

	I agree. But I also think that it is worth to point the problem and try
to address it.

	Cheers,

	Carlos J.

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 06 Oct 2004 11:11:38 +0800

> I can deduce you agree that the mobility transparency section is not needed?
Partly.  To be specific, I agree change the mobility transparency
section to a section discussing the need for NEMO-aware nodes in a RO
solution.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 06 Oct 2004 15:16:57 +0800

> that zero-overhead, no routing header, no DO.
Ah, I see.  It means we use a different address space for NEMO-RO so
that these address are not routed using aggregation, but rely on the
mobile router running some kind of dynamic routing protocol.

However, I foresee other problems with this approach,  Off-hand, (1)
that will mean RO is achieved in a way that is totally incompatible with
NEMO-Basic, (2) imagine millions of mobile networks in the future, and
we just created another routing table explosion, etc.

> attachment point, no?  It's the MR that sends the unique BU no?

Depending on the RO-solution, it can be the VMNs sending the BU, or MR
sending the BU on behalf of VMNs.  Point is, there will be hundreds of
BU generated from the mobile network.
> the number of MN's, yes.  But if any of those 'if's is not then no storm.

You statement maybe correct, again it depends on the solution of
NEMO-RO.  That's why the draft as a problem analysis draft should
discuss it.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 06 Oct 2004 16:22:16 +0800

> related, not relative (minor).

OK.

Right.

> has a small BU/BAck component.  Eliminate that component and it's still 

What you've mentioned here is I believe what I discussed in the previous
mail about normalizing the signaling packets (BU/BA/RR) against the data
packets (video/audio packets, in this example).

The catch here is in quoting the video streaming example, the number of
data packets per second is huge, making the number of signalling packets
to be smaller in comparison.

However, if we used another example of web-browsing, or
instant-messaging, the number of data packets generated by the
application will be smaller per second. In this scenario, the sudden
surge of sending N * BU messages, where N = number of MNNs, may be
significant.

Having said that, one still have to relate back to the application and
user experience.  For web-browsing, or IM, the user would most likely be
quite tolerant of "random" (in the perspective of user) increased delay
caused by "BU Storm".  For video streaming, users will be irritated more
by sudden delays.

Sorry if I seems to be contradicting myself, but I just want to explore
the issue deeper.

> send BU's on behalf of its MNN's, or LFN's.

You might be surprised, but in fact, I tend to think the same way as you
do.   However, I also felt that it is necessary to include such
discussions in the draft.  It is yet to be decided whether BU storm is a
significant issue.  From my discussions above, I believe it is dependent
on the applications.  For an application that generates small number of
data packets per second, but cannot tolerate delays, BU storm may be an
important consideration.  One such application that comes to mind will
be VoIP.

> backoff algorithm limiting and randomizing the order of sent BU's apply 

True.  Shouldn't this be documented in the draft as well?

/rgds
/cwng

---

From: Christophe Janneteau <[email-masked]>
Date: Wed, 06 Oct 2004 10:21:47 +0200

Hi,

Sorry to jump in...

> [...]

Sorry to jump in...

IMHO, if the bandwith is limited (e.g . GPRS) is it also highly possible 
that the many user applications would not be able to survive (or with 
significant QoS degradation) the handover anyway....whether there is a 
"BU storm or not"....

>>I was trying to say that BU storm is not a drawback of having MR do RO

I agree. It seems to me that the BU storm looks like a nice theoritical 
issue, but may have little foundations in realistic deployements...
Indeed the MR-to-CN BUs for RO will increase as the number of CN 
increases, but the impact on the TLMR-AR link should not be too much an 
issue since realistic deployement should consider high bandwith TLMR-AR 
link in case of large nemo (with possibly large number of CNs)....just 
to be able to support the traffic from applications.

thoughts?

Christophe

CHristophe.

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 06 Oct 2004 16:26:56 +0800

Hello Carlos, 

> 	I agree. But I also think that it is worth to point the problem and try
I don't meant to troll, but I must say "me too!" to that last sentence
:)

/rgds
/cwng

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 06 Oct 2004 12:59:55 +0200

Hi Christophe,

> significant QoS degradation) the handover anyway....whether there is a 

	IMHO, it depends on the scenario. GPRS is only an example, and
'significant QoS degradation' depends also on the applications, the
specific service provided to the users by the network operator, etc. I
just wanted to point out that, IMHO, I agree that the "BU storm" is not
such a big problem, but it interesting enough to at least address it. 
> to be able to support the traffic from applications.

The TLMR-AR link would be likely wireless, so even it is well
provisioned, we couldn't expect higher bandwidths, so it is worth to
take into account also the performance improvement of the protocols in
terms of signalling overhead, IMHO.

	Kind regards,

	Carlos J.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2004 14:49:17 +0200

Chan-Wah Ng wrote:
>> I agree with the DO containing the HoA means no zero-encapsulation
>>  and overhead.  I don't see how a NEMO-RO solution can hope to 
>> achieve zero overhead with existing routing infrastructure, but I 
>> see how a NEMO-RO solution can achieve zero-overhead without the 
>> existing (and not any other) infrastructure.  That is, if the 
>> aggregatation of moving networks is disconnected from the 
>> infrastructure, then it is possible to have that zero-overhead, no
>>  routing header, no DO.
>> 

No, it means that when you have an aggregation of moving networks whose
TLMR is disconnected (no infrastructure), there should be a way to make
those networks talk to each other without RH's nor DO's.

> that will mean RO is achieved in a way that is totally incompatible 
> with NEMO-Basic,

Exactly, that solution should interoperate with NEMO basic, that's for
sure, although if off-hand it looks as if it doesn't.

> (2) imagine millions of mobile networks in the future, and we just 
> created another routing table explosion, etc.

As long as there's no infrastructure I can't quite imagine millions of
mobile networks.

>>> Nope, but let's do a bit of thought experiment.  If you are 
>>> looking at the NEMO being a W-PAN or a car network, it might not
>>>  even be windy at all! Perhaps only a little breezy, so to speak.
>>>  ;)
>> 
>> But the number of BU's depend not on the size of the moving 
>> network! Let me however follow your thought experiment.
>> 
>> 
>>> hundreds of VMN.  IF every change in point of attachment of such
>>>  a large NEMO must be accompanied with one BU per CN, we can 
>>> expect 100 BUs after a change in point of attachment.
>> 
> Depending on the RO-solution, it can be the VMNs sending the BU, or 
> MR sending the BU on behalf of VMNs.  Point is, there will be 
> hundreds of BU generated from the mobile network.

What's "hundreds of BU's" compared to "millions of UDP packets"?

>> connecting to the successive AR's along the track, and if every MN
>>  is having a continuous communication, then the number of BU's is 
>> exactly the number of MN's, yes.  But if any of those 'if's is not
>>  then no storm.
> 

YEs, depends on the solution.  A problem statement draft for route
optimization should discuss it and look in a non-biased way at various
approaches to solve this problem...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2004 14:55:14 +0200

Carlos Jesús Bernardos Cano wrote:
> I agree. But I also think that it is worth to point the problem and 
> try to address it.

YEs, absolutely.  But there are ways and ways to describe problems.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2004 15:06:16 +0200

> surge of sending N * BU messages, where N = number of MNNs, may be 

I'd think that a real BU storm when train changes AR can only apppear if
all passengers click Reload simultaneously and at the exact moment of
changing AR...

> Having said that, one still have to relate back to the application 
> and user experience.  For web-browsing, or IM, the user would most 
> likely be quite tolerant of "random" (in the perspective of user) 
> increased delay caused by "BU Storm".  For video streaming, users 
> will be irritated more by sudden delays.

Yes.

> Sorry if I seems to be contradicting myself, but I just want to 
> explore the issue deeper.

It's just a discussion, I experience that too.

>> This is to say I do not think a BU storm is an inconvenient of 
>> having MR send BU's on behalf of its MNN's, or LFN's.
> 
> You might be surprised, but in fact, I tend to think the same way as
>  you do.   However, I also felt that it is necessary to include such
>  discussions in the draft.

That's the prerequisite for having a WG item IMHO.

>> And, if a MR-RO-for-LFN's BU's were stormy in the sense like that 
>> of RS's of hosts powering up on a common subnet, would an 
>> exponential backoff algorithm limiting and randomizing the order of
>>  sent BU's apply as a solution.
> 

Which draft?

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 06 Oct 2004 15:43:20 +0200

Hi Alex,

	I don't want to be a pain ;->, I'll try to make this my last comment on
this issue...

> all passengers click Reload simultaneously and at the exact moment of

	Well, not at the exact moment... Binding cache entries have a lifetime,
so it is not needed to click the reload button exactly at the moment of
the handover is taking place, is it?

	Kind Regards,

	Carlos J.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2004 15:50:06 +0200

Carlos Jesús Bernardos Cano wrote:
> I don't want to be a pain ;->, I'll try to make this my last comment
> on this issue...

Not at all a pain!  Am I a pain?  The pain is when we loose track, I
think; the problem should be defined.

>>> application will be smaller per second. In this scenario, the
>>> sudden surge of sending N * BU messages, where N = number of
>>> MNNs, may be significant.
>> 
>> I'd think that a real BU storm when train changes AR can only
>> apppear if all passengers click Reload simultaneously and at the
>> exact moment of changing AR...
> 
> Well, not at the exact moment... Binding cache entries have a
> lifetime, so it is not needed to click the reload button exactly at
> the moment of the handover is taking place, is it?

Ok, so BC entries have lifetimes, and when they're renewed BU's are
sent.  The lifetime fields in the BC have various values, rarely
identical, so no simultaneous BU's sent, no storm, no?

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 06 Oct 2004 16:40:22 +0200

Hi Alex,

> think; the problem should be defined.

	OK, then I'll make one more comment ;->

> identical, so no simultaneous BU's sent, no storm, no?

	Yes, when the NEMO is not moving, the entries in the BC will likely
have different values. But, when the MR moves, it should send BUs to all
the CNs, shouldn't it? So some sort-of BU storm happens, IMHO.

	Kind regards,

	Carlos J.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2004 17:12:08 +0200

Carlos Jesús Bernardos Cano wrote:
>>>>> instant-messaging, the number of data packets generated by 
>>>>> the application will be smaller per second. In this scenario,
>>>>>  the sudden surge of sending N * BU messages, where N =
>>>>> number of MNNs, may be significant.
>>>> 
>>>> apppear if all passengers click Reload simultaneously and at 
>>>> the exact moment of changing AR...
>>> 
>>> lifetime, so it is not needed to click the reload button exactly 
>>> at the moment of the handover is taking place, is it?
>> 
> have different values. But, when the MR moves, it should send BUs to 
> all the CNs, shouldn't it? So some sort-of BU storm happens, IMHO.

Exactly.

So in order to avoid the "sort-of BU storm" let's use rate limitation.
Hopefully MR will act like an RFC3775 MN: "The mobile node is
responsible for retransmissions and rate limiting in the return
routability procedure, registrations, and in solicited prefix discovery."

If we say, like the taxonomy draft says, that because MR sends BU to 
CN's then BU storms appear, the immediate thought is to think "don't let 
MR send BU's to CN's".

If we say, however, that an MR not using rate limiting may provoke BU 
storms (easier than MH would provoke), then the immediate thought is to 
think "use rate limiting".

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 06 Oct 2004 17:56:49 +0200

Hi Alex,

> CN's then BU storms appear, the immediate thought is to think "don't let 

	I completely agree

> think "use rate limiting".

	I agree again ;->

	Kind Regards,

	Carlos J.

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 07 Oct 2004 10:32:34 +0800

> those networks talk to each other without RH's nor DO's.

Okay, I see.  Isn't that threading a bit too close to MANET?

> approaches to solve this problem...

Agree whole-heartedly.  It is my intent to address the concern of the
draft being too, should I say, solution-specific.

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 7 Oct 2004 16:39:42 +0900

> > overheads, a home-address destination option would also constitute as

Here are a few comments on this thread.

> that zero-overhead, no routing header, no DO.

I would propose to use the terms:

- "Packet Overhead" instead of "Encapsulation" (which is a kind of
packet overhead). 

- And, instead of Zero Overhead, we should speak about "Minimal
Overhead".

In this thread, do we speak about requirements, or metrics to evaluate
the solutions ? BTW, "Minimal Overhead" is already listed in the
requirement draft.

> Let me however follow your thought experiment.

The number of BUs depends on the number of recipients (# HAs ? # CRs ? #
CNs ? : how to qualify the recipient depends on the solution's
internals).

Note that I can do a video-conference from a car, or have a web server
on a car, so there is no need for a "big network" for a huge number of
CNs. Size of the network and #CNs are orthogonal. We already said that
on this list tens of times.

> attachment point, no?  It's the MR that sends the unique BU no?

That depends on the solutions. Some solution may propose that the MNNs
send BUs (I think this is a bad idea because it doesn't scale, but bad
ideas don't prevent people to propose such solutions).

>   Let me write a different mail on that...

This may depend on the type of link. If it's a cellular phone, that
could become stormy quickly.

> send BU's on behalf of its MNN's, or LFN's.

What about the multihoming context ? The video may be received by the
satellite (unidirectional link), but you use the cellular phone to send
BU/ack. If all the 800 people do that in the train, that is a problem.

I just wanted to point out that we shouldn't eliminate this issue of our
minds (it's not such a theoritical issue as pointed out by Christophe
and Alex (BTW, hi to both of you;-). And I agree with Carlos that it
worth to keep an eye on improving the bandwidth by decreasing the
signaling, whatever ratio of available bandwidth vs cost of signaling (I
think you sort of meant that ?)

So, we have to be careful at the same time about the so-many possilble
configurations of the mobile networks, how it is connected to the
Internet, and the type of applications running on top of that
connections.

> >  the mobile node (VMN, LMN, or LFN).

I did suggest this multicast idea, one old paper is available on my web
page, and the complete simulation results are in my PhD dissertation.
The reason why I suggested the use of multicast was not to limit packet
overhead, but to avoid the BU storm (I called that BU explosion),
particularly on the first hops between the MR and the CNs (of course,
building multicast trees is also expensive in terms of signaling, unless
you use XCAST, but then you cannot accomodate millions of CNs).

> sure, although if off-hand it looks as if it doesn't.

It doesn't have too. It is desirable. That's another metric to qualify
the solutions. If there is no good solution that is compatible with NEMO
Basic Support, we should definitely consider something not compatible.
 
> As long as there's no infrastructure I can't quite imagine millions of

I can.
There is a big earthquake in Tokyo (we just had one yesterday: 5,8), the
infrastructure is destroyed, each person (=1 PAN x few millions of
equipped people) and each car (=1 in-vehicle network) are self-organizing.

But this also looks like ad-hoc networks, so I don't like very much when
we mention "no infrastructure" in this thread. Please define what's the intend.

In summary, I think a problem statement draft should speak about the
problem, the issues (with no solution in mind, which is hard to achieve)
and propose some metrics to evaluate all the solutions. This list of
metrics could/should include, but is not limited to:
- packet overhead
- signaling overhead
- delay
- amount of state
- etc

Then, we could see which solutions could qualify or not according to:
- minimal overhead
- minimal signaling
- minimal delay
- mininum state at routers/dedicated servers
- level of compatibility with NEMO Basic support
- scalability
- etc.

Thierry.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Oct 2004 17:04:51 +0200

Chan-Wah Ng wrote:
>>>> I agree with the DO containing the HoA means no 
>>>> zero-encapsulation and overhead.  I don't see how a NEMO-RO 
>>>> solution can hope to achieve zero overhead with existing 
>>>> routing infrastructure, but I see how a NEMO-RO solution can 
>>>> achieve zero-overhead without the existing (and not any other) 
>>>> infrastructure.  That is, if the aggregatation of moving 
>>>> networks is disconnected from the infrastructure, then it is 
>>>> possible to have that zero-overhead, no routing header, no DO.
>>> 
>>> Ah, I see.  It means we use a different address space for NEMO-RO
>>>  so that these address are not routed using aggregation, but rely
>>>  on the mobile router running some kind of dynamic routing 
>>> protocol.
>> 
>> No, it means that when you have an aggregation of moving networks 
>> whose TLMR is disconnected (no infrastructure), there should be a 
>> way to make those networks talk to each other without RH's nor 
>> DO's.
> 

Were it so I'd have posted to the MANET WG.

Two moving networks with MR1 and MR2.  MR1, MR2 and LFN do not use OSPF.
  MR1 nested within MR2.  LFN's need to communicate, without TLMR
connected to AR.  The problem is they can't.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Oct 2004 17:09:08 +0200

> problem, the issues (with no solution in mind, which is hard to

Hard to achieve, but not impossible.  Sometimes it is sufficient to just 
say "a form of Routing Header" instead of saying RRH.

Alex