Subject: RE: [nemo] Re: BU storms when MR does RO on behalf of LFN's (was: Re: more comments on the RO Taxonomy draft)

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 6 Oct 2004 15:12:56 +0200

Salut Christophe :)

> Some comments on your email below.
> 
> Pascal Thubert (pthubert) wrote:
> > Let's take examples
> > -------------------
> >
> > Case 1: MR joins a tree.
> >
> > Say a MR with an LFN attaches into an existing tree at depth 3. so
we
> > have:
> > Root-MR <- MR1 <- MR2 <- MR . Say LFN starts a connection with CN,
and
> > say we want to optimize that.
> >
> > With the assumptions in the quoted text, our MR has to bind its MNP
to
> > the CN with its careof. But CN does not know how to reach that
careof,
> > which is from MNP2 (MR2's MNP). So MR2 has to bind MNP2 with its
careof
> > with CN. Recursively, MR1 and root-MR have to bind to CN as well.
> > So we need 4 bindings, which have to be synchronized while
maintained
> > individually.
> 
> Right. But note that the applications are still maintained even if the
> full path for RO is not known at CN (e.g. binding for MR2 missing),
and
> the path would still be partially optimized.
True for an initial binding.
Now if there's a movement and the CN has an old state for one hop, then
the traffic could be disrupted.  

> 
> That said, there may be some ways to speed up and "synchronize" the
> sending of the bindings of nested MRs to CN, so that CN gets all of
them
> "at once".
Yes :) One way is to take a snapshot of the path on the way of the
packet.

> 
> > On the other hand, if you look at RRH, only the MR that moves sends
a
> > binding. The BU traces the way out. That's a single BU, with a
snapshot
> > of the tree at the time of the packet. No state in the intermediate
> > routers. No additional BUs that the CN has to correlate together.
> 
> RRH may have advantages, but also has drawbacks (e.g. significant
> departure from Basic-NEMO BU semantic, determining optimun number of
> slot in RRH header, security, etc...). BTW, It may be too early  now
to
> start comparing solutions, this may turn in an endless thread :)

Right. I used that as an example to explain clearly the difference of
approach. Specking in general terms is sometimes very opaque.

> When doing this exercise one should make sure that all the various
> criterias for comparison are taken into account. They also need to be
> defined first...
> 
cool

> >
> > Case 2: Root-MR now changes its point of attachment.
> >
> > With the assumptions in the quoted text, it has to send one BU to
all
> > CNs of all the LFNs in the tree. This causes a burst on the network.
> 
> But only Root-MR would sent BU, thus zero overhead is introduced
inside
> the aggregation while this would not be true with RRH. If RRH is to be
> used only in BU messages, then lower MRs in the aggregation need to
> discover Root-MR movement in order to send BU...thus extra signalling.
> In addition all MRs behind Root-MR will then need to send BUs to
update
> CNs with their optimized path, thus extra signalling.
> 
> If in-band RRH (i.e. in all data packets) is used then overhead of RRH
> header takes place for each packet?...
Actually, there are a number of possible optimizations. RRH does not
have to be added to all packets. The draft suggests a type 3 that's just
a home address in most packets.
In the case we discuss, since a movement is detected, then the RRH is
forced.

> [...]
> 
> > With RRH, MRs might delay the BU for a small amount of time in case
> > there's upstream traffic for that CN that would update the RRH cache
in
> > the CN in-band, avoiding many of the BUs.
> 
> Well, with MR-to-CN BU, only Root-MR would need to send the BU to the
> CNs, and of course could arrange not to send the simultaneously to
avoid
>    overhead on the TLMR-RA link...
> 
Right, there needs to be an additional complexity in the MR that moves
to pace down the flow of BUs in order not to clog itself even before it
clogs the link. But that's not the worst complexity. Figuring out which
are the CN is much harder, mostly if ESP is used. 

> >
> > Conclusion
> > ----------
> >
> > With the assumptions in the quoted text, for each (LFN, CN) that's
ROed
> > binding, each MR above the LFN in the nested structure needs to send
a
> > BU to all these CNs when it moves, so that a CN has the chain of BUs
> > that enables building a path down the tree.
> >
> > When a MR moves to a new place in the tree, it has to rebind for all
CNs
> > down its tree, as we said. But then all MRs above it have to do it
too.
> > And MRs up its previous location have to stop doing it, otherwise
the CN
> > is very confused.
> 
> No, I don't think CN will be confused if it still has bindings for the
> mobile routers up to MR's previous location. As soon as CN gets the
new
> MR's binding, it knows that the MR has moved to a new location. This
new
> location could match the prefix of a new upper mobile router. If CN
has
> a binding for this new upper-MR is will use it, and route packet along
> new-upper-MR CoA and MR CoA. Entries for old-upper-MR is not used and
> does not arm at all....
> 
If the CN only gets extra information that it does not need anymore,
that seems right :)
I'm afraid of corner cases when a single BU is missing. I do think that
the path should be traced in one message so 1) it's simple to parse and
2) it reflects a consistent snapshot of the tree at a given point of
time.

Pascal