Subject: RE: [NSIS] Re: Clarification: tearing down from intermediate node

From: "Cheng Hong" <[email-masked]>
Date: Mon, 22 Jan 2007 18:07:30 +0800

Hi Jukka,

> However... we may have potential problem in a certain case. 
> Say, MN is QNI, and sends a full RESERVE, which arrives 
> eventually at QNE3, the SII-Handle changes. QNE3 prepares to 
> change the session state and send a tear down to the old 
> SII-Handle. Now, at the same time, a refreshing (either 
> partial or full) RESERVE comes from the old SII-Handle. What 
> should QNE3 do now? It has received two RESERVEs from two 
> different SII-Handles, which is the right one? Which should 
> be torn down? (This is even more problematic, if the IP 
> address of the MN changed, so we two different MRIs)
> 
> Do we need some clear indication of what is a refreshing 
> RESERVE, and what is an full RESERVE sent in the initial 
> phase, and after a routing change?

Yes. That is the problem I am referring to. RSN does not proivde any
help in this case.

It would be even more complicated if MN experiences quick handovers
(ping-pong?). Reserve messages could arrive at QNE3 out of order. E.g.
MN moves to new location and sends a RESERVE, and handover back to the
old location and sends another RESERVE; the second RESERVE might reach
QNE3 earlier than the first. In this case, just distinguishing the
refresh or full RESERVE does not really help.

Cheers

Cheng Hong

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: Monday, January 22, 2007 5:36 PM
> To: Cheng Hong
> Cc: Roland Bless; [email-masked]; Takako Sanda
> Subject: Re: [NSIS] Re: Clarification: tearing down from 
> intermediate node
> 
> 
> Hi,
> 
> AFAICT, QNE3 uses the same RSN for the next peer towards the 
> MN, regardless of the actual next peer. If the peer changes, 
> the RSN doesn't matter.
> 
> Now,
> 
> 1. if MN is QNI, then after handover, the GIST SII-Handle 
> will change, 
>    which is an indication that the state has changed, and 
> thus the RSN is 
>    in a way re-set. The RSN is not meaningfull here.
> 
> 2. If MN is QNR, after handover, the next peer changes, and 
> QNE3 is in 
>    charge of using the right RSN.
> 
> I don't see any problems here.
> 
> 
> However... we may have potential problem in a certain case. 
> Say, MN is QNI, and sends a full RESERVE, which arrives 
> eventually at QNE3, the SII-Handle changes. QNE3 prepares to 
> change the session state and send a tear down to the old 
> SII-Handle. Now, at the same time, a refreshing (either 
> partial or full) RESERVE comes from the old SII-Handle. What 
> should QNE3 do now? It has received two RESERVEs from two 
> different SII-Handles, which is the right one? Which should 
> be torn down? (This is even more problematic, if the IP 
> address of the MN changed, so we two different MRIs)
> 
> Do we need some clear indication of what is a refreshing 
> RESERVE, and what is an full RESERVE sent in the initial 
> phase, and after a routing change?
> 
> Jukka
> 
> On Mon, 22 Jan 2007, Hong Cheng wrote:
> 
> > Hi Jukka,
> > 
> > The RSN is meant for adjacent QNEs only. It cannot be used for 
> > message/state management if the peer(/SII) is different. 
> However, in 
> > mobility event handling, sometimes an e2e type of sequence number 
> > comes in handy, e.g. to detect the latest mobility event 
> (as discussed 
> > in Mobility Applicability draft).
> > 
> > I guess some of the confusion came from the tricks 
> introduced in QoS 
> > NSLP draft section 3.2.10.2. It works fine with that particular 
> > scenario, but does not solve general problems (of 
> identifying message 
> > sequences from different peers).
> > 
> > Considering the scenario in your earlier mail (MN is 
> sending and QNI 
> > case), the QNE3 has no way to tell if the message from QNE2 
> or QNE5 is 
> > newer, since the RSN doesn't apply here.
> > 
> > cheers
> > 
> > Cheng Hong
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Jukka MJ Manner wrote:
> > > Right... True. Even though the RSN changes on some hops 
> of the e2e 
> > > path, this doesn't really need to be propagated anywhere.
> > > 
> > > The only case where we need to do e2e signaling is when the MRI 
> > > changes, e.g., the CoA of the MN.
> > > 
> > > Jukka
> > > 
> > > On Fri, 19 Jan 2007, Roland Bless wrote:
> > > 
> > > > Hi Jukka,
> > > >
> > > > Jukka MJ Manner wrote:
> > > > > There is actually another problem with the RSN.
> > > > >
> > > > > Consider the case "MN as QNR and data receiver"
> > > > >
> > > > > When QNE3 gets the notify, it replies back with a RESERVE 
> > > > > towards QNR which has "RSN=old-RSN +1". But all nodes 
> from QNI 
> > > > > up to QNE3 will still be sending refresh messages 
> using the old RSN.
> > > > >
> > > > > Thus, we need some further mechanism to inform the 
> QNI that it 
> > > > > should use a new RSN value in further refreshes, 
> right? E.g. a 
> > > > > NOTIFY towards the QNI
> > > > No, not really. Maybe I'm completely off-track, but 
> IIRC RSNs have 
> > > > only local significance between directly adjacent QNEs. 
> Thus there 
> > > > is simply no need to notify other nodes upstream of a 
> new RSN value.
> > > >
> > > > > that says "Path changed, new RSN" and include the new RSN? 
> > > > > Sounds like a hack, any suggestions?
> > > > Maybe I need to dig into a scenario down below before I 
> understand 
> > > > the problem, but the above suggestion doesn't make sense to me.
> > > >
> > > >  Roland
> > > >
> > > > > Jukka
> > > > >
> > > > > On Fri, 12 Jan 2007, Takako Sanda wrote:
> > > > >
> > > > > > Hi Jukka,
> > > > > >
> > > > > > I still have a question for the operation below.
> > > > > >
> > > > > >
> > > > > > > > > The tear-down part:
> > > > > > > > > - QNE3 also noticies that the SII-Handle has changed, 
> > > > > > > > > and could basically
> > > > > > > > >   send a NOTIFY to QNE2 and through the QNI's 
> old path saying
> > > > > > > > >   "Route
> > > > > > > > >   Change" 0x02
> > > > > > > > > - QNE2 will forward it to QNE1
> > > > > > > > > - QNE1 would then at some point figure out QNI has 
> > > > > > > > > disappeared, and will
> > > > > > > > >   start removing the reservation using a 
> tearing RESERVE
> > > > > > > > How the QNE1 figure out the QNI has disappeared might 
> > > > > > > > require some enhancement. Maybe the "Route Change" 
> > > > > > > > indication from QNE3 could further identify 
> whether it is 
> > > > > > > > upstream route changed or downstream route changed. It 
> > > > > > > > might help the QNE1 reach the conclusion faster.
> > > > > > > JM: I believe this falls a bit down the path of security. 
> > > > > > > What can a QNE trust? I would rather let the QNE1 
> figure by 
> > > > > > > itself that the QNI has disappeared. The message sent is 
> > > > > > > only a hint that tells QNE1 to verify if QNI is 
> still there. 
> > > > > > > It would only take a few seconds, basically once the 
> > > > > > > retransmission procudure of either GIST or the 
> NSLP fails, QNE1 can deduce that the QNI is gone.
> > > > > > How does QNE1 know the next peer was NI?
> > > > > > In order to know this, I guess, QNE1 needs to have 
> received an 
> > > > > > explicit notification from NI in advance.
> > > > > >
> > > > > > cheers,
> > > > > > Takako
> > > > > >
> > > > > > On Wed, 10 Jan 2007 12:35:00 +0200 (EET) Jukka MJ Manner 
> > > > > > <[email-masked]> wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > some answers below.
> > > > > > >
> > > > > > > Jukka
> > > > > > >
> > > > > > > On Wed, 10 Jan 2007, Hong Cheng wrote:
> > > > > > >
> > > > > > > > Hi Jukka,
> > > > > > > >
> > > > > > > > The operation is well analyzed. The text should be 
> > > > > > > > incorporated into the Mobility Applicability draft. I 
> > > > > > > > think generally a tear-down could be initiated 
> by any QNE 
> > > > > > > > (e.g. the CRN), as long as it is along the 
> direction from 
> > > > > > > > QNI to QNR.
> > > > > > > >
> > > > > > > > Please find a few more comments inline.
> > > > > > > >
> > > > > > > > cheers
> > > > > > > >
> > > > > > > > Cheng Hong
> > > > > > > >
> > > > > > > >
> > > > > > > > Jukka MJ Manner wrote:
> > > > > > > > > Hi Cheng,
> > > > > > > > >
> > > > > > > > > After re-reading the QoS NSLP spec, I think 
> the spec is 
> > > > > > > > > quite accurate in how the NSLP supports 
> mobility, and it 
> > > > > > > > > seems to work properly.
> > > > > > > > > Tearing down
> > > > > > > > > the reservation on the old path from the 
> cross-over QNE 
> > > > > > > > > would be good to do, but not necessarily critical for 
> > > > > > > > > the proper operation of the NSLP. Yet, the 
> current QoS 
> > > > > > > > > NSLP spec mentions the tear-down at the cross-over 
> > > > > > > > > router.
> > > > > > > > >
> > > > > > > > > Consider the following scenario:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > [MN]   [QNE1] --- [QNE2] ---\
> > > > > > > > > |                           \
> > > > > > > > > |                           [QNE3] --- [QNE6] 
> --- [QNE7] ---
> > > > > > > > > |                           /
> > > > > > > > > V                          /
> > > > > > > > > [MN]   [QNE4] --- [QNE5]---/
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The two main (simple) cases are "MN as QNI and data 
> > > > > > > > > sender" and "MN as QNR and receiver"
> > > > > > > > >
> > > > > > > > > "MN as QNI and data sender": we could rely on 
> just the 
> > > > > > > > > soft-state to expire on the old path, and a 
> new RESERVE 
> > > > > > > > > on the new path, or use the following, based 
> on the NSLP 
> > > > > > > > > draft text.
> > > > > > > > >
> > > > > > > > > - MN moves from peer QNE1 to QNE4
> > > > > > > > > - GIST gets a hint that routing has changed, triggers 
> > > > > > > > > the NSLP
> > > > > > > > > - The NSLP then sends a new full RESERVE with 
> a new RSN
> > > > > > > > > - The RESERVE hits QNE4, which makes reservation
> > > > > > > > > - Then the RESERVE is forwarded to QNE5, which also 
> > > > > > > > > makes the reservation
> > > > > > > > > - Finally, the RESERVE hits QNE3, which makes a 
> > > > > > > > > reservation and forwards
> > > > > > > > >   the RESERVE to QNE6, and so on
> > > > > > > > >
> > > > > > > > > The tear-down part:
> > > > > > > > > - QNE3 also noticies that the SII-Handle has changed, 
> > > > > > > > > and could basically
> > > > > > > > >   send a NOTIFY to QNE2 and through the QNI's 
> old path saying
> > > > > > > > >   "Route
> > > > > > > > >   Change" 0x02
> > > > > > > > > - QNE2 will forward it to QNE1
> > > > > > > > > - QNE1 would then at some point figure out QNI has 
> > > > > > > > > disappeared, and will
> > > > > > > > >   start removing the reservation using a 
> tearing RESERVE
> > > > > > > > How the QNE1 figure out the QNI has disappeared might 
> > > > > > > > require some enhancement. Maybe the "Route Change" 
> > > > > > > > indication from QNE3 could further identify 
> whether it is 
> > > > > > > > upstream route changed or downstream route changed. It 
> > > > > > > > might help the QNE1 reach the conclusion faster.
> > > > > > > JM: I believe this falls a bit down the path of security. 
> > > > > > > What can a QNE trust? I would rather let the QNE1 
> figure by 
> > > > > > > itself that the QNI has disappeared. The message sent is 
> > > > > > > only a hint that tells QNE1 to verify if QNI is 
> still there. 
> > > > > > > It would only take a few seconds, basically once the 
> > > > > > > retransmission procudure of either GIST or the 
> NSLP fails, QNE1 can deduce that the QNI is gone.
> > > > > > >
> > > > > > > > > - The tearing RESERVE will eventually hit QNE3, which 
> > > > > > > > > noticies that it has
> > > > > > > > >   an existing, and newer state (higher RSN), 
> and will drop the
> > > > > > > > >   tear
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > "MN as QNR and data receiver": we could rely 
> on routing 
> > > > > > > > > changes to eventually lead to a refreshing 
> RESERVE from 
> > > > > > > > > QNE3 to hit QNE5, which will then send back a 
> RESPONSE 
> > > > > > > > > saying "full QSPEC required". A subsequent 
> full RESERVE 
> > > > > > > > > will then set up the reservation on the new 
> path. Or, in 
> > > > > > > > > order to make it faster, we could use the following:
> > > > > > > > >
> > > > > > > > > - 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
> > > > > > > > This is assuming the QNE4 has already been discovered. 
> > > > > > > > When the MN is QNR and data receiver, considering the 
> > > > > > > > discovery process, wouldn't sending a trigger to QNI 
> > > > > > > > directly result in a faster process?
> > > > > > > JM: Once GIST tells a routing change has 
> happened, the NSLP 
> > > > > > > will ask GIST to send the NOTIFY towards the QNI. 
> For doing 
> > > > > > > that, GIST must find the next peer QNE node, 
> which is QNE4 
> > > > > > > in this case. Since the NSLP works hop-by-hop, you can't 
> > > > > > > really send a message directly to the QNI, 
> without going through all the intermediate nodes.
> > > > > > >
> > > > > > > > > - 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
> > > > > > > > >
> > > > > > > > > The tear down:
> > > > > > > > > - QNE3 should also send a tearing RESERVE 
> with the old 
> > > > > > > > > RSN to QNE2, which
> > > > > > > > >   again sends ti QNE1
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Jukka
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, 14 Dec 2006, Hong Cheng wrote:
> > > > > > > > >
> > > > > > > > > > Hi Jukka,
> > > > > > > > > >
> > > > > > > > > > I would agree that the cross-over router should be 
> > > > > > > > > > left capable of tearing down the unneeded 
> > > > > > > > > > reservations. Please see some comments inline below:
> > > > > > > > > >
> > > > > > > > > > cheers
> > > > > > > > > >
> > > > > > > > > > Cheng Hong
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Jukka MJ Manner wrote:
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > If you look at how the NSIS protocols 
> work, there is 
> > > > > > > > > > > no way a node can make sure a tear-down 
> was intiated 
> > > > > > > > > > > by the QNI. A QNE receives a teardown from its 
> > > > > > > > > > > upstream peer, but it can't tell whether 
> that peer 
> > > > > > > > > > > initiated the tear down in the first 
> place, or the QNI.
> > > > > > > > > > >
> > > > > > > > > > > If I would do a "mobility enhanced QoS NSLP", I 
> > > > > > > > > > > would tear down at the cross-over router the 
> > > > > > > > > > > unnecessary reservation. Of course the 
> spec can say 
> > > > > > > > > > > "don't do it", but a QNE can not really 
> confirm it 
> > > > > > > > > > > isn't being done.
> > > > > > > > > > > And the
> > > > > > > > > > > QNI or the QNR can't see that either.
> > > > > > > > > > >
> > > > > > > > > > > The QoS NSLP spec could say "only the QNI 
> SHOULD (or 
> > > > > > > > > > > MAY) be able to initiate a tear down", and thus 
> > > > > > > > > > > leave the option open for a QNE to also do it.
> > > > > > > > > > >   
> > > > > > > > > > [Cheng] Agree. This should be left open. 
> And I think 
> > > > > > > > > > the quoted text in current QoS NSLP draft is 
> > > > > > > > > > reflecting this point.
> > > > > > > > > >
> > > > > > > > > > > Or we could make a new INFO_SPEC code for 
> > > > > > > > > > > "reservation not need" which is a hint 
> sent by the 
> > > > > > > > > > > cross-over router to inform downstream 
> QNEs on the 
> > > > > > > > > > > old path that the MN has moved away. It 
> is then up 
> > > > > > > > > > > to each QNE to decide whether to remove the 
> > > > > > > > > > > resources and state, or not.
> > > > > > > > > > >
> > > > > > > > > > >   
> > > > > > > > > > [Cheng] This option might lead to some 
> problem though, 
> > > > > > > > > > since it could leave the QNEs on the path 
> > > > > > > > > > unsynchronized should they decide to do different 
> > > > > > > > > > things in response to the INFO_SPEC.
> > > > > > > > > >
> > > > > > > > > > > Jukka
> > > > > > > > > > >
> > > > > > > > > > > On Wed, 13 Dec 2006, Takako Sanda wrote:
> > > > > > > > > > >
> > > > > > > > > > >   
> > > > > > > > > > > > Hi Jukka and all,
> > > > > > > > > > > >
> > > > > > > > > > > > I would like to clarify about tearing 
> down operation.
> > > > > > > > > > > >
> > > > > > > > > > > > In section 3.2.11 (Rerouting), 5th 
> paragraph, it is said,
> > > > > > > > > > > >    "After the reservation on the new 
> path is set up, the
> > > > > > > > > > > >    branching
> > > > > > > > > > > >    node
> > > > > > > > > > > >    may want to tear down the 
> reservation on the old path
> > > > > > > > > > > >    (sooner than
> > > > > > > > > > > >    would result from normal soft-state 
> time-out)."
> > > > > > > > > > > >
> > > > > > > > > > > > This means that the CRN will initiate 
> the TEAR on 
> > > > > > > > > > > > the old path.
> > > > > > > > > > > >
> > > > > > > > > > > > At Munich Interim, It was discussed 
> that tearing 
> > > > > > > > > > > > down from intermediate node needs to be avoided 
> > > > > > > > > > > > because of session ownership issue. But 
> I cannot 
> > > > > > > > > > > > find any conclusion of this discussion.
> > > > > > > > > > > > 
> http://www.ietf-nsis.org/nsis/Munich_Interim_Meeti
> > > > > > > > > > > > ng/MeetingMinutes.html
> > > > > > > > > > > >
> > > > > > > > > > > > Do we have any decision for "tearing down from 
> > > > > > > > > > > > intermediate node"?
> > > > > > > > > > > >
> > > > > > > > > > > > cheers,
> > > > > > > > > > > > Takako
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, 06 Dec 2006 12:09:25 +0200 
> (EET) Jukka MJ 
> > > > > > > > > > > > Manner <[email-masked]> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >     
> > > > > > > > > > > > > Dear all,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I sent the following request for 
> feedback two weeks ago.
> > > > > > > > > > > > > No
> > > > > > > > > > > > > comments
> > > > > > > > > > > > > have been raised. I will wait until 
> this Friday, 
> > > > > > > > > > > > > then submit the draft.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Jukka
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, 21 Nov 2006, Jukka MJ Manner wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >       
> > > > > > > > > > > > > > Hi all,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I have done all the edits I had in 
> my list to 
> > > > > > > > > > > > > > the QoS NSLP spec, the main points are in 
> > > > > > > > > > > > > > recent thread with Roland. From the 
> url below 
> > > > > > > > > > > > > > you can find the current draft v. "13-pre1" 
> > > > > > > > > > > > > > and a diff to v. 12.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > A direct link to the diff:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/d
> > > > > > > > > > > > > > 
> raft-ietf-nsis-qos-nslp-12-from-3-pre1.diff.ht
> > > > > > > > > > > > > > ml
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I would appreciate comments on the 
> changes I 
> > > > > > > > > > > > > > did (what is wrong, what I missed, etc.).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I still have one problem with the 
> spec, namely 
> > > > > > > > > > > > > > the way the NSLP suggests to handle 
> mobility 
> > > > > > > > > > > > > > and path changes. I think we need to review 
> > > > > > > > > > > > > > that statement, because it seems 
> like a "hack"
> > > > > > > > > > > > > > (playing
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > the RSN value), and not really 
> useful. And the 
> > > > > > > > > > > > > > interactions with GIST look partly 
> wrong. The 
> > > > > > > > > > > > > > folks working on the mobility draft (me
> > > > > > > > > > > > > > included) could comment. The section I'm 
> > > > > > > > > > > > > > talking about is 3.2.10, especially 
> 3.2.10.2, 
> > > > > > > > > > > > > > in the v.12 draft.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > BR,
> > > > > > > > > > > > > > Jukka
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >         
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > >>>>> _______________________________________________
> > > > > > > nsis mailing list
> > > > > > > [email-masked]
> > > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > > ----- Takako SANDA <[email-masked]> 
> > > > > > Next-Generation Mobile Communications Development Center, 
> > > > > > Matsushita Electric Industrial Co., Ltd. (Panasonic)
> > > > > > Phone: +81 46 840 5764  Fax: +81 46 840 5122
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > 
> > > 
> > 
> > 
> > 
> > 
> 

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