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

Hi Roland,

Thanks for the more comprehensive analysis. I agree with your points.
However, I think the described procedure somehow assumes that the CN is
a QNE. In case the CN is not the QNI/QNR, there might need to have
further improvement (as mentioned in my early mail). I think this should
also be mentioned in the draft, as NSIS allows this case.

Please find some other comments inline below:

cheers

Cheng Hong


Roland Bless wrote:
> Hi Hong, Takako and all,
> 
> we were writing up another e-mail, but I guess your analysis is
> mostly correct. I'll try to summarize our (Martin and I) comments
> as follows:
> 
> We (Martin an I) have some major comments about the draft and are
> willing to contribute to it.
> First, we find that we basically should distinguish four cases:
> 1.) MN is sender, sender-initiated reservation
> 2.) MN is sender, receiver-initiated reservation
> 3.) MN is receiver, sender-initiated reservation
> 4.) MN is receiver, receiver-initiated reservation
> 
> It seems that only case 1.) is currently discussed in section 4
> and we think it would be good to systematically discuss
> the other cases, too.

[HCheng] Agree. I think the current draft needs to be cleaned up. Your
suggestion sounds quite reasonable.

> In case that MobileIPv6 is used it boils down to
> the following cases as Hong described already. We assume
> that the MN changes its address and the we distinguish
> two flows:
> cases 1.)+2.) (MN-Sender)   f_o: old-CoA -> CN, f_n: new-CoA -> CN
> cases 3.)+4.) (MN-Receiver) f_o: CN -> old-CoA, f_n: CN -> new-CoA
> 
> Case
> 1.)
> - MN changes its IP address, obtains new-CoA
> - QoS NSLP must become aware of the handover, so that the
> - MN simply initiates a new RESERVE for the new flow f_n
> 
> 2.)
> - MN changes its IP address, obtains new-CoA
> - QoS NSLP must become aware of the handover, so that the
> - MN initiates a new QUERY(RESERVE-INIT) for the new flow f_n
> 
> 3.)
> - MN changes its IP address, obtains new-CoA
> - MN performs mobility management signaling, i.e. binding update
>   to the CN.
> - CN becomes aware of the handover (this is the important part)
>   so that the NSLP can initiate a new RESERVE.
> 4.)
> - MN changes its IP address, obtains new-CoA
> - MN performs mobility management signaling, i.e. binding update
>   to the CN.
> - CN gets aware of the handover, NSLP sends a new
>   QUERY
> 
> The important part for all four cases is that
> the QoS NSLP becomes aware of the handover. There
> are several possibilities for the trigger, but I
> think we should use a new GIST API primitive for
> the notification (but probably as mobility extension
> of GIST not within the current proposed draft).
> You wrote that GIST will trigger the NSLP,
> but I don't think that there is currently such
> a possibility:
> new binding update actually changes an existing flow
> f_o into the new f_n. So the only existing primitive
> would be to indicate
> NetworkNotification(QoS-NSLP, MRI(f_o), Routing-Status-Change=Bad)
> for the old flow. But we need to get the new MRI
> in order to send the NSLP message. One problem is that
> GIST doesn't have any state for the new flow f_n.
> So I would propose to have a new NetworkNotificationType,
> like MRI change:
> NetworkNotification(QoS-NSLP, MRI(f_o), MRI(f_n))

[HCheng] This sounds reasonable. I agree that we should make this an
mobility extension of the GIST, as it only needs to be supported by some
specific nodes, e.g. MN or CN.

> The problem is, however, that an updated IP address
> (due to mobility management) may affect several GIST
> flows.

[HCheng] Does this mean this specific API should support a wildcarded
NSLP ID? On a MN, the change of MRI should affect all the NSLP. On the
CN, only the NSLP having a session with MN should be affected. Should
GIST differentiate this?

> 
> An alternative would be a trigger caused by the
> application itself, e.g., due to application level
> signaling. It would be similar to the fact that
> we need such a trigger anyway for receiver-initiated
> reservations in order to let the sender issue an initial
> Query. I guess we need to support both possibilities
> for cross layer info.

[HCheng] I guess the application layer trigger is a separate issue
instead of an alternative, as not all application supports IP address
changes. This may also relates to some earlier discussion of Appl-NSLP
interface.


> Concerning your mentioned option of directly sending
> a NOTIFY to the other end: that's also an alternative
> that I discussed with Martin. Our proposed EST-MRM
> would probably enable a node to do so, i.e., a NOTIFY
> indicating a handover event could be sent directly
> to the other end.

[HCheng] The EST-MRM seems quite useful in this case. Another way is to
simply define a flag such that the message could be routed directly.

However, I guess the main issue of concern is how to find/locate where
the message should be sent, assuming asymmetric routing.

> Now for some further comments to the draft:
> 
> Further comments on section 4.2:
> I propose to change the name of "State Update"
> at least to "Localized State Update", because
> my intuitive understanding of State Update is
> that is denotes the process to update the flow's state
> along the whole path.
> 
> With respect to section 4.2.1 we want to remark that
> usually the main difference between mobility/handover
> scenarios and re-routing as describe in appendix A is:
> in the basic mobility scenario the MRI changes: the
> MN gets a new care-of-address and thus we have a new flow
> (we denote this as f_n). In contrast to this, a re-routing
> by route changes will usually not lead to a change of
> the MRI. So normally only the CRN can determine at
> NSLP level that a handover happened by detecting two
> different MRIs (f_o=old flow and f_n=new flow) belonging
> to the same SID. GIST does not really care about the SID,
> so this relation must be handled at the NSLP
> level.

[HCheng] Agree. Although GIST should have adequate information to handle
it, I don't think it cares (or should care about this).

> Furthermore, I would propose to rephrase the last
> paragraph of section 4.2.3 as QoS NSLP does not allow
> to sent RESERVEs towards the QNI. Thus, there is no
> option to do it differently.
> 
> Best regards,
>  Roland and Martin
> 
> Hong Cheng wrote:
>> 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?
>>
>>
>> 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.
> 
>