Re: Re: [NSIS Mobility draft] Updating from -07 to -08

Hi,

Me and Nuutti Varis, our GIST expert, had a chat yesterday and we tried to 
figure out what could be a good option. I think the problem lies 
elsewhere, it is not a (QoS) NSLP problem.

When the IP address does not change (with MIP the e2e BU solves the 
problem), the point is that even if we would be able to send a message 
upstream, we still need the routing towards the MN to be in place. There 
must be some routing protocol in place that sets up e.g. a new host route 
to the MN when it has moved. This protocol must be coupled with GIST, 
i.e., GIST must be able to get a notification from a routing change. This 
would be a cross-over router having the MN state. Once the node gets a 
hint that the next peer for a MN has changed, it can reissue a RESERVE 
towards the new path.

Thus, I would say that we should not invent an NSLP solution to a mobility 
management protocol issue. We just need to note that GIST must be able to 
see when routes change, to set up the new route on the downstream.

rgs,
Jukka

On Fri, 7 Dec 2007, Roland Bless wrote:

> Hi Jukka,
> 
> see comment inline.
> 
> Jukka MJ Manner wrote:
> > On Thu, 15 Nov 2007, Roland Bless wrote:
> > 
> >> Hi Jukka,
> >>
> >> [I'm taking this to the list now...]
> >>
> >> Jukka MJ Manner wrote:
> >>> I think we are talking about the same thing. The main point is that if IP 
> >>> addresses change, the MRI is invalidated, and the QNI must then, in one 
> >>> way or another be notified. There must be (otherwise nothing works) some 
> >>> mobility signaling where the QNI gets to know the new IP of the MN, and 
> >>> can then reissue a RESERVE with a new MRI.
> >> Ok, however, I believe that your proposed solution doesn't work:
> >> you proposed to send a NOTIFY towards the CN. This will require usage
> >> of the new flow's MRI and the resulting GIST Query must be sent in
> >> _upstream_ direction, i.e., PC-MRI(CN->MN-newCoA, D-Flag=1) - upstream.
> >> Now there is the problem of choosing the correct encapsulation for the
> >> Query: only _upstream_ Q-mode encapsulation would be an option, but this
> >> is not appropriate to use in this case due to its limited applicability
> >> to certain environments. Even if the MN could send the NOTIFY to its
> >> new access router (QNE4 below), there is no routing state installed yet
> >> in upstream direction in QNE4, i.e., it doesn't know any next peer
> >> in upstream direction, so only upstream Q-mode could be used, but that
> >> is not really applicable in this case. So only the last paragraph of
> >> section 4.3.3 applies:
> >>    o  If no routing state exists, GIST can attempt to use Q-mode as in
> >>       the Query case: either sending a Data message with the Q-mode
> >>       encapsulation, or using the event as a trigger for routing state
> >>       setup (see Section 4.4).  If this is not possible, e.g. because
> >>       the encapsulation for the MRM is only defined for one message
> >>       direction, then this is an error condition which is reported back
> >>       to the local signalling application.
> >>
> >> So an error will be reported back to the application.
> >> As a conclusion: sending a NOTIFY in upstream direction does not
> >> work along paths that have no routing state yet.
> > 
> > 
> > [JM]: If the CN requests reliable or secure transport, GIST will send an 
> 
> I don't know what it has to do with reliable and secure transport?
> 
> > empty Query to the next, set up routing state, and only then send the 
> > NOTIFY. This will hit QNE4. Now QNE4 does not know about the SID in 
> > question, so should it send an error back, or forward the message in the 
> > same way towards the CN? 
> 
> Please read the above text again. The problem lies in the fact that
> you have to send a GIST-Query _upstream_ and no routing state exists
> yet. So even if an MA exists, it cannot be used.
> This could only be done with _upstream_ Q-mode encapsulation, but this
> is definitely not applicable in a general way.
> 
> > [JM]: Yet, also with unreliable/unsecure transport, what would happen, if 
> > QNE4 would actually decide not to peer? It sees a NOTIFY for a SID it 
> > doesn't know about, so it could as well forward the message further, 
> > right? The message will eventually hit a QNE (or eventually the CN), who 
> > then knows about the SID.
> 
> See above. The GIST Query has to find its way first. This is the real
> problem.
> 
> Regards,
>  Roland
>