RE: [NSIS] NSIS mobility related issue # 1 forcomment-CRNdiscovery-related issue

["Seong-Ho Jeong" <shjeong at hufs.ac.kr>]

Hi Robert and all,

Please see my comments in line.

Regards,
Seong-Ho

> -----Original Message-----
> From: nsis-bounces at ietf.org [mailto:nsis-bounces at ietf.org] On Behalf Of
> Hancock, Robert
> Sent: Monday, March 07, 2005 7:03 AM
> To: starsu.lee at samsung.com; john.loughney at nokia.com
> Cc: sanda.takako at jp.panasonic.com; nsis at ietf.org
> Subject: RE: RE: [NSIS] NSIS mobility related issue # 1 forcomment-
> CRNdiscovery-related issue
> 
> hi,
> 
> some comments from a ntlp-designer's perspective (which
> may just display my failure to understand the details here).
> they may still help to illuminate the discussion.
> 
> 1. it isn't clear to me what distinction is made between
> NTLP-crossover and NSLP-crossover nodes. according to the
> current GIMPS design, no per-flow state is stored in GIMPS
> which is relevant to a flow except at nodes which also
> process the NSLP in question. so, the NTLP-crossover node
> detected by GIMPS will always be NSLP capable, and thus
> would (presumably) be the NSLP-crossover node.

The basic motivation of the distinction between different types 
of CRN is to identify where the CRN is discovered. Yes, the 
problem is truly about 'NSLP CRN discovery' although the CRN 
can be detected at the NTLP layer.
> 
> Is this document about possible NTLPs or about GIMPS as
> 'the' NTLP this sort of context?

Currently, the document discusses mainly the functionality 
of GIMPS since other parts of the NTLP are not new...
> 
> 1a. In the following, I assume that the CRN is really the
> NSLP-relevant CRN (since only the NSLP can carry out repair
> actions). So we are talking about which layer should
> discover the NSLP-CRN.

I agree as mentioned above.

> 
> 2. GIMPS only associates state with flow/NSLP combinations.
> (It knows about sessions, but takes almost no notice of
> them. In particular, it really doesn't know whether sessions
> are associated with each other, or whether several flows
> are really associated with the same session, and it
> doesn't validate anything about what session identifiers
> are used.)
> This means that there are several scenarios where the CRN
> which the NSLP is interested in cannot be detected by the
> NTLP. One example would be where an old flow is replaced
> by a new one with a difference path. The NSLP doesn't care
> about this but the NTLP would see nothing here.
>
> A converse case would be that the NTLP detects a route
> change for a flow, which the NSLP doesn't care about
> (because the flow has been replaced and the NSLP is
> letting it die away).
> 
> Another case is where there is a single flow and session
> for which a potential route change is detected by the
> NTLP at one node, but the NTLP doesn't actually know
> where the true CRN is. (This is the situation discussed
> in section 6.1 of the GIMPS spec.)

In Section 6.1.4 of the GIPMS draft, it was mentioned that
NSLP peers are a single GIMPS hop apart. Does it mean that
GIMPS is closely coupled with NSLP? Is it possible to allow
different GIMPS states to be set up according to the type 
of NSLP? I think this can be true if we take a look at 
Figure 7 in Appendix B. In this case, I think the CRN 
discovery would not be too difficult if the messaging 
association setup process is used. In other words, it may 
not be too difficult to determine if the current node is 
a CRN because the GIMPS can use the flow ID, session ID, and 
NSLP ID as well as pointer which are already needed for messaging 
association, and the GIMPS can let the involved NSLP know 
the information to perform necessary actions immediately..
Please correct me if I am wrong.

> 3. I think my conclusions from this are two-fold (and
> there is an open question to go with them):
> 
> - the NTLP should discover [some] nodes where the route
> of a flow [may have] changed, and report this to the NSLP
> 
> - the NSLP should decide whether it is a CRN which it
> has to do something about
> 
> The open issue is whether
> a) the NTLP should hunt down the true route change point
> itself, or
> b) whether it should leave this up to the NSLP to do so.
> 
> Option (a) is clearly a nice case of the NTLP providing
> a common service. However, this represents a load on
> the network which may not be justified; only the NSLP
> can decide this. Option (b) requires additional messages
> at the NSLP level, but this may be required anyway for
> reporting route changes which are discovered directly
> by the signalling application. So my preference is (a)
> here.
> 
> It would be helpful for the GIMPS progress to get a
> comment on whether the analysis of this issue provides
> any further insight on the issues of section 6.1 of
> the GIMPS draft (since this hasn't received much
> attention so far.)
> 
> cheers,
> 
> r.
> 
> > -----Original Message-----
> > From: nsis-bounces at ietf.org [mailto:nsis-bounces at ietf.org] On
> > Behalf Of Sung-Hyuck Lee
> > Sent: 06 March 2005 03:56
> > To: john.loughney at nokia.com
> > Cc: nsis at ietf.org ; sanda.takako at jp.panasonic.com
> > Subject: Re: RE: [NSIS] NSIS mobility related issue # 1 for
> > comment-CRNdiscovery-related issue
> >
> >
> > Hi John and all,
> >
> > John Loughney wrote:
> > >
> > > Hi all,
> > >
> > > I partially agree with Takako on this, though I may be wrong on my
> > > comment ...
> > >
> > >> I am not sure the definition of "NSLP discovers the CRN".
> > But I think
> > >> both layers need to be involved in CRN discovery. As the
> > CRN belongs
> > >> to a particular NSLP session, it would be possible that
> > CRN discovery
> > >> procedure is initiated by the NSLP messages from that
> > particular NSLP
> > >> application. Although NTLP has a functionality for CRN discovery
> > >> (e.g. by comparing IDs and adjacent peer), it may requires a tight
> > >> integration with NSLP. At least it should be decided which layer
> > >> triggers CRN discovery procedure.
> > >
> > > Are we finding the cross-over NTLP-node or the cross-over
> > NSLP node?
> > > My feeling is that the NSLP CRN may be more relevant,
> > ultimately.  It
> > > seems that NTLP layer will be hop-by-hop, so an NTLP-CRN
> > doesn't realy
> > > seem applicable.  Once an NSLP discovers the CRN, then it
> > may need to
> > > trigger some discovery at the NTLP layer.  Comments?
> >
> > I agree that the objective of CRN discovery is to find the
> > logical merging point related to the NSLP states. In this
> > issue, what authors of the mobility draft would
> > like to address is that it is more appropriate to detect the
> > NSLP CRN at the NTLP
> > layer, and an explicit action for the CRN discovery may be
> > able to done if
> > necessary. In this case, which action in the NSLP level needs
> > to be considered?
> > Also, is there any advantage for CRN discovery if it is done?
> >
> > The authors have seemed to think that actually NTLP layer was
> > tightly coupled
> > with NSLP layer to perform messaging association with the peer node;
> > The GIMPS message has message routing state information such as
> > flow/session/NSLP identifiers, so the signaling application
> > can be identified at
> > the NTLP layer through the procedure of messaging
> > association. This means
> > that the NSLP CRN can implicitly be discovered by using the
> > flow/session/NSLP identifiers at the procedure of NSLP peer
> > node discovery of NTLP layer. It results
> > in reducing processing overhead by avoiding unnecessary
> > procedure to discover
> > the CRN at NSLP layer.
> >
> > Some mobility scenarios have an effect on performing the CRN
> > discovery. For
> > example, in a ping-pong type handover scenarios, it is
> > required to immediately
> > find the latest CRN. In this case, since the NTLP layer can
> > immediately detect the
> > route changes caused by mobility, the NSLP CRN discovery at
> > the NTLP layer
> > can also be preferred to that at the NSLP layer to perform
> > such a fast discovery.
> >
> >
> > Thanks,
> >
> > Sung-Hyuck
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis at ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis







_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis