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

Hi Roland, Hong, Takako,

What you are discussing is the case of MIP, and sure, here the binding 
update helps as the upstream trigger. But if we do not employ MIP? What 
about mobility within a local domain without MIP. In such a case, the MN 
IP will not change, but we need the upstream trigger to set up the 
signaling path efficiently. In that case, the upstream NOTIFY is our only 
help, I'd say.

(In this scenario, the IP address could actually change, too, and we use 
e.g. SIP to re-bind the session and data streams. This comes back to the 
MIP case, though - some e2e signaling exists to provide a new IP address 
of the MN, and this would be coupled somehow with the NSIS protos.)

rgs,
Jukka

On Fri, 16 Nov 2007, 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.
> 
> 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
> 
> 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.
>