Subject: Session-ID in GIMPS (was: RE: [NSIS] Re: Session in NSIS)

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 23 Feb 2004 11:02:54 -0000

dear all,

some comments on this from the actual protocol operational 
perspective.

1. GIMPS currently requires a Session-ID *and* flow information
in each message. This means that any NSIS message *has* to have
a session-id set to some value.

We could think about changing this. At the moment, GIMPS doesn't
use the Session-ID internally so probably one could make it
mandatory only in messages containing an NSLP payload. (An example
could be a message setting up path (GIMPS) state for a signalling 
application but which actually created no signalling application
state.)

(However, the mobility discussion or other further refinements 
may imply that GIMPS would look at the Session-ID in message 
processing. It's probably a bit early to rule that out.)

2. I think the discussion of which node 'chooses' the Session-ID
is a bit reversed. Any node can set the Session-ID for a message
to be anything it likes; if the signalling application doesn't
set a value in an outgoing message, I guess GIMPS will have to
choose one. It's entirely up to NSLP designers to decide the rules
whereby a either a new value is chosen, or one is used from another
message (e.g. an incoming one). It's impossible in general to say 
anything more than that without getting into circular definitions
(for example:
- signalling session = messages with the same session id;
- initiator = node which begins the signalling session;
==> "the NI sets the Session-ID" but that doesn't really say anything).

More detail has to come from the individual NSLP designers saying
how this message field is actually being used. That could well
be different between different signalling applications.

cheers,

robert h.

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email-masked]]
> Sent: Friday, February 20, 2004 12:57
> To: 'Thanh Tra LUU'
> Cc: 'nsis'
> Subject: RE: [NSIS] Re: Session in NSIS
> 
> 
> hi Nary Tra, 
> 
> ~snip~
> 
> > 
> > i agree. in any case, session-id does not give enough 
> information for
> > authentication, authorization. however, how to use the 
> session-id for
> > re-authentication and re-authorization is not clear now :o)
> 
> true. i think that the reason for this is that the mobility 
> handling is not
> fully specified and needs more discussions. once the expected 
> signaling
> behavior is clarified it would be useful to take a look at 
> the proposed
> security mechanisms again and to provide some text for the 
> individual nslps.
> 
> 
> ciao
> hannes
> 
> > 
> > Nary Tra,
> > ENST, Paris
> > 
> > 
> 
> _______________________________________________
> 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: Mon, 23 Feb 2004 12:37:02 +0100

hi hancock,

> ==> "the NI sets the Session-ID" but that doesn't really say anything).

it does not seem very clear. i guess i understand your idea. you mean that
some nodes can initiate a signaling session and it depends on NSLP ? for me,
a session-id is a flow-id if there is no change of address. session-id is a
"symbol" of flow. if a node initiates a signaling session, the session-id
must represent a flow which is not established in network or represent an
aggregation flow. in this case, the node is NI of the aggregation flow but
it is not the NI of individual flows.

otherwise, if i misunderstand your idea, do you mean session-id is not
global ?

Nary Tra,
ENST, Paris.