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

Hi Roland and Jukka,

This seems like some interesting discussion that should be used to
update the MIP operation part in the draft.

Based on the description, I don't think a NOTIFY from MN is necessary
when the other end (CN or HA) is a QNE.

When MN is the Data Sender, it should work this way:
- MN changes its IP addr, e.g. obtain a new-CoA;
- MN sends a QUERY(RESERVE-INIT)towards the CN/HA with the new MRI (if
it's QNR); or
- MN sends a RESERVE towards the CN with the new MRI (if it's QNI)

When MN is the Data Receiver, and the CN/HA is a QNE, it should work
this way:
- MN changes its IP addr, e.g. obtain a new-CoA;
- MN does Mobility Management signaling to inform CN/HA of new-CoA
(otherwise data path would not change, remember CN/HA is the data sender);
- CN/HA is triggered by GIST to send QUERY towards MN using new MRI;
- MN sends RESPONSE (if it's QNR) or RESERVE (if it's QNI); and
- CN/HA sends RESERVE if it is QNI.
In the above step 3, CN/HA sends QUERY instead of RESERVE directly(if
CN/HA is QNI) because the path condition may change as MN changes
location (as indicated in your earlier email, WiFi and WiMAX may
provides different throughput). However, if time is a concern, CN/HA can
always use back the old QSPEC for a direct RESERVE first.

The situation will become a bit more interesting when the CN/HA is not
QNE. In this case, how the MN does the update worth some discussion.

If MN is the Data Sender, same operation as above should be able to work.

If MN is the Data Receiver, there are problems in signaling as indicated
in Roland's email, especially when we assume the routing is asymmetric.
There are two possible ways:
- If MN knows the QNI/QNR addr, it can send a NOTIFY/QUERY directly to
it. However, in the current QoS NSLP spec, there is no way for the MN to
know that info. Should we fix this, e.g. as a special mobility/proxy
INFO-Element?
- Get some help from the CN/HA (the data sender). Possibly to
encapsulate the NOTIFY to CN/HA, and get them to send it via Data Path.
This is like sending a special PING to the CN/HA.

What do you think?

cheers

Cheng Hong





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.
> 
>> 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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
>