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

From: Roland Bless <[email-masked]>
Date: Thu, 15 Nov 2007 14:44:38 +0100

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

---

From: Hong Cheng <[email-masked]>
Date: Fri, 16 Nov 2007 10:51:27 +0800

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 16 Nov 2007 11:55:34 +0100

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.

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))
The problem is, however, that an updated IP address
(due to mobility management) may affect several GIST
flows.

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.

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.

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.

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

---

From: Takako Sanda <[email-masked]>
Date: Mon, 19 Nov 2007 11:23:39 +0900

Hi Roland,

Thank you for the useful comments.

As you say, it will be good to describe all of four cases in the draft:

But as submission deadline is today, I do not think we can write these
scenarios in -08. Therefore, I will only adopt all of your other
comments for -08, and add other scenarios for -09 soon after coming IETF
meeting.

Is this fine?

cheers,
Takako

On Fri, 16 Nov 2007 11:55:34 +0100

---

From: Hong Cheng <[email-masked]>
Date: Mon, 19 Nov 2007 14:09:40 +0800

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

> and we think it would be good to systematically discuss

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

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

> (due to mobility management) may affect several GIST

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

> Query. I guess we need to support both possibilities

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

> indicating a handover event could be sent directly

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

> so this relation must be handled at the NSLP

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

---

From: Roland Bless <[email-masked]>
Date: Mon, 19 Nov 2007 09:24:36 +0100

Hi Takako,

> comments for -08, and add other scenarios for -09 soon after coming IETF

Sure, this is fine for me.
Unfortunately, we cannot discuss further things personally
in Vancouver, since I cannot attend the IETF meeting this time.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Tue, 20 Nov 2007 15:13:43 +0100

Hi Hong,

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

> CN, only the NSLP having a session with MN should be affected. Should

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.

> changes. This may also relates to some earlier discussion of Appl-NSLP

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

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

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 20 Nov 2007 22:26:06 +0200 (EET)

Just as a quick note, I need more time (and a lot of paper, and good pens) 
to figure out all your discussions, and the implications. I'll get back to 
you on that later.

Jukka