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

[Roland Bless <bless at tm.uka.de>]

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.

> The asymmetric paths is a real problem, especially if the MN switches e.g. 
> interface technologies, goes from WLAN to WiMAX, and changes operators at 
> the same time. In that case the QUERY will hit some node, the QNI at the 
> latest, which can then send the RESERVE towards the new location of the 
> MN.

We will come back later with more detailed comments about the mobility
scenarios.

Regards,
 Roland & Martin (Roehricht)

> 
> Jukka
> 
> On Fri, 9 Nov 2007, Roland Bless wrote:
> 
>> Hi Jukka,
>>
>> see comments below.
>>
>> Jukka MJ Manner wrote:
>>>> <snip>
>>>>> [MN]   [QNE1] --- [QNE2] ---\
>>>>>  |                           \
>>>>>  |                           [QNE3] --- [QNE6] --- [QNE7] ---
>>>>>  |                           /
>>>>>  V                          /
>>>>> [MN]   [QNE4] --- [QNE5]---/
>>>>>
>>>> <snip>
>>>>> - MN moves, gets a hint from GIST that routing has changed
>>>>> - MN sends a NOTIFY towards QNI saying "Route Change" 0x02
>>>>> - QNE4 will receive it, and forward it, same with QNE5
>>>>> - The NOTIFY will hit QNE3, which notes that the message for a known 
>>>>>  session comes from a new SII-Handle.
>>>>> - QNE3 should then send a full RESERVE with a new RSN and an RII to 
>>>>>  QNE5
>>>>> - QNE4 will receive the RESERVE, make the reservation, and forward it
>>>>> to the MN
>>>>> - The MN gets the RESERVE and replies with a RESPONSE
>>>> - In order to send NSIS message hop by hop for upstream direction (MN->
>>>> QNE4->...->QNE7... in the figure below), GIST state need to be
>>>> established in advance, and this GIST state is established for
>>>> downstream direction (e.g., QNE3 aware of route change and perform route
>>>> change process towards MN in the new location). But if this is possible,
>>>> I guess "make it faster" operation (operation above) does not make sense,
>>>> because QNE3 (CRN) will able to do new reservation and teardown without
>>>> receiving NOTIFY from MN.
>>>> - How MRI update can be done in this case?
>>>
>>> In order for the MN to send the NOTIFY, each GIST hop will need to set up 
>>> state upstream. This state establishment will result in a QUERY hitting 
>>> QNE3, which will decide to peer. The SID is known, thus, the QNE3 will 
>>> consider this a re-routing event, and perform the signaling as above. This 
>>> should work? QNE3 will not know about the re-routing until QNE1 figures 
>>> out the MN has disappeared, and QNE1 starts tearing down the reservation.
>> Sorry, but I don't get the point here and I doubt that its working
>> correctly. what is the exact scenario?
>>
>> - MN is QNR and data receiver?
>> - Reservation is sender-initiated?
>> - MN uses Mobile IP?
>>
>> I see the different cases now:
>> a) MN gets a new IP address and default route
>> b) MN performs mobility management signaling (Bindung Update)
>>
>> Is it that GIST will already detect a route change by a)
>> or will the route be changed by b)?
>>
>> With the current proposal I have the following issues:
>> * In case of a) it may be the case that QNE3 is not even hit by a Query
>>   sent upstream due to asymmetric paths.
>> * The MRI must get updated along the whole path, especially for
>>   profile update in the first hop router at the QNI.
>> * QNE3 tries to automatically reserve resources as they were before the
>>   handover. This is especially inappropriate in case of vertical
>>   handovers when the QSPEC should be changed. Therefore it would be good
>>   that the QNI is involved in re-issuing a RESERVE.


_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis