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

Hi Hong,

Hong Cheng wrote:
> 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.

Yes, that was what you described, I guess that you are referring to the
Proxy Mode of QoS NSLP.

> [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?

I guess that will affect all flows whose MRI is touched and
that are managed by GIST. If an address change is signalled to
GIST internally (e.g., triggered by MobileIP implementation),
GIST must iterate through its message routing state tabled look
for the changed address. If found, it will issue an API indication
for the change, no matter what NSLP is affected.

>> 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.

Sure, not every application will be able or willing
to deal with that.

>> 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.

If the message must only hit the other end, actually
you don't care about the fact how the message came there.
Specifically, you want to avoid setting up GIST state along
the "wrong path" that is going to time out anyway...

>> (Handover should be managed at NSLP level)
> [HCheng] Agree. Although GIST should have adequate information to handle
> it, I don't think it cares (or should care about this).

I guess that -- following along the end-to-end argument -- the
NSLP has more accurate information on what to do or may apply
its on logic. It would be hard to get it right at the GIST level
for any application...

Regards,
 Roland