Subject: RE: [NSIS] SESSION_ID

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 15 Jan 2004 11:18:31 -0000

nary,

you might like to read the thread starting with
http://www.ietf.org/mail-archive/working-groups/nsis/current/msg03460.html
where precisely this question was (eventually) discussed.

the basic point (I believe) is that session-ids are allocated by
nodes in a way which (ideally) would be globally unique; since 
everyone knows that local allocation of globally unique ids is
extremely hard, we will settle for probabilistic uniqueness and live
with the consequences of that.

what is (at the moment deliberately) unspecified is the set of rules
which a node should follow in allocating session-ids. so the answer
to your question is: "maybe; maybe not; why does it matter?"

it may be we will have to specify some rules, but i don't think we
should make them up just for the sake of it right now.

from an engineering perspective, there are many similar considerations
here to the discussions that took place in ipv6 w.g. about how
tightly/loosely the flow label should be defined. (although the flow
label is a completely independent entity from the session id, the
questions like 'who allocates it' and 'what does it map onto' and
'how precisely should we define it' are very similar IMHO.) the end
result (currently in draft-ietf-ipv6-flow-label-09.txt) is I think a
good guide on how to think about the question.

hope this helps,

robert h.

> -----Original Message-----
> From: Thanh Tra LUU [mailto:[email-masked]]
> Sent: Wednesday, January 14, 2004 09:23
> To: Cheng Hong
> Cc: [email-masked]
> Subject: Re: [NSIS] SESSION_ID
> 
> 
> hi Cheng,
> 
> i totally agree. so i made the question for a confirmation.
> 
> session-id is used to identify one flow  + one nslp-id ?
> 
> (flow is data flow between 2 end hosts. of course, ip addresses can be
> changed ;-) )
> 
> Nary Tra,
> ENST, Paris.
> 
> > Hi Nary,
> >
> > I don't think the text suggest that the session ID is just 
> for ONE flow.
> It
> > is quite possible that ONE signaling application could own 
> multiple flows.
> >
> > Cheers
> >
> > Cheng
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Thanh Tra LUU
> > > Sent: Monday, January 12, 2004 6:00 PM
> > > To: [email-masked]
> > > Subject: [NSIS] SESSION_ID
> > >
> > >
> > > hi all,
> > >
> > > In our framework, authors write "the session identifier can
> > > be used by the NTLP to demultiplex received signaling
> > > messages  between multiple instances of the same signaling
> > > application".
> > >
> > > i just want to confirm: is it right that a session-id is only
> > > used for one flow and ONE signaling application ?
> > >
> > > B. regards,
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Thu, 15 Jan 2004 14:13:19 +0100

hi hancock,

> with the consequences of that.

i agree and i don't try to mention the golbally unique characteristic  of
Session-id in this discussion.

> good guide on how to think about the question.

i've had the same engineering perspective of session-id as you stated.
Otherwise, nothing is impossible. For example, if i implement a NSLP daemon
which is a NSLP environment to support all NSLP signaling application, it is
easier for NTLP to pass NSLP payload of all NSLP types to NSLP daemon.
Otherwise, i implement a NSLP_A daemon for signaling application A, NSLP_B
daemon for signaling application B...in this case, NTLP must decide which
daemon is selected to send NSLP payload. just some thoughts about NSLP/NTLP
interface. i reread the documents and thanks for your advices.

Nary Tra,
ENST, Paris.