Subject: RE: [nemo] RO taxonomy

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 1 Nov 2004 18:35:06 +0100

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: vendredi 29 octobre 2004 19:08
> To: Pascal Thubert (pthubert)
> Cc: IETF NEMO WG; marcelo bagnulo braun; Carlos Jesús Bernardos Cano; Chan-Wah NG
> Subject: Re: [nemo] RO taxonomy
> 
> Pascal Thubert (pthubert) wrote:
> 
> 
> >    5.  Obsolete BU
> >
> >        If the Binding messages are sent asynchronously by each MR, then,
> >        when the relative position of MRs and/or the TLMR point of
> >        attachment change rapidly, the image of Mobile Network that the
> >        CN maintains is highly unstable.  If only one BU in the chain is
> >        obsolete due to the movement of an intermediate MR, the
> >        connectivity may be lost.
> 
> It also isn't clear to me how such an approach would work when multiple
> MRs move at the same time. With a tree of AR->MR1->MR2->MNN,
> if MR1 changes AR at the same time as MR2 changes from MR1, wouldn't the
> fact that each "layer" tries to independently signal the CN make things
> very flaky; some part of one layers 6 packet BU exchange with the CN
> might be lost due to the layers above also moving.
> 
> >    A conclusion is that the path information must be somehow aggregated
> >    to provide the CN with consistent snapshots of the full path across
> >    the Mobile Network.  This can be achieved by an IPv6 form of loose
> >    source / record route header, that we introduce here as a Reverse
> >    Routing Header
> 
> Another possible way, in the case when the CN is modified, would be to
> have the MNN learn the list of CoA from announcements (e.g. in RAs) from
> the chain of MRs above it.
> That way the MNN can reliably learn the list, and then the MNN can pass
> the list to the CN in a BU.

Right. Actually that way has been proposed in a draft as an improvement to the RRH. A lot happened on the side of the mainstream in the last 2 years :) After discussion in this ML, the result of the change seemed quite identical to the original RRH in terms of security, though a tiny bit more complex with a bit more latency. So the RRH process was not modified. 

Note that the draft still mentions MRHA only and was not extended to CN, though it's pretty straightforward... waiting for WG attention, when we are ready for it as a group :)

> 
> But I think the case when the CN isn't modified is about as easy; the
> MNN would instead of sending a BU to the CN with the list, it will send
> a BU to the CN which points at the top MR's COLA, and a BU to that MR
> which points it at the CoA of the next MR in the tree, etc.
> Thus the MNN learns the path of MRs the packets need to traverse and
> creates bindings in each MR indicating the next hop.
> (MNN->CN path and HAO left as an exercise for the reader :-)
> 

Or all the MRs could register to the root, and we are back to the LMM story.  

Pascal