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

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 23 Feb 2004 13:09:22 -0000

hi,

[snip]

> > 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).
> 
> 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.

"you" (i.e. the signalling application) can use the Session-ID 
like this. however, you could use it other ways as well.

> 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.

This would be the normal mode of operation, but I don't think 
we can be that prescriptive about how session-ID is interpreted.
examples:

a) there is a flow from S to R, and some reverse routing state
already exists to get signalling from R to S. Both S and R want
to make reservations for the flow, but neither knows the S-ID
that the other will use. Consequence: two reservations. (Another
way of putting this: in your phrase "must represent a flow which
is not established in the network", how would a node ever be able
to ensure that a flow was not established in the network? This
is information it could never know.)

b) at the GIMPS level you receive two discover messages for the
same flow but from different directions (different peers). This
might be for several reasons (some legitimate, some malicious);
GIMPS uses the Session-ID to separate the routing state for each.

> 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 ?

Session-ID is as global as the NSLPs make it. Typically, I assume
it will be valid along the entire path. (This does not mean that 
there can be only one for a given flow.) There might also be reasons
why the session changed mid-path (e.g. to interwork between sender-
and receiver-initiated signalling paradigms at a proxy node.) It
all depends on the NSLP.

r.

> Nary Tra,
> ENST, Paris.

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

---

From: "Cheng Hong" <[email-masked]>
Date: Tue, 24 Feb 2004 16:18:56 +0800

Hi Robert and all,

<Snip>
> 
> Session-ID is as global as the NSLPs make it. Typically, I 
> assume it will be valid along the entire path. (This does not 
> mean that 
> there can be only one for a given flow.) There might also be 
> reasons why the session changed mid-path (e.g. to interwork 
> between sender- and receiver-initiated signalling paradigms 
> at a proxy node.) It all depends on the NSLP.
> 
> r.

If the NSLP decides how global the Session-ID is, could we say that
Session-ID could only be unique within the specific NSLP space? It means the
different NSLP applications could choose different session ID value for the
same flow, and use the same session id for unrelated flows?

Best regards

Cheng

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Tue, 24 Feb 2004 10:57:39 +0100

hi robert,

> is information it could never know.)

I don'n mention how to create a global SESSION_ID (e.g. random)  here,
supposing that there are some ways to do it.  in case of bidirectional
reservation, if these are two indenpendent reservations, it is easy, you can
take two different SESSION_IDs. NTLP can not know the relation between two
reservations. If two reservations are not independent, there must be some
mechanism to know it (off path signaling, aller-retour (reservation S to R
and then R to S or vice versa)...).

> GIMPS uses the Session-ID to separate the routing state for each.

i don't understand what flow you mean. For me, the flow from S to R and the
flow from B to A are different.
At NTLP level, if it receives two messages for the same flow but from
different directions (different peers) and IF it knows the routing is
symmetric, the route discovery is not necessary.

> and receiver-initiated signalling paradigms at a proxy node.) It

i agree.

Nary Tra,
ENST, Paris