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

From: "Cheng Hong" <[email-masked]>
Date: Mon, 22 Jan 2007 14:43:01 +0800

Hi Jukka 

> QNE1 just figures out that its next peer for the session is 
> not there anymore, thus, the reservation can be torn down.

If QNE1 doesn't know the next peer is QNI, would not it attempts some
new path discovery/rerouting to find a new peer instead of immediately
do a tear down? Although it is pretty much a local configuration issue,
if no indication is available to help QNE1 making the decision, it may
take quite long for it to decide tearing the old session down.

Cheers

Cheng Hong 

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: Thursday, January 18, 2007 12:06 AM
> To: Takako Sanda
> Cc: Cheng Hong; [email-masked]
> Subject: Re: [NSIS] Re: Clarification: tearing down from 
> intermediate node
> 
> 
> Hi,
> 
> QNE1 does not need to know that the next peer is the QNI. 
> QNE1 just figures out that its next peer for the session is 
> not there anymore, thus, the reservation can be torn down.
> 
> 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_Meeting/MeetingMi
nutes.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/draft-ietf-nsis-q
os-nslp-12-from-3-pre1.diff.html
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 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

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 22 Jan 2007 11:36:49 +0200 (EET)

Yes, it will use the defined retransmission procedure before giving up, or 
GIST can indicate that there is no more QNEs on this path.

Jukka