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

[Takako Sanda <[e-mail]>]

Hi Roland,

Thank you for the useful comments.

As you say, it will be good to describe all of four cases in the draft:
 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

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
Roland Bless <[e-mail]> 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.
> 
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis




_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis